Analyse von Deepfake-Angriffen im Rahmen der Kundenidentifizierung

Wo die Härtung in die Deepfake-Angriffsoberfläche passt 

Ein Gesicht allein beweist nicht mehr die Identität einer Person. Das ist die unangenehme Wahrheit, die Banken nun erfahren müssen, da KI-generierte Gesichter und Dokumente die KYC-Prüfungen (Know Your Customer) umgehen, die für eine Welt vor generativer KI entwickelt wurden. 

Kameras kommen in Banking-Apps an einigen spezifischen Stellen im Identitätsprüfungsprozess zum Einsatz, nicht nur einmal bei der Registrierung. Am offensichtlichsten ist die Kontoeröffnung: Neukunden fotografieren ihren Personalausweis und nehmen anschließend ein Selfie oder ein kurzes Live-Video auf, damit die App das Gesicht auf dem Dokument mit dem Gesicht vor der Kamera abgleichen und die Anwesenheit einer lebenden Person bestätigen kann (Lebenderkennung). Viele Banken nutzen die Kamera auch im Rahmen der Zwei-Faktor-Authentifizierung: Eine hohe Überweisung, ein Zurücksetzen des Passworts oder das Hinzufügen eines neuen Zahlungsempfängers können eine erneute Verifizierung auslösen. Einige Institute führen regelmäßige Überprüfungen alle ein bis zwei Jahre oder bei erhöhten Risikosignalen durch. In jedem Fall ist die Kamera nicht die einzige Sicherheitsmaßnahme; sie wird üblicherweise mit Geräteprüfungen, Einmalpasswörtern oder Verhaltenssignalen kombiniert. Aus diesem Grund werden Deepfake-Angriffe häufig mit Identitätsdiebstahl, Malware, Phishing und anderen Techniken kombiniert, um die bestehenden Sicherheitsvorkehrungen zu umgehen. 

Es ist verlockend, „Deepfake-Betrug“ als ein einziges Problem mit einer einzigen Lösung zu betrachten. Doch es handelt sich nicht um einen einzelnen Schwachpunkt. Die KYC-Verifizierung durchläuft einen mehrstufigen Prozess, der mit der physischen Szene vor der Kamera beginnt, über das Gerät, die App-Laufzeitumgebung, das geräteinterne Entscheidungsmodell, das Netzwerk, die serverseitige Entscheidung und schließlich die laufende Sitzung verläuft. Ein Angreifer benötigt nur eine einzige Schwachstelle; ein Verteidiger muss alle absichern. 

Keine einzelne Sicherheitsmaßnahme deckt den gesamten Prozess ab, und es bedarf mehrerer Sicherheitsanbieter oder intern entwickelter Komponenten, um die Angriffsfläche vollständig zu schützen. Dieser Beitrag beschreibt den gesamten Prozess von Anfang bis Ende, konzentriert sich auf die drei Phasen, die ein Produkt zur Anwendungshärtung und RASP wie Arxan Security tatsächlich abmildert (Phasen 2, 3 und 5), und gibt einen ehrlichen Überblick darüber, wer die übrigen Phasen abdeckt.  

Angriffsfläche für Deepfakes im KYC-Bereich: sieben Pipeline-Stufen, jede mit eigenem Angriffs- und Kontrollmechanismus.

Phase 1 – Die physische Ebene / Präsentationsebene: Ist das Gesicht überhaupt echt? 

Bevor das Gerät oder die App überhaupt zum Einsatz kommt, erfolgt der Angriff direkt auf die Kameralinse: Fotos, Bildschirme und Masken. Präsentationsangriffserkennungssysteme (PAD), die gemäß ISO/IEC 30107-3 evaluiert werden, erkennen dies mithilfe von Sensoranalysen. Die Verantwortung hierfür liegt beim Identitätsanbieter, der Techniken wie Textur-, Tiefen- und Reflexionsanalyse sowie proprietäre Verfahren einsetzt, um sicherzustellen, dass die von der Kamera erfassten Inhalte real sind. 

Phase 2 – Die Geräte-/Aufnahmeschicht: Ist die Kamera überhaupt real? 

