Le HSM n'est pas un coffre-fort

Éditorial

Un module matériel de sécurité empêche qu'on vole une clé ; il n'empêche pas qu'on s'en serve. Entre les deux se trouve presque tout le risque réel, et presque rien de ce qu'on achète.

Mis à jour le 25 septembre 2026~24 min de lecture12 sections

papy cyber

→ Lire l’explication complète de la marmotte

Le coffre-fort et le guichet

Le module matériel de sécurité jouit, dans les salles de réunion, d’une réputation que peu d’objets techniques ont méritée. On le présente comme un coffre-fort. On dit « la clé est dans le HSM » sur le ton qu’on prend pour dire « les bijoux sont à la banque », et la réunion passe au point suivant, apaisée. Il y a des mots qui ferment les discussions mieux qu’un argument ; « HSM » en est un, avec « chiffré » et « conforme ».

L’image est fausse, et elle est fausse d’une manière instructive. Un coffre-fort protège un objet en empêchant qu’on s’en approche. Un HSM protège une clé en empêchant qu’on l’emporte, mais il est construit, précisément, pour qu’on s’en serve. Il passe ses journées à signer, déchiffrer, dériver, envelopper, pour quiconque se présente avec le bon identifiant. Ce n’est pas un coffre, c’est un guichet, avec une employée d’une probité absolue qui ne vous laissera jamais toucher le tampon, mais qui tamponnera sans ciller tout ce que vous lui tendrez, pourvu que vous ayez le bon ticket.

La différence n’est pas une nuance de vocabulaire. Elle sépare deux familles de menaces que le discours commercial confond volontiers : le vol de la clé, contre lequel le HSM est remarquable, et l’usage abusif de la clé, contre lequel il ne fait à peu près rien par lui-même. Or, dans la plupart des scénarios réalistes de compromission, l’attaquant n’a pas besoin de voler la clé. Il lui suffit de s’asseoir à la place de l’application légitime et de demander poliment.

Les deux éditoriaux précédents, sur la révocation et sur les certificats courts, supposaient tacitement qu’une clé compromise est une clé copiée. Celui-ci examine l’autre hypothèse, qui est la plus fréquente et la moins vendue.

Ce que le HSM protège vraiment

Rendons d’abord au module ce qui lui appartient, et c’est beaucoup.

Un HSM est un calculateur spécialisé, enfermé dans une enveloppe conçue pour résister à l’ouverture, qui génère des clés en son sein, les conserve dans sa mémoire protégée, et effectue les opérations cryptographiques sans jamais exposer la clé en clair à l’extérieur. La page de ce site sur la protection des données avec un HSM en décrit le fonctionnement ; retenons les propriétés.

