闡述汽車OTA技術(shù)的安全風(fēng)險

隨著汽車軟件升級逐步在智能網(wǎng)聯(lián)汽車產(chǎn)品中廣泛應(yīng)用，覆蓋研發(fā)、生產(chǎn)、售后等多個環(huán)節(jié)，對企業(yè)的技術(shù)水平和管理能力均提出新的要求。若生產(chǎn)企業(yè) OTA 管理不當(dāng)、OTA 技術(shù)不成熟，會加劇功能實現(xiàn)的可靠性風(fēng)險，使升級后的系統(tǒng)將車輛與駕駛?cè)吮┞对谖粗奈ｋU中。本文首先闡述車聯(lián)網(wǎng)安全現(xiàn)狀，之后結(jié)合 OTA 風(fēng)險評估流程對 OTA 帶來的網(wǎng)絡(luò)安全、數(shù)據(jù)安全和功能安全風(fēng)險進行分析，提醒企業(yè)規(guī)避應(yīng)用OTA技術(shù)中面臨的各種安全風(fēng)險。

一、車聯(lián)網(wǎng)安全形勢分析

伴隨智能化、網(wǎng)聯(lián)化的不斷推進，車輛開放連接逐漸增多，“車、路、云、網(wǎng)”數(shù)據(jù)交互日益頻繁，車聯(lián)網(wǎng)領(lǐng)域的安全風(fēng)險邊界逐漸延伸。車聯(lián)網(wǎng)信息安全風(fēng)險主要集中在車端、平臺、通信、數(shù)據(jù)等方面。

（1）車端安全風(fēng)險隱患凸顯

一是車載軟硬件存在安全隱患。當(dāng)前，汽車電子電氣架構(gòu)正由分布式向域控集中式架構(gòu)、整車集中式架構(gòu)不斷發(fā)展，步入軟件定義汽車時代。車載智能網(wǎng)關(guān)、遠程信息處理控制單元（T-BOX）、電子控制單元（ECU）等車載聯(lián)網(wǎng)設(shè)備目前尚缺乏較高等級的安全校驗機制和安全防護能力，近年來陸續(xù)披露出一些安全漏洞隱患。

二是車載網(wǎng)絡(luò)存在安全隱患。CAN 、FlexRay 等車載網(wǎng)絡(luò)協(xié)議缺乏安全設(shè)計，車內(nèi)數(shù)據(jù)傳輸主要根據(jù)功能進行編碼，按照 ID 進行標(biāo)定和接收過濾，部分僅提供循環(huán)冗余校驗，缺乏重要數(shù)據(jù)加密、訪問認證等防護措施，導(dǎo)致車載網(wǎng)絡(luò)容易受到嗅探、竊取、偽造、篡改、重放等攻擊威脅，難以保障車載網(wǎng)絡(luò)的安全性。

（2）車聯(lián)網(wǎng)平臺服務(wù)面臨的攻擊威脅加劇

近年來，汽車遠程服務(wù)、在線升級（OTA）平臺、車輛調(diào)度平臺等業(yè)務(wù)服務(wù)快速發(fā)展，用戶的規(guī)模逐步擴大，日漸成為網(wǎng)絡(luò)攻擊的重要目標(biāo)。由于車端用戶可通過車聯(lián)網(wǎng)平臺進行信息交互、遠程操作，一旦遭受網(wǎng)絡(luò)攻擊控制，可被利用實施對車輛的遠程操控，造成嚴重后果。

（3）車聯(lián)網(wǎng)通信安全面臨挑戰(zhàn)

當(dāng)前，聯(lián)網(wǎng)車輛數(shù)量和通信需求不斷增長。在“車-云”通信場景下，網(wǎng)絡(luò)隔離不到位、通信協(xié)議存在漏洞隱患、訪問接入缺乏安全認證等問題突出?！败?設(shè)備”通信場景下，受限于設(shè)備性能等因素，通信安全認證機制尚不完善，存在拒絕服務(wù)攻擊等漏洞隱患，可導(dǎo)致WiFi、藍牙、智能鑰匙失效[16]。

