which may contain portions of cryptographic key material used to secure communications between that server and the outside world. Exposing keys can lead to compromise the very (sensitive) data being protected by that secure communications channel. To protect encrypted information, it is imperative that the key never reveals itself in memory or on disk. Standard crypto implementations (as were exploited in OpenSSL in the aforementioned Heartbleed attack) leave both the algorithm and key vulnerable to tampering and reverse engineering. White-box cryptography mathematically transforms the key into a complex graph of numbers and executable code. This graph has multiple valid paths randomly chosen at runtime based on a user-supplied random source. Combining mathematical algorithms, data, and code obfuscation techniques to transform the key and related crypto operations in complex ways requires deep knowledge in multiple disciplines to attack. Importantly, the key is never present in static or runtime memory. Rather, the key becomes an inert collection of data that is useless without the uniquely generated white box algorithm. In short, replacing the standard cryptographic libraries with a white-box enabled library would never expose the keys, thereby preventing such attacks from ever being effective. Important techniques in a white box implementation White-box products and technologies vary from institution to institution. Naturally, certain features and techniques are stronger than others. The following techniques should be considered fundamental to any white-box implementation for use in a potentially vulnerable system: Diversity Rather than implementing a single white-box cryptography algorithm for all users (which would lead to break-once-run-everywhere attacks), code generators should be used to produce unique variants of the algorithms. This mitigates first pass observations of sensitive data (i.e., keys or selected plaintext). Uniquely, “tailored algorithms” also eliminate algebraic attacks that could easily unwind data protections that result from understanding a single standard implementation. Algorithms should be implemented using alternate mathematical methods. White-box algorithms should not simply automate transformations of standard algorithms. Each algorithm/ cipher should be modified in ways that leverage the specific properties of the underlying mathematics; blanket transformation should never be applied over all algorithms. Hardware binding Software is inherently easier to attack than hardware. By simply copying the original software system bit for bit, an attacker is guaranteed unlimited attempts to break the system. Hardware however can enforce more permanent penalties. A strong whitebox cryptography implementation should take advantage of hardware when available to limit reverse engineering attempts on the obfuscated algorithm(s). One such technique includes hardware binding. Cryptographically binding a hardware identifier to the white-box algorithm and/or data forces an attacker to reverse-engineer a complex, dynamically changing key-graph while tied to a single hardware system—a system that can enforce more permanent penalties should an intrusion be detected. Side-channel resistance Resistance against side-channel attacks (such as simple or differential power analysis) is paramount to protecting the key material from exposure. A solid white-box cryptography implementation should utilize numerous side-channel analysis countermeasures to resist exposing the key to such attacks. Important obfuscations Certain attacks against many cryptographic algorithms may yield well-known answers. Many times, standard cryptography algorithm designs result in implementations that have fundamental vulnerabilities to white-box attacks because they make an explicit assumption of executing on a secure host. A strong white-box implementation should not preserve these vulnerabilities. Fig. 2: A diverse white-box implementation should include randomization and multiple transformation obfuscations leveraging the underlying mathematics of the cryptography algorithm. White-box obfuscations should prevent well-versed attackers from exposing the underlying mathematical principals of an algorithm to trick the algorithms into yielding an obfuscated version of a well-known answer. Additionally, obfuscations such as round boundary blurring should be employed to hide clear cut attack points that would compromise, as an example, an AES round. Using white-box cryptography, keys are made unavailable to an attacker forcing them to go through the pain of reverse engineering complex and numerous combinations of obfuscation transformations with a detailed understanding of Abstract Algebra and Discrete Math. Given the rise in mobile Internet connected devices combined with a growing need for secure operations and communications, a strong white-box cryptography implementation using (at a minimum) the techniques described above should be considered an essential component to any software system using cryptography. www.electronics-eetimes.com Electronic Engineering Times Europe July/August 2014 37

EETE JULAUG 2014

To see the actual publication please follow the link above