Authentication

Android verwendet Nutzerauthentifikatoren, um das Gerät zu entsperren und den Zugriff auf kryptografische Schlüssel zu steuern. Dazu gehören die folgenden Komponenten:

  • Speicher für kryptografische Schlüssel und Dienstanbieter. Der Android-Keystore bietet hardwaregestützte kryptografische Dienste für Apps. Das Android Keystore-System auf Framework-Ebene wird vom Systemdienst keystore2 unterstützt. Diese basiert wiederum auf einer zugrunde liegenden herstellerspezifischen KeyMint-Implementierung (früher Keymaster), die dafür sorgt, dass Schlüsselmaterial nur in einer hardwaregestützten sicheren Umgebung zugänglich ist, z. B. in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) oder einem Secure Element (SE) wie StrongBox.
  • Nutzerauthentifikatoren Bestätigen Sie die erfolgreiche Authentifizierung des Nutzers. Android unterstützt die folgenden Authentifizierungskomponenten:
    • Gatekeeper für die Authentifizierung per PIN, Muster oder Passwort in der TEE.
    • (Optional) Weaver für die Authentifizierung per PIN, Muster oder Passwort in einem Secure Element.
    • Fingerabdruck für die Fingerabdruckauthentifizierung.
    • Andere biometrische Authentifizierungsmethoden. Geräte, die mit Android 9 oder 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 mit dem keystore2-Dienst über hardwaregestützte Authentifizierungstokens (AuthTokens) .

Jede dieser Komponenten ist herstellerspezifisch, aber die Herstellerimplementierung muss eine Hardwareabstraktionsschicht (HAL)-Schnittstellenspezifikation erfüllen und die entsprechenden VTS-Tests (Vendor Test Suite) bestehen.

Anbieterimplementierungen sind in der Regel ebenfalls in zwei Teile unterteilt, die durch einen anbieterspezifischen Kommunikationsmechanismus verbunden sind :

  • Ein HAL-Dienst wird als Android-Systemprozess ausgeführt und empfängt Binder-Anfragen 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 Start des Geräts nach dem Zurücksetzen auf die Werkseinstellungen sind alle Authentifikatoren bereit, Anmeldedaten vom Nutzer zu erhalten. Ein Nutzer muss zuerst eine PIN, ein Muster oder ein Passwort bei Gatekeeper (oder Weaver, falls verfügbar) registrieren. Bei dieser ersten Registrierung 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 ein vorhandener Berechtigungsnachweis erfolgreich verifiziert wurde, wird die mit dem vorhandenen Berechtigungsnachweis verknüpfte Nutzer-SID auf den neuen Berechtigungsnachweis übertragen. So kann der Nutzer auch nach dem Ändern eines Berechtigungsnachweises weiterhin auf Schlüssel zugreifen.

In einigen Situationen kann ein Geräteadministrator eine nicht vertrauenswürdige Registrierung durchführen, um neue Anmeldedaten zu registrieren, ohne vorhandene Anmeldedaten vorzulegen. Dadurch 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. Beachte, dass alle sicheren Komponenten einen (pro Bootvorgang) geheimen HMAC-Schlüssel gemeinsam nutzen, mit dem sie die Nachrichten der jeweils anderen Komponenten authentifizieren.

Nachdem ein Nutzer Anmeldedaten eingerichtet hat und ihm eine Nutzer-SID zugewiesen wurde, kann er die Authentifizierung starten. Diese beginnt, wenn ein Nutzer eine PIN, ein Muster, ein Passwort, einen Fingerabdruck oder ein anderes starkes biometrisches Verfahren angibt. Authentifizierungsvorgang

Abbildung 1. Authentifizierungsvorgang

  1. Ein Nutzer stellt eine Authentifizierungsmethode bereit und der zugehörige Dienst sendet eine Anfrage an den HAL-Dienst.
    • Bei PIN, Muster oder Passwort sendet LockSettingsService eine Anfrage an gatekeeperd.
    • Die Abläufe für die biometrische Authentifizierung 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) und verwendet dazu die entsprechende BiometricManager-Klasse, z. B. FingerprintManager oder FaceManager. Unabhängig von der Version erfolgt die biometrische Authentifizierung asynchron, nachdem die Anfrage gesendet wurde.
  2. Der HAL-Dienst sendet Daten an die entsprechende TA, die ein AuthToken generiert:
    • Bei der Authentifizierung per PIN, Muster oder Passwort sendet gatekeeperd den Hash 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 ist, gibt die Gatekeeper-TA ein AuthToken mit der entsprechenden Nutzer-SID aus (signiert mit dem gemeinsamen HMAC-Schlüssel).
    • Bei der Authentifizierung per Fingerabdruck wartet fingerprintd auf Fingerabdruckereignisse und sendet die Daten über die Fingerabdruck-HAL an die Fingerabdruck-TA in der TEE. Wenn die Authentifizierung in der TEE erfolgreich ist, gibt die Fingerabdruck-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 die TA.
  3. Das resultierende signierte AuthToken wird über eine Binder-Schnittstelle an den Systemdienst keystore2 übergeben.
  4. Der keystore2-Dienst hängt die AuthTokens an die Anfrage für KeyMint (früher Keymaster) an, um kryptografische Vorgänge auszuführen. Der KeyMint-HAL-Dienst leitet sie an die KeyMint-TA weiter, die sie mit dem HMAC-Schlüssel verifiziert, 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 anhand des Zeitstempels, ob die Verwendung des Schlüssels zulässig ist.

Der Authentifizierungsablauf erfordert keine direkte Kommunikation zwischen TAs in der sicheren Umgebung: AuthTokens fließen von der Authentifikator-TA zum keystore2-Dienst in Android, der sie wiederum an die KeyMint-TA weitergibt. Außerdem kann der keystore2-Dienst so Anfragen, die fehlschlagen werden, schnell ablehnen, da er die verfügbaren AuthTokens im System kennt. Dadurch wird ein potenziell kostspieliger IPC in die TEE vermieden.

AuthToken-Format

Das Format des AuthTokens wird durch die AIDL-Spezifikation in HardwareAuthToken.aidl vorgegeben.

Bootvorgang des Geräts

Bei jedem Start eines Geräts muss der AuthToken-HMAC-Schlüssel generiert und für alle TEE-Komponenten (Gatekeeper, KeyMint und unterstützte biometrische TAs) freigegeben werden. Um Replay-Angriffe zu verhindern, muss der HMAC-Schlüssel bei jedem Neustart des Geräts zufällig generiert werden.

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

  • Vereinbarung über ein gemeinsames Secret: Der keystore2-Dienst führt beim Gerätestart ein Protokoll zur Vereinbarung eines Schlüssels zwischen mehreren Parteien aus, sodass der HMAC-Schlüssel zwischen den beteiligten TAs sicher abgeleitet werden kann. Teilnehmende TAs müssen jedoch Zugriff auf einen gemeinsamen vorinstallierten Schlüssel haben.
  • Direkter Zugriff: TAs, die sich in derselben sicheren Umgebung befinden, können einen internen Interprocess Communication-Mechanismus (der plattformabhängig ist) verwenden, um den HMAC-Schlüssel freizugeben.

In beiden Fällen darf der HMAC-Schlüssel niemals außerhalb der 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 der 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 den Wert nicht dauerhaft oder im Cache.

Da einige TEEs keine IPC-Infrastruktur haben, findet keine Kommunikation zwischen Applets im TEE statt. Dadurch kann der Schlüsselspeicherdienst auch Anfragen schnell ablehnen, die fehlschlagen werden, da er die Authentifizierungstabelle im System kennt. So wird ein potenziell kostspieliger IPC in die TEE vermieden.