Azure Confidential Computing を入門したい人に贈る基本のき

皆様こんにちは、「Microsoft Azure Tech Advent Calendar 2022」の 12/21 担当です。

https://qiita.com/advent-calendar/2022/microsoft-azure-tech

最近、Azure Confidential Computing なるものに少し興味が沸いたので、理解しようともがいていました。しかし、新しめの技術である上にニッチであるということも相まって、なかなか全体像を理解するのに時間がかかっております (正直全然理解できてないです😫)。

ですが、これを最初に知っておけば助かったなぁ、と思える知識は増えてきたので、本日は「Confidential Computing って何？食えるのか？」みたいな状態だった過去の自分に向けて、Confidential Computing の基礎となる知識をまとめてみました。

自分はこの分野のセキュリティ専門家ではないので、正確でない情報が含まれる可能性がある点はご了承ください。間違いがあれば指摘いただけると喜びます。また、既にエキスパートだという方には少し物足りないかもしれないです。その場合は、代わりにクリスマスツリーにオーナメントを飾り付ける時間としてご活用ください🎄

はじめに

そもそも、コンフィデンシャル コンピューティング (Confidential Computing) とは何でしょうか。

自分がこの言葉を知ったのは Azure Confidential Computing がきっかけでしたが、クラウドサービスとして Confidential Computing を提供しているのは Azure だけではありません。様々なクラウド サービス事業者 (GCP、IBM、AWS) から同様のサービスが提供されています。これらの共通項は「使用中のデータ」を保護するという点です。

Azure Confidential Computing の公式ドキュメントから抜粋

Confidential Computing を促進するために発足したコミュニティーである Confidential Computing Consortium (CCC) でも、同じような表現で定義されています。以下はホームページに書いてあった説明文の抄訳です

(筆者抄訳)
コンフィデンシャル コンピューティングは、ハードウェアで実現された信頼可能な Trusted Execution Environment 内で計算を実行することで、使用中のデータ を保護します。この安全で隔離された環境は、アプリケーションとデータが使われている間も、データの不正アクセスや改ざんを防止します。この技術により、保護規制の対象となる重要なデータを管理する組織のセキュリティ水準を向上することが出来ます。

以上の内容から、Confidential Computing のやりたいこと、その実現方法、得られる効果は次の通りであることがわかります。

• 目的: 使用中のデータを保護する
• 方法: ハードウェアで実現された Trusted Execution Environment 内で計算を実行する
• 効果: 重要なデータを管理する組織のセキュリティ水準が向上する

なぜ必要なのか？

まず初めに抑えておきたいのは、実行環境には "信頼" の概念が存在する、という事実です^[1]。

基本的に、アプリケーションの実行環境は、抽象化と効率化のための便利な道具 (e.g. ファームウェア、ハイパーバイザ、カーネル、共有ライブラリ、ミドルウェア) をたくさん詰め込んだ、リッチな実行環境です。これらの便利な道具はたいてい第三者組織から提供されていて、実装が非公開なものも多く含まれます。

一般に、得体の知れないコンポーネントが増えるほどセキュリティリスクは増加するため、マイクロカーネルのような "poor" な実行環境がセキュリティ的に望ましいとされます。しかしながら、実際には、リッチな環境以外でアプリを動かすのはもはや現実的ではなくなりつつあります。Docker (Container) を禁止されただけで、白目を剥いて倒れるエンジニアもいるかもしれません😫。

そこで私たちは、明示的あるいは暗黙的に、「OS やハイパーバイザ、あるいはハードウェアから提供されるセキュリティ機能を利用すれば、安全にアプリケーションを実行できる」という仮定を置きます。例えば、無自覚のうちに、次のような安全対策機能を使っているのではないでしょうか。

• Linux や Windows では、ユーザー空間のアプリケーションがデバイスを操作する時、システムコールを発行する必要があります。システムコールが呼ばれると、それがシステムに悪影響を与えないかカーネルによって検証されます。
• VT-x を活用したハイパーバイザは、ゲスト上でセンシティブな命令 ^[2] が発行されると、それをトラップして命令の内容を検査します。

