我們先理解一下業界具有統一認識的一些概念：
安全啓動：啓動過程中，前一個部件驗證後一個部件的數字簽名，驗證通過後，運行後一個部件，否則就中止或復位系統。因此它是一個防惡意篡改的手段。
可信啓動：啓動過程中，前一個部件度量（計算HASH值）後一個部件（通常在後一個部件被簽名校驗過之後），然後把度量安全的保存下來，比如擴展到TPM的PCR中。後續接入平臺後，部件的度量會上報到認證平臺，認證平臺會有配置一個可信白名單，如果某個部件的版本信息不在白名單裏，則認爲此設備是不受信任的，因爲它可能使用了一個雖然有簽名，但可能BUG的版本。因此它是一個可信版本的管理手段。
安全啓動/可信啓動 是確保系統級別的安全手段，適用於有可信訴求的整機系統，終端設備如手機、STB、路由器等，當然也適用於通用服務器設備。
以上安全啓動和可信啓動的概念，網上以及公司W3有許多專家在討論，可以自行進一步理解。然而，如果僅從字面要求試圖實施時，我們又會發現許多新的問題，舉個例子：安全啓動時，確實每一級都被簽名校驗了，但確定安全嗎？ 某一級如操作系統1分鐘前剛剛被校驗過，1分鐘後還是可信的嗎？不見得，這個過程中，操作系統完全有可能已經被非法修改過了。
要做到相對更安全，要麼能夠做到Runtime的實時校驗，即每次使用那一刻都要校驗。如果做不到Runtime校驗，那就想辦法將校驗過的數據安全保存起來…相關實現方案和技術其實在有前提的情況下已具備，這是另一個課題。
這個前提是指系統需要是不開放的嵌入式系統，因爲不開放，可定製，提供特定的功能/服務，因此整機系統的保護是可行的，並且方案都是很成熟的。
那對於通用計算設備比如服務器產品是個什麼樣的情況呢？ 基本上就是這麼個事實：
- 系統“全局保護”越來越難以實現，且不切實際
原因是當前開源共享，並且是自由的大環境。操作系統開源，應用開源，用戶自由地選擇不同版本的操作系統和應用，一切都不在設備廠商的控制中。
2. “全局保護”不可行，那就將保護範圍縮小到應用的部分片段--
這就是Intel SGX或ARM TrustZone的由來
因此，Intel SGX或ARM TrustZone是傳統的系統保護手段不可行，通用系統設備的保護方案無法借鑑嵌入式系統的方案後，安全技術工作者轉變思路後的產物。
接下來我們來理解一下基於這兩種技術的應用的工作過程，但此文不討論這兩個安全方案的實現原理。
Intel SGX
網上有相當多的材料，並且都有一個特點：短小精悍。於是我們就看到了非常經典的一個圖，足以說明SGX應用的工作原理：
- 應用在設計時，需要考慮所謂的trusted和untrusted兩部分，trusted即爲處理敏感數據的實現部分
- 實現應用，對於trusted部分，需要使用Enclave定義語言（EDL）來實現需要的邏輯。通過EDL實現的內容，將被執行在安全區域（Enclave）
- Enclave中的實現可被untrusted的代碼調用，當被調用時，命令會通過底層驅動傳遞Enclave中；
- Enclave中的數據對外部不可見，也禁止外界的訪問（包括系統高權限的代碼也不可訪問）
- 處理完之後，返回結果，但過程數據仍然在Enclave中；
- 獲得返回後，應用的untrusted部分按即定的過程繼續執行。
我們可以再看一下EDL的使用示例，這樣可以瞭解應用開發的難易程度：
enclave {
// An EDL file can optionally import functions from
// other EDL files
from “other/file.edl” import foo, bar; // selective importing
from “another/file.edl” import *; // import all functions
// Include C headers, these headers will be included in the
// generated files for both trusted and untrusted routines
include "string.h"
include "mytypes.h"
// Type definitions (struct, union, enum), optional
struct mysecret {
int key;
const char* text;
};
enum boolean { FALSE = 0, TRUE = 1 };
// Export functions (ECALLs), optional for library EDLs
trusted {
//Include header files if any
//Will be included in enclave_t.h
//Trusted function prototypes
public void set_secret([in] struct mysecret* psecret);
void some_private_func(enum boolean b); // private ECALL (non-root ECALL).
};
// Import functions (OCALLs), optional
untrusted {
//Include header files if any
//Will be included in enclave_u.h
//Will be inserted in untrusted header file
“untrusted.h”
//Untrusted function prototypes
// This OCALL is not allowed to make another ECALL.
void ocall_print();
// This OCALL can make an ECALL to function
// “some_private_func”.
int another_ocall([in] struct mysecret* psecret)
allow(some_private_func);
};
};
可以看到，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應用實現的原理：
- 基礎設施：與SGX不同的，TEE的功能，依賴於安全OS，首先要確保設備上已經部署了安全OS，並且要確保其是可信的；
- 設計應用，對於需要可信保護的處理過程，需要實現在單獨的可應用中（TA）；APP以及TA需要分別開發，物理上他們是兩個程序；
- APP執行到安全處理部分時，它通過TEE標準接口向TA發消息；
- 調用需要進入內核態，通過驅動將消息送到TEE側；
- TA收到消息後，來執行即定的數據處理邏輯。
- 最後將結果返回到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年以後纔可能產品化，這個世界變化太快，兩年的時間實太是太久，暫不討論。
轉自鯤鵬社區
