Pourquoi un résultat de présence provenant du téléphone ne suffit pas

Parce que le téléphone ne vous appartient pas. Un résultat de présence calculé par l'application et envoyé à votre serveur comme « réussi » est une déclaration faite par un appareil qui, dans les cas qui vous intéressent, est contrôlé par l'attaquant. Ce dernier peut modifier l'application, l'exécuter dans un émulateur ou lui fournir une vidéo qui ne provient jamais d'une caméra. Un serveur qui accepte cette déclaration a délégué sa vérification la plus importante à la personne qu'il contrôle.

La solution repose davantage sur un principe que sur une fonctionnalité : le téléphone collecte des preuves, et le serveur tranche. Conservez les données enregistrées, réévaluez-les sur une infrastructure que vous contrôlez et considérez la décision de l’appareil comme une donnée parmi d’autres.

Que peut modifier un attaquant sur l'appareil ?

Sur leur propre téléphone, presque tout ce qui se passe avant que les données ne quittent l'appareil.

• Le résultat lui-même. Si l'application envoieliveness: trueUne application modifiée ou une requête interceptée peuvent envoyer la même valeur sans que personne ne se trouve devant la caméra.

• Le flux vidéo de la caméra. Une caméra virtuelle, un émulateur ou une caméra connectée. API L'application peut présenter une vidéo préenregistrée ou générée comme si elle était diffusée en direct. La logique de détection de direct fonctionne alors correctement, même avec une entrée factice.

• Le timing. Un outil de relecture peut renvoyer une session authentique enregistrée précédemment.

L'Institut national américain des normes et de la technologie (NIST) décrit directement le second cas. Sa directive relative à la vérification d'identité, SP 800-63A-4 (s’ouvre dans un nouvel onglet) (juillet 2025), définit les attaques par injection comme l'insertion de « supports modifiés ou falsifiés entre le point de capture (par exemple, un appareil) et l'élément effectuant la comparaison », et note qu'elles sont de plus en plus souvent associées à des outils d'intelligence artificielle générative. Elle ajoute que la capture en direct et la détection des attaques par présentation rendent la tâche plus difficile, mais « ne suffisent pas à couvrir tous les cas possibles de ce type d'attaques ».

Pourquoi un bon contrôle de disponibilité sur l'appareil ne résout-il pas ce problème ?

Car une attaque par présentation et une attaque par injection sont des problèmes différents.

Une attaque par présentation consiste à placer un objet devant une caméra réelle : une photo, un écran, un masque. Une bonne fonctionnalité de détection de la présence sur l’appareil est conçue pour repérer ces attaques. NIST prévoit qu'il soit testé : la norme SP 800-63A-4 exige la détection d'attaques par présentation pour la collecte biométrique à distance avec un taux d'acceptation des attaques par imposteur inférieur à 0,07, testé conformément à la norme ISO / IEC 30107-3:2023. NIST Il s'agit d'une norme américaine, mais c'est un point de repère utile à interroger auprès d'un fournisseur.

Une attaque par injection ne présente jamais rien à la caméra. Le contrôle interne de l'appareil peut être excellent et réussir le test, car il analyse précisément la vidéo qui lui a été fournie. Les seuls éléments susceptibles d'être détectés sont la preuve elle-même et les indices relatifs à sa capture, examinés dans un endroit inaccessible à l'attaquant.

Que doit revérifier le serveur exactement ?

Quatre pratiques, classées par ordre d'importance.

1. Conservez l'enregistrement, pas seulement l'image.

Une simple photo selfie ne prouve pas grand-chose quant à la présence en direct. Conservez un court enregistrement du défi. Cela permettra au serveur de réanalyser la situation et à un examinateur de visionner le contenu. Toden Dans les SDK, le selfie est automatiquement capturé une fois les défis réussis, et une courte vidéo de présence est enregistrée pour analyse côté serveur, comme décrit dans le SDK documentation (s’ouvre dans un nouvel onglet) .

2. Reconstituez le verdict à partir de l'enregistrement.

