周奇才 王奕童 趙炯 熊肖磊

（1.同濟(jì)大學(xué)，上海 201804；2.同濟(jì)大學(xué)浙江學(xué)院，嘉興 314051）

主題詞：空中下載 安全通信 密鑰管理

1 前言

空中下載（Over-The-Air，OTA）是一種從遠(yuǎn)程服務(wù)器下載更新包的技術(shù)，利用此技術(shù)對(duì)互聯(lián)網(wǎng)汽車進(jìn)行升級(jí)已成為趨勢(shì)，但如果車輛在OTA過程中遭受網(wǎng)絡(luò)攻擊，則車內(nèi)電子控制單元（Electronic Control Unit，ECU）可能被破壞或控制，從而對(duì)用戶形成嚴(yán)重的安全威脅。

針對(duì)車輛安全下載升級(jí)的過程已有許多研究。Mahmud等[1]提出的一次性密鑰組通信方案實(shí)現(xiàn)過程繁瑣，而且無法防止針對(duì)特定目標(biāo)的持續(xù)性攻擊。Nilsson等[2-4]提出了基于Hash鏈認(rèn)證的安全硬件空中更新（Secure Firmware updates Over The Air，SFOTA）方案，并深入操作系統(tǒng)層面規(guī)劃?rùn)?quán)限管理和日志處理，但該方案缺少對(duì)目標(biāo)車輛的認(rèn)證過程和ECU密鑰管理方案。Steger等[5-6]提出了基于不同場(chǎng)景的組通信方案升級(jí)流程以及使用區(qū)塊鏈技術(shù)的軟件認(rèn)證流程，但增加了額外的基礎(chǔ)設(shè)施和計(jì)算開銷。Kuppusamy等[7]提出了車輛安全軟件升級(jí)框架Uptane，可以有效抵抗大部分類型的攻擊，并減少密鑰泄露產(chǎn)生的危害，但仍無法阻止竊聽攻擊和局部升級(jí)攻擊。

EVITA（E-safety Vehicle Intrusion Protected Applications）項(xiàng)目的移動(dòng)終端空中下載（Firmware Over-The-Air，F(xiàn)OTA）方案[8]可以基于可信診斷工具確保OTA過程安全。Mansor等分析了其不足[9]，并描述了一種利用移動(dòng)設(shè)備下載固件數(shù)據(jù)的方案[10]，但其前提條件是存在一個(gè)與車配對(duì)的可信移動(dòng)設(shè)備，使方案具有很大局限性，且如果移動(dòng)設(shè)備被惡意獲取、使用或破解，不僅會(huì)泄露使用預(yù)共享密鑰加密的固件包和ECU的解鎖密鑰，惡意用戶還可以利用移動(dòng)設(shè)備控制密鑰的內(nèi)容，實(shí)現(xiàn)選擇明文攻擊。

本文提出一個(gè)基于互聯(lián)網(wǎng)設(shè)備的OTA更新包的安全通信協(xié)議方案，可以在不安全的網(wǎng)絡(luò)及有風(fēng)險(xiǎn)的設(shè)備上實(shí)現(xiàn)安全通信，并參考Uptane軟件模式提出一個(gè)簡(jiǎn)單密鑰泄露保護(hù)方案。

2 系統(tǒng)模型

2.1 系統(tǒng)模型與前提條件

本文系統(tǒng)模型與EVITA項(xiàng)目的FOTA模型基本一致。車內(nèi)的每一個(gè)通信節(jié)點(diǎn)具有不同等級(jí)的硬件安全模塊（Hardware Security Modules，HSM）作為實(shí)現(xiàn)密碼學(xué)算法和機(jī)密存儲(chǔ)的安全模塊，HSM的定義和等級(jí)劃分依照EVITA項(xiàng)目定義。車輛中央通信單元（Central Communication Unit，CCU）是車內(nèi)會(huì)話中心，擁有全功能的HSM。CCU也作為一個(gè)密鑰管理（Key Master，KM）節(jié)點(diǎn)保存車內(nèi)ECU的公鑰或預(yù)備密鑰。車內(nèi)ECU根據(jù)功能需求擁有不同等級(jí)的HSM。車輛CCU與OEM服務(wù)器通過互聯(lián)網(wǎng)設(shè)備進(jìn)行連接，該設(shè)備可以是個(gè)人擁有的智能設(shè)備，也可以是主機(jī)廠或者供應(yīng)商提供的網(wǎng)絡(luò)終端，可以實(shí)現(xiàn)安全診斷、更新等傳統(tǒng)診斷工具（Diagnostic Tool，DT）所具有的功能。因?yàn)橹悄苁謾C(jī)具有較高的普及率、良好的運(yùn)算性能以及便利性，所以本文以典型的移動(dòng)設(shè)備（Mobile Device，MD）手機(jī)作為互聯(lián)網(wǎng)設(shè)備進(jìn)行相關(guān)分析，系統(tǒng)模型如圖1所示。

