轉自：https://zhuanlan.zhihu.com/p/50894009
MS Thsis
Kristoffer Severinsen
Secure Programming with Intel SGX and Novel Applications
本次閱讀主要着眼於論文第三章
SGX教程
Intel的SGX是實現在第六代CPU之後的一組擴展指令集[1]。SGX着眼於提供一個爲用戶應用程序提供可信的執行環境，爲了達到這一目標，SGX使得應用程序在一段位於Enclave地址空間中能夠開闢一段受保護的內存空間。這段受保護空間實行嚴格的訪問控制和加密操作來提供對程序數據機密性和代碼完整性的保護，使得即使是Hypervisor、BIOS，操作系統等特權應用都不能隨意訪問這段地址空間。在enclave中運行的受保護程序還擁有一個密碼學測度，這可被髮送給客戶端來驗證程序的可信執行和爲遠程終端或不可信平臺提供secrets。
SGX的安全模型與TPM[2][3]、TXT[4]一樣依賴於軟件認證。Intel更進一步的將信任域從信任CPU&TPM提供商縮小到只需要信任CPU提供商，因此SGX通過不信任enclave之外的代碼從而減小了TCB的大小。SGX提供的功能大多數是在微指令中實現，但是保護內存不受物理***主要是由CPU中的MEE（memory encryption engine）硬件單元提供，這個硬件通過對保護內存讀寫的解密加密，保證了數據只有在CPU中的enclave內存中才是明文。
SGX的內存管理
SGX提供的軟件隔離執行環境主要是通過一套特殊的內存管理機制來實現的。如圖 1：
上圖爲SGX的內存抽象模型，包括了內存的管理、佈局與組織。PRM（Preserved Random Memory）是動態內存DRAM中一段用於SGX的保留區域，這段連續的內存空間處於最低的BIOS層而不能被任何軟件訪問。EPC（Enclave Page Cache）是PRM中操作系統分配的裝載應用程序數據和代碼的4KB大小內存的集合。EPCM（EPC Metadata）是維護EPC的入口地址，並且包含CPU跟蹤EPC內存頁元數據的狀態表。它來保證每個EPC由一個Enclave獨享。[5]
SGX的物理內存佈局
爲了防止Enclave的內存不被特權軟件染指，Intel專門保留一片物理內存來支持SGX相關功能（PRM）。如現代操作系統一樣，PRM中也使用分頁內存管理，SGX保留PRM的一部分內存用於EPC分頁。EPC內存頁只能在處理器運行於Enclave模式下才能夠被訪問，enclave之外的軟件無法訪問EPC，這一關鍵特性爲Intel 實現強大隔離執行提供了嚴格的安全保證。
由於EPC分頁機制是由不可信的操作系統來管理的，因此SGX會在每個EPCM中記錄每個EPC頁的分配信息，SGX通過此來檢測分配地址的合法性與有效性。
爲了跟蹤運行Enclave實體的身份，SGX在每個Enclave中使用一個EPC頁來維護結構體SECS（SGX enclave control structure）。SECS記錄了Enclave的元數據，包括如enclave密碼學測度等敏感信息，因此這段結構體只能被CPU的SGX管理機制訪問修改。如果Enclave中的代碼能夠修改SECS結構中的數據，如密碼學測度、身份信息等，那麼整個系統的軟件認證功能便形同虛設。EPCM結構體構造如圖：
和一個人的簡介很想，姓名（enclave SECS），性別（PT），合法公民（VALID），家庭住址（address），會做什麼（RWX）。
EPCM中還保存有頁表屬性，這些屬性需要在一開始就被enclave程序開發者（Independent Software Vendor ISV）定義好。
Enclave的內存佈局
Enclave與原宿主進程共享一片虛擬地址空間，Enclave從某種程度上來說是源程序的動態加載庫（DLL Windows,.SO Linux）。部分Enclave中映射到EPC頁的虛擬內存稱爲（enclave linear address range）ELRANGE。這段地址空間包含了Enclave中加載的數據與代碼，並且一旦EPC分配在PRM終止後這段地址對於原始進程來說是不能訪問的。任何試圖讀寫ELRANGE地址空間的enclave外部代碼都會產生一個未定義的行爲的錯誤。
由於是操作系統或者Hypervisor將線性地址（虛擬地址）轉化到物理地址，因此CPU必須要防止對enclave的地址映射***[6]。當從EPC頁地址轉換到物理地址時，CPU使用在SECS中存儲的初始分配信息來保證傳遞給地址轉換過程的EPC頁虛擬地址與EPCM中保留的EPC入口地址相匹配。這樣來防止操作系統將ELRANGE地址映射到不受保護的內存，使得ELRANGE內存對enclave之外的軟件不可見。
地址轉化過後需要進入Enclave的話，硬件線程必須要做上下文轉換使得CPU進入Enclave模式才能夠訪問Enclave中的內容，並且還必須設置初始enclave上下文，以便將控制權轉移到enclave內的一些預定義入口點。SGX使用Thread Control Structure(TCS)來保存這類入口點信息。TCS結構必須被剝去起來，不然系統通過修改入口信息就能夠在任意位置進入Enclave。與SECS一樣，TCS保留在專門的EPC頁中並且只能被SGX管理機制修改。TCS的另一個功能就是支持多個硬件線程並行執行Enclave中的代碼，每個這樣的線程必須保證線程安全且與一個TCS相關聯。代碼開發者必須爲在enclave中的每個多線程分配相應的TCS。
如果執行過程中發生中斷或者使用OCALL來調用enclave外的代碼是，需要執行程序上下文切換，此時程序的上下文被保存在一系列連續的被稱作State Save Area（SSA）的EPC中。
Enclave的生命週期
創建。操作系統調用ECREATE指令來創建一個Enclave，指令返回一個新Enclave的SECS結構，ECREATE會檢查SECS結構的正確性，並確保在SECS中將Enclave標記爲未初始化。
當Enclave未被初始化時，系統使用EADD指令來在EnclaveEPC頁中加載數據和代碼。EADD指令會檢查操作系統分配的虛擬地址是否時位於ELRANGE中。EADD指令在試圖往初始化的Enclave加載數據和代碼或者EPC頁已經加載數據或者代碼之後會失敗。在EADD之後，系統必須調用EEXTEND來對新加入的EPC頁進行測度，，並且更新Enclave的測度（MRENCLAVE）。
初始化。在將初始化代碼和數據加載進Enclave中後，操作系統調用EINIT指令來初始化Enclave。EINIT需要一個INIT Token來初始化。INIT Token是由Lauch Enclave提供的用來表徵Enclave程序作者是否存在與Intel的白名單之上。Enclave作者還必須向Intel提交他們的身份信息和他們用於簽名的公鑰來使得Intel將他們添加到白名單之中。當EINIT收到INIT Token之後，它將在SECS中將Enclave標記爲已初始化，並且禁止向Enclave中添加更多的內存頁。因此在開發者必須在設計之初就估算好程序的空間複雜度。這樣的做法一方面由Intel集中化管理身份信息使得信息透明度進一步將強並且使得惡意的enclave作者能夠被迅速辨識出來使得系統的安全性大大的上升，但另一方面，由於所有的控制權都在於Intel手中，這限制了SGX技術的商業大規模使用。
Enclave的線程機制
任何能夠將EPC頁映射到其虛擬地址空間的進程都能夠執行enclave代碼。當CPU執行enclave代碼時稱爲enclave模式，此時CPU可以訪問駐留在PRM中的EPC頁面。TCS的數目即線程數是由enclave作者決定，然後再決定有多少線程可以併發地執行enclave代碼。
初始化後的Enclave使用EENTER指令來跳轉進入Enclave執行受保護的程序。只有在RING 3的程序才能夠使用EENTER指令，EENTER並不不執行特權切換，CPU依舊在ring 3的enclave 模式下執行。EENTER和Linux系統中的Syscall很相似，用在不受信任的程序想要在受保護的環境中執行代碼，並且和Syscall一樣，EENTER也需要保存調用者的執行上下文以便在Enclave代碼返回時恢復跳轉前的狀態。
EENTER需要TCS的虛擬地址作爲輸入，接着這條指令將RIP（EIP）寄存器修改爲TCS中保存的入口偏移地址。這個入口點是由enclave應用開發者定義的，任何對此地址的修改都會導致在初始化enclave是不一致的密碼學測度。這樣保證了enclave中的代碼只會被定義好的地址上通過ECALL來調用。實際上，入口點只是enclave內存範圍內的函數，enclave作者已顯式地將該內存範圍定義爲enclave代碼的入口點。
Enclave的密碼學測度
爲了測度一個Enclave，在ECREATE，EADD，EEXTEND指令中都是用安全哈希SHA-256來對輸入做計算。EINIT將完成所有中間測度，並將最終測度結果存儲在enclave s SECS中的MRENCLAVE字段中。實際上，這意味着重新啓動的客戶端必須使用相同的enclave代碼、SGX構建工具和相同版本的驅動程序，並使用相同的enclave配置以計算相同的測度來重新創建enclave。
ECREATE使用給定給ECREATE的大小參數擴展enclave測度，以保證enclave大小和SSA具有與作者期望相同的值。需要注意的時Enclave創建時的屬性不是Enclave測度的一部分，而是包含在認證過程的信息當中。
EADD將會對給定EPC頁ENCLAVEOFFSET進行測度，該字段是期望映射到的Enclave虛擬地址空間與ELRANGE基本地址的相對偏移量。EPC的page type和權限字段也會在EADD指令中被測度。對這些字段進行密碼學測度保證了enclave的內存佈局和enclave應用作者的期望一致。SGX所提供的所有安全保證都是依賴於在創建階段對於代碼和TCS頁的測度。如果沒有這些測度，enclave代碼或者入口點地址就會被被任意修改。EADD指令不會對內存頁中的內容進行測度。
爲了將Enclave的測度擴展到包含內存內容，必須爲指定頁面EEXTEND指令。EEXTEND會以每256字節度量EPC頁面的內容，以及enclave內的預期偏移量。這樣的設計考慮（將內存頁的加載和測度分離）可能來自SGX的一些延遲約束。[5]
最後，EINIT最終將測度保存在SECS中的MRENCLAVE字段，接着將INIT字段設置爲True來完成整個Enclave的初始化。
Enclave身份
軟件認證依賴於受信軟件的密碼學測度來確定其身份。使用度量來識別受信任軟件的一個大缺點是，軟件的兩個不同版本的測度是不一樣的。SGX支持Enclave的兩種不同類型的身份系統，第一個是基於Enclave的測度，第二個是基於分發給enclave應用作者的公鑰證書。SECS結構體從某種角度來說就相當於Enclave的身份，它同時擁有兩種enclave的身份：MRENCLAVE即爲enclave的測度，MRSIGNER即爲作者的測度（或者簽名者的公鑰）。
enclave能夠基於自己的測度派生對稱加密密鑰，該密鑰可以用於加密敏感信息，這些敏感信息可以安全地存儲在enclave之外。這個祕密據說被Enclave封存起來。由於密鑰來自對enclave的代碼和初始數據測度，因此只有具有相同測度的同一個enclave才能派生相應的解密密鑰。使用從enclave測度中獲得的密鑰來封存敏感信息是Seal策略中最嚴格的，它不允許作者在不向enclave提供敏感信息的情況下更新enclave軟件。爲了能夠在同一飛地的不同版本之間遷移敏感信息，SGX依賴於一個CA爲Enclave開發者的一級證書層次結構。當初始化Enclave的時候，EINIT指令會使用Enclave中證書的信息來填充SECS中描述基於證書的enclave身份信息字段，稱爲MRSIGNER。敏感信息的遷移過程使用EGETKEY指令來基於enclave的證書身份獲取一個對稱密鑰。敏感信息使用AES-GCM分組加密後接着就可以傳給不受信任的宿主程序。宿主程序將敏感信息轉發給能夠生成相同密鑰的目標enclave，接着enclave解密消息獲得敏感信息完成敏感信息遷移。
Enclave的密鑰生成過程
此處的幾種密鑰介紹我們基於另外一篇文章（Trust is in the Keys of the Beholder:
Extending SGX Autonomy and Anonymity BY Alon Jackson）
SGX的祕密由兩種fuse密鑰組成：Root Provisioning Key（RPK）。與Intel共享此密鑰以此來支持未來的硬件認證；RootSealKey（RSK）—Intel承諾不知曉密鑰，這使得SGX能夠創建用於認證和封存的爲一直。兩者在SGX中用同樣的方式存儲（一次性燒入），但在英特爾提供的不同保證下由不同的進程產生和維護。
RootProvisionKey：Intel在製造設備時燒入的第一個密鑰就是RPK，該密鑰是在一個稱爲Intel Key Generation Facility (iKGF)的特殊用途設施中由專用硬件安全模塊(HSM)[8]隨機生成的，Intel保證該設施是一個保衛良好的離線生產設施。RPKs被交付到不同的，被英特爾的正式出版物命名爲“大容量製造系統”的生產設施中，被集成燒入到處理器內。Intel存儲所有RPK，因爲它們是SGX處理器通過在線供應協議驗證其身份的基礎。出於這原因，iKGF還將每個RPK的不同派生密鑰轉發到Intel的在線服務器。
RootSealKey：SGX中第二個燒入的密鑰稱爲RSK。和第一個密鑰一樣RSK也被保證在統計上不同部分的RSK是不同的。而與RPK不同的是，Intel宣稱它試圖清除這個密鑰所有生產過程的殘留信息，這樣每個SGX都假設它的RSK值是唯一的，並且只有它自己知道。除了下面討論的一個特殊密鑰，enclave可信接口提供的所有密鑰都是基於RSK派生的。[9]
使用Root密鑰派生
爲SGX的不同用途，Enclave使用EGETKEY指令基於不同的請求參數和請求生成的密鑰類型結合燒入的Root密鑰來生成不同用途的密鑰。
EGETKEY的一個重要參數是SVN（Security Version Number），SVN使用發出請求Enclave設置的用來代表請求生成密鑰性質的參數。主要由兩種SVN類型，CPU SVN被enclave開發者用來表示處理器的微指令更新版本，ISV SVN則用來表徵enclave代碼版本。如下圖：
SGX檢查調用者enclave中的SIGSTRUCT中設置的SVN值，並且只允許獲取小於等於調用enclave SVN值中的密鑰（向下兼容，但是不允許向上請求）。這個密鑰派生特性使得同一軟件的升級版本獲取以前版本創建的密鑰成爲可能。[9]
爲了在密鑰中包含作者的個人信息，SGX保留一個Owner Epoch參數作爲在密鑰生成過程中加入的個人熵，這個值由用戶在啓動期間通過設置密碼來配置，並且會永久保存在內存中非易失性區域。SGX EGETKEY指令設置KEYREQUEST中的KEYNAME值來比表示請求生成不同類型的密鑰。 EGETKEY生成的各種不同密鑰總結如下表：
認證
認證是一個特稱於enlave中的程序向其他enclave證明其完整性和真實性的過程。SGX認證即是一個在SGX平臺上運行的ISV enclave(證明者)希望來向遠程enclave（驗證者）證明其身份（MRENCLAVE）、和確實是在真實的SGX處理器上正確的隔離執行。
SGX支持兩種類型的認證，本地認證和遠程認證。本地認證是指一個enclave可以被運行在一個SGX之上的另一個Enclave驗證其向證明的上述兩點。遠程認證顧名思義即不要求兩個enclave存在於同一個SGX之上。
本地認證
通過使用ERREPORT指令，enclave可以獲取用來描述其軟件和硬件TCB的硬件斷言。返回的Report包含enclave的屬性、測度值和ISV附加數據。對於驗證方來說，這些值使得他們足以斷言enclave中運行代碼的完整性、執行環境(包括CPU的安全級別)以及認證enclave所使用的Seal標識。認證方指定驗證方的MRENCLAVE值，然後自己填充需要參與認證的相關數據並且使用REPORT對稱密鑰來簽名整個REPORT結構，這樣EREPORT指令的輸出結果並不會暴露用來簽名的密鑰。認證方接着將生成好的REPORT發送給驗證方，驗證方調用EGETKEY指令獲得相同的REPORT密鑰後對REPORT結構進行驗證。這個REPORY密鑰用來簽署一個SGX中所有enclave的REPORT，因此本地認證只能在同一平臺下的enclave之間進行。
本地認證過程如下圖：
在本地認證中第一次成功過後，因爲可以確保是使用真正調用者屬性填充的REPORT，因此後續對於認證過的enclave見證只需要根據預期認證要求驗證報告字段就行了。
遠程認證
在討論遠程認證之前，我們先討論SGX平臺下的一些用來獲取遠程認證密鑰的預備過程。
預備過程即一個SGX設備向Intel證明其真實性、CPU SVN合法性以及其他一些系統屬性，爲得到一個反應其真實性和TCB版本的遠程認證密鑰。認證密鑰是SGX上的敏感信息，使用密鑰認證簽名的有效性是由Intel簽名的見證平臺合法性證書來保證的。Intel使用在線的特定設施來提供SGX的預備服務。SGX的預備服務和遠程認證過程是使用Intel設計的稱爲EPID的組簽名方法[14]。爲了實現EPID預備過程Intel提供了一個特殊的Enclave Povision Enclave(PvE)。
PvE。PvE負責在平臺上使用Intel的在線供應服務器執行預備過程。爲了證明其真實性，PvE使用一些只能由特殊enclave生成的SGX特權密鑰。這兩種密鑰分別是Provision Key和Provision Seal Key。基於特殊enclave他們直接被intel簽名的SIGSTRUCT證書，因此使用特權屬性啓動的特殊enclave能夠使用EGETKEY來獲取這兩種特權密鑰。PrK密鑰生成過程分爲兩個階段，首先是將RPK和現在硬件的TCB級別綁定，接着加上enclave的軟件屬性使用AES-CMAC算法得出PrK。PrK當中並沒有包含RSK是因爲這個密鑰Intel需要預計算離線的iKGF中RPK庫來生成相同密鑰來認證平臺的合法性。Owner Opoch屬性沒有在PrK中包含與上述原因一致，只不過是通過忽略平臺所有者信息來生成PrK。Intel之所以這麼設計的原因可能是防止太多直接使用RPK而泄露密鑰。從iKGF中僅使用RPK的One Way Fuction（OWF）派生密鑰和CPU的可信邊界，可以防止派生密鑰泄漏任何原始燒入密鑰。
PvE除了生成PrK之外，還可以調用EGETKEY指令生成Provision Seal Key。和上一過程相似，PSK中也沒由包含Owner Opoch屬性。於PrK不同的是，這個密鑰使用同時使用RSK來作爲根密鑰。這樣生成的密鑰不會被平臺所有者的變化所影響，並且可以認爲這個特定平臺太所獨有的密鑰不會被Intel所知曉。
預備協議。
1：Enclave Hello。在得到硬件TCB的特定PrK後，PvE使用兩個值來初始化預備協議。第一個是PrK的OWF輸出，稱爲Platform Provision ID(PPID)。第二個反映了現有SVN下平臺宣稱的TCB級別。這兩個值都使用Intel的provisioning server公鑰加密後發送給provision 服務器。
2．服務器挑戰。Intel使用PPID來判斷平臺以前是否已經預備化過。如果是這樣的話，服
務器將加密過後的以往生成的認證密鑰添加到挑戰中去。其他情況則是服務器驗證是否給此EPID組提供服務，接着將EPID組參數、隨機參數(nouce)和預計算的TCB挑戰返回給平臺。
3：enclave回覆。在PvE使用PrK解密收到的TCB挑戰之後，它通過使用TCB挑戰作爲密鑰計算CMAC(nonce)來生成TCB證明。接着，PvE自己產生一個隨機的EPID成員密鑰使用數學方法[14]隱藏這個密鑰，以免Intel的Provision 服務器獲取到平臺生成的成員密鑰信息從而獲得一定的匿名性。爲了支持未來取回認證密鑰的服務，未被隱藏的成員密鑰將使用PvE派生的Provision Seal Key來加密。在平臺已經被認證過後，平臺必須使用PSK來解密從服務器得到的備份認證密鑰副本獲得認證密鑰，並且使用此認證密鑰來合法地簽名一條由Intel選擇的消息，一次來證明自身存在於組中並未被撤銷，如果是這樣的話那麼這個階段可以認爲此時的協議就是取回認證密鑰或者TCB更新。兩種EPID成員密鑰、TCB和未撤銷的證明作爲平臺響應的一部分一起被髮送。
4：完成。服務器收到回覆過後，首先驗證TCB證明中使用的值是否和iKGF中收到的值一致，一致時繼續EPID參與協議。接着處理隱藏的成員密鑰，以創建使用EPID組發佈者密鑰簽名的惟一證書，並與加密的成員密鑰一起存儲，以備將來重新預備事件。平臺成員密鑰與相配的簽名證書一起來形成一個獨一無二的EPID私鑰。最後服務器發送帶簽名證書的消息來結束整個協議。需要注意的時由於認證密鑰是由兩方共同構建的，因此密鑰發佈者對此並不知曉。
5：最後。PvE使用PSK解密認證密鑰，然後將其密封在enclave外來以備後用。由於EPID組按照TCB級別進行分類，因此平臺的EPID簽名可以在以後使用，這既代表SGX平臺的真僞，也代表平臺的TCB級別。
遠程認證：
在遠程認證過程中，enclave利用本地認證機制獲取遠程可驗證的Quote。這靠一個稱作Quoting Enclave（QE）的特殊enclave來完成。QE使用平臺獨一無二地非對稱密鑰將本地的Report轉化未遠程地Quote，遠程主機就可以通過相應地公鑰驗證Quote。
與上述EPID認證協議不同，SGX版本地EPID認證協議不允許依賴方來扮演EPID驗證者地角色，Intel轉而提供一個全球的在線驗證設施，稱爲Intel Attestation Server(IAS)。SGX版本的EPID認證協議涉及兩個英特爾控制的服務和兩個獨立參與者。每對都被分爲證明者和驗證者:在第一對中，QE和IAS分別扮演驗證者和驗證者的角色。在獨立地對中，ISV認證enclave和服務提供者分別扮演證明者和驗證者的角色。
QE：QE提供用於遠程認證的由認證密鑰簽名地Quotes。QE首先使用本地認證來獲得請求enclave的EREPORT接着沿着REPORT的合法性，如果合法QE使用認證密鑰簽名這個REPORT將它轉化成Quote。由於認證密鑰時使用PSK封存的，只有PvE和QE可以得到它，這個特權是在由Intel簽名SIGSTRUCT中的預備屬性指定的。
SGX服務提供者。依賴方是指服務器提供者且並沒有啓用硬件的SGX技術。服務供應商應向IAS註冊，滿足一系列英特爾規定的要求以便提交認證證據，以便進行ISA認證。主要的IAS服務包括:驗證ISV enclave Quote、請求更新的認證撤銷列表和檢索與獲取Quote的斷言歷史信息記錄。
遠程認證模式。QE支持兩種具有不同關聯屬性的Quote簽名模式，即完全匿名Quote和假名Quote。Quote的關聯屬性是由平臺唯一的認證密鑰簽名的basename參數決定。使用相同的認證密鑰多次簽名相同的basename參數會生成容易關聯的假名Quote。當使用假名Quote時，IAS首先會驗證basename是否適合特定的服務提供者相關[6]。服務提供者使用這種模式在保護用戶隱私的同時來跟蹤再次訪問的用戶並防止女巫***。相比之下，通過在不同的basename上籤署多個簽名，使得服務器提供者無法在計算上確定Quote是否使用相同的認證密鑰生成，從而保護了平臺的匿名性。因此，QE使用隨機的basename來簽署完全匿名Quote。
遠程認證協議：
首先ISV enclave向服務提供者發送初始化請求，請求中包含EPID組。
如果服務提供者希望爲此EPID組提供服務，則它通過向IAS請求更新的sig- RL(對應於平臺的特定組)來繼續服務。
然後服務提供者生成包含SPID、一個隨機數、更新的Sig-RL、可選（使用假名簽名時）basename的挑戰信息。
如果enclave支持所請求的簽名模式，那麼它將調用EREPORT指令，以創建針對平臺QE的可本地驗證的報告。爲了在enclave和服務提供者之間建立經過身份驗證的安全通道，將新生成的臨時公鑰添加到本地報告的附加數據存儲區。EREPORT連同服務提供者的挑戰一起發送到QE。
QE使用EGETKEY獲取report密鑰來驗證EREPORT。如果成功的話QE再次調用EGETKEY獲取PSK來解密遠程認證密鑰。根據所請求的認證模式，認證密鑰首先用於通過對所挑戰的basename或隨機值進行簽名來生成身份簽名。如果使用非隨機的basename，則簽名反映平臺的假名身份;否則，身份簽名是完全匿名的。然後使用認證密鑰計算平臺身份簽名上的兩個知識簽名。第一個證明身份的簽名是用英特爾認證的密鑰簽名的。第二個是一個未撤銷證明，它證明用於身份簽名的密鑰不會創建所挑戰的Sig-RL中的任何身份簽名。然後使用QE代碼中硬編碼中IAS的公鑰對最後的Quote進行加密，結果被髮送回驗證飛地。[16]
Enclave將Quote轉發給服務提供者以驗證。
由於Quote時被加密它只能被Intel驗證，因此服務提供者將Quote轉發給IAS。
IAS首先根據Quote的身份簽名驗證它的EPID證明。然後，它通過爲列表中的每個私鑰計算Quote basename上的身份簽名驗證它們都不等於Quote的身份簽名，同時來驗證平臺是否在Priv-RL列表中。這將完成平臺的有效性檢查，然後IAS將創建一個新的認證驗證報告作爲對服務提供者的回覆。認證驗證報告包括平臺爲認證enclave生成的Quote結構。[10]
一份陽性的認證驗證報告證實enclave的確是在真正的Intel SGX處理器上運行一段特定代碼。然後，服務提供者有責任驗證ISV enclave身份，並向平臺提供適當的回覆。[10]
整個過程如下圖所示
參考文獻
[1]Frank McKeen et al. “Innovative instructions and software model
for isolated execution.” In: HASP@ ISCA. 2013, p. 10.http ://
http://css.csail.mit.edu/6.858/2015/readings/intel-sgx.pdf(visited on
01/30/2017).
[2]W. Arthur, D. Challener, and K. Goldman. A Practical Guide to TPM
2.0. APress, 2015. DOI: 10.1007/978-1-4302-6584-9
[3]S. Delaune et al. “Formal analysis of protocols based on TPM state
registers.” In: Proceedings of the 24th IEEE Computer Security Foundations
Symposium (CSF’11). Cernay-la-Ville, France: IEEE Computer
Society Press, June 2011, pp. 66–82. DOI: 10.1109/CSF.2011.12.
[4]David Grawrock. Dynamics of a Trusted Platform: A Building Block
Approach. Intel Press, 2009.
[5]Victor Costan and Srinivas Devadas. “Intel SGX Explained.” In: IACR
Cryptology ePrint Archive 2016 (2016), p. 86.
[6]Yuanzhong Xu, Weidong Cui, and Marcus Peinado. “Controlledchannel
attacks: Deterministic side channels for untrusted operating
systems.” In: IEEE Symposium on Security and Privacy. IEEE. 2015,
pp. 640–656.
[7]Intel Corporation. Intel® Software Guard Extensions Programming
Reference. 2014. https://software.intel.com/sites/default/_les/
managed/48/88/329298-002.pdf.
[8]C.R.E.B.F.M.Simon Johnson, Vinnie Scarlata. Intel software
guard extensions: Epid provisioning and attestation services,
intel-sgx-epid-provisioning-and-attestation-services.
[9]Intel. Intel Software Guard Extensions Programming Reference (rev2), Oct. 2014.
329298-002US.
[10]Intel Software Guard Extensions: Intel Attestation Service API, version
ias-api-spec.pdf.
[11] http://www.google.com/patents/US8885819.
[12]V. Costan and S. Devadas. Intel SGX explained. Cryptology ePrint Archive, Report
2016/086, 2016. http://eprint.iacr.org/.
[13]I. Anati, S. Gueron, S. Johnson, and V. Scarlata. Innovative technology for CPU
based attestation and sealing. In Proceedings of the 2nd International Workshop on
Hardware and Architectural Support for Security and Privacy, volume 13, 2013.
[14]E. Brickell and J. Li. Enhanced privacy id from bilinear pairing. Cryptology ePrint
Archive, Report 2009/095, 2009. http://eprint.iacr.org/2009/095.
[15]Intel. SGX Tutorial, ISCA 2015. http://sgxisca.weebly.com/, June 2015.
[16]S. Johnson, V. Scarlata, C. Rozas, E. Brickell, and F. Mckeen. Intel software guard
extensions: EPID provisioning and attestation services, April 2016.