在聽說了很多硬體漏洞比如Spectre、Meltdown和Foreshadow之後,可能很多SoC和系統設計人員們都在思考如何在不犧牲安全性的前提下保持應用的處理效率。很多設計人員正在研究如何透過RISC-V的開放式指令集架構(ISA)設計安全引擎,一種從源頭開始就被保護的安全引擎。

在主CPU管理併發執行多個進程的主要工作負載時,這些安全引擎充當輔助處理器。然而,設計人員意識到這其中許多應用都需要安全矽IP來隔離不同應用之間的安全資產。

如果一個SoC上運作多個需要訪問安全資產的應用程式,那麼這些應用程式最好不能訪問彼此的資產。舉個例子,人們肯定不希望他們的銀行應用程式能夠訪問他們的數位版權管理(DRM)視訊重播金鑰,反之亦然。這樣做的另一個好處在於,一個應用程式中的安全性漏洞無法洩漏另一個應用程式使用的安全資產。

要滿足這些需求,安全處理器,如Rambus的CryptoManager Root of Trust(CMRT)必須支援多個硬體信任根(RoT),這些信任根在安全矽IP自身中要被彼此隔離。簡而言之,每個實體都有自己的虛擬信任根,無需信任其他實體即可執行安全功能。

信任根為可信運算環境的安全性奠定了基礎。為了支持多個根,安全矽IP必須能夠辨識當前根(即每個根必須具有處理器已知的唯一辨識碼)。

一旦信任根被辨識,安全矽IP就必須應用該根的特定策略。該策略利用一組在硬體中強制執行的許可權來實現,這些許可權描述了根對加密處理器中可用的安全與非安全資產的訪問能力。創建許可權的原則為:給定根對資產的存取權限與其他根完全隔離,當然如果非常必要,也可以允許兩個根訪問同一組資產。

創建信任根

要創建信任根,安全矽IP應用開發人員需要創建包括公開金鑰與私密金鑰的金鑰對。橢圓曲線加密(ECC)或RSA金鑰對在這裡是比較合適的選擇。要計算出公開金鑰的唯一加密值(稱為散列摘要),並將此散列摘要用作根的唯一辨識碼。公開金鑰的散列摘要必須安全地提供給安全矽IP的非揮發性記憶體(NVM),而私密金鑰則用於運算應用的二進位映射的數位簽章,該二進位映射將在安全矽IP內執行。

在運作時,當應用程式載入到安全矽IP中時,簽名、虛擬根公開金鑰和其他中繼資料都附加在應用程式映射中。安全矽IP使用附加到映射的公開金鑰來確定該公開金鑰的散列摘要是否與儲存在處理器NVM中的虛擬根ID匹配,如果找到匹配的ID,則使用公開金鑰來驗證應用本身的散列摘要簽名,一旦驗證了映射的簽名,則安全處理器將應用的根許可權應用於硬體。

請注意,創建應用程式的實體擁有私密金鑰。安全矽IP永遠看不到這個金鑰,它由實體安全地保存,永遠不會被暴露。

KDF在應用隔離中的作用

安全矽IP內部的硬體金鑰匯出函數(KDF)對於進一步隔離虛擬根不可或缺(圖1)。KDF應當基於一個標準,例如美國國家標準暨技術研究院(NIST)SP 800-108。KDF可以有多個用於匯出金鑰的輸入。為實現根之間的隔離,唯一根辨識字是KDF的其中一個輸入。

20191118TA31P1 圖1 安全矽IP內部的金鑰匯出函數對於進一步隔離不同的虛擬根非常必要。(資料來源:Rambus)

當應用程式載入到安全矽IP中時,根辨識字被程式設計到KDF中。這意味著由兩個不同的根私密金鑰簽名的兩個不同的應用程式不會匯出相同的金鑰集,即使KDF的所有其他輸入參數都相同也不可以。因此,在安全矽IP內執行的應用程式可以使用KDF來匯出它自己唯一的應用程式對稱金鑰或ECC金鑰對。

使用KDF匯出應用程式金鑰的另一個好處在於無需將金鑰儲存在NVM中,而儲存在記憶體中的金鑰通常易受攻擊。當下一次應用程式需要使用特定金鑰時,應用程式將執行與先前相同的金鑰匯出過程。

