White box encoding

Abstract

The invention relates to a method for generating encoding for a computer-implemented cryptographic algorithm. The following steps are carried out: - obtaining at least one characteristic specific to a computer peripheral (1) configured to execute a cryptographic algorithm (43); - on the basis of the specific characteristic, generating an encoding operation (433, 434) dependent on the peripheral (1); - associating the generated dependent encoding operation (433, 434) with the cryptographic algorithm (43).

Description

White box encoding

[0001] The invention relates to white-box cryptography, and more particularly to the encoding operations associated with an encryption algorithm within the framework of a white-box attack model.

[0002] White-box cryptography is a subject of study based on the premise that an attacker, who seeks to identify secret, encrypted data that can be decrypted using an encryption algorithm, has full access to the algorithm's execution platform and to the software implementation of this algorithm in the platform: the binary code is thus entirely visible, it is modifiable, and the attacker can also act at will on the software execution through the various systems of the platform such as memory, calls to processors, etc. The most classic example is that of an attacker having access to a third-party smartphone, in which a software application on the smartphone encrypts or decrypts secret data using an encryption key and a cryptographic algorithm, for example of the "AES" type (for "AdvancedEncryptionStandard").The attacker has full power over the smartphone and the algorithm, and can thus seek to read the corresponding binary code, modify it, execute it in a specific manner, with the ultimate objective, knowing the type of algorithm used, of identifying the encryption key, decrypting the secret data, and / or modifying this data.

[0003] To prevent this attacker from accessing secret data and to protect the integrity of the encryption in this white box context, a method is known in the state of the art consisting of encoding elementary operations of the encryption (or decryption) algorithm. Indeed, an elementary operation, resulting from the combination between a known type of algorithm and a specific encryption key, is generally implemented in the form of a truth table indicating the possible results of the operation depending on the input data. An encoding operation therefore consists of applying a random transformation to an elementary operation in order to make this operation unreadable. To encode an operation, a substitution of the elements of the truth table can be carried out, by combining the initial table with a random substitution table, in order to obtain an "obfuscated" or "merged" table.Alternatively, a linear transformation can be applied to the operation by combining a vector representing the output data, or a matrix corresponding to the operation, with another matrix, called an encoding matrix, which is also random. An encoding can also be a combination of one or more substitutions and one or more encoding matrices. Other types of encoding are possible. In addition, each elementary operation following an encoded elementary operation is itself combined with a so-called "inverse" encoding, or decoding, corresponding inversely to the previous encoding. This is, for example, the inverse substitution table or the inverse matrix corresponding to the previous encoding, so that the initially planned algorithm is not modified by successive encodings.In all cases, only the truth tables resulting from these encoding operations merged with the elementary operations, i.e. the so-called "obfuscated" or "merged" tables, are stored in the software memory implementing the algorithm. In this way, the attacker, having access only to the obfuscated tables, cannot identify which elementary operation is associated with each table and therefore cannot determine the encryption key used and decrypt the secret data.

[0004] These encodings, which allow an encryption (and / or decryption) algorithm to be encoded within an unsecured execution platform, for example within a smartphone, are called "internal", since they make it possible to make the encryption key used within the white box formed by the implemented algorithm unreadable.

[0005] However, this white box generally communicates with a remote server and a third-party application on the same platform. For example, it is common for a server to encrypt data and communicate the encrypted data to the smartphone, and then for the white box, i.e., the decryption algorithm executed by the smartphone, to be used to decrypt the data before this decrypted data is communicated within the same smartphone to a third-party application, called the "final application," which is intended to use the decrypted data. However, the final applications are developed by third-party companies, independently of the white boxes.These companies therefore acquire white boxes marketed in the form of software libraries containing the encryption and decryption algorithm, and an API (for "ApplicationProgrammingInterface") allowing the algorithm to be controlled and the data output from this algorithm to be used in the final application developed. In this context, the "internal" encodings within the white box do not prevent the decrypted data from circulating, in clear text, between the white box and the final application. Similarly, even if the encryption key used is now very difficult to identify within the white box thanks to the internal encodings installed in this white box, the attacker can attempt to port the code, i.e. export the entire code from the white box to another device to exploit it there without having to identify the key.

[0006] This is why it is known in the state of the art to implement, in addition to these internal encodings, so-called "external" encodings, placed at the ends of the complete communication channel between the sending of the data and their use. For example, first of all within the remotely located server, a first "external" encoding is applied to the last truth table of the server's encryption algorithm, whether in the form of a substitution table, an encoding matrix or another form of random encoding, so that the data to be communicated to the smartphone is not only encrypted as intended, but also encoded before being communicated to the smartphone. Then, at the input of the white box, the inverse encoding of the outer encoding is applied to the first truth table of the decryption algorithm, before the data is processed through the white box decryption algorithm and its inner encodings.The inverse encoding corresponding to the first external encoding is therefore part of the white box. Then, a new random encoding is done at the output of the white box, by applying this new encoding to the last truth table of the white box. Here too, this second encoding is therefore part of the white box. At the output, the data is therefore decrypted, but again encoded this time using this new random encoding, before being communicated to the final third-party application intended to use it. Finally, within this third-party application, the external encoding corresponding to the inverse of the encoding applied at the end of the white box allows the data to be decoded within the application before it is used by the application.

