Automotive Safety Relies on Cybersecurity - yet Myths Persist
As the auto industry plows ahead with advances in energy efficiency, comfort and safety, it appears that some are forgetting the importance of the E/E Architecture and the role it plays in the safety of the automobile. I recently highlighted some of the Myths that persist around Automotive Cybersecurity at an Automotive Security Research Group presentation, emphasizing the importance of the modern automobile being Secure by Design.
Here we highlight the myths that are diverting attention from the critical importance of ensuring that you have the processes in place to always ensure that your product is protected and the safety of your customers is front of mind.
In 2021 the auto industry will be significantly influenced by a number of trends that will drive the shift from “vehicle manufacturers” to “vehicle software platform developers”.
Myth 1 - Crypto will Solve ALL of your Problems
Designing in cryptography is only one part of the solution for designing a secure E/E Architecture and requires every application in the vehicle to be secure. With application cryptography, each application may require its own keys with therefore key management - making the implementation of Automotive Cybersecurity a complex but very necessary task.
The design of the security system will also need to look at the current limitations of the automobile Controller Area Network (CAN), a bus network where all applications can read and write and hence is open to security vulnerabilities deliberate or otherwise in any of the applications connected.
The current CAN is designed for small payloads / short messages and so is not well suited to have crypto added to those messages.
Myth 2 - The Controller Area Network (CAN) is to Blame
Although the CAN bus meets its original design requirements as a closed network transporting short informational messages, it is not well suited for networking smart devices passing both information and control messages. It was never intended as a general communications network with possible connections to outside the vehicle and connecting a multitude of active controllers.
The current CAN bus’ small payload will not support strong cryptographic protocols, and any crypto used will increase latency (a very undesirable feature in the real-time environment of a vehicle). On top of this, there is little ability to support key management and Message Authentication Codes thus the CAN bus is not suitable as a backbone architecture.
Myth 3 - A Hardware Security Module (HSM) will Solve the Problem
Yes, Hardware Security Modules (HSM) will assist in securing a vehicle, but it is only one element in a robust security design - secure hardware is only useful to support a secure application.
An HSM will help with security key management and authenticating software and messages. An HSM will also help keep the costs of implementing Automotive Cybersecurity, but each of the applications will also need to have cybersecurity central to their design.
Myth 4 - All you need is “Secure Coding”
We all need to recognize that software is created by engineers, engineers are human and humans are fallible. Regardless of how well the application is designed and coded, there is a chance that there will be bugs and maybe even flaws in the design.
A malicious agent will look for and exploit any chink in the armour they can find, be it a flaw in the design or an un-noticed bug. The system architect will need to take into account the possibility that any one of the applications may become compromised and introduce malicious requests on the overall system.
Myth 5 - Following a Standard is the Answer
Standards are not a Silver Bullet to solving Cybersecurity challenges as those standards need to be included into the architecture, design and coding of the solution and this is done by people (see Myth 4). With the UN mandating that cybersecurity be considered part of a vehicle’s lifecycle, publishing standards and proposing regulation will force us to consider the problem. BUT standards provide guidance, they do not provide a solution.
Myth 6 - Security Can Be Added Later
Think of the lack of effective security as a defect - fixing a defect by adding security features after release may require a re-design of the product and will definitely be significantly more costly than if it were included in the design from the outset. Security cannot just be patched in.
IBM System Science Institute Relative Cost of Fixing Defects
Myth 7 - The Firewall will provide Protection
It is impossible to build a firewall around a system of many connected applications, there are far too many required trusted relationships needed. If any one of the connected applications is compromised the attacker is inside the firewalls and free to wreak havoc.
Trust between applications is essential, but that will rely on establishing that trust through ensuring authenticity and ensuing that a request from a trusted application actually originated from that application. This requires layers of security to exist inside the firewall and not to rely on the firewall itself.
Myth 8 - It’s Unhackable
Send the invitation to the hackers! Really … nothing is unhackable, and if you find this hard to believe request a white hat penetration test.
Myth 9 - It’s Secure and will be Forever
Just because no one has found, maybe even attempted to find, a vulnerability in your automotive E/E Architecture it does not mean that they can’t or won't. If someone wants to perpetuate a malicious act against your company, they will spend the time, money, and effort to find a vulnerability that allows them to … the only way to beat them is to stay one step ahead of them … invest in on-going processes to identify and remedy vulnerabilities before they can be exploited.
Myth 10 - Our Security is Secret
Do not believe that just because you have in-house architects, designers and engineers that have developed their own methods for securing the E/E, that their secrets will remain secret for long. Refer to Myth 9.
Myth 11 - Only way to break-in is Physical Access
If you have an On-Board Diagnostic (OBD) port, wireless connection or any other third party device connected to the automotive E/E network or backbone, then you have potentially opened the door to the automotive control systems. Think every ride-share, car-share, taxi or fleet vehicle that are connected and can thus be attacked by those with malicious intent.
Myth 12 - Security ONLY adds Cost
Security is the enabler of the connected, immersive environment of modern cars. Without security you would not have safety and the ability to sell a product. Security adds a LOT comparatively to the small incremental cost of design and production.
The Time to act is now - call in the Myth Busters
Now that we have reviewed these 12 myths, we must recognize that:
- Cryptography is useful for secrecy (of the messages sent) and authenticity (of the application), but there is a lot more to secure design than merely encryption
- HSM is a useful module to enforce rules around the use of encryption keys to ensure secrecy and authenticity and prevent malicious requests
- The current CAN bus is not designed for a secure and connected vehicle
This means that automotive cybersecurity must now become an integral and essential part of the modern E/E Architecture. Cars must be secure by design. This means that cybersecurity must be included in the initial design and not as an add-on.
Every application and their interactions must be secured holistically. We MUST implement a process to continually monitor, investigate, identify and remedy security vulnerabilities.
A cybersecure vehicle is a SAFE vehicle.
Don’t forget to share this post
