Résumé

  • RFC 9708 décrit l’emploi des clés et signatures HSS/LMS dans X.509, PKIX et CMS. Chaque clé privée LM-OTS ne doit signer qu’une fois ; le signataire doit donc conserver un état exact des feuilles consommées.
  • Une signature vérifiée ne démontre pas que cet état est resté unique. Échec d’écriture persistante, retour à un instantané de machine virtuelle ou clonage peuvent remettre en circulation une feuille déjà dépensée.
  • Le contrôle décisif est temporel : réserver puis enregistrer durablement l’état avant de libérer la signature, maintenir un seul écrivain autorisé et conserver les reçus permettant de rapprocher chaque sortie de sa consommation irréversible.

Le scénario ne commence pas par une attaque spectaculaire. Un service de signature fonctionne, une opération de maintenance tourne mal, puis l’équipe restaure l’instantané réputé sain. Les certificats sont les mêmes, la clé publique est la même et les nouvelles signatures passent la vérification. Pourtant, l’image restaurée a oublié des signatures qui ont déjà quitté la machine. Elle peut réutiliser les secrets à usage unique qui les ont produites.

C’est la frontière opérationnelle que rend visible RFC 9708. Publié sur la voie normative en janvier 2025, le texte modernise l’intégration du Hierarchical Signature System et du Leighton–Micali Signature scheme dans les certificats et le Cryptographic Message Syntax. Il remplace RFC 8708, corrige des ambiguïtés d’encodage signalées par les errata et ajoute des jeux de paramètres. Mais aucune amélioration de syntaxe ne supprime le caractère avec état de HSS/LMS.

RFC 8554 décrit la réalité sous-jacente. L’état de la clé privée contient notamment l’indice de la prochaine signature à usage unique. L’opération de signature rend un objet signé et un nouvel état privé. À l’épuisement de l’arbre, il n’existe plus d’état suivant. Réemployer deux fois le même état secret retire les garanties cryptographiques et peut rendre une falsification réalisable.

Le patrimoine à protéger est donc double : les secrets eux-mêmes et l’historique exact de ce qui a été dépensé.

L’objet vérifié ne raconte pas toute l’histoire

LM-OTS fournit une signature à usage unique. LMS place de nombreuses clés de ce type dans un arbre de Merkle ; HSS peut superposer plusieurs arbres. On obtient un budget de signatures pratique, mais fini. Une signature indique la feuille employée et un vérificateur peut établir sa cohérence mathématique avec la clé publique.

Ce même vérificateur ne voit pas nécessairement la seconde signature produite, ailleurs ou plus tard, avec la même feuille. La vérification porte sur l’objet présenté. L’unicité porte sur l’histoire globale de tous les exemplaires capables de signer. Les reçus suivants ne doivent pas être confondus :

Reçu Conclusion limitée
clé publique admise la politique accepte cette clé HSS/LMS
identifiant d’algorithme compris l’encodage et le jeu de paramètres sont reconnus
signature valide l’objet satisfait la procédure de vérification
indice de feuille lu la signature désigne une position précise
réservation consignée le signataire a affecté cette position
état suivant durable le stockage a avancé au-delà de la position
signature exportée les octets ont franchi la frontière du module
rapprochement global réussi aucune autre sortie ne revendique la même position
effet métier observé un système s’est appuyé sur le contenu signé

La validité de la signature n’absorbe pas les autres lignes. Elle ne prouve ni l’écriture sur support non volatil, ni l’absence d’un clone, ni l’exclusivité de l’écrivain. RFC 9708 exige le suivi des feuilles utilisées et nomme trois causes de perte d’intégrité : des écritures persistantes qui échouent, la prise d’un instantané de machine virtuelle et le clonage. La faiblesse se situe alors dans l’exploitation ordinaire, non dans la fonction de hachage.

Il faut dépenser l’état avant de livrer le résultat

L’ordre des événements est la règle de sécurité. Si le service calcule une signature, la renvoie, puis incrémente son compteur, une panne entre la réponse et l’écriture durable peut ramener le compteur en arrière. Même une écriture acquittée par le système d’exploitation peut demeurer dans un cache volatil. Après redémarrage, le service ne sait plus que le monde extérieur détient déjà la signature.

La publication NIST SP 800-208 insiste sur cette difficulté des signatures fondées sur le hachage avec état. Dans son profil, le module conforme doit incrémenter l’identifiant de feuille et persister l’incrément en mémoire non volatile avant d’exporter la signature ou d’accepter une nouvelle demande. Une séquence prudente est donc : réserver la prochaine feuille ; enregistrer irrévocablement sa consommation ; produire la signature sous cet état ; l’exporter avec un reçu ; puis rapprocher toute issue incertaine sans jamais remettre la feuille dans le stock libre.