このようなセキュリティ機能がどのような仕組みで動いているのかすら意識しないレベルで、普段、私たちは様々なコンポーネント（開発ベンダーや開発コミュニティ）を信頼しているのです。実行環境を階層化して描いてみると、以下のような図で信頼の連鎖が表現できます（隣のレイヤー同士の関係のみを描いてますが実際には飛び飛びになることもあります）。

一般的な実行環境における信頼モデル。上位レイヤーに機能提供して、下位レイヤーを信頼する

さてさて、クラウド コンピューティングが当たり前の技術となって長い期間が経過しました。クラウドの世界では、責任共有モデルと呼ばれるセキュリティ プラクティスが一般的に推奨されます^[3]。つまり、「アプリケーションが動作しているインフラ (ハードウェア、ハイパーバイザ、OS) のセキュリティはクラウド事業者に任せて、ユーザーはアプリケーションのセキュリティに集中しましょう」という役割分担です。

ただ、考えるなと言われると、むしろ考えてしまうのが人間というもの^[4]。責任境界を明示されると、このクラウドプラットフォームは信頼に足り得るのか？ と考えたくなります。ハイパーバイザの実装や運用に問題はないのか…、どこのチップを使っていて脆弱性の対策はどんな風にやってるのか…、色々気になりますよね。クラウドプラットフォームは「実行環境に対する信頼」の概念を意識しやすい環境なのです。多くのクラウドプラットフォームがマルチテナントな環境であることも、懸念を強める要因の一つです。悪意あるユーザーが同じ物理マシン上でよからぬことを企んでいる可能性がありますし、実装ミス等が原因で意図せず自身が加害者サイドになることもあり得ます。

また、アプリケーションによっては、(クラウドに限らず) どんな環境で実行しようと、データの取り扱いに注意を払わなければならないアプリケーションも存在します。例えば、診療データを入力してガンの診断を行う医療系の機械学習システムや、送金トランザクションを処理する金融系システムなどが挙げられます。これらの背景にあるのは、データ流出時の社会的ダメージや金銭的補償に対するリスク管理や、法令による制約などです。こうしたアプリケーションでは、より一層どのコンポーネントを信頼するか、という点が重要になります。

もちろん、クラウド事業者側も信頼を得るために努力します。

例えば、Azure であれば、多くのコンプライアンス標準に適合したデータセンターを設計・運用しています (ISO 27001 や SOC I/II のような国際標準から、ISMAP や FISC のような日本固有の標準まで) ^[5]。

加えて、Safe Deployment Process ^[6]や、セキュリティに対しての投資^[7]を通して、サービスの信頼性向上に取り組んでいます。

ここで背中を押してくれるのが Confidential Computing です。Confidential Computing を使えば、「中間に位置するコンポーネントを信頼せず、ハードウェアだけを信頼する」モデルが可能になるんです👏

Confidential Computing を使う場合の信頼モデル。実際にはハードウェアの中でも CPU だけが信頼対象となる

Confidential Computing は、ハードウェアに実装されたメモリ暗号化などの機能によって、外部から隔離されたアプリケーションの実行環境を提供する技術です。ここでいう外部とは、アプリケーションより下位層に位置するコンポーネントも当然含まれます。例えば、悪意あるクラウド事業者によってアプリケーションの実行内容が閲覧・改ざんされるリスクを低く抑えることが出来ます。また、クラウドでなかったとしても、環境の隔離によるメリットが享受できます (例: OS に仕込まれた rootkit は隔離実行環境にアクセスできない)。Confidential Computing を使えば、より安心できる環境でアプリケーションを実行できるようになります。

改めて、モチベーションをおさらいします。

• 私たちは無意識のうちにいろんなコンポーネントを信頼してアプリケーションを実行している
• クラウド上で実行したり貴重なデータを取り扱う際は、ビジネス要件に応じて、信頼対象を極小化したい時がある
• Confidential Computing は、ハードウェアのみを信頼する計算環境を提供することで、この需要を満たす

Trusted Execution Environment

Confidential Computing の目的と背景が分かったところで、もう一歩先に踏み込んでみたいと思います。Confidential Computing は「ハードウェアで実現された Trusted Execution Environment 内で計算を実行する」ことで目的を果たすのでした。なので、ここでは Trusted Execution Environment (TEE) について深堀していきます。

