Intel SGX入門 - SGX基礎知識編・改

過去に執筆した以下のIntel SGX解説記事ですが、お陰様でご好評をいただけております一方で、私がIntel SGX、ひいてはTEE（Trusted Execution Environment）に触りたての学生の頃に書いたものであり、2025年現在となっては些か情報が古くなっている節があります。
https://qiita.com/Cliffford/items/2f155f40a1c3eec288cf

そこで、今回は私の所属する株式会社Acompanyの2025年度アドベントカレンダーの枠をお借りして、改めて2025年12月時点での最新の状況をもとに、Intel SGXについての解説記事を書く事にします。
https://adventar.org/calendars/12116

また、本記事は筆者が担当しておりますセキュリティキャンプのゼミで作成・使用している資料に沿う形で書いておりますので、そちらとは多分に重複する部分もございます。

なお、今回の記事は上記の過去記事よりも詳細チックになりますので、ふんわりと把握されたい方には、引き続き過去記事の方についてもおすすめいたします。

前提知識：TEEの概要

TEEとは、ハードウェア機能（特に、CPUやコプロセッサが主流）によりメモリ上の特定の区画を隔離し、場合によってはその区画の一部または全部の暗号化も行う事で、使用中のデータ（Data-in-Use）を保護しながら安全に計算を進める事を実現する技術です。

2025年現在、TEE実装は大きく分けて2つの種類に大別する事ができます。1つ目は、プログラムの内特定の部分のみを隔離する、いわば「部分隔離型」とも言えるもので、本記事の本題のIntel SGX（Software Guard eXtensions）の他、ARM TrustZoneやRISC-V Keystone等もこれに分類されます。2つ目は、仮想マシン全体を丸ごと隔離保護する「Confidential VM（CVM）型」というもので、ある意味でSGXの後継に位置するIntel TDX（Trust Domain Extensions）や、AMD SEV-SNP（Secure Encrypted Virtualization - Secure Nested Paging）、ARM CCA（Confidential Computing Architecture）といったものがこれに分類されます。

また、最近ではNVIDIAがHopperアーキテクチャ以降のハイエンドGPU（例：H100、B200）において、一般に「NVIDIA Confidential Computing（NCC）」と呼ばれるGPU版のTEEを提供しています。NCCは、専らCVM型のTEEと連携しながら動作を進めます。

TEEを用いてデータを保護しながらの安全な計算を行う事を、最近ではConfidential Computing（CC）と呼称する事が多くなっています[1]。

TEEの応用例としては、例えば

• エッジデバイスやスマホ等にTEEを展開し、その中でデジタルコンテンツのDRMを解除する事でリッピングを防ぐ
• TEE内でセンシティブデータ（例：生体情報）を取り扱い、使用されたデータを特定できない統計情報を計算結果として出力する、いわゆる「秘密計算」
• ブロックチェーンのトランザクション処理をTEEで保護しプライバシー性を高める
• CVM+NCCの組み合わせのもとに、TEE保護下でLLM処理を行う
  等、その応用先は広くかなりの可能性を秘めた技術である事が分かります。

TEEの最も顕著な利点として、他の準同型暗号や秘密分散のような秘密計算技術に比べると、空間・時間計算量が圧倒的に小さいというものがあります。TEEの利用によりメモリ使用量が膨れ上がる事も無ければ、処理速度も平文での計算と同等というのは、かなりの魅力と言えるでしょう。
反面、そのTEEを実装・提供するハードウェアベンダ（例：Intel, AMD, ARM, NVIDIA）は無条件で信頼する必要があるため、信頼の前提という面では準同型暗号や秘密分散に一歩劣ります。

Intel SGXとは？

Intel SGX（Software Guard eXtensions）は、IntelによるTEEの一実装です。x86命令セットアーキテクチャの拡張として実装されているもので、より具体的にはXuCodeという拡張マイクロコード（マイクロコードとは、あるCPU命令を構成するよりローレベルな命令で、いわば分子に対する原子のような命令）として組み込まれています[2]。

SGXでは、「Enclave」（直訳で「飛び地」の意）と呼ばれる隔離領域を専用のCPU命令により生成し、その中で機密情報等を扱いながら計算する事で、使用中のデータの保護を行いながら安全に処理を行うTEE機能を提供します。このEnclaveへのアクセスはCPUにより厳格に制限・管理される他、CPUパッケージ内に搭載された専用のユニットにより、暗号学的にも保護されています。

SGXには、第6世代〜第10世代CoreシリーズCPU、及び同時期の一部Xeonプロセッサに搭載されていた「Legacy-SGX」と、第3世代Xeonスケーラブルプロセッサ以降で搭載されている「Scalable-SGX」の2種類が存在します。Legacy-SGXの方は既にDeprecatedとなっており、2025年現在では専らScalable-SGXを使用するのが主流となっています。

Enclaveメモリの暗号化を行うCPUパッケージ内の専用ユニットは、このLegacy-SGXかScalable-SGXかで別物となっています。Legacy-SGXでは、メモリ暗号化エンジン（Memory Encryption Engine；MEE）と呼ばれるユニットが搭載されています。一方で、Scalable-SGXでは、Intel TME-MK（Total Memory Encryption - Multiple Key）という機能を提供する、MK-TMEエンジンというユニットがこの責を負います。いずれも、CPUパッケージ内でもコア（Core）の外側に存在するアンコア（Uncore）上に、メモリコントローラの一部として搭載されています。

Legacy-SGXのMEEでは、以下のような技術を組み合わせて、Enclaveの強力な暗号学的隔離保護を提供していました：

• Tweak値（外部パラメータ）を採用した版の128bit AES-CTR暗号
• マークルツリー（SGX Integrity Tree; SIT[5]）
• Carter-Wegman式メッセージ認証符号（MAC）

中でもSITというマークルツリーによるメモリ完全性保護と、カウンタ値を暗号文導出に織り交ぜられるこのAES暗号化方式は、非常に強力な保護性能を誇っていました。SITは、そのマークルツリーの根（ルート）がMEEで保持されるため、ハードウェア的にメモリ完全性を保護できるという特徴を有しています。もしEnclaveの内容に少しでも改竄が発生した場合、完全性の保証のために即座にそのマシンをシャットダウンします。これは、Scalable-SGX含む2025年現在現役のどのTEE実装にも搭載されていない、非常に強力で特徴的なメリットです。

また、MEEの使用するAES-CTRでは、アクセスする度にカウンタ値が更新され、それが暗号文導出に使われるため、同じ物理アドレスにおいて同じ平文をEnclaveに配置した場合にも、それ対するEnclaveの暗号文は別物になるという、鮮度（Freshness）の保証もされていました[6]。

しかし、特にこのSITを実装しハードウェア的にメモリ完全性保護を提供する代償として、Enclaveのメモリサイズがどんなに最大でも512MB、大抵のクライアント向けPCでは128MB（さらに、メタデータで32MBが消費されるため自由に使えるのは96MB）という、極めて苛烈な制限を強いる結果となってしまいました。往年の携帯ゲーム機であるSony PSP（Playstation Portable）ですら64MBのメモリを搭載していたと考えると、如何にこの上限が厳しいものであるかが分かると思います。これは、SITのサイズがEnclaveのサイズに比例し、一定以上になると手に負えない程のオーバーヘッドになるため、やむを得ず設定された制限であるようです[7]。

一方で、Scalable-SGXでは、MEEの代わりにMK-TMEエンジンを使用するようになった事で、CPU1ソケットあたり最大512GBのEnclaveサイズを確保できるようになるという、劇的な制限緩和が実現されました。MK-TMEエンジンでは、Enclaveメモリを128bit AES-XTSにより暗号化します。
Legacy-SGXにおけるEnclaveメモリサイズ制限はSGX開発者にとっては悪夢のような制約であったため、その観点だけで見れば大きな進歩であるようにも見えます。

しかしながら、MK-TMEエンジンはMEEが持っていたような、ハードウェアレベルのメモリ完全性保護機能が失われてしまっています。何故ならば、そもそもマークルツリー（SIT）機能自体がMK-TMEエンジンでは廃止されてしまったためです。これは、SITが苛烈なメモリサイズ制限を課していた事を考えると、利便性を優先してのトレードオフ的な判断であると言えますが、この仕様変更によりLegacy-SGXとは後述の通り大きく脅威モデルが変わる結果となりました。
一応、Intel TDXにおいて「Cryptographic Integrity（Ci）」と呼ばれているものに等しいと思われるソフトウェアベースのメモリ完全性保護機能は提供されているようですが[8]、ハードウェアベースのSITに比べると、その効果はかなり限定的なものになっていると言わざるを得ません。この辺りも、次の脅威モデルについてのセクションで説明いたします。

Intel SGXの脅威モデル

以下の図は、TEE分野ではもはや伝説的な論文とも言える、Graphene-SGX（現：Gramine）に掲載されているSGXの脅威モデル図を和訳したものです。

SGXは、プロセスレベル、OSレベル、オフチップハードウェアレベルの3つに対しての攻撃に対して保護能力を有しますので、それぞれ以下にて説明します。

プロセスレベルの攻撃に対する保護

これは、言い換えればユーザモード（非特権）で動作する、同一マシン上のプロセスレベルの攻撃です。例えば、UNIX系列のOSにおいてsudo（root）権限を持たない者、Windowsであれば「管理者として実行」を発動する権限を持たない者がこれに該当します。SGXに無関係な従来の一般的な攻撃者は、このユーザ権限から何とかしてOSのroot権限を奪取し悪さを企む事をモチベーションとしているため、SGXに無関係な従来の攻撃者に近いと表現できるかも知れません。

具体的な例としては、ユーザモードで動作する同一マシン上の別プロセスから、例えばコード脆弱性を突いてメモリ破壊攻撃を仕掛けたり、ROP（Return-Oriented Programming）攻撃を仕掛けるといったようなシナリオが考えられます。

SGXは、このようなプロセスレベルのEnclaveに対する攻撃から保護する事ができます。Enclaveへの進入は、専用のEnclaveエントリポイントに対して専用のCPU命令（ENCLU[EENTER]；後述）を発行する事でのみ行えます。かつ、進入後の動作定義は予めEnclave開発者により実装されたプログラムによって厳格に固定されているため、エントリポイントから進入して当事者が想定していない悪性の動作をするような真似は一切できません。

かつ、次に説明する特権レベル攻撃者に対しても適用される議論として、SGXではEnclaveモード（Enclave進入状態）以外の状態で（つまりEnclave外から）Enclaveメモリにアクセスすると、読み出し値は0xFF、書き込みは無視されるという性質を備えています。この性質は、Abort Page Semantics（APS）と呼ばれます。もちろん、（後述の物理攻撃であればともかく、プロセスレベル攻撃ではまずあり得ませんが）APSが発動しなかったとしても、読み出し値は暗号文であるため無意味なバイナリ列となり、Legacy-SGXであれば書き込んだ時点でMEEが改竄検知してマシンをハングアップさせるので、いずれにしろAPS無しでも直接の平文取得や、あるいは暗号文の書き込みが行われてしまう事はありません。
ただし、TEEメモリの暗号文を観測してサイドチャネル攻撃（後述）を行うCipherleaksのような攻撃が、元々APSのような機能を有していなかった（今ではCiphertext Hidingという同様の機能があります）AMD製のTEEであるSEV-SNPに対して提案されているため、いくら強固なLegacy-SGXでもAPSがあるに越した事はありません。Intel TDXにも、デフォルトでAPSと同様の機能が実装されています[10]。

OSレベルの攻撃に対する保護

これは、謂わば特権（root権限）を有するような攻撃者による攻撃に対する保護です。従来のマルウェアの具体例で言えば、例えばルートキットがこの例に該当します。また、悪意のあるOS、ハイパーバイザ、BIOSといった特権的なコンポネント達も、この特権攻撃者として分類・想定されます。

しかし、これも後述の通りSGX（というよりもTEE）は非階層的な分離モデルを持つ、つまりはユーザ権限であろうが特権であろうが分け隔てなく隔離領域（Enclave）への攻撃を阻止するため、例え特権攻撃者であっても前述のユーザレベル攻撃者に対するものと全く同じ議論となります。

ただし、コードやSGX自体の実装、あるいはCPUレベルの脆弱性が存在する場合に、この「特権攻撃者からも保護できる」という喧伝につけ込み、通常の環境ではまずあり得ないような苛烈な特権攻撃を前提とした攻撃が提案される事が多くなってしまっているという側面があります。例えば、Load Value Injection（LVI）[11]という、かつてのCPUに存在した脆弱性を突いた攻撃や、SGX-Step[12]という割り込みベースの攻撃補助ツール等がこの一例として挙げられます。

オフチップハードウェアレベルの攻撃に対する保護

オフチップハードウェアレベルの攻撃とは、謂わば「CPU以外のハードウェアに対する物理攻撃」と言い換える事ができます。TEEにおいては、専らDRAM（DIMMシステム）に対する直接的な攻撃を指す事が多いです。
一方で、CPUパッケージに対する物理攻撃は、TEEは保護対象外としています。例えば、CPUパッケージの電子顕微鏡による観察はこのような例として挙げられます。これらは、有効な攻撃を行うには現実的には不可能であるか極めて現実離れした設備が必要であり、そもそも心配する必要がないという立場を前提としているためです。実際、CPUパッケージ内でMEEやMK-TMEエンジンで復号された後、レジスタやキャッシュにはEnclave（TEE）のデータは平文状態で存在しています。

実は、このオフチップハードウェア攻撃に対してどのくらいの耐性を持つかは、Legacy-SGXであるかScalable-SGXであるかで大きく異なります。
まず、いずれにおいても対策できる攻撃の例としては、コールドブート攻撃が挙げられます。これは、まず攻撃対象マシンの電源が落ちた後、すぐにDRAMを取り出して冷却します。DRAMは電荷を利用してデータを保持していますが、低温環境下ではこの電荷の減衰に時間がかかります。つまり、「RAMは揮発性」という一般常識のイメージに反し、電源を落とした後もデータが一定時間メモリ上に残留してしまうのです。
この状態で、解析用の別マシンに差し替える等をして起動すると、電荷が残留しているがために、本来閲覧できてはならなかったメモリコンテンツを不正に読み取る事ができてしまいます。

