Authenticating devices through a cryptographic process

Abstract

To implement device authentication through a cryptographic process that fully protects a cryptographic algorithm.SOLUTION: A processing method in a first device DV1 cooperating with a second device includes receiving first data DT1 including challenge data, obtaining key data CEC including an encrypted cryptographic key DEC masked by performing a cryptographic masking function, receiving an unmasking key K2, determining DEC by performing a cryptographic unmasking function on the basis of the unmasking key, determining a decrypted cryptographic key KEC by decryption running a decryption algorithm in a white-box implementation on the basis of the DEC, determining answer data ANS1 by a cryptographic operation that executes a predetermined cryptographic algorithm on the basis of the KEC and the challenge data, and sending the answer data ANS1 to authenticate the first device.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to the field of cryptography, and in particular to performing cryptographic processes to allow a second device to authenticate a first device. [Background technology]

[0002] Digital devices (also known as computing devices or digital appliances) such as computers, tablets, chip cards, mobile phones, connected objects, etc. are ubiquitous in our daily lives. These devices often require security solutions to be implemented to protect access to the device and to defend sensitive data against any attacks.

[0003] A common security solution involves embedding a secure element into such devices. As defined by the "Global Platform" standards organization, familiar to those skilled in the art, a secure element is a hardware and software platform configured to securely host applications and their associated sensitive data (e.g., cryptographic keys, algorithms, etc.) according to rules established by a trusted third party. The secure element provides a secure execution environment for applications. Secure elements can take various hardware forms, including a UICC (universal integrated circuit card) module, an embedded secure element (or "embedded SE" or "eSIM"), or a microSD card. UICC modules and microSD cards are typically removable. Each form of secure element is intended for use in very specific applications and must meet the specific requirements of the target market.

[0004] Although secure elements offer a good level of protection, their deployment is complex and limited because they require very specialized equipment and services provided by experts. The use of secure elements to protect devices makes their implementation and operation more complex and therefore is not always desirable.

[0005] Another solution involves implementing applications in open appliances such as PCs, tablets or smartphones without using any secure element, which allows access to new markets and simplifies the deployment of applications. To defend open devices, pure software solutions (e.g., cryptography) must be implemented.

[0006] However, a security challenge arises in that the source code and data implemented in open devices (those that do not use a secure element) are easily accessible to potential hackers. Open devices can be subject to "white-box" attacks, meaning that the attacker has full access to the software implementation of the cryptographic algorithms. That is, the binaries are fully visible and modifiable to the attacker, giving the attacker complete control over the execution platform. As a result, the software implementation of applications on open devices needs to be well-defended.

[0007] To protect open devices, various known software solutions can be used, including "white-box" cryptography. A white-box cryptography solution is based on implementing a cryptographic algorithm while protecting the secret cryptographic key used. White-box cryptography can be applied to any cryptographic algorithm used in an application that requires protection. A white-box implementation of a cryptographic algorithm involves modifying (complicating, masking, etc.) the implementation of the algorithm in question, for example, by changing the internal representation of the functions and data involved to protect the secret key used. A white-box implementation also involves incorporating, for example, a secret (in the form of data but also in the form of code) and random data instantiated at compile time into a compound that makes the secret difficult to guess. To authenticate a user, for example, a white-box implementation of the Advanced Encryption Standard (AES) cryptographic algorithm can be used in an application.

[0008] However, even white-box implementations present security problems in that cryptographic algorithms are susceptible to certain attacks (statistical attacks), provided the attacker rolls out the necessary resources. Such attacks are possible, in particular, when an attacker can monitor the execution of a memory-based application.

[0009] If an attacker is able to discover the cryptographic key of a cryptographic algorithm in a white-box implementation, the supplier of the target application will need to use a new white-box implementation of a different design to once again defend the target cryptographic algorithm and the new associated secrets. This creates a problem because the number of possible white-box implementations for a given algorithm is relatively limited. Therefore, the supplier's freedom in selecting or modifying a white-box implementation of a cryptographic algorithm is very limited. Therefore, defending a cryptographic algorithm that is under attack can quickly become difficult. [Prior art documents] [Non-patent literature]

[0010] [Non-Patent Document 1] “White-Box Cryptography and an AES Implementation”(Stanley Chow,Philip A.Eisen,Harold Johnson,and Paul C.van Oorschot;In Kaisa Nyberg and Howard M.Heys,editors;Selected Areas in Cryptography,volume 2595 of Lecture Notes in Computer Science,pages 250-270.Springer,2002;https: / / eprint.iacr.org / 2013 / 104.pdf) Summary of the Invention [Problem to be solved by the invention]

[0011] It is also desirable to have a cryptographic algorithm well-protected so that the cryptographic key or keys used are effectively protected against any attack. In addition, if an attacker is able to achieve an attack on the cryptographic algorithm used to protect a given application, the software implementation should be easily adaptable so that the target application is protected as well as possible.

[0012] Furthermore, when a cryptographic algorithm is used to protect a protocol or a given application, it is desirable to be able to adapt the software implementation of the cryptographic algorithm as needed without affecting the given protocol or application (and thus with minimal impact on the protocol or application in question). [Means for solving the problem]

[0013] To this end, the invention provides a processing method implemented by a first device cooperating with a second device, the method comprising: a) receiving first data from a second device, the first data including first challenge data; b) obtaining key data including an encrypted encryption key obtained from encryption with a first encryption algorithm, the key data being masked by performing a cryptographic masking function based on the encrypted encryption key and a masking key; c) receiving an unmasking key from the second device; and d) determining an encrypted encryption key by performing a cryptographic unmasking function based on the key data obtained in b) and the unmasking key received in c); e) determining a decrypted encryption key by decrypting by performing a first decryption algorithm in a white-box implementation based on the encrypted encryption key; f) determining answer data by a cryptographic operation by performing a predetermined cryptographic algorithm based on the decrypted cryptographic key and the received first challenge data; g) in response to the first data received in a), transmitting answer data to the second device to cause the second device to authenticate the first device; The present invention relates to a processing method including the steps of:

[0014] The present invention advantageously allows a second device to authenticate a first device in a reliable and flexible manner, in particular allowing any cryptographic algorithm to be effectively defended while allowing a high degree of freedom in the software implementation used.

[0015] The present invention makes it possible to defend a cryptographic algorithm in such a way that the cryptographic key or keys used are effectively protected against any attack. In addition, if an attacker is successful in attacking a cryptographic algorithm used to protect a given application, the present invention can be used to easily adapt a software implementation to defend the application as well as possible.

[0016] Moreover, when a cryptographic algorithm is used to protect a given protocol or application, the present invention allows the software implementation of the cryptographic algorithm to be adapted as needed without affecting the given protocol or application (and thus with minimal impact on the target protocol or application).

[0017] According to a particular embodiment, the first encryption algorithm and the first decryption algorithm are related cryptographic algorithms configured to perform an inverse cryptographic function.

[0018] According to a particular embodiment, the first encryption and decryption algorithm is different from the default encryption algorithm.

[0019] According to a particular embodiment, the method comprises, prior to c) receiving the unmasking key: h) transmitting second data including second challenge data to the second device; wherein the unmasking key received from the second device in c) is calculated based on the second challenge data.

[0020] According to a particular embodiment, the method further comprises, before h), i) obtaining tokens, the tokens being: - key data; - first time data indicating a validity period for which the encryption key is valid; - an identifier of said cryptographic key that can be used during said validity period; Including, getting and the second data transmitted in h) includes the first time data and the identifier extracted from the token.

[0021] According to certain embodiments, the method comprises: j) selecting the token obtained in i) from among one or more tokens accessible by the first device based on the second time data included in the first data received in a); wherein the second time data indicates a validity period during which the cryptographic key of the selected token must be valid.

[0022] According to a particular embodiment, the token obtained in i) further comprises second challenge data distinct from the first time data and the identifier; The second data transmitted in h) includes the second challenge data extracted from the token.

[0023] According to a particular embodiment, the first time data and the identifier contained in the second data transmitted in h) constitute second challenge data.

[0024] According to a particular embodiment, the token further comprises a key encoded in a format suitable for white-box implementation; In e), the decrypted encryption key is determined by decryption by performing a first decryption algorithm in the white-box implementation based on the encrypted encryption key and based on a key extracted from the token and encoded in a format suitable for the white-box implementation.

[0025] According to a particular embodiment, the cryptographic masking and unmasking functions are associated encryption and decryption functions, respectively.