結論から書くと、TEE とは次の性質を備えた実行環境のことです。

• 認められたアプリケーション/ソフトウェアだけが TEE の中で実行できる。
• TEE 内の使用中データは保護されていて、TEE 外のソフトウェアやハードウェアからは閲覧したり改ざんできない (保護対象は主にメモリやレジスタだがケースバイケース)。

正確な TEE の定義

文献 ^[8] や ^[9] の通り、TEE の定まった定義があるかと言われると微妙で、文脈に依存するところが大きいようです。トレンドとしては、ハードウェアベースである、信頼の起点はハードウェアである、Remote Attestation に対応する、の条件を満たす TEE が主流です。

TEE のアイディアは非常に単純です。それは、システム中の「信頼できるコンポーネント」と「信頼できないコンポーネント」を明確に区別する、というものです。たとえカーネルが自身の管理下にあるユーザー空間のメモリ領域にアクセスする場合でも、カーネルが信頼できないならアクセスは拒否されます。このようなアイディアは古くから存在していて、2002 年に開発された ARM TrustZone も TEE の一つです。

設計思想に応じて TEE の実現方法/性質は大きく異なりますが、Confidential Computing としてカテゴライズされる TEE は、「特別な CPU」を使ったハードウェアベース^[10]の TEE です。特別な CPU とは、CPU 内部に備えた暗号化装置をベースにした特殊な命令セットを提供することで、メモリページやレジスタへのアクセスを制限できる CPU を指します。例えば、Intel SGX に対応した Intel 製 CPU や、AMD SEV に対応した AMD 製 CPU です。

ハードウェアベースだからと言ってソフトウェア的な支援が全く不要かというとそんなことはありません。ハイパーバイザ/カーネルで特殊な命令セットに対応したり、アプリケーション側で TEE への対応が必要だったりもします。暗号化処理や隔離の仕組みが CPU で提供されているので、ハードウェアベースと言っているだけです。

ところで、TPM さえあれば Raspberry Pi 上で動作する TEE も存在します^[11]。つまり、特別な CPU を使わずとも、ソフトウェア実装に頼って TEE を実装することも可能だということです。それでは、なぜ Confidential Computing ではハードウェアベースの TEE に注目するのでしょうか？

それは、ハードウェアベースの TEE には次のようなメリットがあるためです。

• ソフトウェアで実装するより高速になる
• Trusted Computing Base (TCB) が小さくなる

TCB とは、特に根拠を示すことなく「安全である」と仮定できるコンポーネントの集合です。例えば、セキュアブート等の対策をしていないサーバーは TCB が非常に大きく、アプリケーションより下層に存在する全てのソフトウェアとハードウェア (e.g. CPU、ファームウェア、ハイパーバイザ、OS) が TCB に含まれす。ハードウェアのサポートで実現する TEE は TCB が小さくなる傾向にあり、そのため一定の評価を得ているという訳です。

公平のために補足しておくと、ソフトウェアベースの TEE と比較すると次のデメリットも存在する点に注意してください。全てはトレードオフです。

• ハードウェア費用が高くなりがち
• バグ修正や機能追加が難しい

TEE の例: Hyper-V VBS

TEE の例を一つ紹介します。Microsoft Hyper-V の Virtualization-Based Security (VBS) です。Confidential Computing としてカテゴライズされる TEE ではないですが、Microsoft Azure と関連があるので取り上げました。

• 仮想化ベースのセキュリティ (VBS) | Microsoft Learn
• Virtualization-based security (VBS) memory enclaves: Data protection through isolation - Microsoft Security Blog

VBS は、ハイパーバイザ (Hyper-V) とハードウェアの支援 (VT-X/AMD-v) を組み合わせて実現する TEE です。ハイパーバイザより上位に存在するゲスト OS (カーネルとアプリケーション) を丸ごと隔離実行環境化します。CPU の機能を使ってはいるものの、メモリの暗号化機能がハイパーバイザでソフトウェア実装されているので、トレンド (Confidential Computing) 的には TCB が大きすぎるという感じです。

