Confidential ComputingのためのService Mesh「MARBLERUN」
Edgeless SystemsはConfidential Computing分野で、以下の3つのブロダクトを提供している。
MARBLERUN (open source)
confidential computingのためのservice mesh
EDGELESS RT (open source)
Intel SGX SDK。Go, (Rust, C++, python) サポート
EDGELESS DB (private preview)
DB(SQL supported)に記録したデータに基づく秘匿処理
Rulesを定義可能
A発行の証明書を持つデバイスはデータ送信可能、
B発行の証明書を持つクライアントはデータにアクセスすることなく、アルゴリズムXによる分析処理を実行可能、
証明書C, Dを持つ複数主体がRulesを共同で更新可能
ここでは特にMARBLERUNについて紹介する。
nrryuya.icon > Edgeless Systemsのユースケース集
MARBLERUN
複数のTEEマシンを利用してConfidential Computing-basedサービスを提供する際に便利なService mesh
service mesh
サービス間コミュニケーションに必要な機能をオフロードし透過的に提供
サービスディスカバリ、ロードバランシング、分散トレーシング、TLS、サーキットブレーカーなど
Istio, Consul, Linkerd
一般的にそれぞれのサービスでサイドカー（プロキシ）として実装される
envoy
controle plane
ポリシー適用、ルーティング、各メトリクス集約など
data plane
https://gyazo.com/91112f1b5e9ba604c0b89762a40ba12b
cipepser.icon service間の通信は暗号化されるんです？Mutual-Attested-TLSしつつも、どのサービスに渡すみたいなルーティング関連の情報は平文なのかな
（注）以下の"Service mesh"はサービス間通信のReliabilityやObservabilityを高めるための仕組みとは違います。
servish mesh for confidential computing
以下のような、基本的なconfidential computingアプリケーションの実行ステップによりE2Eで秘匿性と完全性が保証されるのが特徴的である。
1. アプリケーション開発者がSGX環境のマシンでEnclaveにデプロイ
2. ユーザー（クライアントアプリケーション）がRemote Attestationでプログラムの完全性証明
3. 暗号化し、クライアントからデータを送信し、Enclave内で処理され、結果を暗号化しレスポンス
ここで、サービスが複数のSGX環境マシンに渡る場合、2のステップでは単一マシンの完全性しか証明・検証できないことになる。
ナイーブな解決策として以下があげられる。
ユーザーそれぞれのenclaveに対しRemote Attestationの検証
--> サービスの数だけ検証する必要がありツライ
サービス間の通信確立時に互いをRemote Attestation (Mutual-Attested-TLS) で検証するロジック自体をEnclaveに組み込んでおくことで、ユーザは単一のEnclaveのRemote Attestationを検証
--> 一般的に共通する部分を、Marblerunとして提供
nrryuya.icon > Anonifyも、RAの検証をしているBCのスマコンを検証するので近い
Marblerunのアプローチ
data-planeをサイドカーとしてデプロイするのではなく、アプリケーションロジックを実行するEnclave内に統合する。（現状アプリケーション実装の修正が少し必要）
Manifestによる一元的な設定管理
External Attestation検証時のCA機能
Controle Planeのホストマシン移行時のリカバリ機能
Controle Plane --> Data Planeへのsecret管理
https://gyazo.com/5f6b2cf2e98547de740337e870c96709
memo
Marblerunのcontrole planeがCAとして機能
controle planeがvirtual sealing keysをdata planeに配布し、その鍵を使ってメモリデータを暗号化してストレージに記録する。これによりマシンに依存せずdata planeは永続化したデータを復号可能に。
controle planeが固定のSGXマシン想定の場合は通常のsealingでcontole planeの状態は永続化
controle planeのマシンを移行可能にしておくために、RSA公開鍵であるRecovery Keyをmanifestに指定しておき、状態暗号共通鍵をRecovery Keyで暗号化して永続化することで、Recovery Keyに対応する秘密鍵で復号し別のマシンに移行可能
Future Workとして、Recovery Keyの秘密分散でガバナンス強化
Controle planeは以下のsecretをdata planeに提供
virtual sealing keys
shared symmetric keys
TLS credentials
Manifest定義
references