首語

　　隨著軟件定義汽車（Software Defined Vehicles, SDV）的概念的提出，汽車軟件發展迅速，其功能越來越多，也變得越來越智能，汽車在為人們更好服務的同時，許多安全問題也隨之出現。汽車安全主要分為功能安全和信息安全，功能安全主要是要求降低汽車硬件的隨機失效概率，信息安全則主要保證汽車軟件安全運行、正常升級。怎樣保證軟件能夠安全運行，讓汽車ECU只運行完整的、可信的軟件？這種要求可以讓汽車的安全啟動（Secure Boot）來做到。

　　一、安全啟動了什么

　　當駕駛者準備啟動汽車時，汽車中各種各樣的軟件便會被加載，完成各種各樣的服務。這些軟件是汽車廠商設計并經過驗證的，汽車廠商保證了他們的軟件可行性和安全性，并把這些軟件在汽車賣給消費者之前就安裝在汽車中，并在后期對軟件維護和優化升級，通過在線升級（On The Air, OTA）技術對汽車軟件進行遠程升級。消費者能持續獲得可靠的優質軟件服務。

　　這些看起來都沒什么問題，但如果在消費者使用過程，這些配套軟件被惡意替換，那么不但軟件可能無法提供相應的服務和安全性，還極有可能對人和汽車本身造成嚴重傷害。所以汽車廠商在設計之初，就考慮到這一問題，實現了安全啟動來應對，安全啟動是一段在啟動引導程序（Bootloader）中的程序，在實現汽車各項功能的軟件（App）啟動之前，Bootloader會首先啟動，對App進行校驗，主要檢查App的兩項指標：完整性（Integrity）、可信度（Authentication），如果檢查不通過，則不會啟動App。完整性指軟件二進制可執行文件是否保持原樣，有沒有被篡改；可信度指軟件的來源是否可靠，在汽車軟件中，指是否是汽車廠商提供的。這兩項指標確保了汽車運行的軟件是來自汽車廠商有安全保證的軟件，并且沒有被篡改，從而保護了人和汽車的安全。

　　二、怎樣保證安全

　　怎么在汽車上實現對App的完整性和可信度的檢查呢？這里就需要一些密碼學（Cryptography）技術。

　　先來了解一些名詞：

　　哈希函數（Hash Function）：可將任意長度數據轉化為指定長度摘要（e.g. SHA2安全哈希函數，MD5）

　　對稱加密（Symmetric Encryption）：用同一把密鑰對數據進行加解密（e.g. DES，AES高級加密標準）

　　非對稱加密（Asymmetric Encryption）：使用公鑰和私鑰對數據加解密（e.g. RSA，ECC）

　　完整性驗證

　　App可執行文件是一個二進制文件，可以把App的可執行文件作為哈希函數的輸入，會得到一個固定長度的哈希值（Hash Value），這里就不得不提到哈希函數的一個特點，哈希函數的輸入值改變會影響輸出值，而且是極大的改變，哪怕是輸入值的一位（Bit）數據被改變。設想，使用哈希函數把汽車廠商的正版軟件作為輸入得到一個哈希值，并把其保存起來，黑客得到了汽車廠商的App并對其修改，然后想讓汽車運行他修改過的軟件，Bootloader在啟動安全啟動時，對修改后的App的再做一次哈希，發現與先前的值截然不同，也就不會啟動帶有風險的App。這就保證了軟件的整體性。

　　但這還不夠，哈希函數的實現方式是公開的，汽車廠商可以正常的App生成一個哈希值H1存放起來，那么黑客也可以生產一份經過修改的App的哈希值H2替換之前的H1， 并把修改后的App刷入汽車中，這樣Bootloader啟動時發現保存的哈希值H2和即將要運行的App（經過修改的）一致，則會正常運行。就可以騙過安全啟動的驗證，達到運行修改后App的目的。解決這一問題，這就要提到另一個技術——一次性可編程（One Time Programmable， OTP），這是單片機的一種存儲器類型，其作用是程序燒入單片機后，將不可再次更改和清除，汽車廠商可以將自己App所生成的哈希值存儲到這樣的存儲器中，就可以保證經過安全啟動驗證的App一定是汽車廠商所提供的，這塊區域也不可能被篡改。

　　可信度驗證

　　但接下來還有一個問題需要解決，前面我們提到過OTA技術，汽車廠商會在消費者使用汽車過程中，持續對汽車軟件進行維護和升級，如果汽車廠商把最初那一版App的哈希值放到了OTP存儲器中，那么結果就是，汽車廠商對App升級后，由于這塊區域的內容無法被更改（汽車廠商也無法修改），結果就是升級App后，由于安全啟動校驗不通過，導致軟件無法啟動。所以我們得采取其他的解決方案。

