WO2010146140A1 - White-box cryptographic system with configurable key using block selection - Google Patents

Abstract

A white-box cryptographic system (600) is presented for performing a key- dependent cryptographic operation, such as AES. The system comprises a plurality of basic blocks (640), such as look-up tables, and a basic block manager (650). The basic block manager is configured to iteratively select a selected one of the plurality of basic blocks in dependency on a block selection string (664). By sending a new block selection string to the system the key for which the system is configured can be updated.

Description

White-box cryptographic system with configurable key using block selection.

FIELD OF THE INVENTION

The invention relates to a cryptographic system for performing a key- dependent cryptographic operation mapping an input-message to an output-message, the system comprising a plurality of basic blocks and a basic block manager, the basic block manager being configured to iteratively select a selected one of the plurality of basic blocks and to provide the selected basic block with a basic block input to obtain a corresponding basic block output, the basic block input comprising at least a part of intermediate processing data and/or the input-message, the basic block output comprising at least part of the intermediate processing data and/or the output-message. The invention further relates to a corresponding method and software.

BACKGROUND OF THE INVENTION

The Internet provides users with convenient and ubiquitous access to digital content. Because of the potential of the Internet as a powerful distribution channel, many consumer electronics (CE) products strive to directly access the Internet or to interoperate with the PC platform — the predominant portal to the Internet. The CE products include, but are not limited to, digital set top boxes, digital TVs, game consoles, PCs and, increasingly, hand-held devices such as PDAs, mobile phones, and mobile storage and rendering devices, such as Apple's iPod. The use of the Internet as a distribution medium for copyrighted content creates the compelling challenge to secure the interests of the content provider. In particular it is required to warrant the copyrights and business models of the content providers. Increasingly, CE platforms are operated using a processor loaded with suitable software. Such software may include the main part of functionality for rendering (playback) of digital content, such as audio and/or video. Control of the playback software is one way to enforce the interests of the content owner including the terms and conditions under which the content may be used. Where traditionally many CE platforms (with the exception of a PC and PDA) used to be closed, nowadays more and more platforms at least partially are open. In particular for the PC platform, some users may be assumed to have complete control over the hardware and software that provides access to the content and a large amount of time and resources to attack and bypass any content protection mechanisms. As a consequence, content providers must deliver content to legitimate users across a hostile network to a community where not all users or devices can be trusted.

Typically, digital rights management systems use an encryption technique based on block ciphers that process the data stream in blocks using a sequence of encryption/decryption steps, referred to as rounds. During each round, a round- specific function is performed. The round-specific function may be based on a same round function that is executed under control of a round-specific sub-key.

Content providers must deliver content to legitimate users across a hostile network to a community where not all users or devices can be trusted. In particular for the PC platform, the user must be assumed to have complete control of the hardware and software that provides access to the content, and an unlimited amount of time and resources to attack and bypass any content protection mechanisms. The software code that enforces the terms and conditions under which the content may be used must not be tampered with. The general approach in digital rights management for protected content distributed to PCs is to encrypt the digital content, for instance DES (Data Encryption Standard), AES (Advanced Encryption Standard), or using the method disclosed in WO9967918, and to use decryption keys.

The two main areas of vulnerability of digital rights management relying on encryption are the software plug-ins which enforce the terms and conditions under which the content may be used, and the key distribution and handling.

After the key used to encrypt content is comprised, it can be distributed over the Internet with comparative ease. One way to avoid this is to use white-box cryptography, wherein a key dependent cryptographic operation is performed in such a way that the key cannot be recovered, not even by attacker having full access to the implementation. In white- box cryptography it is assumed that an attacker has full access to the implementation. Apart from analyzing the input and output behavior of a system, in the white box context an attacker may also analyze the internal behavior of a system. Usually it is the goal of a white box attack to recover in a useable form the key that corresponds to particular encryption or decryption operation.

Most white-box implementations use techniques based on hiding the cryptographic key by adding a veil of randomness, such as random encodings, and complexity in both the control and the data path of the software application. The idea behind this is that it becomes more difficult to extract information merely by code inspection. "White-Box Cryptography and an AES Implementation", by Stanley Chow, Philip Eisen, Harold Johnson, and Paul C. Van Oorschot, in Selected Areas in Cryptography: 9th Annual International Workshop, SAC 2002, St. John's, Newfoundland, Canada, August 15-16, 2002, referred to hereinafter as "Chow 1", and "A White-Box DES Implementation for DRM Applications", by Stanley Chow, Phil Eisen, Harold Johnson, and Paul C. van

Oorschot, in Digital Rights Management: ACM CCS-9 Workshop, DRM 2002, Washington, DC, USA, November 18, 2002, referred to hereinafter as "Chow 2", disclose methods with the intend to hide the key by a combination of encoding its tables with random bijections, and extending the cryptographic boundary by pushing it out further into the containing application.

In Chow's white-box implementations, the key is not explicitly present in the implementation. This reduces the risk of the key being found by inspection of the implementation. Instead, the key is only present implicitly. Chow uses the method of partial evaluation to hide a key in a cryptographic system, therein a basic block which needs key input is evaluated in- so-far it depends on the key and does not depend on the input-message. For example, a basic operation wherein an input-value, a key- value, and a masking value which does not depend on the input-message, e.g. a value from an s-box needs to be xor-ed can be partially evaluated by xor-ing the key value and the masking value together beforehand. In this way the operation still depends on the key-value although the key-value is not explicitly present in the implementation. Instead, only the xor between the key-value and masking-value is present in the implementation.

SUMMARY OF THE INVENTION

A problem with the approach taken in Chow 1 and Chow 2 is that the key is embedded in the white-box implementation. All operations that depend on the key are simplified to depend on one particular key. In this way that particular key is spread throughout the implementation making hiding through obfuscation of the key easier. Instead of having a key schedule in the implementation, the approach taken in Chow 1 and 2 pre- calculates all round keys. There is therefore no need for a separate key schedule, which is therefore also dispensed with.

A disadvantage of this approach is that the white-box implementation can only be used for one cryptographic key. This is considered a disadvantage for some applications. For example, for security reasons one may want to frequently update the key used. If at some point, for whatever reason the particular key is leaked, then it is only of use to an attacker for a limited amount of time, until the next key-update. Moreover, having the possibility of using multiple keys makes it easier to do key management. For example: First content intended for a first group of people can be encrypted with a first key, and second content intended for a second group of people can be encrypted with a second key. A user who is in the intersection of the first group and the second group may access both the first and the second content using a single white-box system if only he could update his key. Moreover, there exist a number of protocols and cryptographic standards which make it impossible or impractical to fix the used key beforehand. For example, key negotiation protocols cannot be used with cryptographic operations using a fixed key. Also DRM standards, such as OMA DRM, assume that different keys are used for content keys, right keys etc.

One solution to update the key used in white box implementation is to update the entire white box implementation, or at least all its blocks, this is however impractical as the size of white box implementations is often rather large, especially when compared with the size of a typical key. For example, a white-box implementation may be tens or even hundreds of kilobytes, whereas a single AES key is only 16 bytes. Even an AES key which is expanded into its corresponding round keys is only 160 bytes.

It would be advantageous to have an improved cryptographic system for performing key-dependent cryptographic operations mapping an input-message to an output- message. To better address this concern in a first aspect of the invention a cryptographic system for performing key-dependent cryptographic operation mapping an input-message to an output-message is presented. The system comprising a plurality of basic blocks, and a basic block manager, the basic block manager being configured to iteratively select a selected one of the plurality of basic blocks and to provide the selected basic block with a basic block input to obtain a corresponding basic block output, the basic block input comprising at least a part of intermediate processing data and/or the input-message, the basic block output comprising at least a part of the intermediate processing data and/or the output-message, wherein the cryptographic system is configured to receive a block selection string, the basic block manager being configured to iteratively select a selected one of the plurality of basic blocks in dependency on the block selection string for configuring the cryptographic operation for a particular key.

