Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

HIDL für die Gesichtserkennung

Übersicht

Mit der Gesichtserkennung können Nutzer ihr Gerät entsperren, indem sie einfach auf die Vorderseite des Geräts schauen. Unter Android 10 wird ein neuer Gesichtserkennungs-Stack unterstützt, mit dem Kamerabilder sicher verarbeitet werden können. So werden Sicherheit und Datenschutz bei der Gesichtserkennung auf unterstützter Hardware gewährleistet. Android 10 bietet außerdem eine einfache Möglichkeit für sicherheitskonforme Implementierungen, die Anwendungsintegration für Transaktionen wie Onlinebanking oder andere Dienste zu aktivieren.

Der Android-Gesichtsauthentifizierungs-Stack ist eine neue Implementierung in Android 10. Mit der neuen Implementierung werden die Schnittstellen IBiometricsFace.hal, IBiometricsFaceClientCallback.hal und types.hal eingeführt.

Architektur

Die BiometricPrompt API umfasst alle biometrischen Authentifizierungen, einschließlich Gesicht, Finger und Iris. Das Face HAL interagiert mit den folgenden Komponenten.

FaceManager

FaceManager ist eine private Schnittstelle, die eine Verbindung zu FaceService aufrechterhält. Sie wird von Keyguard verwendet, um mit einer benutzerdefinierten Benutzeroberfläche auf die Gesichtserkennung zuzugreifen. Apps haben keinen Zugriff auf FaceManager und müssen stattdessen BiometricPrompt verwenden.

FaceService

Dies ist die Framework-Implementierung, die den Zugriff auf die Hardware für die Gesichtserkennung verwaltet. Es enthält grundlegende Statusautomaten für die Registrierung und Authentifizierung sowie verschiedene andere Hilfsprogramme (z. B. Enumeration). Aus Stabilitäts- und Sicherheitsgründen darf in diesem Prozess kein Anbietercode ausgeführt werden. Auf den gesamten Anbietercode wird über die Face 1.0 HIDL-Schnittstelle zugegriffen.

konfrontiert

Dies ist eine ausführbare Linux-Datei, die die von FaceService verwendete Face 1.0-HIDL-Schnittstelle implementiert. Es registriert sich als IBiometricsFace@1.0, damit FaceService es finden kann.

Implementierung

Face HIDL

Um das Face-HIDL zu implementieren, müssen Sie alle Methoden von IBiometricsFace.hal in einer anbieterspezifischen Bibliothek implementieren.

Fehlermeldungen

Fehlermeldungen werden über einen Callback gesendet und versetzen den Zustandsautomaten nach dem Senden wieder in den Leerlaufzustand. Die meisten Nachrichten haben einen entsprechenden String, der dem Nutzer angezeigt wird, um ihn über den Fehler zu informieren. Das ist aber nicht bei allen Fehlern der Fall. Weitere Informationen zu Fehlermeldungen finden Sie unter types.hal. Alle Fehlermeldungen stellen einen Endstatus dar. Das Framework geht also davon aus, dass der HAL nach dem Senden einer Fehlermeldung in den Leerlauf zurückkehrt.

Akquisitionsnachrichten

Akquisitionsnachrichten werden während der Registrierung oder Authentifizierung gesendet und sollen den Nutzer zu einer erfolgreichen Registrierung oder Authentifizierung führen. Jeder Ordinalzahl ist eine Nachricht aus der Datei FaceAuthenticationManager.java zugeordnet. Anbieterspezifische Meldungen können hinzugefügt werden, sofern die entsprechenden Hilfetexte angegeben werden. Akquisitionsnachrichten sind an sich keine Endzustände. Das HAL muss so viele davon senden, wie für die aktuelle Registrierung oder Authentifizierung erforderlich sind. Wenn eine Akquisitionsmeldung zu einem Endzustand führt, in dem kein Fortschritt erzielt werden kann, sollte das HAL auf die Akquisitionsmeldungen mit einer Fehlermeldung reagieren, z. B. wenn das Bild zu dunkel ist und zu dunkel bleibt, um Fortschritt zu erzielen. In diesem Fall ist es angemessen, UNABLE_TO_PROCESS zu senden, nachdem mehrere Versuche unternommen wurden, aber kein weiterer Fortschritt erzielt werden kann.

Hardware