La clé ne sort pas. Une clé générée dans le module avec les bons attributs (en PKCS#11 : marquée sensible et non extractible) ne peut pas être lue par l’application, ni par l’administrateur du serveur, ni par un attaquant qui aurait pris le contrôle total de la machine hôte. Elle n’apparaît dans aucun vidage mémoire, aucune sauvegarde de disque, aucun instantané de machine virtuelle. C’est une propriété considérable. Une clé logicielle vit dans la mémoire d’un processus, dans un fichier, dans les sauvegardes de ce fichier, dans les copies de ces sauvegardes, et dans la mémoire du stagiaire qui l’a collée un jour dans un ticket pour « tester un truc ».

La clé ne se clone pas en douce. Les sauvegardes et la réplication entre modules se font sous forme chiffrée, par enveloppement avec une clé que seuls les modules d’un même domaine de sécurité connaissent. On peut répliquer une clé vers un autre HSM ; on ne peut pas, en principe, la recopier sur une clé USB.

Le matériel résiste à l’ouverture. Selon le niveau de certification visé, l’enveloppe détecte les tentatives d’intrusion physique et efface les secrets en réponse. C’est la partie la plus spectaculaire, celle qu’on montre dans les salons, et dans la plupart des modèles de menace, la moins pertinente : on rencontre plus souvent un attaquant avec un accès distant à un serveur applicatif qu’un attaquant avec un fer à souder dans une salle blanche.

L’opération est attestable. Certains modules peuvent produire une attestation, signée par une clé du fabricant, prouvant qu’une clé donnée a été générée dans le module et n’en est jamais sortie. Pour une autorité de certification ou un service de signature, c’est une propriété précieuse, parce qu’elle transforme une affirmation (« la clé est protégée ») en preuve vérifiable.

Tout cela est vrai, et tout cela concerne une seule menace : l’extraction. Le HSM garantit que la clé reste unique, localisée, non copiable. Il ne garantit rien sur ce qu’on lui fait faire.

L’oracle

Supposons un serveur applicatif qui signe des documents, ou des jetons d’authentification, ou des paquets logiciels, avec une clé conservée dans un HSM. Supposons maintenant que ce serveur soit compromis : une vulnérabilité dans l’application, un identifiant d’administration volé, une dépendance piégée. L’attaquant a le contrôle de la machine.

Il ne peut pas lire la clé. Le HSM l’en empêche, et c’est très bien. Mais il dispose de tout ce que l’application légitime possède : la bibliothèque qui parle au module, la configuration qui indique où il se trouve, l’identifiant (le PIN, le certificat client, le jeton) qui ouvre une session. Il peut donc faire exactement ce que fait l’application : demander au module de signer. Et le module, qui ne connaît de l’application que son identifiant, signe.

En termes savants, le HSM est devenu un oracle : une boîte noire qui calcule, avec une clé que personne ne voit, le résultat de n’importe quelle entrée qu’on lui soumet. Pour l’attaquant, un oracle de signature vaut presque autant que la clé elle-même, pendant toute la durée où il y a accès. Il peut signer un logiciel piégé, émettre des jetons au nom de n’importe quel utilisateur, produire des documents faux et parfaitement authentiques. Il peut aussi, avec un oracle de déchiffrement, déchiffrer tout ce qui passe. Les signatures qu’il obtient sont indiscernables des signatures légitimes : elles sont faites par la même clé, dans le même module, par la même procédure. Elles sont même, si l’on tient à la précision, parfaitement légitimes du point de vue cryptographique, ce qui est le genre de légitimité qui console peu.

L’histoire récente de la sécurité offre au moins un cas célèbre de ce mécanisme, sans qu’aucun HSM n’ait besoin d’être mis en cause : lors de la compromission de la chaîne de production de SolarWinds, révélée fin 2020, du code malveillant a été inséré dans le processus de construction et distribué signé par le processus légitime de l’éditeur. La signature n’était pas volée. Elle était authentique. Elle attestait fidèlement que l’éditeur avait publié ce paquet, ce qui était exact, et ne disait rien de ce que contenait le paquet, ce qui n’était pas son rôle. Aucune protection de la clé, si parfaite soit-elle, ne pouvait intervenir : la clé avait fait exactement ce qu’on lui demandait.

Le HSM empêche que la clé soit volée. Il n’empêche pas que la clé soit empruntée. Et l’emprunt suffit.

Ce que l’on gagne quand même

Il faut être précis sur la différence, parce qu’elle existe et qu’elle compte. Un attaquant qui a volé une clé la possède pour toujours : il peut s’en servir depuis n’importe où, à n’importe quel moment, bien après avoir été chassé du réseau, et seule une révocation (dont on a vu, dans le premier éditorial, la fiabilité) peut en limiter l’effet. Un attaquant qui dispose d’un oracle ne l’utilise que tant qu’il est dans la place. Le jour où on l’en expulse, il n’a plus rien.

C’est un gain réel, et je ne le minimise pas. Le HSM transforme une compromission permanente en compromission temporaire. Mais il faut mesurer que tout ce qui a été signé pendant la compromission reste signé, pour toujours, et que la seule façon de savoir ce qui a été signé est de l’avoir noté. Ce qui nous amène à la question que les brochures évitent : qui a le droit de parler au guichet, et qui tient le registre ?

PKCS#11, ou la politesse du guichet

La plupart des applications parlent à un HSM à travers PKCS#11, l’interface de programmation standard décrite dans la page dédiée. Il vaut la peine de regarder comment elle conçoit le contrôle d’accès, parce que c’est là que la métaphore du coffre-fort commence à se fissurer sérieusement.

Le modèle est le suivant. Le module expose des emplacements (slots) contenant des jetons (tokens). Une application ouvre une session sur un jeton, puis s’authentifie, typiquement avec un PIN, soit comme utilisateur (qui peut se servir des clés), soit comme responsable de sécurité (qui administre le jeton, initialise le PIN utilisateur, mais n’a généralement pas accès aux clés elles-mêmes). Une fois authentifiée comme utilisateur, la session peut utiliser toutes les clés privées du jeton, pour toutes les opérations que leurs attributs autorisent.

Relisons cette dernière phrase avec l’œil du cambrioleur. Dans le modèle de base, l’authentification porte sur le jeton, pas sur la clé, ni sur l’opération, ni sur le contenu. Qui connaît le PIN du jeton peut tout signer avec toutes les clés du jeton. Et ce PIN, pour qu’une application fonctionne sans humain, est stocké quelque part sur le serveur applicatif : dans un fichier de configuration, une variable d’environnement, un gestionnaire de secrets dont l’identifiant d’accès est lui-même stocké sur le serveur. La clé est dans le coffre ; la combinaison est scotchée sous le bureau. Ce n’est pas une négligence, c’est une nécessité : une application qui doit signer à trois heures du matin ne peut pas attendre qu’un humain tape un code.

Les attributs des objets PKCS#11 ajoutent une granularité utile, sur ce qu’une clé peut faire : signer ou non, déchiffrer ou non, envelopper d’autres clés ou non, être extraite ou non. Bien posés, ils limitent les dégâts d’un oracle : une clé de signature qui ne peut pas déchiffrer ne sert pas d’oracle de déchiffrement. Mal posés, ils créent des trous d’une élégance remarquable. La littérature de recherche documente depuis le début des années 2000 des familles d’attaques où une clé autorisée à la fois à envelopper et à déchiffrer permet, par une séquence d’appels parfaitement légaux, d’extraire en clair des clés pourtant marquées sensibles. Le module, dans ce cas, ne s’est pas fait voler : il a obéi à une suite d’instructions cohérentes dont la somme était une trahison. Les fabricants ont ajouté des parades, et les bonnes configurations séparent strictement les usages. Mais la leçon demeure : un HSM applique une politique, il n’en invente pas.

Pour voir, en lecture seule, comment se présentent les objets d’un jeton, l’outil générique d’OpenSC suffit. L’exemple suivant utilise SoftHSM, un module logiciel de test, avec son chemin habituel sous Debian ; pour un vrai module, remplacez par la bibliothèque du fabricant :

# Liste les emplacements et jetons visibles (aucune authentification)
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --list-slots

# Liste les objets du jeton et leurs attributs d'accès et d'usage.
# --login demande le PIN de manière interactive : ne le passez pas
# en argument, il finirait dans l'historique du shell.
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --login --list-objects

Pour chaque clé privée, l’outil indique notamment les usages autorisés et des indicateurs d’accès. Ceux qu’on veut lire sur une clé qui ne doit jamais sortir sont « sensitive », « always sensitive » et « never extractable ». Une clé autorisée à la fois à envelopper et à déchiffrer mérite une question, et une clé marquée extractible, une explication.

Le contrôle d’accès, ou la frontière déplacée

On arrive ici à ce qui me semble être la thèse centrale de cet éditorial, et je la formule sans ménagement : un HSM ne supprime pas la frontière de sécurité autour de la clé, il la déplace vers l’identifiant qui permet de s’en servir. Avant, il fallait protéger la clé. Après, il faut protéger le PIN, le certificat client, le compte de service, la machine qui les détient, et tout ce qui peut prendre le contrôle de cette machine. Le périmètre réel de la clé n’est pas l’enveloppe métallique du module : c’est l’ensemble des serveurs, des comptes et des processus qui peuvent ouvrir une session.

Dans une architecture ordinaire, cet ensemble est plus grand qu’on ne le croit. Les modules en réseau sont souvent partagés entre plusieurs applications, avec des partitions séparées ; chaque serveur client détient ses identifiants de partition ; chaque compte d’administration de ces serveurs a donc, de fait, un accès à la clé. Les environnements de préproduction ont parfois accès à la même partition « pour simplifier ». Les équipes d’intégration disposent d’un identifiant de secours. Les outils de supervision ouvrent des sessions pour vérifier que le module répond. Chaque ligne de cette liste est défendable. Leur somme est un guichet où l’on entre sans faire la queue.

Les bonnes pratiques qui en découlent n’ont rien d’exotique, mais il est frappant de voir combien elles sont peu appliquées, précisément parce que la présence du HSM donne le sentiment que le problème est réglé.

Une partition par usage, une clé par finalité. Une clé de signature de code n’a rien à faire dans la même partition qu’une clé de signature de jetons, et aucune application ne devrait avoir accès à une clé dont elle n’a pas l’usage. C’est le principe de moindre privilège appliqué au guichet : chacun son ticket, chacun sa file.

Des identifiants qui ne vivent pas en clair. Quand le module le permet, l’authentification par certificat client, avec une clé elle-même protégée par un module local ou un composant de confiance du serveur, vaut mieux qu’un PIN dans un fichier. Cela ne supprime pas le problème de l’oracle (un attaquant maître du serveur peut toujours utiliser l’identifiant sans le voler), mais cela interdit de l’emporter.

Un intermédiaire qui sait ce qu’il signe. C’est le point décisif. Si l’application parle directement au module, le module signe tout ce que l’application lui tend. Si l’application parle à un service de signature qui, lui seul, parle au module, ce service peut appliquer une politique que le module ne sait pas exprimer : quels types de contenus, quels formats, quelles limites de fréquence, quelles approbations préalables. Un service de signature de code peut exiger que le condensat à signer corresponde à une construction enregistrée dans le système d’intégration, validée par une revue. Un service d’émission de jetons peut refuser d’en produire plus d’un certain nombre par minute. Le HSM protège la clé ; le service de signature protège l’intention. Sans le second, le premier n’est qu’un excellent serviteur au service de n’importe qui.

La journalisation, ou le seul témoin

Si l’oracle ne peut pas être entièrement empêché, il peut au moins être observé. La plupart des modules journalisent les opérations : ouverture de session, authentification, usage d’une clé, opérations d’administration. C’est, avec le quorum, la seule fonction du HSM qui touche à l’usage plutôt qu’à l’extraction, et elle est, comme toutes les fonctions de journalisation dans l’histoire de l’humanité, consciencieusement produite et rarement lue.

Il faut être lucide sur ce que ces journaux contiennent. Ils disent qu’une signature a eu lieu, avec quelle clé, à quelle heure, depuis quelle session. Ils ne disent presque jamais ce qui a été signé, parce que le module reçoit un condensat et ne sait pas de quel document il provient. Un journal de HSM qui montre trois cents signatures dans la nuit n’indique pas lesquelles étaient illégitimes. Il indique seulement qu’il y en a eu trois cents, ce qui est déjà une information, à condition de savoir combien il aurait dû y en avoir.

D’où deux principes qui me paraissent essentiels.

Le registre doit être tenu en amont. C’est le service de signature, pas le module, qui doit enregistrer ce qu’il a fait signer : le condensat, l’objet d’origine, le demandeur, l’approbation. Ce registre, rapproché du journal du module, permet de répondre à la seule question qui compte après une compromission : qu’est-ce qui a été signé qui n’aurait pas dû l’être ? Sans lui, la seule réponse honnête est « tout ce qui a été signé pendant la période est suspect », ce qui, pour une clé de signature de code ou une autorité de certification, peut signifier des mois de production à désavouer.

Le volume doit être comparé à l’attendu. Une clé de signature de code qui sert une fois par version publiée n’a aucune raison de signer à trois heures du matin. Une clé d’autorité qui émet quelques certificats par jour n’a aucune raison d’en émettre des centaines. Ces écarts se détectent avec une simplicité désarmante, à condition que quelqu’un ait écrit, quelque part, ce qui est normal. C’est la partie la moins technique du travail, et donc la plus souvent omise : on achète un appareil à plusieurs dizaines de milliers d’euros pour ne pas écrire une règle d’alerte de trois lignes.

Il faut enfin exporter ces journaux hors du module et hors de la portée de ceux qui l’administrent, vers un système où ils ne peuvent pas être effacés par la même personne qui pourrait abuser de la clé. Un témoin qui dépend de l’accusé n’a jamais fait un procès équitable.

Le quorum, ou l’autorisation à plusieurs

Reste la fonction qu’on présente volontiers comme la réponse à tout ce qui précède : le quorum, ou contrôle à plusieurs mains. Le principe consiste à exiger que plusieurs personnes, parmi un groupe désigné, s’authentifient ensemble (chacune avec sa carte, son code, son jeton) pour qu’une opération soit autorisée : typiquement un certain nombre parmi un ensemble plus large, pour qu’une absence n’arrête pas tout et qu’une trahison isolée ne suffise pas. La page sur l’architecture en haute disponibilité aborde son rôle dans la gestion des domaines de sécurité.

C’est un excellent mécanisme, et il faut regarder précisément où il s’applique. Dans la pratique, le quorum protège le plan d’administration : initialisation du module, création d’un domaine de sécurité, sauvegarde et restauration, modification des politiques, export d’une clé enveloppée vers un autre module. Ce sont des opérations rares, graves, qui justifient de réunir trois personnes dans une salle. Il protège aussi, dans certains cas, l’usage de clés exceptionnelles : la clé d’une autorité racine, qu’on n’utilise que quelques fois par an, lors de cérémonies scriptées, filmées, consignées, où chaque geste est lu à voix haute comme une liturgie.

Il ne protège presque jamais le plan d’usage courant. On ne réunit pas trois personnes chaque fois qu’un serveur doit signer un jeton d’authentification ; on ne demande pas une approbation collective pour chacune des milliers de signatures quotidiennes d’un service. Pour ces usages, le quorum a servi une fois, à l’initialisation, et le PIN de l’application a pris le relais.

Autrement dit, le quorum protège admirablement la clé contre ceux qui pourraient la déplacer, et pas du tout contre ceux qui peuvent s’en servir. Il répond encore à la question de l’extraction, sous une autre forme. Pour l’usage, il faut revenir à ce qui a été dit plus haut : un service de signature qui exige, pour les opérations rares et sensibles, une approbation humaine, éventuellement multiple, portant sur le contenu à signer et non sur l’ouverture d’une session. Le quorum qui compte n’est pas celui du module ; c’est celui qui valide l’intention, en amont.

Le meilleur argument contraire

J’ai été sévère avec le HSM, ou plutôt avec la façon dont on en parle. Voici l’argument le plus fort en sa faveur, et je le crois en grande partie juste.

Sans HSM, tout ce que j’ai décrit reste vrai, et il faut y ajouter le vol. L’attaquant qui compromet un serveur applicatif sans HSM dispose de l’oracle, lui aussi, et il repart en plus avec la clé. Le HSM ne crée pas la vulnérabilité de l’usage abusif : il la laisse telle qu’elle était, et supprime une vulnérabilité supplémentaire, beaucoup plus grave par sa durée. Lui reprocher de ne pas régler l’oracle, c’est reprocher à une porte blindée de ne pas empêcher le cambrioleur déjà entré par la fenêtre de se servir de la cuisine.

L’argument se renforce quand on se souvient du premier éditorial. Une clé volée ne se rattrape que par la révocation, et la révocation, sur le web public, protège mal contre l’attaquant actif. Une clé restée dans un HSM ne se rattrape pas du tout : elle n’a jamais été perdue. On coupe l’accès, on reconstruit le serveur, et la clé est de nouveau sûre. Pour une autorité de certification, la différence entre ces deux situations est la différence entre un incident et la fin de l’entreprise. L’affaire DigiNotar, en 2011, a montré ce que coûte une autorité dont on ne peut plus établir ce qui a été émis en son nom.

Il faut ajouter que le HSM protège remarquablement contre une menace que j’ai peu évoquée : l’initié qui copie. L’administrateur malveillant, le prestataire indélicat, l’employé sur le départ, qui pourraient emporter une clé logicielle sur une clé USB et s’en servir des années plus tard, ne peuvent rien emporter d’un module bien configuré. Contre eux, le coffre-fort est une métaphore exacte.

Je retiens tout cela. Ma critique ne porte pas sur l’objet, mais sur ce qu’on croit avoir acheté avec lui. Le HSM est une condition nécessaire de toute protection sérieuse d’une clé de grande valeur ; il n’en est pas une condition suffisante, et le danger commence le jour où on le traite comme tel. La phrase « la clé est dans le HSM » répond à la question « peut-on voler la clé ? ». Elle est systématiquement prononcée en réponse à une autre question : « la clé est-elle en sécurité ? ». Ce glissement est le sujet de cet éditorial.

Ce que je ne sais pas

Je ne sais pas quelle part des compromissions réelles de clés passe par l’extraction et quelle part par l’usage. Mon intuition, nourrie par la littérature publique sur les incidents de signature, est que l’usage domine largement dans les architectures où la clé est déjà protégée, mais je n’ai pas de chiffre fiable, et les organisations qui en ont ne les publient guère.

Je ne sais pas ce que valent les politiques d’usage embarquées dans les modules récents. Certains fabricants proposent des mécanismes d’autorisation par clé ou par opération, voire l’exécution de code de confiance à l’intérieur du module, qui permettraient de déplacer une partie de la politique du service de signature vers le module lui-même. Je n’ai pas évalué ces fonctions, elles varient beaucoup d’un modèle à l’autre, et je me garde d’en dire du bien ou du mal.

Je ne sais pas si les services cloud de gestion de clés changent la nature du problème. Ils exposent le module à travers une API authentifiée par les identités de la plateforme, avec des politiques d’accès fines et une journalisation centralisée. Cela ressemble beaucoup à ce que je recommande. Cela déplace aussi la frontière vers les identités cloud, dont la compromission est devenue un sport à part entière. Je ne sais pas si le bilan est meilleur ; je sais qu’il est différent.

Je ne sais pas comment on vérifie, de l’extérieur, qu’un HSM est bien configuré. La certification atteste des propriétés du produit, pas de l’usage qu’on en fait. Un module certifié avec une clé extractible, une partition partagée et un PIN dans un dépôt de code reste certifié. Je ne connais pas de méthode d’audit simple qui distingue un HSM qui protège d’un HSM qui décore.

Ce qui reste

Trois éditoriaux pour une conclusion qui aurait pu tenir sur un ticket de caisse : la sécurité d’une clé ne se résume jamais à l’endroit où elle est rangée. On ne sait pas la retirer à distance (la révocation), on a choisi de la faire mourir jeune (les certificats courts), et l’on a construit pour elle des coffres qui l’empêchent de partir mais pas de travailler (le HSM).

Trois choses me semblent acquises. Que le HSM protège contre l’extraction, et contre rien d’autre par lui-même : c’est beaucoup, c’est nécessaire, et ce n’est pas ce que la plupart des gens croient acheter. Que la frontière de sécurité se déplace vers l’identifiant qui ouvre la session, et qu’une architecture qui ne protège pas cet identifiant avec le même soin que la clé a simplement déménagé son problème. Et que seul un intermédiaire qui sait ce qu’il fait signer protège l’intention, avec un registre tenu en amont, des volumes attendus écrits quelque part, et une approbation humaine là où la gravité le justifie.

Il reste, pour finir, une observation d’ordre presque moral, et je la livre avec la prudence d’un homme qui a longtemps cru aux coffres-forts. Les objets de sécurité les plus coûteux ont une propriété commune : ils rassurent en proportion de leur prix. Un module à plusieurs dizaines de milliers d’euros, certifié, scellé, installé dans une baie fermée à clé, produit un sentiment de sécurité que ne produira jamais une règle d’alerte de trois lignes sur le nombre de signatures nocturnes. C’est pourtant souvent la règle de trois lignes qui aurait vu l’attaque. On n’achète pas la vigilance ; on achète ce qui permet de s’en croire dispensé.

🐝 Ce qui arrive si on s’en passe

Un module sans service de signature ni registre en amont aligne la protection de toutes ses clés sur celle du client le moins surveillé : l’outil de supervision qui ouvre une session, l’environnement de préproduction branché « pour simplifier ». Les signatures émises pendant une compromission restent valides, et aucun vérificateur en aval ne peut les rejeter puisqu’elles sont cryptographiquement irréprochables. Pire, le constat rassurant « la clé n’a pas quitté le module » pousse à ne rien révoquer ni remplacer, et les faux artefacts continuent de circuler sous une identité parfaitement authentique. Le coffre est intact ; c’est le contenu du courrier qui ne l’est plus.

🦫 Explication de la marmotte 🍫

Un module matériel de sécurité est un petit ordinateur spécialisé, enfermé dans un boîtier qui résiste à l’ouverture. Il fabrique des clés cryptographiques à l’intérieur, les garde dans sa mémoire protégée et effectue lui-même les calculs, comme signer ou déchiffrer. Une clé créée avec les bons réglages ne sort jamais en clair : ni l’application, ni l’administrateur du serveur, ni un pirate maître de la machine ne peuvent la copier. Les sauvegardes entre modules se font sous forme chiffrée.

Pour utiliser une clé, l’application ouvre une session avec le module, en général par une interface standard appelée PKCS#11, et s’authentifie avec un code ou un certificat. Ensuite, elle peut demander n’importe quelle opération autorisée sur les clés de cet espace. Ce code est stocké sur le serveur, puisque l’application doit fonctionner sans humain.

Si le serveur est piraté, l’attaquant ne vole pas la clé, mais il peut demander au module de signer ce qu’il veut, tant qu’il reste dans la place. Les signatures obtenues sont authentiques et impossibles à distinguer des bonnes. La protection réelle dépend donc de ce qui entoure le module : un espace séparé par usage, des identifiants bien protégés, un service intermédiaire qui vérifie ce qu’on lui fait signer et limite les volumes, un registre de ce qui a été signé, des journaux exportés hors de portée des administrateurs, et une approbation à plusieurs pour les opérations rares et graves.

Pages voisines

La citent

Le HSM n'est pas un coffre-fort

Elle cite

Le HSM n'est pas un coffre-fort

Le coffre-fort et le guichet

Ce que le HSM protège vraiment

L’oracle

Ce que l’on gagne quand même

PKCS#11, ou la politesse du guichet

Le contrôle d’accès, ou la frontière déplacée

La journalisation, ou le seul témoin

Le quorum, ou l’autorisation à plusieurs

Le meilleur argument contraire

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines