Solving an Alarming Cyber-Security Vehicle Vulnerability for CAN Bus Hacking

Yes We CAN!

Solving an Alarming Cyber-Security vehicle Vulnerability of the Aging Automotive CAN Bus

Since its invention three decades ago, the Controller Area Network (CAN), a network of independent controllers that share information, has revolutionized vehicular communications. As car and truck manufacturers deploy more controllers in vehicles, the role of the CAN network is expanding greatly. With today’s vehicles utilizing more than 100 electronic control units (ECUs), a typical vehicle will host from two to as many as seven CAN networks.

Illustration of CAN bus in connected cars and the vulnerability for CAN bus hacking

While networking technology has advanced significantly since CAN’s introduction, the CAN bus itself has remained largely unchanged. CAN has performed admirably up to this point, but as the cyber-attack landscape grows, security flaws in the CAN bus standard are being exposed which enable vehicle hacking.

Recent research has shown one particularly alarming flaw, damaging performance and impeding safety.

Fortunately, GuardKnox offers a cost-effective antidote to this sort of attack for vehicles already in the field as well as newly manufactured ones.

CAN Do: Communications

Think of the CAN bus as a simple network where any system in the vehicle can listen on it and send commands to other systems over the bus. For example, whenever an ECU wants to communicate with another ECU, it simply writes an encoded message, known as a “frame”, onto the bus with the address of its intended recipient. All connected devices receive all the frames, but only the target device, the intended recipient, can decode and process the frame.

CANnot Do: Error Handling

The vehicle’s CAN bus is contended by a growing army of devices connected to it. Errors arise when a device reads values that do not correspond to the original expected value on a frame. When a device detects such an event, it writes an error message onto the CAN bus to “recall” the errant frame and notify the other devices to ignore the recalled frame. This mishap is very common and is usually due to natural causes, transient malfunctions or, most often, by too many devices trying to send frames through the bus at the same time.

When a device writes too many error messages, this is a sign that the device itself may be malfunctioning. So as not to allow a malfunctioning device to “hog” the bus, the CAN standard mandates that such a device must enter a Bus-Off state, effectively isolating the malfunctioning device from the network and maintaining the unimpeded functioning of the other devices.

CAN Bus Hacking Attack

Research presented at the 2017 International Conference on Detection of Intrusions and Malware & Vulnerability Assessment (DIMVA) in Bonn has alerted the automotive world to an alarming CAN bus hacking vulnerability. The authors of the research show that their discovery involves an actual working local attack that is not only undetectable and vendor-neutral, but also cannot be easily resolved by simple remote patches or updates.

The Denial of Service (DoS) attack consists of rapid, malicious changing of a specific CAN frame bit from “1” to “0” or vice versa by a device connected to the vehicle’s OBD port (mandatory since 1996 for all cars manufactured in the US to be sold in the US and for all gasoline vehicles sold in the EU since 2001 and diesels since 2004) or alternatively, by a hacked ECU, or an ECU operated from externally injected malware. The targeted device reacts to the repeated erroneous messages by putting out an error message each time. Eventually, the targeted device writes so many error messages onto the CAN bus that it is forced to enter the Bus-Off state and cease communicating altogether. Bus-Off can drastically affect the car’s performance to the point where it becomes dangerous or even fatal. What if this is the airbag or braking system?

Quote showing the vulnerability of CAN bus hacking for airbag or braking systems

A short video covering this attack against an Alfa-Romeo Giuletta using an Arduino processor card connected to the OBD port has been published on YouTube. It shows how the perpetrators, the authors of the research, were able to disable the parking help/support sensors. The authors could have disconnected other systems in the car including safety mechanisms like door locks, air bags and even the steering wheel. The software that perpetrated this attack is, in fact, available as open source on GitHub.