[0007] Thanks to these external encodings placed outside the white box, even once decrypted, the data does not circulate "in clear" outside the white box, it remains encoded, therefore protected from manipulation by an attacker who would like to intercept it. In addition, the attack consisting of carrying the entire white box code on another device does not work, since in this context the white box code includes within it an encoding at its input and an encoding at its output. Without the corresponding reverse encodings, which are located remotely (within the server and within the final application), it is not possible to recover the data in clear. Moreover, added to the internal encodings, these external encodings associated with encodings at the output and input of the white box make it even more difficult to identify the encryption key of the white box.

[0008] It should be noted that all of these encodings, both internal and external, are random, that is to say they use transformations, substitutions or other manipulations unknown to all, so that no attacker can find them.

[0009] However, this method, which includes internal and external encodings, still has at least two drawbacks.

[0010] First, as mentioned above, the final applications are developed by third-party companies that acquire white boxes and use an API to control them. These companies must therefore integrate into their application themselves the external encoding corresponding, inversely, to the output encoding of the white box. They must then themselves ensure the protection of this external encoding (which can be called external decoding) within the final application. They therefore have an uncomfortable security responsibility and often force them to use an external solution, potentially expensive, unreliable and adding complexity to the entire data communication channel. In addition, this constraint contravenes the principle of simplified security sold to these companies when the white box was acquired.

[0011] Second, if the white box is leaked, it remains difficult to identify the source of the leak. In particular, it is not very relevant to embed signatures or identification tokens in the white box, since the attacker will have the possibility of modifying or deleting them.

[0012] The invention aims in particular to improve the security of an already encoded white-box cryptographic algorithm. Another aim is to identify the source of a possible leak in the algorithm.

[0013] To this end, the invention relates to a method for generating encoding for a cryptographic algorithm, implemented by computer, characterized in that the following steps are implemented:

[0014] - obtaining at least one characteristic specific to a computer device configured to execute a cryptographic algorithm;

[0015] - from the specific characteristic, generation of a device-dependent encoding operation;

[0016] - association of the generated dependent encoding operation with the cryptographic algorithm.

[0017] Thus, the transformation associated with the dependent encoding operation depends on at least one characteristic of the device on which the algorithm is intended to be executed. This dependent encoding operation, which can be called dependent encoding, therefore makes it possible to anchor the algorithm on a particular device. The security of the data and of the encryption is therefore improved. In particular, if this dependent encoding is a decoding of a previous encoding, it is necessary to decode the data to generate this dependent encoding using the device, since only this device provides the specific characteristic allowing the generation of the correct decoding. Alternatively, if this dependent encoding aims to encode data, the latter can also only be decoded using the device.

[0018] Furthermore, since dependent encoding is device-dependent, it is easier to identify the source of the algorithm leak, since only the intended device can correctly decode the data encoded using this dependent encoding and thus execute the algorithm. Furthermore, if the attacker modifies the dependent encoding to make the source of the leak untraceable, the algorithm no longer works, rendering any attack useless.

[0019] Advantageously, to associate the dependent encoding operation with the algorithm, the encoding operation is combined with a cryptographic elementary operation of the algorithm so as to form a single merged operation, so that data processed by the merged operation is operated in accordance with the cryptographic elementary operation and simultaneously encoded in accordance with the dependent encoding operation.

[0020] Thus, dependent encoding cannot be distinguished from an elementary operation, in particular encryption or decryption, of the algorithm. Both the operation and the dependent encoding are therefore impossible to identify for an attacker with access to the executable code. The operation and the encoding are thus "masked".

[0021] Preferably, the dependent encoding operation is associated with the algorithm before any cryptographic execution of the algorithm on the device, in particular during an installation of the algorithm on the device, the cryptographic execution corresponding in particular to a data encryption or decryption operation.

[0022] Thus, the algorithm includes this dependent encoding before it is even used on the device. The dependent encoding therefore remains identical even if the algorithm is implemented on a device other than the one whose encoding is dependent. In particular, it is possible for the algorithm to be associated with this encoding before being implemented on the device, if the device and its specific characteristics are known in advance.

[0023] Alternatively, the algorithm having been installed on the device, the steps of obtaining the specific characteristic, generating the dependent encoding operation and associating the dependent encoding operation with the algorithm are carried out, during a cryptographic execution of the algorithm on the device, the cryptographic execution corresponding in particular to a data encryption or decryption operation.

[0024] So, here the dependent encoding is instead generated at the time of the algorithm execution. In particular, it must be generated again at each execution. The generated dependent encoding can therefore in this case vary depending on the device on which it is generated.

[0025] Advantageously, the dependent encoding operation associated before any cryptographic execution being a first dependent encoding operation, the dependent encoding operation generated and associated during the cryptographic execution on the peripheral being a second dependent encoding operation, this second encoding operation is generated so that data encoded via the first dependent encoding operation is decoded via the second dependent encoding operation.

[0026] In other words, the two previous operations are performed in parallel to generate two distinct but corresponding dependent encodings: one - generated in advance and remaining identical regardless of the device on which the algorithm is implemented - encodes data, while the other, in this case the dependent decoding - generated at each execution from the device on which the algorithm is implemented - decodes this same data. Thus, the data can only be decoded if the algorithm is implemented on the device on which the encoding and decoding are dependent. If the algorithm is implemented on another device, the dependent encoding will encode the data according to the device on which it is dependent, and then the dependent decoding will decode it according to the other device, so the data will not be correctly decoded.The association between a dependent encoding generated in advance and a dependent decoding generated at each cryptographic execution therefore allows anchoring of the white box on a particular device.

[0027] We can reverse the operations so that the operation generated in advance is decoding, the operation generated at each execution being encoding.

[0028] Preferably, the cryptographic elementary operation being a first cryptographic elementary operation and the merged operation being a first merged operation, the algorithm also comprising a second cryptographic elementary operation directly following the first cryptographic elementary operation, the following steps are implemented:

[0029] - combination, before any cryptographic execution of the algorithm on the device, of the first dependent encoding operation with the first elementary cryptographic operation so as to form the first merged operation;

[0030] - combining, during the cryptographic execution of the algorithm on the device, the second dependent encoding operation with the second elementary operation, so as to form a second merged operation, so that, when the data encoded and operated by the first merged operation is processed by the second merged operation, it is decoded in accordance with the second dependent encoding operation and simultaneously operated in accordance with the second cryptographic elementary operation.

[0031] Thus, dependent encoding and decoding operations cannot be distinguished, by an attacker with access to the executable code, from the elementary operations with which they are respectively combined. These elementary and encoding operations are "hidden" in the white box.

[0032] Advantageously, the following steps are also implemented:

[0033] - prior to the first steps stated, generation of a third encoding operation, not dependent on the device, and of a fourth encoding operation, not dependent on the device and generated so that data encoded via the third encoding operation is decoded via the fourth encoding operation,

[0034] - before any cryptographic execution of the algorithm, combination of the third encoding operation with the first merged operation, so as to form a new first merged operation allowing simultaneously to encode the data in accordance with the first encoding operation and the third encoding operation and to operate the data in accordance with the first elementary operation;

[0035] - during cryptographic execution, combination of the fourth encoding operation with the second merged operation, so as to form a new second merged operation allowing simultaneously to decode the data in accordance with the second encoding operation and the fourth encoding operation and to operate the data in accordance with the second elementary operation.

[0036] Thus, non-dependent, i.e. random, conventional encoding (and decoding) operations are added to the device-dependent encoding (and decoding) operations, and they are also merged with the first and second elementary operations of the algorithm, respectively. Two merged operations are thus obtained, one corresponding to a first elementary operation, to the dependent encoding and to a non-dependent encoding (which is called the third encoding operation), the other corresponding to the second elementary operation, to the dependent decoding and to the non-dependent decoding (which is called the fourth encoding operation), these operations not being able to be distinguished from each other within the merged operations. The addition of the non-dependent encodings and decodings makes it possible to hide the second elementary operation.Indeed, since the dependent decoding (the second dependent encoding operation) is only generated at the execution of the algorithm, in the absence of the non-dependent encoding, the second elementary operation would be accessible and understandable to an attacker with the executable code. The fusion between the non-dependent decoding and the second elementary operation therefore makes it possible to hide the latter before the generation of the dependent decoding.

[0037] Again, as throughout the description, unless otherwise evident, the terms encoding and decoding could be reversed.

[0038] Preferably, the first and second elementary cryptographic operations forming a pair of encoded operations, the steps of generating and combining encodings are repeated for at least one other pair of encoded operations of the algorithm, preferably for several pairs.

[0039] Thus, the method involves more than two elementary cryptographic operations of the algorithm. Potentially, each elementary operation of the algorithm may be involved in an association with a dependent encoding, but generating a dependent encoding or decoding at the time of execution of the algorithm requires resources and time that may make the execution too long. It is therefore advantageous to adapt the number of elementary operations combined with dependent encodings according to the desired degree of security and the resources available within the device.

[0040] Advantageously, the cryptographic algorithm is of the “AES” type, for “AdvancedEncryptionStandard” or “DES” for “DataEncryptionStandard”.

[0041] These algorithms, associated with private keys, in fact include operations that are easily separable from one another and which will form the elementary cryptographic operations. Now, the more easily an algorithm is separable into simple elementary operations, the easier it is to encode it by associating encodings with these operations, in particular dependent encodings here.

[0042] Preferably, the obtained device-specific characteristic is one of the following characteristics or a combination of at least some of the following characteristics:

[0043] - the MAC number (for “Media Access Control”) of the device;

[0044] - the IMEI number (for “International Mobile Equipment Identity”) of the device;

[0045] - the serial number of the phone;

[0046] - a counter of the number of installations of a cryptographic algorithm within the device.

[0047] Thus, generating the dependent encoding using another device results in a different encoding, or a non-matching decoding, since the eigencharacteristic is different.

[0048] Advantageously, the generation of the device-dependent encoding operation comprises a step of hashing the characteristic(s) specific to the device, so as to generate a device-dependent encoding table or a device-dependent encoding matrix, at least one of the elements of the table or respectively of the matrix being derived from the hash.

[0049] Thus, SHA-type hash functions, for example from the SHA-2 family, can be used to generate the dependent encoding from the eigencharacteristic(s).

[0050] Preferably, to combine the dependent encoding operation with the elementary cryptographic operation, the terms of a truth table corresponding to the elementary operation are substituted by means of the generated substitution table, so as to form a merged table corresponding to the merged operation, or a mathematical operation is performed between a matrix corresponding to the elementary operation and the generated dependent encoding matrix, so as to form a merged matrix corresponding to the merged operation.

[0051] The invention also provides a cryptography method, in which at least one piece of data is encrypted or decrypted on a computer peripheral by a cryptographic algorithm and the data is encoded by at least one encoding operation associated with the algorithm, in which the encoding operation is dependent on at least one characteristic specific to the peripheral.

[0052] Preferably, the encoding operation of this cryptographic method has been previously associated with the cryptographic algorithm in accordance with the encoding generation method described above.

[0053] The invention also provides a computer program comprising instructions which, when the program is executed by a computer, cause the latter to implement the steps of the encoding generation method or the cryptography method described above.

[0054] Also provided according to the invention is a computer-readable recording medium comprising instructions which, when executed by a computer, cause the latter to implement the steps of the encoding generation method or the cryptography method described above.

[0055] The invention also provides a computer peripheral comprising computer computing means capable of executing a cryptographic algorithm associated with an encoding operation generated in accordance with the method described above. Brief description of the figures

[0056] The invention will be better understood on reading the following description, given solely by way of example and with reference to the appended drawings in which:

[0057] is a diagram of a system according to one embodiment of the invention;

[0058] is a detailed diagram of a white box according to the embodiment of the;

[0059] is a flowchart according to a first mode of implementation of the invention;

[0060] is a flowchart according to a second mode of implementation of the invention;

[0061] is a flowchart according to a third mode of implementation of the invention including the first and second modes of implementation. Detailed description Definitions

[0062] An "elementary operation" refers to any transformation, for example mathematical, applied to one or more input data resulting in one or more output data of the operation. Within an executable code, an elementary operation can thus be represented by a truth table, accessible and understandable to an informed attacker, indicating, for each possible input of the operation, each corresponding output. In particular, this involves indicating for any series of input bits in an operation what the corresponding series of output bits is.

[0063] The term "encoding" will hereinafter refer to any operation aimed at making incomprehensible, within an executable code, either one or more data, or the transformation associated with an elementary operation. Encoding is therefore itself an operation of transforming input data into output data. The encoding of an elementary operation therefore aims to prevent an attacker from understanding the truth table of the elementary operation. Such encoding can therefore consist of replacing the output data of the truth table with other data via a substitution table, unrecorded and random, indicating the substitutions to be made. It can also be a mathematical operation between a vector corresponding to the output data of the initial truth table and a random matrix, called an encoding matrix, again unrecorded.In all cases, the initial truth table is no longer accessible since it is replaced by the "encoded", "merged" or "obfuscated" truth table, corresponding to the table resulting from both the elementary operation and the associated encoding operation. The encoded elementary operation and the encoding are therefore combined with each other in such a way that they can no longer be distinguished from each other when reading the executable code.

[0064] For simplicity, although the encoding operation itself is not distinguishable from the data or the operation with which it is associated, and although it may have been merged with other successive operations, the theoretical position of the encoding operation in a succession of steps may be referred to as "encoding" in the following. The result of an encoding operation may also be referred to as "encoding".

[0065] It should be noted that every encoding necessarily corresponds to an inverse encoding, or decoding. This is the operation associated with the inverse transformation of the encoding, allowing the encoded data or operation to be recovered when it is applied subsequently. In the following, we can refer to decoding indifferently by the term encoding or inverse encoding.

[0066] During a succession of elementary operations, particularly in an encryption or decryption algorithm, an encoded operation is followed by another operation merged with the inverse encoding. In this way, the elementary operations follow one another as planned in the algorithm without the encodings disrupting them. In the executable code, an attacker can identify an obfuscated table corresponding to an elementary operation and a first encoding, the two operations being merged. Then, he can identify the next obfuscated table, corresponding to the inverse encoding, a new elementary operation and a second encoding, the three operations also being merged. However, and this is the interest of encodings, the attacker cannot identify the elementary operations performed since they are merged with the encodings. He therefore cannot recover the encryption key and the encrypted data.

[0067] A distinction will be made between encryption / decryption on the one hand, and encoding on the other. Encryption or decryption corresponds to a succession of operations carried out using a cryptographic algorithm and a key. Encoding consists of encoding one of these operations or the output data of these operations. Thus, by "cryptographic algorithm", we will designate an encryption or decryption algorithm based on a known type of algorithm, for example "DES" or "AES", using a specific key, and we will distinguish it from the encoding operations which are merged into it.

[0068] Finally, by "peripheral" we mean any terminal comprising means for implementing the method described. In the following, this will in particular refer to any communication terminal equipped with computer computing means, such as a smartphone. Method of implementation

[0069] In the illustrated embodiment, the invention is implemented within a smartphone 1. The latter includes, in software form, a final application whose executable code 2 is schematically illustrated. This application receives encrypted data as input, such as data sent by a banking server 9 located remotely, and allows a payment to be generated by smartphone as output. It could be a completely different type of application and a completely different type of data. In all cases, it is in the form of a code 2 executable via the smartphone 1, code 2 which can be schematically divided into two parts.

[0070] Thus, part 3 comes directly from the source code developed by the developer, or development company, in charge of application 2. It is not specific to the invention but it is the heart of application 2 in the sense that it receives the decrypted data as input and implements the role assigned to the application, here a payment in accordance with methods which are not specific to the invention and will not be described.

[0071] Part 4 of code 2 includes a cryptographic algorithm of the "AES" type (for "AdvancedEncryptionStandard") operating with a private key and encodings internal to the algorithm which will be described in detail below. This set of operations forms a decryption process 43, which makes it possible to decrypt the data received from the server 9 before communicating them to part 3 which will use them. This portion 4 would also make it possible to encrypt data to be sent to the server, we would then speak of encryption. Part 4 forms a "white box". Indeed, an attacker with the smartphone 1 can read the entire code of the application 2, manipulate it, execute it in a fine-grained manner, to try to identify in this part 4 the encrypted data, and / or the elementary operations forming the encryption or decryption algorithm 42 to deduce in particular the key used. It can also try to export this white box 4 to another device.

