Intégrer un HSM à la signature CI/CD

Intégrer un HSM à la signature CI/CD

Un HSM (Hardware Security Module) dans une chaîne d’intégration continue et de livraison continue (CI/CD) permet de signer des artefacts sans exposer la clé privée au système de build. Le compromis est net : on gagne une frontière cryptographique vérifiable, on paie une dépendance réseau, opérationnelle et organisationnelle qui ne tolère pas les bricolages de runner éphémère.

Explication de la marmotte

Signer automatiquement un logiciel ressemble à apposer un sceau officiel sur chaque colis qui sort d’un atelier. Le sceau permet aux destinataires de vérifier que le colis vient bien de l’atelier attendu et qu’il n’a pas été remplacé pendant le transport, même si beaucoup de mains ont touché les cartons.

→ Lire l’explication complète de la marmotte

Décision d’architecture HSM et CI/CD

La clé de signature de production doit rester générée, stockée et utilisée dans le HSM. Exporter une clé pour la remettre dans un gestionnaire de secrets annule la propriété recherchée : le pipeline ne parle plus à un module matériel, il détient une copie de la clé. Ce modèle transforme un vol de secret de CI/CD en capacité de signer des versions malveillantes. Très pratique pour l’attaquant, moins pour la chaîne de confiance.

Le pipeline obtient un droit d’usage limité, pas la possession de la clé. Avec PKCS#11 (Public-Key Cryptography Standards #11), le runner charge une bibliothèque cliente, ouvre une session authentifiée et demande une opération de signature. La clé privée ne quitte pas le HSM. La présentation du modèle HSM détaille cette séparation entre clé, application et mécanisme matériel.

Deux architectures sont recevables :

1. Runner connecté directement au HSM : approprié si les runners sont dédiés, placés sur un réseau d’administration et si chaque exécuteur possède une identité stable. C’est le modèle le plus direct, mais il impose de protéger très sérieusement le réseau et les identités de machine.
2. Service de signature intermédiaire : recommandé pour des runners mutualisés ou éphémères. Le pipeline transmet le condensat cryptographique, l’identité du job et des métadonnées contrôlées à un service qui applique les règles d’autorisation avant d’appeler le HSM.

Le second modèle coûte un composant supplémentaire, donc une autre chose à superviser à trois heures du matin. Il permet néanmoins de découpler la sécurité du HSM de l’élasticité des runners. Pour une plateforme partagée, c’est le choix à retenir. Un runner mutualisé qui ouvre une session PKCS#11 avec un code secret commun est un coffre-fort dont la combinaison est collée sur la porte, avec une police un peu plus petite.

La signature doit intervenir après la compilation, les tests, la génération des métadonnées et le calcul du condensat final. Signer avant une étape de packaging, de compression ou d’injection de manifeste signe un objet qui ne sera jamais distribué. L’artefact signé doit être immuable : même octet, même nom de version, même condensat. La reproductibilité de build ne remplace pas la signature, mais elle permet de détecter qu’un binaire signé ne correspond pas aux sources attendues.

Prérequis PKCS#11, identité de workload et réseau

Le HSM doit fournir une interface PKCS#11 compatible avec l’outil de signature retenu et avec son mécanisme cryptographique. Vérifier précisément les mécanismes exposés avec C_GetMechanismList et C_GetMechanismInfo. Un support RSA (Rivest, Shamir, Adleman) ne garantit pas le support de CKM_SHA256_RSA_PKCS, et un support ECDSA (Elliptic Curve Digital Signature Algorithm) ne garantit pas que le hachage soit effectué dans le module. Les brochures commerciales ont une relation créative avec les tableaux de compatibilité.

Pour des artefacts généralistes, choisir RSA avec PSS (Probabilistic Signature Scheme) et SHA-256 (Secure Hash Algorithm 256 bits), ou ECDSA avec P-256 et SHA-256 lorsque les outils de vérification le supportent sans ambiguïté. Fixer les paramètres PSS, notamment la fonction de hachage et la longueur de sel. Laisser l’outil négocier ces paramètres produit des signatures parfois valides, parfois invérifiables, toujours pénibles à diagnostiquer.

Chaque pipeline doit disposer d’une identité de workload distincte. Une identité de projet, d’environnement et de niveau de promotion est le minimum. Le job de préproduction ne doit pas pouvoir utiliser la clé de production, même si le même dépôt produit les deux artefacts. L’autorisation doit vérifier au moins :

• l’identité cryptographique du runner ou du service de signature ;
• le dépôt et la branche ou le tag autorisés ;
• l’état de validation du pipeline ;
• le type d’artefact et son registre de destination ;
• la clé de signature explicitement autorisée.

L’authentification réseau doit reposer sur TLS (Transport Layer Security) avec authentification mutuelle lorsque le HSM est distant. Un certificat client sans contrôle d’autorisation applicative ne suffit pas : il prouve quelle machine parle, pas si cette machine a le droit de signer une version distribuable.

Prévoir une synchronisation horaire fiable. Les certificats de signature, jetons d’horodatage et journaux d’audit dépendent du temps. Une dérive d’horloge ne rend pas la cryptographie fausse, elle rend les preuves chronologiques discutables. Ce qui est parfois presque aussi divertissant qu’un audit sans journal.

Flux de signature d’artefact et séparation des rôles

Le flux recommandé ne transmet au HSM que le strict nécessaire. Le runner construit l’artefact, calcule son condensat avec l’algorithme imposé, puis demande la signature. Le HSM retourne la signature et le pipeline publie ensemble l’artefact, la signature, le certificat public et les métadonnées de provenance.

Ne jamais laisser le pipeline choisir librement le libellé PKCS#11 de la clé. Le libellé est une donnée de sélection, pas un contrôle d’accès. Une configuration contenant key=production devient un escalier vers la mauvaise clé dès qu’un job peut modifier la configuration de build. La sélection de clé doit être imposée par une politique côté service de signature ou par un compte HSM strictement cloisonné.

Le code PIN (Personal Identification Number) d’un objet PKCS#11 ne doit pas figurer dans les variables persistantes du projet. Préférer un secret à durée courte délivré au job après vérification de son identité, ou une authentification par certificat de client lorsque le fournisseur le permet. Un code PIN partagé entre tous les runners interdit l’attribution fiable d’une signature à un workload donné.

La signature prouve l’usage de la clé, pas la qualité du code signé. Elle ne garantit ni l’absence de dépendance compromise, ni l’exécution des tests, ni l’approbation humaine, ni l’intégrité du serveur CI/CD avant la signature. Ces garanties doivent venir de l’isolation des runners, des règles de fusion, de l’attestation de provenance et du contrôle du registre d’artefacts. La signature de code est un scellement, pas un exorcisme.

Exemple PKCS#11 avec un artefact de build

L’exemple suivant utilise pkcs11-tool du paquet OpenSC pour demander au HSM une signature RSA avec hachage SHA-256. Il suppose qu’une clé privée non extractible et son certificat existent déjà dans le jeton, sous l’identifiant hexadécimal 01.

# La bibliothèque PKCS#11 est fournie par le constructeur du HSM.
export PKCS11_MODULE=/opt/hsm/lib/libvendorpkcs11.so

# Le PIN arrive d'un mécanisme de secret à durée courte.
# Ne jamais l'écrire dans un fichier de configuration ou dans les logs.
export HSM_USER_PIN="$CI_HSM_USER_PIN"

# Signer l'artefact final, après packaging et avant publication.
pkcs11-tool \
  --module "$PKCS11_MODULE" \
  --login \
  --pin "$HSM_USER_PIN" \
  --sign \
  --mechanism SHA256-RSA-PKCS \
  --id 01 \
  --input-file dist/application-2.4.0.tar.gz \
  --output-file dist/application-2.4.0.tar.gz.sig

# Exporter seulement le certificat public nécessaire à la vérification.
pkcs11-tool \
  --module "$PKCS11_MODULE" \
  --read-object \
  --type cert \
  --id 01 \
  --output-file dist/signing-cert.pem

Avant d’intégrer cette commande, vérifier que le mécanisme SHA256-RSA-PKCS est bien supporté par le HSM et que l’outil ne transforme pas l’entrée. Certains outils attendent un condensat déjà calculé, d’autres calculent eux-mêmes le condensat. Mélanger les deux produit une double empreinte, une signature valide sur une donnée inattendue et une après-midi de diagnostic assez classique.

Conserver le certificat et l’empreinte de l’artefact dans le registre de livraison. La vérification doit être exécutée hors du pipeline de construction, idéalement au moment du déploiement. Vérifier une signature dans le même environnement compromis qui l’a produite reste mieux que rien, ce qui est une catégorie de sécurité peu enthousiasmante.

Surface d’attaque du service de signature

Le premier risque est l’abus de signature par un job légitime mais non autorisé. Une branche de fonctionnalité, une requête de fusion ou un fork ne doit jamais obtenir le même droit qu’un tag de livraison. Les règles doivent être évaluées côté système de signature, pas seulement dans le fichier de pipeline modifiable avec le code.

Le second risque est le rejeu. Si le service signe un condensat arbitraire sans lier la demande à un identifiant de build, un attaquant peut rejouer une requête capturée ou soumettre un artefact externe. Inclure dans la demande un identifiant unique, l’empreinte de l’artefact, le dépôt, la révision source et une expiration courte. Journaliser le tout dans un stockage append-only, c’est-à-dire qui n’autorise pas la modification des entrées existantes.

Le troisième risque est l’indisponibilité du HSM. Un cluster CI/CD ne doit pas contourner une panne de signature en publiant un artefact non signé. Échouer fermé est la bonne décision. Pour la disponibilité, prévoir au moins deux nœuds HSM ou deux partitions répliquées selon les capacités du fournisseur, avec une procédure testée de bascule. La haute disponibilité d’un module matériel impose de vérifier la réplication des objets, des politiques et des journaux, pas seulement l’ouverture du port réseau.

