🔐
数式なしで理解するTEE入門：秘匿実行環境の仕組み
想定読者: ブロックチェーンと ZKP の知識はあるが、TEE を使った実装は未経験の開発者
ゴール: TEE の基本概念と、ブロックチェーン dApp での活用パターンを理解する
1. 「何を隠す」ために TEE が選ばれているのか
1.1 公開チェーンのジレンマ ─ なぜ隠したい？
パブリックチェーンは コードも入力データも誰でも閲覧できる ことが前提です。
しかし実務では、次のような情報を公開せずに処理したいケースが増えています。
| 例 | 公開されると困る理由 |
|---|---|
| DEX のリアルタイム オーダーブック | MEV（サンドイッチ）攻撃を誘発する |
| NFT オークションの 最低入札額 | 事前リークで価格操作される |
| 個人データを含む AI モデル推論 | 個人情報保護・企業機密の観点 |
| ゲームの 乱数シード / 戦略 AI | チートや逆アセンブルで不正プレイが可能になる |
「計算はしたいが、中身は見せたくない」という要求に対し、
ゼロ知識証明（ZK）と並ぶ秘匿計算の選択肢として、ハードウェアレベルでデータと処理を隔離する仕組みである Trusted Execution Environment（TEE） が注目されています。
1.2 秘匿計算 ざっくり比較マップ
※ここでは ZK／MPC／FHE／TEE を 一枚絵で俯瞰 します。
| 項目 |
ZK (SNARK/STARK/zkVM) |
MPC (Multi-Party Computation) |
FHE (Fully Homomorphic Encryption) |
TEE (Trusted Execution Environment) |
|---|---|---|---|---|
| ざっくり仕組み | 公開回路で計算 → "正しさだけ" 超小型証明 | 秘密分割して多数ノードで分散演算 | 暗号化のまま加減乗算 | CPU 内の隔離領域で平文計算＋ハード署名 |
| 証明／通信サイズ | 128 B – 数 MB | 通信量：O(演算 × 人数) | ほぼ無し（暗号文のみ） | Quote+証明書チェーン≒4-5 KiB |
| レイテンシ*¹ | 秒 – 分（生成） | RTT× 通信ラウンド数 | 桁違いに遅い（×10³ – 10⁴） | ミリ秒（ネイティブ級） |
| 開発難易度 | 回路設計 or no_std Rust | プロトコル設計＋オーケストレータ | 専用ライブラリ＋演算制限多 | ほぼ通常 C/C++/Rust |
| 量子耐性 | 曲線依存：弱 / STARK：強 | 暗号方式次第 | 暗号方式次第 | ハード署名＋外側暗号次第 |
| 依存 & 信頼 | 数学＋ Trusted Setup*² | 各 MPC ノード | FHE ライブラリ | 対応 CPU / ConfVM |
| 強み | 極小証明・オンチェーン検証容易 | 入力を完全非公開のまま演算 | データ常時暗号化 | 速度・I/O・ロジック完全秘匿 |
| 弱み | 証明生成重い／回路制限 | 通信コスト・同期難 | 計算激重・実用領域狭い | ハード依存・サイドチャネル |
*¹ = "Hello World" 規模の目安 *² = Groth16 系のみ
1.3 TEE のワークフロー（30 秒解説）
| ステップ | 何が起きているか |
|---|---|
| ① 隔離 | Enclave は OS/HV から隔離。平文計算しても外部から読めない。 |
| ② 測定 | CPU がプログラムハッシュ＋初期状態を署名（Quote）。 |
| ③ 署名付き結果 | Host は 結果＋Quote をチェーンへ送り、スマコンが検証。 |
1.4 実戦投入されている TEE ユースケース
| 分野 | プロジェクト / サービス | 目的 | 参考 |
|---|---|---|---|
| MEV & サンドイッチ防止 | Flashbots SUAVE — カスタム enclave でプライベートオーダーフローを処理 | 取引内容を暗号化したままマッチ → ブロック提案まで秘匿 (Flashbots Writings) | |
| MEV Blocker RPC / CoW DAO — Builder が SGX で競合を遮断 | ユーザートランザクションを先回りから保護 (CoW DAO) | ||
| プライベート Smart Contracts | Secret Network — バリデータ SGX で入力を復号 | DeFi・NFT に秘匿入出力を提供 (docs.scrt.network) | |
| 暗号経済プロトコル | Shutter Network / Rolling Shutter — TEE ＋閾値暗号で L2 を保護 | ロールアップ全体のフロントラン耐性を実装 (Shutter Blog, Shutter Blog) | |
| ウォレット & キー管理 | Fireblocks — MPC 鍵署名を SGX で補完 | 鍵分割 + enclave でカストディ | |
| AI 推論 on-chain | Gensyn (研究中) — AI モデル推論を Nitro Enclave で行いハッシュを記録 | 高速・大容量モデルの秘匿実行 |
2. 主要 TEE 実装カタログ
| 実装 | 隔離スコープ（どこまでがハードウェアで守られているか） | アテステーション（TEE 環境が本当に安全かを外部に示す仕組み） | インフラ要件・提供形態 | 備考 |
|---|---|---|---|---|
| Intel TDX | VM 全体を VMM から隔離 | TDX Quote (ECDSA P-256) | 4th Gen Xeon「Sapphire Rapids」以降が必須。クラウド: Azure DCesv5、GCP C3、Alibaba g8i、OCI | |
| AMD SEV-SNP | VM メモリ＋レジスタ | SNP Report (ECDSA) | 3rd Gen EPYC「Milan」以降／Azure DCasv5、GCP N2D、OCI Confidential VM | |
| AWS Nitro Enclaves | EC2 内サブ VM | Attestation Doc | Nitro 世代 EC2 (x86/Graviton) が前提。エンクレーブ生成は同一 VM 内で完結 | |
| ARM TrustZone | CPU を Secure / Normal に分離 | 実装依存 | SoC による | モバイル／ハードウォレット |
| Keystone / Open Titan | RISC-V オープン TEE | Keystone Evidence | 開発ボード／FPGA が前提。研究・教育向け |
✔ インフラ観点の要点
- オンプレ／自前サーバーで使う場合は、TEE に対応する CPU と最新の BIOS やマイクロコードのアップデートが必要。
- クラウド利用なら「Confidential VM」SKU を選択するだけで OK だが、リージョン／インスタンスサイズが限定される点に注意。
- SGX 時代と違い TDX / SNP はハイパーバイザ側にもカーネルパッチが必要 なので、DIY は難易度高め。
3. TEE vs zk-SNARK / zkVM ― ベンチ表
| 指標 | Groth16 zk-SNARK | RISC Zero zkVM (STARK) | TEE (Nitro / TDX / SNP) |
|---|---|---|---|
| 証明 / Quote サイズ | 128–192 B | 200 KB〜数 MB | ≈ 4-5 KiB |
| 生成レイテンシ | 10²–10³ ms | 10³–10⁴ ms | 10⁰ ms |
| 検証 Gas | ≈ 230 k | STARK Raw 3–5 M → 圧縮 280 k | L1: ≈300 k / L2(プリコン): < 50 k |
| Trusted Setup | 必須 | 不要 | 不要 |
| 量子耐性 | 弱 | 強 | ハード依存 |
| 開発体験 | 回路 DSL | Rust (no_std) | 通常の Rust/C/C++ |
| 動的ロジック | 制限大 | 〇 だが証明重い | 自由 |
| 主リスク | 回路バグ | 証明肥大 | サイドチャネル |
| インフラ要件 | 任意 CPU + libsnark 等 | 任意 CPU + zkVM | 対応 CPU または Confidential VM が必須 |
4. TEE で「何が守れる／漏れる」か
| 項目 | zk-SNARK | zkVM | TEE | 解説 |
|---|---|---|---|---|
| 入力データ | ✅ | ✅ | ✅ | Witness / Enclave メモリ |
| 中間状態 | ✅ | ✅ | ✅ | レジスタ・スタック |
| プログラム本体 | 公開 | ハッシュのみ | 完全秘匿 | バイナリ未配布も可 |
| 計算ロジック分岐 | 公開 | ハッシュのみ | ✅ | if/loop も秘匿 |
| 実行時間漏れ | — | — | ⚠️ | 高負荷で外部観測可 |
| Quote/証明 | 128–192 B | 200 KB〜 | 4-5 KiB（証明書チェーン含む） | ハード署名付き |
| 鍵ストレージ | — | — | ✅ | Sealing キー |
| インフラ依存 | 低 | 低 | 高：対応 CPU/VM なしでは動かない |
5. アーキテクチャ基礎 ─ Host / Enclave / Verifier
5.1 ３つの役割をまず押さえる
| 役割 | 実体 | 主な責務 | 例 |
|---|---|---|---|
| Guest / Enclave | CPU 内の隔離領域 | ❶ 秘匿データを平文で計算 ❷ 署名付き Quote を生成 |
TDX TD, SEV-SNP VM, Nitro Enclave |
| Host (Prover) | Enclave を持つ VM（dApp サーバ） | ❸ Enclave に入力を渡し結果を受取る ❹ 結果 + Quote をチェーン or API へ提出 |
EC2 インスタンス、Confidential VM |
| Verifier | スマートコントラクト / L2 Node / 別サーバ | ❺ Quote を検証し結果を確定 | Solidity コントラクト、Rollup Sequencer |
1 行要約
Enclave ＝金庫で計算、Host ＝金庫番、Verifier ＝金庫の"鑑定士"。
5.2 リモートアテステーション全体像
- 隔離 (ISO) – Enclave メモリは HV や root でも読めない
- 測定 (MEASURE) – 起動時のハッシュを CPU が ECDSA/ED25519 で署名
- 証明 (ATTEST) – Quote を CA (Intel IAS / AMD AAS / AWS KMS) が検証し、証明書を発行
-
確定 (VERIFY) – スマコンが署名チェーンを検証、
resultをオンチェーン状態に反映
5.3 通信チャンネル整理
| チャネル | 用途 | 特徴 |
|---|---|---|
| vsock (Nitro) | Host↔Enclave IPC | UNIX ソケット感覚・外部ネット遮断 |
| virtio-serial (TDX/SNP) | 同上 | QEMU/KVM で一般的 |
| gRPC + TLS | Host↔dApp Frontend | Enclave 外通信 |
| On-chain call | Host↔Smart Contract | submitResult(bytes result, bytes report) |
5.4 スマートコントラクト側の検証パターン（擬似コード）
function verify(bytes calldata result, bytes calldata report)
external
{
// ① CA の署名を検証
require( CA_PUBKEY.verify(report), "invalid CA sig" );
// ② Report 内の PCR 値が期待する IMAGE_HASH か照合
bytes32 pcr = extractPCR(report);
require( pcr == EXPECTED_HASH, "tampered enclave" );
// ③ 必要なら result ハッシュも report に含めて整合確認
...
// ④ 状態更新
_apply(result);
}
ポイント
- オラクル不要：CA 公開鍵をコントラクトに固定すれば完全オンチェーン検証
- Gas：ECDSA検証はL1では≈300 k gas、secp256r1 プリコンパイルのあるL2なら数万gas程度
5.5 実装時のハマりどころ
| 落とし穴 | 回避策 |
|---|---|
| 時間差リプレイ（同じ Quote 使い回し） | Report に Nonce or Block Number を含める |
| I/O サイドチャネル（I/O サイズで情報漏えい） | パディング & 定数長レスポンス |
| 電源/周波数攻撃（SNP 電圧グリッチなど） | DC・クラウド専用 HW 採用／Shamir fallback |
| CA ダウン（可用性リスク） | 複数 CA を許容する fail-over 仕様に |
これで Host / Enclave / Verifier の責務とリモートアテステーションの流れが把握できます。
6. TEE の弱点と攻撃面
| リスク領域 | 攻撃例とひとこと解説 | 想定される影響 | 主な対策 |
|---|---|---|---|
|
サイドチャネル (Side Channel) |
キャッシュタイミング攻撃 ‐ CPU がデータにアクセスする際の速度差から、秘匿データを推測する攻撃手法。 電圧グリッチ ‐ CPU に瞬間的な低電圧をかけエラーを起こし、機密情報を読み取る手法。 |
秘匿データや暗号鍵が漏れる可能性 | - 時間一定の実装 - レスポンス長の固定 - 電圧・周波数をロック |
| ロールバック／リプレイ |
スナップショット巻き戻し ‐ 昔の VM イメージを起動させ、状態を改ざんする手法。 |
ステートが古い状態に戻され二重実行などが発生 | ブロック高・Nonce を Enclave に渡し、Quote で確認 |
| サプライチェーン |
改ざんされた BIOS／ファーム ‐ 起動前のコードが書き換えられ、TEE ごと支配されるリスク。 |
TEE の信頼前提が崩れる | セキュアブート、起動時ハッシュのチェック、信頼できるクラウドを選択 |
| 可用性 |
CA（証明機関）停止 ‐ Quote 検証用サービスが落ちると新規検証が止まる。 |
dApp が一時的に停止 | 複数 CA の許容、失敗時はキャッシュ済み証明で暫定運用 |
7. ハイブリッド設計 ─ 技術を組み合わせる３つの型
| 組み合わせ | 期待できる効果 | 処理フローの例 |
|---|---|---|
| TEE × ZK | TEE で重い処理を高速実行 →ZK で結果を数百 B に圧縮しチェーンへ | AI モデルで推論した数 GB の結果 → 結果の要約データを Groth16 の証明で圧縮 → スマートコントラクトはその小さな証明だけを検証 |
| TEE × MPC | 鍵や意思決定を複数ノードで共有、重い計算だけ TEE に | Threshold ECDSA で署名生成 →Enclave が大量トランザクションをバッチ処理 |
| TEE × FHE | データをずっと暗号化したまま移動し、計算時だけ TEE で復号 | FHE で暗号化した統計データ →Enclave で平均値計算 → 再暗号化して外部へ |
実例として、Flashbots SUAVE（TEE ＋ ZK）、Fireblocks（TEE ＋ MPC）などがあります。
8. まとめと参考資料
8.1 技術選定の早見ポイント
| 判断軸 | TEE が適する | ZK／MPC が適する |
|---|---|---|
| レイテンシ | ミリ秒単位 | 秒〜分でも可 |
| オンチェーン証明サイズ | なるべく小さく | 数百 B 〜数 MB 許容 |
| 信頼モデル | ハードウェアを信頼できる | 数学的完全性／複数主体を優先 |
8.2 参考資料
| 分類 | 公式／参考リンク | 解説 |
|---|---|---|
| AWS Nitro Enclaves | Nitro Enclaves 概念とアテステーション概要 | アテステーションの仕組みと証明書の検証フロー |
| アテステーション・ドキュメントの構造と検証手順 | Attestation Docのフォーマットと検証方法の詳細解説 | |
| 実測サイズと実装ノート | Attestation Doc (≒5 KiB)のサイズと署名構造 | |
| Intel TDX | Intel TDX DCAP Quoting Library API | TDX Quoteフォーマットと生成API、ECDSA P-256署名仕様 |
| AMD SEV-SNP | SEV-SNP Attestation: Establishing Trust in Guests | VCEK/証明書チェーンとAAS検証フロー |
| オンチェーン署名検証 | RIP-7212: P256VERIFY | プリコンパイル (3,450 gas) 対応L2向け仕様 |
| P-256署名検証のガス測定 | Solidity実装の場合 約330kガスかかる実測データ | |
| クラウドでのTEE実装例 | EC2上のAMD SEV-SNP検証手順 | snpguestでレポート取得と検証を行う実例 |
| Hands-on | AWS Nitro Enclaves Workshop | 初心者向けハンズオン（KMS 統合例） |
おわりに
最後までお読みいただきありがとうございます。
改めまして、naizo と申します。普段はブロックチェーン周りの開発をしています。
細々とブロックチェーン関連の記事を書いていますので、
よろしければぜひフォローしていただけると嬉しいです！
この記事が皆さんにとって、TEE や zk 技術を試すきっかけになれば幸いです。
質問やフィードバックなどありましたら、コメントや SNS でお気軽にご連絡ください。
Discussion