While current security requirements are already met for Ethernet-based connection of sensors, a corresponding standardized concept was previously lacking for SerDes-based links. A working group of the Automotive SerDes Alliance aims to close this gap.
A trend topic in the automotive industry is autonomous driving, which is intended to relieve the driver in a variety of situations and in some situations even move the vehicle completely without driver intervention. The implementation of autonomous driving is based abstractly on the processing of many sensor data and the resulting control of the vehicle.
It is essential that autonomous driving has clear safety implications. On the one hand, the criticality from a safety point of view is significantly higher: The driver can no longer intervene by monitoring, and functions can therefore no longer simply be stopped while driving, as it was previously the case, when malfunctions occur. On the other hand, security is also much more in demand here than before, since successful attacks on an autonomous vehicle can lead directly to uncontrollable safety problems. A driver who does not expect to intervene will no longer be able to compensate for a sharp steering angle during an autonomous drive before the vehicle collides. In this case, security must prevent an attack in order to enable safety objectives to be met.
From a security point of view, it is essential that the security level for autonomous vehicles is significantly increased in many areas. This article focuses on the first step in the chain, the transmission of sensor data. If these sensor data are already manipulated, attacks cannot be reliably stopped in the later processing stages. For the secure integration of Ethernet-connected sensors, powerful solutions are already available in the IT world with TLS, IPsec and MACsec. MACsec in particular allows the effective protection of multicast messages, an important unique advantage.
However, the current security situation of many solutions for non-Ethernet-based sensor connections - especially for cameras - seems not so bright. So far, there are no or hardly any comparable security solutions available that would allow an OEM to achieve a security level comparable to that of Ethernet.
Security specification requirements
During the work on the standard, many use cases have been compiled from which different requirements can be derived. For a better understanding, however, only three exemplary requirements are presented here:
These requirements make it clear that simple protection of messages cannot be sufficient and further security measures are necessary. In the following, therefore, the focus is not only on protecting messages during transmission but also on key exchange.
Security on the Link Layer
The basic security design aims at securing the communication per link. For reasons of limited additional computing power, symmetric keys should be used for security.
The transmitted data packet, the container, consists of a header and the user data in the unsecured case. For an integrity check and optional encryption of the container user data, two new fields are added to the container: The eight least significant bits of a 64-bit security counter to detect replay attacks, and an Integrity Check Value (ICV) to check the integrity of the header, counter, and payload (Figure 1).
AES-GMAC is favored as the cryptographic method of choice, since its implementation can also offer AES-GCM and thus optional encryption in addition to integrity protection without significant additional effort.