AutoSec:面向車載網(wǎng)絡的安全汽車數(shù)據(jù)傳輸方案
摘要
現(xiàn)代車輛包含數(shù)百個電子控制單元(ECU)和傳感器,以增強眾多與安全和舒適性相關的功能。電子控制單元(ECU)通過控制器局域網(wǎng)(CAN)總線執(zhí)行實時信息交換,例如汽車指令傳輸。然而,CAN 總線架構僅支持非常有限的安全功能,因此,通過 CAN 進行的車載通信易受嚴重安全威脅。此外,由于 ECU 本質(zhì)上資源受限,若認證方案不具備成本效益,ECU 間通信過程中的持續(xù)消息傳輸會導致能量耗盡。本文提出一種輕量級方案 AutoSec,該方案利用低成本的按位異或(XOR)和連接(concatenation)運算,為聯(lián)網(wǎng)車輛提供安全高效的車載通信。定性分析表明,AutoSec 能夠保障消息完整性、用戶認證和消息機密性等安全屬性。我們在樹莓派 3B+(Raspberry Pi 3B+)上實現(xiàn)了 AutoSec,并通過大量實驗驗證了其安全穩(wěn)健性和輕量性。結果顯示,AutoSec 將計算時間減少了約 99%,能量消耗降低了約 99%。
1、引言
控制器局域網(wǎng)(CAN)總線技術通過廣泛部署,已在車載網(wǎng)絡(IVN)中變得相當普及。CAN 為現(xiàn)代車輛中不同電子控制單元(ECU)之間的廣播通信提供支持。近年來的技術發(fā)展使現(xiàn)代車輛能夠訪問云服務,并通過移動蜂窩網(wǎng)絡與其他車輛進行通信。這些接口不僅提供實用服務,還可能引入新的攻擊面,導致車輛 ECU 的安全漏洞增加。攻擊者可通過被攻陷的 ECU 控制車輛,造成嚴重后果,例如更改車輛速度或使車輛完全停止。
研究工作表明,CAN 缺乏安全機制,導致車載網(wǎng)絡(IVN)暴露于攻擊者之下。例如,研究人員在吉普切諾基(Jeep Cherokee)上進行的實驗表明,遠程攻擊者可輕易從被攻陷的 ECU 發(fā)送偽造消息,從而控制車輛的不同功能。另一項研究揭示了不同寶馬(BMW)車型存在的安全威脅,包括通過 CAN 遠程控制聯(lián)網(wǎng) ECU 的能力。由于缺乏加密技術且訪問控制不足,CAN 極易受到攻擊者攻擊。此外,CAN 總線的廣播特性使其更易遭受攻擊,且訪問控制難度加大。ECU 與外部網(wǎng)絡之間的通信應采用穩(wěn)健的加密技術設計,以保護車載網(wǎng)絡(IVN)免受內(nèi)部和外部攻擊者的威脅。在車載通信中,ECU 通過 CAN 總線廣播消息,以管理自動駕駛汽車的運行操作。此外,自動駕駛車輛通過專用短程通信(DSRC)、4G/5G 或 Wi-Fi 技術與其他車輛、行人、無線傳感器和其他智能設備等不同組件連接,確保車輛在道路上平穩(wěn)行駛。因此,在向 ECU 傳遞關鍵消息以使其采取進一步行動時,保障關鍵安全屬性至關重要;否則,可能會對車載運行操作造成嚴重損害。因此,本研究旨在解決車載消息傳輸中的重要安全挑戰(zhàn),即(i)發(fā)送方驗證、(ii)消息機密性和(iii)數(shù)據(jù)正確性。我們明確了與 CAN 相關的主要安全問題如下:?由于 CAN 中發(fā)送方身份未知且無法驗證發(fā)送方真實性,攻擊者可偽裝成任何具有相似消息標識符的 ECU。因此,所有連接到 CAN 總線的 ECU 都可能在系統(tǒng)中發(fā)起偽裝攻擊,從而影響車輛功能。ECU 通過 CAN 總線連接,為車輛提供各種汽車服務。CAN 通過網(wǎng)關 ECU(GECU)與無線接口關聯(lián),這使得攻擊者無需接觸車輛即可發(fā)起攻擊。此外,CAN 無法保證對被攻陷的 ECU 或其他 ECU 進行持續(xù)監(jiān)控。因此,攻擊者可發(fā)送虛假消息,誤導 CAN 總線。
?CAN 中的消息廣播未采用任何加密措施。所有連接到 CAN 總線的 ECU 都能監(jiān)聽任何消息,這可能導致數(shù)據(jù)機密性問題,或使攻擊者能夠向系統(tǒng)注入虛假數(shù)據(jù) [13]。考慮到 CAN 的安全缺陷,攻擊者可能試圖盜竊車輛、停用汽車系統(tǒng)、發(fā)送錯誤消息以及掩蓋故障功能。因此,在自動駕駛車輛的消息交換過程中,保障重要安全屬性至關重要。
研究貢獻
我們提出一種用于自動駕駛車輛 CAN 數(shù)據(jù)傳輸?shù)陌踩p量級方案。本文的貢獻主要體現(xiàn)在以下三個方面:
1. 提出一種安全輕量級方案 AutoSec,用于 CAN 上的安全數(shù)據(jù)傳輸,保障消息完整性、用戶認證和消息機密性等安全屬性。由于 ECU 處理能力有限,我們采用 SHA-512、按位異或(XOR)和連接(concatenation)運算,以實現(xiàn)高效的計算和驗證。
2. 對 AutoSec 進行分析,確認其在抵御消息完整性攻擊、用戶認證攻擊、消息機密性攻擊和會話密鑰攻擊方面的安全穩(wěn)健性。
3. 從計算時間、能量消耗和通信開銷等開銷指標方面評估 AutoSec 的性能。實驗結果表明,與其他相關現(xiàn)有方案相比,AutoSec 顯著提升了計算效率并降低了能量消耗。
文章結構
本文其余部分組織如下:第 2 節(jié)討論相關工作;第 3 節(jié)介紹系統(tǒng)概述、攻擊者模型和所提協(xié)議 AutoSec 的安全需求;第 4 節(jié)詳細闡述所提方案 AutoSec;第 5 節(jié)對 AutoSec 進行全面的安全分析;第 6 節(jié)呈現(xiàn) AutoSec 的性能評估結果;最后,第 7 節(jié)對研究進行總結。
2、相關工作
已有許多旨在保障車載網(wǎng)絡(IVN)消息通信安全的方案被提出。以下介紹一些與本文研究背景相關度較高的工作。提出一種名為 TACAN(CAN 中的發(fā)送方認證)的方案,該方案利用隱蔽信道的概念,為 CAN 總線上的 ECU 提供安全認證。該方案不使用額外的比特或 CAN 消息,也無需修改 CAN 協(xié)議。TACAN 利用隱蔽信道的概念開發(fā)防御技術,通過集中式可信監(jiān)控節(jié)點實現(xiàn)發(fā)送方認證。TACAN 由三個用于 ECU 認證的隱蔽信道組成。作者在華盛頓大學的 EcoCAR(2016 款雪佛蘭科邁羅)測試平臺上實現(xiàn)了 TACAN,并從比特錯誤、吞吐量和檢測性能等方面進行了全面評估。結果表明,TACAN 在檢測 CAN 總線攻擊和驗證 ECU 的一般功能方面具有較高的有效性。但該方案基于共享加密密鑰和消息到達時間間隔,導致計算開銷較大,且安全級別較低,無法滿足當今的安全需求。由于帶寬降低、有效載荷小以及計算資源受限等因素,CAN 中的幀認證通常具有局限性。為解決這一問題,提出一種通過觀察 CAN 信號差異來確定實際發(fā)送方身份的方法。
該方案能夠大幅減少所需資源,且識別率高達 99.98%。作者將其方案與最輕量級方案進行比較,結果表明該方案具有更小的內(nèi)存占用和更低的計算需求,并且能夠適應運行過程中的增量信號變化。該工作在一個原型車和兩輛量產(chǎn)車上進行了評估,在一周的時間內(nèi),在不同電子設備運行的變化條件下開展了相關測試。然而,該方案需要高性能的模數(shù)轉(zhuǎn)換器和較強的計算能力,這會顯著增加實現(xiàn)成本,對汽車行業(yè)產(chǎn)生重要影響。帕拉尼瓦米等分析了當前 CAN 總線的幀級認證協(xié)議,指出了其中的不足和局限性。作者提出一套協(xié)議套件,包括實體認證、密鑰管理、遠程傳輸請求幀的安全消息流以及車輛與外部設備通信所需的會話密鑰更新等功能。通過隨機預言機模型驗證所提協(xié)議的安全性,并評估其抵御已知攻擊的能力。仿真結果表明,與其他現(xiàn)有方案相比,該協(xié)議具有更高的效率。利用真實車輛和惡意智能手機應用程序,證明了在聯(lián)網(wǎng)汽車環(huán)境中遠程無線攻擊的可行性。他們根據(jù)當前的 CAN 規(guī)范設計了一種 CAN 安全協(xié)議,并通過 CANoe 軟件和 DSP-F28335 微控制器對該協(xié)議進行了評估。評估結果表明,所提安全協(xié)議在認證延遲和通信負載方面具有良好的性能。但該技術的主要缺點是,由于應用程序運行在移動設備上,攻擊者可能通過蜂窩網(wǎng)絡發(fā)起攻擊。
在系統(tǒng)設計階段提出一種新穎高效的方案,以提供最佳的安全性和安全性。該設計優(yōu)化確保每個實時應用程序都能在截止日期前執(zhí)行,并減少 CAN 總線上的傳輸消息數(shù)量。優(yōu)化操作后,作者對特定消息應用哈希消息認證碼,以確保 ECU 之間的安全通信并抵御網(wǎng)絡攻擊。安全分析和實驗結果證明,所提方案能夠及時有效地抵御 CAN 總線攻擊。盡管該技術通過選擇性消息認證減少了汽車 CAN 的通信開銷,但額外數(shù)據(jù)包的傳輸會引入延遲。格羅扎等利用有序的 CMAC 緩沖區(qū)對 CAN 幀的標識符進行認證,并驗證發(fā)送方節(jié)點的合法性。此外,作者考慮了實際場景,結果表明,盡管存在排序帶來的約束,但所達到的安全級別非常接近 ID 字段的長度。采用的方法能夠抵御重放攻擊和總線上的模糊測試。作者在汽車級微控制器和高端車輛的 CAN 總線流量分配上進行了實際實現(xiàn)。用于保障 CAN 總線安全的計算需求也相對較低。
3、系統(tǒng)概述
本節(jié)將介紹本研究的系統(tǒng)模型和相關背景知識。具體而言,3.1 節(jié)討論系統(tǒng)架構;3.2 節(jié)介紹攻擊者模型,包括攻擊者的目標和能力;最后,3.3 節(jié)列出安全需求。
3.1 系統(tǒng)架構
系統(tǒng)模型的設計目的是明確車載通信的總體框架以及不同實體的功能。圖 1 展示了車載網(wǎng)絡的基本概述,其中網(wǎng)關 ECU(GECU)和各種類型的 ECU 通過單一 CAN 總線連接。各組件的作用描述如下:

