WO2024083849A1 - Encodage en boite blanche - Google Patents

Encodage en boite blanche Download PDF

Info

Publication number
WO2024083849A1
WO2024083849A1 PCT/EP2023/078864 EP2023078864W WO2024083849A1 WO 2024083849 A1 WO2024083849 A1 WO 2024083849A1 EP 2023078864 W EP2023078864 W EP 2023078864W WO 2024083849 A1 WO2024083849 A1 WO 2024083849A1
Authority
WO
WIPO (PCT)
Prior art keywords
encoding
algorithm
dependent
cryptographic
elementary
Prior art date
Application number
PCT/EP2023/078864
Other languages
English (en)
Inventor
Vincent Giraud
Original Assignee
Banks And Acquirers International Holding
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Banks And Acquirers International Holding filed Critical Banks And Acquirers International Holding
Publication of WO2024083849A1 publication Critical patent/WO2024083849A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/16—Obfuscation or hiding, e.g. involving white box

Definitions

  • 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.
  • a method is known in the state of the art consisting of encoding elementary operations of the encryption algorithm (or decryption).
  • 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.
  • 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.
  • 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.
  • 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.
  • a server encrypt data and communicate the encrypted data to the smartphone
  • the white box i.e. the decryption algorithm executed by the smartphone
  • the final 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.
  • the final applications are developed by third-party companies, independently of the white boxes.
  • 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.
  • 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.
  • this second encoding is therefore part of the white box.
  • 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.
  • 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. .
  • 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.
  • 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:
  • 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.
  • 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.
  • this dependent encoding aims to encode data, the latter can also only be decoded using the device.
  • 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.
  • 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.
  • 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 ”.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • the method concerns more than two elementary cryptographic operations of the algorithm.
  • 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.
  • the cryptographic algorithm is of the “ AES ” type, for “ Advanced Encryption Standard ” or “ DES ” for “ Data Encryption Standard ”.
  • the device-specific characteristic obtained is one of the following characteristics or a combination of at least some of the following characteristics:
  • 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.
  • SHA type hash functions for example from the SHA-2 family, can be used to generate dependent encoding from the specific characteristic(s).
  • 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.
  • 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 device.
  • the encoding operation of this cryptography method has been previously associated with the cryptographic algorithm in accordance with the encoding generation method described above.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Encoding 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.
  • 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.
  • 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.
  • 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.
  • decoding indifferently by the term encoding or inverse encoding.
  • an encoded operation is followed by another operation merged with the reverse encoding.
  • the elementary operations follow one another as planned in the algorithm without the encodings disturbing them.
  • 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.
  • 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.
  • 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.
  • encryption 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.
  • peripheral we mean any terminal comprising means for implementing the method described.
  • any communication terminal equipped with computer calculation means such as a smartphone.
  • 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.
  • 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.
  • 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.
  • 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.
  • the data output from the server 9 are both encrypted and encoded, before being decoded by encoding 41 then decrypted by algorithm 43.
  • 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” are provided in the code of part 3). ”) provided by the seller of the white box 4, 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 the white box 4 making it possible to obtain the decrypted data or, on the contrary, to provide the white box 4 with data to be encrypted.
  • an API for “ Application Programming Interface” are provided in the code of part 3).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • MAC number for “ Media Access Control ”
  • IMEI number for “ International Mobile Equipment Identity ”
  • 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.
  • fingerprints a counter incremented each time the white box 4 is installed on the smartphone 1.
  • step 200 the fingerprints obtained are passed to a hash function of type SHA256, 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.
  • this table can only be obtained by hashing the numbers entered and not by other numbers.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Step 40 is the initialization of the communication channel.
  • White boxes 4 and 91 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.
  • 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.
  • 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.
  • 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.
  • step 60 server 9 encrypts the requested data using algorithm 91.
  • step 70 the encrypted data is encoded by external encoding 92 located on server 9.
  • step 80 they are sent to smartphone 1, in particular to application 2, and in particular to white box 4.
  • 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.
  • the dependent encoding 434, inverse of the encoding 433, is generated only at the time of this decryption.
  • step 810 once the encoding 433 has been generated, the data is decrypted and decoded.
  • step 820 the data still decrypted is encoded again, this time using encoding 42.
  • the decrypted and encoded data are communicated to core 3 of the application.
  • step 840 external encoding 31, reverse of encoding 42, decodes the data.
  • its fusion with the subsequent operations of core 3 does not allow it to be identified.
  • the dependent internal encodings 433 and 434 therefore make it possible to anchor the white box on the smartphone 1.
  • an external encoding typically encoding 31
  • the dependent encodings internal to the white box would provide additional security.
  • smartphone 1 it is necessary to have smartphone 1 to execute the algorithm.
  • 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.
  • 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.
  • 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 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.
  • the invention makes it particularly relevant to do without external encodings, which in the illustrated embodiment are encodings 92 and 31.
  • 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.
  • 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.
  • 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.
  • the data circulates in the clear, that is to say in a decrypted manner, between the decryption algorithm and the final application.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

L'invention concerne un procédé de génération d'encodage pour algorithme cryptographique, mis en œuvre par ordinateur. On y met en œuvre les étapes suivantes : - obtention d'au moins une caractéristique propre à un périphérique informatique (1) configuré pour exécuter un algorithme cryptographique (43); - à partir de la caractéristique propre, génération d'une opération d'encodage (433, 434) dépendante du périphérique (1); - association de l'opération d'encodage dépendante (433, 434) générée à l'algorithme cryptographique (43).

Description

