Ab 2026 werden wir, um unser stabiles Entwicklungsmodell für den Trunk zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten, den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen. Verwenden Sie android-latest-release, um AOSP zu entwickeln und dazu beizutragen. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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. Android 10 bietet Unterstützung für einen neuen Gesichtserkennungs-Stack, mit dem Kamerabilder sicher verarbeitet werden können. So werden Sicherheit und Datenschutz bei der Gesichtserkennung auf unterstützter Hardware gewahrt. 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-Gesichtserkennungs-Stack ist eine neue Implementierung in Android 10. Die neue Implementierung führt die Schnittstellen IBiometricsFace.hal, IBiometricsFaceClientCallback.hal, und types.hal ein.

Architektur

Die BiometricPrompt API umfasst alle biometrischen Authentifizierungsmethoden, einschließlich Gesichtserkennung, Fingerabdruckerkennung und Iriserkennung. Die 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 UI 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 Gesichtserkennungshardware verwaltet. Sie enthält grundlegende Zustandsautomaten 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. Der gesamte Anbietercode wird über die Face 1.0 HIDL-Schnittstelle aufgerufen.

faced

Dies ist eine ausführbare Linux-Datei, die die Face 1.0 HIDL-Schnittstelle implementiert, die von FaceService verwendet wird. Sie registriert sich als IBiometricsFace@1.0, damit FaceService sie finden kann.

Implementierung

Face HIDL

Um die 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 setzen den Zustandsautomaten nach dem Senden in den Leerlaufzustand zurück. Die meisten Nachrichten haben einen entsprechenden für Nutzer sichtbaren String, um den Nutzer über den Fehler zu informieren. Allerdings haben nicht alle Fehler diesen String. Weitere Informationen zu Fehlermeldungen finden Sie unter types.hal. Alle Fehlermeldungen stellen einen Endzustand dar. Das Framework geht davon aus, dass die HAL nach dem Senden einer Fehlermeldung in den Leerlaufzustand zurückkehrt.

Erfassungsmeldungen

Erfassungsmeldungen werden während der Registrierung oder Authentifizierung gesendet und sollen den Nutzer zu einer erfolgreichen Registrierung oder Authentifizierung führen. Jede Ordnungszahl hat eine zugehörige Meldung aus der FaceAuthenticationManager.java Datei. Anbieterspezifische Meldungen können hinzugefügt werden, sofern die entsprechenden Hilfestrings bereitgestellt werden. Erfassungsmeldungen sind keine Endzustände. Die HAL muss so viele davon senden, wie erforderlich sind, um die aktuelle Registrierung oder Authentifizierung abzuschließen. Wenn eine Erfassungsmeldung zu einem Endzustand führt, in dem kein Fortschritt erzielt werden kann, sollte die HAL auf die Erfassungsmeldungen mit einer Fehlermeldung folgen, z. B. wenn das Bild zu dunkel ist und zu dunkel bleibt, um Fortschritte zu erzielen. In diesem Fall ist es sinnvoll, nach mehreren Versuchen, bei denen kein weiterer Fortschritt erzielt werden konnte, UNABLE_TO_PROCESS zu senden.

Hardware

Damit Geräte die Anforderungen für starke biometrische Authentifizierung für Android 10 erfüllen, müssen sie über sichere Hardware verfügen, um die Integrität der Gesichtserkennungsdaten und den endgültigen Authentifizierungsvergleich zu gewährleisten. Im Android Compatibility Definition Document (CDD) wird die erforderliche Sicherheitsstufe und die akzeptable Spoof Acceptance Rate (SAR) beschrieben. 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 Injection-Angriffe auf die Gesichtserkennung zu verhindern. So könnten beispielsweise die zugehörigen Speicherseiten für Bilddaten privilegiert und als schreibgeschützt markiert werden, damit nur die Kamerahardware sie aktualisieren kann. Idealerweise sollte kein Prozess außer der TEE und der Hardware Zugriff haben.

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

Methoden

Alle folgenden Methoden sind asynchron und müssen sofort zum Framework zurückkehren. Andernfalls wird das System langsam und es kann zu Watchdog-Resets kommen. Es wird empfohlen, eine Nachrichtenwarteschlange 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 für eine minimale Zeit blockiert wird.

Methode	Beschreibung
`setCallback()`	Wird von `FaceService` aufgerufen, um alle Nachrichten an sich selbst zurückzuleiten.
`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 wieder aufgerufen wird.
`revokeChallenge()`	Beendet die sichere Transaktion, indem die von `generateChallenge()` generierte Challenge ungültig gemacht wird.
`enroll()`	Registriert das Gesicht eines Nutzers.
`cancel()`	Bricht den aktuellen Vorgang ab (z. B. Registrierung, Authentifizierung, Entfernung oder Enumeration) und setzt `faced` in den Leerlaufzustand zurück.
`enumerate()`	Listet alle Gesichtsvorlagen auf, die mit dem aktiven Nutzer verknüpft sind.
`remove()`	Entfernt eine Gesichtsvorlage oder alle Gesichtsvorlagen, die mit dem aktiven Nutzer verknüpft sind.
`authenticate()`	Authentifiziert den aktiven Nutzer.
`userActivity()`	Diese Methode sollte nur verwendet werden, wenn sich die HAL im Authentifizierungs- oder Standby-Zustand befindet. Wenn Sie diese Methode verwenden, wenn sich die HAL nicht in einem dieser Zustände 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, in der das System nach einem Gesicht sucht.
`resetLockout()`	Wenn zu viele Gesichter abgelehnt werden, muss `faced` in einen 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 (Hardware Authentication Token, HAT) erforderlich, um den internen Zustand sicher zurückzusetzen. Setzt die Sperrung nur für den aktuellen Nutzer zurück.

Die drei verbleibenden Methoden sind alle synchron und sollten nur für eine minimale Zeit blockieren, um zu verhindern, dass das Framework ins Stocken gerät.

Methode	Beschreibung
`generateChallenge()`	Generiert ein eindeutiges und kryptografisch sicheres Zufallstoken, das den Beginn einer sicheren Transaktion angibt.
`setFeature()`	Aktiviert oder deaktiviert eine Funktion für den aktuellen Nutzer. Aus Sicherheitsgründen ist hierfür ein HAT erforderlich, um die PIN, das Muster oder das Passwort des Nutzers mit der oben genannten Challenge zu vergleichen.
`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 mit dem aktuellen Gesichtssatz verknüpft ist. Diese ID muss sich ändern, wenn ein Gesicht hinzugefügt wird.

Zustandsdiagramm

Das Framework erwartet, dass faced dem folgenden Zustandsdiagramm folgt.