上海磐時 PANSHI

“磐時，做汽車企業(yè)的安全智庫”

好書分享/ 《一本書讀懂智能汽車安全》

汽車軟件開發(fā)階段安全的意義與原則

本文節(jié)選自SASETECH 汽車安全社區(qū)組織編寫的《一本書讀懂智能汽車安全》，該書由磐時創(chuàng)始人邊俊、博世汽車曲元寧以及吉林大學(xué)教授張玉新主導(dǎo)，匯聚了博世、蔚來、小鵬、磐時、卓馭、地平線、上汽、吉林大學(xué)等業(yè)界和學(xué)界在汽車安全領(lǐng)域的實踐經(jīng)驗和研究成果。它系統(tǒng)地展示了智能汽車研發(fā)全流程的功能安全、預(yù)期功能安全和網(wǎng)絡(luò)安全，以及三者如何在復(fù)雜的智能駕駛系統(tǒng)中實現(xiàn)高效安全的融合。書中豐富的案例和實踐經(jīng)驗對于提升產(chǎn)品安全性，優(yōu)化用戶體驗具有極大的參考價值，是智能汽車開發(fā)團隊的優(yōu)秀讀物。

以下內(nèi)容節(jié)選自《一本書讀懂智能汽車安全》：

無論是功能安全還是網(wǎng)絡(luò)安全相關(guān)的標(biāo)準(zhǔn)，都對軟件提出了諸多需求。那么，這些需求背后的邏輯是什么?為什么會有這些需求?回歸本質(zhì)看安全標(biāo)準(zhǔn)背后的東西，我們才能更好地理解需求，更好地落實需求。本節(jié)將嘗試從原理出發(fā)，為大家闡述什么是軟件安全。

01.

軟件安全的含義

1.1 經(jīng)典軟件事故

回顧剛剛過去的幾年里，軟件事故發(fā)生的頻率越來越高。軟件事故是指軟件出錯造成不可恢復(fù)的系統(tǒng)故障。在汽車領(lǐng)域，常見的軟件事故包括功能安全事故和網(wǎng)絡(luò)安全事故。下面通過兩個例子來分別介紹經(jīng)典軟件事故。

（1）Case 1：功能安全事故

2013年10月24日星期四，俄克拉荷馬州的一家法院對豐田公司不當(dāng)加速導(dǎo)致乘客死亡的案件做出了判決。此案件的核心是發(fā)動機控制模塊（ECM）的固件。

最終結(jié)論是：

◆豐田汽車的電子節(jié)氣門控制系統(tǒng)（ETCS）源代碼不合理。

◆豐田汽車的源代碼存在缺陷和錯誤，包括可能導(dǎo)致意外加速的錯誤。

◆代碼質(zhì)量指標(biāo)預(yù)測存在其他錯誤。

◆豐田汽車的失效保護機制存在缺陷和不足。

◆豐田汽車 ETCS 的不當(dāng)行為是意外加速的原因。

在技術(shù)調(diào)查中，ECM軟件構(gòu)成了調(diào)查的核心。關(guān)于堆溢出方面，豐田聲稱僅使用了分配的堆棧空間的 41%，但專家的調(diào)查顯示，實際使用的堆?？臻g高達 94%。除此之外，在代碼中還發(fā)現(xiàn)了堆棧終止、MISRAC規(guī)則違反遞歸等問題，并且 CPU 沒有結(jié)合內(nèi)存保護來防止堆棧溢出。

內(nèi)存中的單個位控制著每個任務(wù)，因此硬件或軟件故障導(dǎo)致的損壞會暫停所需任務(wù)或啟動不需要的任務(wù)。車輛測試證實，某一特定的停滯任務(wù)將導(dǎo)致油門控制失效，駕駛員必須在意外加速事件期間將腳完全從制動器上移開，才能結(jié)束意外加速。在代碼中發(fā)現(xiàn)了一系列其他錯誤，包括緩沖區(qū)溢出、不安全的鑄造，以及任務(wù)之間的競賽條件。