The cryptographic system performs the key-dependent cryptographic operation by using basic blocks to map the input message to intermediate processing data and eventually to the output-message. The basic blocks that are used to do the mapping represent the key on which the cryptographic operation depends. By changing which basic blocks are used the cryptographic operation is changed. As the system can receive a block selection string, the selection of the tables can be influenced from outside the system, and in particular, even after the cryptographic operation has been implemented as a white-box. By changing the cryptographic operation the key dependency can be changed in a desired direction. The mapping of input message to output message then occurs in a way modified according to the block selection string.

As noted, for many cryptographic operations it is desired to have a white-box implementation. The invention may be applied, for example, to symmetric and asymmetric cryptographic operations. Also, the invention may be applied to block ciphers, stream ciphers, message authentication schemes, signature schemes, etc. Note that the invention may also be applied to hash functions. The latter is especially useful if the hash function is used as a building block which processes secret information, e.g., a secret key, secret data, etc. For example, the invention may be applied to a hash function used in a keyed-Hash Message Authentication Code (HMAC or KHMAC). Well known block ciphers include Advanced Encryption Standard (AES), Secure And Fast Encryption Routine, (S AFER, and variants SAFER+ and SAFER++), Blowfish, Data Encryption Standard (DES), etc. A well known stream cipher is RC4. Moreover any block cipher can be used as stream cipher using an appropriate mode of operation, e.g., Cipher feedback (CFB), Counter mode (CTR), etc.

The input message can represent, e.g., encrypted content data, such as multi- media data, including audio and/or video data. The encrypted content data may also comprise encrypted software, e.g., encrypted computer code representing some computer application, e.g., a computer game, or an office application. The input message may also represent a key for use in a further cryptographic operation. The latter may be used, for example, in a key exchange protocol, wherein a white-box implementation according to the invention encrypts and/or decrypts data representing a new key. The input data may also be plain data, for example, plain user data. The latter is especially advantageous in message authentication schemes. A white-box implementation according to the invention may have the property that the implementation may only be used for encryption, only be used for decryption, but not for both. For example, this property can be achieved if the implementation uses basic blocks which are not bijective, for example, a look-up table having more input bits than output bits. Accordingly, if a user only has a white-box decryptor, he may verify a MAC code but not create new MACs. This strengthens the non-repudiation properties of such a message authentication scheme. The plurality of basic blocks are interconnected, in the sense that the basic block manager uses some of the outputs obtained from some basic blocks as inputs, or as part of inputs, for some other blocks. The basic blocks therefore build on the results of one or more of the previous blocks. In this way the basic blocks can be said to form a network of basic blocks that together represent the cryptographic operation. A basic block may be implemented in hardware, for example, as a computer chip. A basic block may use a switch board, a state machine or any other suitable construction for implementing functions in computer hardware. A basic block may also be implemented in software running on a general purpose computer chip, e.g. a microprocessor. For example, a basic block may use a plurality of computer instructions, including arithmetical instructions, which together implement the functionality of the basic block. A preferred implementation for the basic block, which may be used both in software and hardware, is a look-up table. A look-up table implementation comprises a list which lists for possible input values, an output value. The input value may be explicit in the lookup table. In that situation the look-up table implementation could map a particular input to a particular output by searching in the list of input values for the particular input. When the particular input is found the particular output is then also found. For example, the particular output may be stored alongside the particular input. Preferably, the input values are not stored explicitly, but only implicitly. For example, if the possible inputs are a consecutive range, e.g. of numbers or bit-strings, the look-up table may be restricted to storing a list of the output values. A particular input number may, e.g., be mapped to the particular output which is stored at a location indicated by the number. Note that a loop-up table may also be implemented in hardware gates by converting the look-up table to a Boolean function. Several techniques to do this are known, e.g., using Karnaugh maps.

Using look-up tables for the basic blocks has the advantage that they can be obfuscated relatively straightforwardly. For example, the output values of a table may be encoded in some manner, by replacing the un-encoded values with the encoded values.

A look-up table for a function may, for example, be created by computing the output value of the function for its possible inputs and storing the outputs in a list. If the function depends on multiple inputs the outputs may be computed and stored for all possible combinations of the multiple inputs. Look-up tables are especially suited to implement nonlinear functions, which map inputs to output in irregular ways. A white-box implementation can be further obfuscated, as is explained below, by applying to one or more of its look-up tables a fixed obfuscating input encoding and a fixed output encodings. The results of applying a fixed obfuscating input encoding and output encodings is then fully pre-evaluated. Using this technique, a look-up table would be replaced by an obfuscated look-up table which may have the same dimensions and may take the same number of input bits to produces the same number of output bits. The input encoding and output encoding used in such obfuscation are not explicit in the final white-box implementation. The network of basic blocks are arranged to compute an output message when they are presented with an input message. Typically, the input message is operated upon by a number of basic input blocks. A number of further basic blocks may take input from one or more of the basic input blocks and/or from the input. Yet further basic blocks can take input in any combination of the input message, the output of basic input blocks and the output of the further basic blocks. Finally some set of basic exit blocks, i.e., at least one, produce as output all or part of the output-message. In this manner a network of basic blocks emerges which collective computes the mapping from the input message to the output message. The key used is preferably a cryptographic key, and preferably contains sufficient entropy to withstand an anticipated brute force attack. It may be advantageous to implement some of the basic blocks, for example an

XOR operation, in different ways than look-up tables. For example, this may be done if only linear encodings are used for the operation rather than non-linear encodings. Implementing some basic blocks as look-up tables and some in other ways, for example, as computer software implemented formulas has the advantage that size requirements reduce. The basic block manager may in response to receiving the block selection string make multiple selections for configuring the cryptographic operation for a particular key. In particular, even for updating that part of a round key on which, say, a single T-box, depends multiple selections may be made. The multiple selections may together update the white-box implementation of the T-box to a new key. In a preferred embodiment the plurality of basic blocks comprises at least one sub-plurality of basic blocks, the basic block manager being configured to select the selected one of the plurality of basic blocks from the sub-plurality in dependency on part of the block selection string.

By organizing the plurality of basic blocks into one or more of sub-pluralities, the size of the block selection string can be reduced. Instead of having to select for each step a table from all possible tables, the block selection string need only select a table from the sub-plurality. For example, consider a hypothetical situation with 128 tables and two selection moments: the block selection string would then need two times 7 bit. However, if the 128 tables were split over a first sub-plurality of 64 tables for the first selection and a second plurality of 64 tables for the second selection, then only two times 6 bits are needed. In an actual white -box implementation the number of tables and selection moments is vastly larger making the saving considerably more pronounced. There are many opportunities to select sub-pluralities, e.g., based on their dimension, the cryptographic operation embodied, the round in which the table is to be used, the input and/or output encoding that are applied, etc.

Note that if multiple sub-pluralities are used, then there may be an overlap between them.

In a preferred embodiment, the sub-plurality of basic blocks are configured to produce basic block outputs encoded with a same output-encoding.

In a white-box implementation the various basic blocks are typically obfuscated using input and/or output encodings. The white-box implementation may be organized so that an output of one basic block is encoded using an encoding scheme which is the same as, or at least compatible with, the input encoding scheme of a basic block that follows. The basic blocks in the sub-plurality can be selected using the block selection string as alternatives. It simplifies the implementation if these alternatives use the same output- encoding, since in that case no further administration is needed before the a produced output is used in a next basic block. For example, all basic block in the sub-plurality may use the same output encoding as the following input encoding, or all basic block in the sub-plurality may use the same output encoding so that a single encoding conversion block can be used to convert from the single used output encoding to the following input encoding. This simplifies the embodiment, and also reduces its size as fewer, or even no, conversion blocks are necessary.

In a preferred embodiment the sub-plurality of basic blocks are configured to receive basic block inputs with a same input-encoding.

Similarly, if the basic blocks in the sub-plurality use the same input encoding, then no or fewer conversion blocks are needed of the input value that is sent to the selected basic block in the sub-plurality.

