Résumé

  • RFC 9684 définit des RPC YANG capables de demander des quotes TPM 1.2 ou 2.0 liées à un nonce et d’extraire des journaux BIOS, IMA ou de démarrage d’équipement réseau.
  • Une signature et un PCR cohérents prouvent un ensemble de mesures sélectionné ; ils ne prouvent pas que le bon TPM, les bons PCR et tous les composants pertinents ont été couverts.
  • La chaîne complète sépare identité de la clé, reconstruction du journal, valeurs de référence, appréciation du Verifier, résultat d’attestation, autorisation locale, exécution et effet réseau.

Le PCR signé était exactement celui que le journal permettait de recalculer. Aucun octet ne manquait dans la réponse. Pourtant, le fichier qui avait déclenché l’enquête n’apparaissait nulle part : la politique IMA ne l’avait jamais mesuré.

Ce résultat n’était pas faux. Il répondait fidèlement à une question trop étroite. Le danger commence lorsqu’un tableau remplace « cohérence des mesures incluses » par « équipement sain » et efface le choix qui précède la cryptographie.

RFC 9684 fournit l’interface CHARRA pour ce premier travail. Le module ietf-tpm-remote-attestation permet à un client YANG de sélectionner des PCR, d’envoyer un nonce frais, de recevoir une quote TPM et de demander des journaux de mesure. Cette interopérabilité est précieuse. Elle ne transforme pas le modèle de données en politique d’acceptation.

Le nonce date la réponse, pas toute la machine

Le client doit fournir un nonce frais doté d’une entropie suffisante. L’Attester l’intègre à la réponse, ce qui empêche de présenter une ancienne quote comme réponse à la nouvelle demande. Cette preuve de fraîcheur reste attachée à l’Evidence produite.

Elle ne garantit pas que l’état n’a pas changé une seconde plus tard. Elle ne révèle pas les PCR non demandés. Elle ne complète pas un journal que la politique de mesure a laissé vide. Elle ne montre pas automatiquement quel composant physique dépend de quel TPM dans un châssis composite.

RFC 9684 laisse explicitement hors de son périmètre la manière de communiquer la relation entre chaque TPM et le composant mesuré. Avec la fonction mtpm, plusieurs TPM peuvent répondre ; sans certificate-name, tous ceux qui sont compatibles peuvent être sollicités. Une réponse unique est donc précise seulement si l’organisation connaît et gouverne la carte composant–TPM–certificat.

Le reçu de demande doit conserver le nonce, l’identité de l’équipement, le RPC, la version TPM, le certificat ciblé, la banque de hash, les indices PCR, le type de journal et la version de configuration. Sans ces éléments, une quote valable devient impossible à interpréter après un remplacement de carte, une rotation de clé ou une évolution du firmware.

La clé d’attestation doit elle aussi être attestée

Une réponse TPM 2.0 peut exposer TPMS_QUOTE_INFO, la signature, le certificat nommé, le temps de fonctionnement et des valeurs PCR non signées destinées à l’analyse. La signature protège la structure attestée ; les valeurs PCR facilitent la reconstruction ; le certificat relie la clé à un rôle d’attestation attendu. Aucun champ ne remplace les autres.

Le destinataire doit vérifier qu’un certificat TPM 1.2 correspond à une AIK active ou qu’un certificat TPM 2.0 désigne une AK active dont la maîtrise de la clé privée appartient légitimement au TPM visé. « Signature valide » ne répond pas à « qui avait le droit de signer pour ce composant ? ».

Le modèle contient en outre des structures configurables. Un certificat peut ne pas correspondre à l’AK attendue. Un type de clé peut être mal décrit. Une liste peut annoncer des algorithmes que le TPM physique ne prend pas en charge. Des PCR jamais étendus par le logiciel système peuvent être sélectionnés. Dans ces cas, NETCONF ou RESTCONF peut transporter parfaitement une conclusion mal cadrée.

