Gestion des clés cryptographiques à grande échelle : HSM vs Cloud KMS

Pourquoi la gestion des clés est critique pour les banques et les plateformes crypto

La cryptographie protège les données des clients, les enregistrements de transactions, les numéros de carte et la conservation des actifs numériques. Mais la cryptographie n'est aussi solide que les clés qui la sous-tendent. Une clé de signature compromise permet à un attaquant de falsifier des transactions. Une clé de chiffrement divulguée expose tous les enregistrements qu'elle protégeait. Une clé racine perdue peut rendre des données chiffrées définitivement inaccessibles.

Pour les banques et les plateformes fintech régulées, la gestion des clés n'est pas une question de sécurité abstraite - c'est une obligation de conformité. PCI DSS impose des procédures documentées de cycle de vie des clés à toute organisation qui traite des données de porteurs de carte. MiCA impose aux prestataires de services sur crypto-actifs des politiques de conservation des clés privées, la protection matérielle étant la pratique attendue du marché. En France, l'ACPR supervise les établissements de paiement et l'AMF les prestataires de services sur crypto-actifs (PSCA), le régime PSAN ayant pris fin avec la période transitoire, achevée le 1er juillet 2026. L'ANSSI publie également des recommandations sur les mécanismes cryptographiques, dont le référentiel ANSSI-PG-083, passé en version 3.00 le 20 mars 2026 pour intégrer la menace quantique. Deux précisions utiles, parce qu'elles sont régulièrement escamotées : ce référentiel est non normatif sauf disposition réglementaire contraire - il s'impose par les schémas de certification et de qualification, pas directement à votre banque - et il exclut explicitement la gestion des clés, qui fait l'objet d'un document ANSSI distinct. Citer PG-083 comme source de vos durées de vie de clés est donc une erreur courante.

Le défi principal n'est pas de générer une clé solide - c'est résolu. Le défi est de gérer les clés à grande échelle : les faire tourner sans interruption de service, accorder l'accès uniquement aux processus autorisés, détecter les usages abusifs et retirer les clés de manière sécurisée en fin de vie.

Fondamentaux du HSM - ce que font les modules matériels de sécurité

Un Hardware Security Module (HSM) est un appareil physique dédié qui effectue des opérations cryptographiques à l'intérieur d'un périmètre résistant aux manipulations. Le matériel de clé ne quitte jamais le HSM en clair. Si vous tentez d'ouvrir le boîtier, il s'efface. En cas de coupure de courant inattendue, il s'efface également. La clé privée n'existe qu'à l'intérieur de la puce.

La certification de référence pour les HSM est FIPS 140, émise par le NIST américain, dans sa version 140-2 puis 140-3 qui lui succède. Le niveau 3 est celui qu'attendent en pratique la plupart des régulateurs bancaires et des schémas de carte : preuves physiques de manipulation, authentification basée sur l'identité, détection et réponse aux tentatives de sondage physique. Le calendrier de bascule 140-2 vers 140-3 conditionne les achats de matériel : demandez à votre fournisseur le statut de validation exact du modèle proposé, en cours de validité ou non, plutôt qu'une mention générique « FIPS » sur une fiche produit. En France, l'ANSSI qualifie par ailleurs certains produits dans le cadre des Critères Communs.

Le marché des HSM est concentré autour d'un petit nombre de constructeurs, parmi lesquels Thales, Entrust, Utimaco et IBM. Les gammes de produits et leur propriété ont bougé au fil des cessions du secteur : vérifiez qui édite réellement le modèle qu'on vous propose plutôt que de vous fier au nom de marque historique. Dans un déploiement bancaire de paiement typique, les HSM sont installés dans le rack du centre de données, connectés aux serveurs de traitement des paiements via un segment réseau dédié.

Cloud KMS - capacités et comparaison

Les services de Cloud KMS fournissent la gestion des clés cryptographiques via une API, le fournisseur gérant le matériel sous-jacent. Les trois principales options sont AWS KMS, Google Cloud KMS et Azure Key Vault. Tous s'appuient, selon les documentations des fournisseurs, sur des HSM validés FIPS 140 dans leurs centres de données - mais le client ne gère pas ces HSM directement, et le niveau de validation revendiqué varie selon l'offre et la région : c'est un point à vérifier dans le certificat, pas dans la brochure.