In a preferred embodiment, a first basic block of the sub-plurality of basic blocks is configured to produce a first response encoded with the output-encoding upon receiving a first input, a second basic block of the sub-plurality of basic blocks is configured to produce a second response encoded with the output-encoding upon receiving the first input, wherein the second response differs an amount from the first response which depends on the first and second basic block and which is independent from the first input. One way to introduce key material, e.g., parts of the particular key for which the block selection string configures the cryptographic operation, is to have multiple basic blocks that are the same up to a constant. In this way, the cryptographic operation can be sent into a desired direction by selecting the basic block which corresponds to the desired intermediate value. For example, if the sub-plurality follows a basic block which is adapted to some fixed, key, its results may be corrected to the desired particular key, by selecting the basic block that gives the correct offset. On the other hand the sub-plurality may precede a basic block which is adapted to a fixed key. By changing the input, the effect may be obtained that an operation is performed for a different key. The constant offset may be obfuscated by the output encodings of the first and second basic blocks. That is, even though the first response and the second response may differ a constant offset, the encoded version of the first response and the encoded version of the second response may differ an amount which is not independent of first input. It is noted that for some operation that addition and subtraction operation coincide. For example there is no difference between the XOR sum and the XOR difference of two bit-strings, e.g., representing some value.

In a preferred embodiment, the sub-plurality of basic blocks are each adapted to perform the same key-dependent sub-operation of the cryptographic operation and are adapted for different particular sub-keys. If a basic block is adapted to operate according to a particular key value, e.g., a key byte, then that basic block may be constructed 256 times to form a sub-plurality, that is as many times as there are possible key values. Each copy of that basic block is configured to work according to a different key-value. The block selection string then selects the basic block that corresponds to the desired key value. Note that the relation between the key values, e.g., the values 0 up to 255 and the basic blocks in the sub-plurality can be in any random relation. This will further obfuscate the relation between the block selection string and the key that the system is configured for. Note that a cryptographic key may comprise multiple values, e.g., 160 bytes for a round-expanded AES-key.

In a preferred embodiment, the sub-plurality of basic blocks each represents a XOR operation.

A larger linear operation, e.g., mapping 32 bits to 32 bits, may be converted to a look-up table for use in a white-box operation, by using the technique of striping. This technique splits the operation over a number of smaller operations, having smaller input and multiple outputs. Large linear operations are frequently used in cryptographic operation as they can provide good mixing of the intermediate data. Striping is more fully explained in Chow 1, Section 3.2. A consequence of the striping is that the results of the smaller operations may later be recombined using XOR operations to obtain the desired larger value, which is the result of the large linear operation. . These XOR operations may be done using special basic blocks, for example using type IV look-up tables. Since the XOR operation occurs frequently throughout many white-box cryptographic operations, and moreover can be implemented as a relativity small table, they provide a good candidate to implement multiple times for different keys. For example, a xor table, for xor-ing two 4 bit inputs is only 16 times 16 times 4 bit large, that is, 1024 bit or 128 byte. Moreover, such a table need only be duplicated 16 times to accommodate all 16 possible offsets. In this way, the size increase caused by incorporating a table multiple times is kept within bounds and small compared to the large key-dependent basic blocks.

In a preferred embodiment, the block selection string comprises a sub-string, the sub-string determining said selection of the sub-plurality of basic blocks. A further aspect of the invention is a cryptographic method for mapping an input-message to an output-message. The method comprises selecting a selected one of a plurality of basic blocks, providing the selected basic block with a basic block input comprising at least a part of intermediate processing data and/or the input-message to obtain a corresponding basic block output comprising at least a part of the intermediate processing data and/or the output-message, wherein the cryptographic method is configured for obtaining, e.g., receiving, a block selection string, the selected basic block being selected in dependency on the block selection string.

A method according to the invention may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both. Executable code for a method according to the invention may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc.

In a preferred embodiment, the computer program comprises computer program code means adapted to perform all the steps of a method according to the invention when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.

A white -box cryptographic system is presented for performing a key- dependent cryptographic operation, such as AES. The system comprises a plurality of basic blocks, such as look-up tables, and a basic block manager. The basic block manager is configured to iteratively select a selected one of the plurality of basic blocks in dependency on a block selection string. By sending a new block selection string to the system the key, for which the system is configured, can be updated.

Another white-box using an updatable key is given in a patent application of the same applicant and same inventor as the current applicant, with attorney docket number PH013609, and title 'White-box cryptographic system with configurable key using intermediate data modification', which was first filed on 19.06.2009, incorporated herein by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects of the invention will be elucidated hereinafter by reference to the drawings, wherein

Figure 1 is a diagram illustrating operations in a round of AES, Figure 2 is a diagram illustrating an example of obfuscating tables, Figure 3 is a diagram illustrating a round for a column in a white-box AES implementation,

Figure 4 is a diagram illustrating mappings incorporated in a type Ia table, Figure 5 is a diagram illustrating mappings incorporated in a type II table, Figure 6 is a diagram illustrating mappings incorporated in a type III table, Figure 7 is a diagram illustrating mappings incorporated in a type IV table,

Figure 8 is a diagram illustrating mappings incorporated in a type Ib table, Figure 9 is a diagram illustrating a white box implementation with an updatable key.

Figure 10 is a diagram illustrating a round of white-box AES Figure 11 is a diagram illustrating an embodiment.

DETAILED DESCRIPTION OF EMBODIMENTS

We will describe the workings of the invention using as an example a block cipher, the block cipher AES. However, this is done as an illustrative example only, as the invention can be more generally applied, to other block ciphers, e.g. DES, but more generally also to other cryptographic primitives, for example, hash functions.

In overview the following may be done. The block cipher AES is first converted into a form using only a network of look-up tables for its computations. Converting all cryptographic primitives to look-up tables is not necessary. In fact some of the computation may be performed using primitives in other forms than look-up tables. Below we will show how AES may be performed using only look-up tables, but not all conversions need to be adopted. The conversion to a network of look-up tables is done for a particular key. The precise key can for example be chosen to be the all zero key, or any random key. Although explicit reference to the key will disappear in this process, it will turn out that the contents of some look-up tables will depend on the key. Some look-up tables only depend on implementation choices, e.g., the obfuscating encodings that are used, etc, whereas other look-up tables also depend on the key.

One way to make the key for which the white-box implementation is adapted updatable is by taking each one of the key dependent look- up tables in turn and duplicate the key-dependent look-up tables as many times as there are key values on which they could have depended. The duplicates are then modified to perform the same operation albeit for a different key value. The block selection string can then pick the correct look-up table to change the way the white box implementation depends on the key. Note that, although there is no need to send look-up tables themselves to update the white-box, and sending a block selection string suffices, one may also send one or more update look-up tables along with the block selection string during a key-update.

Another way to introduce key dependency is to take a look-up table immediately preceding the key-dependent look-up table and duplicate it. The duplicates are changed to that the input to the key-dependent look-up table is modified, in that way the output of the key-dependent look-up tables are also modified. The modification can be chosen such that the effect is the same as if the key-dependent look-up table itself was replaced with a corresponding look-up table but dependent on a different key. Similarly, one could duplicate a look-up table immediately following the key-dependent look-up table and modify its duplicates. In this way the output of the key-dependent look-up tables are also modified. The modification can be chosen such that the effect is the same as if the key- dependent look-up table itself was replaced with a corresponding look-up table but dependent on a different key.

AES is a block cipher with a block size of 128 bits or 16 bytes. The plaintext is divided in blocks of 16 bytes which form the initial state of the encoding algorithm, and the final state of the encoding algorithm is the cipher text. To conceptually explain AES, the bytes of the state are organized as a matrix of 4x4 bytes. AES consists of a number of rounds. Each round is composed of similar processing steps operating on bytes, rows, or columns of the state matrix, each round using a different round key in these processing steps. Figure 1 illustrates some main processing steps of a round of AES. The processing steps include:

AddRoundKey 802 - each byte of the state is XOR' ed with a byte of the round key. - SubBytes 804 - A byte-to-byte permutation using a lookup table.

ShiftRows 806 - Each row of the state is rotated a fixed number of bytes.

MixColumns 808 - Each column is processed using a modulo multiplication in GF(2⁸).

The steps SubBytes 804, ShiftRows 806, and MixColumns 808 are independent of the particular key used. The key is applied in the step AddRoundKey 802.

