KYC : Contourner la vérification d'âge avec des modèles génératifs vidéo

Introduction

Le KYC (Know Your Customer) ou « Connaissez votre client », est un processus qui vise à lier une personne physique à un utilisateur en s'assurant de son identité. Historiquement, cette pratique était surtout réservée aux institutions financières. Aujourd'hui, elle s'applique et tend à s'appliquer à de plus en plus de services en ligne. L'objectif est de créer un lien de confiance : l'entreprise doit savoir précisément à qui elle s'adresse avant de fournir un service. Avec le renforcement des lois numériques, le KYC est devenu une étape obligatoire pour lutter contre les crimes facilités par le monde du numérique, comme l'usurpation d'identité ou le blanchiment d'argent. Plus récemment, de nombreux pays renforcent l'appareil législatif afin de rendre la vérification d'âge obligatoire pour l'accès à certains services en ligne avec en ligne de mire les sites pornographiques et les réseaux sociaux. 

Cet article cherche à établir un état de l'art sur les méthodes de KYC et les techniques de contournement existantes. Nous comparerons des solutions de contournement basées sur l'intelligence artificielle, en utilisant des modèles locaux et une infrastructure peu coûteuse, et un équivalent cloud (deepfake-as-a-service). Nous le clôturerons avec un exemple concret de contournement de la vérification d'âge sur un site pour adulte. Si c'est principalement cette partie qui vous intéresse, vous pouvez la retrouver ici.

Les référentiels

Pour encadrer ces vérifications de manière technique, plusieurs normes ont été créées. En France, l'ANSSI a mis en place le référentiel PVID (Prestataire de Vérification d'Identité à Distance). Il impose des tests de « preuve de vie » pour s'assurer que l'utilisateur est physiquement présent derrière sa caméra et qu'il n'utilise pas une simple photo, une vidéo pré-enregistrée ou un masque.

Au niveau européen, c'est le règlement eIDAS qui sert de cadre. Son but est d'harmoniser les pratiques entre les pays membres : une identité numérique validée dans un pays doit pouvoir être reconnue partout dans l'Union européenne. D'ailleurs, le référentiel PVID est conçu pour répondre au moins aux exigences de l'eIDAS.

À l'international, les approches varient selon les zones géographiques. Les États-Unis, par exemple, n'ont pas de référentiel centralisé. Les obligations sont basées sur le risque et dépendent grandement du secteur d'activité. Un exemple de ligne directrice est le NIST SP 800-63 qui se rapporte à l'identité numérique et se concentre sur l'analyse de données de contexte. Dans d'autres pays, comme l'Inde avec le système Aadhaar, l'État utilise une base de données biométrique centralisée pour identifier chaque citoyen.

Les enjeux du KYC

Pour les entreprises, l'enjeu est avant tout l'équilibre entre conformité et expérience client. D'un côté, le respect des normes comme le PVID est une obligation légale stricte pour certaines activités comme le dispositif LCB-FT imposé au secteur financier. De l'autre, le KYC est le premier point de contact avec l'utilisateur. S'il est trop complexe ou trop long, il peut créer une friction qui peut pousser le client à abandonner le processus. Le défi consiste donc à proposer un parcours de vérification qui soit à la fois robuste et fluide pour l'utilisateur.

