Biometrischer Login, den ein gehookter Callback nicht fälschen kann

Der biometrische Login gehört zu den Funktionen, die Nutzer an Banking-Apps am meisten schätzen: ein Blick oder eine Berührung statt einer PIN. Zugleich ist er eine der Funktionen, die sich am leichtesten so umsetzen lassen, dass sie sicher aussehen, es aber nicht sind.

Bei einem Sicherheitsaudit der Android-App einer Retail-Bank war die biometrische Authentifizierung einer der Bereiche, die wir gehärtet haben. In diesem Artikel erklären wir die verbreitete Schwachstelle, wie die Bindung der Biometrie an ein CryptoObject sie schließt und was damit noch nicht gelöst ist.

---

Die verbreitete Schwachstelle: Vertrauen in den Callback

Androids BiometricPrompt meldet das Ergebnis einer Prüfung über einen Callback. Die einfachste Implementierung folgt dieser Logik:

1. Den biometrischen Dialog anzeigen.

2. Auf onAuthenticationSucceeded warten.

3. Die Sitzung entsperren.

Das Problem ist Schritt 3. Auf einem kompromittierten Gerät kann ein Hooking-Tool wie Frida den Erfolgs-Callback direkt aufrufen. Die App kann eine echte biometrische Übereinstimmung nicht von einem gefälschten Methodenaufruf unterscheiden.

📌 Kernaussage:

Ein Callback sagt: „Irgendetwas hat Erfolg gemeldet.“ Ein kryptografischer Schlüssel, den nur das System entsperren kann, sagt: „Es hat eine echte biometrische Prüfung stattgefunden.“

---

Die Lösung: Biometrie an einen Schlüssel binden

Statt dem Callback zu vertrauen, knüpft die App den Login an eine kryptografische Operation:

1. Erstellen Sie einen Schlüssel im Android Keystore, der vor jeder Verwendung eine Nutzerauthentifizierung erfordert.

2. Kapseln Sie eine Cipher oder Signature mit diesem Schlüssel in einem CryptoObject und übergeben Sie es an BiometricPrompt.

3. Erst nach einer echten biometrischen Übereinstimmung entsperrt das System den Schlüssel für diese Operation.

4. Verwenden Sie die entsperrte Cipher, um ein Sitzungsgeheimnis zu entschlüsseln oder eine Server-Challenge zu signieren. Der Login wird nur fortgesetzt, wenn diese Operation gelingt.

Fälscht ein Angreifer den Callback, wurde die Cipher nie entsperrt. Entschlüsselung oder Signatur schlagen fehl – und mit ihnen der Login.

---

Designentscheidungen, auf die es ankommt

1. Etwas Echtes entschlüsseln oder signieren

Das CryptoObject muss etwas schützen, von dem der Login tatsächlich abhängt – ein Sitzungsgeheimnis oder eine Signatur, die der Server prüft. Wer die Cipher auf Dummy-Daten anwendet und das Ergebnis ignoriert, holt die Schwachstelle direkt zurück.

2. Festlegen, was bei geänderter Biometrie passiert

Schlüssel lassen sich so konfigurieren, dass sie ungültig werden, sobald ein neuer Fingerabdruck oder ein neues Gesicht registriert wird. Das stoppt eine Person, die ihre eigenen biometrischen Merkmale auf einem entsperrten Smartphone hinzufügt. Es bedeutet aber auch, dass die App einen klaren Ablauf braucht, um die Biometrie über PIN oder Passwort wieder zu aktivieren.

3. Einen Fallback beibehalten

Biometrie schlägt fehl: nasse Finger, Masken, neue Smartphones. Ein Fallback auf PIN oder Passwort ist Teil des Designs und muss genauso gut geschützt sein wie der biometrische Weg.

4. Mit weiteren Schutzmaßnahmen kombinieren

Die Bindung an ein CryptoObject schließt eine Lücke. Root- und Hooking-Erkennung, serverseitige Sitzungsvalidierung und Rate Limiting schließen andere.

---

Nur Callback vs. an CryptoObject gebundene Biometrie

Aspekt	Nur Callback	An CryptoObject gebunden
Was den Erfolg belegt	Ein Methodenaufruf	Ein Schlüssel, den das System entsperrt
Gefälschter Callback per Hooking-Tool	Login gelingt	Login schlägt fehl
Implementierungsaufwand	Gering	Mittel
Veränderung der User Experience	—	Keine für den Nutzer

Wie Mobian unterstützt

Bei Mobian war an ein CryptoObject gebundene Biometrie eine der Schutzmaßnahmen in einem Behebungsplan mit 124 Aufgaben für die Android-App einer Retail-Bank – neben Overlay-Schutz, Hooking- und Emulator-Erkennung sowie Anti-Repackaging-Prüfungen. Jede Maßnahme wurde durch ein unabhängiges QA-Security-Paket verifiziert, nicht nur von dem Entwickler, der sie umgesetzt hatte.

Fazit

Ein biometrischer Login, der einem Callback vertraut, ist nur so stark wie das Gerät, auf dem er läuft. Wird der Login an einen Keystore-Schlüssel gebunden, den das System erst nach einer echten Übereinstimmung entsperrt, bringt ein gefälschter Callback einem Angreifer nichts. Die User Experience bleibt gleich; der Unterschied zeigt sich erst, wenn jemand zu betrügen versucht.

Häufige Fragen

Was ist falsch daran, nur den biometrischen Erfolgs-Callback zu prüfen?

Wenn eine App eine Sitzung entsperrt, sobald onAuthenticationSucceeded aufgerufen wird, kann ein Angreifer mit einem Hooking-Tool wie Frida auf einem kompromittierten Gerät diese Methode direkt aufrufen. Die App sieht einen Erfolg, ohne dass jemals ein Fingerabdruck oder ein Gesicht geprüft wurde.

Was ist ein CryptoObject bei der Android-Biometrie?

Ein CryptoObject kapselt eine kryptografische Operation, etwa eine Cipher oder Signature, die einen Schlüssel aus dem Android Keystore verwendet. Wird dieser Schlüssel so erstellt, dass er eine Nutzerauthentifizierung erfordert, funktioniert die Operation erst nach einer echten biometrischen Prüfung durch das System. Ein gefälschter Callback verschafft dem Angreifer nur eine Cipher, die sich nicht verwenden lässt.

Schützt an ein CryptoObject gebundene Biometrie vor jedem Angriff?

Nein. Sie schließt die Lücke des gefälschten Callbacks, sollte aber mit weiteren Schutzmaßnahmen kombiniert werden, etwa Root- und Hooking-Erkennung, serverseitigen Sitzungsprüfungen und einem Fallback auf PIN oder Passwort. Keine einzelne Maßnahme macht eine App sicher.

Was passiert, wenn ein Nutzer einen neuen Fingerabdruck registriert?

Schlüssel lassen sich so konfigurieren, dass sie ungültig werden, sobald neue biometrische Merkmale registriert werden. Das hindert jemanden, der seinen eigenen Fingerabdruck auf einem entsperrten Smartphone hinzufügt, daran, sich damit anzumelden. Die App braucht dann jedoch einen klaren Ablauf zur erneuten Einrichtung, in der Regel über PIN oder Passwort.

Welche OWASP-Kategorie wird damit adressiert?

Vor allem M3: Insecure Authentication/Authorization der OWASP Mobile Top 10 (2024). Die Bindung des Schlüssels an die Biometrie unterstützt außerdem gute Praxis im Sinne von M10, Insufficient Cryptography.