Except for the step ShiftRows 806, the processing steps can be performed on each column of the 4x4 state matrix without knowledge of the other columns. Therefore, they can be regarded as 32-bit operations as each column consists of 4 8-bit values. Dashed line 810 indicates that the process is repeated until the required number of rounds has been performed. Each of these steps or a combination of steps may be represented by a lookup table or by a network of lookup tables. If the AddRoundKey step were implemented by XOR' ing with the round key, then the key is visible to the attacker in the white-box attack context. The AddRoundKey step can also be embedded in lookup tables, which makes it less obvious to find out the key. In fact, it is possible to replace a full round of AES by a network of lookup tables. For example, the SubBytes, ShiftRows, and MixColumns steps may be implemented using table lookups. Below we will discuss a possible white-box implementation of AES more fully. First we will present white box implementation techniques with respect to a fixed key, then we will describe how to extend the implementation to an updatable implementation. It is noted that one may also choose to create an updatable implementation directly, without going through the intermediate step of producing a white-box implementation adapted to a single fixed key.

Figure 2 illustrates a way to make it even more difficult to extract the key. After a cryptographic operation, such as an AES encryption, has been transformed into a network of basic operations, further obfuscation is possible. Let X and 7 be two functions, i.e., basic operations. Consider the composite operation Y o X = Y(X(c)) , illustrated as diagram 812, that is, to obtain the composite operation, Y is performed after X. Here c is an input value, for example a 4-byte state column. However, the approach applies to any type of input value c. Mappings X and 7 can be implemented as look-up tables which can be stored in memory, however, when they are stored in memory the values can be read by an attacker. Diagram 814 illustrates how the contents of the look-up tables can be obfuscated by using an input encoding F and an output encoding H. Look-up tables corresponding to l ° F^*1 and H o Y are stored as illustrated instead of X and Y, making it more difficult to extract X and Y. Diagram 816 shows how to add an additional, for example random, bijective function G, such that the intermediate result of the two tables is also encoded. In this case, two tables are stored in memory: I' = G <> I o F^'1 and Y ' = H ° Y ° G^"1 . This is illustrated once more in diagram 18:

Y O X ' = (H o Y o G ¹ ) o (G o X o F^~] ) = H o (F ° X) ° F^"1 , where o denotes function composition as usual (i.e., for any two functions fix) and g{x), f ° g (x) — f(g(x)) by definition), X and Y are functions suitable for implementation by means of look-up tables. Likewise a network consisting of more than two functions can be encoded. The actual tables encoding X and Y are obfuscated by combining H o Y o G^"1 in a single look-up table and combining G o X o F^"1 in a single look-up table. As long as F, G, and/or H remain unknown, the attacker cannot extract information about X and/or Y from the look-up tables, and hence the attacker cannot extract the key that is the basis for X and/or Y. Other cryptographic algorithms, including DES and Rijndael (of which AES is a particular instantiation), may also be encoded as a (cascade or network of) look-up tables that may be obfuscated in a way similar to the above. The invention is not limited to the exemplary cryptographic algorithms mentioned. Chow 1 discloses a method with the intend to hide the key by encoding its tables with random bijections representing compositions rather than individual steps. Preventing secret-key extraction has the advantage that an attacker is prevented from extracting keying material which would allow software protection goals to be bypassed on other machines, or from publishing keying material effectively creating 'global cracks' which defeat security measures across large user-bases of installed software. It provides an increased degree of protection given the constraints of a software-only solution and the hostile-host reality. In the approach of Chow 1, the key is hidden by (1) using tables for compositions rather than individual steps; (2) encoding these tables with random bijections; and (3) extending the cryptographic boundary beyond the crypto algorithm itself further out into the containing application, forcing attackers (reverse engineers) to understand significantly larger code segments to achieve their goals. Chow 1 discusses a fixed key approach: the key(s) are embedded in the implementation by partial evaluation with respect to the key(s), so that key input is unnecessary. Partial evaluation means that expressions involving the key are evaluated as much as reasonably possible, and the result is put in the code rather than the full expressions. This in itself somewhat hides the key as it now resides throughout the implementation, but furthermore, the efficient techniques of obfuscating lookup tables can be applied to hide the key. A possible attack-scenario is for an attacker to extract a key-specific implementation and use it instead of the key. This problem can be mitigated by designing the key-specific implementation tailored to function as a component of a larger containing system. The larger system can be arranged to provide the component with input in a manipulated or encoded form. When the key-specific implementation is removed by an attacker and inserted in a different larger system, the key-specific implementation will not function properly since the different larger system will not provide its input in the manipulated form expected by the key-specific implementation.

Referring to the step of encoding tables, since encodings are arbitrary, results are meaningful only if the output encoding of one step matches the input encoding of the next. For example, if step X is followed by step Y (resulting in computation of Y ° X ), the computation could be encoded as

Y O X ' = (H o Y o G^H ) o (G o X o F^"1 ) = H o (Y o X) o F^"1 . This way, Y ° X is properly computed albeit that the input needs to be encoded with F and the output needs to be decoded with H^"1. The steps are separately represented as tables corresponding to Y' and X', so that F, G, and H are hidden as well as X and Y.

Apart from such confusion steps, Chow 1 uses diffusion steps by means of linear transformations to further disguise the underlying operations. The term mixing bijection is used to describe a linear bijection, used in the above sense. The implementation of Chow 1 takes input in a manipulated form, and produces output in a differently manipulated form, thereby making the white-box AES implementation difficult to separate from its containing application. Note that the mixing bijection represents additional obfuscating means and are not necessary to implement AES functionality. If more obfuscation is necessary then a white-box according to the invention may also be combined with other obfuscation techniques.

Chow 2 discusses a cryptographic implementation of DES designed to withstand white-box attacks that aim at extracting secret keys from the program. The techniques discussed in this paper about obfuscating look-up table networks apply for a large part also to other cryptographic algorithm including AES and others. While an attacker controlling the execution environment can clearly make use of the software itself (e.g. for decryption) without explicitly extracting the key, forcing an attacker to use the installed instance at hand is often of value to digital rights management (DRM) systems providers. In general, the approach in Chow 2 is to work towards an implementation consisting entirely of substitution boxes, none of which implement affine transformations. A number of techniques, described in Chow 2, support the general approach. Some of these techniques are 110- blocked encoding, combined function encoding, by-pass encoding, split-path encoding, and output splitting.

Partial evaluation means that expressions based on values (partially) known at the time of implementation are pre-evaluated. In a simplified example, when the key is '5', and the original implementation contains the expression '2 * key', then rather than incorporating '2 * 5' in the implementation, the pre-evaluated expression ' 10' is put in the implementation. This way, the key '5' is not directly present in the code. In the case of DES with a fixed key, this involves replacing standard S-boxes with key-specific pre-evaluated S- boxes, e.g., computed from the key at or before compilation time. A mixing bijection according to Chow 2 is a bijective linear transformation designed such that each output bit depends on a large number of input bits. I/O-blocked encoding is an encoding method for handling large numbers of input and output bits. In this case, the encoding/decoding can be formed as a concatenation of encodings, where each encoding deals with a subset of the input/output bits. Combined function encoding means that if two or more operations can be processed in parallel, a single encoding function is applied to the concatenation of the inputs (respectively outputs) of the parallel operations. It is more or less the opposite of I/O-blocked encoding. By-pass encoding means that the encoding transformation adds a number of superfluous bits of entropy to the input and/or output of the transform to be obfuscated, and redesign the transform to be obfuscated to "by-pass" the superfluous bits such that they do not affect the final output of the procedure. Split-path encoding means that a function is modified to provide additional output bits for obfuscating the essential information bits. Output splitting means that the output of a function is distributed over several partial functions, where the output of all partial functions must be combined, preferably in a non- obvious way, in order to obtain the original output of the function.

Chow 2 proposes building encoded networks to construct S-boxes with wide input of, say, 32 bits or even 96 bits. Such a wide-input S-box is divided into a network of S- boxes each having a more narrow input and output; each of the S-boxes is encoded by incorporating an encoding function in the S-box. The inverse of the encoding function is incorporated in the S-box processing the output of the S-box.

