一种基于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总线达到设计目标，且所带来的通信延迟可以被当前车载电子系统接受。