通俗理解SGX attestation

英特爾CPU從第六代酷睿開始增加了SGX特性，含有Intel Xeon版服務器級的CPU也包含了，比如Intel Xeon E3 v6。它是Software Gaurd Extensions的縮寫，目的是從硬件實現信息安全。簡單來講就是英特爾通過硬件來實現一個安全的沙盒。這裏一個電腦可以分爲安全的沙盒和不安全的沙盒外部環境。沙盒外面的環境被認爲是有可能被黑客或者惡意者完全操控的，是不安全的。沙盒外面的代碼無法窺探或者修改沙盒內部的代碼和數據；沙盒內部的代碼執行也不會影響外部環境，沙盒有專門的「口子」，用於將數據從不安全的環境傳入沙盒或者從沙盒內傳出到非安全的環境。這裏我們把沙盒用TEE表示，它是Trusted Execution Environment的簡稱，沙盒內部的環境中的程序被稱爲enclave程序，中文翻譯爲飛地。

TEE中的enclave程序可以由開發人員自定義開發，然後放到TEE中執行。現在Bob將他的enclave程序放到他本地且支持Intel SGX硬件的電腦上運行，也可以放到遠方的其它人的電腦上執行。enclave運行的時候，他可以通過客戶端傳給enclave數據或者接受enclave計算的結果，如果enclave運行在Bob本人的電腦上，安全性沒有問題；但是，如果enclave運行在其它人的電腦上，就讓他擔心了！遠方的電腦可能是雲服務提供商，他並不百分之百相信提供商是善良的，他希望（1）他的enclave是在支持Intel SGX的硬件平臺上面執行的。如果遠方的enclave運行在非Intel SGX支持的環境下，比如模擬的環境，就不能帶來安全行保證；並且（2）希望在他的enclave程序初始化的時候完整性沒被破壞，也就是enclave沒有被篡改；（3）在他跟enclave程序通信的過程中數據是加密的。爲了打消他的安全顧慮，就需要用到SGX attestation技術了。SGX Attestation有local attestation的和remote attestation的兩種。

如果兩個enclave程序運行在同一個計算機上，那麼這兩個enclave怎麼樣才能相信對方是安全的呢？這時候便需要local attestation。

實現這種方式最直接的方法是英特爾公司爲每一個SGX CPU生成一對公私**對，將私鑰燒錄在不可刪改的硬件上面。我們假設英特爾的CPU能夠實現複雜的密碼原語，比如進行數字簽名。英特爾公司還需要提供一個公鑰證書認證中心（Certificate Authority）爲每一個SGX CPU和它的公鑰關聯起來，這個跟互聯網上面的公鑰認證中心是一個道理，目的是提供公鑰的認證，讓其它人能夠確認其所持有或使用的某一個公鑰是屬於切確的團體或者個人的。比如我希望使用A的公鑰加密一個消息然後發給A，A使用他的私鑰就能解密和查看這個消息，但是在加密前我希望能夠確定這是A的公鑰，怎麼確定呢？就需要到公鑰認證中心去查詢了。如果我使用的是黑客調包後的公鑰來加密我的消息，那麼黑客在得到密文後就可以直接解密查看這消息了。這些條件具備之後，在enclave完成初始化之後，enclave程序根據初始化狀態信息生成一個哈希摘要，然後讓SGX CPU簽名，即數字簽名（跟現實中的簽名是同一個意思，表示簽名者認同了所簽署的文件），然後將簽名和哈希摘要一同發給Bob。Bob收到之後，利用英特爾提供的Attestation service來認證enclave發來的數據，確信遠程的enclave確實是運行在可信的Intel SGX GPU上面。

一個攻擊者是不能夠僞造簽名的，因爲（1）攻擊者不能夠獲得燒錄在硬件上面的CPU私鑰；（２）只有enclave程序才能夠讓CPU數字簽名；（３）不同的enclave程序的哈希摘要是不一樣的，一個攻擊者不能夠僞造enclave的哈希摘要。因爲上面的原因，如果遠方電腦發來的數據能夠通過認證，那麼Bob就信服他enclave程序在遠方電腦上面安全運行。