A white box implementation of AES To improve to clarity of the exposition, we will first describe a possible white- box implementation of a block cipher, in this case AES. Below we will indicate how the white-box may be adapted such that the precise cryptographic operation that it performs may be changed afterwards by sending it an updating string. It is noted, that the problem the invention seeks to solve is not just restricted to the particular implementation given below, but is endemic to white-box implementations in general. We refer to Chow 1, in particular section 2.2 to section 3.6, for more details on known white-box implementations.

A White-box AES implementation can be sketched as follows. The input to the AES encryption and decryption algorithm is a single 128-bit block. This block is represented by a 4 x 4 matrix consisting of 16 bytes. AES usually consists of 10 rounds for AES- 128. Each round updates a set of sixteen bytes which form the state of AES, thus each AES round processes 128 bits. AES- 128 uses a key of 128 bits. This key serves as input for an algorithm which converts the key into different round keys of 128 bits. A basic round consists of four parts:

SubBytes • ShiftRows

• MixColumns

AddRoundKey.

This order of operations applies to AES encryption. Although the standard order of operations in AES decryption is different, it is possible to rewrite the AES decryption algorithm to have the same order of operations as for AES encryption.

Before the first round, an extra AddRoundKey operation occurs, and from round ten the MixColumns operation is omitted. The only part that uses the key is AddRoundKey, the other three parts do nothing with the key. In the implementation the boundaries of the rounds are changed to integrate the AddRoundKey step and the SubBytes step of the next round into one step. A round begins with AddRoundKey and SubBytes followed by ShiftRows and finally MixColumns.

First, the key is hidden by composing the SubBytes step and the AddRoundKey together into one step. This makes the key no longer visible on its own. Because the key is known in advance, the operations involving the key can be pre-evaluated. This means that the standard S-Boxes which are used in the step SubBytes can be replaced with key-specific S-Boxes. To generate key-specific instances of AES-128, the key is integrated into the SubBytes transformations by creating sixteen 8 >< 8 (i.e. 8-bit input, 8-bit output) lookup tables T₁^ which are defined as follows: T₁^ (X) = S(X Q k;-¹), / = 0,...,3; ; = 0,...,3; r = l,...,9 , where S is the AES S-box (an invertible 8-bit mapping), and k\ _; is the AES sub-key byte at position i, j of the 4x4 matrix which represents the round key for round r. These T-boxes compose the SubBytes step with the previous round's AddRoundKey step. The round 10 T-boxes absorb the post- whitening key as follows: T:_l ^o(x) = S(x ® kl_J ) ® k]_r°_{{ι ι)} , / = 0,...,3; / = 0,...,3 , where sr(i, j) denotes the new location of cell i, j after the ShiftRows step. The total number of T-boxes is 10x16 = 160. However, the key can easily be recovered from T- boxes because S is publicly known. This makes additional encodings necessary. Linear transformations are used for diffusing the inputs to the T-boxes. These linear transformations are called mixing bijections and can be represented as 8 ^χ 8 matrices over GF (2). The mixing bijections are inverted by an earlier computation to undo their effect.

Figure 3 illustrates the tables involved in a round of white-box AES for one 32-bit column of the state (after applying ShiftRows). The three other 32-bit columns are handled in the same way, although the tables have a different content since for those columns different key values may be used. Moreover, different encoding may be applied to the other columns.

The names of the different types of tables are introduced here. They are discussed in more detail hereinafter. Before the rounds, each byte of the 128-bit state is applied to a respective type Ia table. This results in respective 128-bit values which are XOR' ed using a network of type IV tables to provide a 128-bit output that is divided into four 32-bit values. The processing steps of each 32-bit value are outlined here. The four bytes of the 32-bit value are input to four respective type II tables 20. Each of the four type II tables 20 result in a 32-bit output. These outputs are bitwise XOR'ed using type IV tables 22. Each type IV table 22 performs a 4-bit bitwise XOR. By properly connecting inputs and outputs of type IV tables, the bitwise XOR of the four 32-bit outputs can be realized as will be understood by the skilled artisan. The result of this step is a 32-bit value. Each of the four bytes of this value is applied to a respective type III table 24. Each type III table provides a 32-bit output. These outputs are again bitwise XOR'ed using a network of type IV tables 26 similar to the network of type IV tables 22. The output is a 32-bit value indicative of a column of the state. This is repeated for each round.

After the rounds have been performed for each of the four 32-bit values, the outputs are combined into a 128-bit value. Each byte of the 128-bit value is applied to a type Ib table; the results are XOR' ed using a network of type IV tables.

Figure 4 illustrates a type Ia table 100. Figure 5 illustrates a type II table 200. Figure 6 illustrates a type III table 300. Figure 7 illustrates a type IV table 400. Figure 8 illustrates a type Ib table 500.

The mixing bijections are used as follows. An AES state is represented by a 4x4 matrix consisting of bytes. The MixColumns step operates on a column (four 8-bit cells) at a time. Consider a 32 x 32 matrix MC, which implements the MixColumns operation. If this is represented by a table, this table would cost 2³² x 32 = 137438953472 bits = 16 GB. In order to avoid such large tables the matrix is blocked into four sections.

MC is blocked into four 32 x 8 sections, MCO, MCl, MC2, MC3 (block 208). Multiplication of a 32-bit vector x = (xθ, . . . , x31) by MC is done by dividing the bits of x into four bytes and multiplying each of the sections of MC with one of the bytes, yielding four 32-bit vectors (zθ, . . . , z3). This is followed by three 32-bits XORs giving the final 32- bit result z. The four tables together only cost 4 x 28 x 32 == 32768 bits = 4 KB.

The three XORs will be divided into 24 4-bit XORs, each represented by a possibly encoded look-up table, with appropriate concatenation (e.g. ((z[0, 0], z[0, 1], z[0, 2], z[0, 3])+(z[l, 0], z[l, 1], z[l, 2], z[l, 3]))||((z[0, 4], z[0, 5], z[0, 6], z[0, 7])+(z[l, 4], z[l, 5], z[l, 6], z[l, 7]))|| . . .), where || denotes concatenation and + denotes XOR. By using these strips and subdivided XORs, each step is represented by a small lookup table. In particular, for i = 0, . . . , 3 the zi are computed using 8 x 32-bit tables. An 8 x 32-bit table has an 8-bit input and a 32-bit output. Such a table may be implemented by listing 2 output values of 32 bit each. The 4-bit XORs become 24 8 x 4-bit tables. Figure 7 illustrates how input decodings 402 and output encodings 406 can be put around the XORs 404. These encodings are usually randomly chosen non-linear 4 x 4 bijections. The XOR tables are called type IV tables 400. The type IV tables take as input 4 bits from each of two previous computations. The output encodings 212 of those computations are matched with the input decodings 402 for the type IV tables to undo each other. The choice for 4 x 4 non-linear bijections depended on the size of the tables. In this situation a type IV table is only 28 x 4 bits = 128 bytes. 24 tables are needed which cost together 3 KB. If the XORs were not divided, three XOR tables would be needed which computed 32-bit XORs. The T-boxes 206 and the 8 x 32-bit tables 208 could be represented as separate lookup tables. Instead, they can be composed creating new 8^χ32- bit tables 200 computing the SubBytes and AddRoundKey transformations as well as part of MixColumns. This saves both space (to store the T-boxes) and time (to perform the table lookups). Before splitting MC into MCi as above, MC will be left-multiplied by a 32 x

32 mixing bijection MB, illustratively indicated in Figure 5 at reference numeral 210, chosen as a non-singular matrix with 4x4 sub-matrices of full rank. The use of mixing bijections increases the number of possible constructions for a particular table.

