簡介
在軟件和服務通過互聯網部署的時代，英特爾 SGX 和英特爾構架擴展使得服務提供商能夠通過有線或無線方式為應用程序提供敏感內容，並自信地認為他們的秘密得到妥善保護。為此，服務提供商必須能夠確定地知道遠程平台上正在運行什么軟件以及它在哪個環境中執行。
軟件周期
支持英特爾 SGX 的軟件不附帶敏感數據。安裝軟件后，它會聯系服務提供商以將數據遠程提供給 enclave。然后，該軟件會加密數據並將其存儲以備將來使用。如下圖：
- enclave 啟動 —— 不受信任的應用程序啟動 enclave 環境以保護服務提供商的軟件。在構建 enclave 后，會記錄一個安全日志，反映 enclave 的內容及其加載方式，該安全日志稱為 enclave 的“度量”。
- attestation —— enclave 聯系服務提供商以將其敏感數據提供給 enclave，此時平台產生一個安全斷言，用於識別硬件環境和 enclave。
- provisioning —— 服務提供商評估 enclave 的可信度，它使用 attestation 來建立安全通信並向 enclave 提供敏感數據，使用安全通道，服務提供商將數據發送到 enclave 。
- sealing/unsealing —— enclave 使用持久的基於硬件的加密密鑰來安全地加密和存儲其敏感數據，以確保只有在受信任的環境恢復時才能檢索數據。
- 軟件升級 —— 服務提供商可能需要 enclave 軟件更新。為了簡化數據從舊軟件版本到新版本的遷移，軟件可以請求舊版本的密封密鑰來解封數據並請求新版本的密封，這樣密封的數據將無法用於以前版本的軟件。
最后，當平台所有者計划轉讓平台所有權時，應將其所有權期間可用的秘密設為不可訪問。英特爾 SGX 包含一個用戶擁有的特殊持久值，該值在更改時會更改軟件可用的所有密鑰。
安全模式
希望向遠程平台提供機密的服務提供商必須事先知道遠程平台的保護策略滿足要部署的機密的保護要求。根據英特爾 SGX 的安全模型，負責保護機密的可信計算基礎 (TCB) 包括處理器的固件和硬件，以及 enclave 內的軟件。enclave 編程者可以使用 Intel SGX 專用的密封和認證組件，這些組件支持以下安全模型斷言，以向服務提供商證明機密將根據預期的安全級別得到保護：
- 英特爾 SGX 為 enclave 實例提供了從 enclave 身份平台請求安全斷言的方法。
- 英特爾 SGX 為 enclave 實例提供了驗證源自同一平台上其他 enclave 實例的斷言的方法。
- 英特爾 SGX 為遠程實體提供了驗證來自 enclave 實例的斷言的方法。
- 英特爾 SGX 允許 encalve 實例獲取綁定到平台和 enclave 的密鑰。
Intel SGX 指令
英特爾 SGX 架構提供硬件指令 EREPORT 和 EGETKEY，以支持證明和密封。接受 SGX 安全模型的機密所有者可以根據這些指令向負責系統安全的 TCB 報告。
為了創建 enclave 環境，不受信任的軟件使用英特爾 SGX 指令，這些指令還計算已啟動的環境的加密度量。
為了啟用 attestation 和 sealing，硬件提供了兩個額外的指令 EREPORT 和 EGETKEY。EREPORT 指令提供了一個證據結構，該結構以加密方式綁定到硬件以供 attestation 驗證者使用。EGETKEY 為 enclave 軟件提供了對 attestation 和 sealing 過程中使用到的 Report 密鑰和 seal 密鑰的訪問權限。
度量
英特爾 SGX 架構負責為 attestation 和 sealing 建立身份標識符。對於每個 enclave，它提供兩個度量寄存器，MRENCLAVE 和 MRSIGNER：MRENCLAVE 提供了 enclave 代碼和數據的身份標識，像在構建時一樣；而 MRSIGNER 提供了 enclave 的密封機構的身份標識符。
MRENCLAVE - Enclave Identity
“Enclave Identity”是 MRENCLAVE 的值，它是內部日志的 SHA-256 摘要，記錄了在構建 enclave 時完成的所有活動。該日志包含以下信息：
- 頁面內容（代碼段、數據段、堆、棧）
- 頁面在 enclave 中的相對位置
- 與頁面相關聯的任何安全標志
一旦 enclave 通過 EINIT 指令完成初始化，MRENCLAVE 將不會再進行更新。MRENCLAVE 的最終值是一個 SHA-256 摘要，以加密方式標識 enclave 內的代碼、數據和棧、enclave 頁面的放置順序和位置以及每個頁面的安全屬性。對這些變量中的任何一個進行任何更改都會導致 MRENCLAVE 中的值不同。
MRSIGNER - Sealing Identity
enclave 具有用於數據保護的第二個身份，稱為“Sealing Identity”。Sealing Identity 包括“密封機構”、產品 ID 和版本號。密封機構是在 enclave 發布之前對其進行簽名的實體，通常是 enclave 創建者。enclave 創建者向硬件提供使用 RSA 算法簽名的 enclave 證書 (SIGSTRUCT)，其中包含 enclave 身份的預期值、MRENCLAVE 和密封機構的公鑰。硬件使用其中包含的公鑰檢查證書上的簽名，然后將計算出的 MRENCLAVE 值與簽名版本中的對應值進行比較。這些檢查通過后，密封機構的公鑰的散列值將會被存儲在 MRSIGNER 寄存器中。需要注意的是，如果多個 enclave 由同一個 Sealing Authority 簽名，則它們都將具有相同的 MRSIGNER 值。Sealing Identity 的值可用於密封數據，其方式是來自同一密封機構的 enclave（例如，同一 enclave 的不同版本）可以共享和遷移其密封數據。
證明
attestation 是證明某個軟件在平台上已正確實例化的過程，它是第三方可以確信正確的軟件在啟用英特爾 SGX 技術的平台上的 enclave 內安全運行的一種機制。為此，英特爾 SGX 架構會生成一個證明斷言，該斷言傳達以下信息：
- 將被證明的軟件環境的身份
- 任何不可測量狀態的詳細信息（例如軟件環境可能運行的模式）
- 軟件環境希望與其自身相關聯的數據
- 為生成斷言，與平台 TCB 綁定的加密信息
英特爾 SGX 架構提供了一種機制，用於在同一平台上運行的兩個 enclave 之間創建通過身份驗證的斷言（本地證明），以及另一種擴展本地證明以向平台外的第 3 方提供斷言的機制（遠程證明）。
最后，為了在系統中獲得最大的可信度，認證密鑰應該只綁定到特定的平台TCB。如果平台 TCB 發生變化，比如通過微碼更新，平台證明密鑰應該被替換，以正確代表 TCB 的可信度。
平台內 enclave 認證
應用程序開發人員可能希望編寫可以相互協作以執行某些更高級別功能的 enclave。為了做到這一點，他們需要一種讓 enclave 相互驗證的機制。為此，英特爾 SGX 架構提供了 EREPORT 指令。
當被 enclave 調用時，EREPORT 創建一個簽名結構，稱為 REPORT。REPORT 結構包含 enclave 的兩個身份標識符、與 enclave 關聯的屬性（屬性標識模式和在 ECREATE 期間建立的其他屬性）、硬件 TCB 的可信度以及 enclave 開發人員希望傳遞給目標 enclave 的附加信息，以及消息驗證碼 (MAC) 標簽。目標 enclave 是驗證 REPORT 結構 MAC 信息的 enclave，以確定創建 REPORT 的 enclave 在同一平台上運行。
這里的 MAC 使用稱為“Report Key”的密鑰生成，如下表所示，Report Key 僅對目標 enclave 和 EREPORT 指令已知。驗證（目標）enclave 可以使用 EGETKEY 指令檢索其自己的 Report Key。EGETKEY 為 enclave 提供密鑰，其中包括 Report Key，可用於對稱加密和身份驗證。目標 enclave 使用 Report Key 重新計算 Report 數據結構上的 MAC，並驗證 Report 是由證明（報告）enclave 生成的。英特爾 SGX 架構使用 AES128-CMAC 作為 MAC 算法。
每個 REPORT 結構還包括一個用於用戶數據的 256 位字段，該字段將 enclave 內的數據綁定到 enclave 身份（如 REPORT 中所表達的那樣）。這個字段可以用來擴展帶有輔助數據的 REPORT，方法是用輔助數據的散列摘要填充它，然后與 REPORT 一起提供。用戶數據字段的使用使 enclave 能夠構建更高級別的協議，以在其自身與另一個實體之間形成安全通道。
例如，通過交換認證公共 Diffie-Hellman 密鑰的 REPORT，這些密鑰是使用相互同意的參數在 enclave 內隨機生成的，enclave 可以生成經過身份驗證的共享秘密，並使用它來保護它們之間的進一步通信。英特爾架構支持通過可供 enclave 軟件使用的 RDRAND 指令生成真隨機數。
下圖顯示的示例流程說明了，同一平台上的兩個 enclave 如何相互驗證，並驗證對方是否在同一平台上的 enclave 內運行，從而滿足英特爾 SGX 的安全模型。
- 在 enclave A 和 B 之間的通信路徑建立后，enclave A 獲得 enclave B 的 MRENCLAVE 值。請注意，此步驟中的通信路徑不必是安全的。
- enclave A 用 enclave B 的 MRENCLAVE 調用 EREPORT 指令以創建目的地為 enclave B 的簽名 REPORT，enclave A 通過不受信任的通信路徑將其 REPORT 發送到 enclave B。
- 收到 enclave A 的 REPORT 后：
-
- enclave B 調用 EGETKEY 來檢索它的 Report Key，在 REPORT 結構上重新計算 MAC，並將結果與 REPORT 中的 MAC 進行比較。如果 MAC 值匹配，則確認 A 確實是一個與 enclave B 在同一平台上運行的 enclave，因此 A 在遵守英特爾 SGX 安全模型的環境中運行。
- 一旦驗證了 TCB 的固件和硬件組件，enclave B 就可以檢查 enclave A 的 REPORT 以驗證 TCB 的軟件組件：（1）MRENCLAVE 反映了在 enclave 內運行的軟件鏡像的內容（2）MRSIGNER 反映了密封者的身份
- 然后，enclave B 可以通過使用它剛剛收到的 REPORT 中的 MRENCLAVE 值，為 enclave A 創建 REPORT 來回報。
- enclave B 將其 REPORT 傳輸到 enclave A。enclave A 可以用與 enclave B 類似的方式驗證 REPORT，確認 enclave B 與 enclave A 存在於同一平台上。
跨平台 enclave 認證
用於平台內 enclave 認證的身份驗證機制使用對稱密鑰系統，其中只有驗證 REPORT 結構的 enclave 和創建 REPORT 的 EREPORT 指令才能訪問身份驗證密鑰。創建可以在平台外驗證的證明需要使用非對稱加密。英特爾 SGX 啟用了一個特殊的 enclave，稱為 quoting enclave，專門用於遠程認證。quoting enclave 使用上述平台內 enclave 證明方法驗證來自平台上其他 enclave 的 REPORT，然后用設備特定（私有）非對稱密鑰創建的簽名替換這些 REPORT 上的 MAC，此過程的輸出稱為 QUOTE。
- Intel Enhanced Privacy ID (EPID)
當在平台的整個生命周期中使用少量密鑰時，使用標准非對稱簽名方案的證明會引起隱私問題。為了克服這個問題，英特爾引入了一個直接匿名認證方案的擴展，該方案由TPM使用，稱為“英特爾增強隱私ID（EPID）”，用於 quoting enclave 簽署 enclave 認證。EPID 是一種組簽名方案，它允許平台在不唯一標識平台或鏈接不同簽名的情況下對對象進行簽名。相反，每個簽名者都屬於一個“組”，驗證者使用該組的公鑰來驗證簽名。EPID 支持兩種簽名模式：在 EPID 的全匿名模式下，驗證者無法將給定的簽名與組的特定成員相關聯；在偽匿名模式下，EPID 驗證器能夠確定它之前是否已驗證過平台。
- The Quoting Enclave
quoting enclave 創建用於簽署平台證明的 EPID 密鑰，然后由 EPID 后端基礎設施進行驗證。EPID 密鑰不僅代表平台，還代表底層硬件的可信度。
當 enclave 系統運行時，只有 quoting enclave 可以訪問 EPID 密鑰，並且 EPID 密鑰與處理器固件的版本綁定。因此，可以看到 QUOTE 是由處理器本身發出的。
- Example Remote Attestation Process
下圖顯示了，在用戶平台上具有安全處理元件的應用程序如何向具有挑戰性的服務提供商提供證明，以便從提供商那里獲得一些增值服務。請注意，大多數用法中，很少使用此過程（例如，在注冊時）為 enclave 提供通信密鑰，然后在后續連接中直接使用該密鑰。
- 最初，應用程序需要來自平台外部的服務，並與服務提供系統建立通信。服務提供商向應用程序發出挑戰，以證明它確實在一個或多個 enclave 內運行了必要的組件，挑戰本身包含一個用於活躍性目的的隨機數。
- 應用程序提供了 quoting enclave 的標識符，並將其與提供者的挑戰一起傳遞給應用程序的 enclave。
- enclave 生成一個清單，其中包括對挑戰的響應和臨時生成的公鑰，供挑戰者用於將秘密傳送回 enclave。然后它生成清單的哈希摘要，並將其作為 EREPORT 指令的用戶數據包含在內，該指令將生成將清單綁定到 enclave 的 REPORT。最后 enclave 將 REPORT 發送回應用程序。
- 應用程序將 REPORT 轉發到 quoting enclave 進行簽名。
- quoting enclave 使用 EGETKEY 指令檢索其 Report Key 並驗證 REPORT。quoting enclave 創建 QUOTE 結構並使用其 EPID 密鑰對其進行簽名。quoting enclave 將 QUOTE 結構返回給應用程序。
- 應用程序將 QUOTE 結構和任何相關的支持數據清單發送給服務挑戰者。
- 挑戰者使用 EPID 公鑰證書和吊銷信息或證明驗證服務來驗證 QUOTE 上的簽名。然后，它使用 USERDATA 驗證清單的完整性，並檢查清單以獲取對它在步驟 1 中發送的挑戰的響應。
密封
當 enclave 被實例化時，其數據被維護在 enclave 邊界內，硬件為其提供保護（機密性和完整性）。但是，當 enclave 進程退出時，enclave 將被破壞，並且 enclave 內受保護的任何數據都將丟失。如果數據打算在以后重新使用，則 enclave 必須進行特殊安排以將數據存儲在 enclave 之外。
上面的表格顯示，EGETKEY 提供對永久性密封密鑰的訪問，enclave 軟件可以使用這些密鑰加密和保護數據的完整性。英特爾 SGX 對 enclave 使用的加密方案沒有限制。當與平台提供的其他服務（例如單調計數器）結合使用時，也可以對數據進行重放保護。
英特爾 SGX 支持的密封策略
調用EGETKEY時，enclave 會選擇標准或策略，enclave 可以為其訪問此密鑰。這些策略有助於控制敏感數據對 enclave 未來版本的可訪問性。
英特爾 SGX 支持兩種密封密鑰策略：
- 密封 enclave 身份
- 密封 sealing 標識
密封 enclave 的身份會生成一個密鑰，該密鑰可用於該確定 enclave 的任何實例。這不允許未來的軟件訪問這個 enclave 的秘密。密封 enclave 的密封標識會產生一個密鑰，該密鑰可用於由同一密封機構簽署的其他一些 enclave。這可用於允許較新的 enclave 訪問先前版本存儲的數據。
只有使用相同策略規范執行 EGETKEY 的后續 enclave 實例，才能檢索密封密鑰，並解密出先前的 enclave 實例使用該密鑰密封的數據。
- 密封 Enclave Identity
當密封 enclave 的 Enclave Identity 時，EGETKEY 將基於 enclave 的 MRENCLAVE 的值。任何影響 enclave 度量的更改都會產生不同的密鑰。這導致每個 enclave 使用不同的密鑰，從而在 enclave 之間提供完全隔離。使用此策略的一個副產品是，同一個 enclave 的不同版本也會有不同的密封密鑰，從而阻止了離線數據遷移。
此策略對於發現漏洞后不應使用舊數據的用途非常有用。例如，如果數據是身份驗證憑證，則服務提供商可以撤銷這些憑證並提供新的憑證，訪問舊憑證可能有害。
- 密封 Sealing Identity
當密封 enclave 的 Sealing Identity 時，EGETKEY 基於 enclave 的 MRSIGNER 的值和 enclave 的版本來確定密鑰。MRSIGNER 反映了簽名 enclave 證書的密封機構的密鑰/身份。
密封 Sealing Identity 比 Enclave Identity 的優勢在於它允許在 enclave 版本之間離線遷移密封數據。密封機構可以簽署多個 enclave 並使它們能夠檢索出相同的密封密鑰，這些 enclave 可以透明地訪問被另一個 enclave 密封的數據。
Sealing Idnetity 密封時，不應允許舊軟件訪問新軟件創建的數據。當發布新軟件的原因是為了解決安全問題時，情況確實如此。為方便起見，密封機構可以選擇規定一個安全版本號 (SVN) 作為密封標識的一部分。EGETKEY 允許 enclave 指定在生成 Seal Key 時使用哪個 SVN，它將只允許 enclave 為其密封標識或以前的標識指定 SVN。當 enclave 密封數據時，它可以選擇設置允許訪問該密封密鑰的 enclave 的最小 SVN 值。他可以保護未來的機密不被舊的易受攻擊的軟件訪問，但仍然可以實現無縫升級過渡，其中所有以前的機密在升級后都可用。
SVN 與產品版本號不同。一個產品可能有多個版本，具有不同的功能，但具有相同的 SVN。飛地編寫者有責任與他們的客戶溝通（如有必要），哪些產品版本具有相同的安全等效性。
從平台中刪除秘密
Intel SGX 架構提出了一種機制，稱為 OwnerEpoch，它使平台所有者可以通過更改單個值來更改系統中的所有密鑰。由於通過 EGETKEY 指令請求密鑰時會自動包含 OwnerEpoch，因此使用特定 OwnerEpoch 值密封的數據對象只有在 OwnerEpoch 設置為相同值時才能解封。
該機制的主要目的是允許平台所有者在將平台轉讓給其他人（永久或暫時）之前，以簡單且可恢復的步驟拒絕訪問平台上的所有密封秘密。在轉移平台之前，平台所有者可以使用 OEM 提供的鈎子將 OwnerEpoch 更改為不同的值。在臨時轉移的情況下（例如平台維護），一旦平台歸還，平台所有者可以將 OwnerEpoch 恢復到其原始值，並可以恢復對密封秘密的訪問。