Une panne après l’enregistrement mais avant l’exportation gaspille éventuellement une feuille. Ce gaspillage réduit la capacité ; il ne détruit pas la promesse d’unicité. Le choix inverse économise une feuille au prix d’une possible réutilisation. Dans ce système, un trou inexpliqué dans la suite est préférable à deux signatures publiques issues du même secret à usage unique.

Il faut ainsi résister aux automatismes du logiciel sans état. Réessayer une requête n’est pas forcément idempotent. Restaurer une sauvegarde ne signifie pas revenir à une situation sûre. Dupliquer une image ne signifie pas ajouter une capacité horizontale. Chaque opération doit respecter la flèche du temps propre au registre de signature.

La haute disponibilité peut dupliquer le pouvoir de signer

Deux répliques possédant le même état privé peuvent chacune émettre des signatures parfaitement valides et dépenser les mêmes indices. Un verrou dans une base partagée ne suffit pas si un nœud peut exporter avant que la transaction soit durable. Deux modules matériels ne suffisent pas si le même état secret a été copié dans les deux sans partition de l’espace de feuilles.

Des architectures sûres existent : un module souverain sérialise les consommations ; des signataires distincts reçoivent des sous-arbres disjoints ; un compteur matériel monotone révèle un retour arrière ; le basculement clôt l’ancien écrivain avant d’armer le nouveau. Mais le reçu doit correspondre à la propriété réelle. « Matériel » ne signifie pas automatiquement « état exclusif ». « Hautement disponible » ne signifie pas « écrivain unique ».

Le profil du NIST est plus restrictif que la syntaxe générale de l’IETF. Il impose des ensembles approuvés, l’exécution dans des modules cryptographiques matériels et la non-exportation du secret. Cette recommandation ne permet pas d’affirmer que toute mise en œuvre de RFC 9708 possède ces protections. Le statut d’un RFC documente une norme ; une fiche fournisseur documente au mieux une capacité annoncée ; seuls les reçus d’exécution prouvent le comportement d’un signataire pendant un incident donné.

Certificats et CMS transportent la clé, pas sa mémoire

RFC 9708 spécifie notamment l’identifiant d’objet, l’absence de paramètres dans AlgorithmIdentifier et le transport de la clé publique HSS/LMS sans enveloppe ASN.1 supplémentaire. Dans un certificat X.509, l’usage de clé doit rester compatible avec la signature, et non avec le chiffrement ou l’accord de clés. L’ensemble s’insère dans l’architecture de RFC 5280 et les modules ASN.1 de RFC 5912.

Pour CMS, défini par RFC 5652, la matière signée dépend de la présence d’attributs signés. Sans eux, le contenu est signé directement. Avec eux, le contenu est haché et l’encodage DER de SignedAttributes, comprenant le type de contenu et l’empreinte du message, devient l’entrée de la signature. Des domaines comme la livraison de micrologiciels décrite par RFC 4108 peuvent ainsi employer HSS/LMS dans des conteneurs existants.

Cette interopérabilité règle la représentation, non la continuité historique. Un certificat lie une clé publique à un sujet selon une politique d’émission ; il ne certifie pas qu’aucun ancien instantané ne contient l’état privé. Un vérificateur CMS voit les octets protégés ; il ne voit pas l’écriture disque perdue dans le signataire. L’extension du rayon d’usage augmente donc la valeur du registre sans le rendre plus visible.

La capacité finie doit entrer dans la gouvernance

L’arbre définit un nombre limité de signatures. L’organisation doit connaître le jeu de paramètres, le niveau hiérarchique, le débit prévu, la durée visée, la marge de réserve et le délai nécessaire au remplacement. Un pic de consommation peut signaler une attaque, une livraison légitime ou une panne de mesure ; dans tous les cas, le budget restant est une donnée de sécurité. Revenir à un indice ancien ne crée pas de capacité. Cela falsifie le registre.

Le registre LMS de l’IANA recense les codes de types normalisés. La notice RFC Editor, les versions texte et XML, l’historique IETF et la page des errata forment le dossier public de la norme. Aucun de ces documents ne donne le nombre de feuilles restant chez un exploitant ni ne prouve la qualité de ses restaurations.

Le principe du code en fonctionnement de Heng Lu ramène alors la preuve à la transition exécutable : l’état est-il rendu durable avant que la signature ne sorte ? La spécification initiale minimale fournit le socle d’interopérabilité, sans effacer les décisions locales sur le matériel, le cloisonnement et le basculement. La séparation des couches de réalité interdit enfin de prendre le statut normatif, la validité d’un objet et la sûreté d’un historique pour une seule et même preuve.

La force de HSS/LMS ne dispense donc pas de confiance opérationnelle ; elle la déplace. Le système réduit certaines dépendances à des hypothèses mathématiques vulnérables au calcul quantique, mais exige en échange une mémoire que l’infrastructure ne doit jamais rajeunir. La clé est à la fois un secret et une comptabilité du temps.

Sources