TrustMee: Self-Verifying Remote Attestation Evidence

以下は、論文「TrustMee: Self-Verifying Remote Attestation Evidence」の詳細な技術的概要です。

1. 問題定義

リモートアテステーションは、機密仮想マシン（cVM）および信頼実行環境（TEE）における信頼の確立に不可欠です。しかし、現在の検証メカニズムには重大な限界が存在します。

• プラットフォーム固有の複雑性: 検証者は、サポートするすべての TEE（例：Intel SGX、Intel TDX、AMD SEV-SNP）に対して、ハードウェア固有の暗号論理とパースライブラリを実装する必要があります。
• 信頼計算基盤（TCB）の増大: 検証者は、証明書やアテステーション証拠をパースするために、C/C++ と OpenSSL などのメモリ安全性が保証されていない言語で書かれたネイティブプラグインやドライバに依存しています。これにより、バグや脆弱性（例：リモートコード実行）が検証者自体に導入されます。
• 保守性とスケーラビリティ: 新しい TEE のサポートを追加するには、検証者のコードベースを更新し、再コンパイルして再デプロイする必要があります。これにより、「鶏と卵」の問題が生じ、検証者はセキュリティリスクと保守コストを最小化するために、より少ないプラットフォームのサポートに誘導されます。
• 脆弱性: 一つの TEE に対する検証者プラグインのバグは、検証サービス全体を侵害し、攻撃者に他のプラットフォームをなりすます可能性を招く恐れがあります。

2. 手法：TrustMee アーキテクチャ

著者は、プラットフォームに依存しないアテステーション検証者「TrustMee」を提案します。これは、プラットフォーム固有の検証論理の負担を検証者からアテスターへ移行させるものです。

中核概念：自己検証型証拠

検証論理をハードコーディングする代わりに、アテステーションを行う TEE は、そのアテステーション証拠に併せて、特定の検証論理を WebAssembly (Wasm) コンポーネント としてバンドルします。

• アテスター: 標準的なアテステーション証拠と、その特定の証拠形式をパースおよび検証するロジックを実装する対応する Wasm コンポーネントを生成します。
• 検証者 (TrustMee):
  1. 証拠と Wasm コンポーネントを受信します。
  2. Wasm コンポーネントを測定し（信頼ストアに対するハッシュ/署名の確認）、
  3. サンドボックス化された WebAssembly ランタイム (Wasmtime) 内でコンポーネントを実行します。
  4. コンポーネントが証拠をパースし、エンドースメントを確認し、標準化されたクレームのセットを出力します。
  5. TrustMee ホスト（プラットフォームに依存しないコード）がこれらのクレームにアプリーポリシーを適用し、結果を標準的な Entity Attestation Token (EAT) 形式で署名します。

主要な技術コンポーネント

• WebAssembly コンポーネントモデル: ホストとコンポーネント間の厳格で言語に依存しないインターフェースを定義するために、Wasm インターフェース型 (WIT) を使用します。これにより、TEE に関わらず、検証者は統一された API（evaluate 関数）を介してコンポーネントと対話します。
• サンドボックス化: Wasm コンポーネントは、制限されたアクセス（例：「燃料計量」による制限された CPU サイクル、制御されたネットワークアクセス、隔離されたファイルシステム）を持つサンドボックス内で実行されます。これにより、悪意のあるまたはバグのあるコンポーネントが検証者をクラッシュさせたり、機密ホストデータにアクセスしたりするのを防ぎます。
• 信頼モデル:
  • 検証者は Wasm ランタイム と ポリシーエンジン を信頼します。
  • プラットフォーム固有のロジックは信頼されませんが、隔離されています。
  • 検証者は、Wasm コンポーネントの 署名者（通常は TEE ベンダ）と、コンポーネントのハッシュを参照値に対して確認します。
  • コンポーネントが未署名であるか、未知の署名者からの場合、厳格なデフォルトポリシー（ネットワークなし、CPU 制限あり）の下で実行されます。

3. 主要な貢献

