【華爲雲技術分享】Intel SGX和ARM TrustZone淺析

咱們先理解一下業界具備統一認識的一些概念：

安全啓動：啓動過程當中，前一個部件驗證後一個部件的數字簽名，驗證經過後，運行後一個部件，不然就停止或復位系統。所以它是一個防惡意篡改的手段。

可信啓動：啓動過程當中，前一個部件度量（計算HASH值）後一個部件（一般在後一個部件被簽名校驗過以後），而後把度量安全的保存下來，好比擴展到TPM的PCR中。後續接入平臺後，部件的度量會上報到認證平臺，認證平臺會有配置一個可信白名單，若是某個部件的版本信息不在白名單裏，則認爲此設備是不受信任的，由於它可能使用了一個雖然有簽名，但可能BUG的版本。所以它是一個可信版本的管理手段。

安全啓動/可信啓動 是確保系統級別的安全手段，適用於有可信訴求的整機系統，終端設備如手機、STB、路由器等，固然也適用於通用服務器設備。

以上安全啓動和可信啓動的概念，網上以及公司W3有許多專家在討論，能夠自行進一步理解。然而，若是僅從字面要求試圖實施時，咱們又會發現許多新的問題，舉個例子：安全啓動時，確實每一級都被簽名校驗了，但肯定安全嗎？ 某一級如操做系統1分鐘前剛剛被校驗過，1分鐘後仍是可信的嗎？不見得，這個過程當中，操做系統徹底有可能已經被非法修改過了。

要作到相對更安全，要麼可以作到Runtime的實時校驗，即每次使用那一刻都要校驗。若是作不到Runtime校驗，那就想辦法將校驗過的數據安全保存起來…相關實現方案和技術其實在有前提的狀況下已具有，這是另外一個課題。

這個前提是指系統須要是不開放的嵌入式系統，由於不開放，可定製，提供特定的功能/服務，所以整機系統的保護是可行的，而且方案都是很成熟的。

那對於通用計算設備好比服務器產品是個什麼樣的狀況呢？ 基本上就是這麼個事實：

1. 系統「全局保護」愈來愈難以實現，且不切實際

緣由是當前開源共享，而且是自由的大環境。操做系統開源，應用開源，用戶自由地選擇不一樣版本的操做系統和應用，一切都不在設備廠商的控制中。

2. 「全局保護」不可行，那就將保護範圍縮小到應用的部分片斷--

這就是Intel SGX或ARM TrustZone的由來

所以，Intel SGX或ARM TrustZone是傳統的系統保護手段不可行，通用系統設備的保護方案沒法借鑑嵌入式系統的方案後，安全技術工做者轉變思路後的產物。

接下來咱們來理解一下基於這兩種技術的應用的工做過程，但此文不討論這兩個安全方案的實現原理。

Intel SGX

網上有至關多的材料，而且都有一個特色：短小精悍。因而咱們就看到了很是經典的一個圖，足以說明SGX應用的工做原理：

1. 應用在設計時，須要考慮所謂的trusted和untrusted兩部分，trusted即爲處理敏感數據的實現部分
2. 實現應用，對於trusted部分，須要使用Enclave定義語言（EDL）來實現須要的邏輯。經過EDL實現的內容，將被執行在安全區域（Enclave）
3. Enclave中的實現可被untrusted的代碼調用，當被調用時，命令會經過底層驅動傳遞Enclave中；
4. Enclave中的數據對外部不可見，也禁止外界的訪問（包括系統高權限的代碼也不可訪問）
5. 處理完以後，返回結果，但過程數據仍然在Enclave中；
6. 得到返回後，應用的untrusted部分按即定的過程繼續執行。

咱們能夠再看一下EDL的使用示例，這樣能夠了解應用開發的難易程度：

 1 enclave {  2     // An EDL file can optionally import functions from  3     // other EDL files
 4     from 「other/file.edl」 import foo, bar; // selective importing
 5     from 「another/file.edl」 import *; // import all functions  6     // Include C headers, these headers will be included in the  7     // generated files for both trusted and untrusted routines
 8     include "string.h"
 9     include "mytypes.h"
10     // Type definitions (struct, union, enum), optional
11     struct mysecret { 12         int key; 13         const char* text; 14  }; 15     enum boolean { FALSE = 0, TRUE = 1 }; 16     // Export functions (ECALLs), optional for library EDLs
17  trusted { 18         //Include header files if any 19         //Will be included in enclave_t.h 20         //Trusted function prototypes
21         public void set_secret([in] struct mysecret* psecret); 22         void some_private_func(enum boolean b); // private ECALL (non-root ECALL).
23  }; 24     // Import functions (OCALLs), optional
25  untrusted { 26         //Include header files if any 27         //Will be included in enclave_u.h 28         //Will be inserted in untrusted header file
29  「untrusted.h」 30         //Untrusted function prototypes 31         // This OCALL is not allowed to make another ECALL.
32         void ocall_print(); 33         // This OCALL can make an ECALL to function 34         // 「some_private_func」.
35         int another_ocall([in] struct mysecret* psecret) 36  allow(some_private_func); 37  }; 38 };