[0072] This white box 4 also includes within it two encodings 41 and 42, distinct from the encodings internal to the algorithm 43 which will be described below. These encodings 41 and 42 correspond to so-called “external” encodings 92 and 31. Encoding 42 makes it possible to encode the data at the output of the decryption operations of algorithm 43. Thus, although the data are decrypted by algorithm 43, they do not circulate “in clear” between the white box 4 and the core 3. The core 3 of the application includes at its input an encoding 31 which is the inverse encoding of encoding 42, making it possible to decode the data received from the white box 4. This inverse encoding 31 is merged with the first operation programmed by the core 3 so that this encoding 31 is not comprehensible. Encoding 31 is considered to be “external” because it is outside the white box.However, it can only decode data encoded via encoding 42 of the white box, and vice versa. Similarly, encoding 41 at the input of white box 4 is the inverse encoding of encoding 92 placed at the output of algorithm 91 within server 9. Thus, the data output from server 9 are both encrypted and encoded, before being decoded by encoding 41 and then decrypted by algorithm 43. It should be noted that encoding 92 is the only encoding associated with algorithm 91. In particular, this algorithm 91 does not include internal encodings, associated with elementary operations.

[0073] Part 4, encompassing algorithm 43 and internal encodings 41 and 42, does not come directly from the developer of application 2. Indeed, it was developed by another company independently of part 3, and was acquired by the developer of application 2 to be implemented in the form of software libraries. Thus, to control this independent white box 4, calls to an API (for "ApplicationProgrammingInterface") provided by the vendor of white box 4 are provided in the code of part 3, the API allowing for example to initialize the algorithm, to encrypt or decrypt data using this algorithm 43. The developer therefore used the API to program the calls to white box 4 allowing to obtain the decrypted data or on the contrary to provide white box 4 with data to be encrypted.

[0074] Finally, remotely from the smartphone, the banking server 9 also includes in software form an “AES” algorithm and an associated private key. The algorithm makes it possible to encrypt data using the key before communicating it to the smartphone 1. All of these encryption operations form the encryption algorithm 91. It can also make it possible to decrypt received data. However, and unlike algorithm 43, this algorithm 91 does not include internal encodings.

[0075] We will now detail the operations of the cryptographic algorithm 43 placed in the white box 4 and executed within the smartphone 1, with reference to the. We will not describe to what extent and at what times the private key is changed, nor how it is communicated to the server 9, these elements not being specific to the invention.

[0076] By combining an AES type algorithm and a private key, we obtain the cryptographic algorithm 43 which is used in the illustrated embodiment to decrypt data encrypted by the algorithm 91. It is therefore formed from a succession of elementary operations resulting from the combination between the AES algorithm as it is known and the chosen or determined private key. These operations are encoded, that is to say that each operation is associated with an encoding.

[0077] The encodings 432 and 435 do not depend on the characteristics of the smartphone 1; they are generated when the application 2 is installed on the smartphone independently of the latter, or even before its installation. The encodings 41 and 42 also do not depend on the smartphone 1. However, they are chosen so as to correspond to the inverses of the respective external encodings 92 and 31, or vice versa.

[0078] These encodings 432, 435, 41, 42, 92 and 31 are therefore generated in a conventional manner.

[0079] On the other hand, the encoding 433, generated upon installation of the application 2 on the smartphone 1, depends directly on the smartphone 1, while the encoding 434 is only generated each time the algorithm 43 is executed and also depends on the smartphone 1, as described below.

[0080] On the, the elementary operation 431 is encoded by the encoding 432. This encoding 342 is conventional: it is the application of a randomly chosen substitution table. Thus, the substitutions made depend on nothing but chance. Then a new encoding is applied, the encoding 433. This encoding is of a different type: it was not chosen at random. On the contrary, the substitution table of this encoding 433 was decided at the time of installation of the application 2 on the smartphone 1 and was carried out by means of characteristics of the smartphone 1, according to a method which will be described below. In other words, this encoding 433 depends directly on the smartphone 1 on which the application 2 is intended to be used.

[0081] Operation 431, encoding 432 and encoding 433 are merged so that they can no longer be distinguished from each other, and the corresponding truth table is definitively implemented in algorithm 43 as soon as application 2 is installed on smartphone 1. From then on, the initial elementary operation 431 can no longer be identified as such by an attacker. The next elementary operation of algorithm 43 is operation 436. It is merged with encoding 435 which is the inverse encoding of encoding 432. These two operations must also be merged with encoding 434 which is the inverse encoding of encoding 433. By construction, this inverse encoding 434 is necessarily also dependent on smartphone 1. However, unlike all the previous encodings, encoding 434 is not implemented in application 2, neither before nor after its installation. Indeed, it is generated only when these operations are executed. Encoding generation methods

[0082] We will now describe with reference to an encoding generation method 10 for generating the dependent encoding 433. It is implemented as part of the installation of the application 2 within the smartphone 1.

[0083] It should be noted that the elementary operations with which the encodings are combined relate to data forming eight-bit vectors, i.e. 256 possible entries. Of course, this number can vary and be adjusted in order to balance the available resources with the desired security level.

