Patent Application
20140101458
This invention relates to data security and cryptography and more generally to improving the security of computer enabled cryptographic processes.
Cryptographic algorithms are widely used for encryption and decryption of messages, authentication, digital signatures and identification. The AES (Advanced Encryption Standard) is a well known cipher. AES is an exemplary symmetric block cipher. Block ciphers operate on blocks of plaintext and ciphertext, usually of 64 or 128 bits but sometimes longer. Stream ciphers are the other main type of cipher and operate on streams of plain text and cipher text 1 bit or byte (sometimes one word) at a time. With a block cipher, a particular plain text block will always be encrypted to the same cipher text block using the same key. However, to the contrary with a stream cipher, the same plain text bit or byte will be encrypted to a different bit or byte each time it is encrypted. Hence in the ECB (electronic code book) mode for block ciphers, each plain text block is encrypted independently. In another mode, encryption is also a function of the previous blocks.
AES is approved as an encryption standard by the U.S. Government. Unlike its predecessor DES (Data Encryption Standard), it is a substitution permutation network (SPN). AES is fast to execute in both computer software and hardware implementation, relatively easy to implement, and requires little memory. AES has a fixed block size of 128 bits and a key size of 128, 192 or 256 bits. Due to the fixed block size of 128 bits, AES operates on a 4×4 array of bytes. It uses key expansion and like most block ciphers a set of encryption and decryption rounds (iterations). Each round involves the same processes. Use of multiple rounds enhances security. Block ciphers of this type use in each round a substitution box or s-box. This operation provides non-linearity in the cipher and significantly enhances security.
Note that these block ciphers are symmetric ciphers, meaning the same algorithm and key are used for encryption and decryption, except usually for minor differences in the key schedule. As is typical in most modern ciphers, security rests with the (secret) key rather than the algorithm. The s-boxes or substitution boxes accept an n bit input and provide an m bit output. The values of m and n vary with the cipher and the s-box itself. The input bits specify an entry in the s-box in a particular manner well known in the field.
Many encryption algorithms are primarily concerned with producing encrypted data that is resistant to decoding by an attacker who can interact with the encryption algorithm only as a “Black Box” (input-output) model, and cannot observe internal workings of the algorithm or memory contents, etc due to lack of system access. The Black Box model is appropriate for applications where trusted parties control the computing systems for both encoding and decoding ciphered materials.
However, many applications of encryption do not allow for the assumption that an attacker cannot access internal workings of the algorithm. For example, encrypted digital media often needs to be decrypted on computing systems that are completely controlled by an adversary (attacker). There are many degrees to which the Black Box model can be relaxed. An extreme relaxation is called the “White Box” model. In a White Box model, it is presumed that an attacker has total access to the system performing an encryption, including being able to observe directly a state of memory, program execution, modifying an execution, etc. In such a model, an encryption key can be observed in or extracted from memory, and so ways to conceal operations indicative of a secret key are important.
The publication “White-Box Cryptography in an AES implementation” Lecture Notes in Computer Science Vol. 2595, Revised Papers from the 9th Annual International Workshop on Selected Areas in Cryptography pp. 250-270 (2002) by Chow et al. discloses implementations of AES that obscure the operations performed during AES by using table lookups (also referred to as TLUs) to obscure the secret key within the table lookups, and obscure intermediate state information that would otherwise be available in arithmetic implementations of AES. In the computer field, a table lookup table is an operation using a data structure (the table) to replace a computation with an array indexing operation.
Chow et al. (for his White Box implementation where the key is known at the computer code compilation time) uses 160 separate tables to implement the 11 AddRoundKey operations and 10 SubByte Operations (10 rounds, with 16 tables per round, where each table is for 1 byte of the 16 byte long—128 bit—AES block). These 160 tables embed a particular AES key, such that output from lookups involving these tables embeds data that would normally result from the AddRoundKey and SubByte operations of the AES algorithm, except that this data includes input/output permutations that make it more difficult to determine what parts of these tables represent round key information derived from the AES key.
An extension of Chow et al. was published by Olivier Billet et al. “Cryptanalysis of a White Box AES Implementation” in SAC 2004, LNCS 3357 pp. 227-240, 2005. The details of the processed basic operations are necessary to mount this attack. This means the attacker has to distinguish the set of operations to extract the operations per rounds, the MixColumn operation, etc.
Hence there are two basic principles in the implementation of secure computer applications (software). The first is called “Black Box” because it implicitly supposes that the user does not have access to the computer code nor any cryptographic keys themselves. The computer code security is based on the tampering resistance over which the application is running, as this is typically the case with SmartCards. For the “White Box”, it is assumed the (hostile) user has partially or fully access to the implemented code algorithms; including the cryptographic keys themselves. It is assumed the user can also become an attacker and can try to modify or duplicate the code since he has full access to it in a binary (object code) form. The White Box implementations are widely used (in particular) in DRM (Digital Rights Management) applications to protect e.g. audio and video content.
Software implementation of cryptographic building blocks are insecure in the White Box threat model where the attacker controls the computer execution process. The attacker can easily extract the (secret) key from the memory by just observing the operations acting on the secret key. For instance, the attacker can learn the secret key of an AES cipher software implementation by passively monitoring the execution of the key schedule algorithm. Also, the attacker could be able to retrieve partial cryptographic result and use it in another context (using in a standalone code, or injecting it in another program, as an example).
The conventional implementation of a block cipher in the White Box model is carried out by creating a set of table lookups. Given a dedicated cipher key, the goal is to store in a table the results for all the possible input messages. This principle is applied for each basic operation of the block cipher. In the case of the AES cipher, these are the shiftRow, the add RoundKey, the subByte and the mixColumns operations.
Since all the possible inputs have to be considered, the inputs are split into sets of bytes. The result after each operation on each byte is stored. Moreover, for security reasons, the input and output of the tables are masked through various methods (including permutations). The size of the tables differs according to the choice of the input decomposition (byte, half byte, double-bytes . . . ) and to the choice of the masking process (a XOR, random permutation etc.) See Chow et al.
When a block cipher has been implemented using a White Box approach, the code of the execution process is not particularly long and mainly consists of the lookup table accesses and masks managements, plus some extras. The first goal for an attacker reverse engineering such code is to retrieve the code to obtain, after simplification, an equivalent understandable and executable source code. Various tools exist to harden the code against reverse engineering threats. But, this is often not enough security.
The present method and apparatus tie the (e.g. White Box) table lookups to the associated implementing computer code to obtain a monolithic code (meaning hard for an attacker to penetrate) at source code compilation time to avoid an attacker replacing any lifted code with other code. In other words, tying the tables to the code provides an opportunity for code integrity verification. This means that an attacker will have to break several different layers of protection before having a fully functional reverse engineered code. The method is not limited to decryption or block ciphers, but is useful for any cryptographic process having lookup tables.
Consider an existing White Box implementation of a cryptographic algorithm. The associated computer code mainly corresponds to a set of table accesses and their management. In the implementation of secure code, various basic operations have been masked, modified, changed into more complex forms, etc. One of the possible ways for an attacker to proceed is to isolate some small functions, to understand what they are doing, to try to find where they are repeated (loops) and then, recompose the original code considering this information. As already explained, the table lookups are generated through a specific process managing correctly the masks on input and output data. See
If an attacker is able to reverse-engineer the code of an encryption algorithm and extract the tables, then he is able to rebuild code equivalent to the original code (being able to encrypt) by extracting all the tables. The present method is intended to avoid this.
To thwart reverse engineering of a part of the computer code implementing a cryptographic algorithm (process) and to reinforce the code protection, the present method protects the tables, which are intensively used for the table lookup operations. Many known White Box cryptographic implementations are tied to the code directly (so that an update of the software could change the underlying implementation as far as it does not modify the final result). The present disclosure is of a way to tie two or more White Box implementations together, see
In this approach, the input content and cryptographic keys remain unchanged but the values in the lookup tables are changed at the time of compilation of the source code. Software integrity information provided in the code allows the method to tie the implementation to the software (code) itself. This way, part of the process cannot be attacked directly without having to reverse engineer this additional protection. Any modification by an attacker to the integrity of software (by adding a patch, software breakpoint, etc.) will inevitably tamper with the associated integrity verification information and lead to changes in the resulting output, making it easy to detect such code tampering. See commonly owned United States Patent Application Publication No. 20080168564, Software or other information integrity verification using variable block length and selection, incorporated herein by reference in its entirety.
A table is globally (all entries) masked in accordance with the invention, where this may be accomplished by any type of masking operation (generically referred to as a “permutation”). This masking is performed on the source code when it is compiled. This process is illustrated in
As shown in
The process thus is to generate hashes, corresponding to the binary (object) code itself, and then re-use this hash information to perform additional masking operations on the lookup tables. This way the White Box process tables are dependent on the binary code which uses them and an attacker will not be able to simply extract these tables from the binary code and use them as is. It is also a way to associate together two different protections as described above: code integrity verification and White Box cryptography.
The following describes a more complex method which is an extension of the above. This more complex method is usually performed on the object (compiled) code. Let fT designate the one-way function (there may be one function for each T_j computation) used to compute each T_j, so expressed algebraically:
T
—
j=fT(part_of_code—j)
where “part_of_code_j” designates a part (such as a particular number of words or bytes) of the global code in which a White Box cryptographic process implementation is used.
This process does not necessarily mask (called the “extra mask” hereinafter) all entries of the tables but can apply the extra mask only to a part of some of the tables. All tables are subject to the initial masking operation. When accessing the tables dedicated to the White Box process, a call is done to function fT with the index information. fT is an external and code obfuscated function. In one embodiment, the process adds an extra mask operation to the tables. This extra masking is, e.g., a complex encryption of the dedicated or chosen positions, or a simple XOR (logical exclusive OR) operation. Between these two extreme solutions, various other masking methods exist. This extra masking operation is designated EM(.).
Note that only a part of each of the tables may be extra masked.
The extra mask function, designated EM(.), can take different inputs according to what is needed. For instance, the inputs can be only the value in at the original position in the table, denoted A, and T_j. In this example, EM(.) can be merely an XOR operation, so that:
T
—
j XOR A
Another example uses a more complicated extra masking function to increase complexity. The extra masking function still must be an invertible operation such as addition, multiplication or a symmetric cipher encryption using a global key k or a table dedicated key with an associated encryption function designated E, so E(A,T_j XOR k). So the initial masking operation is also by definition such an invertible operation. Otherwise one could not unmask it. The input can also use the value of the position A, T_j, the table index position I, and the table number designated tN where there is a number of lookup tables designated by numbers. In this case several complex processes can be used to defeat an attack, for instance expressed logically as:
T
—
j XOR A XOR tN XOR I
with a more complex process with an encryption function E as E(A,f(T_j, tN, I)), where f(.) is any suitable derivation function.
From a security point of view, it is important that the extra masked values cannot be identified to other data (that is, when masked are indistinguishable by an attacker). For instance, the extra masked values should stay in the same range of the usual masked values (byte to byte). Moreover, in a table it is better to mask several positions, because conventionally a given masked value appears only once in each table. It is however possible to circumvent this problem by using a conventional masking process not only depending on a bijection, but also on the position in the table. This way, a given value can appear several times in a table, even prior to applying the extra masking transformation.
The overall implementation of a White Box cryptographic process in accordance with the invention is as follow:
The access to the tables originally (without applying the present protection) was:
1) alpha=Table[beta];
This is replaced in accordance with the invention by:
1) If beta position extra mask
2) else alpha=Table[beta], where conventionally alpha designates the TLU output and beta designates the TLU input.
The previous example considers only extra masking of selected table positions. This extra masking could also be applied to all table positions.
The information about which part of each table is transformed can be determined either dynamically (computed only at run time), or stored statically at compilation time in another (master) table lookup. Run time means code execution, when the cryptographic process object code is executed on a message being encrypted. Static or dynamic processes may be used in various table lookups in one cryptographic process. For the static case, the master table contains a list of the other table lookups and their indices which are transformed and the tables which are not transformed. For the dynamic case, the goal is to know, from various information, if the table index which has to be fetched is transformed or not. One way to do this is to use a multi-root polynomial. For instance, if there are 50 table indexes, and 20 of them are transformed indexes, one could use a polynomial of degree 20. Each index which requires a transformation would be a root of the polynomial (for performance reasons, operations would be done modulo a given value). Typically an index of 20 is too large to process a byte of data, so this would process a data word or 4 bits. This way, when a value has to be fetched from the table, one would compute this polynomial. If the resulting value is null, then one would need to call a transformation to obtain the real value. If not, one could fetch the direct value. This occurs at run time.
The implementation of a White Box cryptosystem requires several table lookups which are accessed several times, so all the tables can be masked with the present process. In another embodiment only some of the tables are masked with the process. In yet other embodiments only a part of each of the tables is masked with the process, or only a part of some of the tables is masked with the process.
The more hash values of T_j available, the more secure is the solution. Masking only some bytes of data at a given table position would result in using only a part of them for one execution. This would also desirably link the code execution process with the data input, since according to the word accessed inside a table a call to obtain T_j is done or not and index j is varying. For instance, if an attacker wants to lift all the White Box process tables, he will have to monitor several different decryptions to know which parts of the tables are transformed, and how they are transformed.
Since the present method uses information regarding the binary (compiled or object) code itself for verification purposes, it by definition cannot have that information in the corresponding source code before it is compiled. So in one embodiment the method uses multiple passes to develop the binary code from the source code, as follows:
These steps are typically performed using suitable software tools provided to the developer along with the conventional compiler. Each computer language of course has such a compiler.
The overall object code creation process can be summarized as:
The White Box table lookups are modified at source code compilation time accordingly to store the software integrity verification information, and the “correction” (recovering actual cryptographic values) is performed at run time, according to the instant recomputed software integrity verification information.
For the case of a plurality of linked White Box processes (see
In case of software integrity tampering or modification by an attacker, the White Box software integrity information will be corrupted since the integrity verification (hash) computation will generate an unexpected result and table lookups will not be computed with the correct values. As a consequence, the deciphered integrity verification (hash) value will not be retrieved correctly.
Advantages of the present method include: the complexity of the cryptography process is increased, tying the cryptographic implementation and results to the software which hosts the code protects integrity, and tables cannot be simply lifted from the object code by an attacker as they were before so they are protected. White Box security is also dependent on the software integrity protection. Here the tables are never all “in clear” in memory and so are harder to reverse engineer.
When this masked object code is executed on the user's system, for instance to actually encrypt or decrypt a message, the object code is unmasked at run time.
Computer code in terms of the above described developer's tools and the compiler is conventionally stored in memory (computer readable storage medium, e.g., RAM or ROM) associated with a processor for in the computing system execution by the processor. The incoming source code embodying the cryptographic process to be protected is received at a port of the computing system and stored in a computer readable storage medium (memory, e.g., RAM) where it is coupled to the processor. The processor conventionally partitions the code into suitable sized blocks at the partitioning module. Other software (code) modules executed by the processor carry out the functionality set forth above.
Computing system 160 can also include a main memory 168, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by processor 164. Main memory 168 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 164. Computing system 160 may likewise include a read only memory (ROM) or other static storage device coupled to bus 162 for storing static information and instructions for processor 164.
Computing system 160 may also include information storage system 170, which may include, for example, a media drive 162 and a removable storage interface 180. The media drive 172 may include a drive or other mechanism to support fixed or removable storage media, such as flash memory, a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disk (CD) or digital versatile disk (DVD) drive (R or RW), or other removable or fixed media drive. Storage media 178 may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive 72. As these examples illustrate, the storage media 178 may include a computer-readable storage medium having stored therein particular computer software or data.
In alternative embodiments, information storage system 170 may include other similar components for allowing computer programs or other instructions or data to be loaded into computing system 160. Such components may include, for example, a removable storage unit 182 and an interface 180, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units 182 and interfaces 180 that allow software and data to be transferred from the removable storage unit 178 to computing system 160.
Computing system 160 can also include a communications interface 184. Communications interface 184 can be used to allow software and data to be transferred between computing system 160 and external devices. Examples of communications interface 184 can include a modem, a network interface (such as an Ethernet or other network interface card (NIC)), a communications port (such as for example, a USB port), a PCMCIA slot and card, etc. Software and data transferred via communications interface 184 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 184. These signals are provided to communications interface 184 via a channel 188. This channel 188 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of a channel include a phone line, a cellular phone link, an RF link, a network interface, a local or wide area network, and other communications channels.
In this disclosure, the terms “computer program product,” “computer-readable medium” and the like may be used generally to refer to media such as, for example, memory 168, storage device 178, or storage unit 182. These and other forms of computer-readable media may store one or more instructions for use by processor 164, to cause the processor to perform specified operations. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system 160 to perform functions of embodiments of the invention. Note that the code may directly cause the processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.
In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system 160 using, for example, removable storage drive 174, drive 172 or communications interface 184. The control logic (in this example, software instructions or computer program code), when executed by the processor 164, causes the processor 164 to perform the functions of embodiments of the invention as described herein.
This disclosure is illustrative and not limiting. Further modifications will be apparent to these skilled in the art in light of this disclosure and are intended to fall within the scope of the appended claims.