L'avantage opérationnel est significatif : pas de matériel à gérer, pas de capacité à planifier, pas de firmware à patcher. Pour les équipes fintech cloud-native sans personnel dédié aux opérations cryptographiques, Cloud KMS abaisse considérablement la barrière à une bonne gestion des clés. Concernant la résidence des données, les entités régulées par l'ACPR doivent prendre en compte les règles d'externalisation informatique et peuvent être soumises à des exigences de localisation. AWS Paris (eu-west-3) et GCP Paris offrent une résidence des données en France, ce qui facilite la conformité avec les attentes de l'ACPR et de la CNIL. Sur SecNumCloud, une nuance essentielle et contre-intuitive : le référentiel v3.2 ne prétend pas vous protéger techniquement contre un accès du fournisseur. Il l'écrit lui-même - les garanties sont contractuelles, et il renvoie le client qui veut une protection technique vers un chiffrement supplémentaire déployé sous son propre contrôle.

HSM vs Cloud KMS - matrice de décision

Aucune option n'est universellement supérieure. Le bon choix dépend de vos obligations réglementaires, de votre maturité opérationnelle, du volume et de la sensibilité de la charge de travail.

Un schéma courant pour les fintech régulées en France : Cloud KMS pour le chiffrement au niveau applicatif (données au repos, signature API, gestion des secrets) et un HSM dédié ou Cloud-HSM pour les opérations les plus sensibles (génération de clés de carte, clés privées de crypto-actifs, authentification des messages de paiement). Cela répartit la charge opérationnelle tout en maintenant le matériel le plus critique dans le hardware.

Chiffrement en enveloppe et cycle de vie des clés

Le chiffrement en enveloppe (envelope encryption) est le schéma standard pour chiffrer de grands volumes de données sans tout envoyer via l'API du KMS. Au lieu de chiffrer chaque enregistrement directement avec la clé maîtresse, on génère localement une Clé de Chiffrement de Données (DEK) éphémère, on chiffre les données avec le DEK, puis on chiffre le DEK avec une Clé de Chiffrement de Clés (KEK) conservée dans le KMS ou le HSM. Le DEK chiffré voyage avec le texte chiffré. Pour déchiffrer, on appelle le KMS pour déballer le DEK, puis on déchiffre localement.