[0026] According to a particular embodiment, the cryptographic masking and unmasking functions are symmetric encryption functions, and the masking key and the unmasking key are identical.

[0027] According to a particular embodiment, the cryptographic masking and unmasking functions are XOR functions.

[0028] According to a particular embodiment, the method further comprises, following step g), k) triggering a predefined function in cooperation with the second device in response to detecting that the second device has successfully authenticated the first device. Includes.

[0029] In certain embodiments, the different steps of the processing method are determined by computer program instructions.

[0030] Consequently, the invention also relates to a computer program on an information medium (or recording medium), which can be implemented in a device (a so-called "first device") or more generally in a computer, which program comprises instructions suitable for the implementation of the steps of the processing method as defined herein.

[0031] This program may use any programming language and may be in the form of source code, object code, or a code intermediate between source code and object code (such as a partially compiled form), or in any other desired form.

[0032] The invention also relates to an information medium (or recording medium), which can be read by a computer and which contains instructions of a computer program as defined herein.

[0033] The information medium can be any entity or device capable of storing a program. For example, the medium can include a storage means such as a rewritable non-volatile memory or ROM memory (e.g., a CD-ROM or a microelectronic circuit ROM) or a magnetic recording means (e.g., a floppy disk or a hard disk).

[0034] Furthermore, the information medium may also be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention may in particular be downloaded over an Internet-type network.

[0035] Alternatively, the information carrier may be an integrated circuit in which the program is embedded, the circuit being suitable for performing or for use in performing the method in question.

[0036] The present invention also relates to a device (a so-called first device) capable of implementing the processing method as defined herein. In particular, the present invention relates to a first device capable of cooperating with a second device, the first device comprising: - a first receiving module configured to receive first data from a second device, the first data including first challenge data; - an obtaining module configured to obtain key data including an encrypted encryption key obtained from encryption with a first encryption algorithm, the key data being masked by performing a cryptographic masking function based on the encrypted encryption key and a masking key; - a second receiving module configured to receive an unmasking key from a second device; - a first determination module configured to determine an encrypted cryptographic key by performing a cryptographic unmasking function based on the obtained key data and the received unmasking key; - a second determination module configured to determine a decrypted encryption key by decrypting by executing the first decryption algorithm in a white-box implementation based on the encrypted encryption key; - a third determination module configured to determine answer data by a cryptographic operation by executing a predetermined cryptographic algorithm based on the decrypted cryptographic key and based on the received first challenge data; a transmitting module configured to transmit answer data to the second device in response to the received first data to cause the second device to authenticate the first device; A first device is provided, comprising:

[0037] It should be noted that the different embodiments mentioned above (and those described below) can be applied in a similar manner to the first device of the present invention in the context of the processing method of the present invention and the associated advantages.

[0038] For each step of the processing method, the first device of the present invention may include a corresponding module configured to perform said step.

[0039] In this regard, the term "module" herein may equate to a software component, a hardware component, or an assembly of hardware and software components.

[0040] A software component is equivalent to any element of a program or software capable of implementing a function or set of functions in accordance with what is described below for one or more computer programs, one or more subprograms of a program, or more generally for a module of interest. Such a software component can be executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and can access the hardware resources of this physical entity (memory, storage media, communication buses, electronic input / output cards, user interface, etc.).

[0041] Similarly, a hardware component is equivalent to any element of a hardware assembly that is capable of implementing a function or set of functions as described below for the module in question. The hardware component may be a programmable hardware component or a hardware component with an embedded processor for executing software (e.g., an integrated circuit, a chip card, a memory card, an electronic card for executing firmware, etc.).

[0042] Other features and advantages of the present invention will become apparent from the description provided below, with reference to the accompanying drawings, which show exemplary, without limitation, embodiments thereof, in which: [Brief explanation of the drawings]

[0043] [Figure 1] 1 illustrates a method for allowing a second device to authenticate a first device according to a first example. [Figure 2] 1 schematically illustrates an environment in which a first device cooperates with a second device and a remote server, according to certain embodiments. [Figure 3] 1 shows a schematic representation of the structure of a first device according to a particular embodiment of the invention; [Figure 4] 3 shows a schematic representation of the structure of a second device according to a particular embodiment of the invention. [Figure 5] 3 illustrates a schematic representation of modules implemented by a first device according to certain embodiments of the present invention. [Figure 6] 1 illustrates, in diagram form, steps of a processing method according to a particular embodiment of the present invention. [Figure 7] 1 illustrates, in diagram form, steps of a processing method according to a particular embodiment of the present invention. [Figure 8] A variation of the processing method shown in FIG. 6 is presented in diagram form. DETAILED DESCRIPTION OF THE INVENTION

[0044] As already indicated, this specification relates to authenticating a first device and, more generally, to having a second device authenticate a user of this first device, for example for the purpose of accessing any service or any functionality.

[0045] The embodiments described below fall within the category of access control for vehicles (e.g., cars, etc.). Thus, a first device is used by a user to authenticate itself to another device that controls access to the vehicle. However, it will be understood that the present invention applies more generally to cryptographic operations, and any first device may authenticate itself to another, so-called second device. By way of example, a second device of the present invention may be configured to control any functionality of the vehicle, such as controlling a door or starting / stopping the vehicle. The second device may similarly control a door to a house, control a security gate, control access to transportation, or control access to Internet services, game consoles, etc.

[0046] The nature of the first and second devices may vary depending on the envisaged application or applications. The first device may for example be a terminal (mobile phone, tablet, computer, etc.), a USB key or equivalent.

[0047] Specifically, the present invention provides enhanced security in allowing a second device to authenticate a first device by using a cryptographic algorithm in a white-box implementation to protect the cryptographic key used for authentication. To achieve this, a first device cooperates with a second device to authenticate itself to the second device. During the processing method (authentication method), the first device unmasks an encrypted cryptographic key possessed by the first device using an unmasking key provided by the second device during a previous interaction between the first and second devices. The first device then decrypts the encrypted cryptographic key thus obtained by executing a decryption algorithm in a white-box implementation. The first device can then generate an answer by executing a predetermined cryptographic algorithm based on the decrypted cryptographic key and challenge data previously provided by the second device. By transmitting this answer to the second device in response to the first challenge data, the first device can authenticate itself to the second device, and the second device can verify the validity of the answer and infer from the verification whether the authentication will be successful or not.

[0048] Other aspects and advantages of the present invention will become apparent from the exemplary embodiments described below, by reference to the above-referenced drawings.

[0049] As already indicated, white-box cryptography is a well-known technique that involves implementing the functionality of a given cryptographic algorithm, but by adapting the implementation of this algorithm to use a secure implementation (a so-called white-box implementation). The reader is referred to, for example, in the literature:

[0050] Formal specifications (such as standards and norms) of cryptographic algorithms provide descriptions of the mathematical functions implemented in the operations of these algorithms (e.g., the AES algorithm is standardized by the National Institute of Standards and Technology (NIST)). White-box implementations of such cryptographic algorithms aim to modify these descriptions, for example, by changing the internal representation of the functions or data implemented in these algorithms so as to hide the secret in the implementation's code to protect it from any attacks. For example, a table can be used to combine both a secret key (in the form of data and / or code) and random data with a function that makes the secret difficult to guess. The general principles of white-box implementations of given cryptographic algorithms are well known to those skilled in the art and will not be described in further detail here.

[0051] As already indicated, the applicant recognizes that current techniques for white-box implementation of cryptographic algorithms offer advantages from a security perspective, but also require constraints and limitations in their ability to effectively protect protocols or applications. This is particularly due to the fact that white-box implementation of cryptographic algorithms is generally used by the protocol or application that it is desired to protect.

[0052] Figure 1 schematically represents a first solution in which a MAC (Message Authentication Code) algorithm based on AES (Advanced Encryption Standard) in a white-box implementation is used by a first device 2 (a terminal in this example) to authenticate itself to a second device 4 (a vehicle in this example).