圖1 系統(tǒng)模型

系統(tǒng)的前提條件要求為：

a.OEM服務(wù)器：提供實(shí)現(xiàn)功能需求的APP；具有通過給定車輛信息（如VIN）獲得相關(guān)CCU公鑰、ECU密鑰的能力；提供升級(jí)數(shù)據(jù)包。

b.MD（手機(jī)）：獲取OEM提供的官方APP；連接目標(biāo)CCU；具有一定的性能以滿足運(yùn)算需求。

c.CCU：存儲(chǔ)正確的OEM公鑰；具有EVITA項(xiàng)目定義的功能要求（包括全HSM等）；搜集并提供當(dāng)前車內(nèi)升級(jí)所需要的相關(guān)信息；作為車內(nèi)KM擁有ECU的相關(guān)密鑰。

d.ECU：具有EVITA項(xiàng)目定義的相關(guān)功能要求（包括HSM、升級(jí)功能等）；提供升級(jí)需要的相關(guān)信息（如ID、型號(hào)、版本號(hào)、升級(jí)狀態(tài)等）。

e.手機(jī)APP：正確存儲(chǔ)OEM公鑰并可靈活替換；實(shí)現(xiàn)本文的通信協(xié)議和通用的密碼算法；實(shí)現(xiàn)針對(duì)汽車的其他通信功能以及診斷功能（可選）。

2.2 威脅模型

基于Delov-Yao的網(wǎng)絡(luò)攻擊模型，定義攻擊者的能力有：對(duì)OEM服務(wù)器到MD、MD到CCU、CCU到ECU之間的網(wǎng)絡(luò)通信過程進(jìn)行竊聽、攔截、修改、參與會(huì)話及偽裝成其他角色；入侵MD，得到通信協(xié)議的全部流程及OEM公鑰，甚至獲得MD私鑰以及全部存儲(chǔ)信息。

2.3 安全目標(biāo)

定義目標(biāo)為：在所有傳輸流程正確認(rèn)證完成后，確保ECU接受到的數(shù)據(jù)具有機(jī)密性、完整性、可用性、可認(rèn)證性和新鮮性。

3 協(xié)議框架描述

協(xié)議主要流程分為4個(gè)部分，依次為：安全通信握手，用來生成本次通信的所有臨時(shí)密鑰，以保證整體過程的通信安全；車輛信息反饋，通過CCU完成車輛信息傳輸，用以生成合適的OTA更新數(shù)據(jù)；數(shù)據(jù)下載請(qǐng)求，MD從OEM服務(wù)器獲得更新數(shù)據(jù)；升級(jí)數(shù)據(jù)包交付，MD將數(shù)據(jù)交付給CCU并轉(zhuǎn)交給ECU。部分?jǐn)?shù)據(jù)符號(hào)的定義如表1所示。

表1 符號(hào)定義與解釋

在2.1節(jié)的系統(tǒng)條件下，服務(wù)器將采用某種方式通知（或CCU定期查詢得知）ECU需要升級(jí)，并利用此協(xié)議進(jìn)行數(shù)據(jù)包交付。

3.1 安全通信握手過程

安全通信握手過程可以在OEM服務(wù)器、CCU和ECU之間秘密分享Km1，在OEM、CCU和MD之間秘密分享Km2。其中Km1通過某種算法（如帶固定填充的Hash算法等）生成會(huì)話密鑰Ks1和MAC密鑰Kc1，保證OEM對(duì)CCU和ECU的安全傳輸。Km2同樣生成密鑰Ks2和Kc2，用于OEM、MD、CCU的通信，起到保護(hù)會(huì)話機(jī)密性的作用。同時(shí)Km2還可以對(duì)APP的其他車輛診斷操作和通信信息進(jìn)行保護(hù)。

