トラステッド実行環境（TEE）

# トラステッド実行環境（TEE） ## 定義トラステッド実行環境(trusted execution environment, TEE)とは、プロセッサ上に「閉じた世界(closed world)」を設け、通常のOSやroot権限のプロセスからも隔離された領域で機密性の高い処理(暗号鍵の扱い、重要なI/Oなど)だけを実行させるハードウェア機構である。*Security Engineering* 第3版第6章は、代表的な2系統の実装として、Intelの**Software Guard eXtensions(SGX、2015年発表)**とArmの**TrustZone(2004年発表、2015年まで非公開)**を挙げる。SGXはメモリの一部を暗号化区画(エンクレーブ)として扱い、Memory Encryption Engine(MEE)による暗号化と、エンクレーブ外のプロセスがエンクレーブメモリにアクセスできないようにする新命令・メモリアクセス検査を備える。TrustZoneは「開いた世界」(通常のOSと汎用アプリケーション)と「閉じた世界」(単一のtrusted execution environmentで、暗号処理やSIMカード・指紋リーダーのような機微なI/Oを担う)という2ワールドモデルを取り、プロセッサがセキュア状態にあるかどうかは、ユーザーモードかスーパーバイザーモードかとは独立した軸である。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3.1, §6.3.2) Armの**CHERI**は、TEEそのものではないが同じ「プロセス内をさらに細分化して隔離する」という関心を共有する発展形で、サブスレッドにメモリの特定範囲への読み書きアクセスを割り当てることで、プロセス切り替えのコストをかけずに同一プロセス内に複数のサンドボックスを実現するケーパビリティ拡張である。2018年に製品として発表され、Windows・Android・iOSのようなOSに徹底導入されれば近年のゼロデイ攻撃の大半を防げたはずだと本章は評する。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3.2) TEEの起源は、MicrosoftとIntelがDRM実現のためPCプラットフォームに暗号を導入しようとした2000年代初頭の産業アライアンス(現Trusted Computing Group)にあり、TPMチップによるtrusted bootという形で最初に実用化された。Microsoftの当初の野心的な計画(project Palladium、「2つの世界」モデルをWindows Vistaに実装する構想)は複雑すぎて頓挫したが、そのビジョンは2004年からArmのTrustZoneに引き継がれたと本章は位置づける。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.2.5) ## 横断的知見 - **TEEと第18章の耐タンパ性は、「何を信頼すべき範囲から除外するか」を最小化するという同じ設計原則を共有するが、脅威モデルが根本的に異なる**: 第6章のSGX・TrustZoneは、CPUパッケージ自体の物理的な信頼を前提とした上で、OSやroot権限プロセスからの隔離をソフトウェア・アーキテクチャレベルで実現する。これに対し第18章が扱うHSM・スマートカードの耐タンパ性は、攻撃者がデバイスを物理的に占有し、封止を削り取り、プローブを当てるという「パッケージそのものへの信頼を疑う」脅威モデルを前提に、化学的・機械的な防御を積み重ねる。TEEの未解決の問い(Meltdown・Spectreがエンクレーブの保護の限界を露呈させた)は、第18章が扱う光学的故障誘発・電力解析といった物理攻撃とは異なる攻撃面(マイクロアーキテクチャ的サイドチャネル)から生じており、両ソースを突き合わせると「信頼範囲の最小化」という原則だけでは脅威モデルの設計は決まらないことが分かる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3.1, §6.3.2, [[@2020__Wiley__Security Engineering 3e - Chapter 18 Tamper Resistance]] ch.18 §18.5.3) - **第22章(Phones)は、第6章が理論として示したTEEの実装品質問題を、モバイル業界の実際のOEM・チップベンダー横断の実装状況で裏づける**。第6章はTEEを「概ね健全な2ワールドモデル」として抽象的に説明していたが、第22章はQualcommのTEE実装においてtrusted app(TA)がホストOSのメモリ領域をマップできてしまい、脆弱なTAが1つでもあればデバイス全体がroot化されうるという具体的な実装バグを報告し、他4社のTEEベンダーにも「弱いASLR・過大なTCB・デバッグチャネル経由の情報漏洩・実行防止機構の欠如・複数のサイドチャネル・失効の仕組みの欠如」が横断的に見られるとするCerdeiraらのサーベイを引く。さらに、Arm自身がTrustZoneへの正式な鍵格納(KeyStore)を提供したにもかかわらず、OEM・端末・ソフトウェアバージョン間の差異が大きすぎて開発者の多くが結局は難読化に頼っているという実装現場の実態を示す。これは、第6章がTEEを「信頼計算基盤を最小化する現代的機構」と位置づける理論と、実際の量産チップ・OSエコシステムでの実装品質が乖離しうることを、単一ソースの理論だけでは見えなかった形で確認するものである。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3.1, [[@2020__Wiley__Security Engineering 3e - Chapter 22 Phones]] ch.22 §22.4.1.1, §22.4.1.2) - **「エンクレーブアーキテクチャが側チャネル攻撃にどこまで耐性を持ちうるか」という本ページの未解決の問いは、第19章(Side Channels)を読むと否定的な答えが得られる**: 第19章は、2017年のCachezoom攻撃がSGXエンクレーブからキャッシュサイドチャネル経由で鍵を抽出したこと、2018年のForeshadowが「SGXとシステム管理モードを含む、Spectreが破れなかったIntelプロセッサの機能の多くを破った」ことを報告する。これは、TEEが前提とする「OS・他プロセスからの論理的な隔離」が保たれていても、投機的実行・キャッシュ状態というCPUマイクロアーキテクチャ全体に共通する物理的性質そのものが漏洩経路になるため、ソフトウェア・アーキテクチャレベルの隔離だけでは防げないことを具体的に示す。すなわちエンクレーブの側チャネル耐性には本質的な限界があり、対策はエンクレーブの外側(CPU設計そのものの変更)に委ねざるを得ない。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 19 Side Channels]] ch.19 §19.4.5) - **第20章は、第6章が定義したSGXの信頼モデルを、実際に稼働する認証(attestation)機構の内部構造にまで踏み込んで補強する**: 第6章はSGXを「チップ境界を信頼境界とし、ソフトウェア攻撃から隔離するアーキテクチャ」として抽象的に説明するのに対し、第20章はその認証がどう成立するかを具体的に描く――ファブが焼き込むseal secretとprovisioning secretからmaster derivation key(MDK)を生成し、Intelが発行するEnhanced Privacy ID(EPID、署名者匿名性を保つグループ署名)によってチップの真正性を証明する。この認証の単位はチップ単位ではなくEPIDグループ単位であり、1個のチップのMDKが漏洩すると同じグループの全チップの認証が破られる(2019年にAMDの同等機構でマイクロコードのバグにより実際に発生)。これは、第6章が「CPUパッケージ自体の物理的な信頼を前提とする」と述べる際の「信頼」の中身が、単一チップの信頼ではなく、Intelが管理する不透明なグループ単位の信頼であることを明らかにし、TEEの脅威モデルにサプライヤー(Intel)自身への信頼という新たな次元を加える。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3.1, [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]] ch.20 §20.6) - **[[Signal]]のプライベート連絡先発見は、TEEが「HSMに代わる汎用暗号プラットフォーム」たりうるという第6章の位置づけを、実運用アプリで裏づける具体例である**: Signalは、利用者のアドレス帳をサーバに渡さずに連絡先の中の他のSignalユーザーを発見するために、SGXエンクレーブに連絡先を送り検証済みのコード上で照合させる方式へ移行した(電話番号ハッシュの単純比較では100アカウント・25日でアメリカの5億件超の電話番号を走査され250万人のユーザーが特定されてしまったため)。しかしこの処理はSGXのメモリ制限(128MB)の中でハッシュテーブルを工夫して収める必要があり、コンテキストスイッチのオーバーヘッドのためにバッチ処理でしか実用速度が出ない。これはTEEが「汎用プラットフォーム」として謳われつつも、実際のアプリ開発では性能制約・実装の難しさという固有のエンジニアリングコストを強いることを、単一のアプリ事例から示す。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]] ch.20 §20.3, §20.6) ## 未解決の問い - SGXは当初エンクレーブコードがIntelの署名を要求していたが、SGXv2以降は署名を委譲し「根本の信頼(root of trust)」を他者に開放する方向に進んだ。この変更が、本章が報告するエンクレーブマルウェア(SGX malwareの実験)のリスクをどれだけ増大させたか、産業的な定量評価はまだない。 - Michael Schwarz・Samuel Weiser・Daniel Grussが実証した、SGXエンクレーブからホストアプリへのステルスなROP攻撃に対し、Intelは将来のcontrol-flow enforcement technology(CET)で対処するとしている。CETがこの種の攻撃をどこまで防げるかは本章の執筆時点(2020年)で未検証のまま残る。 - TrustZoneは2004年の発表から2015年まで閉鎖的に運用され、OEMがNDAの下でのみアプリ開発者に開放していた。この「閉じたエコシステム」の期間が、SGXと比較してTrustZoneの脆弱性発見・対応にどう影響したかは本章では論じられていない。 - CHERIが2021年に最初のシリコンを予定していると本章は述べる(2020年執筆時点)。CHERIがWindows・Android・iOSのようなメインストリームOSに実際に採用され、ゼロデイ脆弱性を防ぐ効果を発揮したかどうかは、本章の記述の範囲外(2020年時点の予測)であり、後続のソースでの検証が必要。 - 第22章はQualcomm以外の4つのTEEベンダーにも同種の実装品質問題(弱いASLR・過大なTCB等)があるとするCerdeiraらのサーベイを引くが、どのベンダーがどの問題を持つのか、Appleの独自TEE実装がこれらの問題を抱えるのかは、第22章の記述の範囲では特定されない。 - 第20章はSGXのEPIDグループの規模(1グループに何個のチップが属するか)が「Intelが全ての認証を不透明に行っており、利用者は結果を信じるしかない」ため不明だと述べる。この不透明性が、TEEを「信頼計算基盤の最小化」の実装とみなす第6章の評価にどう影響するかは、本ページの既存の横断的知見(Intel自身への信頼という次元)を超えて、Intelの認証運用の透明性そのものを検証する後続ソースが必要である。 ## 関連 - ソース: [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]](§6.2.5, §6.3.1, §6.3.2) / [[@2020__Wiley__Security Engineering 3e - Chapter 22 Phones]](§22.4.1.1, §22.4.1.2) / [[@2020__Wiley__Security Engineering 3e - Chapter 19 Side Channels]](§19.4.5) / [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]](§20.3, §20.6) - 概念: [[信頼計算基盤（TCB）]](TEEはTCB最小化の現代的なハードウェア実装) / [[セキュリティ設計原則]](機構の経済性とTEEの脅威モデル未定義という限界) / [[Capability-based Security]](CHERIのケーパビリティ拡張) / [[耐タンパ性]](同じ信頼範囲最小化の原則を異なる脅威モデルで実現する系譜) / [[投機的実行とマイクロアーキテクチャサイドチャネル（Meltdown・Spectre）]](エンクレーブ側チャネルの技術的詳細) / [[Signalプロトコル]](SGXを用いるプライベート連絡先発見) - 実体: [[Signal]](SGXエンクレーブを実運用で用いるアプリ) ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 6, §6.2.5, §6.3.1, §6.3.2. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 18, §18.5.3. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 22, §22.4.1.1, §22.4.1.2. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 19, §19.4.5. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 20, §20.3, §20.6.