Enfin, surveiller les échecs d’authentification, les signatures refusées, les changements de politique, les créations d’objets et les opérations d’administration. Une hausse de signatures n’est pas automatiquement une attaque, mais une clé de production qui signe soudain des artefacts de développement mérite mieux qu’un graphique bleu dans un tableau de bord.

Rotation, sauvegarde et reprise des clés de signature

La rotation doit créer une nouvelle clé dans le HSM, associer un nouveau certificat, publier la chaîne de confiance et conserver l’ancienne clé en vérification pendant la période définie. Détruire immédiatement l’ancienne clé empêche de valider les versions historiques. La conserver indéfiniment transforme une rotation en décoration rituelle.

La politique de rotation dépend de l’exposition, de la durée de validité des artefacts et des exigences de conformité. La rotation des clés HSM doit distinguer rotation planifiée, compromission présumée et remplacement de certificat. En cas de compromission, désactiver immédiatement la capacité de signature, révoquer le certificat lorsque l’écosystème le permet, identifier les artefacts signés depuis le dernier point fiable et publier une nouvelle confiance.

Les sauvegardes du HSM ne sont pas des exports de clés en clair. Elles reposent sur des mécanismes de réplication fournisseur, de cartes d’administration ou de clés de transport protégées. Tester la restauration sur une partition distincte et vérifier la capacité réelle à signer avec les objets restaurés. Une sauvegarde qui contient des objets mais pas les droits, les certificats ou les paramètres de mécanisme est un inventaire, pas une reprise.

🐝 Ce qui arrive si on s’en passe

Sans HSM dans la chaîne de signature, la clé privée qui atteste l’origine des artefacts est exposée au système de build lui-même. Elle traverse alors des runners éphémères, des variables d’environnement et des journaux, autant d’endroits où elle peut être exfiltrée par un build compromis ou une dépendance malveillante. La conséquence est qu’un attaquant ayant volé cette clé signe des artefacts frauduleux indistinguables des légitimes : le sceau qui devait prouver la provenance garantit alors un contenu falsifié, et chaque destinataire qui vérifie la signature est trompé. Sans cette frontière cryptographique où la clé signe sans jamais être lisible par le pipeline, la confiance dans toute la distribution repose sur l’endroit le plus exposé de la chaîne. Une clé de signature qui fuit ne se contente pas d’un incident local, elle contamine tout ce qui sera signé avec, jusqu’à sa révocation et sa réémission.

🦫 Explication de la marmotte 🍫

Un logiciel est construit automatiquement à partir de son code. À la fin de cette construction, le système obtient un fichier à distribuer, par exemple une archive ou une image de conteneur. Avant de publier ce fichier, il calcule une empreinte mathématique qui change si un seul octet du fichier change.

Le système demande ensuite à un appareil matériel spécialisé de signer cette empreinte. La clé privée utilisée pour signer est créée et conservée dans cet appareil. Le serveur de construction ne reçoit jamais cette clé. Il reçoit seulement la signature produite et le certificat public qui permet de la vérifier.

Avant d’accepter une demande, l’appareil ou un service placé devant lui vérifie l’identité du travail automatique, le projet concerné, la version demandée et les règles d’autorisation. Un travail provenant d’une branche de test ne doit pas pouvoir signer une version destinée à la diffusion.

La signature, le certificat et le fichier sont publiés ensemble. Plus tard, un système de déploiement recalcule l’empreinte du fichier et vérifie la signature avec la partie publique du certificat. Si le fichier a changé, si la mauvaise clé a été utilisée ou si la signature manque, le déploiement doit échouer.

La clé doit aussi être remplacée périodiquement, les anciennes signatures doivent rester vérifiables, et les événements doivent être enregistrés. Si l’appareil de signature est indisponible, la publication doit s’arrêter plutôt que contourner le contrôle.

À lire aussi

• Dimensionner un cluster HSM à forte charge transactionnelleMéthode de capacité, tests de charge et exploitation d’un cluster HSM pour le paiement et la signature de masse.
• Comment isoler les clés dans un HSM multi-tenantGestion multi-tenant d'un HSM partagé, isolation logique des clés par partition et règles d'exploitation entre applications ou équipes internes.
• Migrer un fournisseur HSM sans interruptionMéthode de migration progressive d'un système cryptographique vers un nouveau fournisseur HSM sans interrompre les services.
• Attestation matérielle HSM des clés généréesVérifier par preuve cryptographique qu’une clé a été créée et reste protégée dans un HSM certifié.

Pages voisines

La citent

• Installer SoftHSM v2 sur Debian/Ubuntu pour un laboratoire PKCS#11

Intégrer un HSM à la signature CI/CD

Elle cite

• ⇄Lien dans les deux sens :Signer et vérifier les artefacts de build
• Architecture module cryptographique materiel haute disponibilite
• Protéger des données avec un HSM (hardware security module)
• Rotation des cles
• OIDC pour sécuriser les identifiants CI/CD
• SLSA : niveaux Build, provenance in-toto et vérification

⇄ : les deux pages se citent l’une l’autre.