1. TrustMee アーキテクチャ: アテスターが検証コードを提供する、自己検証型リモートアテステーションの新しい設計。これにより、検証者がプラットフォーム固有のドライバを維持する必要がなくなります。
2. 実装: Trustee フレームワーク（Confidential Containers プロジェクトの一部）に統合された動作プロトタイプ。これには、AMD SEV-SNP、Intel TDX、および Intel SGX 用の Wasm 検証コンポーネントが含まれます。
3. 標準化: システムは、既存の依存当事者との互換性を確保する標準的な EAttestation Result (EAR) 形式で結果を生成します。
4. セキュリティ分析: Wasm 内でプラットフォーム固有のパースロジックを隔離することが、検証者の TCB を大幅に削減し、メモリ安全性が保証されていないライブラリに関連するリスクを軽減することを示しています。
5. パフォーマンス評価: ネイティブドライバと比較した Wasm アプローチのオーバーヘッドを定量化しました。

4. 結果と評価

著者は、AMD SNP、Intel TDX、Intel SGX に対するネイティブ Trustee ドライバに対して TrustMee を評価しました。

• 互換性: 単一の修正されていない検証者ホストを使用して、3 つの異なる TEE アーキテクチャからの証拠の検証に成功しました。新しい TEE を追加するには、検証者の更新ではなく、新しい Wasm コンポーネントの配布のみが必要です。
• セキュリティ:
  • Wasm サンドボックスは、パースおよび暗号操作を正常に隔離します。
  • 悪意のあるコンポーネントは、ポリシーエンジン（署名者/ハッシュチェックを介して）によって検出されない限り、検証者を侵害したり、他のプラットフォームをなりすましたりすることはできません。
  • 拒否サービス（DoS）攻撃は、燃料計量とネットワーク制限によって軽減されます。
• パフォーマンス（レイテンシ）:
  • コールドスタート: コンポーネントのダウンロードとコンパイルを含む初期検証は、ネットワークおよびコンパイルのオーバーヘッドにより、より高いレイテンシを有します。
  • ウォームスタート: コンポーネントがキャッシュされると、オーバーヘッドは管理可能です。
    • AMD SNP: ネイティブ Wasm 検証は、現在の Wasm ランタイムにおけるハードウェアアクセラレーション暗号の欠如により、ネイティブの C/Rust ドライバよりも約 3.67 倍遅くなりました。ただし、ホストベースの暗号（Wasm からネイティブ暗号関数を呼び出す）を使用すると、このオーバーヘッドは約 1.47 倍に削減されました。
    • Intel TDX/SGX: 純粋な Rust ライブラリ（dcap-qvl）を使用した Wasm ベースの検証者は、Intel の独自 DCAP ライブラリを使用したネイティブ Trustee ドライバよりも実際には高速でした。dcap-qvl を使用したネイティブドライバと比較した場合、Wasm のオーバーヘッドは約 3.17 倍でしたが、絶対レイテンシは低く（多くの場合 50ms 未満）、維持されていました。
  • リクエストサイズ: TrustMee のリクエストは、ベース 64 エンコードされた JSON の代わりに CBOR エンコーディングを使用しているため、コンポーネント識別子のサイズを相殺しつつ、ネイティブのリクエストよりも小さく（最大 37% 削減）なる傾向があります。

5. 意義と将来への影響

• 検証とハードウェアの分離: TrustMee は、検証者と TEE ベンダ間の密結合を断ち切ります。これにより、クラウドプロバイダや検証者は、コード変更なしに新しい TEE を即座にサポートできるようになります。
• 攻撃対象領域の削減: エラーを起こしやすいパースおよび暗号ロジックをサンドボックス内に移動させることで、検証者の TCB はコアロジックと Wasm ランタイムに縮小され、リモートコード実行脆弱性のリスクが大幅に低下します。
• スケーラビリティ: このモデルは、メンテナンスの負担を、すでに検証ライブラリを維持している TEE ベンダから、検証者運用者へ移行させます。
• 拡張性: このアーキテクチャは、複合アテステーション（ハードウェア層上のアプリケーション層の検証）をサポートし、Veraison などの他のフレームワークにも適応可能です。

結論: TrustMee は、リモートアテステーションをセキュリティやパフォーマンスを犠牲にすることなくプラットフォームに依存しないものにできることを実証しています。WebAssembly を活用して検証論理を証拠にバンドルすることで、現在の異種 TEE エコシステムの統合および保守のボトルネックを解決します。