[0084] In step 100, the program 2 requests to obtain characteristics specific to the smartphone 1, namely the MAC number (for “Media Access Control”), the IMEI number (for “International Mobile Equipment Identity”), and the telephone serial number. It also generates a fourth number which is a counter incremented each time the white box 4 is installed on the smartphone 1. These characteristics specific to the smartphone 1 are referred to as “fingerprints”. These calls are made by the code 2 using conventional “APIs” associated with the smartphone. These calls may have been previously authorized by the user when confirming the installation of the application 2. The specific characteristics may have been chosen differently.

[0085] In step 200, the fingerprints obtained are passed to a SHA256 type hash function, the hash function having been chosen so that the output corresponds to a substitution table of the same type as the truth table of conventional encodings. The hash function is also chosen so that a variation of one of the numbers provided generates a different substitution table at the output. It is finally chosen so that this table can only be obtained by hashing the numbers entered and not by other numbers. Thus, this table, which therefore corresponds to an encoding dependent on the smartphone 1, can only have been generated via the smartphone 1. This internal encoding therefore makes it possible to anchor the white box on the smartphone 1. In the case where the hash function is used to establish a dependent encoding matrix, it is necessary for this matrix to be invertible, so as to be able to determine the inverse encoding.

[0086] In step 300, the dependent substitution table, or dependent encoding table, is applied to the truth table resulting from the encoding 432 (itself applied to the initial table 431).

[0087] At step 400, only the final truth table, resulting from the combination between the table associated with the initial operation 431, the encoding 432 and the dependent encoding 433, is stored in the executable code 2.

[0088] It should be noted that, instead of obtaining the characteristics directly from device 1 in step 100, these can be known in advance. In this case, steps 200 to 400 could be carried out outside device 1. It is thus possible to consider implementing the 433 encoding in the algorithm before installing this algorithm in device 1.

[0089] We will now describe with reference to an encoding generation method 20 for generating the dependent encoding 434. This is implemented only at each execution of the algorithm 43 on the peripheral 1, that is to say during the decryption of data.

[0090] In step 500, which is the first step in generating this encoding 434, the program 2 requests to obtain the characteristics specific to the smartphone 1, which are the MAC number (for “Media Access Control”), the IMEI number (for “International Mobile Equipment Identity”), and the serial number of the telephone. It also generates the counter starting at 0. Given that these calls are made on the same smartphone 1 as the one on which the calls of step 100 were made, and that the counter is chosen to start at the same stage, the same fingerprints are obtained.

[0091] In step 600, the same hash function as in step 200 is applied to these numbers. This results in the same substitution table as that determined in step 200 of method 10.

[0092] At step 700, this table is reversed, with input and output replacing each other. This table is therefore the inverse of the table resulting from step 200. Data encoded using one of the tables could therefore be directly decoded using the other.

[0093] At step 800, this reverse table is merged with the encoding 435 and the table associated with the new elementary operation 436, so that a single table corresponding to these three operations is stored in the software implementation.

[0094] Now, the data resulting from operation 431 and encoded by internal encodings 432 and 433 can be decoded by internal decodings 434 and 435 at the same time as elementary operation 436 is taking place.

[0095] Of course, it is possible to reverse the roles of the 433 and 434 encodings by generating the reverse 434 encoding at installation and the 433 encoding only at each decryption operation.

[0096] It should be noted that, in this mode of implementation, only operations 431 and 436 are associated with dependent encodings 433 and 434. The other elementary operations of algorithm 43 are only associated with conventional encodings, such as encodings 432 and 435, which do not depend on the smartphone 1 and are not generated when the decryption is executed, but are implemented upon installation (or even before). However, it may be advantageous to carry out dependent encodings for several of the operations of algorithm 43, in order to further improve the security of the method. On the other hand, it may not be necessary to carry out dependent encodings for all the elementary operations. Indeed, too many dependent encodings generated may cause excessive resource consumption during the decryption operation since each encoding to be generated in this context will have to be the subject of steps 500 to 800.The time spent executing algorithm 43 may also be increased.

[0097] Ultimately, in a variant with several dependent encodings, each operation of algorithm 43 is associated with a conventional encoding, then some of these operations are, in addition, associated with dependent encodings such as encodings 433 and 434. It is the responsibility of the white box developer to identify the number and position of the dependent encodings depending on the desired degree of security and the resources of the planned device.

[0098] Data encryption, decryption, encoding and decoding

[0099] We will now describe a method 30 summarizing the data communication chain between the server 9 and the core 3 of the application 2 by means in particular of the methods 10 and 20.

[0100] Step 40 is the initialization of the communication channel. The white boxes 4 and 91, respectively within the smartphone 1 and the server 9, are installed when the application 2 is installed. The initial elementary operations of the algorithm 43, as well as the algorithm 91, are generated so that the algorithm 43 can decrypt data encrypted by the algorithm 91, and vice versa. In particular, in the context of the “AES” type algorithm, the private key is the same for the algorithms 43 and 91. The algorithms differ, however, in that the algorithm 91, placed on the server, does not include internal encodings, because the server is considered a secure environment.

[0101] Steps 100 to 400 of the method 10 are then implemented. In particular, the dependent encoding 433 is generated at this time in the application 2 by means of the characteristics of the smartphone 1. This is also the case for the non-dependent encodings 432 and 435.

[0102] At step 50, core 3 of application 2 requests the sending of secret data from the remote server 9. This involves, in particular, validation of banking data to validate a payment.

[0103] In step 60, the server 9 encrypts the requested data using algorithm 91.

