Décryptage des attaques de type « connaissance du client » (KHI) basées sur les deepfakes

Où se situe le durcissement de la surface d'attaque des deepfakes ? 

Un visage ne prouve plus l'identité d'une personne. C'est la vérité dérangeante que les banques découvrent à mesure que les visages et les documents générés par l'IA passent entre les mailles du filet des contrôles de connaissance du client (KYC), conçus pour un monde antérieur à l'IA générative. 

Les caméras interviennent à plusieurs moments clés du parcours d'authentification dans une application bancaire, et pas seulement lors de l'inscription. Le cas le plus évident est l'ouverture de compte : un nouveau client photographie une pièce d'identité officielle, puis prend un selfie ou une courte vidéo en direct afin que l'application puisse comparer le visage sur le document avec celui filmé et confirmer la présence physique d'une personne (détection de présence). De nombreuses banques déclenchent également une vérification par caméra dans le cadre d'une authentification renforcée : un virement important, une réinitialisation de mot de passe ou l'ajout d'un nouveau bénéficiaire peuvent entraîner une nouvelle vérification. Certains établissements effectuent des vérifications périodiques tous les un à deux ans, ou dès que les signaux de risque augmentent. Dans tous les cas, la caméra n'est pas le seul élément de sécurité ; elle est généralement associée à des vérifications de l'appareil, des codes d'accès à usage unique ou des signaux comportementaux. C'est pourquoi les attaques par deepfake sont souvent combinées à l'usurpation d'identité, aux logiciels malveillants, au phishing et à d'autres techniques pour contourner les différents niveaux de sécurité. 

Il est tentant de considérer la fraude par deepfake comme un problème unique avec une solution unique. Or, il ne s'agit pas d'un point de défaillance unique. La vérification KYC suit un processus complexe à plusieurs étapes, depuis la scène physique capturée par l'objectif, en passant par l'appareil, l'application, le modèle de décision embarqué, le réseau, la décision côté serveur, et enfin la session en cours. Un attaquant n'a besoin que d'une seule faille ; un défenseur doit sécuriser l'ensemble du processus. 

Aucun contrôle de sécurité unique ne couvre l'intégralité du processus, et plusieurs fournisseurs de sécurité ou composants développés en interne sont nécessaires pour sécuriser la surface d'attaque. Cet article décrit le processus de bout en bout, se concentre sur les trois étapes où un produit de renforcement applicatif et de protection contre les attaques par déni de service (RASP) comme Arxan Security apporte une réelle protection (étapes 2, 3 et 5), et présente un bilan transparent des acteurs qui interviennent dans le reste du processus.  

Surface d'attaque deepfake KYC : sept étapes de pipeline, chacune avec sa propre attaque et son propre contrôle.

Étape 1 — La couche physique / de présentation : Le visage est-il même réel ? 

Avant même que l'appareil ou l'application ne soit en action, l'attaque cible l'objectif lui-même : photos, écrans et masques. Les moteurs de détection d'attaques par présentation (PAD), évalués selon la norme ISO/IEC 30107-3, la détectent grâce à l'analyse des capteurs. Cette responsabilité incombe au fournisseur d'identité, qui utilise des techniques telles que l'analyse de texture, de profondeur et de réflexion, ainsi que des approches propriétaires, pour s'assurer de l'authenticité des éléments présentés à la caméra. 

Étape 2 — La couche appareil/capture : la caméra est-elle même réelle ? 

Cette étape aborde une question que la plupart des gens ne se posent jamais : la « caméra » utilisée pour la vérification d’identité est-elle réellement une caméra ? Sur un appareil rooté ou jailbreaké, ou au sein d’un émulateur, un attaquant peut remplacer le composant caméra et injecter une vidéo deepfake pré-rendue directement dans l’API de la caméra. Le logiciel reçoit alors des images d’apparence parfaite, mais contenant tout ce que l’attaquant souhaite. Il s’agit d’une attaque par injection, une étape essentielle pour intégrer des deepfakes basés sur l’IA dans l’application. 

Il s'agit là du domaine d'application principal de RASP : détection du root et du jailbreak, détection des émulateurs et détection de l'interception de l'API de la caméra pendant l'exécution de l'application. MASVS-Resilience-1 exige que l'application valide l'intégrité de la plateforme et couvre cet aspect de la protection contre les attaques par deepfake.  

Étape 3 — La couche d'exécution : L'application est-elle toujours l'application ? 

Supposons que l'appareil soit authentique. La question suivante est de savoir si le code de l'application effectuant la vérification a été altéré. Les acteurs malveillants interceptent ou modifient le logiciel d'identité à l'aide de frameworks d'instrumentation tels que Frida ou Xposed. Ils peuvent également reconditionner l'application en désactivant la vérification de présence, de sorte que la fonction de vérification renvoie simplement « réussi » quelle que soit l'image capturée par la caméra. 

Il s'agit du cas d'utilisation standard de protection contre la falsification, domaine d'expertise d'Arxan Security où nous sommes les pionniers et les meilleurs : obfuscation pour rendre le logiciel d'identité difficile à détecter, détection d'instrumentation et d'interception pour limiter les outils de piratage disponibles, et contrôles d'intégrité qui détectent les binaires modifiés lors de l'exécution. MASVS-Resilience-2, 3 et 4 correspondent directement à ces contrôles : protection contre l'analyse statique, l'analyse dynamique et la falsification. 

Étape 4 — La couche de décision côté client : le modèle embarqué a-t-il été trompé ? 

