Biometrische Verfahren

Biometrie bietet eine bequemere, aber möglicherweise weniger sichere Möglichkeit, Ihre Identität mit einem Gerät zu bestätigen. Beim mehrstufigen Authentifizierungsmodell bietet die primäre Authentifizierung (also wissensfaktorbasierte Modalitäten wie PIN, Muster und Passwort) das höchste Maß an Sicherheit. Biometrie ist die sekundäre Ebene der Authentifizierung und bietet ein Gleichgewicht zwischen Komfort und Sicherheit. Das Android CDD definiert drei Klassen biometrischer Stärke: Klasse 3 (früher „Stark“), Klasse 2 (früher „Schwach“) und Klasse 1 (früher „Komfort“). Jede Klasse hat eine Reihe von Voraussetzungen, Berechtigungen und Einschränkungen – weitere Einzelheiten finden Sie im CDD oben. Alle drei Klassen dürfen mit Lockscreen integriert werden, aber nur starke und schwache Authentifikatoren dürfen mit den android.hardware.biometrischen APIs integriert werden. In dieser Tabelle werden die einzelnen Authentifikatoren und die von ihnen unterstützten Funktionen beschrieben.

Authentifikator	Sperrbildschirm	BiometricPrompt-Integration	Keystore (zeitbasierter Schlüssel)	Keystore (operationsbasierter Schlüssel)
BIOMETRIC_STRONG (Klasse 3)	Ja	Ja	Ja	Ja
BIOMETRIC_WEAK (Klasse 2)	Ja	Ja	NEIN	NEIN
BIOMETRISCHER_KOMFORT (Klasse 1)	Ja	NEIN	NEIN	NEIN
DEVICE_CREDENTIAL	Ja	Ja	Ja	Ja

Das Android-Framework unterstützt die biometrische Authentifizierung von Gesichtern und Fingerabdrücken. Android kann so angepasst werden, dass es andere biometrische Modalitäten unterstützt (z. B. Iris). Die biometrische Integration hängt jedoch von der biometrischen Sicherheit und nicht von der Modalität ab. Weitere Einzelheiten zu biometrischen Sicherheitsspezifikationen finden Sie unter Messen der biometrischen Entsperrsicherheit .

Quelle

Android 12

• Stellt die BiometricManager.Strings- API vor, die lokalisierte Zeichenfolgen für Apps bereitstellt, die BiometricPrompt zur Authentifizierung verwenden. Diese Zeichenfolgen sollen gerätespezifisch sein und genauere Informationen darüber liefern, welche Authentifizierungstypen verwendet werden können.
• Beinhaltet Unterstützung für den Fingerabdrucksensor unter dem Display (UDFPS).

Android 11

• Stellt die BiometricManager.Authenticators-Schnittstelle vor, die Konstanten bereitstellt, mit denen Entwickler die von ihren Apps akzeptierten Authentifizierungstypen angeben können.
• Fügt dieAbsichtsaktion ACTION_BIOMETRIC_ENROLL hinzu, mit der Entwickler den Benutzer anweisen können, eine Authentifizierungsmethode zu registrieren, die den Anforderungen ihrer Apps entspricht.
• Fügt die Methode AuthenticationResult #getAuthenticationType () hinzu, mit der Entwickler überprüfen können, ob sich der Benutzer mit biometrischen Anmeldeinformationen oder Geräteanmeldeinformationen authentifiziert hat.
• Bietet zusätzliche Unterstützung für Authentifizierungsschlüssel pro Verwendung innerhalb der BiometricPrompt-Klasse.

Android 10

• Stellt die BiometricManager Klasse vor, mit der Entwickler die Verfügbarkeit der biometrischen Authentifizierung abfragen können.
• Beinhaltet die Integration von Fingerabdruck- und Gesichtsauthentifizierung für BiometricPrompt

Android 9

• Beinhaltet nur die Fingerabdruckintegration für BiometricPrompt .
• Veraltet die FingerprintManager-Klasse. Wenn Ihre gebündelten Apps und System-Apps diese Klasse verwenden, aktualisieren Sie sie, um stattdessen BiometricPrompt und BiometricManager zu verwenden.
• Die FingerprintManager CTS-Verifizierungstests wurden aktualisiert, um BiometricPrompt mithilfe von BiometricPromptBoundKeysTest zu testen.

Implementierung

Um sicherzustellen, dass Benutzer und Entwickler ein nahtloses biometrisches Erlebnis haben, integrieren Sie Ihren biometrischen Stapel mit den APIs BiometricPrompt , BiometricManager und ACTION_BIOMETRIC_ENROLL . Geräte mit biometrischen Sensoren müssen diese Festigkeitsanforderungen erfüllen. Darüber hinaus müssen alle Implementierungen das CTS-Modul CtsBimetricsTestCases bestehen.

