摘要

本文旨在證明，在汽車場景中，通過使用一種名為 “基于屬性的加密”（ABE）的加密方案，可以提升空中下載（OTA）更新功能的安全性，該方案能夠為空中軟件 / 固件更新提供機密性保障。我們通過研究表明，ABE 在計算時間和存儲方面的開銷相較于 OTA 過程中產(chǎn)生的其他開銷而言可忽略不計，從而證明 ABE 能夠無縫集成到現(xiàn)有的 OTA 更新解決方案中，同時也證實了可以以極低的成本增強安全性。為了支撐這一觀點，我們展示了在賽靈思（Xilinx）ZCU102 評估板上實施所提出的 ABE OTA 技術(shù)的實驗結(jié)果。該評估板是一款面向汽車領(lǐng)域的軟硬件（HW/SW）平臺，配備了 Zynq UltraScale + 多核片上系統(tǒng)（MPSoC）芯片，其計算能力可代表真實汽車電子控制單元（ECU）的水平。

1、引言

在過去的幾十年里，汽車行業(yè)發(fā)生了翻天覆地的變革。車輛對電子元件的依賴程度日益加深，借助電子元件為消費者提供全新功能。如今，每輛車配備的電子控制單元（ECU）數(shù)量遠超 80 個，軟件維護已成為一個亟待解決的重要問題。在行業(yè)內(nèi)，據(jù)估算，每 1000 行代碼中的漏洞數(shù)量在 0.5 到 25 個之間波動。認為市場上的車輛不存在任何漏洞是不切實際的，而假定這些漏洞均不會引發(fā)安全隱患則更為荒謬。新的攻擊手段和漏洞利用方式層出不窮，要完全防范所有威脅幾乎是不可能的。不過，在大多數(shù)情況下，針對新發(fā)現(xiàn)的漏洞，我們能夠找到解決方案，并通過軟件或固件更新來修復漏洞。

為車輛的軟件或固件進行更新的一種安全方式是將車輛送至最近的授權(quán)維修店，但顯然這種方式應盡量避免，因為它不僅會給消費者帶來極大不便，還會增加汽車原始設備制造商（OEM）的額外成本。這一嚴峻問題也引起了歐洲處理器計劃（EPI）項目委員會及其合作伙伴（如寶馬和 Elektrobit）的高度關(guān)注。

空中下載（OTA）更新是解決這一問題的方案之一，用戶可以像操作智能手機或家用電腦那樣自行完成更新操作。其核心原理是：每輛車內(nèi)都配備一個特殊的 ECU，即網(wǎng)關(guān)，它負責將外部網(wǎng)絡與車輛內(nèi)部所有的 ECU 連接起來。例如，網(wǎng)關(guān)可為車內(nèi)乘客提供信息娛樂服務，而在本文所述場景中，它能與制造商建立互聯(lián)網(wǎng)連接，以便下載更新文件。

目前已有多種先進的解決方案實現(xiàn)了 OTA 軟件更新功能，這些方案均著重保障更新的真實性和完整性，而機密性則被視為可選的安全特性。然而，這就導致更新文件的知識產(chǎn)權(quán)（IP）無法得到有效保護。因為如果更新文件在傳輸?shù)杰囕v的過程中未經(jīng)過任何加密處理，競爭對手便可輕易截獲并分析其中的內(nèi)容。這種情況在以下場景中尤為不利：更新文件包含應對新型攻擊的創(chuàng)新性防護措施，或是為車輛新增了特色功能。

另一個問題在于，即便通過建立安全通道（如傳輸層安全協(xié)議 TLS）來實現(xiàn)更新文件的機密傳輸，但當更新文件處于 “靜態(tài)存儲” 狀態(tài)時，其機密性便無法得到保障。“靜態(tài)存儲” 指的是數(shù)據(jù)未在互聯(lián)網(wǎng)中傳輸，例如存儲在云服務器中的數(shù)據(jù)就處于靜態(tài)存儲狀態(tài)。這意味著，若制造商借助安全通道保障更新文件的機密性，就無法使用第三方不可信服務器來存儲和分發(fā)更新文件，因為當更新文件上傳到這類服務器時，它將處于未加密狀態(tài)。此外，即便制造商使用自家的可信云服務器向每輛車傳輸更新文件，一旦更新文件到達車輛的網(wǎng)關(guān)，仍有可能被篡改網(wǎng)關(guān)的人員輕易截獲。

造成這種風險的原因在于，網(wǎng)關(guān)是唯一直接連接互聯(lián)網(wǎng)的 ECU，因此相較于其他所有 ECU，它更容易遭受網(wǎng)絡攻擊，也更易被篡改。事實上，在《AUTOSAR 更新與配置管理規(guī)范》文檔中也明確指出，宜設置一個獨立于網(wǎng)關(guān)的專用 ECU，專門負責管理車輛的軟件更新。

解決 “靜態(tài)數(shù)據(jù)” 安全問題的一種方法是對更新文件進行非對稱加密（如采用 RSA 算法），使得只有上述專用 ECU（甚至網(wǎng)關(guān)都不具備此權(quán)限）能夠?qū)ζ溥M行解密。但這種方法的成本較高，因為制造商需要為每一輛待更新的車輛分別對更新文件進行加密處理。

