Résumé

  • RFC 10013 définit un objet « composant mesuré » : nom et valeur brute ou condensée obligatoires, version, autorités de signature du composant et indicateurs de profil facultatifs. Cet objet s’insère dans une revendication de mesure EAT en JSON ou en CBOR.
  • La conformité du format ne vaut pas décision de confiance. L’autorité qui signe le composant n’est pas nécessairement le signataire de l’EAT ; un condensat identique ne prouve pas que le périmètre utile a été mesuré ; une évaluation positive ne prouve ni propriété, ni enrôlement, ni droit d’accès.
  • La preuve défendable conserve toute la chaîne : objet prélevé, moment et méthode de mesure, profil, fraîcheur, valeur de référence, politique du Verifier, Attestation Result et règle propre au Relying Party.

Une remise en service qui paraît déjà décidée

Imaginons un boîtier de bord revenu de maintenance. Avant de réintégrer le réseau d’exploitation, il présente un EAT récent et correctement signé. Le composant se nomme « chargeur de démarrage », sa version suit un schéma connu, son condensat SHA-256 correspond à la référence autorisée et deux identifiants d’autorité renvoient aux signataires admis du micrologiciel.

Le Verifier renvoie un résultat conforme. L’écran de remise en service passe au vert.

Pourtant, le boîtier ne possède encore aucun droit.

La mesure a peut-être couvert le chargeur signé sans le fichier mutable qui lui indique quel module charger ensuite. La valeur de référence peut encore accepter une version devenue vulnérable. Le boîtier peut être authentique mais appartenir à un prestataire. Il peut être enrôlé pour envoyer de la télémétrie, pas pour administrer le réseau. L’ordre des autorités peut avoir un sens que seul le profil EAT applicable définit.

Ces incertitudes ne réfutent pas la mesure. Elles montrent ce qu’elle ne décide pas.

Publié en juillet 2026 sur la voie Standards Track, RFC 10013 normalise la description d’un état échantillonné. Sa retenue est essentielle : il rend une preuve échangeable sans lui attribuer les conséquences de sécurité et de métier qui appartiennent aux acteurs en aval.

Mesurer suppose d’abord de choisir

Un composant mesuré peut être un micrologiciel en mémoire flash, un logiciel chargé au démarrage, un contrôle d’intégrité en cours d’exécution, un objet du système de fichiers, une configuration ou un registre du processeur. Le modèle est plus large qu’un inventaire logiciel.

RFC 9393 définit CoSWID pour identifier et suivre des logiciels. EAT pouvait déjà transporter un CoSWID de type evidence. Mais un registre CPU, une étape de démarrage précoce ou un objet sans système de fichiers ne se laisse pas toujours décrire comme un paquet installé. RFC 10013 répond à cette lacune.

Il ne choisit pas les octets.

Le concepteur de plateforme trace le périmètre. Le mécanisme de collecte lit un état à un instant donné. Une enclave ou une racine matérielle peut renforcer la collecte ; elle ne transforme pas un périmètre incomplet en vue complète. Un condensat exact d’un objet trop étroit reste exact et trop étroit.

Il faut donc conserver le Target Environment, la frontière du composant, le collecteur, l’époque de démarrage, le moment du prélèvement et les dépendances hors mesure. Le message « secure boot réussi » n’est exploitable que si l’on sait quelle propriété concrète a été testée.

La primauté du code en fonctionnement replace l’autorité au bon endroit. Le standard fournit une grammaire commune. L’exploitation doit encore montrer ce qui a été lu, ce qui s’est exécuté et quelle action a suivi.

Cinq champs, cinq limites

Le nom du composant est obligatoire et lisible par une personne. Sa convention dépend du type de composant. Il doit rester stable au fil des versions afin de faciliter le suivi, mais il ne devient pas pour autant un identifiant mondial. Un chemin de fichier peut désigner un emplacement sans garantir que le même objet sémantique y réside toujours.

La version est facultative. Elle peut réutiliser le vocabulaire de schémas de version de CoSWID. Le modèle d’information recommande Semantic Versioning ; il ne l’impose pas à tous les micrologiciels, registres et objets de configuration.

