Biométrie et sensibilisation du payeur dans le lien dynamique

L'approche de Corbado associe les passkeys résistants au phishing (SCA) à un affichage contrôlé par la banque et à un lien dynamique côté serveur pour respecter l'Art. 5 des NTR de la DSP2 (« ce que vous voyez est ce que vous signez »).

• Implémentation de base (actuelle) : Nous affichons le montant et le bénéficiaire de la transaction dans une interface utilisateur contrôlée par la banque Bison, juste avant et pendant l'authentification par passkey. Notre back-end génère un challenge unique qui est lié à un instantané canonique de la transaction (montant, bénéficiaire, txnId). La réponse n'est acceptée que si elle correspond à cet instantané ; toute modification l'invalide.

• Position réglementaire : Le lien dynamique reste obligatoire pour les paiements à distance, même avec les passkeys (DSP2 Art. 97(2) ; NTR Art. 5). Les NTR n'exigent pas que le « code d'authentification » du lien dynamique soit calculé sur l'appareil ; la génération/validation côté serveur est acceptable lorsque l'intégrité de l'affichage, la spécificité et l'invalidation en cas de changement sont appliquées (voir aussi la Q&R de l'ABE 2020_5366 sur l'endroit où le code peut être calculé).

• Sécurité et auditabilité : Lier une signature de passkey ancrée dans le matériel et résistante au phishing à des données de transaction spécifiques empêche la falsification et le relais, et produit une preuve solide et irréfutable du consentement du payeur. Lorsque cela est pris en charge, nous pouvons éventuellement adopter la Secure Payment Confirmation (SPC) pour ajouter une preuve cryptographique des détails affichés sans modifier le modèle de back-end.

• SCA : Deux éléments indépendants de catégories distinctes (connaissance/possession/inhérence), protégés contre la divulgation/réplication avec des mesures d'atténuation appropriées (NTR Art. 6–8). L'indépendance est requise (Art. 9), y compris la séparation lors de l'exécution sur des appareils polyvalents (par exemple, protections au niveau de l'OS, matériel sécurisé).
• Lien dynamique (NTR Art. 5) :
  • (i) le payeur est informé du montant et du bénéficiaire lors de l'authentification
  • (ii) le code d'authentification est unique à ce montant/bénéficiaire
  • (iii) toute modification invalide le code
  • (iv) la confidentialité/intégrité du montant, du bénéficiaire et du code sont protégées de bout en bout. Cela répond à l'intention réglementaire du « ce que vous voyez est ce que vous signez ».
• Implication : Une authentification forte de l'utilisateur seule ne suffit pas pour les paiements. L'approbation doit être liée à des données de transaction spécifiques avec une preuve vérifiable de ce lien et de l'affichage au payeur (NTR Art. 5(1)(a–d)).

Clarification — phishing vs. autorisation : Les passkeys sont liés à une origine, donc les faux domaines ne peuvent pas obtenir de signatures valides. Cependant, la DSP2 exige toujours un lien dynamique pour les paiements à distance afin de lier l'autorisation au montant et au bénéficiaire exacts, pour invalider toute modification et pour protéger l'intégrité de ce qui est affiché au payeur (NTR Art. 5(1)(a–d)). Le lien dynamique traite de l'intégrité de l'autorisation (y compris la substitution MITM/MITB/TPP), et pas seulement du phishing.

L'Avis de l'ABE 2019 (EBA‑Op‑2019‑06) renforce le fait que le lien dynamique lie l'authentification au montant et au bénéficiaire, exige l'indépendance des facteurs et accepte les clés cryptographiques liées à l'appareil comme preuve de possession lorsqu'un lien unique avec l'appareil existe. Il souligne également l'intégrité de ce qui est affiché au payeur lors de l'authentification. Avis de l'ABE 2019

Avant la DSP2, de nombreuses banques s'appuyaient sur des OTP par SMS ou des listes de TAN imprimées qui n'affichaient souvent ni le montant ni le bénéficiaire à côté de l'étape d'approbation. Cette lacune permettait de tromper plus facilement les clients pour qu'ils autorisent des virements non intentionnels une fois leurs identifiants volés. Le lien dynamique a été introduit pour combler cette lacune en s'assurant que le payeur est informé du montant exact et du bénéficiaire au moment de l'authentification et en rendant le code d'authentification spécifique à ces détails afin que toute modification l'invalide (NTR Art. 5(1)(a–d)). Lorsque le SMS fait partie du flux, les émetteurs doivent également garantir la confidentialité, l'authenticité et l'intégrité du montant/bénéficiaire et du code à toutes les phases de l'authentification (Q&R 2018_4414 ; NTR Art. 5(2)). Les approbations in-app d'aujourd'hui (par exemple, « Voulez-vous autoriser 100 USD à Jean Dupont via Face ID ? ») mettent en œuvre ce principe du « ce que vous voyez est ce que vous signez » de manière conviviale pour le client.

