Signer numériquement : preuve publique, politiques de vérification

Une signature numérique lie une clé privée à un contenu précis et permet à tout détenteur de la clé publique correspondante de vérifier ce lien. Elle sert à distribuer du logiciel, valider une provenance, émettre des certificats ou autoriser une transaction. Son compromis central est simple : la vérification publique facilite la distribution de la confiance, mais impose une discipline brutale sur les clés, les formats et les règles de vérification.

→ Lire l’explication complète de la marmotte

Ce qu’une signature établit, et ce qu’elle ne remplace pas

Une signature établit l’intégrité du contenu signé et la possession de la clé privée au moment de la création. Si la clé publique est correctement reliée à une identité, elle permet aussi d’authentifier l’émetteur déclaré. C’est une vérification publique, contrairement à un code d’authentification de message, ou MAC (Message Authentication Code), qui repose sur un secret partagé : tout vérificateur d’un MAC peut aussi en produire un.

Cette propriété rend la signature adaptée à la supply chain. Une plateforme de livraison continue peut publier un artefact, sa provenance et une signature. Un poste de déploiement vérifie alors l’ensemble sans recevoir la clé de signature. Pour autant, signer un binaire ne prouve ni qu’il est sans vulnérabilité, ni que sa compilation était propre, ni que son auteur avait le droit métier de le publier. La signature est une preuve cryptographique, pas une procédure de gouvernance.

La « non-répudiation » mérite le même traitement sans romantisme. Une signature peut démontrer qu’une clé a signé un message. Elle ne démontre pas, seule, quelle personne contrôlait cette clé, si son usage était autorisé, ni si elle a été compromise avant la signature. Une preuve opposable exige des éléments externes : enrôlement d’identité, politique de conservation, journalisation protégée, horodatage fiable et procédure de révocation. Le droit ne se déduit pas d’une courbe elliptique.

Le rattachement entre clé et identité doit être explicite. Un certificat de l’infrastructure à clés publiques, ou PKI (Public Key Infrastructure), est un moyen courant, mais il faut vérifier sa chaîne, ses contraintes d’usage et sa période de validité. Une clé publiée dans un dépôt de code peut être suffisante pour un projet interne si son empreinte est distribuée par un canal déjà authentifié. Sans ancrage de confiance, une signature vérifie seulement que « quelqu’un possédait cette clé inconnue ».

Pour le rattachement d’une clé publique à une identité, voir relier une clé à une identité.

Choisir un schéma sans collectionner les algorithmes

Pour les nouveaux systèmes généraux, Ed25519, variante d’EdDSA (Edwards-curve Digital Signature Algorithm), constitue le choix par défaut lorsque l’écosystème l’accepte. Les clés et signatures sont compactes, la génération de nonce est déterministe et les bibliothèques sérieuses réduisent plusieurs erreurs d’intégration. Cette recommandation vaut à condition d’utiliser une implémentation maintenue, qui rejette les encodages non canoniques et les petites sous-structures.

ECDSA (Elliptic Curve Digital Signature Algorithm) reste incontournable dans des écosystèmes matériels, des certificats et des protocoles existants. Son point faible opérationnel est le nonce : réutiliser le même nonce avec la même clé révèle la clé privée. Un générateur aléatoire défaillant suffit donc à transformer une signature valide en fuite irrécupérable. ECDSA déterministe selon RFC 6979 limite ce risque, mais ne corrige ni une implémentation boguée ni une clé extraite.

RSA-PSS (Rivest, Shamir, Adleman, Probabilistic Signature Scheme) reste pertinent pour les environnements qui exigent RSA, notamment certains modules matériels ou profils réglementaires. Il faut utiliser PSS, pas le vieux PKCS#1 v1.5 pour les nouveaux usages, fixer la fonction de hachage et la longueur du sel dans le profil, puis les imposer à la vérification. Laisser la bibliothèque choisir selon le contenu reçu fabrique un analyseur de rétrocompatibilité, pas une politique de sécurité.

DSA (Digital Signature Algorithm), les variantes historiques d’ElGamal, ESIGN, Ong-Schnorr-Shamir ou les signatures fondées sur des automates cellulaires n’ont pas leur place dans une nouvelle architecture. Les connaître peut aider à auditer un héritage ou lire un article, pas à concevoir un protocole. Un algorithme rare n’est pas original, il est surtout moins audité et plus difficile à intégrer.

Les signatures Schnorr apportent une construction simple et permettent des multisignatures efficaces dans des protocoles conçus pour elles. BLS (Boneh-Lynn-Shacham) permet l’agrégation de nombreuses signatures en une seule, grâce à des couplages bilinéaires. Le gain de taille est réel, mais le coût est une surface d’attaque et de dépendances plus large : validation des clés publiques, preuves de possession et bibliothèques spécialisées deviennent obligatoires. Sans preuve de possession, l’attaque de clé parasite permet à un participant de fabriquer une clé qui détourne l’agrégation.

