Authentifizierung

Android verwendet das Konzept kryptografischer Schlüssel mit Benutzerauthentifizierung, für das die folgenden Komponenten erforderlich sind:

• Anbieter von kryptografischer Schlüsselspeicherung und -diensten. Speichert kryptografische Schlüssel und stellt zusätzlich zu diesen Schlüsseln Standard-Kryptoroutinen 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 ein Secure Element (SE) wie Strongbox umfassen kann.
• Benutzerauthentifizierer. 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 biometrische Daten verwenden. Diese Komponenten kommunizieren ihren Authentifizierungsstatus über einen authentifizierten Kanal mit dem Keystore-Dienst. (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 Authentifizierungstokens (AuthTokens) zu unterstützen.

Einschreibung

Beim ersten Start des Geräts nach einem Zurücksetzen auf die Werkseinstellungen sind alle Authentifikatoren darauf vorbereitet, Anmeldeinformationsregistrierungen vom Benutzer zu empfangen. Ein Benutzer muss zunächst eine PIN/ein Muster/ein Passwort bei Gatekeeper registrieren. Bei dieser ersten Registrierung wird eine zufällig generierte 64-Bit-Benutzer-Sicherheitskennung (SID) erstellt, die als Kennung für den Benutzer und als verbindliches Token für das kryptografische Material des Benutzers dient. Diese Benutzer-SID ist kryptografisch an das Kennwort des Benutzers gebunden; Erfolgreiche Authentifizierungen beim Gatekeeper führen zu AuthTokens, die die Benutzer-SID für dieses Passwort enthalten.

Ein Benutzer, der einen Berechtigungsnachweis ändern möchte, muss einen vorhandenen Berechtigungsnachweis vorlegen. Wenn ein vorhandener Berechtigungsnachweis erfolgreich überprüft wird, wird die mit dem vorhandenen Berechtigungsnachweis verknüpfte 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 völlig zufälligen Benutzer-SID registriert. Der Benutzer kann auf das Gerät zugreifen, die unter der alten Benutzer-SID erstellten Schlüssel gehen jedoch dauerhaft verloren. Dies wird als nicht vertrauenswürdige Anmeldung bezeichnet.

Unter normalen Umständen lässt das Android-Framework keine nicht vertrauenswürdige Registrierung zu, sodass die meisten Benutzer diese Funktionalität nie sehen werden. Dies kann jedoch durch gewaltsames Zurücksetzen des Passworts durch einen Geräteadministrator oder einen Angreifer verursacht werden.

Authentifizierung

Nachdem ein Benutzer Anmeldeinformationen 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 zugehörige Dienst stellt eine Anfrage an den zugehörigen Daemon.
   • Für PIN, Muster oder Passwort sendet 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 mithilfe der entsprechenden Biometric Manager Klasse, z. B. FingerprintManager oder FaceManager , eine Anfrage an den entsprechenden biometrischen Daemon (z. B. „ fingerprintd “ für Fingerabdrücke oder „ faced für Gesicht). 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:
   • Zur 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.
   • Zur Authentifizierung per Fingerabdruck wartet 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 Keystore-Dienstes an den Keystore-Dienst. ( gatekeeperd benachrichtigt den Keystore-Dienst auch, wenn das Gerät erneut gesperrt wird und wenn sich das Gerätekennwort ändert.)
4. Der Keystore-Dienst übergibt die AuthTokens an Keymaster und verifiziert sie mithilfe des mit dem Gatekeeper geteilten Schlüssels und der unterstützten biometrischen TEE-Komponente. Keymaster vertraut dem Zeitstempel im Token als Zeitpunkt der letzten Authentifizierung und basiert eine Schlüsselfreigabeentscheidung (um einer App die Verwendung des Schlüssels zu ermöglichen) auf dem Zeitstempel.

AuthToken-Format

Um die Token-Freigabe und Kompatibilität zwischen Sprachen und Komponenten sicherzustellen, wird das AuthToken-Format in hw_auth_token.h beschrieben. Das Format ist ein einfaches Serialisierungsprotokoll mit Feldern fester Größe.

Gerätestartablauf

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. Um zusätzlichen Schutz vor Replay-Angriffen zu bieten, 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 eine plattformabhängige Implementierungsfunktion. Der Schlüssel darf niemals außerhalb des TEE zugänglich gemacht werden. Wenn einem TEE-Betriebssystem ein 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.

Ein Beispiel für ein TEE ist das Betriebssystem Trusty , das neben Android läuft, 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; Fingerprint und Gatekeeper fordern den Schlüssel für jede Verwendung von Keymaster an und speichern oder speichern den Wert nicht.

Da einige TEEs über keine IPC-Infrastruktur verfügen, findet keine Kommunikation zwischen Applets im TEE statt. Dadurch kann der Keystore-Dienst auch Anfragen, die zwangsläufig fehlschlagen, schnell ablehnen, da er die Authentifizierungstabelle im System kennt, wodurch ein potenziell kostspieliger IPC im TEE eingespart wird.