圖 1、基于 CAN 總線的汽車車載通信系統(tǒng)模型
· 網(wǎng)關 ECU(GECU):作為主要 ECU,它充當外部世界與車載網(wǎng)絡之間的中介。GECU 與遠程信息處理系統(tǒng)和車載診斷系統(tǒng) - II(OBD-II)連接,以執(zhí)行車輛的各種功能。它作為中央授權機構,負責在 ECU 之間建立 / 更新會話密鑰,并記錄車輛中所有已安裝 ECU 的 ID。
· 電子控制單元(ECU):每個 ECU 從傳感器(連接到發(fā)動機、制動系統(tǒng)、變速箱、冷卻系統(tǒng)、車軸、轉(zhuǎn)向系統(tǒng)等汽車部件)收集數(shù)據(jù),并通過 CAN 總線與其他 ECU 和 GECU 廣播相關消息。由于 ECU 配置的處理能力較低,執(zhí)行滿足高安全級別的高級加密運算需要花費更多時間。
· 攻擊者:系統(tǒng)主要包括內(nèi)部攻擊者和外部攻擊者兩種類型,他們可能在車載通信過程中發(fā)起被動攻擊和主動攻擊。其中,惡意 ECU 指的是系統(tǒng)的合法組件,但在車載通信過程中試圖偽造消息。3.2 節(jié)將詳細討論攻擊者的目標。
3.2 攻擊者模型
CAN 消息通過 CAN 總線廣播到所有 ECU的研究表明,攻擊者可通過本地或遠程訪問連接到汽車聯(lián)網(wǎng)系統(tǒng)。因此,我們考慮攻擊者的以下意圖,其目的是在車載通信中執(zhí)行惡意活動:
?攻擊者希望攔截或中斷車載通信,以實現(xiàn)各種目標,例如停止傳輸關鍵信息、追蹤車輛用戶、修改消息、延遲實時數(shù)據(jù)、傳播錯誤 / 虛假消息、丟失重要消息、未經(jīng)授權訪問系統(tǒng)消息以及竊取通信消息內(nèi)容。攻擊者的最終目的是對車載通信發(fā)起遠程攻擊,以破壞其功能。
?攻擊者試圖通過在 CAN 總線上發(fā)送多條虛假消息來降低 CAN 總線的性能效率,導致所有 ECU 忙于驗證收到的多條消息的正確性。基于研究,我們對攻擊者的安全能力做出以下假設:
?所有 ECU 都直接與網(wǎng)關 ECU(GECU)連接,而 GECU 與無線接口相關聯(lián)以實現(xiàn)不同功能,這使得攻擊者能夠向 CAN 總線注入錯誤消息。
?攻擊者可在短時間內(nèi)定期通過 CAN 發(fā)送多條消息,造成混淆,即接收方 ECU 難以確定應遵循哪條指令繼續(xù)執(zhí)行操作,從而導致 CAN 總線上的消息被覆蓋。
?攻擊者可故意在 CAN 總線上發(fā)送多條消息,以增加接收方的驗證開銷,最終導致 ECU 與總線斷開連接。
?若任何惡意 ECU 連接到 CAN 總線,它都能在 CAN 總線上廣播幀,因此攻擊者可對車載網(wǎng)絡發(fā)起惡意攻擊。
?我們假設攻擊者了解目標汽車系統(tǒng)的設計和規(guī)格。
3.3 安全需求
本研究的目標是通過實現(xiàn)認證、完整性和機密性,保障車載通信的重要安全屬性。這一目標通過以下方式實現(xiàn):采用秘密組密鑰通信和不可修改的標識符來驗證發(fā)送方身份,同時使用單向哈希函數(shù)計算消息,以保障消息的完整性和機密性。考慮到這些安全屬性,所提方案能夠防止消息的未授權訪問、消息篡改和數(shù)據(jù)偽造。以下討論 CAN 中不同安全屬性的重要性:
· 認證:當消息發(fā)送到 CAN 時,接收方通過數(shù)據(jù)幀中的發(fā)送方 ID 提取發(fā)送方信息,但 CAN 中沒有用于確認發(fā)送方身份的驗證機制。若任何被攻陷 / 惡意的 ECU 使用其他 ECU 的發(fā)送方 ID 進行偽造,則很難確定偽造消息的原始發(fā)送方。因此,認證在 CAN 中起著關鍵作用,通過驗證消息的發(fā)送方,防止非法消息的傳輸。
· 完整性:CAN 中的消息以明文形式發(fā)送,僅靠循環(huán)冗余校驗(CRC)校驗和不足以檢查 CAN 消息的正確性,因為攻擊者可相應地替換 CRC 信息。結果,ECU 可能會遵循被修改的消息來控制車輛功能,從而引發(fā)事故。因此,在執(zhí)行后續(xù)操作之前,最好先確認 CAN 消息的準確性。
機密性:根據(jù) CAN 標準,消息在 CAN 上廣播。因此,至少所有連接到 CAN 總線的 ECU 都會收到這些傳輸?shù)南ⅲ@可能導致重要信息泄露。因此,系統(tǒng)在通過 CAN 總線發(fā)送消息時應保障消息的機密性。
4、所提方案:AutoSec
自動駕駛車輛的運行完全依賴于汽車操作的及時性和準確性。因此,在車輛行駛過程中,在網(wǎng)關 ECU(GECU)和各 ECU 之間安全高效地傳輸關鍵信息(即汽車指令),對于快速做出更好的決策至關重要。現(xiàn)有的車載通信協(xié)議無法抵御關鍵安全問題,例如會話密鑰更新泄露、認證攻擊、私鑰存儲問題和加密密鑰泄露等。此外,這些協(xié)議的設計成本相對較高,例如采用橢圓曲線密碼學(ECC)且包含較多運算操作,導致執(zhí)行時間較長。
現(xiàn)代車輛具備更多功能,例如遠程信息處理、高級駕駛輔助系統(tǒng)和信息娛樂系統(tǒng)。因此,每輛車所需的 ECU 數(shù)量不斷增加,這些 ECU 需要在車載網(wǎng)絡(IVN)中執(zhí)行更多的計算操作。因此,設計一種在執(zhí)行各種操作時計算時間短且滿足重要安全需求的協(xié)議至關重要。我們提出一種安全數(shù)據(jù)傳輸方案(命名為 AutoSec),該方案采用 SHA-512、按位異或(⊕)和連接(||)運算,實現(xiàn)安全且經(jīng)濟高效的數(shù)據(jù)交換,保護關鍵信息免受各種安全威脅。AutoSec 結合輕量級運算(|| 和⊕)和 SHA-512,通過適當?shù)膮f(xié)議設計,在滿足 256 位安全級別的同時,快速完成各種計算。由于 AutoSec 旨在通過低成本的加密運算保護車載消息通信,因此不需要任何硬件修改和網(wǎng)絡改進。因此,所提方案可輕松應用于現(xiàn)有的 CAN 架構。AutoSec 主要包括兩個階段:(i)基本設置和(ii)消息通信協(xié)議。4.1 節(jié)討論基本設置過程,以在 ECU 中生成和加載長期密鑰。4.2 節(jié)詳細討論與 AutoSec 相關的安全通信協(xié)議。表 1 描述了 AutoSec 設計中使用的各種符號。

