朱立民 李仁發(fā)

（1.吉利汽車研究院（寧波）有限公司，寧波 315000；2.湖南大學(xué)，長沙 410000）

主題詞：信息安全 AES加密算法 智能駕駛 CAN網(wǎng)絡(luò)協(xié)議

1 前言

智能網(wǎng)聯(lián)汽車與其他車輛、基礎(chǔ)設(shè)施等通信的過程中，其內(nèi)部網(wǎng)絡(luò)與外界產(chǎn)生大量數(shù)據(jù)交換，如果汽車外部通信網(wǎng)絡(luò)信道被劫持，則使得針對汽車的網(wǎng)絡(luò)攻擊成為可能。

2007年，波鴻魯爾大學(xué)的Wolf等人分析了汽車可能遭受的網(wǎng)絡(luò)攻擊類型并提出了對應(yīng)的防御措施[1]。華盛頓大學(xué)的Koscher提出了特定的無線網(wǎng)絡(luò)攻擊技術(shù)，展示了智能汽車面臨的網(wǎng)絡(luò)安全問題，即當裝有特定惡意軟件的手機與汽車藍牙設(shè)備相連接，展開短距離無線攻擊即成為可能[2]。Brooks等人將可接入汽車網(wǎng)絡(luò)的通訊手段進行分類，利用CERT分類法分析針對車載服務(wù)的攻擊，結(jié)果表明，ECU中的固件升級時需要特定的安全保護，且需防范車輛與網(wǎng)絡(luò)中心融合帶來的安全隱患[3]，如遠程診斷服務(wù)。Schweppe等人[4-5]建議利用EVITA-HSM建立安全通信結(jié)構(gòu)，采用32 bit消息認證碼（Message Authentication Code,MAC），車內(nèi)網(wǎng)絡(luò)總線的特性使其可以抵擋持續(xù)35周的碰撞攻擊，因此是足夠安全的。然而，作者提出的安全架構(gòu)過于抽象，既沒有表述如何產(chǎn)生32 bit的MAC，也沒有考慮到數(shù)據(jù)機密性和外部設(shè)備的連通性。為了保護車內(nèi)網(wǎng)絡(luò)免于遭受重放攻擊（指當攻擊者嗅探到數(shù)據(jù)消息和認證消息后，將這些內(nèi)容重復(fù)放入CAN總線發(fā)送至目標ECU而達到攻擊的效果）。Groza和Marvay提出一種類似TESLA協(xié)議的具有消息認證功能的CAN總線協(xié)議[6]。Woo展開了一次遠程無線攻擊車輛的試驗，并根據(jù)CAN總線的特性提出一種安全CAN總線協(xié)議，結(jié)果顯示該協(xié)議在通信延遲和負載方面表現(xiàn)較好[7]。

為了對車輛網(wǎng)絡(luò)數(shù)據(jù)進行有效保護，需要從數(shù)據(jù)的機密性和可認證性兩方面進行考慮。本文以車輛內(nèi)部網(wǎng)絡(luò)為研究視角，提出一種安全CAN總線協(xié)議對數(shù)據(jù)進行保護，使車內(nèi)網(wǎng)絡(luò)不能通過外部接口被利用，從而有效抵制汽車網(wǎng)絡(luò)攻擊。

2 研究基礎(chǔ)

智能汽車通常搭載百余個ECU通過各類數(shù)據(jù)總線連接在一起，如CAN、LIN、MOST和FlexRay總線，其中CAN總線應(yīng)用最為廣泛。然而，CAN總線不具備數(shù)據(jù)的機密性和可認證性，總線上的惡意節(jié)點可以監(jiān)聽總線上的所有消息，甚至可以向其他節(jié)點發(fā)送惡意消息。因此，本文提出基于高級加密標準的計數(shù)器模式和密碼塊鏈消息認證碼（Advanced Encryption Standard Counter with CBC-MAC，AES-CCM）算法的安全CAN總線協(xié)議以抵御外界網(wǎng)絡(luò)攻擊。

2.1 設(shè)計前提

針對智能汽車特殊的應(yīng)用場景，安全CAN總線設(shè)計需保證3個前提：

a.安全協(xié)議不能增添過大的載荷。如圖1所示，CAN數(shù)據(jù)幀的長度為16 Byte，其中數(shù)據(jù)域只有8 Byte。目前CAN總線的數(shù)據(jù)域已經(jīng)有很高的利用率，為確保足夠的安全性，MAC的長度至少為4 Byte，則CAN數(shù)據(jù)幀的有效載荷將減小一半，因此，此方法不符合應(yīng)用場景。

圖1 傳統(tǒng)CAN總線協(xié)議

b.安全協(xié)議不能依靠很強的計算能力和存儲能力。通常，車載ECU是具有有限資源的微控制器，如果設(shè)計中需要大量的數(shù)據(jù)計算和存儲，普通ECU難以保證實時性。例如，非對稱加密算法RSA算法不但具有很強的機密性而且具有認證性[8]，符合本文的設(shè)計目的，但受ECU的限制不能應(yīng)用于CAN總線上。

c.安全協(xié)議不能造成任何硬件修改。如果安全協(xié)議需要進行硬件修改，將造成成本增加、可移植性降低以及設(shè)計復(fù)雜化。安全協(xié)議的實現(xiàn)應(yīng)在傳統(tǒng)CAN控制器和CAN接收器的硬件基礎(chǔ)上對協(xié)議本身進行修改，相比于EVITA項目中提出在汽車設(shè)計時增添硬件安全模塊的策略[5]，單純的協(xié)議修改更容易被汽車制造商所接受。

2.2 設(shè)計思路

通過總結(jié)當前存在的針對智能汽車的網(wǎng)絡(luò)攻擊類型[2]，Samuel Woo指出通過修改CAN總線等車內(nèi)網(wǎng)絡(luò)總線，使其具備機密性和可認證性即可抵御各種類型的網(wǎng)絡(luò)攻擊[7]。為實現(xiàn)CAN總線的機密性和可認證性，需要滿足：ECU發(fā)送節(jié)點與ECU接收節(jié)點間必須以密文形式通信；包含MAC的數(shù)據(jù)幀只能由可信任的ECU發(fā)送節(jié)點生成；ECU接收節(jié)點可以驗證MAC的正確性；不能存在相同值的MAC。

AES算法與CCM模式的結(jié)合不但可以滿足設(shè)計中對機密性和可認證性的要求，AES-CCM算法還具有加密速度快、安全性能高、計算量低和所需存儲空間小的優(yōu)勢。本著設(shè)計簡單、高效和易實現(xiàn)的初衷，本文設(shè)計的安全CAN總線協(xié)議將保持傳統(tǒng)CAN總線的幀格式。

從機密性方面考慮，AES-CCM算法可利用128 bit的密鑰產(chǎn)生密文，安全性可以得到保證。但AES-CCM算法是分組加密算法，其分組大小為128 bit，而CAN總線的數(shù)據(jù)場最大只有64 bit，因此采用補位的方案，即所需加密數(shù)據(jù)小于128 bit時，進行補零操作以滿足AESCCM算法的分組長度需求。

從可認證性方面考慮，用MAC替換16 bit的循環(huán)冗余校驗（Cyclic Redundancy Check，CRC）域既可以提供數(shù)據(jù)完整性，也可以提供數(shù)據(jù)可認證性，即MAC可以檢測數(shù)據(jù)幀中的惡意數(shù)據(jù)破壞，也可以檢測數(shù)據(jù)傳輸錯誤，因此CRC場完全可以被MAC場取代。AES-CCM算法可以產(chǎn)生所需要的MAC，并可根據(jù)需要得到4 Byte、6 Byte和8 Byte等不同長度的MAC（本文采用4 Byte）。AES-CCM算法在MAC生成過程中引入隨機數(shù)，即每次加密產(chǎn)生的MAC均不相同，因此本節(jié)設(shè)計的安全CAN總線可以抵御攻擊者嗅探到有效數(shù)據(jù)幀對汽車進行的重放攻擊。

