CANS 2016: Cryptology and Network Security pp 749-754 | Cite as
Hybrid WBC: Secure and Efficient White-Box Encryption Schemes
Abstract
White-box cryptography aims at providing security against an adversary that has access to the encryption process. Numerous white-box encryption schemes were proposed since the introduction of white-box cryptography by Chow et al. in 2002. However, most of them are slow, and thus, can be used in practice only to protect very small amounts of information, such as encryption keys.
In this extended abstract we present a new threat model for white-box cryptography which corresponds to the practical abilities of the adversary in a wide range of applications. Furthermore, we study design criteria for white-box primitives that are important from the industry point of view. Finally, we propose a class of new primitives that combine a white-box algorithm with a standard block cipher to obtain white-box protection for encrypting long messages, with high security and reasonable performance.
Keywords
Block Cipher Encryption Process Digital Right Management Threat Model Practical Ability1 Introduction
The white-box threat model in secret-key cryptography, introduced by Chow et al. [4] in 2002, considers an adversary that is accessible to the entire information on the encryption process, and can even change parts of it at will. The range of applications in which the white-box threat model is relevant is already extensive and continues to grow rapidly. One example is the Digital Rights Management (DRM) realm, where the legitimate user (who, of course, has full access to the encryption process), may be adversarial. Another example is resource-constrained Internet-of-Things (IoT) devices applied in an insecure environment (like RFID tags on the products in a supermarket). Yet another example is smartphones and public cloud services. While certain security-critical services in such devices are provided with support of hardware security features, such as ‘secure element’ or TrustZone in mobile devices or ‘hardware security modules’ in the cloud, most services are implemented as software operating within Rich OS. The main reasons for that are low cost, development efficiency and complicated ecosystems. As a result, the cryptographic implementations are vulnerable to a wide variety of attacks in which the adversary has ‘white-box’ capabilities.
The ever-growing range of applications where the white-box threat model is relevant necessitates devising secure and efficient solutions for white-box cryptography. And indeed, numerous white-box primitives were proposed since the introduction of white-box cryptography in 2002. These primitives can be roughly divided into two classes.
The first class includes algorithms which take an existing block cipher (usually AES or DES), and use various methods to ‘obfuscate’ the encryption process, so that a white-box adversary will not be able to extract the secret key. Pioneered by Chow et al. [4], this approach was followed by quite a few designers. An advantage of these designs is their relation to the original ciphers, which makes transition to the white-box primitive and compatibility with other systems much easier. Unfortunately, most of these designs were broken by practical attacks a short time after their presentation. In addition, all designs of this class are orders of magnitude slower than the ‘black-box’ primitives they are based upon.
The second class includes new block ciphers designed especially with white-box protection in mind, like the ASASA and SPACE families [1, 2]. An important advantage of these designs is their better performance and higher security (though, some of them were also broken, see [5]). On the other hand, transition from existing designs to the entirely new ciphers is not an easy task, and so, quite often commercial users will be reluctant to make such a major change in the design.
In this extended abstract we propose a class of new primitives which provide strong security with respect to a ‘real-life’ white-box adversary, and on the other hand, are convenient for practical use – meaning that the performance is reasonable and that transition from currently used primitives to the new primitives is relatively easy. To this end, in Sect. 2 we present a new threat model for white-box cryptography which corresponds to the practical abilities of the adversary in a wide range of applications. Once the security model is set, we study design criteria for white-box primitives that are important from the industry point of view. In Sect. 3 we propose a class of new primitives that combine a white-box algorithm with a standard block cipher to obtain white-box protection for encrypting long messages, with high security and reasonable performance. Preliminary security analysis of the new primitives, along with a comparison with previous works, can be found in the full version of this paper [3].
2 Practical Requirements and Design Strategy
2.1 Security Requirements – A New Threat Model
Unlike the classical black-box model, in white-box cryptography the abilities of the adversary are not clearly defined, and different threat models are implicitly used by different authors.
The works of Chow et al. [4] and their successors implicitly assume that there is a part of the encryption process, called external encoding, which is performed outside of the encryption device and cannot be accessed by the white-box adversary. Such an assumption is not realistic in scenarios where the entire encryption process is implemented in software.
Instead, we propose the following threat model, which is relevant in a wide variety in realistic scenarios. Assume that the same white-box encryption scheme is used in many devices, with at most a small difference between them (e.g., a unique identification number that is used in the encryption process). Further, assume that the adversary can mount an ‘expensive’ white-box attack on at most a few devices (e.g., by purchasing them and then analyzing in depth), and he is willing to break the encryption of all other devices. Formally, we assume that the adversary has a white-box access to several devices from the family and only black-box access to all devices in the family. Using the white-box access, the adversary can obtain full information on the devices he took control of. His goal is to break the encryption schemes of all other devices. Thus, the security goal in this model can be thought of as minimizing the damage from one-time compromise.
Our threat model is well suited for IoT environment. IoT devices are usually manufactured in a production line simply assembling flash memories with the same binary programmed including cryptographic keys, i.e. the same cryptographic keys are shared across multiple devices. This is because it would be quite expensive to embed separate keys into each device either in production lines or by consumers; additional key-embedding process and related key management, as well as adding UX layers to IoT devices, generally require considerable cost. In such an IoT environment, an adversary may implement the white-box attack for a single device, and try to compromise the whole system using the obtained key or any critical information, along with capabilities from the conventional black-box model.
We note that this threat model does not fit for all applications of white-box cryptography. However, it seems relevant in sufficiently many scenarios for being considered specifically.
2.2 Performance and Cost Requirements
While industry accepts the need in strong security of the algorithms, it is often the case that practical efficiency considerations are prioritized by commercial users over security considerations. Hence, if we want to design a primitive that will be employed in practice, we should take into account the main practical requirements from the industry point of view.
The main two design criteria we concentrate on are the following:
Reasonable performance. Previously suggested white-box algorithms except the SPACE family are 12 to 55 times slower than AES. White-box primitives have thus been used to protect relatively small sizes of data. We aim at using the white-box primitive to protect large amounts of data, and so, the encryption speed must be reasonably fast – ideally, almost as fast as the AES.
Low transition cost. The new architecture should be designed so as to minimize the modification of the existing development or manufacturing process related to cryptographic implementations. Interestingly, this may be the most important factor for commercial adoption in reality.
2.3 Design Strategies
The practical requirements listed above lead to the following design considerations.
First, if we use a white-box algorithm to encrypt each block of the message then the performance of the resulting encryption scheme is the same as that of the white-box algorithm. For most of the currently existing white-box algorithms, this means that the scheme is very slow. Moreover, even for the SPACE family whose members are not so slow, standard ‘software obfuscation techniques’ aimed at protecting the security of the running code, make the encryption process much slower, and thus too slow for our purposes. As a result, it is desirable to use the white-box algorithm to encrypt only part of the message blocks, and encrypt most blocks with a ‘classical’ algorithm.
Second, almost all existing solutions for data protection in data communication such as SSL, TLS and SSH are based on a shared secret (e.g. session key). Designers of some solutions for data communication want to apply this session key in white-box encryption with minimum modification of their cryptographic implementation. However, they cannot use this key directly in a white-box scheme since the initiation of a white-box algorithm is slow and in general is separate from running environment. In addition, in many cases users request a certificate algorithm to be used in their implementation. Hence, we aim at applying a session key directly in the components of our scheme, except the white-box algorithm.
Third, the most effective way to minimize the damage from one-time compromise is to encrypt each message by a one-time key which is protected by white-box algorithms. However, managing these one-time keys is a big burden and existing key exchange protocols do not provide a one-time session key. Thus, we will encrypt the nonce by a white-box algorithm and use it in the encryption process as a replacement for a one-time key.
3 The New Primitives
3.1 General Structure and Security Goals
Our primitives use two separate keys – one for a white-box primitive and another for a ‘classical’ encryption algorithm (e.g., AES), where the white-box algorithm is only used for encryption of a nonce (e.g. initial vector (IV) or a counter) while the classical algorithm is used for encryption of plaintexts. The keys \(K_1\) and \(K_2\) are assumed to be permanent and may be shared by many devices, while the nonce in changed in every encryption session.
We restrict the use of our scheme to encrypting messages of length at most \(2^{64}\) blocks in a single session (i.e. without rekeying). Furthermore, as common in nonce-based algorithms, we do not allow re-use of the nonce.
The security level we aim at is data complexity of \(2^{64}\) and memory and time complexities of \(2^{80}\). That is, any white-box attack that can recover the secret key \(K_1\), or distinguish our scheme from random, or recover part of the plaintext in a non-compromised session, should require either more than \(2^{64}\) messages, or more than \(2^{80}\) time or more than \(2^{80}\) memory.
3.2 The New Hybrid White-Box Schemes
F-CTR-WBC: a white-box variant of AES-CTR with a 256-bit block and a feed-forward operation
The first scheme, called F-CTR-WBC and presented in Fig. 1, is similar to the standard CTR mode of operation using the AES block cipher, but with three differences. First, a counter CTR is encrypted using a white-box primitive (e.g., white-box-AES or a member of the SPACE family). Second, the scheme contains a feed-forward operation (in order to thwart a trivial attack in the white-box model presented in [3]). Third, the block length is increased to 256 bits (e.g., by using Rijndael-256 instead of AES), in order to make a time-memory tradeoff attack presented in [3] infeasible. Our experiments show that this scheme is only 1.3 times slower than AES-CTR.
UF-CTR-WBC: a two-layered variant with feed-forwards
Initial security analysis of both schemes is presented in [3].
References
- 1.Biryukov, A., Bouillaguet, C., Khovratovich, D.: Cryptographic schemes based on the ASASA structure: black-box, white-box, and public-key (extended abstract). In: Sarkar, P., Iwata, T. (eds.) ASIACRYPT 2014, Part I. LNCS, vol. 8873, pp. 63–84. Springer, Heidelberg (2014)Google Scholar
- 2.Bogdanov, A., Isobe, T.: White-box cryptography revisited: space-hard ciphers. In: Proceedings of Computer and Communications Security (CCS 2015), pp. 1058–1069. ACM (2015)Google Scholar
- 3.Cho, J., Choi, K.Y., Dunkelman, O., Keller, N., Moon, D., Vaidberg, A.: Hybrid WBC: Secure and Efficient White-Box Encryption Schemes, IACR eprint report 2016:679 (2016)Google Scholar
- 4.Chow, S., Eisen, P., Johnson, H., Van Oorschot, P.C.: White-box cryptography and an AES implementation. In: Nyberg, K., Heys, H. (eds.) SAC 2002. LNCS, vol. 2595, pp. 250–270. Springer, Heidelberg (2003). doi: 10.1007/3-540-36492-7_17 CrossRefGoogle Scholar
- 5.Gilbert, H., Plût, J., Treger, J.: Key-recovery attack on the ASASA cryptosystem with expanding S-boxes. In: Gennaro, R., Robshaw, M. (eds.) CRYPTO 2015, Part I. LNCS, vol. 9215, pp. 475–490. Springer, Heidelberg (2015). doi: 10.1007/978-3-662-47989-6_23 CrossRefGoogle Scholar