原文
Physical integrity, attestation, and the state of permissionless TEEs — fnerdman (2026-05-26)
私はかつて、「Web3のトラステッド実行環境 (TEE) プロジェクトに10億ドルを預けることができるか」と尋ねられたことがあります。Googleのデータセンターにある単一のトラステッド実行環境 (TEE) ではなく、分散型トラステッド実行環境 (TEE) ネットワークに対してです。私の答えは「ノー、しかしそこには到達できると信じています」でした。そのためには、トラステッド実行環境 (TEE) のパーミッションレス性と分散化の両方を解決する必要があります。つまり、ハードウェア自体が物理的に侵害される可能性がある場合でも、トラステッド実行環境 (TEE) システムを誰にでも開かれたものにし、かつ安全に保つことです。これは、私が2024年から行ってきた作業、会話を変えた最近の物理攻撃、そして今日利用可能なプロバイダーごとの評価に基づいて、現状を考察したものです。私は[Ritual]で働いており、トラステッド実行環境 (TEE) を使用する分散型L1を構築しています。ここで説明するすべては、私たちにも当てはまります。
1. これまでの取り組みと現状に至る経緯
トラステッド実行環境 (TEE) のアテステーション（証明）には、Web3コミュニティのほとんどが無視してきた構造的なギャップがあります。私は2024年半ばからこのことについて書いてきました。
2024年6月、私はFlashbotsフォーラムに[TEE Engineering Part 1]を公開しました。その論文の主張は、クラウド・アテステーションは、直接的なハードウェア・アテステーションを、不透明なハイパースケーラー（hyperscaler）の検証サービスへの信頼に置き換えるというものでした。Microsoft Azure Attestationは独自のブラックボックスです。あなたは独立して検証可能なハードウェアの主張ではなく、彼らの署名を信頼することになります。私はクラウド・アテステーションが実際に提供するものを「データセンター実行保証 (Data Center Execution Assurance)」と呼びました。これは、トラステッド実行環境 (TEE) がクラウドプロバイダーの物理的に保護された環境内で実行されており、誰かのサイドチャネルラボではないという声明です。
その投稿は、今振り返ると2025年に起こったすべてのチェックリストのように読める「今後の作業」セクションで締めくくられていました。他のプロバイダーからの代替クラウド・アテステーションの確認、再現可能なビルドによる監査可能なアテステーションの要求、データセンター実行保証のためのオープンソースツールチェーンの研究、そして「Proof of Cloud」の開発 — プロバイダーがサポートしていなくても、エンクレーブがクラウドオペレーターに関連付けられていることを証明できるというアイデアです。これらの項目はすべて2025年の議論に登場しました。Google Cloudのアテステーションは、TDXやSEV-SNPに対する実際のオペレーターの保証がないことが判明しました。GCPのファームウェアに対する再現可能なビルドの要求は、Googleの内部OVMFフォークがアップストリームのedk2とは異なる独自のツールチェーンで構築されており、誰もその作業を引き継がなかったため、進展しませんでした。データセンター実行保証の正式な学術的扱いは、[DCEA paper]となりました。[Proof of Cloud]は、同じ問題に対する別の証人ベースのアプローチとして出荷されました。
2024年11月、私は[TEE.salon Bangkok](https://collective.flashbots.net/t/tee-salon-bangkok-11-10-2024/4060)で[[「Where you run your TEEs matters」](https://youtu.be/VO4HkFYBBfY)]と題した講演を行いました。この講演では、クラウド・アテステーションが不十分であること、物理的なトラステッド実行環境 (TEE) のセキュリティが脆弱であること、そしてパーミッションレスなトラステッド実行環境 (TEE) システムには現在のスタックが提供するもの以上のものが必要であると主張しました。講演後、Googleの従業員やエコシステムの他の人々が参加するワーキンググループが招集され、DCAPアテステーションの改善を推進しました。しかし、私たち数人が他の仕事に移ったため、その作業は立ち消えになりました。
これらは予測ではありませんでした。構造的な弱点は目に見えていました。2025年に変わったのは、それらを悪用するためのハードウェアが誰かによって構築されたことです。
ほとんどすべてのトラステッド実行環境 (TEE) の議論で、3つのことが混同されています。以下の内容を理解するためには、これらを区別する必要があります。
- 機密実行 (Confidential execution): メモリ暗号化とハードウェア分離。AES-XTS、SGXエンクレーブ、TDXトラストドメイン、SEV-SNP。
- 測定とアテステーション (Measurement and attestation): 実行されているソフトウェアと構成の暗号学的証明。
- カストディと物理的完全性の保証 (Custody and physical integrity endorsement): アテステーションチェーンに組み込まれるか、またはそれに付随する検証可能な声明で、2つのことをカバーします。カストディ（誰が物理的にハードウェアを制御しているか）と物理的完全性（ハードウェアが改ざんから保護されているか）です。この記事全体を通して、「保証 (endorsement)」はこのレイヤーを指します。
レイヤー1と2はCPUベンダーが提供するものです。レイヤー3は、この記事全体が扱っている内容です。2025年以前は、検証されたアテステーションチェーンが物理的完全性を暗黙的にカバーしていると主張できました。測定値が一致すれば、プラットフォームは密かに偽装されることはなかったからです。その主張はもはや通用しません。
2. 何が壊れたのか
2025年9月と10月、2つの関連する攻撃が、サーバーへの物理アクセスと約1,000ドルの機器があれば、Intelのアテステーションチェーンから署名キーを抽出し、標準的なDCAP検証を通過する偽のアテステーションクォートを偽造できることを示しました。
[WireTap]（2025年9月30日公開; [論文]）はDDR4ベースのIntel SGXを標的にしました。1,000ドル未満のハードウェアと45分未満の時間で、Intelの[DCAP Quote Verification Library]によって検証されるSGXクォートを偽造できる署名キーを入手しました。彼らは4つのWeb3ネットワーク[1][2][3][4]に対して攻撃を実証し、Secret Networkのテストネットワークに偽造されたアテステーションで参加し、コンセンサスシードを受け取りました。論文の明確な推奨事項は、「任意のエンティティが信頼できるノードとして参加することを許可せず、信頼できるステータスを得るためにはさらなる許可を要求することを推奨します」というものでした。これは、文字通り、パーミッションレスなトラステッド実行環境 (TEE) ネットワークへの参加に反対する議論です。
[TEE.fail]（2025年10月28日公開; [論文]）はこれをDDR5とIntel TDXに拡張しました。これは、第4世代Xeon Scalable以降に出荷されたすべてのTDX対応CPUを意味します。コストは同じ。約15分。彼らは、Intelの最高信頼レベルであるUpToDateで検証される、意味不明な測定値を持つTDXクォートを偽造しました。彼らは、非プロダクションの[Flashbots BuilderNet]インスタンスと、テストネット上の[Automata]のオンチェーンDCAP検証に対して実証しました。
Intelの立場: 物理バスの割り込みは[明示的に範囲外]です。CVEなし。メモリ暗号化エンジンは[マイクロコードでは修正できません]。AMDの立場: [範囲外]（AMD-SB-3040）です。ファームウェアアップデートの予定はありません。
これはハードウェアレベルの物理攻撃です。ソフトウェアのサイドチャネル攻撃やマイクロアーキテクチャの脆弱性は、マイクロコードアップデートやTCBリカバリによってパッチを適用できます。物理バスの割り込みはできません。この脆弱性はハードウェアの寿命が尽きるまで持続します。
3. 物理的セキュリティ: 私たちが間違っていること
私たちのほとんどはソフトウェアネイティブです。物理的セキュリティに関する専門的な直感を持っていません。物理攻撃に対する私たちのメンタルモデルは、個人に対する5ドルのレンチ攻撃か、エージェントがレーザーグリッドを迂回して金庫に侵入するスパイ映画のどちらかです。どちらも、データセンターが実際にどのように機能するかを代表するものではなく、このトピックを評価する方法を形作ります。
しかし、ハイパースケーラーのデータセンターにおける物理的セキュリティにはフィクションはありません。それは現実的で実質的なものです。[Googleのデータセンターがセキュリティの観点から実際にどのように見えるか]をご覧ください。武装警備員、生体認証アクセス制御、24時間365日の監視、6層の物理アクセス制御、そして廃止されたストレージメディアの物理的破壊。AmazonとMicrosoftも同等の施設を運営しています。ランダムな攻撃者がGCPデータセンターに侵入し、DIMMにインターポーザーを取り付け始めることはできません。これは意味のあるセキュリティ特性です。
しかし、[TEE.fail]の[ブリーフケース]は、攻撃コストを1,000ドル、攻撃時間を15分と見積もっています。データセンターの物理的セキュリティだけが、そのブリーフケースとあなたのアテステーションキーの間に立ちはだかっています。もし誰かが[物理アクセスを得た場合] — たとえ短時間であっても、たとえ内部犯を通じてであっても — 攻撃は安価で迅速です。セキュリティ保証は、データセンターが不正な物理アクセスを防ぐことに完全に依存しています。これはほとんどの脅威モデルにおいて依存するに足る合理的なことであり、物理的セキュリティを無価値と見なすのではなく、そのことを認識することが重要です。
物理攻撃はステルススペクトラム上に位置します。[TEE.fail]のようなハードウェアインターポーザー攻撃は騒々しいものです。誰かが機器を入手し、武装警備員と生体認証を突破し、稼働中のシステムにそれをインストールし、データを取得する必要があります。これは、何が起こっているかを知っている人々の連鎖であり、痕跡や内部告発者なしに実行するのは困難であり、ハイパースケーラーの物理的セキュリティは各ステップのコストを上昇させます。より静かな側は、構造的な批判が効いてくる場所です。国家安全保障書簡（National Security Letter, NSL）を持つ誰かは、クラウドプロバイダーの法務チームを通じてすべてを入手する可能性が高く、物理的に現れる必要さえなく、顧客はそれが起こったことを決して知りません。測定されていないACPIテーブルや侵害されたファームウェアビルドパイプラインを通じたソフトウェアレベルの攻撃も同じ静かな側に位置します。特権アクセスを持つ単一の悪意のある内部犯によって実行される可能性があります。
国家安全保障書簡（National Security Letter, NSL）は、米国政府が記録を要求するもので、箝口令が組み込まれています。クラウドプロバイダーは顧客にその要求の存在を伝えることができません。米国政府は[2023年に11,000件以上のNSLを発行しました]。これらは日常的なものであり、例外的なものではありません。
トラステッド実行環境 (TEE) のワークロードにとって、強制アクセスによる脅威には2つの要素があります。第一に、クラウドオペレーターはハイパーバイザー、ファームウェアパイプライン、ネットワーク、およびトラステッド実行環境 (TEE) 周辺のI/Oチャネルを制御します。強制されたオペレーターは、その環境を計測して、転送中、I/O境界、またはファームウェアアップデートパイプラインを通じてデータをキャプチャできます。トラステッド実行環境 (TEE) のメモリ暗号化はDRAM内のデータを保護することを意図していますが、オペレーターが制御するインターフェースを通じてデータが流れるのを防ぐことはできません。第二に、これは推測的ですが構造的に健全です。IntelとAMDは、プロビジョニングセレモニーに必要であるため、出荷するすべてのCPUのルートキーマテリアルをほぼ確実に保持しています。CPUベンダーへのNSLは、プラットフォームごとの署名キーの開示を強制する可能性があります。中間者攻撃の位置（クラウドオペレーターから）とCPUルートキー（ベンダーから）の両方があれば、暗号化されたデータと暗号化キーの両方が同じ手に渡るため、トラステッド実行環境 (TEE) の完全なセキュリティモデルは崩壊します。どちらか一方だけでは不十分ですが、オペレーターが手の届く範囲にいれば、両方とも法的手続きを通じて達成可能です。
これはグローバルに悪用可能です。インフラストラクチャとすべての通信経路が、NSLに相当するものを発行するエンティティの管轄下にある場合、その特定の管轄下で実行されているノードのトラステッド実行環境 (TEE) のセキュリティ保証は侵害されると予想しなければなりません。すべてのノードが平等に扱われ、機密データへの完全なアクセス権を持っている場合、オペレーターの管轄区域の多様性だけでは適切な緩和策にはなりません。1つの管轄区域が侵害されれば十分です。このような脅威モデルでは、MPCラッピングなどの追加のデータ断片化対策を講じる必要があります。
トラステッド実行環境 (TEE) システムは、オペレーターの多様性の下で反対の挙動を示す2種類の保証を提供します。完全性 (Integrity) の保証は積み重なります。同じワークロードをN人のオペレーターで実行し、1人の正直なオペレーターが結果の不一致を検出すれば、問題を示すのに十分です。多様性が増えるほど、より堅牢になります。機密性 (Confidentiality) の保証は逆です。秘密を保持する各オペレーターは、別の単一障害点となります。多様性が増えるほど、より脆弱になります。これをMPCでパッチ適用すると、積み重ねの特性は回復しますが、グローバル分散の前提に反するレイテンシ、スループット、ネットワークトラフィックに実際のコストがかかります。
そのため、パーミッションレス性は分散化ではありません。パーミッションレス性は分散化の前提条件です。システムはプロトコルにおいてパーミッションレスであることができます — 誰でもノードを立ち上げることができます — しかし、ホスティングにおいては集中化されている可能性があります。米国のGCP TDX VMで実行されているすべてのノードはパーミッションレスですが、運用上は集中しています。逆は成り立ちません。招待リストによってゲートされているネットワークは、ゲートキーパー自体が制御のポイントであるため、真に分散されているとは言えません。この記事はパーミッションレス性についてです — 誰でも有効な保証付きアテステーションを生成し、参加できることです。分散化は完全性/機密性の線に沿って分かれます。完全性については単純です — より多くの管轄区域にわたってより多くのオペレーターが同じワークロードを実行すれば、保証はより強力になります。機密性については、上記の二重の対立に直面します — より多くのオペレーターは機密性を直接破り、標準的なパッチ（MPC）はグローバル分散に反するコストを伴います。その二重の対立の下で、機密性の高い分散型トラステッド実行環境 (TEE) システムを実際に構築する方法は、それ自体がエンジニアリングの問題であり、ここでは範囲外です。以下の議論が管轄区域の多様性に触れる場合、それは関連する文脈として扱い、解決策として扱わないでください。
4. 現在のツールキット
以下のプロバイダー分析は、SGXエンクレーブではなく、機密VMデプロイメント（TDX、SEV-SNP）に焦点を当てています。SGXはWireTapの議論で言及されていますが、ここでは主題ではありません。
GCP: 最も利用され、最も露出しており、修正に最も近い
GCPは、ほとんどのハイパースケーラーWeb3トラステッド実行環境 (TEE) プロジェクトが実行されている場所です。Web3に特化したチームがコミュニティと真剣に関わり、独自の認証プロトコルではなく、バニラのIntel TDX DCAPに基づいたツールを提供しているため、この状況に至りました。これらは真の強みです。
問題点: GCPはTDXやSEV-SNPに対して、暗号学的にオペレーター署名されたカストディ声明を持っていません。GCPの機密VMからTDXクォートを検証する際、ハードウェアが純正のIntel TDXであり、ファームウェアの測定値が期待される値と一致することを確認します。VMがGoogleのインフラストクチャ内で実行されていたことを検証するわけではありません。ハードウェアのIDをGoogleの物理環境に結びつけるGoogleの署名はありません。
人々が真のカストディ声明と誤解するかもしれない機能があります。Googleはファームウェアバイナリを公開し、その測定値をgce-tcb-verifierを通じて署名しています。これにより、CVMで実行されているバイナリがGoogleがデプロイしようとしたバイナリであることを検証できます。これは何も提供しないよりはるかに進んだステップです。しかし、そのバイナリのソースコードは公開されていません。ビルドは再現可能ではありません。Googleの内部OVMFフォークは、[アップストリームのedk2とは異なる]独自のツールチェーンで構築されており、アップストリーム自体も非決定的なビルドです。そのため、ファームウェアは検査可能ですが、独立して監査することはできません。バイナリを見ることはできますが、リバースエンジニアリングなしにそれが何をするかを検証することはできません。
そして、私はそのバイナリを自宅の地下室のラボで実行できます。GoogleはOVMFバイナリをGCSバケットで公開しています。私はそれを1つ取得し、QEMUで起動すると、結果として得られるTDXアテステーションはGCPデータセンターのものとまったく同じに見えます。なぜなら、アテステーションには「これはGoogleから来たものだ」という記述がないからです。署名も、保証も、ハードウェアのIDとGoogleの物理インフラストラクチャの結合もありません。
透明性対策としてバイナリを公開することが不完全に感じるなら、それはその通りです。この推進のほとんどは、[Dionna Glaze]という一人の人物によるものでした。彼女のCCC TACミーティングでのUEFI透明性に関するプレゼンテーションを見ると、アテステーション付きビルドや、ある時点でのソース公開など、さらに多くの計画があったことがわかります。問題は、彼女が2025年に[GoogleからAppleに移籍した]ことです。退職前に、彼女は現状を文書化しました。
- GoogleのOVMFフォークは[ソースとして公開されておらず]、内部ツールチェーンで構築されており、再現可能ではありません。
EV_POST_CODEイベントは[意図的にPCR0に測定されていません]。これによりGoogleは再起動時にファームウェアとACPIテーブルを変更できます。- ACPIテーブルのダイジェスト署名は[行われていません]。
ACPIテーブルに関する最後の点は、[BadAML]（ACM CCS 2025、[BlackHat Europe 2024]でプレビュー）のために重要です。ホストが提供するACPIテーブルは、ゲストカーネルが任意の物理メモリ読み書き（プライベートな暗号化されたページを含む）で実行するAMLバイトコードを運びます。[Edgeless SystemsはこれをベアメタルSEV-SNPでエンドツーエンドで再現しました]。GCPでは、ACPIテーブルは[測定されていないFwCfgインターフェース]を通じて提供され、GCPは署名されたACPI参照値を公開していません。Intel TDXのTDVFは、正しく構成されていればインストールされたACPIテーブルをRTMR[0]に測定しますが、GCPの構成ではそれらの測定値に署名していません。
つまり、これらすべてが意味するのは、GCPはブートファームウェアを介して任意のトラステッド実行環境 (TEE) に簡単にバックドアを仕込むことができ、たとえオープンソース化して再現可能なビルドを追加したとしても、ACPIテーブルに署名しないことで、そのバックドアをより不透明な方法で再導入することになるということです。また、次のように捉えることもできます。署名されたファームウェアバイナリが良性であったとしても、ACPIテーブルを介して署名されていないバックドアをオンデマンドでサイドロードできるのであれば、そのファームウェアバイナリは何の役に立つのでしょうか。
Dionnaは、今日の機密コンピューティング技術の真の価値提案について、引用する価値のあることを述べています。「[ホストを信頼境界から外すという機密コンピューティングの脅威モデルは悪いものです。いかなるセキュリティレイヤーも防弾ではありませんでした。CCは、顧客データの強制開示を技術的に高価にするためのものです…1人の内部告発者が数十億ドル規模のビジネスを破壊するような、顧客から盗むよう誰かにいつでも命じることは、ビジネス上意味がありません。]」この枠組みは正直であり、データセンターの物理的セキュリティが実際に提供するものです。経済的コストの議論は、特定の法的およびビジネス体制に依存します。それは単一のCSP-管轄区域のペア内では有効ですが、異なる法的文脈にあるノードにはきれいに翻訳されません。私たちの困難は、データセンターの物理的セキュリティを信頼することが、意味のある完全性を持ってトラステッド実行環境 (TEE) を使用するために現在利用可能な最も実用的なアプローチであることを受け入れることです。
Googleは、顧客のコンテナ（任意のVMではない）を実行し、Google署名付きのOIDCアテステーション・トークンを生成するマネージドPaaSであるConfidential Spaceを提供しています。アーキテクチャ的には、これはAzureと同じ形です。独自のクラウド検証者（Google Cloud Attestation）がハードウェアクォートを評価し、クレームトークンを発行します。パーミッションレスなトラステッド実行環境 (TEE) システムにとってConfidential Spaceは役立ちます。Google署名付きトークンはオペレーターの保証として機能しますが、ワークロードはコンテナに制約されます。
GCPについて批判の中で見落とされがちな点があります。GCPは、3つのハイパースケーラーの中で、クリーンなパーミッションレス性のストーリーを持つことに最も近い存在です。彼らはバニラのIntel TDX DCAPに基づいて構築しています。アテステーションを独自のレイヤーでラップしていません。Intelは、[Platform Ownership Endorsement (PoE)]を公開しました。これは、すべてのDCAPクォートに既に存在するPIIDを使用して、オペレーターが特定のCPUのカストディを暗号学的に署名するための標準化されたメカニズムです。GCPがPoEを採用すれば、バニラのDCAPアテステーション（既に存在）に加えて、Google署名付きのオペレーター保証（PoE）、そして両方のオンチェーン検証可能性（DCAPは[Automata]を通じて既にオンチェーン）が得られます。この組み合わせは、どのハイパースケーラーよりも実際に強力になるでしょう。Azure（独自の認証が複雑すぎて直接オンチェーン検証できない）よりも強力であり、Nitro（CPU機密コンピューティングの意味でのトラステッド実行環境 (TEE) ではなく、単一オペレーターにロックされている）よりも強力です。GCPが現状から必要とされる状態になるまでのギャップは技術的に小さいです。PoEを採用し、内部のprotobufベースの測定インフラストラクチャをIntelのCoRIM形式にブリッジし、PIIDに署名するだけです。このブリッジング作業はDionnaが退職する前に進行中でしたが、その後静かになりました。この記事の執筆時点では、PPIDを介した内部結合作業が進行中であり、おそらく第2四半期末までに完了する予定です。Googleは、顧客が独自のソフトウェアスタックを持ち込めるベアメタル機密コンピューティングオプションを提供しています。進行中の作業がGoogle固有の結合としてのみ完了するのか、それともIntel PoEも統合されるのかはまだ不明であり、ベアメタルオプションにオペレーター保証が含まれるかどうかも不明です。
Azure: 保証はあるが、他すべてを困難にする
AzureはTDXとSEV-SNPを[パラバイザー (OpenHCL/OpenVMM)]でラップし、ネストされた仮想化を使用しています。TDX MRTDはMicrosoftのパラバイザーバイナリを測定し、ゲストOSは測定しません。ゲストのブート測定値は、パラバイザーがトラストドメイン内で管理するvTPM PCRを介して提供されます。Azureはその後、[Azure Virtual TPM Root Certificate Authority 2023]にルートを持つ[AK証明書チェーン付きのvTPM]を提供します。このAKチェーンはオペレーターの保証です。つまり、「これはAzureで実行されている」と述べています。これはGCPがTDX/SEV-SNPで持っていない唯一のものです。しかし、その下のハードウェアアテステーションは、あなたのコードではなくMicrosoftのコードをアテステーションしています。
したがって、保証で得られるものは、他のすべてで失われます。パラバイザーは不透明な独自のセットアップです。Microsoftは[オープンソース化しました]が、再現可能なビルドパスはなく、公開されたバイナリとアテステーションのリンクもなく、Microsoft自身の[FAQ]にはTDXブートアテステーションプロセスが[「ユーザーには不透明」]であると記載されています。実行中のパラバイザーが公開されたソースに対応していることを外部から検証することはできません。アテステーションチェーンは重厚です。デュアルPKI（IntelとAzure）、TPMクォート解析、イベントログ再生、Runtime Claims JSONの正規化、そしてreport_dataを介したクロスバインディング。直接的なオンチェーン検証は実用的ではありません。間接的な検証は2つの方法で可能です。1. Azureアテステーションを非Azureのトラステッド実行環境 (TEE) 内でオフチェーンで検証し、そのトラステッド実行環境 (TEE) をオンチェーンで検証する — しかし、これは独自の信頼仮定を伴う2ホップパスです。または2. [Microsoft Azure Attestation (MAA)]、Microsoftがホストする検証サービスによって発行されたJWTクレームのみをオンチェーンで検証する — しかし、これに取り組んだ人はいません。
Flashbotsにいた頃、私たちはWeb3のユースケースでAzureと繰り返し連携しようとしました。彼らは興味を示しませんでした。Azureはエコシステムが必要とする保証特性を持っていますが、Web3ビルダーがそれにアクセスできるようにすることには関心がないようです。
AWS Nitro: トラステッド実行環境 (TEE) ではないが、誰もが学ぶべきモデル
Nitroはハードウェアトラステッド実行環境 (TEE) ではありません。Intel/AMDの意味でのメモリ暗号化もハードウェア分離もありません。脅威モデルにAWSの内部犯による物理アクセスが含まれる場合、Nitroは役に立ちません。
しかし、3つのハイパースケーラーすべてがオペレーターの信頼を必要とすることを受け入れるなら — 実際そうなのですが — Nitroは最もクリーンなモデルです。Nitroアテステーションは、単一の[CBORエンコードされたCOSE署名付きドキュメント]です。AWSルートへの単一の署名チェーン。それを検証し、測定値をチェックすれば完了です。デュアルPKIも、イベントログ再生も、JSON正規化もありません。これが、Nitroアテステーションが直接オンチェーンで検証可能である理由（[BaseのSolidityバリデーター]、[Automataのライブラリ]）であり、オペレーターの保証と測定値の検証が単一のオンチェーンステップで行われる唯一のアテステーションである理由です。Azureはオペレーター保証付きのオンチェーン検証を達成できますが、トラステッド実行環境 (TEE) の仲介を介した間接的な方法のみです。GCPは直接オンチェーンDCAP検証を行うことができますが、オペレーター保証はありません。
Ritualで直接ぶつかった運用上の制限の1つは、Nitroエンクレーブのネットワーキングが親EC2インスタンスへのvsockを通じてボトルネックになることです。高スループットのワークロードは著しく劣化します。
ハードウェアの完全性とオペレーターのIDは、単一の信頼アンカーであるAWSに統合されています。これは検証の簡素さにとっては強みですが、分散化にとっては制限となります。Nitroアテステーションを発行できる唯一のエンティティはAWSだからです。
真の比較
今日、3つのプロバイダーすべてにおいて実用的な結果は同じです。つまり、オペレーターを信頼するということです。GCPのファームウェアは、監査できない署名付きバイナリです。Azureのパラバイザーは、実行中のアテステーションに結びつけられないオープンソースコードです。どれも、トラステッド実行環境 (TEE) で実際に何が実行されているかを独立して検証する手段を提供しません。Nitroはそれすら試みません。AWSが信頼のルートであり、それが取引であると最初から伝えています。
違いは現状ではなく、今後の道筋にあります。GCPは、独自のプロトコルをアテステーションチェーンに組み込まない点で際立っています。GCPは標準のDCAPを使用しているため、IntelのPoEメカニズムをきれいに組み込むことができます。Azureは独自のプロトコルを開発しており、この記事の執筆時点では、その道筋から外れる計画はないようです。Nitroは完全に異なるモデルであり、オペレーターへの信頼が確立されています。
Intel Platform Ownership Endorsement (PoE)
[Intel PoE]は、最も重要な近未来の開発です。これは、2024年のGoogleとのワーキンググループで提案され承認された、以前のIntelの提案を進化させたものです。その提案は、PPID（Platform Provisioning ID、すべてのDCAPクォートに含まれるCPUごとの識別子）をハードウェアとクォートの結合に利用するというものでした。PoEはPPIDをPIID（Platform Instance ID）に置き換えます。PIIDは、よりクリーンな失効特性を持つ関連する識別子であり、結合単独ではなく、その上にオペレーター署名付きの保証を追加します。
PoEは、プラットフォームオペレーターがIETFの[CoRIM形式]を使用してPIIDの保証に署名することを可能にします。この署名は、「このオペレーターがこのアテステーションを生成した物理プラットフォームを制御している」と述べています。これは、これまで欠けていたレイヤー3のプリミティブです。
工場出荷時リセットのセマンティクスは、post-TEE.failの復旧にとって重要です。SGXの工場出荷時リセットを実行すると、PIIDが再生成されます。古い保証は無効になります。古いIDの下での偽造されたクォートは、現在の保証に対する検証に失敗します。
PoEはオプトインであり、ツールは[まだ出荷されていません]。これが解き放つもの: OVH、OpenMetal、コロケーション施設などのあらゆるホスティングプロバイダーが、ハイパースケーラーと同等の立場でオペレーターのルートとして機能できるようになります。これにより、有効な物理的完全性の保証を生成できる関係者のセットが大幅に広がり、オペレーターの多様性への最も直接的な道筋となります。AMD SEV-SNPについては、同等のメカニズムは発表されていません。
Proof of Cloud
PoEがオペレーター署名付きの保証であるのに対し、[Proof of Cloud]は異なるアプローチを取ります。階層化されたアライアンス/レジストリです。現在、レベル1のみが稼働しており、特定のトラステッド実行環境 (TEE) ハードウェアが特定のプロバイダーの管理下にあることを人間が証人として検証します。仕様には、[DCEA論文]のvTPMクロスリンクアプローチを組み込んだ[レベル2の暗号学的階層]と、レベル3の継続的監視階層も記述されています。L2もL3も展開されていません。
このプロジェクトはまだ初期段階です。[ウェブサイト]はPhalaとNillionのバックエンドを介したアテステーションクォートの検証を受け付けていますが、[憲章]に記述されている追記専用の透明性ログである公開ハードウェアレジストリには、まだクエリ可能なインターフェースがなく、オンチェーン検証パスもありません。L1の人間証人モデルは、スケーリングしないCPUごとの検証を必要とします。しかし、これは単一オペレーターのPKIに還元されないカストディ保証レイヤーへの最初の試みです。[Secret、NEAR、Oasis、Nillion]は、[TEE.fail]への対応と並行して、共同のProof of Cloudの取り組みを発表しました。
PoEとProof of Cloudは、関連するが異なる問題を対象としています。PoEは、保証に署名する協力的なオペレーターを前提としています。Proof of Cloudは、オペレーター自身が保証に署名できない、または署名しないシナリオに対して関連する問題を解決します。PoCのL2仕様として採用されたDCEAアプローチは、ハイパーバイザー自体が悪意を持つ可能性がある設定をさらにターゲットにしており、オペレーターの署名とは独立してTPMクロスリンクを介してハードウェアIDを実行時状態に結合します。
大規模および中規模のホスティングプロバイダー
OVHは2024年に[ベアメタルTDX]を発表しました。これは、アテステーションチェーンに独自のファームウェアを含まない、最も初期のハイパースケーラー以外の提供でした。OpenMetalや同様のプロバイダーは、XEONハードウェアでTDXをサポートしています。
これらのプロバイダーは、パーミッションレスなトラステッド実行環境 (TEE) システムの自然な基盤です。直接的なハードウェアアクセス、ハイパースケーラーの抽象化レイヤーなし、管轄区域の多様性の可能性。しかし、現在、ネイティブなオペレーター保証を提供しているプロバイダーはありません。PoEがなければ、OVHサーバーからのTDXアテステーションは、攻撃者のガレージで生成されたものと区別できません。PoEがこれらのプロバイダーを実用的なものにするのです。
[dstack]上で動作するPhala Cloudは、これらの同じホスティングプロバイダーを基盤として使用していますが、PoEの採用を待つのではなく、[Proof of Cloud]を通じて保証のギャップを埋めようと取り組んでいます。今日のオペレーター保証のギャップは他の中規模ホストと同じですが、Phalaはそれを埋めるために取り組んでいるProof of Cloudの取り組みの背後にあるプラットフォームの1つです。
トラストレスなトラステッド実行環境 (TEE) ハードウェア
[Trustless TEE Initiative]は、長期的な答えです。Intel、AMD、またはクラウドオペレーターへの信頼を必要としない、オープンソースでコミュニティが製造するトラステッド実行環境 (TEE) ハードウェアです。キー抽出が物理的に不可能なPUFベースの署名ハードウェア（[UCLouvain/SIMPLE-Crypto]）、[IRIS]非破壊チップ検査を備えたオープンシリコン、そして[Fabric Cryptography]によって駆動される完全な次世代トラステッド実行環境 (TEE) です。これらは数年、数百万ドル規模の研究プログラムです。PUF署名者は4年間のプログラムです。次世代トラステッド実行環境 (TEE) は、実際の構築の前に実現可能性調査が必要です。これが完全なパーミッションレス性への唯一の道ですが、実現には何年もかかります。
Darkbloom
最近注目すべきプロジェクトは、[Darkbloom]（Eigen Labs）です。これはまったく異なるアプローチを取っています。コンシューマー向けApple Silicon Mac上で分散型AI推論を行い、サーバーグレードのトラステッド実行環境 (TEE) ハードウェアの代わりに、Secure EnclaveキーカストディとAppleのマネージドデバイスアテステーションを使用します。これが宣伝通りに機能すれば、夢にかなり近いものとなるでしょう。データセンターに依存せず、真に分散化されたパーミッションレスな参加を可能にするコンシューマーハードウェアです。しかし、現実は初期段階であり、制約があります。分離はソフトウェアベース（macOSの強化、SIP、Hardened Runtime、オプションのHypervisor.frameworkページテーブル）であり、ハードウェアメモリ暗号化ではありません。この記事で議論されているトラステッド実行環境 (TEE) 技術は、ハードウェアを使用して分離を強制しますが、Darkbloomはオペレーティングシステムを使用します。信頼レベルは、強化されたLinuxコンテナにホストから誰も侵入できないと信頼するのとほぼ同等です。方向は逆（マシン所有者からワークロードを保護するのではなく、ワークロードからホストを保護する）ですが、境界の強度は同じクラスです。コーディネーターはEigen Labsの下で集中化されています。[ソースは独自]（「All rights reserved」）であり、リポジトリにはコア技術の[仮特許ドラフト]が含まれており、再利用に関する意図は十分に明確です。
比較表
| プロバイダー | トラステッド実行環境 (TEE) 技術 | カストディ保証 | オンチェーンTEE検証 | オンチェーンカストディ保証 | PoE対応 |
|---|---|---|---|---|---|
| AWS Nitro | ハイパーバイザー（メモリ暗号化なし） | あり、オペレーター署名済み（アテステーションに統合） | 直接（Solidityで約63Mガス） | 直接（同じ署名） | 該当なし |
| Azure | パラバイザー + vTPM経由のTDX、SEV-SNP | あり、オペレーター署名済み（AK証明書チェーン） | DCAPのみ（約4-5Mガス）；複合的で直接ではない | 間接的（TEE仲介経由） | 複雑（独自の認証） |
| GCP | TDX、SEV-SNP（バニラDCAP） | なし | 直接（DCAP 約4-5Mガス） | なし（検証するものがない） | クリーンに適合（バニラDCAP + PIID） |
| OVH / OpenMetal | ベアメタルTDXまたはSEV-SNP | なし | 直接（DCAP） | なし（まだ） | 自然に適合 |
| Phala Cloud | dstack経由のTDX | あり、証人ベース（PoC、初期段階） | Automata DCAP経由 | なし（PoCにはオンチェーンパスがない） | あり（ただしPoCを追求中） |
5. エコシステムの対応
| パターン | ネットワーク | ステータス |
|---|---|---|
| 直接攻撃された | Secret、Phala、Crust、IntegriTEE (WireTap); BuilderNetラボ、Automataテストネット、Phala dstack (TEE.fail) | 移行済みまたはアローリストを追加 |
| Automataダウンストリーム | ElizaOS、Espresso、Puffer UniFi (TEE.fail論文で言及) | Automataから継承された露出 |
| BuilderNetクラスのブロックビルダー | BuilderNet、Unichain (Rollup-Boost経由) | 設計上パーミッション型、IPアローリスト |
誰も話したがらないことですが、[Automata]は、エコシステムのほとんどが依拠するオンチェーンDCAP検証インフラストラクチャを提供しています。[11のメインネットにデプロイされており]、Taiko、Flashbots、Uniswap、ElizaOS、Phala、Puffer、Espressoなどからコードレベルの統合があります。[TEE.fail]は、偽造されたクォートが彼らの検証を通過することを実証しました。[TEE.failの[論文]は、ElizaOS、Espresso、PufferのUniFiを、偽造クォート攻撃の下で「保証を失う」Automataに依存するプロジェクトとして挙げています。これらのインテグレーターのいくつかは、Automataの素の検証に追加の入札制御（MRENCLAVEアローリスト、IPゲーティング、スラッシングレイヤー）をラップしていますが、構造的な失敗は残ります。オンチェーンDCAPアテステーションはレイヤー1と2（ハードウェアアテステーションと測定）のみをカバーします。欠けているのはオンチェーンのレイヤー3検証です。入札決定が素のDCAP承認のみに依存している者は、この失敗モードを継承します。
これらの攻撃に対して対応を公表したすべてのネットワークは、生のアテステーション以外のオペレーター入札制御を既に持っていたか、後から追加しました。有効なアテステーションクォートだけで誰にでも開かれたままでいるとは、どのネットワークも言いませんでした。
誰もがパーミッション型に移行しました。あるいは、既にそうでした。
6. パーミッションレス性の実際の現状
トラステッド実行環境 (TEE) システムにおけるパーミッションレス性は、保証（endorsement）を使用すれば今日でも可能です。ただし、保証によってゲートされた参加が「パーミッションレス」と見なされるかどうかは、定義の厳密さによります。メカニズムは存在します。Intel PoEは、DCAP対応のオペレーターなら誰でも署名できる標準化された保証を提供します。AzureのAKチェーンは、Azureホスト型CVM向けのオペレーター保証を提供します。Nitroの統合アテステーションは、AWS向けのオペレーター保証を提供します。
AWSまたはAzureで実行されているシステムは、設計上すでに保証を持っています。Nitroの統合アテステーションとAzureのAKチェーンは保証です。ほとんどは、オープンな参加を可能にするためではなく、パーミッション型コンテキスト内でそれらを使用しています。初期の例外もあります。[Secret Networkのセミパーミッション型モデル]では、Azureホスト型ノードが[手動承認なしで参加できます]。Azureの署名が参加をゲートする保証として機能します。非Azureノードは依然としてホワイトリストまたはガバナンス投票が必要です。[Marlin Oyster]は、Nitro上でのパーミッションレスなオペレーターオンボーディングについて説明しています。これらは実際の進歩ですが、単一プロバイダーの保証者にロックされたままです。
これは完全なパーミッションレス性ではありません。保証を使用するということは、保証者を信頼するということです。完全なパーミッションレス性には、保証をまったく必要としないハードウェア、つまり物理設計自体がキー抽出を防ぐトラストレスなハードウェアが必要です。そのようなハードウェアは[Trustless TEE Initiative]によって研究されています。しかし、生産には程遠い状況です。
保証を通じた部分的なパーミッションレス性は今すぐ達成可能であり、再導入されるべきです。トラストレスなハードウェアを通じた完全なパーミッションレス性は、何年も先のことです。
7. 何が必要か
複数のホスティングプロバイダーが異なる管轄区域でノードを運用し、それぞれが検証可能なオペレーター保証を生成し、それがエンドツーエンドでオンチェーンで検証されるトラステッド実行環境 (TEE) ネットワークは、今日存在しません。それを妨げているもの、誰がその作業を行う必要があるか、そしてビルダーがその間に何ができるかを以下に示します。
誰かがEVM用のCoRIM PoE検証器を作成する必要があります。 DCAPクォート検証は、[Automata]を介して既にオンチェーンで約4〜5Mガスで実行されています。[CoRIM]エンコードされたPoE保証はCBORであり、ASN.1/X.509よりもはるかに簡単にオンチェーンで解析できます。オペレーターのPIIDに対する署名を検証し、それがDCAPクォートのPIIDと一致することを確認します。署名がsecp256k1を使用している場合、EVMでの検証はほぼ無料です。これは、エキゾチックな証明インフラストラクチャなしに、ハードウェアアテステーションとオペレーター保証の両方をオンチェーンで提供する完全なスタックを実現するための欠けているピースです。
Automataはオンチェーンのレイヤー3検証メカニズムを構築すべきです。 Automataはオンチェーンアテステーションの主要なプロジェクトであり、PoEとProof of Cloudの両方に対するオンチェーン検証器を開発するのに最も適した立場にあります。[TEE.fail]以降の状況の変化を認識し、Proof of Cloudの取り組みに参加することが自然な次のステップとなるでしょう。
IntelはPoE統合をDCAPに実装する必要があります。 [仕様]は存在しますが、ツールはまだ公開されておらず、PoE保証は依然としてオペレーターが帯域外で配布する必要のある外部アーティファクトです。Intelは、PoEがクォートに直接埋め込まれる将来のDCAPバージョンについて説明しており、これにより採用が簡単になるでしょう。保証がアテステーションとともに移動し、検証するアーティファクトが1つになるからです。それが実現するまで、合理的なオペレーターは、ステージ2がリリースされたら破棄しなければならないステージ1の保証パイプラインを構築することに投資しないでしょう。PoEの採用は、オペレーターの意欲ではなく、Intelによってブロックされています。
GCPは結合作業を完了し、PoEを検討する必要があります。 TDXクォートをPPIDを介してGCEインスタンスIDに結合する内部作業が進行中であり、おそらく第2四半期末までに完了する予定です。顧客が独自のソフトウェアスタックを持ち込めるベアメタル機密コンピューティングオプションも存在します。完全にPoE互換のオペレーター保証を実現するための技術的なギャップは小さいです。内部のprotobuf測定インフラストラクチャをCoRIMにブリッジし、PIIDに署名するだけです。これにより、GCPはバニラのDCAPに加えてオペレーター保証とオンチェーン検証可能性を得ることができ、どのハイパースケーラーよりも強力な組み合わせとなります。進行中の作業がGoogle固有の結合としてのみ完了するのか、それともIntel PoEも統合されるのかはまだ不明です。
Proof of Cloudはオンチェーンレジストリを必要としています。 [検証メカニズムは機能します]。[憲章]は追記専用の透明性ログを記述しています。そのログにはまだクエリ可能な公開インターフェースがなく、オンチェーン検証パスもありません。それがなければ、Proof of Cloudの結果は、依存する当事者がスマートコントラクトで独立して検証できないオフチェーンの主張となります。
少なくとも1つの中規模ホスティングプロバイダーがPoEを採用する必要があります。 OVHまたはOpenMetalがベアメタルTDXサーバーのPIIDに署名することは、ハイパースケーラー以外のパーミッションレスなトラステッド実行環境 (TEE) 運用の最初の真のテストとなるでしょう。管轄区域の多様性は、3つの米国クラウドプロバイダーからではなく、各地域にわたるホスティングオペレーターがそれぞれ独自の検証可能な保証を生成するところから始まります。
一方、今日構築しているなら、選択肢は限られています。Phala / dstackは実行可能なオプションです。トラステッド実行環境 (TEE)、GPU、PoCを介した部分的なパーミッションレス性を提供し、現在Ritualで使用されています。最も安価ではなく、単一ベンダーロックインのリスクと、エージェントワークロードが展開されるにつれて容量の天井が厳しくなる可能性があります。
**GCP（バニラTDX）**は、ハイパースケーラーの中で最も有望です。バニラDCAP、PoEを追跡、内部結合作業が進行中です。もし彼らがリリースすれば、市場で最も強力な組み合わせが得られます。もしリリースしなければ、頼るべきオペレーター保証はありません。
Azure、Nitro、またはGCP Confidential Spaceは、今すぐ堅実なものが欲しいなら問題ありません。AKチェーン、統合アテステーション、またはGoogle署名付きOIDCトークンを提供します。これらの中で、今日直接オンチェーンで検証可能なのはNitroだけです。これらが進化することを期待しないでください。どれも提供するものを変更する意欲を示していません。
投稿2件 - 参加者2名