表 1、符號列表及其描述
4.1 AutoSec:基本設置
網(wǎng)關 ECU(GECU)作為中央 ECU,向道路運輸管理局(RTA)注冊,以在車載網(wǎng)絡中執(zhí)行各種操作。所有已安裝 ECU 的 ID 列表和相應的長期密鑰都安全地存儲在 GECU 的受保護內(nèi)存中。所有 ECU 最初都在防篡改的可信平臺模塊中加載長期密鑰(K_i、GK 和 K_rs)。為了驗證固件的完整性,ECU_i 計算固件摘要 H (K_i || ID_ECU_i || Image_Firmware) 并將其發(fā)送給 GECU,其中 Image_Firmware 包含該 ECU 軟件的不同詳細信息。GECU 收到后,將收到的固件摘要與計算值進行確認,以進行驗證。
4.2 AutoSec:消息通信協(xié)議
ECU 與車輛中的不同汽車部件相連,通過 CAN 總線在 ECU 之間交換實時信息,以實現(xiàn)汽車操作。AutoSec 結合時間戳、每個 ECU 的不同密鑰、隨機數(shù)和單向哈希函數(shù)進行設計,增強了對會話密鑰泄露的防御能力,防止加密密鑰泄露,并加強了新鮮度驗證,保護車載網(wǎng)絡(IVN)中的消息通信過程免受各種安全攻擊。該階段包括三個協(xié)議:(i)初始會話密鑰計算與驗證協(xié)議(ISCVP)、(ii)遠程幀傳輸請求協(xié)議(RFTRP)和(iii)會話密鑰更新協(xié)議(SKUP)。以下詳細描述這些協(xié)議:
4.2.1 所提初始會話密鑰計算與驗證協(xié)議(ISCVP)
每個 ECU 與 GECU 執(zhí)行以下步驟,以進行初始會話密鑰計算和驗證。由于車輛包含多個 ECU,此過程按固定順序與 GECU 執(zhí)行。該過程如圖 2 所示。

圖 2、AutoSec:初始會話密鑰計算與驗證協(xié)議(ISCVP)設計描述
4.2.2 所提遠程幀傳輸請求協(xié)議(RFTRP)
當某個 ECU(例如 ECU_r)需要從另一個 ECU(例如 ECU_s)獲取某些信息時,接收方 ECU(ECU_r)向發(fā)送方 ECU(ECU_s)發(fā)送請求,以建立它們之間的數(shù)據(jù)交換連接。圖 3 展示了遠程幀傳輸請求協(xié)議(RFTRP)過程,以確認雙方(ECU_s 和 ECU_r)的合法性以及各自在數(shù)據(jù)傳輸連接建立前發(fā)送的消息的合法性。

圖 3、AutoSec:遠程幀傳輸請求協(xié)議(RFTRP)設計描述
4.2.3 所提會話密鑰更新協(xié)議(SKUP)
ECU_i 和 GECU 之間的會話密鑰會定期更新,以使用新計算的會話密鑰提高系統(tǒng)安全性。然而,若采用會話密鑰更新協(xié)議(SKUP),則所有連接的 ECU 都能輕易獲取 ECU_i 的新會話密鑰。因此,我們設計了一種增強的會話密鑰更新協(xié)議(SKUP),以解決當前會話密鑰更新過程中存在的這一問題。所提會話密鑰更新協(xié)議(SKUP)如圖 4 所示。

圖 4、AutoSec:會話密鑰更新協(xié)議(SKUP)設計描述
5、安全分析
我們對所提協(xié)議進行安全分析,以驗證其抵御關鍵安全攻擊的穩(wěn)健性。基于隨機預言機模型(ROM),我們討論與 AutoSec 相關的定義、定理及其相應證明。在該模型中,構建攻擊者(A)和挑戰(zhàn)者(C)之間的游戲,以確認在多項式時間內(nèi),攻擊者(A)是否能以不可忽略的概率贏得挑戰(zhàn)者(C)給定的挑戰(zhàn)。AutoSec 基于 SHA-512 構建,考慮到 n 位輸出哈希運算的廣義生日攻擊成本為 O (2^(n/2)),該方案在多項式時間內(nèi)實現(xiàn) 256 位安全級別。考慮到在不久的將來計算能力要達到如此高的水平,SHA-512 具有抗碰撞性。
定義
若攻擊者(A)在多項式時間內(nèi)僅具有微不足道的優(yōu)勢,則所提協(xié)議在構建的游戲中是安全的。
遠程幀傳輸請求協(xié)議(RFTRP)- 預言機
我們假設攻擊者(A)充當 ECU_s,想要為 {ID_ECU_r, P_rs, Q_rs, T_i1} 發(fā)送虛假 / 修改的響應消息。因此,攻擊者(A)向 ECU_r 發(fā)送 {CT_rs^A, R_rs^A, T_i2^A}。在所提遠程幀傳輸請求協(xié)議(RFTRP)中,ECU_r(充當挑戰(zhàn)者 C)通過 T_i3 - T_i2 ≤ ?T 確認收到消息的新鮮度,并將收到的 R_rs 與計算的 R_rs 進行驗證。
會話密鑰更新協(xié)議(SKUP)- 預言機
我們假設攻擊者(A)充當 GECU,想要更新 ECU_i 和 GECU 之間的會話密鑰。因此,ECU_i 充當挑戰(zhàn)者(C),以確認會話密鑰更新過程中與原始 GECU 的連接。攻擊者(A)向 ECU_i 發(fā)送 {ID_ECU_i^A, X_i^A, Y_i^A, T_i1^A}。在所提會話密鑰更新協(xié)議(SKUP)設計中,ECU_i 端分別通過?T 和 Y_i 驗證有效性和合法性,以確認真實性。若滿足條件,ECU_i 向請求的 ECU 發(fā)送 {Z_i, T_i2}。在接收端,通過驗證確認交換參數(shù)的正確性。
定理 1
基于隨機預言機模型(ROM),所提協(xié)議能夠抵御基于消息完整性的攻擊。
證明:我們假設攻擊者(A)想要在遠程幀傳輸請求協(xié)議(RFTRP)階段,在不了解 ECU_s 的情況下,向 ECU_r(充當挑戰(zhàn)者 C)發(fā)送針對 {ID_ECU_r, P_rs, Q_rs, T_i1} 的修改 / 虛假消息響應。因此,攻擊者(A)需要計算 R_rs [=h (EK_rs || AK_rs || Q_rs || T_i2)] 和 CT_rs [=M ⊕ h (R_rs || p_i || ID_ECU_s)]。我們認為,攻擊者可從公共通信信道獲取 P_rs 和 Q_rs,但無法計算 K_rs(僅 ECU_s 和 ECU_r 知曉)和 p_i(缺少所有必要值)。因此,攻擊者(A)無法正確計算 R_rs 和 CT_rs。此外,若攻擊者(A)向 ECU_r 發(fā)送 {CT_rs^A, R_rs^A, T_i2^A},則挑戰(zhàn)者 C 通過 T_i3 - T_i2^A ≤ ?T 以及 R_rs 與 R_rs^A 的比較進行驗證。若攻擊者(A)對計算參數(shù)進行任何修改,則在 R_rs 是否等于 R_rs^A 的驗證中,無法證明消息的合法性。因此,在所提遠程幀傳輸請求協(xié)議(RFTRP)中,攻擊者(A)沒有機會在消息傳輸過程中進行任何修改。
定理 2
所提方案能夠保障用戶認證屬性。
證明:攻擊者(A)可能試圖在遠程幀傳輸請求協(xié)議(RFTRP)中通過偽裝 ECU_r 或 ECU_s 來破壞認證屬性。要偽裝 ECU_r,攻擊者(A)需要向 ECU_s 發(fā)送有效的計算參數(shù),以便接收實體在驗證后繼續(xù)執(zhí)行后續(xù)操作。若攻擊者(A)向 ECU_s 發(fā)送偽造參數(shù),則由于 Q_rs' 是否等于 Q_rs 的驗證失敗,請求將被丟棄。在所提遠程幀傳輸請求協(xié)議(RFTRP)中,攻擊者(A)需要計算 P_rs^A、Q_rs^A,以向 ECU_s 發(fā)送 {ID_ECU_r, P_rs^A, Q_rs^A, T_i1^A},但攻擊者(A)不知道 / 沒有 K_rs(僅 ECU_r 和 ECU_s 知曉)。因此,在所提遠程幀傳輸請求協(xié)議(RFTRP)中,攻擊者(A)無法進一步偽裝 ECU_r。要對 ECU_s 發(fā)起偽裝攻擊,攻擊者(A)需要知曉 ID_ECU_s 和 K_rs,因為這些值用于計算 P_rs 和 Q_rs。此外,攻擊者(A)需要 p_i(由 ECU_r 選擇)來生成 EK_rs 和 AK_rs。然而,在所提遠程幀傳輸請求協(xié)議(RFTRP)中,攻擊者(A)無法計算所有必要值以執(zhí)行惡意活動。若攻擊者(A)向 ECU_r 發(fā)送偽造參數(shù)(CT_rs^A、R_rs^A 和 T_i2^A),則通過?T 和 R_rs 是否等于 R_rs^A 可直接識別。因此,在所提遠程幀傳輸請求協(xié)議(RFTRP)中,攻擊者(A)無法偽裝 ECU_s。
定理 3
所提遠程幀傳輸請求協(xié)議(RFTRP)在傳輸汽車指令時能夠保障消息機密性。
證明:攻擊者(A)希望在遠程幀傳輸請求協(xié)議(RFTRP)中獲取消息(M)。M 用于計算 CT_rs,因此,攻擊者(A)需要 R_rs、p_i、CT_rs 和 ID_ECU_s。攻擊者(A)可從 {CT_rs, R_rs, T_i2} 中獲取 R_rs 和 CT_rs,但不知道 p_i 和 ID_ECU_s。且若沒有 K_rs 和 ID_ECU_s,很難計算 p_i。因此,在所提遠程幀傳輸請求協(xié)議(RFTRP)中,由于缺少所有必要值,攻擊者(A)無法獲取 M。□
定理 4
基于隨機預言機模型(ROM),所提方案能夠抵御會話密鑰攻擊。
證明:我們假設攻擊者(A)想要通過充當 GECU,非法更新 ECU_i 和 GECU 之間的會話密鑰。因此,在這種情況下,ECU_i 充當挑戰(zhàn)者(C),以確認收到參數(shù)的真實性。攻擊者(A)需要計算 X_i [=h (ID_ECU_i || T_i1 || K_i || GK) ⊕ x_i] 和 Y_i [=h (GK || ID_ECU_i || x_i || ID_GECU)],以進行會話密鑰更新。我們假設攻擊者(A)作為內(nèi)部攻擊者獲取了 GK,但不知道 K_i(僅 ECU_i 和 GECU 知曉)。此外,攻擊者(A)需要 x_i 和 K_i 來計算 Z_i^A,以發(fā)送響應消息(即 {Z_i, T_i2}),用于會話密鑰更新確認。然而,GECU 將(GECU 端計算的)Z_i 與(攻擊者 A 發(fā)送的)Z_i^A 進行確認。若交互參數(shù)發(fā)生任何變化,則 Z_i 是否等于 Z_i^A 的驗證過程將失敗。因此,攻擊者(A)無法更新 GECU 和 ECU_i 之間的會話密鑰。表 2 總結了和 AutoSec 的對比分析,展示了不同屬性下的安全優(yōu)勢。方案基于組密鑰認證的概念,使得攻擊者能夠通過被攻陷的 ECU 發(fā)起認證攻擊。此外,由于第 i 次會話的加密密鑰對所有 ECU 都相同,會話密鑰可能會全部或部分泄露。而且,需要可信平臺模塊(TPM)來存儲關鍵值,而 AutoSec 不需要 TPM。由于 AutoSec 基于 SHA-512 構建,且每個會話中每個 ECU 的會話密鑰計算值都不同,因此 AutoSec 在各種安全屬性方面具有穩(wěn)健性。

表 2、CAN 數(shù)據(jù)傳輸方案的安全屬性對比
6、性能評估
消息通過 CAN 廣播,而 ECU 是資源受限的組件,用于處理 / 傳輸車載通信信息。因此,為了實現(xiàn)經(jīng)濟高效的汽車數(shù)據(jù)交換,需要考慮計算時間、通信開銷和能量消耗。在保障安全的同時,有必要減少不同加密運算和參數(shù)的數(shù)量,以獲得高效結果。因此,我們將所提方案與近年來在車載網(wǎng)絡(IVN)中使用 CAN 的相關方案進行比較。
6.1 測試平臺配置
自動駕駛車輛中的 ECU 硬件配置 64 位 ARM 內(nèi)核處理器以執(zhí)行計算,而樹莓派 3B+(Raspberry Pi 3B+)也基于 ARM 處理器設計。因此,我們采用包含兩個樹莓派 3B + 設備的測試平臺環(huán)境,以測量 AutoSec 的計算效率。樹莓派 3B + 的配置如下:1.4 GHz 四核 64 位 ARM Cortex-A53 處理器,搭載 BCM2837B0 芯片,1 GB 靜態(tài)隨機存取存儲器(SRAM),2.5 安培電源和 5 伏電壓供應。
6.2 結果分析
我們從計算時間、通信開銷和能量消耗方面,呈現(xiàn) AutoSec 和相關通信方案的性能結果,以分析它們在 CAN 通信中的效率。詳細解釋如下:
6.2.1 計算時間
計算時間基于數(shù)據(jù)傳輸階段執(zhí)行所需的加密運算的數(shù)量和類型計算。計算時間通常以毫秒(ms)為單位。為了計算不同運算的執(zhí)行時間,我們在樹莓派 3B + 平臺上,使用 Python 3.7 中的 Python 庫(即 pycrypto 和 py-ecc)執(zhí)行相應的加密運算(即 128 位 AES 加密 / 解密(AES)、帶有 256 位大質(zhì)數(shù)的橢圓曲線小規(guī)模乘法(ECSM)、SHA-512 [h (?)] 和 KDF_GK)。其中,KDF_GK 是基于 SHA-512 的密鑰派生函數(shù),生成兩個 512 位的密鑰值,在密鑰生成過程中實現(xiàn)更高的安全性。由于 h (?) 和 KDF_GK 的計算均采用 SHA-512,因此兩個函數(shù)的執(zhí)行時間相同。經(jīng)過 100 次運行后,AES 的平均執(zhí)行時間(T_AES)為 1.1410 毫秒,橢圓曲線小規(guī)模乘法(ECSM)的平均執(zhí)行時間(T_ECSM)為 3.0520 毫秒,h (?)/KDF_GK 的平均執(zhí)行時間(T_h (?)/KDF_GK)為 0.0014 毫秒。由于異或(⊕)和連接(||)的執(zhí)行時間極短,所有方案均未將其納入考慮范圍。方案在初始會話密鑰計算與驗證協(xié)議(ISCVP)中需要執(zhí)行 6T_h (?) + 2T_KDF,在遠程幀傳輸請求協(xié)議(RFTRP)中需要執(zhí)行 2T_AES + 2T_h (?),在會話密鑰更新協(xié)議(SKUP)中需要執(zhí)行 2T_AES + 3T_h (?) + 2T_KDF。協(xié)議設計在初始會話密鑰計算與驗證協(xié)議(ISCVP)中需要執(zhí)行 4T_h (?),在遠程幀傳輸請求協(xié)議(RFTRP)中需要執(zhí)行 4T_h (?) + 2T_AES,在會話密鑰更新協(xié)議(SKUP)中需要執(zhí)行 8T_h (?) + 4T_ECSM。
而 AutoSec 在初始會話密鑰計算與驗證協(xié)議(ISCVP)、遠程幀傳輸請求協(xié)議(RFTRP)和會話密鑰更新協(xié)議(SKUP)階段分別僅需要執(zhí)行 9T_h (?) + 2T_KDF、9T_h (?) + 2T_KDF 和 6T_h (?) + 2T_KDF。基于每個運算的平均執(zhí)行時間,我們計算了 Woo 等 [8]、帕拉尼瓦米等的方案以及 AutoSec 的計算時間,結果如圖 5 所示。由于 AutoSec 采用低成本且運算數(shù)量較少的設計,其計算時間相比方案更短。

圖 5:相關 CAN 通信方案的計算時間對比
6.2.2 能量消耗
車載網(wǎng)絡(IVN)中的數(shù)據(jù)交換需要執(zhí)行不同的運算,而會話密鑰更新在消息 / 密鑰生成和驗證過程中會消耗能量。因此,為了實現(xiàn)可持續(xù)發(fā)展的環(huán)境,有必要評估能量需求。能量消耗的計算公式為 EC_CO = T_CT?P_CPU,其中 EC_CO 表示能量消耗,T_CT 表示計算時間,P_CPU = V?I 表示 CPU 最大功率,V 表示電壓功率,I 表示電流。能量消耗以毫焦耳(mJ)為單位測量。由于采用樹莓派 3B + 作為實現(xiàn)平臺,CPU 最大功率為 12.5 瓦。通常,消息的通信階段(即 4.2 節(jié)中的初始會話密鑰計算與驗證協(xié)議(ISCVP)、遠程幀傳輸請求協(xié)議(RFTRP)和會話密鑰更新協(xié)議(SKUP))會針對不同操作常規(guī)執(zhí)行,而基本設置階段僅在初始時執(zhí)行一次。因此,消息通信的能量消耗在節(jié)能數(shù)據(jù)交換方案的設計中起著重要作用,我們計算了這些通信協(xié)議設計的能耗。圖 6 比較了方案以及 AutoSec 的能耗需求。由于 AutoSec 的計算時間相比方案更短,因此其能耗更低。

圖 6:相關 CAN 通信協(xié)議的能耗對比
6.2.3 通信開銷
發(fā)送方和接收方都需要交換不同的開銷參數(shù),以執(zhí)行初始會話密鑰計算與驗證、遠程幀傳輸請求和會話密鑰更新(見 4.2 節(jié))。傳輸這些參數(shù)的成本稱為通信開銷(以字節(jié)為單位),根據(jù)每個協(xié)議期間參數(shù)的類型和所需數(shù)量計算。單向哈希(即 SHA-512 h (?))、AES 加密(AES)、橢圓曲線乘法(ECMP)、隨機數(shù) / 身份標識(RN/ID)和時間戳(TS)分別需要 64 字節(jié)、32 字節(jié)、64 字節(jié)、12 字節(jié)和 8 字節(jié)。在 AutoSec 中,初始會話密鑰計算與驗證協(xié)議(ISCVP)、遠程幀傳輸請求協(xié)議(RFTRP)和會話密鑰更新協(xié)議(SKUP)的通信開銷分別為 280 字節(jié) [4h (?) + 3TS]、284 字節(jié) [4h (?) + 1ID + 2TS] 和 220 字節(jié) [3h (?) + 1ID + 2TS]。方案在初始會話密鑰計算與驗證協(xié)議(ISCVP)中的通信開銷為 236 字節(jié) [3h (?) + 1RN + 1AES],在遠程幀傳輸請求協(xié)議(RFTRP)中的通信開銷為 96 字節(jié) [1h (?) + 1AES],在會話密鑰更新協(xié)議(SKUP)中的通信開銷為 160 字節(jié) [2h (?) + 1AES];而方案在初始會話密鑰計算與驗證協(xié)議(ISCVP)、遠程幀傳輸請求協(xié)議(RFTRP)和會話密鑰更新協(xié)議(SKUP)中的通信開銷分別為 152 字節(jié)(2h (?) + 2RN)、160 字節(jié) [2h (?) + 1AES] 和 256 字節(jié) [2h (?) + 2ECMP]。圖 7 展示了相關工作的通信開銷對比研究。[8] 的初始會話密鑰計算與驗證協(xié)議(ISCVP)中,種子值和隨機數(shù)通過 CAN 總線廣播,這些值用作密鑰計算和驗證的輸入,使得被攻陷的 ECU(基于廣播值)能夠在后續(xù)執(zhí)行惡意活動。
盡管方案最小化了通信開銷,但在遠程幀傳輸請求協(xié)議(RFTRP)的消息交換過程中未提供雙向認證,且其協(xié)議設計僅能滿足 128 位安全級別。未使用時間戳,攻擊者可從會話密鑰更新協(xié)議(SKUP)中傳輸?shù)膮?shù)中推導出種子值,從而容易發(fā)起認證攻擊。方案將關鍵值以明文形式發(fā)送,且未使用時間戳,這降低了通信成本,但增加了數(shù)據(jù)交換過程中的安全漏洞,且該方案僅能實現(xiàn) 128 位安全級別。AutoSec 主要基于 SHA-512 構建,以滿足 256 位安全級別,并且在開銷參數(shù)交換過程中交換不同類型的值(即 SHA-512 和時間戳),能夠抵御 CAN 總線上的數(shù)據(jù)修改、信息泄露和消息新鮮度攻擊。因此,AutoSec 的通信開銷相比方案更高。然而,在其他關鍵性能指標方面(計算時間極短且能耗低),AutoSec 相比方案表現(xiàn)更優(yōu)(參見圖 5 和圖 6)。安全性和計算效率都是車載網(wǎng)絡的重要因素,AutoSec 在這兩方面取得了平衡,總體表現(xiàn)更優(yōu)。

圖 7、相關 CAN 通信機制的通信開銷對比
7、結論
本文提出一種用于 CAN 車載網(wǎng)絡的安全消息通信方案 AutoSec。AutoSec 利用 SHA-512、按位異或(XOR)和連接(concatenation)運算,提供安全的 CAN 消息傳輸。這些運算滿足車輛中資源受限 ECU 的高效計算和驗證需求。對 AutoSec 的有效性分析表明,該方案能夠保障用戶認證、消息完整性、消息機密性,并能抵御會話密鑰攻擊。所提方案采用低成本的加密運算執(zhí)行車載消息通信,無需進行硬件修改或網(wǎng)絡改進。通過與同類方案的對比分析,AutoSec 的性能評估結果表明,其在能量效率和低通信時間方面表現(xiàn)更優(yōu)。

(添加微信號NewCarRen咨詢)