[0053] As shown in the figure, during the authentication method, it is assumed that terminal 2 and vehicle 4 interact with each other to enable terminal 2 to authenticate itself to vehicle 4. Vehicle 4 transmits randomly selected challenge data CH0 to terminal 2 (E2). Terminal 2 then computes an answer RP0 based on the received challenge data CH0 (E4). To achieve this, terminal 2 uses an AES-based MAC algorithm, or more precisely a specific white-box implementation of this algorithm (wb[aes / K EC ]) in its memory. This white-box implementation embeds an encryption key K EC and this encryption key K EC is masked in the code of the implementation. Therefore, terminal 2 executes the AES-based MAC algorithm in a white-box implementation based on the challenge data CH0 provided by vehicle 4 (E4) (RP0=wb[aes / K EC ](CH0)). At the determined time, the terminal 2 transmits the answer RP0 to the vehicle 4 (E6), which can then verify the validity of the received answer RP0. To achieve this, the vehicle transmits the challenge data CH0 and a key K EC Based on the received answer RP0, the vehicle computes its own answer RP0a by performing an AES-based MAC algorithm (E8). The vehicle then compares the received answer RP0 with its theoretical answer RP0a (E10), and if RP0 and RP0a match, the authentication of terminal 2 is successful.

[0054] In the example shown in Figure 1, the white-box implementation technique is applied directly to the AES-based MAC algorithm used by vehicle 4 to authenticate terminal 2, but this creates a problem. As already mentioned, there are only a limited number of possible white-box implementations for the same cryptographic algorithm (i.e., the AES-based MAC algorithm in this example). If an attacker obtains the cryptographic key K ECor if the security of the implementation of the AES-based MAC algorithm at terminal 2 is compromised for any reason, it may prove difficult to implement a new white-box implementation of this same AES-based MAC algorithm at terminal 2 while maintaining a good level of security. In this example, the programmer has only limited freedom due to the fact that the configuration of vehicle 4 imposes the use of an AES-based MAC algorithm at vehicle 4, and therefore terminal 2, and the fact that in this example, white-box implementation techniques are applied to this AES-based MAC algorithm within terminal 2. Moreover, even if it were possible to modify the algorithm used by vehicle 4 to authenticate terminal 2, this would generally be undesirable because it would require extensive modification of the configuration of devices already deployed in the field.

[0055] The present invention provides a change of principle by applying white-box implementation techniques to a different decryption algorithm that is now no longer imposed by a second device to authenticate the first device, but is used by the first device to defend the authentication process (but is not used by the second device during the authentication method). Thus, it is possible to adapt and defend the white-box implementation of this other decryption algorithm in the first device without any impact on the second device, in particular without requiring any extensive modification of the second device's configuration, while maintaining a good level of security throughout the authentication process. Any adaptation of the white-box implementation on the first device side is independent of the second device, thereby providing more flexibility in better defending the authentication method against attacks.

[0056] Specific embodiments will now be described with reference to Figures 2-8. Unless otherwise specified, shared or similar elements across several figures will have the same reference numerals, have the same or similar characteristics, and for simplicity, these shared elements will not be generally described again.

[0057] 2 shows an environment E in which a first device DV1 cooperates with a second device DV2, the first device DV1 and the second device DV2 together forming a system SY1.

[0058] In this example, the first device DV1 is a terminal such as a mobile phone (smartphone) or a tablet, for example, and the second device DV2 is a household appliance included in or coupled to the vehicle 8. In a variant, the device DV2 can be the vehicle 8 itself.

[0059] In this example, a user UR uses a terminal DV1 to authenticate himself to a vehicle 8, and more specifically to a second device DV2 that controls access to the vehicle 8.

[0060] The environment E optionally includes a remote server SV1 capable of communicating with at least the first device DV1 and the second device DV2 (or at least one of these). The server SV1 can, for example, send data in the form of a token TN (also called data group) to the first device DV1 or send challenge data CH2 to the second device DV2, although implementations of the invention are possible without such a server SV1.

[0061] Figure 3 shows the structure of the first device DV1 shown in Figure 2 according to a particular embodiment. In this example, the first device DV1 includes a processor 10, a volatile memory 12, a non-volatile memory 14, a non-volatile memory 16, and a communication interface INT1.

[0062] The memory 14 is a rewritable non-volatile memory or a read-only memory (ROM), and constitutes a recording medium (or information medium) according to a specific embodiment readable by the first device DV1, and has registered thereon a computer program PG1 according to a specific embodiment, which includes instructions for executing steps of a processing method according to a specific embodiment, as will be explained later.

[0063] The memory 16 is a rewritable non-volatile memory that can store a token TN, a white-box implementation of a decryption algorithm pdec (denoted wb[pdec]), along with a predefined encryption algorithm ALp. However, the contents of the memory 16 may vary depending on the implementation of the invention under consideration. In this example, the memory 16 stores a set of tokens TN, denoted TN1 to TN20, each of which contains key data C EC , challenge data CH2 and data EXP and ID. As will be explained later, the content of the tokens TN and the number of tokens TN may vary depending on the case. By way of example, implementations are possible without such tokens TN or without the data EXP and ID within these tokens TN.

[0064] As will be explained later, the key data C EC is the encrypted encryption key D obtained from the encryption performed by the encryption algorithm penc. EC As will become clearer later, this encryption algorithm penc corresponds to the inverse of the decryption algorithm pdec (in other words, these two algorithms match each other), and the decryption algorithm pdec is able to disable or decrypt the encryption performed by the encryption algorithm penc.

[0065] Therefore, the encrypted encryption key D EC is the encrypted form of the encryption key K EC is equivalent to (D EC =enc(K EC )). The decryption algorithm pdec in the white-box implementation can be any decryption algorithm (such as a proprietary algorithm or all or part of the AES algorithm). As will be explained later, aspects of the present invention are based on the fact that in this example, white-box implementation techniques are applied to this decryption algorithm pdec.

[0066] Key data C EC (Therefore, CEC The encrypted encryption key D contained in EC ) is the encrypted encryption key D EC and is further masked by executing a cryptographic masking function F1 based on a masking key K1. EC is the encrypted encryption key D EC and the masking key K1 as input and execute a cryptographic masking function F1. EC The encrypted encryption key D contained in EC is masked by executing the masking function F1. EC is the encryption key K in encrypted form (by penc) EC This is equivalent to the masking (by F1) of the original image.

[0067] As will be shown later, the key data C EC It is not the first device DV1 that performs the masking by the function F1 to generate the key data C. However, the first device DV1 does EC can be obtained or received and stored in memory 16.

[0068] The nature and use of the different elements contained in memory 16 will be explained in more detail below.

[0069] The communication interface INT1 enables the first device DV1 to communicate with the second device DV2 via a suitable communication link of wired or wireless type (e.g. via Bluetooth, Wi-Fi, NFC or a wireless communication type (e.g. GSM or LTE, etc.)).

[0070] The processor 10 also uses a volatile memory 12 to carry out different operations or functions required for the operation of the first device DV1, including the execution of a computer program PG1 during the implementation of the processing method of the invention.

[0071] Figure 4 shows the structure of the second device DV2 shown in Figure 2 according to a particular embodiment. In this example, the second device DV2 includes a processor 20, a volatile memory 22, a non-volatile memory 24, a non-volatile memory 26, and a communication interface INT2.

[0072] The memory 24 is a rewritable non-volatile memory or a read-only memory (ROM), which constitutes a recording medium (or information medium) according to a specific embodiment readable by the second device DV2, and on which a computer program PG2 according to a specific embodiment is recorded. This computer program PG2 includes instructions for executing steps of a processing method according to a specific embodiment, as will be explained later.

[0073] The memory 26 is a rewritable non-volatile memory and stores the above-mentioned predetermined encryption algorithm ALp, encryption algorithm AL1, one or more keys K EC The memory 26 may store a master key MK, a key TK, and data EXP and ID from which EXP can be derived. However, the contents of the memory 26 may vary depending on the implementation of the invention under consideration. By way of example, implementations are possible without at least one of EXP, ID, TK, and MK (or even without any of them).

[0074] As shown in FIG. 4, the memory 26 can also store time data EXPmin (hereinafter referred to as second time data), on which the implementation of the present invention is possible.

[0075] The nature and use of the different elements contained in memory 26 will be explained in more detail below in specific examples.

[0076] Thus, in the example considered here, a default encryption algorithm ALp is used by the first and second devices DV1, DV2 during the authentication method to have the second device DV2 authenticate the first device DV1. This encryption algorithm ALp can, of course, be any algorithm used to perform encryption (or more generally, cryptographic operations), as long as the first and second devices DV1, DV2 use the same encryption algorithm ALp. This encryption algorithm ALp can, for example, be an AES encryption algorithm, a signature calculation algorithm, or a MAC (Message Authentication Code) identifier calculation algorithm (e.g., based on AES). Since a thorough modification of the configuration of the second device DV2 is not desirable, the nature of the encryption algorithm ALp implemented in the first device DV1 is given by the configuration of the second device DV2.

