秦武韜,王鵬,李玉峰,2
(1.網絡通信與安全紫金山實驗室,江蘇 南京 211111;2.上海大學計算機工程與科學學院,上海 200444)
隨著新一輪科技革命的蓬勃發展,網絡通信技術、深度學習技術、計算機技術等不斷進步,并與傳統汽車技術相結合,使智能網聯汽車快速發展,大量網聯汽車逐漸步入人們的日常生活中[1-2]。智能網聯汽車在帶來巨大便利的同時,導致針對汽車的各種攻擊入口被打開,用戶、車輛、環境等海量隱私或敏感信息存在被非法竊取的巨大風險,不僅帶來了巨大的網絡安全問題,也使傳統的功能安全問題與網絡安全問題相互交織,引發復雜的廣義功能安全問題[3-5]。
車內通信安全是汽車廣義安全的重要組成部分,一旦通信安全受到威脅,輕則導致隱私泄露、財產損失,重則導致汽車故障、車輛惡意被控,引發行車安全及其他惡性事件[6]。在車內通信網絡中,控制器局域網絡(CAN)總線憑借簡單、輕量化、可靠性好、布線靈活、成本低等優勢,一直是車內通信網絡的主力軍,連接著動力域、車身域等車內各個域(如圖1 所示),承擔著絕大多數的通信任務,特別是包含位置、速度、轉向、發動機轉速等有關行車安全的信息[7]。

圖1 車內CAN 架構
然而,基于CAN 總線的通信是一種廣播形式的網絡通信,出于輕量化和快速響應的考慮,CAN總線在設計階段沒有應用加密技術,因此通過一些手段可以輕易地獲取總線上傳輸的真實信息,不僅導致車內各類數據極易泄露,而且攻擊者可以利用這些信息對網絡上的其他單元進行攻擊,嚴重危害車輛安全[8]。因此,在智能網聯化的今天,必須對CAN 傳輸的數據進行加密處理。
智能網聯汽車的信息傳輸和車輛的安全控制要求車內數據傳輸必須具有低時延的特點,而CAN總線本身的數據傳輸能力相對較弱,且具有固定的數據格式,每個標準幀所能傳輸的數據固定為8 字節(64 位),這就要求在對CAN 數據進行加密時需采用快速、輕量化的分組加密方法,加密前后數據長度不變,不增加CAN 總線的傳輸負擔,不改變原有數據的傳輸節奏和格式。
此外,CAN 總線的廣播形式使一個車載單元(OBU,on board unit)被攻破俘獲,則所有經CAN總線傳輸的數據均會泄露。如果簡單采用同樣的分組對稱密碼進行加密,將使所有經CAN 總線傳輸的數據面臨“全軍覆沒”的巨大風險。如果各OBU 兩兩之間分配密鑰,盡管可以確保數據傳輸的保密性,但會帶來大量的密鑰,如果同一數據需要發送至n個OBU,則需要重復加密、傳輸n次,帶來了極大的計算量和沉重的總線傳輸負擔,這在當前CAN 總線傳輸負載率已經較高的情況下并不現實,將顯著增加傳輸時延,危害行車安全。
因此,需要設計一種輕量化、低時延的加密策略,在不顯著增加計算量、數據傳輸量的情況下確保CAN 總線傳輸的密文僅能被數據發送的目標單元解密,即同時滿足以下3 個特點。1) 輕量化、低時延,確保高效加解密;2) 報文數據64 bit 分組加密,不改變原有傳輸節奏和格式;3) 針對性地加解密,非目標數據用戶無法得到明文信息。
在現有的CAN 數據加密方法中,1977 年由美國政府頒布的數據加密標準(DES,data encryption standard)具有典型代表性[9],DES 為64 bit 分組對稱加密,分組位數與CAN 標準幀中的數據長度(如圖2 所示)一致,應用簡單方便、適用性強,但隨著現代計算能力的提升存在著暴力破解的風險;而基于DES 的改進算法3DES 通過多次加解密運算提升了安全性[10],但加密的計算量大幅增加,加密時間是DES 算法的3 倍多。因此,美國政府頒布了高級加密標準(AES,advanced encryption standard)用于取代DES[11-12],AES 算法由于其出色的安全性和較小的計算量,已經成為主流的對稱加密算法,但其要求明文長度至少達到128 bit,超過了CAN 數據幀的64 bit,無法直接應用。一種典型解決方法是利用64 bit 空白報文補位至128 bit,再利用AES進行加密處理,生成128 bit 的密文后連續發送兩幀,接收方則連續接收兩幀后再進行解密,但該方法明顯存在著加解密計算量和總線數據傳輸量翻倍的問題[13];另一種方法則是通過累積兩幀數據幀補位至128 bit,再利用AES 進行加解密,但該方法的奇數拍報文必須等待偶數拍報文配對后才能發送,增加了奇數拍報文的等待時間,帶來了時延的不確定性。

圖2 標準幀數據格式
此外,現有的CAN 數據加密算法直接對明文數據進行處理,在明文出現之前不進行預加解密計算,所有計算累積到加密或解密請求出現后,未能充分利用離線段的計算能力,增大了在線段的運算負擔和加解密時延。同時,現有的CAN 總線數據加密方法仍采用簡單的對稱密碼設計思路,各OBU通過預設相同的密碼來實現數據的加解密,增加了數據泄露的風險,無法滿足CAN 總線傳輸中針對性加解密的需求。
因此,本文面向CAN 報文加解密快速響應需求,利用CAN 總線周期性傳輸特點,提出一種基于在線-離線處理的組合加密方法,如圖3 所示。首先,利用OBU 的身份屬性制定訪問策略對分組密碼進行加密、分發,確保僅有目標OBU 可以完成密碼解密,獲取分組密碼。然后,對CAN 報文加解密方法進行在線離線處理改造,其中,在離線階段利用AES 算法動態生成8 字節會話密鑰,在線段則利用會話密鑰通過異或運算迅速響應數據的加解密需求,實現高速、輕量化、64 位分組和針對性加解密,同時滿足智能網聯汽車CAN 報文加解密的3 個需求。

圖3 與周期耦合的在線離線加解密模式
AES 加解密流程如圖4 所示。從圖4 中可以看出,其核心運算主要包括輪密鑰加、字節代換(逆字節代換)、密鑰擴展、行移位(逆行移位)、列混合(逆列混合)5 種,具體方法介紹如下。

圖4 AES 加解密流程
1) 輪密鑰加。如圖5 所示,將數據逐個與本輪相應密鑰進行異或運算。其中,m為待運算數據,k為本輪密鑰,c為異或運算結果。

圖5 輪密鑰加
2) 字節代換(逆字節代換)。把輪密鑰加后產生的每一個字節用十六進制表示,然后以十六進制的第一個數字為行,第二個數字為列,在S 盒[14]表中查找對應的數字代替原先的數字,完成字節代換。逆字節代換則從逆S 盒中查找元素替代。
3) 密鑰擴展?;?6 字節原始密鑰,按順序以每4 字節為一組,按位進行依次連接,獲得第一輪密鑰W[0]、W[1]、W[2]、W[3]。對于后續輪密鑰,采用如圖6 所示的方法進行計算,即

圖6 密鑰擴展

其中,T (·)為包括字循環移位、字節替換和輪常量異或運算的非線性函數[11]。
4) 行移位(逆行移位)。把字節代換得到的矩陣逐行進行左環移,逆行移位則與行移位相反。
5) 列混合(逆列混合)。利用給定矩陣對上一步獲得的矩陣進行變換,其中,列混合為

針對車內CAN 網絡數據加密64 位分組、輕量化、低時延、針對性解密的需求,本文提出一種與CAN 總線通信周期耦合的組合加密方案,具體流程如圖7 所示。

圖7 在線離線處理的組合加密流程
組合加密方案由兩部分組成,一部分為基于屬性的分組密碼加密方法,確保用于CAN 報文加密的分組密碼僅由目標數據用戶獲得,防止加密信息擴散,避免某一單元被攻破后全車信息泄露。
另一部分為基于分組加密方法的CAN 報文數據加密,該方法利用AES 算法動態生成8 字節會話密鑰,實現分組對稱加密,密文與明文長度不變,實現了數據傳輸節奏和格式的穩定。
此外,在加解密過程中,使用了在線離線處理技術,將計算量大、不依賴實時報文信息的計算放入通信間歇的離線段進行,可大幅度降低計算時延。本文方案具體內容介紹如下。
該方法首先根據確定的報文收發OBU 確定收發組,在本收發組第一幀CAN 報文發送前,利用基于身份屬性加密方案對分組密碼mkey進行加密,確保僅有目標數據用戶可完成解密獲得分組密碼mkey,確保后續報文的安全。具體步驟介紹如下。
1) Ex.SysAtt():收集汽車各OBU 的屬性,包括所屬域、單元類型、種類、編號等,如自動駕駛域、傳感器、相機、1,確定系統屬性集U= {u1,u2,…,uu}。
2) Ex.Setup(τ,U):進行設置,輸入安全選取的隱含安全參數τ與各OBU 單元屬性集合U,計算公鑰PK 和主私鑰MSK

其中,g為G1的生成元,G1為雙線性映射概念下的循環群,其元素包括γ1,γ2,…,γ u,相關概念可參考文獻[15],隨機參數a,b∈ Zp。
3) Ex.KeyGen(MSK,PK,S):根據各OBU 屬性,利用主私鑰MSK 和公鑰PK 生成相應私鑰,預設至各組件中,對于第k個組件,其私鑰為

其中,1,2,…,s表示OBU 屬性集S中的屬性標號,L表示私鑰的組成參數,用于后續解密,?(i)表示第k個OBU 的屬性到系統屬性集U中元素的映射,隨機參數t∈Zp。
以上三步均在系統聯網實驗前完成,確保各私鑰安全裝訂。
4) Offline.EncryptKey(PK):在離線段,數據發送OBU 選擇隨機數r∈Zp,利用公鑰PK 計算中間密文ICkey。

5) Online.EncryptKey(PK,ICkey,mkey,(M,ρ),v):此時已經確定密鑰明文mkey和訪問控制策略(M,ρ),利用中間結果完成加密,輸出密文Ckey。

針對傳統分組對稱加密方法加密安全性不足、最小加密長度與CAN 數據長度不匹配、缺乏在線離線處理導致在線段計算負擔過重等問題,本節給出一種基于在線離線AES(OOAES,online-offline AES)的CAN 報文分組加密方法,具體流程如圖8所示。該方法在離線階段利用128 位AES 分組密碼對由計數器和上一幀明文信息構成的配對信息進行預加密,通過截取8 字節密文生成動態會話密鑰,等待加密請求;在線段則利用動態會話密鑰通過異或運算對8 字節的CAN 數據進行加密,生成8 字節密文通過CAN 網絡進行傳輸。

圖8 加解密處理流程
圖8 中,mkey是長度為16 字節的AES 分組密碼,由數據加密方自定義;配對信息是長度為16 字節的明文信息,由8 字節的循環計數器和上一數據幀CAN 數據的明文消息構成,對于初始幀則采用事先約定的消息,如{00 00 00 00 00 00 00 00}。
利用AES對16字節配對信息進行加密處理后,獲得16 字節長度的AES 密文。在CAN 標準數據幀中,數據長度為8 字節,因此可從16 字節的密文中截取8 字節構成動態會話密鑰G,利用8 字節的會話密鑰G與CAN 明文進行異或加密運算獲得8 字節的CAN 密文進行傳輸。解密流程與加密流程相似,區別在于解密流程利用動態會話密鑰與經CAN 總線傳輸的密文進行異或解密運算,獲得明文完成解密。
在CAN 報文的加解密過程中,充分設計了在線離線的處理方法。對于加密過程,系統啟動后,首先在離線階段完成預加密計算,獲得加密會話密鑰G;當CAN 明文生成并觸發加密請求時,進入在線段,此時利用G對明文進行快速加密,生成密文數據并發送;加密過程隨后進入離線階段,更新配對信息并進行預加密,生成新的會話密鑰等待CAN 報文數據。解密過程與加密過程類似,系統啟動后,首先在離線階段完成預解密計算,獲得解密會話密鑰G;當接收到CAN密文數據時,進入在線段,運行異或運算恢復明文數據;完成解密后進入離線階段,更新配對信息進行預解密,生成新的解密會話密鑰等待CAN密文數據。
通過在線-離線加解密處理方法的運用,顯著減少了在線段的運算量,節約了運算時間,將巨大的預加密計算工作前置到了計算資源相對空閑的離線階段,確保了在線段能快速響應加密和解密請求,大幅降低了加解密帶來的時延。
為了驗證加解密的正確性,生成1 000 幀描述汽車速度變化的CAN 報文,對比數據非加密傳輸和使用本文提出的CAN 報文加密方法進行加密傳輸的結果,分別如圖9 和圖10 所示。

圖9 非加密網絡數據

圖10 加密網絡數據
從圖9 和圖10 中可以看出,對于未采用加密處理的CAN 報文傳輸方法,可以輕易從網絡端竊取汽車真實的速度數據,不具備傳輸的安全性;而采用加密處理后的數據呈現出類似于高斯噪聲的不規則變化,趨勢、結果與真實數據明顯不同。接收端獲取的結果與發送端一致,證明本文所提加密方法可以有效準確地對CAN 數據進行加解密,確保了CAN 網絡傳輸數據的安全性。
雪崩效應是指明文或密鑰發生微小變化時,密文會出現不可區分的改變,理想情況是每個二進制位有50%的概率發生翻轉。本節將分別進行密鑰雪崩效應測試和密文雪崩效應測試,其中,密鑰雪崩效應測試中將128 位密鑰的最后一位翻轉,觀測密鑰翻轉前后1 000 幀CAN 密文二進制位的翻轉概率;密文雪崩效應測試中將CAN 報文中速度數據的最后一位翻轉,觀測翻轉前后1 000 幀密文的翻轉概率。圖11 給出了1 000 幀報文的雪崩率曲線,圖12 給出了密鑰雪崩率和密文雪崩率統計,表1 給出了雪崩效應特性的測試統計結果。圖12 中,橫坐標表示組別,組1為密鑰調整帶來的雪崩率,稱為“密鑰-雪崩率”,組2 為明文調整帶來的雪崩率,稱為“明文-雪崩率”。從圖12 中可以看出,本文方法具有優異的雪崩特性效應,密文二進制翻轉概率約為50%,達到了某一位微小的輸入變化使輸出發生不可區分改變的效果。

圖11 1 000 幀報文雪崩率

圖12 密鑰雪崩率和密文雪崩率統計

表1 雪崩效應特性測試結果
基于3.1 節生成的1 000 幀CAN 報文數據,分別利用DES、3DES、AES 和OOAES 在一臺搭載i5-9400 @2.9 GHz 處理器的windows 10 機器上進行 500 次蒙特卡羅仿真實驗,編程語言為C++11,統計加解密總耗時和明文出現后的在線段耗時。其中,加密時長定義為加密運算階段耗時,即各個加密運算步驟耗時之和;解密時長定義為解密運算階段耗時,即各個解密運算步驟耗時之和;在線運行時長等于加密在線運行時長和解密在線運行時長之和,表示明文出現后轉換為密文的時間和密文出現后轉換為明文的時間。在實驗中,利用C++chrono 庫中的steady_clock 函數統計1 000 次加解密的耗時之和,以減少單次統計的不必要誤差。
在仿真結果中,圖13 和圖14 分別給出了總耗時和在線段耗時對比,表2 給出了各階段耗時的平均統計結果。從圖13、圖14 和表2 可以看出,本文提出的OOAES 具有良好的全程計算效率和極其優異的在線段計算效率,主要體現在以下兩點。

表2 1 000 幀CAN 報文加解密各階段耗時的平均統計結果

圖13 1 000 幀報文加解密總耗時對比

圖14 1 000 幀報文加解密在線段耗時對比
1) OOAES 的加解密總耗時遠小于常規AES 算法。OOAES 的加密部分與常規AES 基本一致,該部分單幀耗時大致相同,約為14 μs,但AES 的解密部分運算量很大,單幀耗時達到65 μs。OOAES繞過AES 的解密模塊,仍然利用加密方法生成解密所采用的動態會話密鑰,大大降低了解密計算量,單幀解密耗時僅14 μs,獲得了更優異的加解密總耗時成績。
2) OOAES 的在線段耗時呈指數級降低。常規的DES、3DES、AES 等方法直接對明文(密文)進行加密(解密)處理,在未獲取明文(密文)前的離線段缺乏預加密工作,導致所有加解密計算累積到加解密需求出現后,使在線段的計算負擔巨大,增加了CAN 報文數據產生到解密段的時延。從測試結果看,DES、3DES 和AES 的在線段單幀計算耗時分別達到了8.3 μs、24.3 μs 和79.4 μs,而采用了在線-離線處理技術的OOAES方法將大量計算前移至離線段,在線段僅利用動態會話密鑰進行異或加解密運算,計算量指數級減小,每千幀在線段耗時僅為85 μs,單幀耗時為0.085 μs,領先DES 和AES 2~3 個數量級,單幀CAN 報文加密接近零時延,可以做到“即請求,即加(解)密”。
為了進一步驗證本文提出的方法在車載系統的可行性和有效性,利用一款搭載Arm Cortex-A53 max @1.2 GHz的車載旭日X3芯片進行不同消息周期CAN 報文的加解密分析。
基于上述軟硬件條件,進行1 000 組不同CAN消息周期的仿真實驗,每組仿真所采用的數據均為1 000 幀8 字節CAN 報文信息,消息周期根據文獻[17]給出的統計規律隨機采樣,確保小于10 ms周期的實驗組數占比約為41%,10~20 ms 周期的實驗組數占比約為31%。單幀CAN 報文加解密平均計算耗時分布如表3 所示。

表3 單幀CAN 報文加解密平均計算耗時分布
圖15 給出了單幀加解密平均耗時分布。從圖15可以看出,相較于運算能力更強的Intel i5 芯片,基于車載旭日X3 芯片的加解密計算耗時有所增加,但單幀數據的加解密平均耗時仍然不超過0.75 ms(圖 15 中超過0.75 ms 的平均耗時占比為0),顯著小于CAN 消息周期,具有良好的可行性。為了進一步分析CPU 計算資源占用情況,實驗中同步統計了加解密過程中的CPU 占用率。

圖15 單幀加解密平均耗時分布
圖16 給出了不同消息周期下CPU 利用率的情況。從圖16 可以看出,消息周期越長,CPU 利用率越低;消息周期越短,CPU 利用率越高。這是因為一定時間內,加解密的計算負擔隨著消息收發頻率的增加而增加。盡管如此,從圖17 可以看出,CPU利用率超過4%的情況很少,占比不超過1%,事實上,在本次仿真中也僅出現一次,利用率為4.027 5%,這說明本文提出的OOAES 計算資源占用有限,對其他應用的影響不大。

圖16 不同消息周期下CPU 利用率的情況

圖17 CPU 利用率分布
根據車內CAN 總線對數據加密低時延、輕量化、分組、針對性保密的需求,設計了基于在線離線處理的組合加密方法。該方法首先利用身份屬性對分組密碼進行加密分發,確保僅數據目標OBU 可以完成密碼解密,避免單一OBU 攻破后全車信息泄露的風險。基于在線離線處理框架設計基于AES 的CAN 報文分組加密方法,巧妙地利用離線段進行預加密計算,生成8 字節動態會話密鑰,不僅解決AES 最小加密長度與CAN 報文長度不匹配的問題,更實現量級地降低在線段加(解)密時長,具備報文數據“即請求、即加(解)密”的能力。