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