Tech Trends: Security concerns for next-generation automotive electronics

In 2010, U.S. carmakers introduced a feature to enable car owners to manipulate the locks and start the engine from anywhere on the planet using a smartphone. This connectivity piggybacks on the car’s remote telematics system, which has become standard in many models.

Just prior to this smartphone introduction, a team of university researchers published a study demonstrating how such a car’s critical systems—brakes, engine throttling, etc. —could be maliciously tampered with by exploiting vulnerabilities in the car’s embedded systems (see Reference).

The researchers learned how to bridge from the low security network to the critical systems using "fuzzing" techniques. Brakes and engine were disabled while the car was in motion, demonstrating that the attacks could indeed place passengers in peril.

Connecting the automobile to wide-area networks is exactly the trigger that brings in the threat of sophisticated attackers. A single flaw may allow a remote attacker to perpetrate damage to an entire fleet of vehicles.

What the researchers do not talk about is what we can do about embedded automotive security today. As we’ll discuss later, practical changes must be made to better isolate the network subsystems and secure critical functions.

Modern automobile electronics
The figure below shows a selection of electronic systems within the modern automobile.


High-end luxury cars contain as many as two hundred microprocessors in these systems across one hundred components or electronic control units (ECUs). Multiple networks of varying type, including Controller Area Network (CAN), FlexRay, Local Interconnect Network (LIN), and Media Oriented Systems Transport (MOST), connect these ECUs, The car OEM integrates ECU components and software from dozens of Tier-1 and Tier-2 suppliers. But the OEM does not rigorously control their suppliers’ development processes.

It should come as no surprise that this situation has become untenable. OEMs are suffering from the "longest pole" syndrome: A single ECU, delivered with serious reliability problems, may be all that is needed to cause shipping delays or failures that harm reputation.

Security threats and their mitigation
Security threats to vehicles can be classified in three domains: Local-physical, remote, and internal-electronic. Combinations of these will often be required to inflict damage.

Local-physical threats
An example of local-physical threat would be someone physically tapping into the drivetrain’s CAN network and disrupting communications. Such an invasive attack can quite easily disable critical car functions. However, a local attacker, such as a disgruntled mechanic, can harm only one car and is therefore unlikely to get the attention of security teams. Furthermore, a car’s complex electronic system is simply impractical to protect from physical attack. So we generally punt on this class of threats.

There is, however, one exception: Somewhere within one or more ECUs, private cryptographic keys are stored for use in creating protected communication channels and to provide local data protection services. The figure below shows some examples of long-range radio connections in next generation vehicles.


Data protection may be required for automotive algorithms, multimedia content, and cryptographic material. Private key storage must withstand sophisticated physical attacks, both invasive and non-invasive, because the loss of even a single key may enable an attacker to establish connections into remote infrastructures where widespread damage can ensue.

OEMs must be able to achieve assurance of key protection across the entire life cycle, from creation and embedding into ECUs, to delivery and integration within the car, and in the field. Embedded cryptographic experts such as Green Hills Software, Mocana, and Certicom can help OEMs and their suppliers with guidance and oversight in this area.

Remote threats
These are the classic attacks: A hacker tries to probe the car’s long range radio interfaces for vulnerabilities in network security protocols, Web services, and applications to find a way into the internal electronics complex. In contrast to data centers, the car is unlikely to possess a full complement of IDS, IPS, firewalls, and UTMs. Regardless, recent intrusions at Sony, Citigroup, Amazon, Google, and RSA starkly demonstrate how these defense mechanisms are like Swiss cheese against sophisticated attackers.

When the Stuxnet attack came to light in 2010, U.S. Department of Defense CYBERCOM chief General Keith Alexander suggested that the U.S.’s critical infrastructure be isolated on its own secure network, distinct from the Internet. While this may seem heavy-handed, it is precisely the kind of thinking needed. A car’s critical systems must be strongly isolated from ECUs and networks not critical for safe operation.