上海磐時 PANSHI

“磐時，做汽車企業的安全智庫”

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

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

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

以下內容節選自《一本書讀懂智能汽車安全》：

無論是功能安全還是網絡安全相關的標準，都對軟件提出了諸多需求。那么，這些需求背后的邏輯是什么?為什么會有這些需求?回歸本質看安全標準背后的東西，我們才能更好地理解需求，更好地落實需求。本節將嘗試從原理出發，為大家闡述什么是軟件安全。

01.

軟件安全的含義

1.1 經典軟件事故

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

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

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

最終結論是：

◆豐田汽車的電子節氣門控制系統（ETCS）源代碼不合理。

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

◆代碼質量指標預測存在其他錯誤。

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

◆豐田汽車 ETCS 的不當行為是意外加速的原因。

在技術調查中，ECM軟件構成了調查的核心。關于堆溢出方面，豐田聲稱僅使用了分配的堆棧空間的 41%，但專家的調查顯示，實際使用的堆棧空間高達 94%。除此之外，在代碼中還發現了堆棧終止、MISRAC規則違反遞歸等問題，并且 CPU 沒有結合內存保護來防止堆棧溢出。

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

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

（2）Case2：網絡安全事故

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

1) Tesla 汽車車聯網系統攻擊案例分析

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

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

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

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

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

2) 語音控制系統破解案例

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

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

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

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

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

軟件安全是軟件開發和運行過程中的一個重要問題，它涉及網絡安全、功能安全和性能 安全等多個方面。

隨著軟件性召回事件的日益增多，這一趨勢凸顯了在軟件開發過程中安全性問題的重要性。這需要考慮功能安全，確保車輛關鍵系統的可靠性和穩定性，也需要考慮網絡安全，防止潛在的遠程攻擊和數據泄露，另外也要考慮汽車系統在規定的條件下和規定的時間內，完成既定功能的能力（即性能安全）。

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

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

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

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

02.

影響軟件安全的因素

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

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

對于軟件自身失效，一般可以歸為功能安全中的“軟件系統性失效”以及預期功能安全 中的“算法性能局限”。此部分內容是本章的關注點。

對于惡意入侵，一般可以歸為網絡安全的軟件威脅。此部分內容是本章的關注點。

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

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

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

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

3）編碼錯誤：編碼錯誤是軟件系統性失效的另一個常見來源。編碼時的疏忽或者錯誤的 代碼邏輯，導致軟件不能正常運行或者出現異常。

4）軟件測試不充分：軟件測試不充分是軟件系統性失效的另一個重要因素。如果軟件測試不夠嚴格，漏洞和錯誤可能不被發現，導致軟件系統性失效問題出現。

5）軟件算法能力不足：預期功能安全會引入機器學習技術問題。機器學習因算法能力不足或訓練數據質量問題會引發軟件系統性失效，例如未選擇最合適的算法、樣本特征選擇不當或硬件資源的限制導致的算法性能局限。訓練數據的質量問題通常源于數據集的不完整性 或數據標記的不準確性。

2.2 常見的軟件威脅及分類

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

（1）設計階段的軟件威脅及漏洞

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

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

示例：

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

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

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

示例：

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

在未授權的情況下修改系統的關鍵配置文件、用戶數據等。這種威脅及漏洞是由于缺少訪問檢查、沒有進行完整性檢查等。

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

示例：

用戶惡意刪除系統中的敏感文件，或攻擊者頻繁使用用戶賬號登錄的行為。這種威脅及漏洞是由于缺少對用戶登錄行為的有效審計，或對異常登錄狀態的日志。

4）Information Disclosure。這種威脅主要指泄露用戶的敏感信息或關鍵業務信息給非授權用戶。用戶能夠獲得未被授予訪問權限的數據，以及攻擊者能夠在網絡傳輸過程中獲取數據等行為，都屬于信息泄露威脅。

示例：

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

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

示例：

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

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

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

示例：

在未經授權用戶同意的情況下運行可執行文件來實現攻擊。

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

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

1）越界寫入。越界寫入即緩沖區溢出，指當應用程序在預期輸入緩沖區的邊界之外寫入數據時出現這種安全漏洞。當應用程序執行指針運算或更改索引以引用內存緩沖區之外的位置時，也可能導致該弱點，通常會導致意外執行非預期的代碼、程序崩潰或數據損壞。

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

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

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

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

03.

功能安全軟件的核心要求

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

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

（1）需求分析

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

（2）設計過程

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

（3）測試流程

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

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

3.2 常見的軟件威脅及分類

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

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

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

安全論證方法論總體思想見圖 6-24。簡而言之，安全案例的論證需要做到“有理有據”。“理”指的是要有道理，采用的標準、原理依據、必要的假設等；“據”指的是有證據，用真實、具體的證據證明安全目標。

GSN 相關的語法及語義如表 6-3 所示。

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

04.

網絡安全對軟件的核心要求

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

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

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

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

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

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

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

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

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