TEE Anchor: TEEへの物理的攻撃を未然に阻止する仕組み

株式会社Acompanyでも研究・製品の主力の技術の1つとして活用しているTEE（Trusted Execution Environment）に関して、現行のTEEに対し、最近になって物理的攻撃（Physical Attacks）が現実的な脅威として浮上してきました。本記事では、このTEEに対する物理攻撃を間接的かつ効果的に対策するために用いる事のできる、新たに開発した「TEE Anchor」についてご紹介します。

TEEに対する物理攻撃の脅威

2025年になり、TEE.fail[1]とBattering RAM[2]と呼ばれる、TEEに対する物理攻撃が発表されました。これらは、TEEを動かすマシン（コンピュータ）のDRAM部分にインターポーザという攻撃装置を取り付け、DRAMに流れるトラフィックを読み取ったり、あるいは接地（アース）により操作対象のメモリ上の物理位置の改竄（エイリアス）させる事で、TEEが保護する秘密情報を抽出してしまうという攻撃です。

各攻撃論文はただ単に秘密を奪取するだけではなく、そのTEEの正しさをリモートから検証できるTEEの身元証明書（Attestation Report）を作成する上で必須の、そのハードウェアが固有に保持する秘密である、一般にAttestation Keyと呼ばれる鍵の抽出も行っています。これによりTEEでも何でもない攻撃者がAttestation Reportを偽造し、TEEの信頼の根幹を揺るがしてしまう可能性すら浮上しているわけです。

文字で説明するだけでは分かりにくい部分もあると思いますので、実際にその攻撃や攻撃装置の様子を写真で見てみましょう。

この通り、まさに攻撃対象マシンに物理的にアクセスし、攻撃装置を取り付け、文字通り「物理的に攻撃」している様子が分かります。ちなみに物理攻撃といってもスレッジハンマーでマシンを破壊するようなものはここでは含みません。ハンマーでの粉砕が最も手っ取り早い「物理的な可用性攻撃」であるとすれば、これらの攻撃は「物理的な機密性・完全性攻撃」とでも言えるでしょう。

このような物理攻撃は、これらの攻撃の登場までは問題として認識はされていたものの、現実的でないと放置されていました。しかし、TEE.failは1000ドル、Battering RAMに至ってはたったの50ドルで攻撃構成のセットアップが可能となり、金額的にはちょっと気合の入ったマニアであれば全然手の届くレベルに留まっています。

これらの現行のTEEに対する物理攻撃の根本原因は、TEEのメモリ暗号化に決定性（Deterministic）の暗号化方式、例えばAES-XTSやAES-XEXを用いている部分にあります。これらの暗号化方式は調整値（Tweak）として物理アドレスを用いており、これは裏を返せば同じ平文を同じ物理アドレスに配置した場合、暗号化鍵が同じ限りは必ず同じ暗号文になる、という事になります。TEE.failもBattering RAMも、物理アドレスを合わせればこの暗号文を再現できてしまう事を悪用しています。

他にも、まだ2026/7現在は少なくとも公開情報としては確認されていませんが、より強い物理攻撃者を想定した場合、

1. ある時点 $t$ での特定のメモリページを読み取りバックアップする
2. 目的の処理が行われる時点 $t’$ まで待つ
3. 時点 $t’$ になったら、バックアップしたメモリページで同じ場所に書き戻す

という物理的なメモリロールバック攻撃が可能となってしまいます。例えば時点 $t$ では秘密情報が載っており、その後ワイプして公開情報を載せて時点 $t’$ でそれを外部に送信するようなプログラム実装になっていた場合には、この攻撃が致命的な脅威になる事は明らかです。

これらの物理的な機密性・完全性攻撃を対策できていたのが、今では廃止されてしまった、クライアントマシン（CoreシリーズCPUマシン等）に搭載されていた旧式のIntel SGXです。この旧式のSGXは、書き込みの度にインクリメントされるカウンタ値を、CPUハードウェア管理のマークルツリーにより完全性を維持しながら、CPUハードウェアにより管理していました。メモリ暗号化時にはこのカウンタ値を調整値として用いる事で、これらの物理攻撃を防いでいたわけです。

