Authentication

Android bietet Nutzer-Authentifikatoren, mit denen das Gerät entsperrt und der Zugriff auf kryptografische Schlüssel gesteuert wird. Dazu gehören die folgenden Komponenten:

  • Speicher- und Dienstanbieter für kryptografische Schlüssel. Der Android Keystore bietet hardwaregestützte kryptografische Dienste für Apps. Das Android-Keystore-System auf Frameworkebene wird vom keystore2-Systemdienst unterstützt. Diese basiert wiederum auf einer zugrunde liegenden anbieterspezifischen KeyMint-Implementierung (früher Keymaster), die dafür sorgt, dass auf Schlüsselmaterial nur in einer hardwaregestützten sicheren Umgebung wie einer Trusted Execution Environment (TEE) oder einem Secure Element (SE) zugegriffen werden kann.
  • Nutzer-Authenticator Bestätigen Sie die erfolgreiche Authentifizierung des Nutzers. Android unterstützt die folgenden Authentifizierungskomponenten:
    • Gatekeeper für die PIN-, Muster- oder Passwortauthentifizierung im TEE.
    • Optional: Weaver für die PIN-, Muster- oder Passwortauthentifizierung in einem sicheren Element.
    • Fingerabdruck für die Fingerabdruckauthentifizierung.
    • Andere biometrische Authentifizierungsmethoden Auf Geräten mit Android 9 oder höher kann BiometricPrompt als einziger Integrationspunkt für Fingerabdruck und zusätzliche biometrische Daten verwendet werden.
    Diese Komponenten geben ihren Authentifizierungsstatus mithilfe von hardwaregestützten Authentifizierungstokens (AuthTokens) an den keystore2-Dienst weiter .

Jede dieser Komponenten ist anbieterspezifisch, aber die Anbieterimplementierung muss die Schnittstellenspezifikation der Hardware Abstraction Layer (HAL) erfüllen und die entsprechenden VTS-Tests (Vendor Test Suite) bestehen.

Anbieterimplementierungen sind in der Regel auch in zwei Teile unterteilt, die über einen anbieterspezifischen Kommunikationsmechanismus verbunden sind :

  • Ein HAL-Dienst wird als Android-Systemprozess ausgeführt und empfängt Binderanfragen vom Android-System.
  • Eine vertrauenswürdige Anwendung (Trusted Application, TA) wird in der sicheren Umgebung ausgeführt und führt die eigentlichen sicheren Vorgänge aus.

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 (oder Weaver, falls verfügbar) 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 vorhandene Anmeldedaten ändern möchte, muss diese Anmeldedaten vorlegen. Wenn eine vorhandene Anmeldedaten erfolgreich bestätigt wird, wird die mit den vorhandenen Anmeldedaten verknüpfte Nutzer-SID auf die neuen Anmeldedaten übertragen. So kann der Nutzer auch nach dem Ändern der Anmeldedaten weiterhin auf Schlüssel zugreifen.

In einigen Fällen kann ein Geräteadministrator eine nicht vertrauenswürdige Registrierung ausführen, um neue Anmeldedaten zu registrieren, ohne vorhandene Anmeldedaten vorzulegen. So kann der Nutzer auf das Gerät zugreifen, aber Schlüssel, die unter der alten Nutzer-SID erstellt wurden, gehen dauerhaft verloren.

Authentifizierung

In diesem Abschnitt wird ein typischer Authentifizierungsablauf beschrieben, der Interaktionen zwischen mehreren Komponenten sowohl in Android als auch in der sicheren Umgebung umfasst. Alle sicheren Komponenten teilen sich einen geheimen HMAC-Schlüssel (pro Boot), mit dem sie die Nachrichten der anderen authentifizieren.

Nachdem ein Nutzer Anmeldedaten eingerichtet und eine Nutzer-SID zugewiesen bekommen hat, kann er mit der Authentifizierung beginnen. Dazu gibt er eine PIN, ein Muster, ein Passwort, einen Fingerabdruck oder ein anderes starkes biometrisches Verfahren an. Authentifizierungsablauf

