Automotive Security is Available Today- Security, Architecture, Issues and Challenges

The automotive industry has a substantial challenge on their hands. Car makers are putting more and more electronics into our automobiles, and at the same time, they’re increasingly connecting their cars to the Internet. This opens up the vehicle to security threats – and security is not a part of the automotive architecture.

That’s changing in the long term, but developers need a security solution today, since we have several years of transition during which cars and drivers could be at risk if they simply wait around for the new standards to materialize. Secure microcontrollers, Trust Anchor Devices (TAD), and border security devices provide this intermediate step. They are straight forward to implement and dramatically strengthen a car’s ability to reject intrusions and activity by anyone that isn’t authorized to be there.

An Insecure Legacy

Automobiles have been going electronic for many years. Because the consequences of failure can mean loss of life, automobiles are designed differently from other vehicles in the interest of safety. Each electronic function gets its own independent computing resources, bundled into what’s called an Electronic Control Unit, or ECU. These ECUs are interconnected by the CAN bus, which was developed for this specific purpose.

Originally, only drive-oriented functions were built and attached to the bus. But new electronic automobile content – specifically, advanced driver assistance systems (ADAS) and the so-called “center stack,” the center of infotainment – has gone far beyond making sure the car runs efficiently. Some components are more safety critical than others, but they’re all connected to the same CAN bus.

The infotainment portion in particular has created a demand for an Internet connection, and with that connection, others can attempt to access the bus, and thereby, access all of the electronic modules – critical and not – in the car, making security an important consideration.

While it might be tempting to place all of the blame on this non-mission-critical set of modules, a cellular Internet connection isn’t the only possible entry point. Cars will have Wi-Fi and Bluetooth as alternative ways to gain entry, and even the keyless lock systems and the onboard diagnostic systems provide possible entryways into the core of the vehicle.

Meanwhile, ADAS software creates complex relationships between various sensors in the car and other actuators. If the car detects a possible collision with the car ahead, it may apply the brakes automatically to slow down faster than the driver can react, avoiding a disaster. The ADAS system must therefore have access to critical parts of the drive and safety systems. Because the Internet connection exposes all of this, we’re again faced with a security challenge.

The problem is that the CAN bus architecture has no security. And CAN bus performance is too slow to support adding security on an ad-hoc basis. So, at this point, automobile manufacturers and their suppliers have no guiding principles on how to implement system-wide security without either inventing a massive system themselves or just plugging security leaks one by one as they’re found.

While the amount of basic ECU software may grow at a nominal pace, the amount of ADAS and infotainment code is exploding. This creates an ongoing challenge for developers: how can they be sure that they’re not creating opportunities for someone to break in and begin toying with the vehicle’s critical components?

And it’s not just a consideration within the vehicle. Car-to-car communication, which is critical for ADAS systems to sort out what else is happening on the road and how to respond to challenges, means that, technically, all cars within listening range of each other are also on the same network, potentially putting each other at risk.

Help is coming – eventually

Change is difficult in industries where it can take five years for a new concept to go from idea to the dealership. Even the very need for security has seen pushback, since it represents a fair amount of work to retool operations with a secure mindset. It’s taken dramatic demonstrations like the Jeep hack to show that this really matters.

Fortunately, CAN FD, the next generation of the CAN bus standard, has the performance required to support security. It is 4 times faster than CAN 2.0 and has a 64-byte payload instead of the 8 bytes that CAN 2.0 provides. It hasn’t been formally approved yet, but a solid draft exists, and it is expected to be adopted in due time.

The new architecture moves from the highly distributed nature of things today towards a more centralized, controllable structure. ECUs can be merged within domains, with domain controllers acting as firewalls protecting their domain. Ultimately, these domain controllers themselves can be merged, providing a central locus of authentication and access authorization. Carefully selected secure microprocessors can manage a secure boot process and enforce isolation and trusted zones to protect against rogue software gaining access to critical resources.

CAN FD is a major change from the current CAN architecture, so the rollout will involve five to eight years of checkout and evaluation (and resistance), followed by eventual adoption. This is good news for security – in the long term. In the meantime, something must be done to protect the cars being launched before CAN FD becomes the standard way to do things.

Holding down the fort

Even though CAN FD is awaiting formal approval, CAN FD transceivers are available today. This provides an opportunity to add security now, in advance of formal adoption. Security can be added in a number of ways. Secure microcontrollers exist, although they’re typically higher-end processors, and so they might be out of range of an ECU cost target.

Instead, TADs, which provide crypto functionality, or border security devices, which combine a TAD with a CAN FD transceiver, can be used to ensure that each ECU is protected. They can be placed between a processor with a CAN 2.0 transceiver and a CAN FD bus, providing added security with a minimal amount of ECU design change.

The crypto functionality supports strong authentication of anyone trying to access the ECU. It will also encrypt communications, favoring elliptical curve cryptography for newer chips; this either gives stronger protection or allows shorter keys than older RSA encryption. However, existing modules may have RSA encryption as part of an ad-hoc security scheme, so the devices will provide RSA functionality as well.

Critically, all of the cryptographic functions will be executed in hardware, making it impossible to examine cryptography code as its running. This also improves performance, reducing any additional overhead needed for security. In addition, the border security device will protect any keys in a manner that makes it impossible for anyone – authorized or not – to see any of the keys. Tamper-proof features mean that a determined snooper will not be able to crack open the border security device in an attempt to extract its secrets by brute force or through side-channel attacks.

Security is available today

TADs and border security devices are available now from companies like Atmel. This makes it possible to start immediately to address the serious problem that faces the automotive industry today. While awaiting the improvements that CAN FD will bring in five or more years, lines of code are being added at a furious pace without waiting for CAN FD approval.

Automobile modules designed today with TADs or border security devices can go a long way towards eliminating the serious vulnerabilities that are riding around our roads.