Widerstandsfähigkeit biometrischer Identitätsprüfung gegen moderne Angriffe im Test

Das Citadelo-Team analysierte das Innovatrics Identity Verification (IDV) Toolkit im Rahmen eines 16-tägigen Black-Box-Penetrationstests. Ziel des Assessments war es, das Vorgehen eines realen Angreifers zu simulieren und die Mechanismen der Liveness Detection zu umgehen. In diesem Artikel beschreiben wir unseren Ansatz beim Reverse Engineering, der Runtime Instrumentation sowie bei Injection Attacks, mit denen wir die Widerstandsfähigkeit des Systems unter realistischen Angriffsbedingungen überprüft haben.

Warum unabhängige Tests biometrischer Systeme unverzichtbar sind

In einer Zeit, in der bereits ein einziger KI-generierter Deepfake einem Unternehmen Schäden in Millionenhöhe verursachen kann, verschwimmt die Grenze zwischen einer echten und einer künstlich erzeugten Identität zunehmend. Diese Bedrohung ist längst kein theoretisches Risiko mehr, das nur in Vorstandsetagen diskutiert wird. Sie zählt heute zu den wichtigsten Gründen für strengere regulatorische Anforderungen im Bereich der digitalen Identität und Cybersicherheit.

Mit der schrittweisen Umsetzung des AI Act steigen die Anforderungen an Transparenz und Sicherheit von KI-gestützten Systemen kontinuierlich. Dazu gehört insbesondere die Fähigkeit, zuverlässig zwischen einer echten Person und einer künstlich erzeugten Identität unterscheiden zu können.Remote-Identifizierung und Online-Authentifizierung gehören heute zum Standard moderner digitaler Dienste. Biometrische Identitätsprüfung bildet dabei eine der wichtigsten Säulen moderner Zero-Trust-Architekturen und ersetzt zunehmend klassische Authentifizierungsverfahren wie Passwörter, PIN-Codes oder Sicherheitsfragen.

Doch auch Angreifer entwickeln ihre Methoden kontinuierlich weiter. Generative KI, Open-Source-Werkzeuge zur Manipulation von Videos sowie Frameworks zur Laufzeitmanipulation von Anwendungen sind heute frei verfügbar. Dadurch lassen sich selbst komplexe Presentation Attacks mit manipulierten biometrischen Eingaben deutlich einfacher durchführen.

Die biometrische Gesichtserkennung stellt häufig die letzte Verteidigungslinie gegen Identitätsbetrug dar. Gelingt es einem Angreifer, diese Schutzmechanismen zu umgehen, kann er unberechtigte Konten eröffnen, Maßnahmen zur Bekämpfung von Geldwäsche (Anti-Money Laundering – AML) umgehen oder Zugriff auf kritische Finanzsysteme erlangen. Unternehmen können sich deshalb nicht allein auf Herstellerzertifizierungen oder einmalige Sicherheitsaudits verlassen. Die tatsächliche Widerstandsfähigkeit eines Systems lässt sich nur durch unabhängige Sicherheitstests nachweisen, die reale Angriffsszenarien simulieren.

Diese Fallstudie beschreibt eine Black-Box-Sicherheitsbewertung (Black-Box Security Assessment) des Innovatrics Identity Verification Toolkit, einer der führenden Lösungen für die digitale Identitätsprüfung. Während eines sechzehntägigen Assessments analysierten wir die interne Funktionsweise der Lösung, führten Reverse Engineering ihrer Komponenten durch, versuchten native Schutzmechanismen zu umgehen, simulierten Injection Attacks und bewerteten deren Ergebnisse.

Trotz intensiver Tests konnten wir weder die mehrschichtige Sicherheitsarchitektur der Lösung überwinden noch die Mechanismen der Liveness Detection erfolgreich umgehen. 

„Im Rahmen eines bedeutenden Kundenprojekts mussten wir die Widerstandsfähigkeit unserer Lösung zur Identitätsprüfung gegenüber Injection Attacks unabhängig überprüfen lassen. Wir entschieden uns für Citadelo aufgrund ihrer technischen Expertise, ihres ausgezeichneten Rufs und ihrer Fähigkeit, das Assessment innerhalb eines anspruchsvollen Zeitrahmens durchzuführen. Die Ergebnisse der Sicherheitsbewertung lieferten uns einen unabhängigen Nachweis der Widerstandsfähigkeit unserer Lösung und stärkten gleichzeitig das Vertrauen unseres Kunden in deren Sicherheit,“ Viktor Bielko- Product Manager, IDV Toolkit, Innovatrics.

Warum Black Box? Die Perspektive eines Angreifers

Die Sicherheitsbewertung eines Software Development Kits (SDK) mittels Black-Box-Testing (Black-Box Testing) ist deshalb besonders aussagekräftig, weil sie die Bedingungen eines realen Angriffs möglichst genau nachbildet.

Während des Assessments hatten wir weder Zugriff auf den Quellcode noch auf Architekturdiagramme oder interne Entwicklungsdokumentationen. Unsere Analyse basierte ausschließlich auf öffentlich verfügbarer Dokumentation, den produktiven Binärdateien der Client-Anwendung sowie öffentlich zugänglichen APIs. Bei dieser Art der Sicherheitsbewertung lässt sich nicht davon ausgehen, wie eine Anwendung funktionieren sollte. Entscheidend ist vielmehr ihr tatsächliches Verhalten unter realen Bedingungen. Ein wirklich sicheres biometrisches SDK muss auch dann widerstandsfähig bleiben, wenn ein Angreifer die vollständige Kontrolle über das Endgerät übernimmt, auf dem die Anwendung ausgeführt wird. Dieser Ansatz basiert auf dem Kerckhoffs's Principle, wonach die Sicherheit eines Systems niemals auf der Geheimhaltung seiner Funktionsweise (Security Through Obscurity) beruhen darf.

Die Durchführung des Tests ohne interne Informationen ermöglichte uns eine objektive Bewertung, ob die Laufzeitschutzmechanismen der Anwendung, die Code-Obfuskation (Code Obfuscation) sowie die Absicherung der Kommunikation modernen Methoden des Reverse Engineering und automatisierten Angriffen tatsächlich standhalten.

Testumfang und Methodik

Unsere technische Sicherheitsbewertung konzentrierte sich hauptsächlich auf die Bibliothek Innovatrics Android Face Lite Library sowie deren Kommunikation mit dem Dienst Digital Identity Service (DIS). Obwohl wir die iOS-Implementierung ebenfalls stichprobenartig analysierten, lag der Schwerpunkt des Assessments auf Android. Die offenere Architektur dieser Plattform ermöglicht eine wesentlich detailliertere Analyse von Binärdateien, Systemaufrufen und dem Laufzeitverhalten der Anwendung.

Das Assessment gliederte sich in drei aufeinander aufbauende Phasen.

Phase 1: Statische Analyse und Dekompilierung (Static Analysis & Decompilation)

In der ersten Phase analysierten wir die Binärdateien der Anwendung, um deren logische Struktur zu rekonstruieren. Dabei identifizierten wir fest kodierte Konstanten, rekonstruierten die interne Klassenarchitektur und untersuchten die nativen Bibliotheken von Drittanbietern, die Bestandteil der Lösung sind.

Phase 2: Laufzeitanalyse und API-Hooking (Dynamic Instrumentation & Hooking)

In der zweiten Phase konzentrierten wir uns auf die Laufzeitanalyse der Anwendung (Runtime Instrumentation). Mithilfe spezialisierter Werkzeuge injizierten wir eigene Skripte in den laufenden Prozess. Dadurch konnten wir den Programmablauf überwachen, Entscheidungslogiken nachvollziehen, kryptografische Daten im Arbeitsspeicher analysieren und ausgewählte Datenstrukturen während der Laufzeit gezielt verändern.

