Authentication

Android bietet das Konzept von Nutzerauthentifikatoren, die zum Entsperren des Geräts und zum Steuern des Zugriffs auf kryptografische Schlüssel verwendet werden. Dazu sind die folgenden Komponenten erforderlich:

  • Speicher und Dienstanbieter für kryptografische Schlüssel Speichert kryptografische Schlüssel und stellt Standard-Kryptoroutinen für diese Schlüssel bereit. Android unterstützt einen hardwarebasierten Keystore und KeyMint (früher Keymaster) für kryptografische Dienste, einschließlich hardwarebasierter Kryptografie für die Schlüsselspeicherung, die eine Trusted Execution Environment (TEE) oder ein Secure Element (SE) wie StrongBox umfassen kann.
  • Nutzerauthentifikatoren: Die Anwesenheit des Nutzers und/oder die erfolgreiche Authentifizierung bestätigen. Android unterstützt Gatekeeper für die Authentifizierung per PIN, Muster oder Passwort und Fingerprint für die Authentifizierung per Fingerabdruck. Geräte, die mit Android 9 und höher ausgeliefert werden, können BiometricPrompt als einzigen Integrationspunkt für Fingerabdruck und zusätzliche biometrische Daten verwenden. Diese Komponenten kommunizieren ihren Authentifizierungsstatus über einen authentifizierten Kanal mit dem Keystore-Dienst. Das Android-Schlüsselspeichersystem auf Framework-Ebene wird ebenfalls vom Schlüsselspeicherdienst unterstützt.

Jede dieser Komponenten ist anbieterspezifisch. Die Anbieterimplementierung muss jedoch einer Hardware Abstraction Layer (HAL)-Schnittstellenspezifikation entsprechen und die entsprechenden VTS-Tests (Vendor Test Suite) bestehen.

Die Implementierungen von Anbietern 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 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 empfangen. 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. Die Nutzer-SID ist kryptografisch an das Passwort des Nutzers gebunden. Bei erfolgreichen Authentifizierungen bei Gatekeeper werden AuthTokens generiert, die die Nutzer-SID für dieses Passwort enthalten.

Ein Nutzer, der eine vorhandene Anmeldedaten ändern möchte, muss diese Anmeldedaten vorlegen. Wenn eine vorhandene Anmeldedaten erfolgreich bestätigt werden, wird die Nutzer-SID, die mit den vorhandenen Anmeldedaten verknüpft ist, 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 durchführen, um neue Anmeldedaten zu registrieren, ohne vorhandene Anmeldedaten zu präsentieren. Der Nutzer kann dann auf das Gerät zugreifen, aber Schlüssel, die unter der alten Nutzer-SID erstellt wurden, sind dauerhaft verloren.

Authentifizierung

In diesem Abschnitt wird ein typischer Authentifizierungsablauf beschrieben, bei dem mehrere Komponenten sowohl in Android als auch in der sicheren Umgebung interagieren. Alle sicheren Komponenten verwenden einen geheimen HMAC-Schlüssel (pro Bootvorgang), mit dem sie die Nachrichten der anderen Komponenten authentifizieren.

Nachdem ein Nutzer Anmeldedaten eingerichtet und eine Nutzer-SID zugewiesen bekommen hat, 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 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.
    • Authentifizierungsabläufe auf Grundlage biometrischer Daten hängen von der Android-Version ab. Auf Geräten mit Android 8.x und niedriger wird mit FingerprintService eine Anfrage an fingerprintd gesendet. Auf Geräten mit Android 9 und höher wird mit BiometricPrompt eine Anfrage an den entsprechenden biometrischen Daemon gesendet (z. B. fingerprintd für Fingerabdrücke oder faced für das Gesicht). Dabei wird die entsprechende BiometricManager-Klasse verwendet, 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 das entsprechende TA, das 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 im TEE. Wenn die Authentifizierung im TEE erfolgreich ist, gibt die Gatekeeper-TA ein AuthToken mit der entsprechenden Nutzer-SID aus, das mit dem gemeinsamen HMAC-Schlüssel signiert ist.
    • Bei der Fingerabdruck-Authentifizierung wartet fingerprintd auf Fingerabdruckereignisse und sendet die Daten über den Fingerabdruck-HAL an die Fingerabdruck-TA im TEE. Wenn die Authentifizierung im 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 die entsprechende TA.
  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 wieder gesperrt wird und wenn sich das Gerätepasswort ändert.)
  4. Der Keystore-Dienst übergibt die AuthTokens an KeyMint und überprüft sie mit dem Schlüssel, der für den Gatekeeper und die unterstützte biometrische TEE-Komponente freigegeben ist. KeyMint vertraut dem Zeitstempel im Token als letzter Authentifizierungszeit und stützt eine Entscheidung zur Freigabe eines Schlüssels (damit eine App den Schlüssel verwenden kann) auf den Zeitstempel.

Für den Authentifizierungsablauf ist keine direkte Kommunikation zwischen TAs in der sicheren Umgebung erforderlich: AuthTokens werden von der Authenticator-TA an den keystore2-Dienst in Android gesendet, der sie wiederum an die KeyMint-TA weiterleitet. Außerdem kann der keystore2-Dienst Anfragen, die ohnehin fehlschlagen würden, schnell ablehnen, da er die verfügbaren AuthTokens im System kennt. So wird ein potenziell kostspieliger IPC in das TEE vermieden.

AuthToken-Format

Das Format des AuthToken wird durch die AIDL-Spezifikation in HardwareAuthToken.aidl angegeben.

Geräte-Bootvorgang

Bei jedem Start eines Geräts muss der HMAC-Schlüssel für das AuthToken generiert und für alle TEE-Komponenten (Gatekeeper, KeyMint und unterstützte biometrische Trustlets) freigegeben werden. Um den Schutz vor Replay-Angriffen zu erhöhen, 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 Starten des Geräts ein Multi-Way-Key-Agreement-Protokoll aus, das eine sichere Ableitung des HMAC-Schlüssels zwischen den beteiligten TAs ermöglicht. Teilnehmende TAs müssen jedoch Zugriff auf ein gemeinsames vorab freigegebenes Secret haben.
  • Direkter Zugriff:TAs, die sich in derselben sicheren Umgebung befinden, können den HMAC-Schlüssel über einen internen Interprocess Communication-Mechanismus (plattformabhängig) freigeben.

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 ein 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 Trustlet 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.

Da einigen TEEs eine IPC-Infrastruktur fehlt, findet keine Kommunikation zwischen Applets im TEE statt. Dadurch kann der Keystore-Dienst Anfragen, die ohnehin fehlschlagen würden, schnell ablehnen, da er die Authentifizierungstabelle im System kennt. So wird ein potenziell kostspieliger IPC in das TEE vermieden.