Nachdem ich bereits das TOTP-Verfahren zur 2-Faktor-Authentifikation in einem Beitrag erwähnt habe, möchte ich in diesem auf U2F eingehen.
Hierfür werde ich Schritt für Schritt die einzelnen Mechanismen skizzieren und erklären.
Universal Second Factor ist ein von der FIDO Aliance[1] angetriebener offener Standard für Geräte zur 2-Faktor-Authentifikation. Hierbei soll der zweite Faktor durch Besitztum erreicht werden. Unterstützt werden prinzipiell USB, NFC und Bluetooth.
Grundsätzlich baut der Standard auf dem Prinzip der Public-Key-Kryptographie[2] und dem Challenge-Response-Verfahren[3] auf.
Ich möchte an dieser Stelle die grundsätzliche Vorgehensweise eines Challenge-Response-Verfahrens erläutern. Aufbauend auf diesem Modell sollen anschließend weitere Mechanismen aufgegriffen werden.
Das Gerät hält einen privaten Schlüssel, der das Gerät nie verlässt. Bei der Registrierung wird dem Server der öffentliche Schlüssel übergeben (Wie dies genau funktioniert werde ich später genauer beschreiben, da vorher noch einige Vorgänge näher beleuchtet werden müssen).
Die prinzipielle Vorgehenswieise ist die Folgende:
Ausgehend von diesem Sequenzdiagramm werden im Folgenden weitere Funktionen und Verfahren des U2F Standards erläutert.
In unserem obigen Bild wäre es nun einfach, einen Phishing Angriff [4] durchzuführen.
Um dies zu verhindern, wurde dieses Phishing Protection genanntes Verfahren entwickelt:
Dadurch, dass neben der Challenge zusätzlich die Origin vom Gerät signiert wird, ist es dem Server möglich die Authentifikaiton abzulehnen, wenn ein Phishing Versuch vorliegt und diese daher fehlerhaft ist.
In der obigen Abbildung ist es möglich, den Benutzer anhand seines Keys zu tracken bzw. herauszufinden, auf welchen Diensten dieser genutzt wird. Darum ergänzen wir unser Sequenzdiagramm in diesem Schritt um folgendes:
Es wird also für jeden Dienst ein seperates Schlüsselpaar genutzt. Anhand der appID und des handles kann das Gerät mit dem passenden privaten Schlüssel signieren. Somit weist das Gerät keine eindeutige Kennung nach außen auf. Selbst wenn die Zugangsdaten eines Dienstes (aus welchem Grund auch immer) öffentlich werden.
Hierfür wird am Gerät zustätzlich ein Counter (Zähler) implementiert, der sich bei jeder Signatur erhöht.
Der Server speichert den letzten Counter-Wert und prüft, ob dieser höher als der vorherige ist.
Ist dies nicht der Fall, liegt ein Problem vor bzw. das Gerät wurde in irgendeiner Form geklont.
Hierzu ist anzumerken, dass diese Lösung nicht immer Funktioniert. Wenn das geklonte Gerät sich zuerst bei einem Dienst anmeldet, wird dieses angenommen. In wiefern es weitere Mechanismen zur Cloning-Protection auf hardwareebene gibt ist sicherlich vom entsprechenden Gerät an und für sich abhängig.
Nachdem wir uns Stück für Stück an die Funktionsweise herangetastet haben, möchte ich hier noch den Ablauf der Registration darstellen.
Das Zertifikat zur Übertragung des public keys entspricht dem X.509 Standard[5]. Dieses wird beispielsweise bei der Nutzung von HTTPS Seiten genutzt.
Nachdem die grundsätzliche Vorgehensweise erläutert wurde, möchte ich diese nun mit einem Praxisbeispiel veranschaulichen. Zum Testen bietet sich eine vom Hersteller yubico bereitgestellte Testseite[6] an.
Zur Registrierung wird ein Benutzername und ein Kennwort gewählt. Anschließend wird man aufgefordert den Vorgang physisch am U2F Gerät zu bestätigen.
Folgende Daten können während der Registrierung eingesehen werden:
Login Data
username: security101_U2F_test
password: vCRz2%)PxuRBAMu83UfkT$/MmreXZ{
Registration Data
origin: https://demo.yubico.com
version: U2F_V2
challenge: fIqqz7ymVeuNmq4A89X0wA47dlETvHQg4npm69kKmiY
appId: https://demo.yubico.com
Response Data
clientData: {"typ":"navigator.id.finishEnrollment","challenge":"fIqqz7ymVeuNmq4A89X0wA47dlETvHQg4npm69kKmiY","origin":"https://demo.yubico.com","cid_pubkey":"unused"}
registrationData: 0504dcb4c288b614c28e8d175cee743a8cffa2a52d6b044148add5e3f84cac432b09093b44310b44d49a31d737e47d5af6b36f59a8b35c2345e5f0bd9f1a6df7367840ba92cc8a5f03f2ec9252fa92eab579bce62923b7613ba1d897a0531bbcf6b6f48b3d93eb5d823fe55ee7ed66da8bd11c06ea62a5d57d7006f625620aaea9613a3082015d30820103a003020102020121300a06082a8648ce3d04030230273125302306035504030c1c4c6564676572204649444f204174746573746174696f6e2043412031301e170d3136303732313133333633375a170d3236303730393133333633375a3030312e302c06035504030c254c6564676572204e616e6f2d5320553246204174746573746174696f6e20426174636820313059301306072a8648ce3d020106082a8648ce3d0301070342000423c27f2c89f642caa2acafd8914c7aa6d3e2c04b37125df69a16867258ec404630980bf89c432ce689efec046f5a5cf461d02335a08384987860e1fcd70cd387a31730153013060b2b0601040182e51c020101040403020520300a06082a8648ce3d040302034800304502207a1a27a2cbde2978826be0fdbd4ca85e3f6e3f72417c5968dba9407e60c46a140221008f2aff7afeff55cf8fced7f579cfec9c87940aa5442560c6e79f3da01aaa6a423045022100d5c80f0b83529936daf50d1c8cfebbc0b7f35111f2168678b5ff95b7ba51d5da02204c56aa2039974cc7c3dd1e3ded876346a957c637fd85fc04f6f403cd912d9fb1
Attestation Certificate
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 33 (0x21)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=Ledger FIDO Attestation CA 1
Validity
Not Before: Jul 21 13:36:37 2016 GMT
Not After : Jul 9 13:36:37 2026 GMT
Subject: CN=Ledger Nano-S U2F Attestation Batch 1
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:23:c2:7f:2c:89:f6:42:ca:a2:ac:af:d8:91:4c:
7a:a6:d3:e2:c0:4b:37:12:5d:f6:9a:16:86:72:58:
ec:40:46:30:98:0b:f8:9c:43:2c:e6:89:ef:ec:04:
6f:5a:5c:f4:61:d0:23:35:a0:83:84:98:78:60:e1:
fc:d7:0c:d3:87
ASN1 OID: prime256v1
X509v3 extensions:
1.3.6.1.4.1.45724.2.1.1:
...
Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:7a:1a:27:a2:cb:de:29:78:82:6b:e0:fd:bd:4c:
a8:5e:3f:6e:3f:72:41:7c:59:68:db:a9:40:7e:60:c4:6a:14:
02:21:00:8f:2a:ff:7a:fe:ff:55:cf:8f:ce:d7:f5:79:cf:ec:
9c:87:94:0a:a5:44:25:60:c6:e7:9f:3d:a0:1a:aa:6a:42
-----BEGIN CERTIFICATE-----
MIIBXTCCAQOgAwIBAgIBITAKBggqhkjOPQQDAjAnMSUwIwYDVQQDDBxMZWRnZXIg
RklETyBBdHRlc3RhdGlvbiBDQSAxMB4XDTE2MDcyMTEzMzYzN1oXDTI2MDcwOTEz
MzYzN1owMDEuMCwGA1UEAwwlTGVkZ2VyIE5hbm8tUyBVMkYgQXR0ZXN0YXRpb24g
QmF0Y2ggMTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABCPCfyyJ9kLKoqyv2JFM
eqbT4sBLNxJd9poWhnJY7EBGMJgL+JxDLOaJ7+wEb1pc9GHQIzWgg4SYeGDh/NcM
04ejFzAVMBMGCysGAQQBguUcAgEBBAQDAgUgMAoGCCqGSM49BAMCA0gAMEUCIHoa
J6LL3il4gmvg/b1MqF4/bj9yQXxZaNupQH5gxGoUAiEAjyr/ev7/Vc+Pztf1ec/s
nIeUCqVEJWDG5589oBqqakI=
-----END CERTIFICATE-----
Nach dieser Registrierung ist es möglich sich anzumelden. Dafür wird wieder der Benutzername mit dazugehörigem Kennwort eingegeben und nach Aufforderung mit dem U2F Gerät bestätigt.
Bei einem erfolgreichen Login können folgende Daten eingesehen werden:
Login Data
username: security101_U2F_test
password: vCRz2%)PxuRBAMu83UfkT$/MmreXZ{
Challenge Data
version: U2F_V2
challenge: EukOIwh52fC_LRMcS3B9HXrPA3Yw_RDaOZ0BOUOZUU0
keyHandle: upLMil8D8uySUvqS6rV5vOYpI7dhO6HYl6BTG7z2tvSLPZPrXYI_5V7n7Wbai9EcBupipdV9cAb2JWIKrqlhOg
Response Data
clientData: {"typ":"navigator.id.getAssertion","challenge":"EukOIwh52fC_LRMcS3B9HXrPA3Yw_RDaOZ0BOUOZUU0","origin":"https://demo.yubico.com","cid_pubkey":"unused"}
signatureData: AQAAAAMwRAIgbYpkN7QL5GJn4y3p4OrbnvQhF9Po12H1-nzh5G2yb4gCIBLmxlUoR2RwEtIYQe_VXHej0eaKuUwhwI-pLzerPY3R
Authentication Parameters
touch: true
counter: 3
Ich möchte an dieser Stelle bewusst keine Empfehlung aussprechen, da ich in die Umsetzung der Hardware wenig einblicke habe. Dennoch möchte ich eine kleine Auswahl mir bekannter U2F Geräte vorstellen:
(*) Alle Links wurden am 12.02.2018 zwischen 08:00 und 16:00 Uhr eingesehen
Ich möchte darauf Hinweisen, dass ich hier nur eine grobe Übersicht geben wollte und einige Details außer acht gelassen wurden.
Vielen Dank fürs Lesen !