Biometrische Verfahren sind eine bequemere, aber möglicherweise weniger sichere Methode, um Ihre Identität mit einem Gerät zu bestätigen. Im mehrstufigen Authentifizierungsmodell bietet die primäre Authentifizierung (d. h. wissensbasierte Methoden wie PIN, Muster und Passwort) das höchste Sicherheitsniveau. Biometrische Verfahren gehören zur sekundären Authentifizierungsebene und bieten ein ausgewogenes Verhältnis zwischen Komfort und Sicherheit. Im Android-CDD werden drei Klassen für die biometrische Stärke definiert: Klasse 3 (früher „Stark“), Klasse 2 (früher „Schwach“) und Klasse 1 (früher „Nutzerfreundlichkeit“). Für jede Klasse gelten bestimmte Voraussetzungen, Berechtigungen und Einschränkungen. Weitere Informationen finden Sie im CDD oben. Alle drei Klassen dürfen in den Sperrbildschirm eingebunden werden, aber nur starke und schwache Authentifikatoren dürfen in die android.hardware.biometrics-APIs eingebunden werden. In dieser Tabelle werden die einzelnen Authentifikatoren und die von ihnen unterstützten Funktionen beschrieben.
| Authenticator | Sperrbildschirm | BiometricPrompt-Integration | Schlüsselspeicher (zeitbasierter Schlüssel) | Schlüsselspeicher (vorgangsbasierter Schlüssel) |
|---|---|---|---|---|
| BIOMETRIC_STRONG (Klasse 3) | Ja | Ja | Ja | Ja |
| BIOMETRIC_WEAK (Klasse 2) | Ja | Ja | Nein | Nein |
| BIOMETRIC_CONVENIENCE (Klasse 1) |
Ja | Nein | Nein | Nein |
| DEVICE_CREDENTIAL | Ja | Ja | Ja | Ja |
Das Android-Framework unterstützt die biometrische Authentifizierung per Gesicht und Fingerabdruck. Android kann angepasst werden, um andere biometrische Verfahren (z. B. Iriserkennung) zu unterstützen. Die biometrische Integration hängt jedoch von der biometrischen Sicherheit und nicht von der Modalität ab. Weitere Informationen zu biometrischen Sicherheitsanforderungen finden Sie unter Sicherheit des biometrischen Entsperrens messen.
Quelle
Android 12
- Die API BiometricManager.Strings wird eingeführt. Sie bietet lokalisierte Strings für Apps, die BiometricPrompt zur Authentifizierung verwenden. Diese Strings sind für Geräte vorgesehen und geben genauere Informationen dazu, welche Authentifizierungstypen verwendet werden können.
- Unterstützung für den Fingerabdrucksensor unter dem Display.
Android 11
- Das BiometricManager.Authenticators-Interface wird eingeführt. Es enthält Konstanten, mit denen Entwickler die von ihren Apps akzeptierten Authentifizierungstypen angeben können.
- Fügt die
ACTION_BIOMETRIC_ENROLLIntent-Aktion hinzu, mit der Entwickler Nutzer auffordern können, eine Authentifizierungsmethode zu registrieren, die den Anforderungen ihrer Apps entspricht. - Fügt die
AuthenticationResult#getAuthenticationType()-Methode hinzu, mit der Entwickler prüfen können, ob sich der Nutzer mit biometrischen Anmeldedaten oder Geräteanmeldedaten authentifiziert hat. - Bietet zusätzliche Unterstützung für Auth-per-Use-Schlüssel in der BiometricPrompt-Klasse.
Android 10
- Führt die
BiometricManagerKlasse ein, mit der Entwickler die Verfügbarkeit der biometrischen Authentifizierung abfragen können. - Enthält die Integration der Fingerabdruck- und Gesichtserkennung für
BiometricPrompt
Android 9
- Enthält die Fingerabdruckintegration nur für
BiometricPrompt. - Die Klasse „FingerprintManager“ wird eingestellt. Wenn Ihre gebündelten Apps und System-Apps diese Klasse verwenden, aktualisieren Sie sie, sodass stattdessen
BiometricPromptundBiometricManagerverwendet werden. - Die
FingerprintManager-CTS-Verifier-Tests wurden aktualisiert, umBiometricPromptmitBiometricPromptBoundKeysTestzu testen.
Implementierung
Damit Nutzer und Entwickler biometrische Daten nahtlos nutzen können, müssen Sie Ihren biometrischen Stack in die APIs BiometricPrompt, BiometricManager und ACTION_BIOMETRIC_ENROLL einbinden. Geräte mit biometrischen Sensoren müssen diese Anforderungen an die Stärke erfüllen.Außerdem müssen alle Implementierungen das CTS-Modul „CtsBiometricsTestCases“ bestehen.
So integrieren Sie Ihren biometrischen Stack in die ACTION_BIOMETRIC_ENROLL API:
- Ändern Sie die BiometricEnrollActivity, um den Registrierungsvorgang zu präsentieren. Ihr biometrischer Faktor kann nur präsentiert werden, wenn er die erforderliche Stärke erfüllt. Wenn Ihr Gerät mehrere unterstützt, sollte durch diese Aktion eine Liste angezeigt werden, aus der der Nutzer auswählen kann.
HAL-Implementierungsrichtlinien
Befolgen Sie diese Richtlinien für den biometrischen HAL, um sicherzustellen, dass biometrische Daten nicht weitergegeben und entfernt werden, wenn ein Nutzer von einem Gerät entfernt wird:
- Stellen Sie sicher, dass rohe biometrische Daten oder Derivate (z. B. Vorlagen) niemals von außerhalb der sicheren isolierten Umgebung (z. B. TEE oder Secure Element) zugänglich sind. Alle gespeicherten Daten müssen mit einem gerätespezifischen Schlüssel verschlüsselt werden, der nur der vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) bekannt ist. Wenn die Hardware dies unterstützt, beschränken Sie den Hardwarezugriff auf die sichere, isolierte Umgebung und schützen Sie ihn mit einer SELinux-Richtlinie. Machen Sie den Kommunikationskanal (z. B. SPI, I2C) nur für die sichere isolierte Umgebung mit einer expliziten SELinux-Richtlinie für alle Gerätedateien zugänglich.
- Die biometrische Erfassung, Registrierung und Erkennung muss in der sicheren isolierten Umgebung erfolgen, um Datenpannen und andere Angriffe zu verhindern. Diese Anforderung gilt nur für biometrische Verfahren der Klasse 3 (früher „Stark“) und Klasse 2 (früher „Schwach“).
- Um Replay-Angriffe zu verhindern, sollten Sie biometrische Vorlagen mit einem privaten, gerätespezifischen Schlüssel signieren. Für den Advanced Encryption Standard (AES) muss mindestens eine Vorlage mit dem absoluten Dateisystempfad, der Gruppe und der biometrischen ID signiert werden, damit Vorlagendateien auf einem anderen Gerät oder für andere Personen als den Nutzer, der sie auf demselben Gerät registriert hat, nicht verwendet werden können. So soll beispielsweise verhindert werden, dass biometrische Daten eines anderen Nutzers desselben Geräts oder von einem anderen Gerät kopiert werden.
- Wenn Sie Daten außerhalb der TEE speichern müssen, verwenden Sie den vom
setActiveUser() HIDL methodbereitgestellten Dateisystempfad oder geben Sie eine andere Möglichkeit an, alle Nutzer-Vorlagendaten zu löschen, wenn der Nutzer entfernt wird. Das soll verhindern, dass Nutzerdaten offengelegt werden. Geräte, die diesen Pfad nicht verwenden, müssen nach dem Entfernen des Nutzers bereinigt werden. Gemäß CDD müssen biometrische Daten und abgeleitete Dateien verschlüsselt gespeichert werden, insbesondere wenn sie nicht in der TEE gespeichert werden. Wenn dies aufgrund der Speicheranforderungen der sicheren isolierten Umgebung nicht möglich ist, fügen Sie Hooks hinzu, um sicherzustellen, dass die Daten entfernt werden, wenn der Nutzer entfernt oder das Gerät zurückgesetzt wird. Weitere Informationen finden Sie unter LockSettingsService.removeBiometricsForUser().
Personalisierung
Wenn Ihr Gerät mehrere biometrische Verfahren unterstützt, sollte der Nutzer in den Einstellungen ein Standardverfahren festlegen können. Bei Ihrer BiometricPrompt-Implementierung sollte die biometrische Methode der Klasse 3 (früher „Stark“) als Standard verwendet werden, sofern der Nutzer sie nicht explizit überschreibt. In diesem Fall muss eine Warnmeldung angezeigt werden, in der die Risiken der biometrischen Methode erläutert werden (z. B. Ein Foto von Ihnen kann Ihr Gerät entsperren).
Gerätespezifische Authentifizierungsstrings
Ab Android 12 sind kontextbezogene Authentifizierungs-Strings für Entwickler über die BiometricManager.Strings API verfügbar. Sie können die von dieser API zurückgegebenen Ressourcenwerte anpassen, um gerätespezifische Strings zu implementieren. Wenn Sie dies tun, müssen Sie dafür sorgen, dass alle neuen Strings für alle vom Gerät unterstützten Sprachen übersetzt werden. Achten Sie außerdem darauf, dass die folgenden Eigenschaften beibehalten werden:
Methode |
String purpose |
Einzuschließende Authentifizierungstypen |
Wenn sowohl biometrische Verfahren als auch die Displaysperre möglich sind |
|---|---|---|---|
getButtonLabel() |
Label für eine Schaltfläche, die BiometricPrompt auslöst |
Nur registrierte Typen (falls möglich), die die Anforderungen an Authentifikatoren erfüllen |
Verwende den String biometric-only (z. B. „Fingerabdruck verwenden“). |
getPromptMessage() |
Meldung, die bei der Authentifizierung in BiometricPrompt angezeigt wird |
Nur registrierte Typen (falls möglich), die die Anforderungen an Authentifikatoren erfüllen |
Kombinierte biometrische und Displaysperren-String verwenden (z.B. „Verwenden Sie Ihren Fingerabdruck oder Ihre PIN, um fortzufahren“) |
getSettingName() |
Name einer Einstellung, die BiometricPrompt für die Authentifizierung aktiviert |
Alle Typen, die vom Gerät unterstützt werden (auch wenn sie nicht registriert sind) und die Authentifikatoranforderungen erfüllen |
Kombinierte biometrische und Displaysperren-Formulierung verwenden (z. B. „Fingerabdruck oder Displaysperre verwenden“) |
Nehmen wir als Beispiel ein Gerät mit einem Gesichtssensor der Klasse 2 mit einem registrierten Gesicht, einer registrierten PIN und einem Fingerabdrucksensor der Klasse 3 ohne registrierte Fingerabdrücke. In der folgenden Tabelle finden Sie Beispielstrings für jede Kombination aus zulässigen Authentifikatoren und der aufgerufenen Methode BiometricManager.Strings:
Zulässige Authentifikatoren |
getButtonLabel() |
getPromptMessage() |
getSettingName() |
|---|---|---|---|
Biometrische Sicherheitsfunktionen der Klasse 3 (BIOMETRIC_STRONG) |
„Fingerabdruck verwenden“ (Nur der Fingerabdruck erfüllt die Anforderungen an die Authentifizierung.) |
„Mit Ihrem Fingerabdruck fortfahren“ (Nur Fingerabdruck erfüllt die Anforderungen an den Authentifikator) |
„Fingerabdruck verwenden“ (Nur der Fingerabdruck erfüllt die Anforderungen an die Authentifizierung.) |
Biometrische Methode der Klasse 2 (BIOMETRIC_WEAK) |
„Gesicht verwenden“ (Gesicht und Fingerabdruck erfüllen die Anforderungen; nur Gesicht ist registriert) |
„Mit Ihrem Gesicht fortfahren“ (Gesicht und Fingerabdruck erfüllen die Anforderungen; nur Gesicht ist registriert) |
„Gesichtserkennung oder Fingerabdruck verwenden“ (Gesichtserkennung und Fingerabdruck erfüllen die Anforderungen; das Gerät unterstützt beides) |
Displaysperre (DEVICE_CREDENTIAL) |
„PIN verwenden“ (Alle Displaysperren erfüllen die Anforderungen; PIN ist registriert) |
„Geben Sie Ihre PIN ein, um fortzufahren“ (Jede Displaysperre erfüllt die Anforderungen; PIN ist registriert) |
„Displaysperre verwenden“ (Jede Displaysperre erfüllt die Anforderungen) |
Biometrisches Verfahren der Klasse 3 ODER Displaysperre |
„PIN verwenden“ (Fingerabdruck und jede Displaysperre erfüllen die Anforderungen; nur PIN ist registriert) |
„Geben Sie Ihre PIN ein, um fortzufahren“ (Fingerabdruck und Displaysperre erfüllen die Anforderungen; nur PIN ist registriert) |
„Fingerabdruck oder Displaysperre verwenden“ (Fingerabdruck und jede Displaysperre erfüllen die Anforderungen) |
Biometrisches Verfahren der Klasse 2 ODER Displaysperre |
„Gesicht verwenden“ (Gesicht, Fingerabdruck und Displaysperre erfüllen die Anforderungen; Gesicht ist registriert und ersetzt die PIN) |
„Verwende dein Gesicht oder deine PIN, um fortzufahren“ (Gesicht, Fingerabdruck und jede Displaysperre erfüllen die Anforderungen; Gesicht und PIN sind registriert) |
„Biometrisches Verfahren oder Displaysperre verwenden“ (Gesichtserkennung, Fingerabdruck und jede Displaysperre erfüllen die Anforderungen) |
Zertifizierungsstufe
Ihre biometrische Implementierung muss die folgenden Tests bestehen:
- CTS BiometricManager
- CTS BiometricPrompt (Sanity-Test, ausführliche Tests hängen vom Prüfer ab)
- Abschnitt „CtsVerifier Biometric Test“ : Muss für jede vom Gerät unterstützte biometrische Methode einzeln bestanden werden.
Wenn Ihr Gerät außerdem ein biometrisches Verfahren unterstützt, das ein AOSP-HIDL hat (fingerprint@2.1, fingerprint@2.2, face1.0), muss es den entsprechenden VTS-Test (fingerprint, face) bestehen.