此過程具體流程如圖2所示?？紤]到從MD發(fā)起請(qǐng)求起到OEM與CCU數(shù)據(jù)交互結(jié)束至少需要5次通信，故在此基礎(chǔ)上增加2次密鑰確認(rèn)過程已經(jīng)接近最簡(jiǎn)。

圖2 安全通信握手流程

此流程可以保證發(fā)起請(qǐng)求和生成密鑰的實(shí)體都是可信的?；贠EM與CCU之間具有互相認(rèn)證的能力，OEM生成帶有隨機(jī)種子的簽名包以驗(yàn)證本次會(huì)話確實(shí)有可信的CCU參與。而CCU生成的所有主密鑰加密簽名數(shù)據(jù)包，保證了密鑰來源的合法且機(jī)密。對(duì)應(yīng)圖2，每次通信的數(shù)據(jù)構(gòu)成如下：

OEM服務(wù)器接到OTA請(qǐng)求后，返回包含附帶簽名的數(shù)據(jù)包package1。package1含有時(shí)間戳和隨機(jī)種子，用來特定此次會(huì)話。MD將該包轉(zhuǎn)交給CCU，CCU則可以驗(yàn)證此次會(huì)話是否有OEM服務(wù)器參與，隨后生成2個(gè)主密鑰Km1和Km2，配合OEM服務(wù)器隨機(jī)種子和車輛VIN一起封裝在用OEM公鑰加密的數(shù)據(jù)包package2內(nèi)。CCU同時(shí)將Km2用MD公鑰加密后與package2拼合在一起發(fā)送給MD。MD只能解析出Km2，并計(jì)算出相應(yīng)會(huì)話密鑰Ks2和MAC密鑰Kc2，之后MD將package2轉(zhuǎn)送給OEM服務(wù)器，OEM服務(wù)器驗(yàn)證完成后獲得2個(gè)主密鑰，之后驗(yàn)證密鑰是否分享成功。

這一系列步驟完成后，后續(xù)通信數(shù)據(jù)均使用此過程生成的Kc2進(jìn)行MAC加密，與原文拼接后使用Ks2對(duì)稱加密。當(dāng)傳輸敏感數(shù)據(jù)包時(shí)（如ECU解鎖密鑰），需利用Ks1和Kc1以同樣的方式對(duì)包先進(jìn)行加密，再嵌入整體消息并再次利用Kc2、Ks2進(jìn)行加密（加密結(jié)構(gòu)參見3.3節(jié)）。

3.2 車輛信息反饋過程

車輛信息反饋過程用來通知OEM服務(wù)器當(dāng)前車輛的軟件狀態(tài)。車輛的信息數(shù)據(jù)可以在平時(shí)車輛使用過程中由CCU備份，具體流程如圖3所示。

圖3 車輛信息反饋流程

此過程完成后，OEM服務(wù)器可以根據(jù)相應(yīng)的信息生成更新數(shù)據(jù)包。

3.3 數(shù)據(jù)下載請(qǐng)求過程

數(shù)據(jù)下載請(qǐng)求過程為MD從OEM服務(wù)器獲得ECU解鎖密鑰和升級(jí)文件的過程，如圖4所示。當(dāng)有多個(gè)ECU需要升級(jí)時(shí)，則可以采用打包傳輸?shù)姆绞?，通過CCU分別傳輸?shù)綄?duì)應(yīng)的ECU，以對(duì)抗局部升級(jí)攻擊。

圖4 下載請(qǐng)求流程

圖4中，每次通信的數(shù)據(jù)結(jié)構(gòu)與含義如下：

此過程完成后，MD會(huì)得到包含時(shí)間戳以及經(jīng)過2次加密的ECU解鎖密鑰和升級(jí)數(shù)據(jù)包，由于MD無法獲得主密鑰Km1，所以MD無法得到具體數(shù)據(jù)包的內(nèi)容，從而保證了在風(fēng)險(xiǎn)設(shè)備上的通信安全。

3.4 升級(jí)數(shù)據(jù)包交付過程

升級(jí)數(shù)據(jù)包的過程是CCU將數(shù)據(jù)包交付給ECU，同時(shí)保存ECU的備份數(shù)據(jù)，如圖5所示。

圖5 升級(jí)數(shù)據(jù)包交付流程

3.5 錯(cuò)誤處理方式

