Cryptographie post-quantique pour les prestataires de services de paiement

Un prestataire de services de paiement (PSP) peut commencer sa migration post-quantique dès maintenant, sur les éléments qu'il maîtrise seul : le TLS des points de terminaison publics et partenaires, le trafic interne de service à service, l'administration SSH, et l'inventaire cryptographique que PCI DSS demande déjà. Les éléments qui dépendent de tiers, à savoir les spécifications des réseaux de cartes, la cryptographie EMV des puces et du sans contact, les modules matériels de sécurité (HSM) et les terminaux de paiement, évoluent au rythme de leurs fournisseurs. Tout l'exercice consiste à séparer les deux : migrer ce qui vous appartient, documenter ce qui ne vous appartient pas, et conserver l'ensemble dans un seul inventaire daté.

Pourquoi l'échange de clés passe en premier

RSA, ECDSA, EdDSA, ECDH et le Diffie-Hellman sur corps finis sont tous cassés par l'algorithme de Shor sur un ordinateur quantique suffisamment puissant, quelle que soit la taille de clé. Aucune date crédible pour une telle machine n'est avancée ici. Ce qui compte pour les paiements, c'est la forme du risque, appelée harvest now, decrypt later (HNDL, « récolter maintenant, déchiffrer plus tard ») : le trafic capturé aujourd'hui n'est protégé que par l'échange de clés qui a produit la clé de session, de sorte qu'un attaquant qui l'enregistre pourra le déchiffrer plus tard, lorsque cet échange de clés deviendra cassable. Une signature est différente : la falsifier n'a d'intérêt que tant que la signature est encore considérée comme fiable.

C'est pourquoi l'échange de clés hybride passe en premier et les signatures ensuite. Pour un PSP, le trafic enregistré est concret : messages d'autorisation, appels aux API de tokenisation, fichiers de règlement et de rapprochement, transferts par lots vers les acquéreurs et les processeurs, et sessions d'administration dans l'environnement des données des titulaires de cartes. Notre article sur le harvest now, decrypt later détaille ce raisonnement. Un groupe hybride combine un échange de clés classique avec ML-KEM (Module Lattice Key Encapsulation Mechanism), publié par le NIST sous la référence FIPS 203 le 13 août 2024, de sorte que la session reste au moins aussi robuste qu'aujourd'hui même si l'un des deux composants venait à céder.

Ce qu'un PSP peut migrer dès maintenant

• Points de terminaison HTTPS publics : pages de paiement hébergées, scripts de checkout, tableaux de bord marchands, récepteurs de webhooks et API publiques. Le groupe hybride X25519MLKEM768 (codepoint IANA 0x11EC, voir le registre des paramètres TLS) est proposé par défaut par les versions actuelles de Chrome, Edge et Firefox, et les clients qui ne le prennent pas en charge négocient à la place le groupe classique.
• TLS de service à service au sein de l'environnement des données des titulaires de cartes, où vous maîtrisez les deux extrémités et pouvez mettre à jour les bibliothèques selon votre propre calendrier.
• Administration SSH : OpenSSH 9.9 (19 septembre 2024) a ajouté mlkem768x25519-sha256, OpenSSH 10.0 (9 avril 2025) en a fait l'accord de clés par défaut, et OpenSSH 10.1 (6 octobre 2025) affiche un avertissement lorsqu'une connexion négocie un accord de clés non post-quantique. Voir les notes de version d'OpenSSH.
• Reliquats pré-normalisation : tout groupe X25519Kyber768Draft00 restant (codepoint 0x6399) est obsolète et devrait être remplacé par les groupes ML-KEM.
• L'inventaire lui-même, qui relève de la documentation plutôt que d'un projet cryptographique, et qui constitue le livrable qu'un évaluateur demandera généralement en premier.

Vérifiez ce qu'un point de terminaison négocie aujourd'hui avant de modifier quoi que ce soit. OpenSSL 3.5 ou une version ultérieure est nécessaire pour les groupes ML-KEM :

openssl version
openssl s_client -connect api.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i negotiated

Sur un nginx compilé avec OpenSSL 3.5 ou une version ultérieure, le groupe hybride s'active en le plaçant avant les groupes classiques, ce qui préserve le repli :

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Les noms de directives et de groupes pris en charge varient selon les serveurs et les distributions : vérifiez-les sur votre propre build. Testez d'abord en préproduction, puis surveillez les taux d'échec de handshake et la compatibilité des clients après chaque changement en production. Le partage de clé hybride est plus volumineux qu'un partage classique, ce qui peut avoir un impact sur les liaisons contraintes et sur les anciens équipements intermédiaires qui inspectent le handshake. L'accord de clés hybride pour TLS 1.3 est spécifié dans la RFC 10024 (août 2026).

Ce qui dépend des réseaux de cartes, des fournisseurs de HSM et des terminaux

Les domaines suivants ne relèvent pas de la décision d'un PSP. Aucune date post-quantique n'est indiquée ici à leur sujet, car ce site ne publie que des sources primaires datées, et les réseaux de cartes, EMVCo et les fournisseurs de HSM sont seuls à faire autorité sur leurs propres plans.

