Gesichtsauthentifizierung HIDL

Überblick

Mit der Gesichtsauthentifizierung können Benutzer ihr Gerät entsperren, indem sie einfach auf die Vorderseite des Geräts schauen. Android 10 bietet Unterstützung für einen neuen Gesichtsauthentifizierungsstapel, der Kamerabilder sicher verarbeiten kann und so Sicherheit und Datenschutz bei der Gesichtsauthentifizierung auf unterstützter Hardware gewährleistet. Android 10 bietet außerdem eine einfache Möglichkeit für sicherheitskonforme Implementierungen, um die Anwendungsintegration für Transaktionen wie Online-Banking oder andere Dienste zu ermöglichen.

Der Android-Gesichtsauthentifizierungsstapel ist eine neue Implementierung in Android 10. Die neue Implementierung führt die Schnittstellen IBiometricsFace.hal , IBiometricsFaceClientCallback.hal types.hal ein.

Die Architektur

Die BiometricPrompt-API umfasst die gesamte biometrische Authentifizierung, einschließlich Gesicht, Finger und Iris. Der Face HAL interagiert mit den folgenden Komponenten.

FaceManager

FaceManager ist eine private Schnittstelle, die eine Verbindung mit FaceService aufrechterhält. Es wird von Keyguard verwendet, um über eine benutzerdefinierte Benutzeroberfläche auf die Gesichtsauthentifizierung zuzugreifen. Apps haben keinen Zugriff auf FaceManager und müssen stattdessen BiometricPrompt verwenden.

FaceService

Dies ist die Framework-Implementierung, die den Zugriff auf die Gesichtsauthentifizierungshardware verwaltet. Es enthält grundlegende Registrierungs- und Authentifizierungszustandsmaschinen sowie verschiedene andere Hilfsfunktionen (z. B. Aufzählung). Aus Stabilitäts- und Sicherheitsgründen darf in diesem Prozess kein Herstellercode ausgeführt werden. Der Zugriff auf den gesamten Anbietercode erfolgt über die Face 1.0 HIDL-Schnittstelle .

konfrontiert

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

Implementierung

Gesicht HIDL

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

Fehlermeldungen

Fehlermeldungen werden durch einen Rückruf gesendet und bringen die Zustandsmaschine nach dem Senden in den Ruhezustand zurück. Die meisten Nachrichten verfügen über eine entsprechende benutzerseitige Zeichenfolge, um den Benutzer über den Fehler zu informieren, aber nicht alle Fehler verfügen über diese benutzerseitige Zeichenfolge. Weitere Informationen zu Fehlermeldungen finden Sie unter types.hal . Alle Fehlermeldungen stellen einen Endzustand dar, d. h. das Framework geht davon aus, dass die HAL nach dem Senden einer Fehlermeldung in einen Ruhezustand zurückkehrt.

Akquisitionsnachrichten

Erfassungsnachrichten werden während der Registrierung oder Authentifizierung übermittelt und sollen den Benutzer zu einer erfolgreichen Registrierung oder Authentifizierung führen. Jeder Ordnungszahl ist eine Nachricht aus der Datei FaceAuthenticationManager.java zugeordnet. Anbieterspezifische Meldungen können hinzugefügt werden, sofern die entsprechenden Hilfezeichenfolgen bereitgestellt werden. Akquisitionsnachrichten sind an und für sich keine Endzustände; Von der HAL wird erwartet, dass sie so viele davon sendet, wie nötig 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 der HAL den Erfassungsmeldungen eine Fehlermeldung folgen lassen, z. B. wenn das Bild zu dunkel ist und zu dunkel bleibt, als dass Fortschritte erzielt werden könnten. In diesem Fall ist es sinnvoll, UNABLE_TO_PROCESS zu senden, nachdem mehrere Versuche unternommen wurden, aber kein weiterer Fortschritt erzielt werden konnte.

Hardware