[0077] Moreover, the communication interface INT2 is configured to cooperate with the communication interface INT1 of the first device DV1 in order to establish a communication link between DV1 and DV2 (and vice versa). As already indicated, this link can be of various types (wired or wireless).

[0078] The processor 20 further uses the volatile memory 22 to carry out different operations or functions required for the operation of the second device DV2, including executing a computer program PG2 during the implementation of the processing method of the present invention.

[0079] It should be noted that the first and second devices DV1, DV2 shown in Figures 2-4 constitute merely exemplary embodiments, and other implementations are possible within the scope of the present invention. As will be understood by those skilled in the art, certain elements of the first and second devices DV1, DV2 are described herein only to facilitate understanding of the present invention, and these elements are not necessarily required to practice the present invention.

[0080] 5 according to a particular embodiment, the processor 10 of the first device DV1, driven by the computer program PG1, now implements a number of modules, namely a first receiving module MD2, an acquiring module MD4, a second receiving module MD6, a first determining module MD8, a second determining module MD10, a third determining module MD12 and a transmitting module MD14, and, if applicable, also a second acquiring module MD16 and / or a second transmitting module MD18. However, implementations of the invention are in particular possible without these modules MD16 and MD18.

[0081] More precisely, the first receiving module MD2 is arranged to receive, from the second device DV2, first data DT1 comprising first challenge data CH1.

[0082] The acquisition module MD4, as already explained above with reference to FIG. 3, EC Therefore, the key data C EC is D EC The encryption key denoted by EC is itself an encrypted encryption key D EC and has been masked by previously performing a cryptographic masking function F1 based on a masking key K1.

[0083] Therefore, as already shown, the encrypted encryption key D EC is the encryption key K EC is an encrypted version of , which is encrypted by the encryption algorithm penc using the encryption key K EC Furthermore, the key data C EC The encrypted encryption key D contained in EC is itself masked by executing the masking function F1.

[0084] The acquisition module MD4 is key data C EC The method for recovering the key data C may vary depending on the case, as will be explained later. EC For example, these key data C can be received in advance from the outside (for example, from the server SV1 (FIG. 2)). EC The method may be configured to generate:

[0085] The second receiving module MD6 is configured to receive from the second device DV2 an unmasking key K2, which is configured to be able to be used as input to a cryptographic unmasking function F2, as will be shown below.

