HN 日本語サマリー

← 一覧へ戻る
セキュリティ

TEEsについて話す時が来た

It's time to talk about TEEs (alinush.github.io)

12 pointsby joshcsimmons1 コメント

要約

この記事は、トラステッド・エグゼキューション・エンバイロメント(TEE)に対する懸念される攻撃を調査し、TEEベースのアプリケーションのデプロイメントを再考するよう促しています。Enclaveコードのバグや、Intel SGXやAMD SEVなどのプラットフォームに影響を与えるリモートアテステーション偽造の脆弱性が指摘されています。結論として、貴重な秘密情報をTEEに格納することは、特に物理攻撃のリスクを考慮すると、漏洩につながる可能性があるため推奨されません。

全文翻訳

TEEについて語る時が来た

この記事は、TEEに対する懸念される攻撃をいくつか調査します。その目的は、TEEベースのアプリケーションをどのようにデプロイするか、あるいはそもそもデプロイすべきかどうかを再考してもらうことです。

信頼できるハードウェア企業(Intel、AMDなど)は、主にパフォーマンス、機能性、そして(願わくば)開発者フレンドリーさで競合しています。彼らはセキュリティでも競合しようとするかもしれませんが、私の意見ではそれは困難です。なぜなら、常に他の誰かがより高いセキュリティを(誤って)主張でき、そのような主張は市場で裁定するのが難しいからです。さらに、現代のCPUアーキテクチャの複雑さ、サイドチャネル攻撃の蔓延、アテステーションサービスの集中化はすべて、TEEのセキュリティ主張を疑わしいものにしています。

いずれにせよ、(いくつかの)TEE攻撃は以下の通りです。

エンクレーブコードのバグ

エンクレーブは、環境(例えば、ホストOS、あるいは物理的な環境)から秘密情報や計算の整合性を保護することを目的としています。しかし、エンクレーブプラットフォームがセキュアであっても、エンクレーブ内で実行されるコードのバグは悲劇につながる可能性があります。

  • Signalの連絡先発見エンクレーブにはメモリ安全性に関する問題があり、ホストがそれを混乱させ、エンクレーブが自身のメモリ内容を漏洩させる原因となりました[1]。

TEEリモートアテステーション偽装バグ

これらの攻撃の多くは、Intel SGXだけでなく、AMD SEVのような他のTEEプラットフォームにも影響を与えました。

  • 2018年、Foreshadow: 悪意のあるOSがIntel SGXアテステーションキーを(初めて!)盗むことが可能になりました。
  • 2020年、SGAxe: SGXアテステーションキーを盗むにはリング0へのアクセスが必要です(これは2回目でした!)。
  • 2022年、ÆPIC Leak: マイクロアーキテクチャのバグにより、ホストのroot管理者(root admin)がSGXアテステーションキーを盗むことが可能になりました。
  • 2024年、BadRAM[2]、AMD SEV-SNPシステム上の改ざんされたDIMM SPDチップ。
    • 1回の物理アクセス(DIMMの再プログラムに約10ドル)を持つホストのroot管理者は、正規のAMDチップが正規のVMを証明するレポートに署名している間に、バックドアのあるVMを実行できます(キーは抽出されませんが、アテステーションは偽です)。
  • 2025年、WireTap.fail[3]、DDR4システム向けのインターポジション物理攻撃。
    • 「コードがSGX下で実行されているかどうかを判断するための主要なメカニズムであるアテステーションキーを抽出することに成功しました。これにより、ハッカーは正規のSGXハードウェアになりすまし、実際にはコードを露出した状態で実行し、データにアクセスできるようになります。Secret Network、Phala、Crust、IntegriTEEなどのSGXを利用する実際のソフトウェアに対して、具体的なセキュリティ侵害を実証しました。」
  • 2025年、TEE.fail[4]、DDR5システム向けのインターポジション物理攻撃。
  • 2025年、Battering RAM、DDR4システム向けのインターポジション物理攻撃。
  • 2026年、DDRrop[5]、書き込みをドロップすることによるDDR5システム向けのインターポジション物理攻撃。
    • Intel TDXリモートアテステーション偽装。

あなたは言うかもしれません:「私は気にしない。私の脅威モデルには物理攻撃は含まれない。」いいえ、それは違います、愚か者:あなたのリモートアテステーション検証者は、正常な状態にある任意のIntel CPUからの引用を受け入れます。そして攻撃者のCPUもその一つです。一つが破られれば、すべてが破られます、ただし…

ただし:検証者を、あなた自身のPCK証明書[6]のみを受け入れるようにピン留めする場合、それは暗黙のうちに攻撃者のCPUを除外します。これは、いわゆるスケーラブルSGX(唯一残っている形式)で機能し、PKIを慎重に管理する必要があります。つまり、実質的にフットガン(足で踏む銃、つまり自分で自分を傷つける可能性のあるもの)を扱うことになります。

幸運を祈ります。

TEEライブネス(可用性)バグ