The challenge to mitigating this pernicious DoS attack is to detect it before the denial of service has been executed, i.e., before the targeted device goes to Bus Off state. The following defenses have been suggested:

  • Power drain detection: A system or program notifies about possibly malicious devices added to the CAN bus network. It detects strange or additional drains to the bus current. This mitigation is useless if no additional malicious device is added to the network (the attack comes from the corruption of an existing ECU, for instance) or if such a device does not cause a sufficient drain.
  • Error determination: A system or program detects possible malicious devices through the nature of the error frames being sent. Malicious errors repeat and will present themselves as identical to each other. This mitigation is ineffective. Existing CAN bus IDS/IPS technologies are essentially based on the anomaly-detection of malformed frames because, in the majority of attacks, an injection of frames is needed. However, this particular CAN bus hacking attack is based on the transmission of bits concurrently with the transmission of a legitimate frame. From the receiving device’s point of view, there would simply be a frame transmission interrupted by an error. A frame analysis-based IDS would only notice the effect of this attack, i.e., the receiving device going to Bus Off state. But this would be ineffective in mitigating the attack itself since the detection would only take place after the fact.
  • Network Segmentation or Topology Alteration: Create various CAN sub-buses, or change the network topology from a bus to a star, to prevent free circulation of CAN frames to all devices. This is impossible for cars already on the road and, in any case, it merely reduces the number of targets of the DoS attack, but doesn’t eliminate it.
  • Regulated OBD-II Diagnostic Port Access: Require a special hardware key to open the case where the OBD II port is physically located, or implement a software-level authentication of traffic from and to the port. This would require a change in government regulations.
  • Encryption: Encrypt CAN frame ID fields to prevent attackers from identifying CAN frames to target, resulting in a noisier and much more detectable attack pattern. This will require a change in CAN standards.
  • GuardKnox’s Communication Lockdown™: Read on to see how GuardKnox successfully addresses CAN bus vulnerabilities.

More radical changes in automotive systems architectures have been proposed by others. All of these changes are problematic due to their cost, logistics and implementation time frame.

So, what will happen with the millions of existing and unprotected vehicles on the road today? Are they destined to remain vulnerable for years to come? Will new vehicles join the ranks of the unprotected?

Solution by GuardKnox

GuardKnox’s Communication Lockdown™ methodology takes a similar approach to automotive cyber security as the protection deployed in F-35I and F-16I fighter jets, as well as the Iron Dome and Arrow III missile-defense systems.

The Communication Lockdown™ approach eliminates risks to the safety and security of the vehicle by enforcing a formally verified and deterministic configuration of communication among the various networks of the vehicle. It enforces the allowed “legal” communication, while being completely impervious to attacks. The core functionality is deterministic, thus preventing any possibility of attacks causing changes in functionality. Protection is provided through the GuardKnox Secure Network Orchestrator™ (SNO) that ascertains that all external network communication is ‘locked down’.

The Communication Lockdown™ solution delivers consolidation, lower complexity, easier certification and overall cost reduction. The GuardKnox technology and software stack can be implemented in various hardware architectures thus easing the integration process for existing automotive computers.

How is Communication Lockdown™ better?

  1. No false positives: Communication Lockdown™ is not a ‘learning based’ mechanism; there are no false positives.
  2. Fully deterministic: No statistical mechanisms nor need for heuristics, Communication Lockdown™ is not reactionary!
  3. Stand-alone operation: No need for constant updates nor configurations.
  4. No constant communication: There is no need for cloud connectivity nor regular updates.
  5. Seamless integration: Easily incorporates into the vehicle without the need for third-party integrations and fits the existing Automotive Tiered Value Chain.
  6. Agnostic to both present and future attacks: The Communications Lockdown™ approach is not to look for attacks but to ensure the vehicle continues to function in the way it was designed.
  7. Added functionality: The methodology introduces foundations for new revenue streams for OEMs and changes the way end-users interact with their vehicles.

For an in-depth review of the cybersecurity threats landscape for the automotive industry, download our industry report here.

The cyber security threat landscape for automotive market and connected vehicles cyber defense