[0086] The first determination module MD8 determines the key data C obtained by the acquisition module MD4. EC and on the basis of the unmasking key K2 received by the second receiving module MD6, by executing a cryptographic unmasking function F2 EC (i.e., key K EC The unmasking function F2 is configured to determine an encrypted version of the key data C EC In other words, the first determination module MD8 is configured to nullify the masking previously performed by the function F1 to generate the key data C EC The key data C is generated using an unmasking function F2, which is the inverse encryption function of the masking function F1 used to generate the key data C. EC As will be seen later, various cryptographic functions F1, F2 can be envisioned, as long as they are inverses of each other.

[0087] The second determination module MD10 determines the encrypted encryption key D determined by the first determination module MD8. EC The decrypted encryption key K is obtained by executing the decryption algorithm pdec in a white-box implementation (i.e., the white-box implementation wb[pdec]) based on ECis configured to determine

[0088] The third determination module MD12 determines the decrypted encryption key K determined by the second determination module MD10. EC and based on the first challenge data CH1 received by the first receiving module MD2, it is configured to determine answer data ANS1 by a cryptographic operation by executing a predefined cryptographic algorithm ALp as mentioned above. As will be explained in specific examples below, this cryptographic operation can be an encryption or another type of cryptographic operation (signature operation, MAC operation, etc.).

[0089] The sending module MD14 is configured to send the answer data ANS1 determined by the third determination module MD12 to the second device DV2 as a reply to the first data DT1 received by the first receiving module MD2, in order to have the second device DV2 authenticate the first device DV1.

[0090] As already indicated, the first device DV1 receives, if applicable, the key data C EC The acquisition module MD4 then derives from the token TN key data C EC According to particular embodiments, the token TN may contain various other data, such as challenge data CH2 or data EXP and ID, the nature and use of which will be explained later.

[0091] As already indicated, the first device DV1 may also include a second transmission module MD18 configured to transmit, if applicable, second data DT2 including second challenge data CH2 to the second device DV2 (the second challenge data CH2 being extracted, for example, from the token TN obtained by the second acquisition module MD16, if applicable).

[0092] The configuration and operation of modules MD2 to MD18 of first device DV1 will be seen in more detail in the exemplary embodiments described herein by referring to Figures 6 to 8. It should be noted that modules MD2 to MD18 as shown in Figure 5 illustrate merely exemplary embodiments of the present invention, without limitation.

[0093] Generally, for each step of the processing method of the present invention, the first device of the present invention may include a corresponding module configured to perform said step.

[0094] A particular embodiment will now be described with reference to Fig. 6. More precisely, the first device DV1 (hereinafter referred to as "terminal") and the second device DV2 previously described with reference to Figs. 2 to 5 cooperate with each other in particular to enable the first device DV1 to authenticate itself to the second device DV2. To achieve this, the terminal DV1, in cooperation with the second device DV2, executes a computer program PG1, thereby implementing a processing method (or authentication method). Similarly, the second device DV2 executes a computer program PG2 in order to authenticate the terminal DV1.

[0095] During a reception step S2, the terminal DV1 receives from the second device DV2 first data DT1 containing first challenge data denoted CH1. The second device DV2 selects the challenge data CH1 to send to the terminal DV1 in S2, for example randomly to make the method more secure.

[0096] Furthermore, the terminal DV1 uses the encrypted encryption key D EC key data C containing EC (S4) is obtained, but the key data C EC (Therefore, the key data C EC The encrypted key D contained in EC ) is the encrypted encryption key D EC and has been masked by performing a cryptographic masking function F1 based on a masking key K1.

[0097] More specifically, the encrypted encryption key D EC is obtained by encryption using the encryption algorithm penc. In other words, the encrypted encryption key D EC is the encryption key K EC is an encrypted version of , which is encrypted by the encryption algorithm penc using the encryption key K EC is obtained by encrypting

[0098] Furthermore, the key data C EC The encrypted encryption key D contained in EC has itself been masked by executing a cryptographic masking function F1. EC is the encryption key K in encrypted form (by penc) EC This is equivalent to the masking (by F1) of the original image.

[0099] Terminal DV1 receives key data C EC The method for recovering the key data C may vary depending on the case, as will be explained later. EC can be received beforehand from outside, for example, from the server SV1 (FIG. 2). According to a particular example, the key data C EC The server SV1 generates the encryption key K by executing the encryption algorithm penc. EC Encrypted by encrypting the encrypted encryption key D EC and then performing a cryptographic masking function F1 based on the masking key K1 to obtain the encrypted cryptographic key D EC This is done by masking the

[0100] In advance, the terminal DV1 stores the received key data C in its memory 16 (FIG. 3). EC can be recorded and retrieved by querying the memory 16 in the acquisition step S4.

[0101] During a sending step S6, the terminal DV1 sends second data DT2 to the second device DV2, which data includes second challenge data, denoted CH2. The way in which the terminal DV1 predetermines the second challenge data CH2 to send to the second device DV2 can vary depending on the case. The terminal DV1 may for example predetermine the second challenge data CH2 to send to the second device DV2. EC and may previously receive second challenge data CH2 associated with the second device DV1 and store it in its memory 16. As will be shown below, implementations are possible in which the terminal DV1 does not transmit any second data DT2 to the second device DV2.

[0102] In this example, the second device DV2 then determines (S8) an unmasking key K2 based on the second challenge data CH2 received in S6. More precisely, the second device DV2 computes this unmasking key K2 by executing an encryption algorithm AL1 based on the second challenge data CH2 and, if applicable, also based on the key TK stored in the memory 26 of the second device DV2 (although the use of this key TK is not mandatory). In other words, the encryption algorithm AL1 takes as input the second challenge data CH2 and, if applicable, also the key TK, and produces as output the unmasking key K2. This unmasking key K2 is then used to encrypt the key data C in this masked form. EC The encrypted encryption key D contained in EC The answer is constructed with the aim of enabling terminal DV1 to unmask the

[0103] It should be noted that in S8, any encryption algorithm AL1 can be used by the second device DV2 to generate the unmasking key K2, provided that the encryption algorithm AL1 can generate the necessary unmasking key K2 such that the terminal DV1 can perform the unmasking S12 as described below. In particular, the encryption algorithm AL1 can be different from the default encryption algorithm ALp used by the terminal DV1 and the second device DV2 to authenticate the terminal DV1. The encryption algorithm AL1 can be the AES algorithm or any other suitable encryption algorithm.

[0104] Thus, during a sending step S10, the second device DV2 sends an unmasking key K2 to the terminal DV1 in response to the second data DT2 received in S6. The sending of the second challenge data CH2 from the terminal DV1 to the second device DV2 in S6 provides an additional defense to the processing method, since the second device DV2 can generate the unmasking key K2 only on the basis of the challenge data CH2 previously provided by the terminal DV1 during the interaction. However, other implementations are possible in which the second device DV2 does not need the second challenge data CH2 of the terminal DV1 in order to generate or obtain the unmasking key K2.

[0105] As a variant, the terminal DV1 does not send the second data DT2 in the sending step S6, and the second device DV2 determines the unmasking key K2 in any suitable way in S8 (this key K2 can in particular be received externally).The second device DV2 then sends the unmasking key K2 to the terminal DV1 in S10 without providing an answer to the challenge data CH2 from the terminal DV1.

[0106] According to a particular example, the second device DV2 receives an unmasking key K2 from the server SV1. To achieve this, the second device DV2 receives, for example, a list of one or more unmasking keys K2 from the server SV1. The second device DV2 then extracts an unmasking key K2 from this list (for example, according to a predefined order) and transmits the unmasking key K2 to the terminal DV1 at S10.

[0107] According to another example, DV2 receives from server SV1 the key K EC In association with the received message, the challenge data CH2 or the unmasking key K2 can be received.

[0108] The terminal DV1 therefore receives (S10) the unmasking key K2 provided by the second device DV2 in reply to the second data DT2. Then, during a decision step S12, the terminal DV1 determines whether the key data C obtained in S4 EC and based on the unmasking key K2 received at S10, by performing a cryptographic unmasking function F2 (as mentioned above). EC In other words, the key data C EC and unmasking key K2 as input and execute unmasking function F2 to obtain key data C EC and thus the encrypted encryption key D EC is obtained as the output.

[0109] The unmasking function F2 can be adapted depending on the case, and the key data C EC In other words, the unmasking function F2 is selected as a function of the masking function F1 to produce the inverse cryptographic effect (i.e., unmasking effect) of the masking function F1.

[0110] According to a particular example, the cryptographic masking function F1 and the unmasking function F2 are associated encryption and decryption functions, respectively. Various encryption and decryption functions can be envisaged. According to a particular example, the cryptographic masking function F1 and the unmasking function F2 are symmetric encryption functions, which are associated with a masking key K1 (key data C EC is generated) and the unmasking key K2 are identical. In a variant, the cryptographic masking function F1 and the unmasking function F2 are asymmetric encryption and decryption functions, and the keys K1 and K2 are different public and private keys, respectively.

[0111] According to a particular example, the cryptographic masking function F1 and the unmasking function F2 are "exclusive OR" (also called XOR or exclusive disjunction) functions. The XOR function, which is well known to those skilled in the art, is conventionally represented by the symbol "

number

[0112] Key data C EC The initial masking of the encryption key K EC provides advantageous protection of the encrypted cryptographic key D EC (and hence the encryption key K EC ) the terminal DV1 must be able to retrieve the unmasking key K2 in advance by interacting with the second device DV2. Only by using this unmasking key K2 can the terminal DV1 derive the encrypted encryption key D by executing the cryptographic unmasking function F2. EC (i.e., the encrypted form of the encryption key K EC ) can be determined. Without the unmasking key provided by the second device DV2, the attacker can determine the encrypted encryption key DEC cannot be unmasked.

[0113] Then, during a decision step S14, the terminal DV1 receives the encryption key K in its decrypted form (plain text). EC To achieve this, the terminal DV1 determines the encrypted encryption key D EC In other words, the terminal DV1 performs the decryption by executing the decryption algorithm pdec in a white-box implementation based on the plaintext encryption key K EC To generate the output, the encrypted encryption key D EC Run the white-box implementation wb[pdec] of the decoding algorithm pdec, taking as input

[0114] Therefore, according to the principles of the present invention, a white-box implementation technique is applied not to a predefined encryption algorithm ALp imposed by the second device DV2 to authenticate the terminal DV1, but to a decryption algorithm pdec that is specific to the terminal DV1 and can therefore be adapted by a person skilled in the art with more freedom than the algorithm ALp in order to secure the method as well as possible.

[0115] The decryption algorithm pdec uses the encryption key K EC To obtain the encrypted encryption key D EC It can be any decryption algorithm as long as it is capable of reversing (or nullifying) the encryption previously performed by the encryption algorithm penc to produce pdec. In other words, the encryption algorithm penc and the decryption algorithm pdec are associated cryptographic algorithms configured to perform an inverse cryptographic function.

[0116] The decryption algorithm pdec may be, for example, a proprietary algorithm or all or part of the AES algorithm. According to a particular example, the encryption algorithm penc and the decryption algorithm pdec differ from the default encryption algorithm ALp used by the second device DV2 to authenticate the terminal DV1. It should be noted that the difference may relate to the implementation of the same type of algorithm (based on the same mathematical principles). By way of example, the algorithms ALp and pdec (and penc) may be different algorithms in the sense that their respective software implementations are different, e.g., in the case where the algorithm pdec is the AES algorithm in a white-box implementation, while the algorithm ALp is the AES algorithm in a non-white-box implementation.

[0117] According to a particular example, the decryption algorithm pdec is an algorithm other than the AES algorithm.

[0118] During step S14, the white-box implementation wb[pdec] of the decryption algorithm pdec is EC It should be noted that besides the above, data specific to the terminal DV1 and / or data from the user UR of the terminal DV1 (for example a secret PIN code entered by the user UR) can be taken as input.

[0119] The white-box implementation wb[pdec] of the decryption algorithm pdec can also take into account a key that can be embedded in the white-box implementation or "tokenized" (i.e., in the form of a token) and passed as a parameter of the white-box. This tokenized key can be, for example, converted by the terminal DV1 into the key data C obtained in S4. EC can be obtained from

[0120] Then, during a determination step S16, the terminal DV1 determines the decrypted encryption key K determined in S14. ECand based on the first challenge data CH1 previously received at S2, the terminal DV1 determines the answer data ANS1 by encryption (or generally by a cryptographic operation) by executing a predefined cryptographic algorithm ALp (as mentioned above). In other words, the terminal DV1 uses the cryptographic key K to generate the answer data ANS1 as output. EC and challenge data CH1 as input and executes a predefined cryptographic algorithm ALp, and the answer data ANS1 constitutes the answer to the challenge data CH1 received at S2.

[0121] In the example considered here, the encryption algorithm ALp does not have a white-box implementation (although it is possible for it to have one). As explained above, white-box implementation techniques are applied to the decryption algorithm pdec in S14, which can improve the flexibility and security of the processing method.

[0122] Then, during a transmission step S18, the terminal DV1 responds to the first data DT1 received in S2 (specifically in response to the challenge data CH1) by transmitting answer data ANS1 to the second device DV2 in order to allow the second device DV2 to authenticate the terminal DV1 (and therefore the user UR).

[0123] Once the answer data ANS1 is received (S18), the second device DV2 authenticates the terminal DV1 based on the answer data ANS1 and on the challenge data CH1 (S20). More precisely, the second device DV2 receives the encryption key K EC and based on the challenge data CH1 previously sent in S2, the second device DV2 computes theoretical answer data ANS1a by encryption (or generally by a cryptographic operation) by executing a predefined cryptographic algorithm ALp (S22). In other words, the second device DV2 uses the cryptographic key K to generate the theoretical answer data ANS1a as output. ECand challenge data CH1 as input and executes a predetermined encryption algorithm ALp. The second device DV2 obtains an encryption key K EC can be recovered.

[0124] Next, the second device DV2 compares the answer data ANS1 provided by the terminal DV1 in S18 with the theoretical answer data ANS1a determined in S22 (S24). If the received answer data ANS1 matches the theoretical answer data ANS1a, authentication of the terminal DV1 is successful; otherwise, authentication fails. In other words, authentication of the terminal DV1 is successful only if ANS1 and ANS1a match.

[0125] As already mentioned, the default encryption algorithm ALp used by the first and second devices DV1, DV2 during the authentication method for authenticating the first device DV1 may differ depending on the case, as long as this same encryption algorithm ALp is used by both the terminal DV1 and the second device DV2 (so that the answer data ANS1 can be verified by the second device DV2 in S20). This encryption algorithm ALp may be, for example, an AES encryption algorithm, a signature calculation algorithm or a MAC (Message Authentication Code) identifier calculation algorithm (for example, based on AES). The principles of signature or MAC calculation are well known to those skilled in the art and, for the sake of brevity, will not be described in detail here.

[0126] The second device DV2 can further control access to a function F3 (any function of the vehicle 8) depending on the result of the authentication step S20. In particular, if the authentication of the terminal DV1 is successful, the second device DV2 can trigger the implementation of the function F3, and if the authentication is unsuccessful, the second device DV2 can block the function F3. As already mentioned, this function F3 can, for example, involve controlling access to the vehicle 8 or controlling its start.

[0127] According to a particular example, following the sending step S18 (FIG. 6), the terminal DV1 is reconfigured to modify the decryption algorithm pdec by replacing it with a new decryption algorithm pdec that is different from the old one. Then, again in S14, the new decryption algorithm pdec, implemented in a white-box implementation in the terminal DV1, can be used to perform the authentication method as described in steps S2 to S26 above.

[0128] The present invention advantageously allows a second device to reliably and flexibly authenticate a first device DV1. In the example described above, the second device DV2 executes a predefined cryptographic algorithm ALp to authenticate the first device DV1. Since it is desirable to modify the configuration (application, protocol, etc.) of the second device DV2 as little as possible, the configuration of the second device DV2 forces the first device DV1 to use this same cryptographic algorithm ALp during the authentication method to generate the answer data ANS1. The reason for this is that the use of the same algorithm ALp is necessary to enable the second device DV2 to verify the validity of the answer data ANS1 provided by the first device DV1 in S20 (FIG. 6) by calculating the theoretical answer data ANS1a, as described above.

[0129] However, the principle of the present invention is based on the fact that during the execution of the decryption algorithm pdec by the first device DV1 (S14, FIG. 6), a white-box implementation technique is applied. Therefore, it is not the encryption algorithm ALp but the decryption algorithm pdec that has a white-box implementation in the first device DV1 (although it could also be the encryption algorithm ALp). As long as the selection of the algorithms ALp and pdec is decorrelated, the decryption algorithm pdec (S14) in the white-box implementation in the first device DV1 can be carefully selected and adapted as needed without modifying the encryption algorithm ALp (S16, S22) executed in the first and second devices DV1 and DV2. In other words, any encryption algorithm ALp can be used by the second device DV2 as long as the same encryption algorithm ALp is also used in the first device DV1 to generate the answer data ANS1 (S16, FIG. 6). Specifically, the encryption algorithm ALp does not need to be protected by a white-box implementation in the first device DV1. The invention therefore allows for configuration flexibility when a special attack compromises the security of the first device DV1 and requires a modification of the white-box implementation of the decryption algorithm pdec in the first device DV1.

[0130] As mentioned above, the number of possible white-box implementations for the same algorithm is limited. Therefore, when a security problem occurs, the present invention EC The decryption algorithm pdec can be modified such that a new pdec algorithm is implemented in a white-box implementation by the first device DV1 during step S14 (FIG. 6) of determining pdec, thereby increasing the security of the authentication method without any impact on the configuration of the second device DV2. Thus, in other words, the present invention makes it easier to update a white-box implementation of the decryption algorithm pdec without any impact on the second device DV2 that does not run the decryption algorithm pdec.

[0131] However, the encryption key K EC Although an attacker may attempt to analyze the decryption algorithm pdec implemented in a white-box implementation to extract pdec, the algorithm pdec may be a proprietary algorithm (or all or part of the AES algorithm, if applicable) and may be periodically modified, thereby making any attack more difficult. According to a particular example, the decryption algorithm pdec is an algorithm other than the AES algorithm.

[0132] Another advantage of the present invention is that the unmasking key K2 can be recovered to generate the encrypted key D EC To be able to unmask K, the first device DV1 needs to interact with the second device DV2, which allows the attacker to obtain the decrypted key K. EC The key lies in the fact that the attacker has a limited time to discover and use the encryption key K. This prior interaction between the first device DV1 and the second device DV2 allows the attacker to EC The attack becomes more complex because the attacker is forced to interact with the second device DV2 beforehand to determine K. If the transaction is not completed correctly (e.g., if the transaction does not complete correctly or takes too long), the second device DV2 must specifically determine the encryption key K so that it is considered invalid. EC can be blocked, thus preventing any subsequent authentication based on this key.

[0133] In the following, a variant implementation of the embodiment of Fig. 6 will be described with reference to Figs. 7 and 8. Unless otherwise specified, the descriptions of the different features and steps of the invention provided above according to the above-described embodiments are applicable in the same way to equivalent features having the same reference signs in the variants of Figs. 7 and 8.

[0134] According to the embodiment shown in Fig. 7, it is again assumed that the first device DV1 (hereinafter referred to as "terminal") and the second device DV2 previously described with reference to Figs. 2 to 5 cooperate with each other in order to enable the first device DV1 to authenticate itself to the second device DV2. To achieve this, the terminal DV1, in cooperation with the second device DV2, executes a computer program PG1 to implement a processing method (or authentication method). Similarly, the second device DV2 executes a computer program PG2 to authenticate the terminal DV1.

[0135] In this example, it is assumed that during a receiving (or obtaining) step S40, the terminal DV1 receives (or obtains) several tokens TN, each of which contains key data C associated with challenge data CH2. EC , first time data EXP, and a key identifier ID. For each token TN, the first time data EXP indicates the validity time for which the associated cryptographic key is valid. In addition, the identifier ID indicates the validity time of the cryptographic key K associated with the considered token TN. EC and identify this key K EC is available for use during a validity period specified by the first time data EXP.

[0136] The first time data EXP may indicate, for example, an expiration date or end of a validity period (e.g., an expiration date and / or an expiration time), beyond which the associated encryption key K EC is no longer valid.

[0137] The identifier ID can be an index or take any other suitable form. The same validity period (and therefore the same value of data EXP) can be used for several encryption keys K EC This identifier ID is used to identify some cryptographic key K, including EC (and therefore more generally several tokens TN). The values ​​of the data EXP and ID are EC) can be chosen to be associated with the data pair (EXP, ID).