[0104] In step 70, the encrypted data is encoded by the external encoding 92 located on the server 9.

[0105] At step 80, they are sent to smartphone 1, in particular to application 2, and in particular to white box 4.

[0106] At step 90, encoding 41 at the white box input, which is the inverse of encoding 92, decodes the data. As a reminder, since it is merged with the following operation and encoding, this decoding is not understandable to an attacker.

[0107] Steps 500 to 800 described above, of method 20, are then carried out at the heart of the data decryption algorithm 43. In particular, the dependent encoding 434, inverse of the encoding 433, is generated only at the time of this decryption.

[0108] In step 810, once the 433 encoding is generated, the data is decrypted and decoded.

[0109] At step 820, the still decrypted data is encoded again, this time using encoding 42.

[0110] In step 830, the decrypted and encoded data are communicated to the core 3 of the application.

[0111] At step 840, the external encoding 31, inverse of the encoding 42, decodes the data. Here again, its fusion with the subsequent operations of the core 3 does not allow it to be identified.

[0112] It should be noted that although the process illustrated is a decryption process, encodings work in the same way for an encryption process. Encodings are then associated with elementary encryption operations rather than decryption.

[0113] The dependent internal encodings 433 and 434 therefore make it possible to anchor the white box on the smartphone 1. Thus, even if an external encoding, typically the encoding 31, were to leak, i.e. be identified by an attacker, the dependent encodings internal to the white box would provide additional security. Indeed, thanks to these dependent encodings 433 and 434, it is necessary to have the smartphone 1 to execute the algorithm. Indeed, by executing it on a different device, the encoding 434 generated at the time of execution on this new device would not correspond to the encoding 433 dependent on the smartphone 1, and the algorithm 43 as a whole would fail.

[0114] An attacker cannot therefore make the white box work on another device. Furthermore, unlike a signature or an identification token, these dependent encodings cannot be removed by the attacker, because, since they are merged into the elementary steps of the algorithm, they are fully part of the algorithm and any modification would cause the algorithm to fail to execute.

[0115] An attack therefore only becomes feasible using a virtual machine aimed at falsifying the device's fingerprints. However, to do this, it is necessary to know the device very well, to the point that it is preferable to own it, making the creation of a suitable virtual machine obsolete.

[0116] This process of dependent encodings internal to the white box depends on the white box developer and not the developer of the final application. This is in line with the simplified security approach associated with the sale of "turnkey" white boxes to companies developing final applications. In particular, the latter's responsibility regarding the protection of external encodings is mitigated since the dependent encodings internal to the white box provide additional security.

[0117] Furthermore, the generation of a dependent encoding makes it easier to identify a leak. Indeed, since only the execution platform appropriate for the dependent encoding can be used to run the algorithm, it is easier to identify the platform from which the leak originates. Thus, in the case of the illustrated embodiment, if the white box 4 were to leak, it would not operate on any device except on the smartphone 1, which would make it possible to determine that it originated from the smartphone 1.

[0118] The invention is not limited to the embodiments presented and other embodiments will become apparent to those skilled in the art.

[0119] For example, other hash functions are possible. Moreover, the eigencharacteristic is not limited to the examples provided but concerns any characteristic that can be extracted from a device and that is unique to this device. It also concerns any relevant combination of eigencharacteristics allowing to further isolate a device from others.

[0120] Furthermore, the invention makes it particularly relevant to dispense with external encodings, which in the illustrated embodiment are encodings 92 and 31. In this case, encodings 41 and 42 are also removed. This is particularly relevant with regard to external encoding 31, the implementation and protection of which must be ensured by the developer of the final application 2, which contravenes the simplified security principle sold with the white box 4. However, given that the dependent encodings make it possible to anchor the white box on the peripheral as the external encodings aim to do, the latter become superabundant and can be removed. In this case, any attack of the white box code porting type remains delicate given the dependent encodings, and the developer of the final application no longer has to ensure the security of an encoding.On the other hand, in this case, the data circulates in clear, that is to say in a decrypted manner, between the decryption algorithm and the final application.

[0121] It is possible to integrate internal encodings into the algorithm 91 in order to improve its security. In addition, it is possible to integrate, as in the white box 43, dependent encodings into the server algorithm 91, to further improve its security and facilitate the identification of a possible leak of this white box 91. This is, however, generally less essential than for an algorithm operating on a mobile device, where security is more questionable.

[0122] It is possible to integrate dependent encodings into cryptographic algorithms other than the "AES" type algorithm. This is the case, for example, for the "DES" algorithm (for "DataEncryptionStandard"). More generally, each algorithm that can be encoded can be the subject of the dependent encodings of the invention. This is particularly the case for encryption or decryption methods divided into elementary operations that can be encoded.

Claims

