Résumé

  • Un composant mesuré associe un nom stable, éventuellement une version, une valeur brute ou condensée et, si le profil le prévoit, des identifiants d’autorités. Ces identifiants concernent la signature ou l’identification du composant, pas la signature de l’EAT englobant.
  • Le profil EAT doit définir la fonction de chaque autorité, leur ordre et les 64 bits de drapeaux locaux. Si ce profil est inconnu et que ces champs apparaissent, le consommateur doit rejeter le jeton.
  • Le reçu complet relie cible mesurée, échantillonnage, digest, autorité du composant, profil, attester, fraîcheur, valeurs de référence, politique du vérificateur, résultat puis décision propre de la relying party.

L’incident commence par une phrase apparemment anodine dans un tableau de bord : « signed by authority X ».

L’équipe firmware comprend que X a approuvé le binaire. L’équipe d’accès croit que X a signé le jeton d’attestation. L’auditeur conclut que X a autorisé le terminal. Les trois lectures semblent compatibles avec la même ligne ; aucune ne décrit nécessairement le protocole.

La RFC 10013 donne justement une place différente à ces actes. Publiée en juillet 2026 sur le Standards Track, elle porte les noms de Simon Frost, Thomas Fossati, Hannes Tschofenig et Henk Birkholz. Le profil IETF de Tschofenig relie son nom à de nombreux travaux de sécurité et à cette RFC ; l’Université de la Bundeswehr à Munich le présente comme professeur de Secure Networks depuis mars 2026. Ces faits bornés documentent une contribution. Ils ne font pas de lui l’auteur unique ni le décideur des déploiements.

Ce que le composant transporte réellement

Un measured component n’est pas un avis de conformité. C’est une représentation d’un objet dont l’état a été échantillonné dans un environnement cible : firmware en flash, boot loader, logiciel chargé, fichier, configuration ou registre matériel.

Son nom est obligatoire. Une version peut le compléter. La mesure est soit une suite d’octets bruts, soit un couple algorithme/digest. Le modèle peut aussi porter une liste authorities et huit octets de drapeaux dont le profil fixe la signification.

La stabilité du nom est recommandée parce qu’elle permet de suivre le même composant au fil des versions. Mais cette continuité ne garantit pas que la bonne cible a été mesurée. Un digest exact n’indique ni où l’échantillonnage s’est produit, ni quand, ni avec quel degré d’isolation. Il ne contient pas la valeur de référence à laquelle on le comparera.

La RFC 9711 avertit elle-même que le format EAT ne fixe pas le niveau de sécurité de l’attester ou de la collecte des claims. Une valeur bien encodée peut provenir d’un capteur faible. Une signature correcte peut protéger une observation incomplète. La syntaxe empêche certaines ambiguïtés ; elle ne remplace pas l’évaluation.

L’autorité du composant n’est pas l’attester

La section décisive décrit l’autorité comme l’entité capable d’identifier le composant de façon autoritative en le signant. Cette signature peut être contrôlée à l’installation ou lors de l’exécution par le firmware de démarrage, le système ou un lanceur. L’identifiant peut prendre la forme d’un certificat X.509, d’une clé brute, d’une empreinte ou d’un autre lien unique à la clé publique.

Puis vient la frontière : cette signature n’a aucun rapport nécessaire avec la signature de l’attester sur la preuve EAT. L’identifiant d’autorité ne désigne donc pas, à lui seul, le signataire du jeton englobant.

Un fabricant peut signer le firmware. Un opérateur de flotte peut ajouter son approbation. Un tiers peut certifier une étape. Plus tard, un environnement d’attestation observe la machine et signe les claims. Ces acteurs peuvent partager une organisation ; le protocole n’en déduit aucune identité commune.

La RFC 9019 montre pourquoi cette séparation est saine. Authentifier l’auteur d’une image ou d’un manifeste fournit une entrée à la décision, pas toutes les permissions. Pour une infrastructure critique, l’appareil peut exiger l’accord du producteur et celui de l’opérateur. La possession d’une clé valide n’emporte pas le mandat de l’autre principal.

Le profil est le dictionnaire obligatoire

Plusieurs autorités peuvent figurer dans le tableau. L’une peut être le système de mise à jour, une autre le propriétaire de flotte, une troisième l’auditeur. Leur ordre peut même être significatif. Aucun octet ne permet de deviner ces rôles universellement.