[0138] As already indicated, other implementations are possible that do not rely on the data EXP and ID. However, the use of the data EXP and ID is dependent on the encryption key K EC This has the advantage that it allows the validity of a key to be limited, thus limiting the time an attacker has to compromise the security of the system and use an illegally obtained key.

[0139] In the example considered here, the terminal DV1 contains tokens TN (denoted TN1 to TN20) in its memory 16 (FIG. 3). However, it should be noted that the number of tokens obtained by the terminal DV1 may vary depending on the case. The terminal DV1 may obtain one or more tokens TN, as explained above.

[0140] During a reception step S42, the terminal DV1 receives from the second device DV2 first data DT1 comprising first challenge data CH1 (as already explained above) and second time data EXPmin. In other words, the reception step S42 differs from the previously described step S2 (FIG. 6) in that the received first data DT1 comprises second time data EXPmin in addition to the first challenge data CH1. The second time data EXPmin allows the terminal DV1 to select a token TN in a step S44, as will be explained below.

[0141] During the selection step S44, the terminal DV1 selects a token TN from among one or more tokens TN accessible by the terminal DV1 (i.e., in the example considered here, from among the tokens TN1 to TN20 recorded in its memory 16) based on the second time data EXPmin of the first data DT1 received in S42.

[0142] The second time data EXPmin is the encryption key K of the token TN selected in S44. ECIn other words, the terminal DV1 selects the key data C from the available tokens TN1 to TN20 that satisfies the validity time condition imposed by EXPmin. EC Token TN (and therefore the corresponding encryption key K EC The terminal DV1 selects the key data C of the target token TN. EC Based on the first time data EXP associated with the EC It is determined whether or not this second time condition EXPmin is met.

[0143] For example, the second time data EXPmin is EC (Thus, the corresponding encryption key K EC ) indicates the minimum remaining time (for example, the minimum expiration date) for which the encryption key K EC Therefore, based on the value of the time data EXPmin, the terminal DV1 can select an appropriate token TN in S44.

[0144] According to a particular example, in S44, the terminal DV1 selects a new token TN at each iteration of the authentication method (ie at each new reception (S42) of the first data DT1).

[0145] Once the selection S44 has been made, the terminal DV1 transmits to the second device DV2 (S46) second data DT2, which includes the second challenge data CH2, the first time data EXP and the identifier ID extracted from the token TN selected in S44. In other words, the transmission step S46 differs from the previously described step S6 (FIG. 6) in that the second data DT2 includes, in addition to the second challenge data CH2, the data EXP and ID specified in the token TN selected in S44. Thus, in this case, the transmitted second challenge data CH2 is separate from the data EXP and ID contained in the second data DT2.

[0146] According to a particular example, the terminal DV1 signs the second data DT2 with the private key SKm before transmitting the second data DT2 to the second device DV2. According to another example, the signing of the second data DT2 is performed by the server SV1 and then received by the first device DV1 and stored together with the associated token. The second device DV2, which possesses the public key PKm associated with the private key SKm, can then verify the signature. The second device DV2 only allows the authentication method to continue if the signature verification is successful. This variant specifically makes it possible to avoid any DoS (Denial of Service) attack aimed at disrupting the second device DV2 so that a legitimate user UR cannot authenticate itself and thus loses the considered service. Such an attack may be possible if an attacker pretends that the terminal DV1 transmits an arbitrary or incorrect value of the first time data EXP in the second data DT2 to the second device DV2. In such a case, the second device DV2 may then reject any token TN that does not have a validity period at least up to the end of the validity period indicated by the last EXP received.

[0147] Moreover, when the second data DT2 are received, the second device DV2 derives the token TN (and therefore the encryption key K) selected by the terminal DV1 in S44 based on these second data DT2. EC) (S48). More precisely, in the example considered here, the second device DV2 verifies in S48 the validity of the token TN selected by the terminal DV1 based on the first time data EXP and the identifier ID contained in the received second data DT2. The second device DV2 verifies, for example, based on the data EXP and the ID, that the token TN selected by the terminal DV1 in S44 has not yet been used by the terminal DV1 or another terminal. During this verification, the second device DV2 can specifically compare the first time data EXP received in S46 with the second time data EXPmin contained in the data DT1 sent to the terminal DV1 in S42, and verify whether the first time data EXP meets the validity time condition imposed by EXPmin. As already mentioned, for the token TN to be valid, the key data C of the token TN must be EC It is particularly necessary that the first time data EXP associated with meets the time validity condition imposed by EXPmin.

