Strong encryption is essential, but the process of encrypting data is not that challenging, and nor is using the relevant tools, says Jonathan Carter
Strong encryption is an essential defense in the battle to protect sensitive data. This is because hackers will often choose to target an application that relies upon hardcoded keys. These applications retrieve relevant keys from a local space in an obfuscated location such as a file or the code’s binary embedded resources. The attacker discovers these secret locations via static analysis tools like IDA Pro. Once they discover these locations, they can immediately retrieve the targeted keys (via malware), decrypt the code’s sensitive data and even transmit it to a third party.
Best practices around encryption-based software security consistently recommend that software running in a hostile environment should avoid the use of hardcoded keys when encrypting or decrypting sensitive content. Instead, code should leverage keys that are derived at runtime from dynamically generated content such as user input (typically passwords) or runtime properties of the local environment. These practices make sense and accurately address the nature of most ‘low hanging fruit’ for hackers within cryptographic attacks.
Typical Dynamic Key Generation Strategies
Let’s examine a common scenario of how a software engineer might apply best practices to a local cryptographic module that is running within a hostile environment:
In this scenario, the cryptographic module generates a dynamic key (depicted as green in figure 1) that it uses to encrypt or decrypt a local storage file (depicted as a blue cylinder in figure 1). Typically, this capability is necessary when the application must operate in an offline environment.
Here, the code generates a random dynamic key by combining a locally ‘baked in’ hardcoded key (K2 in figure 1) with runtime properties of the local environment (in this example, an Android Host ID comprised of the processor, hardware, and serial number of the device) through the use of an AES 128-bit CMAC algorithm. The app then uses the newly generated 128-bit key for subsequent encryption or decryption of the local storage file (depicted as red arrow keys in figure 1).
Unchecked Risks Remain With Dynamic Key Generation Strategies
There are still potential pitfalls that surface along the way of generating a dynamic key as we follow the typical ‘best practice’ scenario. Best practice recommends that organizations should use industry-standard algorithm implementations that have been vetted and comply to standards like FIPS 140-2.
However, common encryption implementations represent a new source of technical risk. By their very nature, industry-standard implementations of cryptographic algorithms use keys that have very popular binary signatures. This means that hackers can perform dynamic analysis of an application’s memory space to identify and retrieve keys with these signatures. Hackers used this technique in the recent Target attack where the hacker scraped the PoS’ memory to obtain data (credit cards) that matched a particular pattern.
The Solution Involves Whitebox Cryptography
In order to make dynamic analysis and reverse engineering of keys particularly painful and tedious for the hacker, it is best to use a whitebox cryptography solution that does not contain any of the typical binary signatures found in common implementations of keys:
In this version of the solution, we still generate a unique 128-bit dynamic key by combining the hardcoded key (K2) with properties of the device via a CMAC algorithm. However, we have replaced an industry-standard implementation of CMAC with a whitebox equivalent that requires and produces special whitebox keys. This alternate whitebox CMAC implementation adds further levels of transformation to the final output (in this case, denoted as green arrows in figure 2) to further obfuscate the nature of the whiteboxed key.
After generating the heavily transformed CMAC key, we apply a SHA hash (as denoted by the ‘expand’ box in figure 2) to double the CMA 128-bit key to a 256-bit key. We use mismatched transformations and convert the incoming ‘green’ transformation and apply an additional ‘red’ transformation to it. This further obfuscates the nature of the original whiteboxed key to the attacker.
After key expansion to 256 bits, we have two 128 distinct keys that are used separately for either encryption or decryption. Our whitebox solution requires different keys for either AES encryption or decryption. Normally, AES algorithms use one key for both encryption and decryption. The requirement of two-distinct keys will further confuse the hacker as it adds yet another level of complexity to any attempt at reverse-engineering the original keys or understanding the underlying algorithms.
Conclusions
Dynamically generating keys is a good start to properly implementing cryptography to protect an asset. However, the use of classic industry-standard cryptographic implementations opens the window for key theft via dynamic analysis in an application’s memory. When dealing with particularly sensitive assets, it is best to apply whitebox cryptography as an additional layer of protection against reverse engineering and key theft.
About the Author
Jonathan Carter is an application security professional with over 15 years of security expertise. As a software engineer, Jonathan produced software for online gaming systems, payment gateways, SMS messaging gateways, and other solutions requiring a high degree of application security. Jonathan’s technical background in artificial intelligence and static code analysis has led him to a diverse number of security roles. Jonathan is technical director, Arxan Technologies and mobile project lead with OWASP.