Aujourd'hui, sur mobile, deux modèles dominent. Premièrement, une notification push peut rediriger le client vers l'application via un deep-link pour qu'il examine les détails de la transaction et l'approuve. Les superviseurs ont précisé que la notification push peut servir de preuve de l'élément de possession si les contrôles de l'Article 7 sont en place pour atténuer l'utilisation non autorisée et empêcher la réplication, et si le parcours global est conforme aux NTR ; néanmoins, les risques d'ingénierie sociale subsistent et doivent être pris en compte dans l'UX (Q&R 2019_4984 ; NTR Art. 7).

Deuxièmement, les approbations utilisant la biométrie native de l'appareil (avec un PIN en solution de secours) effectuent une vérification de l'utilisateur localement pour déverrouiller une opération de clé privée. La clé privée se trouve dans un environnement matériel sécurisé (Secure Enclave/TEE/TPM) et signe un challenge. Cela correspond parfaitement à la SCA : inhérence (biométrie) plus possession prouvée par le lien à l'appareil et une clé cryptographique liée à l'appareil (EBA‑Op‑2019‑06, paras. 25, 35–37). Pour les paiements à distance, le code doit être dynamiquement lié au montant et au bénéficiaire, et ces détails doivent être affichés au payeur avant la vérification de l'utilisateur (NTR Art. 5). Si les deux facteurs sont sur un seul appareil, il faut mettre en œuvre des environnements d'exécution sécurisés distincts et des contrôles d'intégrité afin que la compromission de l'un ne compromette pas l'autre (NTR Art. 9(2)–(3)).

Sous le capot, la biométrie locale ne s'authentifie pas directement « auprès de la banque ». Au lieu de cela, la biométrie (ou le PIN de secours) effectue une vérification de l'utilisateur sur l'appareil et contrôle l'accès à une clé privée non exportable stockée dans un module de sécurité matériel. Lorsque le payeur approuve, l'appareil utilise cette clé privée pour produire une signature numérique sur un challenge fourni par la banque. Si la banque dérive ou associe ce challenge à un instantané canonique de la transaction (montant, bénéficiaire, identifiants), alors la signature résultante fonctionne comme un code d'authentification spécifique à ces détails. Toute modification invalidera le code car l'instantané stocké ne correspond plus ou, dans des conceptions améliorées, parce que la dérivation du challenge change. La partie relative à la sensibilisation du payeur reste une exigence d'UX : afficher le montant et le bénéficiaire dans une vue contrôlée par la banque juste avant la vérification de l'utilisateur. Ensemble, cela satisfait aux exigences de l'Art. 5 des NTR sur la sensibilisation, la spécificité/unicité et l'invalidation en cas de changement, tandis que les contrôles de l'Article 7 et le lien à l'appareil prouvent l'élément de possession.