しかし、旧式のSGXはこの代償として、パフォーマンスが著しく悪化するという欠点を抱えていました。結果、TEEとして現実的な速度を維持するには、TEEのサイズが1つあたり最大でも512MB、典型的には128MB（の内実際にユーザが使えるのは96MB）という、極めて厳しいメモリサイズ制約が強いられる事になりました。

現行のSGXはこのサイズ制限を大幅に緩和した反面旧式のSGXにあったようなハードウェアベースの強い対策は失われています。その他、Intel TDX、AMD SEV-SNP、Arm CCAといった主要なTEEが前提としている各種暗号化方式も、同様に物理攻撃対策には不十分となっているわけです。

この状況を見てもお分かりの通り、パフォーマンスを維持しながら物理攻撃を対策するには、以下の2つが必要です：

• 旧式のSGXでもあったような、非決定性の暗号化を復活させる事。
• 昨今TEEに要請される大規模ワークロードの状況を鑑みて、旧式SGXにあったようなメモリサイズ制約は生じないようにし、かつ処理速度も高速に維持する事。

これは現在のTEE・ハードウェア技術からすれば魔法のようなものであり、近日中に作り上げて全世界に公開！とは到底いきません。かつ、万一公開されたとしても、これに対応したメモリ暗号化エンジンを搭載したCPUを使用する必要があり、これは一般にはハードウェアレベルの換装が必要になります。そして、換装できない既存のマシンに関しては、依然として物理攻撃の脅威に晒され続ける事になるのです。

TEE物理攻撃の弱点

さて、これだけ見るとかなりの脅威であるTEE物理攻撃ですが、そんな物理攻撃にも無視できない弱点が主に2つ存在します。

1つ目に、決してこの物理攻撃自体が簡単ではないという事です。論文では気軽に構築して適用できる、という雰囲気を醸し出していますが、電子工作や攻撃パターン確立のためのリバースエンジニアリング等も、結構な気合がいるのは明らかです。また、インターポーザの構築以外にも、攻撃の過程では既知の様々な高度な攻撃手法（例：SEV-Step、Controlled-Channel Attacks等）を組み合わせています。その他にも攻撃対象に関する暗号学含む詳細な理解が必要であり、誰しもに開かれている簡単な攻撃、というわけではありません。これは、これまでに数多く提案されてきたTEEへの攻撃にも概ね共通して言える議論でもあります。

そして重要な2つ目として、単純にそのマシンに物理的にアクセスできなければこの攻撃は実行できません。CVSSの計算基準でも物理アクセスを要する攻撃は一番スコア係数が低く設定されているように、これはリモート等からも実現できる攻撃に比べ敷居が遥かに高いです。

より分かりやすい例を挙げましょう。例えば武装警備員が警備しているデータセンターに無理矢理侵入してTEE.failなんて試みようものなら、ゲートの前でそれこそ攻撃者が物理的に処理されて終わりでしょう。また、そもそもデータセンターはその所在自体が秘匿されている事が多く、特定ができないのであれば攻撃のしようも無いでしょう。

逆に、個人が自宅で保持しているような、いわば「野良のマシン」は、その本人の一存でいくらでも操作が可能であるため、物理攻撃の観点では「危険」なマシンであると言えます。論文著者らの実験はまさに、自身の保有するマシンに対して物理攻撃を仕掛けた筆頭であると言えます。

TEE.failの公式サイトでも、前掲のデータセンターへの攻撃の写真と一緒に「Are You Crazy?! Who Will Let You Into a Datacenter With This Thing!」（気が狂ってるのか？！誰がそんなもんをデータセンターに持ち込むのを許すというのか？）とセルフツッコミを入れています。

「所属証明」という新たなセキュリティ要件

つまりは、ハードウェア的に根本から原因を対策できない現状、「そのマシンが信頼可能な（警備等が厳重な）組織により管理されている」、即ち「そのマシンが信頼可能な組織に所属している」事を証明する事が、物理攻撃を対策する上での最も有効な方法の1つであると言えます。

信頼可能な組織の筆頭としては、厳重に警備されたデータセンターでマシンを管理するクラウドベンダが挙げられます。これはTEEが本来はホスト側の特権を持つ主体からの保護を大きなモチベーションの1つとしている事を考えると皮肉な話ではあります（勿論、それでもなお「特権を持つソフトウェアベースの攻撃を仕掛けるクラウドベンダ」からは現行のTEEも依然として守る事ができます）。