一般的なゲスト OS (e.g. Ubuntu, Windows Server) を TEE で起動しても良いんですが、セキュアカーネルと呼ばれる特別なカーネルを TEE として起動して、その上でセキュリティ関連サービス (e.g. 仮想 TPM) を実行する、みたいな方法で使えます。

仮想マシンのための「仮想TPM」――仮想化ベースのセキュリティ（その2）：vNextに備えよ！ 次期Windows Serverのココに注目（35） - ＠IT

実は VBS は Azure とも関連が深い技術です。例えば、Azure VM のトラステッド起動や、SQL Server の Always Encrypted (Secure Enclave mode) で使用されています。

• トラステッド起動は、セキュアカーネル上の仮想 TPM を使って、VM ブート時のブートチェーン (ファームウェア、ドライバ) の完全性をチェックしてくれる Azure VM のオプション機能です。
  https://learn.microsoft.com/ja-jp/azure/virtual-machines/trusted-launch
• Always Encryped は、SQL Server データベースの特定列をサーバーサイドで暗号化する技術です。VBS を使うオプションを選択すると、DBMS の Alyways Encryped を担当するコードが TEE 内で実行されます。そのため、クエリを処理するために保護対象データを一時的に復号化しても、TEE による暗号化が引き続き有効となり、実質、復号化されることなくクエリの処理まで完了できる。
  https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-enclaves?view=sql-server-ver16

アテステーション

TEE を悩ます問題の一つに「完全性」があります。

一般に、暗号システムでは、情報セキュリティにおける 3 要素 (CIA) のうち機密性を担保するだけでは不十分で、完全性も担保しなければいけません。それは TEE でも同様です。つまり、外部のコンポーネントが TEE で実行しているコードやデータを読み書き出来ないことを保証するだけではダメで、TEE そのものや実行しているコードが改ざん (偽装) されてないことも保証できなければなりません。

「TEE で実行してるから安心や～」と思ってたら、実は本物そっくりの環境に偽装されていて、いつのまにかデータを抜き取られていた・・・みたいなことになったら困りますよね。

そこで、TEE に完全性を与える枠組みがあります。それが アテステーション (Attestation) です^[12]。

アテステーション (構成証明) とは、あるコンポーネントにとって、別のコンポーネントが信頼できるか判断するためのプロトコルです。TEE はアテステーションの応用の一つに過ぎず、アテステーション自体はもっと一般的な仕組みです。大別して次の 2 種類が存在します。

• リモート アテステーション: 物理マシンの垣根を越えて、リモートマシン上のコンポーネントの信頼性を検証する
• ローカル アテステーション: 同じ物理マシンに存在するコンポーネントの信頼性を検証する

一般的に、ローカル アテステーションは独自のインターフェイスによって実現されます。例えば AMD SEV-ANP の TEE だと、信頼性に関するレポートを特定のインターフェイス (CPU の命令セットとセキュアチャネル) を使って取得したりします。マシン内で閉じている話なので、状況に応じて自由に使っても特段支障はありません。

しかしリモート アテステーションは少し話が違います。検証する側と検証される側の間のプロトコル標準を定めておかなければ、ベンダーの数が増えると組み合わせ爆発が発生します。また、実際のユースケースとしても、リモート アテステーションは需要があります。HTTP ではクライアントとサーバーが異なるマシンであることが多いのと同様に、検証される側と検証する側もまた異なるマシンであることの方が多いのです。

そのため、リモート アテステーションに関しては、業界標準を定める動きがあります。現在、IETF の Remote Atestation procedureS (RATS) ワーキンググループにて、リモート アテステーションの標準化作業が進められています ^[13]。Confidential Computing のコンソーシアム (CCC) からも、RATS に準拠したアテステーションライブラリのリファレンス実装が OSS で提供する予定です。

RATS による terminology をベースに、リモート アテステーションの仕組みをざっくり説明していきます。最終的な目的は、Attester が信頼できるかの判断を Relying Party が下すこと、つまり Relying Party が「信頼できる」か「信頼できない」を出力することです。

<登場人物>

• Attester: 自分が信頼できることを Relying Party に証明したいコンポーネント
• Relying Party: Attester が信頼できる奴なのか疑っているコンポーネント
• Verifier: 信頼性の検証を円滑に進めるための仲介役

