電子發(fā)燒友App
01
信息安全需求
本章節(jié)主要從硬件安全、系統(tǒng)安全、通信安全、數(shù)據(jù)安全四個方面介紹下信息安全的需求，重點介紹硬件安全和系統(tǒng)安全。
1.1 硬件安全
硬件安全主要關(guān)注的是PCB板的保密措施和關(guān)鍵芯片的加密功能。
1.1.1 接口安全
量產(chǎn)階段，調(diào)試接口（如JTAG，SWD等）不宜直接暴露在PCB板上，如果無法避免，建議改為測試PIN方式分散布置。
量產(chǎn)階段，調(diào)試接口需要設(shè)置安全的身份驗證，身份驗證的口令至少為8位，且必須包含數(shù)字、大小寫字母。
對于車燈模組來說，需要注意的是主控MCU的調(diào)試接口，其他的外圍芯片基本不涉及到代碼讀取。
1.1.2 主板安全
量產(chǎn)階段，主板上的關(guān)鍵芯片（如主控芯片、硬件加密芯片、收發(fā)器等）、端口和管腳功能的標(biāo)識絲印需要去除。
芯片間敏感數(shù)據(jù)的通信線路應(yīng)盡量隱藏，對抗針對控制器內(nèi)部數(shù)據(jù)傳輸?shù)母`聽和偽造攻擊。
主板上的關(guān)鍵芯片采用可靠焊接封裝（如BGA、CSP），防止關(guān)鍵芯片被拆下讀取芯片內(nèi)部信息。
1.1.3 芯片安全
為保證整車的網(wǎng)絡(luò)安全，需考慮硬件級的安全加密，一般選擇集成了FULL EVITA等級的HSM模塊的MCU，如果使用的MCU沒有加密模塊，可以外接一個車規(guī)級別SE芯片，該SE芯片至少可提供如下接口：
AES128算法接口
對稱密鑰存儲接口
SHA256算法接口
RSA2048算法接口
非對稱密鑰存儲接口
真隨機(jī)數(shù)獲取接口
主要芯片及加密芯片需滿足抗攻擊保護(hù)，滿足：
使用必要的安全機(jī)制，防御針對芯片的電壓、時鐘的單次故障注入攻擊；
使用必要的安全機(jī)制，防御針對芯片的電磁、激光的單次故障注入攻擊；
使用必要的防護(hù)措施，對抗針對加密芯片的側(cè)信道簡單功耗分析（SPA）攻擊；
使用必要的防護(hù)措施，對抗針對加密芯片的側(cè)信道一階差分功耗分析（DPA）攻擊；
使用必要的防護(hù)措施，對抗針對加密芯片的側(cè)信道相關(guān)功耗分析（CPA）攻擊。
EVITA(E-safety Vehicle Instruction Protected Applications)項目定義了可用于汽車網(wǎng)絡(luò)信息安全領(lǐng)域的HSM(Hardware security module)的相關(guān)規(guī)范，針對不同的硬件能力將其分為Full、Medium和Light HSM。EVITA官網(wǎng)有對應(yīng)的分類表，如下所示。
EVITA HSM 分類表
不同等級的HSM模塊以及SHE(Secure Hardware Extension)支持的詳細(xì)功能對比如下：
EVITA HSM level（來源：CSDN@ppyang395942297111）
1.3 系統(tǒng)安全
系統(tǒng)安全主要關(guān)注的是整個系統(tǒng)的軟件代碼的真實性和完整性，以及如何防止軟件泄露的措施。
1.3.1 代碼安全
系統(tǒng)開發(fā)過程中對代碼進(jìn)行安全掃描或分析，并提供代碼掃描報告。對核心功能相關(guān)代碼實施代碼混淆、加固，防止被逆向分析。
車燈模組使用的MCU一般都是M0，M4內(nèi)核的，代碼相比BCM，網(wǎng)關(guān)等不算復(fù)雜，不太需要安全掃描。如果是高端車型需要做ADB，這部分算法目前比較復(fù)雜，建議實施代碼混淆、加固。
1.3.2 軟件讀保護(hù)
在代碼存儲區(qū)增加外部讀保護(hù)機(jī)制，對固件進(jìn)行保護(hù)，防止被竊取。
1.3.3 安全啟動
保證可信根安全；
對bootloader、應(yīng)用程序的真實性和完整性進(jìn)行校驗，防止被惡意篡改。
1.3.4 安全升級
對要升級的應(yīng)用層程序進(jìn)行來源合法性和完整性校驗；
對flash驅(qū)動進(jìn)行真實性和完整性校驗。
1.3.5 安全診斷
應(yīng)支持適配新的診斷、刷寫的安全訪問算法；
禁止開放未定義的診斷服務(wù)。
1.4 通信安全
通信安全關(guān)注的是ECU之間如何保證關(guān)鍵消息的可靠傳輸。
關(guān)鍵數(shù)據(jù)需要加密傳輸和消息認(rèn)證，保證消息來源的合法性和完整性。
消息認(rèn)證需要符合車廠的SecOC(Security Onboard Communication)規(guī)范。
對使用速率較高的CAN FD通信的ECU，車廠會要求一些關(guān)鍵數(shù)據(jù)在傳輸時先進(jìn)行對稱加密然后再傳輸加密后的消息。目前前燈模組逐漸開始使用CAN FD通信，但是車廠并不強(qiáng)制要求通信安全。
1.5 數(shù)據(jù)安全
數(shù)據(jù)安全關(guān)注的是關(guān)鍵信息的安全存儲。
重要數(shù)據(jù)和個人敏感信息應(yīng)實現(xiàn)安全存儲和隔離，防止未經(jīng)授權(quán)的訪問、篡改、刪除和檢索；
實現(xiàn)重要數(shù)據(jù)和個人敏感信息的安全傳輸，保證其機(jī)密性、完整性和可用性。
車燈模組主要的訴求要保存用于加密重要數(shù)據(jù)的密鑰，使用帶HSM模塊的MCU或者外掛的SE芯片，都是支持該功能的。
02
安全啟動流程
隨著車規(guī)MCU自帶的加密模塊功能變豐富之后，安全啟動（Secure Boot）也變得更加容易實現(xiàn)。如下是安全啟動的流程示意圖。
安全啟動流程示意圖
MCU上電之后，先運行可信引導(dǎo)程序?？尚乓龑?dǎo)程序會去驗證bootloader對應(yīng)區(qū)域的數(shù)據(jù)是否被篡改，即驗證bootloader的真實性和完整性。如果Bootloader驗證成功，就跳轉(zhuǎn)到bootloader，然后由bootloader驗證應(yīng)用程序的真實性和完整性。應(yīng)用程序驗證成功后，就跳轉(zhuǎn)到應(yīng)用程序，至此整個安全啟動流程就結(jié)束。
對于帶硬件加密模塊的MCU來說，可信引導(dǎo)程序一般通過加密模塊進(jìn)行使能以及配置需要驗證的bootloader的大小。如S32K144的Secure boot，需要通過CSEc模塊進(jìn)行使能；S32K3的Secure boot功能由HSE模塊負(fù)責(zé)。推薦閱讀如下文章：
S32K3亮點介紹-secure boot功能
對應(yīng)上述安全啟動流程的方案有三種，如下所示，接下來詳細(xì)介紹下這三種方案。
基于簽名技術(shù)的安全啟動方案
基于對稱簽名技術(shù)的安全啟動方案
基于CMAC技術(shù)的安全啟動方案
2.1 基于簽名技術(shù)的安全啟動方案
方案框圖如下：
基于簽名技術(shù)的安全啟動方案
生產(chǎn)階段：
MCU在出廠前，對bootloader和應(yīng)用程序的bin文件分別使用Hash算法（SHA256選用較多）得到概要值（或稱為完整性度量值），然后使用私鑰和RSA2048算法對概要值進(jìn)行簽名，最后將bin文件、簽名之后的概要值以及公鑰一起燒錄到MCU中。
安全啟動階段用到的私鑰，其生成、存儲和運算由汽車零部件供應(yīng)商負(fù)責(zé)，汽車廠商不參與。
啟動階段：
MCU上電之后，可信引導(dǎo)程序開始運行，根據(jù)預(yù)先保存的bootloader的地址信息，通過Hash運算得到bootloader的概要值1。然后使用預(yù)先保存的公鑰對bootloader的簽名概要使用RSA2048算法進(jìn)行驗簽，得到概要值2。最后將概要值1和概要值2進(jìn)行比較，如果一樣，MCU就跳轉(zhuǎn)到bootloader運行，否則就一直保持復(fù)位或者其他車廠要求的狀態(tài)。
bootloader運行之后，根據(jù)預(yù)先保存的應(yīng)用程序的地址信息、公鑰、簽名概要，執(zhí)行和可信引導(dǎo)程序一樣的操作，驗證應(yīng)用程序的真實性和完整性。
2.2 基于對稱簽名技術(shù)的安全啟動方案
方案框圖如下：
基于對稱簽名技術(shù)的安全啟動方案
生產(chǎn)階段：
MCU在出廠前，對bootloader和應(yīng)用程序的bin文件分別使用Hash算法（SHA256選用較多）得到概要值（或稱為完整性度量值），然后使用密鑰和對稱算法（不低于AES128）對概要值進(jìn)行加密得到MAC值，最后將bin文件、MAC值以及密鑰一起燒錄到MCU中。
MAC：Message Authentication Code，消息身份驗證代碼。
啟動階段：
MCU上電之后，可信引導(dǎo)程序開始運行，根據(jù)預(yù)先保存的bootloader的地址信息，通過Hash運算得到bootloader的概要值1。然后使用預(yù)先保存的密鑰對bootloader的MAC值使用對稱算法（不低于AES128）進(jìn)行解密，得到概要值2。最后將概要值1和概要值2進(jìn)行比較，如果一樣，MCU就跳轉(zhuǎn)到bootloader運行，否則就一直保持復(fù)位或者其他車廠要求的狀態(tài)。
bootloader運行之后，根據(jù)預(yù)先保存的應(yīng)用程序的地址信息、密鑰、MAC值，執(zhí)行和可信引導(dǎo)程序一樣的操作，驗證應(yīng)用程序的真實性和完整性。
2.3 基于CMAC技術(shù)的安全啟動方案
方案框圖如下：
基于CMAC技術(shù)的安全啟動方案
生產(chǎn)階段：
MCU在出廠前，對bootloader和應(yīng)用程序的bin文件分別使用密鑰和CMAC應(yīng)用的算法（不低于AES128）得到各組的CMAC值，然后將bin文件、CMAC值以及密鑰一起燒錄到MCU中。
CMAC：Cipher Block Chaining-Message Authentication Code，也簡稱為CBC_MAC，它是一種基于對稱密鑰分組加密算法的消息認(rèn)證碼。
啟動階段：
MCU上電之后，可信引導(dǎo)程序開始運行，根據(jù)預(yù)先保存的bootloader的地址信息，使用預(yù)先保存的密鑰對bootloader的BIN文件使用CMAC算法（不低于AES128）得到CMAC值1，然后將預(yù)先保存的CMAC值和CMAC值1進(jìn)行比較，如果一樣，MCU就跳轉(zhuǎn)到bootloader運行，否則就一直保持復(fù)位或者其他車廠要求的狀態(tài)。
bootloader運行之后，根據(jù)預(yù)先保存的應(yīng)用程序的地址信息、密鑰、CMAC值，執(zhí)行和可信引導(dǎo)程序一樣的操作，驗證應(yīng)用程序的真實性和完整性。
03
安全升級流程
安全升級和傳統(tǒng)的升級方式相比，主要是驗證應(yīng)用程序的真實性和完整性的方法更加完善了，一般采用3.1-3.3中的任意一種方式即可。下面只介紹下基于簽名技術(shù)的安全升級方案，其他兩種方案就不贅述了。
3.1 基于簽名技術(shù)的安全升級方案
方案框圖如下：
基于簽名技術(shù)的安全升級方案
生產(chǎn)階段：
客戶只需要將車廠分配過來的公鑰和BIN文件一起燒錄進(jìn)MCU即可。
私鑰的生成、存儲和運算由主機(jī)廠負(fù)責(zé)。
升級階段：
零部件廠商登錄車廠指定的網(wǎng)站，提交更新后的應(yīng)用程序的BIN文件，車廠審核通過后，會從云端下發(fā)到車身網(wǎng)關(guān)。在這個過程中，應(yīng)用程序的BIN文件也增加了對應(yīng)的簽名概要（如上圖左框部分）。
車身網(wǎng)關(guān)將BIN文件和簽名概要通過CAN/LIN總線傳輸給對應(yīng)的ECU節(jié)點。ECU中的MCU會對BIN文件進(jìn)行 Hash和驗簽操作，然后將得到的簽名概要和傳輸過來的簽名概要進(jìn)行比較，如果一樣，就升級傳輸過來的應(yīng)用程序，否則放棄此次升級并刪除傳輸過來的應(yīng)用程序。
審核編輯：黃飛
?
工商網(wǎng)監(jiān)
評論