Sécuriser une transaction bancaire contre rejeu et falsification

Une transaction bancaire a une propriété que peu de systèmes partagent : une fois compensée, elle ne se rattrape pas, et un virement instantané est irrévocable en dix secondes. Toute l’architecture de paiement en découle : l’erreur de conception ne se corrige pas, elle se rembourse. La position défendue ici : la signature de l’ordre lui-même compte davantage que l’authentification de la session.

→ Lire l’explication complète de la marmotte

Liaison dynamique et authentification forte du client

La deuxième directive européenne sur les services de paiement (DSP2) impose l’authentification forte du client (SCA, Strong Customer Authentication) : deux facteurs parmi connaissance, possession et inhérence. Pour un paiement à distance, les normes techniques de réglementation (RTS, Regulatory Technical Standards) ajoutent la liaison dynamique : le code d’authentification est calculé sur le montant et le bénéficiaire, et les modifier l’invalide.

Une session authentifiée puis détournée par un logiciel malveillant dans le navigateur laisse passer n’importe quel ordre ; un code lié au montant et à l’IBAN (International Bank Account Number) ne valide que l’ordre affiché au client. À condition que la confirmation s’affiche sur un canal que le logiciel malveillant ne contrôle pas (application distincte, lecteur dédié) : affichée dans la même page web que l’ordre, elle se falsifie avec le même script. La fraude cherche rarement le maillon cryptographique ; elle cherche l’écran qui affiche « 125,00 € » pendant que la puce signe autre chose.

Côté carte, le standard EMV (Europay, Mastercard, Visa) fait calculer à la puce un cryptogramme de demande d’autorisation (ARQC, Authorization Request Cryptogram) sur le montant, la devise, la date, un nombre imprévisible fourni par le terminal et un compteur de transactions (ATC, Application Transaction Counter). La clé de la carte est dérivée d’une clé maîtresse de l’émetteur, conservée dans un HSM (Hardware Security Module) (voir le module cryptographique matériel).

Surface d’attaque d’une transaction : rejeu, altération, canal auxiliaire

Rejeu. Un ordre valide rejoué deux fois reste valide deux fois si rien ne le rend unique. Contre-mesures : nonce ou compteur dans les données signées, fenêtre d’horodatage courte, et côté API (Application Programming Interface) une clé d’idempotence qui interdit deux écritures comptables pour un même identifiant d’ordre. Côté carte, un ATC déjà vu signale un clone.

Altération en transit. TLS (Transport Layer Security) protège un canal, pas l’ordre : chaque terminaison (répartiteur de charge, passerelle, bus d’intégration) le voit en clair et peut le modifier. Seule une signature applicative sur une forme canonique de l’ordre survit à ces traversées.

Canaux auxiliaires. Un module qui répond différemment selon la nature de l’erreur fuit de l’information. L’attaque de Bleichenbacher contre le remplissage RSA (Rivest, Shamir, Adleman) de PKCS#1 v1.5 (Public-Key Cryptography Standards n° 1) reste l’exemple d’école, détaillé dans la rubrique Cryptographie : quelques milliers de réponses « remplissage valide ou non » suffisent à déchiffrer un message. Règle : un seul code d’échec opaque, et un temps de réponse constant.

Injection de clés et double contrôle. Le chargement d’une clé maîtresse en HSM se fait par composants, détenus par des personnes distinctes (connaissance partagée et double contrôle exigés par PCI DSS, Payment Card Industry Data Security Standard). Un administrateur seul capable de reconstituer une clé annule toute la hiérarchie.

Ce que l’authentification forte ne garantit pas

L’authentification forte prouve que le titulaire a validé l’ordre, pas qu’il a compris ce qu’il validait. La fraude par manipulation (le client, convaincu par un faux conseiller, autorise lui-même un virement vers un compte mule) passe toutes les vérifications techniques : bon appareil, bon facteur, bon code lié au bon montant. Le règlement européen sur les virements instantanés impose depuis octobre 2025 la vérification du bénéficiaire (VoP, Verification of Payee), qui compare le nom saisi au titulaire réel de l’IBAN avant validation ; c’est un signal, pas un blocage.

Elle ne garantit pas non plus la non-répudiation : un code issu d’un secret partagé (HMAC, Hash-based Message Authentication Code) a pu être calculé par la banque comme par le client. Seule une signature asymétrique, clé privée confinée dans l’appareil, lève l’ambiguïté.

Le compromis central du sujet : chaque exemption d’authentification forte (petit montant, bénéficiaire de confiance, analyse de risque de la transaction) gagne de la conversion et paie en exposition. L’exemption par analyse de risque se défend si le taux de fraude mesuré reste sous les seuils réglementaires ; sans mesure, c’est un pari sur le panier moyen.

Exemple reproductible : signer un ordre et détecter sa modification

Exécutable avec OpenSSL 3, l’exemple signe la forme canonique d’un ordre avec une clé ECDSA (Elliptic Curve Digital Signature Algorithm) P-256, puis montre qu’un seul caractère modifié invalide la signature.