Lorsqu'une vidéo de synthèse est suffisamment convaincante pour tromper un modèle embarqué intact, seul un modèle plus performant peut faire la différence. La détection passive de présence et la détection des deepfakes embarqués relèvent des compétences des fournisseurs d'identité — les mêmes fournisseurs qu'à l'étape 1, mais dans un domaine différent. 

Étape 5 — La couche transport : ce résultat provient-il réellement de l’application ? 

Même avec un appareil sécurisé et une application intacte, le résultat de la vérification doit parvenir au serveur. Les cybercriminels ciblent cette étape par des interceptions de type « homme du milieu », des attaques par rejeu et des abus directs de l'API. Ils utilisent notamment des techniques comme la capture d'une réponse « vérifiée » légitime et sa réutilisation, ou encore le contournement de l'application et la communication directe avec l'API KYC avec des résultats falsifiés. 

Les contrôles standard sont bien connus : chiffrement de bout en bout, attestation des applications clientes, épinglage de certificats et conception d'API sécurisée. Arxan Security propose l'épinglage de certificats et une cryptographie en boîte blanche, utilisables pour un chiffrement de bout en bout sécurisé, l'attestation et des protocoles tels que le TLS mutuel (mTLS). Dans une évaluation classique des menaces de type « homme du milieu » (MitM), l'attaquant se concentre exclusivement sur l'interception des communications. Pour les applications clientes, comme les applications bancaires, les acteurs malveillants contrôlent les couches matérielles, logicielles et de communication. La cryptographie en boîte blanche d'Arxan va plus loin et protège la couche transport en sécurisant la clé présente dans le binaire et la mémoire de l'application. L'association de la cryptographie en boîte blanche avec le chiffrement de bout en bout et les protocoles d'attestation empêche les acteurs malveillants de pénétrer la couche transport. Plus d'informations sur les contrôles MitM sont disponibles ici : https://digital.ai/catalyst-blog/quand-l'attaquant-est-le-client-qui-se-défend-contre-les-attaques-de-l'homme-du-monde/  

Étape 6 — La couche de décision côté serveur : le système dorsal a-t-il détecté ce que l’appareil a manqué ? 

À l'instar de la couche de décision côté client, tout ou partie du modèle de traitement des images de la caméra peut être géré côté serveur. L'architecture client/serveur varie selon le fournisseur d'identité, la plateforme et le logiciel applicatif. La revérification côté serveur, l'analyse des signaux et la logique de décision et d'orchestration propre à l'entreprise permettent de détecter les éléments non pris en compte par le modèle côté client.  

Étape 7 — Couche comportementale/de session : Le reste de la session ressemble-t-il toujours au client ? 

Les acteurs malveillants présentent souvent un schéma comportemental différent de celui des utilisateurs typiques. L'évaluation continue des risques, l'empreinte digitale des appareils et la biométrie comportementale sont gérées par des plateformes de gestion des risques et de la fraude ou par un moteur de risque interne, et non par le fournisseur d'identité ou la couche RASP. 

Pourquoi la frontière est importante 

La sécurité logicielle repose sur une approche de défense en profondeur. Cela implique de superposer différentes fonctionnalités de sécurité, telles que l'obfuscation et la vérification d'intégrité, à un développement applicatif et une infrastructure sécurisés. La clarté des responsabilités à chaque étape est essentielle à l'efficacité de la défense. Un fournisseur de solutions de détection d'attaques par présentation (PAD) et de vérification de la vivacité, même parmi les meilleurs, est inutile si le binaire exécutant son SDK peut être modifié pour renvoyer systématiquement « réussi ». De même, une couche RASP robuste ne peut détecter un deepfake sophistiqué présenté à une application non altérée. 

Le système ne fonctionne que si chaque responsable d'étape assume pleinement ses responsabilités. D'après notre expérience, la fraude contourne généralement les contrôles les plus rigoureux et exploite plutôt les failles de sécurité.  

A Retenir 

Les solutions de renforcement des applications et RASP d'Arxan Security atténuent trois des sept étapes de la surface d'attaque des deepfakes KYC., et ils sont Les trois étapes qu'un fournisseur d'identité ne peut pas couvrir seul. Au niveau de l'appareil/de la capture, la détection du root, du jailbreak, de l'émulateur et de l'interception de l'API caméra empêche un attaquant d'injecter un deepfake avant même qu'une seule image n'atteigne le SDK d'identité. Au niveau de l'exécution — notre domaine de prédilection d'origine, où nous restons la référence — l'obscurcissement, l'instrumentationLa détection des interceptions et les contrôles d'intégrité binaire empêchent les attaquants de simplement modifier le contrôle de vivacité pour qu'il renvoie toujours « réussi ». Au niveau de la couche transport, L'épinglage de certificats et la cryptographie en boîte blanche garantissent que le résultat « vérifié » parvenu au serveur est bien celui produit par l'application, et non une version rejouée ou falsifiée. résultatChacune de ces commandes correspond directement à MASVS.-Les quatre premières étapes de résilience offrent aux clients une norme vérifiable justifiant leur affirmation. Négliger l'une d'entre elles peut compromettre, falsifier ou intercepter le résultat d'un fournisseur d'identité fiable avant même qu'il n'atteigne le système dorsal. Le fournisseur d'identité, la pile décisionnelle côté serveur et la plateforme de gestion des risques et de la fraude sont responsables des quatre autres étapes. tout en C'est Arxan Security qui garantit la fiabilité de leurs résultats de bout en bout.