在OTA功能實現(xiàn)過程中，云端、車端、通信鏈路、升級包等關(guān)鍵環(huán)節(jié)均存在被攻擊和篡改等安全隱患。OTA網(wǎng)絡(luò)安全態(tài)勢分析如圖5-1所示。

圖5-1 OTA網(wǎng)絡(luò)安全態(tài)勢分析圖

二、OTA 風(fēng)險評估方法

基于網(wǎng)絡(luò)安全、數(shù)據(jù)安全及功能安全風(fēng)險評估理論基礎(chǔ)、現(xiàn)有的威脅分析以及實踐經(jīng)驗，結(jié)合汽車本身的復(fù)雜特性，可建立以資產(chǎn)為核心的汽車OTA 遠程升級安全風(fēng)險評估模型。

OTA 風(fēng)險評估方法具體參照 ISO 26262《道路車輛功能安全工程》、ISO/SAE21434《道路車輛網(wǎng)絡(luò)安全工程》、SAE J3061《信息物理汽車系統(tǒng)網(wǎng)絡(luò)安全指南》等標(biāo)準(zhǔn)，主要評估對象包括 OTA 相關(guān)項、組件及漏洞。在相關(guān)標(biāo)準(zhǔn)中定義有 STRIDE、攻擊樹、EVITA、HEAVENS、OCTAVE、PASTA 等威脅分析和風(fēng)險評估方法論，對這些方法論的對比和融合后歸納如表5-1所示。

表5-1 OTA 風(fēng)險評估歸納表

2.1 OTA 相關(guān)項及組件風(fēng)險評估

以威脅分析及風(fēng)險評估分析方法TARA 為例， 建立OTA 風(fēng)險評估流程，如

圖5-2所示。

圖5-2 TARA 風(fēng)險評估流程

2.1.1 安全相關(guān)性判定

在進行 TARA 分析前，需要對相關(guān)項的功能及其運行環(huán)境進行定義，以充分識別出資產(chǎn)（包括內(nèi)部實體、外部實體、存儲數(shù)據(jù)、數(shù)據(jù)流等），實體、數(shù)據(jù)被破壞后帶來的危害場景等。相關(guān)項定義（Item Definition）的目的是了解分析對象，了解其業(yè)務(wù)、功能、流程、邊界，OTA 相關(guān)項邊界定義如圖5-3所示。

圖5-3 OTA 相關(guān)項邊界定義示意圖

數(shù)據(jù)流圖（Data Flow Diagram）需把該相關(guān)項中每個功能用到的數(shù)據(jù)標(biāo)識出來，從哪個實體產(chǎn)生，經(jīng)過哪個實體處理，經(jīng)過哪個實體轉(zhuǎn)發(fā)等。數(shù)據(jù)流圖要素的基本符號如圖5-4所示。

圖5-4 數(shù)據(jù)流圖要素的基本符號

以 OTA 業(yè)務(wù)為例，參考數(shù)據(jù)流圖如圖5-5所示。

圖5-5 OTA 業(yè)務(wù)參考數(shù)據(jù)流圖

2.1.2資產(chǎn)識別

資產(chǎn)識別（Asset Identification），是識別車輛在使用的過程中需要被保護不受網(wǎng)絡(luò)攻擊的信息，包括了通訊數(shù)據(jù)、用戶隱私數(shù)據(jù)、ECU 固件、算法等各種類型的信息。資產(chǎn)定義的目的是識別出這些資產(chǎn)，確定每項資產(chǎn)的網(wǎng)絡(luò)安全屬性,從而分析出潛在的損害場景。資產(chǎn)識別過程表如表5-2所示。

表5-2資產(chǎn)識別過程表

