正文

在開始講解安全啟動(Secure Boot)之前，我們首先來簡單認識下為什么需要有車載信息安全？

為什么要有車載信息安全？

隨著智能駕駛，智能座艙的不斷發展，車內ECU也越來越集中化，網絡化，ECU之間不單單可以直接通過以太網通信，同時也可以通過V2X技術與車外進行通信，車與車之間，車與外界之間聯系越來越緊密，如此一來便無形之中給外界開了諸多與車輛通信的渠道。

比如我們最為常見的整車OTA技術，如果在行車過程中，ECU中運行的軟件突然被黑客進行篡改或者控制，將會大大影響到行車安全，隨著未來整車自動駕駛技術的不斷發展，從L3到L4甚至到L5，人在駕駛方面起到的作用將會越來越小，此時整車的信息安全將會顯得至關重要。

而整車信息安全的就在于整車各個智能控制ECU在啟動階段就做好相關的安全確認與校驗，才能將風險及時控制住，如果在Runtime時候去檢測，則可能會造成更大的行車安全問題。

因此，在車載信息安全領域，在各個智能ECU節點的啟動階段做好相應的安全檢查技術，也就是我們所說的安全啟動技術，即Secure Boot技術，毫無疑問便可以將各種黑客造成的篡改早早的扼殺在搖籃之中，從而保證最終各ECU中程序Runtime中的行車安全。

Secure Boot簡介

應用背景

在芯片上運行的代碼一般來說可能會面臨兩大類信息安全攻擊風險：

代碼被惡意更改或者攻擊；

代碼IP被非法讀取或獲取；

對于第一類風險，我們需要采用某種安全機制來確保芯片運行用戶指定的程序，防止代碼被惡意篡改；對于第二類風險，為了防止代碼被盜，需要針對代碼原文進行加密存儲，在芯片啟動過程中再進行解密后啟動。

由于上述代碼加密或者啟動代碼驗證等方面都需要花費更多的CPU資源來完成這些工作，因此僅僅依靠傳統CPU可能無法高效完成此類工作，需要引入與安全加密有關的單獨硬件來做這方面工作，比如我們常說的HSM或者HSE等。

HSM或者SHE模塊本質上來講就是一種硬件加解密引擎，將這些特別耗時的任務交給專門的硬件模塊來處理，一方面能夠實現Secure boot需求，另一方面也能夠提高程序啟動效率。

一般來說，支持安全啟動的芯片一般都會存在OTP區域（one time programable），其工作原理與保險絲一致，芯片再出廠后，該區域內所有的bit均為1，如果某個bit被燒寫為0，就會徹底熔斷該bit，再也無法改變該值，也就是再也無法更改為1了，一般該OTP區域用于存儲用戶的密鑰信息。

當然有些芯片可能實現OTP的方式是通過某些控制寄存器來控制某些內存區域，通過控制這些控制寄存器無法被再次改寫，從而間接完成被控制的內存區域具備OTP區域特性。

實現目標

具備安全特性如HSM的芯片加入到Secure boot功能之后，便會利用OTP區域內存儲的用戶密鑰信息對即將加載的軟件進行多級安全驗證，從而最終建立起可靠的安全信任鏈，通過該安全啟動信任鏈便可以完成軟件信息安全的五大特性指標：

真實性：即軟件版本未經過篡改；

完整性：軟件版本包含了開發者發布的所有內容，沒有發生任何變化；

時效性：軟件版本是有效期間內的版本；

不可抵賴性：軟件發布后，發布者不能否認版本的所有權；

機密性：軟件版本不泄露給未授權的個人或實體，不能被非法盜取或者讀取；

Secure Boot 相關密碼學方法總結

在講解Secure Boot實現策略之前，小T有必要跟大家一起先來了解下與Secure Boot有關的相關密碼學基本方法，這樣才能夠更為徹底的理解為什么Secure Boot實現策略要這么來做才更加安全。

代碼明文加密與對稱加密算法

為了保護軟件版本IP，防止代碼被惡意篡改，因此有必要針對軟件版本進行加密處理，即針對代碼明文進行加密處理。

AES作為一種較為常見的對稱加密算法，具備應用范圍廣，相對容易隱藏，吞吐量高等優點，通常便可以用來做代碼加密處理。

所謂對稱加密算法就是加密，解密都是用的同一個密鑰，如下圖1所示，代碼釋放者可以將如下代碼明文用AES加密算法加密成密文，然后將代碼密文燒寫到對應的存儲芯片中，安全芯片HSM或HSE在啟動過程中將加密后的代碼密文加載到內存中，同時利用OTP區域中事先燒錄的密鑰進行代碼解密，此時便可以發現整個解密過程用到了相同的密鑰及相同算法的逆算法，從而通過解密將代碼密文恢復成明文。

該AES對稱加密技術的顯著優勢就是加解密速度快，特別適用于大數據量的加密存儲。

圖1-1 代碼明文對稱加密過程

圖1-2 代碼密文對稱解密過程

信息摘要與哈希函數

哈希函數又稱為哈希算法，是一種可以將任意長度的一組數據創建為定長的小的數字指紋的方法，該數字指紋也被稱作為信息摘要，為了便于理解，后續統一以這種數字指紋稱呼為信息摘要。

哈希函數用到的就是哈希變換，哈希變換具備如下兩個典型的特征：

加密過程不可逆：也就意味著任何人都無法根據信息摘要推算出加密前的明文到底是什么？

一一對應性：輸入的明文與信息摘要一一對應，絕對不會存在不同的明文哈希變換之后得到的信息摘要一樣的情況。

在Secure Boot中，一般采用SHA哈希函數來實現哈希變換，來完成最終的信息摘要生成，比如最為常見的SHA256，即生成的信息摘要為4個Byte（Hash Value），以便用來校驗代碼的完整性，如下圖2所示。

圖2 哈希算法過程

信任鏈與非對稱加密算法

在整個Secure Boot的過程中除了解決防止代碼IP被意外獲取之外，最為關鍵的還是要解決一個信任問題，所謂信任問題就是CPU加載的軟件版本是軟件發布者A發布的軟件版本，而不是別人的非法軟件版本。

要解決這類信任問題，就需要使用到非對稱加密算法，所謂非對稱加密算法就是該算法中存在兩個密鑰，一個是公鑰，一個是私鑰。它們是一對，如果用公鑰進行加密，只有用對應的私鑰才能進行解密，如果用私鑰進行加密，也只有使用對應的公鑰進行解密才行。

一般來說，密鑰的長度越長，算法便會越安全，一般來說會使用非對稱加密算法來解決上述信任問題，如RSA非對稱加密算法。它是一種公開的、基于數學理論的加密算法，不依賴于任何機構或個人，也不容易被破解，可以實現數字簽名與認證工作。

如下圖3-1所示，在如下的安全啟動過程中軟件版本發布者A可以使用RSA私鑰來實現對代碼的信息摘要進行加密處理，生成數字簽名；然后芯片端則可以使用對應的公鑰來對數字簽名進行解密，從而來完成版本的真實性，同時一旦驗證成功，則也具備不可抵賴性，因為只有軟件版本發布者A才具有私鑰，如圖3-2所示：

圖3-1 私鑰加密生成數字簽名過程



圖3-2 公鑰解密還原信息摘要過程

公鑰信息交互與數字證書

除了上述解釋軟件版本自身的信任問題，還需要確保密鑰信息自身傳輸過程的安全性與保密性，此時就需要建立一套完備的信任機制來完傳遞密鑰。

數字證書就是一種權威性的文檔，由證書簽發機關(CA)簽發的對用戶公鑰的認證,也就是我們常說的"根證書"。 證書一般包含如下幾個方面的內容：

電子簽證機關的信息；

公鑰用戶信息；

公鑰；

有效期和數字簽名等；

一般來說，該數字證書的格式跟驗證方法需遵循X.509國際標準。

Secure Boot實現策略