如果Bob希望向他的enclave程序傳輸一些數據或者希望接收enclave的執行結果，但是他不想讓其它人知道所傳輸的內容。這就需要在Bob和enclave之間建立一個安全的傳輸通道了。如何建立呢？原理跟現在瀏覽器的HTTPS的TLS差不多。先使用**交換算法（Diffie-Hellmann key exchange）協商一個對稱加密算法的**，然後通信雙方都使用這個**來加密消息進行通信。

前面我們有一個假設，「英特爾的CPU能夠實現複雜的密碼原語」，不幸的是，實際上現在的英特爾CPU不能在硬件層面實現如此複雜的用於數字簽名的密碼原語。於是，英特爾採用了軟件的方式來實現。但是普通的軟件有被黑的可能，於是就有了Quoting Enclave （QE），顧名思義它是一個特殊的enclave程序，它能夠安全地執行「數字簽名」的邏輯計算，目的是用於remote attestation的數字前面。現在我們假設這個QE是安全可靠的，那麼剩下的問題是如何讓Bob的enclave向QE證明自己「運行在與QE同一個平臺上」。如果這兩個enclave都運行在同一個電腦上面，證明過程就是的local attestation了。local attestation的一個方便的地方是兩個enclave都能夠使用相同的被燒錄在SGX CPU上面的私鑰：Bob的enclave可以讓SGX CPU使用類似於「數字簽名」的方式簽名一個消息，讓QE驗證 （這裏涉及到 message authentication code (MAC) tag）。這樣不直接告訴Bob的enclave SGX CPU的**，就能夠讓QE確信Bob的enclave運行在同一個電腦上面。

最後需要提到的是，英特爾的公鑰認證中心的服務跟傳統的有一定區別。英特爾使用的是Enhance Privacy ID（EPID），表示的是羣組簽名。它將簽名者劃分羣組。當由用戶拿着一個公鑰證書來驗證簽名者的時候，CA只返回簽名者所在的羣組，而不是特定的簽名者。這樣做的目的是爲簽名者提供匿名保護。

-----------------------------內容添加------------------------------

Remote Attestation的例子
結合上面的圖片講解remote attestation。圖片中有五個實體，他們分爲兩大部分，左邊三個屬於運行在SGX CPU平臺上面的遠程計算機；右邊的challenger便是前文中的Bob了。右下角的Attestation Verification是Intel提供的認證服務。

Application是運行在TEE之外的應用程序，非安全的，Application Enclave是前文Bob的enclave程序。（1）Challenger（這裏是Bob）給遠方的application發起一個challenge，伴隨一個nonce隨機數，用於遠程電腦的活性檢測。（2）Application向Application Enclave發送Quoting Enclave的ID和Bob的challange以及nonce隨機數。（3）Application Enclave收到消息之後，根據自己的程序初始化日誌和其他數據（這些用manifest表示），生成一個摘要，放到User Data中，再調用EREPORT指令生成一個報告，目的是將manifest綁定到這個Application Enclave。最後將報告發送給Application。（4）Application把它轉發給Quoting Enclave，讓Quoting Enclave對它簽名。（5）Quoting Enclave先驗證這個報告，通過之後使用EPID中的私鑰進行簽名，生成一個QUOTE，然後向Application返回QUOTE。（6）Application將QUOTE和其他相關的數據發送給Challenger（7）Challenger結合EPID公鑰和Attestation Verification Service認證QUOTE。

謝謝

reference

Anati, Ittai, et al. "Innovative technology for CPU based attestation and sealing."Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy. Vol. 13. ACM New York, NY, USA, 2013.

Johnson, Simon, et al. "Intel® software guard extensions: Epid provisioning and attestation services."White Paper1 (2016): 1-10.

Costan, Victor, and Srinivas Devadas. "Intel SGX Explained."IACR Cryptology ePrint Archive2016.086 (2016): 1-118.

http://chenju2k6.github.io/blog/2018/02/Attestation