使用KDF還有一個優點是可以重複匯出相同的對稱金鑰或ECC公開金鑰和私密金鑰對。它們通常透過動態加密法(on-the-fly)匯出。一旦應用程式使用完金鑰,金鑰就被系統刪除。

簡而言之,兩個不同的虛擬根不能創建相同的金鑰。因為透過KDF能夠匯出的金鑰使用了根辨識字作為資料的一部分來匯出。這就是應用程式之間實現加密隔離的方式。

其他資產的隔離

除了透過匯出的金鑰隔離,安全矽IP還可以進一步擴展給定虛擬根環境之下執行的應用程式的隔離。例如,應用程式通常不會共用NVM區域。另外,一般會希望限制對安全矽IP的通用輸入輸出(GPIO)的訪問,而應用給定虛擬根許可權策略可以實現對此類資產的嚴格存取控制。

還有一些應用程式要求安全矽IP將匯出的金鑰或從NVM讀出的金鑰透過安全匯流排傳送到外部處理單元。這個外部處理單元可能由於某些特定原因或出於對性能的考慮而被使用。此時必須設置虛擬根的許可權,以便只有那些應該將金鑰傳遞給外部處理單元的應用程式才能這樣做,而其他不需要將金鑰傳遞給外部處理單元的應用程式則不能訪問安全匯流排。

保證安全矽IP內的所有應用程式都彼此隔離可以增加我們對系統安全性的信心。

擁有了如此安全的保護傘,為安全矽IP開發應用程式的實體得以維護其特定的虛擬根私密金鑰。其他實體無法訪問這些匯出的金鑰、特定金鑰匯流排、NVM記憶體位址範圍、GPIO接腳或任何其他相關資料,同時也阻止了其他人嘗試攻擊或意外地匯出這些關鍵資料,例如,開發人員的錯誤不會導致誤訪其他人的資產,這些資產受硬體保護。一旦在硬體中為基本金鑰、NVM、安全金鑰目標和其他關聯資產設置許可權後,應用程式就無法修改這些許可權,因為它們被設置在硬體中,不能被重寫。

提供對多個信任根支持的安全矽IP解決方案

在前文,已經討論了系統和SoC設計人員如何在其應用程式中增加多個安全矽IP信任根並隔離它們以實現超高安全性。

這種安全矽IP的解決方案是提供對多個信任根的支持,就像Rambus的CryptoManager信任根。安全矽IP產品的每個根都可為安全矽IP內的多個信任根提供支援,安全矽IP內的每個根都有自己的辨識字和許可權集,用於建立對執行所需資產的存取權限。載入應用程式時,其請求的許可權被程式設計到硬體寄存器中,使得該應用程式只能訪問它指定的資產。根據硬體中應用的其他應用程式的許可權,可以限制在安全矽IP內執行的其他應用程式訪問原始應用程式的資產。

如果攻擊者想要在安全矽IP上運作應用程式,則必須能夠訪問其虛擬根私密金鑰。即使攻擊者可以訪問另一個應用程式的虛擬根私密金鑰,他們的應用程式也無法訪問原始應用的資產。

對於系統或SoC設計人員來說,要實現此功能就必須選擇具有多個硬體信任根的安全矽IP,且每個信任根在安全矽IP內部都被隔離。這意味著每個實體都依賴於自己的虛擬信任根來執行安全功能,而無需信任其他虛擬信任根。

應用示例

以下是基於此類安全矽IP應用的一些具體示例。如圖2所示,示例中的實體可以是DRM、銀行業務或安全通訊應用。

20191118TA31P2 圖2 應用程式實體可以是DRM、銀行業務或安全通訊應用,每個實體都完全相互隔離。(資料來源:Rambus)

如圖2所示,每個應用程式在彼此完全隔離的情況下執行。另一種不太安全的替代方案是所有三個實體共用同一組資產(下方框架圖)。

如前所述,系統和SoC設計人員需要考慮其設備支援的潛在客戶應用程式。一些可能的應用包括視訊流、銀行業務和安全通訊的DRM,每種應用程式對安全性和對安全矽IP資產的訪問都有不同的要求。

DRM應用:DRM應用需要將安全矽IP匯出的金鑰輸出到可以解密和解碼視訊流的外部引擎。在這種情況下,可以使用安全矽IP提供的許可權模型來確保只有DRM應用程式可以匯出解密視訊流所需的金鑰。此外,還可以根據安全矽IP的許可權設置僅允許DRM應用程式將金鑰傳遞給視訊解碼模組。