基于屬性的加密（ABE）大幅降低了多接收端端到端加密的成本，同時解決了更新文件靜態(tài)存儲的安全問題，使得為更新文件提供機密性保障變得經(jīng)濟且高效。借助 ABE 技術(shù)，即便攻擊者成功篡改了車輛的網(wǎng)關(guān)，更新文件依然處于加密狀態(tài)，并且通過專用 ECU 所持有的長期密鑰進行簽名，從而使攻擊者的篡改行為失去意義。攻擊者若想分析更新文件副本，唯一的途徑就是篡改專用 ECU 或需要進行更新的目標 ECU。

汽車行業(yè)已意識到此類風險，并針對這些問題制定了一系列安全策略，例如多層安全架構(gòu)。該架構(gòu)根據(jù)相關(guān)應用的安全需求，將車輛內(nèi)部架構(gòu)劃分為不同的安全級別，涵蓋從低安全級別（如信息娛樂系統(tǒng)）到高安全級別（如自動駕駛車輛的制動系統(tǒng)）的各個領(lǐng)域。除其他作用外，該策略確保了不直接連接互聯(lián)網(wǎng)的 ECU 難以被篡改。

盡管近年來已有眾多高質(zhì)量的研究成果證實了 ABE 在各類設備上的可行性，但據(jù)作者所知，目前尚無文獻針對 ABE 在真實汽車嵌入式硬件平臺上的影響展開測試。本文的研究目標就是證明，總體而言，ABE 方案能夠在與車輛實際搭載的 ECU 性能相近的平臺上良好運行。為此，我們選用了 Bethencourt 等人提出的密文策略基于屬性的加密（CP-ABE），因為此前有關(guān) ABE 可行性的研究均采用了該方案。通過證明該方案對 OTA 過程的影響微乎其微，我們進而表明 ABE 能夠在這類設備上實現(xiàn)出色的性能表現(xiàn)。

本文的貢獻主要包括以下三個方面：（1）提出一種適用于軟件 / 固件 OTA 安全更新的 ABE 技術(shù)，該技術(shù)可無縫集成到現(xiàn)有的先進解決方案中；（2）證實 ABE 不僅符合現(xiàn)代汽車的車內(nèi)網(wǎng)絡架構(gòu)，還與真實汽車 ECU 的計算能力相匹配；（3）在真實的汽車兼容平臺（即賽靈思 ZCU102 評估板）上對 ABE 的性能進行實驗評估。

本文其余部分的結(jié)構(gòu)安排如下：第 2 節(jié)介紹相關(guān)背景知識并綜述相關(guān)研究成果；第 3 節(jié)闡述性能評估的實驗設置；第 4 節(jié)展示并分析實驗結(jié)果；最后，第 5 節(jié)對全文進行總結(jié)。

2、相關(guān)研究

2.1 基于屬性的加密

基于屬性的加密（ABE）是一種將訪問控制機制嵌入加密數(shù)據(jù)的加密技術(shù)。在 ABE 中，數(shù)據(jù)和可解密實體均通過 “屬性” 來描述，并且通過基于這些屬性定義的布爾公式（即策略）來管控對數(shù)據(jù)的訪問權(quán)限。

在 ABE 機制中，加密方（以下簡稱 “數(shù)據(jù)生產(chǎn)者”）使用一個公開且唯一的加密密鑰；而任何解密方（以下簡稱 “數(shù)據(jù)消費者”）則使用各自專屬的私有解密密鑰。ABE 主要包含兩種范式：密文策略基于屬性的加密（CP-ABE）和密鑰策略基于屬性的加密（KP-ABE）。

在 CP-ABE 中，每個數(shù)據(jù)消費者都持有一個屬性集合，該集合被嵌入到其解密密鑰中；每一份數(shù)據(jù)都對應一個訪問策略，該策略被嵌入到密文中。訪問策略可被視為一棵樹狀結(jié)構(gòu)，其中內(nèi)部節(jié)點代表邏輯運算符 “與”（AND）和 / 或 “或”（OR），葉子節(jié)點則代表具體的屬性。所有 CP-ABE 方案均包含四個核心算法：

· 初始化算法（Setup）：生成主密鑰和加密密鑰；

· 密鑰生成算法（KeyGen）：以主密鑰和描述解密密鑰持有者的屬性集合作為輸入，生成解密密鑰；

· 加密算法（Encrypt）：以加密密鑰、明文消息以及描述待加密數(shù)據(jù)的訪問策略作為輸入，生成密文；

· 解密算法（Decrypt）：以解密密鑰和密文作為輸入，當且僅當解密密鑰中的屬性集合滿足密文中的訪問策略時，才能解密得到明文消息。

KP-ABE 與 CP-ABE 采用相同的算法框架，但兩者在屬性集合和訪問策略的應用方式上存在差異。在 KP-ABE 中，密鑰生成算法（KeyGen）的輸入是訪問策略而非屬性集合，而加密算法（Encrypt）的輸入則是屬性集合而非訪問策略。

ABE 具備抗合謀特性，即兩個數(shù)據(jù)消費者無法通過合并各自的密鑰來訪問單獨任何一方都無權(quán)訪問的數(shù)據(jù)。此外，ABE 的一大顯著優(yōu)勢在于，數(shù)據(jù)生產(chǎn)者只需對信息進行一次加密，就能通過數(shù)學方式為其施加訪問控制機制，確保只有擁有足夠訪問權(quán)限的解密密鑰才能對其進行解密。

這意味著，如果數(shù)據(jù)生產(chǎn)者采用 RSA 算法向 n 個數(shù)據(jù)消費者發(fā)送一個文件，就需要對該文件進行 n 次加密；而若采用 ABE 算法，只需對文件進行一次加密即可。因此，汽車企業(yè)可以利用 ABE 對更新文件進行加密并簽名，然后將其上傳至第三方云存儲服務器，由這些服務器安全地將更新文件分發(fā)給所有目標車輛，確保接收的更新文件具備真實性、完整性和機密性。即便第三方云存儲服務器不可信，采用 ABE 也是一種安全的設計選擇。

在本次性能評估中，我們選用了 Bethencourt 等人提出的 CP-ABE 方案。我們認為，對于原始設備制造商（OEM）而言，CP-ABE 是更優(yōu)的選擇，因為與 KP-ABE 方案相比，CP-ABE 能讓數(shù)據(jù)生產(chǎn)者（即 OEM）擁有更強的控制權(quán)。

2.2 空中下載（OTA）框架

空中下載（OTA）更新解決方案是未來汽車 ECU 軟件和固件更新的發(fā)展方向。對用戶而言，無需將車輛送至最近的授權(quán)維修店進行更新，極大地提升了便利性，同時也提高了用戶實際安裝更新的意愿。此外，有數(shù)據(jù)顯示，汽車 OTA 更新可將保修成本降低一半。

目前已有一些先進的解決方案實現(xiàn)了 OTA 固件 / 軟件更新的端到端加密，例如 vConnect。該方案通過在服務器與車輛網(wǎng)關(guān)之間建立加密會話來構(gòu)建安全通道。但這種方式存在安全隱患：當更新鏡像文件下載完成后，它會在網(wǎng)關(guān)內(nèi)處于 “靜態(tài)存儲” 狀態(tài)。由于網(wǎng)關(guān)是唯一直接連接互聯(lián)網(wǎng)的 ECU，因此它是最容易受到攻擊的 ECU。

相比之下，如果企業(yè)采用本文提出的 ABE OTA 軟件更新技術(shù)，網(wǎng)關(guān)只需將下載到的加密且已簽名的鏡像文件轉(zhuǎn)發(fā)給更新與配置管理器（UCM）即可。根據(jù)《AUTOSAR 自適應平臺規(guī)范》文檔，UCM 也可運行在一個獨立于網(wǎng)關(guān)的專用 ECU 上，從而能更好地抵御外部攻擊。

2016 年，Karthik 等人發(fā)布了 Uptane 框架，該框架專為地面車輛的軟件和固件 OTA 更新安全而設計。Uptane 允許用戶選擇使用對稱加密、非對稱加密或數(shù)字信封技術(shù)對軟件鏡像（即軟件更新文件）進行加密。本文設計了一個集成 ABE 的簡易框架，用于評估 ABE 對 OTA 軟件更新的影響。由于 ABE 本質(zhì)上屬于非對稱加密方案，因此本文的研究將證明，ABE 能夠集成到真實復雜的框架中，是保障知識產(chǎn)權(quán)（IP）機密性的可行方案。

2018 年，Asokan 等人提出了 ASSURED 框架，這是一種基于 Uptane的 OTA 固件更新框架。他們在研究中聲稱，ASSURED 框架實現(xiàn)了以下五個目標：

1. 端到端認證與完整性：更新文件必須經(jīng)過制造商簽名，并由設備進行驗證；

2. 控制器的更新授權(quán)：只有經(jīng)過授權(quán)的設備才能安裝更新；

3. 更新安裝的證明：設備必須能提供更新已安裝的證明；

4. 設備上代碼與密鑰的保護：更新文件的存儲以及關(guān)鍵代碼的隔離執(zhí)行必須在安全存儲區(qū)域內(nèi)進行；

5. 最小化設備負擔。

然而，ASSURED 框架并未將竊聽通信以獲取更新代碼，或從被篡改的網(wǎng)關(guān)中竊取更新代碼的外部實體視為潛在攻擊者。與之不同的是，本文的研究除了實現(xiàn) ASSURED 框架所達成的目標外，還考慮了此類攻擊者，并通過基于屬性的加密（ABE）技術(shù)為更新文件提供保護，抵御這類攻擊。

2020 年，Ghosal 等人提出了 STRIDE 方案，這是一種適用于自動駕駛車輛的 OTA 軟件更新方案。在該方案中，作者采用 Bethencourt 等人提出的 CP-ABE 方案來保障軟件更新文件的機密性，并通過 OMNeT++仿真工具進行了全面的性能評估。但與本文不同的是，他們并未在真實的汽車平臺上測試引入 ABE 后的性能表現(xiàn)，而本文則在賽靈思 ZCU102 評估板上開展了相關(guān)測試，從而能更真實地評估 ABE 的性能。此外，他們的研究未對密鑰撤銷機制的性能進行評估，而在實際應用場景中，密鑰撤銷機制至關(guān)重要，不能被忽略。

Halder 等人近期發(fā)表了一篇關(guān)于聯(lián)網(wǎng)車輛安全 OTA 軟件更新的綜述文章。在該綜述中，更新文件的機密性被視為一項強制性要求，作者探討并分析了多種相關(guān)方案，涵蓋僅基于對稱密鑰、哈希函數(shù)、區(qū)塊鏈、RSA 與隱寫術(shù)結(jié)合、硬件安全模塊（HSM）以及安全更新框架等技術(shù)的 OTA 更新方案。然而，該綜述并未提及明確基于屬性的加密（ABE）的解決方案。

2.3 測試平臺與汽車硬件背景

基于屬性的加密（ABE）技術(shù)最初由 Sahai 和 Waters 于 2005 年提出。此后，眾多研究人員提出了各自的 ABE 方案，并在各類平臺上對這些方案進行了評估。此外，已有大量文獻探討了多種 ABE 方案（包括 KP-ABE 和 CP-ABE）在智能手機、物聯(lián)網(wǎng)設備等資源受限設備上的可行性。但據(jù)作者所知，目前尚無文獻針對 ABE 方案在真實汽車嵌入式硬件平臺上的影響展開測試。

傳統(tǒng)物聯(lián)網(wǎng)設備（如智能手機、傳感器、樹莓派等）與汽車嵌入式平臺的主要區(qū)別在于硬件配置。正如讀者將在本節(jié)末尾了解到的，汽車嵌入式平臺具備多核處理器、實時處理器等硬件組件，而這些組件在普通物聯(lián)網(wǎng)設備中通常是不存在的。因此，本節(jié)將闡述真實汽車平臺的車載網(wǎng)絡架構(gòu)和計算能力，以便將所提出的 ABE 技術(shù)集成到具有代表性的汽車場景中。同時，本文還將介紹新興的車輛架構(gòu)設計，說明為何在討論 ABE 在汽車領(lǐng)域的性能時，不能直接參考以往的研究成果。

車載網(wǎng)絡正經(jīng)歷從傳統(tǒng)的基于域的電子架構(gòu)向區(qū)域架構(gòu)的轉(zhuǎn)型。基于域的架構(gòu)包含多個簡單且相互獨立的 ECU 和網(wǎng)絡，將繼續(xù)用于普通汽車子系統(tǒng)（如制動或轉(zhuǎn)向控制系統(tǒng)）。而對于高性能任務（如用于障礙物檢測、導航和軌跡規(guī)劃的傳感器融合），則需要少量的超級計算機來支撐。

除了傳統(tǒng)的本地互聯(lián)網(wǎng)絡（LIN）和控制器局域網(wǎng)（CAN）外，在新興的汽車平臺中，無線車聯(lián)網(wǎng)（V2X）通信通過車載版本的無線局域網(wǎng)（如 802.11p 技術(shù)）和蜂窩網(wǎng)絡（如 C-V2X）來實現(xiàn)。這種多樣化的連接方式將大幅增加軟件 OTA 分布式分發(fā)的可能性，但同時也帶來了安全隱患，使車輛更容易受到外部網(wǎng)絡威脅的攻擊。

汽車企業(yè)已意識到這一嚴重威脅，并嘗試將所有連接功能集中到一個名為 “網(wǎng)關(guān)” 的 ECU 上。然而，對于 OTA 軟件 / 固件更新這類關(guān)鍵應用，根據(jù)相關(guān)規(guī)范，建議設置一個獨立于網(wǎng)關(guān)的專用 ECU，即更新與配置管理器（UCM）。該 ECU 存儲 OTA 軟件 / 固件更新所需的加密參數(shù)，例如用于簽名驗證的公鑰和用于解密的私鑰。

實際上，車輛內(nèi)部推薦的 OTA 更新流程如下：

1. 網(wǎng)關(guān)下載經(jīng)過簽名和加密的更新文件，并將其轉(zhuǎn)發(fā)給 UCM；

2. UCM 驗證更新文件的簽名；

3. UCM 對更新文件進行解密；

4. UCM 將解密后的更新文件轉(zhuǎn)發(fā)給需要更新的 ECU。

這種新型汽車網(wǎng)絡架構(gòu)的一個關(guān)鍵特征是配備了性能更強大的 ECU。與普通 ECU（通常采用低成本微控制器）不同，高性能汽車 ECU 處理器通常具備以下特點：

1. 具備以太網(wǎng)物理層和交換機接口；

2. 搭載應用處理器（如采用 AArch64 64 位指令集的 Cortex-A 系列處理器）；

3. 配備硬件安全引擎（HSE），用于安全啟動和加速安全服務。

特別值得注意的是，對于上述第三點，根據(jù)車載安全硬件的實際標準 ——EVITA 項目的規(guī)定，UCM 應屬于 “安全級別 IV” 的 ECU。在車內(nèi)互聯(lián)方面，S32G 芯片支持以太網(wǎng)、CAN 等多種網(wǎng)絡協(xié)議。這些特性使得 UCM 能夠輕松執(zhí)行多種加密操作，并且能夠與所有需要 OTA 軟件 / 固件更新支持的普通 ECU 進行連接。

需要明確的是，這類高性能 ECU 并非未來的研發(fā)方向，而是已經(jīng)投入實際應用。將多核 Cortex-A 處理器集成到汽車平臺的理念也被超級計算機平臺所采用，例如瑞薩（Renesas）H3 異構(gòu)片上系統(tǒng)（SoC）。該芯片集成了四個 Cortex-A72 核心、四個 Cortex-A53 核心，并由一個雙核鎖步 Cortex-R7 實時微控制器和豐富的網(wǎng)絡接口進行管理。

為此，歐洲處理器計劃（EPI）正在研發(fā)一款高性能異構(gòu)處理器，該處理器集成了多個采用 AArch 64 位架構(gòu)且支持可擴展向量擴展（SVE）的 ARM 核心，以及用于嵌入式現(xiàn)場可編程門陣列（FPGA）、大規(guī)模并行處理器陣列（MPPA）和基于 RISC-V 的模板與神經(jīng)流加速器（STX）的協(xié)處理器模塊。

為了評估 ABE 作為附加功能的易集成性，本文在一個真實的汽車兼容評估板上進行了性能評估。為此，我們選擇了賽靈思（Xilinx）的 ZCU102 評估板，該板是一款多功能原型平臺，既能代表高性能汽車 ECU 處理器，也可作為異構(gòu)超級計算機的簡化版本。

ZCU102 評估板搭載了 Zynq UltraScale + 多核片上系統(tǒng)（MPSoC）芯片，該芯片包含四個帶 ARM Neon?技術(shù)的 ARM Cortex?-A53 核心、兩個 Cortex-R5F 實時處理器核心以及一個 Mali?-400 MP2 圖形處理器。此外，ZCU102 的 FPGA 資源支持進一步集成加速器，同時還提供了豐富的連接接口。

在軟件開發(fā)方面，ZCU102 支持類 Linux 操作系統(tǒng)（PetaLinux）以及集成設計環(huán)境（VITIS），便于同時開發(fā)硬件和軟件部分。需要說明的是，賽靈思 Zynq UltraScale+ MPSoC 平臺不僅是一款快速原型開發(fā)工具，還可作為產(chǎn)品級解決方案使用。最近，大陸集團（Continental）已采用該平臺用于其四維（4D）汽車雷達系統(tǒng)。

3、研究方法

為了評估引入 ABE 對車輛性能的影響，我們設計了以下實驗。在實驗中，我們選用 Bethencourt 等人提出的 CP-ABE 方案作為 ABE 方案。默認情況下，CP-ABE 加密采用數(shù)字信封技術(shù)，即 CP-ABE 密文用于保護一個對稱密鑰，該對稱密鑰再對實際的明文消息進行對稱加密。在本文中，所提及的 CP-ABE 加密和 CP-ABE 解密均默認采用數(shù)字信封技術(shù)，其中對稱加密算法選用高級加密標準（AES）。

本實驗場景包含多個車輛、一個制造商和一個 “誠實但好奇” 的云服務器。制造商持有 CP-ABE 主密鑰、CP-ABE 加密密鑰、一對 RSA 密鑰，并知曉每輛車的 RSA 公鑰，同時負責生成系統(tǒng)所需的所有加密密鑰。

根據(jù)《AUTOSAR 規(guī)范文檔》的規(guī)定，我們假設每輛車都配備一個專門用于 OTA 更新的 ECU，即更新與配置管理器（UCM）。該 ECU 不直接連接互聯(lián)網(wǎng)，但與網(wǎng)關(guān)以及所有支持 OTA 更新功能的 ECU 相連。每輛車持有以下三種密鑰 / 參數(shù)：

1. 一個 CP-ABE 解密密鑰，該密鑰包含車輛的組件信息和特性描述；

2. 一對 RSA 密鑰；

3. 制造商的 RSA 公鑰。

這些與車輛相關(guān)的加密密鑰由原始設備制造商（OEM）在車輛生產(chǎn)過程中安裝到實現(xiàn) UCM 功能的 ECU 中。

制造商的主要操作流程如下：生成軟件更新文件，使用 CP-ABE 對其進行加密，結(jié)合版本號使用 RSA 算法對加密后的文件進行簽名，然后將經(jīng)過簽名和加密的更新文件存儲到云服務器中。云服務器會將經(jīng)過簽名和加密的更新文件發(fā)送給所有請求更新的車輛。

車輛接收更新文件的流程如下：網(wǎng)關(guān)接收到軟件更新文件后，將其轉(zhuǎn)發(fā)給 UCM；UCM 首先驗證制造商的簽名，然后對 CP-ABE 密文進行解密；最后，UCM 將解密后的更新文件轉(zhuǎn)發(fā)給需要更新的 ECU，待用戶確認后，該 ECU 完成更新安裝。圖 1 展示了該用例場景及各實體間的交互過程。

此外，當一個或多個解密密鑰存在泄露風險時，制造商需為未受影響的車輛提供新的密鑰。具體操作流程為：制造商為每輛未受影響的車輛生成新的 CP-ABE 解密密鑰，使用該車輛的 RSA 公鑰對新的解密密鑰進行加密，再用自身的 RSA 私鑰對加密后的密鑰進行簽名，隨后將經(jīng)過加密和簽名的解密密鑰（以下簡稱 “密鑰更新文件”）存儲到云服務器中。如果某輛車有新的解密密鑰可供使用，那么當該車請求軟件更新時，云服務器會同時將密鑰更新文件發(fā)送給該車。在這種情況下，UCM 首先驗證密鑰更新文件的簽名，然后通過 RSA 解密獲取新的 CP-ABE 解密密鑰；最后，UCM 驗證軟件更新文件的簽名，并使用新的 CP-ABE 解密密鑰對其進行解密。圖 2 展示了這一交互過程。

讀者可能會認為這種密鑰撤銷機制的效率較低，但本文所設計的是一種最壞情況的場景：如果這種簡單機制對測試平臺的性能影響較小，那么更先進、更高效的撤銷機制必然能得到更好的支持。

圖 1、采用密文策略基于屬性的加密（CP-ABE）的固件空中下載更新用例場景

圖 2、密鑰泄露情況下的 CP-ABE 解密密鑰分發(fā)流程

3.1 攻擊者模型

結(jié)合圖 2（本文所研究的最復雜場景），我們對攻擊者模型進行定義，明確攻擊者的能力、動機、目標以及攻擊方式。

我們假設原始設備制造商（OEM）、更新與配置管理器（UCM）以及車輛的所有 ECU（網(wǎng)關(guān)除外）都是可信的，而云服務器和網(wǎng)關(guān)則被視為不可信實體。我們認為這一假設具有合理性，因為車輛中的網(wǎng)關(guān)是唯一直接連接互聯(lián)網(wǎng)的 ECU，相較于其他 ECU，它面臨更多的外部攻擊風險。

下面我們將分析兩類潛在威脅：被動攻擊者和主動攻擊者。

被動攻擊者

被動攻擊者能夠攔截互聯(lián)網(wǎng)中傳輸?shù)乃邢ⅲㄔ荚O備制造商（OEM）與云服務器之間、云服務器與車輛之間傳輸?shù)南ⅰ１粍庸粽叩哪繕擞袃蓚€：

1. 截獲并解密 ABE 密文，獲取更新文件；

2. 截獲并解密 RSA 密文，獲取 ABE 解密密鑰。

然而，這兩個目標均無法實現(xiàn)，因為要達成這些目標，攻擊者必須分別破解文獻和提出的加密方案，而這些方案在當前技術(shù)水平下具有較高的安全性。

主動攻擊者

主動攻擊者能夠獲取并 / 或控制云服務器和 / 或網(wǎng)關(guān)。他們可能利用近年來發(fā)現(xiàn)的眾多漏洞來實施攻擊。例如，主動攻擊者可在網(wǎng)關(guān)（或云服務器）中植入間諜軟件，從而獲取該網(wǎng)關(guān)（或云服務器）處理的所有信息。

主動攻擊者的目標包括：

1. 強迫車輛安裝惡意軟件更新；

2. 解密 ABE 密文；

3. 從車輛中獲取解密密鑰和 RSA 私鑰。

要實現(xiàn)目標（1），攻擊者必須偽造原始設備制造商（OEM）對軟件更新文件的有效簽名，這意味著需要破解 RSA 簽名方案，而這在目前是難以實現(xiàn)的。

攻擊者可通過控制云服務器或網(wǎng)關(guān)來嘗試實現(xiàn)目標（2），但由于云服務器和網(wǎng)關(guān)均不持有任何解密密鑰，因此該目標同樣無法達成。

若攻擊者以某種方式獲取了某輛車的 CP-ABE 解密密鑰和 RSA 私鑰，從而實現(xiàn)目標（3），那么他們就能解密所有該 ABE 密鑰有權(quán)訪問的密文，并且能夠獲取并解密為該車生成的密鑰更新文件。不過，這種攻擊僅在原始設備制造商（OEM）未對該密鑰執(zhí)行撤銷操作前有效。一旦 OEM 執(zhí)行撤銷操作，會將對應的 RSA 公鑰從其公鑰數(shù)據(jù)庫中移除，并停止為該受影響車輛生成密鑰更新文件。

需要說明的是，原始設備制造商（OEM）如何發(fā)現(xiàn)攻擊行為并進而執(zhí)行密鑰撤銷操作，這一過程超出了本文的研究范圍。

4、性能評估

本節(jié)簡要說明我們?nèi)绾螛?gòu)建實驗場景，并介紹所使用的軟硬件環(huán)境。

4.1 實驗設置

我們設計了一個客戶端 - 服務器應用程序，用于模擬云服務器與車輛之間的交互過程。該應用程序采用 C 語言編寫，并使用了 OpenSSL、libswabe、CP-ABE 工具包、GMP（ GNU 多精度算術(shù)庫）以及基于配對的密碼學（PBC）庫。

實驗的核心目標是測量從車輛發(fā)起更新請求到完成更新安裝所耗費的時間，最終證明 CP-ABE 在提供關(guān)鍵安全特性的同時，對性能的影響微乎其微。

我們設計了三種不同的實驗場景，分別如下：

1. 無 CP-ABE 場景：當車輛請求更新時，云服務器將更新文件（明文形式）及其對應的版本信息發(fā)送給車輛，且這些數(shù)據(jù)均經(jīng)過原始設備制造商（OEM）簽名。該場景作為評估 CP-ABE 性能的基準參考。

2. 僅 CP-ABE 加密場景：云服務器存儲經(jīng)過 CP-ABE 加密的軟件更新文件及其版本信息，且這些數(shù)據(jù)均經(jīng)過 OEM 簽名。該場景的交互過程如圖 1 所示。