La migration post-quantique mérite une trajectoire, pas une activation décorative. ML-DSA, standardisé par le National Institute of Standards and Technology, est destiné à remplacer progressivement les signatures vulnérables à un ordinateur quantique cryptographiquement pertinent. Ses signatures sont nettement plus volumineuses. Pour les données devant rester vérifiables longtemps, prévoir dès maintenant une enveloppe versionnée pouvant porter deux signatures, classique et post-quantique. Pour un jeton éphémère, cette complexité n’apporte souvent rien.

Signer des octets, jamais une intention vague

Une signature porte sur une suite d’octets. Elle ne signe pas « le JSON », « le manifeste » ou « l’image conteneur » au sens métier. Deux représentations visuellement identiques peuvent avoir des octets différents : ordre des champs, espaces, Unicode, précision numérique, fins de ligne ou encodage des dates. Le vérificateur doit reconstruire exactement la même représentation, ce qui est une source classique d’échecs et parfois de contournements.

La stratégie la plus robuste consiste à signer un format canonique défini par un profil versionné, ou à signer le condensé cryptographique d’un artefact immuable. Pour un document structuré, inclure au minimum le type de message, la version du format, l’algorithme accepté, l’identité attendue et le contexte d’usage. Cette séparation de domaine empêche qu’une signature créée pour autoriser un déploiement soit réinterprétée comme une validation financière.

# Calculer le condensé SHA-256 de l'artefact immuable.
sha256sum application-4.2.1.tar.gz > application-4.2.1.tar.gz.sha256

# Signer le fichier de condensé avec RSA-PSS et SHA-256.
openssl dgst -sha256 \
  -sigopt rsa_padding_mode:pss \
  -sigopt rsa_pss_saltlen:digest \
  -sign release-private.pem \
  -out application-4.2.1.tar.gz.sha256.sig \
  application-4.2.1.tar.gz.sha256

# Vérifier en imposant le même profil, puis comparer le condensé à l'artefact.
openssl dgst -sha256 \
  -sigopt rsa_padding_mode:pss \
  -sigopt rsa_pss_saltlen:digest \
  -verify release-public.pem \
  -signature application-4.2.1.tar.gz.sha256.sig \
  application-4.2.1.tar.gz.sha256

La commande ne suffit pas à sécuriser une chaîne de livraison. Le vérificateur doit vérifier le nom attendu de l’artefact, son canal de publication, la clé autorisée pour ce produit et la période de validité. Accepter toute clé d’un trousseau, toute autorité de certification ou tout algorithme annoncé par le fichier signé revient à laisser l’attaquant écrire la politique de vérification.

Un horodatage renforce la démonstration qu’une signature existait avant une date donnée, mais ne prolonge pas magiquement la validité d’une clé compromise. Lorsque la conservation est longue, archiver l’artefact, sa signature, la chaîne de certificats, les politiques applicables et des preuves d’horodatage renouvelées. La révocation d’un certificat ne se propage pas aux fichiers déjà téléchargés ni aux décisions déjà prises.

Exploiter la clé de signature comme un actif critique

La clé privée de signature doit être séparée des clés de chiffrement et des secrets applicatifs. Une clé qui signe une release ne doit jamais être accessible au processus qui exécute la release. Le bon modèle est un service de signature dédié, protégé par un module de sécurité matériel, ou HSM (Hardware Security Module), lorsque la criticité justifie le coût et la disponibilité à assurer.

Un HSM ne corrige pas une autorisation trop large. Si un jeton d’intégration continue peut demander la signature de n’importe quel contenu, il devient une machine à publier des artefacts malveillants, avec une belle clé non exportable. Il faut limiter chaque identité de charge de travail à un périmètre : dépôt, branche protégée, type d’artefact, environnement et durée de vie. Les demandes de signature doivent être journalisées avec le condensé, l’identité appelante, le profil utilisé et la décision d’autorisation.

La rotation doit être conçue avant le premier déploiement. Publier la nouvelle clé publique, accepter temporairement l’ancienne et la nouvelle selon une fenêtre bornée, puis retirer l’ancienne des politiques de vérification. Les artefacts historiques exigent une stratégie distincte : conserver leur clé publique et leurs preuves, sans maintenir la capacité de signer avec une clé retirée. Une sauvegarde de clé privée non chiffrée dans un coffre de fichiers n’est pas une reprise, c’est une copie supplémentaire à compromettre.

La supervision doit distinguer les pannes de signature, les refus attendus et les anomalies. Une hausse de signatures, une demande hors plage horaire ou un changement de profil cryptographique méritent une alerte. Tester aussi la reprise : restauration de configuration, indisponibilité du HSM, perte d’un nœud de signature, révocation urgente et vérification hors ligne. La disponibilité compte, mais une solution de secours qui exporte la clé privée annule proprement le modèle de protection.

Pour cadrer inventaire, cycles de vie et responsabilités, gouverner la cryptographie et son inventaire complète utilement cette discipline.

Signatures spécialisées : choisir la propriété manquante

