TEE とセキュアエンクレーブ（SGX・TrustZone・SEV）

TEE が変える脅威モデル

通常のセキュリティは「OS とハイパーバイザは信頼できる」前提に立ちます。アプリは OS を信じ、OS はハードを信じる——この信頼の連鎖が一段でも崩れれば終わりです。しかしクラウドでは、自分のワークロードが他人の管理する物理サーバーとハイパーバイザの上で動く。管理者権限を持つ者やインフラ事業者を、本当に無条件で信じられるでしょうか。

TEE（Trusted Execution Environment、信頼実行環境）はこの前提を覆します。OS・ハイパーバイザ・BIOS・さらには DRAM に物理プローブを当てる攻撃者までを脅威モデルに含め、それでもなお守られる隔離領域を CPU ハードウェアが強制的に作る。信頼の起点（Root of Trust）を OS ではなく CPU そのものに置き換えるのが核心です。

Intel SGX：プロセス内の暗号化エンクレーブ

SGX（Software Guard Extensions）は、1プロセスの中に「エンクレーブ」と呼ぶ保護領域を作ります。粒度が小さく、信頼境界を必要最小限に絞れるのが特徴です。エンクレーブのコードとデータは EPC（Enclave Page Cache）という物理メモリ領域に置かれ、CPU 内の MEE（Memory Encryption Engine）が DRAM へ書き出す全データを暗号化し、完全性ツリー（Merkle 木）で改ざんとリプレイを検出します。OS は EPC ページのマッピングを管理できますが、中身は読めも書けもしません。

実行モデルは明確に分かれます。エンクレーブへの入退場は専用命令（EENTER / EEXIT）を通り、割り込みや例外で抜けるときは AEX（Asynchronous Enclave Exit）でレジスタ状態を暗号化退避してから OS に制御を返す。OS にはエンクレーブ内部のレジスタもメモリも一切見えません。

ECREATE → EADD/EEXTEND → EINIT   // エンクレーブ構築・計測の確定
EENTER                           // ユーザーコードからエンクレーブへ
  （保護された計算。EPC は MEE で暗号化）
EEXIT / AEX                      // 通常退出 / 割り込みによる非同期退出

構築時、CPU は追加されるページの内容とレイアウトを逐次ハッシュし、MRENCLAVE という計測値に畳み込みます。これがエンクレーブの「正しい中身」の指紋になり、後述の構成証明で使われます。なお SGX のエンクレーブはユーザー権限で動き、I/O やシステムコールを直接行えないため、外界とのやり取りは必ず信頼できない OS を経由します。この境界設計は最小権限の原則の徹底版と言えます。

ARM TrustZone：CPU を2つの世界に割る

TrustZone は粒度が大きく、CPU 全体を「セキュアワールド」と「ノンセキュアワールド」の2世界に分割します。バス上を流れる NS（Non-Secure）ビット1本が世界を区別し、ノンセキュアワールドのコードはセキュア側のメモリ・周辺機器・割り込みに一切触れられません。世界の切り替えは Monitor モード（SMC 命令で遷移）が仲介します。

Normal World           |  Secure World
 Rich OS (Android 等)   |  Secure OS (OP-TEE 等)
 通常アプリ             |  Trusted Application (TA)
        \               |               /
         ----  SMC ──→ Secure Monitor ──→  世界切替

スマートフォンの指紋認証・DRM・モバイル決済・鍵保管が典型用途で、セキュア側で動く小さな Trusted Application が秘密鍵を握り、ノーマル側の OS が乗っ取られても鍵自体は漏れません。SGX が「アプリの中に金庫を置く」のに対し、TrustZone は「CPU に裏口の管理人室を常設する」イメージです。ただし TrustZone 自体はメモリ暗号化を規定せず、隔離はバスとメモリコントローラのアクセス制御（TZASC 等）で行う点に注意します。秘密の保管という観点ではシークレット管理のハードウェア版の役割を担います。

AMD SEV：VM まるごとを暗号化する

クラウドの主役は VM です。SEV（Secure Encrypted Virtualization）はゲスト VM のメモリを VM ごとに別の鍵で暗号化し、ハイパーバイザからゲストのメモリ平文を隠します。鍵は CPU に内蔵された AMD Secure Processor（独立したセキュリティチップ）が管理し、ハイパーバイザにも OS にも渡しません。粒度は SGX より遥かに粗い「VM 単位」で、既存 OS をそのまま暗号化保護に載せられるのが強みです。

世代で保護範囲が大きく違うことを正確に押さえる必要があります。

つまり「暗号化されている」ことと「改ざんを防げる」ことは別問題です。SEV-SNP の RMP（Reverse Map Table）は各物理ページの正当な所有者を記録し、悪意あるハイパーバイザによるページの再マップ・入れ替え・リプレイを検出します。Intel 側の対応物が TDX（Trust Domain Extensions）で、こちらも VM 粒度の保護を提供します。

構成証明：本物の TEE で正しい中身が動く証明

TEE の真価は隔離だけでなく、遠隔の相手に「正規のハードの上で、改ざんされていないコードが動いている」と暗号学的に証明できる点にあります。これが構成証明（Remote Attestation）です。仕組みは三段に分けて捉えると正確です。

1. 計測：エンクレーブ／VM の初期状態（SGX なら MRENCLAVE、MRSIGNER）をハードがハッシュで記録する。
2. 署名：その計測値を、CPU に焼き込まれた製造元しか持たない秘密鍵で署名し、引用（Quote）を作る。SGX なら ECDSA ベースの DCAP、初期世代は EPID（グループ署名で個体を匿名化）を用いた。
3. 検証：受信側がベンダの証明書チェーン（X.509 チェーン検証と同じ信頼連鎖）を辿って署名を確認し、計測値が期待どおりかを照合する。

Verifier                         Enclave / TEE
   |   nonce（リプレイ防止）  →        |
   |                                   |  計測値 + nonce を取得
   |   ← Quote = Sign_HW(計測値,nonce) |
   | ベンダ証明書で署名検証            |
   | 計測値が想定の MRENCLAVE か照合   |

検証が通って初めて、Verifier はエンクレーブへ秘密（復号鍵やデータ）を安全に投入します。nonce を混ぜるのは過去の Quote の使い回しを防ぐためで、これを欠くとリプレイで偽装される。署名鍵がハードに封じられているからこそ、ソフトのエミュレータでは正しい Quote を作れず、「本物の TEE である」ことが担保されます。

既知の攻撃：TEE は万能ではない

TEE は脅威モデルを広げますが、CPU 内部の物理的・マイクロアーキ的欠陥は TCB の内側にあり、設計の前提を崩します。実装が理論に追いついていない点を正確に理解することが、誤用を避ける鍵です。

• サイドチャネル：エンクレーブのメモリは暗号化されても、アクセスのパターンは OS から観測できます。OS はページフォルトを意図的に誘発（controlled-channel 攻撃）し、エンクレーブがどのページを触ったかを追って秘密を推定できる。キャッシュタイミングも同様で、根はサイドチャネル攻撃と共通です。
• Foreshadow（L1TF）：投機的実行の欠陥を突き、SGX エンクレーブのデータを L1 キャッシュ経由で抜いた。Spectre / Meltdown と同系統で、構成証明の署名鍵すら危険に晒した。
• Plundervolt / 故障注入：CPU の電圧・周波数を意図的に下げて演算にビット反転を起こし、エンクレーブ内の暗号計算を誤らせて鍵を漏らす。物理に近い層からの攻撃で、純粋なソフト防御では塞げない。
• SEV の完全性欠如：完全性保護のない初期 SEV / SEV-ES では、ハイパーバイザがゲストの暗号文を入れ替える・物理ページを差し替える攻撃が成立した。SEV-SNP の RMP はまさにこれへの回答です。

実務での使いどころ

TEE が真に効くのは、「インフラ管理者やクラウド事業者を信頼したくない」というデータ機密性の要求がある場面です。機密データの分析、複数当事者が秘密を持ち寄る計算、鍵の保管、ブロックチェーンのオラクルなどが典型で、近年は「Confidential Computing」として VM 粒度（SEV-SNP / TDX）の採用が中心になっています。SGX のプロセス粒度は信頼境界を最小化できる一方、開発が難しく、Intel はクライアント向け SGX を縮小しました。

導入時の鉄則は三つです。第一に、脅威モデルの境界を正しく引く。TEE はサイドチャネルや物理故障注入を完全には防がないため、何を守れて何を守れないかを明示する。第二に、構成証明を必ず実装する。TEE で動かしているつもりが偽の環境だった、では意味がありません。第三に、TCB を小さく保つ。エンクレーブに余計なコードを詰めるほど攻撃面が増えます。