Phase 3: Injection Attacks und Angriffe auf die Kommunikationsschicht (Digital Injection & Transport Layer Attacks)

In der letzten Phase führten wir fortgeschrittene Angriffsszenarien durch. Dabei testeten wir Manipulationen der Netzwerkkommunikation, das Abfangen von Authentifizierungstokens sowie verschiedene Injection Attacks, darunter auch die Simulation einer virtuellen Kamera, die dem System manipulierte Bilddaten anstelle des Kamerabildes zuführte.

Reverse Engineering und Laufzeitanalyse

Sobald eine Anwendung auf dem Gerät eines Benutzers ausgeführt wird, besitzt ein Angreifer aus technischer Sicht die vollständige Kontrolle über dieses Gerät. Er kann versuchen, die interne Logik der Anwendung durch Dekompilierung (Decompilation) zu analysieren oder ihr Verhalten während der Laufzeit mithilfe von Runtime Instrumentation zu untersuchen.

Zum Schutz vor solchen Angriffen verlagern Entwickler sicherheitskritische Funktionen in native Bibliotheken, setzen Code Obfuscation ein und implementieren Mechanismen zur Erkennung von Debuggern sowie von Werkzeugen für Runtime Instrumentation. Werden solche Werkzeuge erkannt, beendet die Anwendung ihre Ausführung oder blockiert die weitere Verarbeitung. Obwohl sich diese Schutzmechanismen unter bestimmten Voraussetzungen umgehen lassen, erfordert dies tiefgehende technische Kenntnisse, Eingriffe auf niedriger Systemebene und einen erheblichen Zeitaufwand.

Analyse der Angriffsszenarien und Testergebnisse

Während des sechzehntägigen Assessments arbeitete unser Team systematisch alle geplanten Angriffsszenarien ab. Wir analysierten die Netzwerkkommunikation, deobfuskierten dekompilierten Code, führten Reverse Engineering nativer Bibliotheken durch, untersuchten die interne Verarbeitung der Gesichtserfassung, versuchten verschiedene Sicherheitsmechanismen zu umgehen und entwickelten eine Testumgebung für unterschiedliche Injection Attacks.

Simulation einer virtuellen Kamera mit LSPosed (Virtual Camera Simulation via LSPosed Hooking)

Das erste Angriffsszenario zielte darauf ab, den Bildstrom der echten Kamera vollständig durch ein zuvor aufgezeichnetes Video zu ersetzen. Ziel war es, einen Presentation Attack mit manipulierten biometrischen Eingaben durchzuführen, ohne das Video auf einem externen Bildschirm oder einem zweiten Gerät wiedergeben zu müssen. Hierfür nutzten wir eine Anwendung, die als Systemmodul fungierte. Mithilfe des Frameworks LSPosed wurden Aufrufe der Android Camera2 API abgefangen, sodass das Betriebssystem der Anwendung anstelle des Kamerabildes Bilddaten aus einer vorbereiteten Videodatei bereitstellte.

Ergebnis: Nicht erfolgreich

Obwohl es uns gelang, den Bildstrom auf der Java-Ebene erfolgreich zu ersetzen, erkannte der Verifizierungsmechanismus von Innovatrics die Unstimmigkeiten unmittelbar. Die bereitgestellten Bilddaten wurden verworfen und die Sitzung als Manipulationsversuch (Tampering) eingestuft.

Einschleusen von Daten vor der Verschlüsselung (Man-in-the-App Cryptographic Boundary Interception)

