汽車(chē)網(wǎng)絡(luò)安全方案需求分析

一束光線 2024-09-02 發(fā)布于浙江

展開(kāi)全文

1.安全啟動(dòng)

2.安全升級(jí)

3.安全存儲(chǔ)

4.安全通信

5.安全調(diào)試

6.安全診斷

7.小結(jié)

廢話不多說(shuō)，目前識(shí)別到的關(guān)于汽車(chē)ECU的網(wǎng)絡(luò)安全方案需求如下：

—

安全啟動(dòng)

對(duì)于MCU，安全啟動(dòng)主要是以安全島BootROM為信任根，在MCU啟動(dòng)后，用戶程序運(yùn)行前，硬件加密模塊采用逐級(jí)校驗(yàn)、并行校驗(yàn)或者混合校驗(yàn)的方式，對(duì)Flash中的用戶關(guān)鍵程序進(jìn)行數(shù)據(jù)完整性和真實(shí)性進(jìn)行校驗(yàn)，確認(rèn)程序沒(méi)有被篡改。
對(duì)于SOC，安全啟動(dòng)主要是同樣以安全島BootROM為信任根，通常采用逐級(jí)校驗(yàn)的方式對(duì)manifest中定義的image鏡像文件進(jìn)行校驗(yàn)。常見(jiàn)順序?yàn)锽ootROM -> SecureBL-> Application。BootROM用于驗(yàn)簽和解壓SecureBL程序，確保SecureBL是可信軟件后將其加載到RAM中進(jìn)行運(yùn)行；SeucreBL負(fù)責(zé)對(duì)存放在Flash中的App進(jìn)行解密、數(shù)據(jù)完整性和真實(shí)性的驗(yàn)證，確保沒(méi)有被篡改后，從Flash拷貝至RAM中運(yùn)行，或者直接在Flash運(yùn)行。

—

安全升級(jí)

隨著汽車(chē)智能網(wǎng)聯(lián)的迅猛發(fā)展，汽車(chē)升級(jí)技術(shù)引入OTA(Over-the-Air Technology)的方式。

通常意義下，汽車(chē)OTA分為SOTA和FOTA兩種：

SOTA：Software over the Air，即對(duì)車(chē)載IVI運(yùn)行在Linux、IOS或Android系統(tǒng)上的應(yīng)用軟件升級(jí)，例如對(duì)導(dǎo)航地圖信息的升級(jí)、音樂(lè)播放軟件的升級(jí)等；
FOTA：Firmware over the Air，即對(duì)整車(chē)偏控制類(lèi)的ECU進(jìn)行固件升級(jí)，通常包括制動(dòng)系統(tǒng)、動(dòng)力系統(tǒng)等。

OTA升級(jí)的抽象模型如下：

T-Box(或者帶有T-Box功能的座艙域)接收到來(lái)自云端的升級(jí)包后，對(duì)升級(jí)包進(jìn)行驗(yàn)簽解密，完成數(shù)據(jù)包的拆分，同時(shí)作為OTA Master對(duì)車(chē)內(nèi)所有ECU進(jìn)行差分升級(jí)。

除OTA之外，線下4S店或工廠通過(guò)OBD對(duì)特定ECU進(jìn)行升級(jí)的方式也需要進(jìn)行數(shù)據(jù)的真實(shí)性和完整性的校驗(yàn)。

綜上，為保證上述兩種升級(jí)包的發(fā)布來(lái)源有效、數(shù)據(jù)完整不被篡改、升級(jí)內(nèi)容不被惡意截獲，一方面需要為升級(jí)包進(jìn)行簽名，保證數(shù)據(jù)來(lái)源可靠，數(shù)據(jù)完整沒(méi)有被篡改；另一方面還需要對(duì)升級(jí)包進(jìn)行加（OBD方式除外），傳輸數(shù)據(jù)過(guò)程通過(guò)密文傳輸，從而降低軟件更新時(shí)數(shù)據(jù)暴露的風(fēng)險(xiǎn)。

—

安全存儲(chǔ)

安全存儲(chǔ)通常是兩種方式實(shí)現(xiàn)。

Flash某些Sector通過(guò)設(shè)置訪問(wèn)權(quán)限，從而防止非法訪問(wèn)或篡改；
OTP:eFuse，只能被燒寫(xiě)一次。

—

安全通信

安全通信分為車(chē)內(nèi)網(wǎng)絡(luò)通訊和車(chē)云網(wǎng)絡(luò)通訊。

