Today’s car is essentially a mobile computing device. The last few decades have transformed the complexity and volume of electronics used in cars. What has taken it to the next level is the ability to connect to the outer world through wireless communication technology. However, this has opened up vehicles to a huge vulnerability – mass hacking.
Earlier, physical access was a prerequisite for any sort of tampering or malicious embedding of software. However, this has been proven wrong in the last couple of years. The ability to remotely connect to a car using wireless technologies, like cellular, has taken hacking to a new level. Earlier what could have been imagined as part of a Hollywood thriller could now very well be a reality.
OEMs and suppliers need to make a concerted effort towards tackling this issue. Guidelines like SAE J3061 [1] are a good first step towards a comprehensive approach the automotive industry can uniformly adhere to. An obvious step to contain the risk would be to limit or restrict a car’s ability to connect to the outer world. However, this goes against the preferences of today’s consumers and with OEMs themselves seriously planning to roll out “over-the-air” software updates; there is no looking back.
It is important to note that the impact of security encompasses aspects of privacy and loss of functionality apart from safety concerns. Features like “over-the-air” software updates require security and encryption measures not only on in-vehicle electronics but also on the IT back end and employee access policies.
The AES 128 encryption cipher is sufficient for secure communication in automotive applications. Ciphers like AES 128 cannot be easily broken as long as the key is not compromised. EVITA and SHE are security initiatives in the automotive world setup with the objective of designing and specifying secure and tamper proof controllers. Existing hardware needs to be upgraded to be able to process this efficiently, using dedicated “Hardware Security Modules” (HSM) [2].
Another challenge that engineers face is balancing safety versus security. The additional processing time required for decrypting safety critical messages needs to be accounted for in the fault tolerant time interval [3] for controllers. For example, outbound torque requests from the TCM can be signed and encrypted before being sent to the Engine ECU. However, the additional time required for – encrypting at the TCM, transmitting of additional payload on the CAN bus, and decrypting at the Engine ECU now needs to be accounted for within the same FTTI. In other words, with everything else remaining the same the Engine ECU has a lesser amount of time available to detect and react to single point faults that could cause unintended acceleration.
Also, just like an internet browser, a car is only secure until a motivated hacker has identified a potential exploit. Hence securing a car is a continuous process and is not finished once released into production. As cars are getting more feature rich with each model year, OEMs and suppliers have a long uphill journey to protect against the specific security risks of their cars.
- SAE J3061: Cybersecurity Guidebook for Cyber-Physical Vehicle Systems
- AURIX Security Hardware
- ISO 26262-1:2011, Road vehicles – Functional Safety – Part 1: Vocabulary