Une multisignature produit plusieurs signatures indépendantes sur le même contenu. Le vérificateur voit quelles clés ont approuvé et applique une règle, par exemple deux signatures parmi trois. Une signature à seuil distribue au contraire la production d’une signature unique entre plusieurs détenteurs de fragments de clé. Elle réduit l’exposition d’une clé complète, mais masque souvent quels participants ont réellement coopéré. Le choix dépend donc de la propriété recherchée : audit des approbateurs ou protection contre le vol d’une clé unique.

Les signatures aveugles permettent de signer un contenu sans que le signataire le lise. Elles sont utiles pour certains jetons anonymes, mais ne fournissent pas l’anonymat complet : adresse réseau, moment d’émission, réutilisation d’un jeton et métadonnées peuvent relier les événements. Les signatures à vérificateur désigné et les signatures incontestables réduisent la vérifiabilité publique volontairement. Elles conviennent à des protocoles précis, pas à la distribution de logiciel où la vérification par tous est précisément l’objectif.

Les signatures par procuration délèguent un pouvoir de signature. Elles doivent encoder le périmètre, l’expiration et l’identité du délégant dans les données vérifiables. Une simple remise de clé privée n’est pas une délégation, c’est un abandon de contrôle. Les signatures collectives, agrégées ou à seuil demandent aussi une défense contre les participants malveillants, les clés non validées et l’abandon d’un participant pendant le protocole.

FAQ

Faut-il signer le fichier ou son condensé cryptographique ?

Signer le condensé est généralement préférable pour les gros artefacts et facilite les vérifications distribuées. Le fichier contenant le condensé doit toutefois identifier sans ambiguïté l’artefact, son algorithme de hachage et son encodage. Un condensé isolé, sans contexte, peut être recollé à un autre usage.

Une signature chiffre-t-elle le contenu ?

Non. La signature rend une modification détectable et lie le contenu à une clé, mais elle laisse le contenu lisible. La confidentialité exige un chiffrement séparé, avec ses propres clés, destinataires et règles de rotation.

Peut-on accepter un ancien algorithme « pour compatibilité » ?

Seulement derrière une politique explicite, limitée et mesurée. Le vérificateur doit savoir quel ancien format est accepté, pour quels artefacts, jusqu’à quelle date et avec quelle clé. Une compatibilité sans date de fin devient rapidement le chemin préféré des attaquants.

🐝 Ce qui arrive si on s’en passe

Sans preuve signée attachée à l’artefact, la confiance se reporte sur le canal de transport : un miroir, un cache ou un proxy devient un point d’autorité, et une copie modifiée reste indiscernable d’une copie d’origine dès qu’elle quitte le lien chiffré. La vérification hors ligne disparaît, donc un poste isolé ne dispose d’aucun moyen local de décider. En incident, plus rien ne relie un binaire retrouvé à une publication précise : le périmètre d’un rappel de version ne se démontre pas, seulement se déclare. Les journaux perdent l’ancre commune qu’est le condensé signé, ce qui empêche de dater l’apparition d’une variante. Une vérification permissive laisse aussi parler l’implémentation, comme le montre la question qui rend le module bavard.

🦫 Explication de la marmotte 🍫

Pour signer un fichier, un logiciel utilise une information secrète appelée clé privée. Il transforme d’abord le contenu en une empreinte courte, calculée de façon à changer fortement si un seul caractère du contenu change. Il utilise ensuite la clé privée pour produire une signature liée à cette empreinte.

La clé publique associée peut être distribuée largement. Lorsqu’un système reçoit le fichier et la signature, il recalcule l’empreinte du fichier puis utilise la clé publique pour contrôler que la signature correspond. Si le fichier a été modifié, si la signature vient d’une autre clé ou si son format est invalide, le contrôle doit échouer.

Le contrôle ne suffit que si la clé publique est reconnue. Il faut donc savoir quelle clé est autorisée pour quel logiciel, pendant quelle période et pour quel type de document. Une clé publique inconnue peut vérifier une signature valide sans rendre son auteur digne de confiance.

La clé privée doit rester protégée, car toute personne qui l’obtient peut créer de fausses signatures. Elle doit être remplacée périodiquement, surveillée et retirée rapidement en cas de suspicion. Si le service qui signe tombe en panne, il faut pouvoir continuer ou restaurer son fonctionnement sans copier la clé secrète dans des endroits moins protégés.

Pages voisines

La citent

Signer numériquement : preuve publique, politiques de vérification

Elle cite

Signer numériquement : preuve publique, politiques de vérification

Signer numériquement : preuve publique, politiques de vérification

Ce qu’une signature établit, et ce qu’elle ne remplace pas

Choisir un schéma sans collectionner les algorithmes

Signer des octets, jamais une intention vague

Exploiter la clé de signature comme un actif critique

Signatures spécialisées : choisir la propriété manquante

FAQ

Faut-il signer le fichier ou son condensé cryptographique ?

Une signature chiffre-t-elle le contenu ?

Peut-on accepter un ancien algorithme « pour compatibilité » ?

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines