Authentifizierung

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.

1. 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 an gatekeeperd .
   • 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 an fingerprintd ). Auf Geräten mit Android 9 und höher stellt BiometricPrompt eine Anfrage an den entsprechenden biometrischen Daemon (z. B. „ fingerprintd “ für FingerprintManager oder „ faced “ für Gesichter) mithilfe der entsprechenden Biometric Manager -Klasse, FaceManager . Unabhängig von der Version erfolgt die biometrische Authentifizierung asynchron, nachdem die Anforderung gesendet wurde.
2. 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.
3. 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.)
4. 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.

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.