基于互聯網設備的車輛安全空中下載通信協議方案

周奇才 王奕童 趙炯 熊肖磊

（1.同濟大學，上海 201804；2.同濟大學浙江學院，嘉興 314051）

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

1 前言

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

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

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

本文提出一個基于互聯網設備的OTA更新包的安全通信協議方案，可以在不安全的網絡及有風險的設備上實現安全通信，并參考Uptane軟件模式提出一個簡單密鑰泄露保護方案。

2 系統模型

2.1 系統模型與前提條件

本文系統模型與EVITA項目的FOTA模型基本一致。車內的每一個通信節點具有不同等級的硬件安全模塊（Hardware Security Modules，HSM）作為實現密碼學算法和機密存儲的安全模塊，HSM的定義和等級劃分依照EVITA項目定義。車輛中央通信單元（Central Communication Unit，CCU）是車內會話中心，擁有全功能的HSM。CCU也作為一個密鑰管理（Key Master，KM）節點保存車內ECU的公鑰或預備密鑰。車內ECU根據功能需求擁有不同等級的HSM。車輛CCU與OEM服務器通過互聯網設備進行連接，該設備可以是個人擁有的智能設備，也可以是主機廠或者供應商提供的網絡終端，可以實現安全診斷、更新等傳統診斷工具（Diagnostic Tool，DT）所具有的功能。因為智能手機具有較高的普及率、良好的運算性能以及便利性，所以本文以典型的移動設備（Mobile Device，MD）手機作為互聯網設備進行相關分析，系統模型如圖1所示。

圖1 系統模型

系統的前提條件要求為：

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

b.MD（手機）：獲取OEM提供的官方APP；連接目標CCU；具有一定的性能以滿足運算需求。

c.CCU：存儲正確的OEM公鑰；具有EVITA項目定義的功能要求（包括全HSM等）；搜集并提供當前車內升級所需要的相關信息；作為車內KM擁有ECU的相關密鑰。

d.ECU：具有EVITA項目定義的相關功能要求（包括HSM、升級功能等）；提供升級需要的相關信息（如ID、型號、版本號、升級狀態等）。

e.手機APP：正確存儲OEM公鑰并可靈活替換；實現本文的通信協議和通用的密碼算法；實現針對汽車的其他通信功能以及診斷功能（可選）。

2.2 威脅模型

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

2.3 安全目標

定義目標為：在所有傳輸流程正確認證完成后，確保ECU接受到的數據具有機密性、完整性、可用性、可認證性和新鮮性。

3 協議框架描述

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

表1 符號定義與解釋

在2.1節的系統條件下，服務器將采用某種方式通知（或CCU定期查詢得知）ECU需要升級，并利用此協議進行數據包交付。

3.1 安全通信握手過程

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

此過程具體流程如圖2所示。考慮到從MD發起請求起到OEM與CCU數據交互結束至少需要5次通信，故在此基礎上增加2次密鑰確認過程已經接近最簡。

圖2 安全通信握手流程

此流程可以保證發起請求和生成密鑰的實體都是可信的。基于OEM與CCU之間具有互相認證的能力，OEM生成帶有隨機種子的簽名包以驗證本次會話確實有可信的CCU參與。而CCU生成的所有主密鑰加密簽名數據包，保證了密鑰來源的合法且機密。對應圖2，每次通信的數據構成如下：

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

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

3.2 車輛信息反饋過程

車輛信息反饋過程用來通知OEM服務器當前車輛的軟件狀態。車輛的信息數據可以在平時車輛使用過程中由CCU備份，具體流程如圖3所示。

圖3 車輛信息反饋流程

此過程完成后，OEM服務器可以根據相應的信息生成更新數據包。

3.3 數據下載請求過程

數據下載請求過程為MD從OEM服務器獲得ECU解鎖密鑰和升級文件的過程，如圖4所示。當有多個ECU需要升級時，則可以采用打包傳輸的方式，通過CCU分別傳輸到對應的ECU，以對抗局部升級攻擊。

圖4 下載請求流程

