ログイン/ 登録

TEE開発者ガイド

2025/01/25 12:01

従う

Author: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Compiled by Shew, Fairy LoamGodRealmX

Appleがプライベートクラウドを発表し、NVIDIAがGPUの機密コンピューティングを提供して以来、信頼された実行環境(TEE)の人気が高まっています。そして、NVIDIA が GPU で機密コンピューティングを提供して以来、信頼された実行環境 (TEE) はますます人気が高まっています。その機密性の保証は、ユーザーデータ (秘密鍵が含まれる場合もあります) の保護に役立ち、一方、分離は、人間、他のプログラム、またはオペレーティングシステムのいずれによっても、その上に配置されたプログラムの実行が改ざんされないことを保証します。したがって、暗号×AIの領域が製品を構築するためにTEEを多用していることは驚くべきことではありません。

どんな新技術でもそうであるように、TEEは楽観的な実験期間を経ています。この記事では、TEEとは何か、TEEセキュリティモデル、一般的な脆弱性、TEEを安全に使用するためのベストプラクティスの方法について、基礎となる概念的なガイドを開発者と一般読者に提供したいと思います。(注: 文章を理解しやすくするために、TEEの用語を意識的に簡単なものに置き換えています)。

TEEとは

TEEとは、プロセッサーやデータセンター内の隔離された環境のことで、他のシステムからの干渉を受けずにプログラムを実行することができます。システムの他の部分からの干渉は一切ありません。TEEが他のシステムから干渉されないようにするためには、主に厳密なアクセス制御を含む一連の設計が必要です。TEEは現在、携帯電話、サーバー、PC、クラウド環境においてユビキタスであり、非常にアクセスしやすく、手頃な価格となっています。

上記は曖昧で抽象的に聞こえるかもしれませんし、実際、サーバーやクラウドのプロバイダによってTEEの実装方法は異なりますが、根本的な目的は、TEEが他のプログラムによって妨害されるのを防ぐことです。

読者の多くは、指紋で携帯電話のロックを解除するなど、生体認証情報でデバイスにログインしていると思われます。指紋で携帯電話のロックを解除するなど。しかし、悪意のあるアプリやウェブサイト、あるいはジェイルブレイクしたOSが、この生体情報にアクセスしたり盗んだりできないようにするにはどうすればいいのだろうか？実際、データを暗号化する以外に、TEEデバイスの回路は、機密データが占有するメモリとプロセッサ領域に、いかなるプログラムもアクセスできないようにしているだけです。

ハードウェアウォレットもTEEアプリケーションのシナリオの一例です。ハードウェアウォレットはコンピュータに接続し、サンドボックス内でコンピュータと通信しますが、コンピュータはハードウェアウォレット内に保存されたニーモニックに直接アクセスすることはできません。どちらの場合も、ユーザーは、デバイス製造者がチップを適切に設計し、TEE内の機密データがエクスポートまたは閲覧されないように適切なファームウェア・アップデートを提供することを信頼します。

セキュリティモデル

残念ながら、TEEの実装は多種多様であり、これらの異なる実装（IntelSGX、IntelTDX、AMDSEV、AWSNitroEnclaves、ARMTrustZone）は、すべて個別のセキュリティモデルでモデリングし、分析する必要があります。本稿の残りの部分では、IntelSGX、TDX、AWSNitro に焦点を当てます。なぜなら、これらの TEE システムには、より多くのユーザがおり、利用可能な開発ツールが充実しているからです。上記のシステムは、Web3内で最も一般的に使用されているTEEシステムでもあります。

一般的に、TEEにデプロイされたアプリケーションのワークフローは次のようになります:

「開発者」は、オープンソース化されていてもいなくてもよいコードを書きます。
EIFは、TEEシステムのあるサーバーでホストされます。
開発者は、EIFをホストするためにTEEを搭載したPCを使用し、一般ユーザに直接サービスを提供できる場合もあります
ユーザは、定義済みのインターフェイスを介してアプリケーションと対話できます。

