HSM (module de sécurité matériel)

Un module de sécurité matériel (HSM) est un dispositif matériel dédié et inviolable qui génère, stocke et utilise des clés cryptographiques, de sorte que le matériel de la clé n'existe jamais en clair en dehors du dispositif. Chaque opération sensible — créer une clé, signer, chiffrer ou désenvelopper une autre clé — se déroule à l'intérieur de la frontière renforcée du HSM lui-même.

Un HSM ne concerne pas qui contrôle une clé ; c'est le rôle des clés gérées par le client. Un HSM concerne l'endroit où la clé réside physiquement et la façon dont elle est protégée. C'est la racine de confiance matérielle qui se trouve souvent sous un service de gestion de clés (KMS) : l'endroit où réside réellement « votre propre » clé.

Ce que fait réellement un HSM

Un HSM concentre quatre capacités dans un seul dispositif renforcé :

• Génération de clés. Les clés sont créées sur le dispositif à l'aide d'un véritable générateur de nombres aléatoires matériel (TRNG), produisant des clés à plus forte entropie que le logiciel seul.
• Stockage sécurisé. Les clés privées et secrètes restent à l'intérieur de la frontière cryptographique et ne sont jamais exportées en clair ; au mieux, elles sortent enveloppées (chiffrées) par une autre clé qui, elle non plus, ne sort jamais.
• Opérations sur le dispositif. La signature, le chiffrement, le déchiffrement et l'enveloppement/désenveloppement de clés s'exécutent à l'intérieur du HSM ; l'application envoie donc les données et reçoit un résultat sans jamais manipuler la clé brute.
• Contrôle d'accès et audit. Une authentification forte, la séparation des rôles et une journalisation inviolable déterminent qui peut utiliser chaque clé et enregistrent la façon dont elle a été utilisée.

Comme la clé ne sort jamais sous une forme utilisable, voler le serveur qui l'entoure ne donne pas la clé.

HSM, KMS et CMK/BYOK

Ces termes sont souvent utilisés de façon interchangeable, mais ils répondent à des questions différentes :

• KMS (service de gestion de clés) est le logiciel qui gère le cycle de vie des clés : création, rotation, politiques, accès et audit, généralement exposé sous forme d'API.
• HSM est la racine de confiance matérielle. Un KMS est fréquemment « adossé à un HSM », ce qui signifie que les clés maîtresses qu'il gère sont réellement générées et conservées à l'intérieur d'un HSM.
• CMK / BYOK concerne le contrôle : c'est vous, et non le fournisseur, qui possédez et administrez la clé.

En résumé : la CMK décide qui contrôle la clé, un KMS décide comment la clé est gérée, et un HSM décide où la clé réside et à quel point sa garde est inviolable. Une clé gérée par le client réside très souvent dans un KMS adossé à un HSM.

Assurance : FIPS 140-3, inviolabilité et interfaces

La valeur d'un HSM repose sur une assurance indépendante que ses protections tiennent réellement.

• FIPS 140-3. C'est la norme actuelle des États-Unis et du Canada pour les modules cryptographiques, qui remplace FIPS 140-2 (dont les validations sont en cours de retrait). Elle définit quatre niveaux de sécurité (1 à 4) de protection physique et logique croissante ; les HSM sont couramment validés au niveau 3, qui ajoute la détection et la réponse aux tentatives d'effraction ainsi que l'authentification basée sur l'identité.
• Inviolabilité. Les HSM associent la preuve d'effraction (on voit qu'il a été ouvert) à la réponse à l'effraction (les clés sont effacées si la frontière est franchie). Beaucoup sont également évalués selon les Critères communs.
• Interfaces standard. Les applications communiquent avec les HSM via PKCS#11 (une API locale, aussi appelée Cryptoki, pour dialoguer avec un jeton cryptographique) et KMIP (un protocole réseau de gestion de clés entre un client et un KMS ou un HSM).

Appliance sur site, HSM cloud et quand en avoir besoin

Les HSM se présentent sous plusieurs formes de déploiement :

