Auditer un HSM pour la conformité PCI DSS dans les paiements

Un HSM (Hardware Security Module) certifié FIPS (Federal Information Processing Standards) 140-3 niveau 3 ne rend pas un environnement conforme à PCI DSS (Payment Card Industry Data Security Standard) : la certification porte sur le boîtier, l’audit porte sur la façon de s’en servir. Reste à savoir ce que l’évaluateur vérifie autour du module, et ce qui fait échouer un audit sur du matériel irréprochable.

→ Lire l’explication complète de la marmotte

Périmètre PCI DSS, PCI PIN et PCI PTS HSM

Trois référentiels se croisent. PCI DSS v4.0.1 protège les données de carte stockées et transmises ; ses exigences 3.6 et 3.7 couvrent la gestion des clés, quel que soit l’outil. PCI PIN Security s’applique à qui traite des codes PIN (Personal Identification Number) : acquéreurs, processeurs, gestionnaires de distributeurs. PCI PTS HSM (PIN Transaction Security) est une certification de produit, équivalente en esprit à FIPS 140, mais centrée sur les fonctions de paiement.

La conséquence d’architecture tranche le choix du matériel. Un HSM généraliste certifié FIPS suffit pour chiffrer des PAN (Primary Account Number) en base ou opérer une tokenisation sous PCI DSS. Dès qu’il faut traduire des blocs PIN, générer des CVV (Card Verification Value) ou vérifier des cryptogrammes EMV (Europay Mastercard Visa), il faut un HSM de paiement (Thales payShield, Utimaco Atalla ou équivalent), idéalement certifié PCI PTS HSM, avec son jeu de commandes hôte dédié. Un module généraliste ne passe pas un audit PCI PIN.

Recommandation : fixer le périmètre par référentiel avant de choisir le module, et dédier le HSM aux paiements. Un module partagé avec d’autres usages (signature de code, PKI, Public Key Infrastructure, interne) entre tout entier dans le périmètre, administrateurs et réseaux d’administration compris : le dédier coûte un boîtier, le partager coûte un audit plus large chaque année.

Exigences 3.6 et 3.7 : ce que l’évaluateur contrôle

Le QSA (Qualified Security Assessor) teste le processus, pas la cryptographie du module :

3.6.1.2 : les clés secrètes et privées sont soit chiffrées par une KEK (Key Encryption Key) au moins aussi forte, soit conservées dans un SCD (Secure Cryptographic Device) comme un HSM, soit détenues en au moins deux composants pleine longueur. La distinction entre KEK et DEK (Data Encryption Key), détaillée dans KEK ou DEK, doit apparaître dans la documentation d’architecture cryptographique exigée des prestataires par 3.6.1.1.
3.7.4 : chaque clé a une cryptopériode définie et respectée. Une clé de chiffrement des données jamais tournée depuis la mise en service est la non-conformité la plus banale ; la mécanique est détaillée dans la page sur la rotation des clés.
3.7.6 : double contrôle et connaissance partagée pour toute opération manuelle sur une clé non chiffrée. Sur le module, cela se traduit par un quorum de cartes d’administration (k parmi n) ; hors du module, par des composants de clé saisis par deux gardiens distincts, jamais par un seul.
3.7.7 : impossibilité de substituer une clé sans autorisation, ce qui renvoie aux attributs d’usage et au contrôle d’intégrité des blocs de clés.

L’erreur récurrente : un quorum configuré en 1 sur n « pour la maintenance », puis jamais rétabli. Vingt ans de cérémonies de clés apprennent que le quorum de maintenance devient toujours le quorum de production, avec un procès-verbal daté du jour de l’installation comme seule trace de la bonne intention.

Surface d’attaque d’un HSM de paiement

Les attaques connues visent l’interface de commandes, pas le boîtier. Les attaques d’interface publiées depuis le début des années 2000 (confusion de types de clés, attaque par table de décimalisation sur la vérification de PIN) exploitent des commandes légitimes enchaînées dans un ordre que le concepteur n’avait pas prévu. La contre-mesure structurelle est le bloc de clé : ANSI (American National Standards Institute) X9.143 (ex-TR-31) lie cryptographiquement une clé à son usage, ce qui interdit de réemployer une clé de chiffrement de PIN comme clé de chiffrement de données. PCI PIN impose sa généralisation par phases, dont le calendrier a été repoussé plusieurs fois : la date applicable se lit dans la version en vigueur, pas dans un souvenir de réunion.

Côté HSM généraliste, les oracles de padding RSA (Rivest-Shamir-Adleman) PKCS#1 (Public-Key Cryptography Standards) v1.5 restent exploitables à travers le déchiffrement PKCS#11 si le mécanisme CKM_RSA_PKCS est autorisé pour le déchiffrement ou le désemballage. Le désactiver par politique, et préférer OAEP (Optimal Asymmetric Encryption Padding), relève de l’exigence 12.3.3 sur l’inventaire annuel des suites et protocoles cryptographiques.

Enfin, une console d’administration joignable depuis le réseau bureautique annule le double contrôle : l’attaquant n’a plus besoin des cartes, seulement d’une session ouverte.

Exemple : collecter les preuves d’attributs de clés via PKCS#11

L’évaluateur demande des preuves que les clés, par exemple AES (Advanced Encryption Standard), sont non extractibles et que les mécanismes faibles sont bornés. Le script ci-dessous se reproduit avec SoftHSM2 et OpenSC sur Debian ou Ubuntu ; sur un HSM réel, seul le chemin du module change (voir PKCS#11 expliqué).

# Paquets : softhsm2 et opensc (pkcs11-tool)
sudo apt install -y softhsm2 opensc
MOD=/usr/lib/softhsm/libsofthsm2.so

# Jeton de démonstration (sur un HSM réel, le jeton existe déjà)
softhsm2-util --init-token --free --label pci-audit --so-pin 87654321 --pin 123456

# Clé AES-256 marquée sensible, jamais lisible hors du module
pkcs11-tool --module "$MOD" --token-label pci-audit --login --pin 123456 \
  --keygen --key-type AES:32 --label dek-pan --sensitive

# Preuve 3.6.1.2 : attributs d'accès de chaque objet (sensitive, never extractable)
pkcs11-tool --module "$MOD" --token-label pci-audit --login --pin 123456 \
  --list-objects | tee preuve-objets-$(date +%F).txt

# Preuve 12.3.3 : mécanismes exposés, en repérant le déchiffrement RSA PKCS#1 v1.5
pkcs11-tool --module "$MOD" --token-label pci-audit --list-mechanisms \
  | tee preuve-mecanismes-$(date +%F).txt | grep -E '^ *RSA-PKCS,'

La sortie Access: sensitive, always sensitive, never extractable, local est celle attendue pour une clé générée dans le module. Une clé importée, sans local, doit être rattachée à une cérémonie documentée sous double contrôle. SoftHSM expose RSA-PKCS sans restriction, ce qui est précisément le constat qu’un vrai HSM doit contredire par sa politique.

Ce que la conformité ne garantit pas, et l’exploitation

Un rapport de conformité (ROC, Report on Compliance) atteste un état à une date. Il ne garantit ni le quorum du lendemain, ni qu’une application appelante n’écrit pas de PAN déchiffrés en journal, ni la résistance à une attaque d’API (Application Programming Interface) non publiée. La protection des données en clair après sortie du HSM relève de l’application et de la cryptographie côté code ; le module ne voit que des appels.

En exploitation : exporter les journaux d’audit du HSM vers une collecte centralisée et les revoir (exigence 10), rejouer chaque année une restauration de clés avec le quorum réel, tenir le registre des sacs scellés et des cartes d’administration, tester la bascule d’une architecture HSM haute disponibilité sans désactiver le double contrôle « le temps du test ». Une restauration bloquée faute de gardien range disponibilité et conformité dans la même colonne rouge.

🐝 Ce qui arrive si on s’en passe

Sans audit de conformité du HSM, rien ne vérifie que le double contrôle et la connaissance partagée exigés par PCI-DSS pour la gestion des clés sont réellement appliqués : un seul administrateur peut alors charger, exporter ou remplacer un composant de clé sans qu’aucune trace ne l’attribue. Les journaux du module, s’ils ne sont ni collectés ni revus, ne permettent plus de reconstituer quelle clé a servi à quelle opération, ce qui prive l’enquête de toute chronologie après un incident. La configuration dérive aussi en silence : des mécanismes hérités restent actifs, comme le déchiffrement PKCS#1 v1.5 exploité dans « la question qui rend le module bavard ». Enfin, les périodes de validité des clés ne sont plus contrôlées, et l’organisme ne peut pas démontrer au QSA le périmètre couvert.

🦫 Explication de la marmotte 🍫

Les entreprises qui manipulent des numéros de cartes bancaires doivent suivre un règlement de sécurité écrit par les grands réseaux de cartes. Pour protéger ces numéros, elles les chiffrent avec des clés secrètes, et ces clés sont gardées dans un boîtier spécial qui refuse de les laisser sortir.

Chaque année, un contrôleur agréé vérifie non pas le boîtier, déjà testé par un laboratoire, mais la manière de s’en servir. Qui peut administrer le boîtier ? Faut-il deux personnes, chacune avec sa propre carte, pour toute opération sensible ? Chaque clé a-t-elle une date de remplacement, et ce remplacement a-t-il eu lieu ? Les clés sont-elles bien marquées comme impossibles à extraire ? Le boîtier garde-t-il un journal de chaque opération, et quelqu’un le lit-il ?

Les attaques connues n’ouvrent pas le boîtier. Elles enchaînent des commandes autorisées dans un ordre imprévu pour lui faire révéler un secret, ou utilisent une vieille méthode de chiffrement que le boîtier accepte encore. On se protège en attachant à chaque clé l’usage qui lui est permis et en désactivant les méthodes anciennes.

Sans ces contrôles, personne ne peut dire après un incident quelle clé a servi à quoi.

Pages voisines

La citent

Lire une certification FIPS 140-3 ou Critères Communs d'un HSM

Auditer un HSM pour la conformité PCI DSS dans les paiements

Elle cite

Auditer un HSM pour la conformité PCI DSS dans les paiements

Auditer un HSM pour la conformité PCI DSS dans les paiements

Périmètre PCI DSS, PCI PIN et PCI PTS HSM

Exigences 3.6 et 3.7 : ce que l’évaluateur contrôle

Surface d’attaque d’un HSM de paiement

Exemple : collecter les preuves d’attributs de clés via PKCS#11

Ce que la conformité ne garantit pas, et l’exploitation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines