ベンダー各社は「コンフィデンシャルコンピューティング」を、欧州のソブリンクラウド構想を支える技術的基盤として位置づけようとしています。しかし新たな研究によると、システム内で暗号学的な信頼を証明するために使われるセキュリティプロトコルには、根本的なアーキテクチャ上の欠陥がある可能性があるといいます。
コンフィデンシャルコンピューティングは、リモートアテステーション(遠隔認証)と呼ばれる仕組みに支えられています。これは、機密データをやり取りする前に、サーバーが本物で改変されていないトラステッド・エグゼキューション・エンバイロメント(TEE)上で稼働していることを、クライアントに対して暗号学的に証明する仕組みです。インテルの製品ページでは、TDXが「データ主権とガバナンスに対する保護機能を追加する」と謳われています。Google Cloudも自社のコンフィデンシャルコンピューティング基盤について、「顧客データへのアクセスを完全かつ監査可能な形で制御できる」と説明しています。
5月には、The Registerが報じたところによると、インテルおよびAMDのシリコン上でオペレーティングシステムの下層で稼働する「チップの中のチップ」、すなわちマネジメントエンジンは、SecNumCloudのような欧州のソブリンティ(主権)フレームワークが実際に評価する範囲の外にあるとのことです。これにより、シリコンの上位層、つまりチップ自体が信頼できることを証明するためのプロトコルについては、疑問が未解決のまま残されていました。
新たに独立検証を経た研究が、この疑問に答えを出しました。しかもその答えは、安心できるものではありません。
謳い文句ほど証明できていないプロトコル
TUドレスデンの研究者であるMuhammad Usama Sardar氏は、この過去2年間、Attested TLSと呼ばれるこのプロトコルが、実際にその謳い文句どおりの働きをしているかどうかを形式的に検証する作業に取り組んできました。プロトコルの記号的セキュリティ解析ツールであるProVerifを用いた結果、同氏と共著者らは、Attested TLSはその大部分において謳い文句どおりの働きをしていないことを発見しました。
Mariam Moustafa氏、Tuomas Aura氏を共著者とし、AsiaCCS 2026カンファレンスで発表された同氏らの最近の論文「Identity Crisis in Confidential Computing」では、最先端のAttested TLSプロトコル2種類に対する迂回攻撃(ダイバージョン攻撃)が発見されました。あるサーバー宛てに意図された接続が、世界のどこかにある、同一のソフトウェアを稼働させた別の侵害済みマシンへと、クライアント側が気づかないまま密かにリダイレクトされてしまうというものです。この場合、接続先として意図されていたサーバー自体には何の落ち度もありません。攻撃者は、このプロトコルがソフトウェアの完全性はチェックしても、その所在地はチェックしないという点を突いているだけなのです。
最近発表された論文「Intra-handshake.fail」(共著者:Viacheslav Dubeyko氏、Jean-Marie Jacquet氏、ESORICS 2026に採択)は、さらに踏み込んだ内容になっています。この論文では、業界で「イントラ・ハンドシェイク・アテステーション」と呼ばれる、TLSハンドシェイク自体の最中にエビデンスを生成する方式を検証し、そのエビデンスを基盤となる接続に暗号学的に紐付ける7通りの手法をテストしました。その結果、いずれの手法もリレー攻撃を防げないことが判明しました。リレー攻撃とは、クライアントが本物で信頼できるAIエージェントやサーバーのエビデンスを検証したつもりが、最終的には全く別の悪意あるエージェントやサーバーに対して自らのトラフィックを暗号化してしまうというものです。これらの前提としては、ハードウェア自体は信頼できるという出発点があります。
「コンフィデンシャルコンピューティングでは、いずれにせよハードウェアメーカーを信頼せざるを得ません」とSardar氏はThe Registerに語りました。「これを回避する方法は絶対にありません」。この信頼の根(ルート・オブ・トラスト)を受け入れた上で、プロトコル層がそれ以外のすべてを保証するはずだった、と同氏は主張します。しかし同氏の研究は、そのプロトコル層が提供しているのは、想定よりもはるかに少ないということを示しています。
3段階の信頼レベル
研究者らは、この問題を、アテステーションのエビデンスと、それが証明すべき実際のTLS接続との間の暗号学的な紐付けについて、段階的に厳格さが増す3つのレベルとして形式化しています。
最も弱いレベル1は、エビデンスをハンドシェイク中の最初の鍵交換、すなわちディフィー・ヘルマン(Diffie-Hellman)ステップのみに紐付けるものです。このステップでは、どちらの当事者も相手の身元を証明する前に、クライアントとサーバーが共有秘密について合意します。レベル2は、サーバーの身元確認までのすべてをカバーする、クライアントのハンドシェイク・トラフィック鍵に紐付けます。最も強力で、実運用上最も重要となるレベル3は、接続が確立された後にクライアントが送信する機密データの暗号化に実際に使われるアプリケーション・トラフィック鍵そのものに、エビデンスを紐付けるものです。
Sardar氏によるProVerifを用いた広範な解析は、イントラ・ハンドシェイク・アテステーションに焦点を当てたものであり、ハンドシェイク後のアテステーションは対象範囲外でした。検証対象となった7種類の紐付けメカニズムのうち、レベル1を達成しているのは3種類のみで、残りはこの最低基準すら満たしていません。
同氏のチームが独自に提案する緩和策、すなわちTLSハンドシェイクシークレットとサーバーの公開鍵を組み合わせて構築する暗号学的バインダーは、形式的にはレベル2を達成しています。しかしレベル3については、論文の結論によれば、現行のアーキテクチャのイントラ・ハンドシェイク・アテステーションの範囲内では「達成できない可能性がある」とされています。これは、TLS 1.3がそもそも手放すことを想定していなかった特性を破壊しない限り、達成できないということです。
平易に言えば、現時点で利用可能な最良の修正策でも、証明できるのはハンドシェイク開始時点でクライアントが正しいマシンと通信しているということだけです。それから数分後に送信されるデータが、依然として同じマシンに送られていることまでは証明できないのです。
実運用システムであり、実験室のプルーフ・オブ・コンセプトではない
この脆弱性は、学術的なモデルにとどまるものではありません。Sardar氏のチームは、イントラ・ハンドシェイク・アテステーションを実装した4つの実運用システムを形式的に解析しました。対象は、WhatsApp向けのMeta社のPrivate Processingシステム、Edgeless SystemsのContrast、オープンソースのCocos AIプラットフォーム、そしてコンフィデンシャル・コンピューティング・コンソーシアム(CCC)のAttestation Special Interest Groupが維持するプルーフ・オブ・コンセプトの4つです。このうち3つは、現在すでに実運用で稼働しています。今回の攻撃は、Cocos AIのバージョン0.4.0から0.8.2までのすべてのバージョンに適用されます。この種の欠陥自体は目新しいものではありません。Sardar氏のチームは、形式的解析によって発見されるまで、これらの攻撃は何年もの間見過ごされてきたほど巧妙なものだったと指摘しています。
この責任ある開示の結果、CVE-2026-33697が発行され、共通脆弱性評価システム(CVSS)で7.5、深刻度「高」と評価されました。比較のために挙げると、研究者らは論文の中で、AMDのSEV-SNPを対象とした2024年のメモリエイリアシング攻撃であり、それ自体が大きく報じられた「BadRAM」のスコアが5.3だったと指摘しています。CCC Attestation SIGのリポジトリでは、CVE-2026-33697は、Fabricked(5.9)、BreakFAST(5.9)、Staleus(4.0)を上回り、最近発見された一連のコンフィデンシャルコンピューティングの欠陥の中で最もスコアの高い脆弱性として掲載されています。
同ワーキンググループとIETFのTLSワーキンググループはいずれも、このリレー攻撃を正式に認めています。「現状の実装では、Attested TLSはまだ成熟したものとは言えません」とSardar氏はThe Registerに語りました。「私たちはさらに調査を進めており、今後さらに問題が発見されるだろうと確信しています」。
この発見をより際立たせているのは、最初にこれを見逃したのが誰だったかという点です。Metaは、Sardar氏のチームが検証する前に、定評あるセキュリティ企業Trail of Bitsに依頼し、WhatsApp実装について広範なセキュリティレビューを実施していました。しかし、そのレビューではこのリレー攻撃は検出されませんでした。
このギャップを説明するのは、能力不足ではなく手法の違いです。ESORICSの論文には、Sardar氏のチームがTrail of Bitsに直接連絡を取ったところ、同社はレビュー過程で形式手法を一切用いていなかったことを認めた、と記録されています。ProVerifのような形式検証ツールは、定義された脅威モデルが許容するあらゆるシナリオに対して、プロトコルを網羅的にチェックします。一方、手作業による監査は、どれほど徹底していてもサンプリングにすぎません。エビデンスが接続にどう紐付けられるかという微妙な欠陥は、サンプリングによるレビューをすり抜けてしまう一方で、網羅的な形式解析の下では確実に破綻していることが証明され得るのです。
Sardar氏がテストした採用済みのプルーフ・オブ・コンセプト・プロジェクトを管理するCCCのAttestation Special Interest Groupは、自らのシステムが同じリレー攻撃に対して脆弱であることを発見しました。
誰も作ろうとしなかったリポジトリ
この脆弱性自体は、すでに長期にわたる整然とした開示プロセスを経ていました。Sardar氏のチームは2025年10月にCocos AIにこの問題を報告し、ベンダーは2カ月後にこれを認め、CVEは2026年3月に公開されました。
しかし、その後に起きたことは違っていました。
6月14日、Sardar氏はCCCのAttestation Special Interest Groupの議長らに書面を送り、relay-attacks-in-intra-handshakeという名称の新しいGitHubパブリックリポジトリを作成するよう依頼しました。これは、研究者や標準化コミュニティが利用できるよう、リレー攻撃に関する自身の形式解析の成果物をApache 2.0ライセンスの下で公開するためのものでした。同氏は、同グループのガバナンス下にある既存の採用済みプロジェクトを引き合いに出しており、これは書類上は数分で済むはずの事務手続きにすぎませんでした。
その3日後の6月17日、同氏はリマインダーを送りました。翌日には2通目のリマインダーを送り、論文の最終版のためにこの成果物へのリンクが必要であることを伝えました。最初の依頼から10日後となる6月24日、同氏は再び書面を送りましたが、今度は外交的な言い回しを省いた内容でした。「これほどの遅延に正当な理由があるとは思えません。依頼したリポジトリは採用済みプロジェクトの一部であり、新規リポジトリの作成にそれほど時間がかかるはずがないからです」。それでも、新しいリポジトリは依然として作成されませんでした。
CCCのAttestation Special Interest Groupは、リレー攻撃に対して脆弱であることが示された4つのシステムのうちの1つである、CCC自身のプルーフ・オブ・コンセプト・プロジェクトを管理する立場にあります。この事実には、何の脚色も必要ありません。このプロジェクトを監督するグループは、自らに影響する同じ脆弱性の証拠を公開するという依頼に対し、1週間以上にわたり、3度の書面によるリマインダーを受けてもなお、行動を起こさなかったのです。
論文の最終版が出版社に送られるまでに新規リポジトリが作成されなかったため、Sardar氏はそれでも成果物を公開しました。ただし、依頼していた専用リポジトリではなく、既存のCCC関連リポジトリの中に公開する形をとりました。同氏はThe Registerに対し、そのリポジトリはもともと無関係な別のプロジェクト用に作られたものだったと説明した上で、こう語りました。「(このインフラをめぐるベンダー主導のワーキンググループによる)独占状態が続いているため、私たちはコミュニティに周知し、研究者が独自に分析できるよう、成果物を公開することにしました」。
CVEはそれとは関係なく、正式にクレジットされ公開された状態にあります。この遅延は、根底にある数学的事実を何ら変えるものではありません。
BSIも同じ結論に到達
これらすべては、Sardar氏の解釈を鵜呑みにする必要のあるものではありません。IETFのメーリングリストとは全く別の場所で、ドイツ連邦情報セキュリティ庁(BSI)も、独自の完全に別の経路を通じて、これと近い結論に到達しています。
BSIの広報副担当者であるCarina Hilt氏は、デジタル主権におけるコンフィデンシャルコンピューティングの役割について直接質問を受けました。同氏はThe Registerに対し、この技術は「多層防御の一要素」として機能し、テナント分離を強化し、機密性と完全性を保護するものの、可用性は保護しないと述べました。さらに重要な点として、同氏は「アイデンティティ管理や鍵管理といった他のサービスへの依存についても、コンフィデンシャルコンピューティングによって緩和されるわけではない」と付け加えました。
言い換えれば、これはSardar氏のプロトコル解析が明らかにしたのとまさに同じギャップを、制度的な立場から裏付けるものです。コンフィデンシャルコンピューティングが保証する範囲は、実際に鍵やアイデンティティ基盤を誰が管理しているかを保証するには遠く及ばないということです。あるデプロイメントがそれらのアイデンティティ・鍵管理基盤に依存している以上、その保証はそこで止まってしまいます。
ベンダーのマーケティング上の主張についてさらに追及されても、BSIは姿勢を緩めませんでした。「ベンダー各社によるコンフィデンシャルコンピューティングの位置づけは、その技術的能力を過大に評価している可能性があります」と同担当者はThe Registerに語りました。「コンフィデンシャルコンピューティングだけでは、デジタル主権の要件を満たすことはできません」。
チップメーカー各社の見解
インテルのフランス広報担当マネージャーであるMikael Moreau氏は、同社のTDXコンフィデンシャルコンピューティング技術を支えるアテステーション基盤について、そしてそのインフラにおけるインテル自身の役割が一種の依存関係を構成するのかどうかについて、具体的に質問を受けました。同氏は、同社は「自社のアテステーション基盤が主権保証に対する制約になるとは考えていない」と述べ、インテルのシリコンおよび証明書のルート・オブ・トラストへの依存はあくまで「限定的なもの」だと主張しました。インテルは顧客のワークロードのデータパスには関与しておらず、アテステーションを通じて顧客の平文データを受け取ることもなく、運用上の信頼判断は独立した検証者に委任することも、顧客自身が保持することも可能だとしています。
これは、慎重に組み立てられた、技術的には筋の通った回答です。しかし、それが説明しているのはアーキテクチャであって、法律の問題ではありません。インテルは、2024年に成立した米国法であるRISAA(ハードウェアメーカーに対し、秘密裏の情報機関からの命令への協力を強制し得る法律)の下で、同社のアテステーション基盤が主権上のリスクをもたらすかどうかについて質問を受けていました。この質問に対する回答は得られませんでした。
Googleは、本記事についてのコメント依頼に応じませんでした。
あらゆる場面で認められているのに、営業トークだけは別
Sardar氏の発見は、制度的に4つの異なる対応を引き起こしました。
Sardar氏を含むグループが2025年7月、マドリードで開催されたIETF 123のBirds of a Featherセッションで説得力ある主張を行った結果として発足したIETFのSecure Evidence and Attestation Transport(SEAT)ワーキンググループは、同氏が定めた相関性に関する特性を、新規の仕様策定作業に対する明示的かつ必須の要件として、そのまま憲章に書き込みました。これはまさに、標準化団体があるべき対応をとった例であり、形式検証を後付けするのではなく、プロセスそのものに組み込んだ形です。
IETFのTLSワーキンググループも同じ攻撃を正式に認めましたが、自らの拘束力ある要件としては採用しませんでした。CCCが10日間にわたり行動を起こさなかったため、Sardar氏はワーキンググループの助けを借りることなく、自らこの証拠を公開する結果となりました。
そうした動きは、いずれも営業上の会話にまでは及んでいません。インテルとGoogleは今なお、コンフィデンシャルコンピューティングを、主権が守られ検証済みの保護の証しとして売り込み続けています。その主張を支える基盤について直接質問されたインテルの回答は、その中核にある法的な問いには踏み込みませんでした。Googleに至っては、まったく回答すらしませんでした。
欧州のCIOや調達担当者にとって、これは通常問われる問い以上の疑問を投げかけるものです。もはや問題は、どの企業がクラウドを所有しているか、あるいはどの政府がどのハードウェアメーカーに命令を強制できるか、だけではありません。ワークロードが主張どおりの場所で稼働していることを証明するはずの暗号学的なハンドシェイクが、そもそも信頼できるものなのかどうかが問われているのです。
タイミングの問題が排除するレベル
Sardar氏自身の緩和策が達成できるのはレベル2までです。データの送信が始まった後もワークロードが依然として保護されていることを検証しようとする顧客にとって、実際に重要となるレベル3は、エビデンスがハンドシェイク自体の最中に生成される現行のイントラ・ハンドシェイク・アテステーションのアーキテクチャの下では、そもそも達成不可能かもしれません。問題はタイミングにあります。レベル3を達成するには、エビデンスを実際のアプリケーションデータを暗号化する鍵に紐付ける必要がありますが、その鍵が存在する時点では、TLSプロトコル自体を大幅に変更しない限り、エビデンスはすでに送信済みになってしまっているのです。ハンドシェイク後のアテステーションであれば、その時点を過ぎてから行われるため、紐付け対象となる鍵がすでに存在している状態になります。
「ハンドシェイク後のアテステーション単独であれば、レベル3の紐付けを達成できると私たちは考えています」とSardar氏はThe Registerに語り、両方式を組み合わせるとする新しい提案は、セキュリティを高めることなく不要な複雑さを加えるだけだと警告しました。同氏がIETFのTLSワーキンググループに向けて出す提言は率直です。開発者は、イントラ・ハンドシェイク・アテステーションを完全に放棄すべきだ、というものです。®