3 設(shè)計方案

根據(jù)應(yīng)用背景不同，本文提出2種設(shè)計方案實現(xiàn)安全CAN總線協(xié)議。

3.1 方案一

3.1.1 數(shù)據(jù)幀發(fā)送

如圖2所示為方案一的安全CAN總線協(xié)議示意，共有3個ECU接入CAN總線?？偩€呈多主機通信，每個ECU既可作為發(fā)送節(jié)點，也可作為接收節(jié)點。當ECU需要發(fā)送數(shù)據(jù)幀且總線空閑時，即可發(fā)送。

數(shù)據(jù)幀發(fā)送前，ECU2將至多128 bit的明文P、附加消息A和隨機數(shù)N組合進行格式化函數(shù)操作，然后利用高級加密標準的密碼塊鏈接（AES-Cipher Block Chaining，AES-CBC）算法生成T（即MAC）：

圖2 方案一的安全CAN總線協(xié)議示意

T的長度為32 bit，標準數(shù)據(jù)幀中CRC場的最大長度為16 bit，因此連續(xù)2個標準幀可以實現(xiàn)T替換CRC場。ECU2通過高級加密標準的計數(shù)器模式（AESCounter mode，AES-CTR）算法生成密文C：

至多128 bit的密文C和32 bit的T經(jīng)過簡單處理組成消息R，最終由連續(xù)的2個標準幀傳送至目標節(jié)點ECU3。

通過AES-CCM加密算法對原始數(shù)據(jù)的處理，連續(xù)的2個標準幀構(gòu)成了1個具有機密性和可認證性的安全CAN總線數(shù)據(jù)幀，完成方案一的安全CAN總線數(shù)據(jù)幀的發(fā)送。其中AES-CCM加密的過程為：

輸入：N、A、P

輸出：R

1.Formatting Function(N、A、P)->B0,B1,…Br

2.Y0=CIPHk(B0)

3.for i from 1 to r

4.Yi=Ek(B0⊕Yi-1)

5.T=MSBTlen(Yr)

6.Counter Generation Function(N)->Ctr0,Ctr1,…Ctrm

7.for j from 0 to m

8.Sj=CIPHk(Ctrj)

9.S=S1||S2…||Sm（“||”表示連接運算）

10.Return R=(P⊕MSBPlen(S))||(T⊕MSBTlen(S0))

3.1.2 數(shù)據(jù)幀接收

如圖3所示，當目標節(jié)點ECU3從CAN總線上接收到來自ECU2連續(xù)的2個標準幀（單個安全數(shù)據(jù)幀）時，ECU3將數(shù)據(jù)場和CRC場中的內(nèi)容組合成為AES-CCM解密算法中的輸入?yún)?shù)R，另外的2個輸入?yún)?shù)為附加消息A和隨機數(shù)N（均預(yù)先存于ECU的ROM中）。通過AES-CCM解密算法，ECU3得到明文P、MAC和來自ECU2的T。將MAC與T進行一致性驗證，如通過驗證則返回明文P，否則丟棄明文并返回錯誤提示。AESCCM算法解密的過程為：

輸入：N、A、R

輸出：P or INVALID

1.if Clen

2.Return INVALID

3.else

4.Counter Generation Function()->Ctr0,Ctr1,…Ctrm

5.for j from 0 to m

6.Sj=CIPHk(Ctrj)

7.S=S1||S2…Sm

8.P=MSBClen-Tlen(R)MSBClen-Tlen(S)

9.T=LSBTlen(R)MSBClen-Tlen(S0)

10.if N or A or P not valid

11.Return INVALID

12.else

13.Formatting Function(N、A、P)->B0,B1,… Br

14.Y0=CIPHk(B0)

15.For i from 1 to r

16.Yj=CIPHk(Bi Yi-1)

17.if T MSBTlen(Yr)

18.Return INVALID

19.else

20.Return P

3.2 方案二

CAN總線協(xié)議包含2類數(shù)據(jù)幀，即標準幀和擴展幀，其不同點主要為ID場的長度，標準幀的ID長度為11 bit，擴展幀的幀ID長度為29 bit，如圖3所示為CAN標準幀與擴展幀的對比。對于標準幀數(shù)據(jù)，可用擴展幀發(fā)送，即取其ID場中11 bit作為標準幀ID場，其余18 bit作保留位。本文中，方案二利用擴展幀發(fā)送標準幀數(shù)據(jù)，利用保留位中的16 bit發(fā)送MAC，其余置零。同時，CRC場用于搭載另外16 bit的MAC。最終由1個擴展幀構(gòu)成的安全CAN總線數(shù)據(jù)幀可以發(fā)送32 bit的MAC和至多64 bit的密文。

圖3 標準幀與擴展幀對比

如圖4所示為方案二的安全CAN總線協(xié)議示意，在數(shù)據(jù)幀發(fā)送前，發(fā)送節(jié)點ECU2將明文P、隨機數(shù)N和附加消息A作為輸入進行AES-CCM算法的加密，得到MAC和密文。利用1個擴展幀作為單個安全CAN總線數(shù)據(jù)幀進行消息發(fā)送，其中32 bit的MAC由擴展ID場和CRC場共同發(fā)送，8 Byte的數(shù)據(jù)場用于發(fā)送密文。

圖4 方案二的安全CAN總線協(xié)議示意

對于安全CAN總線數(shù)據(jù)幀的接收，當節(jié)點ECU3在總線上監(jiān)測到擴展幀時，將CRC場和擴展ID場共同搭載的32 bit MAC、隨機數(shù)N和附加消息A作為AES-CCM解密算法的輸入。解密過程中，ECU3對MAC進行認證，認證通過則返回正確明文，否則拋棄該數(shù)據(jù)幀并返回錯誤提示。

3.3 對比分析

兩種方案均在傳統(tǒng)CAN總線協(xié)議的基礎(chǔ)上，利用AES-CCM算法作為加密算法實現(xiàn)安全CAN總線協(xié)議，具備機密性、可認證性和抗重放攻擊的能力，均采用128 bit的密鑰和32 bit的MAC，利用傳統(tǒng)CAN總線的CRC場來發(fā)送MAC。兩種方案均未對傳統(tǒng)CAN總線添加任何硬件模塊且沒有對協(xié)議的數(shù)據(jù)格式進行修改，具有良好的兼容性。

在方案一中，消息的可認證性需要發(fā)送節(jié)點和接收節(jié)點同步操作，數(shù)據(jù)幀MAC認證需要接收節(jié)點取得完整的安全CAN數(shù)據(jù)幀單元后才可以進行，即存在認證延遲。同時，同步過程中數(shù)據(jù)幀的丟失將造成認證失敗。而在方案二中，密文和MAC的發(fā)送僅需1個擴展幀即可完成，因此可以有效避免認證延遲和因幀丟失造成認證失敗的問題，并且其通訊負載也將有所降低。然而，方案二的實現(xiàn)會導(dǎo)致擴展幀ID場長度由29 bit降低至11 bit，即僅支持標準ID場長度。

綜上所述，兩種方案有著相同的安全功能和安全等級。兩者的區(qū)別主要體現(xiàn)在是否存在認證延遲，方案二高效利用了傳統(tǒng)CAN總線協(xié)議，可以通過1個擴展幀來實現(xiàn)安全CAN總線協(xié)議數(shù)據(jù)幀，消除了認證延遲。因此，對于標準數(shù)據(jù)幀的發(fā)送，方案二更加具有優(yōu)勢。

4 試驗驗證

4.1 試驗平臺

本文采用2塊16 bit飛思卡爾汽車開發(fā)板MC9S12XF512作為硬件開發(fā)平臺，軟件開發(fā)平臺為飛思卡爾工具包CodeWarrior Version 5.0。開發(fā)板通過BDM下載器與PC機連接下載二進制代碼，同時通過USBCANⅡ采集CAN總線上的數(shù)據(jù)。開發(fā)板通過LCD顯示屏和串口調(diào)試軟件顯示內(nèi)部數(shù)據(jù)。圖5所示為安全CAN總線協(xié)議的試驗平臺。

圖5 安全CAN總線協(xié)議試驗平臺

4.2 性能分析

通常，ECU的CRC接口在出廠時會被屏蔽，用戶不可以對CRC場進行任何修改。為了完成對安全CAN總線協(xié)議的性能評測，對方案二進行適當調(diào)整。車載ECU發(fā)送的CAN消息一般為8 Byte，本文設(shè)定CAN消息為6 Byte，其余2 Byte仿真CRC場發(fā)送MAC。

本節(jié)通過選取1組具體示例來驗證方案的可行性。設(shè)定密鑰K長度為128 bit，隨機數(shù)N長度為56 bit，明文P長度為 48 bit，附加消息A長度為 64 bit：

根據(jù)AES-CCM加密算法進行理論推導(dǎo)，得到6 Byte CipherText和4 Byte MAC：

試驗中，發(fā)送節(jié)點和接收節(jié)點在啟動后立即進入初始化模式，初始化完畢后進入工作模式，并通過LCD顯示已接入CAN總線。發(fā)送節(jié)點ECU將P、K、N、A通過AES-CCM算法生成CipherText和MAC，發(fā)送安全CAN總線協(xié)議數(shù)據(jù)幀（幀ID為10001000100，占用擴展幀的第4～14 bit）至總線。全部6 Byte密文和MAC前2 Byte通過擴展幀數(shù)據(jù)場發(fā)送，MAC后2 Byte通過擴展幀的第15～30 bit發(fā)送。

如圖6所示為USBCANⅡ監(jiān)測到的安全CAN總線協(xié)議數(shù)據(jù)幀。擴展幀ID的第15～30 bit的值為0x4f15，8 Byte數(shù) 據(jù)后 2 Byte為 0xce10，前 6 Byte為0x7162015bc051。監(jiān)測到的數(shù)據(jù)幀數(shù)據(jù)同預(yù)期的密文CipherText和消息認證碼MAC的值相同。

圖6 檢測到的安全CAN總線協(xié)議數(shù)據(jù)幀

接收節(jié)點ECU獲取安全數(shù)據(jù)幀后，將CiphetText和MAC組合，并與隨機數(shù)N、附加消息A和密鑰K進行AES-CCM解密驗證。驗證通過則返回明文并通過LCD提示驗證通過，如圖7所示，否則丟棄明文并提示驗證失敗。

圖7 安全CAN總線數(shù)據(jù)幀驗證通過

分別對普通CAN總線、AES-CCM加密、AES-CCM解密和安全CAN總線在不同時鐘頻率下進行性能測定，性能對比結(jié)果如圖8所示。當ECU的總線頻率為16 MHz時，安全CAN總線通訊延遲遠大于普通CAN總線延遲。隨著總線頻率的增大，安全CAN總線的通訊延遲迅速降低，當總線頻率為128 MHz時，安全CAN總線的通訊可以在2 ms內(nèi)完成。因此，隨著車載ECU性能的逐步提升，本文設(shè)計的安全CAN總線協(xié)議可以高效地應(yīng)用于智能汽車。

圖8 各模塊的性能對比結(jié)果

4.3 算法性能對比

AES-CCM算法對比其他常用算法（如AES-ECB、MD5、SHA-3等）在數(shù)據(jù)加密和認證上具有明顯優(yōu)勢。如文獻[6]、文獻[9]僅利用MD5和SHA-3算法所提出的安全CAN總線不能對數(shù)據(jù)機密性進行保護，因此攻擊者可以對嗅探到的明文進行分析得到具體含義。雖然文獻[7]與方案二均采用AES加密算法，但是CCM的加密模式破解難度更大。在數(shù)據(jù)認證方面，AES-CCM與MD5和SHA-3算法相比在處理速度和安全性能上處于平衡狀態(tài)，既滿足安全性的要求，也有較好的處理響應(yīng)速度，同時可以抵抗重放攻擊。表1所示為算法性能對比結(jié)果。

表1 算法性能對比結(jié)果

4.4 安全性分析

4.4.1 機密性

基于AES-CCM算法的安全CAN總線協(xié)議中，AES-CTR算法用于對數(shù)據(jù)幀的機密性進行保護。攻擊者在總線上嗅探到的數(shù)據(jù)幀均為密文，在密鑰未知的情形下很難進行逆向破解。算法的密鑰長度為128 bit，如果通過窮盡攻擊來獲取密鑰，需要進行2128次嘗試。然而，根據(jù)CTR工作模式的特點，每次加密都會生成新的隨機數(shù)，再考慮到ECU的處理能力和CAN總線的傳輸速度，通過窮盡攻擊來獲取密鑰是不可能實現(xiàn)的。

4.4.2 可認證性

本文采用與文獻[4]相同的32 bit的MAC。雖然Yasuda提出攻擊者在接觸到ECU內(nèi)部固件的情況下，在有限時間內(nèi)可以完成對32 bit的MAC進行破解[10]，但通常攻擊者很難接觸到ECU內(nèi)部固件，這種特殊情況不在本文的考慮范圍內(nèi)。攻擊者可以通過分析已獲取的MAC值結(jié)構(gòu)來獲取有效信息，但是在沒有密鑰的條件下仍不能獲得正確的MAC值。生成MAC的密鑰值在ECU中安全存儲很難被竊取，因此攻擊者只能通過猜測32 bit的所有可能MAC值進行攻擊。在目前的CAN總線傳輸能力下，如果平均每10 ms進行一次密鑰猜測嘗試，則需要11 930 h來完成整個攻擊過程[6]。同時，如果攻擊者對目標ECU進行數(shù)據(jù)傳輸?shù)拈g隔小于10 ms，總線會產(chǎn)生BUS-OFF錯誤，這意味著此節(jié)點將與CAN總線斷開連接不能再進行有效的數(shù)據(jù)通信。

4.4.3 抗重放攻擊

在本文的安全CAN總線協(xié)議中，數(shù)據(jù)幀具有可認證性，而MAC值是判斷該數(shù)據(jù)幀是否有效的直接因素。在每個MAC的生成過程中都需要發(fā)送ECU節(jié)點和接收ECU節(jié)點共同管理的隨機數(shù)作為輸入?yún)?shù)，因此不同的安全CAN總線協(xié)議數(shù)據(jù)幀MAC值均不相同。當攻擊者將嗅探到的內(nèi)容發(fā)送到CAN總線上后，接收節(jié)點會檢測到數(shù)據(jù)異常并進行拋棄處理。

5 結(jié)束語

本文針對普通CAN總線的設(shè)計缺陷，提出基于AES-CCM算法的安全CAN總線協(xié)議。通過對CAN標準幀CRC場的利用，使CAN總線具有機密性、可認證性和抗重放攻擊的能力。利用2塊飛思卡爾MC9S12XF512開發(fā)板作為試驗平臺實現(xiàn)了所設(shè)計的安全CAN總線協(xié)議，并對其可行性和通信延遲進行了分析與評測。結(jié)果顯示，本文提出的安全CAN總線達到設(shè)計目標，且所帶來的通信延遲可以被當前車載電子系統(tǒng)接受。