Tales From the enCRYPT: Protecting Applications Against DFA Attacks

2023 promises to be an eventful year for cryptography. We’ll likely begin to see our first certifications for FIPS 140-3 and more serious explorations of the impact quantum computing has on encryption. Additionally, we’ll see more protections against the powerful DFA attacks that otherwise bedevil cryptographers. 2023 may even be the most exciting year in cryptography since 2001 when the (then) 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 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, where 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. First those environments were the physical property of technology companies. Today every company is a technology company, and the physical and “virtual” security of technology/software/secrets/keys is in most cases left in the formidable hands of giants such as AWS, Google Cloud, and Microsoft Azure.

The other difference we face in 2023 is that much of the technology we create lives in neither the well-protected (we assume) cloud or in corporate data centers. Rather, software/tech and even keys live in apps that consumers have on their mobile phones, desktop computers, smart TVs, and automobiles. Because threat actors can now simply look at instructions that make up the app, software apps need protection for their cryptographic routines and keys. White-box cryptography was introduced in 2002 to address this exact concern, the same year the first DFA paper was published.

White-box cryptography was introduced to make it possible to provide secure cryptographic implementations in apps where attackers can manipulate the code and data at will. White-box 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 white-box crypto implementations, building off the success in hardware, attackers began to use DFA as a technique against white-box 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 here, 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 white-box cryptography implementation which is designed to defend against DFA and is tested by a reputable 3rd party. Because the attacks grow in sophistication over time, is important to use a white-box implementation that is actively developed to keep pace with new attacks.

Secondarily, you should ensure that your application is using app shielding (aka in-app protection aka code obfuscation, anti-tampering and anti-code lifting techniques) 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 (aka apps with anti-tamper) can immediately take action to stop the attack before it progresses.

To learn more about how to protect your mobile, desktop, and server apps, check out our Digital.ai White-Box Cryptography solution brief.