圖4中，每次通信的數據結構與含義如下：

此過程完成后，MD會得到包含時間戳以及經過2次加密的ECU解鎖密鑰和升級數據包，由于MD無法獲得主密鑰Km1，所以MD無法得到具體數據包的內容，從而保證了在風險設備上的通信安全。

3.4 升級數據包交付過程

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

圖5 升級數據包交付流程

3.5 錯誤處理方式

在安全通信握手過程中的任何錯誤都會導致通信重置。通信重置是指由OEM服務器或CCU發送的一個數據包在發送或接收此信息后會復位成通信前的會話狀態，此數據包也會附加上發信者的簽名以防止干擾攻擊。

在其他過程中的錯誤通信可以嘗試恢復，即發送請求重復的信息，此信息也需要使用Ks1、Kc1進行加密。但當累計到一定次數的錯誤量或通信超時后，也將進行通信重置。

3.6 密鑰泄露保護方案

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

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

Root密鑰組：OEM所有Root密鑰的集合，至少包含3對Root密鑰，組內每個Root密鑰的公鑰至少被組內過半數的其他Root密鑰的私鑰簽名。

Root公鑰組：Root密鑰組內的所有公鑰的集合，在每臺車輛出廠時的CCU中預存。

期限會話密鑰對：由OEM定期生成的一個公、私鑰對，此密鑰有生效期限，在期限內起到此協議中的OEM公、私鑰的作用。

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

圖6 期限會話密鑰處理過程

這種方式不僅可以減少密鑰泄露的長期風險，同時可以靈活處理公鑰撤銷的過程。但在期限會話密鑰泄露后與密鑰替換前的時間段內，無法保證通信的機密性，故推薦在軟件數據認證基礎上增加對策。

如果Root組的單個密鑰泄露，短期內并不會產生風險，這是因為單個Root密鑰并不能生成合法的期限會話密鑰或Root密鑰，也不能變更其他Root密鑰的有效性。因為存在物理隔離，短期內大量密鑰泄露是幾乎不可能的，所以及時發現即可安全變更CCU中保存的Root公鑰。處理過程如圖7所示：OEM移除泄露的Root密鑰，生成廢棄信息；OEM生成新的Root密鑰，與廢棄信息合并成替換數據包，并利用Root組中的過半數密鑰進行簽名，同時將包發送至CCU；CCU獲取替換數據包后，利用預存的Root公鑰組認證，更新Root公鑰。

圖7 Root組單個密鑰泄露處理過程

4 協議分析與理論證明

本節主要對協議的安全性進行軟件分析和理論分析。如果能夠保證安全通信握手過程中的主密鑰Km1得到了安全分享，那么在OEM密鑰安全的情況下，由于后續的ECU接收到的數據都由經加密、MAC、增加時間戳的方式傳輸，所以可以保證ECU接收到的數據的機密性、完整性、可用性和新鮮性。故可以認為系統安全性等價于主密鑰Km1是否達成安全目標，所以本文針對主密鑰Km1的信息安全性進行分析。

4.1 Scyther建模分析

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

運行結果是Km1、Km2的機密性在沒有密鑰泄露的情況下成立，如圖8所示。而當放棄MD的公鑰系統，即MD為不可信任或受到安全威脅的狀態時，Km1依舊是機密的，而Km2卻存在風險，如圖9所示，這與預期保持一致。

圖8 密鑰安全時Scyther驗證結果

圖9 MD設備有風險時Scyther驗證結果

4.2 密鑰安全傳輸理論分析

基于安全目標定義，對主密鑰Km1的安全要求逐個分析：

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

b.機密性：所有主密鑰均由CCU生成，且被CCU簽名，所以相關內容都不可能被第三方控制（除非重放攻擊，但新鮮性的證明已經排除這一點）。因為包含主密鑰Km1的所有數據包都被OEM或CCU的公鑰加密，所以無法被MD或其他攻擊者獲取，可以保證機密性。

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

這樣，因為主密鑰Km1的信息安全得以保障，所以可以認為安全目標達成。

5 結束語

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