White-box cryptography aims to construct software implementations of cryptographic algorithms in such a way that they offer a sufficient level of robustness against a white-box attacker. The part ‘a sufficient level of robustness’ refers to protecting the confidentiality of the secret cryptographic key, which is also the primary goal of white-box cryptography. Later in this thesis, other white-box security goals are mentioned (see Sect. 3.4.2 for a discussion). Ultimately, an attacker in the white-box model should not have any advantage over an attacker in the black-box model with respect to extracting the secret cryptographic key, i.e., either having full access to and full control over the cryptographic software implementation or having solely access to the input/output behaviour of the implementation should not make any difference. Implementations obtained through the application of white-box cryptography are called white-box implementations.
The frequent occurrence of the white-box model in the real world, and thus the need for white-box cryptography, emanates from the ever increasing demand to deploy strong cryptographic algorithms in software applications that are executed on an untrusted open platform. As an illustration, we discuss the deployment of white-box cryptography in Digital Rights Management.
WHITE-BOX CRYPTOGRAPHY: A USE CASE 7
1.1.1
Digital Rights Management
Due to the digital revolution starting in the 1990s, copying and (illegally) distributing digital content has never been so easy. Therefore, content providers needed new technologies to protect their digital assets and to control the access and distribution of their copyright protected content. Such content protection schemes are known as Digital Rights Management or DRM. As expected, DRM can be found in many popular online digital multimedia (such as video, music, ebooks, apps etc.) stores nowadays. As an example, refer to the online Apple iTunes and iBooks Stores using Apple’s FairPlay DRM system. Although Apple made music DRM free in 2009 [4], videos and ebooks purchased through the iTunes and iBooks Store still use Apple’s FairPlay DRM system. Besides Apple, there are many other companies using DRM technology as well, such as Microsoft using Windows Media DRM for the Windows Media Player [76].
Remote Content Provider
m License Generator Lic EK Ek0 K E0k(K) EK(m)
Trusted Media Player Application License Verifier YES NO D0k D player m g g 1 g(K)
Figure 1.1: Use case of white-box cryptography: a simplified DRM model. Cryptography typically forms one of the basic building blocks to enforce a DRM system. A simplified DRM model is depicted in Fig. 1.1, that serves merely as an example to sketch an environment that can benefit from white-box cryptography and is not intended to represent real-world deployed DRM architectures. This simplified DRM model comprises two parties: the remote content provider and the trusted media player (e.g., iTunes) executed on the end-user’s untrusted platform (e.g., a PC). Here, it is assumed that the trusted media player is a solely software based application.
Now, the remote content provider delivers the copyright protected media content m to the authorized end-users in an encrypted form, consisting of the following three items:
1. the encrypted media content EK(m), where EK(·) denotes a known
symmetric-key encryption algorithm E using the secret content key K; 2. the encrypted content key Ek0(K), where Ek0(·) denotes a (possibly
end-user’s personal key k. The corresponding decryption algorithms of E and E0 are denoted by D and D0, respectively;
3. the DRM license Lic, comprising the restrictions (conditions) under which the end-user is allowed to access the digital content. Such a DRM license can for example specify a limited time frame (e.g., for movie rentals), or a maximum number of copies that can be made.
Typically, items 2 and 3 are sent simultaneously only upon request (i.e., purchase) of the end-user, whereas item 1 is available for download. Upon receipt of the above three items, the media player performs the following tasks. First, it verifies through the DRM license whether the end-user is allowed to gain access to the media content or not. After a positive confirmation (‘YES’), the media player first decrypts the content key K using the end-user’s personal key k and immediately applies an invertible encoding g to K, and then decrypts the media content using K after first applying the inverse encoding g−1 to g(K).
Clearly, in the DRM setting (Fig. 1.1), the attacker (i.e., either a maliciously behaving end-user or malware executed on the end-user’s device) steps out of the traditional black-box model and complies with the white-box model; he is in possession of and has control over the platform on which the media player application is executed. The attacker has the incentive to circumvent the restrictions posed by the DRM license. Being able to do so, a movie rental becomes as it were a movie purchase. He may achieve his goal by successfully performing one of the following three actions:
1. extract one of both decryption keys, i.e., either the content key K or the end-user’s personal key k;
2. tamper with the license verifier code such that it always outputs ‘YES’; 3. intercept the media content m.
Countermeasures against the above mentioned attempts to bypass the DRM system are given below:
1. ensure that the used cryptographic keys are never revealed in the code implementing the media player application (either static or dynamic) or in the memory of the device on which the application is executed; 2. make the license verifier code tamper-resistant such that reverse
engineering becomes a complex task and any attempt to modify the code results in breaking the functionality of the media player;
OUTLINE AND CONTRIBUTIONS 9
3. fingerprint the media content that unambiguously identifies the end-user such that a traitor (i.e., a malicious end-user illegally distributing his media content) can be traced back.
With respect to the first countermeasure, this can be achieved by constructing white-box implementations of both decryption algorithms to prevent decryption key extraction. Observe that between both decryption algorithms, the content key K only appears in an encoded form, i.e., g(K). In [73], Michiels and Gorissen describe a technique to combine countermeasures 1 and 2. For a discussion on the practical security aspects of DRM and the involvement of white-box cryptography, refer to Schultz [95].