AES-CCM CAN一种基于 算法的安全车载 网络协议

朱立民 李仁发

Automobile Technology - - CONTENTS - (责任编辑 斛畔) 2018 6 20修改稿收到日期为 年 月 日。

【摘要】针对普通CAN总线的安全缺陷,提出基于AES-CCM算法的安全CAN总线协议。分别通过对数据帧CRC场和扩展帧 ID场的利用,提出两种不同的方案,使 CAN总线具有机密性、可认证性和抗重放攻击的能力。利用2块飞思卡尔MC9S12XF512开发板作为试验平台,对所提出的安全CAN总线协议进行了分析与评测,结果表明,当总线频率设定为 128 MHz时,安全CAN总线单帧报文的收发可在2 ms内完成,同时该协议表现出良好的可靠性。 主题词:信息安全 AES加密算法 智能驾驶 CAN网络协议TN919.3 A 10.19620/j.cnki.1000-3703.20180665中图分类号: 文献标识码: DOI: A Secure In-Vehicle CAN Network Protocol Based on AES-CCM Algorithm Zhu Limin1, Li Renfa2 1. Geely Automotive Research Institute (Ningbo) Co., Ltd., Ningbo 315000; 2. Hunan University, Changsha 410000) ( Abstract This paper proposed an AES- CCM algorithm based security CAN bus protocol for offsetting the security【 】defects of traditional CAN bus. By using the data frame’s CRC field and extended frame’s ID field respectively, the paper proposed two different methods to make CAN bus have the abilities of confidentiality, authenticity and anti- replay attack. Two Freescale MC9S12XF512 development boards were used as the experimental platform, the proposed security CAN bus protocol was analyzed and evaluated. The results show that when CAN bus is set at 128 MHz, security CAN bus singleframe message can be received and dispatched within 2 ms, whereas this protocol shows good reliability. Key words: Cyber security, AES encryption algorithm, Intelligent driving, CAN network protocol

1 前言

智能网联汽车与其他车辆、基础设施等通信的过程中,其内部网络与外界产生大量数据交换,如果汽车外部通信网络信道被劫持,则使得针对汽车的网络攻击成为可能。

2007 Wolf

年,波鸿鲁尔大学的 等人分析了汽车可能遭受的网络攻击类型并提出了对应的防御措施[1]。

Koscher

华盛顿大学的 提出了特定的无线网络攻击技术,展示了智能汽车面临的网络安全问题,即当装有特定恶意软件的手机与汽车蓝牙设备相连接,展开短距

Brooks离无线攻击即成为可能[2]。 等人将可接入汽车

CERT

网络的通讯手段进行分类,利用 分类法分析针对

ECU

车载服务的攻击,结果表明, 中的固件升级时需要特定的安全保护,且需防范车辆与网络中心融合带来 Schweppe

的安全隐患[3],如远程诊断服务。 等人[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]。为了对车辆网络数据进行有效保护,需要从数据的

朱立民1 李仁发2 ( 1.吉利汽车研究院(宁波)有限公司,宁波 315000;2.湖南大学,长沙 410000)

机密性和可认证性两方面进行考虑。本文以车辆内部

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

够的安全性, 的长度至少为 则 数据帧的有效载荷将减小一半,因此,此方法不符合应用场景。 b.

安全协议不能依靠很强的计算能力和存储能

ECU

力。通常,车载 是具有有限资源的微控制器,如果

ECU

设计中需要大量的数据计算和存储,普通 难以保

RSA

证实时性。例如,非对称加密算法 算法不但具有很强的机密性而且具有认证性[8],符合本文的设计目的,

ECU CAN

但受 的限制不能应用于 总线上。

c.

安全协议不能造成任何硬件修改。如果安全协议需要进行硬件修改,将造成成本增加、可移植性降

CAN

低以及设计复杂化。安全协议的实现应在传统 控

CAN

制器和 接收器的硬件基础上对协议本身进行修

EVITA

改,相比于 项目中提出在汽车设计时增添硬件安全模块的策略[5],单纯的协议修改更容易被汽车制造商所接受。

2.2 设计思路

通过总结当前存在的针对智能汽车的网络攻击类 Samuel Woo CAN

型[2], 指出通过修改 总线等车内网络总线,使其具备机密性和可认证性即可抵御各种类型的网

CAN

络攻击[7]。为实现 总线的机密性和可认证性,需要

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 AES

需加密数据小于 时,进行补零操作以满足

CCM

算法的分组长度需求。

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) MAC):