資產(chǎn)的網(wǎng)絡(luò)安全屬性通常分為機密性(Confidentiality)、完整性(Integrity)、可用性(Availability)、真實性(Authenticity)、授權(quán)性(Authorization)、抗抵賴性(Non-repudiation)、新鮮性(Freshness)、隱私性（Privacy）。每一個資產(chǎn)都具有相應(yīng)的網(wǎng)絡(luò)安全屬性如表5-3所示。

經(jīng)以上分析，OTA 過程中所涉及信息安全資產(chǎn)包括：

零部件資產(chǎn)：T-BOX 、CGW、目標(biāo) ECU 及車載總線；

數(shù)據(jù)資產(chǎn)：升級包、升級日志和升級指令等信息；

軟件資產(chǎn)：零部件上所運行系統(tǒng)和升級管理程序。

表5-3 OTA 過程涉及的資產(chǎn)和損害情況（示例）

2.1.3威脅分析

威脅場景定義是TARA 分析的重要環(huán)節(jié)，TARA 最終輸出的風(fēng)險等級和風(fēng)險處置決策的對象就是威脅場景。威脅分析過程如表5-4所示。

表5-4 威脅分析過程表（示例）

威脅場景應(yīng)通過目標(biāo)資產(chǎn)、相關(guān)網(wǎng)絡(luò)安全資產(chǎn)受到的威脅，導(dǎo)致網(wǎng)絡(luò)安全財產(chǎn)受損的原因推導(dǎo)得出。推導(dǎo)方法包括 EVITA, TVRA, PASTA, STRIDE 等。以O(shè)TA過程中數(shù)據(jù)資產(chǎn)升級包的完整性、機密性、可用性被破壞為例，威脅場景識別如表5-5所示。

表5-5 威脅場景識別（示例）

攻擊路徑可基于自上而下的攻擊樹；自下而上的告警日志、以往安全事件確定的漏洞等方式推導(dǎo)得出。對于每一個攻擊路徑可基于多維度的攻擊潛力難度系數(shù)得出攻擊潛力值，以及攻擊可行性等級，如表5-6所示。

表5-6 攻擊可行性評估（示例）

影響等級可分為嚴重（Server）、主要（Major）、中等（Moderate）、可忽略（Negligible）四個等級，并通過危害對功能安全（Safety）、財務(wù)（Financial）、可操作性（Operational）、隱私（Privacy）等維度的影響評估來確定危害的綜合影響等級和影響值，如表5-7所示。在實際的影響等級評估中，也可以采用 HEAVENS 方法中提出的定量評估方法，其中安全和財產(chǎn)的影響水平具有較高的權(quán)重（0~1000），操作和隱私方面的損害影響相對較低，權(quán)重也較低（0~100）。

表5-7 OTA 影響等級分析（示例）

2.1.4確認風(fēng)險值

通過結(jié)合安全風(fēng)險的業(yè)務(wù)影響評級和攻擊可行性評級，依據(jù)風(fēng)險評估矩陣評 定風(fēng)險等級，確定安全風(fēng)險的處置優(yōu)先級，為后續(xù)的韌性處置方案設(shè)定評級目標(biāo)。風(fēng)險值確認過程參見表 5-8。

表5-8 風(fēng)險值確認過程表

根據(jù)表5-9風(fēng)險評估矩陣識別風(fēng)險值 R。

表5-9 風(fēng)險評估矩陣

根據(jù)表5-10進行風(fēng)險值分析。

表5-10 風(fēng)險值分析（示例）

2.1.5風(fēng)險處置

根據(jù)風(fēng)險處置方案思維導(dǎo)圖，借助風(fēng)險處置庫，設(shè)計風(fēng)險處置的韌性方案。在風(fēng)險處置方案設(shè)計完成后，通過再次評估，判斷參與風(fēng)險是否降至風(fēng)險等級目標(biāo)。若殘余風(fēng)險仍未達到風(fēng)險等級目標(biāo)，需根據(jù)業(yè)務(wù)的實際情況，考慮是否接受殘余風(fēng)險或進一步增強處置措施形成最終風(fēng)險處置方案。風(fēng)險處置活動參見表5-11、表5-12。

表5-11 風(fēng)險處置過程表

表5-12 風(fēng)險處置活動（示例）

2.1.6處置跟蹤驗證

對上述修復(fù)的結(jié)果進行測試驗證，由相關(guān)技術(shù)人員或第三方根據(jù)處置方案進行測試驗證。

2.1.7殘余風(fēng)險評估

殘余風(fēng)險主要方式產(chǎn)生如表5-13所示。針對殘余風(fēng)險應(yīng)重新進行特定范圍的風(fēng)險評估，并識別是否達到可接受風(fēng)險水平。處于不可接受范圍的殘余風(fēng)險須進一步增加相應(yīng)的管理和控制措施，在所有的殘余風(fēng)險處于可接受范圍的水平后，應(yīng)發(fā)布風(fēng)險聲明并加強日常網(wǎng)絡(luò)安全監(jiān)測。

表5-13 殘余風(fēng)險產(chǎn)生方式

2.1.8風(fēng)險閉環(huán)

梳理風(fēng)險評估流程文檔，為后續(xù)網(wǎng)絡(luò)安全日常運維或安全審計提供支持。

2.2 OTA 安全漏洞風(fēng)險評估

OTA 安全漏洞指硬件、軟件、協(xié)議的具體實現(xiàn)或系統(tǒng)安全策略上存在缺陷，從而使攻擊者能夠在未授權(quán)的情況下訪問或破壞系統(tǒng)。應(yīng)對安全漏洞進行識別、風(fēng)險評估、修復(fù)、測試驗證等操作以保證系統(tǒng)安全。以下提供了安全漏洞處置流程及技術(shù)方法，可用于針對某 OTA 業(yè)務(wù)場景所涉及零部件和環(huán)境進行漏掃，以得出具體漏洞信息。OTA 安全漏洞評估流程見圖5-6。

圖5-6 OTA安全漏洞風(fēng)險評估流程圖

2.2.1漏洞識別

漏洞識別方式：漏洞公告、漏洞掃描、滲透測試、白帽測試等；

漏洞類型識別：如 STIRDE 威脅模型中的仿冒、篡改、信息泄露等類型。

2.2.2風(fēng)險評估定級

Common Vulnerability Scoring System（CVSS）提供了一種方法來描述可利用性的主要特征，并生成分值反應(yīng)其嚴重程度，使得人們確定處理它們的優(yōu)先級[17]。

CVSS 評分方法如表5-14所示。

表5-14 CVSS 評分方法

CVSS 可利用性值與攻擊可行性的映射示例如表5-15所示。

表5-15 基于CVSS的攻擊可利用性映射表

2.2.3修復(fù)可行性評估

修復(fù)可行性評估首先需要根據(jù)上文風(fēng)險處置的方式初步篩選出漏洞的處置方式，針對具體的修復(fù)方式（如補丁升級、版本升級、更換組件等）進行測試驗證，評估對 OTA 系統(tǒng)是否造成影響或引入新的高危及以上風(fēng)險。

2.2.4測試驗證

對已經(jīng)修復(fù)的漏洞進行測試驗證，如重新漏洞掃描、滲透測試、人工復(fù)現(xiàn)等

進行驗證。

2.2.5閉環(huán)

在測試驗證階段確認漏洞修復(fù)有效后，對相關(guān)風(fēng)險評估和測試驗證過程文檔進行歸檔保存，最后可流程閉環(huán)。

三、OTA 網(wǎng)絡(luò)安全風(fēng)險分析

根據(jù) OTA威脅分析和風(fēng)險評估流程，OTA面臨的網(wǎng)絡(luò)安全風(fēng)險包括 OTA平臺安全風(fēng)險、通信安全風(fēng)險、車端安全風(fēng)險和升級包安全風(fēng)險。

3.1 OTA 平臺安全風(fēng)險