此外，凱美瑞 ETCS 代碼還被發(fā)現(xiàn)有11000個全局變量。專家將該代碼描述為“意大利面條”(圈復(fù)雜度)。豐田寬松地遵循了廣泛采用的 MISRAC編碼規(guī)則，但專家組發(fā)現(xiàn)有 80000處代碼違規(guī)。豐田公司自己的內(nèi)部標(biāo)準(zhǔn)僅使用了11條MISRAC規(guī)則，其中5條在實際代碼中被違反。專家還發(fā)現(xiàn)，同行代碼審查不充分且未經(jīng)跟蹤，豐田也沒有任何缺陷跟蹤系統(tǒng)。

（2）Case2：網(wǎng)絡(luò)安全事故

騰訊科恩實驗室在 2016 年和 2017年對 Tesla 汽車進行了兩次引人注目的遠程攻擊，成功利用多個高危安全漏洞（包括內(nèi)核、瀏覽器、MCU 固件、UDS 協(xié)議，以及 OTA 更新過程中的漏洞），攻人了 Tesla 汽車的關(guān)鍵系統(tǒng)，如 CID、IC、網(wǎng)關(guān)和自動駕駛模塊。這些攻擊不僅展示了車聯(lián)網(wǎng)系統(tǒng)的脆弱性，也促使 Tesla加強了其安全防護措施，包括及時發(fā)布安全補丁和更新。同時，這些案例也引起了汽車行業(yè)對網(wǎng)絡(luò)安全的廣泛關(guān)注，推動了相關(guān)標(biāo)準(zhǔn)和法規(guī)的制定與完善。

1) Tesla 汽車車聯(lián)網(wǎng)系統(tǒng)攻擊案例分析

首先介紹遠程攻擊面。Tesla在每輛汽車中都內(nèi)置了一個 WiFi TeslaService，其密碼以明文形式保存在 OtCarNetManager 中,，正常模式下不會自動連接。

首先介紹遠程攻擊面。Tesla在每輛汽車中都內(nèi)置了一個 WiFi TeslaService，其密碼以明文形式保存在 QtCarNetManager 中，正常模式下不會自動連接。

TeslaGuest 是特斯拉 4S 店和充電站提供的 WiFi熱點，這一信息被保存在汽車中，以便自動連接。研究人員可以制作一個釣魚熱點，當(dāng)Tesla用戶使用 CID 搜尋充電樁時，可以將OtCarBrowser 的流量重定向到自己的域名，從而達到遠程攻擊的目的。

除了 WiFi技術(shù)，在蜂窩網(wǎng)絡(luò)下，攻擊者如果建立足夠多的網(wǎng)站，利用網(wǎng)絡(luò)釣魚技術(shù)或用戶失誤，也可以達到入侵的目的。

其次介紹瀏覽器攻擊。從 Tesla 車載瀏覽器的 user-agent得到“Mozilla/5.0（X11;Linux）AppleWebKit/534.34 （KHTML, Gecko）likeQtCarBrowser Safari/534.34”,可以得出 OtWebkit 的版本是 2.2.x。這是一個比較老的版本，存在許多漏洞。騰訊科恩團隊利用了其中兩個漏洞實現(xiàn)了任意代碼執(zhí)行，從而攻擊瀏覽器。

2) 語音控制系統(tǒng)破解案例

“海豚音攻擊”的原理是將語音命令的頻率轉(zhuǎn)換為超聲波頻率信號，由于該信號超出人耳接收頻率的范圍，無法被人聽見，但可以被手機、智能家居以及智能汽車等智能設(shè)備的語音控制系統(tǒng)接收到。

由于麥克風(fēng)的非線性特性，原本被調(diào)制的語音命令會被解調(diào)，恢復(fù)到調(diào)制之前的狀態(tài)。之后，濾波器會過濾掉人耳不可聽到的部分，這樣語音指令可以無聲無息地被語音識別系統(tǒng)識別到，最終實現(xiàn)攻擊。