• La cryptographie EMV des puces et du sans contact, y compris l'authentification des données hors ligne, qui repose sur des clés RSA et à courbes elliptiques fixées par la spécification.
• Les interfaces réseau des réseaux de cartes et les hiérarchies de clés qu'elles imposent aux acquéreurs et aux processeurs.
• Le firmware des HSM, les configurations certifiées, et la prise en charge PKCS#11 de ML-KEM et ML-DSA (Module Lattice Digital Signature Algorithm, FIPS 204).
• Les formats de key blocks et la cryptographie liée au code PIN.
• Le matériel des terminaux de paiement, dont le cycle de remplacement se compte en années.

Interprétation, et non exigence : attribuez à chacune de ces dépendances une ligne dans l'inventaire, avec un responsable interne, la position publiée du fournisseur s'il en existe une, et une date de revue. Lorsqu'un bulletin d'un réseau de cartes ou une note de version d'un HSM paraît, cette ligne évolue et l'historique montre quand vous en avez eu connaissance. Les questionnaires fournisseurs lors du renouvellement des contrats constituent l'autre levier : demandez une feuille de route écrite plutôt que de supposer qu'elle existe.

PCI DSS 12.3.3 en constitue déjà l'ossature

L'exigence 12.3.3 de PCI DSS v4.0.1 demande que les suites de chiffrement et les protocoles utilisés soient documentés et revus au moins une fois tous les 12 mois. Elle comporte trois volets : un inventaire à jour indiquant la finalité de chaque algorithme et l'endroit où il est utilisé, une surveillance de la viabilité continue de ce qui est en usage, et une stratégie documentée pour répondre aux évolutions anticipées des vulnérabilités cryptographiques. Elle est obligatoire depuis le 31 mars 2025, après avoir été une bonne pratique jusqu'à cette date ; la norme est disponible dans la bibliothèque documentaire du PCI SSC. Notre guide sur l'inventaire cryptographique PCI DSS 12.3.3 en détaille la structure, et la page de référence PCI DSS v4.0.1 recense les jalons datés.

Lisez attentivement le troisième volet. Les évolutions anticipées des vulnérabilités cryptographiques, c'est là que le post-quantique trouve sa place. Interprétation : la vulnérabilité quantique de l'échange de clés RSA et à courbes elliptiques constitue une telle évolution anticipée, de sorte que la stratégie 12.3.3 d'un PSP peut mentionner l'échange de clés hybride, indiquer quels points de terminaison sont déjà migrés, et lister les dépendances aux réseaux de cartes et aux HSM avec leurs responsables. L'exigence 12.3.3 n'impose pas ML-KEM aujourd'hui.

DORA : ce que le texte exige des entités financières de l'UE

Le règlement délégué (EU) 2024/1774 de la Commission, qui constitue les normes techniques de réglementation relatives à la gestion du risque lié aux TIC au titre de DORA, s'applique aux entités financières de l'UE, y compris les établissements de paiement et de monnaie électronique. L'Art. 6 exige une politique de chiffrement et de contrôles cryptographiques comprenant des dispositions pour mettre à jour ou modifier la technologie cryptographique en fonction des avancées de la cryptanalyse. L'Art. 7 exige une gestion des clés sur l'ensemble de leur cycle de vie et un registre des certificats pour les actifs TIC soutenant des fonctions critiques ou importantes. Les deux sont résumés avec leurs jalons sur la page de référence DORA.

Le texte ne nomme aucun algorithme et ne fixe aucune date post-quantique. Interprétation : l'Art. 6 est satisfait par une politique prévoyant un élément déclencheur défini et un circuit d'approbation pour changer d'algorithme, et l'Art. 7 par un registre des certificats qui consigne déjà l'algorithme et la taille de clé, ce qui en fait l'endroit naturel pour repérer ce qui repose encore sur RSA ou ECDSA. NIS2 Art. 21(2)(h) demande des politiques et procédures relatives à l'utilisation de la cryptographie en des termes similaires, par le biais de la transposition nationale. Cet article est fourni à titre informatif et ne constitue pas un conseil juridique.

De l'exigence à la preuve

Dates officielles pour la planification

Aucune de ces sources n'est propre aux paiements, et aucune ne constitue une échéance légale pour un PSP sauf si la dernière colonne l'indique. Conservez les nuances lorsque vous les citez en interne.

Commencez par les points de terminaison visibles

L'étape utile la plus rapide consiste à mesurer ce que vos points de terminaison de paiement publics négocient aujourd'hui, puis à décider de l'ordre des travaux : analysez votre domaine avec PQC Status pour vérifier la prise en charge de ML-KEM hybride, les versions de TLS et la chaîne de certificats. Lancez l'analyse séparément sur le domaine de checkout, l'hôte de l'API et l'hôte des webhooks, car ils se trouvent souvent derrière des terminaisons TLS différentes. Consignez chaque résultat dans l'inventaire 12.3.3 avec sa date, ajoutez les dépendances aux réseaux de cartes, aux HSM et aux terminaux comme lignes ouvertes avec leurs responsables, et fixez la prochaine revue à douze mois au plus.