　　這里可以使用數字簽名（Digital Signature）技術，可以采用非對稱加密算法，利用私鑰（Private Key）對汽車廠商App的哈希值進行加密生成一個簽名保存起來，簽名只能用公鑰（Public Key）才能解密，簽名解密后是一串哈希值，我們就可以用這個哈希值和即將要啟動的App的哈希值進行比較。這樣看起來就好了很多，在OTA升級時，利于數字簽名技術對將要升級的App進行完整性和可信度驗證，確保將要升級的App沒有被篡改并且確實來自于汽車廠商（汽車廠商利用私鑰加密，汽車軟件升級驗證時用公鑰解密），然后將簽名寫入FLASH某個區域（不需要OTP特性）。那么公鑰放在那里呢？前面提到的OTP又派上用場了，這塊區域就可用來存儲和汽車廠商成對的公鑰。

　　當然也有采用基于分組密碼的消息認證碼算法（Cipher-based Message Authentication Code，CMAC）的方案進行安全啟動的驗證，其目的是相似的，只不過使用的方法不同。

　　如何實現加解密

　　有了解決方案，如何實現這些復雜的算法呢？這里就要講一講車規級MCU的發展歷史了，在一開始， MCU的芯片廠商并沒有集成硬件來完成加密算法（Cryptographic Algorithm），加解密過程基本都是軟件來實現的，其實軟件加解密這一塊離大家都很近，比如，熟悉Linux的同學知道，兩個客戶端要進行SSH通信前，需要提前生成SSH鑰匙，這里的SSH鑰匙就是上面提到的非對稱加密算法中的公鑰和私鑰。這樣實現加密算法的方法就是軟件實現，所以早期汽車實現這些加密算法也都是通過軟件層面實現的。這種方式有一定缺陷，比如加解密過程中，需要MCU中主核（一般是M4或M7）來完成整個算法，期間也不能做其他的事，主核在設計之初也沒有考慮對加解密算法進行優化，結果就是實際效率會差很多。 目前，主流的方法是通過硬件實現加密算法，例如硬件安全模塊（HSM，Hardware Security Modules）和安全硬件拓展（SHE，Secure Hardware Extension）。

　　SHE顧名思義，是對MCU的擴展，它主要提供類似于OTP的存儲空間，并不能為主核提供硬件加速，結構圖如下：

　　HSM就強大得多，擁有自己的CPU，并且有類似OTP的安全存儲區域，其結構如下：

　　目前，大多數高端車規級芯片都會集成SHE和HSM，國外芯片廠商有ST、NXP、infineon等，國內芯片廠商有芯馳、地平線、黑芝麻等，比較常見內嵌HSM模塊的芯片有意法半導體的SPC58、英飛凌的Trave系列、芯馳的G9X。

　　三、安全啟動流程

　　上述的這些解決方法和工具已經可以實現完整的安全啟動過程，這里要介紹一個安全啟動的概念——信任錨（Trust Anchor），大家可以把它理解為運動會中接力賽的接力棒，其實仔細想想就會發現，上面講的很多安全啟動的內容都是Bootloader來完成的，那么Bootloader的完整性和可信度又該怎么保證呢？其實就是靠這個信任錨，BootRom（是一段固化在芯片Rom中的程序）它先檢查Bootloader的完整性和可信度，確保沒有問題后，將信任錨傳遞給Bootloader，然后Bootloader進行密鑰的檢查、簽名驗證等操作，確保App是正確的，然后才啟動App完成各種服務。

　　四、發展與挑戰

　　汽車軟件發展迅速，它給人民生活帶來極大的便利，但機會和風險是并存的，汽車軟件的信息安全問題也不容小覷，以UNECE/WP. 29 （R155、R156） 和 ISO/SAE 21434 為代表的汽車信息安全的國際法規與標準已經發布與實施，我國也早已將發展智能網聯汽車上升到國家戰略高度，國家各部委根據在車聯網關鍵部件和生命周期各環節的職責劃分，制定相關政策及執行監管，包括網信辦、工信部、交通運輸部、公安部、國標委等，共同推動建立健全智能網聯汽車信息安全管理機制。例如，市場監管總局分別在2020年11月和2021年6月發布文件，規范了 OTA 技術在召回工作中的應用，明確要求生產者采用 OTA 方式消除汽車產品缺陷、實施召回的，須向市場監管總局備案。要求車企在使用 OTA 開展技術服務活動時，需向市場監管總局質量發展局備案；車企如果使用 OTA 消除車輛缺陷、實施召回的，也需要向市場監管總局質量發展局備案。

　　汽車信息安全技術也在不斷進步，國內外汽車廠商都在努力做出安全可靠的汽車軟件。相關外企研發出HSM模塊，并嵌入加密算法、訪問控制、完整性檢查等技術到汽車控制系統，但是目前HSM仍然不支持國密算法，存在技術壁壘，未能實現國產自主可控。國內對于芯片集成安全硬件還不完備，此種情況下能有一款支持國密標準的國產汽車硬件安全模塊對國內汽車行業十分重要。國密算法是我國自主研發創新的一套數據加密處理系列算法，隨著我國智能汽車信息安全的要求，需要將國密算法嵌入到硬件加密芯片中結合使用。

　　最好的情況就是，能在芯片層面保證安全啟動的方案和App軟件都是自主可控，這樣就可以最大程度的保證人和汽車的安全。

更多信息可以來這里獲取==>>電子技術應用-AET<<