一種基于AES-CCM算法的安全車載CAN網絡協議

朱立民 李仁發

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

主題詞：信息安全 AES加密算法 智能駕駛 CAN網絡協議

1 前言

智能網聯汽車與其他車輛、基礎設施等通信的過程中，其內部網絡與外界產生大量數據交換，如果汽車外部通信網絡信道被劫持，則使得針對汽車的網絡攻擊成為可能。

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

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

2 研究基礎

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

2.1 設計前提

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

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

圖1 傳統CAN總線協議

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

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

2.2 設計思路

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

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

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

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

3 設計方案

根據應用背景不同，本文提出2種設計方案實現安全CAN總線協議。

3.1 方案一

3.1.1 數據幀發送

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

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

圖2 方案一的安全CAN總線協議示意

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

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

通過AES-CCM加密算法對原始數據的處理，連續的2個標準幀構成了1個具有機密性和可認證性的安全CAN總線數據幀，完成方案一的安全CAN總線數據幀的發送。其中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 數據幀接收

如圖3所示，當目標節點ECU3從CAN總線上接收到來自ECU2連續的2個標準幀（單個安全數據幀）時，ECU3將數據場和CRC場中的內容組合成為AES-CCM解密算法中的輸入參數R，另外的2個輸入參數為附加消息A和隨機數N（均預先存于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總線協議包含2類數據幀，即標準幀和擴展幀，其不同點主要為ID場的長度，標準幀的ID長度為11 bit，擴展幀的幀ID長度為29 bit，如圖3所示為CAN標準幀與擴展幀的對比。對于標準幀數據，可用擴展幀發送，即取其ID場中11 bit作為標準幀ID場，其余18 bit作保留位。本文中，方案二利用擴展幀發送標準幀數據，利用保留位中的16 bit發送MAC，其余置零。同時，CRC場用于搭載另外16 bit的MAC。最終由1個擴展幀構成的安全CAN總線數據幀可以發送32 bit的MAC和至多64 bit的密文。

圖3 標準幀與擴展幀對比

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

圖4 方案二的安全CAN總線協議示意

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

3.3 對比分析

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

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

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

4 試驗驗證

4.1 試驗平臺

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

圖5 安全CAN總線協議試驗平臺

4.2 性能分析

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

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

根據AES-CCM加密算法進行理論推導，得到6 Byte CipherText和4 Byte MAC：

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

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

圖6 檢測到的安全CAN總線協議數據幀

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

圖7 安全CAN總線數據幀驗證通過

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

圖8 各模塊的性能對比結果

4.3 算法性能對比

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

表1 算法性能對比結果

4.4 安全性分析

4.4.1 機密性

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

4.4.2 可認證性

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

4.4.3 抗重放攻擊

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

5 結束語

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