汽車制造商在面臨上述功能安全或網(wǎng)絡(luò)安全問題時，通常會采取批量召回措施來作為事故后的處理。召回的目的是解決這些問題，確保消費者的安全，并維護企業(yè)的聲譽。圖6-23展示的是我國 2021年缺陷涉及總召回數(shù)量的分布。從缺陷涉及的總成來看，發(fā)動機和電子電氣系統(tǒng)是主要的缺陷產(chǎn)生部件，占總召回數(shù)量的 84.3%。因發(fā)動機總成缺陷實施召回 50 次，涉及車輛 371.3萬輛，占總召回數(shù)量的 42.5%;因電子電氣系統(tǒng)缺陷實施召回 54 次，涉及車輛 365.0萬輛，占總召回數(shù)量的 41.8%;因制動系統(tǒng)缺陷實施召回 21 次，涉及車輛 51.0萬輛占總召回數(shù)量的 5.8%。

一直以來，發(fā)動機都是主要缺陷產(chǎn)生的部件。近年來，因發(fā)動機問題，無論是合資品牌還是自主品牌，都曾發(fā)布過大規(guī)模召回公告。隨著電動化和智能化的發(fā)展，電氣設(shè)備的安全 問題也逐漸凸顯，如今其缺陷占比已經(jīng)接近發(fā)動機缺陷的比例。

值得關(guān)注的是，近兩年的召回趨勢向新能源動力特征變化，軟件、電池等的召回逐步增多，類似傳統(tǒng)車的發(fā)動機缺陷特征。從表 6-2 可以看出，軟件性召回在 2023 年爆發(fā)式出現(xiàn)。 軟件性召回的增多，也說明了無論傳統(tǒng)車還是新能源車的軟件問題都逐步顯現(xiàn)。同時，召回政策和標(biāo)準(zhǔn)也需要不斷完善，規(guī)范車輛軟件設(shè)計、編碼和測試，從而阻止軟件事故的發(fā)生。

軟件安全是軟件開發(fā)和運行過程中的一個重要問題，它涉及網(wǎng)絡(luò)安全、功能安全和性能 安全等多個方面。

隨著軟件性召回事件的日益增多，這一趨勢凸顯了在軟件開發(fā)過程中安全性問題的重要性。這需要考慮功能安全，確保車輛關(guān)鍵系統(tǒng)的可靠性和穩(wěn)定性，也需要考慮網(wǎng)絡(luò)安全，防止?jié)撛诘倪h程攻擊和數(shù)據(jù)泄露，另外也要考慮汽車系統(tǒng)在規(guī)定的條件下和規(guī)定的時間內(nèi)，完成既定功能的能力（即性能安全）。

網(wǎng)絡(luò)安全是軟件安全的核心內(nèi)容之一，主要涉及數(shù)據(jù)和隱私的保護。網(wǎng)絡(luò)安全包括防止非法訪問、防止數(shù)據(jù)泄露、防止數(shù)據(jù)篡改等。為了保證網(wǎng)絡(luò)安全，軟件需要采用加密技術(shù)身份認證技術(shù)、訪問控制技術(shù)等。

功能安全是指軟件在正常運行和故障情況下都能保證其應(yīng)有的功能服務(wù)。它主要涉及軟件的可靠性和安全性。確定性雖然沒有被功能安全標(biāo)準(zhǔn)提及，但我們認為確定性是 ISO 26262 標(biāo)準(zhǔn)的核心思想。為了保證功能安全，軟件需要進行充分的測試和驗證，包括單元測試、集成測試、系統(tǒng)測試等。

性能安全是指軟件在高負載情況下仍能保持穩(wěn)定運行。它主要涉及軟件的性能優(yōu)化和高負載能力。為了保證性能安全，軟件需要進行性能測試和負載測試，以確保其在高負載情況 下仍能正常運行。

