FR3140960A1 - White box encoding - Google Patents

Abstract

The invention relates to a computer-implemented encoding generation method for a cryptographic algorithm. The following steps are implemented: - obtaining at least one characteristic specific to a computer device (1) configured to execute a cryptographic algorithm (43); - from the specific characteristic, generation of an encoding operation (433, 434) dependent on the device (1); - association of the dependent encoding operation (433, 434) generated with the cryptographic algorithm (43). Figure for abstract: figure 2

Description

White box encoding

The invention relates to white-box cryptography, and more particularly to encoding operations associated with an encryption algorithm as part of a white-box attack model.

White box cryptography is a subject of study based on the postulate that an attacker, who seeks to identify secret, encrypted data that can be decrypted using an encryption algorithm, has full access to the cryptography platform. execution of the algorithm and 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 as desired 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 “ Advanced Encryption Standard ”). The attacker has full powers over the smartphone and over the algorithm, and can thus seek to read the corresponding binary code, modify it, execute it in a specific way, with the ultimate objective of knowing the type of algorithm used, to identify the encryption key, to decrypt the secret data, and/or to modify this data.

To prevent this attacker from accessing the secret data and 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 algorithm (or decryption). Indeed, an elementary operation, resulting from the combination between a type of known algorithm and a specific encryption key, is generally implemented in the form of a truth table indicating the possible results of the operation according to the data d 'entrance. An encoding operation therefore consists of applying a random transformation to an elementary operation so as to make this operation unreadable. To encode an operation, we can carry out a substitution of the elements of the truth table, by combining the initial table with a random substitution table, so as 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 the 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. Furthermore, each elementary operation succeeding 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 algorithm initially planned is not modified by successive encodings. In all cases, only the truth tables resulting from these encoding operations merged with the elementary operations are stored in the software memory implementing the algorithm, that is to say the so-called “ obfuscated ” or “ merged” tables. ". In this way, the attacker, having access only to the obfuscated tables, cannot identify the elementary operation associated with each table and therefore cannot determine the encryption key used and decrypt the secret data.

These encodings, making it possible to encode an encryption (and/or decryption) algorithm 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.

However, this white box generally communicates on the one hand with a server located remotely, and on the other hand with a third-party application located 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 the white box, i.e. the decryption algorithm executed by the smartphone, is used to decrypt the data before this decrypted data is communicated within the same smartphone to a third-party application, called “ final ”, 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 “ Application Programming Interface ”) allowing the algorithm to be controlled and the data to be used. coming out of this algorithm in the final developed application. In this context, the “ internal ” encodings within the white box do not prevent the decrypted data from circulating, in plain text, between the white box and the final application. Likewise, 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. say export the entire white box code to another device to use it there without having to identify the key.

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 data and their use. For example, first 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 expected, but also encoded before being communicated to the smartphone. Then, at the entrance to the white box, the reverse encoding of the external encoding is applied to the first truth table of the decryption algorithm, before the data is processed through the decryption algorithm. the white box and its internal 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 opposite 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. .

Thanks to these external encodings placed outside the white box, even once decrypted, the data does not circulate " in the clear " outside the white box, it remains encoded, therefore protected from manipulation by an attacker who would like to intercept them. Furthermore, the attack consisting of porting the entire white box code to 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 exit. Without the corresponding reverse encodings, which are located remotely (within the server and within the final application), it is not possible to find the data in plain text. Furthermore, when added to the internal encodings, these external encodings combined with white box output and input encodings make it even more difficult to identify the white box encryption key.

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

However, this method comprising internal encodings and external encodings still has at least two drawbacks.

First, as noted above, final applications are developed by third-party companies who acquire white boxes and use an API to control them. These companies must therefore themselves integrate into their application the external encoding corresponding, inversely, to the white box output encoding. They must then themselves ensure the protection of this external encoding (which can be called external decoding) within the final application. They therefore have a responsibility regarding security which is uncomfortable and often forces them to rely on 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 acquiring the white box.

Second, in the event of a white box leak, it remains difficult to identify the source of the leak. In particular, it is of little relevance to embed signatures or identification tokens in the white box, since the attacker will have the possibility of modifying or deleting them.

The invention aims in particular to improve the security of an already encoded white box cryptographic algorithm. Another goal is to help identify the source of a possible leak in the algorithm.