SGXでは、このような攻撃でEnclaveメモリを読み取ったとしても、MEEやMK-TMEエンジンで暗号化されているため、単に無秩序な暗号文が見えるに留まります。また、MEEでもMK-TMEでも、少なくとも一度電源が落ちるとメモリ暗号化鍵が別物となるため、暗号文の再生を悪用した攻撃をコールドブート攻撃経由で行う事もできません。

Scalable-SGXでは対策できないオフチップハードウェア攻撃

しかし、Scalable-SGX、ひいてはLegacy-SGX以外の現行の全てのTEEが対処できない攻撃として、「ランタイム中に動的にEnclaveメモリの読み書きを行うハードウェア攻撃」が挙げられます。

Legacy-SGXでは、MEEというハードウェアがルートを保持するSITにより、メモリ完全性保護機能を提供していました。一方で、Scalable-SGXのCryptographic Integrity（Ci）はあくまでもTEEメモリに対するMACを同じくメモリ上で保持するにとどまるため、謂わばソフトウェアベースの完全性保護でしかありません。つまり、そのメモリ上のMACも含めてハードウェア的に書き換えてしまえば、攻撃が通用してしまいます。

例えば、あるEnclaveメモリページAがあるとします。このページAには、ある時点t'では公開したくない秘密情報が載っているとします。その後の時点tで、公開しても良い処理結果で上書きされ、Enclaveプログラムはそれを外に出す動作を行います。
ここでもし、時点tにおいてハードウェア的にページAを、バックアップしておいた時点t'のもので上書きロールバックできると何が起きるでしょうか。プログラムは、所定の時点tに到達したのでページAの内容を公開しますが、実際には時点t'にロールバックされているため、そこに秘密情報があると知らずにそれを公開してしまうでしょう。

また、Scalable-SGXではEnclaveメモリ暗号化鍵（TME-MK鍵）が再起動するまで不変であり、物理アドレスに依存しますがMEEのようにカウンタ値は用いません。つまり、同じEnclave物理アドレスに同じデータを配置すると、そのEnclave暗号文は再現されてしまいます。これにより、暗号文を再生させて照合・観測するような攻撃が成立してしまいます。

このような攻撃は夢物語に聞こえるかも知れませんが、前者の能動的書き換えタイプとしてBatteringRAM[14]が、後者の受動的読み取りタイプとしてWireTap[15]とTEE.fail[6]が2025年に登場しました。これらはいずれも、メモリインターポーザという装置を介してそのような悪性の操作を行います。

（画像はこちらより引用）

およそ入門編記事には似つかわしくない複雑な話となりましたが、要するに、Scalable-SGXを含む現行のTEEは、物理攻撃者に対する保護機能を万全には提供できないという事です。唯一の即席の解決策は、マシン自体を厳重な警備の敷かれたデータセンター等に配置する事です。これを最も容易に満たせるのは、クラウドベンダが提供するTEEインスタンスを使用する事ですが（大手クラウドベンダのデータセンターであれば警備も厳重であると考えられるからです）、これはLegacy-SGXはOS等の特権コンポネントを悪用して攻撃を仕掛けるクラウドベンダから保護できる事を売りにしていた事を考えると、かなり皮肉な現状であると言わざるを得ません。

さらにまとめるのであれば、Scalable-SGXはあくまでも警備が厳重なサーバ運用が前提となっており、Web3系における野良の人間も扱えるノードや、クライアントマシンとしてエッジにて保護するといった運用は、Legacy-SGX時代とは異なり脅威モデル外となってしまっているのです。

その他TEEの保護対象外の攻撃

ここからは、前述の脅威モデル図に記載された内容からは外れますが、まず、SGX（ひいてはTEE）は単に利用するだけでサイドチャネル攻撃からの保護を提供する事はありません。

気をつけるべきなのは、あくまでも「TEEの利用によりサイドチャネル攻撃に強くなる事は無い」のであり、「TEEを使う事で明示的にサイドチャネル攻撃に弱くなるわけでは無い」という事です。つまり、平文環境でサイドチャネル攻撃に弱いコードはTEEでも弱いですし、その逆も然りです。これは、準同型暗号や秘密分散にもサイドチャネル攻撃が存在する事を考えても、特にTEEだけの特性というわけではありません。

次に、SGX（TEE）は使用中のデータとコードの機密性は保護しますが、コードの安全性の保証は行いません。例えば、もしコードにバッファオーバーフロー（BoF）脆弱性があれば、それをTEEに載せてもBoF脆弱性が無くなる事はありません。もちろん、Enclave実行中の状態をEnclave外から観測するのはEnclaveの機密性により通常よりも難しくはなりますが、完全な対策としては期待できません。
これは、危険なコーディングをコンパイル時点で排除できるRustを開発に用いるRust-SGXを用いる事で、いくらかそのリスクを軽減する事ができます。

最後に、SGX（TEE）は可用性に対する攻撃の保護を提供しません。マシンをシャットダウンすればEnclaveも当然消えてしまいますし、ホストOSがEnclaveの実行を拒否したり、通信内容や保存した暗号データを破壊したり、あるいは単純にDDoSでEnclave実行のパフォーマンスを著しく下げたりする事もできます。もし可用性を担保したいようであれば、SGX（TEE）の機能よりもある種外側で、フォールトトレラントな設計を行う必要があります。

SGX1とSGX2

ところで、Legacy-SGXとScalable-SGXという区別の他に、SGXにはSGX1（SGXv1）とSGX2（SGXv2）という、別の区別が存在します。SGX1は最初期から存在していたもので、SGX2はそれに加えて例えば以下のような追加機能を搭載したバージョンです。

• Enclave初期化（EINIT）後でも動的なEnclaveメモリページの追加（Enclave Dynamic Memory Management；EDMM）を行える命令（ENCLS[EAUG]）。ただし、EAUGを用いてもそのマシンのEnclaveサイズ上限の突破はできず、あくまでも制限サイズ内での動的追加に留まる[19]。
• Enclave内で利用可能な、クロック周波数ベースの信頼可能な時間ソース（RDTSC命令等）[20]。

つまるところ、SGX2はSGX1に対して多少利便性を追加した程度のものであり、1CPUソケットあたり512GBにまでEnclaveメモリを増大させたScalable-SGXとは、根本的に無関係です。それこそ、Legacy-SGXでSGX2対応のマシンも存在しますし、Scalable-SGXでSGX2のマシンも存在します。しかし、Intelのドキュメントがどうしても散逸気味である事、そもそもSGXの仕様自体が混沌としている事、そしてSGX2のEDMMの性質が「EINIT後であれば無限にEnclaveサイズを増やす事ができる」と誤って解釈されているケースが跡を絶たない事から、結果としてSGX2とScalable-SGXが国際論文レベルでも混同されているという背景が存在します[21][22]。

Enclaveの実行権限と分離モデル

SGX Enclaveの特徴として、Enclaveはユーザモード（非特権モード）でのみ動作する事ができます。つまり、Enclaveはある種の非特権な1プロセスのような形で動作するという事です。リングプロテクションモデルで言えば、Ring-3権限で動作するという事になります。