1. Attester が Evidence を Verifier に送信する
   • Attester は、自身が信頼できる人であることを示したいので、信頼できる人しか知らない情報をどこかしらから集めてくる。その情報が Evidence で、Claim と呼ばれる key/value ペアの配列で構成される。
   • Evidence のフォーマットは CWT, JWT, X.509 等が想定されている。
   • TEE の文脈だと、Attester には TEE が相当します。TEE は CPU/TPM にお願いをして、自分が TEE であることを示す証拠 (e.g. TEE 作成時にのみわかる RAM のハッシュ値) を署名付きで作成してもらう。
2. Verifier は Evidence を基にして、Attestation Result を作成して Relying Party に送信する
   • Evidence の完全性を保証するために Endorsement と呼ばれるコンポーネントが補佐してくれる場合もある。
   • Attestation Result も CWT, JWT, X.509 等のフォーマットが想定されている。
3. Relying Party は Attestation Result を基にして、Attester が信頼出来るか判定する
   • 正直、信頼度のスコア化や信頼判断のロジックを Verifier と Relying Party にどう配分するかは実装に依存する部分もある。

概念的には以上の流れの通りですが、実際には Attester と Verifier が同じコンポーネントで実装されていたり、Verifier と Relying Party が同じコンポーネントで実装されていたりします (前者をパスポート モデル、後者をバックグラウンドチェック モデルと呼ぶ)。細かいところまでは追わないので、詳細は「Remote Attestation Procedures Architecture」を参照ください。

https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/

Confidential Computing の TEE たち

抽象的な話が続いたので、ここからは具体的な技術の話、Confidential Computing で使われている TEE の実装を二つ紹介します。Intel SGX と AMD-SEV ANP です。どちらも、CPU 内部のメモリ暗号化装置でメモリを保護し、ファームウェアの助けを借りて完全性を担保します。

簡単な比較表をまとめておきましたので、中身はあんまりどうでもいいよって人はこちらをご覧ください。

テクノロジー	Intel SGX	AMD SEV-SNP
リリース	2015年	2021年
対応チップ	Skylake 以降の Intel CPU	SEV-SNP 対応の ARM CPU (例: EPYC 7003)
暗号化アルゴリズム	128bit AES-CTR	128bit AES-XEX
動作モード	ユーザーモード (Ring 3)	カーネルモード (Ring 0)
隔離対象	プロセス	VM
TCB	小さい	大きめ (ゲスト OS のカーネルが含まれるため)
アプリの修正	必要 (1st/3rd party 製 SDK で作成)	不要 (ハイパーバイザ/ゲスト OS のカーネルが吸収)
適切なワークロード	マイクロサービス※	レガシーで改修できないアプリケーション、 システムコールを大量に発行するアプリケーション
Remote Attestation	対応	対応

※ SGXv2 なら大規模データを扱うアプリケーションにも対応可能。

Intel SGX

最初に紹介するのは、Intel SGX です。

Intel SGX (Software Guard eXtensions) は、第 6 世代 Skylake 以降の Intel CPU で利用可能な拡張機能/命令セットです。Intel SGX では、Memory Encryption Engine (MEE) と呼ばれる暗号化エンジンを CPU に備えており、MEE が TEE 内で動作するアプリケーションのメモリ領域を暗号/復号化します。この暗号化されたメモリ領域を Enclave と呼びます。

SGX の特徴のひとつは、ユーザー空間のプロセスが Enclave を作成して、さらに Enclave 内で動作させるコードとデータをロードする点です。つまり、プロセス単位で TEE を形成します。信頼できるコンポーネント (TCB) は Enclave と Intel のハードウェア/ファームウェアだけで、ハイパーバイザ (VMM) はおろかカーネル (OS) も信頼しない脅威モデルを採用しています。

文献 ^[14] の Figure1 から抜粋

SGX が有効になったマシンでは、ブート時にシステムメモリの一部を Enclave やメタデータ用の領域として確保します。これを Processor Reserved Memory (PRM) と呼びます。PRM の最大値は CPU ごとに異なります。最大が 128 MB だった時代もありましたが、機種によっては 512 GB にも対応します^[15]。

PRM から Enclave 用に払い出されるメモリ領域を Enclave Page Cache (EPC) と呼びます。Enclave を作成するたびに確保されるので、ヒープのようなイメージです。EPC の最大値は PRM に依存します。例えば、PRM が 128 MB の時は、EPC の最大値は 92 MB です。仮想マシンごとに Enclave 環境を用意する場合は、各 Enclave に独自の EPC が割り当てられ、EPC の合計に対して制約がかかります。

Enclave 側で使えるメモリのサイズ (HeapMaxSize) と、Enclave に割り当てられる EPC のサイズは必ずしも一致しません。なぜなら、SGX は、メモリが枯渇すると EPC ページを (通常のメモリ領域に) ページアウト/インする機能を備えているためです。例えば、EPC の最大値が 92 MB のマシンでも、1 GB データをオンメモリで扱う (ように見える) Enclave アプリケーションを作成できます。ページアウト/インする時は、Enclave 固有の暗号鍵で暗号化/複合化されてからページが移動するので、データ漏洩の心配はありません。ただし、このオペレーションは非常に高コストで、ページングが頻繁に発生する状況ではメモリ アクセス レイテンシが 100 倍以上増加することもあります^[16]。

Sealing

Enclave コードが終了したりマシンの電源を落とす、それに伴って Enclave 内のデータも消去されます。そこで、SGX では Enclave データを安全に Enclave 外部に持ち出す仕組みが用意されています。具体的には、Enclave 固有の鍵を使ってデータを暗号化/複合化します。暗号化を sealing (seal) と呼び、複合化を unselaing (unseal) と呼びます。

Intel 提供の SDK を使う場合、sgx_seal_data と sgx_unseal_data で seal/unseal が可能です。また、seal したデータを外部記憶装置に永続化するシナリオに備えて、ファイルシステムを模倣するライブラリも提供されています。Intel® Protected File System Library を使うと、POSIX 標準の fopen や fwrite に似た API で sealing とファイル操作を一気通貫で実施できます^[17]。

SGXv2

従来、SGX は大規模データの取り扱いが苦手でした。これは主に PRM (EPC) の最大サイズが限定的 (128 MB や 256 MB 程度) だったことが原因です。しかし、新たな Ice Lake プロセッサ (3rd Generation Intel® Xeon® Scalable Processor) の登場により、この制限が大きく緩和されることになります^[18][19]。MEE の改良など、少しアーキテクチャが変更されたことから、新たなプロセッサでの Intel SGX を SGXv2 と呼ぶこともあります。

第 3 世代の Xeon Scalable Processor では、プロセッサごとの EPC 最大値が 512GB になりました。さらに、NUMA (マルチソケット) 構成に対応し、追加で EPC が必要な場合は他の NUMA ノード (ソケット) の助けを借りて EPC を増やすことが出来ます。これらの機能拡張によって、最大 1 TB の EPC に対応します^[20]。複数の NUMA ノードを使っても、パフォーマンスの劣化はあまり見られないようです^[16:1]。

アプリ開発

Enclave アプリケーションの開発者は、Intel 公式から提供されている Intel SGX SDK か、サードパーティ製の SDK (e.g. Open Enclave SDK, Confidential Consortium Framework) を使います。

https://learn.microsoft.com/en-us/azure/confidential-computing/enclave-development-oss#intel-sgx-compatible-tools

また、通常なら OS (カーネル) から提供される便利機能、たとえば、時間管理、マルチスレッディング、セマフォによる同期などが利用できません ^[21]。複数のコンポーネント間で協働させる場合は、Enclave 外部のスレッドやプロセスでの制御が必要になります。

参考文献

• Introducing the Intel® Software Guard Extensions Tutorial Series
  https://www.intel.com/content/www/us/en/developer/articles/training/introducing-the-intel-software-guard-extensions-tutorial-series.html
• SGX 101
  https://sgx101.gitbook.io/sgx101/
• Victor Costan and Srinivas Devadas, Intel SGX Explained
  https://eprint.iacr.org/2016/086.pdf

AMD SEV-SNP

次に、AMD による TEE テクノロジーである SEV-SNP を紹介します。名前は、Secure Encrypted Virtualization-Secure Nested Paging の略です。

Intel SGX と SEV-SNP が決定的に異なるのは、SEV-SNP はハイパーバイザ (仮想化) を支援する機構であり、VM を丸ごと隔離環境としてしまう点です。SEV-SNP を利用するために必要な修正はハイパーバイザとゲスト OS (カーネル) だけなので、アプリケーション側でコード変更する必要がないことが大きなメリットとして知られています。

SEV-SNP の脅威モデルでは、SEV-SNP 上で実行される VM (SEV-SNP VM) が信頼するのは、自身と AMD から提供されるハードウェア/ファームウェアだけです。他の VM やハイパーバイザは信頼しません。これを実現するため、AMD Secure Processor (AMD-SP) と呼ばれるプロセッサと、その内部に備えた AES ベースのメモリ暗号化エンジンを活用します。暗号化には 128bit AES (XOR-Encrypt-XOR) が使われ、暗号鍵は VM 起動時に生成されます。

SEV-SNP の脅威モデル (文献 ^[22] FIGURE 2 より抜粋)

ちょっとした歴史

SEV-SNP には前身となった技術が 2 つあります: SEV と SEV-ES です。

2016 年、AMD は Secure Encrypted Virtualization (SEV) を発表しました。SEV は、メモリの内容を AES ベースの暗号化アルゴリズムで保護することにより、VM をハイパーバイザから論理的に隔離します。しかしながら、SEV にはレジスタの内容を保護する機能がなく、例えば VMEXIT 時にレジスタの中身が丸見えになる問題がありました。

翌年 2017 年に SEV-ES (Encrypted State) が発表されます。SEV-ES では、GHCB と呼ばれるデータ構造でレジスタの値を保護しつつ、ハイパーバイザ側には必要最小限の値だけを渡すように変更することで、SEV の問題点を修正しました。ただし、再び新たな問題が発見されます。メモリページの整合性 (完全性) に関する脆弱性です。SEV/SEV-ES は、メモリページそのものを書き換えられてもそれを検知できないため、悪意あるハイパーバイザによるいくつかの攻撃 (e.g. Memory ReMapping、メモリページのリプレイ攻撃) を防止できないことが判明しました。

そこで AMD は、2021 年、SEV シリーズの最新となる SEV-SNP (Secure Nested Paging) を発表します。SEV-SNP では、メモリページに「所有者」の概念を導入し、各メモリページの所有者として「AMD ファームウェア」・「ハイパーバイザ」・「VM」のいずれかを割り当てます。そして、VM が所有するメモリページは、VM 以外から読み書きできない動作に変更しました。SEV-SNP は、Reverse Map Table (RMP) と呼ばれるデータ構造で、ホスト物理アドレスとゲスト物理アドレス間のマッピングと共にページの所有権を管理します。

しかしながら、Intel SGX 同様、SEV-SNP でも対応できない高度な物理攻撃もいくつか知られています^[23]。

リモート アテステーション

SEV / SEV-ES では、VM 起動時のローカル アテステーション (その VM が本当に SEV の TEE で起動されたかを検証する仕組み) は対応していたものの、起動後にアテステーションする方法は提供されていませんでした。

一方で、SEV-SNP の VM は、任意のタイミングで Secure Processor に対して Attestation Report を要求できます (SNP_GUEST_REQUEST 命令)。

(文献 ^[22:1] FIGURE 10 より抜粋)

Attestation Report は、VM が SNP-SEV 環境で動作していることを証明するのデータの集合で、CPU チップと TCB バージョンに固有な署名鍵 Versioned Chip Endorsement Key (VCEK) で電子署名されています。なお、TCB バージョンとは、アップグレード可能な AMD ファームウェアに付与されているバージョニング ID です。

証明書 (検証鍵) は、AMD が公開している Key Distribution Centre (KDC) と呼ばれる配布ポイントから入手できます。Remote Attestation プロトコルの Verifier や Relying Party に相当するコンポーネントは、以下の URL にアクセスして Attestation Report の署名を検証します。

https://kdsintf.amd.com/vcek/v1/<プロダクトファミリー>/$<チップ ID>?<TCB バージョン>