To this end, the subject of the invention is a method of generating encoding for a cryptographic algorithm, implemented by computer, characterized in that the following steps are implemented:

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

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

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

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 we can call dependent encoding, therefore makes it possible to anchor the algorithm on a particular device. Data and encryption security 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 by means of the peripheral, since only this peripheral provides the specific characteristic making it possible to generate the correct decoding. Alternatively, if this dependent encoding aims to encode data, the latter can also only be decoded using the device.

Furthermore, since the 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 therefore to execute the algorithm. Furthermore, if the attacker modifies the dependent encoding to make the source of the leak untraceable, the algorithm no longer works, making any attack useless.

Advantageously, to associate the dependent encoding operation with the algorithm, the encoding operation is combined with an elementary cryptographic 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 elementary cryptographic operation and simultaneously encoded in accordance with the dependent encoding operation.

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 encoding are thus “ hidden ”.

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

So the algorithm includes this dependent encoding even before it is used on the device. The dependent encoding therefore remains identical here even if the algorithm is implemented on a device other than the one whose encoding is dependent. It is notably possible that the algorithm is associated with this encoding before being implemented on the device, if the device and its specific characteristics are known in advance.

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, during a cryptographic execution of the algorithm on the device, the cryptographic execution corresponding in particular to a data encryption or decryption operation.

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

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 device 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.

In other words, the two previous operations are carried out 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, dependent encoding will encode the data according to the device it is dependent on, then 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 the white box to be anchored on a particular device.

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

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

- 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;

- combination, during the cryptographic execution of the algorithm on the device, of 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.

Thus, the dependent encoding and decoding operations cannot be distinguished, by an attacker having 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.

Advantageously, the following steps are also implemented:

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

- 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 operating the data in accordance with the first elementary operation;

- 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 decoding the data in accordance with the second encoding operation and the fourth operation encoding and operating the data in accordance with the second elementary operation.

Thus, we add to the device-dependent encoding (and decoding) operations non-dependent, that is to say random, conventional encoding (and decoding) operations, and we also merge them respectively with the first and second elementary operations of the algorithm. We therefore obtain two merged operations, one corresponding to a first elementary operation, to the dependent encoding and to a non-dependent encoding (which we call the third encoding operation), the other corresponding to the second elementary operation, dependent decoding and non-dependent decoding (called fourth encoding operation), these operations cannot be distinguished from one another within the merged operations. The addition of non-dependent encoding and decoding makes it possible to hide the second elementary operation. Indeed, given that 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 for an attacker with executable code. The merger between the non-dependent decoding and the second elementary operation therefore makes it possible to mask the latter before generating the dependent decoding.

Here again, as in the entire description, unless otherwise evident, the terms of encoding and decoding could be reversed.

Preferably, the first and the second 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, preferably for several pairs.

Thus, the method concerns more than two elementary cryptographic operations of the algorithm. Potentially, each elementary operation of the algorithm can be concerned by an association with a dependent encoding, but the generation of a dependent encoding or decoding at the time of execution of the algorithm requires resources and time which can 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.

Advantageously, the cryptographic algorithm is of the “ AES ” type, for “ Advanced Encryption Standard ” or “ DES ” for “ Data Encryption Standard ”.

These algorithms, associated with private keys, include operations that are easily separable from each other and which will form elementary cryptographic operations. However, 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 here dependent encodings.

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

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

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

- the serial number of the phone;

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

Thus, generating the dependent encoding using another device results in a different encoding, or a non-corresponding decoding, since the inherent characteristic is different.

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 coming from the hash.

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

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 table fused corresponding to the fused 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 fused matrix corresponding to the fused operation.

According to the invention, a cryptography method is also provided, 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 device.

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

According to the invention, there is also provided a computer program comprising instructions which, when the program is executed by a computer, lead it to implement the steps of the encoding generation method or the cryptography method described above. .

According to the invention, there is also provided a computer-readable recording medium comprising instructions which, when executed by a computer, lead it to implement the steps of the encoding generation method or of the encoding method. cryptography described above.

According to the invention, there is also provided a computer peripheral comprising computer calculation 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

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

there is a diagram of a system according to one embodiment of the invention;

there is a detailed diagram of a white box according to the embodiment of the ;

there is a flowchart according to a first mode of implementation of the invention;

there is a flowchart according to a second mode of implementation of the invention;

there is a flowchart according to a third mode of implementation of the invention including the first and second mode of implementation.

detailed description Definitions

“ Elementary operation ” means 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 for 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 is the corresponding series of output bits.

By “ encoding ”, we will designate in the following 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, unregistered 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 the encoding matrix, again not recorded. In all cases, the initial truth table is then no longer accessible since it is replaced by the “ encoded ”, “ merged ” or even so-called “ 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.

For simplicity, although the encoding operation is itself not distinguishable from the data or from the operation with which it is associated, and although it may have been merged with other successive operations, we can designate in subsequently by “ encoding ” the theoretical position of the encoding operation in a succession of steps. We can also designate “ encoding ” as the result of an encoding operation.

It should be noted that any encoding necessarily corresponds to an inverse encoding, or decoding. This is the operation associated with the inverse transformation of the encoding, making it possible to find the encoded data or operation when it is applied subsequently. In the following, we can designate decoding indifferently by the term encoding or inverse encoding.

During a succession of elementary operations, in particular in an encryption or decryption algorithm, an encoded operation is followed by another operation merged with the reverse encoding. In this way, the elementary operations follow one another as planned in the algorithm without the encodings disturbing them. In the executable code, an attacker can manage to identify an obfuscated table corresponding to an elementary operation and a first encoding, the two operations being merged. Then, it can identify the following 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 carried out since they are merged with the encodings. It cannot therefore find the encryption key and the encrypted data.

We will distinguish 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 output data from these operations. Thus, by “cryptographic algorithm”, we will designate an encryption or decryption algorithm based on a type of known algorithm, for example “DES” or “AES”, using a specific key, and we will distinguish it from encoding operations which are merged there.

Finally, by “peripheral” we mean any terminal comprising means for implementing the method described. In the following, it will concern in particular any communication terminal equipped with computer calculation means, such as a smartphone.

Method of realization

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 transmitted by a bank server 9 located remotely, and allows it to generate a payment 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 presented in the form of code 2 executable via smartphone 1, code 2 which can be schematically divided into two parts.

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 processes which are not specific to the invention and will not be described.

Part 4 of code 2 includes an “ AES ” type cryptographic algorithm (for “ Advanced Encryption Standard ”) 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 the party 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 smartphone 1 can read the entire code of application 2, manipulate it, execute it in a fine manner, to try to identify the encrypted data in this part 4, and/or the elementary operations forming the encryption or decryption algorithm 42 to deduce in particular the key used. He can also try to export this white box 4 to another device.

This white box 4 also includes within it two encodings 41 and 42, distinct from the internal encodings of 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 the algorithm 43. Thus, although the data is decrypted by the algorithm 43, they do not circulate "in the 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 the encoding 42, allowing to decode the data received from the white box 4. This inverse encoding 31 is merged with the first operation programmed by the heart 3 so that this encoding 31 is not understandable. We consider that encoding 31 is “ external ” because it is outside the white box. However, it can only decode data encoded via white box 42 encoding, and vice versa. Similarly, the encoding 41 at the input of the white box 4 is the inverse encoding of the encoding 92 placed at the output of the algorithm 91 within the server 9. Thus, the data output from the server 9 are both encrypted and encoded, before being decoded by encoding 41 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.

Part 4, including algorithm 43 and internal encodings 41 and 42, is not directly from the developer of application 2. In fact, it was developed by another company independently in 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 “ Application Programming Interface ”) provided by the seller of the 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 by means of this algorithm 43. The developer therefore used the API to program calls to the white box 4 making it possible to obtain the decrypted data or on the contrary to provide the white box 4 of the data to be encrypted.

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. On the other hand and unlike algorithm 43, this algorithm 91 does not include internal encodings.

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 when the private key is changed, nor how it is communicated to server 9, these elements not being specific to the invention.

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 algorithm 91. It is therefore formed of 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.

Encodings 432 and 435 do not depend on the characteristics of smartphone 1, they are generated when 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. On the other hand, they are chosen so as to correspond to the inverses of the respective external encodings 92 and 31, or vice versa.

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

On the other hand, encoding 433, generated when installing application 2 on smartphone 1, depends directly on smartphone 1, while encoding 434 is only generated each time algorithm 43 and also depends on the smartphone 1, as described below.