一方で、その当事者達の間で信頼可能と見なしても良い組織というのも、状況次第では多分にあり得ます。例えば特定の金融機関・組織、特定の防衛・軍事組織、特定の（コンセンサス的に承認されている）Web3系コミュニティといった具合です。このように、状況次第で任意の組織を信頼可能とする要求が考えられる事を鑑みると、特定のクラウドベンダのみにロックインされてしまうとそれは不十分であると言えます。

しかし、ここで問題となるのは、既存の技術ではそのような所属証明を行えるものは限られているという事です。従来のRA（Remote Attestation）は、TEEマシン及びTEEインスタンスのセキュリティレベルや動作定義等をチェックし、期待するセキュリティや動作であるかを確かめる事はできますが、そのマシンがどの組織による管理下にあるかは、AMD SEV-SNPを除いて確かめる事はできません。

SEV-SNPでは、AMDとクラウドベンダが共有する秘密に基づき生成したVLEK（Versioned Loaded Endorsement Key）をAKとして用いる事で、その署名を検証する事によりそのクラウドベンダにAttester（検証対象TEEマシン）が属している事を確信する事ができます。しかし、VLEKはクラウドベンダ以外に仕組みを提供する前提ではない記述がされており[3]、かつあくまでもSEV-SNPに限定されるため、任意組織による展開可能性とTEE横断性に欠けるという側面があります。

同時に、このようなセンセーショナルな攻撃の話題が出て色々なコミュニティが黙っているわけもなく、その他にも物理攻撃の登場を皮切りとして、様々な所属証明の提案が登場してきています（詳細は後述します）。しかしこれらはどれも、所属証明を行う上で以下の全てを満たせるものがなく、セキュリティ、パフォーマンス、フレキシビリティのいずれかまたはその複数を犠牲にしてしまっている側面があります：

• 現行のTEE全てに対して所属証明を適用する事ができる、TEE横断性を備えている事。
• 所属証明の適用に際してパフォーマンス上のオーバーヘッドを最小限にする事。
• TPMのような、TEEが本来信頼境界の外に置いているコンポネントを余計に信頼しなくて良い事。
• 従来のRAの実施（検証）は検証者（Verifier）やリモートユーザ（Relying Party; RP）が自前で実施可能であり、その実施自体まで特定の組織に依拠する過剰な信頼の委譲を行わない事。
• 任意の組織により所属証明を展開可能である事。

これら5つの要件はいずれも、任意の組織が物理攻撃対策のためのマシンの所属保証を手軽に、全てのTEEに対し、そして最大まで安全性を高めつつ行う上では不可欠な要素であると言えます。

これら5つの要件を全て満たすTEE Anchor

今回新たに開発したTEE Anchorは、上記の5つの要件を全て満たしつつ、物理攻撃対策のための組織への所属保証を実現します。コアとなるアイデアは、そのTEEマシンのCPUの識別子（Chip ID）に対し、組織のルートCAによる認証（署名及び証明書発行）を行う事で、組織独自のPKIによりその所属の保証を行うというものです。

Chip IDは、現行の主流のTEEにおいては、そのTEEのAttestation Report（AR）か、またはそれを認証するTEEベンダ発行の証明書から抽出する事ができます（以下、これらをまとめてRA証跡と呼ぶ事にします）。各TEEそれぞれ、例えば以下のような値をChip IDとして利用可能です：

• Intel SGX/TDX: PPID（Platform Provisioning ID）。PCK Cert（TEEベンダ発行の証明書）から抽出可能
• AMD SEV-SNP: CHIP_ID。Attestation Reportから抽出可能
• Arm CCA: cca-platform-instance-id。Attestation Report（Platform Token）から抽出可能

TEE Anchorは、主にプロビジョニングと検証の2つの主要な機能を有し、これらがTEE Anchorの中核となります。その他、プロビジョニングのための組織CAの初期化機能や、特定のマシンに対する証明書を失効させるための機能も有します。これらのいずれも、CLI上で（あるいはsubprocess的に） tee-anchor コマンドを実行する事で簡単に呼び出せる、CLIツールとして提供されています。感覚としてはvirteeのsnpguestのように簡単に使う事が可能で、逆にSGX/TDXのRAのようにゴリゴリにコード実装に組み込みながら開発する手間は発生しないのもメリットです。

