Protecting applications against DFA attacks

2001 was an exciting time for cryptography, as the new Advanced Encryption Standard (AES) specification was finalized, making a mathematically secure and performant encryption algorithm available to the public.

Designed to replace older cryptographic algorithms that were starting to show weaknesses in their math and being vulnerable to the increasing computing power available to attackers, AES put the power back in the hands of the those trying to protect their data. Attackers quickly recognized that brute force attacks and attacks on the math of AES were going to be ineffective and that they instead needed a new approach.

With the first research paper on the topic published in 2002, Differential Fault Analysis, or DFA, is an attack technique that is designed to recover cryptographic keys from apps by injecting “faults” into the app’s crypto code at runtime and observing changes in the app’s behavior. A fault is essentially flipping a bit inside an internal calculation and observing what changes. Faults can be injected in a variety of ways, such as varying power levels in hardware devices or changing bits of memory in software.

Attackers inject faults at many different parts of the app, until they find a place where a fault changes the output of a crypto operation in a specific way. Based on how the crypto operation’s output changes, DFA and some math can allow crypto keys to be recovered. Once those keys are recovered, any data encrypted with them is vulnerable and at risk.

Originally, DFA was an an attack primarily against hardware devices, where machine code was not readily available for attackers to view. The software case was much more straightforward, since usually crypto keys were clearly visible inside app code, which tools like disassemblers could easily display. For a long time, if a piece of code was doing cryptography, it was kept in a secure environment, where attackers were not able to easily look at app code to find those keys.

This has changed dramatically, as consumers today have many apps on their mobile phones, desktop computers, smart TVs, and even automobiles. Because attackers could now simply look at the code in the app, software apps needed protection for their cryptographic routines and keys. Whitebox cryptography was introduced in 2002, to address this exact concern, the same year the first DFA paper was published.

Whitebox cryptography was introduced to make it possible to provide secure cryptographic implementations in apps where attackers can manipulate the code and data at will. Whitebox cryptography is a way to get the same output for a given input as a normal cryptographic implementation, but the internals of how it is done are completely different from a standard crypto implementation. This makes it very difficult for an attacker to understand what is happening. Because of the difficulty they had understanding whitebox crypto implementations, building off the success in hardware, attackers began to use DFA as a technique against whitebox cryptography in software implementations.

DFA is becoming more common. Various security researchers speak about DFA attacks at conferences, they implement hardware and software DFA attacks, and publish how to do so. DFA is no longer purely an attack limited to academia or high-end security labs. Real world attacks are occurring, and with the proliferation and weaponization of the attack code, the frequency of reported attacks is increasing.

As DFA advances in effectiveness and commonality, it is imperative to ensure that your defenses against it are keeping pace and still able to protect the cryptographic routines inside your app. There are several steps you can take to ensure that you are doing as much as possible to defend against DFA attacks.

The first is ensuring that you are using a modern whitebox cryptography implementation which is designed to defend against DFA and is tested against the latest versions of the attack. Because the attacks grow in sophistication over time, is important to use a whitebox implementation that is actively developed to keep pace with new attacks.

Secondarily, you should ensure that your application is using app shielding to make it more difficult for attackers to mount a DFA attack in the first place. Applications with obfuscation make it difficult for attackers to understand where to inject faults and applications that can recognize when they are under attack can immediately take action to stop the attack before it progresses.