至此，與車載信息安全Secure Boot有關的密碼學方法到此基本就介紹完畢了，想必大家應該對secure boot為什么要使用這些密碼學方法有了更為清晰的認識，接下來我們將重點來講解Secure Boot如何利用上述密鑰學方法實現如下兩個方面的內容：

安全鏡像生成流程：該流程主要介紹通過密碼學相關方法能夠生成供芯片端正確識別的合法軟件版本，防止非法軟件被意外啟動；

安全鏡像啟動流程：該流程主要介紹通過密碼學相關方法來完成針對軟件版本的多層安全校驗機制如何進行實施；

整個安全啟動版本需要校驗的文件主要包含如下兩個部分：

符合X.509格式的數字證書或根證書；

用戶軟件版本；

安全鏡像生成流程

如下圖4所示，整個安全鏡像文件生成包含如下幾個基本步驟：

S1：用戶使用AES加密算法來實現將代碼明文轉換為密文，同時用戶也需要提前在芯片端OTP區域燒錄該AES密鑰；

S2：用戶需采用SHA256哈希函數來對代碼密文進行哈希運算，最終得到該軟件版本密文的信息摘要；

S3：用戶需生成符合X.509國際標準的數字證書或者根證書文件，該文件中需包含上述軟件版本密文的信息摘要與RSA公鑰信息；

S4：用戶需采用SHA256哈希函數來對上述數字證書做哈希運算，得到數字證書的信息摘要，同時用戶使用RSA私鑰對該信息摘要進行加密處理，最終得到該用戶的數字簽名。

圖4 安全鏡像生成全流程

安全鏡像啟動流程

如下圖5所示，較為詳細地展示了安全啟動流程中的多級安全校驗機制，從而保證最終的軟件的安全性，合法性與完整性。

S1：芯片復位啟動后，通過硬件加密模塊如HSM或者HSE先對燒錄在Flash中的X.509標準數字證書公鑰信息進行哈希運算，并與提前燒錄到芯片OTP區域的公鑰哈希值進行比對，如果結果一致，那么則可以確認公鑰的合法性，這個就是整個信息安全信任鏈的第一個環節，也是十分重要的環節；

S2：公鑰合法性確認后，硬件加密模塊如HSM或HSE再利用數字證書的數字簽名進行用戶合法性鑒權。具體操作步驟就是通過上述確認的公鑰對數字簽名進行解密處理得到證書的哈希值，同時針對存儲在Flash芯片上的證書重新進行哈希運算，對比兩個哈希值是否一致，如果一致，則鑒權成功，合法性得到了保障；

S3：然后再利用硬件加密模塊如HSM或HSE來重新計算Flash芯片上存儲的軟件版本的哈希值，即信息摘要，并與數字證書的信息摘要進行比對確認是否一致，如果匹配則說明代碼沒有被惡意篡改， 用戶軟件版本的完整性與安全性得到了保障；

S4：芯片硬件加密模塊如HSM或HSE最終利用OTP區域提前存儲的AES對代碼進行解密處理，從而得到代碼明文，最終便可以正常加載到CPU中啟動運行。

注意：上述任意一個流程沒有通過，將不會進行后續流程的校驗，則停留在當前的Boot中。

圖5 安全鏡像啟動全流程

由于Secure Boot相比傳統的Boot而言，增加了多重安全校驗機制，毫無疑問會增加代碼啟動時間，從而因此第一幀報文發出過晚，因此需要權衡并優化。針對這類問題在具體項目實施過程中與上述流程可能允許存在些許差異，常見的一些差異表現如下：

比如數字證書的公鑰信息提取在上位機已成功提取，無需軟件來做，減少啟動時間；

軟件代碼的AES加解密措施有些項目考慮到啟動時間問題可能也會省略，這個具體還是要看項目端具體需求；

不同供應商使用的Secure Boot流程與上述流程可能均存在差異，這個依照各個項目而定，本文只是提供了一般性的Secure Boot實現策略。

審核編輯：劉清