Figure 5 illustrates an 8 x 32 type II table 200 including 4 x 4 input decodings 202 and 4 x 4 output encodings 212. These output encodings and input decodings are nonlinear 4 x 4 bijections which must match the input decodings and output encodings of the type IV tables 400. The type II tables 200 are followed by type IV tables 400. In order to invert MB, an extra set of tables is used for calculating MB^"1. Let (x'_o, . . . , x'₃₁) be the input to MixColumns, and let (z₀, . . . , Z₃₁) be the output after MixColumns. Let (z'_o, . . . , z'₃i)^τ be the result after multiplication with MB. (z'o , . . . , z'₃i)^τ serves as input to the type III tables 300. Note that the input decodings and the output encodings need not be considered here because the output encoding of a table is undone by the input decoding of a next table. In the type III tables 300, MB ' is applied 304 and the inverses 308 of the four input mixing bijections 204 of the next round's four type II tables 200. Figure 6 illustrates an 8 x 32 type III table 300 including 4 x 4 non-linear input decodings and 4 x 4 non-linear output encodings. These tables are followed by corresponding type IV tables 400.

One round of data operations involves an operation on a 128-bit state matrix. The data operations performed on each of four strips of 32 bits of the 128-bit state matrix is as follows. The 32-bit strip is divided into four 8-bit bytes. Each of the four bytes is fed into a distinct type II table 200, resulting in four 32-bit output values. These values have to be XOR' ed using obfuscated type IV tables 400. To that end, each 32-bit output value is divided into eight 4-bit nibbles, and appropriate pairs of nibbles are input to respective type IV tables, such that the XOR of the four 32-bit output values is obtained in encoded form. This 32-bit resulting encoded XOR' ed result is again divided into bytes, and each byte is input to a distinct type III table 300. The input decoding of each nibble of the type III tables corresponds to the output encoding of the last applied type IV tables. The type III tables again result in four 32-bit output values that are again XOR' ed using obfuscated type IV tables 400. In summary, the rounds are implemented by lookup tables. The lookup tables of a single round are networked as follows. The data is fed into Type II tables. The output of these tables is fed to a network of Type IV tables representing encoded XORs. The output of this network is fed to Type III tables canceling the mixing bijection encoding that is inserted by the Type II tables. The encoded output of the round is finally derived by feeding the output of the Type III tables into, again, a network of Type IV tables representing encoded XORs.

Furthermore, the white-box implementation contains Type I tables at the beginning (type Ia table 100) and the end (type Ib table 500) for respectively canceling out and inserting external encodings. The type Ia table 100 can be used to apply a concatenation of mappings as illustrated in Figure 4 by applying a single table look-up. In the concatenation, a 4-bit nibble input decoding 102 appears first. Then, an 8-bit to 128-bit mapping 104 appears; this mapping is part of an encoding of the input and output of the network; this mapping can be undone elsewhere in the program. Apart from the linear 8 bit to 128 bit mapping, also other tables may be part of the external encoding. For example, if

Table 100 is comprised in the first round, then 102 may be included. Similarly, if Table 100 is in the last round 106 en 108 may be included. The result of mapping 104 is split in 16 eight-bit pieces to which respective 8-bit bijections 106 are applied. Finally, the output nibble encoding 108 is applied. As mentioned, the cascade of mappings 102, 104, 106, and 108 is pre-evaluated and the final result is tabulated in a look-up table. This results in a table with at most 256 entries of 128 bits each. The concatenation of mappings incorporated in a type Ib table 500 is schematically displayed in Figure 8. The first mapping is the input nibble decoding 502, which is followed by an 8-bit bijection 504, a T-box T_tJ 506, where r corresponds to the last round, an 8-bit to 128 bit mapping for providing output encoding, and output nibble encodings 510. The 128-bit output of this kind of table is XOR'ed with the output of other type Ib tables, again making use of nibble input and output encoded type IV tables 400. The output encoding 508 is undone elsewhere in the program, i.e., outside the cryptographic part of the program. This makes it more difficult for an attacker to break the encodings of the tables by analyzing only an input and an output of the cryptographic part of the program.

An improved white-box implementation of AES

White-box techniques, such as described, e.g., in Chow 1 and Chow 2 can be combined with each other in various ways to obtain white-box implementation of a wide variety of cryptographic operations, including block-ciphers, especially substitution-affine- transformation ciphers, streams ciphers, message authentication codes (MAC), etc. To convert AES into lookup tables the technique of partial evaluation was used. As a consequence the key has spread over the whole of the implementation. To make the white box implementation updatable the following changes can be made.

Referring again to Figure 3, only type II tables and Type Ib tables depend on the key, since they incorporate a T-box. The other tables depend on the details of the cipher algorithm, (in this case AES), and the encodings chosen.

Figure 3 shows all Type II tables needed for one column of one round of AES and 32 bits of intermediate data. One Type II box depends on 8 key-bits, that is, on 8 bit of one AES round-key.

The key-bits on which a Type II block depends can take 256 possible values. In a first embodiment each Type II table is implemented 256 times. That is as many times as there are possible values for the key bits on which the Type II table depends. For example the table marked 820 would be constructed 256 times. Each version of table 820 can be constructed in the same manner except that a different T box is used. The T boxes differ in that they depend on different key bits. In this way all Type II boxes are implemented 256 times.

Similarly, the type Ib tables can be duplicated 256 ways to make the way in which it depends on the key updatable.

Figure 9 illustrates cryptographic system 600. The system comprises a plurality of basic blocks 640. Of plurality 640 basic blocks 612, 614, 620, 632 and 634 are shown. A basic block takes one or more inputs and produces one or more outputs. To more effectively address the blocks a number of sub-pluralities have been indicated in plurality 640. The use of sub-pluralities is optional. Shown are sub-plurality 610 comprising at least blocks 612 and 614 and sub-plurality 630 comprising at least blocks 632 and 634. Cryptographic system 600 comprises a basic block manager 650 which has access to the blocks in plurality 640. The blocks 640 may for example be implemented as look-up tables and stored in a memory to which manager 650 has access. Alternatively, the blocks can be implemented as hardware chips using e.g. CMOS technology. Manager 650 may for example have access to the basic blocks via a bus. Manager 650 itself may be implemented as a software program stored in a memory and executed using a general purpose processor (not shown). Alternatively, manager 650 may be implemented as a finite state machine in hardware. Manager 650 is adapted to receive an input-message 662 and a block selection string 664. Block selection string 664 indicates which blocks are to be used at what point in the cryptographic operation. For example, block selection string 664 may comprise a first sub-string for indicating which block from sub-plurality 610 is to be used. If sub-plurality 610 comprises 256 blocks then 8 bit would suffice to indicate a block from that set.

Alternatively, each block can be given a label, which can be referred to in block selection string 640. For example, block selection string may comprise "620 614 632" to indicate that blocks 620, 614 and 632 are to be used. This may also indicate the order in which the blocks are to be used. Alternatively, the order may be determined by manager 650 based on different criteria, e.g., a predetermined a-priori order. Compared to a fixed key implementation, the block selection string may comprise for each Type II box in the fixed key implementation a sub-string of 8 bits which indicate which version of that Type II box should be used in the updatable white box of cryptographic system 600. Note that there does not need to be a direct relation between the eventual key that will be used and the block selection string. Only the combination of the tables and the block selection string determine the key. Access to the block selection string 664 alone does not suffice to derive the key used in the cryptographic operation for which it configures the cryptographic system 600. Out of all the copies of all the Type II and Ib blocks the block selection string indicates which table is to be used.

During operation, manager 650 receives block selection string 664 and input- message 662. Manager 650 parses the block selection string 664 and determines which of the blocks are to be used. Input message 662 may then be distributed over a number of blocks, e.g., some bytes or nibbles comprised in message 662 are used as input to one or more of the blocks. A basic block produces an output which comprises an intermediate result and/or whole or part of the output message (not shown). The output message may be formed by combining, e.g., concatenating, the output of multiple specific basic blocks. Intermediate data, and combinations thereof, are used as inputs to further basic blocks in an iterative fashion until the basic blocks together have performed the cryptographic operation, or at least a substantive part thereof.