Côté utilisateurs, le KYC est souvent perçu comme une contrainte, oscillant entre sécurité et vie privée. Dans un monde où l'usurpation d'identité numérique est très présente, ces procédures garantissent que personne ne pourra ouvrir un compte bancaire ou souscrire un crédit en leur nom. Cependant, cela implique de confier des données sensibles (pièce d'identité, données biométriques, etc) à des plateformes tierces. L'enjeu pour l'utilisateur est donc la confiance : il accepte la contrainte du KYC à condition que ses données soient protégées et que le processus ne soit pas excessivement intrusif.

Plus récemment, en plus du secteur financier et des jeux d'argent en ligne, les sites pornographiques et les réseaux sociaux sont mis sous le feu des projecteurs. En France, la loi du 21 mai 2024 charge l'ARCOM d'établir les exigences de vérification d'âge. Cette autorité est alors en mesure de prononcer le blocage ou le déréférencement des plateformes ne répondant pas à ces exigences. Un certain nombre de sites pornographiques ont déjà fait face au déréférencement, en particulier Pornhub, 4ᵉ site le plus visité en France avec 417 millions de visiteurs en 2022. La conséquence est alors une baisse d'environ 28% du trafic en France sur le 2ᵉ semestre 2025, pourtant un des pays les plus représentés sur le site avant le blocage. Cette baisse de trafic n'est cependant pas totale, en effet, la loi désigne que l'accès depuis l'espace géographique français (par IP). L'utilisation de VPN rend alors l'accès au site possible, y compris pour les mineurs.

Le référentiel PVID

Le référentiel PVID définit un cadre technique très rigoureux visant à garantir que l'identité numérique délivrée dispose de la même valeur qu'une confirmation en face-à-face.

L'ANSSI définit trois phrases principales dans ce processus :

1. L'acquisition de donnée : l'utilisateur est guidé pour capturer des images ou des vidéos du titre d'identité ainsi que des données biométriques (selfie vidéo, challenge dynamique).
2. La vérification de donnée : le système vérifie l'authenticité et la validité du titre d'identité et procède à l'évaluation de la preuve de vie. La vérification comporte souvent une validation par un opérateur humain. Cette vérification n'est pas rendue obligatoire par le référentiel en dehors de la levée de doute ou d'alerte par le système automatisé. En pratique, le référentiel impose la même garantie qu'un face à face avec "une personne formée de manière générale à la comparaison de visages", faisant de l'humain une composante récurrente dans un service conforme au référentiel.
3. La décision : le système renvoie le verdict du processus (succès ou échec). En plus du verdict, le prestataire PVID doit constituer et conserver un dossier de preuve, contenant tous les éléments appuyant la décision, en cas de litige.

Le schéma suivant illustre le processus PVID dans les grandes lignes. À noter que le référentiel ne vise pas à imposer des technologies, mais seulement le cadre. Il est donc possible d'implémenter une solution PVID conforme qui diffère en partie de ce schéma.

L'eIDAS sur lequel se base le PVID définit deux niveaux de sécurité. Le premier est le niveau substantiel. Ce niveau tend à réduire, comme son nom l'indique substantiellement le risque d'usurpation. Il vise les cas d'usages classiques du KYC PVID (par exemple, l'ouverture de compte bancaire). C'est celui qui garantit la valeur du face-à-face. Aujourd'hui, quatre opérateurs sont certifiés au niveau substantiel en France : Docaposte IOT, IDnow, NjF Vision et Namirial.

Le second niveau est le niveau élevé. Il est réservé à des actions sensibles comme la signature électronique qualifiée (signature électronique de niveau 3 et 4) ou des actes notariés. Ce niveau est l'équivalence de la délivrance d'un titre d'identité en mairie ou en gendarmerie. À noter qu'aucun opérateur n'est actuellement certifié par l'ANSSI pour ce niveau. Il reste donc aujourd'hui théorique uniquement pour ce référentiel.

Enfin, le PVID impose également des contraintes de souveraineté et de sécurité informatique : le prestataire doit protéger l'intégrité des données capturées contre l'interception et s'assurer que l'environnement d'exécution n'a pas été compromis. Cependant, cet aspect n'entre pas dans la surface d'attaque considérée par la majorité des attaquants, et ne sera donc pas approfondi dans cet article.

État de l'art

Comme décrit dans la partie précédente, le référentiel PVID utilise plusieurs données, dont des images du titre d'identité et du visage de l'utilisateur. Dans le cadre de cette étude, nous nous plaçons en tant qu'attaquant en possession d'un titre d'identité valide pour un tiers.

Un contournement d'un système de KYC nécessite deux vecteurs : des images capables d'outrepasser l'analyse de la preuve de vie, et un moyen de présenter ces images au système. Nous parlerons d'injection pour désigner la présentation des images frauduleuses.

Injection de données

En ce qui concerne l'injection, le référentiel PVID prévoit deux cas principaux :

• la présentation physique à la caméra (une photo, un masque, du maquillage) ;
• l'injection d'une vidéo en remplaçant la source de données lors de la phase d'acquisition.

De nos jours, les systèmes de détections du vivant modernes n'ont quasiment aucune chance d'être trompés par une présentation physique sans moyens importants. En effet, seule l'utilisation de masques en latex utilisés pour le cinéma et faits sur mesure accompagnés d'une prestation de maquillage adéquate permet d'obtenir de bons résultats pour un cout assez important (environ 10 000€). La suite de cet article se concentrera donc sur les méthodes d'injections au niveau de l'acquisition.

Il existe aujourd'hui plusieurs techniques pour injecter une vidéo pré-enregistrée ou générée à la volée à l'aide de l'intelligence artificielle. Il est par exemple possible d'utiliser des drivers kernel pour émuler des sources d'images, et les utiliser lors de la capture. C'est ce qui est fait par les caméras virtuelles d'OBS. Sur un appareil que vous maîtrisez totalement, il est possible d'ajouter une caméra virtuelle très simplement. Sous Linux, le module kernel v4l2loopback permet cette manipulation :

$ modprobe v4l2loopback devices=1 video_nr=10 card_label="Logitech HD Pro Webcam C920" exclusive_caps=1 max_buffers=2

Cette nouvelle caméra virtuelle sur laquelle on injecte un flux vidéo peut être utilisé dans un navigateur par exemple :

En streamant une vidéo sur le nouvel équipement :

$ ffmpeg -re -stream_loop -1 -i demo.mp4 \
    -f v4l2 -vcodec rawvideo -pix_fmt yuv420p \
    -s 1920x1080 -r 60 \
    /dev/video10

Dans le cas où la procédure de KYC est à effectuer sur un smartphone (ce qui est souvent le cas), il est possible d'intercepter les appels vers l'API des caméras avec Frida et rediriger les buffers pour qu'ils lisent depuis un fichier MP4 et non le capteur physique. De même, en passant par un émulateur mobile, les caméras virtuelles seront facilement configurables pour s'appliquer à notre besoin.
    
L'ensemble de ces techniques, historiquement efficaces et faciles d'implémentation, sont combattues par plusieurs mesures des opérateurs de KYC. L'objectif est de ne plus traiter naïvement la donnée reçue par le serveur, et ainsi être en capacité de vérifier l'origine de la vidéo.

Les mesures les plus efficaces concernent les captures faites depuis un smartphone. Il est par exemple possible d'utiliser le mécanisme d'attestation de capteur. L'application peut solliciter le Secure Element de l'appareil, s'il en dispose, pour signer un buffer. Si la vidéo provient d'une autre source (buffer Frida ou caméra virtuelle), la signature sera invalide ou manquante.

Dans le même esprit, pour garantir que l'exécution de l'application est faite sur un smartphone, les API Play Integrity pour Android et App Attest pour iOS vont permettre de vérifier si l'application ne tourne pas dans une machine virtuelle ou sur un appareil rooté (principalement en analysant la mémoire et les propriétés du système). Forcer l'intégrité du smartphone est une première mesure possible pour contrer les attaquants opportunistes. Cependant, forcer l'utilisation de ces mécanismes disqualifie d'emblée tout système d'exploitation mobile alternatif ne proposant pas ces mécanismes.

Enfin, une des forces de la capture sur smartphone est l'accès à des données de mouvement. Les solutions KYC ont donc la possibilité d'utiliser les métriques de mouvement (accélérométrie). Ces données permettent d'analyser le bruit de fond accélérométrique. En effet, tenir un smartphone en main crée des tremblements. Si l'accéléromètre renvoie une valeur fixe, ou une boucle, la solution peut conclure qu'une injection de donnée est probablement en cours. En plus de la valeur seule, il est possible de corréler la valeur avec les images vidéos. Même si les valeurs gyroscopiques ne sont pas suspectes en elles-mêmes, si elles sont incohérentes avec les images fournies par les capteurs vidéo, c'est également un signal fort d'une injection d'images.

D'autres méthodes de détection, plus génériques, existent aussi. Ces dernières ne sont pas propres à l'utilisation d'un smartphone, et peuvent être appliquées dans un environnement de bureau. Les vérifications peuvent être effectuées côté serveur ou côté client, avec WebAssembly. C'est régulièrement la deuxième option qui est choisie, car elle offre des capacités de télémétrie en temps réel et sans intermédiaire, donc plus précises. La vérification de la cohérence matérielle permet d'abord de comparer le nombre de cœurs CPU déclarés par le navigateur avec la performance réelle mesurée via des boucles de calcul intensives en WASM, un décalage trahissant souvent un environnement émulé. Ensuite, la détection d'horloge utilise les compteurs de WASM pour détecter les micro-latences induites par un débogueur ou pour distinguer une horloge matérielle authentique d'une horloge virtualisée, généralement plus irrégulière. Enfin, des mesures d'anti-hooking ciblent l'interception de fonctions telles que navigator.mediaDevices.getUserMedia : le module vérifie si la fonction pointe bien vers du code natif et s'assure qu'aucun "monkeypatching" n'a été appliqué. Par exemple, dans le cas où des contraintes de format de vidéos seraient trop importantes, le code suivant permet de hook la fonction getUserMedia, et de diminuer la contrainte de résolution pour accepter n'importe quelle vidéo.

// Save original function
const originalGetUserMedia = navigator.mediaDevices.getUserMedia
// hook function to intercept contraints
navigator.mediaDevices.getUserMedia = async function(constraints) {
  // Delete unecessary keys to remove the need to provide them
  for (const key of ["facingMode", "frameRate", "deviceId"]) {
    if (constraints && constraints.video && Object.hasOwnProperty.call(constraints.video, key)) {
      delete constraints.video[key];
    }
  }
  // Relax mandatory keys to broader values
  if (constraints && constraints.video) {
    constraints.video.width = { min: 1, ideal: 1920, max: 3840 };
    constraints.video.height = { min: 1, ideal: 1080, max: 2160 };
  }
  // Call original function with new contraints
  return originalGetUserMedia.call(navigator.mediaDevices, constraints);
};

À noter que présenter des vidéos de faible qualité a de multiples avantages, comme le temps de génération, un plus faible niveau de détail permettant de rendre plus complexe la détection. Il est donc parfois nécessaire de procéder à de l'upscaling de la qualité et du nombre d'images par seconde d'une vidéo initiale, pour répondre à des contraintes fortes. Des audits menés par Synacktiv ont révélé que l'implémentation de l'algorithme de Lanczos (pour la résolution) et la fonction de "Motion Interpolation" (pour le nombre d'images par seconde) de l'outil FFmpeg offrent un bon rapport résultat/durée d'exécution. La commande suivante permet d'upscaler une vidéo en 480p vers de la 720p, et de passer de 25 à 30fps.

$ ffmpeg -i input.mp4 -vf "scale=1280:720:flags=lanczos,minterpolate=fps=30" -c:v libx264 -c:a copy output.mp4

Enfin, il est crucial de noter que si le processus de KYC n'impose pas l'usage d'une application mobile native, la vérification par webcam sur navigateur (Desktop) constitue la voie de moindre résistance pour un attaquant. Sur un système d'exploitation de bureau, l'isolation entre le navigateur et le système est bien moins stricte. Les caméras virtuelles y sont perçues comme des périphériques standards et les APIs de capture web (WebRTC) n'ont pas encore de mécanismes de "chaîne de confiance" aussi matures que ceux des environnements mobiles. Si le workflow permet de basculer sur un ordinateur, l'attaquant privilégiera systématiquement ce vecteur pour sa simplicité de manipulation.

Contournement de la preuve de vie

Il est raisonnable de supposer que les mesures anti-injections seront contournées par des attaquants déterminés. Ce chapitre fera donc l'inventaire des principales mesures de preuve de vie qui est la phase déterminante durant un processus de KYC.

Techniques de détection

Il existe trois catégories de techniques de détection : La détection passive, la détection active et la vérification humaine. Évidemment, combiner des techniques venant des trois catégories améliore grandement l'efficacité d'une solution de détection.

Détection passive

La détection passive analyse le flux vidéo sans imposer d'action particulière à l'utilisateur. L'objectif est de détecter des signaux physiologiques ou physiques impossibles à reproduire fidèlement avec une photo ou une vidéo rejouée.

Un premier axe repose sur l'analyse texturale et spectrale. Une impression papier ou un écran présente une texture uniforme et une réflexion lumineuse homogène, caractéristique d'une surface plane. À l'inverse, la peau humaine présente des micro-variations de texture et une réflexion localisée (principalement sur le front, le nez et les pommettes). Ces propriétés sont analysées via des descripteurs de texture comme les LBP (Local Binary Patterns) ou des CNN entraînés spécifiquement sur des jeux de données de fraude.

Ensuite, les algorithmes modernes intègrent une analyse des micro-mouvements. La respiration, les saccades oculaires ou les micro-expressions faciales produisent des déformations de l'image dont la distribution fréquentielle est caractéristique d'un être vivant. Un deepfake serait plus susceptible de présenter soit une absence de ces signaux, soit une distribution trop régulière.

Enfin, plus récente et particulièrement robuste, est la détection du signal cardiaque par rPPG (remote photoplethysmography). En analysant les variations infimes de couleur à la surface du visage causées par le flux sanguin, il est possible d'extraire un signal de fréquence cardiaque. Une photo ou une vidéo pré-enregistrée ne présente évidemment pas ce signal, ou le présente de façon incohérente avec les conditions de capture. Cette méthode est néanmoins sensible aux variations d'éclairage et à la compression vidéo, ce qui en fait une bonne technique théorique, difficilement applicable à des processus KYC dans des environnements non contrôlés.

Détection active

Contrairement à la détection passive, la détection active repose sur des challenges, et demande donc une action de la part de l'utilisateur, ou au moins crée activement une interaction avec ce dernier.

Le challenge le plus répandu est le mouvement de tête : l'utilisateur est invité à tourner la tête selon des instructions affichées à l'écran. L'aléatoire de la séquence vise à rendre inopérant le rejeu d'une vidéo pré-enregistrée. Ce challenge est aussi relativement efficace contre les deepfake classiques appliquant un masque se retrouvant déformé à partir d'un certain angle. Couplé à une contrainte temporelle stricte, ce mécanisme est relativement efficace contre les attaques opportunistes.

Dans le même esprit se trouvent les challenges vocaux. L'utilisateur est invité à prononcer une séquence de mots. En plus de la synchronisation des lèvres, certaines implémentations croisent l'analyse audio avec les mouvements faciaux pour détecter toute incohérence entre les deux flux.

Une troisième approche plus sophistiquée, développée et brevetée par iProov sous le nom de Flaskmark, repose sur la projection de flashs lumineux colorés via l'écran du dispositif sur le visage de l'utilisateur. La séquence étant aléatoire, la solution repose sur la difficulté à reproduire des réflexions lumineuses sur le visage en quasi-temps réel avec un modèle d'IA. Cette solution a l'autre grand avantage de ne pas nécessiter d'action directe de l'utilisateur, bien que s'agissant d'une solution active.

Vérification humaine

La vérification humaine reste, à ce jour, l'un des mécanismes les plus difficiles à tromper de façon systématique. Des opérateurs entraînés à la détection de faux vérifient manuellement les vidéos de vérification : ils cherchent des incohérences sur le visage comme des "glitch", et détectent des incohérences contextuelles comme un éclairage artificiel, des contours suspects autour du visage ou un comportement hésitant de l'utilisateur.

Cependant, la vérification humaine n'est pas sans limites. La fatigue, les biais cognitifs et la cadence de traitement des centres de vérification peuvent mener à des erreurs de vérification. Par ailleurs, les deepfakes générés par des modèles vidéo génératifs récents atteignent un niveau de réalisme suffisant pour tromper un observateur non spécialiste, notamment lorsque la qualité de la vidéo est dégradée.

Contournement par Intelligence Artificielle

Les récentes évolutions dans le domaine de l'intelligence artificielle ont vu émerger des modèles de diffusion permettant de réaliser plusieurs types de tâches :

• image-to-video : Génération d'une vidéo à partir d'une image de référence et d'un prompt ;
• text-to-video : Génération d'une vidéo à partir d'un prompt écrit décrivant le contenu de la vidéo souhaitée ;
• video-to-video : Modification d'une vidéo à partir d'une autre vidéo et d'un prompt d'instructions ;
• video-to-text : Description textuelle d'une vidéo, souvent embarquée dans des modèles dits "vision", comme la dernière série de modèles Qwen3.6.

 
Une large offre de modèles couvrant des besoins plus spécifiques est également proposée : estimation de profondeur, détection d'objet, classification etc...
 
La catégorie video-to-video nous intéresse particulièrement dans le cas de la génération de deepfake car elle permet d'obtenir des mouvements plus naturels en fournissant une vidéo d'un acteur en entrée. L'offre de modèles vidéo est très riche aussi bien en open-source qu'en closed-source où une partie des acteurs principaux comme Alibaba publient les anciennes versions de leurs modèles closed-source en open-source sur la plateforme huggingface.

Le modèle open-source le plus emblématique de la catégorie video-to-video est Wan2.2 Animate, développé par Alibaba (également auteurs de la suite Qwen). Ce modèle de 14 milliards de paramètres permet de remplacer une personne dans une vidéo par une autre personne avec pour seule référence une photo.

Les avantages face aux traditionnels deepfakes sont multiples. Premièrement, les deepfakes se basant sur une approche de face-swapping nécessitent une phase d'entraînement plus ou moins longue pour obtenir des résultats convaincants. Les modèles vidéo génératifs eux ne nécessitent aucune phase d'entraînement. Le revers de la médaille est le temps de rendu légèrement plus long. Ensuite, afin d'obtenir un résultat convaincant, il était nécessaire d'avoir une morphologie et une pilosité similaire à celle de la victime. En effet, les deepfakes traditionnels ne font qu'appliquer le masque de la victime sur la vidéo de référence. Ainsi, les proportions du visage sont déformées et les cheveux ne sont pas remplacés.

L'approche d'utilisation de modèles vidéo génératifs est légèrement différente, le modèle Wan 2.2 Animate nécessite un masque de pose afin d'extraire les mouvements du visage pour ensuite animer l'image de référence. Ainsi, aucun masque n'est appliqué par-dessus le visage original, ce qui vient supprimer l'apparition de contours évidents que l'on peut retrouver sur un deepfake et surtout les proportions de la victime sont conservées. En particulier, les mouvements de tête ne laissent pas apparaitre de déformation du masque.

En dépit de ces nombreux avantages, quelques points d'amélioration subsistent. En particulier, le mouvement des yeux et de la bouche est souvent imparfait. Ces points ont en outre été remontés par les opérateurs lors d'audits PVID.

Comme évoqué plus tôt, certains challenges reposent sur l'utilisation de flashs lumineux sur l'utilisateur. Parmi les deux modèles testés, seul Wan 2.2 Animate prend en compte la variation de l'environnement lumineux.

Le passage d'objet devant le visage de la personne, les mouvements de tête et la prononciation de mots fonctionnent également avec un niveau de réalisme tout à fait correct.

Deux approches ont été évaluées pour la génération de deepfake vidéo génératif :

• Solution auto-hébergée sur un serveur équipé d'une carte graphique NVIDIA RTX 5090 (32Go VRAM);
• Solution hébergée dans le cloud avec Comfy Cloud.

ComfyUI

Les deux approches utilisent l'interface ComfyUI pour son intuitivité, le grand nombre de workflows et composants disponibles. En effet, de nombreuses plateformes proposent des solutions clés en main pour réaliser des deepfakes vidéo génératif (Kling, Wan, Luma, Higgsfield). Cependant, la flexibilité apportée par Comfy, notamment la possibilité de combiner plusieurs tâches dans un workflow unique et la finesse des réglages nous ont orientés vers cette solution.

Présentation de l'interface

L'interface propose de relier des blocs fonctionnels entre eux afin de constituer un workflow. Chacun de ces nœuds (blocs) correspond à une fonction Python sous forme de boite noire acceptant des paramètres et des sorties de différentes natures : images, vidéo, nombre, texte, etc. Chaque nœud peut ensuite être relié via un couple input/output de même type (par exemple, un output de type image peut être renvoyé vers un input de type image sur un autre nœud).

Un ensemble de nœuds constitue un workflow pouvant être exporté et réutilisé clé en main par la communauté. Une bibliothèque de modules additionnels développés par la communauté permet d'ajouter de nouveaux nœuds, de télécharger des modèles directement depuis Huggingface ou même des workflows.

Performances

Bien que les workflows soient fortement optimisés pour réduire l'utilisation de VRAM, il est intéressant de faire varier les différents paramètres, notamment la taille de modèles utilisés pour optimiser au mieux les ressources et trouver un point d'équilibre entre qualité et vitesse.

En effet, nombre de plateformes de KYC imposent un temps contraint entre l'envoi d'un challenge et la résolution de celui-ci. Le temps est volontairement assez généreux pour prendre en compte les contraintes techniques comme les coupures de connexion ou les connexions lentes. Ainsi, le défi est bien souvent d'optimiser chaque nœud du workflow pour obtenir un résultat rapide.

Le temps de traitement d'un workflow est fortement influencé par la résolution des données d'entrée. Par exemple, la génération d'une vidéo en 1080p à 60 FPS est beaucoup plus longue qu'une vidéo en 360p à 20 FPS. Il convient alors d'identifier les limites techniques acceptées par le service de KYC. Comme présenté plus tôt, il est également possible de procéder à de l'upscaling de résolution et à de l'injection de frame, ces procédés étant bien souvent bien moins coûteux en temps de calcul.

En optimisant le workflow afin de produire des vidéos de 5 secondes au format 480x720p30FPS avec une RTX 5090, le temps de rendu est d'environ 3 minutes avec le modèle Wan 2.2 14B Animate.

À titre de comparaison, l'utilisation d'un workflow similaire avec le modèle closed-source Kling 3.0 sur Comfy cloud prend environ 7 minutes (les performances sont assez décevantes et probablement expliquées par le temps d'attribution d'un GPU).

Démonstration

Afin d'illustrer les capacités de contournement d'un système de KYC non PVID sur un cas concret utilisant la vérification d'âge, un site de vidéo pour adultes a été sélectionné. D'autres exemples existent comme des banques, mais pour des questions de légalité, ils n'ont pas été retenus (la création de comptes bancaires sous une fausse identité étant répréhensible par la loi).

Lors de l'accès au site depuis la France, le traditionnel formulaire demandant de valider la majorité du visiteur a été remplacé par un message informant que la législation française demande une vérification d'âge proposée par le service anglais AgeGo.

Ce service propose plusieurs méthodes de vérification :

• Selfie : Vérification vidéo du visage de l'utilisateur nécessitant d'aligner sa tête dans un cercle. Vérification algorithmique uniquement.
• Selfie + pièce d'identité : Comparaison d'une pièce d'identité avec la méthode précédente.
• Carte bancaire (non disponible en France) : Vérification à partir d'une carte bancaire, aucune vérification biométrique.
• Identité numérique : Utilisation de l'application Yoti Digital ID. Cette méthode reprend alors le mécanisme Selfie + pièce d'identité.

Sur le site analysé, seules les méthodes Selfie et Yoti sont disponibles :
 

Pour cette démonstration, la méthode la plus simple a été choisie, la vérification par Selfie. Une fois cette méthode sélectionnée, le challenge est relativement simple et utilise un modèle de machine learning local pour la détection de visage (Blazeface 1.0.2 avec TensorFlow.js) et AWS Rekognition.

AWS Rekognition propose plusieurs services de reconnaissance vidéo (identification de célébrité, vérification d'âge, de genre etc...). Plusieurs types de challenges sont proposés par ce service, ici FaceMovementChallenge. Le service assure mettre en place des mécanismes de détection de Deepfake, d'injection de vidéo pré-enregistrée ou de masques physiques.

Analyse du processus de vérification

Le mécanisme de vérification commence par la création d'une session server-to-server tel que décrit par la documentation du service AgeGo via la requête suivante :

GET /s2s/start/?nonce=n8c4zzfpme1mo8zy&isu=d3d3Lnh2aWRlb3MuY29t&siteid=73&ch=eyJicmFuZHMiOlt7ImJyYW5kIjoiTm90L0EpQnJhbmQiLCJ2ZXJzaW9uIjoiOCJ9LHsiYnJhbmQiOiJDaHJvbWl1bSIsInZlcnNpb24iOiIxNDIifSx7ImJyYW5kIjoiR29vZ2xlIENocm9tZSIsInZlcnNpb24iOiIxNDIifV0sIm1vYmlsZSI6ZmFsc2UsInBsYXRmb3JtIjoiV2luZG93cyIsImFyY2hpdGVjdHVyZSI6ImFtZDY0IiwiYml0bmVzcyI6IjY0IiwibW9kZWwiOiIiLCJwbGF0Zm9ybVZlcnNpb24iOiIxMCIsImZ1bGxWZXJzaW9uTGlzdCI6W3siYnJhbmQiOiJOb3QvQSlCcmFuZCIsInZlcnNpb24iOiI4In0seyJicmFuZCI6IkNocm9taXVtIiwidmVyc2lvbiI6IjE0MiJ9LHsiYnJhbmQiOiJHb29nbGUgQ2hyb21lIiwidmVyc2lvbiI6IjE0MiJ9XX0%3D HTTP/2
Host: myapi.agego.com
[...]

Les paramètres suivants sont présents :

• nonce : Nonce utilisé par la suite pour éviter les attaques par rejeu ;
• isu : Identifiant propre à l'utilisateur ;
• siteid : Identifiant du site ;
• ch : Structure JSON décrivant le navigateur utilisé par l'utilisateur.

L'endpoint GET /api/session/self renvoie les attributs de l'utilisateur :

{
    "is_user": false,
    "is_valid": true,
    "site_id": 73,
    "site_name": "Xvideos",
    "is_verified": false,
    "logo_filename": "site_logos/466d1cdb426a9ac6eb142711243bed20.png",
    "methods": [
        "photo-age-with-id-fallback",
        "yoti-age-verification"
    ],
    "doubleAnonymityMethods": [
        "photo-age-with-id-fallback",
        "yoti-age-verification"
    ],
    "origin": "AS8QfJEaDuPbmiYUILNw4Jm5j2LjX8FI9HuHqO",
    "is_child": false,
    "should_register": false,
    "has_otp": false,
    "passkey_scanned": false
}

On peut y lister les méthodes de vérification disponibles et l'état de vérification de l'utilisateur avec l'attribut "is_valid".

L'endpoint GET /api/config/aws intervenant un peu plus tard dans le processus renvoie une Identity Pool Cognito :

{
    "region": "eu-west-1",
    "cognito_identity_pool_id": "eu-west-1:9ad6f3b1-6a50-4392-adb2-afc0dbb92fba"
}

Cognito est un service d'IAM d'AWS permettant d'intégrer des mécanismes d'authentification et de gestion des utilisateurs. Une Identity Pool est un répertoire d'identités fédérées pouvant être utilisées pour demander des identifiants permettant d'accéder à des services AWS.

On constate alors que l'application récupère des identifiants pour cette même Identity Pool via l'action AWSCognitoIdentityService.GetCredentialsForIdentity :

POST / HTTP/2
Host: cognito-identity.eu-west-1.amazonaws.com
[...]

{"IdentityId":"eu-west-1:607701a0-6de1-c5fb-e37c-35389610fb49"}

[...]
HTTP/2 200 OK
{
    "Credentials": {
        "AccessKeyId": "ASIAWA5YBUBW3U5OKT4X",
        "Expiration": 1774014481,
        "SecretKey": "HES[...]cpv",
        "SessionToken": "IQoJb3JpZ2luX2VjEG0aCWV1LXdlc3QtMSJGMEQCIHuxUMGnJLS0T4RUTyT3p/[...]
    },
    "IdentityId": "eu-west-1:607701a0-6de1-c5fb-e37c-35389610fb49"
}

Ces identifiants pourraient être directement utilisés sur l'API ou la CLI AWS pour accéder à des services.

Avant le lancement du challenge, une session de vérification est créée sur l'API AgeGo qui fournit un token utilisé par la suite pour obtenir les résultats du service Rekognition :

GET /api/verify/photo-age-fallback/create-liveness-session HTTP/2
Host: myapi.agego.com
X-Ag-Sid: CCLhOA2plrO6YYWB39k5MjGepIgqbBZxtMQWBlIGtm18ZH2NQCIbA7DBZ130Ul
X-Verification-Method: photo-age-with-id-fallback
[...]

HTTP/2 200 OK
[...]
{"token":"3b41c11e-c1b7-425d-8b16-afab79c3c942","provider":"aws"}

Une session websocket est lancée via l'endpoint GET /start-face-liveness-session-websocket sur l'hôte streaming-rekognition.eu-west-1.amazonaws.com (service hébergé en Irlande). 

GET /start-face-liveness-session-websocket?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAWA5YBU[...]0320%2Feu-west-1%2Frekognition%2Faws4_request&X-Amz-Date=20260320T124823Z&X-Amz-Expires=299&X-Amz-Security-Token=IQoJ[...]ZYh&X-Amz-Signature=047915034c671cd8ce42c01cd91c1e470645124bfa4f64dd671c9c6f2add2481&X-Amz-SignedHeaders=host&attempt-count=2&challenge-versions=FaceMovementAndLightChallenge_2.0.0%2CFaceMovementChallenge_1.0.0&precheck-view-enabled=0&session-id=bdaf1a7f-3847-4f67-aa13-5abe70a9bd0e&video-height=1080&video-width=1920&x-amz-user-agent=aws-sdk-js%2F3.967.0%20ua%2F2.1%20os%2FWindows%20lang%2Fjs%20md%2Fbrowser%23Google-Chrome_142%20api%2Frekognitionstreaming%233.967.0%20m%2FE%20aws-amplify%2F6.16.2-framework%2F3-ui-react-liveness%2F3.6.0 HTTP/1.1
Host: streaming-rekognition.eu-west-1.amazonaws.com
[...]

HTTP/1.1 101 Switching Protocols
[...]

Ensuite, quelques échanges via websocket permettent de fixer le challenge et la configuration de ce dernier :

Une fois le visage identifié, des chunks de vidéos signés au format webm sont envoyés via le même canal websocket, jusqu'à la fin du challenge :

Pour finir le challenge est vérifié avec le token récupéré précédemment :

GET /api/verify/photo-age-fallback/verify-selfie?token=3b41c11e-c1b7-425d-8b16-afab79c3c942 HTTP/2
Host: myapi.agego.com
[...]
HTTP/2 200 OK
[...]
{"status":true,"age_verified":true,"should_register":true}

L'état de vérification de l'utilisateur passe alors à true :

GET /api/session/self HTTP/2
[...]
HTTP/2 200 OK
[...]
{
    "is_user": false,
    "is_valid": true,
[...]

Instrumentation de la solution de contournement

Comme nous l'avons constaté lors de l'analyse du processus de vérification, une signature de chaque chunk vidéo est mise en place au sein de l'échange websocket. La solution la plus simple reste alors d'émuler un flux vidéo via le module kernel v4l2loopback.

Le challenge consistant systématiquement à bouger la tête en arrière puis en avant, il est nécessaire d'enregistrer une vidéo modèle servant de base à la génération de deepfake. Ainsi, l'alignement du visage avec le challenge permet de résoudre le challenge de manière systématique.

Cependant, un périphérique vidéo ne peut être utilisé simultanément par deux programmes. Le but étant de capturer à la fois la vidéo du challenge avec OBS et de retransmettre le flux de la webcam sur la page web de vérification, il est nécessaire de procéder de la manière suivante :

• Création d'un périphérique v4l2loopback :

$ modprobe v4l2loopback devices=1 video_nr=10 card_label="Shared_Webcam" exclusive_caps=1

• Ajout d'une source V4L2 sur OBS.
• Démarrage de la Caméra Virtuelle (assignée au périphérique v4l2loopback, /dev/video10).
• Enregistrement de la session de vérification via le bouton "Start Recording" sur OBS :

L'enregistrement du challenge peut ensuite être utilisé dans le workflow ComfyUI :

Ce workflow réalise les tâches suivantes :

• Extraction de la première frame de la vidéo enregistrée précédemment;
• Vieillissement du visage de la personne via le modèle d'image NanoBanana Pro;
• Génération du deepfake avec le modèle Kling 3.0.

Soumission du challenge

La vidéo obtenue lors de l'étape précédente peut alors être chargée directement dans OBS en chargeant une source de type Media en cochant l'option "loop".

La caméra virtuelle diffuse maintenant en boucle la vidéo de deepfake et est prête à être utilisée pour soumettre le challenge.

Le challenge passe alors la validation algorithmique et donne accès au contenu du site.

Des tentatives de rejeu de vidéos ont également été effectuées. Le rejeu de la vidéo sans modification échoue, cependant, en le fait de déplacer la vidéo au sein d'OBS durant le challenge suffit à contourner cette limitation.

Conclusion

Le KYC est une problématique actuelle qui doit faire face à des défis techniques face à l'arrivée de nouvelles technologies toujours plus convaincantes. L'arrivée des modèles vidéo génératifs vient rebattre les cartes aussi bien pour les mécanismes de vérification algorithmiques qu'humains. Cette technologie vient combler les défauts de l'approche face-swapping du deepfake (entraînement, réalisme, prérequis pour l'acteur).

Via l'utilisation de services en ligne de génération de vidéo par un modèle génératif vidéo, il est assez simple de contourner les mécanismes de vérification d'âge notamment mis en place sur des sites pornographiques.

Les référentiels comme PVID apportent un cadre et des garanties techniques à ces mécanismes de vérification. En constante évolution, les nouvelles méthodes éprouvées lors des audits sont référencées par l'ANSSI dans une démarche d'adaptation constante. Les constats récents poussent à envisager de nouvelles méthodes de détection, potentiellement elles-mêmes basées sur des modèles génératifs vidéo ou des services d'identités numériques.

Bibliographie

• PVID (ANSSI) : https://cyber.gouv.fr/documents/386/PVID_referentiel-exigences_v1.1.pdf
• List des opérateurs PVID (ANSSI) : https://messervices.cyber.gouv.fr/visas/catalogue-produits-services-pro…
• eIDAS (commision européenne) : https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
• Forensic Analysis for Source Camera Identification from EXIF Metadata (MDPI) : https://www.mdpi.com/2313-433X/12/3/110
• Camera Pipe Injection: Why Your Biometric Backend is Fed Fake Data (InstaTunnel) : https://medium.com/@instatunnel/camera-pipe-injection-why-your-biometri…
• NIST (US gov) : https://pages.nist.gov/800-63-3/
• Aadhaar paperless KYC (UIDAI Head Office) : https://uidai.gov.in/en/2-uncategorised/11320-aadhaar-paperless-offline…
• Micro-texture analysis using LPB: https://ieeexplore.ieee.org/document/6117510
• Photoplethysmography for Passive Liveness and Media Authenticity: https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.177162099.93142957/v1
• Flaskmark: https://www.iproov.com/iproov-system/technology/patented-concepts
• WAN 2.2: https://github.com/Wan-Video/Wan2.2