Damit Geräte die strengen biometrischen Anforderungen für Android 10 erfüllen, müssen sie über sichere Hardware verfügen, um die Integrität der Gesichtsdaten und den ultimativen Authentifizierungsvergleich sicherzustellen. Das Android Compatibility Definition Document (CDD) beschreibt das erforderliche Sicherheitsniveau und die erforderliche akzeptable Spoof-Akzeptanzrate (SAR). Für eine sichere Verarbeitung und Erkennung ist eine vertrauenswürdige Ausführungsumgebung (TEE) erforderlich. Darüber hinaus ist sichere Kamerahardware erforderlich, um Injektionsangriffe auf die Gesichtsauthentifizierung zu verhindern. Beispielsweise könnten die zugehörigen Speicherseiten für Bilddaten privilegiert und als schreibgeschützt markiert werden, sodass nur die Kamera-Hardware sie aktualisieren kann. Im Idealfall sollte außer TEE und der Hardware kein Prozess Zugriff haben.

Da die Hardware zur Gesichtsauthentifizierung erheblich variiert, ist es erforderlich, je nach Gerätearchitektur hardwarespezifische Treiber zu entwickeln, um die Gesichtsauthentifizierung 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 führt dies zu einem langsamen System und möglichen Watchdog-Resets. Es wird empfohlen, eine Nachrichtenwarteschlange mit mehreren Threads zu haben, um eine Blockierung des Anrufers zu vermeiden. Alle GET-Anfragen sollten Informationen nach Möglichkeit zwischenspeichern, damit der Anrufer für einen minimalen Zeitraum blockiert wird.

Methode	Beschreibung
setCallback()	Wird von FaceService aufgerufen, um alle Nachrichten auf sich selbst zurückzuführen.
setActiveUser()	Legt den aktiven Benutzer fest, auf den alle nachfolgenden HAL-Vorgänge angewendet werden. Die Authentifizierung erfolgt immer für diesen Benutzer, bis diese Methode erneut aufgerufen wird.
revokeChallenge()	Beendet die sichere Transaktion, indem die von generateChallenge() generierte Herausforderung ungültig gemacht wird.
enroll()	Registriert das Gesicht eines Benutzers.
cancel()	Bricht den aktuellen Vorgang ab (z. B. Registrieren, Authentifizieren, Entfernen oder Aufzählen) und kehrt in den faced zurück.
enumerate()	Listet alle Gesichtsvorlagen auf, die dem aktiven Benutzer zugeordnet sind.
remove()	Entfernt eine Gesichtsvorlage oder alle Gesichtsvorlagen, die dem aktiven Benutzer zugeordnet sind.
authenticate()	Authentifiziert den aktiven Benutzer.
userActivity()	Diese Methode sollte nur verwendet werden, wenn sich die HAL im Authentifizierungs- oder Standby-Zustand befindet. Die Verwendung dieser Methode, wenn sich die HAL nicht in einem dieser Zustände befindet, gibt OPERATION_NOT_SUPPORTED zurück. Das Aufrufen dieser Methode, während die HAL bereits eine Authentifizierung durchführt, kann die Zeitspanne 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. Wenn dies der Fall ist, muss die verbleibende Zeit an das Framework gesendet werden, damit es sie dem Benutzer anzeigen kann. Wie bei setFeature() erfordert diese Methode ein aktives Hardware-Authentifizierungstoken (HAT), um den internen Status sicher zurückzusetzen. Setzt die Sperre nur für den aktuellen Benutzer zurück.

Die drei verbleibenden Methoden sind alle synchron und sollten für die minimale Zeitspanne blockieren, um ein Abwürgen des Frameworks zu vermeiden.

Methode	Beschreibung
generateChallenge()	Erzeugt ein einzigartiges und kryptografisch sicheres Zufallstoken, das den Beginn einer sicheren Transaktion anzeigt.
setFeature()	Aktiviert oder deaktiviert eine Funktion für den aktuellen Benutzer. Aus Sicherheitsgründen erfordert dies, dass ein HAT die PIN/das Muster/das Passwort des Benutzers mit der oben genannten Herausforderung vergleicht
getFeature()	Ruft den aktuellen Aktivierungsstatus der Funktion ab, wie durch die Standardeinstellung oder einen Aufruf von setFeature() oben vorgegeben. Wenn die Gesichts-ID ungültig ist, muss die Implementierung ILLEGAL_ARGUMENT zurückgeben
getAuthenticatorId()	Gibt einen Bezeichner zurück, der dem aktuellen Flächensatz zugeordnet ist. Diese Kennung muss sich jedes Mal ändern, wenn ein Gesicht hinzugefügt wird

Zustandsdiagramm

Das Framework erwartet, faced dem folgenden Zustandsdiagramm folgt.