車(chē)內(nèi)網(wǎng)絡(luò)通訊，目前常見(jiàn)的是CAN通信，以明文的方式在整車(chē)內(nèi)部進(jìn)行交互，攻擊者可隨意偽造報(bào)文對(duì)車(chē)輛控制器特別是動(dòng)力、制動(dòng)系統(tǒng)進(jìn)行控制。因此，需要在關(guān)鍵報(bào)文上做PDU級(jí)別的身份驗(yàn)證機(jī)制，以防止數(shù)據(jù)被篡改或是被重放攻擊。常見(jiàn)的是對(duì)CAN使用SecOC模塊，對(duì)以太幀使用MACsec模塊等。
MACsec模塊
SecOC
車(chē)云網(wǎng)絡(luò)通訊安全主要是SLS(Secure Socket Layer)/TLS(Transport Layer Security)進(jìn)行保護(hù)。

—

安全調(diào)試

安全調(diào)試通常是指產(chǎn)品下線后對(duì)MCU進(jìn)行片上debug，一般使用基于挑戰(zhàn)\響應(yīng)的身份驗(yàn)證機(jī)制來(lái)限制調(diào)試器訪問(wèn)。只有授權(quán)的調(diào)試設(shè)備（具有正確響應(yīng)的設(shè)備）才能訪問(wèn)調(diào)試端口

在生產(chǎn)或者下線階段，必須要禁用或者鎖定相關(guān)的調(diào)試接口，禁用意味著無(wú)法與硬件調(diào)試接口建立連接，鎖定意味著硬件調(diào)試接口受到保護(hù)，只能根據(jù)安全調(diào)試解鎖來(lái)訪問(wèn)。

以某中央網(wǎng)關(guān)芯片的安全調(diào)試為例，其挑戰(zhàn)-響應(yīng)機(jī)制如下：

—

安全診斷

車(chē)載診斷時(shí)，讀取特定內(nèi)存位置、執(zhí)行特定例程、下載數(shù)據(jù)等服務(wù)時(shí)需要進(jìn)行身份認(rèn)證；下載數(shù)據(jù)服務(wù)即上述提到的基于UDS安全升級(jí)，需要對(duì)數(shù)據(jù)或者程序進(jìn)行身份認(rèn)證。讀取特定內(nèi)存位置的服務(wù)也需要進(jìn)行身份認(rèn)證，以防數(shù)據(jù)通過(guò)OBD口泄露。

安全診斷就是是通過(guò)某種認(rèn)證算法來(lái)確認(rèn)Client的身份，并決定Client端是否被允許訪問(wèn)?？梢酝ㄟ^(guò)對(duì)隨機(jī)數(shù)種子生成的非對(duì)稱(chēng)簽名進(jìn)行驗(yàn)證或者通過(guò)基于對(duì)稱(chēng)加密算法的消息校驗(yàn)碼來(lái)驗(yàn)證其身份。

ISO 14229-2020版本就提出了0x29服務(wù)(Authentication Service)，如下：

具體步驟如下：

客戶端(通常是診斷儀)發(fā)送證書(shū)至服務(wù)器，證書(shū)中一般包含客戶端的公鑰。對(duì)于支持安全診斷通信的客戶端和服務(wù)器，在認(rèn)證過(guò)程中同步使用Diffie-Hellman算法生成密鑰
服務(wù)器接著確認(rèn)證書(shū)的有效性，驗(yàn)證客戶端是否合法；若不合法則停止認(rèn)證流程，返回否定響應(yīng)，合法則繼續(xù)認(rèn)證流程
服務(wù)器繼續(xù)對(duì)證書(shū)發(fā)起挑戰(zhàn)，請(qǐng)求客戶端對(duì)所發(fā)證書(shū)的所有權(quán)證明，通常挑戰(zhàn)中包含認(rèn)證所需隨機(jī)數(shù)
客戶端接收到挑戰(zhàn)信息后使用私鑰對(duì)接收到的隨機(jī)數(shù)進(jìn)行計(jì)算得到簽名，放入響應(yīng)消息中發(fā)給服務(wù)器
服務(wù)器使用客戶端的公鑰解密并驗(yàn)證應(yīng)答消息中的簽名信息，與挑戰(zhàn)消息比較，向客戶端回復(fù)認(rèn)證結(jié)果

—

小結(jié)

本文主要是在梳理當(dāng)前項(xiàng)目security方案的需求時(shí)，順便整合了下車(chē)-管-端的需求分析，雖然我們用不到這么多需求。這里分享給大家。

本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶發(fā)布，不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買(mǎi)等信息，謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊一鍵舉報(bào)。

轉(zhuǎn)藏 分享

QQ空間 QQ好友新浪微博微信

獻(xiàn)花（0） +1

來(lái)自：一束光線 > 《信息安全》

舉報(bào)/認(rèn)領(lǐng)