CANAuth - A Simple, Backward Compatible

Broadcast Authentication Protocol for CAN bus

Anthony Van Herrewege, Dave Singelee, Ingrid Verbauwhede

firstname.lastname@esat.kuleuven.be

Abstract— The Controller-Area Network (CAN) bus protocol [1] is a bus protocol invented in 1986 by Robert Bosch GmbH, originally intended for automotive use. By now, the bus can be found in devices ranging from cars and trucks, over lightning setups to industrial looms. Due to its nature, it is a system very much fo- cused on safety, i.e., reliability. Unfortunately, there is no build-in way to enforce security, such as encryption or authentication.

In this paper, we investigate the problems associated with implementing a backward compatible message authentication protocol on the CAN bus. We show which constraints such a protocol has to meet and why this eliminates, to the best of our knowledge, all the authentication protocols published so far.

Furthermore, we present a message authentication protocol, CANAuth, that meets all of the requirements set forth and does not violate any constraint of the CAN bus.

Keywords—CAN bus, embedded networks, broadcast authentication, symmetric cryptography

1. Introduction

The Controller-Area Network (CAN) bus protocol [1] is a bus protocol invented in 1986 by Robert Bosch GmbH, originally intended for automotive use.

CAN bus nodes are all connected to the same, shared bus line. The CAN bus is wired such that a 0-signal is dominant over a recessive 1-signal. These dominant and recessive signals are used for a CSMA/CA scheme. An arbitration scheme using priority resolution is used to decide which node is allowed to transmit data over the bus. The lower a node its ID (and thus the more dominant 0s it sends during bus arbitration), the higher its priority. Using this scheme makes the CAN bus fit for use as a real-time communication bus.

During transmission, a node continuously checks the signal on the bus and compare this with the signal it is transmitting. If a mismatch occurs, an error is raised, except during arbitration, in which case the node will just stop transmitting. After each message, a CRC is transmitted and receiving nodes will raise an error in case a mismatch occurs. To prevent broken nodes from continuously disturbing and invalidating messages, internal error counters are kept which, depending on their value, disable the right of a node to raise errors. This guarantees that communication over the CAN bus is very reliable, since, even with broken nodes raising errors, messages will eventually be transmitted successfully.

One year after its introduction, Philips presented the first CAN bus controller and, in time, the protocol was used more and more in non-automotive machines. By now, the bus protocol can be found in a wide range of devices: from cars and trucks, over lightning setups to industrial looms, printers, freezers and trains.

Due to its nature, the design of CAN bus is very much focused on safety, i.e., reliability. Unfortunately, there is no build-in way to enforce security, such as encryption or authentication. This leads to many possible attacks, as demonstrated by Koscher et al. [2] and Checkoway et al. [3]. Examples of such attacks are controlling brakes, remotely starting the car and controlling the air conditioning.

In this paper, we investigate the possibility of imple- menting a backward compatible message authentication protocol on the CAN bus. We show which constraints such a protocol has to meet and why this eliminates, to the best of our knowledge, all the authentication protocols published so far.

In Section II, we very briefly show some of the work that is already been done on broadcast authentication protocols. Section III gives a detailed overview of the requirements such a protocol should meet and the constraints it should honor for it to be usable on the CAN bus. Then, in Sec- tion IV, we present our proposal for such an authentication protocol. In Section V, an adversarial model is defined and the security properties of the protocol are investigated. Finally, we present our conclusions in Section VI.

1. Previous Work

In the past, different protocols have been published on how to archieve authentication in broadcast networks, some of those even aimed at lightweight embedded networks. The next few paragraphs give a very concise overview of some of those protocols.

The TESLA protocols are a family of related lightweight authentication protocols, relying on delayed key disclosure to guarantee message authenticity. The original TESLA protocol was published by Perrig et al. in 2000 [4], [5]. This protocol is designed to provide authenticated broad- cast capabilities. Subsequently, Perrig et al. presented

micro;TESLA [6], a modification of the original TESLA protocol, aimed at sensor networks, with severe contraints placed on computation and storage capabilities.

Other protocols have been published for use in broadcast

networks, such as a symmetric solution by Gennaro and

Rohatgi [7] and Rohatgirsquo;s improved protocol [8].

Unfortunately, all of these protocols have certain charac- teristics which violate the constraints set in Section III, such as requiring challenge-response communication, introducing delays (the main problem with TESLA and micro;TESLA) or needing to transmit large amounts of data (the main problem of the solutions by Gennaro and Rohatgi), all of whic

剩余内容已隐藏，支付完成后下载完整资料