The selection of basic blocks and distribution of the input message and intermediate data over the basic blocks can also be combined. For example, input message 662 can directly be send to basic blocks that are not key-dependent. When key dependent basic blocks, e.g. tables, are needed they may be selected on the basis of block selection string 664. In case of an AES operation an embodiment may work as follows, the incoming input message 662 is first distributed over Type Ia blocks. Next the outputs are combined using Type IV blocks, which are not key dependent. Next Type II blocks are selected based on the block selection string 664. For example, block 612 and block 614 may both be a Type II block, which were constructed in the same manner except for the fact that they represent a different key byte, of the first round key. By selecting the appropriate Type II block the key of the cryptographic operation is also selected. Intermediate results that were obtained in previous blocks are now processed by the selected block of sub-plurality 610. When the key- dependent blocks have finished and produced further intermediate results, those results may be processed by blocks which are not key-dependent. For example, basic block 620 may process the result of the basic block that was selected from sub-plurality 610, independent from the block selection string.

Note that the block selection string does not reveal which type II block corresponds to which key byte. The results of the Type II blocks are again combined using Type IV blocks. In case of an embodiment which does not use Mixing Bijections, the next round may commence at this point. If those operations are done a layer of non-key dependent Type III blocks, and Type IV blocks is first performed before the next round.

Recall from Figure 5 that a type II block starts with a T-box, which in turn starts with a key addition. This can be exploited to avoid making multiple versions of the type II boxes. Instead the basic block that gives the input to the particular type II block, e.g., a type IV block is implemented in multiple versions. For the AES implementation given above, a type II block receives its 8-bit input from two type IV boxes with each 4 bit output. Each of these two input type IV boxes is duplicated 16 times, i.e., 2⁴ times. Each copy is modified to perform not only an XOR operation but also an addition with a fixed 4 bit number. This addition combines with the key addition in the following T-box and has the effect that the Type II block gives a result corresponding to a different key value. In this embodiment it is not necessary to duplicate the Type II boxes. Instead the Type II blocks are made for a fixed key, e.g, the all-zero key, or a random key. During operation, manager 650 introduces an offset of this fixed key based on block selection string 664. Note that in this case, not only does string 664 not indicate the key to be used, the combination of the type IV boxes and the block selection string 664 together only represents an offset to the fixed key. Note that the fixed key is typically unknown to an attacker.

Finally, it is noted that the technique of duplicating the non-key dependent type IV blocks before a type II block can also be done after a block. For example, a block which incorporates at its end a key addition, can be modified with an offset that is introduced in a following block, such as a type IV block.

The last key-dependent block in the AES implementation shown is a type Ib block. Here the same applies. The Ib block itself may be duplicated, or the blocks preceding and following the type Ib blocks can be duplicated. A T-box that depends on two key bytes can be replaced by 2¹⁶ ,different T-boxes, one for each possible combination of the two key bytes. Through the block selection string one of these T-boxes can be selected to update the T-box to the desired key bytes. A type Ib block which comprises two key additions one before the S-box operation and one after, can also be made updateable by making basic blocks before and after the type Ib block updateable. By selecting the appropriate basic block before the type Ib block the key byte addition that occurs before the S-box can be updated, by selecting the appropriate basic block after the type Ib block the key addition occurring after the S-box can be updated. Note that because of external encoding type IV xor tables may be present after the type Ib block. Combinations of the described techniques are also possible. For example, system 600 may be configured for some key value by changing a type II block. Other key values may be configured by selecting an appropriate type IV block before a type II block, etc. It is not necessary that system 600 supports all possible AES keys. Instead fewer versions of a block are made than that the number of key values on which it may depend. As a consequence the white-box can only be configured for a subset of AES keys. It is also possible to modify the key dependency of the cryptographic operation by changing more than one block per key value.

Note that operations may be done, at least partially, in parallel, in so far data dependency allows.

Detailed description of the improved white-box implementation

We continue with a more detailed description of an embodiment of a white- box implementation. We describe an efficient approach for replacing the cryptographic key implemented by a white-box implementation. For every possible key K of the implemented cipher we may specify a small certificate, such that, based on this certificate, a device can derive a white-box implementation that implements key K for that cipher. The certificate is small with respect to the size of the white-box implementation, and can be made to be only a fraction of a kilobyte. Consider a white-box implementation which hides a cryptographic algorithm and a single fixed key in a network of lookup tables. Such a network of lookup tables may be specified by a collection of lookup tables and an algorithm that prescribes how to access these lookup tables. Hence, if S is a set lookup tables and Vs a set of algorithms, where each algorithm gives a different prescription of how to access the lookup tables in S, then the pair (S₅Vs) defines a class C of white-box implementations. We note that an algorithm in Vs need not access all lookup tables of S. Tables may be left unused. Let A be a cryptographic algorithm for which we want to derive a white-box implementation (A can, for instance, be the encryption algorithm of AES) and let A_K be this algorithm for key K. Then, we define a class C=(S₅Vs) of white-box implementations for A, such that for each key K for A the class contains a white-box implementation

that implements A_K. NOW, suppose that in a device we want to replace the key K embedded in a white-box implementation lκ to a key IC . That is, we need to replace I_K=(S₅V_K) by I_ΛΓ =(S,V_K ). Then this may be done by providing the device with a certificate for V_KS which the device then uses to construct Iκ'. The certificate for v/c can be such that V_K' can be derived directly from it or it can be such that it only indicates the difference between v^ and vκ>.

We do not discuss this complete white-box implementation here, but only the part that is relevant for explaining the invention. We refer to Figure 10. After optional preceding transformations, such as initial transformations or the previous rounds, a round of AES starts. The beginning of an AES-round is as follows. The input to a round r is split into 16 bytes, the first two of which are indicated with 910 and 911. Byte 910 is the result of block 981 in the preceding round or in initial transformations. Each byte i is XORed with a byte k[^'~' of the 16-byte round key !■:'-^{' ■}■ The first such addition is indicated with 920. The result of this XOR is used as input to an S-box. The S-Box for byte 910 is indicated with 930. In the construction of a white-box implementation, these two operations are merged into a single so-called T-box operation. This means that for each input byte i to the round we define an 8-to-8-bit bijective mapping T^''] , by T ^"' \ (>i = S(r S* bf^' J-

