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