Protecting Connected Cars from Cyberattack

The smart features built into new cars open the door to serious cyber threats. Linked to the internet, connected cars offer cybercriminals the potential ability to remotely access and manipulate the data these systems rely on, which can lead to problems such as exposure of personal information, compromised vehicle security mechanisms or even full control of the vehicle itself.

Innovative automakers, software developers and tech companies are transforming the automotive industry. Drivers today enjoy enhanced entertainment, information options and connection with the outside world. As cars move toward more autonomous capabilities, the stakes are rising in terms of security.

Even if cars are not entirely driverless, their built-in functions are increasingly dependent on applications, connectivity and sensors. Vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications already allow a car to interact with service providers and infrastructure such as traffic lights. With vehicle speed adjustments, telematics and AI voice recognition and interfaces set to become common features, the risks are growing at an alarming rate.

The rapid increase of these technologies inevitably creates a rich target for hackers looking to gain access to personal information and control the essential automotive functions and features. The real possibility to access information on driver habits for both commercial and criminal purposes, without knowledge or consent, means attitudes toward prevention, understanding and response to potential cyberattacks need to change.

Stealing personally identifiable information, for instance, comes into sharper focus when considering that virtually all new vehicles on the road today come with embedded, tethered or smartphone mirroring capabilities. Geolocation, personal trip history, entertainment preferences and financial details are just some examples of the information that can potentially be stolen through a vehicle’s system.

Connection Security as a Threat Vector

Like other connected devices, it is inevitable that bad actors will exploit vulnerabilities in connected automotive systems. The current poor state of security on connected cars creates a tempting target. For example, catastrophic incidents resulting in personal injury and lawsuits may surface in the near future due to remote manipulation of cars in operation. Conceptual attacks have been emulated in which hackers were able to control the braking and steering of a car by accessing the adaptive cruise control system.

Connectivity also now affords thieves a new way to gain unauthorized entry to locked vehicles. Many manufacturers have opted to replace physical ignitions with keyless systems using mobile applications or wireless key fobs. These are open to illicit entry from wireless communication intercepts between the vehicle and the mobile application or between the wireless fob and the vehicle to gain entry credentials. Wireless key emulation devices and “power amplifiers” that increase the range of the wireless signal have also been documented.

As more automakers release mobile applications that communicate with cars, these conveniences are quickly becoming a major target. One example of a flaw was the NissanConnect EV application for the Nissan Leaf. Poor security made it possible to connect to the Leaf over the internet and remotely turn on the car’s heated seats and steering wheel, fans and air conditioning. In an electric car, this means a malicious actor could drain the battery of an unsuspecting owner.

How Hackers Attack Connected Vehicles

Understanding the threats to connected cars requires knowledge of what hackers are trying to achieve. Hackers will mount different kinds of attacks to achieve different goals. The most dangerous objective might be to bypass controls in critical safety systems, such as steering, brakes and transmission. But hackers might also be interested in obtaining valuable pieces of data that are managed within the car software, such as personal details and performance statistics. While data can be protected with cryptography, this only shifts the problem from protecting the data directly to protecting the cryptographic keys.

If the hacker is trying to steal sensitive data, such as cryptographic keys, they have to know where to look for them. This usually involves a plethora of reverse-engineering techniques. For example, they might introduce faults into the compiled code to see how it breaks. Or they might look for a string corresponding to an error message related to “Engine failure” or “Anti-lock brake system disabled,” and trace where that string is used. They leverage sophisticated techniques such as static and dynamic analysis to help them understand the overall structure of the code, where the functions are located and how they are called from other functions.

On the other hand, physical access to a device means bad actors can tamper with the application itself. Often, the way this is done is by making one small change to the application code so it can be bypassed in any number of ways, typically at the assembly language level, such as inverting the logic of a conditional jump, replacing the test with a tautology or changing function calls to those of the hacker’s own design.

Application Shielding as Fortification

Application shielding is the process of adding security functionality directly to embedded applications so they can withstand attacks independent of the surrounding environment. It combines prevention, detection, remediation and prediction to go beyond basic best practices. As more applications, connections and sensors run in the untrusted environment of the connected car, heightened security measures are apt to follow.

The goal of obfuscation, one element of application shielding, is to remove as much of the structure as possible that would be familiar to reverse engineers, making the code as confusing as possible while keeping functionality the same. One technique is control flow obfuscation. Programs can be broken down into basic blocks, each of which has a series of instructions followed by some kind of branch. For example, a simple “if” statement might have a comparison of a variable to a constant followed by a branch around the body of the “if” statement if the comparison does not evaluate to true. Control flow obfuscation muddles that branching behavior among basic blocks, making it difficult to follow how the execution of the code jumps from one basic block to another.

White-box cryptography is a highly specialized form of anti-reverse engineering in which a special cryptographic library provides protection for cryptographic keys. The underlying mathematics of the cryptographic operations are obfuscated in such a way that the keys never appear in the clear. Standard operations such as encryption, decryption, key unwrapping and digital signature creation and validation can all be done with white-box cryptography techniques, protecting the keys even if the device is jailbroken or rooted.

Integrity protection prevents attackers from making any modifications to the application code. To achieve this, several sophisticated methods are used. For instance, hundreds of very small functions can be embedded into the code that calculate checksums of code fragments and compare them to the checksums stored at compile time. Another method is to add a signature of the code to the executable and, at runtime, verify if the code matches the signature.

Another tool hackers use to reverse-engineer code is debuggers, which often work by setting interrupts at specific points in an executable, thus modifying it. Application shielding inserts numerous anti-debug checks into a protected application, taking into account the unique indications of the target platform that may identify the presence of a debugger.

Finally, jailbreaking and rooting are employed by hackers to gain privileged access to a device. A jailbroken or rooted device can be used to install a modified version of a car manufacturer’s mobile application. The standard security practice is to prevent the application from running on jailbroken and rooted devices by way of a number of smart detection checks inserted into code.

The automotive industry must create and adhere to industrywide best practices that include end-to-end data encryption and cryptography certificates. By embedding self-defending capabilities into vehicle keyless entry and other connected applications, car manufacturers can prevent tampering, reverse engineering and other techniques used by cybercriminals to gain access to sensitive information and a vehicle’s app code.

One of the most revolutionary inventions of the past century, the automobile has been transformed from a combustion engine to a computing machine with more than 100 million lines of code, processing up to 25GB of data per hour. As connectivity, applications and features multiply, the complexity of the automotive computing platform and the challenge of protecting it will define the future of transportation over the next decade.

Avatar photo

Bill Horne

Bill Horne, Ph.D., is Vice President and General Manager, Intertrust Secure Systems. He leads Intertrust’s Secure Systems division, and is responsible for the company’s application shielding suite of products and device identity PKI services. Prior to joining Intertrust, he was the Director of Security Research at Hewlett Packard Enterprise, where he led a team of R&D security experts who supported HP’s security product efforts. Previously, Horne was a research scientist at Intertrust’s STAR Lab from 1997 to 2002, before which he was at NEC Research Institute in Princeton, N.J. Horne has published more than 50 peer-reviewed articles on topics of security and machine learning, and has 33 granted and 44 pending patents to his name. He holds a B.S. in Electrical Engineering from the University of Delaware, and earned an M.S. and Ph.D. in Electrical Engineering from the University of New Mexico.

bill-horne has 4 posts and counting.See all posts by bill-horne