Encodage en boite blanche
L’invention concerne la cryptographie en boite blanche, et plus particulièrement les opérations d’encodage associées à un algorithme de chiffrement dans le cadre d’un modèle d’attaque en boite blanche.
La cryptographie en boite blanche est un sujet d’étude reposant sur le postulat qu’un attaquant, qui cherche à identifier des données secrètes, chiffrées, pouvant être déchiffrées au moyen d’un algorithme de chiffrement, a un accès complet à plateforme d’exécution de l’algorithme et à l’implémentation logicielle de cet algorithme dans la plateforme : le code binaire est ainsi entièrement visible, il est modifiable, et l’attaquant peut également agir à souhait sur l’exécution logicielle à travers les divers systèmes de la plateforme tels que la mémoire, les appels aux processeurs, etc. L’exemple le plus classique est celui d’un attaquant ayant accès à un smartphone d’un tiers, dans lequel une application logicielle du smartphone chiffre ou déchiffre des données secrètes au moyen d’une clé de chiffrement et d’un algorithme cryptographique, par exemple du type « AES » (pour « Advanced Encryption Standard »). L’attaquant a les pleins pouvoirs sur le smartphone et sur l’algorithme, et peut ainsi chercher à lire le code binaire correspondant, le modifier, l’exécuter d’une manière spécifique, avec pour objectif à terme, connaissant le type d’algorithme utilisé, d’identifier la clé de chiffrement, de déchiffrer les données secrètes, et/ou de modifier ces données.
Pour empêcher cet attaquant d’accéder aux données secrètes et protéger l’intégrité du chiffrement dans ce contexte de boite blanche, on connaît dans l’état de la technique une méthode consistant à encoder des opérations élémentaires de l’algorithme de chiffrement (ou de déchiffrement). En effet, une opération élémentaire, issu de la combinaison entre un type d’algorithme connu et une clé de chiffrement spécifique, est généralement implémentée sous la forme d’une table de vérité indiquant les résultats possibles de l’opération en fonction des données d’entrée. Une opération d’encodage consiste donc à appliquer une transformation aléatoire à une opération élémentaire de manière à rendre illisible cette opération. Pour encoder une opération, on peut réaliser une substitution des éléments de la table de vérité, en combinant la table initiale avec une table de substitution aléatoire, de manière à obtenir une table « obfusquée » ou « fusionnée ». Alternativement, on peut appliquer à l’opération une transformation linéaire en combinant un vecteur représentant les données de sortie, ou une matrice correspondant à l’opération, à une autre matrice, dite matrice d’encodage, aléatoire elle-aussi. Un encodage peut aussi être une combinaison d’une ou plusieurs substitutions et d’une ou plusieurs matrices d’encodages. D’autres types d’encodage sont possibles. En outre, chaque opération élémentaire succédant à une opération élémentaire encodée est elle-même combinée avec un encodage dit « inverse », ou décodage, correspondant de façon inverse à l’encodage précédent. Il s’agit par exemple de la table de substitution inverse ou de la matrice inverse correspondantes à l’encodage précédent, de manière à ce que l’algorithme prévu initialement ne soit pas modifié par les encodages successifs. Dans tous les cas, on ne stocke dans la mémoire logicielle implémentant l’algorithme que les tables de vérité résultant de ces opérations d’encodage fusionnées avec les opérations élémentaires, c’est-à-dire les tables dites « obfusquées » ou « fusionnées ». De cette manière, l’attaquant, n’ayant accès qu’aux tables obfusquées, ne peut identifier quelle est l’opération élémentaire associée à chaque table et ne peut donc pas déterminer la clé de chiffrement utilisée et déchiffrer les données secrètes.
Ces encodages, permettant d’encoder un algorithme de chiffrement (et/ou de déchiffrement) au sein d’une plateforme d’exécution non sécurisée, par exemple au sein d’un smartphone, sont dit « internes », puisqu’ils permettent de rendre illisible la clé de chiffrement utilisée au sein de la boite blanche formée par l’algorithme implémenté.
Cependant, cette boite blanche communique généralement d’une part avec un serveur situé à distance, et d’autre part avec une application tierce située sur la même plateforme. Par exemple, il est courant qu’un serveur chiffre des données et communique les données chiffrées au smartphone, puis que la boite blanche, c’est-à-dire l’algorithme de déchiffrement exécuté par le smartphone, soit utilisé pour déchiffrer les données avant que ces données déchiffrées ne soient communiquées au sein du même smartphone à une application tierce, dite « finale », qui a vocation à utiliser les données déchiffrées. Or, les applications finales sont développées par des sociétés tierces, indépendamment des boites blanches. Ces sociétés font donc l’acquisition de boites blanches commercialisées sous la forme de bibliothèques logicielles contenant l’algorithme de chiffrement et de déchiffrement, et une API (pour « Application Programming Interface ») permettant de contrôler l’algorithme et d’utiliser les données sortant de cet algorithme dans l’application finale développée. Dans ce cadre, les encodages « internes » au sein de la boite blanche n’empêchent pas les données déchiffrées de circuler, en clair, entre la boite blanche et l’application finale. De même, même si la clé de chiffrement utilisée est désormais très difficile à identifier au sein de la boite blanche grâce aux encodages internes installés dans cette boite blanche, l’attaquant peut tenter de réaliser un portage du code, c’est-à-dire exporter l’intégralité du code de la boite blanche sur un autre périphérique pour l’y exploiter sans avoir à identifier la clé.
C’est pourquoi il est connu dans l’état de la technique d’implémenter, en plus de ces encodages internes, des encodages dits « externes », placés aux extrémités du canal de communication complet entre l’envoi des données et leur usage. Par exemple, tout d’abord au sein du serveur situé à distance, un premier encodage « externe » est appliqué à la dernière table de vérité de l’algorithme de chiffrement du serveur, que ce soit sous la forme d’une table de substitution, d’une matrice d’encodage ou d’une autre forme d’encodage aléatoire, de sorte que les données à communiquer au smartphone sont non seulement chiffrées comme prévu, mais également encodées avant d’être communiquées au smartphone. Puis, à l’entrée de la boite blanche, l’encodage inverse de l’encodage externe est appliqué à la première table de vérité de l’algorithme de déchiffrement, avant que les données ne soient traitées à travers l’algorithme de déchiffrement de la boite blanche et ses encodages internes. L’encodage inverse correspondant au premier encodage externe fait donc partie de la boite blanche. Ensuite, un nouvel encodage aléatoire se fait à la sortie de la boite blanche, en appliquant ce nouvel encodage à la dernière table de vérité de la boite blanche. Là aussi, ce deuxième encodage fait dès lors partie de la boite blanche. En sortie, les données sont donc déchiffrées, mais encore encodées cette fois au moyen de ce nouvel encodage aléatoire, avant d’être communiquées à l’application tierce finale ayant vocation à les utiliser. Enfin, au sein de cette application tierce, l’encodage externe correspondant à l’inverse de l’encodage appliqué en fin de boite blanche permet de décoder au sein de l’application les données avant qu’elles ne soient utilisées par l’application.
Grace à ces encodages externes placés à l’extérieur de la boite blanche, même une fois déchiffrées, les données ne circulent pas « en clair » à l’extérieur de la boite blanche, elles restent encodées, donc protégées des manipulations d’un attaquant qui souhaiterait les intercepter. En outre, l’attaque consistant à porter l’intégralité du code de la boite blanche sur un autre périphérique ne fonctionne pas, puisque dans ce cadre le code de la boite blanche comprend en son sein un encodage à son entrée et un encodage à sa sortie. Sans les encodages inverses correspondant, qui sont situés à distance (au sein du serveur et au sein de l’application finale), il n’est pas possible de de retrouver les données en clair. De plus, ajoutés aux encodages internes, ces encodages externes associés à des encodages en sortie et entrée de boite blanche rendent encore plus difficiles d’identifier la clé de chiffrement de la boite blanche.
Il est à noter que l’ensemble de ces encodages, internes comme externes, sont aléatoires, c’est-à-dire qu’ils font appels à des transformations, substitutions ou autres manipulations inconnues de tous, de manière à ce qu’aucun attaquant ne puisse les retrouver.
Cependant, ce procédé comprenant encodages internes et encodages externes comprend encore au moins deux inconvénients.
Premièrement, comme indiqué plus haut, les applications finales sont développées par des sociétés tierces qui font l’acquisition de boites blanches et utilisent une API pour les contrôler. Ces sociétés doivent donc intégrer elles-mêmes à leur application l’encodage externe correspondant, de manière inverse, à l’encodage de sortie de la boite blanche. Elles doivent ensuite elles-mêmes s’assurer de la protection de cet encodage externe (qu’on peut appeler décodage externe) au sein de l’application finale. Elles ont donc une responsabilité s’agissant de la sécurité qui est inconfortable et les force souvent à faire appel à une solution extérieure, potentiellement couteuse, peu fiable et ajoutant de la complexité à l’ensemble du canal de communication des données. En outre, cette contrainte contrevient au principe de sécurité simplifiée vendu à ces sociétés lors de l’acquisition de la boite blanche.
Deuxièmement, en cas de fuite de la boite blanche, il reste difficile d’identifier la source de la fuite. En particulier, il est peu pertinent d’embarquer des signatures ou jetons d’identification dans la boite blanche, puisque l’attaquant aura la possibilité de les modifier ou de les supprimer.
L'invention a notamment pour but d’améliorer la sécurité d’un algorithme cryptographique en boite blanche déjà encodé. Un autre but est de permettre d’identifier la source d’une éventuelle fuite de l’algorithme.
A cet effet l’invention a pour objet un procédé de génération d’encodage pour algorithme cryptographique, mis en œuvre par ordinateur, caractérisé en ce qu’on met en œuvre les étapes suivantes :
- obtention d’au moins une caractéristique propre à un périphérique informatique configuré pour exécuter un algorithme cryptographique ;
- à partir de la caractéristique propre, génération d’une opération d’encodage dépendante du périphérique ;
- association de l’opération d’encodage dépendante générée à l’algorithme cryptographique.
Ainsi, la transformation associée à l’opération d’encodage dépendante dépend d’au moins une caractéristique du périphérique sur lequel a vocation à être exécuté l’algorithme. Cette opération d’encodage dépendante, qu’on peut appeler encodage dépendant, permet donc d’ancrer l’algorithme sur un périphérique particulier. La sécurité des données et du chiffrement est donc améliorée. En particulier, si cet encodage dépendant est un décodage d’un encodage précédent, il est nécessaire pour décoder les données de générer cet encodage dépendant au moyen du périphérique, puisque seul ce périphérique fournit la caractéristique propre permettant de générer le bon décodage. Alternativement, si cet encodage dépendant vise à encoder des données, ces dernières ne pourront également qu’être décodées au moyen du périphérique.
En outre, étant donné que l’encodage dépendant dépend du périphérique, il est plus facile d’identifier la source de la fuite de l’algorithme, puisque seul le périphérique prévu permet de décoder correctement les données encodées au moyen de cet encodage dépendant et donc d’exécuter l’algorithme. Par ailleurs, si l’attaquant modifie l’encodage dépendant pour rendre la source de la fuite introuvable, l’algorithme ne fonctionne plus, ce qui rend toute attaque inutile.
Avantageusement, pour associer l’opération d’encodage dépendante à l’algorithme, on combine l’opération d’encodage avec une opération élémentaire cryptographique de l’algorithme de manière à former une seule opération fusionnée, de sorte qu’une donnée traitée par l’opération fusionnée est opérée conformément à l’opération élémentaire cryptographique et simultanément encodée conformément à l’opération d’encodage dépendante.
Ainsi, l’encodage dépendant ne peut être distingué d’une opération élémentaire, en particulier de chiffrement ou déchiffrement, de l’algorithme. L’opération comme l’encodage dépendant sont donc impossibles à identifier pour un attaquant ayant accès au code exécutable. L’opération et l’encodage sont ainsi « masqués ».
De préférence, on associe l’opération d’encodage dépendante à l’algorithme avant toute exécution cryptographique de l’algorithme sur le périphérique, en particulier lors d’une installation de l’algorithme sur le périphérique, l’exécution cryptographique correspondant en particulier à une opération de chiffrement ou de déchiffrement de données.
Ainsi, l’algorithme inclut cet encodage dépendant avant-même qu’il ne soit utilisé sur le périphérique. L’encodage dépendant reste donc ici identique même si l’algorithme est implémenté sur un autre périphérique que celui dont l’encodage est dépendant. Il est notamment possible que l’algorithme se voit associer cet encodage avant d’être implémenté sur le périphérique, si le périphérique et sa caractéristique propre sont connus à l’avance.
Alternativement, l’algorithme ayant été installé sur le périphérique, on réalise les étapes d’obtention de la caractéristique propre, de génération de l’opération d’encodage dépendante et de l’association de l’opération d’encodage dépendante à l’algorithme, lors d’une exécution cryptographique de l’algorithme sur le périphérique, l’exécution cryptographique correspondant en particulier à une opération de chiffrement ou de déchiffrement de données.
Ainsi, ici l’encodage dépendant est au contraire généré au moment de l’exécution de l’algorithme. Il doit être en particulier généré de nouveau à chaque exécution. L’encodage dépendant généré peut donc dans ce cas varier en fonction du périphérique sur lequel il est généré.
Avantageusement, l’opération d’encodage dépendante associée avant toute exécution cryptographique étant une première opération d’encodage dépendante, l’opération d’encodage dépendante générée et associée lors de l’exécution cryptographique sur le périphérique étant une deuxième opération d’encodage dépendante, on génère cette deuxième opération d’encodage de sorte qu’une donnée encodée via la première opération d’encodage dépendante est décodée via la deuxième opération d’encodage dépendante.
En d’autres termes, on réalise parallèlement les deux opérations précédentes pour générer deux encodages dépendants distincts mais correspondants : l’un - généré à l’avance et restant identique quel que soit le périphérique sur lequel est implémenté l’algorithme - encode des données, tandis que l’autre, dans ce cas le décodage dépendant - généré à chaque exécution à partir du périphérique sur lequel est implémenté l’algorithme - décode ces mêmes données. Ainsi, les données ne peuvent être décodées que si l’algorithme est implémenté sur le périphérique dont sont dépendants l’encodage et le décodage. Si l’algorithme est implémenté sur un autre périphérique, l’encodage dépendant va encoder les données conformément au périphérique dont il est dépendant, puis le décodage dépendant va les décoder conformément à l’autre périphérique, de sorte que les données ne seront pas correctement décodées. L’association entre un encodage dépendant généré à l’avance et un décodage dépendant généré à chaque exécution cryptographique permet donc un ancrage de la boite blanche sur un périphérique particulier.
On peut inverser les opérations de sorte que l’opération générée à l’avance est le décodage, l’opération générée à chaque exécution étant l’encodage.
De préférence, l’opération élémentaire cryptographique étant une première opération élémentaire cryptographique et l’opération fusionnée étant une première opération fusionnée, l’algorithme comprenant également une deuxième opération élémentaire cryptographique succédant directement à la première opération élémentaire cryptographique, on met en œuvre les étapes suivantes :
- combinaison, avant toute exécution cryptographique de l’algorithme sur le périphérique, de la première opération d’encodage dépendante avec la première opération élémentaire cryptographique de manière à former la première opération fusionnée ;
- combinaison, lors de l’exécution cryptographique de l’algorithme sur le périphérique, de la deuxième opération d’encodage dépendante avec la deuxième opération élémentaire, de manière à former une deuxième opération fusionnée, de sorte que, lorsque la donnée encodée et opérée par la première opération fusionnée est traitée par la deuxième opération fusionnée, elle est décodée conformément à la deuxième opération d’encodage dépendante et simultanément opérée conformément à la deuxième opération élémentaire cryptographique.
Ainsi, les opérations d’encodage et de décodage dépendants ne peuvent pas être distinguées, par un attaquant ayant accès au code exécutable, des opérations élémentaires auxquelles elles sont respectivement combinées. Ces opérations élémentaires et d’encodage sont « masqué e s » dans la boite blanche.
Avantageusement, on met en outre en œuvre les étapes suivantes :
- au préalable des premières étapes énoncées, génération d’une troisième opération d’encodage, non dépendante du périphérique, et d’une quatrième opération d’encodage, non dépendante du périphérique et générée de sorte qu’une donnée encodée via la troisième opération d’encodage est décodée via la quatrième opération d’encodage,
- avant toute exécution cryptographique de l’algorithme, combinaison de la troisième opération d’encodage avec la première opération fusionnée, de manière à former une nouvelle première opération fusionnée permettant simultanément d’encoder la donnée conformément à la première opération d’encodage et à la troisième opération d’encodage et d’opérer la donnée conformément à la première opération élémentaire ;
- lors de l’exécution cryptographique, combinaison de la quatrième opération d’encodage avec la deuxième opération fusionnée, de façon à former une nouvelle deuxième opération fusionnée permettant simultanément de décoder la donnée conformément à la deuxième opération d’encodage et à la quatrième opération d’encodage et d’opérer la donnée conformément à la deuxième opération élémentaire.
Ainsi, on ajoute aux opérations d’encodage (et décodage) dépendantes du périphérique des opérations d’encodage (et de décodage) non dépendantes, c’est-à-dire aléatoires, conventionnelles, et on les fusionne également respectivement avec les première et deuxième opérations élémentaires de l’algorithme. On obtient donc deux opérations fusionnées, l’une correspondant à une première opération élémentaire, à l’encodage dépendant et à un encodage non dépendant (qu’on appelle troisième opération d’encodage), l’autre correspondant à la deuxième opération élémentaire, au décodage dépendant et au décodage non dépendant (qu’on appelle quatrième opération d’encodage), ces opérations ne pouvant pas être distinguées l’une de l’autre au sein des opérations fusionnées. L’ajout des encodages et décodage non dépendants permet de masquer la deuxième opération élémentaire. En effet, étant donné que le décodage dépendant (la deuxième opération d’encodage dépendante) n’est généré qu’à l’exécution de l’algorithme, en l’absence de l’encodage non dépendant, la deuxième opération élémentaire serait accessible et compréhensible pour un attaquant disposant du code exécutable. La fusion entre le décodage non dépendant et la deuxième opération élémentaire permet donc de masquer cette dernière avant la génération du décodage dépendant.
Là encore, comme dans toute la description, sauf évidence contraire, les termes d’encodage et de décodage pourraient être inversés.
De préférence, la première et la deuxième opération élémentaire cryptographique formant une paire d’opérations encodées, on répète les étapes de génération et de combinaison d’encodages pour au moins une autre paire d’opérations encodées de l’algorithme, de préférence pour plusieurs paires.
Ainsi, le procédé concerne plus de deux opérations élémentaires cryptographiques de l’algorithme. Potentiellement, chaque opération élémentaire de l’algorithme peut être concernée par une association avec un encodage dépendant, mais la génération d’un encodage ou décodage dépendant au moment de l’exécution de l’algorithme nécessite des ressources et du temps qui peuvent rendre l’exécution trop longue. Il est donc avantageux d’adapter le nombre d’opérations élémentaires combinées aux encodages dépendants en fonction du degré de sécurité voulu et des ressources disponibles au sein du périphérique.
Avantageusement, l’algorithme cryptographique est de type « AES », pour « Advanced Encryption Standard » ou « DES » pour « Data Encryption Standard ».
Ces algorithmes, associés à des clés privées, incluent en effet des opérations aisément séparables les unes des autres et qui vont former les opérations élémentaires cryptographiques. Or, plus un algorithme est facilement séparable en opérations élémentaires simples, plus il est aisé de l’encoder en associant à ces opérations des encodages, en particulier ici des encodages dépendants.
De préférence, la caractéristique propre au périphérique obtenue est l’une des caractéristiques suivantes ou une combinaison d’au moins certaines des caractéristiques suivantes :
- le numéro MAC (pour « Media Access Control ») du périphérique ;
- le numéro IMEI (pour « International Mobile Equipment Identity ») du périphérique ;
- le numéro de série du téléphone ;
- un compteur d’un nombre d’installations d’un algorithme cryptographique au sein du périphérique.
Ainsi, la génération de l’encodage dépendant au moyen d’un autre périphérique aboutit à un encodage différent, ou à un décodage non correspondant, puisque la caractéristique propre est différente.
Avantageusement, la génération de l’opération d’encodage dépendante du périphérique comprend une étape de hachage de la ou des caractéristiques propres au périphérique, de manière à générer une table d’encodage dépendante du périphérique ou une matrice d’encodage dépendante du périphérique, au moins un des éléments de la table ou respectivement de la matrice étant issu du hachage.
Ainsi, les fonctions de hachage de type SHA, par exemple de la famille SHA-2, sont utilisables pour générer l’encodage dépendant à partir de la ou des caractéristiques propres.
De préférence, pour combiner l’opération d’encodage dépendante avec l’opération cryptographique élémentaire, on substitue les termes d’une table de vérité correspondante à l’opération élémentaire au moyen de la table de substitution générée, de manière à former une table fusionnée correspondant à l’opération fusionnée, ou on réalise une opération mathématique entre une matrice correspondant à l’opération élémentaire et la matrice d’encodage dépendante générée, de manière à former une matrice fusionnée correspondant à l’opération fusionnée.
On prévoit également selon l’invention un procédé de cryptographie, dans lequel on chiffre ou on déchiffre au moins une donnée sur un périphérique informatique par un algorithme cryptographique et on encode la donnée par au moins une opération d’encodage associée à l’algorithme, dans lequel l’opération d’encodage est dépendante d’au moins une caractéristique propre au périphérique.
De préférence, l’opération d’encodage de ce procédé de cryptographie a été préalablement associée à l’algorithme cryptographique conformément au procédé de génération d’encodage décrit plus haut.
On prévoit également selon l’invention un programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé de génération d’encodage ou du procédé cryptographie décrits plus haut.
On prévoit également selon l’invention un support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé de génération d’encodage ou du procédé de cryptographie décrits plus haut.
On prévoit également selon l’invention un périphérique informatique comprenant des moyens de calcul informatique aptes à exécuter un algorithme cryptographique associé à une opération d’encodage générée conformément au procédé décrit plus haut.
Brève description des figures
L'invention sera mieux comprise à la lecture de la description qui va suivre donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels :
la est un schéma d’un système selon un mode de réalisation de l’invention ;
la est un schéma détaillé d’une boite blanche selon le mode de réalisation de la  ;
la est un logigramme selon un premier mode de mise en œuvre de l’invention ;
la est un logigramme selon un deuxième mode de mise en œuvre de l’invention ;
la est un logigramme selon un troisième mode de mise en œuvre de l’invention incluant les premier et deuxième mode de mise en œuvre.
 Description détaillée Définitions