OTA 平臺安全風(fēng)險主要包括云平臺自身安全、第三方應(yīng)用安全兩個主要方面。

（1）云平臺自身安全風(fēng)險

OTA 平臺大多數(shù)部署在云端服務(wù)器中，會面臨傳統(tǒng)云平臺的所有安全威脅，包括網(wǎng)絡(luò)威脅、主機威脅、應(yīng)用威脅、數(shù)據(jù)威脅等。攻擊者利用 Web 漏洞、數(shù)據(jù)庫漏洞、接口 API 安全注入漏洞等手段發(fā)起 DDoS 攻擊、MITC 攻擊、跨云攻擊、編排攻擊、加密劫持等，可能導(dǎo)致 AccessKey 泄露風(fēng)險、用戶敏感信息泄露、推送的升級包被篡改、升級策略更改等風(fēng)險。

（2）第三方應(yīng)用安全風(fēng)險

隨著車載平臺的發(fā)展，第三方應(yīng)用也會隨之增長，第三方應(yīng)用的 OTA 也將會成為一個很重要的部分。升級后的第三方產(chǎn)品可能存在系統(tǒng)兼容性或者系統(tǒng)漏洞，甚至嚴重的 BUG，所以 OTA 平臺也需要考慮到第三方應(yīng)用的升級流程與規(guī)范要求。

3.2 通信安全風(fēng)險

OTA 通信安全風(fēng)險主要包括身份認證、傳輸加密、中間人攻擊三個主要方面。

（1）身份認證安全風(fēng)險

身份認證風(fēng)險體現(xiàn)在通信過程中未對通信對象進行有效身份驗證，攻擊者通過使用基站偽造、身份偽造、動態(tài)劫持等方式冒充合法參與者，參與車云通信，非法監(jiān)聽通信信息。例如，OTA 云服務(wù)推送軟件升級包到車端的過程，若采用弱認證方式或明文傳輸，容易遭受中間人攻擊、竊聽攻擊等。終端下載升級包的傳輸流程中，如果終端在升級流程中同時缺少驗證機制，那么被篡改的升級包即可順利完成升級流程，達到篡改系統(tǒng)，植入后門等惡意程序的目的。攻擊者還可能對升級包進行解包分析、篡改升級包信息等，或者獲取一些可利用的信息，如漏洞補丁等，可能導(dǎo)致關(guān)鍵信息泄露、代碼業(yè)務(wù)邏輯泄露等風(fēng)險。

（2）傳輸過程安全風(fēng)險

傳輸風(fēng)險主要發(fā)生在車輛通信信息在未進行加密、加密強度較弱、密鑰信息暴露等情況下，導(dǎo)致容易遭受惡意攻擊，造成通信信息的泄漏、非法篡改和破壞。例如，云端與車端的通信過程若采用不安全的通信協(xié)議或通信過程不采用認證機制、明文通信等，容易遭受中間人攻擊、竊聽攻擊、重放攻擊、DoS 攻擊等，可能導(dǎo)致車端升級信息錯誤、敏感信息泄露、拒絕服務(wù)等風(fēng)險。

（3）中間人攻擊安全風(fēng)險

中間人攻擊體現(xiàn)在協(xié)議鏈路層通信未進行加密，攻擊者可以通過抓取鏈路層標(biāo)識實現(xiàn)會話劫持，攻擊者可以基于中間人偽造協(xié)議而實施對升級包的篡改，竊取等。此外，在自動駕駛情況下，汽車使用了篡改后的升級包，攻擊者通過利用升級包中預(yù)植的木馬，干擾車輛正?？刂疲瑤斫煌ò踩L(fēng)險。

3.3 車端安全風(fēng)險

車端安全風(fēng)險主要包括版本回退、車端升級程序被破解繞過、拒絕更新三個主要方面。此外，車端系統(tǒng)出現(xiàn)公開漏洞，若不及時進行修復(fù)，可能導(dǎo)致黑客利用漏洞進行攻擊，造成車輛、財產(chǎn)乃至人身安全風(fēng)險。

