HIDL für die Gesichtserkennung

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht

Mit der Gesichtserkennung können Nutzer ihr Gerät entsperren, indem sie einfach in die Kamera schauen. Android 10 unterstützt einen neuen Stapel 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 Android-Stack für die Gesichtserkennung 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. Die Face HAL interagiert mit den folgenden Komponenten.

Abbildung 1: Biometrischer Stack

FaceManager

FaceManager ist eine private Schnittstelle, die eine Verbindung zu FaceService aufrechterhält. Er wird vom Sperrbildschirm verwendet, um über eine benutzerdefinierte 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 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 HIDL-Schnittstelle von Face 1.0.

konfrontiert

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

Face 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 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

Akquisitionsmitteilungen 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 Meldungen können hinzugefügt werden, sofern die entsprechenden Hilfetexte bereitgestellt werden. Akquisitionsnachrichten sind keine Endzustände an sich. Die HAL sendet voraussichtlich so viele davon, wie erforderlich sind, um die aktuelle Registrierung oder Authentifizierung abzuschließen. Wenn eine Aufnahmemeldung zu einem Endstatus führt, bei dem kein Fortschritt möglich ist, sollte die HAL nach den Aufnahmemeldungen eine Fehlermeldung senden, z. B. wenn das Bild zu dunkel ist und zu dunkel bleibt, um Fortschritte zu erzielen. 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 Anforderungen an die 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 zurückzugeben.
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()	Enthält alle Gesichts-Templates, die mit dem aktiven Nutzer verknüpft sind.
remove()	Entfernt eine 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-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 den Sperrstatus (LOCKOUT oder LOCKOUT_PERMANENT) wechseln. 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. 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 mit der oben genannten Herausforderung vergleichen.
getFeature()	Ruft den aktuellen Aktivierungsstatus der Funktion ab, wie er durch die Standardeinstellung oder einen Aufruf von setFeature() oben festgelegt ist. Wenn die Face 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.

Abbildung 2: Ablauf des Status der Gesichtserkennung