3. CP-ABE 加密 + 密鑰更新場景：該場景與場景 2 的交互過程基本一致，但云服務器會不定期地向車輛發(fā)送新的 CP-ABE 解密密鑰（交互過程如圖 2 所示）。

在場景 2 和場景 3 中，我們采用單一策略對軟件更新文件進行加密，并設置了兩個不同的屬性集合，分別代表兩輛能夠滿足該加密策略的車輛（車輛 1 和車輛 2）。圖 3 展示了所采用的加密策略和屬性集合。

加密策略的具體含義為：“車輛若要訪問該更新數(shù)據(jù)，必須滿足以下兩個條件之一：（1）具備 ECU_MODEL_2247 屬性；（2）同時具備 CAR_MODEL_21 屬性和 ECU_MODEL_2248 屬性”。

兩個車輛的屬性集合具體如下：

· 車輛 1 的屬性集合包含四個屬性，分別是：“CAR_MODEL_23、ECU_MODEL_2247、ECU_MODEL_2256、ECU_MODEL_2268”；

· 車輛 2 的屬性集合包含三個屬性，分別是：“CAR_MODEL_21、ECU_MODEL_2246、ECU_MODEL_2248”。

車輛 1 能夠?qū)γ芪倪M行解密，是因為它具備 ECU_MODEL_2247 屬性；車輛 2 能夠?qū)γ芪倪M行解密，是因為它同時具備 CAR_MODEL_21 屬性和 ECU_MODEL_2248 屬性。

圖 3、實驗所用的加密策略和兩個車輛的屬性集合

實驗中，客戶端（用于模擬車輛）運行在賽靈思（Xilinx）ZCU102 評估板上。如前所述，該評估板搭載了 Zynq UltraScale + 多核片上系統(tǒng)（MPSoC）芯片，配備四個帶 ARM Neon?技術(shù)的 ARM Cortex?-A53 核心、兩個 Cortex-R5F 實時處理器核心、一個 Mali?-400 MP2 圖形處理器，此外還擁有四個 SLFP + 以太網(wǎng)接口、六個 16.3 Gb/s GTH 收發(fā)器、64 個用戶自定義差分 I/O 信號、600 個系統(tǒng)邏輯單元、32 Mb 內(nèi)存以及 2500 個 DSP 切片。

對于每種實驗場景，我們在 ZCU102 評估板上進行了 5000 次迭代測試，并計算了 95% 置信區(qū)間的結(jié)果。在橢圓曲線密碼學（ECC）操作中，我們使用了 PBC 庫的 A 型內(nèi)部參數(shù)，其中群階為 160 位，元素大小為 512 位，嵌入度 k=2，對應的安全級別為 80 位。

在確定密鑰撤銷頻率時，我們參考了特斯拉（Tesla）車輛的更新頻率數(shù)據(jù)。根據(jù)其官方網(wǎng)站信息，2020 年 1 月至 2020 年 11 月期間，特斯拉共發(fā)布了 122 次更新，平均每月發(fā)布超過 11 次更新。基于此，我們設置了四種不同的密鑰撤銷頻率（大致涵蓋從每周到每月的范圍），分別為：每 2 次更新執(zhí)行一次撤銷、每 3 次更新執(zhí)行一次撤銷、每 6 次更新執(zhí)行一次撤銷以及每 12 次更新執(zhí)行一次撤銷。

4.2 實驗結(jié)果

圖 4 展示了實驗結(jié)果。場景 1（無 CP-ABE）的評估結(jié)果顯示，下載更新文件和驗證 RSA 簽名總共耗時約 256 毫秒。

在場景 2（僅 CP-ABE 加密）中，引入 CP-ABE 解密后，從車輛發(fā)起更新請求到開始安裝更新所耗費的時間增加了 200-230 毫秒。耗時增加的原因主要包括兩方面：一是執(zhí)行 CP-ABE 解密操作所需的時間，二是下載 CP-ABE 密文額外數(shù)據(jù)的時間。

從圖 4 中可以看出，車輛 2 的平均耗時比車輛 1 多約 24 毫秒。這是因為在解密 CP-ABE 密文時，車輛 2 需要使用 2 個屬性（即 CAR_MODEL_21 和 ECU_MODEL_2248）來滿足加密策略，而車輛 1 只需使用 1 個屬性（即 ECU_MODEL_2247）即可滿足加密策略。

在場景 3（CP-ABE 加密 + 密鑰更新）中，當撤銷頻率設置為每 6 次更新執(zhí)行一次（相當于每 15 天執(zhí)行一次撤銷）時，額外獲取新解密密鑰的平均耗時為 90-105 毫秒。此外，圖 5 顯示，在多種不同的撤銷頻率下，CP-ABE 解密和密鑰更新對總耗時的影響均較小。即使在最高的撤銷頻率下（每 2 次更新執(zhí)行一次，相當于每 5 天執(zhí)行一次），完成更新文件下載、密鑰更新以及解密的總耗時也僅不到 675-710 毫秒。當撤銷頻率降低到每 12 次更新執(zhí)行一次（大致相當于每月執(zhí)行一次）時，整個過程的耗時僅為 518-535 毫秒。