かつ、その検証は、従来のRAの検証を実施した後に追加で単に当該コマンドを呼び出して実行するだけで良いため、既存のRA実装を破壊する事なく、非侵襲的に所属保証の検証を行う事ができるのも良い部分です。

プロビジョニングフェーズ

TEE Anchorにおけるプロビジョニングとは、マシンを管理する組織が、管理対象のTEEマシンのChip IDに対し、組織のルートCAをトラストアンカーとした証明書を発行するための手続きです。これに基づき後述の検証フェーズにおいて、発行し頒布された証明書をVerifierが署名検証し、証明書に同梱されているChip IDと、実際にAttesterから渡されたARやTEEベンダ証明書に含まれているChip IDとを照合し一致すれば、そのAttesterマシンが真にその組織に所属している事を確信できるという仕組みです。

プロビジョニングを行うには、予めTEE Anchorのサブコマンドにより組織CAを初期化（ルートCA証明書のVerifierへの公開含む）した上で、まず組織が管理対象にしようとしているTEEマシンにおいてRA証跡を取得します。そして、RA証跡を署名検証し、真にTEEベンダのルートCAをトラストアンカーとして認証されている事を念の為確認します。

確認が取れたら、次はRA証跡からChip IDを抽出します。そしてそのChip IDをX.509の拡張領域に同梱したX.509証明書を組織のルートCA秘密鍵により発行します。これにより、Chip IDを含む組織リーフ証明書と、組織リーフ証明書を認証する組織ルートCA証明書からなる2段階の証明書チェーンが生成されます。組織リーフ証明書のTo Be Signed鍵としてはそのTEEにおけるARを認証しているAttestation Key（AK）公開鍵を使用していますが、TEE Anchorにおいては特に関与しないため、これはダミー的な措置に過ぎません。

その後、組織はVerifierに対してこの組織証明書チェーンを頒布します。頒布方法については色々と考えられますが、TEE Anchorの責務からは外れますので、TEE Anchorでは頒布用の仕組みまでは提供しません。この組織証明書チェーンを用いれば、Verifierは検証対象のマシンが信頼可能な組織に真に属しているかを確認する事ができるというわけです。

RA証跡の抽出だけはTEE Anchorの範囲外で各自で実施する必要がありますが、TEE AnchorのGitHubリポジトリではサンプルの抽出用プログラムは簡易的なものですが各TEEについて提供しています。それ以降の組織証明書チェーン作成までの処理は、TEE Anchorのサブコマンドを実行する事で簡単に実行できます。

前提として、このプロビジョニングやそもそもの組織CAの初期化、及び次に説明する失効処理は、物理的に安全な状態で組織が実施する必要があります。これは、第三者による物理攻撃ができない状態を保証する（例：厳重な警備）というのがそもそもTEE Anchorにおける信頼可能組織の大前提ですので、信頼可能な組織が実施する限りは自動的にクリアされる事になります。

失効処理

例えば組織が管理していたマシンを廃棄する場合、その時点でその組織の管理下から外れますので、そのマシンに対する組織証明書はもはや無効としなければなりません。また、物理攻撃以外でAKが侵害された場合には、従来であればそのインシデントを報告してTEEベンダ側に失効してもらいますが、報告とTEEベンダ側による対応のリードタイムがあるため、組織自身が直接失効させた方が速効性がある可能性も多分にあり得ます。

そのようなシナリオに備え、TEE Anchorでは発行した組織リーフ証明書を失効させる機能も提供しています。組織側は、TEE Anchorのサブコマンドを用いる事で、失効させたい証明書を入力として失効対象DB（現実装ではシンプルなテキスト形式）への追加を行い、またそのDBに基づいて証明書失効リスト（CRL; Certification Revocation List）を生成する事ができます。

検証側は、このCRLをオプションで入力とする事が可能であり、その場合には追加で失効有無の確認処理も行われます。

検証フェーズ

