基于當前智能網聯汽車OTA升級架構進行安全分析

隨著汽車行業快速向智能化、網聯化、電動化的方向發展，車載電子器件（ECU）在整車系統中逐漸增多，整車和 ECU 已經實現從物理方式到軟件升級（OTA）的更新迭代。當前針對汽車的黑客攻擊事件頻發，OTA 功能作為智能網聯汽車的重要功能，也成為黑客的重點攻擊對象。攻擊者通過劫持、篡改、替換等攻擊方法對智能網聯汽車 OTA 升級鏈接發起攻擊。文章基于當前智能網聯汽車 OTA 升級架構進行安全分析，通過設計安全的 OTA 升級方案，提升整車 OTA 升級的安全性。

前言

近年來，隨著智能網聯汽車的發展，越來越多的主機廠在汽車產品上集成了 OTA 升級功能，通過 OTA 實現系統升級、應用更新、漏洞修復及功能開通等等。目前主機廠 OTA 系統主要通過自主研發或由 OTA 供應商集成的方式在整車系統上實現 OTA 升級功能。

1 OTA系統架構

整車 OTA 系統主要分為云端、車端、通訊端三部分。

云端主要功能包括：OEM 云對接、車型/車輛/ECU 版本信息管理、升級軟件管理，差分包管理、大版本管理及策略創建、ECU 關聯升級配置、升級模式配置、策略測試、審批、發布等。車端主要功能包括：升級條件判斷、軟件包下載、升級包驗簽、升級包解密、安全刷寫、升級狀態上報等。

通訊端主要負責在 OTA 升級過程中進行報文傳輸及升級包下載等。

圖 1 OTA 升級系統架構圖

2 現階段OTA升級中信息安全威脅

現階段國內 OEM 已在量產車型上集成 OTA 升級功能，并通過實施安全策略保障 OTA 升級的安全性。目前常見的 OTA 升級校驗模式分為兩種：

（1）基于 HASH 算法的完整性校驗：云端使用 HASH 算法如 MD5、SHA-1 等計算升級文件 HASH 值，車端 UC-Mstaer 使用相同算法計算升級文件HASH 值，通過對比 HASH 值，實現升級文件完整性校驗，完成 OTA 升級校驗。但攻擊者通常可通過篡改 HASH 值、篡改校驗邏輯從而繞過該校驗方式。

圖 2 完整性校驗

該種校驗方式安全性較低且針對該方式的攻擊方法較為成熟，不建議 OEM 廠商使用該校驗方式實現 OTA 升級校驗。

（2）基于簽名算法的簽名校驗：通過使用 PKI 系統生成公私鑰，云端使用私鑰對升級包數據校驗和或其他與數據內容有關的變量進行加密處理，完成對數據的合法“簽名”，UC-Master ?則利用云端的公鑰來解讀收到的“數字簽名”，并將解讀結果用于對數據完整性的檢驗，確認簽名的合法性。保障 OTA 升級安全性。

該種校驗方式通過 UC-Master 對升級包進行驗簽，可以保證升級包整包的合法性和完整性，但在實際升級過程中，一個升級包整包通常打包有多個ECU 升級包，UC-Master 在完成升級包整包校驗后，通過對升級包進行解包。通過網關或域控制器透傳至目標 ECU，對目標 ECU 進行升級刷寫。通常目標ECU 不會對升級包進行二次校驗。隨著現在攻擊者攻擊手段不斷升級，攻擊者可在 UC-Master 對升級包整包完成校驗解包后，替換/篡改目標 ECU 升級包，達到惡意升級的目的。

以上兩種方法升級均存在一定安全威脅，雖然基于簽名算法的校驗保證了升級包整包的合法性和完整性，但在升級過程中無法對目標 ECU 升級包進行二次驗證，導致仍存在一定安全隱患，影響整車OTA 升級的安全性。

3 安全的OTA升級設計

針對上文討論，整車 OTA 升級安全性仍存在一定安全威脅。本文將基于數字簽名和消息認證碼設計一種安全的 OTA 升級方法，提高整車 OTA 升級安全性。

3.1 數字簽名

當前部分主機廠 OTA 升級系統通過調用 PKI 系統對升級包進行基于數字簽名的合法性校驗。數字簽名通過使用發送方的私鑰對原始數據進行簽名，只有用發送方公鑰才能通過簽名驗證。