canauth-一个简单的、向后兼容的

CAN总线广播认证协议

Anthony van Herrewege、Dave Singelee、Ingrid Verbauwheede firstname.lastname@esat.kuleuven.be

摘要

本文研究了在CAN总线上实现向后兼容消息认证协议的相关问题。我们展示了这样一个协议必须满足哪些约束，以及为什么这就消除了迄今为止发布的所有身份验证协议。

此外，我们还提供了一个消息身份验证协议，即canauth，它满足所规定的所有要求，并且不违反CAN总线的任何约束。

关键词-

一、引言

控制器局域网（CAN）总线协议[1]是由Robert Bosch GmbH于1986年发明的总线协议，最初用于汽车。

CAN总线节点都连接到同一条共享总线线上。CAN总线的接线方式使得0信号在隐性1信号上占主导地位。这些显性和隐性信号用于CSMA/CA方案。使用优先级解析的仲裁方案用于决定允许哪个节点通过总线传输数据。节点的ID越低（因此在总线仲裁期间它发送的0越占主导地位），它的优先级就越高。该方案使CAN总线适合作为实时通信总线使用。

在传输过程中，节点不断地检查总线上的信号，并将其与正在传输的信号进行比较。如果发生不匹配，则会引发错误，仲裁期间除外，在这种情况下，节点将停止传输。在每条消息之后，传输一个CRC，如果发生不匹配，接收节点将产生一个错误。为了防止断开的节点不断干扰和使消息无效，保留内部错误计数器，根据其值，该计数器禁用节点引发错误的权限。这就保证了通过CAN总线的通信是非常可靠的，因为即使断开的节点引发错误，消息最终也会成功传输。

在推出一年后，飞利浦推出了第一个CAN总线控制器，该协议在非汽车机器中得到了越来越多的应用。到目前为止，总线协议可以在各种设备中找到：从汽车和卡车、闪电装置到工业织机、打印机、冰箱和火车。

由于其本质，CAN总线的设计非常注重安全性，即可靠性。不幸的是，没有内置的方式来强制安全性，例如加密或身份验证。这导致了许多可能的攻击，如Koscher等人所证明的。[2]和Checkoway等人〔3〕。此类攻击的例子包括控制刹车、远程启动汽车和控制空调。

本文研究了在CAN总线上实现向后兼容消息认证协议的可能性。我们展示了这样一个协议必须满足哪些约束，以及为什么这就消除了迄今为止发布的所有身份验证协议。

在第二节中，我们非常简要地展示了一些已经在广播认证协议上完成的工作。第三节详细概述了这样一个协议应该满足的要求以及它应该为在CAN总线上可用而感到荣幸的约束条件。然后，在第四节中，我们提出了这种认证协议的建议。在第五节中，定义了一个对抗模型，并研究了协议的安全性。最后，我们将在第六节中给出我们的结论。

二、以前的工作

在过去，关于如何在广播网络中存档身份验证的不同协议已经发布，其中一些协议甚至针对轻型嵌入式网络。接下来的几段对其中一些协议进行了非常简洁的概述。

特斯拉协议是一系列相关的轻量级身份验证协议，依靠延迟的密钥公开来保证消息的真实性。最初的特斯拉协议由Perrig等人发布。2000年[4]，[5]。该协议旨在提供经过认证的广播功能。随后，Perrig等人提出了针对传感器网络的特斯拉原始协议的修改，对计算和存储能力提出了严格的限制。

其他协议已经发布用于广播网络，例如gennaro和rohatgi的对称解决方案[7]和rohatgi的改进协议[8]。

不幸的是，所有这些协议都具有某些违反第三节中设置的约束的特性，例如需要挑战响应通信、引入延迟（特斯拉和微特斯拉的主要问题）或需要传输大量数据（Gennaro和Rohatgi解决方案的主要问题），所有这些都是在CAN总线网络中不可接受。

三、问题概述

在本节中，我们将解释在CAN总线上向后兼容、轻量级消息身份验证协议的要求和约束。这应该说明为什么迄今为止发布的协议都不能在CAN总线上使用。此外，我们还展示了我们将如何通过我们提出的canauth协议来满足这些需求和约束。

A.认证协议要求

消息身份验证协议应提供的基本要求是：

消息身份验证

消息的真实性应该是可以证明的。只要保证消息是由受信任的节点发送的，那么消息的确切来源就不重要。

重放攻击阻力

重放以前发送的已验证消息将导致验证节点丢弃这些消息。

组密钥

应该可以使用同一个密钥[1]对一组相关消息进行身份验证。这就减少了所需的密钥存储的大小。