（1）版本回退風(fēng)險

一般場景下的升級都是由低版本升級到高版本系統(tǒng)，但如果車端升級未對升級包版本進行判斷，攻擊者可以利用此漏洞，使用存在已知安全漏洞的低版本系統(tǒng)覆蓋現(xiàn)有的系統(tǒng)，將導(dǎo)致車輛面臨安全風(fēng)險。

（2）車端升級程序被破解繞過

按照OTA和安全相關(guān)的國際和國家標(biāo)準(zhǔn)要求，升級過程都需要在車輛端對升級包進行加密和簽名驗證等一系列驗證環(huán)節(jié)，經(jīng)過驗證的升級包才能進行正常的升級流程。如果驗證的算法過于簡單或者驗證流程存在漏洞，攻擊者可以利用這些漏洞構(gòu)造有效的升級包或者繞過驗證流程，在部件上加載運行惡意篡改過的固件，對車輛進行進一步的攻擊或者控制等惡意行為。

（3）拒絕更新風(fēng)險

在車輛升級過程中，攻擊者可能會阻止車輛修復(fù)功能漏洞，通過控制車輛拒絕訪問更新而無法解決車輛潛在漏洞或其他問題。常見的攻擊方式包括：通過阻斷或攔截外部或內(nèi)部網(wǎng)絡(luò)通信流量，阻止車端 ECU 接收任何更新。

3.4 升級包安全風(fēng)險

涉及升級包的應(yīng)用場景分為升級包車云傳輸、升級包車內(nèi)傳輸、升級包安裝。三類應(yīng)用場景中，升級包安全風(fēng)險主要包括升級包信息泄露、升級包信息篡改、升級包信息偽造三個主要方面。

（1）OTA 升級包信息泄露風(fēng)險

OTA 升級包的機密性破壞，攻擊者可輕易捕獲并分析通信數(shù)據(jù)，導(dǎo)致升級包信息泄露風(fēng)險。

（2）OTA 升級包信息篡改風(fēng)險

OTA 升級包的完整性破壞，攻擊者獲取OTA 通信數(shù)據(jù)并進行篡改，造成升級包被篡改或升級指令錯誤。

（3）OTA 升級包信息偽造風(fēng)險

車云之間失去身份的真實性，攻擊者偽造非法信息進入平臺或車輛，導(dǎo)致下發(fā)惡意升級指令或上傳虛假信息等。

（4）OTA 升級包代碼安全風(fēng)險

未對升級包進行代碼檢測，以及對代碼所應(yīng)用的第三方開源代碼進行溯源和分析，導(dǎo)致升級包中存在缺陷（bug）。

四、OTA 數(shù)據(jù)安全風(fēng)險分析

汽車OTA帶來對已售車型大量應(yīng)用服務(wù)的數(shù)據(jù)井噴，還面臨在保證用戶個人信息安全的前提下，企業(yè)如何實施數(shù)據(jù)利用共享，OTA 相關(guān)數(shù)據(jù)如何跨境流通等問題。這些安全風(fēng)險都對企業(yè)的合規(guī)管理與創(chuàng)新發(fā)展提出新的要求。

4.1 用戶隱私信息泄漏風(fēng)險

汽車遠程升級整個過程中涉及到云端服務(wù)器安全、車端安全、車云通信安全，也關(guān)系到生產(chǎn)者、用戶及汽車軟件供應(yīng)商等其他主體之間的數(shù)據(jù)收集、數(shù)據(jù)傳輸?shù)榷鄠€處理環(huán)節(jié)。在這些過程之中如果存在網(wǎng)絡(luò)攻擊風(fēng)險，可能導(dǎo)致 OTA 系統(tǒng)遭受破壞，不法分子可以通過 OTA 系統(tǒng)窺探到用戶的隱私信息，如車輛位置、行車路線等行為習(xí)慣。同時，第三方應(yīng)用平臺可能存在非法獲取其他應(yīng)用和車載端數(shù)據(jù)的風(fēng)險。