在安全通信握手過程中的任何錯(cuò)誤都會(huì)導(dǎo)致通信重置。通信重置是指由OEM服務(wù)器或CCU發(fā)送的一個(gè)數(shù)據(jù)包在發(fā)送或接收此信息后會(huì)復(fù)位成通信前的會(huì)話狀態(tài)，此數(shù)據(jù)包也會(huì)附加上發(fā)信者的簽名以防止干擾攻擊。

在其他過程中的錯(cuò)誤通信可以嘗試恢復(fù)，即發(fā)送請(qǐng)求重復(fù)的信息，此信息也需要使用Ks1、Kc1進(jìn)行加密。但當(dāng)累計(jì)到一定次數(shù)的錯(cuò)誤量或通信超時(shí)后，也將進(jìn)行通信重置。

3.6 密鑰泄露保護(hù)方案

密鑰泄露對(duì)于只使用單個(gè)公、私鑰的系統(tǒng)有致命打擊。如果OEM服務(wù)器只使用單個(gè)私鑰，一旦泄露，則所有安全手段都將無效化。Uptane框架提出了一個(gè)在軟件層面上對(duì)抗密鑰泄露的方案，本文參考其思路，提出一個(gè)用于保護(hù)網(wǎng)絡(luò)通信的簡(jiǎn)明方案，可降低通信時(shí)密鑰泄露的風(fēng)險(xiǎn)以及泄露后的威脅。方案中使用的概念有：

Root密鑰：OEM生成的一個(gè)公、私鑰對(duì)，用于簽名認(rèn)證其他密鑰（期限會(huì)話密鑰等），每個(gè)Root密鑰的私鑰都被機(jī)密地離線存放，不同Root密鑰的私鑰需要物理性地互相隔離。

Root密鑰組：OEM所有Root密鑰的集合，至少包含3對(duì)Root密鑰，組內(nèi)每個(gè)Root密鑰的公鑰至少被組內(nèi)過半數(shù)的其他Root密鑰的私鑰簽名。

Root公鑰組：Root密鑰組內(nèi)的所有公鑰的集合，在每臺(tái)車輛出廠時(shí)的CCU中預(yù)存。

期限會(huì)話密鑰對(duì)：由OEM定期生成的一個(gè)公、私鑰對(duì)，此密鑰有生效期限，在期限內(nèi)起到此協(xié)議中的OEM公、私鑰的作用。

考慮密鑰泄露情況，包括期限會(huì)話密鑰泄露（即OEM私鑰泄露）和Root密鑰泄露。期限會(huì)話密鑰過期后或發(fā)生密鑰泄露時(shí)，可以采用如圖6所示的過程進(jìn)行替換：OEM生成新期限會(huì)話密鑰作為OEM會(huì)話的公、私鑰，Root密鑰組中過半數(shù)的密鑰對(duì)此新密鑰中的公鑰進(jìn)行簽名；OEM發(fā)送新公鑰給CCU；經(jīng)過Root公鑰組認(rèn)證后，CCU替換OEM公鑰。

圖6 期限會(huì)話密鑰處理過程

這種方式不僅可以減少密鑰泄露的長(zhǎng)期風(fēng)險(xiǎn)，同時(shí)可以靈活處理公鑰撤銷的過程。但在期限會(huì)話密鑰泄露后與密鑰替換前的時(shí)間段內(nèi)，無法保證通信的機(jī)密性，故推薦在軟件數(shù)據(jù)認(rèn)證基礎(chǔ)上增加對(duì)策。

如果Root組的單個(gè)密鑰泄露，短期內(nèi)并不會(huì)產(chǎn)生風(fēng)險(xiǎn)，這是因?yàn)閱蝹€(gè)Root密鑰并不能生成合法的期限會(huì)話密鑰或Root密鑰，也不能變更其他Root密鑰的有效性。因?yàn)榇嬖谖锢砀綦x，短期內(nèi)大量密鑰泄露是幾乎不可能的，所以及時(shí)發(fā)現(xiàn)即可安全變更CCU中保存的Root公鑰。處理過程如圖7所示：OEM移除泄露的Root密鑰，生成廢棄信息；OEM生成新的Root密鑰，與廢棄信息合并成替換數(shù)據(jù)包，并利用Root組中的過半數(shù)密鑰進(jìn)行簽名，同時(shí)將包發(fā)送至CCU；CCU獲取替換數(shù)據(jù)包后，利用預(yù)存的Root公鑰組認(rèn)證，更新Root公鑰。

圖7 Root組單個(gè)密鑰泄露處理過程

4 協(xié)議分析與理論證明

本節(jié)主要對(duì)協(xié)議的安全性進(jìn)行軟件分析和理論分析。如果能夠保證安全通信握手過程中的主密鑰Km1得到了安全分享，那么在OEM密鑰安全的情況下，由于后續(xù)的ECU接收到的數(shù)據(jù)都由經(jīng)加密、MAC、增加時(shí)間戳的方式傳輸，所以可以保證ECU接收到的數(shù)據(jù)的機(jī)密性、完整性、可用性和新鮮性。故可以認(rèn)為系統(tǒng)安全性等價(jià)于主密鑰Km1是否達(dá)成安全目標(biāo)，所以本文針對(duì)主密鑰Km1的信息安全性進(jìn)行分析。

4.1 Scyther建模分析

Scyther是一個(gè)形式化分析工具，可以對(duì)通信協(xié)議中的安全問題進(jìn)行分析并針對(duì)漏洞給出攻擊圖。建模針對(duì)第一階段安全通信握手流程，由于Scyther對(duì)時(shí)間戳的支持度有限，模型利用隨機(jī)數(shù)ts作為令牌，進(jìn)行一定程度的替代。為減少運(yùn)算量，對(duì)簽名過程使用整體私鑰加密的方式進(jìn)行替代，軟件略微減少最大運(yùn)行次數(shù)以減少運(yùn)算時(shí)間，通信模型選擇默認(rèn)的D-Y模型。

運(yùn)行結(jié)果是Km1、Km2的機(jī)密性在沒有密鑰泄露的情況下成立，如圖8所示。而當(dāng)放棄MD的公鑰系統(tǒng)，即MD為不可信任或受到安全威脅的狀態(tài)時(shí)，Km1依舊是機(jī)密的，而Km2卻存在風(fēng)險(xiǎn)，如圖9所示，這與預(yù)期保持一致。

圖8 密鑰安全時(shí)Scyther驗(yàn)證結(jié)果

圖9 MD設(shè)備有風(fēng)險(xiǎn)時(shí)Scyther驗(yàn)證結(jié)果

4.2 密鑰安全傳輸理論分析

基于安全目標(biāo)定義，對(duì)主密鑰Km1的安全要求逐個(gè)分析：

a.新鮮性：所有消息都附帶時(shí)間戳，在消息來源可靠的條件下，可以保證消息的新鮮性。同時(shí)，OEM服務(wù)器和需要升級(jí)的CCU代理可以互相認(rèn)證，并且OEM生成了隨機(jī)種子作為會(huì)話的標(biāo)識(shí)，故攻擊者無法依靠重放截獲的密鑰分享信息中控制主密鑰，從而保證了主密鑰的新鮮性。

b.機(jī)密性：所有主密鑰均由CCU生成，且被CCU簽名，所以相關(guān)內(nèi)容都不可能被第三方控制（除非重放攻擊，但新鮮性的證明已經(jīng)排除這一點(diǎn)）。因?yàn)榘髅荑€Km1的所有數(shù)據(jù)包都被OEM或CCU的公鑰加密，所以無法被MD或其他攻擊者獲取，可以保證機(jī)密性。

c.完整性、可認(rèn)證性、可用性：安全通信握手的前5次通信都附加了數(shù)字簽名，所以在驗(yàn)證成功后可以保證主密鑰Km1具有這些性質(zhì)。

這樣，因?yàn)橹髅荑€Km1的信息安全得以保障，所以可以認(rèn)為安全目標(biāo)達(dá)成。

5 結(jié)束語

本文分析了車輛OTA升級(jí)技術(shù)的研究與進(jìn)展，提出一種利用互聯(lián)網(wǎng)設(shè)備進(jìn)行安全OTA更新包通信的協(xié)議框架及一個(gè)簡(jiǎn)化的密鑰泄露保護(hù)方案。通過理論分析和形式化工具Scyther進(jìn)行建模，證明了其有效性。但本研究細(xì)節(jié)仍不完善，在加密算法的選擇上還需進(jìn)一步測(cè)試，對(duì)于特殊通信狀況和不同實(shí)際硬件的特殊性還缺少考慮，后續(xù)將會(huì)對(duì)協(xié)議進(jìn)行輕量化及完善化研究。