原文链接：https://blog.csdn.net/nibiewuxuanze/article/details/78999216
针对车辆网络中的加密数据传输还没有进行标准化。Vector已经构想了一个在CAN上的安全通信的实现，其保护目标是身份认证和防止重放攻击。
在当今的车载网络中，大部分的数据传输是在没有任何特殊安全措施的情况下进行的。因此，如果您可以直接访问车辆总线，就可以读出以原始格式传输的数据，甚至可以以修改的形式将其传输到总线系统中。加密数据传输可以保证信息只能由授权的接收方进行解析。至少，它也会使拦截或更改消息变得更加困难。
关于车辆操纵的媒体报道[1]、[2]提出了一个问题：车载网络中的数据是否真的会受到操纵的影响。操纵装置或内部植入装置是否能影响车辆的行为？采取什么对策来防止这种操纵行为？
今天的车辆是高度复杂的系统，它由联网的传感器和执行器组成，并不断地在总线系统上传输重要的数据。在绝大多数的情况下，信息是以原始数据格式传播。即便合理性检查是可行的，其有效性也是有限的。接收器无法确认数据是否由预期的发送方提供还是由外部的电子控制单元提供的，也就是说无法确认是否是真实的数据。数据可以被*的访问，所以对总线信息的分析可以用来确定信号内容。这种传输方式既不是保密的也没有经过认证。
这就是Vector的工程师们面临的问题。他们的任务是提出一种在CAN网络上可以灵活使用的安全通信的实现方式，并可以与Autosar-3.x基础软件集成在一起。其保护目标是身份验证和防止重放攻击，还需要能够进行不受监控的通信。
对于加密方法，专家们选择了AES算法[3]。从今天的角度来看，该方法被认为是加密安全的。它涉及对称块加密，块长度为128位。它产生的16字节或16字节的倍数的数据块，由发送方发送给接收方。一个附加的优势是，有一些微控制器已经具有非常快的基于硬件的AES算法实现。
由于一个CAN消息的帧中最多可以传输8个字节数据，所以决定使用已经包含在通信堆栈中的ISO传输协议（TP：Transport Protocol）来进行传输。为了简化配置和减少协议开销，选择在发送方和接收方之间采用固定的1:1关系的单向通信。
对称加密要求发送方和接收方都持有相同的**。使用的软件模块允许在运行时动态分配**，这样用户或OEM就可以*地选择**。一种更高阶的方法，例如（不对称的）**交换方法可能会被实现，或者可能会进行静态分配，例如在终端编程（end-of-line programming）中。当一个ECU被替换，并且使用了一个特定于车辆的**时，新的ECU必须由授权方法进行设置，它在任何情况下都保持**机密。
防止重放攻击
在上述配置中，消息的加密传输是可能的，但是，信息仍然是纯静态的，即可以将特定**文本分配给普通文本信号。这意味着重放攻击，也就是说，录制想要的通信片段，然后在以后的时间里，重新播放到系统中。这是因为接收方无法检查消息是否来自于此时的发送方。为了使检查成为可能，在通信开始时，接收方生成一个随机值，作为随后通信的ID键值，它将这个值传递给发送方。发送方在每次传输时递增这个值，并将其附加到传输消息中。当消息到达时，接收方将检查ID键值是否与预期值相匹配。如果匹配，则处理消息；否则会拒绝它。为了容忍可能的信息损失，接收方也会接受稍微高一点的值。这意味着，即使信号内容保持不变（图1），传输消息中的计数器也会持续改变加密数据。
图1:加密通信的消息传输和时序
根据ID键的字宽度和发送消息的频率，在消息中可能会出现计数器值的溢出，这将导致加密消息的重复传输。为了避免这种情况，ID键值只能在特定的时间段内有效。当这个周期过期时，接收方必须生成一个新值并将其用来与发送方进行通信。接收到新的ID键值后，发送方立即发送加密的消息。这意味着接收方也能够发起消息的重传（例如在接收的ID键值与内部的键值不匹配时），这减少了延迟时间。虽然发送节点在接收并确认新的ID键值消息时，有一个时间T(Offset)，但是为了避免总线系统的过载，这样的消息不会立即导致重新发送加密的消息。为了使协议更加健壮，接收方使用时间T(Resent)来监视发送方对新的计数器值的响应。如果它没有从发送方获得确认消息，接收方将生成一个新的ID**并重新发送它。这样就可以检测到发送ECU的简单故障，并缩短重新发送的时间。它还可以避免了在非易失性内存中存储ID键。
无分段数据传输
在ISO-15765传输协议中的分段数据传输，有一个显著的缺点。即传输时间增加了，这种方法被限制为固定的1:1关系，这使得在ISO-15765上的分段数据传输很难实现多个节点的传输。另一方面，CAN FD使整个加密消息同时传输到多个接收器[4]。每个接收器都需要相同的对称**来解密加密的消息。身份验证**的两个变体需要考虑：要么所有的接收方都使用一个共通约定的键值，要么所有的接收器都独立地生成并发送他们的ID键值给发送方。发送方管理所有计数器并将它们附加到数据消息。在加密消息内的计数器值的位置必须唯一地分配给接收方。
图2显示了多个接收器的数据传输。首先，接收方将随机生成的起始值发送给发送方。然后发送方对所有的每个发送周期都增加ID键值，并将它们插入到加密消息的预定义位置中。然后相关的接收方检查ID键值并接受或拒绝数据（图2）。
图2:使用CAN FD的多个接收方的ID键值
然而，随着接收器数量的增加，这会减少可用的数据消息空间。可用的数据字节数也高度依赖于ID键值所选择的字宽度。图1所示的通信时序被应用了。它只需要发送方在接收ID键值时进行修改。发送方没有立即发送加密的消息，而是先等待一个可配置的时间T(IdKeyReply)，以便能够接收到其他接收方的ID键值消息。特殊情况下，T(IdKeyReply) = 0会覆盖原始方法。
Vector实现了在CANoe环境下的CAN FD协议。专家们使用这个软件工具对各ECU和网络进行了广泛的测试，以开发、模拟和测试各ECU和网络。除了应对重放攻击所需的健壮性之外，另一个重点是研究消息丢失、故障和发送方和接收方的重新输入，以及定时错误和突发攻击。在所有这些情况下，加密系统都提供了稳定的传输。
总结与展望
特别是在CAN FD中，实现对多个节点的加密数据的鲁棒传输所付出的努力相对较少，而且这种方法也适用于现有的AUTOSAR环境。一个缺点是在应用程序级别上的数据的序列化和反序列化（图3），这意味着RTE的建模属性不能再用于单个信号。对此类系统的经典攻击点必须牢记于心。例如，它们包括弱随机数生成器（在启动时）或监视对称**。
图3:加密传输的软件组件
在安全技术领域，AES-128算法被认为在不久的将来也是安全的，它的实现是成熟的，甚至可以得到硬件加速器的支持。这里提出的方法使得对CAN (FD)通信的攻击变得更加困难，而且在没有“内部知识”时很难操作。这种方法已经在生产中使用了好几年，并且它也导致了对相关车辆的优惠分类。在这种情况下，安全性不仅保护了数据；它甚至为最终用户提供了直接的成本优势。
在不久的将来，诸如Car2x通信、WLAN、蓝牙和Internet等远程连接将会继续增长，并将需要更严格的IT安全性要求。必须对这些访问模式进行安全防范，并且不允许任何远程操作。这对于驾驶辅助系统来说尤其如此，它依赖于来自其他交通参与者和基础设施的可靠消息。