On désigne par « opération élémentaire » toute transformation, par exemple mathématique, appliquée à une ou des données d’entrée résultant en une ou des données de sortie de l’opération. Au sein d’un code exécutable, une opération élémentaire peut ainsi être représentée par une table de vérité, accessible et compréhensible pour un attaquant informé, indiquant, pour chaque entrée possible de l’opération, chaque sortie correspondante. Il s’agit en particulier d’indiquer pour toute série de bits d’entrée dans une opération quelle est la série de bits de sortie correspondante.
Par « encodage », on désignera dans la suite toute opération visant à rendre incompréhensible, au sein d’un code exécutable, soit une ou des données, soit la transformation associée à une opération élémentaire. L’encodage est donc lui-même une opération de transformation de données d’entrées en données de sortie. L’encodage d’une opération élémentaire vise donc à empêcher un attaquant de comprendre la table de vérité de l’opération élémentaire. Un tel encodage peut donc consister à remplacer les données de sortie de la table de vérité par d’autres données via une table de substitution, non enregistrée et aléatoire, indiquant les substitutions à effectuer. Il peut également s’agir d’une opération mathématique entre un vecteur correspondant aux données de sortie de la table de vérité initiale et une matrice aléatoire, dite matrice d’encodage, là encore non enregistrée. Dans tous les cas, la table de vérité initiale n’est alors plus accessible puisqu’elle est remplacée par la table de vérité « encodée », « fusionnée » ou encore dite « obfusquée », correspondant à la table résultant à la fois de l’opération élémentaire et de l’opération d’encodage associée. L’opération élémentaire encodée et l’encodage sont donc combinés l’un à l’autre de manière à ne plus pouvoir être distingués l’un de l’autre à la lecture du code exécutable.
Par simplicité, bien que l’opération d’encodage ne soit elle-même pas distinguable des données ou de l’opération auquel elle est associée, et bien qu’elle puisse avoir été fusionnée à d’autres opérations successives, on pourra désigner dans la suite par « encodage » la position théorique de l’opération d’encodage dans une succession d’étapes. On pourra également désigner par « encodage » le résultat d’une opération d’encodage.
Il est à noter qu’à tout encodage correspond nécessairement un encodage inverse, ou décodage. Il s’agit de l’opération associée à la transformation inverse de l’encodage, permettant de retrouver les données ou l’opération encodées lorsqu’elle est appliquée à la suite. On pourra dans la suite désigner un décodage indifféremment par le terme d’encodage ou d’encodage inverse.
Lors d’une succession d’opérations élémentaires, en particulier dans un algorithme de chiffrement ou de déchiffrement, à une opération encodée succède une autre opération fusionnée avec l’encodage inverse. De cette façon, les opérations élémentaires se succèdent comme prévu dans l’algorithme sans que les encodages ne les perturbent. Dans le code exécutable, un attaquant peut parvenir à identifier une table obfusquée correspondant à une opération élémentaire et à un premier encodage, les deux opérations étant fusionnées. Puis, il peut identifier la table obfusquée suivante, correspondant à l’encodage inverse, à une nouvelle opération élémentaire et à un deuxième encodage, les trois opérations étant également fusionnées. Cependant, et c’est là l’intérêt des encodages, l’attaquant ne peut pas identifier les opérations élémentaires effectuées puisqu’elles sont fusionnées avec les encodages. Il ne peut donc pas retrouver la clé de chiffrement et les données chiffrées.
On fera la distinction entre chiffrement/déchiffrement d’un côté, et encodage de l’autre. Le chiffrement ou le déchiffrement correspond à une succession d’opérations réalisées au moyen d’un algorithme cryptographique et d’une clé. Un encodage consiste à encoder l’une de ces opérations ou des données de sortie de ces opérations. Ainsi, par « algorithme cryptographique », on désignera un algorithme de chiffrement ou de déchiffrement basé sur un type d’algorithme connu, par exemple « DES » ou « AES », utilisant une clé spécifique, et on le distinguera des opérations d’encodages qui y sont fusionnées.
Enfin, par « périphérique », on désigne tout terminal comprenant des moyens pour mettre en œuvre le procédé décrit. Dans la suite, il s’agira en particulier de tout terminal de communication doté de moyens de calcul informatique, tel qu’un smarpthone.
Mode de réalisation
Dans le mode de réalisation illustré, l’invention est mise en œuvre au sein d’un smartphone 1. Ce dernier inclut, sous forme logicielle, une application finale dont le code exécutable 2 est schématiquement illustré. Cette application reçoit en entrée des données chiffrées, tel que des données émises par un serveur bancaire 9 situé à distance, et permet en sortie de générer un paiement par smartphone. Il pourrait s’agir d’un tout autre type d’application et d’un tout autre type de données. Dans tous les cas, elle se présente sous la forme d’un code 2 exécutable via le smartphone 1, code 2 que l’on peut schématiquement diviser en deux parties.
Ainsi, la partie 3 est directement issue du code source développé par le développeur, ou société de développement, en charge de l’application 2. Elle n’est pas propre à l’invention mais c’est le cœur de l’application 2 dans le sens où elle reçoit en entrée les données déchiffrées et met en œuvre le rôle attribué à l’application, ici un paiement conformément à des procédés qui ne sont pas spécifique de l’invention et ne seront pas décrits.
La partie 4 du code 2 comprend un algorithme cryptographique de type « AES » (pour « Advanced Encryption Standard ») opérant avec une clé privée et des encodages internes à l’algorithme qui seront décrits en détails plus bas. Cet ensemble d’opérations forme un procédé de déchiffrement 43, qui permet de déchiffrer les données reçues du serveur 9 avant de les communiquer à la partie 3 qui va les utiliser. Cette portion 4 permettrait également de chiffrer des données à envoyer au serveur, on parlerait alors de chiffrement. La partie 4 forme une « boite blanche ». En effet, un attaquant disposant du smartphone 1 peut lire l’ensemble du code de l’application 2, le manipuler, l’exécuter d’une manière fine, pour essayer d’identifier dans cette partie 4 les données chiffrées, et/ou les opérations élémentaires formant l’algorithme de chiffrement ou de déchiffrement 42 pour en déduire en particulier la clé utilisée. Il peut également tenter d’exporter cette boite blanche 4 sur un autre dispositif.
Cette boite blanche 4 comprend également en son sein deux encodages 41 et 42, distincts des encodages internes à l’algorithme 43 qui seront décrits plus bas. A ces encodages 41 et 42 correspondent des encodages dits « externes » 92 et 31. L’encodage 42 permet d’encoder les données en sortie des opérations de déchiffrement de l’algorithme 43. Ainsi, bien que les données soient déchiffrées par l’algorithme 43, elles ne circulent pas « en clair » entre la boite blanche 4 et le cœur 3. Le cœur 3 de l’application comprend au niveau de son entrée un encodage 31 qui est l’encodage inverse de l’encodage 42, permettant de décoder les données reçues de la boite blanche 4. Cet encodage inverse 31 est fusionné avec la première opération programmée par le cœur 3 de manière à ce que cet encodage 31 ne soit pas compréhensible. On considère que l’encodage 31 est « externe » car il est extérieur à la boite blanche. Il ne peut toutefois décoder que les données encodées via l’encodage 42 de la boite blanche, et vice versa. Similairement, l’encodage 41 à l’entrée de la boite blanche 4 est l’encodage inverse de l’encodage 92 placé en sortie de l’algorithme 91 au sein du serveur 9. Ainsi, les données en sorties du serveur 9 sont à la fois chiffrées et encodées, avant d’être décodées par l’encodage 41 puis déchiffrées par l’algorithme 43. Il est à noter que l’encodage 92 est le seul encodage associé à l’algorithme 91. En particulier, cet algorithme 91 n’inclut pas d’encodages internes, associés à des opérations élémentaires.
La partie 4, englobant l’algorithme 43 et les encodages internes 41 et 42, n’est pas directement issue du développeur de l’application 2. En effet, elle a été développée par une autre société de façon indépendante à la partie 3, et a été acquise par le développeur de l’application 2 pour être implémentée sous la forme de bibliothèques logicielles. Ainsi, pour contrôler cette boite blanche 4 indépendante, il est prévu dans le code de la partie 3 des appels à une API (pour « Application Programming Interface  ») fournie par le vendeur de la boite blanche 4, l’API permettant par exemple d’initialiser l’algorithme, de chiffrer ou déchiffrer des données au moyen de cet algorithme 43. Le développeur a donc utilisé l’API pour programmer les appels à la boite blanche 4 permettant d’obtenir les données déchiffrées ou au contraire de fournir à la boite blanche 4 des données à chiffrer.
Enfin, à distance du smartphone, le serveur bancaire 9 inclut lui aussi sous forme logicielle un algorithme « AES » et une clé privée associée. L’algorithme permet de chiffrer des données au moyen de la clé avant de les communiquer au smartphone 1. L’ensemble de ces opérations de chiffrement forment l’algorithme de chiffrement 91. Il peut également permettre de déchiffrer des données reçues. En revanche et contrairement à l’algorithme 43, cet algorithme 91 ne comprend pas d’encodages internes.
On va maintenant détailler les opérations de l’algorithme cryptographique 43 placé dans la boite blanche 4 et exécuté au sein du smartphone 1, en référence à la . On ne décrira pas dans quelle mesure et à quels moment la clé privée est changée, ni comment elle est communiquée au serveur 9, ces éléments n’étant pas propres à l’invention.
En combinant un algorithme de type AES et une clé privée, on obtient l’algorithme cryptographique 43 qui sert dans le mode de réalisation illustré à déchiffrer des données chiffrées par l’algorithme 91. Il est donc formé d’une succession d’opérations élémentaires résultant de la combinaison entre l’algorithme AES tel qu’il est connu et la clé privée choisie ou déterminée. Ces opérations sont encodées, c’est-à-dire qu’à chaque opération est associée un encodage.
Les encodages 432 et 435 ne dépendent pas des caractéristiques du smartphone 1, ils sont générés à l’installation de l’application 2 sur le smartphone indépendamment de ce dernier, ou avant même son installation. Les encodages 41 et 42 ne dépendent également pas du smartphone 1. En revanche, ils sont choisis de manière à correspondre aux inverses des encodages respectifs externes 92 et 31, ou inversement.
Ces encodages 432, 435, 41, 42, 92 et 31 sont donc générés de façon conventionnelle.
En revanche, l’encodage 433, généré à l’installation de l’application 2 sur le smartphone 1, dépend directement du smartphone 1, tandis que l’encodage 434 n’est généré qu’à chaque exécution de l’algorithme 43 et dépend également du smartphone 1, comme décrit ci-après.
Sur la , l’opération élémentaire 431 est encodée par l’encodage 432. Cet encodage 342 est conventionnel : il s’agit de l’application d’une table de substitution choisie aléatoirement. Ainsi, les substitutions opérées ne dépendent de rien sinon du hasard. Ensuite est appliqué un nouvel encodage, l’encodage 433. Cet encodage est d’un type différent : il n’a pas été choisi au hasard. Au contraire, la table de substitution de cet encodage 433 a été décidée au moment de l’installation de l’application 2 sur le smartphone 1 et a été réalisée au moyen de caractéristiques du smartphone 1, selon un procédé qui sera décrit plus bas. En d’autres termes, cet encodage 433 dépend directement du smartphone 1 sur lequel l’application 2 a vocation à être utilisée.
L’opération 431, l’encodage 432 et l’encodage 433 sont fusionnés de façon à ne plus pouvoir être distingués les uns des autres, et la table de vérité correspondante est implémentée définitivement dans l’algorithme 43 dès l’application 2 installée sur le smartphone 1. Dès lors, l’opération élémentaire 431 initiale ne peut plus être identifiée tel quel par un attaquant. L’opération élémentaire suivante de l’algorithme 43 est l’opération 436. Elle est fusionnée avec l’encodage 435 qui est l’encodage inverse de l’encodage 432. Ces deux opérations doivent également être fusionnées avec l’encodage 434 inverse de l’encodage 433. Par construction, cet encodage inverse 434 est nécessairement dépendant lui aussi du smartphone 1. Cependant, à la différence de l’ensemble des encodages précédents, l’encodage 434 n’est pas implémenté dans l’application 2, ni avant ni après son installation. En effet, il est généré uniquement à l’exécution de ces opérations.
Procédés de génération d’encodage
Nous allons maintenant décrire en référence à la un procédé de génération d’encodage 10 pour générer l’encodage dépendant 433. Il est mis en œuvre dans le cadre de l’installation de l’application 2 au sein du smartphone 1.
Il est à noter que les opérations élémentaires auxquelles sont combinés les encodages portent sur des données formant des vecteurs de huit bits, c’est-à-dire 256 entrées possibles. Bien entendu, ce nombre peut varier et être ajusté afin d’équilibrer les ressources disponibles au niveau de sécurité souhaité.
A l’étape 100, le programme 2 demande à obtenir des caractéristiques propres au smartphone 1 que sont le numéro MAC (pour « Media Access Control »), le numéro IMEI (pour « International Mobile Equipment Identity »), et le numéro de série du téléphone. Il génère également un quatrième numéro qui est un compteur incrémenté à chaque installation de la boite blanche 4 sur le smartphone 1. On désigne ces caractéristiques propres au smartphone 1 par le terme d’ « empreintes ». Ces appels sont effectués par le code 2 au moyen d’ « API » conventionnelles associées au smartphone. Ces appels peuvent avoir été préalablement autorisés par l’utilisateur au moment de confirmer l’installation de l’application 2. Les caractéristiques propres peuvent avoir été choisies différemment.
A l’étape 200, les empreintes obtenues sont passées à une fonction de hachage de type SHA256, la fonction de hachage ayant été choisie pour que la sortie corresponde à une table de substitution de même type que la table de vérité des encodages conventionnels. La fonction de hachage est également choisie de manière à ce qu’une variation d’un des numéros fournis engendre en sortie une table de substitution différente. Elle est enfin choisie de manière à ce que cette table ne puisse être obtenue que par le hachage des numéros entrés et non par d’autres numéros. Ainsi, cette table, qui correspond donc à un encodage dépendant du smartphone 1, ne peut avoir été générée que via le smartphone 1. Cet encodage interne permet donc d’ancrer la boite blanche sur le smartphone 1. Dans le cas où la fonction de hachage servirait à établir une matrice d’encodage dépendante, il est nécessaire que cette matrice soit inversible, de manière à pouvoir déterminer l’encodage inverse.
A l’étape 300, la table de substitution dépendante, où table d’encodage dépendant, est appliquée à la table de vérité résultant de l’encodage 432 (elle-même appliquée à la table initiale 431).
A l’étape 400, seule la table de vérité finale, résultant de la combinaison entre la table associée à l’opération initiale 431, l’encodage 432 et l’encodage dépendant 433, est stockée dans le code exécutable 2.
Il est à noter que, au lieu d’obtenir directement depuis le périphérique 1 les caractéristiques à l’étape 100, celles-ci peuvent être connues à l’avance. Dans ce cas, les étapes 200 à 400 pourraient être réalisées en dehors du périphérique 1. On peut ainsi envisager de mettre en place l’encodage 433 dans l’algorithme avant l’installation de cet algorithme dans le périphérique 1.
On va maintenant décrire en référence à la un procédé de génération d’encodage 20 pour générer l’encodage dépendant 434. Celui-ci est mis en œuvre uniquement à chaque exécution de l’algorithme 43 sur le périphérique 1, c’est–à-dire lors du déchiffrement de données.
A l’étape 500, qui est la première étape de la génération de cet encodage 434, le programme 2 demande à obtenir les caractéristiques propres au smartphone 1 que sont le numéro MAC (pour « Media Access Control »), le numéro IMEI (pour « International Mobile Equipment Identity »), et le numéro de série du téléphone. Il génère également le compteur démarrant à 0. Étant donné que ces appels sont effectués sur le même smartphone 1 que celui sur lequel les appels de l’étape 100 ont été effectués, et que le compteur est choisi pour démarrer au même stade, les mêmes empreintes sont obtenues.
A l’étape 600, la même fonction de hachage que celle de l’étape 200 est appliquée sur ces numéros. Il en résulte la même table de substitution que celle déterminée à l’étape 200 du procédé 10.
A l’étape 700, cette table est inversée, entrée et sorties se remplaçant les unes les autres. Cette table est donc l’inverse de la table résultant de l’étape 200. Des données encodées au moyen de l’une des tables pourraient donc directement être décodées au moyen de l’autre.
A l’étape 800, cette table inverse est fusionnée avec l’encodage 435 et la table associée à la nouvelle opération élémentaire 436, de sorte qu’une seule table correspondant à ces trois opérations est stockée dans l’implémentation logicielle.
Désormais, les données résultant de l’opération 431 et encodées par les encodages internes 432 et 433 peuvent être décodées par les décodages internes 434 et 435 en même temps que l’opération élémentaire 436 se déroule.
Bien entendu, il est possible d’inverser les rôles des encodages 433 et 434 en générant l’encodage inverse 434 à l’installation et l’encodage 433 uniquement à chaque opération de déchiffrement.
Il est à noter que, dans ce mode de mise en œuvre, seules les opérations 431 et 436 sont associées à des encodage 433 et 434 dépendants. Les autres opérations élémentaires de l’algorithme 43 ne sont associées qu’à des encodages conventionnels, tels que les encodages 432 et 435, ne dépendant pas du smartphone 1 et n’étant pas générés à l’exécution du déchiffrement, mais implémentés dès l’installation (voire avant). Cependant, il peut être avantageux de procéder à des encodages dépendants pour plusieurs des opérations de l’algorithme 43, afin d’améliorer encore plus la sécurité du procédé. En revanche, il peut ne pas être nécessaire de procéder à des encodages dépendants pour toutes les opérations élémentaires. En effet, un trop grand nombre de génération d’encodages dépendants risque d’engendrer une consommation de ressources excessive lors de l’opération du déchiffrement puisque chaque encodage à générer dans ce cadre devra faire l’objet des étapes 500 à 800. Le temps passé par l’exécution de l’algorithme 43 risque également d’être allongé.
Au final, dans une variante à plusieurs encodages dépendants, chaque opération de l’algorithme 43 est associée à un encodage conventionnel, puis certaines de ces opérations sont, en outre, associées à des encodages dépendants tels que les encodages 433 et 434. Il est du ressort du développeur de la boite blanche d’identifier le nombre et la place des encodages dépendants en fonction du degré de sécurité voulu et des ressources du périphérique prévu.
Chiffrage, déchiffrage, encodage et décodage de données
On va maintenant décrire un procédé 30 résumant la chaine de communication de données entre le serveur 9 et le cœur 3 de l’application 2 au moyen notamment des procédés 10 et 20.
L’étape 40 est l’initialisation du canal de communication. Les boites blanches 4 et 91, respectivement au sein du smartphone 1 et du serveur 9, sont installées lorsque l’application 2 est installée. Les opérations élémentaires initiales de l’algorithme 43, ainsi que l’algorithme 91, sont générés de manière à ce que l’algorithme 43 puisse déchiffrer des données chiffrées par l’algorithme 91, et vice versa. En particulier, dans le cadre d’algorithme de type « AES », la clé privée est la même pour les algorithmes 43 et 91. Les algorithmes diffèrent toutefois en ce que l’algorithme 91, placé sur le serveur, ne comprend pas d’encodages interne, car le serveur est considéré comme un environnement sécurisé.
Les étapes 100 à 400 du procédé 10 sont alors mises en œuvre. En particulier, l’encodage dépendant 433 est généré à ce moment-là dans l’application 2 au moyen des caractéristiques du smartphone 1. C’est également le cas des encodages non dépendants 432 et 435.
A l’étape 50, le cœur 3 de l’application 2 requiert l’envoi de données secrètes de la part du serveur 9 situé à distance. Il s’agit en particulier de validations de données bancaires pour valider un paiement.
A l’étape 60, le serveur 9 chiffre les données demandées au moyen de l’algorithme 91.
A l’étape 70, les données chiffrées sont encodées par l’encodage externe 92 situé sur le serveur 9.
A l’étape 80, elles sont envoyées au smartphone 1, en particulier à l’application 2, et en particulier à la boite blanche 4.
A l’étape 90, l’encodage 41 à l’entrée de la boite blanche, qui correspond à l’inverse de l’encodage 92, décode les données. Pour rappel, étant donné qu’il est fusionné à l’opération et à l’encodage suivants, ce décodage n’est pas compréhensible pour un attaquant.
Les étapes 500 à 800 décrites plus haut, du procédé 20, sont ensuite réalisées au cœur de l’algorithme 43 de déchiffrement des données. En particulier, l’encodage dépendant 434, inverse de l’encodage 433, est généré uniquement au moment de ce déchiffrement.
A l’étape 810, une fois l’encodage 433 généré, les données sont déchiffrées et décodées.
A l’étape 820, les données toujours déchiffrées sont à nouveau encodées, cette fois au moyen de l’encodage 42.
A l’étape 830, les données déchiffrées et encodées sont communiquées au cœur 3 de l’application.
A l’étape 840, l’encodage externe 31, inverse de l’encodage 42, décode les données. Là encore, sa fusion avec les opérations ultérieures du cœur 3 ne permettent pas de l’identifier.
Il est à noter que bien que le procédé illustré soit un procédé de déchiffrement, les encodages fonctionnent de la même manière pour un procédé de chiffrement. Les encodages sont alors associés à des opérations élémentaires de chiffrement plutôt que de déchiffrement.
Les encodages internes dépendants 433 et 434 permettent donc d’ancrer la boite blanche sur le smartphone 1. Ainsi, même si un encodage externe, typiquement l’encodage 31, venait à fuiter, c’est-à-dire à être identifié par un attaquant, les encodages dépendants internes à la boite blanche assureraient une sécurité supplémentaire. En effet, grâce à ces encodages dépendants 433 et 434, il est nécessaire de disposer du smartphone 1 pour exécuter l’algorithme. En effet, en l’exécutant sur un dispositif différent, l’encodage 434 généré au moment de l’exécution sur ce nouveau périphérique ne correspondrait pas à l’encodage 433 dépendant du smartphone 1, et l’algorithme 43 dans son ensemble échouerait.
Un attaquant ne peut donc pas faire fonctionner la boite blanche sur un autre dispositif. En outre, à la différence d’une signature ou de jeton d’identification, ces encodages dépendants ne peuvent pas être supprimés par l’attaquant, car, étant donné qu’ils sont fusionnés aux étapes élémentaires de l’algorithme, ils font pleinement partie de l’algorithme et toute modification engendrerait l’échec de l’exécution de l’algorithme.
Une attaque ne devient donc réalisable qu’au moyen d’une machine virtuelle visant à fausser les empreintes du périphérique. Cependant, pour ce faire, il est nécessaire de très bien connaître le périphérique, au point qu’il est préférable de le posséder, rendant la création d’une machine virtuelle appropriée obsolète.
Ce procédé d’encodages dépendants internes à la boite blanche dépend du développeur de la boite blanche et pas du développeur de l’application finale. Ceci est conforme à l’esprit de sécurité simplifiée associé à la vente de boites blanches « clef en main » aux sociétés développant des applications finales. En particulier, la responsabilité de ces dernières concernant la protection des encodages externes est atténuée étant donné que les encodages dépendants internes à la boite blanche offrent une sécurité supplémentaire.
En outre, la génération d’un encodage dépendant permet de faciliter l’identification d’une fuite. En effet, étant donné que seule la plateforme d’exécution appropriée à l’encodage dépendant peut permettre de faire fonctionner l’algorithme, il est plus facile d’identifier la plateforme d’où provient la fuite. Ainsi, dans le cas du mode de réalisation illustré, si la boite blanche 4 venait à fuir, elle ne fonctionnerait sur aucun dispositif excepté sur le smartphone 1, ce qui permettrait de déterminer qu’elle est issue du smartphone 1.
L'invention n'est pas limitée aux modes de réalisation présentés et d'autres modes de réalisation apparaîtront clairement à l'homme du métier.
Par exemple, d’autres fonctions de hachage sont possibles. De plus, la caractéristique propre ne se limite pas aux exemples fournis mais concerne toute caractéristique qui peut être extraite d’un périphérique et qui est propre à ce périphérique. Il s’agit également de toute combinaison pertinente de caractéristiques propres permettant d’isoler encore plus un périphérique vis-à-vis des autres.
En outre, l’invention rend en particulier pertinent le fait de se passer des encodages externes, qui sont dans le mode de réalisation illustré les encodages 92 et 31. Dans ce cas, les encodages 41 et 42 sont également retirés. Ceci est particulièrement pertinent en ce qui concerne l’encodage externe 31 dont l’implémentation et la protection doivent être assurés par le développeur de l’application finale 2, ce qui contrevient au principe de sécurité simplifié vendu avec la boite blanche 4. Or, étant donné que les encodages dépendants permettent d’ancrer la boite blanche sur le périphérique comme le vise les encodages externes, ces derniers deviennent surabondants et peuvent être supprimés. Dans ce cas, toute attaque de type portage de code de la boite blanche reste délicate compte tenu des encodages dépendants, et le développeur de l’application finale n’a plus à assurer la sécurité d’un encodage. En revanche, dans ce cas, les données circulent en clair, c’est-à-dire de manière déchiffrée, entre l’algorithme de déchiffrement et l’application finale.
Il est possible d’intégrer des encodages internes à l’algorithme 91 de manière à améliorer sa sécurité. En outre, il est possible d’intégrer comme à la boite blanche 43 des encodages dépendants à l’algorithme 91 du serveur, pour améliorer encore sa sécurité et faciliter l’identification d’une éventuelle fuite de cette boite blanche 91. Cela est toutefois généralement moins indispensable que pour un algorithme opérant sur un périphérique mobile, où la sécurité est plus sujette à caution.
Il est possible d’intégrer des encodages dépendants dans des algorithmes cryptographiques autres que l’algorithme de type « AES ». C’est par exemple le cas pour l’algorithme « DES » (pour « Data Encryption Standard »). De manière plus générale, chaque algorithme pouvant être encodé peut faire l’objet des encodages dépendants de l’invention. C’est particulièrement le cas des procédés de chiffrement ou déchiffrements divisés en opérations élémentaires pouvant être encodées.