圖3詳細圖解了安全矽IP在DRM應用中的使用,NVM保存了多個應用程式基本金鑰。根據DRM應用程式的虛擬根許可權設置,它唯一可訪問的金鑰是DRM基本金鑰KD,而無法訪問其他被遮蔽的金鑰(KB和KC)。

20191118TA31P3 圖3 安全矽IP用於DRM應用。(資料來源:Rambus)

CPU上執行的應用程式請求KDF使用KD來匯出視訊解密金鑰KV。該應用程式還要求將KV直接輸出到金鑰傳輸(Key Transport)模組,以防止DRM應用程式中潛在的軟體漏洞洩漏KV。金鑰傳輸模組透過安全匯流排將KV傳送到視訊解密和解碼模組,該模組隨之對需要播放給使用者的視訊流進行解密和解碼。

銀行憑證應用:圖4詳細說明了安全矽IP的第二種應用可能——保護用戶的銀行憑證。與上述DRM應用程式一樣,銀行應用程式也僅具有NVM中基本金鑰KB的唯一存取權限,同樣無法訪問NVM中的其他基本金鑰。

20191118TA31P4 圖4 安全矽IP用於用戶銀行憑證。(資料來源:Rambus)

應用程式可以請求KDF使用KB來匯出解密金鑰KA。KA被直接發送到進階加密標準(AES)引擎,這樣CPU就不會讀取其值。應用程式隨後請求AES引擎解密儲存在系統外部檔案系統中的加密銀行憑證,一旦憑證被解密,它們就被傳送到安全矽IP的SRAM,以供在主CPU上執行的銀行應用程式使用。

即使攻擊者意圖對安全矽IP內執行的銀行應用程式執行反向工程,也無法獲取銀行憑證解密金鑰KA。而且,如果攻擊者可以訪問另一個虛擬根私密金鑰來簽署他們自己的銀行應用程式版本,該應用程式也無法匯出合適的KA,其匯出的金鑰KA無法用於解密用戶銀行憑證。

安全通訊應用:第三個示例為安全通訊應用,如圖5所示。安全通訊應用程式在使用前需要進行一些設置,安全矽IP需要首先使用其安全通訊基本金鑰KC匯出ECC私密金鑰KP,然後再使用KP匯出相應的公開金鑰KU,KU隨後在證書簽名請求過程中從設備匯出。

20191118TA31P5 圖5 安全矽IP用於安全通訊應用。(資料來源:Rambus)

憑證授權(CA)根據證書簽名請求生成由CA私密金鑰簽名的數位憑證(CERT)。該數位憑證隨後被導入安全矽IP中,儲存在NVM中只能由安全通訊應用程式訪問的位置。

在與另一方建立安全會話的初始階段,安全通訊應用程式從NVM中讀取CERT。安全通訊應用程式還會請求KDF使用KC重新匯出私密金鑰KP,並將KP傳遞給公開金鑰引擎。隨後,應用程式使用安全矽IP的散列引擎計算出安全通訊參數的散列摘要,也將其傳遞給公開金鑰引擎。

安全通訊應用程式請求公開金鑰引擎根據KP和安全通訊參數的散列摘要生成數位簽章,並放置在SRAM中,安全處理器CPU上執行的安全通訊應用程式將可以訪問它。最後,安全通訊應用程式匯出CERT、安全通訊參數和數位簽章,並發送到建立了安全通道的另一方。

隨著安全通訊協定的發展,安全矽IP被用於與另一方建立機密資料共用。安全矽IP的AES引擎(或其他對稱加密演算法)利用這些共用機密資料加密或解密來自/傳遞到另一方的資料塊。

結論

應用程式保持最高等級的安全性至關重要,本文描述的示例演示了如何在應用程式之間建立完善的資產隔離。此外,在這種保護機制之下,即使某個應用程式被攻擊者執行了反向工程也沒有什麼價值,因為獲取應用程式的虛擬根私密金鑰才是關鍵。而且即使攻擊者可以訪問另一個應用程式的虛擬根私密金鑰,也無法訪問要攻擊的應用程式資產。

(參考原文: Multiply and Isolate Your Roots of Trust for Greater Security (Part 2),by Joel Wittenauer)

本文同步刊登於EE Times Taiwan 11月號雜誌