• Possession (clés liées à l'appareil et synchronisées) : Les clés privées des passkeys sont stockées dans du matériel sécurisé (TEE/Secure Enclave/TPM). Les passkeys liés à l'appareil ne sont pas exportables, ce qui correspond aux attentes de l'ABE pour un lien unique à l'appareil (EBA‑Op‑2019‑06, paras. 25, 35–37). Les passkeys synchronisés peuvent également prouver la possession à chaque authentification, à condition que le lien à l'appareil et les contrôles anti-réplication soient efficaces ; les régulateurs ont souligné la nécessité d'un lien fiable entre l'élément et l'appareil (EBA‑Op‑2019‑06 ; NTR Art. 7).
• Inhérence/connaissance (Vérification de l'utilisateur) : La vérification de l'utilisateur via la biométrie (inhérence) ou le PIN de l'appareil (connaissance) active la clé localement. Combiné à la possession, il s'agit d'une véritable 2FA avec indépendance des facteurs. La compromission de l'un ne compromet pas l'autre.

Le lien dynamique consiste à lier l'authentification à la transaction. La question pour une banque est la suivante : si nous permettons à un utilisateur d'approuver un paiement via un passkey (plutôt que, disons, un OTP ou un dispositif de signature), pouvons-nous garantir que cette approbation est spécifique au montant et au bénéficiaire prévus, et qu'elle ne peut pas être réutilisée ou manipulée ?

Il existe 2 options pour implémenter le lien dynamique avec les passkeys :

• Lien côté serveur (standard) : Générer un challenge WebAuthn unique que le back-end associe au montant et au bénéficiaire exacts. L'utilisateur voit « X € à Y » dans une vue contrôlée par la banque et approuve avec un passkey. La réponse n'est acceptée que pour cette transaction. Toute modification l'invalide.
• Inclusion cryptographique (avancée) : Intégrer un hash du montant/bénéficiaire dans le challenge pour que la signature s'engage sur les données de la transaction. Ce n'est pas requis par les NTR mais ajoute une assurance que même les échanges de back-end échoueraient à la vérification.

Note de conformité explicite : Les NTR n'exigent pas que le « code d'authentification » du lien dynamique soit calculé sur l'appareil du payeur. Un PSP peut le générer et le valider sur le serveur tant que le montant/bénéficiaire sont protégés et que toute modification invalide le code (voir Q&R de l'ABE 2020_5366 sur l'emplacement/le moment du code). C'est notre approche de lien dynamique côté serveur (standard).

Les deux produisent un « code d'authentification » unique, non réutilisable et spécifique à la transaction. La principale réserve est la sensibilisation du payeur : WebAuthn lui-même ne prouve pas ce qui a été affiché. L'intégrité de l'affichage doit provenir d'une interface utilisateur contrôlée par la banque.

L'Article 5 des NTR exige que le payeur voie le montant et le bénéficiaire pendant l'authentification. WebAuthn n'atteste pas de ce qui a été montré. En théorie, si l'application ou l'OS est compromis, un utilisateur pourrait être trompé alors que l'authentificateur signe toujours. Nous analyserons ci-dessous en détail comment ce risque se manifeste en réalité et pourquoi ce n'est pas un risque de sécurité réel, mais plutôt une question d'interprétation de la réglementation.

Contrôles d'intégrité de l'affichage que nous appliquons :

• Une vue contrôlée par la banque affiche le montant + le bénéficiaire : nous bloquons l'invocation du passkey si la vue est obscurcie ou floue.
• Détection de superposition/falsification dans l'application/le web : pas d'invites de passkey depuis des iframes cachées.
• Contrôle de l'intégrité/attestation de l'appareil : refuser ou renforcer la sécurité sur les signaux d'appareils rootés/jailbreakés/compromis.
• Approbation atomique par rapport à un instantané du montant/bénéficiaire détenu par le serveur : un nouveau challenge est requis pour tout changement de paramètre.

À propos de l'inclusion cryptographique : Les extensions « d'affichage de transaction » de WebAuthn (SPC) ne sont pas largement prises en charge aujourd'hui. Notre base de référence portable est le lien côté serveur, renforcé en dérivant le challenge de l'instantané de la transaction (par exemple, H(montant ‖ bénéficiaire ‖ txnId ‖ nonce)) afin que la signature s'engage sur ces valeurs.

Les deux modèles utilisent la cryptographie à clé publique avec des clés d'appareil non exportables, et tous deux s'appuient sur une vérification locale de l'utilisateur pour déverrouiller l'opération de signature. Dans les deux cas, la banque assure la sensibilisation du payeur en affichant le montant et le bénéficiaire dans une vue contrôlée par la banque juste avant la vérification de l'utilisateur, et assure la spécificité en liant le code d'authentification à ces détails — l'invalidant en cas de changement (NTR Art. 5(1)(a–d)). Les NTR sont neutres sur le plan technologique et n'exigent pas que le montant/bénéficiaire soit affiché à l'intérieur d'une modale biométrique de l'OS ; elles exigent l'affichage au payeur et le lien du code (NTR Art. 5). Lorsque les deux éléments de la SCA s'exécutent sur un seul appareil, les exigences d'intégrité et de séparation de l'Article 9 s'appliquent également (NTR Art. 9(2)–(3)). Enfin, l'emplacement du calcul du lien dynamique est flexible : il peut être effectué côté serveur si l'intégrité est préservée et que tout changement invalide le code (Q&R 2020_5366). Ce sont les mêmes conditions dans lesquelles les régulateurs acceptent déjà la biométrie locale avec PKI — par conséquent, les passkeys, mis en œuvre avec les mêmes contrôles de sensibilisation du payeur et de lien, devraient être acceptés sur une base équivalente.

Alors, les passkeys simples conformes à la norme WebAuthn répondent-ils à l'intention du lien dynamique ? Partiellement :

• Attaques MITM/réseau : Oui. Le lien à l'origine et les signatures par challenge empêchent la falsification et la relecture.
• Intégrité de la transaction : Oui. L'association au serveur ou le hachage du challenge garantit que seuls le montant/bénéficiaire d'origine seront vérifiés.
• Consentement du payeur : Plus difficile. Les passkeys n'ont pas d'affichage au niveau de l'authentificateur. La tromperie de l'interface utilisateur sur des appareils compromis pourrait être possible. Il faut construire quelque chose par-dessus pour garantir le consentement du payeur.

Pourquoi le lien dynamique est toujours nécessaire avec les passkeys

• Légal : L'Art. 97(2) de la DSP2 et l'Art. 5 des NTR exigent le lien dynamique pour toute initiation de paiement à distance. Il n'y a pas d'exception pour les méthodes résistantes au phishing.
• Sécurité : Les passkeys suppriment le phishing inter-origines, mais ils ne prouvent pas par eux-mêmes ce qui a été affiché au payeur. Le lien dynamique + les contrôles d'intégrité de l'affichage garantissent que le montant/bénéficiaire spécifique que l'utilisateur a vu est ce que la banque exécute, et que toute modification invalide l'approbation.

En résumé, les passkeys peuvent satisfaire au lien dynamique lorsqu'ils sont strictement liés aux données de transaction et associés à des mécanismes d'affichage fiables. Le défi résiduel est de prouver ce que l'utilisateur a réellement vu.

Corbado offre une solution conforme au lien dynamique qui aborde explicitement les considérations de consentement du payeur ci-dessus.

// TODO FOURNIR LES MAQUETTES DE KARUNA ET LES DÉCRIRE

Déroulement du processus :

• Un affichage contrôlé par la banque montre au payeur le montant et le bénéficiaire exacts. Aucune invite de passkey n'est affichée à moins que cette vue ne soit visible.
• Authentification : le client invoque WebAuthn avec un challenge unique et lié pour la transaction canonique. L'authentificateur effectue la vérification de l'utilisateur (biométrie ou PIN de l'appareil) et signe le challenge et l'origine.
• Vérification du serveur : le back-end vérifie le hash de l'ID RP et l'origine, fait correspondre le challenge à la transaction stockée, vérifie les indicateurs UV, impose une utilisation unique et une expiration, et compare l'instantané du montant/bénéficiaire stocké.
• Approbation et audit : ce n'est qu'alors que la transaction est approuvée de manière atomique. Toute non-concordance/modification est rejetée et nécessite une nouvelle authentification. Un enregistrement d'audit immuable est conservé (ID du credential, authenticatorData, clientDataJSON, signature, challenge, et montant/bénéficiaire canoniques), éventuellement avec une chaîne de hachage pour prouver l'absence de falsification.
• Contrôle de l'intégrité de l'appareil : Évaluer les signaux d'intégrité et d'attestation de l'appareil : refuser ou renforcer la sécurité si l'appareil est rooté/jailbreaké/compromis.
• Canonisation du bénéficiaire : Afficher une étiquette conviviale (par exemple, « ACME GmbH »), mais lier et vérifier par rapport à un identifiant de bénéficiaire canonique (par exemple, IBAN/BIC ou autre schéma unique).

Détails techniques :

• Back-end : créer un objet de transaction avec des données canoniques (par exemple, devise/décimales normalisées ; IBAN/bénéficiaire canonique). Générer un challenge à courte durée de vie s'engageant sur ces valeurs (par exemple, H(montant||bénéficiaire||txnId||nonce)) ; stocker en attente ; n'exposer que des ID opaques au client.
• Client/authentificateur : afficher les détails du payeur dans une vue contrôlée par la banque ; invoquer WebAuthn (ID RP = domaine Bison) uniquement lorsque visible ; exiger la vérification de l'utilisateur ; l'authentificateur signe le challenge + l'origine conformément à WebAuthn.
• Vérification/finalisation : valider la signature, le hash de l'ID RP, l'origine/le type, les indicateurs UV ; anti-relecture/expiration ; comparer l'instantané immuable du montant/bénéficiaire ; approuver de manière atomique ; conserver l'enregistrement d'audit.
• Dériver le challenge de l'instantané : : challenge = H(montant ‖ bénéficiaireCanonique ‖ txnId ‖ nonce)

Politiques UX :

• Mettre clairement l'accent sur le montant/bénéficiaire ; contrôles de confirmation/annulation accessibles ; délais d'attente courts ; nouvelles tentatives en douceur utilisant toujours un nouveau challenge ; reçus immédiats (par exemple, « Vous avez approuvé X € à Y »). Bloquer l'invite de passkey si l'affichage est obscurci et avertir si les paramètres changent avant la signature.
• Détecter les superpositions/contenus obscurcis : ne jamais afficher d'invite de passkey si la vue de la transaction n'est pas visible. Rejeter si les paramètres changent en cours de route et redémarrer avec un nouveau challenge.

Note de conformité : Cette conception de bout en bout répond à l'Art. 5 des NTR : sensibilisation du payeur (affichage contrôlé par la banque), spécificité et unicité (code unique lié au montant/bénéficiaire), invalidation en cas de changement (contrôles stricts du serveur), et confidentialité/intégrité du montant/bénéficiaire et du code à toutes les phases (NTR Art. 5(1)(a–d), 5(2) ; voir aussi Q&R 2018_4414 pour l'intégrité des SMS). L'indépendance des facteurs (Arts. 7–9) est préservée via la possession liée à l'appareil et la vérification de l'utilisateur locale sur des appareils polyvalents avec des protections appropriées (NTR Art. 9(2)–(3)).

Note :* pour les flux web, Corbado adoptera éventuellement la Secure Payment Confirmation (https://www.w3.org/TR/payment-request-secure-payment-confirmation/) si/quand Apple offrira un large support, ajoutant un affichage de confiance médiatisé par le navigateur qui atteste cryptographiquement du montant et du bénéficiaire.

Préoccupation : Attaques de phishing Réponse : Les passkeys sont résistants au phishing par conception : ils sont liés à l'origine légitime et n'impliquent aucun secret partagé, de sorte que les identifiants ne peuvent pas être collectés sur un faux site, contrairement aux OTP. Un attaquant qui relaie le trafic vers un domaine d'apparence similaire ne peut pas obtenir de signature valide pour l'origine de la banque. Le lien dynamique contribue moins dans ce vecteur, mais reste obligatoire pour garantir que toute approbation est unique au montant et au bénéficiaire prévus. Des mesures complémentaires (sensibilisation au phishing, séparation claire des approbations de connexion et de paiement, notation d'anomalie/risque pour les contextes de paiement inhabituels) réduisent davantage l'exposition.

Préoccupation : Ingénierie sociale / Fraude au virement autorisé (APP) Réponse : Aucun authentificateur ne peut empêcher totalement un utilisateur d'autoriser un paiement sous de faux prétextes (par exemple, les arnaques au « compte de sécurité »). Le lien dynamique garantit que l'utilisateur voit explicitement le bénéficiaire et le montant et fournit une preuve solide de son consentement, mais il ne peut pas passer outre un payeur convaincu. Les compensations incluent des avertissements contextuels (nouveau bénéficiaire, premier virement important), des périodes de réflexion ou une exécution différée pour les bénéficiaires à haut risque, une vérification plus stricte du bénéficiaire et des contrôles renforcés (confirmation supplémentaire) sur les signaux de risque. Les notifications post-paiement et les canaux de litige rapides aident à détecter et à contenir les dommages. Nous ajoutons des avertissements contextuels en temps réel (par exemple, nouveau bénéficiaire, premier virement important), des périodes de réflexion pour les bénéficiaires à haut risque, une vérification plus stricte du bénéficiaire et des notifications post-paiement (« Vous avez approuvé X € à Y ») pour accélérer la détection et la réponse.

Préoccupation : Malware ou compromission de l'appareil Réponse : Les clés privées sont non exportables et nécessitent une vérification locale de l'utilisateur pour chaque signature, donc un malware ne peut pas simplement exfiltrer les identifiants. Le risque réaliste est la tromperie de l'interface utilisateur sur un OS entièrement compromis. Atténuez ce risque avec une interface utilisateur sécurisée/vérifiée (par exemple, confirmations protégées), des contrôles d'intégrité de l'appareil/attestation et le blocage des appareils à haut risque, et des confirmations de confiance telles que SPC ou une extension de confirmation lorsqu'elle est disponible. Si des indicateurs de compromission apparaissent (détection de superposition, root/jailbreak), utilisez une re-vérification hors bande ou refusez l'exécution. Aucune méthode grand public n'est parfaite sur un appareil entièrement contrôlé par un attaquant, mais ces contrôles réduisent considérablement la fenêtre d'attaque.

Préoccupation : Man-in-the-browser / Détournement de session Réponse : Des extensions malveillantes ou des scripts injectés peuvent lancer des actions sur l'origine légitime. Les passkeys liés à l'origine arrêtent le phishing inter-sites. Le lien dynamique garantit que les modifications en coulisses du montant/bénéficiaire échouent. Nous renforçons le canal via des contrôles CSP/anti-falsification et en exigeant un nouveau challenge unique pour chaque confirmation.

Préoccupation : Menace interne ou falsification côté serveur Réponse : La réponse d'authentification est liée de manière unique au montant/bénéficiaire d'origine, donc toute substitution côté serveur échoue à la validation. Maintenez des enregistrements de lien immuables et à l'épreuve des falsifications (challenge, credential, signature et montant/bénéficiaire canoniques) pour l'audit/la non-répudiation. Appliquez la séparation des tâches et les contrôles à quatre yeux sur les chemins critiques de traitement des paiements pour réduire le risque interne.

Préoccupation : Appareils volés / Vol d'identifiants Réponse : La simple possession de l'appareil est insuffisante : une vérification de l'utilisateur (biométrie/PIN) est requise pour chaque signature, avec des limitations de tentatives et des blocages au niveau de l'OS. Chaque paiement nécessite un nouveau challenge spécifique à la transaction ; les jetons de session génériques ne peuvent pas autoriser des paiements arbitraires. Des ajouts comme la révocation d'appareil à distance, le renforcement de la sécurité lors de l'utilisation d'un nouvel appareil, les contrôles de géovélocité et les notifications (« Vous avez autorisé X € à Y ») limitent davantage les abus.

Globalement : les passkeys réduisent considérablement les risques de phishing et de relecture ; le lien dynamique reste essentiel pour garantir l'intégrité des transactions, lier les approbations au montant/bénéficiaire et fournir une preuve solide du consentement éclairé dans les scénarios de menace restants.

Question 1 : Comment pouvons-nous prouver que l'utilisateur a réellement vu et accepté le montant et le bénéficiaire en utilisant un passkey ? Réponse : Nous imposons un affichage pour le payeur dans une vue contrôlée par la banque et lions l'approbation à un instantané côté serveur du montant/bénéficiaire. L'assertion du passkey (authenticatorData, clientDataJSON, signature) n'est acceptée que pour le challenge dérivé de cet instantané ; tout changement nécessite un nouveau challenge. Notre audit à l'épreuve des falsifications lie l'assertion à « X € à l'ID-Bénéficiaire Y » et enregistre que notre système n'aurait pas procédé si les détails différaient. Lorsque cela est pris en charge, la SPC ajoute une preuve cryptographique que l'utilisateur a confirmé les détails affichés.

Question 1 : Comment pouvons-nous prouver que l'utilisateur a réellement vu et accepté le montant et le bénéficiaire en utilisant un passkey ? Réponse : C'est essentiellement la question de la non-répudiation. Dans le cadre de la DSP2, le lien dynamique visait à garantir que l'utilisateur est conscient de ce qu'il approuve. Avec un passkey, la preuve que nous conservons est la signature cryptographique (code d'authentification) et les données associées (à quel montant/bénéficiaire elle était liée sur notre serveur). Par politique, nous affichons les détails de la transaction à l'utilisateur dans l'application ou la page web avant qu'il ne s'authentifie. Nous enregistrons cet écran/cette vue et l'authentification par passkey réussie qui s'ensuit pour cette transaction spécifique. En cas de litige, nous pouvons montrer que l'appareil de l'utilisateur a produit une signature valide pour un challenge qui était associé à (par exemple) « 100 € à ACME Corp. » et que notre système n'aurait pas procédé si un détail était différent. Notre conformité repose sur une journalisation sécurisée : nous nous assurons que nos systèmes sont inviolables pour lier la réponse du passkey aux données de la transaction.

Question 2 : Et si l'appareil ou l'OS est compromis ? Un malware peut-il manipuler la transaction ou le processus de passkey ? Réponse : La compromission de l'appareil est une menace critique dans tout scénario de services bancaires numériques. Si le système d'exploitation est malveillant, il pourrait tenter de tromper l'utilisateur ou de détourner des processus. Cependant, même dans le pire des cas, les passkeys maintiennent certaines protections clés. La clé privée ne peut pas être extraite par un malware. Un malware ne peut pas non plus se faire passer pour l'utilisateur auprès de la banque, car il ne peut pas produire la signature du passkey sans la biométrie/le PIN de l'utilisateur. Le maximum qu'il pourrait faire est de pousser l'utilisateur à authentifier quelque chose sous de faux prétextes. Le lien dynamique aide ici en exigeant des contrôles d'intégrité : le malware ne peut pas changer silencieusement les détails de la transaction après coup – s'il le fait, la signature ne sera pas vérifiée. Le point le plus faible est l'affichage/l'interface utilisateur : un cheval de Troie sophistiqué pourrait modifier ce que l'utilisateur voit (par exemple, afficher « ACME Corp » alors que la transaction sous-jacente va en réalité à un autre bénéficiaire). Ce n'est pas trivial, surtout si l'application bancaire utilise des frameworks d'interface utilisateur sécurisés, mais c'est concevable. Cela dit, si nous détectons des signes de compromission de l'appareil (comportement inhabituel, signatures de malware connues, etc.), nous reviendrions à une vérification hors bande ou refuserions la transaction. En résumé : Aucune solution n'est efficace à 100 % si l'appareil de l'utilisateur est entièrement contrôlé par un attaquant. Les passkeys + le lien dynamique réduisent considérablement la surface d'attaque (un attaquant ne peut pas simplement utiliser des identifiants par procuration ou altérer les données réseau ; il devrait monter une arnaque en temps réel sur l'utilisateur). Si l'OS est compromis, le lien dynamique garantit au moins que toute incohérence entre ce qui devrait être et ce qui est approuvé est détectée par notre back-end.

Question 3 : Si une donnée biométrique est utilisée pour déverrouiller le passkey, est-ce considéré comme un ou deux facteurs ? Respectons-nous la règle des 2 facteurs ? Réponse : Une donnée biométrique seule n'est pas suffisante pour la SCA – c'est juste un facteur d'inhérence. Cependant, dans une implémentation de passkey, la biométrie n'est pas seule : la possession de l'appareil est l'autre facteur. La biométrie de l'utilisateur déverrouille la clé privée stockée sur l'appareil. La possession et l'inhérence sont deux catégories distinctes. C'est analogue à la manière dont de nombreuses applications bancaires satisfont déjà à la SCA : vous avez le téléphone (possession) et vous utilisez votre empreinte digitale ou votre visage pour déverrouiller l'application (inhérence). L'ABE a explicitement reconnu les combinaisons de lien à l'appareil plus biométrie comme une SCA conforme. Le scénario du passkey est exactement cette combinaison. Si l'utilisateur choisit d'utiliser un PIN au lieu de la biométrie pour déverrouiller le passkey, alors c'est possession + connaissance, également conforme. Nous imposons la vérification de l'utilisateur sur toutes les opérations de passkey (ce qui signifie que l'utilisateur doit fournir sa biométrie/son PIN à chaque fois), il n'y a donc aucune situation où le simple fait d'avoir l'appareil suffit. Ainsi, chaque autorisation de paiement via passkey est un événement à deux facteurs selon les définitions de la DSP2.

Question 4 : Un attaquant pourrait-il réutiliser une authentification par passkey ou contourner d'une manière ou d'une autre le lien dynamique en manipulant les données en transit ? Réponse : Non. C'est là que les passkeys et le lien dynamique fonctionnent bien ensemble. Chaque authentification WebAuthn produit une signature unique qui est liée au challenge (que nous générons par transaction) et est limitée à notre domaine. Un attaquant ne peut pas rejouer cette signature pour une transaction différente. La signature elle-même incorpore le nonce du challenge et n'est valide que pour ce pour quoi elle a été initialement émise. Si un attaquant interceptait la communication réseau, il ne pourrait pas modifier le montant ou le bénéficiaire sans invalider la signature (puisque le challenge ou le contexte de la transaction ne correspondrait plus). C'est effectivement la protection MITM dont nous avons parlé. De plus, les signatures de passkey incluent des données d'origine – elles ne seront pas vérifiées si elles ne sont pas envoyées à notre origine exacte de site web/application, donc le phishing ou la redirection ne fonctionneront pas. En bref, toute tentative de manipulation invalide le code d'authentification, conformément aux règles du lien dynamique. C'est en fait plus sûr que certains flux actuels basés sur les OTP, où les utilisateurs approuvent parfois un code générique et il y a un risque que la demande ait été falsifiée. Avec les passkeys, nous lions cryptographiquement l'authentification de l'utilisateur à la session/transaction spécifique.

Question 5 : Existe-t-il des avis réglementaires connus sur WebAuthn/passkeys pour la SCA ? Sommes-nous sûrs que les régulateurs accepteront les passkeys comme conformes ? Réponse : À ce jour, l'ABE n'a pas explicitement publié d'avis sur WebAuthn ou le terme « passkeys » dans ses Q&R ou ses directives. Cependant, sur la base des principes qu'ils ont établis, les passkeys s'intègrent clairement dans les méthodes acceptables. L'avis de l'ABE de 2019 anticipait essentiellement des approches de type FIDO2 : pour la possession, ils mentionnent explicitement « l'échange de clés publiques/privées » avec un lien approprié à l'appareil comme preuve de possession. Un passkey WebAuthn est exactement cela – une paire de clés publique/privée, la moitié privée étant liée de manière sécurisée à l'appareil. Ils ont également fait un clin d'œil à la « signature générée par un appareil » comme preuve de possession valide. Donc, bien qu'ils n'aient pas utilisé le terme passkey, la méthode est couverte par leurs exemples. Nous avons également observé que les principaux acteurs des paiements en Europe avancent avec des implémentations de passkeys (par exemple, PayPal), ce qui indique un niveau de confiance dans le fait que cela est conforme à la DSP2. Cet exemple démontre que les passkeys sont acceptés dans le cadre de flux SCA conformes, à condition que le lien dynamique et les exigences générales soient respectés.

Question 6 : Avons-nous encore besoin du lien dynamique si les passkeys sont résistants au phishing ? Réponse : Oui. Les passkeys éliminent le phishing inter-origines, mais la DSP2 impose toujours le lien dynamique pour l'initiation de paiement à distance. Le lien dynamique lie le montant et le bénéficiaire spécifiques au résultat de la SCA et invalide toute modification, traitant de l'intégrité de l'autorisation au-delà du phishing (par exemple, substitution MITM/MITB/TPP).

La solution de Corbado est conforme au lien dynamique et à la DSP2. L'affichage pré-authentification au payeur, le challenge unique lié au montant et au bénéficiaire, la vérification stricte du serveur et l'audit immuable satisfont ensemble aux exigences de l'Art. 5 des NTR sur la sensibilisation du payeur, l'unicité/spécificité, l'invalidation en cas de changement et l'intégrité/confidentialité. L'indépendance des facteurs est préservée grâce à la possession liée à l'appareil et à la vérification de l'utilisateur (biométrie ou PIN), conformément aux directives de l'ABE.

Par rapport aux méthodes OTP/SMS actuelles, Corbado offre une sécurité et des résultats utilisateur nettement meilleurs : résistance au phishing et à la relecture, prévention de la falsification silencieuse des paramètres, preuve non répudiable plus solide et friction réduite grâce à la vérification de l'utilisateur sur l'appareil. Les risques résiduels (par exemple, ingénierie sociale, appareils compromis) sont atténués par des contrôles concrets et sont plus étroits qu'avec les méthodes traditionnelles. Pour le web, Corbado peut adopter la SPC lorsque le support de la plateforme (notamment Apple) sera généralisé, ajoutant une preuve cryptographique de l'affichage sans changer la posture de conformité de base.

En bref, l'autorisation de transaction basée sur les passkeys de Corbado respecte la lettre et l'esprit du lien dynamique de la DSP2 et améliore la résilience à la fraude et l'auditabilité par rapport aux approches traditionnelles, tout en maintenant une voie claire vers les améliorations futures (SPC) à mesure que l'écosystème mûrit.

En pratique, les passkeys satisfont au lien dynamique lorsque nous faisons trois choses : nous affichons le montant et le bénéficiaire au payeur avant la vérification de l'utilisateur ; nous générons un code d'authentification spécifique à ces détails exacts ; et nous invalidons le code en cas de changement (NTR Art. 5(1)(a–d)). Cela reflète les principes que les régulateurs acceptent déjà pour la biométrie locale, avec la commodité supplémentaire que les passkeys sont natifs à l'OS et fonctionnent sur les canaux web et applicatifs sans application supplémentaire. Combinés au lien à l'origine, ils ne présentent pas de demandes usurpées — seules les invites légitimes du site ou de l'application d'origine apparaissent à l'utilisateur.