明らかに、以下の3つのリスクがあります。

Developers: EIFを準備するために使用されるコードは、実際に何をするのでしょうか？EIFコードは、プロジェクトが公開するビジネスロジックに準拠していない可能性があり、プライベートなユーザーデータを盗む可能性があります。または、EIFは実際にTEE内で実行されていますか?サーバはTEE内で他のプログラムを実行することもあります
Vendor: TEEはセキュアに設計されていますか?TEE内のすべてのデータをベンダーに漏らすようなバックドアはありますか?

ありがたいことに、TEE には現在、再現可能なビルドとリモート認証という、これらのリスクを排除するソリューションがあります。再現可能なビルドとリモート認証です。）

では、再現可能なビルドとは何でしょうか?現代のソフトウェア開発では、外部ツール、ライブラリ、フレームワークなど、多くの依存関係をインポートする必要があることが多く、これらの依存関係ファイルは潜在的に危険なものでもあります。npmのようなプログラムは現在、依存ファイルに対応するコードのハッシュを一意の識別子として使用します。npmは、依存ファイルが記録されたハッシュと一致しないことを見つけると、依存ファイルが変更されたと見なすことができます。

また、反復可能なビルドは一連の標準として考えることができます。その目標は、事前に指定されたプロセスに従ってビルドされている限り、任意のコードを任意のデバイスで実行したときに、一貫したハッシュが得られることです。もちろん、実際には、ハッシュ以外の製品を識別子として使用することもできます。

Nixは反復可能なビルドのための一般的なツールです。アプリケーションのソースコードが公開されている場合、開発者が例外を挿入していないことを確認するために、誰でもコードを検査することができます。また、誰でも Nix を使用してコードをビルドし、ビルドの製品がプロジェクトチームによって本番環境にデプロイされた製品と同じコードメトリクス/ハッシュを持つことを確認することができます。しかし、TEE のアプリケーションのコードメトリクスをどうやって知るのでしょうか?これは、「リモート認証」と呼ばれる概念につながります。

リモート証明とは、「リモート認証」です。リモート証明は、TEEプラットフォーム（信頼される当事者）からの署名付きメッセージで、プログラムのコードメトリクス、TEEプラットフォームのバージョンなどが含まれます。リモート証明によって、外部のオブザーバは、プログラムが誰にもアクセスできない安全な場所（実際の TEE の xx バージョン）で実行されていることを知ることができます。

繰り返し可能なビルドとリモート証明により、どのようなユーザーでも以下のことが可能になります。繰り返し可能なビルドとリモート証明により、TEE 内部で実行されている実際のコードと TEE プラットフォームのバージョンを任意のユーザが知ることができ、開発者やサーバによる悪意のある行為を防止できます。

しかしながら、TEEの場合、そのベンダーを信頼する必要が常にあります。TEEのサプライヤが悪であれば、単にリモート証明を偽造することができます。したがって、ベンダーを攻撃ベクトルとして考えるなら、TEEだけに頼るのは避け、できればZKやコンセンサス・プロトコルと組み合わせるべきです。

TEEの魅力

私たちが考えるTEEの特徴は、特にAIエージェントへの展開のしやすさという点で特に人気があります。