圖 4、從發(fā)起更新請求到開始安裝更新前的耗時（場景 3 的撤銷頻率為每 6 次更新一次）

圖 5、場景 3 中不同撤銷頻率下，從發(fā)起更新請求到開始安裝更新前的耗時

從場景 2 和場景 3 與場景 1 的耗時對比來看，CP-ABE 似乎對 OTA 軟件更新過程的耗時產(chǎn)生了不可忽視的影響。但當我們將這些耗時與實際的軟件安裝時間進行對比時，會發(fā)現(xiàn) CP-ABE 所增加的耗時其實是可以忽略不計的。

為此，我們還調(diào)研了汽車場景中軟件更新文件的大小。研究發(fā)現(xiàn)，以特斯拉 “Model 3” 車型為例，其軟件更新文件的大小通常約為 100 MB。為了模擬軟件安裝過程，我們在 ZCU102 評估板上安裝了不同大小的安裝包，并測量了對應的安裝時間。具體而言，我們測試了大小約為 6.9 KiB、2.7 MiB 和 5.9 MiB 的程序，安裝時間如圖 6 所示。

我們未測試更大尺寸的軟件安裝包，主要原因有兩點：一是難以找到大小約為 100 MB 的合適測試程序；二是即便使用這些較小尺寸的安裝包，其安裝時間也已遠大于解密和下載更新文件所需的時間。

圖 6 顯示，大小約為 6.9 KiB、2.7 MiB 和 5.9 MiB 的軟件安裝包，其平均安裝時間分別為 2100 毫秒、12388 毫秒和 22148 毫秒。

圖 6、不同大小軟件的安裝時間對比

圖 7 展示了三種場景下，從車輛發(fā)起更新請求到完成更新安裝的總耗時。由于軟件安裝時間遠大于其他過程的耗時，為了清晰展示 CP-ABE 對總耗時的影響，我們采用了對數(shù)坐標。實際上，當考慮軟件安裝時間時，三種場景的總耗時幾乎沒有差異。

具體而言，對于大小為 5.9 MiB 的軟件更新文件，其平均安裝時間為 22148 毫秒，95% 置信區(qū)間為 ±247 毫秒。這意味著軟件安裝時間比三種場景中之前計算的其他過程耗時高出兩個數(shù)量級。因此，我們可以得出結(jié)論：即便考慮到實驗中所使用的軟件鏡像文件大小遠小于實際部署的更新文件大小，CP-ABE 對 OTA 軟件更新總耗時的影響仍然是可以忽略不計的。

圖 7、從發(fā)起更新請求到完成軟件安裝的總耗時對比（軟件大小為 5.9 MiB，場景 3 的撤銷頻率為每 6 次更新一次）

此外，我們還評估了 CP-ABE 對消息大小的影響。圖 8 展示了云服務器發(fā)送給車輛的更新消息中各組成部分的大小。該更新消息主要包含三個部分：

1. 經(jīng)過對稱加密的軟件更新文件（大小為 5.9 MiB）；

2. 包含對稱密鑰的 CP-ABE 密文；

3. 原始設備制造商（OEM）的 RSA 簽名。

與 RSA 簽名相比，CP-ABE 密文的大小是其三倍多。但與軟件更新文件本身的大小相比，CP-ABE 密文所增加的額外數(shù)據(jù)量幾乎可以忽略不計。正因如此，為了在同一圖表中同時展示兩者的大小，我們不得不采用對數(shù)坐標。

圖 8、云服務器發(fā)送給車輛的更新消息中各字段的大小

考慮到 OTA 軟件更新并非時間敏感型任務，且無論何種情況，軟件安裝過程都是耗時最長的環(huán)節(jié)，我們認為在實際應用中采用 CP-ABE 技術(shù)將極大地提升車輛的安全性。

5、結(jié)論與未來展望

本文的研究表明，在汽車場景中，基于屬性的加密（ABE）技術(shù)能夠提升空中下載（OTA）更新功能的安全性。具體而言，ABE 不僅能為空中軟件 / 固件更新提供機密性保障，還能保護靜態(tài)存儲狀態(tài)下的更新文件。這一安全特性是現(xiàn)有先進解決方案所缺失的。此外，本文還測試了一種簡單的密鑰撤銷機制，而這也是現(xiàn)有系統(tǒng)中未實現(xiàn)的功能。

本文通過實驗證實，ABE 能夠無縫集成到現(xiàn)有的 OTA 更新解決方案中，并且更廣泛地說，ABE 在架構(gòu)和文檔方面均符合汽車行業(yè)標準。同時，與 OTA 軟件更新涉及的其他任務（如軟件安裝）相比，ABE 在計算時間和存儲方面所帶來的額外開銷是可以忽略不計的。這些結(jié)果表明，我們能夠以極低的成本增強 OTA 軟件更新的安全性。

由于比薩大學是 H2020 研究計劃下歐洲處理器計劃（EPI）項目的官方合作伙伴，我們計劃與寶馬（BMW）、Elektrobit 等其他合作伙伴開展合作，將本文提出的研究成果集成到他們現(xiàn)有的系統(tǒng)中。具體而言，我們計劃對 OTA CP-ABE 技術(shù)進行適配，使其符合 AUTOSAR 自適應平臺的規(guī)范要求。