So integrieren Sie Ihren biometrischen Stapel mit der ACTION_BIOMETRIC_ENROLL API:

1. Ändern Sie die BiometricEnrollActivity , um Ihren Registrierungsablauf darzustellen. Beachten Sie, dass Ihre biometrischen Daten nur dann vorgelegt werden können, wenn sie der geforderten Stärke entsprechen. Wenn Ihr Gerät mehr als eine unterstützt, sollte diese Aktion eine Liste anzeigen, aus der der Benutzer auswählen kann.

Abbildung 1. BiometricPrompt-Architektur

HAL-Implementierungsrichtlinien

Befolgen Sie diese biometrischen HAL-Richtlinien, um sicherzustellen, dass biometrische Daten nicht verloren gehen und entfernt werden, wenn ein Benutzer 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 TEE (Trusted Execution Environment) bekannt ist. Wenn die Hardware dies unterstützt, beschränken Sie den Hardwarezugriff auf die sichere isolierte Umgebung und schützen Sie sie mit einer SELinux-Richtlinie. Machen Sie den Kommunikationskanal (z. B. SPI, I2C) mit einer expliziten SELinux-Richtlinie für alle Gerätedateien nur für die sichere isolierte Umgebung zugänglich.
• Die Erfassung, Registrierung und Erkennung biometrischer Daten muss in einer sicheren, isolierten Umgebung erfolgen, um Datenschutzverletzungen und andere Angriffe zu verhindern. Diese Anforderung gilt nur für biometrische Daten der Klassen 3 (vormals Stark) und 2 (vormals Schwach) .
• Um sich vor Replay-Angriffen zu schützen, signieren Sie biometrische Vorlagen mit einem privaten, gerätespezifischen Schlüssel. Signieren Sie für Advanced Encryption Standard (AES) mindestens eine Vorlage mit dem absoluten Dateisystempfad, der Gruppe und der biometrischen ID, sodass Vorlagendateien auf einem anderen Gerät oder für andere Personen als den Benutzer, der sie auf demselben Gerät registriert hat, nicht funktionsfähig sind . Verhindern Sie beispielsweise das Kopieren biometrischer Daten eines anderen Benutzers auf demselben Gerät oder von einem anderen Gerät.
• Wenn Sie Daten außerhalb des TEE speichern müssen, verwenden Sie den von der setActiveUser() HIDL method bereitgestellten Dateisystempfad oder stellen Sie eine andere Möglichkeit bereit, alle Benutzervorlagendaten zu löschen, wenn der Benutzer entfernt wird. Der Grund besteht darin, den Verlust von Benutzerdaten zu verhindern. Geräte, die diesen Pfad nicht verwenden, müssen nach dem Entfernen des Benutzers bereinigt werden. CDD verlangt, dass biometrische Daten und abgeleitete Dateien verschlüsselt gespeichert werden – insbesondere, wenn sie nicht in 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 Benutzer oder das Gerät entfernt wird wird abgewischt. Siehe LockSettingsService.removeBiometrischesForUser()

Anpassung

Wenn Ihr Gerät mehrere biometrische Daten unterstützt, sollte der Benutzer in den Einstellungen einen Standard festlegen können. Ihre BiometricPrompt Implementierung sollte standardmäßig die Biometrie der Klasse 3 (früher „Stark“) bevorzugen, es sei denn, der Benutzer überschreibt sie ausdrücklich. Dann muss eine Warnmeldung angezeigt werden, die die mit der Biometrie verbundenen Risiken erläutert (z. B. „Ein Foto von Ihnen könnte Ihr Gerät entsperren“) )

Gerätespezifische Authentifizierungszeichenfolgen

Ab Android 12 werden Entwicklern kontextbezogene Authentifizierungszeichenfolgen über die BiometricManager.Strings -API zur Verfügung gestellt. Sie können die von dieser API zurückgegebenen Ressourcenwerte anpassen, um gerätespezifische Zeichenfolgen zu implementieren. Stellen Sie in diesem Fall sicher, dass alle neuen Zeichenfolgen für alle vom Gerät unterstützten Gebietsschemata übersetzt werden. Stellen Sie außerdem sicher, dass die folgenden Eigenschaften erhalten bleiben:

Methode	String-Zweck	Einzuschließende Authentifizierungstypen	Wenn biometrische(s) und Bildschirmsperre beides möglich ist
getButtonLabel()	Bezeichnung für eine Schaltfläche, die BiometricPrompt auslöst	Nur registrierte Typen (sofern möglich), die die Anforderungen des Authentifikators erfüllen	Nur biometrische Zeichenfolge verwenden (z. B. „Fingerabdruck verwenden“)
getPromptMessage()	Während der Authentifizierung wird auf BiometricPrompt eine Nachricht angezeigt	Nur registrierte Typen (sofern möglich), die die Anforderungen des Authentifikators erfüllen	Verwenden Sie eine kombinierte biometrische und Bildschirmsperrzeichenfolge (z. B. „Verwenden Sie Ihren Fingerabdruck oder Ihre PIN, um fortzufahren“).
getSettingName()	Name einer Einstellung, die BiometricPrompt für die Authentifizierung aktiviert	Alle vom Gerät unterstützten Typen (auch wenn nicht registriert), die die Authentifikatoranforderungen erfüllen	Verwenden Sie eine kombinierte Zeichenfolge für biometrische Daten und Bildschirmsperre (z. B. „Fingerabdruck oder Bildschirmsperre verwenden“).

Stellen Sie sich beispielsweise ein Gerät vor, das über einen Gesichtssensor der Klasse 2 mit einem registrierten Gesicht , einer registrierten PIN und einen Fingerabdrucksensor der Klasse 3 ohne registrierte Fingerabdrücke verfügt. Die folgende Tabelle enthält Beispielzeichenfolgen für jede Kombination aus zulässigen Authentifikatoren und der aufgerufenen BiometricManager.Strings- Methode:

Zulässige Authentifikatoren	getButtonLabel()	getPromptMessage()	getSettingName()
Biometrie der Klasse 3 ( BIOMETRIC_STRONG )	„Fingerabdruck verwenden“ (Nur der Fingerabdruck erfüllt die Authentifizierungsanforderungen)	„Verwenden Sie Ihren Fingerabdruck, um fortzufahren“ (Nur der Fingerabdruck erfüllt die Authentifizierungsanforderungen)	„Fingerabdruck verwenden“ (Nur der Fingerabdruck erfüllt die Authentifizierungsanforderungen)
Biometrie der Klasse 2 ( BIOMETRIC_WEAK )	„Gesicht benutzen“ (Gesicht und Fingerabdruck erfüllen die Anforderungen; nur das Gesicht wird registriert)	„Benutze dein Gesicht, um fortzufahren“ (Gesicht und Fingerabdruck erfüllen die Anforderungen; nur das Gesicht wird registriert)	„Gesicht oder Fingerabdruck verwenden“ (Gesicht und Fingerabdruck erfüllen Anforderungen; Gerät unterstützt beides)
Bildschirmsperre ( DEVICE_CREDENTIAL )	„PIN verwenden“ (Jede Bildschirmsperre erfüllt die Anforderungen; PIN ist registriert)	„Geben Sie Ihre PIN ein, um fortzufahren“ (Jede Bildschirmsperre erfüllt die Anforderungen; PIN ist registriert)	„Bildschirmsperre verwenden“ (Jede Bildschirmsperre erfüllt die Anforderungen)
Biometrische ODER- Bildschirmsperre der Klasse 3	„PIN verwenden“ (Fingerabdruck und eventuelle Bildschirmsperre erfüllen die Anforderungen; nur die PIN ist registriert)	„Geben Sie Ihre PIN ein, um fortzufahren“ (Fingerabdruck und eventuelle Bildschirmsperre erfüllen die Anforderungen; nur die PIN ist registriert)	„Fingerabdruck oder Bildschirmsperre verwenden“ (Fingerabdruck und eventuelle Bildschirmsperre erfüllen die Anforderungen)
Biometrische ODER- Bildschirmsperre der Klasse 2	„Gesicht benutzen“ (Gesicht, Fingerabdruck und eventuelle Bildschirmsperre erfüllen die Anforderungen; das Gesicht wird registriert und ersetzt die PIN.)	„Verwenden Sie Ihr Gesicht oder Ihre PIN, um fortzufahren“ (Gesicht, Fingerabdruck und eventuelle Bildschirmsperre erfüllen die Anforderungen; Gesicht und PIN sind registriert)	„Biometrie oder Bildschirmsperre verwenden“ (Gesicht, Fingerabdruck und eventuelle Bildschirmsperre erfüllen die Anforderungen)

Validierung

Ihre biometrische Implementierung muss die folgenden Tests bestehen:

• CTS BiometricManager
• CTS BiometricPrompt (zuverlässige, eingehende Tests basieren auf Prüfern)
• Abschnitt „Biometrischer CtsVerifier-Test“: Muss bei jeder Modalität, die das Gerät unterstützt, einzeln bestanden werden

Wenn Ihr Gerät außerdem biometrische Daten mit AOSP HIDL ( Fingerabdruck@2.1 , Fingerabdruck@2.2 , Gesicht1.0 ) unterstützt, muss es den entsprechenden VTS-Test ( Fingerabdruck , Gesicht ) bestehen.