In dieser Phase geht es um die Frage, die sich die meisten Menschen nie stellen: Ist die „Kamera“, die die Identitätsprüfung durchführt, überhaupt eine Kamera? Auf einem gerooteten oder gejailbreakten Gerät oder in einem Emulator kann ein Angreifer die Kamerakomponente ersetzen und ein vorgerendertes Deepfake-Video direkt in die Kamera-API einschleusen. Die Software empfängt Frames, die perfekt aufgenommen aussehen, aber beliebige Inhalte des Angreifers enthalten. Dies ist der sogenannte Injection-Angriff und ein Schritt, um KI-Deepfakes in die Anwendung zu integrieren. 

Dies fällt eindeutig in den Zuständigkeitsbereich von RASP: Erkennung von Root-Zugriff und Jailbreak, Emulatorerkennung und Erkennung von Kamera-API-Hooks während der Laufzeit der Anwendung. MASVS-Resilience-1 verlangt von der App die Validierung der Plattformintegrität und deckt diesen Aspekt des Schutzes vor Deepfake-Kameraangriffen ab.  

Phase 3 – Die Laufzeitschicht: Ist die App noch dieselbe App? 

Angenommen, das Gerät ist echt. Die nächste Frage ist, ob der Anwendungscode, der die Verifizierung durchführt, manipuliert wurde. Angreifer greifen mithilfe von Instrumentierungsframeworks wie Frida oder Xposed in die Identitätssoftware ein oder patchen sie. Sie können die App auch so umpacken, dass die Lebendigkeitsprüfung deaktiviert ist, sodass die Verifizierungsfunktion unabhängig vom Kamerabild einfach „bestanden“ zurückgibt. 

Dies ist der Standard-Anwendungsfall für Manipulationsschutz, und genau hier liegt die Stärke von Arxan Security: Wir sind führend in der Entwicklung und führend in diesem Bereich. Verschleierung erschwert das Auffinden der Identitätssoftware, Instrumentierung und Erkennung von Hooks schränken die verfügbaren Hacking-Tools ein, und Integritätsprüfungen erkennen gepatchte Binärdateien zur Laufzeit. MASVS-Resilience-2, 3 und 4 sind direkt auf diese Kontrollmechanismen abgestimmt: Schutz vor statischer Analyse, Schutz vor dynamischer Analyse und Manipulationsschutz. 

Phase 4 – Die clientseitige Entscheidungsebene: Wurde das On-Device-Modell getäuscht? 

Wenn ein synthetisches Video ein unverfälschtes On-Device-Modell überzeugen kann, hilft nur noch ein besseres Modell. Passive Lebenderkennung und die Erkennung von Deepfakes auf dem Gerät sind Kompetenzen der Identitätsanbieter – dieselben Anbieter wie in Phase 1, nur in einem anderen Fachgebiet. 

Phase 5 – Die Transportschicht: Stammt dieses Ergebnis tatsächlich von der App? 

Selbst bei einem sauberen Gerät und einer unveränderten App muss das Verifizierungsergebnis noch an das Backend übertragen werden. Angreifer zielen genau auf diese Phase ab, indem sie Man-in-the-Middle-Angriffe durchführen, Replay-Angriffe ausführen und die API direkt missbrauchen. Zu diesen Techniken gehören beispielsweise das Abfangen einer legitimen, „verifizierten“ Antwort und deren Wiedergabe oder das vollständige Umgehen der App und die Kommunikation mit der KYC-API mit gefälschten Ergebnissen. 

Die Standardkontrollen sind bekannt: Ende-zu-Ende-Verschlüsselung, Client-App-Attestierung, Certificate Pinning und ein sicheres API-Design. Arxan Security bietet Certificate Pinning und Whitebox-Kryptografie für sichere Ende-zu-Ende-Verschlüsselung, Attestierung und Protokolle wie Mutual TLS (mTLS). Bei typischen Man-in-the-Middle-Bedrohungsanalysen konzentriert sich der Angreifer ausschließlich auf das Abfangen der Kommunikation. Bei Client-Anwendungen wie Banking-Apps kontrollieren die Angreifer die Hardware-, Software- und Kommunikationsschicht. Die Whitebox-Kryptografie von Arxan geht noch einen Schritt weiter und schützt die Transportschicht, indem sie den im Anwendungs-Binärcode und im Speicher vorhandenen Schlüssel schützt. Die Kombination von Whitebox-Kryptografie mit Ende-zu-Ende-Verschlüsselung und Attestierungsprotokollen verhindert, dass Angreifer die Transportschicht durchbrechen. Weitere Informationen zu Man-in-the-Middle-Kontrollen finden Sie hier: https://digital.ai/catalyst-blog/when-the-attacker-is-the-client-defending-against-mitm-attacks/  

