Funktioniert so Passkey?

[PaulEdison]

Hallo,

Ich versuche gerade zu verstehen was Passkeys sind und wie sie funktionieren, und am besten geht das glaube ich das ich sie versuche zu beschreiben und ihr sagt mir ob ihr das auch so seht

Also, sie basieren auf dem Private-Public Encryption Prinzip, das folgendermaßen eingesetzt wird:

01: Client: User surft mit seinem Browser auf eine Website "example.com" (die Passkeys unterstützt)
02: Client: User authentifiziert sich bei seinem login mit Username + passwort.
03: Client: User geht in Webseite auf "Passkey hinzufügen" und löst damit folgenden Erstellungsprozess aus:
04: Client: Browser startet im "Secure Element" (TPM, etc) die Erstellung des Key-Pair (private + public)
05: Client: Browser sendet den "Public Key" an den server
06: Server: Hinterlegt den "Public Key" im Account Profil des users.
07: Client: Hinterlegt den "Private Key" im "Secure Element" in einer DB in einem KeyValue paar ab ("example.com" -> "Private Key").
08: Time goes by
09: Client: surft wieder auf die Website "example.com", gibt den Username an und klickt auf "login mit passkey"
10: Server: sendet ein "gib mir den Passkey für meine domain" + hier ist die "Challenge"
11: Client: Brower öffnet eine Lokale "autorisierungsabfrage" -> diese ist der Windows Login PIN / Finger Abdruck
12: Client: User gibt den PIN ein
13: Client: Browser übergibt die domain "example.come" + die "Challenge" an das "Secure Element" und sagt "Passkey login"
14: Client: "Secure Element" signiert die "Challenge" und gibt diese "Response" zurück.
15: Cleint: Browser sendet die "Response" zurück
16: Server: kann die "Response" mit dem im Account hinterlegten PublicKey verifizieren -> nutzer ist autorisiert. (ab hier wir mit passwort login -> cookie/session ID bla bla)
17: Time goes by
18: Client: User clickt auf phishing link und kommt auf eine seite die so aussieht wie "example.com" aber wirklich "example.trusted-verification.com" ist.
19: gibt den Username an und klickt auf "login mit passkey"
20: Server: sendet ein "gib mir den Passkey für meine domain" + hier ist die "Challenge"
21: Client: Brower öffnet eine Lokale "autorisierungsabfrage" -> diese ist der Windows Login PIN / Finger Abdruck
22: Client: User gibt den PIN ein
23: Client: Browser übergibt die domain "example.trusted-verification.com" + die "Challenge" an das "Secure Element" und sagt "Passkey login"
24: Client: "Secure Element" sagt - die einträge gibt es nicht -> phishing verhindert.


So weit so gut. aber ich habe dennoch ein paar Fragen.
1) Stimmt das mal so in etwa?
2) Wäre ein ablegen im "Secure Element" mit einem PublicKey des Servers nicht besser als nur die domain? Oder ist das egal?
3) Mir ist klar das Privat-Public-Key verfahren viel sicher ist als Passwörter austauschen, aber hängt dann nicht automatisch alles von dem "Secure Element" ab?
3.1) Es wird zu einem sehr lohnenden Ziel?
3.2) Eine Synchronisierung ist als solches nicht möglich?
3.3) Gibt es eine Backup möglichkeit der Datenbank (eine Syncronisierung sehe ich nicht als solche an)?
4) Ist auch trotz dem PP-Key verfahren nach wie vor ein MITM angriff möglich? (Beim schrieben denke ich dass sollet mittels PKI (HTTPS und Certifikaten (und auch PP-Key)) verfahren unterbunden werden) - aber trotzdem)
5) Gibt es Implementierungen die auf einem normalen PasswordStore (e.g.: KeypassXC etc) bassiert?
6) Ist die Idee das ich mich mit jedem Gerät einzeln in einem Account mit einem eigenen Passkey eintrage? (Apple, Google bieten schon syncroniseirung an, aber auch mit Windows?)
7) Gibt es schon Linux (Desktop) Lösungen?
8) Gibt es auch die Möglichkeit mehrere Accounts auf einem "Secure Element" für einen Server zu hinterlegen (ein Account für meine Mutter einen für mich?)
9) Wo ist der unterschied zu YubiKeys und Co?

 

[Tornhoof]

1. Im Großen und Ganzen ja. Was du als Secure Element betrachtest ist technisch ein Implementierungsdetail, für den Prozess nicht notwendig, für eine entsprechende Umsetzung schon. Außerdem mischt du assurance Level, siehe unten. Der Name Passkey ist mehrdeutig. Eigentlich ist es ein technisches Konzept, wird aber mittlerweile primär als Name für die technische Umsetzung von WebAuthN mit Fido2 bezeichnet. Wenn du die Konzepte verstehen willst musst du es getrennt betrachten

2. Verstehe ich nicht ganz, du meinst du willst deinen domänenspezifischen privkey mit dem pubkey des Servers verschlüsseln? Nicht notwendig, die Sicherheit basiert auf der Annahme dass der Client nicht kompromittiert wird.

3. Dafür musst du das assurance Konzept verstehen, prinzipiell gibt's zwei high und Low assurance (und einiges anderes), stell dir einfach vor high assurance erfordert einen echten Hardware Token + zwei Authentication Faktoren. Low assurance benötigt nur einen Faktor und nicht notwendigerweise einen Hardwaretoken. High Assurance für entsprechend wichtige zu sicherende Seiten, Banken etc. Ist die Voraussetzung für financial grade APIs. Low assurance für den Rest. Bei high assurance bist du selber verantwortlich dass du Backup vom Token hast.

