安全利器！龍蜥推出機密計算遠端證明服務—OAAS 誠邀廣大使用者測試

龍蜥社群機密計算推出的最新社群產品——服務化的遠端證明服務中心 OAAS。OAAS 具有極高的安全性和靈活性，並在內部實現了策略引擎，旨在為使用可信執行環境 (TEE) 的使用者提供一個安全高效的遠端證明免部署解決方案，滿足在各類機密計算應用場景下的核心信任需求。在 2023 龍蜥作業系統大會上，龍蜥社群機密計算 SIG Maintainer 張家樂從背景、定位功能和使用方法、技術架構及應用場景和未來展望等 4 個方面全面介紹了 OAAS。以下為本次分享原文：

（圖/龍蜥社群機密計算 SIG Maintainer 張家樂）

01 背景介紹

相信大家對於機密計算都比較熟悉了，它的本質上是透過硬體支援的可信執行環境對執行時的資料進行機密性和完整性的保護。對於現在的終端的使用使用者和現有的雲原生技術體系，機密計算技術底層的特殊性存在技術應用門檻高、部署複雜、使用者不知道其功能的問題。龍蜥社群成立雲原生機密計算 SIG（Special Interest Group），希望透過構建機密計算的底層基礎設施的開源技術棧，降低機密計算的使用門檻，簡化機密計算技術在雲上的場景部署和應用，最終透過培養使用者的心智擴充使用場景。在南向生態上積極和幾家主流的晶片廠商建立緊密的合作關係，和合作方一起在上游社群推出一系列的元件級的開源軟體。在龍蜥社群基於元件級的開源軟體推出一系列解決方案或者社群產品。今天要重點介紹的 OAAS 就屬於這一類，最終以上方案或者產品和社群夥伴共同打磨下具備產品級的安全能力，最終落地到共同的終端使用者的實際場景中。

如果要在實際的落地場景中使用機密計算，歸根結底是對業務的安全性有比較高的要求。這樣一來，關鍵的問題就出現了，機密計算這種基於硬體的安全特性來提供的安全宣告，怎麼樣向真正的使用者證明安全屬性是真正基於硬體的而不是軟體模擬的，因此，龍蜥社群就引入了機密計算的遠端證明技術。換言之，機密計算落地前提的必要條件是基於硬體的安全屬性被真正的應用程式所有者感知和驗證。關於如何去證明目標環境的安全屬性是符合預期的，現在業界有一套通用的抽象標準，就是 RFC 9334 的這套標準，我們一般簡稱它為 RATS，叫 RATS 架構。這套標準它提供了一個對一般性的遠端證明系統的體系結構和協議內容的中立化模型，而在最 底層的硬體層面，現在幾家主流晶片廠商的 TEE 平臺都提供了一些原生的支援能力，比如英特爾的 DCAP PCK 密碼學體系，AMD 的證照鏈以及 Arm Veraison 服務等等。

在實際的雲原生機密計算的複雜場景下，僅僅有基本的原生軟體支援很多時候是不夠的。我們的夥伴和使用者更希望看到一箇中立化運營的、使用便捷的遠端證明服務，來幫實際的終端使用者解決技術門檻高、軟體流程複雜和不同平臺差異大的遠端證明問題，並且對驗證結果的信任做統一控制收口。

大家可以看到上圖左邊是直接在方案中整合原生遠端證明體系，需要在 TEE 側和依賴方側部署很多特定於 TEE 型別的軟體包和程式，在依賴方的本地執行復雜的證據驗證流程，並且需要和硬體廠商進行互動以獲得信任根驗證素材，最後才能獲得一個證明結果。在這個過程中，信任完全來自於對本地程式和硬體廠商。

而上圖右邊是使用一個服務化的遠端證明系統，TEE 側僅僅需要一個客戶端，把證據傳送給遠端證服務，而依賴方側則不需要任何額外的配置和部署，可以直接從遠端證明服務拿到目標 TEE 的證明結果。在這個過程中，方案中整合的遠端證明系統不再特定於 TEE 型別，而且流程簡潔清晰，另外信任成本也解耦到了遠端證明服務這裡，服務的所有者對所有的信任輸入做統一的收口控制。

02 OAAS 功能介紹

OAAS 的定位是一個社群提供的安全高效、通用可控的公開遠端證明服務中心，以統一的形式相容多種 TEE 型別。它的目標就是要簡化遠端證明在機密計算方案中的整合和部署，解決遠端證明技術門檻高、軟體流程複雜和平臺差異性大的問題，並且能夠對證明信任做收口控制。

在功能上，OAAS 不僅支援多平臺 TEE 硬體報告的驗證，還能自定義驗證目標環境的韌體和軟體棧度量值，這得益於 OAAS 內部高度靈活可定製的驗證策略引擎，而最終返回給呼叫者的證明結果是一個標準完備的結果報告令牌。