Claims (17)

  1. Procédé (10, 20) de génération d’encodage pour algorithme cryptographique, mis en œuvre par ordinateur, caractérisé en ce qu’on met en œuvre les étapes suivantes :
    • obtention (100, 500) d’au moins une caractéristique propre à un périphérique informatique (1) configuré pour exécuter un algorithme cryptographique (43) ;
    • à partir de la caractéristique propre, génération (200, 600) d’une opération d’encodage (433, 434) dépendante du périphérique (1);
    • association (300, 400, 700, 800) de l’opération d’encodage dépendante générée à l’algorithme cryptographique.
  2. Procédé (10, 20) selon la revendication précédente, dans lequel, pour associer l’opération d’encodage dépendante (433, 434) à l’algorithme, on combine l’opération d’encodage (433, 434) avec une opération élémentaire cryptographique (431, 436) de l’algorithme de manière à former une seule opération fusionnée, de sorte qu’une donnée traitée par l’opération fusionnée est opérée conformément à l’opération élémentaire cryptographique (431, 436) et simultanément encodée conformément à l’opération d’encodage dépendante (433, 434).
  3. Procédé (10) selon l’une quelconque des revendications précédentes, dans lequel on associe (300, 400, 700, 800) l’opération d’encodage dépendante (433) à l’algorithme (43) avant toute exécution cryptographique de l’algorithme sur le périphérique (1), en particulier lors d’une installation (40) de l’algorithme sur le périphérique, l’exécution cryptographique correspondant en particulier à une opération de chiffrement ou de déchiffrement de données.
  4. Procédé (20) selon l’une quelconque des revendications 1 à 2, dans lequel, l’algorithme (43) ayant été installé sur le périphérique (1), on réalise les étapes d’obtention (100) de la caractéristique propre, de génération (200) de l’opération d’encodage dépendante (434) et de l’association (300, 400) de l’opération d’encodage dépendante (434) à l’algorithme (43), lors d’une exécution (810) cryptographique de l’algorithme sur le périphérique, l’exécution cryptographique correspondant en particulier à une opération de chiffrement ou de déchiffrement de données.
  5. Procédé (10, 20) selon les revendications 3 et 4, dans lequel l’opération d’encodage dépendante (433) associée (10) avant toute exécution cryptographique selon la revendication 3 étant une première opération d’encodage dépendante, l’opération d’encodage dépendante (434) générée et associée (20) lors de l’exécution (810) cryptographique sur le périphérique (1) selon la revendication 4 étant une deuxième opération d’encodage dépendante, on génère cette deuxième opération d’encodage (434) de sorte qu’une donnée encodée via la première opération d’encodage dépendante (433) est décodée via la deuxième opération d’encodage dépendante (434).
  6. Procédé (10, 20) selon la revendication précédente et la revendication 2, dans lequel l’opération élémentaire cryptographique (431) étant une première opération élémentaire cryptographique et l’opération fusionnée étant une première opération fusionnée, l’algorithme (43) comprenant également une deuxième opération élémentaire cryptographique (436) succédant directement à la première opération élémentaire cryptographique, on met en œuvre les étapes suivantes :
    • Combinaison (10), avant toute exécution cryptographique de l’algorithme sur le périphérique, de la première opération d’encodage dépendante (433) avec la première opération élémentaire cryptographique (431) de manière à former la première opération fusionnée ;
    • Combinaison (20), lors de l’exécution cryptographique de l’algorithme sur le périphérique, de la deuxième opération d’encodage dépendante (434) avec la deuxième opération élémentaire (436), de manière à former une deuxième opération fusionnée, de sorte que, lorsque la donnée encodée et opérée par la première opération fusionnée est traitée par la deuxième opération fusionnée, elle est décodée conformément à la deuxième opération d’encodage dépendante (434) et simultanément opérée conformément à la deuxième opération élémentaire cryptographique (436).
  7. Procédé (10, 20) selon la revendication précédente, dans lequel on met en outre en œuvre les étapes suivantes :
    • au préalable des étapes de la revendication 1, génération (40) d’une troisième opération d’encodage (432), non dépendante du périphérique (1), et d’une quatrième opération d’encodage (435), non dépendante du périphérique et générée de sorte qu’une donnée encodée via la troisième opération d’encodage (432) est décodée via la quatrième opération d’encodage (435),
    • avant toute exécution cryptographique de l’algorithme (43), combinaison de la troisième opération d’encodage (432) avec la première opération fusionnée, de manière à former une nouvelle première opération fusionnée permettant simultanément d’encoder la donnée conformément à la première opération d’encodage (433) et à la troisième opération d’encodage (432) et d’opérer la donnée conformément à la première opération élémentaire (431) ;
    • lors de l’exécution cryptographique (810), combinaison de la quatrième opération d’encodage (435) avec la deuxième opération fusionnée, de façon à former une nouvelle deuxième opération fusionnée permettant simultanément de décoder la donnée conformément à la deuxième opération d’encodage (434) et à la quatrième opération d’encodage (435) et d’opérer la donnée conformément à la deuxième opération élémentaire (436).
  8. Procédé (10, 20) de génération d’encodage selon l’une des revendications 6 à 7, dans lequel la première (431) et la deuxième (436) opération élémentaire cryptographique formant une paire d’opérations encodées, on répète les étapes de génération et de combinaison d’encodages pour au moins une autre paire d’opérations encodées de l’algorithme (43), de préférence pour plusieurs paires.
  9. Procédé (10, 20) selon l’une quelconque des revendications précédentes, dans lequel l’algorithme cryptographique est de type « AES », pour « Advanced Encryption Standard » ou « DES » pour « Data Encryption Standard ».
  10. Procédé (10, 20) selon l’une quelconque des revendications précédentes, dans lequel la caractéristique propre au périphérique (1) obtenue est l’une des caractéristiques suivantes ou une combinaison d’au moins certaines des caractéristiques suivantes :
    - le numéro MAC (pour « Media Access Control ») du périphérique ;
    - le numéro IMEI (pour « International Mobile Equipment Identity ») du périphérique ;
    - le numéro de série du téléphone ;
    - un compteur d’un nombre d’installations d’un algorithme cryptographique au sein du périphérique.
  11. Procédé (10, 20) selon l’une quelconque des revendications précédentes, dans lequel la génération de l’opération d’encodage dépendante (433, 434) du périphérique (1) comprend une étape de hachage (200, 600) de la ou des caractéristiques propres au périphérique (1), de manière à générer une table d’encodage dépendante du périphérique ou une matrice d’encodage dépendante du périphérique, au moins un des éléments de la table ou respectivement de la matrice étant issu du hachage.
  12. Procédé (10, 20) selon au moins la revendication précédente et la revendication 2, dans lequel, pour combiner l’opération d’encodage dépendante (433, 434) avec l’opération cryptographique élémentaire (431, 436), on substitue les termes d’une table de vérité correspondante à l’opération élémentaire au moyen de la table de substitution générée, de manière à former une table fusionnée correspondant à l’opération fusionnée, ou on réalise une opération mathématique entre une matrice correspondant à l’opération élémentaire et la matrice d’encodage dépendante générée, de manière à former une matrice fusionnée correspondant à l’opération fusionnée.
  13. Procédé de cryptographie (30), dans lequel on chiffre ou on déchiffre au moins une donnée sur un périphérique informatique (1) par un algorithme cryptographique (43) et on encode la donnée par au moins une opération d’encodage (433, 434) associée à l’algorithme, caractérisé en ce que l’opération d’encodage (433, 434) est dépendante d’au moins une caractéristique propre au périphérique (1).
  14. Procédé (30) selon la revendication précédente, dans lequel l’opération d’encodage (433, 434) a été préalablement associée à l’algorithme cryptographique (43) conformément à l’une quelconque des revendications 1 à 12.
  15. Programme d'ordinateur (2) comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 14.
  16. Support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 14.
  17. Périphérique informatique (1) comprenant des moyens de calcul informatique aptes à exécuter un algorithme cryptographique associé à une opération d’encodage générée conformément à l’une quelconque des revendications 1 à 12.
