The primary goal when designing block ciphers is to approximate ideal block ciphers and hence to obtain a black-box secure cipher. However, in real-world applications, block ciphers are implemented in either hardware or software on physical devices. If the end-users of the communication channel who are in possession of these cryptographic physical devices can no longer be assumed to be trusted, the attacker no longer complies to the black-box model and thus the attack scenario changes drastically. The existence of grey-box and white-box cryptanalytic techniques shows that a black-box secure block cipher does not automatically lead to secure hardware/software implementations. In view of this additional threat, it clearly is insufficient to solely focus attention on designing block ciphers close to be ideal. As it turns out, an attacker will always look for the weakest link in the security chain in order to break the block cipher, hence a secure implementation plays an equally important role. This has been shown by the fairly simple entropy attack and S-box blanking attack with regard to software implementations of block ciphers employed in the white-box model. As a consequence, a natural question is: “Are there techniques to construct software implementations of block ciphers that offer a sufficient level of robustness against an attacker in the white-box model?” The answer may be found in white-box cryptography, to which the second part of this thesis is dedicated. In particular, Part II elaborates on the design and analysis of white-box AES implementations.
Part II
Design and Analysis of
White-Box Implementations
Chapter 3
Design and Analysis of
White-Box Implementations
AES-128 as a Case Study
From Part I of this thesis it follows that it is crucial to implement a cryptographic primitive, such as a block cipher, with respect to the attack model in which it will be deployed. Especially since the introduction of the realistic grey-box and white-box attack models. An attacker within these attack models is considerably more powerful than a black-box attacker, i.e., instead of having only oracle access (i.e., input-output behavior) to the block cipher, the attacker furthermore has (limited) access to the hardware/software implementation of the block cipher. Hence, in the grey-box and white-box models, the attacker mainly focuses on weak implementation designs instead of weak cipher designs (in the case of a public specification of the block cipher). The research domain that specializes in developing secure software implementations of cryptographic primitives employed in the white-box model is called white-box cryptography. The resulting implementations are referred to as white-box implementations. This chapter first elaborates on the objective of white-box cryptography and how this objective can be achieved in a practical manner with regard to block ciphers (both the encryption and decryption routine) by presenting a broad overview of the generic white-box techniques proposed by Chow, Eisen, Johnson and van Oorschot [23, 24] in 2002. Further, it describes in detail the first published white-box AES implementation presented by Chow et al. [23]. Second, this chapter elaborates on when a white-box implementation is insecure, followed by a
complete overview of the analysis of Chow et al.’s white-box AES implementation. Finally, the concluding remarks outline an introduction to the following chapters.
3.1
White-Box Cryptography
White-box cryptography is a fairly recent research domain; it was introduced by Chow, Eisen, Johnson and van Oorschot [23] in 2002. Its existence emanates from the ever increasing demand to deploy strong cryptographic algorithms within software applications that are executed in an untrusted, possibly hostile, environment. In such an environment, referred to as the white-box environment, it is assumed that the attacker is in possession of the hardware/software of the cryptographic primitive, and furthermore has full access to its software implementation and full control over its execution platform. The powerful capabilities of an attacker in the white-box environment, referred to as a white- box attacker, are encapsulated by the white-box attack context [23] (see Def. 8 on p. 30). Although the white-box attack context is the worst case attack model with respect to cryptographic software (here, the term ‘worst case’ is from the perspective of the designer of the cryptographic software), the use case discussed in Chapter 1 illustrates that it is at the same time also a realistic attack model. White-box cryptography aims at protecting the software implementation of cryptographic primitives when executed in a white-box environment. The objective is to provide a sufficient level of robustness against a white-box attacker. What is meant by this robustness against a white-box attacker? When is a software implementation of a cryptographic primitive considered to be secure within the white-box attack context? The following statement should provide a preliminary answer.
Definition 14 (White-box cryptography). White-box cryptography is a
technique that aims at transforming a cryptographic primitive into a func- tionally equivalent software implementation in such a way that the software implementation behaves as a “virtual black box”, i.e., a white-box attacker who has full access to the software implementation as well as full control over its execution environment has no additional advantage over a black-box attacker restricted to oracle access to the implementation in order to achieve his goal (i.e., total break or global deduction). In the foregoing, both adversaries are assumed to be computationally bounded.
Note that Def. 14 is similar to the one given by Wyseur in his doctoral thesis [103, p. 36, Def. 3]. Recall from Sect. 2.4 that the assessment of the security of (the implementation of) a cryptographic primitive is based on a security notion, which comprises the following two factors: (i) the attack model and (ii) the
WHITE-BOX CRYPTOGRAPHY 57
attacker’s goal. Observe that both factors are present in Def. 14. First, a white- box and black-box attacker refer to an attacker in the white-box and black-box model, respectively. Recall from Sect. 2.4.6 that the number of queries is always bounded in the black-box model, but not in the white-box model. Second, the attacker tries to achieve his goal, where typically two different goals (out of the hierarchical classification given in Sect. 2.4.4) play a crucial role in the field of white-box cryptography, i.e., total break (i.e., key recovery) and global deduction. Section 3.4 elaborates in detail on the achievement of both goals within the white-box environment.
With regard to Def. 14, it is interesting to make the following two observations.
1) The white-box model is forced into the black-box model. As mentioned
in the introduction of the grey-box attack model in Sect. 2.4.5 on p. 28, the traditional black-box model assumes that any implementation of a cryptographic primitive behaves as an ideal black box (referred to as a virtual black box in Def. 14). Hence white-box cryptography strives to ensure that the white-box model does not provide any additional advantage over the black-box model.
2) White-box cryptography is a ‘special’ obfuscation technique. Note that
Def. 14 closely resembles the informal definition of an obfuscator of programs introduced by Barak et al. [1]:
Definition 15 (Program obfuscation [1]). Program obfuscation is a technique
that aims at transforming a program P into a functionally equivalent obfuscated program O(P ) behaving as a virtual black box (called the virtual black-box property (VBBP)), i.e., anything that can be efficiently learned from O(P ) could also have been efficiently learned when given only oracle access to P .
Under this resemblance, white-box cryptography can be considered as a ‘special’ kind of obfuscation technique. The emphasis should definitely be placed on ‘special’ as the programs that should be obfuscated into virtual black boxes are cryptographic primitives whose specifications are often publicly known with the exception of the secret key information. Therefore, the primary goal of “white-box obfuscation” is not hiding the functionality of the program, but keeping the key information secret. As pointed out by Yamauchi et al. [108], one should be very careful when applying conventional obfuscation techniques in order to hide a secret (i.e., the cryptographic key) in a public known algorithm. To build further on the observation that white-box cryptography can be considered as a special kind of obfuscation technique, a quote by Chow et al. [23] is given in the following:
“When the attacker has internal information about a cryptographic implementation, choice of implementation is the sole remaining line of defense. Choice of implementation is precisely what is pursued in white-box cryptography.” [23]
The software implementations obtained as a result of the application of white- box cryptography on cryptographic algorithms are referred to as a white-box implementations. Up to early 2014, in the academic literature, the focus of white-box cryptography is mainly on the design of white-box implementations of block ciphers. The white-box implementations covered in this chapter are solely based on lookup tables (see Def. 3 on p. 16). The storage requirement of lookup tables (see Property 1 on p. 16) is of great significance with respect to the practicality of white-box implementations. As a straightforward example, the ideal white-box implementation is discussed below.
3.1.1
Ideal White-Box Implementation
As indicated in [23] by Chow et al., the ideal but at the same time also the most impractical white-box implementation is to represent a key-instantiated nb-bit block cipher E by means of a single lookup table mapping LE nb bits to
nb bits. In particular, LE represents the entire code book of E, i.e., the table
stores the ciphertexts for all 2nb possible plaintexts encrypted using the same
fixed secret key. Interestingly, it is also this lookup table that is used in the generic code book black-box attack (see Sect. 2.5.1, p. 34).
The reason why this implementation achieves perfect white-box security (with respect to key extraction), which corresponds to achieving black-box security within the white-box environment, is straightforward: the lookup table LE
behaves as an ideal black box, i.e., it maps plaintexts directly to ciphertexts. However, the storage requirement of such an ideal lookup table implementation is given by 2nb· n
b bits and hence becomes impractical/unrealistic for common
values of the block size nb. As an example, a lookup table representing the
codebook of a key-instantiated AES-128 cipher would require 4.95 · 1027 TB
of storage space! It should be mentioned that although the ideal white-box implementation prevents key-extraction, it allows global deduction, i.e., the implementation itself is functionally equivalent to the key-instantiated block cipher. However, due to the impractical aspect of the implementation, this becomes irrelevant.
The following section elaborates in detail on the white-box techniques proposed by Chow, Eisen, Johnson and van Oorschot [23, 24] in order to obtain practical white-box implementations of block ciphers.
INITIAL PRACTICAL WHITE-BOX TECHNIQUES 59