Résumé

  • À RIPE 93, Muhammad Usama Sardar a contesté l’attestation précoce intégrée à la négociation TLS. Dans un chemin Intel TDX testé, Cocos AI a accepté une preuve portant une valeur de fraîcheur réutilisée ou différente de celle de la séance.
  • Un second avis Cocos décrit un chemin AMD SEV-SNP où l’absence de valeur attendue permettait l’acceptation d’une preuve étrangère à la connexion. La version 0.9.0 passe à une attestation après négociation ; la charte IETF SEAT exige une fraîcheur par connexion.

Au vestiaire, le portier vérifie une étiquette. Elle est accrochée au manteau d’hier. L’image résume le défaut précis décrit dans l’avis Intel TDX de Cocos AI. Le vérificateur recevait la valeur censée identifier la séance TLS, puis omettait de la placer dans la règle appliquée à la preuve matérielle. Dans l’essai de l’éditeur, une preuve externe portant une valeur différente ou réutilisée a été acceptée ; des données applicatives ont ensuite quitté la porte TLS.

Le programme de RIPE 93 situe l’intervention de Muhammad Usama Sardar le 27 octobre. Sa critique de l’attestation intégrée trop tôt à la négociation trouve ici un cas vérifiable : la complexité ajoutée n’a pas garanti que le justificatif appartenait à la conversation actuelle. Une poignée de main réussie ne contrôle pas à elle seule l’identité du manteau.

Le second défaut change de matériel et de condition. Dans l’avis AMD SEV-SNP, Cocos explique que la version 0.8.2 ne renseignait la valeur ReportData attendue que si l’appelant en fournissait une non vide. En l’absence de valeur, une preuve sans lien avec la connexion pouvait passer. Lorsqu’une valeur non vide était fournie, la comparaison fonctionnait et rejetait les écarts. L’éditeur indique avoir adopté l’attestation après négociation en version 0.9.0.

Un avis distinct d’Edgeless Systems décrit Contrast avant 1.16.0 : sous les conditions d’interception et de fabrication de preuve ou d’extraction de secrets qu’il détaille, un rapport valide issu d’une autre machine pouvait convaincre le vérificateur. La version 1.16.0 introduit une liste d’identifiants matériels autorisés. Il faut donc demander trois choses au tampon « approuvé » : quelle preuve, quelle machine, quelle séance ?

La charte du groupe IETF SEAT demande de lier la preuve à la connexion TLS, de permettre une fraîcheur par connexion et de soumettre le protocole à une analyse formelle pendant sa rédaction. Voilà un cahier des charges qu’un test peut faire mentir ou confirmer. Le protocole gagne sa crédibilité au moment où le vérificateur refuse un justificatif qui appartient à la veille.