• Appliance sur site. Un dispositif physique dans votre propre centre de données, qui vous donne la garde directe du matériel.
• HSM cloud. Une instance de HSM dédiée et mono-locataire louée auprès d'un fournisseur cloud : c'est toujours un vrai HSM, simplement hébergé et exploité à distance.
• KMS adossé à un HSM. Un KMS géré dont les clés maîtresses résident dans des HSM en coulisses, ce qui apporte une grande partie de l'assurance sans que vous ayez à exploiter le matériel.

Vous avez généralement besoin d'un HSM lorsqu'une réglementation ou un contrat exige une racine de confiance matérielle : services financiers et paiements (par exemple PCI DSS), charges de travail du secteur public et de la défense, et infrastructures à clé publique telles qu'une autorité de certification racine ou émettrice.

HSM et ARTESCA

ARTESCA n'est pas un HSM et n'en contient pas. ARTESCA est plutôt conçu pour garder les clés de chiffrement entièrement hors de la baie de stockage et déléguer leur garde à un gestionnaire de clés que vous contrôlez, lequel peut être adossé à un HSM.

ARTESCA chiffre les objets au repos au moyen du chiffrement côté serveur avec chiffrement d'enveloppe : chaque objet reçoit une clé de données unique, et cette clé de données est enveloppée par une clé maîtresse. Lorsqu'ARTESCA est configuré avec un KMS externe, le matériel de la clé maîtresse ne quitte jamais le KMS : seule une référence (l'ID de la clé) est stockée dans les métadonnées de l'objet, et les données de l'objet ne sont jamais envoyées au KMS. Les backends externes pris en charge incluent des gestionnaires de clés compatibles KMIP (comme Thales CipherTrust Manager, HashiCorp Vault et HyTrust KeyControl) et des services compatibles AWS KMS. Chacun d'eux peut, à son tour, être adossé à un HSM comme racine de confiance.

Le résultat est une séparation « zéro confiance » nette : vos données résident dans ARTESCA, vos clés résident dans votre KMS ou HSM, et aucun système unique ne détient les deux. Cela complète les clés gérées par le client pour le contrôle de la clé et S3 Object Lock pour l'immuabilité des données.

FAQ sur les HSM

Quelle est la différence entre un HSM et un KMS ?

Un KMS est un logiciel qui gère le cycle de vie des clés (création, rotation, politiques et accès). Un HSM est le matériel inviolable où les clés peuvent être générées et conservées. Ils sont complémentaires : un KMS est souvent « adossé à un HSM », utilisant un HSM comme racine de confiance.

Un HSM cloud est-il toujours un « vrai » HSM ?

Oui. Un HSM cloud est un module matériel dédié et mono-locataire exploité par un fournisseur cloud pour votre compte. Le matériel et sa validation FIPS sont réels ; seuls l'hébergement et la garde physique diffèrent d'une appliance sur site.

Que signifie un niveau FIPS 140-3 ?

FIPS 140-3 définit quatre niveaux de protection pour les modules cryptographiques. Les niveaux supérieurs ajoutent une authentification plus forte et une protection physique contre l'effraction. Les HSM sont couramment validés au niveau 3, qui exige la détection et la réponse aux effractions ainsi que l'authentification basée sur l'identité.

Ai-je besoin d'un HSM pour utiliser des clés gérées par le client ?

Pas nécessairement. Les clés gérées par le client concernent la question de savoir qui contrôle la clé et peuvent être conservées dans un KMS logiciel. Un HSM renforce l'assurance en garantissant que le matériel de la clé réside dans du matériel inviolable, c'est pourquoi de nombreuses clés gérées par le client se trouvent dans un KMS adossé à un HSM.

PKCS#11 ou KMIP : quelle différence ?

PKCS#11 est une API locale permettant à une application d'utiliser un jeton cryptographique ou un HSM sur le même système. KMIP est un protocole réseau de gestion des clés entre un client et un KMS ou un HSM. Ce sont des normes complémentaires ; ARTESCA s'intègre avec des gestionnaires de clés externes via KMIP.