Android verwendet das Konzept der benutzerauthentifizierungsgesteuerten kryptografischen Schlüssel, für die die folgenden Komponenten erforderlich sind:
- Kryptografischer Schlüsselspeicher und Dienstanbieter. Speichert kryptografische Schlüssel und stellt standardmäßige Kryptoroutinen zusätzlich zu diesen Schlüsseln bereit. Android unterstützt einen hardwaregestützten Keystore und Keymaster für kryptografische Dienste, einschließlich hardwaregestützter Kryptografie für die Schlüsselspeicherung, die eine Trusted Execution Environment (TEE) oder Secure Element (SE) wie Strongbox umfassen kann.
- Benutzerauthentifikatoren. Bestätigen Sie die Anwesenheit des Benutzers und/oder die erfolgreiche Authentifizierung. Android unterstützt Gatekeeper für die PIN/Muster/Passwort-Authentifizierung und Fingerprint für die Fingerabdruck-Authentifizierung. Geräte, die mit Android 9 und höher ausgeliefert werden, können
BiometricPrompt
als einzigen Integrationspunkt für Fingerabdrücke und zusätzliche Biometrie verwenden. Diese Komponenten kommunizieren ihren Authentifizierungsstatus über einen authentifizierten Kanal mit dem Keystore-Service. (Das Android Keystore-System auf Framework-Ebene wird auch durch den Keystore-Dienst unterstützt.)
Gatekeeper-, Fingerabdruck- und biometrische Komponenten arbeiten mit Keystore und anderen Komponenten zusammen, um die Verwendung von hardwaregestützten Authentifizierungstoken (AuthTokens) zu unterstützen.
Einschreibung
Beim ersten Start des Geräts nach einem Zurücksetzen auf die Werkseinstellungen sind alle Authentifikatoren darauf vorbereitet, Anmeldeinformationen vom Benutzer zu erhalten. Ein Benutzer muss anfänglich eine PIN/ein Muster/ein Passwort bei Gatekeeper registrieren. Diese anfängliche Registrierung erstellt eine zufällig generierte, sichere 64-Bit-Benutzerkennung (SID), die als Kennung für den Benutzer und als Bindungstoken für das kryptografische Material des Benutzers dient. Diese Benutzer-SID ist kryptografisch an das Kennwort des Benutzers gebunden; Erfolgreiche Authentifizierungen bei Gatekeeper führen zu AuthTokens, die die Benutzer-SID für dieses Kennwort enthalten.
Ein Benutzer, der einen Berechtigungsnachweis ändern möchte, muss einen vorhandenen Berechtigungsnachweis vorlegen. Wenn ein vorhandener Berechtigungsnachweis erfolgreich verifiziert wird, wird die dem vorhandenen Berechtigungsnachweis zugeordnete Benutzer-SID auf den neuen Berechtigungsnachweis übertragen, sodass der Benutzer nach dem Ändern eines Berechtigungsnachweises weiterhin auf Schlüssel zugreifen kann. Wenn ein Benutzer keinen vorhandenen Berechtigungsnachweis vorlegt, wird der neue Berechtigungsnachweis mit einer vollständig zufälligen Benutzer-SID registriert. Der Benutzer kann auf das Gerät zugreifen, aber Schlüssel, die unter der alten Benutzer-SID erstellt wurden, gehen dauerhaft verloren. Dies wird als nicht vertrauenswürdige Registrierung bezeichnet.
Unter normalen Umständen lässt das Android-Framework keine nicht vertrauenswürdige Registrierung zu, sodass die meisten Benutzer diese Funktion nie sehen werden. Dies kann jedoch durch das erzwungene Zurücksetzen von Kennwörtern, entweder durch einen Geräteadministrator oder einen Angreifer, verursacht werden.
Authentifizierung
Nachdem ein Benutzer einen Berechtigungsnachweis eingerichtet und eine Benutzer-SID erhalten hat, kann er mit der Authentifizierung beginnen, die beginnt, wenn ein Benutzer eine PIN, ein Muster, ein Kennwort oder einen Fingerabdruck bereitstellt. Alle TEE-Komponenten teilen sich einen geheimen Schlüssel, mit dem sie die Nachrichten der anderen authentifizieren.