# Clé de l'appareil client (en production : générée dans l'élément sécurisé, jamais exportée)
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out cle-terminal.pem
openssl pkey -in cle-terminal.pem -pubout -out cle-terminal.pub

# Forme canonique : version, champs dans un ordre fixe, nonce et horodatage inclus
printf '%s' 'v1|montant=125.00|devise=EUR|beneficiaire=FR7630006000011234567890189|nonce=7d3a9c41e2b0|horodatage=2026-09-29T10:15:00Z' > ordre.txt

# Signature côté client, vérification côté banque
openssl dgst -sha256 -sign cle-terminal.pem -out ordre.sig ordre.txt
openssl dgst -sha256 -verify cle-terminal.pub -signature ordre.sig ordre.txt
# Affiche : Verified OK

# Un intermédiaire change le montant : la vérification échoue
sed 's/montant=125.00/montant=925.00/' ordre.txt > ordre-modifie.txt
openssl dgst -sha256 -verify cle-terminal.pub -signature ordre.sig ordre-modifie.txt
# Affiche : Verification failure (code de retour 1)

La signature seule n’arrête pas le rejeu : le serveur doit en plus refuser tout nonce déjà enregistré et tout horodatage hors d’une fenêtre de quelques minutes. Point fragile, la canonisation : si client et serveur ne sérialisent pas l’ordre à l’identique (décimales, casse de l’IBAN), les vérifications échouent en masse, et « tolérer les écarts » rouvre la porte fermée par la signature.

Exploitation : clés, journaux et reprise

Prérequis. HSM de paiement certifiés (PCI PTS HSM, PIN Transaction Security, ou FIPS 140-3, Federal Information Processing Standards, niveau 3), hiérarchie de clés documentée (clé maîtresse, clés de transport de zone, clés de travail), et un référentiel des appareils enrôlés avec leur clé publique.

Rotation. Les clés de travail tournent selon une période de validité vérifiée ; la clé d’un appareil perdu se révoque avec effet immédiat sur la validation des ordres, pas seulement sur les sessions.

Supervision. Chaque transaction porte un identifiant corrélable entre canal, passerelle, cœur bancaire et HSM. Un journal qui ne relie pas l’ordre signé à l’écriture comptable ne sert à rien le jour de la contestation. Les échecs de signature se surveillent en taux : un pic signale une attaque ou une régression de canonisation.

Reprise. La redondance des HSM repose sur un clonage chiffré des clés entre modules du même domaine de sécurité ; une sauvegarde de clé exportée en clair, même temporairement, invalide la certification. La rubrique Domaines situe ces exigences face à d’autres secteurs.

🐝 Ce qui arrive si on s’en passe

Sans ces garde-fous, la porte de la ruche reste ouverte. Une transaction qui n’est ni signée ni horodatée peut être rejouée telle quelle : le même ordre de paiement passe deux fois sans qu’aucun contrôle ne distingue l’original de la copie. Sans scellement du montant et du bénéficiaire, une modification en transit reste indétectable côté serveur, et le client n’a plus de preuve opposable de ce qu’il a réellement validé. Sans journal d’audit corrélé (identifiant d’opération, canal, terminal), la détection d’une fraude arrive après compensation, quand la reprise coûte davantage que la prévention. Les canaux chiffrés mal validés donnent la même ouverture : voir la question qui rend le module bavard, où des réponses d’erreur trop précises suffisent à reconstituer un secret protégé.

🦫 Explication de la marmotte 🍫

Quand un client ordonne un paiement, son téléphone ou sa carte fabrique une signature numérique à partir des détails exacts de l’ordre : le montant, la devise, le compte qui reçoit l’argent, un numéro unique et l’heure. Cette signature est calculée avec une clé secrète rangée dans une puce qui ne la laisse jamais sortir. La banque reçoit l’ordre et la signature, refait le calcul avec la partie publique de la clé, et vérifie que tout correspond. Si un seul chiffre du montant a été changé en chemin, la vérification échoue et le paiement est refusé. Le numéro unique sert à autre chose : la banque garde la liste des numéros déjà utilisés et refuse tout ordre qui revient une deuxième fois, ce qui empêche de rejouer un paiement copié. Chaque étape laisse une trace dans un journal, pour pouvoir prouver plus tard qui a demandé quoi. Ce système a une limite : si le client est trompé par un escroc et valide lui-même un virement vers le mauvais compte, toutes les vérifications passent, car la signature est authentique. La banque compare alors le nom du bénéficiaire au vrai titulaire du compte et prévient le client, mais celui-ci garde le dernier mot.

Pages voisines

La citent

Sécuriser une transaction bancaire contre rejeu et falsification

Elle cite

: les deux pages se citent l’une l’autre.

Sécuriser une transaction bancaire contre rejeu et falsification

Sécuriser une transaction bancaire contre rejeu et falsification

Liaison dynamique et authentification forte du client

Surface d’attaque d’une transaction : rejeu, altération, canal auxiliaire

Ce que l’authentification forte ne garantit pas

Exemple reproductible : signer un ordre et détecter sa modification

Exploitation : clés, journaux et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines