【仮日本語訳】Common Terminology for Confidential Computing（プライバシーテック協会）

本レポートでは、Confidential Computing（機密コンピューティング）の定義や関連する用語の整理、その技術的影響を解説しています。

※Confidential Computing Consortium（以下、CCC）が作成・公開している「White Papers & Reports「Common Terminology for Confidential Computing」を、CCCの了承の元、プライバシーテック協会およびその正会員である株式会社Acompanyが翻訳したものです。

Transcript

1. Common Terminology for Confidential Computing （仮⽇本語訳） A Publication of The Confidential Computing Consortium December 2022 （仮⽇本語訳発⾏: 2025 年 11 ⽉）
2. 2 【翻訳に関する注記】 本⽂書は、Confidential Computing Consortium（以下、CCC）が作成・公開している White Papers & Reports ⽂書を、CCC の了承の元、プライバシーテック協会の正会員 である株式会社 Acompany が主体となって翻訳したものです。 各レポートは参考のため の仮⽇本語訳であり、理解しやすいように補⾜した箇所や、あえて原⽂を忠実に翻訳し ていない箇所が含まれます。正確な内容については原⽂をご参照ください。 また、以下の点をご理解のうえ、お役⽴ていただけますと幸いです。 l 各レポートに関する著作権は CCC に帰属します。 l 各レポートについては、⾃らの判断でご利⽤ください。当協会および株式会社 Acompany は責任を負いません。 l 本レポートは当協会および株式会社 Acompany の判断において翻訳・公開して おります。当協会に参加する他の各企業は、翻訳に関与しておらず、必ずしも各 レポートの内容を⽀持しているとは限りません The documents introduced here are part of the White Papers & Reports created and published by the Confidential Computing Consortium (“CCC”). The translation was primarily carried out by Acompany Co., Ltd., a full member of the Privacy Tech Association, with the consent of CCC. Please note that these translations are provisional Japanese versions provided for reference. In some cases, supplementary explanations have been added for clarity, or the text has not been translated in strict fidelity to the original. For the most accurate content, please refer to the original documents. We hope you'll understand and find the following points useful: l The copyright for each report belongs to CCC. l Please use each report at your own discretion. Neither this association nor Acompany Co., Ltd. is responsible for its usage. l This report has been translated and made public at the discretion of this association and Acompany Co., Ltd. Other companies participating in this association were not involved in the translation and do not necessarily endorse the contents of each report.
3. 3 ⽬次 1. はじめに .................................................................................................................................. 4 2. パッケージングモデルの⽤語 ................................................................................................. 5 3. 分離⼿法 .................................................................................................................................. 6 4. アテステーション（ATTESTATION） ............................................................................... 10 5. 結論/まとめ ........................................................................................................................... 10 参考⽂献 ........................................................................................................................................ 11
4. 4 1. はじめに 多くの企業やオープンソースプロジェクトが、 「ハードウェアに基づきアテステーシ ョンされた Trusted Execution Environment (TEE)」 （原⽂： 「hardware-based, attested Trusted Execution Environments (TEEs)」 ）を基盤とする類似のパラダイムを説明する 際に、似た⽤語を使い始めている。そのため、こうした新しい機能をさまざまな機能ド メインにどのように応⽤されているかを説明するうえで、ベンダーが⼀貫した⽤語を⽤ いることが⾮常に重要になってきている。 Confidential Computing Consortium (CCC)は、Confidential Computing（⽇本では 「機密コンピューティング」とも⾔う）を「ハードウェアベースに基づきアテステーシ ョンされた Trusted Execution Environment（TEE）で計算を実⾏することにより、使 ⽤中のデータを保護すること」 （原⽂： 「the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment」 ）と定義[1] している。また、TEE を構成する 3 つの主要な属性として、data integrity（データの完 全性） 、 data confidentiality（データの機密性） 、code integrity（コードの完全性）を挙 げ て い る 。「 Confidential Computing: Hardware-Based Trusted Execution for Applications and Data 」 で 説 明 さ れ て い る よ う に 、 さ ら に 4 つ の 属 性 〜 code confidentiality（コードの機密性） 、programmability（プログラム容易性） 、recoverability （リカバリー容易性） 、attestability（アテステーション可能性）〜が存在する場合もあ るが、計算環境が Confidential Computing として分類されるためには、attestability（ア テステーション可能性）が唯⼀の必須条件である。 本稿では、 「confidential container」 や 「confidential virtual machine」 など、 「confidential」 という語を説明的な接頭辞として⽤いた新たな応⽤例を定義している。 これらの⽤語は すでに、マーケティング資料や商⽤製品、関連するオープンソースプロジェクトの中で も使われ始めている。 また、Confidential Computing およびそれに関連する「confidential xxx」といった⽤ 語に焦点を当てている。⽬的は、コンピュータアーキテクチャに Confidential Computing を組み込むことで⽣じる影響を説明するための、共通の⽤語を提供するこ とである。 これにより、 コンピューティング・ワークロードの分離によって⽣じる、 種々 の潜在的アーキテクチャの変化を⼗分に説明し、 アプリケーション全体とそのデータの セキュリティ保護に及ぼす影響を適切に評価できるようにすることを⽬指している。 メモリ分離（memory isolation）は、Confidential Computing によって導⼊された新 しい要素の 1 つである。実⾏中のアプリケーションを保護できることは、コンピュー
5. 5 タ・セキュリティへのアプローチを⼤きく変える。サイバー攻撃は多くの場合、メモリ の内容の侵害（メモリ内のデータの抽出や改ざん）から始まる。そのため、効果的なメ モリ分離を実現する機能は、 このような脅威に対する最善の緩和策のひとつと認識され ている。しかし、使⽤中（in use）のデータの保護は、アプリケーション全体における セキュリティの⼀部に過ぎない。機密性の⾼いワークロードとそのデータを、どこにあ っても完全に保護するには、 保管中 （at rest） および転送中 （in motion） の保護に加え、 Confidential Computing を組み合わせた統合ソリューションが必要である。 例えばクラウドコンピューティングでは、 使⽤中のデータの保護は基本要件となりつ つある。これにより、クラウドベンダーのインフラ上で実⾏されるアプリケーションや そのデータについて、クライアント⾃⾝がデータの保護を制御できる。すべてのクラウ ドは、⼀定の信頼関係に基づいた責任共有モデルを採⽤しているが、Confidential Computing は、このモデルにおける責任の分離とリソースの分離をより強固なものに する。 2. パッケージングモデルの⽤語 このドキュメントでは、以下の⽤語を定義する。 l confidential library（コンフィデンシャルライブラリ）: ハードウェアベースでア テステーション済みの TEE の内部で実⾏されるライブラリ（例えば「エンクレ ーブ」 ） のこと。 TEE 内の他のライブラリやホスティング環境から保護され、 TEE 外のアプリケーションから利⽤される可能性のあるもの。 l confidential process（コンフィデンシャルプロセス）: ハードウェアベースでア テステーション済みの TEE の内部で実⾏されるプロセス（例えば「Trusted Application」 ）のこと。これは、TEE 内の他の confidential process やホスティン グ環境から保護される。 l confidential container（コンフィデンシャルコンテナ）: OCI コンテナランタイ ムによって起動される Open Container Initiative (OCI)[2]に準拠したコンテナイ メージのエントリポイントプロセスのこと。このプロセスは、ハードウェアベー スの TEE の内部で実⾏され、TEE 内の他の confidential library やホスティング 環境から保護される。 l confidential VM（コンフィデンシャル VM）: ハードウェアベースでアテステー ション済みの TEE の内部で実⾏される仮想マシン（VM）のこと。これにより、 VM イメージ全体のコードとデータはハイパーバイザーとホストオペレーティ ングシステムから保護されるだけでなく、 他の confidential VM や TEE 内のホス
6. 6 ティング環境からも保護される。 上記の定義において、ホスティング環境には、TEE 内で実⾏されるものの、複数の confidential library、 confidential process、 confidential container、 または confidential VM 間で共有される部分が含まれることがある。このような場合、 「confidential（コンフィ デンシャル） 」という⽤語は、TEE インスタンス全体の共有環境においても、コンフィ デンシャルなコードやデータが保護されていること、つまり、追加の分離レイヤーが存 在することを意味する。例えば、ネストされた（階層的な）分離境界が使⽤されるケー スもある。 コードのコンフィデンシャルな部分が、VM イメージ全体に含まれる confidential library のように、 より⼤きなパッケージの⼀部である場合は、 前置詞 「with」 を⽤いて、 「VM with a confidential library（confidential library を含む VM） 」のように表現する。 これは、VM イメージ全体を TEE 内で実⾏する必要がある「confidential VM」とは対 照的である。 コードの機密部分が、 個別にインストールできる複数のパッケージで構成されている ものの、それらの間にセキュリティ上の分離がない場合は、前置詞「in」を⽤いて、 「a process in a confidential VM（confidential VM 内のプロセス） 」のように表現する。 3. 分離⼿法 前述のパッケージモデルの⽤語で⽰した各機能は、TEE のハードウェアおよびファ ームウェアと連携して動作するソフトウェアによって実現される。これらの機能の組み 合わせにより、データの機密性、データの完全性、そして／またはコードの完全性が確 保される。データの機密性は、実⾏時に、プロセッサ（CPU、あるいは GPU などの他 の処理ユニット） 内や場合によっては RAM 内に、 TEE コンテキストを分離すること によって実現される。データ使⽤中（data-in-use）の保護を実現する⽅法論には、複数 のアプローチが存在する。 以下に、このアプローチの例として、CPU が TEE 内のデータへのアクセスを制限す る⽅法の例を 3 つ挙げる。 l アクセスコントロール検証（Access Control Validation）: メモリの特定領域へのア クセスを、特定のプロセスやコンテキストに限定する⽅法。 l アドレス変換 （Address Translation）: メモリをセグメント化し、その領域を TEE の外部からは直接アドレス指定できなくする⽅法。
7. 7 l ページング制御 （Paging Control）: ⾮ TEE プロセスに、TEE 内のデータと同時 に CPU 内で動作させない⽅法（訳注：CPU が TEE 内のデータを扱っている間 は、⾮ TEE プロセス（通常のアプリや OS 側の処理）は同時には動作せず、切り替 えによって時系列的に分離させる⽅法。つまり、TEE のデータと通常プロセスが CPU 上で同時並⾏に実⾏されることはないので安全である） もちろん、TEE データが可視化され得るのは CPU だけではない。このようなデータ は通常、RAM にも保存される。そして、RAM 上の TEE データは、サイドチャネル攻 撃の標的となる可能性がある。このような攻撃から RAM を保護するには、たとえば RAM 内の TEE データを暗号化するなどの対策が有効である。 プロセッサベンダーは通 常、複数の分離⼿法を組み合わせて、その実装を保護する。これらの分離⼿法の組み合 わせの上に、 Confidential Computing 機能を提供するソフトウェアが階層的に構築され る。 *CPU Addressability Isolation、Example CPUs Claiming Support 1 しかし、これらの分離⼿法に基づいて、実際に統合されて提供されるソフトウェアの レイヤーとはどのようなものなのだろうか？このソフトウェアレイヤーのパッケージ 化の⽅法は、コードが誰によって使われるか−たとえばソフトウェア開発者、システム インテグレーター、あるいはシステム管理者−によって異なる。特に、コードが最終的 1訳注：CPU Addressability Isolation とは CPU がアドレス空間を分離することにより実 ⾏中のデータを保護する隔離⼿法カテゴリ、Example CPUs Claiming Support とは各隔離 ⼿法をサポートする CPU 機能の例をいう
8. 8 にシステム管理者によってインストールされるまでに、複数の階層にわたるアプリケー ションパッケージングが⾏われる場合が多いだろう。この点を念頭に置き、以下にソフ トウェアサプライチェーンの下流の関係者が利⽤する観点から、 実際にソフトウェアレ イヤーがどのようにパッケージ化されるかを⽰す 9 つの例を以下に⽰す。これらの例で は、NIST 800-12 Rev.1[3]で定義されている Trusted Computing Base（TCB）のうち、 ソフトウェアに該当する要素のみを強調している。ファームウェアやハードウェアなど、 TCB の他の構成要素は⽰されていない2。 図に⽰す 9 つの実装例はそれぞれ、前述の「パッケージングモデルの⽤語」の章で述 べた、 4 つのパッケージング⽤語のいずれかにマッピングされる。 ⾚いボックスは、 TEE 内で実⾏されるコンポーネントのセットを⽰している。⻩⾊いボックスは、それらと⼀ 緒にパッケージ化される可能性のある構成要素の例を⽰している。 図には⽰していない が、 場合によっては⾚いボックス内のコンポーネントの⼀部が個別にパッケージ化され ることもある。 さらに、9 つの列はそれぞれ、使⽤中データの分離⼿法（Data-in-Use isolation methodologies） のいずれかのサブセットによってサポートされる。このようなパッケ ージング分類は、Confidential Computing のエンドユーザーにとって有⽤であり、以下 のことが可能になる。 2 訳注：TCB の定義は、NIST 800-12 Rev.1 に記載されていないが、NIST のホームペー ジが参考になる。https://csrc.nist.gov/glossary/term/trusted_computing_base
9. 9 l パッケージ化された製品の⼀部として期待されるソフトウェア要素を表現できる l 特定のパッケージ化された提供物内で、どの情報が分離されているか（あるいは 分離されていないか）が理解できる。 （注：これは、メモリの分離された部分で 実⾏される Confidential Computing を区切る点線の⾚い線で⽰されている。 ） l 「TEE shim」のように、分離⼿法全体に共通する役割が理解できる。TEE shim は、TEE のロードを助け、保護されたメモリとの間で情報をやり取りする。 l 様々な CCC プロジェクトが、共通のノースバウンド抽象化を通じて、メモリ分 離⼿法の違いを抽象化する⽅法を理解できる。 l TEE から公開されるパッケージ化された API が、他のソフトウェアとどのように 連携されるかを理解できる。これには、機密性が確⽴された後、TEE がセキュア なチャネルを介して追加のコード/データをロードする能⼒も含まれる。 l それぞれ異なる分離⼿法に基づく可能性のある、パッケージ化されたソフトウェ アの代替案が⽐較可能になる。 l 拡張性を持たせることで、新たなプロセッサ技術（例：RISC-V ベース）が、⾃⾝ がサポートするパッケージングモデルを主張できる。 様々な CCC のプロジェクトが、ここで説明するパッケージングモデルのいずれか、 あるいは複数を対象としたコードを提供する予定だ。以下は、その例である： l Occlum や Gramine を使うことで、開発者が既存のアプリケーションを Intel SGX 上に構築された「Confidential Library」パッケージとしてパッケージ化すること ができる。 l Enarx は、開発者が単⼀のアプリケーションパッケージをコンパイルし、複数の デプロイメントカテゴリに透過的にデプロイするのに役⽴つ。例えば、同じアプ リケーションを SGX のような「Confidential Library」としても、SEV-SNP のよ うな「Confidential VM」としても実⾏でき、Enarx は抽象化レイヤーを提供する ことで、同⼀のランタイム環境を保証する。 l Open Enclave は、開発者が SGX（ 「Confidential Library」としてパッケージ化） と Trust Zone（ 「Confidential Process」としてパッケージ化）の両⽅で動作可能な ライブラリを設計できるようにする可能性がある。
10. 10 4. アテステーション（Attestation） ワークロードがどのようにパッケージ化されていようとも、 結果としてデプロイされ たものは、それが TEE インスタンス内で実⾏されていることを証明するべきである。 従来のコンピューティングでは、サーバーの認証が求められる。⼀⽅、Confidential Computing における⽬標は、TEE インスタンスの認証である。そして、そのために使 われるのがアテステーションである。つまり、TEE インスタンスで実⾏されているこ とを証明できるよう、 デプロイされたワークロードはその検証を可能にする 「仕組み （メ カニズム） 」を備えている必要がある。Confidential Computing におけるアテステーシ ョンとは、 TCB の測定値 （measurement） に関するハードウェア署名付きレポート （ 「ア テステーションレポート（attestation report） 」 ）の検証を指す。この測定値は、図に⽰ されているような TCB の境界に基づいて提供される。 プロセス分離 （process isolation） のためのアテステーションではアプリケーション （訳注 ： confidential process のこと） を認証する。VM 分離（VM isolation）の場合は、VM（訳注：confidential VM のこ と）そのものや、VM の起動に使⽤される仮想ファームウェアを認証する。 アテステーション結果は、ステートレスな通信、例えば「このデータグラムや計算結 果は特定の TEE インスタンスによって⽣成された」という主張を裏付けるために使⽤ される。また、ステートフルな通信、例えば「この TLS チャネルは特定の TEE インス タンス内で終端されている」という主張をサポートするためにも利⽤される。 パッケージングプロバイダーは、RA-TLS のようなアテステーション済みプロトコル を含めるか、または TEE スタック内の粒度の細かいアテステーション API へのアクセ スを提供できる。 これらのプロトコルや API メソッドは、 フレッシュネス （freshness） 、 証明書の健全性（Certificate Hygiene） 、および TCB（Trusted Computing Base）の測 定（measurement）を含むアテステーション（attestation）のベストプラクティスをサ ポートする必要がある。 アテステーションのベストプラクティスについての詳細説明は、 本ドキュメントでは 取り扱っていない。 関⼼のある⽅は、 ぜひ IETF RATS （Remote ATtestation procedureS） ワーキンググループが策定した 「RATS アーキテクチャ」 などの⽂献を参照して欲しい。 また、Confidential Computing Consortium（CCC）でも「Attestation Special Interest Group （アテステーション特別利益団体） 」 を運営しており、 活動を⼀般公開している。 動画コンテンツや関連ドキュメントも豊富に提供されている。 5. 結論/まとめ Confidential Computing は、 現代のプロセッサに根本的なアーキテクチャを追加する ことで実現されるパラダイムであり、 商⽤チップに仮想化が導⼊された時と同じくらい、
11. 11 コンピュータの動作に変⾰をもたらす可能性を秘めている。 使⽤中のデータを保護する 機能を構築することで、Confidential Computing は現代のシステムにおける信頼、プラ イバシー、セキュリティがどのように管理できるかについて重要な要素を提供する。こ の技術の普及を促進するためには、その技術がどのように使われ、どのような利益をも たらすかを記述する共通の語彙を持つことが重要である。 参考⽂献 [1] Confidential Computing Consortium, “A Technical Analysis of Confidential Computing”, November 2022, https://confidentialcomputing.io/ccc-a-technical-analy-sis-of-confidential-computing-v1- 3_updated_november_2022/ [2] Open Container Initiative, https://opencontainers.org/ [3]Nieles, M. Dempsey, K. and V. Pilliteri, “An Introduction to Information Security”, NIST 800-12 Rev.1, June 2017, https://csrc.nist.rip/publications/detail/sp/800-12/rev-1/final