Résumé

  • RFC 10021 impose à un endpoint Group OSCORE qui a perdu son état de contexte d’éviter la réutilisation de nonce et les erreurs de rejeu : il s’arrête, retrouve le contexte pertinent, puis vérifie la fraîcheur.
  • Un contexte restauré ou un défi de fraîcheur réussi établit une condition protocolaire précise, non la validité persistante d’un ordre, d’une approbation ou d’un effet.

Après le redémarrage d’un équipement de terrain, le mot le plus trompeur est souvent « récupéré ». Il peut vouloir dire que l’alimentation est revenue, qu’un lien réseau existe, qu’un coffre de clés répond ou qu’une supervision reçoit de nouveau un signal. Ce sont des faits différents. Aucun ne devrait devenir, par glissement de vocabulaire, « reprends le travail interrompu ».

RFC 10021, publiée en juillet 2026 sur la voie Standards Track de l’IETF, définit Group OSCORE pour les communications CoAP protégées au sein d’un groupe. En mode groupe, l’émetteur protège un message CoAP et le contresigne avec sa clé privée ; le destinataire vérifie cette contresignature avec la clé publique de l’émetteur et le contexte de sécurité. Le protocole produit donc une preuve étroite sur le message et sur son traitement d’authentification de source. Il n’est pas un ordonnanceur applicatif.

Cette retenue importe surtout quand l’état volatil disparaît. Group OSCORE distingue une partie durable du contexte de sécurité d’une partie variable, susceptible d’être perdue lors d’un redémarrage non préparé. Dès qu’il détecte cette perte, l’endpoint doit éviter de réemployer un nonce avec la même clé et traiter les messages rejoués. S’il ne peut obtenir des paramètres actualisés, il ne doit plus protéger de messages avec le contexte atteint. Un endpoint non silencieux qui ne peut plus détecter les rejeux ne doit pas non plus accepter les messages du groupe.

C’est un arrêt de sécurité, non un obstacle à contourner par un simple redémarrage logiciel.

La règle vaut aussi lorsqu’un historique destinataire a été supprimé pour libérer de la mémoire. Un Recipient Context redérivé commence alors avec une fenêtre de rejeu invalide : l’équipement n’en sait plus assez sur le trafic antérieur pour distinguer une requête neuve d’une ancienne. RFC 10021 propose des voies limitées : écarter le message, obtenir de nouveaux paramètres de contexte ou employer CoAP Echo. Elle ne dit pas qu’un paquet ayant l’apparence correcte reconstitue le passé.

Echo mérite une lecture prudente. RFC 9175 permet au serveur d’émettre un défi que le client renvoie afin de vérifier la fraîcheur selon des exigences définies par l’application. Dans Group OSCORE, un Echo correctement renvoyé peut valider la fenêtre de rejeu pertinente et laisser passer une requête fraîche vers l’application. C’est un rétablissement ciblé de confiance anti-rejeu. Echo ne rattache pas la requête à une réponse antérieure déterminée, ne reconstitue pas un journal transactionnel, ne prouve pas l’intention toujours présente d’un opérateur absent et ne décide pas si un actionneur peut repartir.

Le Group Manager joue un rôle important mais limité. RFC 10021 exige qu’il vérifie qu’un endpoint qui rejoint le groupe est autorisé à le faire, directement ou sur la base d’un élément fourni par une entité de confiance. Les détails de cette autorisation restent hors du champ du texte. L’entrée dans un groupe de sécurité n’est donc pas une délégation permanente pour chaque opération qui pourrait ensuite emprunter ce groupe. Distribution de contexte, appartenance et autorité métier courante suivent des registres et des horloges différents.

Le renouvellement de clés révèle encore la faiblesse d’un voyant vert unique. Un client peut protéger une requête avec l’ancien contexte juste avant que le serveur installe de nouveaux paramètres ; le serveur peut alors protéger sa réponse avec le nouveau contexte. RFC 10021 évite les difficultés de réutilisation de nonce dans cette transition. Elle n’affirme pas que la requête initiale est encore opportune, que l’état cible est encore souhaité ou qu’une réponse tardive prouve l’achèvement du processus.

L’interprétation éditoriale est simple : conserver séparément la détection de perte, les identifiants d’ancien et de nouveau contexte, le reprovisionnement ou le défi de fraîcheur, le résultat de signature et de rejeu, la réconciliation de l’état applicatif, l’approbation locale et l’effet observé indépendamment. Ainsi, un système retrouve un socle de sécurité de message sans transformer cette récupération en autorité.

Sources