為什么需要有車載信息安全？車載信息安全之Secure Boot實(shí)現(xiàn)策略

正文

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

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

隨著智能駕駛，智能座艙的不斷發(fā)展，車內(nèi)ECU也越來越集中化，網(wǎng)絡(luò)化，ECU之間不單單可以直接通過以太網(wǎng)通信，同時也可以通過V2X技術(shù)與車外進(jìn)行通信，車與車之間，車與外界之間聯(lián)系越來越緊密，如此一來便無形之中給外界開了諸多與車輛通信的渠道。

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

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

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

Secure Boot簡介

應(yīng)用背景

在芯片上運(yùn)行的代碼一般來說可能會面臨兩大類信息安全攻擊風(fēng)險(xiǎn)：

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

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

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

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

HSM或者SHE模塊本質(zhì)上來講就是一種硬件加解密引擎，將這些特別耗時的任務(wù)交給專門的硬件模塊來處理，一方面能夠?qū)崿F(xiàn)Secure boot需求，另一方面也能夠提高程序啟動效率。

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

當(dāng)然有些芯片可能實(shí)現(xiàn)OTP的方式是通過某些控制寄存器來控制某些內(nèi)存區(qū)域，通過控制這些控制寄存器無法被再次改寫，從而間接完成被控制的內(nèi)存區(qū)域具備OTP區(qū)域特性。

實(shí)現(xiàn)目標(biāo)

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

真實(shí)性：即軟件版本未經(jīng)過篡改；

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

時效性：軟件版本是有效期間內(nèi)的版本；

不可抵賴性：軟件發(fā)布后，發(fā)布者不能否認(rèn)版本的所有權(quán)；

機(jī)密性：軟件版本不泄露給未授權(quán)的個人或?qū)嶓w，不能被非法盜取或者讀取；

Secure Boot 相關(guān)密碼學(xué)方法總結(jié)

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

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

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

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

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

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

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

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

信息摘要與哈希函數(shù)

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

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

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

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

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

圖2 哈希算法過程

信任鏈與非對稱加密算法

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

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

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

如下圖3-1所示，在如下的安全啟動過程中軟件版本發(fā)布者A可以使用RSA私鑰來實(shí)現(xiàn)對代碼的信息摘要進(jìn)行加密處理，生成數(shù)字簽名；然后芯片端則可以使用對應(yīng)的公鑰來對數(shù)字簽名進(jìn)行解密，從而來完成版本的真實(shí)性，同時一旦驗(yàn)證成功，則也具備不可抵賴性，因?yàn)橹挥熊浖姹景l(fā)布者A才具有私鑰，如圖3-2所示：

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



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

公鑰信息交互與數(shù)字證書

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

數(shù)字證書就是一種權(quán)威性的文檔，由證書簽發(fā)機(jī)關(guān)(CA)簽發(fā)的對用戶公鑰的認(rèn)證,也就是我們常說的"根證書"。 證書一般包含如下幾個方面的內(nèi)容：

電子簽證機(jī)關(guān)的信息；

公鑰用戶信息；

公鑰；

有效期和數(shù)字簽名等；

一般來說，該數(shù)字證書的格式跟驗(yàn)證方法需遵循X.509國際標(biāo)準(zhǔn)。

Secure Boot實(shí)現(xiàn)策略

至此，與車載信息安全Secure Boot有關(guān)的密碼學(xué)方法到此基本就介紹完畢了，想必大家應(yīng)該對secure boot為什么要使用這些密碼學(xué)方法有了更為清晰的認(rèn)識，接下來我們將重點(diǎn)來講解Secure Boot如何利用上述密鑰學(xué)方法實(shí)現(xiàn)如下兩個方面的內(nèi)容：

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

安全鏡像啟動流程：該流程主要介紹通過密碼學(xué)相關(guān)方法來完成針對軟件版本的多層安全校驗(yàn)機(jī)制如何進(jìn)行實(shí)施；

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

符合X.509格式的數(shù)字證書或根證書；

用戶軟件版本；

安全鏡像生成流程

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

S1：用戶使用AES加密算法來實(shí)現(xiàn)將代碼明文轉(zhuǎn)換為密文，同時用戶也需要提前在芯片端OTP區(qū)域燒錄該AES密鑰；

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

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

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

圖4 安全鏡像生成全流程

安全鏡像啟動流程

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

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

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

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

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

注意：上述任意一個流程沒有通過，將不會進(jìn)行后續(xù)流程的校驗(yàn)，則停留在當(dāng)前的Boot中。

圖5 安全鏡像啟動全流程

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

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

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

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

審核編輯：劉清