（図はこちらより引用）

これは、もしEnclaveが特権で動作してしまうと、OSも関与できない所でマルウェアを特権で動作させるといった危険な行為を許してしまう事になるというセキュリティ上の理由による所が大きいと考えられます。また、SGX Enclaveはそのメモリ管理や例外処理等を全てOSに任せ、あくまでも自身は非特権プロセス的に振る舞う事に徹しているため、なまじ特権を持つとシステムアーキテクチャ的に不整合が発生してしまうという側面もあります。

このように、権限としてはユーザモードとして動作するSGX Enclaveですが、Enclave外の攻撃者に関しては非特権であろうが特権であろうが、一律して不正なアクセスを阻止します。つまり、相手がユーザモードだろうが特権モードであろうが、分け隔てなく全て防ぐという事です。
これは、SGXを含むTEEの大きな特徴であり、従来型のユーザ/カーネル分離モデルとは異なります。ユーザ/カーネル分離モデルでは、非特権ユーザはカーネル空間（OS、ハイパーバイザ）にはアクセスできないが、特権側はユーザ空間にアクセスできるという、ある種の階層関係が発生しています。一方で、SGX Enclaveはそのような分け隔てなく一律で隔離するという意味で、「非階層型分離モデル」を採っている、と表現する事ができます[16]。

秘密情報を保持するメモリ領域

さて、ここでもう少し「Enclave」というメモリ領域について深堀りしていきます。

今まで、SGXにおける隔離領域の事を「Enclave」と呼んでいましたが、これはある1つのSGX隔離領域を構成する一式を概念的に呼称するものです。このEnclaveは、厳密にはEPC（Enclave Page Cache）と呼ばれる物理メモリ領域上に生成されます。EPCはEPCページと呼ばれるメモリページの集合であり、これらは全てプロセッサ予約メモリ（Processor Reserved Memory; PRM）という、SGX用に特別に確保されたメモリ領域上に存在します。一方で、物理アドレス領域であるEPCに対する仮想アドレス空間上の領域をELRANGEと呼びます。

些かややこしいですが、これを図に起こすと以下のようになります。


（図はいずれも[17]より引用）

PRMという領域は、CPUが提供するPRMRR（PRM Range Register）というレジスタ（MTRRに類似するものであるという言及があります[17]）により、通常はBIOS設定等を通して設定する事ができます。そこに、EPCページから構成されるEPCという物理メモリ領域が格納され、Enclaveの生成命令が下ると、実際にそのEnclaveにEPCからEPCメモリページが払い出されます。そのような性質を持つEPCに対する仮想アドレス空間上の領域をELRANGEと呼ぶ、というのが、これらのより具体的な関係性です。

そして、Enclave外のアプリケーション等がELRANGE（これはアドレス変換を通してEPCにアクセスしようとしている事を意味します）に対してアクセスしようとすると、上図2枚目左側にあるような、Abort Pageと呼ばれるダミーのメモリページへの読み書きに強制的にすげ替えられます。このAbort Pageは、読み出し値が0xFFとなり、書き込み値が無効化されるという特性を備えています。お分かりの通り、このAbort Pageへのすげ替えによってEnclaveメモリへの不正な読み書きを防ぐのが、前述した「Abort Page Semantics（APS）」なのです。

SGXを支える様々なデータ構造

上述ではEnclaveが概念的な呼称であるという話をしましたが、その仕組みを見てみると、実に様々なデータ構造が関わっている事が分かります。Enclaveを構成するもの、SGXにおける各種処理に使われるものなど、そのバリエーションは豊かです。それぞれについて説明していると紙面が足りないため、以下の表にメジャーなSGXデータ構造の説明を列挙します[17][18]。

データ構造名	機能
EPC（Enclave Page Cache）	メモリ上の保護領域。1Enclaveあたりユーザが自由に使えるEPCサイズ上限は、一般的なLegacy-SGXマシンでは96MB、Scalable-SGXでは512GB/1ソケット
SECS（SGX Enclave Control Structure）	Enclave同一性に関するメタデータを保持。EPC内に存在
TCS（Thread Control Structure）	Enclave実行スレッドを管理。EPC内に存在
SSA（State Save Area）	Asynchronous Enclave Exit（AEX；後述）時にEnclaveの状態を保持。EPC内に存在
PAGEINFO（Page Information）	EPCのアドレス情報やSECSを保持。EPC外に存在
SECINFO（Security Information）	ページタイプ等EPCのメタデータを保持。EPC外に存在
PCMD（Paging Crypto Metadata）	ページアウトしたEPCページの暗号的メタデータを保持。特定のPAGEINFO内などに組み込まれる
VA（Version Array）	退避したEPCページのバージョンを管理する配列。EPC内に存在
EPCM（Enclave Page Cache Map）	CPUが特定のEnclaveに対応するEPCを追跡するための情報を保持。アーキテクチャ的な実体は不明だが、PRM上に存在する事は特許文書で判明している[17]
SIGSTRUCT（Enclave Signature Structure）	Enclaveのハッシュ値や署名者情報を保持。Enclave初期化時等に使用
EINITTOKEN（EINIT Token Structure）	Enclaveの初期化（EINIT）が許可された事を証明するトークン。Launch Enclave（後述）によって生成され、EINIT時に使用されるが、現在では非推奨化している
REPORT（Report）	Enclaveの身元を示す、MAC付きの公開情報。Attestationで使用
TARGETINFO（Report Target Info）	EREPORT命令において使用されるデータ構造。REPORT提出先Enclaveの同一性情報を含む
KEYREQUEST（Key Request）	EGETKEY命令にて、要求する鍵の種類や追加パラメータを指定するデータ構造

Enclaveにまつわる専用CPU命令

Enclaveに関連する操作は、全て専用のSGX命令によって行われます。このSGX命令は2つ存在し、それは特権を要するカーネルレベルの命令であるENCLS（Sはスーパーバイザの意）、非特権で発行できるユーザレベルの命令であるENCLU（Uはユーザの意）です。

このENCLSとENCLUは、それぞれ引数に応じて様々な処理を実行します。厳密には、ENCLSやENCLUはオペコードであるわけですが、これらはEAX（アキュムレータ）内の内容に応じて対応する処理を実行します。この「アキュムレータに格納されている内容」こそが「引数」相当であり、これを専門用語で「リーフ関数（Leaf Function）」と表現します。
例えば、EAXに0x4を格納した状態でENCLU命令を呼び出すと、Enclaveからの脱出を行うEEXITリーフ関数が実行されます。

よって、厳格に表現する場合はENCLU[EEXIT]のように表記する事が多いのですが、日常使いでわざわざENCLU[]とつけるのは面倒であるというのは否めません。よって、便宜的に単に「EEXIT命令（EEXIT Instruction）」のように呼ぶ用法も、慣例として存在しますし、これは別に不自然な事ではありません。

では、まずはENCLS命令によって実行される各種処理（リーフ関数）の一部を以下に列挙します[17][18]。

