Connected Cars and IoT Devices – Protection Against Class Breaks is Essential

Our Managing Director, Thorsten Held, recently penned an article for Connected Car Tech. titled Are Connected Cars a Hacker’s Dream? All of the wonderful connectivity that a connected car promises opens a Pandora’s Box of opportunity for a seasoned hacker as he mentions:

All of this connectivity means that the potential for data leaks, malware, or worse, will intensify, especially where mobile apps are concerned. Aside from data trolling on user behavior information (where did you go? What did you buy there?), the potential for systemic hacks that subvert a car’s control systems and breaks is now a reality. The critical question is: how can car manufacturers reduce the potential for data leaks and attacks?  

That really is the question, not just for automobile manufacturers, but for almost any connected device looking to capitalize on the Internet of Things (IoT). Today, IoT goes beyond cars to kitchen appliances, thermostats, even wearables and clothing. Really, any connected device needs to be treated much like applications from a security standpoint and use robust software protection schemes to prevent attacks and prevent the theft or tampering with proprietary algorithms. But not all software protection is the same…

Although there are code protection techniques on the market, many do not protect against class breaks (sometimes called “Break Once Run Everywhere (BORE) attacks”). A class break is an attack that, if successfully executed on one software instance, could be similarly applied to crack all other instances of the same software. Typically all copies of the target software have the same binary code image, enabling an adversary to develop a generic reverse-engineering scheme. 

Sensor technologies in IoT devices need to be “hardened” to resist hacker attacks. Other software protection best practices include code protection starting at the source code level and white-box cryptography.  Code protection is a tool used to “harden” software application code to prevent reverse engineering and other techniques used by cyber-criminals to gain access to sensitive information and resources contained in applications. It achieves an unprecedented level of security by applying effective integrity protection, code obfuscation, anti-piracy, and anti-debug techniques to application code; whereas white-box cryptography keeps secret cryptographic keys well hidden within app code even during runtime. 

Here’s a rundown of three security schemes to protect against class breaks, and that can help secure connected devices like automobiles:

1. Software diversification is a leading protection technique against class breaks. It significantly increases the time and cost of attacking an installed base of protected applications. Essentially, the attacker must crack each copy of the application. For this reason, software diversification should be a de facto means to protect software applications that are distributed in large numbers to consumer devices, such as desktop computers, mobile devices, and game consoles.

There are two types of software diversification – data and code. Applications containing cryptographic operations should employ at least one, but preferably both, types of software diversification.

2. Data diversification is a relatively simple method that enhances protection against class breaks. With this method, certain embedded data values referenced by the program code vary among different instances of the same application. For example, this data value could be a key that encrypts a database stored on a device, or that encrypts other keys imported into the application. If a hacker manages to extract the key from a particular application instance, he would not be able to use that key to decrypt the secrets of other application instances.

To use data diversification, unique and “personalized” data values have to be injected into the binary image during code compilation or deployment.

3. Code diversification is a much more sophisticated and robust (and usually, more costly) protection against class breaks than data diversification. With this method, binary instructions vary between different instances, or between separate sets of instances. Code diversification is typically a result of applying in-house or vendor-supplied tamper-resistance techniques. This may include code obfuscation, instruction set randomization, integrity protection, anti-debug and anti-dumping techniques, code signing, or virtualization. In most cases, for the sake of performance and simplicity, it is enough to diversify just the sensitive parts of the program code (like the cryptographic routines), but in other cases, the protection can benefit from diversifying the whole executable.

As Thorsten concludes in his article:

It will take only one data breach that causes a serious accident to wake up automobile manufacturers and drivers to how susceptible our connected cars are to data breaches. To avoid hackers taking control of fundamental vehicle functions, car manufacturers will have to ensure applications are secured to protect IP, drivers and their corporate reputations.

Photo credit to Kurt Bauschardt.