Appleがプライベートクラウドを導入し、NVIDIAがGPUで機密計算を提供して以来、信頼実行環境（TEE）がますます人気を集めています。それらの機密性の保証は、ユーザーデータ（たとえば秘密鍵を含む場合もあります）を保護するのに役立ち、隔離性はそれらの上で展開されたプログラムの実行が改ざんされることを防ぎます——人間であれ他のプログラムであれ、またはオペレーティングシステムであれ。したがって、Crypto x AI領域ではTEEを使用した製品の構築が一般的となっても不思議ではありません。
TEE が存在するサーバーは、本質的に信頼されていません。 サーバーは通信を傍受して変更できます。 サーバーがデータを変更せずに読み取ることが許容される場合もあれば、望ましくない場合でもデータを読み取ることが望ましくない場合もあります。 これらのリスクを軽減するには、ユーザーと TEE の間に安全なエンドツーエンドの暗号化チャネルを確立することが重要です。 少なくとも、メッセージの信憑性と発信元を確認するための署名が含まれていることを確認してください。 さらに、ユーザーは、TEE がリモート構成証明を提供していることを常に確認して、正しい TEE と通信していることを確認する必要があります。 これにより、通信の整合性と機密性が確保されます。 **
TEE の開発者ガイド
著者: Prateek, Roshan, Siddhartha & Linguine (Marlin), Krane (Asula) コンパイラ: Shew, GodRealmX
Appleがプライベートクラウドを導入し、NVIDIAがGPUで機密計算を提供して以来、信頼実行環境（TEE）がますます人気を集めています。それらの機密性の保証は、ユーザーデータ（たとえば秘密鍵を含む場合もあります）を保護するのに役立ち、隔離性はそれらの上で展開されたプログラムの実行が改ざんされることを防ぎます——人間であれ他のプログラムであれ、またはオペレーティングシステムであれ。したがって、Crypto x AI領域ではTEEを使用した製品の構築が一般的となっても不思議ではありません。
どの新技術と同様に、TEEは楽観的な実験期間を経験しています。この記事は、開発者や一般読者に基本的なコンセプトガイドを提供し、TEEとは何か、TEEのセキュリティモデル、一般的な脆弱性、TEEを安全に使用するためのベストプラクティスを理解させることを目的としています。*（注意：テキストを理解しやすくするため、わざとTEE用語をより簡単な同等語で置き換えました）。
TEEとは何ですか
TEEはプロセッサまたはデータセンター内の隔離環境であり、プログラムを実行する際にシステムの他の部分からの干渉を受けないようにします。TEEが他の部分からの干渉を受けないようにするには、厳格なアクセス制御が必要であり、これによりシステムの他の部分がTEE内のプログラムやデータにアクセスすることを制御します。現在、TEEは携帯電話、サーバ、PC、クラウド環境など、あらゆる場所で広く利用されており、したがってアクセスしやすく価格も合理的です。
上記の内容は曖昧で抽象的に聞こえるかもしれませんが、実際には異なるサーバーやクラウドプロバイダーがTEEを実装する方法は異なりますが、その根本的な目的はTEEが他のプログラムに干渉されないようにすることです。
!
ほとんどの読者は、指紋を使用して携帯電話をロック解除するなど、生体認証情報でデバイスにログインする可能性があります。しかし、悪意のあるアプリ、ウェブサイト、または脱獄したオペレーティングシステムがこれらの生体認証情報にアクセスして盗むことができないようにするにはどうすればよいでしょうか？実際、データを暗号化する以外に、TEEデバイス内の回路は、内存とプロセッサ領域の占有に関連する機微なデータにアクセスすることを許可していません。
ハードウェアウォレットはTEEのアプリケーションシナリオの別の例です。ハードウェアウォレットはコンピュータに接続され、サンドボックスと通信しますが、コンピュータはハードウェアウォレットに保存されているニーモニックに直接アクセスできません。上記の2つの場合、ユーザーはデバイスの製造元がチップを適切に設計し、適切なファームウェアの更新を提供してTEE内の機密データがエクスポートまたは表示されないようにすることを信頼しています。
セキュリティモデル
残念ながら、TEEの実装は非常に多岐にわたり、これらの異なる実装（Intel SGX、Intel TDX、AMD SEV、AWS Nitro Enclaves、ARM TrustZone）は、独自のセキュリティモデルのモデリングと分析が必要です。この記事の残りの部分では、Intel SGX、TDX、およびAWS Nitroについて主に説明します。これらのTEEシステムは、より多くのユーザーと完全に利用可能な開発ツールを備えています。これらのシステムは、Web3内でも最も一般的に使用されるTEEシステムです。
一般的に、TEEに展開されたアプリケーションのワークフローは次のようになります：
!
明らかに、ここには3つの潜在的なリスクがあります:
幸いなことに、現在のTEEには、上記のリスクを排除するための解決策があります。それは再現可能なビルド(Reproducible Builds)とリモートアテステーション(Remote Atteststations)です。
**再構築可能性とは何ですか？**現代のソフトウェア開発では、外部ツール、ライブラリ、フレームワークなどの大量の依存関係をインポートする必要がありますが、これらの依存ファイルには潜在的な脆弱性が存在する可能性があります。npmなどのソリューションでは、依存ファイルに対応するコードハッシュを一意の識別子として使用しています。npmは依存ファイルが記録されたハッシュ値と一致しないことを検出した場合、その依存ファイルが変更されたと見なすことができます。
!
そして、再現可能な構築は、一連の基準と見なすことができ、任意のコードが任意のデバイスで実行される場合、事前に定義された手順に従って構築すると、最終的には一致するハッシュ値を得ることができます。もちろん、実際の操作では、ハッシュ以外の生成物を識別子として使用することもできます。ここでは、それをコードの測定値と呼びます。(code measurement)
Nixは再現可能な構築に使用される一般的なツールです。プログラムのソースコードが公開されると、誰もがコードを確認して開発者が異常な内容を挿入していないことを確認できます。また、誰もがNixを使用してコードを構築し、構築された成果物がプロジェクトが本番環境に展開した成果物と同じコードメトリクス/ハッシュを持つかどうかを確認できます。しかし、TEE内のプログラムのコードメトリクス値をどのように知ることができるのでしょうか？ここで「リモートプルーフ」と呼ばれる概念が関わってきます。
!
リモートプルーフとは、TEEプラットフォーム（信頼された第三者）からの署名メッセージであり、プログラムのコードメトリック値、TEEプラットフォームのバージョンなどが含まれています。リモートプルーフにより、外部の観察者は、プログラムが安全な場所（xxバージョンの実際のTEE）で実行されていることを知ることができますが、誰もアクセスできません。
!
再構築とリモートプルーフにより、ユーザーはTEE内で実行される実際のコードとTEEプラットフォームのバージョン情報を知ることができるため、開発者やサーバーの不正行為を防ぐことができます。
しかし、TEEの場合、常にサプライヤーを信頼する必要があります。TEEサプライヤーが悪意を持っている場合、リモートプルーフを直接偽造することができます。したがって、サプライヤーを攻撃の可能性のある媒体と見なす場合、TEEだけに依存せず、むしろZKまたはコンセンサスプロトコルと組み合わせることをお勧めします。
TEEの魅力
私たちにとって、TEEの特に人気のある特徴、特にAIエージェントの展開にとっての友好性は、主に以下の点にあります：
良いか悪いかに関係なく、TEEを使用する多くのユースケースには、現時点では代替手段が見つかりにくいです。TEEの導入により、チェーン上のアプリケーションの開発空間がさらに拡大し、新しいアプリケーションシナリオが生まれる可能性があると考えています。
TEEは銀の弾丸ではありません
**TEEで実行されるプログラムは、依然としてさまざまな攻撃やエラーの影響を受けやすいです。**スマートコントラクト同様、さまざまな問題に直面する可能性があります。簡単のため、潜在的な脆弱性を以下のように分類します：
開発者の過失
意図的または意図しないが、開発者は意図的または意図しないコードによってTEE内のプログラムのセキュリティ保証を弱めることができます。これには次のものが含まれます:
ランタイムバグ
開発者は慎重になってもランタイムエラーの犠牲になる可能性があります。 開発者は、以下のいずれかがプロジェクトのセキュリティ保証に影響を与えるかどうかを注意深く考慮する必要があります：
例えば、TEEで実行されると、暗号化トランザクションのマッチングエンジンを処理できますが、このエンジンは公平な順序付けの保証（MEVに対する耐性）を提供できません。なぜなら、ルーター/ゲートウェイ/ホストは依然としてデータパケットの送信元IPアドレスに基づいて破棄したり、遅延させたり、優先的に処理したりすることができるからです。
アーキテクチャの欠陥
TEEアプリケーションで使用される技術スタックは注意が必要です。TEEアプリケーションを構築する際に、以下の問題が発生する可能性があります:
運用上の問題
最後に、TEEプログラムを実行するサーバーを実際に実行する方法に関する実際の注意事項がいくつかありますが、最後に重要ではありません。
安全なTEEプログラムの構築
私たちは私たちの提案を次のように分類します：
1. 最安全なソリューション：外部依存関係なし
高度安全なアプリケーションを作成するには、外部依存関係（外部入力、API、サービスなど）を排除し、攻撃面を減らす必要があります。この方法によって、アプリケーションが独立して実行され、その完全性やセキュリティが損なわれる可能性のある外部インタラクションがないことが保証されます。この方針はプログラムの機能の多様性を制限する可能性がありますが、非常に高いセキュリティを提供することができます。
モデルがローカルで実行されている場合、CryptoxAIのほとんどのユースケースにおいて、このレベルのセキュリティを実現することができます。
2. 必要な予防措置
アプリケーションに外部依存関係があるかどうかにかかわらず、次の内容は必須です！
TEEアプリケーションをバックエンドアプリケーションではなくスマートコントラクトとして扱い、更新頻度を低く保ち、厳格なテストを行います。
TEEプログラムの構築は、スマートコントラクトの作成、テスト、更新と同様に厳格である必要があります。スマートコントラクト同様、TEEは高度に機密で改ざんできない環境で実行され、誤りや予期しない動作が深刻な結果をもたらす可能性があります。これには資金の完全な損失も含まれます。TEEベースのアプリケーションの完全性と信頼性を確保するためには、徹底した監査、広範なテスト、そして最小限の慎重に監査された更新が不可欠です。
監査コードを確認し、ビルドパイプラインをチェックしてください
**アプリケーションのセキュリティはコードそのものだけでなく、ビルドプロセスで使用されるツールにも依存します。**安全なビルドパイプラインは脆弱性を防ぐ上で不可欠です。TEEは提供されたコードが予期した手順で実行されることを保証しますが、ビルドプロセスで導入された欠陥を修正することはできません。
リスクを低減するために、コードを厳密にテストおよび監査し、エラーを排除し、不必要な情報漏洩を防止する必要があります。さらに、再現可能なビルドは、コードが一方によって開発され、他方によって使用される場合に特に重要な役割を果たします。再現可能なビルドにより、TEE内で実行されるプログラムが元のソースコードと一致するかどうかを誰でも検証できるため、透明性と信頼性が確保されます。再現可能なビルドがない場合、TEE内で実行されるプログラムの正確な内容を特定することはほぼ不可能であり、アプリケーションのセキュリティが危険にさらされます。
例えば、DeepWorm（TEEで動作するワームブレインシミュレーションプロジェクト）のソースコードは完全にオープンです。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に依存しないTEEネイティブTLSプロトコルであるScallopという名前のものも提供されています。
TEEメモリは瞬時のものであることを知っています
**TEE内存は一時的であり、これはTEEが閉じられるとその内容（暗号化キーを含む）が失われることを意味します。**これらの情報を保存する安全なメカニズムがない場合、重要なデータに永久的にアクセスできなくなる可能性があり、それにより資金や運営が困難に陥る可能性があります。
IPFSなどの分散型ストレージシステムを持つ多者計算（MPC）ネットワークは、この問題の解決策として使用できます。 MPCネットワークは、鍵を複数のノードに分割し、単一のノードが完全な鍵を持たないことを保証しながら、ネットワークが必要な場合に鍵を再構築できるようにします。この鍵で暗号化されたデータは、IPFS上で安全に保存できます。
必要な場合、MPCネットワークは同じイメージを実行している新しいTEEサーバーに鍵を提供することができますが、特定の条件を満たす必要があります。この方法により、データのアクセス可能性と機密性を信頼できない環境でも確保することができる、柔軟性と強力なセキュリティが確保されます。
!
もう一つの解決策は、TEEが関連する取引をそれぞれ異なるMPCサーバーに渡し、MPCサーバーが署名して集約署名を行い、取引を最終的にチェーンに上げる方法です。この方法の柔軟性ははるかに低く、APIキー、パスワード、または任意のデータ（信頼できるサードパーティの保存サービスがない）を保存するためには使用できません。
!
攻撃面を減らす
安全な重要なユースケースに対して、開発者のエクスペリエンスを犠牲にする価値があり、周辺依存をできるだけ減らす試みが価値があります。たとえば、Dstackには、Dstackの動作に必要なモジュールのみを含むYoctoベースの最小カーネルが付属しています。また、TEEの一部としてブートローダーやオペレーティングシステムが不要であるため、SGX（TDXを超える）のような古い技術を使用する価値さえあります。
物理的な分離
TEEと人為的な介入を物理的に分離することで、TEEのセキュリティをさらに強化することができます。 TEEサーバーをデータセンターやクラウドプロバイダーにホスティングすることで物理的なセキュリティを提供できると信じていますが、Spacecoinのようなプロジェクトはかなり興味深い代替案を探っています。それが宇宙です。SpaceTEEの論文は、発射後の慣性モーメントなどの安全対策に依存し、衛星が軌道に入る過程で予想外の軌道に逸脱していないかを検証します。
マルチプルプルーフ
イーサリアムがネットワーク全体に影響を与えるバグのリスクを軽減するために、複数のクライアント実装に依存しているように、マルチプロバーズは異なるTEE実装方法を使用してセキュリティと柔軟性を向上させます。異なるTEEプラットフォームで同じ計算手順を実行することにより、マルチバリデーションは特定のTEE実装の脆弱性がアプリケーション全体に影響を及ぼすことはありません。この方法では計算プロセスが決定論的であること、または非決定論的な場合には異なるTEE実装方法間での合意が定義される必要がありますが、故障隔離、冗長性、クロスバリデーションなどの重要な利点を提供し、信頼性の保証が必要なアプリケーションにとって優れた選択肢となります。
!
将来を見据えて
**TEEは明らかに非常に興奮する分野となっています。**前述のように、AIの普及とユーザーの機密データへの持続的なアクセスは、AppleやNVIDIAなどの大手テクノロジー企業が製品にTEEを使用し、それを製品の一部として提供していることを意味しています。
一方、暗号コミュニティは常にセキュリティに非常に注力しています。開発者がチェーン上のアプリケーションとユースケースを拡張しようとする中で、機能と信頼のバランスを提供する解決策としてTEEが人気を集めています。TEEは完全なZKソリューションと同様に最小限の信頼を必要としないものではありませんが、Web3企業と大手テクノロジー企業の製品が初めて融合する経路として期待されています。