In the construction of a white-box implementation, this T-box may be implemented by a lookup table. The lookup table not only implements the T-box operation, but a function U^{''' '},. (x) = Q₂ ° * - ° ^Gi *> ^{wnere a}i i^{s a} bijective 8 to 8-bit mapping and a₂

is an 8 to 32 bit mapping that is not necessarily bijective. Function Q^ ¹ is indicated with 925.

The functions a_\ and α₂ may differ for different T-boxes. The lookup tables that implement a T-box are the only lookup tables in the implementation that depend on the AES key. The operations that follow the T-box and which together with T form operation U are indicated for byte 910 with 950. Basic block 950 implements at least the MixColumn operation. The white-box implementation may be transformed into a white-box implementation for another key by redefining the T-box tables in accordance with the bytes of the new round key. This can be done as follows. Let for an AES key K the z^th byte of the round key k^{r) of round r be denoted by k;^{' ' '} and, similarly, let for an AES key K the z^th byte of the round

key k^'-^~'- of round r be denoted by H ^"'^' " . Then we can transform the white-box

implementation for key K into a white-box implementation for key A^* by replacing each table

V^*~" > by table V ^~\ ,~ . This observation can be used to build an embodiment of the invention,

as we now show.

As starting point we take a white-box AES implementation \κ for an arbitrary AES key K. The class C=(S₅Vs) is initialized such that it only contains this white-box implementation. Hence, S contains all lookup tables from the white-box implementation I^ and Vs={vs}, where vs prescribes how the white-box implementation I^ accesses the tables in S. We now extend C as follows.

For each table L^r*'^{: "} , iYi = a, » T^"'^{~ '} ■=■ oT¹, we extend S so that it contains

the set

5^;r = (UΪ^'l .^yS^". -. ^^';--: |^y _: ^'::.^"' G^Y) ^{= G}2 * K^:-^~ * % ^*} of lookup tables. If we replace the tables in white-box implementation

I_K by the proper lookup tables from S;^" , then we can transform I^ into a white-box implementation for any other AES key. We define Vs as the set of all algorithms that can be obtained in this way. In order to obtain a white-box implementation from class C=(S₅Vs) that implements a certain AES key, a device needs only know which lookup table to select from each set S^''^' . Since S/ contains 2 =256 tables, a lookup table from S;^' can be identified by a single byte. This single byte can be transported in a block selection string. Because standard AES consists of 10 rounds and each round consists of 16 T-boxes, this implies that changing a key may be done using a certificate of 160 bytes, i.e., 1280 bits. A consequence is that the number of lookup tables that have to be stored on a device increases. However, by a proper choice of the functions a\ and «2 applied to a table U^''^''"' . (>:) = a_z -• 7^"*" . ^s G^¹, we

can make that the sets S;^{" '} partially overlap. As each lookup table only has to be stored once, this gives an approach for reducing the storage penalty induced by our invention. This concludes the discussion of a first embodiment. The extended set S is not shown in Figure 10.

We now discuss a second embodiment of the invention. Again, we let I^ be a white-box AES implementation according to Chow 1 for AES key K. The construction of this white-box AES implementation can be divided into two parts. In the first part, a white-box implementation is constructed that only uses linear encodings to obfuscate the implementation. This second embodiment uses only such obfuscation. However it is noted that in a second part non-linear encodings may also be added. Further obfuscation, for example using non-linear encodings is preferred, but to simplify the exposition these encodings are not included here. The functions a_x and α₂ in U^'"[ , (:•:) = a, •-> T ' \ o Q^{~ l} are assumed to be

both linear. Again, it is noted that after the steps described here are performed, further obfuscation is possible by applying further non-linear encodings. In white-box implementation 1^, a lookup table u^'~' , (:>;) = G₂ ° T ^{"'' '}■ * ^aϊ ^{L ιs} preceded by two lookup

tables IV₁ and I :V, each computing one nibble of the input a_\(x) of L^{; "'} \ , one of which is

indicated with 981 and the other is not shown.

Both If₁ and IjV implement the XOR of two nibbles. Hence, if we denote the

two input nibbles of I T₁ by n\ and /7₂ and the two input nibbles of £jV by nj, and «₄, then I J₁

computes A₁ =

^']. If we now change the lookup tables 1 T₁ and l^".\ to lookup tables that compute .I₁ = K₁QIn₁QkS₁ ^and

■'-z ~

-^gl i^'-^' J? then this has the same effect as changing

).

From this it follows that we can transform I^ into a white-box implementation for any other AES key by a proper choice of each pair of lookup tables that precedes a table U^''\ . .

As starting point we take a white-box AES implementation I^ for any AES key K. The class C=(S₅Vs) is initialized such that it only contains this white-box implementation. Hence, S contains all lookup tables from the white-box implementation lκ and Vs={vs}, where vs prescribes how the white-box implementation accesses the tables in S. We now extend C as follows.

For each table l ^~\ directly preceding a table (:>:) - tι- ^ T '^" \ -• % ^{l '}

(this table computes a XOR operation) we extend S so that it contains the set

of lookup tables. If we replace the tables l^{" "} _r in white-box implementation I^

by the proper lookup tables from

, then we can transform lκ into a white-box

implementation for any other AES key. We define Vs as the set of all algorithms that can be obtained in this way. One such set S^"~\ is shown in Figure 10 and indicated with 980.

In order to obtain the desired white-box implementation from class C=(S, Vs), a device needs only to know which lookup table to select from each set S^"'\ . Since

contains 2⁴=16 tables, we can identify a lookup table from S^*"^:/ by a single nibble. If I^r

consists of 10 rounds that each contain 16 tables U ^'\ » , and thus 32 tables I^*;^:_ , as may be

done for standard 128 bit AES, changing a key requires a certificate of only 160 bytes, which equals 1280 bits.

The output of operation 950 is combined with parts of the results of other bytes that are similarly transformed. Shown in the figure byte 961 this is one of the four bytes into which byte 911 is transformed. This combination is done in XOR table 970. Note that table 970 could be part of a sub-plurality like sub-plurality 980 but for a next round.

Figure 11 illustrates an embodiment of the invention. The Figure shows a communication port 895 such as a connection to the Internet for connecting with a provider of digital content. The content can also be obtained from medium 896 such as a DVD or CD. Digital content on the PC is typically rendered using media players being executed by processor 892 using memory 891. Such players can execute, for a specific content format, a respective plug-in for performing the format-specific decoding corresponding to content obtained via communication port 895 and/or medium 896. Those content formats may include AVI, DV, Motion JPEG, MPEG-I, MPEG-2, MPEG-4, WMV, Audio CD, MP3,

WMA, WAV, AIFF/ AIFC, AU, etc. For digital rights management purposes, a secure plug-in may be used that not only decodes the content but also decrypts the content. This plug-in comprises processor instructions and parameters stored in memory 891. Processor instructions may cause the process to perform a method according to the invention. The parameters comprise basic blocks and/or look-up tables as set forth herein. A user input 894 may be provided to obtain commands from a user to indicate content to be rendered, and display 893 and/or speakers are provided for rendering the decoded and/or decrypted content.

It will be appreciated that the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source and object code such as partially compiled form, or in any other form suitable for use in the implementation of the method according to the invention. The carrier may be any entity or device capable of carrying the program. For example, the carrier may include a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disk. Further the carrier may be a transmissible carrier such as an electrical or optical signal, which may be conveyed via electrical or optical cable or by radio or other means. When the program is embodied in such a signal, the carrier may be constituted by such cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant method.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. A cryptographic system (600) for performing a key-dependent cryptographic operation mapping an input-message (662) to an output-message, the system comprising a plurality of basic blocks (640), and a basic block manager (650), the basic block manager being configured to iteratively select a selected one of the plurality of basic blocks and to provide the selected basic block with a basic block input to obtain a corresponding basic block output, the basic block input comprising at least a part of intermediate processing data and/or the input- message, the basic block output comprising at least part of the intermediate processing data and/or the output-message, wherein the cryptographic system is configured to receive a block selection string (664), the basic block manager being configured to iteratively select a selected one of the plurality of basic blocks in dependency on the block selection string for configuring the cryptographic operation for a particular key.

2. A cryptographic system as in Claim 1, wherein the plurality of basic blocks comprises at least one sub-plurality of basic blocks (610, 630), the basic block manager being configured to select the selected one of the plurality of basic blocks from the sub-plurality in dependency on the block selection string.

3. A cryptographic system as in Claim 2, wherein the sub-plurality of basic blocks are configured to produce basic block outputs encoded with a same output-encoding.

4. A cryptographic system as in Claim 2, wherein the sub-plurality of basic blocks are configured to receive basic block inputs with a same input-encoding.

5. A cryptographic system as in Claim 3 and 4, wherein a first basic block of the sub-plurality of basic blocks is configured to produce a first response encoded with the output-encoding upon receiving a first input, a second basic block of the sub-plurality of basic blocks is configured to produce a second response encoded with the output-encoding upon receiving the first input, wherein the second response differs a amount from the first response which depends on the first and second basic block and which is independent from the first input.

6. A cryptographic system as in any one of Claims 2 to 5, wherein the sub- plurality of basic blocks are each adapted to perform the same sub-operation of the cryptographic operation and are adapted for different keys.

7. A cryptographic system as in any one of Claims 2 to 5, wherein the sub- plurality of basic blocks each represent an XOR operation.

8. A cryptographic system as in any one of Claims 2 to 7, wherein the block selection string comprises a sub-string, the sub-string determining said selection of the sub- plurality of basic blocks.

9. A cryptographic system as in any one of the preceding claims wherein the basic blocks comprise a look-up table.

10. A cryptographic method for mapping an input-message to an output-message, comprising selecting a selected one of a plurality of basic blocks, providing the selected basic block with a basic block input comprising at least a part of intermediate processing data and/or the input-message to obtain a corresponding basic block output comprising at least a part of the intermediate processing data and/or the output-message, wherein the cryptographic method is configured for obtaining a block selection string, the selected basic block being selected in dependency on the block selection string.

11. A computer program comprising computer program code means adapted to perform all the steps of the method of claim 10 when the computer program is run on a computer.

12. A computer program as claimed in claim 11 embodied on a computer readable medium.