Résumé

  • Le projet daté du 28 octobre distingue la mesure d’un type de logiciel de l’identité d’une instance en cours d’exécution.
  • Une clé ancrée dans l’attestation permet d’authentifier cette instance sans autorité de certification ; un certificat WIMSE lui donne un nom susceptible de survivre au changement de clé.

Imaginez deux exemplaires du même programme confidentiel, lancés au même instant. Leurs mesures sont identiques. C’est une bonne nouvelle pour vérifier le code, une moins bonne pour celui qui a confié un secret à l’un des deux et veut lui parler de nouveau. La machine présente une preuve solide, mais son nom reste à établir.

Le document de Tirumaleswar Reddy et de ses coauteurs est une proposition individuelle, soumise à la discussion SEAT. Il ne rapporte aucun choix arrêté par le groupe. Son premier geste est pourtant net : une empreinte de logiciel désigne un type ; deux processus issus de la même image partagent cette empreinte.

La première voie laisse l’instance créer une paire de clés dans son environnement attesté. La preuve d’attestation transporte la clé publique ; la négociation TLS présente la même clé, directement ou dans un certificat autosigné. L’autorité de confiance est alors la chaîne d’attestation. Ce montage distingue la clé du voisin, sans attribuer un identifiant stable au programme. Après rotation de la clé, la continuité doit être établie autrement.

La seconde voie ajoute un certificat d’identité de charge de travail. Le projet renvoie aux travaux WIMSE sur les justificatifs et sur l’identifiant : le certificat nomme le programme et certifie sa clé, tandis que l’attestation rattache cette clé à l’environnement observé. Le nom peut rester stable quand la clé change. WIMSE autorise toutefois un nom pour une seule instance ou pour un service logique partagé entre plusieurs copies ; c’est le domaine émetteur qui fixe cette précision. L’émetteur du certificat entre ainsi dans la chaîne de pouvoir.

Un tampon valide de chaque côté ne règle pas toute l’affaire. Le certificat peut bien appartenir à l’identité annoncée et la machine être authentiquement isolée ; cette identité peut malgré tout s’exécuter dans une image qui n’a jamais été autorisée pour elle. Le projet confie à la partie qui accepte la connexion la vérification conjointe du nom et des mesures. Il demande aussi une preuve crédible que la clé privée a été créée et gardée dans l’environnement protégé : posséder une clé ne révèle pas son lieu de naissance.

L’architecture RATS sépare déjà l’attestation de la décision de la partie qui s’y fie. Ici, le choix concret est visible : faut-il reconnaître n’importe quelle copie conforme, une clé précise ou un nom qui traverse plusieurs clés ? Chaque réponse dessine une autre frontière d’autorité.