因此，私鑰加密得到的密文實際上就是數字簽名，要驗證這個簽名是否正確，只能用私鑰持有者的公鑰進行解密驗證。使用數字簽名的目的是為了確認某個信息確實是由某個發送方發送的，任何人都不可能偽造消息，并且，發送方也不能抵賴。OTA 通過使用數字簽名可實現防止偽造、防止抵賴、檢測篡改、驗證數據的完整性等，保證 OTA 升級過程中軟件包的合法性。

常見的數字簽名算法有：MD5withRSA／SHA1 withRSA／ SHA256withRSA／ SHA1withDSA／ SHA 256withDSA／SHA512withDSA／ECDSA 等。

基于數字簽名的校驗流程：云端平臺在升級任務下發前，通過簽名算法（私鑰）對軟件升級包進行簽名。車端 OTA-Master 通過調用 PKI 系統（公鑰） SDK 對升級包進行校驗。

但基于數字簽名的 OTA 升級校驗對車端 UC- Matser 環境要求較高，需通過集成 PKI-SDK 或內置密鑰的形式進行。對零部件自身性能及安全性要求較高，通常 UC-Master 搭載在非實時操作系統的智能 ECU 中，如 T-BOX、IVI、CGW 中。主機廠還可在 UC-Master 的智能 ECU 中集成 HSM（硬件安全模塊）或 SE 芯片，保障 OTA 升級安全、高效。

3.2 消息認證碼

基于分組密碼的消息認證碼（CMAC）是基于AES 算法，工作模式分為 ECB、CBC、CFB、OFB 四種，其中 CBC 和 ECB 這兩種模式比較常用。當取AES 作為 MAC 加密的分組密碼時，一般采用 CBC 模式，所以通常稱為基于 AES 的 CBC-MAC，只需要一個塊密碼密鑰，并且在加密數量方面進行了高度優化。從分組密碼密鑰 K1 中派生出兩個掩碼密鑰K2 和 K3。如果最后一個塊完成，掩碼密鑰 K2 將在最后一次加密之前添加；否則，添加掩碼密鑰 K3。但由于分組密碼算法特性，加解密運算時間相對哈希算法運算耗時較長。

基于哈希的消息認證碼（ HMAC）是 Keyed- Hashing for Message Authentication 的縮寫。HMAC 的 MAC 算法是 HASH 算法，首先它是基于信息摘要算法的。目前主要集合了 MD 和 SHA 兩大系列消息摘要算法。其中 MD 系列的算法有 HmacMD2、HmacMD4、HmacMD5 三種算法；SHA 系列的算法有 HmacSHA1 、 HmacSHA224 、 HmacSHA256 、HmacSHA384、HmacSHA512 五種算法。

HMAC 算法除了需要信息摘要算法外，還需要一個密鑰。HMAC 的密鑰可以是任何長度，如果密鑰的長度超過了摘要算法信息分組的長度，則首先使用摘要算法計算密鑰的摘要作為新的密鑰。一般不建議使用太短的密鑰，因為密鑰的長度與安全強度是相關的。通常選取密鑰長度不小于所選用摘要算法輸出的信息摘要的長度。

3.3 整車 OTA 安全設計

由于車端 UC-Master 只能對 OTA 升級整包進行校驗，車端 UC-Master 完成校驗后將升級包整包進行解包，通過網關透傳到目標 ECU 進行刷寫。但當前傳統EEA 架構中只有少數ECU 搭載非實時操作系統，如：T-BOX、IVI、CGW 等。絕大多數 ECU 不具備多線程多任務處理能力且不支持集成第三方SDK，如：VCU、BCM、BMS 等。導致在這類非智能 ECU 上實現基于簽名算法的升級校驗較為困難。雖然開發者可以通過軟件方式實現數字簽名算法，

但由于該類 ECU 通常性能較差，軟件實現可能導致軟件升級簽名驗證耗時較長，影響軟件升級效率。整車的 OTA 升級需在保證安全的前提下，降低對整車及 ECU 性能影響。提高升級效率。

針對當前整車 EE 架構，在 OTA 升級過程中OEM 廠商在車端 UC-Master 中集成 PKI-SDK，實現基于數字簽名的升級校驗。在云端下發升級任務后，車端 DM 下載軟件升級包。UC-Master 對升級包進行簽名校驗，校驗完成后對升級包進行解包分發，通過網關透傳到目標 ECU。ECU 根據自身軟硬件架構，被升級 ECU-UA 對收到的升級包，使用數字簽名或哈希消息認證碼（HMAC）進行二次校驗，校驗成功后進行升級刷寫安裝。
?