元のタイトル: TEE アプリの保護: 開発者ガイド
原作者：prateek、roshan、siddhartha & linguine (Marlin)、krane (Asula)
編集者: Shew、GodRealmX
Apple がプライベート クラウドを発表し、NVIDIA が GPU で機密コンピューティングを提供して以来、信頼された実行環境 (TEE) の人気が高まっています。機密性の保証はユーザー データ (秘密キーを含む場合がある) の保護に役立ちますが、分離により、人間、他のプログラム、またはオペレーティング システムによって、その上にデプロイされたプログラムの実行が改ざんされないことが保証されます。したがって、暗号 x AI 分野の製品を構築するために TEE が広く使用されていることは驚くべきことではありません。
他の新しいテクノロジーと同様に、TEE も楽観的な実験の時期を迎えています。この記事は、開発者と一般読者が TEE とは何か、TEE のセキュリティ モデル、一般的な脆弱性、TEE を安全に使用するためのベスト プラクティスを理解するための基本的な概念ガイドを提供したいと考えています。 (注: 本文を理解しやすくするために、TEE 用語をより単純な同等の用語に意図的に置き換えています)。
TEEとは
TEE は、システムの他の部分からの干渉を受けることなくプログラムを実行できる、プロセッサーまたはデータセンター内の隔離された環境です。 TEE が他の部分から干渉されないようにするには、主に厳格なアクセス制御、つまりシステムの他の部分から TEE 内のプログラムやデータへのアクセスを制御する一連の設計が必要です。 TEE は現在、携帯電話、サーバー、PC、クラウド環境で広く普及しており、非常にアクセスしやすく、手頃な価格になっています。
上記の内容は曖昧で抽象的に聞こえるかもしれませんが、実際には、さまざまなサーバーやクラウド プロバイダーがさまざまな方法で TEE を実装していますが、その基本的な目的は、TEE が他のプログラムによって干渉されるのを避けることです。
おそらくほとんどの読者は、指紋で電話のロックを解除するなど、デバイスにログインするために生体認証情報を使用しているでしょう。しかし、悪意のあるアプリ、Web サイト、またはジェイルブレイクされたオペレーティング システムがこの生体認証情報にアクセスして盗むことができないようにするにはどうすればよいでしょうか?実際、データの暗号化に加えて、TEE デバイスの回路では、プログラムが機密データが占有するメモリおよびプロセッサ領域にアクセスすることはできません。
ハードウェア ウォレットは、TEE アプリケーション シナリオのもう 1 つの例です。ハードウェア ウォレットはコンピュータに接続し、通信をサンドボックス化しますが、コンピュータはハードウェア ウォレット内に保存されているニーモニック フレーズに直接アクセスすることはできません。どちらの場合でも、ユーザーはデバイス メーカーがチップを適切に設計し、TEE 内の機密データがエクスポートまたは閲覧されるのを防ぐための適切なファームウェア アップデートを提供していると信頼します。
セキュリティモデル
残念ながら、TEE 実装には多くの種類があり、これらのさまざまな実装 (IntelSGX、IntelTDX、AMDSEV、AWSNitroEnclaves、ARMTrustZone) には独立したセキュリティ モデル モデリング分析が必要です。この記事の残りの部分では、IntelSGX、TDX、AWSNitro について主に説明します。これらの TEE システムにはより多くのユーザーがおり、完全な開発ツールが利用可能であるためです。上記のシステムは、Web3 で最も一般的に使用される TEE システムでもあります。
一般に、TEE にデプロイされたアプリケーションのワークフローは次のとおりです。
- 「開発者」は、オープンソースであるかどうかのコードを作成します。
- 次に、開発者はコードを Enclave Image File (EIF) にパッケージ化し、TEE で実行できるようにします。
- EIF は、TEE システムを備えたサーバー上でホストされます。場合によっては、開発者は TEE を備えたパーソナル コンピュータを直接使用して EIF をホストし、外部サービスを提供できます。
- ユーザーは、事前定義されたインターフェイスを通じてアプリケーションを操作できます。
明らかに、ここには 3 つの潜在的なリスクがあります。
- 開発者: EIF を準備するために使用されるコードは正確には何をするのですか? EIF コードは、プロジェクト当事者が推進するビジネス ロジックに準拠していない可能性があり、ユーザーの個人データを盗む可能性があります。
- サーバー: TEE サーバーは EIF ファイルを期待どおりに実行しますか?それとも EIF は実際に TEE 内で実行されるのでしょうか?サーバーは TEE 内で他のプログラムも実行する場合があります。
- サプライヤー: TEE は安全に設計されていますか? TEE 内のすべてのデータをベンダーに漏らすバックドアはありますか?
幸いなことに、TEE には上記のリスクを排除するソリューション、つまり再現可能なビルドとリモート認証 (リモート認証ステーション) が用意されています。
では、反復可能なビルドとは何でしょうか?最近のソフトウェア開発では、外部ツール、ライブラリ、フレームワークなどの多数の依存関係のインポートが必要になることが多く、これらの依存関係ファイルには隠れた危険性もある可能性があります。 npm などのソリューションでは、依存ファイルに対応するコード ハッシュを一意の識別子として使用するようになりました。 npm が依存ファイルが記録されたハッシュ値と矛盾していることを検出した場合、依存ファイルが変更されたと見なすことができます。
反復可能なビルドは、一連の標準として考えることができます。その目標は、事前に指定されたプロセスに従ってビルドされている限り、任意のコードを任意のデバイスで実行したときに、最終的に一貫したハッシュ値を取得できることです。もちろん、実際にはハッシュ以外の積を識別子として使用することもできます。これをここではコード測定と呼びます。
Nix は、反復可能なビルドのための一般的なツールです。プログラムのソース コードが公開されると、誰でもコードをチェックして、開発者が異常なコンテンツを挿入していないかどうかを確認できます。誰でも Nix を使用してコードをビルドし、ビルドされた製品がデプロイされた製品と同じかどうかを確認できます。実稼働環境のコードメトリクス/ハッシュ。しかし、TEE でプログラムのコード メトリクスを知るにはどうすればよいでしょうか?これには、「リモート認証」と呼ばれる概念が含まれます。
リモート構成証明は、プログラムのコード メトリック、TEE プラットフォームのバージョンなどが含まれる、TEE プラットフォーム (信頼できるパーティ) からの署名付きメッセージです。リモート構成証明により、外部の監視者は、誰もアクセスできない安全な場所 (実際の TEE の xx バージョン) でプログラムが実行されていることを知ることができます。
反復可能なビルドとリモート認証により、すべてのユーザーが TEE で実行されている実際のコードと TEE プラットフォームのバージョン情報を知ることができるため、開発者やサーバーによる悪事が防止されます。
ただし、 TEE の場合、サプライヤーを信頼する必要が常にあります。 TEE サプライヤーが悪事を行うと、リモート証明書を直接偽造する可能性があります。したがって、プロバイダーが攻撃ベクトルの可能性があると考えられる場合は、TEE のみに依存することは避け、ZK またはコンセンサス プロトコルと組み合わせた方がよいでしょう。
TEEの魅力
私たちの意見では、TEE の特に人気のある機能、特に AI エージェントにとっての導入のしやすさは、主に次の点にあります。
- パフォーマンス: TEE は、通常のサーバーと同様のパフォーマンスとコストのオーバーヘッドで LLM モデルを実行できます。ただし、zkML は LLM の zk 証明を生成するために多くの計算能力を必要とします。
- GPU サポート: NVIDIA は、最新の GPU シリーズ (Hopper、Blackwell など) で TEE コンピューティング サポートを提供します。
- 正確性: LLM は非決定的であり、同じプロンプト単語を複数回入力すると異なる結果が得られます。したがって、複数のノード (不正証明を作成しようとするオブザーバーを含む) は、LLM 操作の結果について合意に達しない可能性があります。このシナリオでは、TEE で実行されている LLM は悪意のある者によって操作されることはないと信頼できます。TEE 内のプログラムは常に書かれたとおりに実行されるため、LLM 推論結果の信頼性を確保するには、TEE が opML やコンセンサスよりも適しています。
- 機密性: TEE 内のデータは外部プログラムには表示されません。したがって、TEE で生成または受信された秘密鍵は常に安全です。この機能を使用すると、このキーで署名されたメッセージが TEE の内部プロシージャから発信されたものであることをユーザーに保証できます。ユーザーは安全に秘密鍵を TEE に預け、いくつかの署名条件を設定することができ、TEE からの署名が事前に設定された署名条件を満たしていることを確認できます。
- ネットワーキング: 一部のツールを通じて、TEE で実行されているプログラムはインターネットに安全にアクセスできます (TEE が実行されているサーバーへのクエリや応答を明らかにすることなく、同時に第三者に正しいデータ取得の保証を提供します)。これは、サードパーティ API から情報を取得する場合に便利で、信頼できる独自のモデル プロバイダーに計算をアウトソーシングするために使用できます。
- 書き込みアクセス: zk ソリューションとは対照的に、TEE で実行されるコードはメッセージ (ツイートまたはトランザクション) を構築し、API および RPC ネットワーク アクセス経由で送信できます。
- 開発者に優しい: TEE 関連のフレームワークと SDK により、あらゆる言語でコードを記述し、クラウド サーバーと同じように簡単にプログラムを TEE にデプロイできます。
良くも悪くも、TEE を使用するかなりの数のユースケースは現在、代替手段を見つけるのが困難です。私たちは、TEE の導入によりオンチェーン アプリケーションの開発スペースがさらに拡大し、新しいアプリケーション シナリオの出現が促進される可能性があると考えています。
TEE は特効薬ではありません
TEE で実行されるプログラムは依然としてさまざまな攻撃やバグに対して脆弱です。スマート コントラクトと同様に、さまざまな問題が発生する傾向があります。わかりやすくするために、考えられる脆弱性を次のように分類します。
- 開発者の過失
- ランタイムの脆弱性
- 建築設計上の欠陥
- 運用上の問題
開発者の過失
開発者は、意図的または意図的でないコードによって、TEE 内のプログラムのセキュリティ保証を弱める可能性があります。これには以下が含まれます:
- 不透明なコード: TEE のセキュリティ モデルは外部の検証可能性に依存しています。コードの透明性は、外部のサードパーティによる検証にとって重要です。
- コード メトリクスに問題があります。コードが公開されている場合でも、コードを再構築してリモート構成証明でコード メトリクスをチェックし、リモート構成証明で提供されるコード メトリクスと照合するサードパーティが存在しない場合は、 。これは、zk 証明を受信しても検証しないのと似ています。
- 安全でないコード: TEE でキーを正しく生成および管理するように注意したとしても、コードには外部への呼び出し中に TEE 内でキーが漏洩する可能性のあるロジックが含まれています。さらに、コードにはバックドアや脆弱性が含まれている可能性があります。従来のバックエンド開発と比較すると、スマート コントラクト開発と同様に、ソフトウェア開発と監査プロセスに高い基準が必要です。
- サプライ チェーン攻撃: 最新のソフトウェア開発では、大量のサードパーティ コードが使用されています。サプライ チェーン攻撃は、TEE の完全性に対して重大な脅威をもたらします。
ランタイムの脆弱性
開発者がどれほど慎重であっても、実行時の脆弱性の犠牲になる可能性があります。開発者は、次のいずれかがプロジェクトのセキュリティ保証に影響を与えるかどうかを慎重に検討する必要があります。
- 動的コード: すべてのコードを透過的に保つことが常に可能であるとは限りません。場合によっては、ユースケース自体が、実行時に TEE にロードされる不透明なコードの動的実行を必要とすることがあります。このようなコードは簡単に秘密を暴露したり、不変条件を破ったりする可能性があるため、これを防ぐために細心の注意を払う必要があります。
- 動的データ: ほとんどのアプリケーションは、実行中に外部 API およびその他のデータ ソースを使用します。セキュリティ モデルはこれらのデータ ソースを含むように拡張され、これらのデータ ソースは DeFi におけるオラクルと同じ立場にあり、誤ったデータや古いデータさえも災害につながる可能性があります。たとえば、AI エージェントの使用例では、Claude などの LLM サービスに過度に依存しています。
- 安全ではなく不安定な通信: TEE は、TEE コンポーネントを含むサーバー内で実行する必要があります。セキュリティの観点から見ると、TEE を実行しているサーバーは、実際には TEE と外部のやり取りの間の完全な仲介者 (MitM) です。サーバーは、TEE の送信接続を覗いて、何が送信されているかを確認できるだけでなく、特定の IP を検閲し、接続を制限し、一方を騙して xx から送信されていると思わせる目的で接続にパケットを注入することもできます。 。
たとえば、暗号化されたトランザクションを処理できる TEE でマッチング エンジンを実行すると、ルーター/ゲートウェイ/ホストが送信元 IP アドレスに基づいてパケットをドロップ、遅延、または優先順位付けする可能性があるため、公正な順序の保証 (反 MEV) を提供できません。
建築上の欠陥
TEE アプリケーションで使用されるテクノロジ スタックは注意して使用する必要があります。 TEE アプリケーションを構築する場合、次の問題が発生する可能性があります。
- 大きな攻撃対象領域を持つアプリケーション: アプリケーションの攻撃対象領域は、完全に安全である必要があるコード モジュールの数です。攻撃対象領域が大きいコードは監査が非常に難しく、バグや悪用可能な脆弱性が隠れている可能性があります。これは、開発者のエクスペリエンスと矛盾することがよくあります。たとえば、Docker に依存する TEE プログラムには、Docker に依存しない TEE プログラムよりもはるかに大きな攻撃対象領域があります。成熟したオペレーティング システムに依存するエンクレーブは、最も軽量なオペレーティング システムを使用する TEE プログラムよりも攻撃対象領域が大きくなります。
- 移植性と生存性: Web3 では、アプリケーションは検閲に耐性がなければなりません。誰でも TEE を開始して、非アクティブなシステム参加者を引き継ぎ、TEE 内のアプリケーションをポータブルにすることができます。ここでの最大の課題は、キーの移植性です。一部の TEE システムにはキー導出メカニズムが組み込まれていますが、TEE 内のキー導出メカニズムが使用されると、他のサーバーは外部 TEE プログラム内でローカルにキーを生成できなくなり、通常、TEE プログラムは同じマシンに限定されます。携帯性を維持するには不十分です。
- 安全でない信頼のルート: たとえば、TEE で AI エージェントを実行する場合、指定されたアドレスがそのエージェントに属していることをどのように確認するのでしょうか。これが慎重に設計されていない場合、本当の信頼のルートは、TEE 自体ではなく、外部のサードパーティまたは主要なエスクロー プラットフォームになる可能性があります。
運用上の問題
最後になりますが、TEE プログラムを実行するサーバーを実際に実行する方法については、実践的な考慮事項もいくつかあります。
- 安全でないプラットフォーム バージョン: TEE プラットフォームはセキュリティ アップデートを受信することがありますが、これはリモート認証のプラットフォーム バージョンとして反映されます。 TEE が安全なプラットフォーム バージョンで実行されていない場合、ハッカーは既知の攻撃ベクトルを悪用して TEE からキーを盗む可能性があります。さらに悪いことに、TEE は今日は安全なプラットフォーム バージョンで実行されますが、明日は安全ではなくなる可能性があります。
- 物理的なセキュリティがない: 最善の努力にもかかわらず、TEE はサイドチャネル攻撃に対して脆弱になる可能性があります。サイドチャネル攻撃には通常、TEE が存在するサーバーへの物理的なアクセスと制御が必要です。したがって、物理的セキュリティは多層防御の重要な層となります。関連する概念はクラウド プルーフです。これにより、TEE がクラウド データ センターで実行されていること、およびクラウド プラットフォームに物理的なセキュリティが保証されていることを証明できます。
安全な TEE プログラムの構築
推奨事項を次の点に分けて説明します。
- 最も安全な解決策
- 必要な予防措置
- ユースケースに応じた推奨事項
1. 最も安全なソリューション: 外部依存関係なし
安全性の高いアプリケーションを作成するには、外部入力、API、サービスなどの外部依存関係を排除する必要がある場合があり、これにより攻撃対象領域が減少します。このアプローチにより、アプリケーションは完全性やセキュリティを損なう可能性のある外部とのやり取りがなく、自己完結型で動作することが保証されます。この戦略はプログラムの機能の多様性を制限する可能性がありますが、非常に高いレベルのセキュリティを提供します。
モデルがローカルで実行されている場合、ほとんどの CryptoxAI ユースケースでこのレベルのセキュリティを実現できます。
2. 必要な予防措置
アプリケーションに外部依存関係があるかどうかに関係なく、次のことは必須です。
TEE アプリケーションをバックエンド アプリケーションではなくスマート コントラクトとして扱い、更新頻度を低く保ち、厳密にテストします。
TEE プログラムの構築は、スマート コントラクトの作成、テスト、更新と同じくらい厳密である必要があります。スマート コントラクトと同様、TEE は非常に機密性の高い不変の環境で動作し、エラーや予期せぬ動作が資金の完全な損失を含む重大な結果につながる可能性があります。 TEE ベースのアプリケーションの整合性と信頼性を確保するには、徹底した監査、広範なテスト、および慎重に監査された最小限の更新が重要です。
コードを監査し、ビルド パイプラインを検査する
アプリケーションのセキュリティは、コード自体だけでなく、ビルド プロセス中に使用されるツールにも依存します。脆弱性を防ぐには、安全なビルド パイプラインが不可欠です。 TEE は、提供されたコードが期待どおりに実行されることを保証するだけであり、ビルド プロセス中に発生した欠陥を修正することはできません。
リスクを軽減するには、コードを厳密にテストおよび監査し、エラーを排除し、不必要な情報漏洩を防ぐ必要があります。さらに、反復可能なビルドは、特にコードが一方の当事者によって開発され、別の当事者によって使用される場合に重要な役割を果たします。反復可能なビルドにより、TEE 内で実行されるプログラムが元のソース コードと一致することを誰でも検証できるため、透明性と信頼性が確保されます。再現可能なビルドがなければ、TEE 内の実行可能プログラムの正確な内容を特定することはほぼ不可能であり、アプリケーションのセキュリティが危険にさらされます。
たとえば、TEE でワームの脳のシミュレーション モデルを実行するプロジェクトである DeepWorm のソース コードは完全にオープンです。 TEE 内のエグゼキュータは、Nix パイプラインを使用して再現可能な方法で構築されます。
監査または検証されたライブラリを使用する
TEE プログラムで機密データを扱う場合は、キー管理とプライベート データの処理に監査済みライブラリのみを使用してください。監査されていないライブラリはキーを公開し、アプリケーションのセキュリティを侵害する可能性があります。データの機密性と整合性を維持するために、十分に精査されたセキュリティを重視した依存関係を優先します。
常に TEE からの証拠を確認してください
TEE と対話するユーザーは、安全で信頼できる対話を確保するために、TEE によって生成されたリモート構成証明または検証メカニズムを検証する必要があります。これらのチェックを行わないと、サーバーは実際の TEE 出力と改ざんされたデータを区別できないように応答を操作する可能性があります。リモート構成証明は、TEE で実行されるコード ベースと構成の重要な証拠を提供します。リモート構成証明に基づいて、TEE 内で実行されるプログラムが期待どおりであるかどうかを判断できます。
特定の証明書は、オンチェーン (IntelSGX、AWSNitro)、ZK 証明を使用したオフチェーン (IntelSGX、AWSNitro)、またはユーザー自身またはホスティング サービス (t16z や MarlinHub など) によって検証できます。
3. ユースケースに応じた推奨事項
アプリケーションのターゲット ユース ケースとその構造に応じて、次のヒントがアプリケーションの安全性を高めるのに役立つ場合があります。
ユーザーによる TEE との対話が常に安全なチャネル経由で実行されるようにする
TEE が存在するサーバーは本質的に信頼できません。サーバーは通信を傍受したり変更したりする可能性があります。場合によっては、サーバーがデータを読み取るだけで変更しないことが許容される場合もありますが、データを読み取ること自体が望ましくない場合もあります。これらのリスクを軽減するには、ユーザーと TEE の間に安全なエンドツーエンドの暗号化チャネルを確立することが重要です。少なくとも、メッセージの信頼性と発信元を確認するための署名がメッセージに含まれていることを確認してください。さらに、ユーザーは、TEE がリモート証明書を提供していることを常にチェックして、正しい TEE と通信していることを確認する必要があります。これにより、通信の完全性と機密性が保証されます。
たとえば、Oyster は CAA レコードと RFC8657 を使用して安全な TLS 発行をサポートできます。さらに、WebPKI に依存しない Scallop と呼ばれる TEE ネイティブ TLS プロトコルも提供します。
TEE メモリは一時的なものであることを理解する
TEE メモリは一時的なものです。つまり、TEE の電源がオフになると、暗号化キーを含むその内容が失われます。この情報を保持する安全なメカニズムがなければ、重要なデータに永久にアクセスできなくなり、資金や業務が滞ってしまう可能性があります。
IPFS などの分散ストレージ システムを備えたマルチパーティ コンピューテーション (MPC) ネットワークは、この問題の解決策として使用できます。 MPC ネットワークはキーを複数のノードに分割し、単一のノードが完全なキーを保持しないようにしながら、必要に応じてネットワークがキーを再構築できるようにします。このキーを使用して暗号化されたデータは、IPFS に安全に保存できます。
必要に応じて、特定の条件が満たされていれば、MPC ネットワークは同じイメージを実行する新しい TEE サーバーにキーを提供できます。このアプローチにより、回復力と強力なセキュリティが保証され、信頼できない環境でもデータへのアクセスと機密性が維持されます。
別の解決策もあります。つまり、TEE は、関連するトランザクションをそれぞれ異なる MPC サーバーに配信し、MPC サーバーが署名した後、集約署名を実行し、最終的にトランザクションをチェーンにアップロードします。この方法は柔軟性が非常に低く、API キー、パスワード、または任意のデータの保存には使用できません (信頼できるサードパーティのストレージ サービスがなければ)。
攻撃対象領域を減らす
セキュリティ クリティカルなユースケースでは、開発者のエクスペリエンスを犠牲にして、周辺機器の依存関係をできるだけ減らすように努める価値があります。たとえば、Dstack には、Dstack の動作に必要なモジュールのみを含む最小限の Yocto ベースのカーネルが付属しています。 SGX (TDX 上) などの古いテクノロジを使用する価値がある場合もあります。このテクノロジでは、ブートローダーやオペレーティング システムが TEE の一部である必要がないからです。
物理的隔離
TEE の安全性は、TEE を人間の介入の可能性から物理的に隔離することでさらに強化できます。データ センターやクラウド プロバイダーで TEE サーバーをホストすることでこれを実現できますが、データ センターでも物理的なセキュリティを提供できると考えています。しかし、スペースコインのようなプロジェクトは、かなり興味深い代替手段である宇宙を模索しています。 SpaceTEEの論文は、衛星が軌道に入る過程で予想から逸脱していないかどうかを検証するために、打ち上げ後の慣性モーメントの測定などの安全対策を講じている。
複数の証明者
イーサリアムがネットワーク全体に影響を及ぼすバグのリスクを軽減するために複数のクライアント実装に依存しているのと同じように、マルチプロバイダーはセキュリティと回復力を高めるためにさまざまな TEE 実装を使用します。複数の TEE プラットフォームで同じ計算ステップを実行することにより、マルチ検証により、1 つの TEE 実装の脆弱性がアプリケーション全体を侵害しないことが保証されます。このアプローチでは、計算プロセスが決定的であること、または非決定的状況で異なる TEE 実装間の合意を定義する必要がありますが、障害の分離、冗長性、相互検証などの重要な利点も提供され、適切な選択である場合に信頼できるソリューションになります。セックス安心アプリの場合。
未来を見据えて
TEE は明らかに非常にエキサイティングな分野になっています。前述したように、AI が普及し、ユーザーの機密データに継続的にアクセスできるということは、Apple や NVIDIA などの大手テクノロジー企業が自社の製品で TEE を使用し、製品の一部として TEE を提供していることを意味します。
一方、暗号通貨コミュニティは常にセキュリティに重点を置いています。開発者がオンチェーン アプリケーションやユースケースを拡張しようとするにつれ、機能性と信頼性の前提の間で適切なトレードオフを提供するソリューションとして TEE が人気を博すようになりました。 TEE は完全な ZK ソリューションほど信頼性が最小化されていませんが、TEE が Web3 企業や大手テクノロジー企業の製品をゆっくりと統合するための最初の道になると期待しています。
