アプリケーションをTEEインスタンスで実行するためのフレームワークEnarx
TL;DR
特定のプラットフォームやSDKに合わせてアプリケーションを書き換えることなく、TEE内でアプリケーションを実行可能なアプリケーションデプロイメントフレームワーク
CPUアーキテクチャに依存しないため、同じアプリケーションコードを複数のターゲットに展開することができ、クロスコンパイルやハードウェアベンダー間で異なる認証(Attestation)メカニズムなどの問題を抽象化することが可能
現在AMD SEVとIntel SGXサポート
本文
背景
アプリケーションが動作するコンピュータシステムのレイヤーを信頼しなければならない問題
コンピュータシステムは、スタックと呼ばれる層で構成されていると考えるのが一般的であり、 スタックは、さまざまなハードウェア、ファームウェア、ソフトウェアの層で構成されており、これらはほとんどの場合、異なる企業によって提供される。例えば各スタックをレイヤで分けると、下記の図のようになる(クラウドコンテナアーキテクチャの例)
https://gyazo.com/cd1c0d6468ea8380d670d47477b084a7
それぞれの色は、レイヤーまたはレイヤーのセットの異なる「所有者」を表す。これらの所有者は、さまざまなタイプがある(CPU, Kernelなど)
ワークロードの所有者であるユーザが、自身のアプリケーションが可能な限り安全であることを確認するためには、どのレイヤーにも悪意や危険性がないことを確認する必要がある。また、それが事実であったとしても、実際にホストシステムを実行しているクラウドサービスプロバイダーなどを信頼する必要がある
TEEベースの開発の難しさ
異なるプラットフォーム→ 別々に開発
異なるSDK→ 使用できる言語が限られる
異なる認証(Attestation)モデル→ 複雑で動的な信頼性の決定
異なるベンダー → 脆弱性管理の難しさ
また、TEEでワークロードをセットアップして実行することは、簡単なことではない
Enarx
上記の図のすべてのレイヤーを信頼しなければならないという問題を解決しようとしているプロジェクトで、TEEを使用して信頼する必要のあるレイヤーの数や所有者の数を最小限まで減らすことを実現する。下の図で言うと、CPU/ファームウェア(IntelやAMDなどのシリコンベンダーが提供)より上の層を信頼する必要がなくなり、実行中に信頼する必要があるのは、アプリケーションの次の層であるミドルウェア層(Enarx)。ApplicationとMiddlewareはTEE内に入る
https://gyazo.com/02849bab61b1f93679845119d745cfce
cipepser.icon CPUだけでなく、Enarxも信用するモデルなのか
特定のプラットフォームやSDKに合わせてアプリケーションを書き換えることなく、TEE内でアプリケーションを実行可能なアプリケーションデプロイメントフレームワーク
Process-Based, VM-BasedのTrusted Execution Modelsに対応
Process-Based: Intel SGX(not upstream), RISC-V Sanctum(no hardware)
VM-Based: AMD SEV, IBM PEF(no hardware), Intel TDX
Not a TEE: TrustZone, TPM
KeepランタイムはWebAssemblyをベースにしているため、開発者に実装言語の幅広い選択肢を提供
CPUアーキテクチャに依存しないため、同じアプリケーションコードを複数のターゲットに展開することができ、クロスコンパイルやハードウェアベンダー間で異なる認証(Attestation)メカニズムなどの問題を抽象化することが可能
AMD SEVとIntel SGXをサポート
構成図
全体
https://gyazo.com/ca7b99414fdc1e9a0649711f8a61d426
Keepランタイムアーキテクチャ
Keepとは
Enarxプロジェクト用語
Enarxのランタイムと関連部品をすべて内蔵したTEEインスタンスのこと
https://gyazo.com/b19bead4868cae7b9136b0692de89fec
cipepser.icon この図はまるっとTEEの中です?
Process or VM-Based Keep
Enarxのコア部分
WebAssembly(WASM)
スタックマシン ISA
サンドボックス化
すべてのブラウザでサポート
サーバーレスで爆発的に普及
急速に進む実装の改善
craneliftとwasmtime
WASI
W3Cスタンダードトラック
POSIXのサブセットに大きく影響されている
主な目標は
移植性
セキュリティ
libcでの実装
cipepser.icon SGX内で動かなそうだけど、どうしてるんだろう
Language Bindings
コンパイルターゲットとインクルード
例
Rust: --target wasm32-wasi
Application
Tenant (自社開発) or サードパーティベンダ
標準的な開発ツール
WebAssemblyにコンパイルされる
WASIインターフェースの使用
https://gyazo.com/c9a69d6af0adc37f22f736e27a6f91af
デプロイフロー
全体構成図を単純化した図
https://gyazo.com/5793f0b6fcc1466feaadb54a55666965
クライアント側とホスト側間でのデータのやり取りはEnarx client agentとEnarx host agent経由で行う
1. CLIまたはOrchestratorは、Enarx client agentに対してワークロードの配置を行う
2. Enarx client agentは、ホスト側のCPU + firmwareに対してKeep命令を送信
jkcomment.icon デプロイ先のホストが本物のTEEインスタンスを作成・起動しているかどうかを確認してもらうため?
3. ホスト側のCPUは、Enarx Keepを生成し、Enarx runtimeをロード
4. ホスト側のCPUは、クライアント側のEnarx client agentに対してKeep + Enarx runtimeのmeasurementを返却
jkcomment.icon 2と4はいわゆるAttestation handshake的な感じ?
jkcomment.icon これはRemote Attestationに当たる?
jkcomment.icon あ?AMD SEVはlocal attestationない?と言うことは実質Remote Attestation?
5. Enarx client agentは、CLIまたはOrchestratorに対して結果を返す(Ok or not OK)
jkcomment.icon 何に対する結果を返すんだろう
6. Enarx client agentは、ホスト側のCPUに対してApplicationのCodeとデータを暗号化して送信
7. ホスト側のCPUは、送られてきたコードとデータをEnarx Keep内でロード
jkcomment.icon もしソースコードを修正し、再デプロイする場合、この1~7のプロセスを踏まないといけない?
メリット
アプリケーションはRust, C, C++, C#, Go, Java, Python, Haskellなどの言語で実装可能(KeepランタイムはWasmベース)
デプロイが容易にできる
https://gyazo.com/f3e594118305e1f47faa933f5b663477
疑問点
Wasmベースなので、一般的なTEE上のアプリケーションと比べると性能的にはあまり期待できない(?)
結局Wasmに依存する形になるため、Wasmに脆弱性が発生したら影響ありそう
Sensitiveなデータとかの言葉が出てくるけど、具体的に言及されてはいない
ソースコードを頻繁に修正し、デプロイする場合のフローが気になる
参考
slides
Webinar
Twitter