Authentifizierung ist in der digitalen Welt schon immer vorhanden gewesen. Sei es am Arbeitsplatz, in sozialen Netzwerken, bei Finanztransaktionen oder in fast allen anderen Bereichen des digitalen Umgangs miteinander. Für die meisten von uns und für den größten Teil der Geschichte des Internets bedeutet Authentifizierung vor allem eines: die Eingabe eines Benutzernamens und eines Passworts. Mit anderen Worten, die meisten von uns mussten während der gesamten Geschichte des Internets mit den Mängeln von Passwörtern in Bezug auf Sicherheit und Benutzerfreundlichkeit leben.
Aber nicht jeder war ständig auf Passwörter angewiesen. Einige von uns haben vielleicht schon Personal Identity Verification (PIV) oder andere Arten von Smartcards zur Authentifizierung verwendet. Smartcards sind zwar viel sicherer als Passwörter, erfordern aber spezielle Lesegeräte (und die Smartcard selbst) und wurden nie in die Webplattform integriert, so dass ihre Reichweite begrenzt blieb.
Später kamen Hardware-Token hinzu, die dem Benutzer einen sich regelmäßig ändernden Code anzeigen und so zu einem zweiten Authentifizierungsfaktor für den Benutzer wurden. Dies löste zwar das Problem der Smartcard-Reader, erforderte aber immer noch den physischen Token selbst. Während diese Token, unabhängig davon, ob sie einen Standard wie das zeitbasierte Einmalpasswort (TOTP) verwendeten oder auf proprietären Methoden basierten, eine etwas größere Reichweite hatten, tippen die meisten von uns immer noch Passwörter zur Authentifizierung ein.
Mit der zunehmenden Verbreitung von Smartphones wurde der Bedarf an speziellen Hardware-Tokens immer geringer. Stattdessen konnte das Smartphone das TOTP anzeigen, einen per SMS übermittelten PIN, oder - noch einfacher - eine Zwei-Faktor-Authentifizierung durch eine Bestätigungsaufforderung auf dem Smartphone implementieren. Dadurch wurden sicherere Authentifizierungsmechanismen für Verbraucheranwendungen (wie Online-Banking) möglich. Es gibt aber auch erhebliche Nachteile: Die Zwei-Faktor-Authentifizierung mit einem speziellen TOTP-Token oder einem Smartphone ist zwar sicherer als ein Passwort allein, aber im Gegensatz zu Smartcards immer noch anfällig für Phishing und andere Angriffe.
FIDO - Standards
Im Jahr 2014 begann die FIDO Alliance mit der Veröffentlichung einer Reihe von Standards, darunter eine Weiterentwicklung des ursprünglich von Google entwickelten U2F-Standards. Der U2F-Standard (Universal 2nd Factor) erfordert ein zusätzliches Gerät, das als Security Token fungiert und auf dem der private Schlüssel gespeichert wird. Dieses Gerät kann verschiedene Formen annehmen, wie z.B. ein USB Token, ein NFC (Near Field Communication) Gerät oder ein Bluetooth Gerät. Diese Token sind physische Geräte, die zur Authentifizierung in einem Zwei-Faktor-Authentifizierungsprozess verwendet werden. U2F ist speziell als zusätzlicher Authentifizierungsfaktor konzipiert, was bedeutet, dass es in Kombination mit einem anderen Authentifizierungsfaktor verwendet wird - typischerweise etwas, das der Benutzer kennt, wie z.B. ein Passwort.
Der zweite wichtige Standard, den die FIDO Alliance in FIDO v1.0 veröffentlicht hat, ist UAF (Universal Authentication Framework). Dieses Verfahren ersetzt zum einen die Notwendigkeit eines Security Tokens und zum anderen wird das Passwort durch ein biometrisches Verfahren oder eine PIN ersetzt. Während jedoch bei U2F das Passwort noch über das Internet übertragen und vom Server der Webanwendung verifiziert wird, findet bei UAF keine Übertragung von sensiblen Authentisierungsinformationen (wie biometrische Daten oder PINs) statt. Die biometrische Erkennung oder PIN-Eingabe dient ausschließlich der lokalen Benutzeridentifikation am Gerät und nur die erzeugte Signatur aus dem Challange-Response Verfahren der Relaying-Party wird zurückgesendet.
Im Jahr 2018 hat die FIDO Alliance den Standard FIDO2 veröffentlicht, der eine Weiterentwicklung und Zusammenführung der Konzepte von U2F (Universal 2nd Factor) und UAF (Universal Authentication Framework) darstellt. Eine der Schlüsselkomponenten von FIDO2 ist WebAuthn, eine Web-API, die es Webbrowsern ermöglicht, auf die Authentifizierungsfunktionen von Endgeräten zuzugreifen. Die zweite wichtige Neuerung, CTAP2 (Client to Authenticator Protocol), ermöglicht die sichere Kommunikation zwischen externen Authentifikatoren und einem nahe gelegenen Gerät wie einem Smartphone oder Laptop und dient als Erweiterung und Nachfolger des in U2F verwendeten Protokolls CTAP1. Während U2F auf die Verwendung von physischen Sicherheitstokens für die Zwei-Faktor-Authentifizierung beschränkt ist und UAF passwortlose Authentifizierungsoptionen bietet, ermöglicht FIDO2 eine flexiblere Kombination dieser Ansätze und unterstützt sowohl Zwei-Faktor- als auch passwortlose Authentifizierungsmodelle.
Die Komponenten von FIDO / FIDO2
Der FIDO2-Standard enthält eine Reihe von Komponenten, die nicht zum Tagesgeschäft eines IT-Professionals gehören. Die wichtigsten Komponenten und Begriffe werden im folgenden Abschnitt beschrieben. Jemand, der sich mit der Implementierung von Passkey beschäftigt und den Prozess der passwortlosen Authentisierung in seinen Grundzügen verstehen will, sollte von diesen Komponenten gehört haben. Man kann noch viel tiefer in die Materie einsteigen, aber der folgende Überblick bildet eine solide Grundlage, um das Prinzip von passwortloser Authentisierung zu verstehen.
Authentifikator (FIDO / FIDO2)
Ein Authentifikator ist eine Hard- oder Softwarekomponente, die im Rahmen von kryptographischen Authentisierungsprozessen verwendet wird. In Systemen, die den FIDO2-Standard verwenden erfüllt der Authentifikator mehrere Aufgaben. Während des Registrierungsprozesses erzeugt der Authentifikator ein kryptographisches Schlüsselpaar, das aus einem öffentlichen und einem privaten Schlüssel besteht. Der öffentliche Schlüssel kann sicher mit externen Parteien geteilt werden, während der private Schlüssel sicher auf dem Authentifikator gespeichert wird und das Gerät niemals verlässt. Bei einer Authentisierungsanfrage verwendet der Authentifikator den privaten Schlüssel, um eine Signatur zu erstellen. Diese Signatur wird als Antwort auf eine von der Relying Party (i.d.R eine Webanwendung auf einem Server) bereitgestellte Challenge erstellt. Die Signatur dient als Nachweis dafür, dass der Benutzer im Besitz des privaten Schlüssels ist, ohne dass dieser offengelegt werden muss. Dieses Verfahren nennt sich Challenge-Response.
Zusammengefasst ist der Authentifikator eine Komponente des Betriebssystems oder ein externes Gerät, auf das kompatible Anwendungen wie beispielsweise ein Browser über die WebAuthn API zugreifen, um Authentifizierungsprozesse durchzuführen.
WebAuthn API (FIDO2)
WebAuthn, kurz für Web Authentication, ist eine moderne API, um eine sichere und benutzerfreundliche Web-Authentifizierung mit kryptographischen Methoden zu ermöglichen. WebAuthn ist Teil der FIDO2-Spezifikationen, die gemeinsam von der FIDO Alliance und dem W3C (World Wide Web Consortium) entwickelt wurden. Die API bildet die Schnittstelle zwischen Client (Browser) und der Relying Party während des Authentifizierungsprozesses.
Um WebAuthn nutzen zu können, müssen sowohl auf dem Client als auch auf dem Server entsprechende Implementierungen der WebAuthn API vorhanden sein. Der Authentifizierungsprozess beginnt damit, dass die Client-API auf Anfrage eines Benutzers eine Authentifizierungsanfrage an den Server sendet. Der Server generiert daraufhin eine Challenge (Herausforderung) und sendet diese an die Client-API zurück. Diese leitet die Challenge an den Authentifikator weiter, der sie mit dem privaten Schlüssel des Benutzers signiert. Die erzeugte Signatur wird von der Client-API zurück an den Server gesendet, wo sie verifiziert wird. Ist die Überprüfung erfolgreich, setzt der Server den Anmeldeprozess fort. Mit diesem Verfahren wird der private Schlüssel des Benutzers nicht über das Internet übertragen, sondern nur die erzeugte Signatur.
Zusammenfassend ist die WebAuthn API eine zentrale Komponente der FIDO2-Spezifikation, die eine sichere und benutzerfreundliche Authentifizierung bei Webanwendungen ermöglicht, indem sie standardisierte Schnittstellen für kompatible Anwendungen wie z.B. Browser und Server bereitstellt, um kryptographische Authentifizierungsprozesse durchzuführen und zu verwalten.
CTAP (FIDO2)
CTAP (Client to Authenticator Protocol) wurde von der FIDO Alliance entwickelt und ist derzeit in zwei Versionen verfügbar. CTAP1 und CTAP2.
CTAP1, früher bekannt als U2F (Universal 2nd Factor), ist eine frühere Version des Protokolls, die sich hauptsächlich auf die Bereitstellung einer Zwei-Faktor-Authentifizierung mit externen Hardware-Sicherheitsschlüsseln konzentrierte. CTAP1 ermöglicht es Benutzern, eine physische Handlung (z. B. das Drücken eines Knopfes auf einem Sicherheitsschlüssel) als zweiten Authentifizierungsfaktor zu verwenden.
CTAP2, eine Weiterentwicklung von CTAP1, unterstützt eine breitere Palette von Authentifizierungsmechanismen, einschließlich passwortloser Authentifizierung und Multi-Faktor-Authentifizierung in einem einzigen Gerät. CTAP2 ermöglicht komplexere Interaktionen und eine sicherere Kommunikation zwischen Authentifikator und Client.
Während WebAuthn auch die Kommunikation zwischen dem Client und einem softwareinhärenten Authentifikator unterstützt, wird CTAP hauptsächlich für die Kommunikation zwischen dem Client und hardwarebasierten Authentifikatoren wie USB-Security Token, aber auch für NFC (Near Field Communication)-Implementierungen verwendet, bei denen z.B. über eine Bluetooth-Verbindung ein Authentifikator auf einem Smartphone verwendet werden kann, wenn der Anmeldeprozess auf einem Clientrechner gestartet wurde.
Die von CTAP definierten Kommunikationsprotokolle stellen sicher, dass alle zwischen Client und Authentifikator übertragenen Authentisierungsdaten verschlüsselt und geschützt sind und dass der private Schlüssel sicher auf dem Authentifikator gespeichert bleibt und niemals offengelegt wird. CTAP ermöglicht somit eine sichere Handhabung des Prozesses über mehrere Geräte hinweg, da der Authentifikator auf mehreren Geräten verwendet werden kann, ohne dass die privaten Schlüssel über eine Cloud-Anwendung synchronisiert werden müssen. Darüber hinaus ermöglicht CTAP2 die Implementierung von Geräten zur biometrischen Mustererkennung wie Fingerabdruck- oder Iris-Scannern.
Zusammenfassend ist CTAP2 ein Protokoll innerhalb der FIDO2-Spezifikation, das eine sichere Kommunikation für externe und mobile Geräte in den Prozess integriert und somit zur Flexibilität und Verfügbarkeit der FIDO2-Kernkomponenten beiträgt.
Blockdiagramm der FIDO2-Architektur
Registrierung und Authentifizierung
Bei der Registrierung in FIDO2 generiert das Gerät des Benutzers ein neues Schlüsselpaar, das aus einem privaten und einem öffentlichen Schlüssel besteht. Der öffentliche Schlüssel wird zusammen mit einer eindeutigen Benutzerkennung an den Server gesendet und dort gespeichert. Bei der Authentifizierung fordert der Server eine Herausforderung (Challenge) an, die der Benutzer mit seinem privaten Schlüssel signiert. Die signierte Antwort wird an den Server zurückgeschickt, der sie mit dem gespeicherten öffentlichen Schlüssel überprüft, um die Identität des Benutzers zu bestätigen.
Relying Party
Die Relying Party (vertrauende Partei) in FIDO2 bezeichnet den Dienst oder Server, der den Authentifizierungsprozess verwaltet und auf Benutzeranfragen antwortet. Wenn ein Benutzer auf eine Web-Anwendung zugreifen möchte, sendet er eine Authentifizierungsanfrage an die Relying Party. Diese antwortet mit einer Challenge, die der Benutzer mit seinem privaten Schlüssel signiert und zur Überprüfung zurückschickt. Die Relying Party verwendet dann den zuvor registrierten öffentlichen Schlüssel des Benutzers, um die Signatur zu validieren und damit die Identität des Benutzers zu bestätigen.
Komponenten der Relying Party
Identity Provider
Der Identity Provider (IdP) ist eine externe oder interne Entität, die für die Verwaltung, Authentifizierung und Verifizierung der Identitäten der Benutzer verantwortlich ist und stellt Autorisierungs-Tokens (z. B. OAuth2) für den Zugriff auf Ressourcen aus.
Credential Repository
Das Credential Repository ist die Komponente, die kryptographische Schlüssel und andere Anmeldeinformationen speichert. Bei der Registrierung eines neuen Passkeys speichert es den öffentlichen Schlüssel des Benutzers zusammen mit anderen Metadaten wie der Benutzer-ID und dem Registrierungsdatum. Während der Authentifizierung vergleicht das Credential Repository den eingehenden öffentlichen Schlüssel mit den gespeicherten Schlüsseln, um die Identität des Benutzers zu verifizieren.
Application Layer
Der Application Layer ist für die zentrale Anwendungslogik verantwortlich. Hier findet die Kommunikation zwischen dem Client und dem Server statt. Typische Aufgaben umfassen die Initiierung der Registrierungs- und Authentifizierungsanforderungen, das Senden und Empfangen von Herausforderungen, und die Anzeige von Statusmeldungen an den Benutzer.
Metadata Repository
Das Metadata Repository ist eine optionale Komponente der Relying Party. Es speichert Metadaten, die für die Verwaltung und Sicherheit der Passkey-Authentifizierung notwendig sind. Dazu gehören Informationen über die verwendeten Authentifikatoren, unterstützte Protokolle, Zertifikate und Richtlinien für die Verwendung und Verwaltung der Anmeldeinformationen. Diese Metadaten helfen sicherzustellen, dass nur vertrauenswürdige und kompatible Geräte und Protokolle verwendet werden und unterstützen die Verwaltung von Sicherheitsrichtlinien in Hochsicherheitsumgebungen.
Passkey
FIDO2-Schlüssel sind immer an den Authentifikator gebunden, auf dem sie erzeugt wurden. Der hohe Sicherheitsstandard von FIDO2-Schlüsseln ergibt sich aus der Notwendigkeit, die Schlüssel z.B. auf einem USB Security Token oder einem Trusted Platform Module (TPM) zu speichern. Passkey erweitert diesen FIDO2-Standard nun dahingehend, dass der Schlüssel kopierbar wird, exportiert und importiert werden kann oder mit einer Cloud synchronisiert und somit auf mehreren Geräten verwendet werden kann. Im FIDO-Standard wird diese Implementierung als Multi Decive FIDO Credentials (MDC) bezeichnet, im Gegensatz zu den hardwaregebundenen Single Device FIDO Credentials (SDC).
Mehrere Hersteller von Passwortmanagern wie KeePassXC unterstützen mittlerweile die MDC "Passkey" Implementierung, die durch das Prinzip der Ende-zu-Ende-Verschlüsselung der Datenbank eine effektive Methode zum Schutz von Passwörtern oder Schlüsseln darstellen, selbst wenn die Umgebung, in der sie gespeichert oder übertragen werden, Sicherheitslücken aufweist. Passkey weicht die sehr hohen Sicherheitsstandards (High Assurance Level) von FIDO2 ein wenig auf, ist aber immer noch signifikant sicherer als herkömmliche Passwörter und besticht durch eine sehr hohe Benutzerfreundlichkeit aufgrund der flexiblen Einsatzmöglichkeiten.
Abschließend kann festgestellt werden, dass der Begriff Passkey kein Element der FIDO-Standards ist, sondern ein Marketingbegriff, der sich vermutlich aus den Wörtern Password und Public-Key zusammensetzt. Die Herkunft des Wortes ist nicht eindeutig geklärt, jedoch hat sich der Begriff im Kontext der Konzepte der passwortlosen Authentifizierung etabliert. Der Begriff wird gleichermaßen für die sehr strenge Implementierung der FIDO-Standards verwendet, welche im Prinzip die High Assurance Level mit Single Device Credentials (SDC) implementiert und dann die eigentliche Idee der Passkey-Implementierung mit Low Assurance Level und Multi Device Credentials (MDC) darstellt.
Im Artikel Passkey für WordPress und KeePassXC wird dieses Verfahren am Beispiel eines WordPress-Login mit KeePassXC und WP-WebAuthn in die Praxis umgesetzt.