軟件安全覆蓋了軟件生命周期的各個階段，包括需求分析、設(shè)計、實現(xiàn)、測試和維護等。 在軟件安全的生命周期中，軟件設(shè)計和開發(fā)是保證軟件安全的基礎(chǔ)，測試是檢驗軟件安全性的關(guān)鍵，維護是保障軟件安全的重要手段。

02.

影響軟件安全的因素

從安全的角度看，影響軟件安全的因素可以分為運行硬件環(huán)境失效、軟件自身失效、惡意入侵。

對于運行硬件環(huán)境失效，一般可以歸為功能安全中的“硬件隨機性失效”與“硬件系統(tǒng) 性失效”，以及預(yù)期功能安全中的“硬件性能局限”。此部分內(nèi)容已在第 5 章展開介紹。

對于軟件自身失效，一般可以歸為功能安全中的“軟件系統(tǒng)性失效”以及預(yù)期功能安全 中的“算法性能局限”。此部分內(nèi)容是本章的關(guān)注點。

對于惡意入侵，一般可以歸為網(wǎng)絡(luò)安全的軟件威脅。此部分內(nèi)容是本章的關(guān)注點。

2.1 軟件自身失效來源及分類

軟件系統(tǒng)性失效是指軟件系統(tǒng)中出現(xiàn)的一系列相似或相關(guān)的錯誤或缺陷。這些錯誤或缺陷通常不是由單個錯誤引起的，而是由系統(tǒng)中的多個因素相互作用而導(dǎo)致的。從整個軟件開 發(fā)生命周期的角度看，軟件系統(tǒng)性失效主要來源如下。

1）軟件需求不合理：軟件需求不合理是軟件系統(tǒng)性失效的主要來源之一。針對傳統(tǒng)系統(tǒng) 來說，需求傳遞不一致（如客戶需求和系統(tǒng)需求不一致，軟件需求與軟件模塊需求不一致）是 導(dǎo)致軟件需求不合理的主要因素。對于自動駕駛或一些復(fù)雜系統(tǒng)而言，需求不合理還源于難 以識別用戶需求或場景需求。由于一些 Corner Case 的存在和用戶誤用的可能，軟件需求往往很難考慮周全，這部分屬于預(yù)期功能安全的范疇。

2）軟件設(shè)計錯誤：軟件設(shè)計錯誤通常是指在軟件設(shè)計過程中出現(xiàn)的一系列問題或缺陷。 這些問題或缺陷通常不是由單個錯誤引起的，而是由設(shè)計過程中多個因素相互作用導(dǎo)致的。 導(dǎo)致軟件設(shè)計錯誤的最大問題是軟件的復(fù)雜性和不確定性，比如，多個設(shè)計決策之間的沖突、 錯誤之間的串?dāng)_、資源（如內(nèi)存、 CPU）的非預(yù)期占用等。

3）編碼錯誤：編碼錯誤是軟件系統(tǒng)性失效的另一個常見來源。編碼時的疏忽或者錯誤的 代碼邏輯，導(dǎo)致軟件不能正常運行或者出現(xiàn)異常。

4）軟件測試不充分：軟件測試不充分是軟件系統(tǒng)性失效的另一個重要因素。如果軟件測試不夠嚴(yán)格，漏洞和錯誤可能不被發(fā)現(xiàn)，導(dǎo)致軟件系統(tǒng)性失效問題出現(xiàn)。

5）軟件算法能力不足：預(yù)期功能安全會引入機器學(xué)習(xí)技術(shù)問題。機器學(xué)習(xí)因算法能力不足或訓(xùn)練數(shù)據(jù)質(zhì)量問題會引發(fā)軟件系統(tǒng)性失效，例如未選擇最合適的算法、樣本特征選擇不當(dāng)或硬件資源的限制導(dǎo)致的算法性能局限。訓(xùn)練數(shù)據(jù)的質(zhì)量問題通常源于數(shù)據(jù)集的不完整性 或數(shù)據(jù)標(biāo)記的不準(zhǔn)確性。

