Biometrische Verfahren bieten eine praktischere, aber potenziell weniger sichere Möglichkeit, Ihre Identität mit einem Gerät zu bestätigen. Beim mehrstufigen Authentifizierungsmodell bietet die primäre Authentifizierung (d. h. wissensfaktorbasierte Modalitäten wie PIN, Muster und Passwort) das höchste Sicherheitsniveau. Biometrische Verfahren gehören zur sekundären Authentifizierungsebene und bieten eine gute Balance zwischen Komfort und Sicherheit. Die Android-Kompatibilitätsdefinition definiert drei Klassen der biometrischen Sicherheit: Klasse 3 (früher „Sehr hoch“), Klasse 2 (früher „Niedrig“) und Klasse 1 (früher „Nutzerfreundlichkeit“). Für jede Klasse gelten bestimmte Voraussetzungen, Berechtigungen und Einschränkungen. Weitere Informationen finden Sie in der oben verlinkten Datenschutzerklärung für Entwickler. Alle drei Klassen dürfen in den Sperrbildschirm eingebunden werden, aber nur starke und schwache Authentifikatoren dürfen in die APIs von android.hardware.biometrics eingebunden werden. In dieser Tabelle werden die einzelnen Authenticator und die von ihnen unterstützten Funktionen beschrieben.
| Authenticator | Sperrbildschirm | BiometricPrompt-Integration | Schlüsselspeicher (zeitabhängiger 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 Gesichts- und Fingerabdruckerkennung. Android kann so angepasst werden, dass andere biometrische Verfahren (z. B. Iriserkennung) unterstützt werden. Die biometrische Integration hängt jedoch von der biometrischen Sicherheit und nicht von der Modalität ab. Weitere Informationen zu den Spezifikationen für die biometrische Sicherheit finden Sie unter Sicherheit biometrischer Entsperrung messen.
Quelle
Android 12
- Einführung der BiometricManager.Strings API, die lokalisierte Strings für Apps bereitstellt, die BiometricPrompt für die Authentifizierung verwenden. Diese Strings sind gerätespezifisch und geben genauer an, welche Authentifizierungstypen verwendet werden können.
- Unterstützt Fingerabdrucksensoren unter dem Display.
Android 11
- Die BiometricManager.Authenticators-Schnittstelle wurde eingeführt. Sie bietet Konstanten, mit denen Entwickler die Authentifizierungstypen angeben können, die von ihren Apps akzeptiert werden.
- Die
ACTION_BIOMETRIC_ENROLL-Intent-Aktion wurde hinzugefügt. Mit dieser können Entwickler Nutzer auffordern, eine Authentifizierungsmethode zu registrieren, die den Anforderungen ihrer Apps entspricht. - Die Methode
AuthenticationResult#getAuthenticationType()method wird hinzugefügt. Mit dieser können Entwickler prüfen, ob sich der Nutzer mit einem biometrischen oder einem Geräte-Anmeldedatensatz authentifiziert hat. - Bietet zusätzliche Unterstützung für Authentifizierung pro Nutzung-Schlüssel in der Klasse „BiometricPrompt“.
Android 10
- Die
BiometricManagerKlasse wird eingeführt, mit der Entwickler die Verfügbarkeit der biometrischen Authentifizierung abfragen können. - Beinhaltet die Einbindung der Fingerabdruck- und Gesichtsauthentifizierung für
BiometricPrompt
Android 9
- Umfasst nur die Fingerabdruckintegration für
BiometricPrompt. - Die Klasse „FingerprintManager“ wird eingestellt. Wenn Ihre gebündelten 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 die biometrischen Funktionen reibungslos nutzen können, sollten Sie Ihren biometrischen Stack in die BiometricPrompt-, BiometricManager- und ACTION_BIOMETRIC_ENROLL-APIs einbinden. Geräte mit biometrischen Sensoren müssen diese Anforderungen an die Sicherheit 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 BiometricEnrollActivity, um den Registrierungsvorgang anzuzeigen. Hinweis: Ihr biometrisches Merkmal kann nur dann verwendet werden, wenn es die erforderliche Stärke aufweist. Wenn Ihr Gerät mehrere unterstützt, sollte durch diese Aktion eine Liste angezeigt werden, aus der der Nutzer auswählen kann.
Richtlinien für die Implementierung von HAL
Befolgen Sie diese Richtlinien für biometrische HALs, damit biometrische Daten nicht gehackt und entfernt werden, wenn ein Nutzer von einem Gerät entfernt wird:
- Achten Sie darauf, dass rohe biometrische Daten oder Derivate (z. B. Vorlagen) niemals von außerhalb der sicheren, isolierten Umgebung (z. B. der TEE oder des Secure Elements) zugänglich sind. Alle gespeicherten Daten müssen mit einem gerätespezifischen Schlüssel verschlüsselt werden, der nur der TEE (Trusted Execution Environment) bekannt ist. Beschränken Sie den Hardwarezugriff auf die sichere, isolierte Umgebung, sofern die Hardware dies unterstützt, und schützen Sie sie mit einer SELinux-Richtlinie. Der Kommunikationskanal (z. B. SPI, I2C) darf nur für die sichere, isolierte Umgebung zugänglich sein. Verwenden Sie dazu eine explizite SELinux-Richtlinie für alle Gerätedateien.
- 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 „Sehr sicher“) und der Klasse 2 (früher „Weniger sicher“).
- Signieren Sie biometrische Vorlagen mit einem privaten, gerätespezifischen Schlüssel, um sie vor Replay-Angriffen zu schützen. Für den Advanced Encryption Standard (AES) müssen Sie eine Vorlage mindestens mit dem absoluten Pfad, der Gruppe und der biometrischen ID des Dateisystems signieren, damit Vorlagendateien auf einem anderen Gerät oder für andere Nutzer als denjenigen, der sie auf demselben Gerät registriert hat, nicht verwendet werden können. So ist es beispielsweise nicht möglich, biometrische Daten eines anderen Nutzers desselben Geräts oder von einem anderen Gerät zu kopieren.
- Wenn Sie Daten außerhalb des TEE speichern müssen, verwenden Sie den vom
setActiveUser() HIDL methodbereitgestellten Dateisystempfad oder sorgen Sie für eine andere Möglichkeit, alle Nutzer-Template-Daten zu löschen, wenn der Nutzer entfernt wird. Der Grund dafür ist der Schutz vor Datenlecks. Auf Geräten, auf denen dieser Pfad nicht verwendet wird, muss nach dem Entfernen des Nutzers eine Bereinigung erfolgen. Gemäß CDD müssen biometrische Daten und abgeleitete Dateien verschlüsselt gespeichert werden, insbesondere wenn sie nicht in einer 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 gelöscht wird. Siehe 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 standardmäßig das biometrische Verfahren der Klasse 3 (früher „Sehr hoch“) verwendet werden, es sei denn, der Nutzer überschreibt es ausdrücklich. In diesem Fall muss eine Warnmeldung mit den mit dem biometrischen Verfahren verbundenen Risiken angezeigt werden (z. B. Ein Foto von Ihnen kann Ihr Gerät entsperren).
Gerätespezifische Authentifizierungsstrings
Ab Android 12 stehen Entwicklern über die BiometricManager.Strings API Strings für die kontextbezogene Authentifizierung zur Verfügung. Sie können die von dieser API zurückgegebenen Ressourcenwerte anpassen, um gerätespezifische Strings zu implementieren. Achten Sie in diesem Fall darauf, dass alle neuen Strings für alle Sprachen übersetzt werden, die das Gerät unterstützt. Außerdem müssen die folgenden Eigenschaften beibehalten werden:
Methode |
Zweck des Strings |
Einzuschließende Authentifizierungstypen |
Ob biometrische Verfahren und Displaysperre möglich sind |
|---|---|---|---|
getButtonLabel() |
Label für eine Schaltfläche, die BiometricPrompt auslöst |
Nur (falls möglich) registrierte Typen, die die Anforderungen an den Authenticator erfüllen |
Nur biometrischen String verwenden (z. B. „Fingerabdruck verwenden“) |
getPromptMessage() |
Nachricht, die bei der Authentifizierung in BiometricPrompt angezeigt wird |
Nur (falls möglich) registrierte Typen, die die Anforderungen an den Authenticator erfüllen |
Verwenden Sie einen kombinierten String für biometrische Verfahren und Displaysperre (z.B. „Verwenden Sie Ihren Fingerabdruck oder Ihre PIN, um fortzufahren“) |
getSettingName() |
Name einer Einstellung, mit der BiometricPrompt für die Authentifizierung aktiviert wird |
Alle vom Gerät unterstützten Typen (auch wenn nicht registriert), die die Anforderungen an den Authenticator erfüllen |
Verwenden Sie einen kombinierten String für biometrische Verfahren und Displaysperre (z. B. „Fingerabdruck oder Displaysperre verwenden“). |
Angenommen, ein Gerät hat einen 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 Authenticatorn und aufgerufener BiometricManager.Strings-Methode:
Zulässige Authenticator |
getButtonLabel() |
getPromptMessage() |
getSettingName() |
|---|---|---|---|
Biometrische Authentifizierung der Klasse 3 (BIOMETRIC_STRONG) |
„Fingerabdruck verwenden“ (Nur der Fingerabdruck erfüllt die Anforderungen an den Authenticator) |
„Mit dem Fingerabdruck fortfahren“ (Nur der Fingerabdruck erfüllt die Anforderungen an den Authentifikator) |
„Fingerabdruck verwenden“ (Nur der Fingerabdruck erfüllt die Anforderungen an den Authenticator) |
Biometrische Authentifizierung der Klasse 2 (BIOMETRIC_WEAK) |
„Gesicht verwenden“ (Gesicht und Fingerabdruck erfüllen die Anforderungen; nur das Gesicht ist registriert) |
„Mit dem Gesicht fortfahren“ (Gesicht und Fingerabdruck erfüllen die Anforderungen; nur das Gesicht ist registriert) |
„Gesicht oder Fingerabdruck verwenden“ (Gesicht und Fingerabdruck erfüllen die Anforderungen; Gerät unterstützt beide) |
Displaysperre (DEVICE_CREDENTIAL) |
„PIN verwenden“ (Jede Displaysperre erfüllt 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 Displaysperre erfüllen die Anforderungen; nur PIN registriert) |
„Geben Sie Ihre PIN ein, um fortzufahren“ (Fingerabdruck und jede Displaysperre erfüllen die Anforderungen; nur PIN registriert) |
„Fingerabdruck oder Displaysperre verwenden“ (Fingerabdruck und jede Displaysperre erfüllen die Anforderungen) |
Biometrisches Entsperren der Klasse 2 ODER Displaysperre |
„Gesicht verwenden“ (Gesicht, Fingerabdruck und jede Displaysperre erfüllen die Anforderungen; Gesicht ist registriert und ersetzt die PIN) |
„Gesicht oder PIN verwenden, um fortzufahren“ (Gesicht, Fingerabdruck und jede Displaysperre erfüllen die Anforderungen; Gesicht und PIN sind registriert) |
„Biometrisches Verfahren oder Displaysperre verwenden“ (Gesicht, Fingerabdruck und jede Displaysperre erfüllen die Anforderungen) |
Zertifizierungsstufe
Ihre biometrische Implementierung muss die folgenden Tests bestehen:
- CTS BiometricManager
- CTS BiometricPrompt (Stichprobentest, ausführliche Tests erfordern einen Verifier)
- Abschnitt zum biometrischen Test von CtsVerifier: muss für jede Modalität, die das Gerät unterstützt, einzeln bestanden werden
Wenn Ihr Gerät außerdem ein biometrisches Verfahren mit einer AOSP-HIDL (fingerprint@2.1, fingerprint@2.2, face1.0) unterstützt, muss es den entsprechenden VTS-Test (fingerprint, face) bestehen.