Kompromittierte Kontoinformationen sind eine der Hauptursachen für Datenschutzverletzungen. Deshalb setzen auch grosse Cloud-Anbieter wie Microsoft und Google auf «Passwordless»-Methoden. Die passwortlose Authentifizierung ist ein Mittel zur Überprüfung der Identität eines Nutzers, ohne ein Passwort zu verwenden. Stattdessen werden bei der passwortlosen Authentifizierung sichere Alternativen wie Besitzfaktoren bzw. Hardware-Tokens oder z.B. Mobile Devices verwendet.
Dazu kommt: Immer mehr Unternehmen weiten derzeit ihre digitale Transformation aus und migrieren in die Cloud. Diese Unternehmen stehen vor der Herausforderung, sich mit einer ganzen Reihe neuer Anwendungsfälle befassen zu müssen, beispielsweise mit Sicherheitsverletzungen aufgrund von Identitätsdiebstahl, weil sie bislang unter Umständen nur in einen Authentifizierungsstandard investiert haben.
FIDO 2.0 als «Passwordless»-Lösung
Beim Begriff FIDO, der für «Fast Identity Online» steht, handelt es sich um eine Reihe plattformunabhängiger zertifizierter Authenticator Tokens – oder: token on mobile devices –, welche den Benutzeranmeldeprozess für Onlinedienste härten, die auf Kryptografie mit öffentlichen Schlüsseln und elliptischen Kurven basieren. Die Standards werden von der FIDO Alliance entwickelt und fördern schnellere und sichere Authentifizierungsprozesse mit dem übergeordneten Ziel, passwortbasierte Anmeldungen, auch One-Time Passwords, zu eliminieren. Vereinfacht gesagt, handelt es sich um einen Standard, der ohne Zertifikate, jedoch asymmetrisch (via Public Key und Private Key) zur Anwendung gelangt.
Wird FIDO im Zusammenspiel mit einem biometrischen Verfahren bzw. einem zweiten lokalen (und nicht übertragbaren Faktor) wie beispielsweise einem Fingerprint ausgehandelt, handelt es sich dennoch um eine asymmetrische Authentisierung, da die biometrischen Informationen nur lokal als zweiter Faktor verwendet werden, auch wenn das symmetrische Verfahren sind.
In der Cloud, beim IdP, wird jeweils nur der Public Key gespeichert und der Private Key bleibt immer lokal, basierend auf der FIDO-Zertifizierung, geschützt und nicht übertragen. (Nur der sogenannte «Nonce», eine einmalige Zufallszahl in der kryptographischen Kommunikation oder die mit dem Private Key verschlüsselte Version bzw. der verschlüsselte «Hash» geht durch die Leitung.)
Anwendungsszenarien des consumernahen FIDO-Standards
Worin sich PKI und FIDO 2.0 unterscheiden
Die Geschichte von Public Key Cryptography begann bereits in den frühen 1970er-Jahren im Zuge wichtiger Entdeckungen zu Verschlüsselungsalgorithmen beim britischen Geheimdienst. Anders als FIDO 2.0 stützt sich PKI mit den digitalen Zertifikaten auf die Dienste einer vertrauenswürdigen Stelle Certificate Authority (CA), welche den Lifecycle eines kryptographischen Schlüssels mit digitalen Zertifikaten abbildet. Mögliche Anwendungen beinhalten: SSL für Webserver und Webdienste, WLAN- bzw. LAN-Authentifizierung, Smart-Card-Anmeldung, E-Mail-Verschlüsselung, E-Mail-Signaturen und Dokumentensignaturen.
Wie bei FIDO wird bei einer PKI ein Paar kryptographischer Schlüssel (Private and Public Key) verwendet. Das Schlüsselpaar wird beim Requestor erzeugt und die CA signiert die beschreibenden Informationen im Zertifikat mit dem Public Key. Diese digitale Signatur kann von jedem mit dem Public Key der CA verifiziert werden. So ermöglicht diese Hierarchie das Hinterlegen eines CA-Zertifikats, wodurch quasi alle Client-Zertifikate verifiziert werden. Bei FIDO handelt es sich demgegenüber immer um ein «1:1-Mapping».
Schema einer PKI-Architektur
CA: Certification Authority
RA: Registration Authority
VA: Validation Authority
Wo es auf Enterprise-Ebene komplex wird
Die Sicherheitsanforderungen steigen durch eine schnelle Nutzung der Cloud-Infrastrukturen und der Multiplizierung von Endgeräten. Hinsichtlich der Implementierung von PKI bestehen ausserdem Einschränkungen bei Cloud-Anwendungen. So kann PKI-Authentifizierung nicht so leicht auf mobile Geräte angewandt werden. Zudem sind PKI-Szenarien teilweise auf etablierte bzw. Enterprise-Anwendungen via VPN beschränkt.
Wie jedes Sicherheitssystem weist aber auch FIDO einige Nachteile auf. Zwar kann FIDO bei Use Cases wie Webadmins oder Fabrikmitarbeitenden Sinn ergeben, da die Anwender unter Umständen kein persönliches Smartphone zur Identifikation mitnehmen möchten. Hier benötigt FIDO keine Zertifikate und man spart sich Kosten und Aufwände; erkauft sich jedoch auch genau jene Nachteile damit. Schliesslich stehen bei Zertifikaten auch Kriterien wie «Validity», «Period» und «Revocation» im Fokus, da ein Zertifikat immer ein Anfangs- und Enddatum beinhalten kann, ab dem es gültig und nicht mehr gültig ist, zumal Enddaten sehr oft anfallen, da die meisten Zertifizierungsstellen es für sinnvoll erachten, ein Zertifikat von Zeit zu Zeit zu erneuern.
So lässt sich nicht nur überprüfen, ob der Inhaber noch echt ist («Trust»), sondern auch ein Zertifikat unter bestimmten Umständen wiederrufen wurde («Revoke»). Dies ist beispielsweise dann erforderlich, wenn der zugehörige private Schlüssel des Inhabers verlorengeht oder die Zertifizierungsstelle dessen Inhaber nicht mehr als vertrauenswürdig erachtet.
Was passiert aber beispielsweise, wenn zu viele Registrierungen mit einem FIDO-Token vorgenommen werden? Was passiert, wenn ein Mitarbeitender sich mit seinem FIDO-Token bei Webservices registriert, die nicht von der Firma vorgesehen sind? Der Nachteil von FIDO liegt daher nicht selten in der Komplexität jener Ausschlussfaktoren begründet, wenn beispielsweise ein Mitarbeitender das Unternehmen verlässt.
Probleme, die sich nur mit einem Identitätsprovider (IdP) lösen lassen
FIDO ermöglicht daher meist nur die Authentifizierung, respektive die sichere Wiedererkennung. Zur Schaffung einer digitalen Identität müssen Authentifizierung und die Identität vom Identitätsanbieter zusammengeführt werden. Hier gelangt ein Identitätsprovider (IdP) zur Anwendung. Da jeder User sich selbst bei allen verwendeten Webservices registrieren muss, ist ein zentraler Authentisierungsdienst (Identity Provider – IdP) notwendig, um den Lifecycle der Token der Mitarbeitenden zu verwalten. Dies umfasst unter anderem die Kriterien:
- Registrierung
- Verwaltung der User-Tokens
(Welcher User verwendet welches Token?) - Validity: Da diese nicht wie bei einem Zertifikat gegeben ist, müssen wir diese für die Mitarbeitenden auf dem IdP realisieren bzw. den Account deaktivieren.
- User-Self-Service: Wie sich Mitarbeitende selbst helfen, damit die User sich online ohne Helpdesk jederzeit neue Credentials zustellen lassen können.
Der IdP verwaltet nebst der Policies für Compliance, Access Control und Re-Authentification vordergründig das Enrollment bzw. die Public Keys des FIDO-Schlüsselpaares. Der Zugriff auf die eigentlichen Webanwendungen erfolgt dann mit Security Assertion Markup Language (SAML) oder OpenID Connect (OIDC). Bei ersterem handelt es sich um eine XML-basierte Auszeichnungssprache bzw. ein Protokoll verschiedener Dienstanbieter wie Office 365, Salesforce und Zoom, während OpenID Connect einer Reihe von (webbasierten, mobilen) Clients den Informationsaustausch über authentifizierte Sessions und Anwender ermöglicht.
Anwendungsszenarien genau evaluieren
Es lohnt sich, die Bedürfnisse im Unternehmen genau zu identifizieren. Sind es beispielsweise temporäre Mitarbeitende eines Unternehmens? Werden Cloud- und Webzugriff, FIDO-Badge-Zugriff oder gar eine Hybrid-PKI-FIDO-Lösung benötigt, beispielsweise für digitale Signaturen und Verschlüsselung? Manchmal kann auch exemplarisch eine Smart Card wie IDPrime mit FIDO oder ein eToken Fusion von Thales (ehemals Gemalto) eine Lösung sein, welche sowohl PKI-Szenarien als auch FIDO-Authentifizierung unterstützt und zur physischen Zutrittskontrolle mit RFID wie z.B. kontaktloser Chipkartentechnik nach Legic (in der Schweiz zu 90 Prozent), Mifare Classic & Desfire kompatibel bleibt.
Fazit
FIDO bietet vor allem für mobile Geräte eine hochsichere Passwordless Authentification, die nun seit Anfang 2023 auch in Azure genutzt werden kann. (Certificate-based Authentication mit Zertifikaten einer eigenen PKI sowie Smart-Card-Anmeldung sind dadurch nun auch bei Azure möglich.) So lassen sich grundsätzlich keine Credentials mehr erbeuten. Auch Phishing-Angriffe laufen dann ins Leere. Man fängt sich mit FIDO aber auch ein paar Nachteile ein, da es im Wesentlichen nur um Key-based Authentication für Consumer handelt.
Die Vorteile eines Zertifikats mit Trust, Validity, Revocation und Managed Devices auf Enterprise-Ebene müssen daher bei den Einsatz von FIDO durch einen zentralen IdP kompensiert werden. Das kann Azure sein oder eine Kombination von Card-Management-Systemen sowie eines geeigneten IdP (wie beispielsweise vSEC: CMS & Thales STA). Dort werden die FIDO-Token für die Benutzer im «Send-to-All-Modus» pre-provisioniert und können dann für den Zugriff auf die Unternehmensapplikationen verwendet werden. Die Smart Cards werden wie üblich vollständig vorbereitet und der Enduser bekommt die Karte und die PIN.
Smart Cards decken ein umfassenderes Anwendungsspektrum ab – wie Authentisierung, Signaturen und Verschlüsselungsapplikation. Eine Kombination von allen Möglichkeiten böte aber wohl die grösste Zukunftssicherheit.
Weiterführende Links