リーフ関数名	機能
EADD	Enclave初期化前のロード処理時にEPCページを追加する
EBLOCK	EPCページをブロック状態（使用禁止状態）にする。EWB前などに使用
ECREATE	Enclaveを生成する。未使用のEPCを新しいEnclaveのSECSに変換
EDGBRD	デバッグモードのEnclaveのEPCページを平文で読み取る
EDBGWR	デバッグモードのEnclaveのEPCページに平文を書き込む
EEXTEND	EADDに伴い、その時点でのMRENCLAVEを更新する
EINIT	Enclaveを初期化する。ECREATE・EADD等の後に使用
ELDB	EWBで退避されたEPCページをブロック状態としてロードする
ELDU	EWBで退避されたEPCページを非ブロック状態（使用可能）としてロードする
EPA	Version Array（VA）ページを追加する
EREMOVE	EPCからページを削除し、ECREATE前の状態に戻す
ETRACK	EBLOCK後、論理プロセッサが関連TLBをフラッシュしたかを追跡開始
EWB	EPCページを暗号化して非PRMメモリ（Enclave外）へ退避させる

ENCLS命令は、ユーザレベルの主体（プロセス）がSGXライブラリ等を通してSGXドライバに実行リクエストを送り、それに応じる形でSGXドライバが実行する、という形で実行されます。例えば、ここはSGXドライバ内のEADD命令を実行する部分です。このSGXドライバ自体は古いものではありますが、現行のドライバでも同様の実装と仕組みが採用されています。

ENCLUのリーフ関数の一部については以下の通りです[17][18]。

リーフ関数名	機能
EENTER	Enclaveに進入する。後述のECALL呼び出しや、後述のOCALLからのリターンに対応
EEXIT	Enclaveから脱出する。Enclaveコードからのreturnや後述のOCALLに対応
EGETKEY	SGXで使用する各種鍵（例：レポートキー）を導出する
EREPORT	そのEnclaveのメタデータであるREPORT構造体を取得
ERESUME	AEXによりEnclaveから一時的に脱出した際、Enclaveに再進入する時に使用する

ENCLU命令については特権のドライバを介したりはせず、主にユーザが呼び出したSGXライブラリのAPIの中で直接実行されます。

Enclaveのライフサイクル

折角各種データ構造やSGX命令について紹介しましたので、それらを用語として用いながらEnclaveの作成から終了までのライフサイクルについて説明します。

まず、非信頼可能ドメインから、sgx_create_enclave()等のAPIが呼び出されると、ドライバ経由でECREATE命令が発行されます。ECREATEが実行されると、未割り当てのEPCが、作成しようとしているEnclaveのSECSに変換されます。

次に、EADD命令により、Enclaveイメージ（開発者による署名が付与されている共有ライブラリ）からメモリページ単位でEPCにロードしていきます。EADDでページを追加する度にEEXTEND命令を実行し、順次SECS上のMRENCLAVE（後述する、Enclaveの動作定義に対するハッシュ値）を更新していきます。

Enclaveイメージから全てのメモリページをEPCにロードし終えたら、EINIT命令を実行する事により、Enclaveの初期化を行います。EINITにより初期化されると、それ以上Enclaveの定義を変更する（EADDによりページを追加する）事はできなくなります。これは、MRENCLAVEがそれ以上変わらない事を意味します。
ただしSGX2であればEDMM機能を備えているので、Enclaveが自由に使えるEPCページを、EINIT後にもEAUG命令により動的に（そのマシンにおける1EnclaveあたりのEPCサイズ上限まで）追加できます。EAUGにより追加されるページはあくまでもヒープですので、MRENCLAVEにより縛られている動作定義には影響しません。
また、EINITが実行されると、初期化しようとしているEnclaveのメタデータ（MRENCLAVE含む）が、Enclaveイメージ開発者の署名に基づくSIGSTRUCTの内容と一致するかを確認します。具体的には、まずSIGSTRUCTの署名を確認し、次にSIGSTRUCTとSECSの内容の一致確認を行います。もし一致すれば、Enclaveイメージのビルド時に想定されている状態で正しく初期化された事を意味するので、安心して起動する事ができます。反対に、この内1つでも検証に失敗したら、その時点でEINITは異常終了します。

初期化後、実際にEnclave内で処理を行うには、Enclave外のプロセスにおいてEENTER命令を発行します。EENTERによりEnclaveに進入しEnclave内の関数に遷移する事をECALL（Enclave CALL）と呼びます。EENTERは開発者により予め定義されたインタフェースを通して進入を行い、そして開発者により予め定義された動作定義に基づき実行が進みますので、Enclaveが正しく実装されている限り、意図しない不正な動作が行われる事はありません。
Enclave内はできる処理に制限がありますので（例：標準出力はじめシステムコールを発行できない）、時にはEnclave内からEnclave外の関数を呼び出したい事もあります。その場合は一度EEXIT命令で外に出て、目当ての処理を行った後に再度EENTERを実行してEnclave内に戻ります。このような一時的なEnclave外関数の呼び出しをOCALL（Outside CALL）と呼びます。
Enclave内での処理を一通り終えてEnclave外に戻る際にも、EEXITを実行します。

EPCページが枯渇してページアウトの必要性が出てきたら、EWB命令によって暗号化された状態でEPCページをEPC外に退避させます。反対に、それをEPCに戻す場合にはELDU命令を実行します。

一通りの処理を終えてEnclaveが用済みになったら、Enclave外でsgx_destroy_enclave()を呼び出す事で、Enclaveインスタンスをデストラクトします。すると、EREMOVE命令によりEPCからページが削除され、未割り当ての状態に戻されます。

このように、上述したデータ構造や各種命令は、SGX Enclaveを利用する上で密接に関わり合いながら活用されているのです。

Asynchronous Enclave Exit（AEX）

さて、上述したEENTERやEEXITによるEnclaveへの進入・脱出は、あくまでも期待される状態に従っての、謂わば「同期的」なものです。しかし、場合によってはページフォールトが起きた場合、割り込みが発生した場合等、意図しないタイミングで処理を挟む必要があります。Enclaveは非特権でのみ動作できますので、特権が必要な例外ハンドラ等を、基本的にはEnclave内で実行する事はできません（例外的なケースはあります）。つまりこのような例外や割り込みが発生すると、その対処を（信頼できない）OSに依頼する必要があります。

このように、意図しないイベントにより、「非同期的」に一時的にEnclaveを脱出する事を、Asynchronous Enclave Exit（AEX）と呼びます。AEXの仕組みを以下の図に示します。

まず、割り込みや例外が発生すると、その時点でのEnclaveの状態（レジスタコンテキスト）を前述のSSAというデータ構造に格納します。そして、EnclaveとOSの橋渡しとして機能する信頼不可能なコードであるトランポリンコードを経てOS側の例外ハンドラに遷移します[23]。

AEXが発生すると、レジスタ内のEnclaveコンテキストは上述の通りSSAに退避され、代わりに「合成状態」（Synthetic State）という、秘密情報が秘匿された形での例外関連情報が格納されます[23]。OSの例外ハンドラはこの合成状態を参照して例外処理を行います。

例外処理が完了したら、ENCLU命令のERESUMEにより、再びトランポリンコードを通してEnclave内に復帰します。そして、SSAからEnclaveコンテキストをレストアし、Enclave内処理を再開します。

