要約

  • Muhammad Usama Sardarは10月27日のRIPE 93で、TLSの握手中に遠隔証明を組み込む方式を批判した。Cocos AIのIntel TDX経路では、再利用または不一致のセッション値を持つ証拠が試験で受理され、握手後にアプリケーションデータが渡された。
  • 別のCocos AI告知はAMD SEV-SNP経路を扱う。呼び出し側が期待値を省くと無関係な証拠が通り得た。0.9.0では握手後の証明へ移行し、IETF SEATの憲章は接続ごとの鮮度を要求している。

入口の係員は札を見た。札が今来た客のものかは見なかった。Cocos AI自身のIntel TDXに関する告知が示すのは、その照合漏れだ。検証器には現在のTLS接続を識別する値が渡された。しかし試験対象の実装は、その値をハードウェア報告の検証条件に入れなかった。以前の接続で使った値や、現在の値と食い違う reportData を含む外部の証拠が通り、握手後にアプリケーションデータが渡された。

RIPE 93の発表記録では、Sardarが早期証明の複雑さと結び付けの欠陥を問題にした。製品の告知がその議論を地面に下ろす。TLSの握手が整っていても、ハードウェアの証拠が「この相手、この接続」を指していなければ、許可の根拠がすり替わる。

もう一つのCocos AI告知はAMD SEV-SNPの別の経路を扱う。0.8.2では、呼び出し側が空でない期待 reportData を渡したときだけ、その値を照合した。値を省くと、現在の接続とは無関係な証拠が通り得た。値を渡せば不一致は拒否された。同社は0.9.0で握手後の証明に移ったという。入力欄が空だったときの振る舞いこそ、この欠陥の中心にある。

Edgeless SystemsのContrast告知では別の境界が問題になった。告知が示す通信傍受と報告偽造または秘密抽出の条件下では、別の機械から来た有効な報告でも旧版の検証器を通過し得た。1.16.0は許可するハードウェアIDの指定を導入した。「証拠が正しい」と「機械が正しい」は同じ判定ではない。

IETF SEATの承認済み憲章は、証拠とTLS接続の結合、接続ごとの鮮度、仕様策定と並行する形式的解析を掲げる。古い証拠、空の期待値、別の機械の報告を投入すれば、要求が実装されているか見える。信頼の札には、今日の客の番号が必要だ。