データには、チップ ID / ファームウェアバージョン / VM の情報 / 署名アルゴリズムなどのメタデータとともに、次のような重要な情報が含まれます。

• Measurement: VM 起動時の、VM に割り当てたメモリの値
• Report data: MSG_REPORT_REQ によって、レポート要求時に含めることができるオプショナルな 512 バイトの値。要求時に Report data を指定すると、AMD-SP は全く同じ値を Attestation Report に含めて返却する (Report は署名されている点に注意)。認証プロトコルにおける nonce に相当する。

参考文献

• AMD Secure Encrypted Virtualization (SEV) - AMD
• AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More
• https://github.com/AMDESE/sev-tool

最後に

本記事では、Confidential Computing の目的が「使用中のメモリデータを保護する」であることを念頭におきつつ、その実現方法であるハードウェアベースの TEE 技術を紹介しました。

今最も人気のある二つの TEE 手法 (Intel SGX と AMD SEV-SNP は、Azure Confidential Computing でもサービス提供されていて、手元に物理マシンを用意しなくても手軽に実践できるようになっています。また、アテステーションの Verifier としての役割を担うマネージドサービス、Azure Attestation Service も提供されています。

https://learn.microsoft.com/ja-jp/azure/confidential-computing/overview

https://learn.microsoft.com/ja-jp/azure/attestation/overview

今回は基礎知識のまとめだけでおなか一杯になってしまったのですが、上記サービスについてはまた別途どこかで紹介したいなと思います。これから Azure Confidential Computing を触ってみたい！という方にとって、本記事が少しでも有益な情報となっていれば幸いです🙏

脚注

1. 文脈によっては「信頼」が特定の意味を持つことがありますが、この記事では厳密に定義してないです。あるコンポーネントが別の組織によって作られたコンポーネントを「信頼」しているとは、それらがひとつの組織で作られた時と同等のセキュリティ強度を持つ、みたいな雰囲気で書いてます。ごめんなさい。

2. ハードウェアの状態を書き換えたり、状態に応じて処理が変化する命令

3. https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility

4. 皮肉過程理論

5. https://learn.microsoft.com/en-us/compliance/regulatory/offering-home

6. "安全なデプロイ プラクティスを発展させる | Azure のブログと更新プログラム" https://azure.microsoft.com/ja-jp/blog/advancing-safe-deployment-practices/

7. "Microsoft Azure's defense in depth approach to cloud vulnerabilities" https://azure.microsoft.com/ja-jp/blog/microsoft-azures-defense-in-depth-approach-to-cloud-vulnerabilities/

8. "Trusted Execution Environment: What It Is, and What It Is Not" https://hal.archives-ouvertes.fr/hal-01246364/file/trustcom_2015_tee_what_it_is_what_it_is_not.pdf

9. "3種類のTEE比較（Intel SGX, ARM TrustZone, RISC-V Keystone）" https://www.slideshare.net/suzaki/3teeintel-sgx-arm-trustzone-riscv-keystone

10. TEE の文脈では、Hardware-Based よりも Hardware-Assisted のほうが一般的な表記です。

11. "SofTEE: Software-Based Trusted Execution Environment for User Applications" https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9131703

12. Attestation Mechanisms for Trusted Execution Environments Demystified

13. https://datatracker.ietf.org/wg/rats/about/

14. Intel® Software Guard Extensions Tutorial Series: Part 1, Intel® SGX...

15. 3rd Gen Intel® Xeon® Scalable Processors Brief

16. Benchmarking the Second Generation of Intel SGX Hardware | Data Management on New Hardware

17. https://www.intel.com/content/dam/develop/external/us/en/documents/overviewofintelprotectedfilesystemlibrary.pdf

18. 3rd Gen Intel® Xeon® Scalable Processors Brief

19. Supporting Intel® SGX on Multi-Socket Platforms

20. What Technology Change Enables 1 Terabyte (TB) Enclave Page Cache...

21. Dave Thaler, Open Enclave SDK

22. https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf

23. A Systematic Look at Ciphertext Side Channels on AMD SEV-SNP | IEEE Conference Publication | IEEE Xplore