Enclaveの測定値

あるコンポネントの同一性（本当に期待する通りの内容であるか）を確認する上で、そのコンポネントのハッシュ値を算出し使用する時、その同一性ハッシュ値の事を「測定値」（Measurement）と呼びます。これは例えば、TPMを用いたMeasured Bootのような文脈などでよく使用されます。

SGX（TEE）においても、Attestationという処理により相手が期待通りの内容かどうかを確かめる事が特にリモートからの利用では必須であるため、その判断材料として測定値が存在します。SGXにおいては、MRENCLAVEとMRSIGNERという2つの測定値が存在します（広義ではAttestationという処理で確認できるコンテンツ全てを測定値と見なす事もありますが、ここでは狭義に同一性ハッシュ値という意味合いを前提とします）。

MRENCLAVEは、そのEnclaveの動作定義に対するハッシュ値です。より厳密には、EnclaveのEINITで確定する初期メモリ内容に対する測定値です。これは、前述の通りEADDに伴いEEXTENDによってEPCページのページ単位のロードごとにSECS上のそれが更新されていきます。EINITで確定するメモリ内容は、開発者が作成したEnclaveイメージからロードされるものですので、Enclaveイメージで定義されている動作定義のハッシュ値という事もできます。

MRENCLAVEは、以下のようなコンテンツに依存します：

• 署名前のEnclaveイメージ（≒Enclaveのソースコード）
• Enclaveの各種設定を行うXMLファイル（Enclave.config.xml）の一部エントリ
• SGXSDK及びSGXPSWのバージョン

気をつけなければならないのは、「Enclaveのイメージ」に依存しているため、仮に全く同じソースコードからビルドしても、環境やビルドツールの違い次第では全く同じハッシュ値となる事が多分にあり得ます。何故ならば、そのような状況では同一ソースコードからのビルド結果が、コンパイル等の過程でバイナリレベルで見ると別物となってしまう事があるからです。

一方で、MRSIGNERはEnclaveイメージに対する署名鍵に依存するハッシュ値です。この署名鍵は、Enclave開発者（作成者）により、Enclaveイメージ（Enclave.so）に署名して署名済みEnclaveイメージ（Enclave.signed.so）を生成するのに使用されます。前述のSIGSTRUCTの議論で出てきた署名は、まさにこの鍵です。
具体的には、MRSIGNERはEnclave署名鍵（3072bit RSA鍵）のRSAモジュラスに対する256bit SHA-2ハッシュ値です。こちらは、例え動作定義がまるで別物でも、同じ署名鍵を用いていれば当然に完全一致するという特徴があります。

Enclaveの2つのモード

Enclaveには、Production Mode Enclave（製品版・本番Enclave）と、Debug Mode Enclave（デバッグ版Enclave）という2つのモードが存在します。これは文字通りではありますが、前者は一切のデバッグ用エントリポイントがSGX機能としては提供されない一方で、後者は専用のSGX命令を用いる事でEPCページの平文での読み書きが可能となります。

具体的には、ENCLSのEDGBRDでEPCページの平文読み取り、EDBGWRでEPCページの平文での書き込みが可能となります。言うまでもなく、これは本番利用する上では絶対にあってはならないインタフェースですので、本番デプロイの際には必ず製品版Enclaveとして作成しデプロイしなければなりません。

過去には、製品版Enclaveを実行するには、Intelへのライセンス申請が必要であったという極めて面倒な懸念事項が存在しました。
https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/request-license.html
しかし、現在では後述の通りその必要が無くなったため、両命令によるデバッグが不要であれば基本的に製品版Enclaveとして作成して問題ありません。

Architectural Enclave（AE）

SGXの大部分はハードウェアとマイクロコードにより実装されていますが、特定の重要な機能に関してはそれらで実装するにはあまりにも重すぎるため、代わりに専用のEnclaveでソフトウェア的に実装・提供されています。このSGXを動作させる上で重要な役割を果たす専用のEnclaveの事をArchitectural Enclave（AE）と呼びます。このAEという用語はいかんせん定義が曖昧なのですが、1つの分かりやすい基準として、基本的にIntel署名がついているEnclaveはAEであると見なせます。

以下、各種AEについて簡単に説明します。

DCAP版Quoting Enclave（QE3）

これは、Remote Attestationという機能の中でも、新しいタイプであるDCAP-RAという方式で使用されるものです。DCAP-RAについては、以下の会社の技術ブログで記した自著記事を参照してください。
https://www.acompany.tech/privacytechlab/intel-sgx-dcap-ra

Remote Attestation（RA）という処理では、リモート検証者がそのEnclaveの身元情報（前述のReport）を検証できるように、Intelをトラストアンカー（信頼の頂点）としたAttestation Key（AK）でそのReportに署名を行い、結果生成物としてQuoteというものを生成する必要があります。この処理は絶対に侵害されてはならないので、SGXの脅威モデル的に信頼できる場所で実行されなければなりません。これを行うAEが、このQuoting Enclaveです。

後述の通り、元々はEPID-RAという古いタイプのRAが存在し、そこで使われていたQEとの差別化で「QE3」という呼称が使われます。EPID-RAについては、以下の会社の技術ブログで記した自著記事を参照してください。
https://www.acompany.tech/privacytechlab/sgx-remote-attestation

QE3の「3」の理由ですが、DCAP-RAがThird-Party Attestationとも呼ばれているからである説、あるいはQE3で生成されるQuoteの定義がsgx_quote_3.hで定義されているから説等諸説ありますが、厳密な語源については不明です。

QE3では、AKとしてECDSAキーペアが使用されます。

Provisioning Certification Enclave（PCE）

こちらも、DCAP-RAで使用されるAEです。DCAP-RAでは、QE3としてIntel署名ではないユーザメイドのものを使用する事もできます。しかし、それだとAKのトラストアンカーをIntelにできません。何なら、Intel製QE3を使用する場合でも、AKキーペア内はQE3内で完結して生成されるため、そのままではIntelをトラストアンカーとした認証が行われていない状態になっています。
つまり、このようなQE3におけるAKに対してIntelをトラストアンカーとした鍵で署名し認証してあげる存在が、QE3の1つ上層に必要になります。この役割を果たすのが、このPCEです。

PCEは、QE3が生成したAK公開鍵に対して、PCK（Provisioning Certification Key）という、Intelをトラストアンカーとしている鍵で署名する事で、QE3のトラストアンカーを正当にIntelにする事ができます。

Quote Verification Enclave（QvE）

DCAP-RAにおいて、Quoteの検証を行う際に任意で使用する事ができるAEです。Intel公式による言及は見受けられませんが、このQvEも自作したり自分で署名したりして使用する事も可能です。

ID Enclave

DCAP-RAにおいて、QEIDという値を導出する役割を持つらしいAEです[24][25]。ただし、あまりにもマイナーすぎるAEですので、このID Enclaveが議論に挙がる事はまずないと思われます。

過去に使用されていたAE

中には、過去には使用されていたが現在では使用されなくなったAEも存在します。以下、それらについて簡単に説明します。

Provisioning Enclave（PvE）