算法生成T(即

32 bit, CRC

T的长度为 标准数据帧中 场的最大长

16 bit, 2 CRC

度为 因此连续 个标准帧可以实现 替换

ECU2 AES

场。 通过高级加密标准的计数器模式(

Counter mode,AES-CTR)

算法生成密文C:

= EncAES- CTR( 2)

C P) (

128 bit 32 bit

至多 的密文C和 的T经过简单处理组

2

成消息R,最终由连续的 个标准帧传送至目标节点

ECU3

AES-CCM

通过 加密算法对原始数据的处理,连续

2 1

的 个标准帧构成了 个具有机密性和可认证性的安全

CAN CAN

总线数据帧,完成方案一的安全 总线数据帧

AES-CCM

的发送。其中 加密的过程为:

NAP

输入:、、

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

将数据场和 场中的内容组合成为

2解密算法中的输入参数R,另外的 个输入参数为附加

ECU ROM

消息A和随机数N(均预先存于 的 中)。通过

AES- CCM ECU3 MAC解密算法, 得到明文P、 和来自

ECU2 MAC

的T。将 与T进行一致性验证,如通过验证

AES则返回明文P,否则丢弃明文并返回错误提示。

CCM

算法解密的过程为:

NAR

输入:、、

P or INVALID

输出:

1. if Clen<Tlen

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

至多 的密文。 4 CAN

如图 所示为方案二的安全 总线协议示意,在

ECU2数据帧发送前,发送节点 将明文P、随机数N和附

AES- CCM

加消息A作为输入进行 算法的加密,得到

MAC 1 CAN

和密文。利用 个扩展帧作为单个安全 总线

32 bit MAC ID

数据帧进行消息发送,其中 的 由扩展 场CRC 8 Byte

和 场共同发送, 的数据场用于发送密文。 CAN ECU3

对于安全 总线数据帧的接收,当节点 在

CRC ID

总线上监测到扩展帧时,将 场和扩展 场共同搭

32 bit MAC AES-CCM载的 、随机数N和附加消息A作为

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

全 总线协议的试验平台。 4.2 性能分析ECU CRC

通常, 的 接口在出厂时会被屏蔽,用户不

CRC CAN可以对 场进行任何修改。为了完成对安全总线协议的性能评测,对方案二进行适当调整。车载

ECU CAN 8 Byte, CAN发送的 消息一般为 本文设定 消

6 Byte, 2 Byte CRC MAC

息为 其余 仿真 场发送 。

1

本节通过选取 组具体示例来验证方案的可行

128 bit, N 56 bit,性。设定密钥K长度为 随机数 长度为

48 bit, A 64 bit:明文 P 长度为 附加消息 长度为

40 44 48 4C 10 14 æ ö æ ö

ç 41 45 49 4D ÷ ç 11 15 - - ÷ = = K M

42 46 4A 4E , 12 16 - - ,

43 47 4B 4F 13 - - - è ø è ø 16 16

20 24 - - 00 04 - - æ ö æ ö

ç 21 - - - ÷ ç 01 05 - - ÷ =

P ç 22 - - - ÷ , A = 02 06 - - 。

23 - - - 03 07 - - è ø è ø

16 16

AES-CCM

根据 加密算法进行理论推导,得到

6 Byte CipherText 4 Byte MAC:

CE - - - CE - - - æ ö æ ö

ç 10 - - - ÷ ç ÷

, MAC= 10 - - - CipherText=

4F - - - 4F - - - 。

15 - - - 15 - - - è ø è ø

16 16试验中,发送节点和接收节点在启动后立即进入初

LCD始化模式,初始化完毕后进入工作模式,并通过 显

CAN ECU

示已接入 总线。发送节点 将PKNA、、、通过

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

和消息认证码 的值相同。 ECU CiphetText

接收节点 获取安全数据帧后,将 和

MAC

组合,并与随机数N、附加消息A和密钥K进行

AES-CCM LCD

解密验证。验证通过则返回明文并通过

7

提示验证通过,如图 所示,否则丢弃明文并提示验证失败。 CAN AES- CCM AES- CCM

分别对普通 总线、 加密、

CAN

解密和安全 总线在不同时钟频率下进行性能测

8 ECU

定,性能对比结果如图 所示。当 的总线频率为

16 MHz CAN CAN

时,安全 总线通讯延迟远大于普通 总

CAN

线延迟。随着总线频率的增大,安全 总线的通讯

128 MHz CAN

延迟迅速降低,当总线频率为 时,安全 总

2 ms ECU

线的通讯可以在 内完成。因此,随着车载 性

CAN

能的逐步提升,本文设计的安全 总线协议可以高效地应用于智能汽车。

4.3 算法性能对比

AES- CCM AES- ECB

算法对比其他常用算法(如 、

MD5 SHA- 3

、 等)在数据加密和认证上具有明显优势。

[6] [9] MD5 SHA- 3

如文献 、文献 仅利用 和 算法所提出的

CAN

安全 总线不能对数据机密性进行保护,因此攻击者可以对嗅探到的明文进行分析得到具体含义。虽然

[7] AES CCM

文献 与方案二均采用 加密算法,但是 的加 AES-CCM

密模式破解难度更大。在数据认证方面, 与

MD5 SHA-3

和 算法相比在处理速度和安全性能上处于平衡状态,既满足安全性的要求,也有较好的处理响应

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

析与评测。结果显示,本文提出的安全 总线达到设计目标,且所带来的通信延迟可以被当前车载电子系统接受。

参考文献

[1] Wolf M, Weimerskirch A, Wollinger T. State of the art: Embedding Security in Vehicles[J]. EURASIP Journal on Embedded Systems, 2007, 2007(1): 1-16. [2] Koscher K, Czeskis A, Roesner F, et al. Experimental Security Analysis of a Modern Automobile[C]. IEEE Symposium on Security and Privacy. IEEE, 2010: 447-462. [3] Brooks R R, Sander S, Deng J, et al. Automobile Security Concerns[J]. IEEE Vehicular Technology Magazine, 2009, 4 (2):20-25. [4] Schweppe H, Roudier Y, Weyl B, et al. Car2X Communica⁃ tion: Securing the Last Meter- A Cost- Effective Approach for Ensuring Trust in Car2X Applications Using In- Vehicle Symmetric Cryptography[C]// IEEE Vehicular Technology Conference, IEEE, 2011: 1-5. [5] Schweppe H, Weyl B, Roudier Y, et al. Securing Car2X Applications with Effective Hardware Software Codesign for Vehicular On- Board Networks[J]. VDI Automotive Security, 2011, 27. [6] Groza B, Murvay S. Efficient Protocols for Secure Broadcast in Controller Area Networks[J]. IEEE Transactions on Industrial Informatics, 2013, 9(4): 2034-2042. [7] Woo S, Jo H J, Lee D H. A Practical Wireless Attack on the Connected Car and Security Protocol for In- Vehicle CAN[J]. IEEE Transactions on Intelligent Transportation Systems, 2015, 16(2): 993-1006. [8] Somani U, Lakhani K, Mundra M. Implementing Digital Signature with RSA Encryption Algorithm to Enhance the Data Security of cloud in Cloud Computing[C]//International Conference on Parallel Distributed and Grid Computing. IEEE, 2010: 211-216. [9] Wang Q, Sawhney S. VeCure: A Practical Security Frame⁃ work to Protect the CAN Bus of Vehicles[C]//International Conference on the Internet of Things. IEEE, 2014: 13-18. [10] Kan Y. Multilane HMAC- Security Beyond the Birthday Iimit[C]//International Conference on Cryptology in India. Springer, 2007: 18-32.

图 检测到的安全 总线协议数据帧

Newspapers in Chinese (Simplified)

Newspapers from China

© PressReader. All rights reserved.