由於 OAAS 在機密計算方案中會扮演一個信任依賴的角色，因此這個服務自身的安全性也是我們的一個考慮重點。在服務實現上，我們使用海光 CSV 安全虛擬化來保護服務例項，並且能夠支援真實性的自證明。同時，驗證完成後返回給呼叫者的證明結果報告上會攜帶龍蜥社群的簽名，並且服務程式會由機密計算 SIG 技術團隊進行維護。最後，服務本身的核心功能模組程式碼都是在放在中立化的國際社群開源的，可以隨時進行程式碼審計。

那麼具體來說，在機密計算方案中使用和整合 OAAS，相比於直接整合 TEE 的原生遠端證明軟體配套，它的優勢體現在以下四個方面。

首先，我們前面講需求來源的時候也提到了，OAAS 它是一個服務化的遠端證明體系，能夠讓方案中整合的遠端證明相關的模組大大簡化，也就是說方案使用者不用再自己去搭建和執行特定於硬體的遠端證明程式，而只是在目標環境中訪問一下龍蜥社群的這個服務，就可以直接拿到證明結果。

其次，在方案中使用 OAAS 可以做到對多種 TEE 的同時相容，OAAS 本身在內部是把特定於 TEE 型別的驗證邏輯進行了封裝抽象，對外提供統一引數格式和統一呼叫介面，而輸出的結果報告也是標準的統一格式。換句話說，對於 OAAS 的使用者來說，遠端證明系統下層特定於 TEE 平臺的技術細節相當於是被抽象隱藏掉了。

另外，OAAS 內部基於 OPA 實現的策略引擎，讓使用者可以在基本的硬體真實性驗證的基礎上，透過編寫和設定策略來細粒度的定製每一個證據欄位的驗證邏輯，同時還可以在驗證中同時管理和控制多個策略。

最後，OAAS 作為一個服務化的遠端證明驗證中心，它相當於是在基本的硬體廠商背書的基礎上做了一個信任收口，從原來的使用者和硬體廠商的二方信任建立引入了一箇中立化的第三方，提供了獨立於特定硬體提供商的額外信任鏈條，在某些特殊的場景下，能夠實現國內我們說的自主可控的系統安全認證。

對於社群使用者來說，使用 OAAS 來進行遠端證明是一個非常簡單高效的操作，在這下圖裡把開始使用 OAAS 總結為四步快速開始。

首先我們需要訪問 OAAS 的主頁。點選建立例項按鈕，在登陸社群帳號之後就可以一鍵建立出來自己的 OAAS 例項，並且拿到相應的例項訪問地址。然後我們可以透過使用給 OAAS 例項設定自定義的 Attestation 策略，這是一個可選的步驟。在此之後需要在 TEE 內收集證明證據，這一步可以手動完成，也可以使用 OAAS 提供的自動化工具一鍵完成。最後只需要訪問一下 OAAS 的認證端點傳送證據，驗證透過之後就可以拿到一個 JWT 格式的令牌，令牌的內容中就包含了遠端證明結果。

可以看到在整個使用過程中，不需要使用者做任何額外的環境配置和軟體搭建，遠端證明過程變得非常簡單高效。

03 OAAS 技術架構

下面從技術的層面給大家分享一下 OAAS 內部的實現。

OAAS 本身的核心元件都是開源的，所以主要從整體架構、內部的策略引擎、最終認證令牌的格式和內容，這三個角度向大家詳細介紹。

首先上圖是 OAAS 例項在服務側的一個整體的模組架構圖。大家可以看到在實現上，我們把服務例項從內部劃分為兩個大的模組群，左邊是 Web API Server，負責處理一些前端的業務邏輯，而右邊是 Attestation 核心，負責執行真正涉及信任的證明驗證邏輯。這樣的劃分有助於在部署的時候採取不同的安全保護級別。

OAAS 例項會向使用者開放 HTTPS RESTful API，在需要對 TEE 執行 Attestation時，訪問 OAAS 的 API 提供收集的 TEE 證據，證據會轉發到後端的核心模組進行驗證。

在後端，我們透過統一介面外掛化的機制把不同平臺TEE證據報告的解析過程統一封裝抽象掉，外掛本身會負責識別和解析來自不同硬體廠商的 TEE 證據內容，並對特定於硬體平臺的證據簽名進行驗證，而硬體廠商的密碼學基礎服務會為 TEE 外掛池提供驗證背書。在完成基本的硬體驗證之後，會將證據解析為統一可讀的格式，交給後端的 OPA 策略引擎進行細粒度的邏輯驗證。而使用者可以透過訪問前端的 RESTful API 來對這裡的驗證策略進行自定義設定和管理，訪問 API 的時候，OAAS 例項會驗證使用者的身份，以確保只有服務的 Owner 才能對策略進行修改。

後端的策略引擎驗證完成後，會將策略引擎輸出的報告和解析後的證據內容打包為一個令牌，透過 HTTPS 響應返回給 TEE，這個令牌表徵了 OAAS 對 TEE 可信度的認證結果。在格式上，這個令牌我們採用了 JWT 格式的標準令牌，包含了OpenAnolis 金鑰簽名的密碼學保護。

