Résumé

  • Le tag CBOR 601 désigne un ensemble d’affirmations CWT sans signature, MAC ni chiffrement propre à l’objet.
  • Dans un usage RATS, l’authenticité et l’intégrité proviennent du canal et de ses extrémités authentifiées ; la fraîcheur et l’autorisation de divulguer restent des preuves distinctes.
  • À l’extraction, le canal cesse de protéger l’objet. Si le récepteur le retransmet, le RFC 9781 le traite comme provenant de ce récepteur : la chaîne de provenance doit être reconstruite explicitement.

La case verte qui ne suit pas le fichier

Une équipe de conformité examine deux lignes. La première dit qu’une session sécurisée a été établie entre un environnement d’attestation et un vérificateur. La seconde dit qu’un fichier portant le tag 601 a été archivé. Entre les deux, aucune ligne ne relie l’octet reçu, l’identité de l’extrémité, le processus d’extraction et le fichier final.

Les deux événements peuvent être vrais sans former une preuve complète. C’est précisément le problème que rend visible l’UCCS, l’Unprotected CWT Claims Set. Un CWT ordinaire place son ensemble d’affirmations dans une enveloppe COSE. L’objet peut alors transporter sa propre preuve d’origine et d’intégrité. L’UCCS retire cette enveloppe lorsque le déploiement dispose déjà d’un mécanisme approprié : un canal sécurisé ou, dans certains cas, un environnement d’exécution de confiance.

Le gain est réel pour les systèmes contraints. Réutiliser une association de sécurité existante réduit les octets, les opérations cryptographiques et la gestion de clés. Mais l’économie ne supprime pas la responsabilité ; elle la déplace vers le canal. Le tag #6.601 annonce seulement la structure. Il ne contient ni signature cachée, ni identité d’émetteur, ni preuve de session.

Pour la transmission RATS, le RFC exige que le récepteur authentifie l’émetteur lors de l’établissement du canal et que l’intégrité des communications soit assurée. Si la confidentialité est nécessaire, le récepteur doit lui aussi être authentifié. Il faut donc connaître le rôle de chaque extrémité, le protocole et la version, le justificatif d’identité, l’ancre de confiance, les paramètres cryptographiques et la session exacte qui a transporté les octets.

La fraîcheur ne se déduit pas de cette identité. Le document indique qu’un nonce peut apporter une protection contre la répétition. TLS 1.3 illustre aussi pourquoi le mode compte : données ordinaires et données précoces n’ont pas les mêmes propriétés de répétition. Une preuve exploitable distingue donc l’authentification de l’extrémité, la protection de l’enregistrement et le contrôle du nonce ou de la fenêtre temporelle.

Le récepteur hérite d’un pouvoir, pas d’une signature

La phrase décisive se trouve à la section 4. Quand l’UCCS sort du canal et entre dans le récepteur, les propriétés du canal ne le protègent plus. L’objet redevient une donnée non protégée dans l’environnement du vérificateur. S’il est ensuite transmis, il est traité comme s’il provenait du récepteur.

Ce n’est pas une subtilité de vocabulaire. Le récepteur acquiert la capacité de sélectionner, normaliser, enregistrer, corréler, signer ou transmettre les affirmations. L’acteur suivant ne voit plus le premier canal. Il voit une nouvelle assertion : « voici ce que j’ai reçu et ce que j’ai choisi de vous remettre ». La nouvelle protection doit donc identifier ce récepteur comme source opérante et relier son assertion à l’entrée originale.

Un hash ne remplace qu’une partie de cette chaîne. Il peut démontrer qu’un fichier correspond aux octets capturés. Il ne dit pas qui a capturé ces octets, dans quelle session, après quelle authentification, ni si le décodeur a modifié la représentation. La recette d’extraction doit lier le hash brut au canal, au processus et à l’instant. La recette de stockage ajoute l’auteur de l’écriture, le contrôle d’accès, le chiffrement au repos, la durée de conservation et l’effacement. La recette de transfert ajoute la transformation, la nouvelle protection, l’audience et l’accusé de réception.

Le cas d’attestation déléguée du RFC montre la bonne manière de franchir la frontière. Un sous-Attester sans clé de signature peut envoyer un UCCS à un Attester principal par un canal local sécurisé. L’Attester principal calcule le hash et protège ce hash avec sa clé de preuve, par exemple dans une structure EAT détachée. Il ne prétend pas que l’UCCS portait déjà une signature. Il assume une nouvelle assertion, traçable et vérifiable.

Le raisonnement ne doit pas devenir circulaire. Le RFC avertit que les affirmations UCCS ne peuvent généralement pas établir la confiance dans les identifiants qui ont créé le même canal. L’identité de l’extrémité doit reposer sur une base indépendante. De même, un canal authentifié ne garantit pas qu’un capteur a mesuré correctement ou qu’un environnement d’attestation résiste à la falsification.

Enfin, une enveloppe CWT complète suit une règle différente. Son COSE conserve son propre chemin de signature et d’intégrité. Le canal authentifie son pair de transport ; il n’endosse pas automatiquement le signataire interne. La rupture de source analysée ici est donc propre au remplacement de la protection de l’objet par celle du canal.

De la réception à l’action

La chaîne utile comporte neuf reçus : format et octets ; établissement du canal ; identité des extrémités ; fraîcheur et répétition ; extraction ; stockage et garde ; retransmission et nouvelle protection ; appréciation par le Verifier ; décision du Relying Party.

Une appréciation favorable n’est pas encore une autorisation. Le RFC 9334 sépare l’Attester qui produit l’Evidence, le Verifier qui l’évalue et le Relying Party qui décide d’une action propre à son service. Le fait que le récepteur devienne source lors d’un transfert rend cette séparation encore plus importante : le Verifier doit savoir s’il évalue l’environnement initial, l’assertion du récepteur ou les deux.

Le RFC 9781 offre ainsi une règle commune minimale et exigeante. Il rend l’économie cryptographique possible à l’intérieur d’un périmètre précis, puis refuse que ce périmètre soit transformé en confiance universelle. Le tag est un fait symbolique. L’assurance apparaît seulement dans l’exécution, les identités et les reçus conservés.

Sources