Method (10, 20) for generating encoding for a cryptographic algorithm, implemented by computer, characterized in that the following steps are implemented: obtaining (100, 500) at least one characteristic specific to a computer peripheral (1) configured to execute a cryptographic algorithm (43); from the specific characteristic, generation (200, 600) of an encoding operation (433, 434) dependent on the peripheral (1); association (300, 400, 700, 800) of the generated dependent encoding operation with the cryptographic algorithm. Method (10, 20) according to the preceding claim, in which, to associate the dependent encoding operation (433, 434) with the algorithm, the encoding operation (433, 434) is combined with a cryptographic elementary operation (431, 436) of the algorithm so as to form a single merged operation, so that a data item processed by the merged operation is operated in accordance with the cryptographic elementary operation (431, 436) and simultaneously encoded in accordance with the dependent encoding operation (433, 434). Method (10) according to any one of the preceding claims, in which the dependent encoding operation (433) is associated (300, 400, 700, 800) with the algorithm (43) before any cryptographic execution of the algorithm on the peripheral (1), in particular during an installation (40) of the algorithm on the peripheral, the cryptographic execution corresponding in particular to a data encryption or decryption operation. Method (20) according to any one of claims 1 to 2, in which, the algorithm (43) having been installed on the peripheral (1), the steps of obtaining (100) the specific characteristic, of generating (200) the dependent encoding operation (434) and of associating (300, 400) the dependent encoding operation (434) with the algorithm (43) are carried out, during a cryptographic execution (810) of the algorithm on the peripheral, the cryptographic execution corresponding in particular to a data encryption or decryption operation. Method (10, 20) according to claims 3 and 4, wherein the dependent encoding operation (433) associated (10) before any cryptographic execution according to claim 3 being a first dependent encoding operation, the dependent encoding operation (434) generated and associated (20) during the cryptographic execution (810) on the peripheral (1) according to claim 4 being a second dependent encoding operation, this second encoding operation (434) is generated so that data encoded via the first dependent encoding operation (433) is decoded via the second dependent encoding operation (434). Method (10, 20) according to the preceding claim and claim 2, in which the cryptographic elementary operation (431) being a first cryptographic elementary operation and the merged operation being a first merged operation, the algorithm (43) also comprising a second cryptographic elementary operation (436) directly following the first cryptographic elementary operation, the following steps are implemented:Combination (10), before any cryptographic execution of the algorithm on the peripheral, of the first dependent encoding operation (433) with the first cryptographic elementary operation (431) so as to form the first merged operation;Combining (20), during the cryptographic execution of the algorithm on the peripheral, the second dependent encoding operation (434) with the second elementary operation (436), so as to form a second merged operation, so that, when the data encoded and operated by the first merged operation is processed by the second merged operation, it is decoded in accordance with the second dependent encoding operation (434) and simultaneously operated in accordance with the second cryptographic elementary operation (436).; Method (10, 20) according to the preceding claim, in which the following steps are further implemented: prior to the steps of claim 1, generation (40) of a third encoding operation (432), not dependent on the device (1), and of a fourth encoding operation (435), not dependent on the device and generated so that data encoded via the third encoding operation (432) is decoded via the fourth encoding operation (435), before any cryptographic execution of the algorithm (43), combination of the third encoding operation (432) with the first merged operation, so as to form a new first merged operation making it possible to simultaneously encode the data in accordance with the first encoding operation (433) and the third encoding operation (432) and to operate the data in accordance with the first elementary operation (431);during the cryptographic execution (810), combining the fourth encoding operation (435) with the second merged operation, so as to form a new second merged operation allowing simultaneously to decode the data in accordance with the second encoding operation (434) and the fourth encoding operation (435) and to operate the data in accordance with the second elementary operation (436).; Method (10, 20) for generating encoding according to one of claims 6 to 7, in which the first (431) and the second (436) elementary cryptographic operation forming a pair of encoded operations, the steps of generating and combining encodings are repeated for at least one other pair of encoded operations of the algorithm (43), preferably for several pairs. Method (10, 20) according to any one of the preceding claims, in which the cryptographic algorithm is of the “AES” type, for “AdvancedEncryptionStandard” or “DES” for “DataEncryptionStandard”. Method (10, 20) according to any one of the preceding claims, wherein the characteristic specific to the device (1) obtained is one of the following characteristics or a combination of at least some of the following characteristics:- the MAC (for "Media Access Control") number of the device;- the IMEI (for "International Mobile Equipment Identity") number of the device;- the serial number of the telephone;- a counter of a number of installations of a cryptographic algorithm within the device. Method (10, 20) according to any one of the preceding claims, wherein the generation of the dependent encoding operation (433, 434) of the device (1) comprises a step of hashing (200, 600) the characteristic(s) specific to the device (1), so as to generate a device-dependent encoding table or a device-dependent encoding matrix, at least one of the elements of the table or respectively of the matrix being derived from the hashing. Method (10, 20) according to at least the preceding claim and claim 2, wherein, to combine the dependent encoding operation (433, 434) with the elementary cryptographic operation (431, 436), the terms of a truth table corresponding to the elementary operation are substituted by means of the generated substitution table, so as to form a merged table corresponding to the merged operation, or a mathematical operation is carried out between a matrix corresponding to the elementary operation and the generated dependent encoding matrix, so as to form a merged matrix corresponding to the merged operation. Cryptography method (30), in which at least one data item is encrypted or decrypted on a computer peripheral (1) by a cryptographic algorithm (43) and the data item is encoded by at least one encoding operation (433, 434) associated with the algorithm, characterized in that the encoding operation (433, 434) is dependent on at least one characteristic specific to the peripheral (1). Method (30) according to the preceding claim, in which the encoding operation (433, 434) has been previously associated with the cryptographic algorithm (43) in accordance with any one of claims 1 to 12. Computer program (2) comprising instructions which, when the program is executed by a computer, cause the latter to implement the steps of the method according to any one of claims 1 to 14. A computer-readable recording medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method according to any one of claims 1 to 14. Computer peripheral (1) comprising computer computing means capable of executing a cryptographic algorithm associated with an encoding operation generated in accordance with any one of claims 1 to 12.

Images