2.2 常見的軟件威脅及分類

近些年，由于汽車智能化、網(wǎng)聯(lián)化、電動化和共享化的發(fā)展，汽車軟件代碼量不斷增加。2016年，主流車型約含 1.5 億行源代碼。預(yù)計到 2025 年，汽車使用的代碼量將達到 2 億行。隨著軟件代碼量的不斷增加，對應(yīng)的軟件安全威脅也呈指數(shù)級增長。軟件層級主要包括“設(shè)計階段的軟件威脅及漏洞”和“實施階段的軟件威脅及漏洞”。

（1）設(shè)計階段的軟件威脅及漏洞

根據(jù)微軟的 STRIDE 威脅模型，軟件的安全威脅主要分為六類，分別為 Spoofing、 Tampering 、Repudiation 、Information Disclosure 、Denial of Service 和 Elevation of Privilege。

1）Spoofing。這種威脅主要指攻擊者假冒合法有效的系統(tǒng)用戶來訪問系統(tǒng)，從而危及系統(tǒng)安全。

示例：

在車云通信場景中，惡意冒充者偽造正常的 IP 數(shù)據(jù)包，劫持與服務(wù)器的連接。這里的威 脅及漏洞是由于通信協(xié)議在設(shè)計時未考慮保密性和完整性。

在車云通信或車內(nèi)通信場景中，不正確使用密鑰或密鑰泄露可能導(dǎo)致攻擊者竊聽網(wǎng)絡(luò)交 互的敏感數(shù)據(jù)，進而冒充合法用戶。這里的威脅及漏洞是由于密鑰等數(shù)據(jù)沒有被有效防護。

2）Tampering。這種威脅主要指攻擊者對軟件或數(shù)據(jù)在使用、存儲、傳輸過程中進行惡意 修改，以達到對系統(tǒng)破壞或數(shù)據(jù)篡改的目的。

示例：

在車內(nèi)或車外通信場景中，對發(fā)送的數(shù)據(jù)進行篡改，例如將車窗控制指令由開更改為關(guān)。 這里的威脅及漏洞是由于在通信鏈路上發(fā)送的數(shù)據(jù)缺乏完整性。

在未授權(quán)的情況下修改系統(tǒng)的關(guān)鍵配置文件、用戶數(shù)據(jù)等。這種威脅及漏洞是由于缺少訪問檢查、沒有進行完整性檢查等。

3）Repudiation。這種威脅主要指攻擊者否認其行為，系統(tǒng)缺乏追蹤、日志和溯源的能力，無法證明其行為。

示例：

用戶惡意刪除系統(tǒng)中的敏感文件，或攻擊者頻繁使用用戶賬號登錄的行為。這種威脅及漏洞是由于缺少對用戶登錄行為的有效審計，或?qū)Ξ惓５卿洜顟B(tài)的日志。

4）Information Disclosure。這種威脅主要指泄露用戶的敏感信息或關(guān)鍵業(yè)務(wù)信息給非授權(quán)用戶。用戶能夠獲得未被授予訪問權(quán)限的數(shù)據(jù)，以及攻擊者能夠在網(wǎng)絡(luò)傳輸過程中獲取數(shù)據(jù)等行為，都屬于信息泄露威脅。

示例：

通過使用一些工具（例如 CANOE），可以獲取車內(nèi)通信的 CAN 報文，并從未加密的數(shù)據(jù)包中輕松地得到車輛的控制指令，或者傳輸?shù)挠脩魯?shù)據(jù)、OTA 數(shù)據(jù)包等敏感信息。

5）Denial of Service。這種威脅主要指攻擊者將系統(tǒng)資源耗盡，導(dǎo)致系統(tǒng)不可用或無法提供正常服務(wù)，進而影響用戶的正常使用，損害整體功能。

示例：