[0148] If in S48 the second device DV2 determines that the token TN selected by the terminal DV1 is valid, the method proceeds to operation step S50. Otherwise, authentication of the terminal DV1 fails and the authentication method ends (if applicable, the second device alerts the terminal DV1 to the failure and asks it to select another token TN that respects the second time data EXPmin).

[0149] During a calculation step S50, the second device DV2 calculates (or determines) an unmasking key K2 based on the second challenge data CH2 contained in the second data DT2 received in S46. This calculation step S50 can be performed by executing the encryption algorithm AL1 in the same way as in step S8 (FIG. 6) previously described. As already mentioned, the second device DV2 can also take into account other inputs, such as the key TK, during the execution of the encryption algorithm AL1.

[0150] During the calculation step S50, the unmasking key K2 can be determined by executing the encryption algorithm AL1, taking as input the first time data EXP and the identifier ID, in addition to the second challenge data CH2 (and, if applicable, the key TK). This makes it possible to further increase the security of the calculation of the unmasking key K2. This makes it possible to prevent an attacker from reusing an expired token, in particular by modifying the time data EXP (e.g., date) or the identifier ID sent to the second device DV2. In such a case, the unmasking key K2 determined in S50 will be different from the one intended to work for the token TN in question.

[0151] The second device DV2 then transmits the unmasking key K2 to the terminal DV1 (S10).

[0152] It should be noted that in the example considered here, the terminal DV1 includes second challenge data CH2 in addition to the first time data EXP and the identifier ID in the second data DT2 that it sends to the second device DV2 in S46 (in other words, it is not the data EXP and ID that serve as second challenge data). The data EXP and ID enable the second device DV2 to verify the validity of the selected token TN, and the second challenge data CH2 enable the second device DV2 to calculate the unmasking key K2. However, a variant is possible in which the terminal DV1 does not include the second challenge data CH2 in addition to the data EXP and ID in the second data DT2 that it sends to the second device DV2 (S46). In this case, it is the data EXP and ID (or at least one of these two data) that serve as second challenge data and thus are used by the second device DV2 to determine the unmasking key K2 in S50. However, including the second challenge data CH2 in the second data DT2, in addition to the first time data EXP and the identifier ID, is advantageous in that it makes it possible to avoid any problems related to collisions in the use of different tokens TN. In general, such collision problems can be avoided by putting in place a mechanism making it possible to guarantee that each data pair (EXP, ID) is unique in the deployed token TN. Based on the data pair (EXP, ID) received in the second data DT2, the second device DV2 can then determine whether the corresponding token TN is still valid or not.

[0153] In a variant, the second data DT2 transmitted to the second device DV2 in S46 may include only the identifier ID, which then serves as second challenge data (without including the first time data EXP or the data CH2 in the second data DT2 transmitted in S46). In this special case, the second device DV2 uses the identifier ID as second challenge data to determine the unmasking key K2 in S50. Regardless of the envisaged implementation, the second device DV2 must preferably be able to verify in S48 that the same token TN is not used twice.

[0154] According to a particular example, the terminal DV1 transmits, in S46, different second challenge data CH2 for each new iteration of the method, in other words, the terminal DV1 transmits, in S46, different second challenge data CH2 for each token TN used to authenticate the terminal DV1 (to the second device DV2 or any other device).

[0155] Moreover, once the unmasking key K2 has been received at S10, the terminal DV1 carries out steps S12, S14, S16 and S18 as already explained previously with reference to figure 6, where, by way of example, it is assumed that the unmasking function F2 used is an XOR function, as already mentioned above.

[0156] The second device DV2 therefore receives the answer data ANS1 in S18. In this example, the second device DV2 determines during the determination step S60 that the encryption key K used by the terminal DV1 ECTo achieve this, the second device DV2 determines the encryption key K 1 (i.e., the one corresponding to the token TN selected by the terminal DV1 in S44) based on the master encryption key MK (stored in the memory 26 in this example) and, if applicable, also based on the data EXP, ID and / or CH2 previously received in S46 in the second data DT2 (i.e., at least one of them, for example EXP and ID, EXP and CH2, ID and CH2 or EXP, ID and CH2). EC is derived (S60).

[0157] The second device DV2 then continues the method by executing steps S20, S22, S24, S26 as already described previously with reference to Figure 6. In particular, the second device DV2 uses the encryption key K calculated in S60 EC and based on the challenge data CH1 previously sent in S42, the second device DV2 calculates theoretical answer data ANS1a by encryption by running a predefined encryption algorithm ALp (or generally by a cryptographic operation) (S22). The second device DV2 then compares the answer data ANS1 received in S18 with the theoretical answer data ANS1a (S24) and infers from this that the authentication was successful if ANS1 and ANS1a match.

[0158] According to the embodiment shown in Fig. 8, it is again assumed that the first device DV1 (hereinafter referred to as "terminal") and the second device DV2 previously described with reference to Figs. 2 to 5 cooperate in particular to enable the first device DV1 to authenticate itself to the second device DV2. To achieve this, the terminal DV1, in cooperation with the second device DV2, executes a computer program PG1 to implement a processing method (or authentication method). Similarly, the second device DV2 executes a computer program PG2 to authenticate the terminal DV1.

[0159] The variant shown in FIG. 8 is a terminal DV1 that generates an encryption key K EC7 in that a key KRand encoded in a format suitable for a white-box implementation is additionally used as an input for the decryption algorithm pdec implemented in the white-box implementation to determine the key KRand (in its decrypted form). This key KRand is therefore only usable by the white-box implementation under consideration. To achieve this, the key KRand can undergo any suitable transformation (for example, a transformation in the form of a table that performs encryption or key-hiding operations) so that said key KRand is only understandable or usable by the white-box implementation under consideration.

[0160] More precisely, as shown in FIG. 8, the terminal DV1 receives (or obtains) during a receiving (or obtaining) step S80 a number of tokens TN, each of which contains key data C associated with challenge data CH2. EC , first time data EXP, a key identifier ID, and a cryptographic key KRand encoded in a format suitable for a white-box implementation (denoted wb[KRand]). In other words, the token TN differs from the one described with reference to Figure 7 in that it also contains, in association with the other elements already listed, a key KRand encoded in a format suitable for a white-box implementation. This key KRand is therefore itself defended to protect against any attacks.

