Authentication

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Android verwendet das Konzept kryptografischer Schlüssel, die durch die Nutzerauthentifizierung gesteuert werden. Dazu sind die folgenden Komponenten erforderlich:

• Speicher- und Dienstanbieter für kryptografische Schlüssel. Hier werden kryptografische Schlüssel gespeichert und standardmäßige Krypto-Routinen für diese Schlüssel bereitgestellt. Android unterstützt einen hardwaregestützten Schlüsselspeicher und Keymaster für kryptografische Dienste, einschließlich hardwaregestützter Kryptografie für den Schlüsselspeicher, die eine Trusted Execution Environment (TEE) oder ein Secure Element (SE) wie Strongbox umfassen kann.
• Nutzer-Authenticator Die Anwesenheit des Nutzers und/oder die erfolgreiche Authentifizierung bestätigen. Android unterstützt Gatekeeper für die PIN-/Muster-/Passwortauthentifizierung und Fingerprint für die Fingerabdruckauthentifizierung. Auf Geräten mit Android 9 und höher kann BiometricPrompt als einziger Integrationspunkt für Fingerabdrücke und zusätzliche biometrische Daten verwendet werden. Diese Komponenten geben ihren Authentifizierungsstatus über einen authentifizierten Kanal an den Schlüsselspeicherdienst weiter. Das Android-Schlüsselspeichersystem auf Frameworkebene wird ebenfalls vom Schlüsselspeicherdienst unterstützt.

Gatekeeper-, Fingerabdruck- und biometrische Komponenten arbeiten mit dem Schlüsselspeicher und anderen Komponenten zusammen, um die Verwendung von hardwaregestützten Authentifizierungstokens (AuthTokens) zu unterstützen.

Registrierung

Beim ersten Starten des Geräts nach dem Zurücksetzen auf die Werkseinstellungen sind alle Authenticator bereit, Anmeldedaten vom Nutzer zu empfangen. Ein Nutzer muss zuerst eine PIN, ein Muster oder ein Passwort bei Gatekeeper registrieren. Bei dieser Erstregistrierung wird eine zufällig generierte 64‑Bit-Nutzer-SID (Secure Identifier) erstellt, die als Kennung für den Nutzer und als Bindungstoken für das kryptografische Material des Nutzers dient. Diese Nutzer-SID ist kryptografisch an das Passwort des Nutzers gebunden. Erfolgreiche Authentifizierungen bei Gatekeeper führen zu AuthTokens, die die Nutzer-SID für dieses Passwort enthalten.

Ein Nutzer, der Anmeldedaten ändern möchte, muss vorhandene Anmeldedaten vorlegen. Wenn vorhandene Anmeldedaten erfolgreich bestätigt werden, wird die mit den vorhandenen Anmeldedaten verknüpfte Nutzer-SID auf die neuen Anmeldedaten übertragen. So kann der Nutzer auch nach dem Ändern von Anmeldedaten weiterhin auf Schlüssel zugreifen. Wenn ein Nutzer keine vorhandenen Anmeldedaten vorlegt, wird die neue Anmeldedaten mit einer vollständig zufälligen Nutzer-SID registriert. Der Nutzer kann auf das Gerät zugreifen, aber Schlüssel, die unter der alten Nutzer-SID erstellt wurden, gehen dauerhaft verloren. Dies wird als nicht vertrauenswürdige Registrierung bezeichnet.

Normalerweise erlaubt das Android-Framework keine Registrierung bei nicht vertrauenswürdigen Konten. Daher sehen die meisten Nutzer diese Funktion nie. Ein erzwungenes Zurücksetzen des Passworts, entweder durch einen Geräteadministrator oder einen Angreifer, kann jedoch dazu führen.

Authentifizierung

Nachdem ein Nutzer Anmeldedaten eingerichtet und eine Nutzer-SID erhalten hat, kann er mit der Authentifizierung beginnen. Dazu gibt er eine PIN, ein Muster, ein Passwort oder einen Fingerabdruck an. Alle TEE-Komponenten teilen sich einen geheimen Schlüssel, mit dem sie die Nachrichten der anderen authentifizieren.

1. Ein Nutzer gibt eine Authentifizierungsmethode an und der zugehörige Dienst sendet eine Anfrage an den zugehörigen Daemon.
   • Bei PIN, Muster oder Passwort sendet LockSettingsService eine Anfrage an gatekeeperd.
   • Biometrische Authentifizierungsabläufe hängen von der Android-Version ab. Auf Geräten mit Android 8.x und niedriger sendet FingerprintService eine Anfrage an fingerprintd. Auf Geräten mit Android 9 und höher sendet BiometricPrompt eine Anfrage an den entsprechenden biometrischen Daemon (z. B. fingerprintd für Fingerabdrücke oder faced für das Gesicht) über die entsprechende BiometricManager-Klasse, z. B. FingerprintManager oder FaceManager. Unabhängig von der Version erfolgt die biometrische Authentifizierung asynchron nach dem Senden der Anfrage.
