The basics of the presented security design have already been agreed upon and the link layer security is currently being transferred to the specification, while the following key exchange procedure is still in the decision phase within the working group.
Key exchange based on a 3-level key hierarchy
The current concept for key exchange and distribution defines three key hierarchy levels (Figure 2). In addition to the actual security of communication, this also makes it possible to prevent part forgery and theft. The top level uniquely identifies an ECU, the middle level binds ECUs to a vehicle, and the lowest level provides session keys.
The top level of the key hierarchy uses so-called device keys, which in turn are formed from two keys of equal length per ECU: The "Tier-1 Device Key" and the "OEM Device Key". The Tier-1 Device Key is persistently burned in by the Tier-1 during the production of the ECU, thus giving the ECU a unique, secure identity in combination with a unique semiconductor identification number. This can be made known to the OEM for further processes. The second key component is written by the respective OEM during the production of the vehicle in the factory or in service, whereby the component is now bound to the OEM and the OEM assumes control and responsibility for the ECU.
The use of Tier-1 and OEM Device Keys ensures that produced ECUs always have cryptographically secured identities, even in logistics. This makes it easy to detect and prevent counterfeit parts at the OEM's plant or when replacing components during service. The complete overall process is not part of the ASA standard and can be designed by the OEM based on the ASA standard.
Within the ECUs, the primary use of the Devices Keys is the installation of Binding Keys of the next level. The complete device key required results from an XOR operation of the Tier-1 device key and the OEM device key. The complete device key is only known to the OEM, while the Tier1 has only knowledge of his part of the device key. This ensures that control can be transferred to the OEM.
The binding key of the middle key hierarchy level ensures the persistent binding of a component to a vehicle or to a higher-level ECU in the vehicle, here called root ECU. This prevents stolen parts such as cameras or sensors from functioning in another vehicle. Each ASA ECU receives its own Binding Key, which is generated in the OEM's backend and transmitted to the ECUs in encrypted form using the respective Device Keys. The persistent installation of the Binding Key can be done in the factory during production of the vehicle as well as in the service in case of a possible exchange of parts. Each ASA ECU has only knowledge of its own Binding Key, whereas the Root ECU must know all Binding Keys belonging to it.
The Link Key, which represents the third level of the key hierarchy, ensures the security of communication during operation. Each ASA link to be secured has its own Link Key, which is renewed at each lifecycle of the vehicle. The generation of all Link Keys for the ASA-Links and their distribution is done by the Root ECU itself. The distribution of the link keys to the two ASA devices of this link is encrypted. These keys are protected with the respective binding key of the ASA device.
All in all, the concept shows a clear advantage: Smaller ECUs equipped with limited computing power only need to perform simple, symmetric cryptographic operations, whereas the main load such as the fast and secure generation and distribution of many keys is handled by a powerful ECU, the root ECU. Furthermore, expensive asymmetric cryptography within the ASA ECUs is not required.
In the context of autonomous driving, it will be crucial that the overall system implements safety and security requirements. The currently existing security requirements for the connection of (external) sensors can be fulfilled with Ethernet-based connection using MACsec. But when using other technologies (e.g. SerDes-based camera links) this gap still needs to be closed. The Automotive SerDes Alliance has recognized this need and initiated a suitable working group in which the above-mentioned solutions are currently being integrated into the standard.