我們前面一再提到，OAAS 內建了一個高度靈活可定製的策略引擎驗證環節，下圖就是策略引擎模組的技術架構。解釋策略和執行驗證邏輯的核心我們是採用了 CNCF 的畢業開源專案 Open Policy Agent 來實現。OPA 是一種強大靈活的策略引擎實現，它定義的 Rego 策略語法能夠讓使用者根據需求編寫任意複雜的驗證判斷邏輯，並且 Rego 它有很多生態模組能夠實現一些功能性的邏輯處理。

在輸入端，OAAS 會把經過 TEE 驗證外掛處理和解析之後的序列化的證據內容和使用者指定的本次驗證的策略列表一同交付給 OPA 核心，這裡序列化的證據內容 OAAS 定義了一種簡單統一的 JSON 格式。

在接收到輸入之後，模組會根據輸入中指定的本次驗證所需求的策略 ID，從策略儲存表中檢索對應的策略並載入到 OPA 核心中。同時最上面的參考值提供服務，會從一些上游的軟體供應鏈安全系統訂閱獲得某些特殊證據欄位的可信參考值，例如kernel和韌體的度量值，然後提供給 OPA 核心。最後 OPA 核心根據策略執行驗證邏輯，並輸出一份評估報告，這份評估報告會和輸入中的序列化證據內容一起打包簽名成一個 JWT 令牌，作為最終的輸出結果。

下圖是 OAAS 的認證結果令牌的詳細內容，由於它是一個 JWT 格式的標準令牌，因此左邊大家可以看到它包含了 JWT 所要求的一些基本的安全欄位，比如過期時間、生效時間、防重放隨機數等等。需要關注的是下面用紅框標出的自定義區域中填充的三項內容。

首先是證明評估報告欄位。這是一個包含多個結構體項的 JSON 陣列，每一項分別對應著一個特定的策略驗證結果，比如輸入中指定這次驗證使用三個不同的策略，那這裡就會有三項。結構體項內部的欄位指明瞭策略的 ID 和這個策略的驗證結果，也就是 true or false，另外還包含了 OPA 的輸出報告，使用者可以透過合適的策略編寫來控制這裡輸出報告的具體格式和內容。

其次是 TCB Status 欄位。這裡就是策略引擎拿到的輸入，也就是 TEE 驗證外掛解析和處理之後的序列化證據內容。

最後是一個 JWK 格式的 RSA 公鑰。這個公鑰可以用來驗證令牌最後的 RS384 簽名，值得一提的是，在 JWK 的 x5u 欄位上，指向了這個公鑰對應的證照鏈下載地址，這個證照鏈的根證照就是龍蜥社群的證照，因此這裡的簽名實際上是表徵了龍蜥社群 OAAS 的背書。

04 應用場景&未來展望

總體來說，OAAS 在雲上機密計算的應用場景非常廣泛。首先這套系統可以為使用者提供各種雲上機密計算例項的靈活高效的自主安全驗證，能夠很好的符合機密計算的安全目標，也就是在不相信雲廠商的前提下提供信任建立的渠道，並且能夠提供高效免部署的友好的使用體感。

其次是藉助 OAAS 的認證令牌驗證和令牌中包含的 TEE 金鑰，我們可以實現向 TEE 中可信並且高效的注入秘密資料，比如映象或者磁碟的解密金鑰，以及一些證照和安全策略。

最後就是在未來隨著機密計算應用規模增大，OAAS 可以作為異構 TEE 節點分散式互聯場景下起到信任派發中心的作用，從而支援基於 OAAS 的異構 TEE 機密互聯。

上圖是一個典型的使用 OAAS 向 TEE 例項安全的進行資料注入的場景案例。在這個案例中，大家可以看到我們的 OAAS 服務在左下角，透過前面提到的四步快速開始，使用者建立出自己的 OAAS 例項。

在方案流程上，首先是 TEE 內的 OAAS client 訪問 OAAS 例項執行證明獲得令牌，然後 TEE 將令牌提供給機密資料儲存伺服器，儲存伺服器透過驗證令牌，就可以知道這個 TEE 的真實性和安全性是經過 OAAS 驗證和擔保的，因此可以將機密資料透過加密通道返回給TEE。這就是藉助 OAAS 的證明能力實現的安全資料注入。

現在 OAAS 處於測試階段。上面是 OAAS 的邀測群，大家如果加入邀測群提供自己的組織資訊和社群賬號的郵箱，都會給大家開放使用 OAAS 的測試的許可權。歡迎大家關注和掃碼加群。謝謝大家。

更多影片回放、課件獲取：

2023 龍蜥作業系統大會直播回放及技術 PPT上線啦，歡迎點選下方連結觀看~

回放連結：

技術 PPT ：關注龍蜥gz號【OpenAnolis 龍蜥】，回覆“龍蜥課件”獲取。

—— 完 ——