- Ein Benutzer stellt eine Authentifizierungsmethode bereit und der zugeordnete Dienst stellt eine Anfrage an den zugeordneten Daemon.
- Für PIN, Muster oder Passwort stellt
LockSettingsService
eine Anfrage angatekeeperd
. - Auf Biometrie basierende Authentifizierungsabläufe hängen von der Android-Version ab. Auf Geräten mit Android 8.x und niedriger stellt
FingerprintService
eine Anfrage anfingerprintd
). Auf Geräten mit Android 9 und höher stelltBiometricPrompt
eine Anfrage an den entsprechenden biometrischen Daemon (z. B. „fingerprintd
“ fürFingerprintManager
oder „faced
“ für Gesichter) mithilfe der entsprechendenBiometric Manager
-Klasse,FaceManager
. Unabhängig von der Version erfolgt die biometrische Authentifizierung asynchron, nachdem die Anforderung gesendet wurde.
- Für PIN, Muster oder Passwort stellt
- Der Daemon sendet Daten an sein Gegenstück, das ein AuthToken generiert:
- Für die PIN/Muster/Passwort-Authentifizierung sendet
gatekeeperd
den PIN-, Muster- oder Passwort-Hash an Gatekeeper im TEE. Wenn die Authentifizierung im TEE erfolgreich ist, sendet der Gatekeeper im TEE ein AuthToken mit der entsprechenden Benutzer-SID (signiert mit dem AuthToken-HMAC-Schlüssel) an sein Gegenstück im Android-Betriebssystem. - Für die Authentifizierung per
fingerprintd
lauscht fingerprintd auf Fingerabdruckereignisse und sendet die Daten an Fingerprint im TEE. Wenn die Authentifizierung im TEE erfolgreich ist, sendet Fingerprint im TEE ein AuthToken (signiert mit dem AuthToken-HMAC-Schlüssel) an sein Gegenstück im Android-Betriebssystem. - Für eine andere biometrische Authentifizierung lauscht der entsprechende biometrische Daemon auf das biometrische Ereignis und sendet es an die entsprechende biometrische TEE-Komponente.
- Für die PIN/Muster/Passwort-Authentifizierung sendet
- Der Daemon empfängt ein signiertes AuthToken und übergibt es über eine Erweiterung der Binder-Schnittstelle des Keystore-Dienstes an den Keystore-Dienst. (
gatekeeperd
benachrichtigt den Schlüsselspeicherdienst auch, wenn das Gerät wieder gesperrt wird und wenn sich das Gerätekennwort ändert.) - Der Schlüsselspeicherdienst übergibt die AuthTokens an Keymaster und verifiziert sie mithilfe des Schlüssels, der mit dem Gatekeeper und der unterstützten biometrischen TEE-Komponente geteilt wird. Keymaster vertraut dem Zeitstempel im Token als letzte Authentifizierungszeit und basiert eine Schlüsselfreigabeentscheidung (um einer App die Verwendung des Schlüssels zu erlauben) auf dem Zeitstempel.
AuthToken-Format
Um die Token-Freigabe und Kompatibilität über Sprachen und Komponenten hinweg sicherzustellen, wird das AuthToken-Format in hw_auth_token.h
beschrieben. Das Format ist ein einfaches Serialisierungsprotokoll mit Feldern fester Größe.
Aufstellen | Typ | Erforderlich | Beschreibung |
---|---|---|---|
AuthToken-Version | 1 Byte | Ja | Gruppieren Sie Tag für alle Felder unten. |
Herausforderung | 64-Bit-Ganzzahl ohne Vorzeichen | Nein | Eine zufällige ganze Zahl, um Replay-Angriffe zu verhindern. Normalerweise die ID einer angeforderten Krypto-Operation. Wird derzeit von transaktionalen Fingerabdruckautorisierungen verwendet. Falls vorhanden, ist das AuthToken nur für Kryptooperationen gültig, die dieselbe Challenge enthalten. |
Benutzer-SID | 64-Bit-Ganzzahl ohne Vorzeichen | Ja | Sich nicht wiederholende Benutzerkennung, die kryptografisch an alle Schlüssel gebunden ist, die der Geräteauthentifizierung zugeordnet sind. Einzelheiten finden Sie unter Gatekeeper . |
Authentifizierungs-ID (ASID) | 64-Bit-Ganzzahl ohne Vorzeichen in Netzwerkreihenfolge | Nein | Bezeichner, der zum Binden an eine bestimmte Authentifizierungsrichtlinie verwendet wird. Alle Authentifikatoren haben ihren eigenen ASID-Wert, den sie entsprechend ihren eigenen Anforderungen ändern können. |
Authentifizierungstyp | 32-Bit-Ganzzahl ohne Vorzeichen in Netzwerkreihenfolge | Ja |
|
Zeitstempel | 64-Bit-Ganzzahl ohne Vorzeichen in Netzwerkreihenfolge | Ja | Zeit (in Millisekunden) seit dem letzten Systemstart. |
AuthToken-HMAC (SHA-256) | 256-Bit-Blob | Ja | Keyed SHA-256 MAC aller Felder außer dem HMAC-Feld. |
Boot-Flow des Geräts
Bei jedem Start eines Geräts muss der AuthToken-HMAC-Schlüssel generiert und mit allen TEE-Komponenten (Gatekeeper, Keymaster und unterstützte Biometrie-Trustlets) geteilt 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 Teilen dieses HMAC-Schlüssels mit allen Komponenten ist ein plattformabhängiges Implementierungsmerkmal. Der Schlüssel darf niemals außerhalb des TEE zur Verfügung gestellt werden. Wenn einem TEE-Betriebssystem kein interner Interprozesskommunikationsmechanismus (IPC) fehlt und die Daten über das nicht vertrauenswürdige Betriebssystem übertragen werden müssen, muss die Übertragung über ein sicheres Schlüsselaustauschprotokoll erfolgen.
Das Trusty -Betriebssystem, das neben Android läuft, ist ein Beispiel für ein TEE, aber andere TEEs können stattdessen 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; Fingerprint und Gatekeeper fordern den Schlüssel für jede Verwendung von Keymaster an und speichern oder speichern den Wert nicht.
Da einigen TEEs eine IPC-Infrastruktur fehlt, findet keine Kommunikation zwischen Applets im TEE statt. Dies ermöglicht es dem Keystore-Dienst auch, Anfragen schnell abzulehnen, die zwangsläufig fehlschlagen, da er Kenntnis von der Authentifizierungstabelle im System hat, wodurch ein möglicherweise kostspieliger IPC in das TEE eingespart wird.