在 HTTP 通信場景中，SYN 泛洪攻擊會導(dǎo)致正常用戶無法連接服務(wù)器，甚至可能導(dǎo)致服務(wù)器崩潰。

薄弱的軟件設(shè)計或配置，導(dǎo)致一個進程占用了幾乎所有的 CPU 資源。

6）Elevation of Privilege。這種威脅主要指普通用戶獲取了系統(tǒng)的訪問權(quán)限，從而擁有足夠的權(quán)限達到損害或破壞整個系統(tǒng)的目的。

示例：

在未經(jīng)授權(quán)用戶同意的情況下運行可執(zhí)行文件來實現(xiàn)攻擊。

(2) 實施階段的軟件威脅及漏洞

正如上文所說，在設(shè)計階段存在多種威脅及漏洞，但是即使對“設(shè)計階段的軟件威脅及漏洞”采取了措施，也無法完全避免在軟件具體實現(xiàn)過程中出現(xiàn)安全威脅及漏洞。同時，安全編碼不完善導(dǎo)致的實施階段的威脅及漏洞可能會引發(fā)嚴(yán)重的損害。根據(jù) CWE 披露的安全缺陷 CWE TOP 25，常見的軟件安全漏洞類型如下。

1）越界寫入。越界寫入即緩沖區(qū)溢出，指當(dāng)應(yīng)用程序在預(yù)期輸入緩沖區(qū)的邊界之外寫入數(shù)據(jù)時出現(xiàn)這種安全漏洞。當(dāng)應(yīng)用程序執(zhí)行指針運算或更改索引以引用內(nèi)存緩沖區(qū)之外的位置時，也可能導(dǎo)致該弱點，通常會導(dǎo)致意外執(zhí)行非預(yù)期的代碼、程序崩潰或數(shù)據(jù)損壞。

2）越界讀取。越界讀取指的是當(dāng)應(yīng)用程序讀取超出預(yù)期輸出緩沖區(qū)邊界之外的數(shù)據(jù)時出現(xiàn)這種安全漏洞。攻擊者可以通過讀取越界內(nèi)存中的敏感信息，獲取繞過身份驗證機制的信息，并利用其他弱點進一步獲取敏感數(shù)據(jù)。

3）輸入驗證不當(dāng)。輸入驗證是一種常用技術(shù)，用于檢查潛在的危險輸入，確保在代碼處 理或與其他組件通信時輸入是安全的。當(dāng)軟件不能正確驗證輸入時，攻擊者能夠以應(yīng)用程序其他部分不期望的形式設(shè)計輸入。這將導(dǎo)致系統(tǒng)接收到意想不到的輸入，可能引起控制流的改變、資源的任意控制或任意代碼的執(zhí)行。

4）釋放后使用。釋放后使用主要指的是相關(guān)內(nèi)存在被釋放后的某個時間點被重新分配給另一個指針。指向已釋放內(nèi)存的原始指針再次被使用，并指向新分配內(nèi)存的某處。數(shù)據(jù)被更改時，將破壞有效使用的內(nèi)存，導(dǎo)致不確定的異常事件發(fā)生。

5）NULL 指針取消引用。NULL 指針取消引用是指應(yīng)用程序解引用一個它認為有效的指針，但該指針實際為空，這通常會導(dǎo)致程序崩潰或退出。 NULL 指針取消引用問題可能由多種缺陷引起，包括競爭條件和簡單的編程遺漏。NULL 指針取消引用通常會導(dǎo)致進程失敗，盡管某些平臺具有異常處理機制，但即使使用異常處理機制，也很難將軟件恢復(fù)到安全的運行狀態(tài)。

03.

功能安全軟件的核心要求

3.1 功能安全軟件與非功能安全軟件的差異

在軟件層面，相比于非功能安全軟件，功能安全軟件在開發(fā)過程中的差異主要體現(xiàn)在以 下幾個方面。

（1）需求分析

