Today’s customers expect all the applications they are used to on their smartphones to be available in a modern car, along with possibilities to connect personal mobile devices to it. However, new features and functionalities, such as automated driving, unlocking via smartphone, navigation with detailed satellite graphics, etc., increase the need to connect the car to the outside to enable them or at least improve performance and user experience.
But when connecting the car to other devices, IT security becomes a priority, because simultaneously the car becomes an attractive target for attackers. Therefore, confidentiality, integrity, and authenticity must be maintained and privacy protection will be a concern.
Although cybersecurity is a common part of daily routines in the traditional IT domain, necessary security mechanisms are not yet widely applied in vehicles. At first glance, this may not appear to be a major problem as there are lots of solutions from other domains that could potentially be reused. But substantial differences compared to an automotive environment have to be taken into account, drastically reducing the possibilities for simple reuse.
Reuse of established and widely used algorithms and procedures for security mechanisms/implementations has both the benefit of lowering the effort but also increasing the security. After having experienced the downside of vendor specific, proprietary algorithms, the car industry is in agreement to use standardized crypto algorithms such as AES (Advanced Encryption Standard), RSA (Rivest-Shamir-Adleman cryptosystem), and ECC (Elliptic Curve Cryptography) that are publicized and thoroughly reviewed by scientists in a public discourse.
Although reuse of existing and proven security technology is desirable, the car has other specific requirements that must be taken into consideration.
In general cars need to fulfill a high-quality level and should endure robust environmental conditions. Both must be reflected also in the security critical parts. Smart card technology deployed in the car needs to support extended temperature range and requires an automotive-specific security qualification and manufacturing process. The first strongly affected security controller was the SIM (mobile subscription module). The car industry required a solderable SIM to cope with vibrations, extended temperature range and an automotive quality level (AECQ-100).
Legacy busses and ECUs
Current car platforms are renewed every five to seven years. A new car platform does not necessarily mean that every ECU in this platform is developed from scratch or all car communication busses are updated to higher performing variants. A critical example is the CAN bus that is still widely used and in many cases already reaching bandwidth limitations. This fact makes it difficult to support the additional overhead of cryptographic signatures in some cases.
The industry is following the tradeoff listed below:
- Classify CAN messages with respect to security criticality and only apply secure communication for critical messages thereby saving bandwidth.
- Use more, parallel CAN busses to lower traffic thus gain bandwidth.
- Isolate less security critical domains from domains that are security and safety critical.
Isolation can be achieved by domain specific gateways hosting firewalls principally similar to the aforementioned ECU intrinsic firewall.
Cars have a substantially longer lifetime than typical IT equipment. The time the architecture and the security foundation of a car are defined until the car is put out of operation can exceed 20 years or more.
This raises the question whether the used crypto algorithms can be regarded as being secure during such long lifetime. Several institutions publish estimates on the lifetimes of known crypto algorithms and related key lengths. There is an evident risk that the car requires an update of its cryptographic algorithms over the lifetime.
Crypto agility has many aspects:
- The overall software architecture needs to support a structure that enables an easy exchange of cryptographic functionality.
- The architecture should also prepare future migration strategies e.g. it should simultaneously support newer and older algorithms. Thereby an evolutionary introduction of new algorithms in the car and infrastructure is possible.
- Busses and storage need to have enough headroom with respect of bandwidth, size and performance to support longer keys.
- Finally, the cryptographic hardware accelerators need to support the new crypto algorithms ideally without impact on real time behavior.
With respect to first and second point mentioned before, the TPM 2.0 standardization already supports crypto agility in all the required specifications. The TPM specification provides a framework that allows adding further crypto algorithms. It is expected that future versions of TPM will therefore support new crypto algorithms while maintaining support for older still relevant algorithms. An ideal solution would be to update specific hardware components step by step, which support new cryptographic algorithms while the backward-compatibility to older algorithms is preserved. This would enable smooth transitions and provides more flexibility on the development process of ECUs, vehicles, and supporting security infrastructure.
This article is excerpted from the SAE International Technical Paper 2017-01-1652 “Cyber Security in the Automotive Domain – An Overview” by Rolf Schneider and Andre Kohn of AUDI AG and Martin Klimke and Udo Dannebaum of Infineon Technologies AG. It was presented during the Cybersecurity for Cyber-Physical Vehicle Systems technical session at WCX17.