La RFC impose donc au profil EAT de dire si authorities est utilisé, ce que représente chaque entrée et comment lire son type. Les 64 bits de flags suivent le même régime. Une longueur fixe ne fabrique pas une sémantique commune.

Si le consommateur ignore le profil et rencontre des autorités ou des drapeaux, il doit rejeter l’EAT. Il ne peut ni supprimer les champs inconnus, ni adopter l’ordre d’un autre produit, ni laisser la réussite de la signature extérieure couvrir son ignorance.

Ce refus est une frontière d’interopérabilité, pas une panne arbitraire. La spécification minimale partage les champs portables et la règle de rejet. Les rôles locaux restent dans le profil de ceux qui peuvent réellement les définir. Le problème survient quand le producteur déploie un nouveau profil avant les vérificateurs, ou quand un vérificateur accepte tout en perdant la capacité d’expliquer ce qu’il a accepté.

Trois politiques après deux signatures

L’EAT doit être protégé en authenticité et en intégrité. Dans le modèle courant, l’attester signe une collection de claims et fournit une fraîcheur par nonce ou autre mécanisme. Le vérificateur doit encore établir la provenance de la clé, l’association à la cible et la qualité de l’environnement d’attestation.

Il compare ensuite les claims à des valeurs de référence selon une politique d’appraisal. Le résultat appartient au vérificateur. La relying party applique enfin sa propre politique à l’opération demandée.

Cette dernière étape ne peut être déduite d’un digest conforme. Une entreprise peut reconnaître un appareil comme sain tout en refusant l’accès parce qu’il appartient à un autre client. Un composant peut être approuvé pour démarrer et interdit pour traiter une classe de données. Une preuve fraîche peut être hors de la fenêtre exigée par une transaction particulière.

La chaîne complète distingue donc : le signataire du composant, l’attester de la preuve, le vérificateur du résultat et le propriétaire de la ressource. L’agence de l’un ne traverse pas automatiquement la signature de l’autre.

La stabilité a un coût de corrélation

Conserver le même nom de composant à travers les versions améliore la comparaison et l’assistance. La RFC 10013 avertit toutefois que nom et version révèlent des informations logicielles ou de configuration et qu’un nom stable peut permettre le suivi.

Un identifiant de clé d’autorité réutilisé à grande échelle ajoute une autre balise. La question n’est pas de supprimer la preuve, mais d’en limiter le destinataire. Le vérificateur peut avoir besoin du composant détaillé alors que la relying party n’a besoin que d’un résultat réduit, lié à une opération et à une durée.

Le profil doit préciser qui voit les mesures brutes, les noms, les versions et les clés, et si la corrélation entre services est autorisée. Une meilleure traçabilité interne ne justifie pas une identité globale du terminal.

Le reçu que l’exploitation doit pouvoir rejouer

Conservez l’EAT exact ou son objet adressé par contenu, son type, son encodage, l’identifiant et la version du profil. Ajoutez la clé de l’attester, l’algorithme extérieur, la provenance de vérification, le nonce, les temps de collecte et de réception.

Pour chaque composant, conservez nom, convention de version, cible et frontière de mesure. Distinguez brut et digest ; dans le second cas, gardez algorithme et valeur. Maintenez l’ordre original des autorités, la définition de profil qui attribue leurs rôles, les signatures de composant associées et leur résultat. Gardez aussi les huit octets de flags avant interprétation.

Le dossier d’appraisal nomme le fournisseur des valeurs de référence, leur jeu et version, chaque comparaison, les mesures absentes, la politique et la version du vérificateur. Il contient le résultat exact et l’identité qui le garantit.

Le dernier bloc appartient à la relying party : ressource, opération, appareil ou principal, politique applicable, décision, restrictions, expiration et voie de remédiation. « Profil inconnu » n’est pas « digest faux » ; « composant non approuvé » n’est pas « EAT mal signé » ; « conforme mais non autorisé » peut être le résultat correct.

La primauté du running code exige d’observer ce que les composants exécutent réellement. Mais une lumière verte sans profils, clés, fraîcheur et versions de politique ne permet pas cette observation. Elle la remplace par une impression.

Sources