Diese Seite wurde von der Cloud Translation API übersetzt.

Gesichtserkennung (HIDL)

Übersicht

Mit der Gesichtserkennung können Nutzer ihr Gerät entsperren, indem sie einfach in die Kamera schauen. Android 10 unterstützt einen neuen Stack für die Gesichtserkennung, mit dem Kameraframes 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 ermöglichen.

Der Face Authentication-Stack für Android 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 Authentifizierungsmethoden, einschließlich Gesicht, Finger und Iris. Der Face HAL interagiert mit den folgenden Komponenten.

FaceManager

FaceManager ist eine private Schnittstelle, die eine Verbindung zu FaceService aufrechterhält. Es wird von Keyguard für den Zugriff auf die Gesichtserkennung über eine benutzerdefinierte UI verwendet. 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. Es enthält grundlegende Maschinen für die Registrierung und den Authentifizierungsstatus sowie verschiedene andere Hilfsfunktionen (z. B. Aufzählung). Aus Stabilitäts- und Sicherheitsgründen darf in diesem Prozess kein Anbietercode ausgeführt werden. Der Zugriff auf den gesamten Anbietercode erfolgt über die Face 1.0 HIDL-Schnittstelle.

gegenüber

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

Implementierung

Gesicht HIDL

Wenn Sie die Face HIDL implementieren möchten, müssen Sie alle Methoden von IBiometricsFace.hal in einer anbieterspezifischen Bibliothek implementieren.

Fehlermeldungen

Fehlermeldungen werden über einen Callback gesendet und setzen den Statusautomaten nach dem Senden wieder in den Status idle (Inaktiv). Die meisten Meldungen haben einen entsprechenden String, der den Nutzer über den Fehler informiert. Nicht alle Fehler haben jedoch diesen String. Weitere Informationen zu Fehlermeldungen finden Sie unter types.hal. Alle Fehlermeldungen stellen einen Endstatus dar. Das Framework geht davon aus, dass die HAL nach dem Senden einer Fehlermeldung in den Inaktivitätsstatus zurückkehrt.

Akquisitionsnachrichten

Akquisitionsnachrichten werden während der Registrierung oder Authentifizierung gesendet und sollen den Nutzer zu einer erfolgreichen Registrierung oder Authentifizierung führen. Jede Ordinalzahl ist mit einer Nachricht aus der Datei FaceAuthenticationManager.java verknüpft. Anbieterspezifische Nachrichten können hinzugefügt werden, sofern die entsprechenden Hilfetexte bereitgestellt werden. Akquisitionsnachrichten sind keine Terminalstatus an sich. Es wird erwartet, dass der HAL so viele dieser Nachrichten sendet, wie erforderlich, um die aktuelle Registrierung oder Authentifizierung abzuschließen. Wenn eine Akquisitionsnachricht in einen Endzustand führt, in dem kein Fortschritt möglich ist, sollte der HAL den Akquisitionsnachrichten mit einer Fehlermeldung folgen, z. B., dass das Bild zu dunkel und zu dunkel bleibt, um einen weiteren Vorgang auszuführen. In diesem Fall ist es sinnvoll, UNABLE_TO_PROCESS nach mehreren Versuchen zu senden, aber es ist kein weiterer Fortschritt möglich.

Hardware

Damit Geräte die Anforderungen an starke biometrische Authentifizierung für Android 10 erfüllen, müssen sie über sichere Hardware verfügen, um die Integrität der Gesichtsdaten und den endgültigen Authentifizierungsabgleich zu gewährleisten. Im Android Compatibility Definition Document (CDD) wird das erforderliche Sicherheitsniveau und die zulässige Rate für Spoofing-Akzeptanz (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 Gesichtsauthentifizierung zu verhindern. So könnten die zugehörigen Speicherseiten für Bilddaten beispielsweise privilegiert und schreibgeschützt sein, sodass nur die Kamerahardware sie aktualisieren kann. Idealerweise 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 an das Framework zurückgegeben werden. Andernfalls wird das System langsam und der Watchdog wird möglicherweise zurückgesetzt. Es wird empfohlen, eine Nachrichtenwarteschlange mit mehreren Threads zu verwenden, um den Aufrufer nicht zu blockieren. Alle GET-Anfragen sollten nach Möglichkeit Informationen im Cache speichern, damit der Aufrufer nur für kurze Zeit blockiert wird.

Method	Beschreibung
`setCallback()`	Wird von `FaceService` aufgerufen, um alle Nachrichten an sich selbst zu verteilen.
`setActiveUser()`	Hiermit wird der aktive Nutzer festgelegt, auf den alle nachfolgenden HAL-Vorgänge angewendet werden. Die Authentifizierung erfolgt immer für diesen Nutzer, bis diese Methode wieder aufgerufen wird.
`revokeChallenge()`	Schließt die sichere Transaktion ab, indem die von `generateChallenge()` generierte Bestätigung ungültig gemacht wird.
`enroll()`	Registriert das Gesicht eines Nutzers.
`cancel()`	Der aktuelle Vorgang (z. B. Registrieren, Authentifizieren, Entfernen oder Auflisten) wird abgebrochen und `faced` kehrt in den Inaktivitätsstatus zurück.
`enumerate()`	Listet alle Gesichtervorlagen auf, die dem aktiven Nutzer zugeordnet sind.
`remove()`	Entfernt eine Gesichtervorlage oder alle Gesichtervorlagen, die dem aktiven Nutzer zugeordnet sind.
`authenticate()`	Authentifiziert den aktiven Nutzer.
`userActivity()`	Diese Methode sollte nur verwendet werden, wenn sich der HAL im Authentifizierungs- oder Standby-Status befindet. Wenn Sie diese Methode verwenden, während sich die 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, in der das System nach einem Gesicht sucht.
`resetLockout()`	Wenn zu viele Gesichter abgelehnt werden, muss `faced` in einen Sperrstatus (`LOCKOUT` oder `LOCKOUT_PERMANENT`) versetzt werden. In diesem Fall muss die verbleibende Zeit an das Framework gesendet werden, damit es 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. Die Sperrung wird nur für den aktuellen Nutzer zurückgesetzt.

Die drei verbleibenden Methoden sind alle synchron und sollten für die minimalste Zeit blockieren, um das Framework nicht zu verlangsamen.

Method	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 muss ein HAT die PIN/das Muster/das Passwort des Nutzers anhand der oben genannten Herausforderung prüfen.
`getFeature()`	Ruft den aktuellen Aktivierungsstatus der Funktion ab, wie er durch die Standardeinstellung oder einen Aufruf von `setFeature()` oben festgelegt ist. Wenn die Gesichts-ID ungültig ist, muss die Implementierung `ILLEGAL_ARGUMENT` zurückgeben
`getAuthenticatorId()`	Gibt eine Kennung zurück, die mit dem aktuellen Gesichtersatz verknüpft ist. Diese Kennung muss sich ändern, wenn ein Gesicht hinzugefügt wird.

Zustandsdiagramm

Das Framework erwartet, dass faced dem folgenden Zustandsdiagramm folgt.