作者：開心果 Need Car
出品：汽車電子與軟件
#01 前 言
當下，汽車產業正在進行著深刻的變革，不斷地朝著“四化”（智能化、電動化、網聯化、共享化）方向進行著轉型升級。而這一進程中，需要依賴車載控制器作為支撐。那么，控制器支撐的核心又是什么呢？就是它所承載的軟件。所以，SDV（Software-Defined Vehicle ，軟件定義汽車）已不在是一個時髦的詞匯，而是真實的扮演著舉足輕重的角色。但是，車載控制器軟件的開發并不是一個簡單的過程，在它工程落地的過程中，會遇到各式各樣的問題，在 ETAS 最近發布的白皮書《汽車微控制器軟件開發的五大挑戰》(1) 中，總結了五個方面： 高度集成任務、標定過程復雜、測試和調試耗時、可拓展和靈活性的限制、整體網絡安全需求。
既然車輛需要變得更“聰明”，就需要控制器之間進行大量的信息交互，也因此，這些交互的控制器構成了局部網絡。當車輛內的各個局域網的信息進行交互時，又構成了更大的網絡簇。更進一步的，車輛網絡與外界交互時，車輛就成了一個網絡移動終端，成了萬物互聯的一部分。當車輛成為網絡的一份子時，它不得不面對復雜的網絡威脅和攻擊。因此，網絡安全就不得不引起我們的格外關注，更具體的說：車輛傳輸和記錄的敏感信息安全，不可忽視！
1.1 車輛信息安全的定義
那么，什么是汽車信息安全（Vehicle cybersecurity）呢？按照法規(2)解釋：汽車的電子電器系統、組件和功能被保護，使其資產不受威脅的狀態。
#02 車輛信息安全的現狀
不可置否，車輛信息安全已經進入法規強標階段。出口海外的車輛，需要滿足聯合國世界車輛法規協調論壇（簡稱為UN/WP.29）發布的R155和R156要求。在國內，《汽車數據安全管理若干規定（試 行）》于2021年 10月 1 日起施行，《汽車數據通用要求》于2024年8月23起實施，《汽車整車信息安全技術要求》將于2026年1月1 日起實施...
由此可以看出，車輛信息安全已然成為軟件開發不可忽視的問題。那么，為什么車輛信息安全近些年會引起如此關注和重視呢？甚至于通過法規進行強制性約束呢？這與近些年不斷攀升的信息安全事件密不可分，部分車輛信息安全事件如下：
（1）豐田汽車數據泄露事件。2023 年 5 月，豐田汽車公司發布公告稱，由于云平臺系統配置錯誤，約 215 萬日本車主的部分車輛數據在近十年間處于公開狀態，包括車載設備 ID、底盤號碼、車輛位置信息等(3)；
（2）蔚來汽車電池數據被篡改事件。2023 年 5 月，蔚來汽車的電池數據被篡改，犯罪團伙通過將事故車和故障電池組的數據寫入完好電池組，使其可以重新充電上路(4)；
（3）高通芯片黑客攻擊事件。2024 年 10 月，高通公司發現其多達 64 款芯片組中存在嚴重漏洞，可能導致內存損壞，黑客可以利用這些漏洞對智能網聯汽車進行遠程控制，威脅車主的生命安全(5)；
如上的汽車安全問題事件很多，近些年更為突出。據 Upstream 發布的《2024 年全球汽車網絡安全報告》顯示，近 5 年汽車安全事件不斷攀升，如下所示： 
2.1 車輛面臨的信息安全威脅
那么，造成車輛信息安全問題的途徑有哪些呢？車輛被攻擊的路徑包含車內和車外兩條路徑。
車內信息安全威脅源主要是持有惡意攻擊軟件的 ECU。車外信息安全威脅源包括：外部設備連接，比如：通過 OBD（On-Board Diagnostics）連接的診斷儀等外部設備，Debug 調試口，XCP 標定口，OTA（Over-The-Air）、藍牙、WIFI 等。示意如下：
如上是我們可以直接想到的攻擊路徑，具體的車輛網絡攻擊方式遠比我們認知的方式多的多。相比以往，2023 年，網絡攻擊變得更為復雜和頻繁，攻擊的目標包括各種車輛系統和組件，以及智能出行平臺、物聯網設備和應用程序。新的攻擊方法讓行業深刻認識到：任何連接點都可能成為攻擊的目標(6)。
按照按攻擊載體劃分的網絡安全事件分布如下：
注：圖片來源資料 6
#03 車輛信息安全的工程落地問題
面對嚴峻的車輛信息安全事件，從控制器軟件供應商到 OEM 都已深刻意識到車輛信息安全的重要性。但是，這并不等同于可以開發出符合預期的軟件，那么，車輛信息安全的工程落地，到底有哪些難點呢？
3.1 信息安全的需求解讀
任何軟件的開發，第一步就是搞清需求。只有準確理解需求，才有可能開發出符合預期的軟件。目前，信息安全在項目實施過程中，需求握手還很難一次性達成。很難一次性達成的原因大致有如下幾點：
首先，汽車行業從業者對信息安全的需求認知薄弱。不同于互聯網行業，車輛信息安全在汽車行業剛剛興起，所以，汽車信息安全工程師解讀需求還需要時間以及工程項目的沉淀。
舉例：信息安全中有“驗簽”（verification）需求，可是在拆分需求時，有時系統工程師也分不清驗簽的工程使用場景，進而導致對具體算法的使用場景一知半解。所以，在理解需求之前，需要理解清楚驗簽的使用場景。首先， 軟件程序升級時需要驗簽。其次，每次控制器上電，運行程序前需要驗簽每一個需要執行的程序。需求初步分解示意如下：
需求理解到如上顆粒度（Granularity）就可以嗎？不能。實際的工程中，不同控制器，芯片選型不同。不同的芯片類型，能滿足的信息安全功能程度又不同，或者說對應的信息安全功能硬件化程度也就不同，需求也就不能一概而論。所以，信息安全需求解讀難的第二個點就是對使用的芯片認識不足。對于信息安全系統工程師而言，針對信息安全需求的拆解必須結合項目使用的芯片類型。但是，如果要了解芯片特性，就需要“啃”那厚厚的芯片手冊，而這無疑是耗費費力的事情，甚至會讓不少系統工程師望而卻步。如果不能深刻的認識芯片，那么，在信息安全需求溝通中，就可能產生理解偏差，甚至產生開發結果與需求不符的窘境。
這里舉一個工程案例：需求要求實現隨機數功能，如果所用芯片支持真隨機（True Random Number）功能，則隨機數必須由硬件實現。
如上需求表明了隨機性功能的實現優先由硬件實現。可是，工程師沿用了之前軟件實現的方案。這問題之所以被暴露出來是因為軟件升級過程中，診斷獲取的隨機種子偶有全 0x00 情況，細致追查發現：軟件的隨機性實現存在一定的 Bug，偶有返回異常，進而返回全 0x00 工況。這個問題看似簡單，但是，如果需求沒有充分解析并執行，那么，就可能引入更多的 Bug。
當然，信息安全對汽車領域從業者，不僅新，而且，隨著信息安全的需求不斷擴充，使得需求需要解讀的信息量不斷增加，這亦增加工程師的解讀成本。
3.2 信息安全的開發難點
通過需求拆解以后，對于軟件開發工程師而言，就需要設計軟件架構，之后，按照軟件架構實現信息安全的功能。信息安全軟件的實現又難在哪里呢？
首先，軟件架構不統一。在實際項目開發過程中，軟件工程師很多時候會從其他的項目中“搬運”已有的功能，如果搬運的功能模塊與新的項目軟件架構沖突，工程師往往會做一些手動修改，如此，就會引入未知變量，增加潛在軟件漏洞。
舉例：工程中可能會遇到這樣的場景，即：只有 HSM 的軟件包，但是，Host 端的軟件程序沒有配套的信息安全軟件接口。為了降低成本，需要工程師開發對應 Host 的信息安全接口。如此，帶來的直接問題就是兩者的框架不統一，而這就是一個安全隱患。軟件架構設計中，某個功能的實現由一個工程師完整實現能最大程度的保證一致性，如果一個功能由兩個或者多個工程師實現，則很難做到預期的一致性。
示意如下：
其次，軟件調試困難。軟件開發的好壞很大程度上依賴軟件的調試環境。調試軟件不僅僅需要價格昂貴的硬件調試設備，還需要對應的調試軟件，這些軟硬件設備的使用需要工程師的儲備，這無疑增加了軟件開發的困難。
這里以英飛凌 TC3xx 芯片的信息安全調試為例。如果一個信息安全工程師需要調試信息安全功能，基本的硬件環境包括：包含所需軟件的電腦、調試器硬件、目標控制器對應的芯片。示意如下：
軟件的編譯需要對應的編譯器（compiler），而且編譯器需要支持信息安全工程的編譯與非信息安全工程的編譯；軟件調試，調試器需要對應的軟件，調試的信息安全，如果包含異構多核，調試器則需要多個 license，以便于支持多核調試。實際的開發中，除此之外，工程師還可能需要了解第三方工具的配置和使用環境，eg：MCAL 配置 工具，BSW 配置工具等。
再次，手動軟件質量不可控。實際的工程開發中，有些功能屬于項目特有的，這些功能無法通過工具鏈自動化實現，因此，需要軟件工程師手動編碼實現。手動編碼的質量很大程度上依賴于工程師的編碼水平和對需求的理解，所以，這也在一定程度上增加了信息安全開發的難度。
3.3 信息安全的測試難點
軟件開發完成以后，工程的接力棒需要遞交給測試人員，由測試人員通過壓測識別出軟件潛在的漏洞。那么，對于信息安全來說，測試的難點在哪里呢？
首先，測試用例設計難。由于測試人員和開發人員的屬性不同，測試人員往往不關注實現的細節，因此，也不會過多的關注芯片手冊信息。但是，脫離了這些細節信息，往往又會使得測試人員難以理解測試的需求，進而在設計測試用例時，會出現測試邊界模糊，測試方案不準確的問題。
其次，測試設備使用成本。信息安全的測試中，需要用到的測試設備或者環境不同于傳統開發，因此，具體信息安全測試前，需要測試工程師對信息安全的測試環境有一定的經驗。而且，信息安全功能需要與 Host 進程（eg：Bootloader 工程、Application 程序等）進行交互。這樣的交互系統，無疑增加了測試的復雜度。對于測試人員，這樣復雜的系統交互場景，靠傳統的測試工具并不能達到測試目標。
Host 進程與信息安全進程通過IPC（Inter-Process Communication， 進程間通信）交互的場景，示意如下：
再次，白盒打樁測試強依賴開發環境。信息安全的測試中，部分測試需要通過軟件打樁的方式進行白盒測試，而這無疑增加了測試的難度。具體難點：信息安全工程師需要有一定編碼能力，同時，需要知道如何編碼對應的信息安全功能接口，進而達到條件修改測試的目的。
除了如上的測試困境以外，還需要考慮測試的如下問題：CWE （CommonWeakness Enumeration）缺陷測試。既然信息安全工程是一個獨立的軟件進程，首先需要確保該工程的可靠性，盡可能的通過軟件的靜態測試和掃描（eg：TESSY 測試等），發現可能導致安全問題的編碼錯誤或者設缺陷。當然，隨著車輛接入網絡的程度越來越高，網絡攻擊的途徑和方式也越多，在成本允許的條件下，可進行滲透測試（Penetration Testing），以此識別出系統中的安全漏洞。你可能好奇：對于MCU級的控制器，有這樣的攻擊場景嗎？有。網絡的攻擊已經不僅僅局限于以太網。CAN總線的攻擊也變得越來越多，比如：CAN DOS（Denial ofService，拒絕服務）攻擊、CAN 報文竊取、CAN報文重放、CAN 報文丟失等。所以，這些測試用例的設計和覆蓋，本身亦是一個艱巨的任務。
#04 結 論
面對復雜多變的車輛安全威脅，法規不斷強化信息安全規范。然而，信息安全的工程落地依然面臨著這樣、那樣的難點。這包括信息安全需求解讀難、開發難以及測試難等諸多問題。如何應對這些難點，使其真正的落地工程，還有很長的路走。
參考文獻：
（1）易特馳白皮書發布-汽車微控制器軟件開發的五大挑戰
（2）GB 44495-2024《汽車整車信息安全技術要求》
（3）https://mp.weixin.qq.com/s?__biz=MzAwMDE1NzIwMw==&mid =2652221905&idx=1&sn=4643d5a5fecb34ea6a3b5029d2f5fd77& chksm=810c22adb67babbb36419ef2c6f92316ac1d3025648530061 c53f968fc98a87d61d0a42844ff&scene=27
（4）https://news.sohu.com/a/808555084_121738491
（5）https://baijiahao.baidu.com/s?id=1815249214872984940&wfr=spi der&for=pc（6）Upstream_2024_Global_Automotive_Cybersecurity_Report.pdf