4.2 數(shù)據(jù)出境合規(guī)風(fēng)險

隨著系列政策文件均提出汽車產(chǎn)生的個人信息和重要數(shù)據(jù)出境管理要求，智 能網(wǎng)聯(lián)汽車作為重點監(jiān)管對象，產(chǎn)生的大量數(shù)據(jù)為數(shù)據(jù)跨境管理帶來新的風(fēng)險。對跨國企業(yè)而言，涉及技術(shù)研發(fā)的數(shù)據(jù)免不了出境或遠程跨國訪問，若分布于各國的數(shù)據(jù)只能本地存儲而無法出境交互，將動搖跨國車企一直以來采取的開發(fā)、維護、集中化管理模式，導(dǎo)致車企需重新對一國市場進行單獨資源調(diào)配，建立和總部一致的技術(shù)團隊，成本不可估量[18]。因此在車輛售出后， 面對遠程升級需要的軟件版本號、升級包名稱、升級時間等決定功能實現(xiàn)的數(shù)據(jù)如何合法地出境流動仍然存在管理規(guī)定不明晰帶來的風(fēng)險。

五、OTA 功能安全風(fēng)險分析

當(dāng)涉及車輛核心功能如動力、制動和電池管理系統(tǒng)等模塊的遠程升級時，可能對車輛的功能安全帶來新的挑戰(zhàn)，升級后的系統(tǒng)將車輛與駕駛?cè)吮┞对谖粗奈ｋU中。OTA 功能安全風(fēng)險可舉例為：

5.1 車端升級條件判斷不當(dāng)導(dǎo)致的安全風(fēng)險

車輛遠程升級是一個比較長的過程，而且升級過程中車輛大部分功能可能無法正常使用，所以一般都要求車輛在P檔、電池電量充足等一定條件下才能進行。如果車輛對于升級條件的判斷存在問題，可能導(dǎo)致在非預(yù)想的情況下觸發(fā)升級事件，對車輛和車內(nèi)人員人身安全造成威脅。

5.2 車端升級失敗導(dǎo)致的車輛功能不可用

在車輛升級過程中可能出現(xiàn)斷電等異常情況導(dǎo)致升級失敗的情況，如果沒有對升級失敗的情況進行妥善的容災(zāi)處理，可能導(dǎo)致車輛無法啟動，甚至零部件損壞等嚴重事件。

5.3 OTA 升級軟件自身缺陷導(dǎo)致的風(fēng)險

軟件更新后未進行充分驗證和測試就直接部署到車輛上，軟件自身的缺陷可能會使軟件運行出現(xiàn)意外行為，導(dǎo)致系統(tǒng)崩潰、觸發(fā)車輛失控等安全事故。

5.4 軟件不兼容風(fēng)險

在車輛升級過程中，升級軟件可能引入新的功能和接口，如果車輛硬件不支

持或不兼容，可能導(dǎo)致升級后系統(tǒng)無法正常工作，造成行車安全隱患。

為應(yīng)對上述 OTA 安全風(fēng)險，總體來說，在云平臺端可采用證書，簽名和加密機制，負責(zé)為 OTA 服務(wù)平臺提供安全服務(wù)，包括密鑰證書管理服務(wù)，數(shù)據(jù)加密服務(wù)，數(shù)字簽名服務(wù)等，保證升級包不會隨意被制作和發(fā)布，升級包的內(nèi)容不會被惡意獲取。在通信鏈路端，可通過可靠的物理鏈路和安全傳輸協(xié)議來保證網(wǎng)絡(luò)傳輸安全。在車端，可通過汽車的功能域隔離，劃分不同 ASIL 等級，通過冗余設(shè)計保證整車的功能可靠性；車輛終端 OTA 組件對升級包進行合法性驗證，適配安全升級流程，通過安全啟動來保證可信的軟件在 ECU 上加載啟動運行。

審核編輯：劉清