Abbildung 1: Authentifizierungsablauf

  1. Ein Nutzer gibt eine Authentifizierungsmethode an und der zugehörige Dienst sendet eine Anfrage an den HAL-Dienst.
    • 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 HAL-Dienst sendet Daten an sein Pendant TA, das ein AuthToken generiert:
    • Bei der PIN-/Muster-/Passwortauthentifizierung sendet gatekeeperd den Hashwert der PIN, des Musters oder des Passworts über den Gatekeeper HAL-Dienst an die Gatekeeper-TA in der TEE. Wenn die Authentifizierung in der TEE erfolgreich war, gibt die Gatekeeper-TA ein AuthToken mit der entsprechenden Nutzer-SID aus (signiert mit dem freigegebenen HMAC-Schlüssel).
    • Bei der Fingerabdruckauthentifizierung prüft fingerprintd auf Fingerabdruckereignisse und sendet die Daten über die Fingerabdruck-HAL an den Fingerabdruck-TA in der TEE. Wenn die Authentifizierung in der TEE erfolgreich ist, gibt die Fingerprint-TA ein AuthToken aus, das mit dem AuthToken-HMAC-Schlüssel signiert ist.
    • Bei anderen biometrischen Authentifizierungen wartet der entsprechende biometrische Daemon auf das biometrische Ereignis und sendet es an den entsprechenden biometrischen HAL-Dienst und TA.
  3. Das resultierende signierte AuthToken wird über eine Binder-Schnittstelle an den keystore2-Systemdienst übergeben.
  4. Der keystore2-Dienst hängt die AuthTokens an, um KeyMint (früher Keymaster) zu bitten, kryptografische Vorgänge auszuführen. Der KeyMint HAL-Dienst leitet sie an die KeyMint-TA weiter, die sie mit dem HMAC-Schlüssel überprüft, der mit dem Gatekeeper und den unterstützten biometrischen TEE-Komponenten geteilt wird. KeyMint vertraut dem Zeitstempel im Token als Zeitpunkt der letzten Authentifizierung und entscheidet basierend auf dem Zeitstempel, ob die Verwendung des Schlüssels zulässig ist.

Für den Authentifizierungsablauf ist keine direkte Kommunikation zwischen TAs in der sicheren Umgebung erforderlich: AuthTokens fließen vom Authenticator-TA an den keystore2-Dienst in Android, der sie wiederum an den KeyMint-TA weitergibt. So kann der keystore2-Dienst auch schnell Anfragen ablehnen, die scheitern müssen, da er über die verfügbaren AuthTokens im System Bescheid weiß. Dadurch wird eine potenziell kostspielige IPC in die TEE vermieden.

AuthToken-Format

Das Format des AuthTokens wird in der AIDL-Spezifikation in HardwareAuthToken.aidl angegeben.

Bootvorgang des Geräts

Bei jedem Starten eines Geräts muss der AuthToken-HMAC-Schlüssel generiert und für alle TEE-Komponenten (Gatekeeper, KeyMint/Keymaster und unterstützte biometrische TAs) freigegeben werden. Um Replay-Angriffe zu verhindern, muss der HMAC-Schlüssel jedes Mal, wenn das Gerät neu gestartet wird, zufällig generiert werden.

Es gibt zwei gängige Möglichkeiten, wie TAs Zugriff auf diesen freigegebenen HMAC-Schlüssel erhalten:

  • Vereinbarung für freigegebene Geheimnisse:Der keystore2-Dienst führt beim Starten des Geräts ein Protokoll für die mehrstufige Schlüsselvereinbarung durch, das eine sichere Ableitung des HMAC-Schlüssels zwischen den teilnehmenden TAs ermöglicht. Die teilnehmenden TAs müssen jedoch Zugriff auf ein gemeinsames vorab freigegebenes Secret haben.
  • Direkter Zugriff:TAs, die sich in derselben sicheren Umgebung befinden, können einen internen, plattformabhängigen Mechanismus zur Interprozesskommunikation verwenden, um den HMAC-Schlüssel freizugeben.

In beiden Fällen darf der HMAC-Schlüssel nie außerhalb des TEE verfügbar gemacht werden.

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 KeyMint und Gatekeeper oder dem entsprechenden biometrischen TA zu kommunizieren. Der HMAC-Schlüssel wird ausschließlich in KeyMint gespeichert. Fingerprint und Gatekeeper fordern den Schlüssel bei jeder Verwendung von KeyMint an und speichern oder cachen den Wert nicht.