La mesure prend une forme brute ou condensée. La forme brute peut aller de quelques octets à une configuration volumineuse ; le décodeur peut limiter la mémoire qu’il lui consacre. Cette latitude est aussi un avertissement contre une surface de déni de service.

La forme condensée indique l’algorithme et la valeur. L’identifiant de l’algorithme est interprété au moyen du registre IANA Named Information Hash Algorithms. RFC 10013 exige une fonction forte. La force cryptographique protège la comparaison, pas le choix de ce qui a été comparé.

Enfin, les autorités sont facultatives. Elles désignent des entités capables d’identifier le composant installé par leur signature numérique. Un certificat X.509, une clé brute ou une empreinte de clé peuvent servir d’identifiant. La vérification peut intervenir à l’installation, dans une architecture de mise à jour telle que RFC 9019, ou au lancement.

Le signataire du logiciel ne signe pas nécessairement la preuve

RFC 10013 sépare expressément la signature du composant de celle de l’EAT qui contient la preuve.

La première établit une provenance pour l’artefact installé. La seconde protège l’ensemble de revendications et le rattache à un Attester. Confondre les deux revient à supprimer la question : qui affirme avoir observé cet état, sur quel appareil et avec quelle protection ?

Plusieurs autorités peuvent apparaître : système de mise à jour, propriétaire de parc, auditeur ou autre approbateur. Leur ordre peut être significatif. Le standard de base ne fixe ni les rôles ni l’encodage. Le profil EAT doit dire si le champ est utilisé et comment lire chaque entrée.

Les indicateurs suivent la même discipline. Ils occupent exactement huit octets, mais leurs 64 bits n’ont aucun sens universel. Si un consommateur ignore le profil alors que des autorités ou des indicateurs sont présents, il doit rejeter l’EAT. Deviner une ancienne disposition des bits ne serait pas de la compatibilité ; ce serait une politique inventée sans trace.

L’interopérabilité des octets n’est pas celle du jugement

RFC 10013 coordonne JSON et CBOR. Une EAT CBOR peut porter un composant CBOR de manière homogène ou encapsuler JSON ; une EAT JSON peut porter JSON ou encapsuler du CBOR en base64url. IANA enregistre les types de média correspondants, et le registre CoRE leur attribue 295 et 296.

Ces numéros permettent de choisir un décodeur. Ils ne permettent pas de choisir une décision.

La conception rejoint le principe de spécification initiale minimale et de décision future localisée. Le socle commun fixe ce qui doit traverser les frontières. Le profil, les valeurs de référence, l’évaluation et l’autorisation restent des choix explicites de ceux qui en supportent le risque.

La recherche officielle des errata de RFC 10013 n’en trouvait aucun le 30 août 2026. Cette observation datée ne prouve ni l’absence future d’erratum ni la correction d’une implémentation.

EAT authentifie un message, pas un niveau de sécurité

RFC 9711 précise que l’EAT définit la sémantique des claims sans imposer de niveau de sécurité à leur implémentation ou à l’Attester. Le destinataire doit comprendre la réalisation du fournisseur et/ou les contrôles du Verifier.

Un même format peut sortir d’un matériel fortement protégé ou d’une application plus ordinaire. La signature prouve l’intégrité et l’origine relatives à une clé ; elle ne rend pas ces deux productions équivalentes.

Tout usage d’EAT doit disposer d’un mécanisme de fraîcheur. Mais la fraîcheur du jeton et l’âge de la mesure ne sont pas automatiquement identiques. Un état prélevé au démarrage peut être inséré dans un jeton émis plus tard. L’audit doit lier heure de prélèvement, heure de signature et époque de démarrage.

EAT distingue également la revendication measurements de measres. Cette dernière peut signaler succès, échec, absence de test ou absence de valeur lors d’une comparaison aux références. RFC 9711 indique qu’elle n’est pas le résultat global d’un Verifier. Traduire measres=success par « appareil digne de confiance » agrandit le champ sans autorité normative.