能夠看到，EDL並非要求用戶掌握學習一門新的語言，它的代碼仍然是類POSIX API，C/C++庫構成的，它也能夠快速的將已有的實現遷移到Enclave中。

小結

SGX Enclave徹底使用了CPU的隔離能力，不可操做外設、中斷等。EDL定義片斷屬於普通App的一部分，所以多核 、多線程均可以支持。EDL隨時隨地定義，部署很是靈活方便。可是EDL是定義在代碼中的，經過版本的逆向工程，對於數據的處理邏輯，是有可能被窺探的。

ARM TrustZone

TrustZone是標準TEE實現的一種方案，GP的TEE架構和規範標準都是由ARM TrustZone 貢獻。當咱們講TrustZone時，能夠理解爲是在講GP TEE。則於標準規範，就致使了與SGX不同的狀況，TEE實現有大量的資料能夠參考。如下是TEE應用實現的原理：

1. 基礎設施：與SGX不一樣的，TEE的功能，依賴於安全OS，首先要確保設備上已經部署了安全OS，而且要確保其是可信的；
2. 設計應用，對於須要可信保護的處理過程，須要實如今單獨的可應用中（TA）；APP以及TA須要分別開發，物理上他們是兩個程序；
3. APP執行到安全處理部分時，它經過TEE標準接口向TA發消息；
4. 調用須要進入內核態，經過驅動將消息送到TEE側；
5. TA收到消息後，來執行即定的數據處理邏輯。
6. 最後將結果返回到APP，但過程數據仍然在TEE側，

TrustZone 利用的是CPU時間片切換來模擬了安全世界，這兩個世界能夠將它理解成一個CPU上處理的兩個進程，它們經過上下文切換來將CPU的時間片佔滿以利用CPU。從安全角度，僅僅分時複用或擬化，是不足以確保安全的，所以ARM另外定義了安全框架，從硬件級別兩個世界，包括Timer、TRNG、TZPC、MMU、Cache等相關設備，不一樣的芯片廠商會有本身的考慮，這個設備多是雙份的，或者是動態切換以達到隔離目的（此處不方便貼上我司920的安全芯片框架）。同時，安全側也須要有一個可信操做系統執行應用。從原理上，REE側和TEE側是對等的，所以並不會性能的差別。應用程序的開發，除了使用TEE定義的標準接口，依賴的都POSIX API，使用標準的開發語言。

在部署應用時，SGX只須要在代碼中定義便可，在TrustZone中側須要單獨開發部署TA。通常設置廠商都會提供給應用開發者自行部署TA的方法，與SGX相比稍有一點不一樣，但並非不可接受（我的觀點），這也確實是SGX很明顯的一個優點，因而乎，ARM後面有了Newmore這樣一個概念。

但也正由於TA與APP是分離的，而且TEE側是不可查看的，所以數據的處理過程很難以被窺探。

最後，還有一點，網上還有一種聲音，認爲SGX和TrustZone「沒有什麼用」，觀點的理由是：

「且不說傳統的攻擊，如SQL注入、溢出攻擊,使得攻擊者能夠直接控制非安全應用，進而經過定義的接口取得數據，即便沒有這些漏洞，惡意軟件經過其餘途徑入侵到了OS裏面，它是否是能夠遠程注入一段代碼到APP，而後調用接口獲取數據？」

這裏必需要反駁一下，之全部這個觀點，是他沒有理解SGX或TrustZone的真正的使用場景。正確的處理方式其實上面的過程描述中咱們已經提到了：

「處理完以後，返回結果，但過程數據仍然在Enclave中」

「最後將結果返回到APP，但過程數據仍然在TEE側」

一個有價值的安全應用，並不會支持將敏感數據經過接口調用返回到非安全側。

應用的安全與否，不管是SGX仍是TrustZone應用，確實很大程度上是依賴開發者的意識。SGX或者TrustZone，它們的價值在因而隱匿敏感數據自己，以及儘量的隱藏處理敏感數據的處理過程。只有以這個導向，在應用開發時纔能有意識地向這個方向去努力。

咱們拿媒體數據舉例，一看就會明白應該如何正確使用SGX或TrustZone---

高價值的媒體內容在網絡傳輸時，它一般是被DRM加密保護的，只有憑證的訂戶才能夠解密播放。盜版者自己可能就是個訂戶，在沒有SGX、TrustZone等保護時，經過拷貝內存等手段就很容易實現盜版。但有這些技術後，加密的媒體流並不會在非安全側解密，而是送往安全側。注意，在SGX、TrustZone解完密以後的媒體，也並不會返回到安全側，而是使用底層安全驅動，直接送往解碼播放了，媒體數據直接在安全側消費了。

以上是從應用開發者角度來比較SGX與TrustZone的差別。但事實上，二者徹底不是一個層面的東西，SGX更適合拿AMD的SEV來比較，由於這兩種技術相似，都是基於所謂的realm技術（局部保護）來實現。ARM有最新的newmore方案，但目前還在驗證的概念階段，預計在2023年之後纔可能產品化，這個世界變化太快，兩年的時間實太是過久，暫不討論。

轉自鯤鵬社區