01

信息安全需求

本章節主要從硬件安全、系統安全、通信安全、數據安全四個方面介紹下信息安全的需求，重點介紹硬件安全和系統安全。

1.1 硬件安全

硬件安全主要關注的是PCB板的保密措施和關鍵芯片的加密功能。

1.1.1 接口安全

量產階段，調試接口（如JTAG，SWD等）不宜直接暴露在PCB板上，如果無法避免，建議改為測試PIN方式分散布置。

量產階段，調試接口需要設置安全的身份驗證，身份驗證的口令至少為8位，且必須包含數字、大小寫字母。

對于車燈模組來說，需要注意的是主控MCU的調試接口，其他的外圍芯片基本不涉及到代碼讀取。

1.1.2 主板安全

量產階段，主板上的關鍵芯片（如主控芯片、硬件加密芯片、收發器等）、端口和管腳功能的標識絲印需要去除。

芯片間敏感數據的通信線路應盡量隱藏，對抗針對控制器內部數據傳輸的竊聽和偽造攻擊。

主板上的關鍵芯片采用可靠焊接封裝（如BGA、CSP），防止關鍵芯片被拆下讀取芯片內部信息。

1.1.3 芯片安全

為保證整車的網絡安全，需考慮硬件級的安全加密，一般選擇集成了FULL EVITA等級的HSM模塊的MCU，如果使用的MCU沒有加密模塊，可以外接一個車規級別SE芯片，該SE芯片至少可提供如下接口：

AES128算法接口

對稱密鑰存儲接口

SHA256算法接口

RSA2048算法接口

非對稱密鑰存儲接口

真隨機數獲取接口

主要芯片及加密芯片需滿足抗攻擊保護，滿足：

使用必要的安全機制，防御針對芯片的電壓、時鐘的單次故障注入攻擊；

使用必要的安全機制，防御針對芯片的電磁、激光的單次故障注入攻擊；

使用必要的防護措施，對抗針對加密芯片的側信道簡單功耗分析（SPA）攻擊；

使用必要的防護措施，對抗針對加密芯片的側信道一階差分功耗分析（DPA）攻擊；

使用必要的防護措施，對抗針對加密芯片的側信道相關功耗分析（CPA）攻擊。

EVITA(E-safety Vehicle Instruction Protected Applications)項目定義了可用于汽車網絡信息安全領域的HSM(Hardware security module)的相關規范，針對不同的硬件能力將其分為Full、Medium和Light HSM。EVITA官網有對應的分類表，如下所示。

EVITA HSM 分類表

不同等級的HSM模塊以及SHE(Secure Hardware Extension)支持的詳細功能對比如下：

EVITA HSM level（來源：CSDN@ppyang395942297111）

1.3 系統安全

系統安全主要關注的是整個系統的軟件代碼的真實性和完整性，以及如何防止軟件泄露的措施。

1.3.1 代碼安全

系統開發過程中對代碼進行安全掃描或分析，并提供代碼掃描報告。對核心功能相關代碼實施代碼混淆、加固，防止被逆向分析。

車燈模組使用的MCU一般都是M0，M4內核的，代碼相比BCM，網關等不算復雜，不太需要安全掃描。如果是高端車型需要做ADB，這部分算法目前比較復雜，建議實施代碼混淆、加固。

1.3.2 軟件讀保護

在代碼存儲區增加外部讀保護機制，對固件進行保護，防止被竊取。

1.3.3 安全啟動

保證可信根安全；

對bootloader、應用程序的真實性和完整性進行校驗，防止被惡意篡改。

1.3.4 安全升級

對要升級的應用層程序進行來源合法性和完整性校驗；

對flash驅動進行真實性和完整性校驗。

1.3.5 安全診斷

應支持適配新的診斷、刷寫的安全訪問算法；

禁止開放未定義的診斷服務。

1.4 通信安全

通信安全關注的是ECU之間如何保證關鍵消息的可靠傳輸。

關鍵數據需要加密傳輸和消息認證，保證消息來源的合法性和完整性。

消息認證需要符合車廠的SecOC(Security Onboard Communication)規范。

對使用速率較高的CAN FD通信的ECU，車廠會要求一些關鍵數據在傳輸時先進行對稱加密然后再傳輸加密后的消息。目前前燈模組逐漸開始使用CAN FD通信，但是車廠并不強制要求通信安全。

1.5 數據安全

數據安全關注的是關鍵信息的安全存儲。

重要數據和個人敏感信息應實現安全存儲和隔離，防止未經授權的訪問、篡改、刪除和檢索；

實現重要數據和個人敏感信息的安全傳輸，保證其機密性、完整性和可用性。

車燈模組主要的訴求要保存用于加密重要數據的密鑰，使用帶HSM模塊的MCU或者外掛的SE芯片，都是支持該功能的。

02

安全啟動流程

隨著車規MCU自帶的加密模塊功能變豐富之后，安全啟動（Secure Boot）也變得更加容易實現。如下是安全啟動的流程示意圖。

安全啟動流程示意圖

MCU上電之后，先運行可信引導程序?？尚乓龑С绦驎ヲ炞Cbootloader對應區域的數據是否被篡改，即驗證bootloader的真實性和完整性。如果Bootloader驗證成功，就跳轉到bootloader，然后由bootloader驗證應用程序的真實性和完整性。應用程序驗證成功后，就跳轉到應用程序，至此整個安全啟動流程就結束。