2. Der Daemon sendet Daten an sein Gegenstück, das ein AuthToken generiert:
   • Bei der PIN-/Muster-/Passwortauthentifizierung sendet gatekeeperd den PIN-, Muster- oder Passwort-Hash an den Gatekeeper im TEE. Wenn die Authentifizierung im TEE erfolgreich war, sendet der Gatekeeper im TEE ein AuthToken mit der entsprechenden Nutzer-SID (signiert mit dem AuthToken-HMAC-Schlüssel) an sein Pendant im Android-Betriebssystem.
   • Bei der Fingerabdruckauthentifizierung prüft fingerprintd auf Fingerabdruckereignisse und sendet die Daten an Fingerprint im TEE. Wenn die Authentifizierung im TEE erfolgreich ist, sendet der Fingerabdruck im TEE ein AuthToken (signiert mit dem AuthToken-HMAC-Schlüssel) an sein Gegenstück im Android-Betriebssystem.
   • Bei anderen biometrischen Authentifizierungen wartet der entsprechende biometrische Daemon auf das biometrische Ereignis und sendet es an die entsprechende biometrische TEE-Komponente.
3. Der Daemon empfängt ein signiertes AuthToken und übergibt es über eine Erweiterung der Binder-Schnittstelle des Schlüsselspeicherdienstes an den Schlüsselspeicherdienst. gatekeeperd benachrichtigt außerdem den Schlüsselspeicherdienst, wenn das Gerät wieder gesperrt wird und wenn sich das Gerätepasswort ändert.
4. Der Schlüsselspeicherdienst übergibt die AuthTokens an Keymaster und bestätigt sie mit dem Schlüssel, der mit dem Gatekeeper geteilt wird, und der unterstützten biometrischen TEE-Komponente. Keymaster betrachtet den Zeitstempel im Token als Zeitpunkt der letzten Authentifizierung und trifft auf Grundlage dieses Zeitstempels eine Entscheidung zur Freigabe des Schlüssels, um einer App die Verwendung des Schlüssels zu ermöglichen.

AuthToken-Format

Um die Tokenfreigabe und die Interoperabilität zwischen Sprachen und Komponenten zu gewährleisten, wird das AuthToken-Format in hw_auth_token.h beschrieben. Das Format ist ein einfaches Protokoll zur Protokollierung mit Feldern fester Größe.

Feld	Eingeben	Erforderlich	Beschreibung
AuthToken-Version	1 Byte	Ja	Gruppen-Tag für alle folgenden Felder.
Die Herausforderung	Vorzeichenlose 64-Bit-Ganzzahl	Nein	Eine zufällige Ganzzahl, um Wiederholungsangriffe zu verhindern. Normalerweise die ID eines angeforderten Krypto-Vorgangs. Wird derzeit für Autorisierungen mit Transaktionsfingerabdrücken verwendet. Falls vorhanden, ist das AuthToken nur für Krypto-Vorgänge mit derselben Herausforderung gültig.
Nutzer-SID	Vorzeichenlose 64-Bit-Ganzzahl	Ja	Nicht wiederholbare Nutzer-ID, die kryptografisch mit allen Schlüsseln verknüpft ist, die mit der Geräteauthentifizierung verknüpft sind. Weitere Informationen finden Sie unter Gatekeeper.
Authenticator-ID (ASID)	Vorzeichenlose 64-Bit-Ganzzahl in Netzwerkreihenfolge	Nein	Kennung, die zum Binden an eine bestimmte Authenticator-Richtlinie verwendet wird. Alle Authenticator haben einen eigenen ASID-Wert, den sie je nach Bedarf ändern können.
Authenticator-Typ	Vorzeichenlose 32-Bit-Ganzzahl in Netzwerkreihenfolge	Ja	0x00 ist Gatekeeper. 0x01 ist „Fingerabdruck“.
Zeitstempel	Vorzeichenlose 64-Bit-Ganzzahl in Netzwerkreihenfolge	Ja	Die Zeit (in Millisekunden) seit dem letzten Systemstart.
AuthToken-HMAC (SHA-256)	256-Bit-Blob	Ja	Schlüsselbasierter SHA-256-MAC aller Felder mit Ausnahme des HMAC-Felds.

Bootvorgang des Geräts

Bei jedem Starten eines Geräts muss der AuthToken-HMAC-Schlüssel generiert und für alle TEE-Komponenten (Gatekeeper, Keymaster und unterstützte biometrische Trustlets) freigegeben werden. Für zusätzlichen Schutz vor Replay-Angriffen muss der HMAC-Schlüssel daher bei jedem Neustart des Geräts zufällig generiert werden.

Das Protokoll zum Freigeben dieses HMAC-Schlüssels für alle Komponenten ist eine plattformabhängige Implementierungsfunktion. Der Schlüssel darf niemals außerhalb des TEE verfügbar gemacht werden. Wenn ein TEE-Betriebssystem keinen internen IPC-Mechanismus (Inter-Process Communication) hat und die Daten über das nicht vertrauenswürdige Betriebssystem übertragen werden müssen, muss die Übertragung über ein sicheres Schlüsselaustauschprotokoll erfolgen.

Das Betriebssystem Trusty, das neben Android ausgeführt wird, ist ein Beispiel für eine TEE. Es können aber auch andere TEEs verwendet werden. Trusty verwendet ein internes IPC-System, um direkt zwischen Keymaster und Gatekeeper oder dem entsprechenden biometrischen Trustlet zu kommunizieren. Der HMAC-Schlüssel wird ausschließlich in Keymaster gespeichert. Der Fingerabdruck und Gatekeeper fordern den Schlüssel bei jeder Verwendung von Keymaster an und speichern oder cachen den Wert nicht.

Da einige TEEs keine IPC-Infrastruktur haben, findet keine Kommunikation zwischen Applets im TEE statt. Außerdem kann der Schlüsselspeicherdienst Anfragen, die zum Scheitern verurteilt sind, schnell ablehnen, da er die Authentifizierungstabelle im System kennt. So wird eine potenziell kostspielige IPC in der TEE vermieden.