検証フェーズでは、まずは検証者がAttesterに対し従来のRAを実施し、Verifierが期待する要件をそのTEEが満たしているかを通常通り確認します。もしARへの署名が違う、TEEベンダ証明書が失効している、期待する測定値ではない等があれば、その場合はわざわざ所属証明の検証を行うまでもないため、その時点で終了してしまって良いでしょう。

従来のRAの検証に成功したら、今度は追加的にTEE Anchorの検証サブコマンドを検証者は実行します。これはSEV-SNPであれば snpguest 実行後に単に tee-anchor を呼び出す、あるいはTDXであればDCAP APIを用いたQuote（AR）の検証後にそのプログラム上からsubprocess的に呼び出す等、前述の通り既存のRA実装に対して非侵襲的に実施する事ができます。

TEE Anchorの検証では、まずRA証跡からChip IDを抽出します。従来のRAを実施しているはずであるため、RA証跡がTEEベンダのお墨付きを受けた状態であるのは判明済みなはずではありますが、現在の実装では念の為再度TEE Anchor側でも、TEEベンダをトラストアンカーとした署名が付与されているかの署名検証を実施します。

その後、予め受け取っている組織ルートCA証明書内により、組織から受け取った組織証明書チェーンを検証し、組織リーフ証明書が真にその組織から発行されたものである事を確認します。そして、組織リーフ証明書からChip IDを抽出し、RA証跡から抽出したものと一致確認を行います。もし一致すれば、そのAttesterは真にその組織に所属している事をVerifierが確信する事ができるため、信頼できると見なしてTEEと実施したい後続の処理を続行します。一致しなかった場合は信頼可能な組織への所属が確認できない事になるため、それ以上のやり取りを拒否し終了します。

前述の通り、この検証にCRLをオプションとして入力として渡すと、失効リストとの照合も実施され、失効されていた場合にはそれを検知する事が可能です。

従来のRAよりも後に実施するTEE Anchorの検証も、TEE Anchorのサブコマンドを実行するだけで簡単に実施する事ができます。

性能

以上までに説明したTEE Anchorの性能面の評価ですが、まず検証に関して見てみると、従来のRAの実行時間未満で完結できているため（SEV-SNPの従来のRAの実行時間についてはsnpguest certs + snpguest attestationで算出すべき点に注意）、許容可能なオーバーヘッドであると言えるでしょう。さらに、実際には従来のRAにはRA証跡の取得・転送をはじめ、リモート通信含む様々な他の処理も含まれますので、図5のグラフの測定対象外である従来RAのそれらも鑑みれば、尚更TEE Anchorのオーバーヘッドが微々たるものである事が分かります。

検証サブコマンド含めその他のサブコマンドも、いずれも10ms内に収まっており、全体を通してかなり軽量に実装できていると結論づけて良いでしょう。

関連手法との比較

このように、仕組みとしては非常にシンプルでかつ必要な要点をおさえているTEE Anchorですが、次は既存の様々な手法との相違点について検討していきます（前述にて既に言及したAMD SEV-SNPのVLEKに関してはここで改めての説明はしません）。

以下に、関連手法とTEE Anchorとの比較を行った恣意的な星取り表を示します。

Intel POE

Intel POE（Platform Ownership Endorsements）[4]は、Intel SGX/TDXにおけるPIID（PPIDではない）というChip IDに対するEndorsementを発行し、従来のRAに加えて追加的にそれを検証します。Intel以外によるEndorsementの払い出しも可能であるため、TEE Anchorとは任意組織による展開可能性やChip ID相当の概念を利用するという意味で基本構造は同種です。

しかし、POEの最大の欠点としては、これを使うにはIntel SGX/TDX用の複雑なRA基盤であるDCAPに組み込む事が必須であるとされている事です。公式声明[4]には、その検証をDCAPのQuote検証ライブラリの1つとして実装する予定であると明記されており、これは筆者が実装し提供しているHumane-RAFW-DCAPを見ても分かる通り、些かクセのあるDCAP APIを呼び出す形で実施されるものであると思われます。また、その性質から完全にSGX/TDXにロックインされてしまうため、他のTEEへの適用は不可能です。