Le modèle PSA de RFC 9783, dont RFC 10013 reprend et généralise une partie, montre que l’évaluation peut exiger une mesure précise, accepter une série de versions ou privilégier un signataire reconnu. Ces politiques ne sont pas interchangeables.

Le Verifier évalue ; le Relying Party expose la ressource

RFC 9334 donne à chaque responsabilité un rôle.

L’Attester produit l’Evidence. Le Reference Value Provider fournit les états attendus. L’Endorser apporte des garanties sur certaines capacités. Le Verifier applique une Appraisal Policy for Evidence et signe un Attestation Result. Le Relying Party décide, au regard de sa propre politique, l’opération ou la donnée qui devient accessible.

Les rôles peuvent résider dans un même service. Leurs décisions ne disparaissent pas pour autant.

Une référence a une provenance, une version, une date d’effet et un retrait éventuel. Après la découverte d’une vulnérabilité, le même condensat peut passer d’acceptable à interdit sans changement de l’équipement. L’administrateur de la référence exerce donc un pouvoir de sécurité à distance.

Le Verifier peut rendre une preuve hétérogène compréhensible pour le Relying Party. En échange, il devient une concentration de confiance. Son identité, sa version de politique, la fraîcheur et la force de l’Evidence doivent accompagner le résultat.

La conformité n’est pas l’habilitation. RFC 9334 explique qu’une entreprise peut reconnaître tous les appareils sains d’un fabricant, tout en n’admettant sur son réseau que ceux dont elle est propriétaire. Un appareil de prestataire, sain et authentique, reste extérieur au parc.

Conserver la chaîne plutôt que le voyant

L’enregistrement défendable suit :

périmètre mesuré → collecteur et instant → valeur → convention de nommage → sens des autorités → signataire et fraîcheur de l’EAT → profil → référence → politique et résultat du Verifier → politique du Relying Party → action accordée → résultat observé.

Un booléen ne permet pas de remonter cette chaîne.

Après un incident, il faut déterminer si le collecteur a omis l’état dangereux, si la référence l’a admis, si le Verifier a mal appliqué sa politique ou si le Relying Party a octroyé un droit excessif. Sans les transitions, chaque équipe montre le même voyant vert.

L’analyse de Heng Lu sur les couches de réalité et le pouvoir symbolique éclaire ce défaut. Nom, version, condensat et résultat représentent un état sélectionné. Ils gagnent en valeur quand la frontière avec l’exécution reste visible.

La preuve peut devenir un inventaire pour l’attaquant

Nom et version révèlent parfois le logiciel, le correctif ou la configuration. RFC 10013 avertit que leur stabilité peut permettre le suivi. Une mesure brute peut divulguer davantage.

La chaîne comporte souvent plusieurs consommateurs. Si le premier déchiffre l’EAT puis transmet des sous-ensembles sans l’enveloppe initiale, RFC 9711 exige une protection de communication équivalente et recommande de réduire l’exposition de chacun.

La souveraineté pratique des données impose de recenser les services, journaux, traces et évaluateurs qui détiennent effectivement ces informations. Posséder le matériel ne signifie pas contrôler toutes les copies de son état.

La divulgation doit suivre le besoin. Le contrôle d’accès peut consommer un résultat récent sans recevoir la configuration brute. Le service de remédiation peut avoir besoin de la version, pas d’un identifiant durable de l’appareil.

La limite est une qualité du standard

RFC 10013 ne dit jamais « cet appareil est bon ». C’est sa force.

Il normalise un objet de preuve, rapproche JSON et CBOR, exige que les profils définissent leurs extensions, impose un condensat fort et ordonne le rejet lorsque des champs dépendant du profil restent incompris. Puis il s’arrête.

Le collecteur répond du périmètre. L’Attester répond de la production de l’Evidence. Le signataire du composant répond de la provenance de l’artefact. Le fournisseur de références répond de l’état attendu. Le Verifier répond de l’évaluation. Le Relying Party répond du droit accordé.

Reconnaître un composant ouvre le raisonnement. Cela ne le clôt pas.