文档介绍：该【一种基于AES-CCM算法的安全车载CAN网络协议 】是由【碎碎念的折木】上传分享，文档一共【13】页，该文档可以免费在线阅读，需要了解更多关于【一种基于AES-CCM算法的安全车载CAN网络协议 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。一种基于 AES-CCM 算法的安全车载 CAN 网络协议
朱立民;李仁发
【摘 要】针对一般 CAN 总线的安全缺陷,提出基于 AES-CCM 算法的安全 CAN CRC 场和扩展帧 ID 场的利用,提出两种不同的方案,使CAN 总线具有机密性、 2 块飞思卡尔MC9S12XF512 开发板作为试验平台,对所提出的安全 CAN 总线协议进展了分析与评测,结果说明,当总线频率设定为 128 MHz 时,安全 CAN 总线单帧报文的收发可在 2 ms 内完成,同时该协议表现出良好的牢靠性.
【期刊名称】《汽车技术》
【年(卷),期】2025(000)008
【总页数】6 页(P54-59)
【关键词】信息安全;AES 加密算法;智能驾驶;CAN 网络协议
【作 者】朱立民;李仁发
【作者单位】吉利汽车争论院(宁波),宁波 315000;湖南大学,长沙410000
【正文语种】中 文
【中图分类】
前言
智能网联汽车与其他车辆、根底设施等通信的过程中，其内部网络与外界产生大量
数据交换，假设汽车外部通信网络信道被劫持，则使得针对汽车的网络攻击成为可
能。
2025 年，波鸿鲁尔大学的 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 总线协议对数据进展保护，使车内网络不能通过外部接口被利用，从而有效抵抗汽车网络攻击。
争论根底
智能汽车通常搭载百余个 ECU 通过各类数据总线连接在一起，如 CAN、LIN、MOST 和 FlexRay 总线，其中 CAN 总线应用最为广泛。然而，CAN 总线不具备
数据的机密性和可认证性，总线上的恶意节点可以监听总线上的全部消息，甚至可
以向其他节点发送恶意消息。因此，本文提出基于高级加密标准的计数器模式和密 码块链消息认证码〔Advanced Encryption Standard Counter with CBC-MAC， AES-CCM〕算法的安全 CAN 总线协议以抵挡外界网络攻击。
设计前提
针对智能汽车特别的应用场景，安全 CAN 总线设计需保证 3 个前提：
安全协议不能增加过大的载荷。如图 1 所示，CAN 数据帧的长度为 16 Byte， 其中数据域只有 8 Byte。目前 CAN 总线的数据域已经有很高的利用率，为确保足
够的安全性，MAC 的长度至少为 4 Byte，则 CAN 数据帧的有效载荷将减小一半， 因此，此方法不符合应用场景。
图 1 传统 CAN 总线协议
安全协议不能依靠很强的计算力量和存储力量。通常，车载 ECU 是具有有限资源的微掌握器，假设设计中需要大量的数据计算和存储，一般 ECU 难以保证明时性。例如，非对称加密算法 RSA 算法不但具有很强的机密性而且具有认证性[8]， 符合本文的设计目的，但受 ECU 的限制不能应用于 CAN 总线上。
安全协议不能造成任何硬件修改。假设安全协议需要进展硬件修改，将造本钱钱增加、可移植性降低以及设计简单化。安全协议的实现应在传统 CAN 掌握器和CAN 接收器的硬件根底上对协议本身进展修改，相比于 EVITA 工程中提出在汽车设计时增加硬件安全模块的策略 [5]，单纯的协议修改更简洁被汽车制造商所承受。
设计思路
通过总结当前存在的针对智能汽车的网络攻击类型[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 总线可以抵挡攻击者嗅探到有效数据帧对汽车进展的重放攻击。
设计方案
依据应用背景不同，本文提出 2 种设计方案实现安全 CAN 总线协议。
方案一
数据帧发送
如图 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
Function(N、A、P)->B0,B1,…Br =CIPHk(B0)
i from 1 to r =Ek(B0⊕Yi-1)
=MSBTlen(Yr)
Generation Function(N)->Ctr0,Ctr1,…Ctrm j from 0 to m
=CIPHk(Ctrj)
=S1||S2…||Sm〔“||”表示连接运算〕
R=(P⊕MSBPlen(S))||(T⊕MSBTlen(S0))
数据帧接收
如图 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 Clen<Tlen INVALID
Generation Function->Ctr0,Ctr1,…Ctrm j from 0 to m
=CIPHk(Ctrj) =S1||S2…Sm
=MSBClen-Tlen(R)MSBClen-Tlen(S) =LSBTlen(R)MSBClen-Tlen(S0)
N or A or P not valid INVALID
Function(N、A、P)->B0,B1,… Br
=CIPHk(B0)
i from 1 to r =CIPHk(Bi Yi-1)
T MSBTlen(Yr) INVALID
P
方案二
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 进展认证，认证通过则返回
正确明文，否则抛弃该数据帧并返回错误提示。
比照分析
两种方案均在传统 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 总线协议数据帧，消退了认证延迟。因此，对于标准数据帧的发送， 方案二更加具有优势。
试验验证
试验平台
本文承受 2 块 16 bit 飞思卡尔汽车开发板 MC9S12XF512 作为硬件开发平台，软件开发平台为飞思卡尔工具包 CodeWarrior Version 。开发板通过 BDM 下载器与 PC 机连接下载二进制代码，同时通过 USBCANⅡ采集 CAN 总线上的数据。开发板通过 LCD 显示屏和串口调试软件显示内部数据。图 5 所示为安全 CAN 总
线协议的试验平台。
图 5 安全 CAN 总线协议试验平台
性能分析
通常，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 为 **********，占用扩展帧的第 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 为0x7162025bc051。监测到的数据帧数据同预期的密文 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 各模块的性能比照结果
算法性能比照
AES-CCM 算法比照其他常用算法〔如 AES-ECB、MD5、SHA-3 等〕在数据加密和认证上具有明显优势。如文献[6]、文献[9]仅利用 MD5 和 SHA-3 算法所提出的安全 CAN 总线不能对数据机密性进展保护，因此攻击者可以对嗅探到的明文进展分析得到具体含义。虽然文献[7]与方案二均承受 AES 加密算法，但是 CCM 的加密模式破解难度更大。在数据认证方面，AES-CCM 与 MD5 和 SHA-3 算法相比在处理速度和安全性能上处于平衡状态，既满足安全性的要求，也有较好的处理响应速度，同时可以抵抗重放攻击。表 1 所示为算法性能比照结果。
表 1 算法性能比照结果加密算法数据加密数据认证抗重放 MD5[6]不支持支持不支持 SHA-3[9]不支持支持支持 AES-ECB 和 MD5[7]支持支持支持 AES-CCM 支持支持支持
安全性分析
机密性
基于 AES-CCM 算法的安全 CAN 总线协议中，AES-CTR 算法用于对数据帧的机