4. Kommt auf die Implementierung an, bei high assurance nein (gesetzt der Hardwaretoken ist nicht kompromittiert) bei low ist's möglich wenn dein Gerät einen unsicheren privkey erzeugt basierend, auf einer schlechten Implementierung eines Software Tokens. Realistisch gesagt, werden erst die nächsten Jahre mögliche Angriffsszenarien zeigen.

5. Ja, für Low assurance. Diverse Demo Implementierungen, keepass soll irgendwann wohl in die Richtung auch was können. Siehe ua https://github.com/keepassxreboot/keepassxc/pull/8825

6. Verstehe deine Frage nicht, jeder Account hat eigenen Passkey. Ob du dich bei mit deinen Google Creds woanders anmeldest ist unabhängig davon.

7. High Assurance über OS Fähigkeiten, afaik Nein. Hardware Tokens und/oder Support von Handy Tokens ja.

8. Jo natürlich, zumindest bei WebAuthN, der relevanten Umsetzung im Browser.
Siehe ua https://www.w3.org/TR/webauthn-2/#sctn-sample-registration

9. Yubikey ist ein Hardwaretoken, Passkey ist ein Konzept, WebAuthN ist eine Implementierung, die das eigentliche Pubkey Konzept beinhaltet, explizit für das Web. Yubikey hat natürlich auch APIs damit kann man das Konzept auch umsetzen.

 

[PaulEdison]

Danke für die Antwort.

2. Verstehe ich nicht ganz, du meinst du willst deinen domänenspezifischen privkey mit dem pubkey des Servers verschlüsseln? Nicht notwendig, die Sicherheit basiert auf der Annahme dass der Client nicht kompromittiert wird.

Damit meinte ich, dass ggf die Challenge dann, wenn mit dem PrivateKey des Servers signiert ist, ich sicherer bin von wem die anfrage kommt, und ich nicht ungefragt wem anderen eine Challenge signiere.
Wäre das ein Problem? (Oder wird davon ausgegangen, dass das auf grund von andern Protokollen gesichert ist)

3. Dafür musst du das assurance Konzept verstehen, prinzipiell gibt's zwei high und Low assurance (und einiges anderes), stell dir einfach vor high assurance erfordert einen echten Hardware Token + zwei Authentication Faktoren. Low assurance benötigt nur einen Faktor und nicht notwendigerweise einen Hardwaretoken. High Assurance für entsprechend wichtige zu sicherende Seiten, Banken etc. Ist die Voraussetzung für financial grade APIs. Low assurance für den Rest. Bei high assurance bist du selber verantwortlich dass du Backup vom Token hast.

Naja, aber bei Physischen/HW "Secure Elements" gibt es so etwas wie ein BackUp eben NICHT - Oder doch? (Ich dache der Private Key kommt da NIE wieder raus)
Wie kann ich dann ein backup machen? (u.a. habe ich gelesen, das Apple & Google so etwas anbieten - oder nutzen die dann doch nicht das jeweilige HW Secure Element)?

Wenn es rein in SW umgesetzt ist - klar dann kann ich den KeyStore (oder wie immer ich die DB nennen will) kopieren (und verschlüsselt von A zu B übertragen).

Aber ein Lohnendes Ziel ist es in beiden Fällen (Und ich frage mich wie sicher so ein Windows PIN ist ...)

6. Verstehe deine Frage nicht, jeder Account hat eigenen Passkey. Ob du dich bei mit deinen Google Creds woanders anmeldest ist unabhängig davon.

Naja, ich will mich ja in jeden Account nicht nut von einem Device aus anmelden, sondern von meinem PC, Smartphone, SmartTV, ....
Ohne Syncronisierung muss ich mich zuerst per Passwort (oder "Proxy-Passkey von einem bereits registrierten Device") anmelden um für dieses Gerät einen eigenen Passkey zu erzeugen.

7. High Assurance über OS Fähigkeiten, afaik Nein. Hardware Tokens und/oder Support von Handy Tokens ja.

Wie es technisch abläuft mit SmartPhone-Passkeys von PC aud nutzten habe ich mir gar noch nicht angesehen.

 

[Tornhoof]

Naja, aber bei Physischen/HW "Secure Elements" gibt es so etwas wie ein BackUp eben NICHT -

Gerade bei Tokens wie yubikey wird empfohlen, die doppelt zu haben. Je nach Lösung entweder durch integrierte Mechanismen oder Backup Codes etc. Der Identitätsprovider erlaubt häufig auch einfach multiple passkeys für den gleichen Account. Dann kannst du zwei Tokens nutzen. Wie gesagt, alles eine Frage der Assurance.

Naja, ich will mich ja in jeden Account nicht nut von einem Device aus anmelden, sondern von meinem PC, Smartphone, SmartTV, ....

WebAuthN ist der Standard zum Login Browser. Für devices ala SmartTV gibt's sog. Device flows. Die hast du garantiert bei Netflix und Konsorten schon gesehen. "Bitte geben sie den folgenden Code vom Handy in der Netflix App aufm Fernseher ein". Da wird kein Passwort genutzt, hat was mit Delegation usw. zu tun. Um das zu verstehen musst du u.a. die OpenId Connect spec lesen und verstehen

Es ist sehr unwahrscheinlich dass du SmartTv mit Passkey Support sehen wirst in absehbarer Zukunft.

Für devices gibt's wie gesagt andere Konzepte.

Damit meinte ich, dass ggf die Challenge dann, wenn mit dem PrivateKey des Servers signiert ist,

Dafür müsste ja, dein hw Token die pubkeys des Servers speichern, der idealerweise rotiert wird. Die HW Tokens haben keinen großen Speicher, sagen wir mal 128Kbyte. Da kannst du nicht viele drin speichern. Ganz zu schweigen von der Rotation. Einfach gesagt, es macht die Lösung weit komplizierter und nicht essentiell sicherer.