向后兼容性

使用身份验证协议的节点必须能够在不干扰任何不兼容节点工作的情况下对其消息进行身份验证。应该可以将许多支持身份验证协议的节点连接到现有总线，而不必对现有节点进行任何重新配置。

B.由于CANBUS的限制

尽管存在许多认证协议，但CAN总线存在一些特殊问题。由于我们需要向后兼容的身份验证协议，因此必须考虑以下限制：

硬实时

CAN总线系统通常用于应用硬实时约束的环境，例如汽车。因此，消息传输和处理时间不应受到身份验证协议的显著影响。所有认证数据都需要与其消息一起发送，以免干扰系统的实时响应能力。

消息长度

CAN总线上的单个消息可以包含1到8个字节的数据。认证协议所需的任何额外的认证数据必须与它所属的消息一起传输。

消息ID

CAN总线上的每种类型的消息都与特定的ID相关联，例如，ID 1=位置L1的温度，ID 2=位置L1的湿度等等。

一个ID由11位[2]组成，由于一个ID与一个非常特定的消息内容耦合，因此大部分ID都将在现有网络中使用。这意味着不能用一些新的内容类型来添加额外的ID。

单向通信

发送消息的CAN接口本身没有ID，所有通信都是广播的。因此，不存在节点之间双向通信的概念，因为CAN

接口没有ID。多个节点之间唯一可能的双向“通信”是通过错误标志。即使这样，发送节点也无法找出哪个接收节点引发了错误。

第一个要求，消息求证，可以通过在消息上附加消息认证代码（MAC）来满足。由于实时性的限制，采用的MAC算法需要快速。理想情况下，一旦收到部分认证数据，就可以开始处理验证。符合这些要求的算法是hmac[9]，[10]，假设其中使用的哈希函数很快。

然后，在MAC计算中加入一些计数器值，就可以满足重放攻击抵抗要求。但是，不应重复使用相同的计数器值，如果使用长度有限的计数器并发送大量经过身份验证的消息，则可能会导致问题。此外，在随后的系统重新启动过程中必须保存的状态越少越好。解决方法是在系统启动期间建立会话密钥。一个有限长度的计数器可以让我们工作，因为它允许系统测量何时应该建立一个新的会话密钥。

由于对消息ID和单向通信的限制，节点不能响应接收到的某些消息而返回消息。这将需要创建大量的新ID，每个ID都具有特定的新内容类型，例如ID 5=节点ni对ID为1的消息的响应。因此，如果n个节点希望能够响应m个不同的消息ID，则必须创建n·m个ID。考虑到大量不同的消息内容类型，这是不可能的，因为这将很快导致所有可用的11位ID耗尽。此外，每次添加一个新节点时，都需要重新配置总线上的现有节点。如果双向通信被证明是必要的，（向后兼容）需要设计解决方案。

使用由CAN协议提供的选项可以直接支持组密钥需求。一般来说，一个人可以用许多验收代码对一个CAN接口进行编程。这些代码告诉接口监听具有与任何接受代码匹配的ID的消息。还可以指定接受屏蔽，允许单个接受代码匹配多个ID。通过将密钥链接到这些验收代码、验收屏蔽集，可以实现组密钥设置。我们将一组相关消息gi定义为ID与接受代码、接受掩码i对匹配的所有消息的集合。

最后一个要求，向后兼容性是最大的问题。首先，不可能通过将身份验证数据与现有的CAN消息连接来附加身份验证数据，因为这将违反消息长度约束。身份验证数据也不能放在CAN消息中，因为这将减少已经非常有限的最大消息大小。第三种选择是通过多条消息发送一个长数据包。但是，这会降低系统的实时能力。

C.带CAN的变速箱

解决所有这些问题的一个解决方案是通过带外通道发送认证数据。这可以通过CAN 协议实现[11]。使用该协议，可以在CAN总线接口的采样点之间插入额外的位。如图1所示，这是如何工作的图形演示。

图1。在不中断常规CAN总线控制器工作的情况下，CAN 协议可以将额外数据插入CAN位的时间段。

通过这种方式传输的数据位的数量受到CAN 接口的最大可达到时钟速度的限制。Ziermann等人报告说，在1兆赫的CAN网络上，它们可以使用300兆赫运行的FPGA为每个CAN字节传输15个CAN 字节。

在较低的CAN总线速度下，此数字线性增加如下：

1. （can 数据位）/can*数据位=1MHZ/f_bus16-1

一个CAN 数据位的丢失是由于需要在每个CAN 传输开始时发送一个起始位。因此，在100 kHz的CAN网络上，每个CAN位最多可以传输159个CAN 位。