On the , the elementary operation 431 is encoded by the encoding 432. This encoding 342 is conventional: it is the application of a substitution table chosen randomly. Thus, the substitutions made depend on nothing except chance. Then a new encoding is applied, 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 produced by means of characteristics of the smartphone 1, according to a process 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.

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 from application 2 installed on the smartphone 1. From then on, the initial elementary operation 431 can no longer be identified as is 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 inverse of encoding 433. By construction, this inverse encoding 434 is also necessarily dependent on the smartphone 1. However, unlike all of the previous encodings, encoding 434 is not implemented in application 2, nor before nor after its installation. In fact, it is generated only when these operations are executed.

Encoding generation methods

We will now describe with reference to the 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.

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

In step 100, program 2 requests to obtain characteristics specific to 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 phone. It also generates a fourth number which is a counter incremented each time the white box 4 is installed on the smartphone 1. We designate these characteristics specific to the smartphone 1 by the term “ fingerprints ”. These calls are made by code 2 using conventional “APIs” associated with the smartphone. These calls may have been previously authorized by the user when confirming the installation of application 2. The specific characteristics may have been chosen differently.

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 as output. Finally, it is 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 function of hashing would be used to establish a dependent encoding matrix, it is necessary that this matrix be invertible, so as to be able to determine the inverse encoding.

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

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.

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

We will now describe with reference to the an encoding generation method 20 for generating the dependent encoding 434. This is implemented only each time the algorithm 43 is executed on the device 1, that is to say during data decryption.

At step 500, which is the first step in generating this encoding 434, 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 phone. It also generates the counter starting at 0. Since these calls are made on the same smartphone 1 as the one on which the calls in step 100 were made, and the counter is chosen to start at the same point, the same fingerprints are obtained.

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

At step 700, this table is inverted, 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 directly be decoded using the other.

In step 800, this inverse 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.

From now on, 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 takes place.

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.

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, not depending on the smartphone 1 and not being generated at the execution of the decryption, but implemented from the start. 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 process. On the other hand, it may not be necessary to carry out dependent encodings for all elementary operations. Indeed, too large a number of generation of dependent encodings risks causing excessive resource consumption during the decryption operation since each encoding to be generated in this context will have to undergo steps 500 to 800. Time passed through the execution of algorithm 43 also risks being lengthened.

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 it is the responsibility of the white box developer to identify the number and place of dependent encodings according to the desired degree of security and the resources of the planned device.

Encryption, decryption, encoding and decoding of data

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 methods 10 and 20.

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

Steps 100 to 400 of 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.

At step 50, core 3 of application 2 requires the sending of secret data from server 9 located remotely. This concerns in particular validation of banking data to validate a payment.

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

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

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

In step 90, encoding 41 at the entrance to the white box, which corresponds to the opposite of encoding 92, decodes the data. As a reminder, given that it is merged into the following operation and encoding, this decoding is not understandable to an attacker.

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

In step 810, once the encoding 433 has been generated, the data is decrypted and decoded.

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

At step 830, the decrypted and encoded data are communicated to core 3 of the application.

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

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

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 encoding 31, were to leak, that is to say to be identified by a 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 smartphone 1 to execute the algorithm. Indeed, by running it on a different device, the 434 encoding generated at run time on this new device would not correspond to the 433 encoding dependent on smartphone 1, and algorithm 43 as a whole would fail.

An attacker cannot therefore operate the white box on another device. Furthermore, unlike a signature or identification token, these dependent encodings cannot be removed by the attacker, because, given that they are merged in elementary steps of the algorithm, they are fully part of the algorithm and any modification would cause the execution of the algorithm to fail.

An attack therefore only becomes possible using a virtual machine aimed at falsely fingerprinting the device. However, to do this it is necessary to know the device very well, to the point that it is better to own it, making the creation of a suitable virtual machine obsolete.

This process of dependent encodings internal to the white box depends on the developer of the white box and not the developer of the final application. This is consistent with the spirit of simplified security associated with the sale of “turnkey” white boxes to companies developing end-use applications. In particular, the latter's responsibility for protecting external encodings is mitigated since dependent encodings internal to the white box provide additional security.

Additionally, generating a dependent encoding makes it easier to identify a leak. Indeed, given that only the execution platform appropriate to the dependent encoding can make the algorithm work, it is easier to identify the platform from which the leak comes. Thus, in the case of the illustrated embodiment, if the white box 4 were to leak, it would not work on any device except on the smartphone 1, which would make it possible to determine that it came from the smartphone 1.

