Differences

This shows you the differences between two versions of the page.

--- yubikey4hk:funktionen:fido2 [2020-07-01 09:51] – ↷ Page moved from forum_2.0:yubikey4hk:funktionen:fido2 to yubikey4hk:funktionen:fido2 Maximilian Barger
+++ yubikey4hk:funktionen:fido2 [2023-09-22 20:40] (current) – external edit 127.0.0.1
@@ Line 15: / Line 15: @@
 Doch nun stellt sich die Frage, wie dieses Protokoll im Hintergrund funktioniert. U2F baut auf einem Challenge-Response-Verfahren mit Public-Key-Kryptographie auf. Dabei generiert der Server eine Challenge und sendet diese an den Client. Der Client wiederrum leitet diese an den YubiKey weiter. Der YubiKey wartet nun auf den Benutzer, damit dieser auf den Kontakt drückt und die Authentifizierung fortgeführt werden kann. Anschließend wird die Challenge mit dem zum Service gehörigen privaten Schlüssel vom YubiKey signiert und an den Server zurückgesendet. Der Server hat den passenden öffentlichen Schlüssel gespeichert und kann somit die Signatur verifizieren. Das ist der sehr vereinfachte Ablauf des Authentifzierungsvorgangs von U2F und ist hier schematisch in einem Bild dargestellt. <sup>[[#Quellen|[5]]]</sup><sup>[[#Quellen|[6]]]</sup>\\
-{{https://intern.hagenbergerkreis.at/wiki/_media/forum_2.0/yubikey4hk/funktionen/u2f_schematic.png?600}}\\
+{{yubikey4hk/funktionen/u2f_schematic.png?600}}\\
 Bevor wir auf den Ablauf bei der Authentizierung genauer eingehen, werden wir die Schlüsselerzeugung bzw. den Registrierungsvorgang erklären.
@@ Line 29: / Line 29: @@
 === Authentifizierung ===
 Nun wird ein genauerer Blick auf den Ablauf des FIDO-Authentifzierungsvorgangs geworfen. Im nächsten Bild werden die Inhalte der einzelnen Übertragungen genauer aufgeschlüsselt:
-{{https://intern.hagenbergerkreis.at/wiki/_media/forum_2.0/yubikey4hk/funktionen/u2f_ablauf.png?600}}\\
+{{yubikey4hk/funktionen/u2f_ablauf.png?600}}\\
 Begonnen wird auf der Serverseite. Hier sendet die Relying Party, also ein Server bei dem ich mich anmelden möchte, eine //Challenge//, ein //Handle// und eine //AppID//. Die //Challenge// ist ein zufälliger Wert der signiert zurückgesendet werden soll. Die //AppID// ist ein einzigartiger Wert des Services, um den //Handle// auf diesen einen Service zu beschränken.\\
 Der Client leitet alles weiter und fügt weitere Informationen hinzu. Dazu zählt der //origin// und die //channel id//. Im //origin//-Feld steht die URI der Relying Party. Dies beugt Phishing vor (die URI wäre sonst eine andere). Die //channel id// beinhaltet die ID des TLS Channels und verhindert MitM-Angriffe, da bei einem Angriff eine andere Channel ID verwendet wird. Diese Werte werden später signiert und der Relying Party präsentiert, dass dieser auch sichergehen kann, dass kein Angriff stattgefunden hat.\\
@@ Line 44: / Line 44: @@
 Um die verschiedenen Protokolle, die in FIDO2 verwendet werden, einordnen zu können, soll folgendes Bild helfen:
-{{https://intern.hagenbergerkreis.at/wiki/_media/forum_2.0/yubikey4hk/funktionen/fido2_protocol_stack.png?600}}
+{{yubikey4hk/funktionen/fido2_protocol_stack.png?600}}
 Hier erkennt man die Rückwärts-Kompatibilität, nämlich dass CTAP1/U2F immer noch unterstützt wird. Dazu hat die FIDO-Alliance CTAP2 hinzugefügt, das unter anderem die Single-Faktor-Authentifzierung ermöglicht. Die Kommunikation zwischen Browser bzw. Client und dem Server übernimmt der WebAuthn-Standard. Das hat den Effekt, dass eine einheitliche Schnittstelle zwischen Browser und Server entsteht, unabhängig vom darunterliegenden Authenticator des Clients. Authenticator können zum Beispiel der YubiKey, ein SmartPhone oder auch Windows Hello sein.<sup>[[#Quellen|[9]]]</sup>\\
@@ Line 52: / Line 52: @@
 Der private Schlüssel muss nun aber, wenn die vorherig genannte Anmeldemethode verwendet wird, auf dem Gerät gespeichert werden und liegt nicht mehr in verschlüsselter Form auf dem Server. Der YubiKey kann 25 verschiedene Schlüssel speichern.<sup>[[#Quellen|[12]]]</sup> Man ist jetzt also begrenzt!\\
 Das Verfahren wird im folgenden Bild zusammengefasst:\\
-{{https://intern.hagenbergerkreis.at/wiki/_media/forum_2.0/yubikey4hk/funktionen/fido2_ablauf.png?600}}\\
+{{yubikey4hk/funktionen/fido2_ablauf.png?600}}\\
 Im Falle, dass man FIDO als zweiten Faktor, neben dem statischen Passwort verwendet, wird wie vorher erklärt auf das CTAP1/U2F-Protokoll zurückgegriffen. Hierbei werden wieder non-resident Schlüssel vewendet. Dazu wird kein Speicherplatz am YubiKey benötigt.
 <sup>[[#Quellen|[8]]]</sup>