Le standard EMV
EMV (Europay, Mastercard, Visa ; aujourd'hui géré par EMVCo, détenu à parts égales par six schemes) est le standard mondial de la carte à puce de paiement. Son principe fondateur consiste à remplacer les données statiques de la piste magnétique, copiables à l'infini, par un dialogue cryptographique dynamique entre la puce, le terminal et l'émetteur, qui rend chaque transaction unique et infalsifiable. La France a généralisé la carte à puce avant les autres marchés. La fraude sur les paiements de proximité y est devenue marginale.
Une transaction EMV contact enchaîne des étapes normalisées : sélection d'application (choix de l'AID, ex. A0000000421010 pour CB), lecture des données carte, authentification offline des données (SDA/DDA/CDA), vérification du porteur (CVM), gestion du risque terminal (planchers, sélection aléatoire). La dernière étape est la génération du cryptogramme (GENERATE AC), qui traduit la décision prise par la puce : demande d'autorisation en ligne (ARQC), approbation offline (TC) ou refus (AAC).
ARQC et ARPC : le cœur cryptographique
L'ARQC (Authorization Request Cryptogram) est un MAC calculé par la puce avec une clé de session, elle-même dérivée de sa clé maître, dérivée à son tour de la clé maître émetteur. Le calcul porte sur les données critiques de la transaction : montant, devise, date, compteur ATC, nombre imprévisible du terminal (UN), résultats de vérification (TVR)... L'émetteur, qui possède les mêmes clés, recalcule l'ARQC. La concordance des deux valeurs établit que la transaction provient de la carte authentique et que ses données n'ont pas été altérées en chemin. L'émetteur répond alors avec un ARPC, cryptogramme retour que la carte vérifie à son tour. Chacune des deux parties authentifie ainsi l'autre.
9F26 08 A1B2C3D4E5F60718 ARQC (8 octets) - le cryptogramme lui-meme
9F27 01 80 CID : 80 = ARQC (demande d'autorisation en ligne)
9F36 02 014A ATC : compteur de transactions de la puce (n. 330)
95 05 0000008000 TVR : resultats des controles terminal
9F37 04 1A2B3C4D UN : nombre imprevisible du terminal (anti-rejeu)
9F02 06 000000012550 montant autorise : 125,50
5F2A 02 0978 devise : EUR
9A 03 260711 date de transaction : 11/07/2026
9F10 12 0110A00003220000... IAD : donnees discretionnaires emetteur (CVR...)
82 02 3900 AIP : capacites de la carte (DDA, CDA...)CVM : vérifier le porteur
La CVM (Cardholder Verification Method) désigne la méthode retenue, dans une transaction donnée, pour vérifier que la personne présentant la carte en est le porteur légitime. La carte embarque une liste CVM ordonnée par préférence et conditionnée (montant, type de terminal). Le terminal exécute la première méthode applicable qu'il prend en charge.
| Méthode | Vérifiée par | Usage typique | Robustesse |
|---|---|---|---|
| PIN online | L'émetteur (PIN chiffré transporté dans l'autorisation) | DAB, standard dans certains pays | Très forte |
| PIN offline (chiffré) | La puce elle-même | Standard en proximité France/Europe | Très forte |
| PIN offline (clair) | La puce (PIN transmis en clair au lecteur) | Héritage ; en voie de disparition | Forte (vulnérable au terminal compromis) |
| Signature | Le commerçant (comparaison visuelle) | Marchés historiques (US pré-2015) | Faible |
| No CVM | Personne | Petits montants, sans contact carte, automates | Nulle, plafonnée (50 € en France) |
| CDCVM | L'appareil du porteur (biométrie/code du smartphone) | Apple Pay, Google Pay | Très forte, pas de plafond sans contact |
- La liste CVM est signée dans les données d'authentification offline : un fraudeur ne peut pas la dégrader discrètement sur une carte DDA/CDA correctement vérifiée.
- Le résultat de la vérification est tracé dans le CVR/TVR et remonte à l'émetteur dans l'IAD ; un émetteur peut refuser une transaction « no CVM » au-delà de ses seuils.
- En France, trois PIN faux consécutifs bloquent la puce (code réponse 75) ; le compteur est géré par la carte et remis à zéro par l'émetteur.
SDA, DDA, CDA : authentifier la carte hors ligne
L'authentification offline des données (ODA) vérifie l'authenticité de la carte sans contacter l'émetteur. Elle conditionne les transactions offline (avion, péage, plancher d'autorisation) et le sans contact rapide. Trois générations coexistent dans le standard, dont la première n'est plus admise pour les nouvelles émissions.
| Méthode | Principe | Faiblesse | Statut 2026 |
|---|---|---|---|
| SDA (Static Data Authentication) | Les données de la carte sont signées une fois pour toutes par l'émetteur (RSA) | Signature statique : clonable sur une « yes-card » qui approuve tout en offline | Obsolète, interdite pour les nouvelles émissions depuis des années |
| DDA (Dynamic Data Authentication) | La carte possède sa propre clé RSA et signe un défi dynamique du terminal | L'authentification et la génération du cryptogramme sont deux étapes séparées (attaque de type wedge possible en théorie) | Standard largement déployé |
| CDA (Combined DDA / AC) | La signature dynamique couvre aussi le cryptogramme de transaction (ARQC/TC) | – | Recommandé/exigé, notamment en sans contact |
La chaîne de confiance repose sur une PKI à trois étages. Les clés publiques des autorités de certification des schemes (CA) sont chargées dans les terminaux, et elles certifient les clés publiques émetteur, qui certifient les clés publiques carte. La révocation des clés CA, par rotations planifiées d'EMVCo, est un chantier récurrent des acquéreurs et des mainteneurs de parcs de TPE.
Sans contact : kernels et tokenisation mobile
Le kernel est le composant logiciel du terminal qui conduit le dialogue sans contact EMV avec la carte. Chaque scheme a historiquement spécifié le sien. Le standard compte huit kernels normalisés, d'où la complexité des certifications de TPE. Un terminal français doit en embarquer plusieurs et sélectionner le bon selon l'AID de la carte. EMVCo a publié le Kernel 8, générique et de nouvelle génération (crypto à courbes elliptiques, canal sécurisé), destiné à remplacer progressivement les kernels propriétaires.
| Kernel | Scheme / technologie | Remarque |
|---|---|---|
| Kernel 1 | Héritage (JCB/Visa historique) | En extinction |
| Kernel 2 | Mastercard (M/Chip, ex-PayPass) | Mode EMV complet, riche en fonctions offline |
| Kernel 3 | Visa (qVSDC, ex-payWave) | Optimisé vitesse : transaction en une passe |
| Kernel 4 | American Express (ExpressPay) | – |
| Kernel 5 | JCB (J/Speedy) | – |
| Kernel 6 | Discover (D-PAS) | – |
| Kernel 7 | UnionPay (QuickPass) | – |
| Kernel 8 | EMVCo nouvelle génération | Unifié, ECC, conçu pour succéder aux kernels 2-7 |
Le paiement mobile (Apple Pay, Google Pay) superpose au sans contact la tokenisation réseau. Le PAN réel est remplacé par un DPAN, token de device stocké dans le Secure Element ou en HCE. Chaque paiement produit un cryptogramme dynamique, et le commerçant comme son PSP ne voient jamais le numéro d'origine.
PCI DSS : protéger les données de carte
PCI DSS (Payment Card Industry Data Security Standard) est le standard de sécurité imposé contractuellement par les schemes à quiconque stocke, traite ou transmet des données de carte. La version 4.0.1 est en vigueur. Ses exigences futures s'appliquent depuis mars 2025. Douze exigences (pare-feu, chiffrement, gestion des accès, journalisation, tests, politique...) se déclinent en centaines de contrôles, avec un niveau de validation proportionné au volume.
| Niveau | Volume annuel (par scheme) | Validation exigée |
|---|---|---|
| Niveau 1 | > 6 M de transactions (ou compromission avérée) | Audit sur site annuel par QSA → ROC + AOC, scans ASV trimestriels |
| Niveau 2 | 1 à 6 M de transactions | SAQ annuel (QSA/ISA selon scheme), scans ASV trimestriels |
| Niveau 3 | 20 000 à 1 M de transactions e-commerce | SAQ annuel, scans ASV trimestriels |
| Niveau 4 | < 20 000 e-commerce ou < 1 M au total | SAQ annuel, scans selon exigences de l'acquéreur |
| SAQ | Périmètre | Poids indicatif |
|---|---|---|
| A | Externalisation totale de la page de paiement (redirection/iframe conforme) | ≈ 30 questions |
| A-EP | Site e-commerce dont le code influence la page de paiement (post direct, JS) | ≈ 190 questions |
| B / B-IP | TPE autonomes RTC / IP, sans stockage électronique | ≈ 40-80 questions |
| C / C-VT | Applications de paiement connectées / terminal virtuel isolé | ≈ 80-160 questions |
| P2PE | Solution de chiffrement point-à-point validée PCI P2PE | ≈ 30 questions |
| D | Tous les autres cas (stockage de PAN, prestataires de services) | 250+ questions |
- Réduire le périmètre avant de le sécuriser : iframe/redirection PSP + tokenisation ⇒ SAQ A au lieu de SAQ D ; c'est la décision d'architecture la plus rentable qui soit.
- PCI DSS v4 renforce l'e-commerce : inventaire et intégrité des scripts de page de paiement (exigences 6.4.3 et 11.6.1), en réponse directe aux attaques Magecart.
- La conformité est annuelle et continue : un AOC périmé est opposable par l'acquéreur en cas d'incident.
Chiffrement de bout en bout, skimming et contre-mesures
Entre la puce et le back-office, la donnée carte traverse des maillons attaquables : tête de lecture, mémoire du terminal, réseau du magasin, serveurs. Le P2PE/E2EE (chiffrement point-à-point) chiffre le PAN dès la lecture dans le module sécurisé du terminal (SRED). La clé de déchiffrement n'existe que chez le processeur. Un attaquant qui compromet la caisse ou le réseau ne voit que des cryptogrammes, et le périmètre PCI du commerçant se réduit drastiquement (SAQ P2PE).