由于可以对消息进行身份验证，而不管其长度或CAN总线网络的总线速度如何，身份验证数据应限制为15字节。这允许在最坏情况下发送所有必要的身份验证数据，即作为1 MHz CAN总线上1字节CAN消息的一部分。由于对身份验证数据长度的限制，使用公钥（和基于身份的）加密是不可能的，因为与对称加密相比，公钥的密钥大小要求很大。

据我们所知，在CAN总线上认证协议必须遵守的限制和要求使得任何已发布的协议都无法使用。

D.多节点传输问题

我们可以设计一个系统，在CAN 时间段内多个节点进行传输，从而实现双向通信。这将违反硬实时约束，只要发送数据所需的特定数量的节点，因为仍然需要多条消息来完成这一任务。但是，在关键机构建立期间，这种违反限制的行为可以被忽略。然而，在下一段中，我们证明了任何需要节点间双向通信的协议都会对CAN总线施加速度限制。

CAN总线协议在传输过程中使用带有碰撞检测（CSMA/CA）的载波检测多址访问协议，通过该协议，可以在一个位的传输窗口中检测到位冲突。假设每个CAN位至少要发送一个带有CAN 协议的数据位。每个CAN 传输以一个起始位开始，因此在CAN 时间段内必须有两个位传输。此时间段最多占CAN总线位传输时间段的40%。因此，在这种情况下，CAN 协议需要以至少2.0的频率工作。_. =比CAN协议快5倍。

CAN总线标准保证，对于最长30米的总线长度，CSMA/CA以及因此而产生的CAN总线协议，可以以1兆赫的最大总线速度工作。但是，由于我们希望CSMA/CA在CAN 传输过程中发挥作用，这需要以至少5倍于CAN总线速度的频率工作，因此给定总线长度的最大CAN总线速度仅为200 kHz。

此外，在CAN字节传输期间发送的16个CAN 位中，只有8个CAN 位可用于数据，因为其他8位需要作为起始位。在CAN 传输窗口中希望发送的数据位越多，如果希望保持CAN 的最大速度为1兆赫，则需要降低CAN总线速度。

当然，在我们的示例中，可以将can 的速度增加到5兆赫，在这种情况下，可以在1兆赫下运行。但是，如果是这样，最大总线长度也将减少，以便在CAN 传输期间及时检测碰撞。

因此，如果需要借助CAN 进行双向通信，则需要减小最大总线长度或CAN总线速度。

四、卡纳斯议定书

在本节中，我们提出了一个简单的认证协议canauth，它满足第三节中规定的所有要求，并且不违反任何约束。

A.数据传输和帧格式

如第三节所述，认证数据通过CAN [11]协议进行带外传输，这为我们提供了认证消息的最大长度为15字节。字节被细分为如图2所示的字段。

图2。Canauth数据帧字段。数据帧由CAN消息的前15个CAN 字节（=120 CAN 位）组成。

前8位用作状态标志。目前，只有前两个位被使用，剩下的六个位可以在未来的协议版本中使用。其余112位用于传输密钥建立或签名数据。在下面的小节中，给出了关于这两种可能性的更多信息。

B.关键设施

这里描述的密钥建立协议要求在每个canauth节点上提供一个或多个预共享的128位密钥。在开发CAN总线设计期间，每组相关消息gi应获得分配的预共享密钥kp i [3]。我们假设这些密钥存储在一些防篡改的存储中，除了节点本身之外，其他任何人都无法查询它们。

负责传输消息的节点gi将为该组设置密钥。如果多个节点发送消息gi，则由具有该组最低ID的节点发送所建立的密钥将获得优先权。

为了防止重播攻击，密钥建立分两个阶段进行。首先，适当的节点（根据上面定义的规则）在CAN总线上发送一条消息，附带的CAN 消息的形式如图3所示。

图3。在密钥建立的第一部分中的canauth数据帧字段。

帧的第一位设置为1，以表示正在建立密钥。第二位设置为零，表示该消息是建立密钥所需的两个消息中的第一个。接下来的6位未使用，应设置为零。消息的实际有效负载是一个24位计数器和一个88位随机数。

使用计数器值ctrai和随机数ri，所有拥有预共享密钥KPI的节点都使用hmac[9]为消息gi生成会话密钥ksi。Canauth的实现可以自由地使用HMAC中被认为足够强大的哈希算法。根据使用的哈希算法，HMAC输

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[609473]，资料为PDF文档或Word文档，PDF文档可免费转换为Word