To Black Box Cryptography and Beyond
Assaf Regev
NOV 14, 2012 09:10 AM
A+ A A-

Traditionally, cryptography has offered a means of communicating sensitive (secret, confidential, or private) information while making it unintelligible to everyone except for the message recipient. Nowadays, the process of protecting sensitive data embedded in code, while attempting to hide portions of text from malicious eyes, is an ever-growing concern.

Replay emulators are available that can try to duplicate the behavior of one system onto another while attempting to be as close to the original as possible. In effect, emulators are a form of a man-in-the-middle (MitM) attack.

In the context of software protection dongle emulators, we refer to the following scenarios:

  • Replay emulators (Partial emulators) — This type of emulator can only record and replay the communication between the protected application and the dongle. If the communication is encrypted and different in every new session, this type of emulator cannot understand the communication, rendering it ineffective. If the protected application uses random data strings, the encrypted communication is always different, again deeming it ineffective.
  • Full emulation — This type of emulator can fully understand the communication between the application and the dongle by decrypting the encrypted communication and mimicking functionality, such as memory read/write, and license verification. In some cases, the emulator can replay encrypted blocks to overcome the encryption. Given the strength of today's hardware and the complexity of the algorithms, this scenario is rarely seen.

One of the most effective methods of combating the aforementioned emulation techniques lies in the secure communication channel created between the protected application and the hardware key. Most dongles in use today circumvent emulators using this approach.

Here are some of the concepts involved:

  • Each string of data passing through the channel is encrypted, preferably using a different (random) key.
  • Data "recorded" from one secure communication channel session cannot be replayed in another session — a technique similar to TCP/IP packet counting.
  • Data communicated between the protected application and the dongle should "appear" different every time even if the raw data is the same.

Beyond the Black Box

Traditional cryptography assumes the attacker has no physical access to the key (i.e., the algorithm performing the encryption or decryption) or any internal workings, and instead can only observe external information and behavior (i.e., inputs and outputs). This methodology attempts to hide the cryptographic keys by putting them out of reach of the attacker.

Advances in attacks on hardware have shown that the previously assumed black box performing the cryptography is not completely black to the hacker — it literally became a shade of gray. The gray box was found to be leaking secret information from within the box, which is discovered through various means, such as DPA and other side-channel attacks. This has increased hardware manufacturing companies' awareness of the need to improve the security of crypto-processors themselves, in addition to spurring different thinking about symmetric cryptography. Is there a way to hide a secret key even if the attacker has some access into a supposedly black box?

Symmetric cryptography needs to be performed in pure software only, running in nontrustworthy environments — software running on a machine operated by an attacker is a perfect example. To model the threat correctly, you need to assume the attacker has full control over the machine and can monitor any step the application performs. This is also called a "white-box scenario" (e.g., a software application exposed to debugging). In contrast with previously described scenarios, this needs to handle far more severe threats while assuming hackers have full visibility and control. Hackers can freely observe dynamic code execution, and internal algorithm details are completely visible and alterable at will.

Cryptographic Method Attributes
Figure 1. Black Box.

Attacker is assumed to have:

  • No access to the cryptographic key or the firmware code executing the cryptographic algorithm — zero visibility on code during execution
  • External information, such as plaintext (input) or ciphertext (output) only
  • Considered secure as long as the cipher has no cryptographic weaknesses
Figure 2. Gray Box.

Attacker is assumed to have:

  • Partial physical access to the cryptographic key as a result of the cipher leaking side-channel information
    • Electromagnetic radiation analysis
    • Current/power consumption analysis
    • Operation timing analysis
  • Most ciphers have published side-channel information that fully reveals the cryptographic key or reduces its key size
Figure 3. White Box.

Attacker is assumed to have:

  • Full visibility — inputs, outputs, memory (using debuggers), and intermediate calculations
  • Access to the algorithms while watching how they are carried out

Traditional cryptography is not secure when running in a white-box model

White-box cryptography integrates the cipher in a way that does not reveal the key and is therefore highly secure

The fully transparent environment was calling for a new type of cryptographic approach, also called "white-box cryptography," that raised the following challenges:

  • How to encrypt or decrypt content without directly revealing any portion of the key, and
  • How to perform strong encryption processes knowing that hackers can observe and/or alter the code during execution.

White-box cryptography went head-to-head with traditional security models. With traditional black-box implementations, the attacker only had access to inputs and outputs and to the cryptographic algorithm under attack but had zero visibility into internal workings. White-box cryptography provides full visibility instead. It aims to protect implementations of cryptographic algorithms in software against key recovery attacks conducted while operating in a fully transparent, potentially hostile execution environment.

How is it then possible to securely "hide" the key within the executed code assuming that one can fully monitor and alter each instruction? Abstractly speaking, this is achieved by combining the secret key with data derived from a mathematical operation that is virtually impossible to invert.

This implementation allows developers to build a system that operates much like a full public/private key scheme but much closer to a standard symmetric cipher in performance. The decryption function can be implemented inside the distributed application but the key itself can't be extracted and the decryption can't be reversed, which enforces the encryption operation correctly.

Although the white-box scenario is considered unsuitable for security-related tasks, white-box cryptography shuffles all the cards and provides a highly secure method for performing encryption while operating in a fully transparent environment. Both encrypt and decrypt operations maintain sensitive data without revealing any portions of the key. In addition, white-box cryptography permits the execution of strong encryption mechanisms (in conjunction with other techniques), while assuming malicious eyes constantly scrutinize the code during execution.

Security comes at a certain cost and, as a result, cannot be airtight. One must understand that the overall security of a protected application is highly dependent on the implementation itself. For example, solely using a strong cryptographic algorithm doesn't provide any security if it's not used in the context it was designed for. Using traditional cryptography in a white-box environment greatly increases the risk of attackers reverse-engineering the protected software and overcoming its "secure channel." As a result, they are able to extract the session key from memory and "peek" into the encrypted channel.

In the past, most attacks have attempted to exploit software security flaws and not weaknesses in the cryptographic algorithms, but, lately, attackers have recognized and exploited the vulnerability of classic cryptography in the open PC environment. It is implicit that software protection must receive specific attention throughout the design and implementation stages, in addition to being continuously enhanced as part of the product lifecycle and the release of new versions. In addition to white-box cryptography, other complementary security measures should be used to further strengthen the overall protection scheme.

by Assaf Regev, SafeNet Inc.

[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment:

Computing Now Blogs
Business Intelligence
by Keith Peterson
Cloud Computing
A Cloud Blog: by Irena Bojanova
The Clear Cloud: by STC Cloud Computing
Computing Careers: by Lori Cameron
Display Technologies
Enterprise Solutions
Enterprise Thinking: by Josh Greenbaum
Healthcare Technologies
The Doctor Is In: Dr. Keith W. Vrbicky
Heterogeneous Systems
Hot Topics
NealNotes: by Neal Leavitt
Industry Trends
The Robotics Report: by Jeff Debrosse
Internet Of Things
Sensing IoT: by Irena Bojanova