PCT/EP2023/078864 2022-10-17 2023-10-17 Encodage en boite blanche WO2024083849A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2210698A FR3140960A1 (fr) 2022-10-17 2022-10-17 Encodage en boite blanche
FRFR2210698 2022-10-17

Publications (1)

Publication Number Publication Date
WO2024083849A1 true WO2024083849A1 (fr) 2024-04-25

Family

ID=85569969

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/078864 WO2024083849A1 (fr) 2022-10-17 2023-10-17 Encodage en boite blanche

Country Status (2)

Country Link
FR (1) FR3140960A1 (fr)
WO (1) WO2024083849A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120163582A1 (en) * 2010-12-23 2012-06-28 Electronics And Telecommunications Research Institute Data encoding and decoding apparatus and method thereof for verifying data integrity
EP2940925A1 (fr) * 2014-04-28 2015-11-04 Nxp B.V. MISE EN oeUVRE DE RÉGLAGES DE SÉCURITÉ EN FONCTION de l'utilisation DANS UNE IMPLÉMENTATION À BOÎTE BLANCHE UNIQUE
EP2960891A1 (fr) * 2014-06-24 2015-12-30 Nxp B.V. Procédé permettant d'introduire la dépendance d'implémentation d'une boîte blanche sur un ensemble de chaînes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120163582A1 (en) * 2010-12-23 2012-06-28 Electronics And Telecommunications Research Institute Data encoding and decoding apparatus and method thereof for verifying data integrity
EP2940925A1 (fr) * 2014-04-28 2015-11-04 Nxp B.V. MISE EN oeUVRE DE RÉGLAGES DE SÉCURITÉ EN FONCTION de l'utilisation DANS UNE IMPLÉMENTATION À BOÎTE BLANCHE UNIQUE
EP2960891A1 (fr) * 2014-06-24 2015-12-30 Nxp B.V. Procédé permettant d'introduire la dépendance d'implémentation d'une boîte blanche sur un ensemble de chaînes