Phase 6 – Die serverseitige Entscheidungsebene: Hat das Backend das erkannt, was dem Gerät entgangen ist? 

Ähnlich wie die clientseitige Entscheidungsebene kann auch das Modell zur Verarbeitung von Kamerabildern teilweise oder vollständig serverseitig implementiert werden. Die Client-Server-Architektur variiert je nach Identitätsanbieter, Plattform und Anwendungssoftware. Serverseitige Re-Verifizierung, Signalanalyse und die unternehmenseigene Entscheidungs- und Orchestrierungslogik erfassen die vom clientseitigen Modell übersehenen Details.  

Phase 7 — Die Verhaltens-/Sitzungsebene: Entspricht der Rest der Sitzung noch dem Verhalten des Kunden? 

Angreifer weisen oft ein Verhaltensmuster auf, das sich von dem typischer Nutzer unterscheiden kann. Kontinuierliche Risikobewertung, Geräte-Fingerprinting und Verhaltensbiometrie werden von Betrugs-/Risikoplattformen oder einer internen Risikoanalyse durchgeführt, nicht vom Identitätsanbieter oder der RASP-Schicht. 

Warum die Grenze wichtig ist 

Sichere Software basiert auf einem mehrschichtigen Sicherheitskonzept. Dies bedeutet, verschiedene Sicherheitsfunktionen wie Verschleierung und Integritätsprüfung mit einer sicheren Anwendungsentwicklung und -infrastruktur zu kombinieren. Die klare Zuordnung der Zuständigkeiten ist entscheidend für den Erfolg der Verteidigung. Ein erstklassiger Anbieter von Präsentationsangriffserkennung (PAD) und Liveness-Tests ist nutzlos, wenn die Binärdatei, die sein SDK ausführt, so manipuliert werden kann, dass sie immer „bestanden“ zurückgibt. Ebenso wenig kann eine starke RASP-Schicht einen gut gemachten Deepfake erkennen, der einer unversehrten Anwendung präsentiert wird. 

Die Pipeline funktioniert nur dann einwandfrei, wenn jeder Verantwortliche seine jeweilige Stufe tatsächlich abdeckt. Erfahrungsgemäß umgeht Betrug in der Regel die stärksten Kontrollmechanismen und nutzt stattdessen die Sicherheitslücken aus.  

Der Imbiss 

Die Anwendungshärtung und RASP-Funktionen von Arxan Security mindern drei der sieben Phasen der KYC-Deepfake-Angriffsfläche., und sie sind Die drei Phasen, die ein Identitätsanbieter nicht allein abdecken kann. Auf der Geräte-/Aufnahmeebene verhindern Root-Zugriff, Jailbreak, Emulator- und Kamera-API-Hooking-Erkennung, dass ein Angreifer einen Deepfake einschleusen kann, bevor auch nur ein einziges Bild das Identitäts-SDK erreicht. Auf der Laufzeitebene — unser ursprüngliches Betätigungsfeld, wo wir nach wie vor der Maßstab sind — Verschleierung, InstrumentierungHooking-Erkennung und Binärintegritätsprüfungen verhindern, dass Angreifer die Lebendigkeitsprüfung einfach so manipulieren, dass sie immer „bestanden“ zurückgibt. Auf der Transportschicht Certificate Pinning und Whitebox-Kryptographie stellen sicher, dass das „verifizierte“ Ergebnis, das das Backend erreicht, tatsächlich das von der App erzeugte Ergebnis ist und nicht ein wiederholtes oder gefälschtes. FolgeJedes dieser Steuerelemente ist direkt MASVS zugeordnet.-Die Resilienzstufen 1 bis 4 bieten Kunden einen nachvollziehbaren Standard für die Authentifizierung. Wird eine dieser Stufen ausgelassen, kann das Ergebnis eines etablierten Identitätsanbieters gefälscht, manipuliert oder abgefangen werden, bevor es das Backend erreicht. Die anderen vier Stufen werden vom Identitätsanbieter, dem serverseitigen Entscheidungs-Stack und der Betrugs-/Risikoplattform abgedeckt. und gleichzeitig die Arxan Security sorgt dafür, dass die Ergebnisse von Anfang bis Ende vertrauenswürdig sind.