これは、旧式のRA方式であるEPID-RAで使用されていたものです。そのマシンにおけるRAの初実行時や、後述のTCB Recovery実施後に、そのマシンのCPUやSGX関連コンポネントが正当であるかを確認後、EPID-RA版のAttestation Key（AK）をマシンにデプロイする、「プロビジョニング」処理を行っていたものです。EPID-RAでは、AKとしてEPID方式のキーペアを使用していたという特徴がありました。

EPID-RA版Quoting Enclave（QE）

文字通り、EPID-RA版のAKでQuoteを生成するAEです。完全に同様ではないものの、DCAP-RAではPCEがQE3を認証してプロビジョニングすると考えると、QE3とPCEはQEとPvEの関係に多かれ少なかれ近いと言えるかも知れません。

Launch Enclave（LE）

製品版モードのEnclaveにおいて、そのEnclaveがIntelによって起動を許可されているかというライセンスを確認し、問題がなければEINITTOKEN構造体を生成してEINITを許可していたAEです。ライセンシングされているかの判断には、そのEnclaveの署名鍵に紐づくMRSIGNER値が用いられます。

しかし、このLEによるライセンシングは、暗号学的なセキュリティという観点での意味は一切持たず、極論を言えば「Intelの（非暗号学的な）認定を得られてるかどうか」という、TEEの非本質的な部分で制約がかけられるものでした。これに対する批判意見は数多く[16][17]、現在では非推奨化され原則として使用されていません。この辺については、もう少し詳細を後述します。

Reference Launch Enclave（ref-LE）

LEはIntelによるライセンシングが強制されており、これが顰蹙を買ったため、Intel以外の他の承認者による起動（EINIT）許可を下せるようにしたAEがこのref-LEです。ref-LEという名前は、文字通りLEのリファレンス実装である事を意味しています。これは、起動許可者の設定が可能になった、Flexible Launch Control（FLC）という機能が実装されたマシンで使用する事ができます。

基本的な機能はLEと同様ですが、MRENCLAVEベースでの許可も可能といった違いも存在します。しかし、現在では後述の理由により、このref-LEも使用される事は基本的に無くなっています。

Platform Service Enclave（PSE）

モノトニックカウンタや信頼可能時間ソースといった、再生攻撃対策等に利用できる、信頼性保証のための機能を提供するAEです。しかし、Linux-SGXではバージョン2.7辺りで突然使用不能となりました。これは、iclsClientというものをLinuxで使用できなくなったのが原因のようです。
この廃止により、CPU由来の鍵でEnclaveのライフサイクルを横断して暗号化できる「シーリング」という機能を使用する際、過去の意図しないシーリングデータでロールバックを行う「シーリング再生攻撃」の対策が困難になってしまいました。

LEを取り巻く現在の状況

先程、LEとref-LEについて説明しましたが、2025年現在、Linux向けSGXドライバの内、DCAPドライバとIn-Kernelドライバ（Linuxカーネル内に元々内包されているドライバ。LinuxのSGXドライバは、Linuxカーネル5.11以降からこれになっています）においては、LEはおろかref-LEも不要となっています。

よって、これらの環境においては、Enclaveの起動は自動的に許可されるようになっています。原理的には、この許可設定はモデル固有レジスタ（MSR；プロセッサ固有の情報を格納するレジスタ）のIA32_SGXPUBKEYHASH0〜IA32_SGXPUBKEYHASH3に、無条件に起動許可する対象のMRSIGNERを入力する事で行います（これが、FLC機能によって実現可能となっています）。
これらの環境では、このMSRにSGXドライバが起動対象のMRSIGNERを自動的に入力するようになっているので、事実上起動許可処理自体が廃止されている、という状況となっています。

このFLC機能自体はref-LEのMRSIGNERを入力してIntel以外の承認を可能とすれば良いのでは？という文脈で実装されたものかと思われますが、このMSRで設定できるならそもそもライセンシング自体回避できるのでは？となり、現在の無条件許可の状況になっている、という流れです。

SGXにおけるRoot of Trust

先程、PCEはIntelをトラストアンカーとしたPCKでAKに署名し認証する、と説明しましたが、では具体的にPCEはどのようにしてそのようなPCKを導出しているのかという疑問が湧いてきます。

結論を言うと、PCKはCPU内のe-fuseという一度だけ書き込み可能な部分に焼き付けられる、信頼の基点（Root of Trust；RoT）の鍵（RoT鍵）を材料として導出されます。RoTとは、そのTEEが動作する上で、そのTEEの身元を証明できる鍵（RoT鍵）を侵害不可能な形で保持できるコンポネントを指し、文字通りそのTEEの信頼性の根幹として機能します。SGXであれば、このCPU内のe-fuseこそがRoT、そこに格納されている鍵がRoT鍵として機能します。

具体的には、SGXのRoT鍵にはRPK（Root Provisioning Key）とRSK（Root Seal Key）の2つが存在します。RPKはIntel側も控えている一方で、RSKはIntelすらも焼き付けた後は情報を破棄するために知らない鍵となっています。
PCKは、この内RPKをベースに導出されます。厳密には、RPKからPK（Provisioning Key）を生成し、さらにそのPKをベースにPCKが導出されます。導出の過程では、後述のCPUSVN等のセキュリティバージョンも素材として混ぜる事で、セキュリティバージョンのアップデートがされると鍵も変わるようになっています。

このPCK導出ロジックは、極論RPKさえ知っていれば、後は誰でも再現性を持って実施する事ができます。IntelはRPKを知っていますから、全てのマシンやバージョンに対するPCKを再現可能です。よって、RAの本処理を実施する前に、そのマシンのPCKに関する情報で問い合わせる事で、Intel側は対応するPCKを再現し、証明に使うIntelをトラストアンカーとした証明書チェーン（PCK Certチェーン）を発行できるのです。RAの検証者は、このPCK Certチェーンを用いる事で、本当にそのRAで使用されたPCKがIntelをトラストアンカーとしているかを確かめる事ができます。

CPUSVNとTCB Recovery

SGXには、そのマシンの全SGX関連コンポネントのセキュリティバージョンを示す、CPUSVN（CPU Security Version Number）という情報が存在します。CPUSVNは、SGX関連の各コンポネント16個それぞれのSVN（8bit）の集合からなる、128bitのバイナリ列です。このCPUSVNは、16個のコンポネントに対する独立したSVNの集合ですので、インクリメント的に増加するものではありません。

例えば、0x01, 0x05, ...0x03というCPUSVNがあるとします。比較対象として、0x02,0x04, ...0x03というCPUSVNがあるとしましょう。この時、全バイトを見た際の数字として大きいのは比較対象の方かも知れませんが、例えば最上位から2桁目のバイト（第2コンポネント）を見た時、比較対象の方が小さいです（0x04 < 0x05）。この場合、CPUSVNの比較としては、第1コンポネントは前者の方が大きいが、第2コンポネントは後者の方が大きいので、一概にどちらのセキュリティレベルが高いとは判断できません。このように、CPUSVNという値が単純なインクリメント的ではない構成となっています。

このCPUSVNは、特に対象マシンのセキュリティ状態を検証する手続きであるAttestationにおいて大活躍します。その一環として、SGXにはTCB Recoveryという概念が存在します。

