Intel SGX學習

轉自：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,

https://software.intel.com/en-us/blogs/2016/03/09/

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

https://software.intel.com/sites/default/files/managed/7e/3b/

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.