對于帶硬件加密模塊的MCU來說，可信引導程序一般通過加密模塊進行使能以及配置需要驗證的bootloader的大小。如S32K144的Secure boot，需要通過CSEc模塊進行使能；S32K3的Secure boot功能由HSE模塊負責。推薦閱讀如下文章：

S32K3亮點介紹-secure boot功能

對應上述安全啟動流程的方案有三種，如下所示，接下來詳細介紹下這三種方案。

基于簽名技術的安全啟動方案

基于對稱簽名技術的安全啟動方案

基于CMAC技術的安全啟動方案

2.1 基于簽名技術的安全啟動方案

方案框圖如下：

基于簽名技術的安全啟動方案

生產階段：

MCU在出廠前，對bootloader和應用程序的bin文件分別使用Hash算法（SHA256選用較多）得到概要值（或稱為完整性度量值），然后使用私鑰和RSA2048算法對概要值進行簽名，最后將bin文件、簽名之后的概要值以及公鑰一起燒錄到MCU中。

安全啟動階段用到的私鑰，其生成、存儲和運算由汽車零部件供應商負責，汽車廠商不參與。

啟動階段：

MCU上電之后，可信引導程序開始運行，根據預先保存的bootloader的地址信息，通過Hash運算得到bootloader的概要值1。然后使用預先保存的公鑰對bootloader的簽名概要使用RSA2048算法進行驗簽，得到概要值2。最后將概要值1和概要值2進行比較，如果一樣，MCU就跳轉到bootloader運行，否則就一直保持復位或者其他車廠要求的狀態。

bootloader運行之后，根據預先保存的應用程序的地址信息、公鑰、簽名概要，執行和可信引導程序一樣的操作，驗證應用程序的真實性和完整性。

2.2 基于對稱簽名技術的安全啟動方案

方案框圖如下：

基于對稱簽名技術的安全啟動方案

生產階段：

MCU在出廠前，對bootloader和應用程序的bin文件分別使用Hash算法（SHA256選用較多）得到概要值（或稱為完整性度量值），然后使用密鑰和對稱算法（不低于AES128）對概要值進行加密得到MAC值，最后將bin文件、MAC值以及密鑰一起燒錄到MCU中。

MAC：Message Authentication Code，消息身份驗證代碼。

啟動階段：

MCU上電之后，可信引導程序開始運行，根據預先保存的bootloader的地址信息，通過Hash運算得到bootloader的概要值1。然后使用預先保存的密鑰對bootloader的MAC值使用對稱算法（不低于AES128）進行解密，得到概要值2。最后將概要值1和概要值2進行比較，如果一樣，MCU就跳轉到bootloader運行，否則就一直保持復位或者其他車廠要求的狀態。

bootloader運行之后，根據預先保存的應用程序的地址信息、密鑰、MAC值，執行和可信引導程序一樣的操作，驗證應用程序的真實性和完整性。

2.3 基于CMAC技術的安全啟動方案

方案框圖如下：

基于CMAC技術的安全啟動方案

生產階段：

MCU在出廠前，對bootloader和應用程序的bin文件分別使用密鑰和CMAC應用的算法（不低于AES128）得到各組的CMAC值，然后將bin文件、CMAC值以及密鑰一起燒錄到MCU中。

CMAC：Cipher Block Chaining-Message Authentication Code，也簡稱為CBC_MAC，它是一種基于對稱密鑰分組加密算法的消息認證碼。

啟動階段：

MCU上電之后，可信引導程序開始運行，根據預先保存的bootloader的地址信息，使用預先保存的密鑰對bootloader的BIN文件使用CMAC算法（不低于AES128）得到CMAC值1，然后將預先保存的CMAC值和CMAC值1進行比較，如果一樣，MCU就跳轉到bootloader運行，否則就一直保持復位或者其他車廠要求的狀態。

bootloader運行之后，根據預先保存的應用程序的地址信息、密鑰、CMAC值，執行和可信引導程序一樣的操作，驗證應用程序的真實性和完整性。

03

安全升級流程

安全升級和傳統的升級方式相比，主要是驗證應用程序的真實性和完整性的方法更加完善了，一般采用3.1-3.3中的任意一種方式即可。下面只介紹下基于簽名技術的安全升級方案，其他兩種方案就不贅述了。

3.1 基于簽名技術的安全升級方案

方案框圖如下：

基于簽名技術的安全升級方案

生產階段：

客戶只需要將車廠分配過來的公鑰和BIN文件一起燒錄進MCU即可。

私鑰的生成、存儲和運算由主機廠負責。

升級階段：

零部件廠商登錄車廠指定的網站，提交更新后的應用程序的BIN文件，車廠審核通過后，會從云端下發到車身網關。在這個過程中，應用程序的BIN文件也增加了對應的簽名概要（如上圖左框部分）。

車身網關將BIN文件和簽名概要通過CAN/LIN總線傳輸給對應的ECU節點。ECU中的MCU會對BIN文件進行 Hash和驗簽操作，然后將得到的簽名概要和傳輸過來的簽名概要進行比較，如果一樣，就升級傳輸過來的應用程序，否則放棄此次升級并刪除傳輸過來的應用程序。