在功能安全軟件的需求分析過程中，我們需要將安全性作為重要的考慮因素，并制定相 應(yīng)的安全性要求。而在非功能安全軟件的需求分析過程中，我們則更加注重用戶需求和技術(shù)實現(xiàn)等方面的考慮。

（2）設(shè)計過程

在功能安全軟件的設(shè)計過程中，我們需要采用相應(yīng)的安全設(shè)計原則，例如防御性編程、安全架構(gòu)設(shè)計等，以確保軟件的安全性。而在非功能安全軟件的設(shè)計過程中，我們則更加注重功能實現(xiàn)和性能等方面的考慮。同時，為了進一步減少軟件的系統(tǒng)性失效和硬件隨機性失效，功能安全軟件往往設(shè)計了許多用于故障檢測的診斷功能。故障檢測的顆粒度和時效性要求，往往是非功能安全軟件不具備的。例如，針對單點失效，功能安全軟件要求故障診斷和處理的時間需要小于故障可能造成危害的時間，這就導(dǎo)致功能安全診斷往往是實時的且間隔時間非常短（如小于 500ms）。

（3）測試流程

功能安全軟件的單元測試需要涵蓋所有的安全性要求，并進行全面的測試覆蓋，以確保軟件的安全性。而非功能安全軟件的單元測試則更加注重功能的實現(xiàn)和代碼的正確性。功能安全軟件的集成測試需要測試軟件各個部分之間的交互和協(xié)作，以確保整個系統(tǒng)的安全性。非功能安全軟件的集成測試則更加注重系統(tǒng)的性能和用戶體驗。功能安全軟件的嵌入式測試需要進行各種可能的場景測試，包括異常情況和故障恢復(fù)等方面的測試，以確保軟件的安全性。非功能安全軟件的嵌入式測試則更加注重系統(tǒng)的可靠性、可維護性和可擴展性。

總的來說，功能安全軟件和非功能安全軟件在開發(fā)過程中存在較大差異。為了保證功能安全軟件的安全性，我們需要進行更加嚴(yán)格的開發(fā)和測試，并采用相應(yīng)的安全設(shè)計原則。

3.2 常見的軟件威脅及分類

安全論證是實施功能安全的重要環(huán)節(jié)。論證方法多種多樣，從形式上來看，可以通過非 形式化的測試確認、過程確認等，也可以通過形式化的驗證方式。其中，常用的形式化方法 是 GSN（Goal Structuring Notation）。

它通過圖形化的結(jié)構(gòu)，更好地展現(xiàn)某個論點在不同應(yīng)用場景中的真實性及支持證據(jù)。GSN 廣泛應(yīng)用于安全性非常重要的行業(yè)，例如汽車、航空飛行器等。它是撰寫安全案例的有力工具，可以以圖形化的方式系統(tǒng)性地論證安全案例的正確性。

GSN 中的安全論證模型可以清楚展現(xiàn)證明文件中的論據(jù)及其相互之間的邏輯關(guān)系。每一個建立的安全論證模型都有完善和規(guī)范的體系，為后續(xù)第三方評估提供全面參考。

安全論證方法論總體思想見圖 6-24。簡而言之，安全案例的論證需要做到“有理有據(jù)”?！袄怼敝傅氖且械览恚捎玫臉?biāo)準(zhǔn)、原理依據(jù)、必要的假設(shè)等；“據(jù)”指的是有證據(jù)，用真實、具體的證據(jù)證明安全目標(biāo)。

GSN 相關(guān)的語法及語義如表 6-3 所示。

圖 6-25 是典型的 GSN 示例。將 GSN 的各主要要素連接在一起，構(gòu)成樹狀架構(gòu)（即Goal Structure）。GSN 通過對安全目標(biāo)的一步步分解和論證，直達葉子節(jié)點，即真實、具體的證據(jù)（又稱 Solution）。在論證過程中，展現(xiàn)論證的策略以進行定量或定性分析、全量或部分分析，采用的原理和標(biāo)準(zhǔn)，必要的假設(shè)等，真正體現(xiàn)安全觀點的有理有據(jù)。