Das zweite Angriffsszenario war deutlich anspruchsvoller. Ziel war es nicht, das Kamerabild zu ersetzen, sondern direkt in die Verarbeitung biometrischer Daten innerhalb der Anwendung einzugreifen. Dabei ließ der Angreifer die Anwendung zunächst ein echtes Kamerabild erfassen, sodass sämtliche Hardware-Metadaten authentisch blieben. Anschließend versuchte er, die im Arbeitsspeicher der Anwendung abgelegten biometrischen Bilddaten unmittelbar vor ihrer Verschlüsselung und Übertragung an den Server abzufangen und durch eigene Daten zu ersetzen. Dieser Angriff ist erheblich komplexer als eine Manipulation des Kamerabildes, da das System weiterhin mit authentischen Gerätedaten arbeitet und lediglich der Inhalt der biometrischen Daten verändert wird.

Ergebnis: Nicht erfolgreich

Obwohl wir während der Laufzeit die Kontrolle über den Speicher der Client-Anwendung übernehmen konnten, erkannte die Serverseite des Systems die Inkonsistenz der empfangenen Daten zuverlässig. Der Versuch, manipulierte Daten einzuschleusen, wurde erkannt und der Identitätsprüfungsprozess abgebrochen.

Einschleusen von Bildsequenzen (Real-Time Frame Injection)

Das letzte Szenario stellte den technisch anspruchsvollsten Angriff im gesamten Assessment dar. Anstatt die Netzwerkkommunikation oder Systemaufrufe zu manipulieren, konzentrierten wir uns direkt auf den nativen Teil des SDK, der für die Initialisierung der Bilddaten verantwortlich ist. Ziel war es, eine Sequenz hochwertiger Bildaufnahmen in Echtzeit einzuschleusen, noch bevor diese intern verarbeitet und serialisiert wurden. Im Gegensatz zu den vorherigen Szenarien umgeht dieser Ansatz mehrere Schutzmechanismen des Betriebssystems und greift direkt in die interne Verarbeitung biometrischer Daten ein. Dadurch zählt er zu den technisch anspruchsvollsten Angriffsmethoden gegen biometrische Identitätsprüfungen.

Ergebnis: Nicht erfolgreich

Auch dieses Angriffsszenario führte nicht dazu, die Mechanismen zur Liveness Detection erfolgreich zu umgehen. Die mehrschichtige Sicherheitsarchitektur der Lösung verhinderte das erfolgreiche Einschleusen manipulierter biometrischer Daten.

Was bedeuten die Testergebnisse?

Die Widerstandsfähigkeit, die das Innovatrics IDV Toolkit während unseres Assessments unter Beweis stellte, verdeutlicht mehrere grundlegende Prinzipien moderner Sicherheitsarchitekturen, wie sie heute im Bankwesen, in der Versicherungsbranche, im FinTech-Sektor und in weiteren regulierten Bereichen eingesetzt werden.

1. Sicherheit darf nicht auf dem Endgerät basieren (De-coupling Client Trust)

Die Testergebnisse zeigen, dass clientseitige Schutzmechanismen wie Code Obfuscation, die Erkennung gerooteter Geräte oder Mechanismen zum Schutz vor Manipulationen den Aufwand für Angreifer deutlich erhöhen. Als alleinige Sicherheitsmaßnahme reichen sie jedoch nicht aus. Verfügt ein Angreifer über ausreichend Zeit, tiefgehendes technisches Know-how und die vollständige Kontrolle über das Endgerät, kann er mithilfe von Runtime Instrumentation oder API Hooking einen Teil dieser Schutzmechanismen umgehen. Die eigentliche Sicherheit biometrischer Identitätsprüfungen hängt daher in erster Linie von serverseitigen Validierungsmechanismen ab. Ein System muss auch dann sicher bleiben, wenn die Client-Anwendung auf einem vollständig kompromittierten Endgerät ausgeführt wird.

2. Sicherheit muss kontinuierlich überprüft werden (Continuous Lifecycle Auditing)