[0161] Each key data C EC The key KRand associated with is, for example, a random key.

[0162] It is then assumed that the terminal DV1 and the second device DV2 perform both steps S42 to S50 and steps S10, S12 as already explained above with reference to FIG.

[0163] Then, during a decision step S86, the terminal DV1 receives the encryption key K in its decrypted form (plain text). EC To achieve this, the terminal DV1 determines the encrypted encryption key D ECThe terminal DV1 performs the decryption by executing the decryption algorithm pdec in a white-box implementation based on the encryption key KRand of the plaintext (obtained in S12) and based on the key KRand in a white-box implementation extracted from the selected token TN in S44. In other words, the terminal DV1 performs the decryption by executing the decryption algorithm pdec in a white-box implementation based on the encryption key KRand of the plaintext (obtained in S12) and based on the key EC To generate the output, the encrypted encryption key D EC and a white-box implementation wb[KRand] of the key KRand as input and executes a white-box implementation wb[pdec] of the decryption algorithm pdec.

[0164] encryption key K EC Once (in its decoded form) has been determined, the terminal DV1 and the second device DV2 continue the processing method by performing steps S16, S18, S60, S20 to S26 as already described with reference to FIG. 7.

[0165] This variant therefore also provides a number of keys KRand in a white-box implementation in the token TN, which allows further defence of the processing method of the invention.

[0166] Furthermore, it should be noted that the order in which the steps of the processing method as previously described with reference to Figures 6 to 8 follow one another constitutes merely one exemplary embodiment, and variations thereof are possible.

[0167] Those skilled in the art will understand that the above-described embodiments and variations constitute merely non-limiting examples of implementations of the present invention. In particular, those skilled in the art can envision any adaptation or combination of the above-described embodiments and variations, in accordance with the claims presented below. [Explanation of symbols]

[0168] 2. First Device 4 Secondary Device 8 vehicles 10 processors 12 Volatile Memory 14 Non-volatile memory 16 Non-volatile memory 20 processors 22 Volatile Memory 24 Non-volatile memory 26 Non-volatile memory AL1 encryption algorithm ALp cryptographic algorithm ANS1 Answer Data ANS1a answer data CEC key material CH0 Challenge Data CH1 First Challenge Data CH2 Second Challenge Data DEC encryption key DT1 First Data DT2 Second Data DV1 First Device DV2 Second Device E. Environment EXP First time data F1 cryptographic masking function F2 cryptographic unmasking function F3 function INT1 communication interface INT2 communication interface K1 masking key K2 Unmasking key KEC encryption key KRand encryption key MD2~MD18 modules MK Master Encryption Key PG1 Computer Program PG2 Computer Program PKm public key RP0 Answer RP0a Answer S10~S86 steps SKm private key SV1 Remote Server SY1 System TK key TN Token TN1~TN20 tokens UR User pdec decoding algorithm penc encryption algorithm wb[pdec] White-box implementation

Claims

1. A processing method implemented by a first device (DV1) cooperating with a second device (DV2), comprising: a) receiving (S2) first data (DT1) including first challenge data (CH1) from the second device; b) the encrypted encryption key (D) obtained from the encryption by the first encryption algorithm (penc); EC ) including key data (C EC ) (S4), wherein the key data is masked by performing a cryptographic masking function (F1) based on the encrypted encryption key and a masking key (K1); c) receiving an unmasking key (K2) from the second device (S10); d) performing a cryptographic unmasking function (F2) based on the key data obtained in b) and the unmasking key (K2) received in c) to obtain the encrypted cryptographic key (D EC ) (S12); e) the encrypted encryption key (D EC ), a decrypted encryption key (K EC ) (S14), wherein the first encryption algorithm (penc) and the first decryption algorithm (pdec) are associated cryptographic algorithms configured to perform an inverse cryptographic function; f) the decrypted encryption key (K EC ) and the received first challenge data (CH1), determining answer data (ANS1) by a cryptographic operation by executing a predetermined cryptographic algorithm (ALp) (S16); g) in response to the first data (DT1) received in a), transmitting the answer data (ANS1) to the second device to have the second device authenticate the first device (S18); A processing method comprising:

2. The method of claim 1 , wherein the first encryption algorithm (penc) and the first decryption algorithm (pdec) are different from the default encryption algorithm (ALp).

3. c) before receiving said unmasking key (K2), h) transmitting second data (DT2) including second challenge data (CH2) to said second device; 3. The method of claim 1, further comprising: wherein the unmasking key (K2) received from the second device in c) is calculated based on the second challenge data.

4. h) before i) obtaining a token (TN), said token (TN) comprising: - said key data (C EC )and, - the encryption key (K EC a first time data (EXP) indicating a validity period during which the - an identifier (ID) of said encryption key that can be used during said validity period; Including, getting and wherein the second data (DT2) transmitted in h) comprises the first time data (EXP) and the identifier (ID) extracted from the token.

5. j) selecting the token obtained in i) from among one or more tokens accessible by the first device based on second time data (EXPmin) included in the first data (DT1) received in a); 5. The method of claim 4, further comprising: wherein the second time data indicates a validity period during which the cryptographic key of the selected token must be valid.

6. i) the token obtained further comprises second challenge data (CH2) distinct from the first time data (EXP) and the identifier (ID); 6. The method of claim 4, wherein the second data (DT2) transmitted in h) comprises the second challenge data (CH2) extracted from the token.

7. The method according to claim 4 or 5, wherein the first time data (EXP) and the identifier (ID) included in the second data (DT2) transmitted in step h) constitute the second challenge data.

8. The token (TN) further comprises a key encoded in a format suitable for white-box implementation (wb[KRand]); In e), the decrypted encryption key (K EC ) is the encrypted encryption key (D EC 8. The method of claim 4, wherein the value of the first decryption algorithm (pdec) is determined by decoding by running the first decryption algorithm (pdec) in a white-box implementation based on the token (wb[KRand]) and based on the key extracted from the token and encoded in a format suitable for the white-box implementation (wb[KRand]).

9. A method according to any one of claims 1 to 8, wherein said cryptographic masking and unmasking functions (F1, F2) are associated encryption and decryption functions, respectively.

10. 10. The method of claim 9, wherein the cryptographic masking and unmasking functions (F1, F2) are symmetric encryption functions, and the masking key (K1) and the unmasking key (K2) are identical.

11. 11. The method according to claim 9 or 10, wherein the cryptographic masking and unmasking functions (F1, F2) are XOR functions.

12. Following g), k) triggering a predefined function in cooperation with the second device in response to detecting that the second device has successfully authenticated the first device. The method according to any one of claims 1 to 11, comprising:

13. A computer program (PG1) comprising instructions for performing the steps of the method according to any one of claims 1 to 12 when the program is executed by a computer.

14. A first device (DV1) capable of cooperating with a second device (DV2), a first receiving module (MD2) adapted to receive from said second device first data (DT1) comprising first challenge data (CH1); the encrypted encryption key (D) obtained from the encryption by the first encryption algorithm (penc); EC ) including key data (C EC an acquisition module (MD4) configured to obtain the key data, wherein the key data is masked by executing a cryptographic masking function (F1) based on the encrypted encryption key and a masking key (K1); a second receiving module (MD6) adapted to receive an unmasking key (K2) from said second device; The obtained key data (C EC ) and the received unmasking key (K2) by performing a cryptographic unmasking function (F2) to obtain the encrypted cryptographic key (D EC a first determination module (MD8) configured to determine - the encrypted encryption key (D EC ), a decrypted encryption key (K EC a second determination module (MD10) configured to determine a first encryption algorithm (penc) and a first decryption algorithm (pdec), wherein the first encryption algorithm (penc) and the first decryption algorithm (pdec) are associated cryptographic algorithms configured to perform an inverse cryptographic function; - the decrypted encryption key (K EC a third determination module (MD12) configured to determine answer data (ANS1) by a cryptographic operation by executing a predetermined cryptographic algorithm (ALp) based on the received first challenge data (CH1) and the received first challenge data (CH1); a transmitting module configured to transmit, in response to the received first data (DT1), the answer data (ANS1) to the second device to cause the second device to authenticate the first device; A first device (DV1) including:

Images