Authentication

Android verwendet Nutzerauthentifizierer, mit denen das Gerät entsperrt und der Zugriff auf kryptografische Schlüssel gesteuert wird. Dazu sind die folgenden Komponenten erforderlich:

  • Speicher für kryptografische Schlüssel und Dienstanbieter Speichert kryptografische Schlüssel und bietet standardmäßige Kryptografieroutinen für diese Schlüssel. Android supports a hardware-backed Keystore and KeyMint (previously Keymaster) for cryptographic services, including hardware-backed cryptography for key storage that might include a Trusted Execution Environment (TEE) or Secure Element (SE), such as StrongBox.
  • Nutzerauthentifizierer Bestätigen die Anwesenheit des Nutzers und/oder die erfolgreiche Authentifizierung. Android unterstützt Gatekeeper für die PIN-/Muster-/Passwortauthentifizierung und Fingerprint für die Fingerabdruck authentifizierung. Auf Geräten mit Android 9 und höher kann BiometricPrompt als einziger Integrationspunkt für Fingerabdruck- und zusätzliche biometrische Authentifizierung verwendet werden. Diese Komponenten kommunizieren ihren Authentifizierungsstatus über einen authentifizierten Kanal mit dem Schlüsselspeicherdienst. Das Android-Schlüsselspeichersystem auf Framework-Ebene wird ebenfalls vom Schlüsselspeicherdienst unterstützt.

Jede dieser Komponenten ist anbieterspezifisch. Die Implementierung des Anbieters muss jedoch der Schnittstellenspezifikation der Hardwareabstraktionsschicht (HAL) entsprechen und die entsprechenden Tests der Vendor Test Suite (VTS) 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 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 werden alle Authentifizierer darauf vorbereitet, Anmeldedatenregistrierungen 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 ID 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 angeben. Wenn vorhandene Anmeldedaten erfolgreich bestätigt werden, 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 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 anzugeben. So kann der Nutzer auf das Gerät zugreifen, aber Schlüssel, die mit der alten Nutzer-SID erstellt wurden, gehen dauerhaft verloren.

Authentifizierung

In diesem Abschnitt wird ein typischer Authentifizierungsvorgang beschrieben, bei dem mehrere Komponenten in Android und in der sicheren Umgebung interagieren. Alle sicheren Komponenten verwenden einen geheimen HMAC-Schlüssel (pro Start), 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. Dazu gibt er eine PIN, ein Muster, ein Passwort, einen Fingerabdruck oder andere starke biometrische Daten an. 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.
    • Die biometrischen Authentifizierungsvorgänge 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 mit der entsprechenden BiometricManager Klasse, z. B. FingerprintManager oder FaceManager, eine Anfrage an den entsprechenden biometrischen Daemon (z. B. fingerprintd für Fingerabdrücke oder faced für Gesichtserkennung). 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 PIN-/Muster-/Passwortauthentifizierung sendet gatekeeperd den PIN-, Muster- oder Passwort-Hash über den Gatekeeper-HAL-Dienst an die Gatekeeper-TA im TEE. Wenn die Authentifizierung im TEE erfolgreich ist, gibt die Gatekeeper-TA ein AuthToken aus, das die entsprechende Nutzer-SID enthält (signiert mit dem gemeinsamen HMAC-Schlüssel).
    • Bei der Fingerabdruckauthentifizierung wartet fingerprintd auf Fingerabdruckereignisse und sendet die Daten über die Fingerabdruck-HAL an die Fingerabdruck-TA im TEE. Wenn die Authentifizierung im TEE erfolgreich ist, gibt die Fingerabdruck-TA ein AuthToken aus (signiert mit dem AuthToken-HMAC-Schlüssel).
    • Bei anderen biometrischen Authentifizierungsmethoden wartet der entsprechende biometrische Daemon wartet 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 Schlüsselspeicherdienstes an den Schlüsselspeicher Dienst. gatekeeperd benachrichtigt den Schlüsselspeicherdienst auch, wenn das Gerät wieder gesperrt wird und wenn sich das Gerätepasswort ändert.
  4. Der Schlüsselspeicherdienst übergibt die AuthTokens an KeyMint und überprüft sie mit dem Schlüssel, der für die Gatekeeper- und die unterstützte biometrische TEE Komponente freigegeben wurde. KeyMint verwendet den Zeitstempel im Token als Zeitpunkt der letzten Authentifizierung und trifft auf Grundlage des Zeitstempels eine Entscheidung zur Freigabe des Schlüssels (damit eine App den Schlüssel verwenden kann).

Für den Authentifizierungsvorgang ist keine direkte Kommunikation zwischen den TAs in der sicheren Umgebung erforderlich. AuthTokens werden von der Authentifizierer-TA an den Dienst keystore2 in Android gesendet, der sie wiederum an die KeyMint-TA weiterleitet. So kann der Dienst keystore2 Anfragen, die mit Sicherheit fehlschlagen, schnell ablehnen, da er die verfügbaren AuthTokens im System kennt. Dadurch wird eine potenziell kostspielige IPC-Kommunikation mit dem TEE vermieden.

AuthToken-Format

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

Geräte-Bootvorgang

Bei jedem Start eines Geräts muss der AuthToken-HMAC-Schlüssel generiert und für alle TEE-Komponenten freigegeben werden (Gatekeeper, KeyMint und unterstützte biometrische Trustlets). 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 gemeinsamen HMAC Schlüssel erhalten:

  • Vereinbarung eines gemeinsamen Secrets: Der Dienst keystore2 führt beim Gerätestart ein Mehrwege-Schlüsselvereinbarungsprotokoll durch, das eine sichere Ableitung des HMAC-Schlüssels zwischen den beteiligten TAs ermöglicht. Die beteiligten 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 Mechanismus für die Interprocess Communication (der plattformabhängig ist) verwenden, um den HMAC-Schlüssel freizugeben.

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

Das Trusty-Betriebssystem, 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 nur in KeyMint gespeichert. Fingerprint und Gatekeeper fordern den Schlüssel bei jeder Verwendung von KeyMint an und speichern oder cachen den Wert nicht.

Da einige TEEs keine IPC-Infrastruktur haben, findet keine Kommunikation zwischen Applets im TEE statt. So kann der Schlüsselspeicherdienst Anfragen, die mit Sicherheit fehlschlagen, schnell ablehnen, da er die Authentifizierungstabelle im System kennt. Dadurch wird eine potenziell kostspielige IPC-Kommunikation mit dem TEE vermieden.