Die Sicherheitsbewertung eines biometrischen Systems darf nicht als einmalige Maßnahme bei der Inbetriebnahme betrachtet werden. Werkzeuge für Reverse Engineering werden kontinuierlich weiterentwickelt, und generative künstliche Intelligenz senkt den Aufwand für die Erstellung realistischer Deepfakes erheblich. Gleichzeitig entwickeln auch Angreifer ihre Methoden ständig weiter. Unternehmen sollten deshalb regelmäßige Sicherheitstests biometrischer Systeme als festen Bestandteil des gesamten Software-Lebenszyklus und ihres Risikomanagements etablieren. Solche Tests dürfen nicht ausschließlich durchgeführt werden, um regulatorische oder gesetzliche Anforderungen zu erfüllen.

3. Hardware-Telemetrie spielt eine entscheidende Rolle (Hardware-Anchored Telemetry)

Moderne Lösungen zur Identitätsprüfung dürfen ihre Entscheidung nicht ausschließlich auf Grundlage des Gesichtsbildes treffen. Systeme, die lediglich bewerten, ob ein Foto oder Video glaubwürdig erscheint, sind deutlich anfälliger für Injection Attacks. Ein wesentlich höheres Sicherheitsniveau bieten Lösungen, die zusätzlich Telemetriedaten direkt von der Hardware des Endgeräts auswerten. Die Kombination aus Bilddaten und Hardware-Telemetrie erhöht den Aufwand für einen erfolgreichen Angriff erheblich und ermöglicht die zuverlässige Erkennung virtueller Kameras, Emulatoren und weiterer Softwaretechniken, die beim Spoofing eingesetzt werden.

Fazit

„Die Black-Box-Sicherheitsbewertung des Innovatrics Identity Verification Toolkit hat die hohe Widerstandsfähigkeit seiner mehrschichtigen Sicherheitsarchitektur bestätigt. Obwohl es unserem Team gelang, die ersten Schutzmechanismen gegen Runtime Instrumentation zu umgehen und die Kontrolle über den Speicher der Client-Anwendung auf einem Android-Gerät zu übernehmen, scheiterten sämtliche nachfolgenden Versuche, manipulierte Daten einzuschleusen. Die Mechanismen zur Liveness Detection blieben während des gesamten Assessments wirksam,“ Oliver -Ethical Hacker, Citadelo

Die Kombination aus der Isolierung sicherheitskritischer Komponenten in nativen Bibliotheken, der Korrelation von Hardware-Telemetriedaten und serverseitigen Validierungsmechanismen bietet ein hohes Maß an Schutz für moderne Systeme zur digitalen Identitätsprüfung.

Black-Box-Penetrationstests gehören zu den effektivsten Methoden, um die Sicherheit einer Anwendung unter realitätsnahen Bedingungen objektiv zu bewerten. Da keinerlei interne Informationen über die Lösung vorausgesetzt werden, lässt sich zuverlässig beurteilen, ob ein Angreifer mit öffentlich verfügbaren Informationen und frei zugänglichen Werkzeugen in der Lage wäre, das System zu kompromittieren.

Je nach Zielsetzung einer Organisation kann dieser Ansatz durch eine White-Box-Sicherheitsbewertung (White-Box Assessment) ergänzt werden. Während ein Black-Box-Test das Vorgehen eines externen Angreifers simuliert, ermöglicht eine White-Box-Analyse eine detaillierte Bewertung der Architektur, der Implementierung einzelner Komponenten sowie des Quellcodes.

Beide Methoden ergänzen sich und liefern unterschiedliche Perspektiven auf die Sicherheit eines Systems. Welcher Ansatz der richtige ist, hängt von den konkreten Risiken, den regulatorischen Anforderungen und dem gewünschten Sicherheitsniveau ab.

Wenn Sie die Widerstandsfähigkeit Ihrer Lösung aus Sicht eines realen Angreifers überprüfen oder die Architektur und Implementierung Ihres Systems im Detail analysieren möchten, unterstützen wir Sie gerne bei der Auswahl des passenden Sicherheitsansatzes.