The modern automobile is an increasingly complex network of computer systems. Cars are no longer analog, mechanical contraptions. Even the most fundamental vehicular functions have become computerized.
At the core of this complexity is the Controller Area Network, or CAN bus.
The CAN bus is a modern vehicle’s central nervous system upon which the majority of intra-vehicular communication takes place. Unfortunately, the CAN bus is also inherently insecure.
Designed more than 30 years ago, the CAN bus fails to implement even the most basic cyber security principles. Research has demonstrated that an attacker can easily gain remote access to a vehicle’s CAN bus.
In our latest blog post we discussed the perimeter problem which the automotive industry is now facing with connected cars. CAN-connected devices are now connected to the internet, targeting them to allow penetration attack vector.
Why is securing the CAN bus such a massive challenge?
With an understanding of the cost and complexity involved, it’s easy to see why the automotive industry has been cautious about disrupting the existing CAN bus.
Securing the CAN will require reverse engineering of complex legacy infrastructure that was never designed with security in mind and does not have any form of authentication.
With a maximum payload of 8 bytes per frame, only limited authentication data can be used in combination with signal data.
Most legacy automotive ECUs have limited hardware and software resources, such as processing power and memory, making it difficult to cost-effectively make changes to the CAN.
The number of CAN IDs available for authentication is limited and most are already allocated to existing functions.
What is the right solution?
The US CERT acknowledged the lack of security by design last year. In their Alert publication the only recommendation they could advise for was to disconnect the OBD port access.
This is obviously not a practical solution for the automotive industry and we needed to find a pragmatic way that will best suit the industry, providing both comprehensive and practical protection.
However, before we can try and find a solution that will protect cars from identified vulnerabilities, we have to understand the essence of the US CERT Alert: CAN connected devices are very hard to protect, and more specifically, it is very hard to protect the car’s internal network from them.
With connected and autonomous technologies creating a wide range of new attack points, it becomes very complex to provide a generic solution for CAN connected devices, as they vary from Android infotainments to radars ... Each subsystem is running on different platforms and with different architectures.
We need a product protecting cars from perimeter breaches, because once a device is breached, which is likely to happen on focused attack, we need to contain the attacker and keep him inside the device, outside of the vehicle.
The Stamper is a Decentralized Firewall, protecting vehicles from any non-secure device connected to the CAN bus.
Decentralized Firewall, composed of “Stampers” and a central smart IDPS:
Stamper module is added to any untrusted device connected to the CAN bus - the Stampers add a verified source address to each message.
IDPS can then perform detection and prevention measures from any ECU - Illegal packets trigger an alert, legal messages are re-sent in their original form to the CAN.
While it may not be that difficult to create a cyber security product, the real challenge lies within the needs of the automotive industry, as elaborated above.
Fitting the Automotive Industry needs - POC
To verify that our new approach to Automotive Cybersecurity indeed fits the automotive industry needs we’ve done a POC with a leading European Tier-1.
The integration process took us a whole 2 (!) days, remotely(!), which is unheard of in the automotive industry. No long discussions, debugging, or other time wasting integration tasks.
As we understand that integration could be a main obstacle to adopting new cyber security products in the automotive industry, all our products are designed with integration ease in mind.
Automotive Manufacturer Needs
In order to measure the POC, the client defined their POC success criteria – to make sure they suit the automotive manufacturer needs:
For us it was an important additional feedback to see whether or not our approach actually fits the Automotive industry. We see that the Stamper is excelling in all the challenges elaborated above that a CAN protection products should overcome – Complexity, Bandwidth, Cost and limited CAN IDs.
Furthermore, we can see that minimal integration time is not only due to our familiarity with automotive components and real time OS like Autosar - allowing us to create compatible products - but also thanks to the Stamper’s minimal footprint, allowing integration into any ECU the manufacturer or supplier prefers.
Next: In-Vehicle Network Protection
The Stamper is able to protect the internal car network from the outside.
But what happens if an attacker managed to find a different way to hack into the vehicle?
For example, tamper the FOTA system and upload his malicious payload directly to an internal ECU?
As we explained in our first blog post, there are several layers of attack, following several steps, and we need to provide the industry with defense measures to protect the vehicle from them all.
In our next blog post we’ll explain what is our approach to protect car’s internal networks.