しかし、POEの最大の欠点として、Intel SGX/TDX用への使用しか想定されていない、つまりはTEE横断性が欠落しているという部分があります。現に、DCAPバージョン1.27と同じタイミングで公開されたリポジトリ[4]を見ても、あくまでもSGX/TDX用のDCAPの一環として提供されているものであり、SEV-SNP等の他のTEEへの直接の利用は不可能です。また、RAの規格化を行うRATs（RFC 9334）で使用される、リファレンス測定値（期待する測定値）を列挙するフォーマットであるCoRIMへの統合を提案するドラフト[10]を見ても、あくまでもIntel SGX/TDXへの適用を前提としているのが読み取れ、TEE横断性を考慮していない事が分かります。

所属証明の展開の自由度という意味ではVLEKよりも上と言えますが、特定のベンダにロックインされTEE横断性が欠落しているという部分については、VLEKと同じ制約を抱えていると言えます。

対して、TEE Anchorは現行の主要なTEEに対して横断的に適用可能であるため、POEとは大きく差別化されます。

DCEA及びDstack

DCEA（Data Center Execution Assurance）[5]は、ホスト側vTPMをTEEのAR及び場合によってはホスト側物理TPM Quoteで認証し、そのvTPMのAKの上位鍵EKに対する証明書を発行する事で、真にそのクラウドベンダに属するかを検証できるようにするという提案です。

また、Dstackはよりシンプルに、SGX/TDXのPPID（Chip ID）がそのクラウドベンダに属するものかを確認後、その上でそのマシンのTPMのAKをTEEのARで認証し、TPM EK証明書を発行してその所属を検証できるようにする提案をしています[6]。

つまりは、そのマシン上の(v)TPMに対するEKがその組織（クラウド）への所属を意味するので、所属証明がこれらの方法でできるだろう、というものです。

確かに1つの手として考えられますが、これらの手法は所属証明を行うという観点では少々過剰である部分も否めません。まず、これらの手法ではTPMに依存するため、物理アクセスを必要としないTPM特有の追加の攻撃ベクタ[7]を生み出す事に繋がりかねません。折角TEEへの物理攻撃を防ぎたいのに、物理アクセスを必要としないTPMへの攻撃でその対策の仕組みが万一ひっくり返されてしまっては本末転倒です。

また、DCEAの論文では、Quote生成だけでも物理TPMで約550ms、vTPMで約300msを要するという実験結果を示しています。これは、各処理10ms未満で済むTEE Anchorに比べると非常に重い事は火を見るよりも明らかです。

よって、これらのTPMベースのアプローチに比べると、TEE Anchorは安全面とパフォーマンス面の双方で優位であると言えます。

Proof of Cloud Alliance

Proof of Cloud Alliance[8]は、Chip IDと検証済み物理ロケーションの対応を複数の独立組織が検証し、それらが共同管理する署名付きの中央集権的な追記専用レジストリに登録する枠組みであり、Chip IDを活用するという点ではTEE Anchorとも共通します。要は、Web3的なコンセンサスベースの共同体がある種多数決的にChip IDに基づく、あるいはその周りの運用を握る仕組みという事です。

しかし、マシンの登録に際して既存メンバによる物理立ち会いや、zk-TLS証明、改竄検知RFIDビーコン、前述のDCEAといった重い追加の措置を通した検証が必要です。さらに、レジストリへの追加には既存メンバによる多数決が必要であり、Chip IDのホワイトリストや失効リストも、複数組織共同管理の中央集権的DBからフェッチする必要があります。これは、任意の組織が自身での運用のためにフレキシブルに展開したいというニーズからすると大きな障壁となります。

一方で、TEE Anchorは各組織が自前のCAで証明書を発行する事で、信頼するマシンを組織自身が独立に決定できます。また、中央集権的なレジストリへの参加や複数組織の合意、そしてコストの重い検証手続きも必要としません。つまり、特にプロビジョニングの設計思想が両者で大きく異なると言えます。

Proof of Cloud Allianceが相互不信な多数の参加者による共有レジストリ志向であるのに対し、TEE Anchorは任意の組織が単独かつ軽量に所属保証を導入できるものであるため、そもそもこれらは似ているようでかなり適用対象が異なるものです。両者ともに、適用領域と運用コスト面で差別化する事が可能で、もしフレキシビリティと軽量さを重視するのであればTEE Anchorが適している、と言えるでしょう。

SPIFFE/SPIRE