La couche sécurisée protège donc l’échange de gestion. Elle ne valide ni la relation clé–TPM, ni le périmètre de mesure, ni le baseline. Confondre ces fonctions revient à laisser l’authenticité du messager décider de la vérité du message.

Un journal cohérent peut être incomplet

Le PCR accumule des extensions sous forme de hash roulant. Le journal redonne les événements nécessaires pour rejouer cette séquence. Le Verifier peut recalculer la valeur attendue, la comparer à l’Evidence signée puis confronter chaque fichier mesuré aux Reference Values.

Cette méthode révèle des écarts avec précision, mais seulement dans le monde qui a été mesuré. L’annexe consacrée à IMA rappelle que les templates définissent les champs du journal et que la politique IMA choisit les fichiers. Sans politique, aucune mesure n’est prise et IMA est effectivement désactivé. Un journal vide peut donc être parfaitement cohérent avec un PCR sans démontrer l’intégrité de l’ensemble logiciel.

Les journaux BIOS/UEFI, IMA et de démarrage réseau ne couvrent pas nécessairement la même phase. Un équipement composite peut démarrer des composants en parallèle. Une mise à jour légitime modifie des hash ; les Reference Integrity Manifests doivent alors évoluer. Une valeur différente peut signaler une altération, un patch autorisé ou une mauvaise référence. La différence est un fait ; son sens dépend du contexte d’appréciation.

Le rapport utile distingue donc : présence et format du journal ; version de la politique de mesure ; résultat du rejeu ; couverture des composants ; identité et date des Reference Values ; règles de tolérance ; décision d’appraisal. Un seul voyant détruit précisément les explications dont l’exploitation aura besoin lors du prochain changement.

Le Verifier ne remplace pas le Relying Party

RFC 9334 sépare l’Attester qui produit l’Evidence, le Verifier qui l’apprécie et le Relying Party qui utilise l’Attestation Result pour une décision donnée. RFC 9683 place cette architecture dans le contexte des équipements réseau et des fournisseurs d’Endorsements et de Reference Values.

RFC 9684 facilite la remontée de l’Evidence. Il ne donne pas au fabricant, au serveur d’attestation ou à l’outil de gestion une autorité universelle sur l’admission réseau. Un résultat acceptable pour l’inventaire peut être insuffisant pour établir une session de routage. Un résultat négatif peut imposer une maintenance sans justifier l’arrêt immédiat d’un service redondé.

Après la décision, une autre preuve commence. Le contrôleur a-t-il réellement isolé le port ? La session a-t-elle été retirée ? Le trafic a-t-il basculé ? Le service est-il resté disponible ? Le TPM ne voit pas ces effets. Une quote ne peut pas être le reçu de l’action prise ailleurs.

Lire les Evidence est un pouvoir sensible

Les journaux exposent des hash et des détails susceptibles d’identifier des versions vulnérables. Leur extraction en volume consomme des ressources. RFC 9684 avertit qu’une demande importante peut contribuer à un déni de service et recommande de protéger les RPC par le modèle NACM, avec refus par défaut sauf pour les Verifiers autorisés.

L’organisation doit donc gouverner deux risques simultanément : une collecte trop faible qui produit une assurance illusoire, et une collecte trop large qui révèle la flotte ou surcharge les équipements. Le minimum commun est un format d’échange ; la fréquence, le volume, le choix des PCR et le droit de demander restent des décisions locales explicites.

La spécification initiale minimale aide à garder cette frontière étroite. Les couches de réalité empêchent le mot « attesté » de fusionner signature, mesure, référence et autorisation. La primauté du code exécuté impose enfin de regarder le système qui a appliqué la décision.

CHARRA rend la réponse TPM transportable et vérifiable. La gouvernance doit refuser de lui attribuer une portée supérieure : Evidence fraîche, verdict situé, action observée — trois reçus, trois propriétaires.

Sources