パフォーマンス:TEEはLLMモデルを実行することができます。strong>コストオーバーヘッドは通常のサーバーと同様です。対照的に、zkMLはLLMのzk証明を生成するために多くの演算を消費します
GPUサポート：NVIDIAは最新のGPUファミリー（Hopper、
正しさ: LLMは非決定論的であり、同じキューワードの複数のエントリーは異なる結果をもたらします。その結果、複数のノード（不正な証明を作成しようとするオブザーバーを含む）がLLMの実行結果についてコンセンサスに達することはないかもしれない。このシナリオでは、TEEで実行されるLLMが悪者によって操作されることはなく、TEE内のプログラムが常に記述された通りに実行されることを信頼できます。このため、TEEはopMLやコンセンサスよりもLLM推論結果の信頼性を保証するのに適しています。-align:left;">機密性： TEE内のデータは、外部のプログラムからは見えません。したがって、TEE 内で生成または受信された秘密鍵は常に安全です。この機能は、その鍵で署名されたメッセージが TEE 内部のプログラムによるものであることをユーザに保証するために使用できます。ユーザーは自分の秘密鍵でTEEを自信を持って信頼し、いくつかの署名条件を設定することができ、TEEからの署名が事前に定義された署名条件を満たしていることを検証できます
NETWORKING: 多くのツールにより、TEEで実行されるプログラムは、インターネットに安全にアクセスすることができます（TEEが実行されているサーバにクエリやレスポンスを開示する必要はありません。）これは、サードパーティのAPIから情報を取得するのに便利であり、信頼できるがプロプライエタリなモデルプロバイダーに計算を委託するのに使用できます
書き込みアクセス: zkシナリオとは逆に、TEEで実行されるコードは、以下のことができます。
Developer Friendly:TEEに関連するフレームワークやSDKを利用することで、どんな言語でもコードを書くことができます。

良くも悪くも、TEEを使用するかなりの数のユースケースは、現在のところ代替手段を見つけるのが困難です。TEEの導入は、オンチェーンアプリの開発領域をさらに拡大し、新たなアプリケーションシナリオを促進する可能性があると考えます。

TEEは銀の弾丸ではありません

TEEで実行されるプログラムは、依然としてさまざまな攻撃やバグに対して脆弱です。スマートコントラクトと同じように、TEEはさまざまな問題に直面しがちです。スマートコントラクトと同じように、TEEもさまざまな問題を抱えやすいのです。: left;">実行時のバグ

アーキテクチャ設計の欠陥

運用上の問題