The invention is not limited to the embodiments presented and other embodiments will be clear to those skilled in the art.

For example, other hash functions are possible. In addition, the specific characteristic is not limited to the examples provided but concerns any characteristic that can be extracted from a device and which is specific to this device. It is also any relevant combination of specific characteristics allowing a device to be further isolated from others.

Furthermore, the invention makes it particularly relevant to do without 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 dependent encodings allow the white box to be anchored to the device as external encodings aim to do, the latter become overabundant and can be removed. In this case, any white box code porting attack 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 the clear, that is to say in a decrypted manner, between the decryption algorithm and the final application.

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

It is possible to integrate dependent encodings into cryptographic algorithms other than the “AES” type algorithm. This is for example the case for the “DES” algorithm (for “ Data Encryption Standard ”). More generally, each algorithm that can be encoded can be the subject of encodings dependent on the invention. This is particularly the case for encryption or decryption processes divided into elementary operations that can be encoded.

Claims (17)

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 own characteristic, generation (200, 600) of an encoding operation (433, 434) dependent on the device (1);
• association (300, 400, 700, 800) of the dependent encoding operation generated 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 an elementary operation cryptographic (431, 436) of the algorithm so as to form a single merged operation, such that data processed by the merged operation is operated in accordance with the elementary cryptographic 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 device (1), in particular during an installation (40) of the algorithm on the device, 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 generation (200) of the dependent encoding operation (434) and the association (300, 400) of the dependent encoding operation (434) to the algorithm (43), during an execution ( 810) cryptographic of the algorithm on the device, the cryptographic execution corresponding in particular to a data encryption or decryption operation. Method (10, 20) according to claims 3 and 4, in which the dependent encoding operation (433) associated (10) before any cryptographic execution according to claim 3 being a first dependent encoding operation, the operation d dependent encoding (434) generated and associated (20) during 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 elementary cryptographic operation (431) being a first elementary cryptographic operation and the merged operation being a first merged operation, the algorithm (43) also comprising a second elementary cryptographic operation (436) directly succeeding the first elementary cryptographic operation, the following steps are implemented:

• Combination (10), before any cryptographic execution of the algorithm on the device, of the first dependent encoding operation (433) with the first elementary cryptographic operation (431) so as to form the first merged operation;
• Combination (20), during the cryptographic execution of the algorithm on the device, of 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 elementary cryptographic 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 peripheral (1), and of a fourth encoding operation (435), not dependent on the peripheral 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 simultaneously allowing the data to be encoded in accordance with the first operation encoding (433) and the third encoding operation (432) and to operate the data in accordance with the first elementary operation (431);
• during cryptographic execution (810), combination of the fourth encoding operation (435) with the second merged operation, so as to form a new second merged operation allowing simultaneously decoding 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 generation and combination of encodings 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 “ Advanced Encryption Standard ” or “ DES ” for “ Data Encryption Standard ”. Method (10, 20) according to any one of the preceding claims, in which the characteristic specific to the peripheral (1) obtained is one of the following characteristics or a combination of at least some of the following characteristics:
- the MAC number (for “ Media Access Control ”) of the device;
- the IMEI number (for “ International Mobile Equipment Identity ”) of the device;
- the serial number of the phone;
- a counter of the number of installations of a cryptographic algorithm within the device. Method (10, 20) according to any one of the preceding claims, in which the generation of the dependent encoding operation (433, 434) of the peripheral (1) comprises a step of hashing (200, 600) of the or characteristics 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 coming from the hash. Method (10, 20) according to at least the preceding claim and claim 2, in which, to combine the dependent encoding operation (433, 434) with the elementary cryptographic operation (431, 436), the terms are substituted of a truth table corresponding to the elementary operation 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 piece of data is encrypted or decrypted on a computer peripheral (1) by a cryptographic algorithm (43) and the data 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 device (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, lead it to implement the steps of the method according to any one of claims 1 to 14. Computer-readable recording medium comprising instructions which, when executed by a computer, cause it to implement the steps of the method according to any one of claims 1 to 14. Computer peripheral (1) comprising computer calculation means capable of executing a cryptographic algorithm associated with an encoding operation generated in accordance with any one of claims 1 to 12.