朱立民 李仁發(fā)

（1.吉利汽車研究院（寧波）有限公司，寧波 315000；2.湖南大學(xué)，長(zhǎng)沙 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ò)信道被劫持，則使得針對(duì)汽車的網(wǎng)絡(luò)攻擊成為可能。

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

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

2 研究基礎(chǔ)

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

2.1 設(shè)計(jì)前提

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

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

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

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

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

2.2 設(shè)計(jì)思路

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

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

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

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

3 設(shè)計(jì)方案

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

3.1 方案一

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

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

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

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

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

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

通過AES-CCM加密算法對(duì)原始數(shù)據(jù)的處理，連續(xù)的2個(gè)標(biāo)準(zhǔn)幀構(gòu)成了1個(gè)具有機(jī)密性和可認(rèn)證性的安全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（“||”表示連接運(yùn)算）

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

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

如圖3所示，當(dāng)目標(biāo)節(jié)點(diǎn)ECU3從CAN總線上接收到來自ECU2連續(xù)的2個(gè)標(biāo)準(zhǔn)幀（單個(gè)安全數(shù)據(jù)幀）時(shí)，ECU3將數(shù)據(jù)場(chǎng)和CRC場(chǎng)中的內(nèi)容組合成為AES-CCM解密算法中的輸入?yún)?shù)R，另外的2個(gè)輸入?yún)?shù)為附加消息A和隨機(jī)數(shù)N（均預(yù)先存于ECU的ROM中）。通過AES-CCM解密算法，ECU3得到明文P、MAC和來自ECU2的T。將MAC與T進(jìn)行一致性驗(yàn)證，如通過驗(yàn)證則返回明文P，否則丟棄明文并返回錯(cuò)誤提示。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ù)幀，即標(biāo)準(zhǔn)幀和擴(kuò)展幀，其不同點(diǎn)主要為ID場(chǎng)的長(zhǎng)度，標(biāo)準(zhǔn)幀的ID長(zhǎng)度為11 bit，擴(kuò)展幀的幀ID長(zhǎng)度為29 bit，如圖3所示為CAN標(biāo)準(zhǔn)幀與擴(kuò)展幀的對(duì)比。對(duì)于標(biāo)準(zhǔn)幀數(shù)據(jù)，可用擴(kuò)展幀發(fā)送，即取其ID場(chǎng)中11 bit作為標(biāo)準(zhǔn)幀ID場(chǎng)，其余18 bit作保留位。本文中，方案二利用擴(kuò)展幀發(fā)送標(biāo)準(zhǔn)幀數(shù)據(jù)，利用保留位中的16 bit發(fā)送MAC，其余置零。同時(shí)，CRC場(chǎng)用于搭載另外16 bit的MAC。最終由1個(gè)擴(kuò)展幀構(gòu)成的安全CAN總線數(shù)據(jù)幀可以發(fā)送32 bit的MAC和至多64 bit的密文。

圖3 標(biāo)準(zhǔn)幀與擴(kuò)展幀對(duì)比

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

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

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

3.3 對(duì)比分析

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

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

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

4 試驗(yàn)驗(yàn)證

4.1 試驗(yàn)平臺(tái)

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

圖5 安全CAN總線協(xié)議試驗(yàn)平臺(tái)

4.2 性能分析

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

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

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

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

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

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

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

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

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

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

4.3 算法性能對(duì)比

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

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

4.4 安全性分析

4.4.1 機(jī)密性

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

4.4.2 可認(rèn)證性

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

4.4.3 抗重放攻擊

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

5 結(jié)束語

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