Résumé

  • Une clé HBS avec état associe un secret durable à un registre évolutif des indices de signature à usage unique déjà consommés. L’intégrité d’une sauvegarde ne garantit donc pas que son état soit encore exclusif.
  • La remise d’une signature et l’avancement durable de l’état doivent constituer un seul acte. Les secteurs, intervalles réservés et fenêtres temporelles réduisent le domaine d’un incident, à condition qu’aucune attribution ne se chevauche après la reprise.
  • Un module matériel qui passe son autotest et produit une signature valide prouve sa capacité à signer, non son droit exclusif sur des indices encore vierges. La reprise doit laisser un reçu de garde vérifiable.

Le scénario le plus trompeur est aussi le plus propre. La sauvegarde est correctement chiffrée, son empreinte correspond, le module matériel accepte l’importation et la signature d’essai est valide. Dans la plupart des systèmes, cette suite de contrôles clôturerait l’incident. Avec une signature à base de hachage avec état, elle ne répond pas à la question essentielle : l’indice utilisé est-il réellement inédit ?

Le RFC 10033, document informatif publié dans le flux IETF, traite précisément de ce risque opérationnel. Les schémas XMSS et LMS utilisent des clés de signature à usage unique au sein d’une structure plus vaste. Si le même secret OTS sert à signer deux messages différents, l’information révélée peut rendre une falsification réalisable. La sécurité dépend donc autant du secret cryptographique que d’une propriété administrative : chaque position ne doit être utilisée qu’une fois.

La sauvegarde authentique mais périmée

Supposons qu’une sauvegarde soit prise lorsque le prochain indice disponible vaut 12 000. Le système vivant signe ensuite 800 messages et enregistre l’indice 12 800. Après une panne, l’équipe restaure la copie ancienne. Les octets sont authentiques et les signatures produites se vérifient, mais la machine croit de nouveau disposer des positions 12 000 à 12 799. Le monde extérieur, lui, les a déjà vues.

Ce n’est pas une falsification de la sauvegarde. C’est une divergence entre deux réalités : l’état conservé par l’opérateur et les signatures définitivement sorties du système. RFC 9802 souligne que les pratiques ordinaires de duplication et de restauration des clés privées peuvent provoquer cette réutilisation si l’état n’est pas coordonné.

Le profil approuvé par le NIST SP 800-208 réduit le problème en imposant que la génération des clés et des signatures s’effectue dans des modules cryptographiques matériels, sans exportation de la clé privée. RFC 10033 présente aussi des procédés applicables au-delà de ce profil. Ces deux cadres ne sont pas interchangeables : une méthode d’exportation décrite à titre opérationnel ne rend pas l’exportation compatible avec les exigences du NIST.

Secret statique, état mouvant

Le matériau secret permet de dériver les clés. L’état mouvant affirme quelles dérivations restent disponibles. Une empreinte protège l’intégrité de la première composante ; elle ne prouve pas que la seconde soit la plus récente. Elle ne révèle pas non plus l’existence d’une machine virtuelle clonée, d’un processus dupliqué, d’un cache non vidé ou d’un module resté actif dans un autre site.

Le compteur n’est donc pas un simple accessoire. Il fait partie de la frontière de sécurité, avec les journaux de sortie, les files de réponses, les réservations d’indices et les preuves de mise à l’arrêt de l’ancien signataire. La question n’est plus seulement « cette copie est-elle correcte ? », mais « qui possède, à cet instant, chaque partie encore inutilisée de l’espace de signature ? »

Une seule opération : avancer puis livrer

RFC 8391 pour XMSS et RFC 8554 pour LMS exigent que l’état de la clé privée soit mis à jour avant la sortie de la signature. RFC 10033 traduit cette exigence en propriété de système : l’avancement de l’état et la libération de la signature doivent se comporter comme une transaction atomique, cohérente, isolée et durable.

Si la machine enregistre l’avancement puis tombe avant de livrer la signature, un indice est perdu, mais il ne sera pas réutilisé. Si elle livre d’abord puis perd l’écriture d’état, la signature existe dehors tandis que l’indice paraît encore libre dedans. Les deux échecs ne sont pas symétriques. Dans le doute, brûler une capacité finie est plus sûr que créer un chevauchement invisible.

Secteurs, intervalles et fenêtres temporelles

Le RFC décrit plusieurs techniques de partition. Des secteurs indépendants peuvent être confiés à des signataires distincts sous une même clé publique. Des plages d’indices peuvent être préattribuées. Un processus peut réserver un intervalle entier avant d’émettre des signatures ; s’il disparaît, la fin inutilisée de cet intervalle est abandonnée. Des fenêtres temporelles peuvent aussi circonscrire l’usage, à condition de ne jamais faire reculer l’horloge logique et de considérer comme consommée toute capacité inutilisée d’une période passée.

Ces méthodes ne suppriment pas l’état. Elles rendent son propriétaire explicite. Lors d’un transfert, la source doit cesser d’utiliser la partie cédée et la destination ne doit recevoir aucun domaine déjà attribué à un autre signataire, une copie hors ligne ou un système en panne. Une fusion ultérieure demande la même preuve de non-chevauchement.

Dans une procédure décrite hors du profil NIST sans exportation, RFC 10033 propose de préparer des arbres inférieurs, de faire signer leur racine par une clé OTS supérieure encore inutilisée, puis d’exporter la graine, la signature, l’indice et l’empreinte avant d’effacer irréversiblement la copie source. À la reprise, la première graine inutilisée est importée, l’arbre est régénéré et vérifié, puis la graine est supprimée du support de sauvegarde. La logique est solide parce qu’elle matérialise le passage de garde. Sa limite opérationnelle demeure la preuve de l’effacement, surtout après une panne catastrophique ou chez un dépositaire tiers.

Le reçu de garde de reprise

RFC 10033 n’impose pas le reçu proposé ici. Il fournit toutefois les éléments qui le rendent nécessaire. Le document de reprise devrait identifier la clé publique, l’algorithme et ses paramètres ; les identités du signataire et du HSM ; la génération de sauvegarde ; l’état restauré ; le plus grand indice dont une signature complète a été observée ; les secteurs, intervalles et fenêtres attribués ; les réservations sacrifiées ; les preuves d’arrêt ou d’effacement de la source ; les empreintes du paquet importé ; les opérateurs et approbateurs ; ainsi que les heures d’activation et de rapprochement.

Le reçu doit consigner l’incertitude au lieu de la faire disparaître. Si une file de réponses a pu libérer 64 signatures après la dernière écriture sûre, les 64 positions doivent être exclues. Si l’ancien appareil ne peut être déclaré inactif, son secteur reste en quarantaine. Une sauvegarde hors contrôle constitue un risque de chevauchement persistant.

Une telle pièce ne transforme pas une hypothèse en preuve cryptographique. Elle rend révisable la décision humaine : pourquoi croyait-on que le signataire restauré possédait seul une zone jamais utilisée, et quelle capacité a-t-on volontairement perdue pour rester prudent ?

Sources