Also Published As

Publication number Publication date
FR3140960A1 (fr) 2024-04-19

Similar Documents

Publication Publication Date Title
FR2986631A1 (fr) Dispositif et procede de production d'un code d'authentification d'un message
EP1627362A1 (fr) Methode de generation d'une cle de securite
FR3011653A1 (fr) Procedes et dispositifs de masquage et demasquage
EP2107808A1 (fr) Module de sécurité (SM) pour unité de traitement de données audio/vidéo
EP3300292B1 (fr) Procédé de chiffrement ou de déchiffrement protégé contre des attaques par canaux cachés
FR2699300A1 (fr) Procédé d'authentification d'un ensemble informatique par un autre ensemble informatique.
EP2166696A1 (fr) Protection de l'intégrité de données chiffrées en utilisant un état intermédiare de chiffrement pour générer une signature
EP1266364A1 (fr) Procede cryptographique de protection contre la fraude
WO2024083849A1 (fr) Encodage en boite blanche
CA2988357C (fr) Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants
WO2024083855A1 (fr) Clés cryptographiques en boite blanche
EP2153575B1 (fr) Obtention de valeurs dérivées dépendant d'une valeur maîtresse secrète
EP3340096B1 (fr) Procédé de configuration d'un programme cryptographique destiné à être exécuté par un terminal
CH716294A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous conditions d'identification personnelle et de géolocalisation, d'une transaction destinée à une blockchain.
EP3842970B1 (fr) Procédé de vérification du mot de passe d'un dongle, programme d'ordinateur, dongle et terminal utilisateur associés
WO2024133604A1 (fr) Procédé de sécurisation de la saisie des chiffres d'un code personnel didentification, et dispositif correspondant.
FR2807245A1 (fr) Procede de protection d'une puce electronique contre la fraude
CA3183198A1 (fr) Dispositif, methode et programme pour une communication securisee entre boites blanches
EP3745638A1 (fr) Procedes de mise en uvre et d'obfuscation d'un algorithme cryptographique a cle secrete donnee
EP3948596A1 (fr) Procédé d'exécution de code sécurisé, dispositifs, système et programmes correspondants
FR2995110A1 (fr) Optimisation memoire cryptographique
CH716291A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique, d'une transaction destinée à une blockchain.
CH716292A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous condition de géolocalisation, d'une transaction destinée à une blockchain.
CH716293A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous condition d'identification personnelle, d'une transaction destinée à une blockchain.
CH716299A2 (fr) Procédé de signature d'une transaction destinée à une blockchain, au moyen d'une clé cryptographique distribuée parmi les noeuds d'un réseau pair-à-pair.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23789673

Country of ref document: EP

Kind code of ref document: A1