Biometrische Verfahren

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“). Jede Klasse hat eine Reihe von Voraussetzungen, Berechtigungen und Einschränkungen. Weitere Informationen finden Sie in der CDD oben. 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 (Kurs 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. Iris) 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 beim biometrischen Entsperren messen.

Quelle

Android 12

  • Stellt die BiometricManager.Strings API vor, die lokalisierte Strings für Anwendungen bereitstellt, die BiometricPrompt für die Authentifizierung verwenden. Diese Strings sollen gerätespezifisch sein und genauer angeben, 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.
  • Es wird die Intent-Aktion ACTION_BIOMETRIC_ENROLL hinzugefügt, mit der Entwickler den Nutzer anweisen können, eine Authentifizierungsmethode zu registrieren, die den Anforderungen ihrer Anwendungen entspricht.
  • Es wurde die Methode AuthenticationResult#getAuthenticationType() hinzugefügt, mit der Entwickler prüfen können, ob sich der Nutzer mit biometrischen oder Geräteanmeldedaten authentifiziert hat.
  • Bietet zusätzliche Unterstützung für auth-per-use-Schlüssel innerhalb der BiometricPrompt-Klasse.

Android 10

  • Die BiometricManager Klasse 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 BiometricPrompt und BiometricManager verwendet werden.
  • Die FingerprintManager-CTS-Verifier-Tests wurden aktualisiert, um BiometricPrompt mit BiometricPromptBoundKeysTest zu 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:

  1. Ändern Sie BiometricEnrollActivity, um den Registrierungsvorgang anzuzeigen. Hinweis: Ihr biometrisches Merkmal kann nur dann verwendet werden, wenn es die erforderliche Stärke aufweist. Wenn dein Gerät mehr als eine Methode unterstützt, sollte bei dieser Aktion eine Liste angezeigt werden, aus der der Nutzer auswählen kann.
Architektur von BiometricPrompt
Abbildung 1. Architektur von BiometricPrompt

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. 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) 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 „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 des Dateisystems, der Gruppe und der biometrischen ID 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 lässt sich beispielsweise verhindern, dass biometrische Daten von einem anderen Nutzer auf demselben Gerät oder von einem anderen Gerät kopiert werden.
  • Wenn Sie Daten außerhalb des TEE speichern müssen, verwenden Sie den von setActiveUser() HIDL method bereitgestellten Dateisystempfad oder bieten Sie eine andere Möglichkeit zum Löschen aller Nutzervorlagendaten an, wenn der Nutzer entfernt wird. Der Grund dafür ist, die Datenlecks zu schützen. Geräte, die diesen Pfad nicht verwenden, müssen eine Bereinigung durchführen, nachdem der Nutzer entfernt wurde. CDD verlangt, dass biometrische Daten und abgeleitete Dateien verschlüsselt gespeichert werden – insbesondere, wenn dies nicht in TEE möglich ist. Wenn dies aufgrund der Speicheranforderungen der sicheren isolierten Umgebung nicht möglich ist, sollten Sie Hooks hinzufügen, damit die Daten entfernt werden, wenn der Nutzer entfernt oder das Gerät auf die Werkseinstellungen zurückgesetzt wird. Siehe LockSettingsService.removeBiometricsForUser()

Personalisierung

Wenn Ihr Gerät mehrere biometrische Verfahren unterstützt, sollte der Nutzer in den Einstellungen eine Standardeinstellung 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 werden Entwicklern die Strings für die kontextbezogene Authentifizierung über die BiometricManager.Strings API zur Verfügung gestellt. 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(n) Authentifizierungstyp(en)
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, eine registrierte PIN und einen Fingerabdrucksensor der Klasse 3 ohne keine registrierten Fingerabdrücke. Die folgende Tabelle enthält Beispielstrings für jede Kombination aus zulässigen Authenticatoren und aufgerufenen BiometricManager.Strings-Methoden:


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; es ist nur eine PIN registriert)
„PIN eingeben, 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 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:

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.