開発者の過失
開発者は、意図的であろうとなかろうと、意図的なコードによって、TEEのプログラムのセキュリティ保証を弱めることができます。
Opaque code:TEEのセキュリティモデルは、外部から検証可能なものに依存しています。コードの透明性は、外部の第三者による検証にとって重要です。
問題のあるコードメトリクス:たとえコードが公開されていたとしても、第三者がコードをリファクタリングし、リモート証明でコードメトリクスの値をチェックすることなく、リモート証明で提供されたコードメトリクスに基づいて、リモート証明で提供されたコードメトリクスをチェックします。リモート証明で提供されたコード・メトリクスに基づきます。これは、zkプルーフを受け取ったが、それを検証していないのと似ています。
安全でないコード: TEE 内でキーを正しく生成および管理するように注意していても、コードに含まれるロジックによって、外部からの呼び出し中に TEE 内でキーが漏れる可能性があります。さらに、コードにバックドアや脆弱性が含まれている可能性もあります。従来のバックエンド開発と比較して、スマートコントラクト開発と同様の、高水準のソフトウェア開発と監査プロセスが必要になります。
サプライチェーン攻撃：現代のソフトウェア開発では、サードパーティのコードが多く使われています。サプライチェーン攻撃は、TEEの完全性に重大な脅威をもたらします。
ランタイム脆弱性
どんなに注意深い開発者でも、ランタイム脆弱性の犠牲になる可能性があります。ランタイムの脆弱性の犠牲者になる可能性があります。
Dynamic code:すべてのコードを透過的に保つことが常に可能であるとは限りません。すべてのコードを透過的に保つことが常に可能であるとは限りません。ユースケース自体が、実行時に TEE にロードされた不透明なコードを動的に実行する必要があることもあります。そのようなコードは、簡単に秘密を漏らしたり、不変性を破ったりする可能性があり、これを防ぐために細心の注意を払わなければなりません。
Dynamic Data:ほとんどのアプリケーションは、実行中に外部APIやその他のデータソースを使用します。セキュリティモデルは、DeFiにおける予知能力者と同じ立場にあるこれらのデータソースを含むように拡張され、不正確なデータ、あるいは古いデータは、災害を引き起こす可能性があります。
安全で不安定な通信：TEEは、TEEコンポーネントを含むサーバー内で実行する必要があります。セキュリティの観点からは、TEE を実行するサーバーは、事実上、TEE と外部とのやりとりの間の完璧な中間者 (MitM) です。サーバーはTEEの外部接続を盗聴し、何が送信されているかを見ることができるだけでなく、特定のIPを検閲したり、接続を制限したり、xxから来たと相手をだますように設計された接続にパケットを注入したりすることもできます
たとえば、TEE内でマッチングエンジンを実行し、暗号化されたトランザクションを処理することができます。たとえば、暗号化されたトランザクションを処理できるマッチングエンジンをTEE内で実行する場合、ルーター/ゲートウェイ/ホストは依然として、パケットの発信元IPアドレスに基づいてパケットを破棄したり、遅延させたり、優先順位をつけたりできるため、マッチングエンジンは公正な順序保証（アンチMEV）を提供できません。
Architectural flaws
TEEアプリは、使用する技術スタックに注意する必要があります。
大きな攻撃対象領域を持つアプリケーション
TEEアプリケーションは、使用される技術スタックに注意する必要があります。アプリケーションの攻撃対象領域とは、完全に安全であることが保証されなければならないコードモジュールの数のことです。大きな攻撃面を持つコードは監査が非常に難しく、バグや悪用可能な脆弱性が隠されている可能性があります。また、これは通常、開発者の経験と矛盾します。例えば、Dockerに依存するTEEプログラムは、Dockerに依存しないTEEプログラムと比較して、攻撃対象領域が非常に大きくなります。成熟したオペレーティングシステムに依存するエンクレーブは、最も軽量なオペレーティングシステムを使用するTEEプログラムよりもはるかに大きな攻撃対象領域を持ちます
PORTABILITY AND ACTIVITY:Web3では、アプリケーションは検閲に強くなければなりません。は検閲に強いものでなければなりません。誰もがTEEを開始し、非アクティブなシステム参加者を引き継ぎ、TEE内のアプリケーションをポータブルにすることができます。ここでの最大の課題は、鍵の移植性です。いくつかのTEEシステム内には鍵生成メカニズムが存在しますが、TEE内の鍵生成メカニズムが使用されると、他のサーバーは外部のTEEアプリケーション内でローカルに鍵を生成することができなくなります。そのため、TEEアプリケーションは通常同じマシンに限定され、移植性を維持するには十分ではありません
安全でない信頼のルート: たとえば、TEEでAIエージェントを実行する場合、指定されたアドレスがエージェントに属していることをどのように検証するのでしょうか。ここを注意深く設計しないと、真の信頼のルートがTEE自体ではなく、外部のサードパーティやキーホスティングプラットフォームである可能性につながります。
運用上の問題
最後になりますが、TEEを実行するサーバーを実際にどのように実行するかという実用的な問題があります。
Insecure Platform Versions:TEEプラットフォームは、時折、プラットフォームのバージョンとして反映されるセキュリティアップデートを受け取ります。リモートプルーフにプラットフォームバージョンとして反映されます。TEE が安全なプラットフォームバージョンで実行されていない場合、ハッカーは既知の攻撃ベクトルを使用して TEE からキーを盗むことができます。さらに悪いことに、TEE は今日安全なプラットフォームバージョンで実行されていても、明日には安全でなくなっているかもしれません。
物理的なセキュリティがない:最善の努力にもかかわらず、TEEはサイドチャネル攻撃に対して脆弱である可能性があります。したがって、物理セキュリティは、重要な深層防御レイヤです。関連する概念として、クラウド認証があります。クラウド認証では、TEEがクラウドデータセンターで実行されていることと、クラウドプラットフォームが物理的なセキュリティを保証していることを証明できます。
セキュアなTEEプロセスを構築する
私たちの推奨事項を以下のポイントに分けました。
最も安全な選択肢
次のことを行ってください。
ユースケースに依存する推奨事項
1.最も安全なシナリオ：外部依存なし
1.strong>
高度にセキュアなアプリケーションを作成するには、外部入力、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発行をサポートすることができます。
TEEのメモリが一時的であることを知る
TEEのメモリが一時的であることを知る
TEEのメモリは一過性であるため、TEEがシャットダウンされると、その内容（暗号化キーを含む）は失われます。この情報を保存する安全なメカニズムがなければ、重要なデータが永久にアクセスできなくなり、資金調達や業務が危険にさらされる可能性があります。
IPFSのような分散型ストレージシステムを備えたマルチパーティコンピューティング（MPC）ネットワークは、この問題の解決策として使用できます。MPCネットワークは複数のノードにキーを分割し、単一のノードが完全なキーを保持しないようにすると同時に、必要に応じてネットワークがキーを再構築できるようにします。この鍵で暗号化されたデータは、IPFS上に安全に保存することができる。
必要であれば、MPCネットワークは、特定の条件が満たされていれば、同じイメージを実行している新しいTEEサーバーが鍵を利用できるようにすることができます。このアプローチにより、弾力性のある堅牢なセキュリティが保証され、信頼されていない環境でもデータへのアクセス性と機密性が維持されます。
別のソリューションがあります。>すなわち、TEE は関連するトランザクションを別々の MPC サーバーに渡し、MPC サーバーはそれらに署名した後、集約署名を実行し、チェーン上のトランザクションを確定する。このアプローチははるかに柔軟性に欠け、APIキー、パスワード、または任意のデータを保存するために使用することはできません（信頼できるサードパーティのストレージサービスはありません）。
攻撃面を減らす
セーフティクリティカルなユースケースの場合、開発者のエクスペリエンスを犠牲にしてでも、可能な限り多くの周辺依存を最小限に抑えるよう努力する価値があります。例えば、Dstackには、Dstackの動作に必要なモジュールだけを含む、最小限のYoctoベースのカーネルが付属している。TDXを超える）SGXのような、TEEの一部であるブートローダやOSを必要としない古い技術を使うことは、価値があるかもしれません。
物理的な分離
TEEのセキュリティは、人間の介入の可能性からTEEを物理的に分離することでさらに強化できます。データセンターやクラウドプロバイダーにTEEサーバーをホスティングすることで、物理的なセキュリティを提供するデータセンターを信頼することができます。しかし、Spacecoinのようなプロジェクトは、宇宙というかなり興味深い代替手段を模索している。SpaceTEEの論文は、打ち上げ後の慣性モーメントを測定し、衛星が軌道に乗る際に予想から外れていないことを確認するといったセキュリティ対策に依存している。
マルチプロヴァー
イーサリアムがネットワーク全体に影響を及ぼすバグのリスクを減らすために複数のクライアント実装に依存しているのと同じように、マルチプロヴァーは異なるTEE実装スキームを使用しています。セキュリティと耐障害性を向上させるために、異なるTEE実装スキームを使用します。複数のTEEプラットフォームで同じ計算ステップを実行することで、multiproversは、1つのTEE実装の脆弱性がアプリケーション全体を危険にさらすことがないようにします。このアプローチでは、計算プロセスが決定論的であるか、または非決定論的な状況で異なるTEE実装シナリオ間のコンセンサスを定義する必要がありますが、障害分離、冗長性、相互検証などの重要な利点も得られるため、信頼性の保証が必要なアプリケーションに適した選択肢となります。
Looking Ahead
TEEは明らかに非常にエキサイティングな分野になっています。前述したように、AIのユビキタス化と機密性の高いユーザーデータへの継続的なアクセスは、AppleやNVIDIAのような大手テック企業が自社製品にTEEを使用し、提供するサービスの一部としてTEEを提供していることを意味します。
一方、暗号コミュニティはセキュリティに非常に注力してきました。開発者がオンチェーンアプリやユースケースを拡張しようとする中、機能性と信頼性の前提を適切にトレードオフするソリューションとして、TEEが人気を博しています。TEEは、完全なZKソリューションほど信頼を最小化するものではありませんが、TEEは、Web3企業が提供するものを大手テック企業が提供するものに徐々に収束させる最初の手段になると期待しています。