SPIFFE/SPIREは、ワークロードにAttestationに基づくSVIDという識別子を発行する枠組みで、PontesらはこれをSEV-SNP CVMに拡張しました[9]。この方式では組織が運用するSPIREサーバがTEEのRAを実施してSVIDを発行しそれを末端のVerifierに渡し、末端のVerifier自身はSVIDをチェックする一方で、末端のVerifierは従来のRAを自身で実施する設計にはなっていません。あくまでも、受信したSVIDのみを見るという設計となっています。ちなみに、これは元々物理攻撃対策を目的として提案されたものではありませんが、この性質から物理攻撃対策への転用が一定以上に可能であると言えるでしょう。

これはMicrosoft Azure Attestation（MAA）同様、従来のRAの実行自体すら組織を信頼し依拠するというモデルです。これ自体は組織を信頼する前提であるため悪い事ではありませんが、あくまで物理的な管理と所属保証に関してのみを信頼するという前提に立つと、従来のRAの実行自体まで追加で信頼をするのは少々過剰であるという見方もできます。

一方でTEE Anchorは、従来のRAもVerifier自身で行う事で、組織への信頼をマシンの物理的な安全な管理やプロビジョニング等の最小限に抑える事ができます。これも優劣ではなく、信頼を中央に集約するか各Verifierに委ねるかという、信頼モデルの違いによる棲み分けとなると結論付けられます。

まとめ

本記事では、セキュリティ、パフォーマンス、フレキシビリティのいずれも両立させつつ、物理攻撃対策のためにTEEマシンの信頼可能な組織への所属保証を実現するTEE Anchorについて紹介しました。

実装に関しては以下のGitHubリポジトリにて公開しています。

GitHub - acompany-develop/tee-anchor: Ensures geographical security and prevents physical attacks by verifying the organisation to which the TEE machine belongs

Ensures geographical security and prevents physical attacks by verifying the organisation to which the TEE machine belongs - acompany-develop/tee-anchor

GitHub

TEE Anchorが、TEEに対する物理攻撃に対する有効な対策の1つとして今後活用されていただければと期待しております。

参考文献

[1] J. Chuang, A. Seto, N. Berrios, S. van Schaik, C. Garman, and D. Genkin, “TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition”, in Proc. 47th IEEE Symp. on Security and Privacy (S&P), 2026. https://tee.fail

[2] J. De Meulemeester, D. Oswald, I. Verbauwhede, and J. Van Bulck, “Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing”, in Proc. 47th IEEE Symp. on Security and Privacy (S&P), May 2026. https://batteringram.eu/

[3] AMD, “SEV Secure Nested Paging Firmware ABI Specification”, Revision 1.58. https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf

[4] Intel, “Platform Ownership Endorsements for Confidential Computing.”, 2026/8/17閲覧. https://github.com/intel/confidential-computing.tee.dcap.poe/tree/main

[5] F. Rezabek, M. Mahhouk, A. Miller, Q. Kilbourn, G. Carle, and J. Passerat-Palmbach, “Proof of Cloud: Data Center Execution Assurance for Confidential VMs”, arXiv preprint arXiv:2510.12469, 2025.

[6] Dstack-TEE, “TEE: TPM-Based Approach to Code and Location Verification #626”, 2026/6/25 閲覧. https://github.com/Dstack-TEE/dstack/discussions/626

[7] D. Moghimi, B. Sunar, T. Eisenbarth, and N. Heninger, “TPM-FAIL: TPM meets Timing and Lattice Attacks”, in Proc. 29th USENIX Security Symposium (USENIX Security 20), pp. 2057–2073, 2020.

[8] Proof of Cloud Alliance, “Proof of Cloud”, 2026/6/25 閲覧. https://proofofcloud.org

[9] D. Pontes, F. Silva, E. Falc˜ao, and A. Brito, “Attesting AMD SEV-SNP Virtual Machines with SPIRE”, in Proc. 12th Latin-American Symp. on Dependable and Secure Computing (LADC ’23), pp. 1–10, 2023. https://doi.org/10.1145/3615366.3615419

[10] Mateusz Bronk et al., “A CoRIM Profile for Intel Platform Ownership Endorsements (POE)”, 2026/8/17閲覧. https://datatracker.ietf.org/doc/draft-bzb-rats-intel-poe-endorsements/