Pour un défi dont la réponse est visible dans la vidéo, vérifiez-la sur le serveur. Le défi du flash d'écran est l'exemple le plus clair : les couleurs affichées à l'écran doivent apparaître, dans l'ordre, en reflets sur le visage. Toden La vérification d'identité réanalyse la vidéo enregistrée sur le serveur pour confirmer que la séquence d'éclairs apparaît bien sur le visage.

3. Consignez comment les preuves ont été recueillies.

Certains outils d'injection laissent des traces : un nom de périphérique caméra appartenant à un logiciel de caméra virtuelle connu, une caméra aux capacités improbables, des signes d'un émulateur. Aucun de ces éléments ne constitue une preuve à lui seul, mais ensemble, ils permettent de savoir à quel point on peut se fier aux pixels. Toden , les signaux d'intégrité de capture alimentent un champ de décision,verification.cameraSuspectC’est le cas lorsqu’une injection potentielle est signalée ; un flux de travail peut alors acheminer ces sessions vers un processus d’examen. La documentation relative à la prise de décision (s’ouvre dans un nouvel onglet) mentionne ce champ au même titre que les autres.

4. Dans la mesure du possible, faites en sorte que le défi vienne du serveur.

Le schéma le plus révélateur est un défi lancé par le serveur, suivi de vérifications ultérieures. Les puces des passeports en sont l'exemple type : dans NFC Pour la vérification de la puce (s’ouvre dans un nouvel onglet) , le serveur effectue une authentification passive sur les données de la puce elle-même (« le client ne décide jamais de l'authenticité »), tandis que l'authentification active exige que la puce signe un défi unique, ce qu'une copie d'une puce authentique ne peut faire. Ce principe s'applique à tout contrôle : moins le client intervient, moins il peut falsifier d'informations.

Que se passe-t-il lorsque le serveur est en désaccord avec le téléphone ?

C’est là que beaucoup de conceptions commettent des erreurs. Une incohérence côté serveur est un indice important d’un problème, mais pas toujours une preuve de fraude. La lumière peut estomper un reflet. Une caméra frontale bas de gamme peut rendre flou un hochement de tête. Le nom d’une caméra virtuelle peut appartenir à un outil d’accessibilité ou de diffusion légitime.

Il faut donc considérer une inadéquation comme un signal de risque, et non comme un verdict. Toden Une incohérence dans la séquence d'éclairs est enregistrée comme un signal de risque plutôt que comme un échec de vérification à part entière. Votre flux de travail détermine les conséquences pour votre produit.

Un itinéraire raisonnable, à titre d'exemple :

Fournissez aux examinateurs l'enregistrement ainsi que le drapeau. Visionner l'extrait est souvent le moyen le plus rapide de distinguer un visage éclairé par le soleil d'un visage rediffusé.

Questions à poser à tout fournisseur de services de présence

Que vous utilisiez ou non Toden , ces questions permettent de distinguer une conception basée sur la confiance accordée au téléphone d'une conception basée sur la vérification par le serveur :

1. Le verdict de disponibilité est-il calculé sur l'appareil, sur le serveur, ou les deux ? Si les deux, lequel décide ?

2. Quelles preuves sont conservées, et un examinateur peut-il les consulter ?

3. Comment détecter une vidéo qui ne provient pas d'une véritable caméra ?

4. Comment la détection des attaques par présentation a-t-elle été testée, et par rapport à quelle norme ?

5. Que se passe-t-il lorsque le serveur est en désaccord avec le périphérique : une panne matérielle ou un signal que je peux acheminer ?

La règle à retenir

La fiabilité d'une vérification dépend de l'endroit le moins fiable par lequel elle transite. Si la décision finale est prise sur un téléphone que vous ne contrôlez pas, ce téléphone limite considérablement votre fiabilité. Transférez la décision au serveur, conservez les preuves sur lesquelles elle repose et utilisez le téléphone pour sa fonction principale : guider rapidement une personne lors d'une capture.