DoSは、SGX、TDX、SEV-SNP、Nitroの脅威モデルには明確に外れています(ホストがエンクレーブのスケジューリングを拒否できるため)。ここでは、TEEプラットフォーム自体の予期せぬ問題によるライブネスの問題に焦点を当てます。

  • 2018年、Spectre/Meltdownを考慮したSGX資格情報の失効により、TEEエンクレーブは麻痺しました。
  • 2022年、SGX.fail[7]は、TCB(Trusted Computing Base)の回復がどれほど遅くロールアウトされ、プラットフォームが長期間「時代遅れ」のままになる可能性があるかを詳細に説明しています。
  • 2022年、AMDプラットフォームにおけるASP fTPMでのTPMアテステーション失敗。
    • 例:ゲーマーがオンライン現金トーナメントに参加できなくなる可能性があります。

その他の学術論文攻撃

非常に多くあります[7][8][9][10]。

理論的には、信頼できるハードウェアの攻撃対象領域を減らす方法があります。例えば、私のMIT時代のグループによるSanctum[11]を参照してください(#shameless-plug)。残念ながら、実際には、これらのより原則的な設計は、パフォーマンスが低い、または機能が少ない傾向があります。

結論

安全なTEEの使用については、多くのことが言えます[12]。このブログではそれは触れていません。ここでは、TEEの脅威モデルと過去の攻撃にのみ触れています。それでも、TEEをセキュリティのために活用する方法がないと主張しているわけではありません。

tl;dr? TEEに貴重な秘密情報を入れないでください。そうしないと、特に物理攻撃があなたの脅威モデルに含まれている場合、それらは公開される可能性が高いです。

しかし、おそらくあなたはこれらすべてを無視するでしょうから、少なくともTEEを注意深く使用してください?[13][14][15]

一般的に、TEEは防御の深層化(defense-in-depth)に使用できます。例えば、MPCノードをTEEに入れたり、プライバシーはTEEによって提供されるが整合性はZKPsによって保証される、低リスクの共有状態を持つ機密アプリケーションを構築したりできます。

参考文献

引用された作品については、以下を参照してください 👇👇

  1. Signal’s SGX-based contact discovery gets broken ↩

  2. BadRAM}: Practical Memory Aliasing Attacks on Trusted Execution Environments, by De Meulemeester, Jesse and Wilke, Luca and Oswald, David and Eisenbarth, Thomas and Verbauwhede, Ingrid and Van Bulck, Jo, in 46th {IEEE} Symposium on Security and Privacy ({S&P}), 2025 ↩

  3. WireTap: Breaking Server SGX via DRAM Bus Interposition, by Alex Seto and Oytun Kuday Duran and Samy Amer and Jalen Chuang and Stephan van Schaik and Daniel Genkin and Christina Garman, in 2025 SIGSAC Conference on Computer and Communications Security (CCS ‘25), 2025, URL ↩

  4. TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition, by Jalen Chuang and Alex Seto and Nicolas Berrios and Stephan van Schaik and Christina Garman and Daniel Genkin, in 47th IEEE Symposium on Security and Privacy (IEEE S&P ‘26), 2026, URL ↩

  5. DDRop}: Active Memory Interposer Attacks on Confidential {VMs} by Dropping {DDR5} Writes, by De Meulemeester, Jesse and Gloor, Stefan and Jattke, Patrick and Moghimi, Daniel and Oswald, David and Thompson, Martin and Razavi, Kaveh and Verbauwhede, Ingrid and Van Bulck, Jo, in Proceedings of the 2026 {ACM} {SIGSAC} Conference on Computer and Communications Security ({CCS} ‘26), 2026 ↩

  6. 私の理解では、「古い」2015年のEPIDベースのSGXアーキテクチャは現在廃止されています。↩

  7. SoK}: {SGX.Fail}: How Stuff Get e{X}posed, by van Schaik, Stephan and Seto, Alex and Yurek, Thomas and Batori, Adam and AlBassam, Bader and Garman, Christina and Genkin, Daniel and Miller, Andrew and Ronen, Eyal and Yarom, Yuval, 2022, URL ↩ ↩2

  8. CacheWarp}: Software-based Fault Injection using Selective State Reset, by Zhang, Ruiyi and Gerlach, Lukas and Weber, Daniel and Hetterich, Lorenz and Lü, Youheng and Kogler, Andreas and Schwarz, Michael, in 33rd USENIX Security Symposium (USENIX Security 24), 2024 ↩

  9. SEVered: Subverting AMD’s Virtual Machine Encryption, by Mathias Morbitzer and Manuel Huber and Julian Horsch and Sascha Wessel, 2018, URL ↩

  10. CLKSCREW}: Exposing the Perils of {Security-Oblivious} Energy Management, by Adrian Tang and Simha Sethumadhavan and Salvatore Stolfo, in 26th USENIX Security Symposium (USENIX Security 17), 2017, URL ↩

  11. Sanctum: Minimal Hardware Extensions for Strong Software Isolation, by Victor Costan and Ilia Lebedev and Srinivas Devadas, in Cryptology {ePrint} Archive, Paper 2015/564, 2015, URL ↩

  12. Debunking TEE FUD: A Brief Defense of The Use of TEEs in Crypto, by Quintus Kilbourn, January 2025 ↩

  13. TEE-based Smart Contracts and Sealing Pitfalls, by Andrew Miller ↩

  14. Don’t let TEEs break your MPC, by Paul Bottinelli ↩

  15. A few notes on AWS Nitro Enclaves: Attack surface, by Paweł Płatek ↩