04.

網(wǎng)絡(luò)安全對軟件的核心要求

隨著汽車中嵌入的軟件數(shù)量的增加，網(wǎng)絡(luò)安全對于汽車軟件變得越來越重要。廣義上講，汽車軟件分為支持智能網(wǎng)聯(lián)服務(wù)的云端軟件和車端軟件。作為移動的主體，隨著網(wǎng)聯(lián)化的進一步發(fā)展，汽車暴露的外部端口及信息也在增多。同時，隨著世界各國對個人隱私數(shù)據(jù)保護的重視和各種法規(guī)的出臺，車端軟件的網(wǎng)絡(luò)安全成為關(guān)注的重點。為保障車端軟件的合規(guī)性以及網(wǎng)絡(luò)安全性，車端軟件需要滿足以下核心要求。

◆信息的機密性保護：車輛必須保護所有敏感數(shù)據(jù)，如用戶隱私、車輛位置、個人信息、 賬號密碼等。車輛必須使用加密技術(shù)來保護這些敏感數(shù)據(jù)，以避免被非法獲取。常用 的方法是使用 TEE 分區(qū)，實現(xiàn)敏感數(shù)據(jù)和非敏感數(shù)據(jù)的隔離。

◆通信安全的保障：伴隨車載以太網(wǎng)的部署，車輛軟件必須使用安全的通信協(xié)議來與其他設(shè)備和服務(wù)進行通信。這些協(xié)議必須提供加密和身份驗證功能，以確保通信的機密性和完整性。安全通信協(xié)議需要覆蓋 OSI 的物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、 會話層、表示層、應(yīng)用層。每一層都需要根據(jù)實際的汽車電子電氣架構(gòu)，采用合理的 安全協(xié)議，例如網(wǎng)絡(luò)層的 IPSec 和傳輸層的 TLS1.0 等。

◆軟件和數(shù)據(jù)的完整性保障：確保汽車軟件不被惡意軟件或黑客篡改。使用數(shù)字簽名、 數(shù)字證書和其他技術(shù)來驗證軟件和數(shù)據(jù)的完整性。當(dāng)然，帶來的新挑戰(zhàn)是如何有效管 理數(shù)字證書的有效性。

◆車輛的可用性防護：車輛必須保護其軟件和數(shù)據(jù)的可用性，以確保它們不受到拒絕服 務(wù)攻擊或其他形式的惡意攻擊。車輛必須使用安全的網(wǎng)絡(luò)協(xié)議和硬件來防止此類攻擊。

◆安全的軟件更新：車輛軟件必須能夠安全更新，以免受已知漏洞攻擊。安全更新必須 能夠安全下載和驗證，以避免惡意軟件注入。

◆安全的系統(tǒng)啟動：車輛軟件必須通過安全啟動過程來確保啟動的軟件沒有被篡改或入侵。安全啟動可以使用數(shù)字簽名和硬件保護來實現(xiàn)。

◆安全事件預(yù)警：車輛軟件需要通過內(nèi)嵌的安全探針實時監(jiān)控車輛安全漏洞，并能夠遠程上報至 VSOC 平臺，實現(xiàn)智能化的預(yù)警及安全事件反饋。

在工程落地實踐中，網(wǎng)絡(luò)安全與功能安全會出現(xiàn)交叉，需要負責(zé)網(wǎng)絡(luò)安全與負責(zé)功能安全的工程師密切配合。當(dāng)然，我們也必須意識到，網(wǎng)絡(luò)安全是無止境的。過度的安全防控會導(dǎo)致汽車性能和使用便捷性下降。因此，網(wǎng)絡(luò)安全做什么，如何做，以及如何實現(xiàn)網(wǎng)絡(luò)安全與整車性能的均衡，是汽車工程實踐的核心工作。