TCB（Trusted Computing Base）とは、SGX（TEE）が安全に動作するために、正しく動作し、悪意や危殆化が存在しない事が求められるコンポネントの総称です。例えば、CPU本体やマイクロコード、AE、SGXSDKのtRTSなんかはこれに含まれます[6]。文脈次第では、TCBにはユーザ定義のTEE（Enclave）も含みます。TCBとTEEは似た用語ではありますが、TEEが概念的な使われ方をされるのに対し、より具体的な領域の意味で使われる事が多いように見受けられます。

このTCBのバージョンは実はCPUSVN（別名：TCBSVN）により表現されるわけですが、例えば何らかの脆弱性が発覚した場合、そのCPUSVNのTCBはもはや安全ではなくなります。そこで、TCB Recoveryというアップデート処理により、SGXのTCBが危殆化した際に、CPUのマイクロコードやSVNをアップデートし、新規のAKの再プロビジョニングが行われます。

TEEというのはとかく日々脆弱性が見つかる技術ですが、このTCB Recoveryという仕様が存在する事で、SGXは安全性の最新化を保証した上で機能提供を行えるわけです。ただし、回復不能なまでに致命的に侵害されてしまった場合には、プラットフォームごと失効されAKの再取得ができない場合も存在するようです[27]。

AMDの古い世代のSEVというTEEでは、このTCB Recovery機能が不十分であった（TCBSVNに紐づいたAKの更新ができなかった）ため、一度鍵が侵害されると二度と回復できなくなるという致命的な不具合が存在していました[29]。現在はSEVもSEV-SNPとなり、仕組みが抜本的に見直され、その辺りはSGX同様に強固となっています。

まとめ

本記事では、過去記事よりも正確かつ詳細な情報を提供・解説すべく、SGXの比較的基本的な部分について説明しました。必要であれば、本文中でもリンクを挙げたようなページも併せて読んでいただいた上で、SGXやTEEに対する知識の増強に貢献できるようでしたら幸いです。

参考文献

[1]About the Confidential Computing Consortium, 2025/12/4閲覧, https://confidentialcomputing.io/about/
[2]XuCode: An Innovative Technology for Implementing Complex Instruction Flows, 2025/12/4閲覧, https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/xucode-implementing-complex-instruction-flows.html
[3]A Memory Encryption Engine Suitable for General Purpose Processors, Shay Gueron, https://eprint.iacr.org/2016/204.pdf
[4]Integrity protected access control mechanisms, 2025/12/4閲覧, https://patents.google.com/patent/US20220209933A1/en
[5]Update the Root of Integrity Tree in Secure
Non-Volatile Memory Systems with Low Overhead, Jianming Huang and Yu Hua, https://arxiv.org/pdf/2103.03502
[6]TEE.fail: Breaking Trusted Execution Environments
via DDR5 Memory Bus Interposition, Jalen Chuang et al., https://tee.fail/files/paper.pdf
[7]Enclavisor: A Hardware-software Co-design for
Enclaves on Untrusted Cloud, Jinyu Gu et al., https://ipads.se.sjtu.edu.cn/_media/publications/enclavisor-tc21.pdf
[8]Intel Platform Security, 2025/12/4閲覧, https://www.intel.co.jp/content/www/jp/ja/content-details/784473/intel-xeon-scalable-processors-intel-platform-security.html
[9]CIPHERLEAKs, 2025/12/4閲覧, https://cipherleaks.com/
[10]Intel TDX Demystified: A Top-Down Approach, PAU-CHEN CHENG et al., https://dl.acm.org/doi/pdf/10.1145/3652597
[11]LVI: Hijacking Transient Execution through
Microarchitectural Load Value Injection, Jo Van Bulck et al., https://lviattack.eu/
[12]SGX-Step: A Practical Attack Framework for Precise
Enclave Execution Control, Jo Van Bulck et al., https://vanbulck.net/files/systex17-sgxstep.pdf
[13]Intel® Software Guard Extensions (Intel® SGX) SDK
for Linux* OS , Intel, https://download.01.org/intel-sgx/latest/linux-latest/docs/Intel_SGX_Developer_Reference_Linux_2.26_Open_Source.pdf
[14]Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via
Dynamic Memory Aliasing, Jesse De Meulemeester et al., https://batteringram.eu/batteringram.pdf
[15]WireTap: Breaking Server SGX via DRAM Bus Interposition, Alex Seto et al., https://wiretap.fail/files/wiretap.pdf
[16]Foreshadow: Extracting the Keys to the Intel SGX
Kingdom with Transient Out-of-Order Execution, Jo Van Bulck et al., https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-van_bulck.pdf
[17]Intel SGX Explained, Victor Costan and Srinivas Devadas, https://eprint.iacr.org/2016/086.pdf
[18]インテル® SGX 命令とデータ構造の概要, 2025/12/6閲覧, https://www.isus.jp/security/overview-of-sgx-instructions-and-data-structures/
[19]Intel® Software Guard Extensions (Intel® SGX) SGX2, Frank McKeen et al. (Intel), https://caslab.csl.yale.edu/workshops/hasp2016/HASP16-16_slides.pdf
[20]Timestamp Cycle Counter (TSC), Intel, https://community.intel.com/t5/Intel-Software-Guard-Extensions/Timestamp-Cycle-Counter-TSC/m-p/1177414
[21]DuckDB-SGX2: The Good, The Bad and The Ugly within Confidential Analytical Query Processing, Ilaria
Battiston et al., https://arxiv.org/pdf/2405.11988
[22]EnigMap: External-Memory Oblivious Map for Secure Enclaves, Afonso Tinoco et al.,
https://www.usenix.org/system/files/usenixsecurity23-tinoco.pdf
[23]Exception Handling in Intel SGX, Intel, https://cdrdv2-public.intel.com/671544/exception-handling-in-intel-sgx.pdf
[24]Intel® Software Guard Extensions (Intel® SGX) Platform Software for Linux* OS, https://download.01.org/intelsgx/latest/linuxlatest/docs/Intel_SGX_PSW_Release_Notes_Linux_2.26_Open_Source.pdf
[25]id_enclave.cpp, GitHub, https://github.com/intel/SGXDataCenterAttestationPrimitives/blob/main/QuoteGeneration/quote_wrapper/quote/id_enclave/id_enclave.cpp
[26]HW_Release mode Intel SGX applications without whitelisted keypair over sgx_lc enabled processor, 2025/12/10閲覧, https://community.intel.com/t5/Intel-Software-GuardExtensions/HW-Release-mode-Intel-SGX-applications-without-whitelisted/td-p/1394136
[27]Supporting Third Party Attestation for Intel® SGX with Intel® Data Center Attestation Primitives, Vinni Scarlata et al., https://cdrdv2-public.intel.com/671314/intel-sgx-support-for-third-party-attestation.pdf
[28]SoK: SGX.Fail: How Stuff Gets eXposed, Stephan van Schaik et al., https://sgx.fail/files/sgx.fail.pdf
[29]Insecure Until Proven Updated: Analyzing AMD SEV’s Remote A‚estation, Robert Buhren et al., https://www.arxiv.org/pdf/1908.11680v1