Damit Geräte die Anforderungen an starke biometrische Verfahren für Android 10 erfüllen, muss die Hardware sicher sein, um die Integrität der Gesichtsdaten und den endgültigen Authentifizierungsvergleich zu gewährleisten. Das Android Compatibility Definition Document (CDD) beschreibt das erforderliche Sicherheitsniveau und die akzeptable Spoof Acceptance Rate (SAR). Für die sichere Verarbeitung und Erkennung ist eine vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) erforderlich. Außerdem ist sichere Kamerahardware erforderlich, um Injektionsangriffe auf die Gesichtsauthentifizierung zu verhindern. Die zugehörigen Speicherseiten für Bilddaten könnten beispielsweise privilegiert und als schreibgeschützt markiert sein, sodass nur die Kamerahardware sie aktualisieren kann. Im Idealfall sollte kein Prozess außer TEE und der Hardware Zugriff haben.

Da die Hardware für die Gesichtserkennung sehr unterschiedlich ist, müssen je nach Gerätearchitektur hardwarespezifische Treiber entwickelt werden, um die Gesichtserkennung zu ermöglichen. Daher gibt es keine Referenzimplementierung für faced.

Methoden

Die folgenden Methoden sind alle asynchron und müssen sofort zum Framework zurückkehren. Andernfalls ist das System langsam und es kann zu Watchdog-Resets kommen. Es wird empfohlen, eine Message Queue mit mehreren Threads zu verwenden, um zu verhindern, dass der Aufrufer blockiert wird. Bei allen GET-Anfragen sollten Informationen nach Möglichkeit im Cache gespeichert werden, damit der Aufrufer nur minimal blockiert wird.

Methode	Beschreibung
`setCallback()`	Wird von `FaceService` aufgerufen, um alle Nachrichten an sich selbst weiterzuleiten.
`setActiveUser()`	Legt den aktiven Nutzer fest, auf den alle nachfolgenden HAL-Vorgänge angewendet werden. Die Authentifizierung erfolgt immer für diesen Nutzer, bis diese Methode noch einmal aufgerufen wird.
`revokeChallenge()`	Schließt die sichere Transaktion ab, indem die von `generateChallenge()` generierte Challenge ungültig gemacht wird.
`enroll()`	Registriert das Gesicht eines Nutzers.
`cancel()`	Bricht den aktuellen Vorgang ab (z. B. Registrieren, Authentifizieren, Entfernen oder Aufzählen) und versetzt `faced` in den Leerlauf.
`enumerate()`	Listet alle mit dem aktiven Nutzer verknüpften Gesichtsvorlagen auf.
`remove()`	Entfernt eine oder alle Gesichtsvorlagen, die mit dem aktiven Nutzer verknüpft sind.
`authenticate()`	Der aktive Nutzer wird authentifiziert.
`userActivity()`	Diese Methode sollte nur verwendet werden, wenn sich das HAL im Authentifizierungs- oder Standby-Status befindet. Wenn Sie diese Methode verwenden, während sich das HAL nicht in einem dieser Status befindet, wird `OPERATION_NOT_SUPPORTED` zurückgegeben. Wenn Sie diese Methode aufrufen, während die HAL bereits authentifiziert wird, kann sich die Zeit verlängern, die das System nach einem Gesicht sucht.
`resetLockout()`	Wenn zu viele Gesichter abgelehnt werden, muss `faced` in den Sperrzustand (`LOCKOUT` oder `LOCKOUT_PERMANENT`) eintreten. In diesem Fall muss die verbleibende Zeit an das Framework gesendet werden, damit sie dem Nutzer angezeigt werden kann. Wie bei `setFeature()` ist für diese Methode ein aktives Hardware-Authentifizierungstoken (HAT) erforderlich, um den internen Status sicher zurückzusetzen. Setzt die Sperrung nur für den aktuellen Nutzer zurück.

Die drei verbleibenden Methoden sind alle synchron und sollten nur so lange blockieren, wie unbedingt erforderlich, um ein Anhalten des Frameworks zu vermeiden.

Methode	Beschreibung
`generateChallenge()`	Generiert ein eindeutiges und kryptografisch sicheres zufälliges Token, das den Beginn einer sicheren Transaktion angibt.
`setFeature()`	Aktiviert oder deaktiviert eine Funktion für den aktuellen Nutzer. Aus Sicherheitsgründen ist dazu ein HAT erforderlich, um die PIN, das Muster oder das Passwort des Nutzers anhand der oben genannten Challenge zu prüfen.
`getFeature()`	Ruft den aktuellen Aktivierungsstatus der Funktion ab, wie durch die Standardeinstellung oder einen Aufruf von `setFeature()` oben festgelegt. Wenn die Gesichts-ID ungültig ist, muss die Implementierung `ILLEGAL_ARGUMENT` zurückgeben.
`getAuthenticatorId()`	Gibt eine ID zurück, die dem aktuellen Gesichtssatz zugeordnet ist. Diese Kennung muss sich ändern, wenn ein Gesicht hinzugefügt wird.

Zustandsdiagramm

Das Framework erwartet, dass faced dem folgenden Zustandsdiagramm entspricht.