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