目錄：
1. 前言
2.信息安全需求
2.1 硬件安全
2.3 系統安全
2.4 通信安全
2.5 數據安全
3. 安全啟動流程
3.1 基于簽名技術的安全啟動方案
3.2 基于對稱簽名技術的安全啟動方案
3.3 基于CMAC技術的安全啟動方案
4. 安全升級流程
4.1 基于簽名技術的安全升級方案
5. 參考資料
近期后臺很多讀者留言咨詢尾燈方案，因為微信公眾號的智能回復只收錄一年內的文章進行訓練，所以后臺的智能回復有些不太準確。
為了后臺智能回復更準確，筆者重新發下之前尾燈相關的文章。
最近在和一些車燈客戶交流時，發現很多車燈項目都多了信息安全的需求，為了進一步了解信息安全的需求，筆者收集了信息安全相關的文檔進行學習和梳理。下文是筆者自己整理的信息安全需求，并從車燈模組的角度增加了一些看法。如有不對的地方，歡迎指出。
本章節主要從硬件安全、系統安全、通信安全、數據安全四個方面介紹下信息安全的需求，重點介紹硬件安全和系統安全。
硬件安全主要關注的是PCB板的保密措施和關鍵芯片的加密功能。
對于車燈模組來說，需要注意的是主控MCU的調試接口，其他的外圍芯片基本不涉及到代碼讀取。
為保證整車的網絡安全，需考慮硬件級的安全加密，一般選擇集成了FULL EVITA等級的HSM模塊的MCU，如果使用的MCU沒有加密模塊，可以外接一個車規級別SE芯片，該SE芯片至少可提供如下接口：
主要芯片及加密芯片需滿足抗攻擊保護，滿足：
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）
系統安全主要關注的是整個系統的軟件代碼的真實性和完整性，以及如何防止軟件泄露的措施。
系統開發過程中對代碼進行安全掃描或分析，并提供代碼掃描報告。對核心功能相關代碼實施代碼混淆、加固，防止被逆向分析。
車燈模組使用的MCU一般都是M0，M4內核的，代碼相比BCM，網關等不算復雜，不太需要安全掃描。如果是高端車型需要做ADB，這部分算法目前比較復雜，建議實施代碼混淆、加固。
在代碼存儲區增加外部讀保護機制，對固件進行保護，防止被竊取。
通信安全關注的是ECU之間如何保證關鍵消息的可靠傳輸。
對使用速率較高的CAN FD通信的ECU，車廠會要求一些關鍵數據在傳輸時先進行對稱加密然后再傳輸加密后的消息。目前前燈模組逐漸開始使用CAN FD通信，但是車廠并不強制要求通信安全。
數據安全關注的是關鍵信息的安全存儲。
車燈模組主要的訴求要保存用于加密重要數據的密鑰，使用帶HSM模塊的MCU或者外掛的SE芯片，都是支持該功能的。
隨著車規MCU自帶的加密模塊功能變豐富之后，安全啟動（Secure Boot）也變得更加容易實現。如下是安全啟動的流程示意圖。
MCU上電之后，先運行可信引導程序。可信引導程序會去驗證bootloader對應區域的數據是否被篡改，即驗證bootloader的真實性和完整性。如果Bootloader驗證成功，就跳轉到bootloader，然后由bootloader驗證應用程序的真實性和完整性。應用程序驗證成功后，就跳轉到應用程序，至此整個安全啟動流程就結束。
對于帶硬件加密模塊的MCU來說，可信引導程序一般通過加密模塊進行使能以及配置需要驗證的bootloader的大小。如S32K144的Secure boot，需要通過CSEc模塊進行使能；S32K3的Secure boot功能由HSE模塊負責。推薦閱讀如下文章：
S32K3亮點介紹-secure boot功能
對應上述安全啟動流程的方案有三種，如下所示，接下來詳細介紹下這三種方案。
方案框圖如下：
生產階段：
MCU在出廠前，對bootloader和應用程序的bin文件分別使用Hash算法（SHA256選用較多）得到概要值（或稱為完整性度量值），然后使用私鑰和RSA2048算法對概要值進行簽名，最后將bin文件、簽名之后的概要值以及公鑰一起燒錄到MCU中。
安全啟動階段用到的私鑰，其生成、存儲和運算由汽車零部件供應商負責，汽車廠商不參與。
啟動階段：
MCU上電之后，可信引導程序開始運行，根據預先保存的bootloader的地址信息，通過Hash運算得到bootloader的概要值1。然后使用預先保存的公鑰對bootloader的簽名概要使用RSA2048算法進行驗簽，得到概要值2。最后將概要值1和概要值2進行比較，如果一樣，MCU就跳轉到bootloader運行，否則就一直保持復位或者其他車廠要求的狀態。
bootloader運行之后，根據預先保存的應用程序的地址信息、公鑰、簽名概要，執行和可信引導程序一樣的操作，驗證應用程序的真實性和完整性。
方案框圖如下：
生產階段：
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值，執行和可信引導程序一樣的操作，驗證應用程序的真實性和完整性。
方案框圖如下：
生產階段：
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值，執行和可信引導程序一樣的操作，驗證應用程序的真實性和完整性。
安全升級和傳統的升級方式相比，主要是驗證應用程序的真實性和完整性的方法更加完善了，一般采用3.1-3.3中的任意一種方式即可。下面只介紹下基于簽名技術的安全升級方案，其他兩種方案就不贅述了。
方案框圖如下：
生產階段：
客戶只需要將車廠分配過來的公鑰和BIN文件一起燒錄進MCU即可。
私鑰的生成、存儲和運算由主機廠負責。
升級階段：
零部件廠商登錄車廠指定的網站，提交更新后的應用程序的BIN文件，車廠審核通過后，會從云端下發到車身網關。在這個過程中，應用程序的BIN文件也增加了對應的簽名概要（如上圖左框部分）。
車身網關將BIN文件和簽名概要通過CAN/LIN總線傳輸給對應的ECU節點。ECU中的MCU會對BIN文件進行 Hash和驗簽操作，然后將得到的簽名概要和傳輸過來的簽名概要進行比較，如果一樣，就升級傳輸過來的應用程序，否則放棄此次升級并刪除傳輸過來的應用程序。
Microsoft Word - EVITA_Final_Publishable_Summary.docx (evita-project.org)[1]
硬件安全模塊- HSM_hsm she_ppyang395942297111的博客-CSDN博客[2]
如果覺得本篇文章對你有用， 不妨給個一鍵三連！！！
Microsoft Word - EVITA_Final_Publishable_Summary.docx (evita-project.org): https://www.evita-project.org/Publications/EVITAD0.pdf
[2]硬件安全模塊- HSM_hsm she_ppyang395942297111的博客-CSDN博客: https://blog.csdn.net/ppyang395942297111/article/details/112647109?spm=1001.2014.3001.5502