Le cycle de vie des clés couvre quatre phases : génération (création du matériel de clé dans un environnement contrôlé et audité) ; usage actif (la clé est opérationnelle et les accès sont journalisés) ; rotation (la nouvelle version prend le relais ; l'ancienne ne déchiffre que les données héritées) ; et destruction (le matériel de clé est effacé de tous les stockages, les journaux confirment la suppression). L'exigence 3 de PCI DSS impose que l'intégralité de ce cycle de vie soit documentée dans une politique formelle de gestion des clés. Attention à la source côté français : le référentiel ANSSI sur le choix des mécanismes cryptographiques (PG-083) exclut expressément la gestion des clés et renvoie à un document dédié. Ne lui faites pas dire ce qu'il ne dit pas.

BYOK et HYOK - contrôler qui peut accéder à vos clés

La question de souveraineté dans la gestion des clés en cloud se réduit à deux modèles :

BYOK (Bring Your Own Key) signifie que vous générez votre matériel de clé maîtresse dans votre propre HSM (ou un environnement contrôlé localement), puis vous l'importez dans le KMS du fournisseur cloud. Le fournisseur stocke et utilise la clé pour votre compte, mais vous l'avez créée et vous conservez l'original. Si vous devez révoquer la capacité du fournisseur à utiliser la clé, vous supprimez l'import et rechiffrez avec une nouvelle clé. Cela satisfait de nombreuses interprétations réglementaires de la "propriété de la clé" tout en conservant l'opérabilité du Cloud KMS.

HYOK (Hold Your Own Key) va plus loin : le matériel de clé maîtresse n'entre jamais dans l'infrastructure du fournisseur cloud. Les demandes de déchiffrement sont acheminées vers votre HSM on-premises ou un service de clés tiers. Le système du fournisseur cloud ne chiffre et ne déchiffre les données que lorsque votre HSM approuve l'opération. Chez GCP, cela s'appelle External Key Management (EKM) ; Azure propose un équivalent via Managed HSM. Dans le contexte français, HYOK est cohérent avec la logique de SecNumCloud, mais pas parce que le référentiel l'exigerait : SecNumCloud n'impose ni clés détenues par le client, ni même de HSM - son chapitre 10.5 accepte un conteneur de sécurité logiciel aussi bien que matériel, et le mot HSM n'y figure nulle part. C'est l'inverse : comme le référentiel reconnaît ne pas offrir de garantie technique contre le fournisseur, c'est au client d'ajouter son propre chiffrement s'il en veut une. HYOK est l'une des façons de le faire.

Pour la plupart des fintech cloud-native, BYOK suffit pour satisfaire les régulateurs tout en préservant l'opérabilité. HYOK vaut la latence supplémentaire et la complexité quand les réglementations exigent spécifiquement que le fournisseur cloud ne puisse pas accéder au matériel de clé en aucune circonstance - comme le prévoient certaines règles nationales de conservation des crypto-actifs et les attentes les plus strictes de l'AMF/ACPR.

Conformité : PCI DSS, MiCA et conservation crypto en France

La gestion des clés se situe à l'intersection de plusieurs cadres réglementaires, et les exigences se recoupent sans être identiques.

PCI DSS v4.0.1 (Exigence 3) impose une cryptographie forte pour les données de porteurs de carte stockées et des procédures documentées de gestion des clés. Mais le contenu réel de l'exigence est plus souple, et souvent mal cité :

L'exigence 3.7.5 impose le retrait, le remplacement ou la destruction d'une clé sur trois déclencheurs : la fin de sa cryptopériode, l'affaiblissement de son intégrité - ce qui inclut explicitement le départ d'une personne connaissant un composant de clé en clair - et une compromission suspectée ou avérée. Une clé retirée ne doit plus servir aux opérations de chiffrement ; la conserver reste facultatif, mais si vous la conservez, elle doit être archivée de manière sécurisée. Le standard cite la clé de chiffrement de clés comme exemple de mécanisme d'archivage, il ne l'impose pas.

L'exigence 3.7.6 est elle aussi plus étroite qu'on ne le croit : le partage des connaissances et le contrôle dual ne s'appliquent qu'aux opérations manuelles de gestion de clés en clair réalisées par des personnes. Ce qui déclenche l'exigence, ce n'est pas l'absence de HSM, c'est le fait qu'un opérateur humain manipule un composant de clé en clair. Une cérémonie de clés manuelle autour d'un HSM la déclenche donc bel et bien.

MiCA impose aux prestataires de services sur crypto-actifs (PSCA) des politiques de conservation des clés privées. En France, la période transitoire s'est achevée le 1er juillet 2026 : le régime PSAN appartient désormais au passé, et seuls les PSCA agréés peuvent fournir ces services. L'AMF et l'ACPR attendent que les contrôles techniques de conservation soient documentés et audités. Sur le détail de ce qu'exigent précisément les textes de niveau 2 en matière de protection matérielle des clés et d'autorisation multi-parties, appuyez-vous sur le texte applicable et sur votre conseil : c'est un point où les résumés de seconde main se contredisent.

La plateforme Crassula est construite nativement dans le cloud sur Google Cloud, ce qui signifie que Cloud KMS et Cloud HSM constituent la couche native de gestion des clés. Pour les clients nécessitant une protection des clés de paiement au niveau PCI ou une conservation de crypto-actifs conforme à MiCA/AMF, l'architecture Crassula prend en charge l'intégration HSM dédiée et les flux d'import de clés BYOK.

Post-quantique : ce que l'ANSSI a daté, et ce qu'il faut décider maintenant

C'est le changement le plus structurant de 2026 pour la gestion des clés, et il a une date. Le référentiel ANSSI-PG-083 est passé en version 3.00 le 20 mars 2026, succédant à la version 2.04 de janvier 2020. La nature de la révision tient en quatre mots dans le document lui-même : « Menace quantique prise en compte ».

La règle qui structure tout le reste est celle du long terme : tout mécanisme destiné à être utilisé au-delà du 1er janvier 2030, ou exposé au risque d'attaque rétroactive - la logique du « collecter maintenant, déchiffrer plus tard » - devrait viser une sécurité post-quantique. Autrement dit : une donnée que vous chiffrez aujourd'hui et qui doit rester confidentielle en 2032 est déjà concernée. Pour une banque, cela vise en priorité les archives, les dossiers KYC et tout ce qui a une durée de rétention longue.

Deux réserves d'honnêteté. D'abord, PG-083 est non normatif : « sauf disposition réglementaire contraire, les recommandations n'ont pas de caractère normatif ». Il ne s'impose à vous que par le canal des certifications et qualifications, ou si un texte le rend obligatoire. Ensuite, l'échéance du 1er janvier 2030 est le jalon français : d'autres jalons européens existent, et nous ne les citerons pas ici faute d'avoir pu les vérifier avec le même niveau de source. Traitez 2030 comme un plancher de planification, pas comme la seule date au calendrier.

La conséquence opérationnelle est immédiate, et elle est moins glamour que la cryptographie elle-même : vous ne pouvez migrer que ce que vous avez inventorié. Savoir quelle clé protège quelle donnée, avec quel algorithme, quelle taille et quelle durée de rétention, c'est le préalable à toute bascule post-quantique. Les organisations qui souffriront en 2029 sont celles qui découvriront à ce moment-là qu'elles n'ont pas cet inventaire.

Key blocks et injection de clés : les échéances PCI sont derrière vous

Les obligations vraiment prescriptives sur les clés ne sont pas dans PCI DSS : elles sont dans les standards frères, et leurs échéances sont désormais toutes passées. Si vous démarrez un chantier en 2026, vous êtes en rattrapage, pas en anticipation.

PCI P2PE impose que les clés symétriques chiffrées soient gérées sous forme de key blocks, avec l'usage de la clé lié cryptographiquement à la clé elle-même (exigence 18-3), selon un calendrier en trois phases : 1er juin 2019 pour les connexions internes et le stockage des clés dans les environnements des prestataires, y compris toutes les applications et bases connectées aux HSM ; 1er janvier 2023 pour les connexions externes vers les schémas et réseaux ; 1er janvier 2025 pour l'ensemble des hôtes commerçants, terminaux et distributeurs.

L'injection de clés en clair a suivi le même chemin (exigence 32-9, domaine 5) pour les terminaux POI v5 et supérieurs en centre d'injection : 1er janvier 2024 pour les entités qui injectent des clés pour le compte de tiers dans le cadre de nouveaux déploiements, et 1er janvier 2026 pour celles qui injectent les terminaux dont elles sont le processeur. Les composants de clé saisis au clavier d'un terminal POI approuvé PCI restent exemptés.

Un dernier point de périmètre, utile quand un fournisseur brandit une certification : PCI PTS HSM est un standard d'approbation d'équipement. Il couvre la conception du matériel et sa gestion jusqu'à la réception sur le lieu de déploiement, puis il passe explicitement la main à l'établissement financier acquéreur et à ses agents. Il ne peut donc pas servir de source à vos obligations opérationnelles de rotation, de cryptopériode ou de retrait de clés. Un HSM approuvé ne rend pas vos procédures conformes.

Références

Les affirmations normatives de ce guide s'appuient sur les sources primaires suivantes, consultées le 16 juillet 2026. Les versions des standards bougent vite dans ce domaine : redatez systématiquement ce que vous citez.

• PCI Security Standards Council, publication de PCI DSS v4.0.1 (11 juin 2024) et note sur les exigences à date différée (64 exigences nouvelles, dont 51 différées au 31 mars 2025).
• PCI DSS v4.0.1, exigences 3.7.4 (cryptopériode), 3.7.5 (retrait des clés) et 3.7.6 (partage des connaissances et contrôle dual), consultées dans le standard lui-même.
• PCI P2PE, exigences 18-3 (key blocks) et 32-9 (injection de clés en clair) ; PCI PTS HSM (standard d'approbation d'équipement, périmètre limité à la réception sur site).
• ANSSI, ANSSI-PG-083, « Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques », version 3.00 du 20 mars 2026 (RègleFactorisation, RègleSécuAsym, RèglePQSécuAsym, RecoSécuLongTerme). Document non normatif sauf disposition réglementaire contraire, et excluant la gestion des clés.
• ANSSI, référentiel SecNumCloud v3.2, chapitre 10.5 « Gestion des secrets » et avertissement sur l'absence de garantie technique contre l'accès du fournisseur.
• NIST, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA).

Ce guide décrit un état des standards au 16 juillet 2026 et ne constitue pas un conseil juridique ni un audit. Plusieurs points volontairement absents ici - obligations cryptographiques précises de DORA et de son RTS, calendrier européen post-quantique, statut de validation FIPS 140-3 - n'ont pas pu être vérifiés au niveau de source exigé pour ce guide et méritent une vérification dédiée avant toute décision d'architecture.

FAQ