EP4631210A1 - Procédés d'authentification mutuelle, dispositif électronique, système et programmes d'ordinateur associés - Google Patents

Procédés d'authentification mutuelle, dispositif électronique, système et programmes d'ordinateur associés

Info

Publication number
EP4631210A1
EP4631210A1 EP23786010.1A EP23786010A EP4631210A1 EP 4631210 A1 EP4631210 A1 EP 4631210A1 EP 23786010 A EP23786010 A EP 23786010A EP 4631210 A1 EP4631210 A1 EP 4631210A1
Authority
EP
European Patent Office
Prior art keywords
authentication
electronic device
key
public key
sending
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP23786010.1A
Other languages
German (de)
English (en)
Inventor
Emmanuelle Dottax
Luk Bettale
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Idemia France SAS
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 Idemia France SAS filed Critical Idemia France SAS
Publication of EP4631210A1 publication Critical patent/EP4631210A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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/3271—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 challenge-response
    • H04L9/3273—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 challenge-response for mutual authentication

Definitions

  • the present invention relates to the field of computer cryptography. It relates more particularly to mutual authentication methods, as well as an electronic device, a system and associated computer programs.
  • each party of the communication announces a public key, and proves that it possesses the private key which accompanies the public key by sending to the other party a cryptographic signature produced with the private key. If the signature can be verified with the public key, then the correct private key was used and the party that sent the signature is legitimate.
  • Such a mutual authentication process is for example specified by the GSMA association in the ‘RSP Technical Specification’ document, typically in its version 2.3 dated 06/30/2021.
  • Such a mutual authentication method is for example implemented by equipment from a telephone operator network and an electronic device, typically a secure element of the eUICC type (for “embedded Universal Integrated Circuit Card” in Anglo-Saxon terminology ) integrated into a communications terminal.
  • eUICC embedded Universal Integrated Circuit Card
  • Certain post-quantum cryptographic algorithms were proposed during a competition organized by the NIST (“National Institute of Standards and Technology”), notably post-quantum cryptographic signature mechanisms, and post-quantum key encapsulation mechanisms or post-quantum KEM (for “Key Encapsulation Mechanism”).
  • a key encapsulation mechanism allows a secret to be securely transmitted to an interlocutor using asymmetric cryptographic algorithms.
  • a key encapsulation mechanism between two parties proposes that the first party uses the public key of the other party and the encapsulation function of the key encapsulation mechanism, to generate a random secret and an encrypted one of this secret.
  • the encrypted one is transmitted to the other party who can, by deencapsulation using its private key, recover the secret, thus shared.
  • Post-quantum signatures require phenomenal sizes of keys and/or phenomenal sizes of intermediate variables, and are therefore highly consuming of RAM.
  • the present invention relates to a method of mutual authentication between an electronic device and a system, the electronic device having a private key associated with a public key, the system having another private key associated with another public key, and the method comprising: i) a system authentication phase comprising the following steps:
  • the calculation by the system of the first authentication result is by application to a reference data including the authentication challenge, of a cryptographic signature function with the other private key
  • the step of authentication of the system by the electronic device is by application to the first authentication result and to the reference data including the authentication challenge, of a cryptographic signature verification function with the other public key ,
  • the authentication data and a shared secret are determined by the system by application to the public key of an encapsulation function of a key encapsulation mechanism
  • the system authentication step is by application to the first authentication result and to reference data including the authentication challenge, of a cryptographic signature verification function with the other public key, - the calculation of the second authentication result uses a shared secret obtained by applying to the private key and the authentication data, a de-encapsulation function of a key encapsulation mechanism.
  • the method according to this first aspect may also include the following optional characteristics, taken alone or in combination whenever technically possible.
  • the private key, the public key, the other private key and the other public key are static keys, that is to say that each of these keys is used for several iterations of the process.
  • the private key, the public key, the other private key and the other public key are therefore not ephemeral keys, ephemeral keys being keys that are generated for a specific iteration and are only valid for that iteration.
  • the calculation of the second authentication result includes the calculation of the shared secret by application to the private key and to the authentication data, of a de-encapsulation function of the key encapsulation mechanism, then obtaining a key derived from the shared secret, then calculating an authentication code of input data with the derived key, the second authentication result being the calculated authentication code.
  • Each sending step and each receiving step includes synchronous communication between the electronic device and the system.
  • the authentication challenge is different at each iteration of the process.
  • the electronic device determines the authentication challenge by random drawing or by incrementing a counter.
  • the reference data is the concatenation of the authentication data and the authentication challenge.
  • the derived key is obtained by applying to the shared secret or the result of a concatenation of the shared secret and the authentication challenge, a key derivation function.
  • a secure channel is established from the derived key for subsequent data exchanges between the electronic device and the system.
  • the method further comprises a step of receiving from the system or a step of sending to the system, encrypted and/or authenticated data, with at least one exchange key calculated from the derived key.
  • the system authentication phase further includes the following steps:
  • the authentication phase of the electronic device further comprises the following step:
  • the method further comprises the following steps:
  • the step of receiving a certificate of the other public key from the system includes decryption with the other key derived from data issued by the system.
  • the authentication challenge is the cipher corresponding to the other shared secret or the cipher of the data including the public key certificate.
  • an authentication phase of the electronic device comprising the following steps:
  • the electronic device authentication step uses the shared secret and the second authentication result.
  • the method according to this second aspect may also include the following optional characteristics, taken alone or in combination whenever technically possible.
  • the private key, the public key, the other private key and the other public key are static keys, that is to say that each of these keys is used for several iterations of the process.
  • the private key, the public key, the other private key and the other public key are therefore not ephemeral keys, ephemeral keys being keys which are generated for a specific iteration and are only valid for this iteration.
  • the step of authenticating the electronic device comprises obtaining a key derived from the shared secret, then comparing candidate data and expected data, the candidate data being the second authentication result and the expected data being obtained by encryption with the key derived from input data, or the expected data being input data and the candidate data being obtained by decryption with the key derived from the second authentication result.
  • the step of authenticating the electronic device comprises obtaining a key derived from the shared secret, then comparing candidate data and expected data, the candidate data being the second authentication result and the data expected being obtained by calculating an authentication code of an input data with the derived key, for example an authentication code based on the hash or an authentication code based on the encryption or an authentication code of Galois.
  • the electronic device is authenticated if the candidate data and the expected data are identical.
  • Each sending step and each receiving step includes synchronous communication between the electronic device and the system.
  • the authentication challenge is an anti-replay challenge.
  • the authentication challenge is different at each iteration of the process.
  • the electronic device determines the authentication challenge by random drawing or by incrementing a counter.
  • the reference data is the concatenation of the authentication data and the authentication challenge.
  • the derived key is obtained by applying to the shared secret or the result of a concatenation of the shared secret and the authentication challenge, a key derivation function.
  • a secure channel is established from the derived key for subsequent data exchanges between the electronic device and the system.
  • the method further comprises a step of receiving from the electronic device or a step of sending to the electronic device, encrypted and/or authenticated data, with at least one exchange key calculated from the derived key.
  • the system authentication phase also includes the following step:
  • the authentication phase of the electronic device further comprises the following steps:
  • the method further comprises the following steps:
  • the data comprising the certificate of the other public key is the certificate of the other public key, or the result of a concatenation of the certificate of the other public key and the first authentication result, or the result of a concatenation of the certificate of the other public key and the authentication data, or the result of a concatenation of the certificate of the other public key, of the first authentication result and of the authentication data.
  • a computer program comprising instructions executable by a processor and adapted for the implementation of a mutual authentication method as defined previously according to the first aspect, when these instructions are executed by the processor.
  • a computer program comprising instructions executable by a processor and adapted for the implementation of a mutual authentication method as defined previously according to the second aspect, when these instructions are executed by the processor.
  • an electronic device comprising means adapted for the implementation of a mutual authentication method as defined previously according to the first aspect.
  • a second module configured to carry out an authentication phase of the electronic device which includes the following steps:
  • the electronic device being characterized in that:
  • the first module is configured to carry out the system authentication step by applying to the first authentication result and to reference data comprising the authentication challenge, a cryptographic signature verification function with the other public key,
  • This electronic device can be configured for the implementation of each of the possibilities of realization envisaged for the mutual authentication method as defined previously according to the first aspect.
  • a system comprising means adapted for the implementation of a mutual authentication method as defined previously according to the second aspect.
  • the invention relates in particular to a system adapted to cooperate with an electronic device having a private key associated with a public key, the system comprising a memory storing another private key associated with another public key, and the system further comprising : i) a first module, configured to carry out a system authentication phase which includes the following steps:
  • a second module configured to carry out an authentication phase of the electronic device which comprises the following steps:
  • the first module is configured to calculate the first authentication result by application to reference data including the authentication challenge, of a cryptographic signature function with the other private key,
  • the second module is configured to determine the authentication data and a shared secret by applying to the public key an encapsulation function of a key encapsulation mechanism, and to carry out the authentication step of the electronic device using the shared secret and the second authentication result.
  • This system can be configured for the implementation of each of the possibilities of realization envisaged for the mutual authentication method as defined previously according to the second aspect.
  • Figure 1 schematically represents the main elements of an electronic device and a system within which the invention is implemented
  • Figure 2 represents in flowchart form the main steps of a mutual authentication method according to a first mode of implementation of the invention
  • Figure 3 represents in flowchart form the main steps of a mutual authentication method according to a second mode of implementation of the invention.
  • Figure 1 schematically represents the main elements of an electronic device 10 and a system 20 within which the invention is implemented.
  • the electronic device 10 and the system 20 are capable of cooperating, in particular to implement a mutual authentication process between the electronic device 10 and the system 20.
  • the electronic device 10 has a private key associated with a public key (not shown).
  • the private key and the public key are NTRU keys as described on the NTRU site - a submission to the NIST post-quantum standardization effort, https://ntru.org/.
  • the private key and the public key are static keys, that is to say that each of these keys is used for the implementation of several iterations of a mutual authentication method according to the invention (typically one of the processes described with reference to Figures 2 and 3).
  • the private key and the public key are therefore not ephemeral keys, ephemeral keys being keys that are generated for a specific iteration and are only valid for that iteration.
  • the other private key and the other public key are RSA or ECDS A keys as described in the document FIPS PUB 186-4, Digital Signature Standard, from Information Technology Laboratory National Institute of Standards and Technology, and dated July 2013, https://nvlpubs.nist.gov/nist- pubs/FIPS/NISTFIPS.186-4.pdf.
  • the other private key and the other public key are Crystal s-Dilithium keys as described on the site Crystals - Cryptography Suite for Algebraic Lattices, https://pq-crystals. org/dilithium/.
  • the other private key and the other public key are Falcon keys as described on the Falcon - Fast-Fourier Lattice-based Compact Signatures over NTRU website, https://falcon-sign.info/.
  • the other private key and the other public key are Sphincs+ keys as described on the Sphincs+ Stateless hash-based signatures site, https://sphincs. org/.
  • the other private key and the other public key are LMS or XMSS keys as described in the document NIST SP 800-208, Recommendation for stateful Hash-Based signature Schemes, from the National Institute of Standards and Technology , and dated October 2020, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf
  • the private key and the public key can be of a different type from the other private key and the other public key.
  • the private key and the public key can be NTRU keys while the other private key and the other public key are Crystals-Kyber keys.
  • the other private key and the other public key are static keys, that is to say that each of these keys is used for the implementation of several iterations of a mutual authentication method according to the invention (typically one of the processes described with reference to Figures 2 and 3).
  • the other private key and the other public key are therefore not ephemeral keys, ephemeral keys being keys which are generated for a specific iteration and are only valid for this iteration.
  • Figure 1 thus schematically represents an electronic device 10 comprising a processor 4 (for example a microprocessor), a storage block 6, a RAM 8 and a communication block 2.
  • processor 4 for example a microprocessor
  • storage block 6 for example a hard disk drive
  • RAM 8 for example a hard disk drive
  • the RAM 8 and the storage block 6 are each linked to the processor 4 so that the processor 4 can read or write data in the storage block 6 and/or the RAM 8.
  • the storage block 6 stores computer program instructions, some of which are designed to implement a mutual authentication method such as at least one of those described with reference to Figures 2 and 3, in particular in cooperation with the system 20, when these instructions are executed by the processor 4.
  • the storage block 6 is for example in practice a hard disk or a non-volatile memory, possibly rewritable, for example of the EEPROM type (for "Electrically Erasable and Programmable Read -Only Memory" according to the commonly used Anglo-Saxon name).
  • the RAM 8 can memorize at least some of the elements (in particular an authentication challenge, an authentication data, a first authentication result and/or a second authentication result as described below in reference to Figures 2 and 3) handled during the different treatments carried out during at least one of the processes described below.
  • the storage block 6, and/or the RAM 8 can store the private key and/or the public key and/or a certificate of the public key.
  • Memory in the remainder of the description is any one of the storage block 6 and the RAM 8.
  • the electronic device 10 also includes several modules not shown. Typically, the electronic device 10 comprises a first module configured to carry out an authentication phase of the system 20, and a second module configured to carry out an authentication phase of the electronic device 10. The electronic device 10 may also include a third module for confidentiality.
  • modules can in practice be produced by a combination of hardware elements and software elements.
  • Each module among the first module and the second module is configured to carry out the steps of a phase described in the methods according to the invention and explained below, and therefore has a functionality described in the methods according to the invention and presented below.
  • the third module for confidentiality is configured to perform other steps described with reference to Figure 3.
  • the electronic device 10 memorizes for example software instructions executable by the processor 4 in order to use a hardware element (for example a communication block or a memory) and thus implement the functionality offered by the module.
  • a hardware element for example a communication block or a memory
  • the computer program instructions stored in the storage block 6 were received (for example from a remote computer) during an operating phase of the electronic device 10 prior to the methods described with reference to the figures 2 and 3.
  • the communication block 2 is connected to the processor 4 so as to allow the processor 4 to receive data m from the system 20, for example a first authentication result and an authentication data such as described with reference to Figures 2 and 3, and/or to transmit data m to the system 20, for example an authentication challenge and a second authentication result as described with reference to Figures 2 and 3.
  • the electronic device can take many forms (not shown).
  • the electronic device is a smart card, such as an identity card, a bank card or a universal integrated circuit card (also known as a UICC card for “Universal Integrated Circuit Card” in Anglo-Saxon terminology).
  • the electronic device is a secure element, such as a secure microcontroller which is integrated into another electronic device, typically a communication terminal or a car.
  • the electronic device is a USB key, or an identity document, such as an electronic passport.
  • Figure 1 also schematically represents system 20.
  • the system 20 includes a processor 14 (for example a microprocessor), a storage block 16, a RAM 18 and a communication block 12.
  • a processor 14 for example a microprocessor
  • storage block 16 for example a hard disk drive
  • RAM 18 for example a hard disk drive
  • communication block 12 for example a wireless local area network
  • the storage block 16 stores computer program instructions, some of which are designed to implement a mutual authentication method such as at least one of those described with reference to Figures 2 and 3, in particular in cooperation with the electronic device 10, when these instructions are executed by the processor 14.
  • the RAM 18 can memorize at least some of the elements (in particular an authentication challenge, an authentication data, a first authentication result and/or a second authentication result as described below in reference to Figures 2 and 3) handled during the different treatments carried out during at least one of the processes described below.
  • the storage block 16, and/or the RAM 18, can store the other private key and/or the other public key and/or a certificate of the other public key.
  • Memory in the remainder of the description is any one of the storage block 16 and the RAM 18.
  • System 20 also includes several modules not shown.
  • the system 20 comprises a first module configured to carry out an authentication phase of the system 20, and a second module configured to carry out an authentication phase of the electronic device 10.
  • the system 20 may also include a third module for confidentiality .
  • modules can in practice be produced by a combination of hardware elements and software elements.
  • Each module among the first module and the second module is configured to carry out the steps of a phase described in the methods according to the invention and explained below, and therefore has a functionality described in the methods according to the invention and presented below.
  • the third module for privacy is configured to perform further steps described with reference to Figure 3.
  • the system 20 memorizes for example software instructions executable by the processor 14 in order to use a hardware element (for example a communication block or a memory) and thus implement the functionality offered by the module .
  • a hardware element for example a communication block or a memory
  • the computer program instructions stored in the storage block 16 were received (for example from a remote computer) during an operating phase of the system 20 prior to the methods described with reference to the figures 2 and 3.
  • the communication block 12 is connected to the processor 14 so as to allow the processor 14 to receive data n from the electronic device 10, for example an authentication challenge and a second authentication result as described with reference to the figures 2 and 3, and/or to transmit data n to the electronic device 10, for example a first authentication result and authentication data as described with reference to Figures 2 and 3.
  • the system can take many forms (not shown) such as a server, a communications terminal, a computer or electronic equipment of a telecommunications network.
  • Figure 2 represents in flowchart form the main steps of a mutual authentication method according to a first mode of implementation of the invention.
  • This method is implemented by the electronic device 10, the electronic device 10 having a private key associated with a public key and cooperating with the system 20, and by the system 20, the system 20 having another private key associated with another public key and cooperating with the electronic device 10.
  • the electronic device 10 has the private key in at least one of its memories, and the system 20 has the other private key in at least one of its memories.
  • the electronic device 10 may have the public key in at least one of its memories
  • the system 20 may have the other public key in at least one of its memories.
  • step E200 the system 20 sends to the electronic device 10 a certificate of the other public key, typically using its communication block 12.
  • the electronic device 10 receives the certificate of the other public key from the system 20, typically using its communication block 2.
  • the method then includes a certificate verification step (step E220) during which the electronic device 10 verifies the validity of the certificate of the other public key received.
  • the method allows the electronic device to ensure that the other public key and the other private key was issued by an entity validated by a trusted authority.
  • the electronic device can thus associate the other public key with the system and ensure the validity of said other public key.
  • the certificate of the other public key may consist of the concatenation of the other public key and a cryptographic signature of said other public key, for example produced with a private certification key issued by a trusted authority.
  • the certificate of the other public key may consist of a chain of certificates, one of which comprises the concatenation of the other public key and a cryptographic signature of said other public key, for example produced with a key private of intermediate certification issued by an intermediate authority, the intermediate authority being validated by a trusted authority via said chain of certificates.
  • the electronic device 10 can then verify the certificate of the other public key received, by verifying said signature with a public certification key associated with the private certification key.
  • the electronic device 10 has the public certification key, for example in one of its memories.
  • the electronic device 10 has previously received the public certification key (for example from a remote computer) during an operating phase of the electronic device 10 prior to the method described here.
  • step E300 the electronic device 10 determines an authentication challenge.
  • the authentication challenge is data from which the system 20 will calculate a response with the other private key.
  • the authentication challenge is not a cryptographic key and is not used as such.
  • the method limits the demand on the resources of the electronic device.
  • the authentication challenge is an anti-replay challenge.
  • the authentication challenge is different at each iteration of the process.
  • the electronic device can for example determine the authentication challenge by random drawing or by incrementing a counter.
  • the method thus secures mutual authentication against replay attacks while limiting the processing implemented by the electronic device.
  • the method then includes a step of sending the authentication challenge to the system (step E310), during which the electronic device 10 sends the authentication challenge to the system 20, typically using its communication block 2.
  • the method then comprises a step of receiving the authentication challenge from the electronic device (step E320) during which the system 20 receives the authentication challenge from the electronic device, typically using its communication block 12.
  • the method then comprises a step of calculating a first authentication result (step E330) during which the system 20 calculates said first authentication result according to the authentication challenge and the other private key.
  • the system 20 calculates the first authentication result by application to reference data comprising the authentication challenge, of a cryptographic signature function with the other private key.
  • the first result is typically a signature with the other private key of the reference data.
  • the reference data is determined by the system from the authentication challenge received from the electronic device.
  • the signature function is as described in this document.
  • the method implemented by the system thus invokes a cryptographic signature function rather than a deencapsulation function of a key encapsulation mechanism for system authentication.
  • the method then comprises a step of sending the first authentication result to the electronic device (step E340), during which the system 20 sends the first authentication result to the electronic device 10, typically using its communication block 12.
  • the method then comprises a step of receiving the first authentication result from the system (step E350), during which the electronic device 10 receives the first authentication result from the system 20, typically using its communication block 2 .
  • the method then includes a system authentication step (step E360), during which the electronic device 10 authenticates the system 20 with the authentication challenge, the first authentication result and the other public key.
  • the electronic device 10 authenticates the system 20 by applying to the first authentication result and to another reference data including the authentication challenge, a cryptographic signature verification function with the other public key.
  • the other reference data is determined by the electronic device from the authentication challenge sent to the system.
  • the reference data and the other reference data must respectively be determined according to a similar algorithm by the system 20 and the electronic device 10. For example, when the reference data is the authentication challenge received by the system from the electronic device, the other reference data is the authentication challenge sent to the system by the electronic device.
  • the cryptographic signature verification function is a cryptographic function phical associated with the signature function used by the system during the step of calculating a first authentication result (step E330).
  • the method implemented by the electronic device thus invokes a cryptographic signature verification function rather than an encapsulation function of a key encapsulation mechanism for system authentication.
  • the method thus limits the demand on the resources of the electronic device.
  • the step of sending certificate to the electronic device (step E200), the step of receiving certificate from the system (step E210), the step of verifying certificate (step E220), the step of determining an authentication challenge (step E300), the step of sending the authentication challenge to the system (step E310), the step of receiving the authentication challenge from the electronic device (step E320), the the step of calculating a first authentication result (step E330), the step of sending the first authentication result to the electronic device (step E340), the step of receiving the first result from the system
  • the authentication (step E350), and the system authentication step (step E360) are in a system authentication phase (PI phase).
  • This system authentication phase is typically implemented by the first module of the system 20 and the first module of the electronic device 10.
  • the first module of the system 20 can thus implement the step of sending a certificate to the electronic device (step E200), the step of receiving the authentication challenge from the electronic device (step E320), the step calculating a first authentication result (step E330) and the step of sending the first authentication result to the electronic device (step E340).
  • the first module of the electronic device 10 can implement the step of receiving a certificate from the system (step E210), the step of verifying the certificate (step E220), the step of determining an authentication challenge (step E300), the step of sending the authentication challenge to the system (step E310), the step of receiving the first authentication result from the system (step E350), and the authentication step of the system (step E360).
  • step E400 the electronic device 10 sends a certificate of the public key to the system 20, typically using its communication block 2.
  • the system 20 receives the public key certificate from the electronic device 10, typically using its communication block 12.
  • the method then includes another certificate verification step (step E420) during which the system 20 verifies the validity of the public key certificate received.
  • step E420 the system 20 verifies the validity of the public key certificate received. The security of the mutual authentication process is thus reinforced.
  • the method allows the system to ensure that the public key and the private key have been issued by an entity validated by a trusted authority.
  • the system can thus associate connect the public key to the electronic device and ensure the validity of said public key.
  • the public key certificate may consist of the concatenation of the public key and a cryptographic signature of said public key, for example produced with another private certification key issued by a trusted authority.
  • the public key certificate may consist of a chain of certificates, one of which includes the concatenation of the public key and a cryptographic signature of said public key, for example produced with another intermediate certification private key. issued by an intermediate authority, the intermediate authority being validated by a trusted authority via said chain of certificates.
  • the system 20 can then verify the public key certificate received, by verifying said signature with another public certification key associated with the other private certification key.
  • the system 20 has the other public certification key, for example in one of its memories.
  • the system 20 has previously received the other public certification key (for example from a remote computer) during an operating phase of the system 20 prior to the method described here.
  • the other public certification key for example from a remote computer
  • the other public certification key and the other private certification key may respectively be the public certification key and the private certification key described above.
  • step E500 the system 20 determines authentication data and a shared secret by application to the public key of an encapsulation function of an encapsulation mechanism of key.
  • the authentication data is the encryption of the shared secret.
  • encapsulation mechanism encapsulation functions are described in the references cited above for the examples of the private key and the public key.
  • the private key and the public key are RSA-KEM keys as described in RFC 5990: Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS), by Randall et al., dated from September 2010, https://www.rfc-editor.Org/rfc/rfc5990.html#appendix-A, the encapsulation function of the encapsulation mechanism is as described in this document.
  • CMS Cryptographic Message Syntax
  • the method implemented by the system thus invokes an encapsulation function of a key encapsulation mechanism rather than a cryptographic signature verification function for the authentication of the electronic device.
  • the method then comprises a step of sending the authentication data to the electronic device (step E510) during which the system 20 sends the authentication data to the electronic device 10, typically using its communication block 12.
  • the method then includes a step of receiving the authentication data (step E520), during which the electronic device 10 receives the authentication data from the system 20, typically using its communication block 2.
  • the method then comprises a step of calculating a second authentication result (step E530) during which the electronic device 10 calculates a second authentication result based on the authentication data and the private key.
  • the electronic device 10 calculates the second authentication result using a shared secret obtained by applying a deencapsulation function of the key encapsulation mechanism to the private key and the authentication data.
  • encapsulation mechanism deencapsulation functions are described in the references cited above for the examples of the private key and the public key.
  • the private key and the public key are RSA-KEM keys as described in RFC 5990: Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS), by Randall et al., dated from September 2010, https://www.rfc-editor.Org/rfc/rfc5990.html#appendix-A, the deencapsulation function of the encapsulation mechanism is as described in this document.
  • CMS Cryptographic Message Syntax
  • the calculation of the second authentication result comprises the calculation of the shared secret by application to the private key and to the authentication data, of a deencapsulation function of the key encapsulation mechanism, then the obtaining a key derived from the shared secret, then encryption with the key derived from input data, the second authentication result being the result of said encryption.
  • the derived key is used here as the encryption key.
  • the derived key may be obtained by applying a state-of-the-art key derivation function to the shared secret or to the result of a concatenation of the shared secret and the authentication challenge.
  • the derived key is the shared secret.
  • the shared secret allows the system to introduce a hazard at each iteration of the process in the calculation of the derived key.
  • the authentication challenge allows the electronic device to also introduce a hazard into the calculation of the derived key.
  • the calculation of the second authentication result comprises the calculation of the shared secret by application to the private key and to the authentication data, of a deencapsulation function of the key encapsulation mechanism, then the obtaining a key derived from the shared secret, then calculating an authentication code of input data with the derived key, for example an authentication code based on the hash as proposed in the NIST publication FIPS PUB198-1 “The Keyed-Hash Message Authentication Code” dated July 2008, or an encryption-based authentication code as proposed in publication NIST.SP.800-38B “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication” from NIST and dated May 2005, or a Galois authentication code as proposed in the publication NIST.SP.800-38D “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC” from NIST and dated November 2007.
  • the second authentication result is then the calculated authentication code.
  • the derived key is used
  • the derived key can be obtained by applying a state-of-the-art key derivation function to the shared secret or to the result of a concatenation of the shared secret and the authentication challenge. .
  • the derived key can, according to another example, be the shared secret.
  • the shared secret allows the system to introduce a hazard at each iteration of the process in the calculation of the derived key.
  • the authentication challenge allows the electronic device to also introduce a hazard into the calculation of the derived key.
  • the method implemented by the electronic device thus invokes a de-encapsulation function of a key encapsulation mechanism rather than a cryptographic signature function for the authentication of the electronic device.
  • the method thus limits the demand on the resources of the electronic device.
  • the method then comprises a step of sending the second authentication result to the system (step E540), during which the electronic device 10 sends the second authentication result to the system 20, typically using its communication block 2.
  • the method then comprises a step of receiving a second authentication result from the electronic device (step E550), during which the system 20 receives the second authentication result from the electronic device 10, typically using its block communication 12.
  • the method then comprises a step of authenticating the electronic device 10 (step E560), during which the system 20 authenticates the electronic device 10 with the second authentication result and the public key.
  • the system authenticates the electronic device using the shared secret (which was determined by the system 20 from the public key during the step of determining authentication data, that is to say step E500) and the second authentication result.
  • the step of authenticating the electronic device includes obtaining the key derived from starting from the shared secret, then comparing candidate data and expected data. The electronic device is authenticated if the candidate data and the expected data are identical.
  • the candidate data is the second authentication result and the expected data is obtained by encryption with the key derived from the input data, or the expected data is the input data and the candidate data is obtained by decryption with the key derived from the second authentication result.
  • the derived key is used as the key of encryption or decryption.
  • the input data can be any data known to the system 20 and the electronic device 10, for example the authentication challenge, the authentication data, the result of a concatenation of the authentication challenge and the authentication data.
  • authentication or other data previously received by the system 20 and the electronic device 10, typically during an operating phase of the electronic device 10 and the system 20 prior to the method described here.
  • the encryption or decryption operation executed here by the system 20 is according to a cryptographic algorithm, for example AES, associated with the encryption operation executed by the electronic device 10 during the step of calculating a second result of authentication (step E530).
  • a cryptographic algorithm for example AES
  • the derived key is obtained by the system 20 in a manner similar to its obtaining by the electronic device 10.
  • the system calculates the derived key by applying this derivation function to the shared secret determined during the step of determining authentication data (step E500).
  • the system calculates the derived key by applying this derivation function to the result of another concatenation of the shared secret and the authentication challenge, the shared secret having been determined during the step of determining authentication data (step E500 ) and the authentication challenge having been received during the reception step from the electronic device of the authentication challenge (step E320).
  • the derived key obtained by the electronic device is the shared secret determined during the step of calculating a second authentication result (step E530)
  • the derived key calculated by the system is the determined shared secret during the step of determining authentication data (step E500).
  • the step of authenticating the electronic device includes obtaining the key derived from from the shared secret, then comparing candidate data and expected data, the candidate data being the second authentication result and the expected data being obtained by calculating the authentication code of the input data with there derived key.
  • the derived key is used as a key for calculating the authentication code of the input data.
  • the electronic device is authenticated if the candidate data and the expected data are identical.
  • the input data can be any data known to the system 20 and the electronic device 10, for example the authentication challenge, the authentication data, the result of a concatenation of the authentication challenge and the authentication data.
  • authentication or other data previously received by the system 20 and the electronic device 10, typically during an operating phase of the electronic device 10 and the system 20 prior to the method described here.
  • the authentication code is obtained by the system 20 in a manner similar to its obtaining by the electronic device 10.
  • the system 20 determines the code d authentication as proposed in this publication.
  • the derived key is obtained by the system 20 in a manner similar to its obtaining by the electronic device 10.
  • the step of sending certificate to the system (step E400), the step of receiving certificate from the electronic device (step E410), the other step of verifying certificate (step E420), the determining step of authentication data (step E500), the step of sending the authentication data to the electronic device (step E510), the step of receiving the authentication data (step E520), the step of calculating a second authentication result (step E530), the step of sending the second authentication result to the system (step E540), the step of receiving a second result from the electronic device authentication (step E550), and the electronic device authentication step (step E560), are in an electronic device authentication phase (phase P2).
  • This phase of authentication of the electronic device is typically implemented by the second module of the system 20 and the second module of the electronic device 10.
  • the second module of the system 20 can thus implement the step of receiving a certificate from the electronic device (step E410), the other step of verifying the certificate (step E420), the step of determining a authentication data (step E500), the step of sending the authentication data to the electronic device (step E510), the step of receiving from the electronic device a second authentication result (step E550 ) and the step of authenticating the electronic device (step E560).
  • the second module of the electronic device 10 can implement the step of sending a certificate to the system (step E400), the step of receiving the authentication data (step E520), the step of calculating a second authentication result (step E530) and the step of sending the second authentication result to the system (step E540).
  • the method limits the demand on the resources of the electronic device.
  • the method implemented by the electronic device invokes a de-encapsulation function of a key encapsulation mechanism rather than a cryptographic signature function for the authentication of the electronic device, and a cryptographic signature verification function rather as an encapsulation function of a key encapsulation mechanism for system authentication.
  • the method implemented by the system invokes a cryptographic signature function rather than a de-encapsulation function of a key encapsulation mechanism for system authentication, and an encapsulation function of a key encapsulation mechanism.
  • key encapsulation rather than a cryptographic signature verification function for electronic device authentication.
  • the method implemented by the system thus allows the electronic device to invoke a de-encapsulation function of a key encapsulation mechanism rather than a cryptographic signature function for the authentication of the electronic device, and a function of cryptographic signature verification rather than a function of wrapping a key wrapping mechanism for system authentication.
  • the method is particularly suitable for mutual authentication between the electronic device and the system in the context of synchronous communication between said electronic device and said system.
  • each sending step (typically sending the authentication challenge to the system, sending the certificate to the system and sending the second authentication result to the system) and each reception step (typically reception of certificate from the system, reception from the system of the first authentication result and reception of the authentication data) implemented by the electronic device comprises synchronous communication between the device electronics and system.
  • each sending step (typically sending the certificate to the electronic device, sending the first authentication result to the electronic device and sending the authentication data to the electronic device ) and each reception step (typically reception from the electronic device of the authentication challenge, receipt of certificate from the electronic device and reception from the electronic device of a second authentication result) implemented by the system includes synchronous communication between the electronic device and the system.
  • each exchange between the electronic device 10 and the system 20 is direct and instantaneous.
  • the method then allows mutual authentication by synchronous communication while limiting the processing implemented by the electronic device.
  • a secure channel can be established from the derived key for subsequent exchanges of data between the electronic device and the system.
  • the method can then further comprise a reception step from the electronic device or a sending step to the electronic device (not shown), respectively a sending step to the system and a reception step from the system (not shown). ), encrypted and/or authenticated data, with at least one exchange key calculated from the derived key.
  • each step can be executed in other orders, to the extent that each step has the elements (for example the public key, the other public key, the authentication challenge, the first authentication result, the authentication data or the second authentication result) necessary for its execution.
  • elements for example the public key, the other public key, the authentication challenge, the first authentication result, the authentication data or the second authentication result
  • said electronic device has the elements necessary for the execution of the step concerned, and
  • the steps of the electronic device authentication phase can be executed before the steps of the system authentication phase (phase PI).
  • the step of sending a certificate to the system can be executed, for example in this order, before executing the step of sending a certificate to the device electronic (step E200), the step of receiving a certificate from the system (step E210), the certificate verification step (step E220), the step of determining an authentication challenge (step E300), the step of sending the authentication challenge to the system (step E310), the step of receiving the authentication challenge from the electronic device (step E320), the calculation step a first authentication
  • the execution of the steps of the authentication phase of the electronic device (phase P2) and the steps of the system authentication phase (phase PI) can be interleaved, the authentication phase of the electronic device and the system authentication phase thus taking place concomitantly.
  • step E300 determination of an authentication challenge
  • step E400 sending a certificate to the system
  • step E310 sending the authentication challenge to the system
  • step E500 determination of authentication data
  • step E330 calculation of a first authentication result
  • step E200 sending the first authentication result to the electronic device (step E340) and sending the authentication data to the electronic device (step E510), then
  • step E210 reception from the system of the first authentication result (step E350) and reception of the authentication data (step E520), then
  • step E560 - authentication of the electronic device
  • sending the certificate to the system (step E400) and sending the authentication challenge to the system (step E310), respectively receiving the certificate from the electronic device (step E410) and receiving the certificate from of the electronic device of the authentication challenge (step E320), can be executed simultaneously by grouping the public key certificate and the authentication challenge in the same message sent by the electronic device to the system.
  • sending the certificate to the electronic device (step E200) and sending the first authentication result to the electronic device (step E340) and sending the authentication data to the electronic device (step E510), respectively the receipt of certificate from the system (step E210) and the reception from the system of the first authentication result (step E350) and the reception of the authentication data (step E520), can be executed if- simultaneously by grouping the certificate of the other public key, the first authentication result and the authentication data in the same other message sent by the system to the electronic device.
  • the first module and the second module of the electronic device 10 can therefore cooperate for the implementation of steps of the method.
  • first module and the second module of the system 20 can therefore cooperate for the implementation of steps of the method.
  • the reference data can be the concatenation of the authentication data (calculated by the system during the step of determining an authentication data ) and the authentication challenge (received from the electronic device).
  • the other reference data is then the concatenation of the authentication data (received from the system) and the authentication challenge (determined by the electronic device and sent to the system).
  • the authentication phase of the electronic device and the authentication phase of the system are thus cryptographed! only related.
  • the security of the mutual authentication process is thus reinforced.
  • the step of sending a certificate to the electronic device (step E200), the step of receiving a certificate from the system (step E210) and the step of verifying the certificate (step E220) can be omitted when the electronic device 10 already has the other public key, typically when the electronic device 10 has previously received the other public key (for example from a remote computer or from the system 20) during an operating phase of the electronic device 10 prior to the process described here
  • the step of sending a certificate to the system (step E400), the step of receiving a certificate from the electronic device (step E410) and the other step of verifying the certificate (step E420) can be omitted when the system 20 already has the public key, typically when the system 20 has previously received the public key (for example from a remote computer or the electronic device 10) during an operating phase of the system 20 prior to the process described here.
  • FIG 3 represents in flowchart form the main steps of a mutual authentication method according to a second mode of implementation of the invention. This method is implemented by the electronic device 10, the electronic device 10 having a private key associated with a public key and cooperating with the system 20, and by the system 20, the system 20 having another private key associated with another public key and cooperating with the electronic device 10.
  • the electronic device 10 has the private key in at least one of its memories, and the system 20 has the other private key in at least one of its memories.
  • the electronic device 10 has a certificate of the public key in at least one of its memories
  • the system 20 has a certificate of the other public key in at least one of its memories.
  • step El 00 the system 20 sends to the electronic device 10 an ephemeral public key associated with an ephemeral private key, typically using its communication block 12.
  • the system 20 has the ephemeral public key and the ephemeral private key, typically in one of its memories.
  • the system 20 has previously received the ephemeral public key and the ephemeral private key (for example from a remote computer) during an operating phase of the system 20 prior to the method described here.
  • the system 20 has previously determined the ephemeral public key and the ephemeral private key during a step of determining ephemeral keys (not shown).
  • the ephemeral public key and the ephemeral private key are Crystals-Kyber keys as described on the Crystals site - Cryptography Suite for Algebraic Lattices, https://pq-crystals. org/kyber/index. shtml.
  • the ephemeral public key and the ephemeral private key are NTRU keys as described on the NTRU site - a submission to the NIST post-quantum standardization effort, https://ntru.org/.
  • the method then comprises a step of receiving the ephemeral public key from the system (step El 10), during which the electronic device 10 receives the ephemeral public key from the system 20, typically using its communication block 2.
  • the method then comprises a step of obtaining another shared secret, that is to say a shared secret different from the shared secret obtained and used during the authentication phase of the electronic device (see below) , and a corresponding cipher (step El 20), during which the electronic device 10 obtains said other shared secret and said corresponding cipher by application to the ephemeral public key of an encapsulation function of another encapsulation mechanism key, that is to say a key encapsulation mechanism which may be different from the encapsulation mechanism used during the authentication phase of the electronic device (see below).
  • the ephemeral public key allows the system to introduce a hazard which forces the use of a new other shared secret at each iteration of the process.
  • the application of the encapsulation function of the other key encapsulation mechanism allows the electronic device to introduce a hazard which also forces the use of a new other shared secret at each iteration of the process.
  • the method then comprises a step of obtaining another derived key (step E130), that is to say a derived key different from the derived key obtained and used during the authentication phase of the electronic device ( see below), during which the electronic device 10 obtains said other key derived from the other shared secret.
  • the other derived key may be obtained by applying a state-of-the-art key derivation function to the other shared secret.
  • the other derived key is the other shared secret.
  • the method then comprises a step of sending to the system the cipher corresponding to the other shared secret (step E140) during which the electronic device 10 sends to the system 20 the cipher corresponding to the other shared secret, typically using its block of communication 2.
  • the method then comprises a step of receiving from the electronic device the cipher corresponding to the other shared secret (step El 50) during which the system 20 receives from the electronic device 10 the cipher corresponding to the other shared secret, typically using its communication block 12.
  • the method then comprises a step of obtaining the other shared secret (step El 60) during which the system 20 obtains the other shared secret by application to the ephemeral private key and to the encrypted code received during the reception step from of the electronic device of the cipher corresponding to the other shared secret (step El 50), a deencapsulation function of the other key encapsulation mechanism.
  • the deencapsulation function of the other encapsulation mechanism is as described in this document.
  • the method then includes another step of obtaining the other derived key (step E170), during which the system 20 obtains the other key derived from the other shared secret.
  • the other derived key is obtained by the system 20 in a manner similar to its obtaining by the electronic device 10.
  • step E120 when the electronic device obtains the other key derived by applying a state-of-the-art key derivation function to the other shared secret determined during the step of obtaining another secret shared and a corresponding cipher (step E120), the system calculates the other key derived by application of this derivation function to the other shared secret determined during the step of obtaining the other shared secret (step El 60).
  • the third module of the system 20 can thus implement the step of sending an ephemeral public key to the electronic device (step E100), the step of receiving from the electronic device the cipher corresponding to the other secret shared (step E150), the step of obtaining the other shared secret (step E160) and the other step of obtaining the other derived key (step E170).
  • the third module of the electronic device 10 can implement the step of receiving the ephemeral public key from the system (step El 10), the step of obtaining another shared secret and a corresponding cipher (step E120), the step of obtaining another derived key (step E130) and the step of sending to the system the cipher corresponding to the other shared secret (step El 40).
  • step E401 the electronic device 10 sends the public key certificate to the system 20.
  • the electronic device 10 sends to the system 20 a result of an encryption with the other key derived from data comprising the certificate of the public key, typically using its communication block 2.
  • the system 20 receives the public key certificate from the electronic device 10, typically using its communication block 12. During this step, the system 20 receives from the electronic device 10 an encrypted data comprising the certificate of the public key, and decrypts with the other derived key data transmitted by the electronic device, that is to say said encrypted data including the public key certificate.
  • the decryption operation executed here by the system 20 is according to a cryptographic algorithm, for example AES, associated with the encryption operation executed by the electronic device 10 during the step of sending a certificate to the system (step E401).
  • AES a cryptographic algorithm
  • the mutual authentication process ensures the confidentiality of the public key certificate sent by the electronic device to the system.
  • the method thus allows the electronic device and the system to ensure the non-traceability of the electronic device.
  • the method then comprises a certificate verification step identical to the other certificate verification step of the first implementation mode (step E420).
  • the method then comprises a step of determining authentication data (step E500), a step of sending the authentication data to the electronic device (step E510), a step of receiving the authentication data (step E520), a step of calculating a second authentication result (step E530), a step of sending the second authentication result to the system (step E540), a step of receiving from the electronic device a second authentication result (step E550), and a step of authenticating the electronic device (step E560), identical to those described for the first implementation mode.
  • the step of sending certificate to the system (step E401), the step of receiving certificate from the electronic device (step E411), the step of verifying certificate (step E420), the step of determining authentication data (step E500), the step of sending the authentication data to the electronic device (step E510), the step of receiving the authentication data (step E520), the step calculating a second authentication result (step E530), the step of sending the second authentication result to the system (step E540), the step of receiving a second result from the electronic device
  • This phase of authentication of the electronic device is typically implemented by the second module of the system 20 and the second module of the electronic device 10.
  • the second module of the system 20 can thus implement the step of receiving a certificate from the electronic device (step E411), the step of verifying the certificate (step E420), the step of determining a piece of data authentication (step E500), the step of sending the authentication data to the electronic device (step E510), the step of receiving from the electronic device a second authentication result (step E550) and the device authentication step electronic (step E560).
  • the second module of the electronic device 10 can implement the step of sending a certificate to the system (step E401), the step of receiving the authentication data (step E520), the step of calculating a second authentication result (step E530) and the step of sending the second authentication result to the system (step E540).
  • step E201 the system 20 sends the certificate of the other public key to the electronic device 10.
  • the system 20 sends to the electronic device 10 a result of an encryption with the other key derived from data comprising the certificate of the other public key, typically using its communication block 12.
  • the electronic device 10 receives the certificate of the other public key from the system 20, typically using its communication block 2.
  • the electronic device 10 receives from the system 20 an encrypted data including the certificate of the other public key and decrypts with the other derived key a data transmitted by the system, that is to say said encrypted data including the certificate of the other public key.
  • the decryption operation executed here by the electronic device 10 is according to a cryptographic algorithm, for example AES, associated with the encryption operation executed by the system 20 during the step of sending the certificate to the electronic device (step E201) .
  • This cryptographic algorithm is preferably the same as that implemented during the step of sending a certificate to the system (step E401) and the step of receiving a certificate from the electronic device (step E411).
  • the mutual authentication process ensures the confidentiality of the certificate of the other public key sent by the system to the electronic device.
  • the method thus allows the electronic device and the system to ensure the non-traceability of the system.
  • the method then comprises another certificate verification step identical to the certificate verification step of the first implementation mode (step E220).
  • the method then comprises a step of determining an authentication challenge (step E300), a step of sending the authentication challenge to the system (step E310), a step of receiving the authentication challenge from the electronic device.
  • authentication step E320
  • a step of calculating a first authentication result step E330
  • a step of sending the first authentication result to the electronic device step E340
  • a step of receiving from the system of the first authentication result step E350
  • a system authentication step step E360
  • the step of sending the certificate to the electronic device (step E201), the receiving step certificate from the system (step E211), the other certificate verification step (step E220), the step of determining an authentication challenge (step E300), the step of sending the certificate to the system authentication challenge (step E310), the step of receiving the authentication challenge from the electronic device (step E320), the step of calculating a first authentication result (step E330), the step sending the first authentication result to the electronic device (step E340), the step of receiving the first authentication result from the system (step E350), and the step of authenticating the system (step E360) , are in a system authentication phase (PI phase).
  • PI phase system authentication phase
  • This system authentication phase is typically implemented by the first module of the system 20 and the first module of the electronic device 10.
  • the first module of the system 20 can thus implement the step of sending a certificate to the electronic device (step E201), the step of receiving the authentication challenge from the electronic device (step E320), the step calculating a first authentication result (step E330) and the step of sending the first authentication result to the electronic device (step E340).
  • the first module of the electronic device 10 can implement the step of receiving a certificate from the system (step E211), the other step of verifying the certificate (step E220), the step of determining a challenge of authentication (step E300), the step of sending the authentication challenge to the system (step E310), the step of receiving the first authentication result from the system (step E350), and the step of system authentication (step E360).
  • the method limits the demand on the resources of the electronic device.
  • the method implemented by the electronic device invokes a de-encapsulation function of a key encapsulation mechanism rather than a cryptographic signature function for the authentication of the electronic device, and a cryptographic signature verification function rather as an encapsulation function of a key encapsulation mechanism for system authentication.
  • the method implemented by the system invokes a cryptographic signature function rather than a de-encapsulation function of a key encapsulation mechanism for system authentication, and an encapsulation function of a key encapsulation mechanism.
  • key encapsulation rather than a cryptographic signature verification function for electronic device authentication.
  • the method implemented by the system thus allows the electronic device to invoke a de-encapsulation function of a key encapsulation mechanism rather than a cryptographic signature function for the authentication of the electronic device, and a function of cryptographic signature verification rather than a function of wrapping a key wrapping mechanism for system authentication.
  • This mutual authentication process ensures the confidentiality of the certificate of the public key sent by the electronic device to the system, and the confidentiality of the certificate of the other public key sent by the system to the electronic device.
  • the ephemeral public key allows the system to introduce a hazard which forces the use of a new other shared secret at each iteration of the process.
  • the application of the encapsulation function of the other key encapsulation mechanism allows the electronic device to introduce a hazard which also forces the use of a new other shared secret at each iteration of the process.
  • This process thus allows the electronic device and/or the system to ensure the non-traceability of the electronic device and the system.
  • the method implemented by the electronic device invokes the deencapsulation function of the key encapsulation mechanism only once, and the encapsulation function of the other key encapsulation mechanism only once.
  • the method limits exchanges between the electronic device and the system.
  • the method is particularly suitable for mutual authentication between the electronic device and the system in the context of synchronous communication between said electronic device and said system.
  • each sending step (typically sending to the system the cipher corresponding to the other shared secret, sending the authentication challenge to the system, sending the certificate to the system and sending the second authentication result to the system) and each reception step (typically reception from the system of the ephemeral public key, receipt of certificate from the system, reception from the system of the first result authentication and receipt of the authentication data) implemented by the electronic device comprises synchronous communication between the electronic device and the system.
  • each sending step (typically sending an ephemeral public key to the electronic device, sending a certificate to the electronic device, sending the first authentication result to the electronic device and sending the authentication data to the electronic device) and each reception step (typically the reception from the electronic device of the encrypted code corresponding to the other shared secret, the reception from the electronic device of the authentication challenge , receipt of certificate from the electronic device and receipt from the electronic device of a second authentication result) implemented by the system comprises synchronous communication between the electronic device and the system.
  • each exchange between the electronic device 10 and the system 20 is direct and instantaneous.
  • the method then allows mutual authentication by synchronous communication while limiting the processing implemented by the electronic device.
  • a secure channel can be established from the derived key for subsequent exchanges of data between the electronic device and the system.
  • the method can then further comprise a reception step from the electronic device or a sending step to the electronic device (not shown), respectively a sending step to the system and a reception step from the system (not shown). ), encrypted and/or authenticated data, with at least one exchange key calculated from the derived key.
  • the step (E340) of sending the first authentication result to the electronic device, and the step (E510) of sending the authentication data to the electronic device comprise encryption with the other key derived from the data to be sent.
  • the system 20 encrypts the first authentication result with the other derived key and then sends the encrypted first authentication result to the electronic device 10 .
  • the system 20 encrypts the authentication data with the other derived key and then sends the encrypted authentication data to the electronic device 10.
  • the mutual authentication process thus ensures the confidentiality of other data transmitted by the system.
  • the mutual authentication method ensures the confidentiality of the first authentication result and the authentication data, sent by the system to the electronic device.
  • the step of receiving the first authentication result from the system (step E350), and the step of receiving the authentication data (step E520), comprise the decryption with the other key derived from data issued by the system.
  • the electronic device 10 receives the cipher of the first authentication result from the system 20 then decrypts the cipher of the first authentication result with the other derived key. first authentication result to obtain the first authentication result.
  • the electronic device 10 receives the encryption of the authentication data from the system 20 then decrypts the encryption of the authentication data with the other derived key. authentication to obtain the authentication data.
  • decryption operations executed by the electronic device 10 are according to a cryptographic algorithm, for example AES, associated with the encryption operations executed by the system 20 during the step of sending the first authentication result (E340) to the electronic device, and the step of sending the authentication data to the electronic device (E510).
  • AES a cryptographic algorithm
  • These decryption and decryption operations can be according to the same cryptographic algorithm as that used for the encryption and decryption operations of the step of sending a certificate to the system (step E401) and of the step of receiving a certificate from of the electronic device (step E411), and/or the step of sending a certificate to the electronic device (step E201) and the step of receiving a certificate from the system (step E211).
  • each step can be executed in other orders, to the extent that each step has the elements (for example the public key, the other public key, the authentication challenge, the first authentication result, the authentication data or the second authentication result) necessary for its execution.
  • elements for example the public key, the other public key, the authentication challenge, the first authentication result, the authentication data or the second authentication result
  • said electronic device has the elements necessary for the execution of the step concerned, and
  • the steps of the system authentication phase can be executed before the steps of the electronic device authentication phase (P2 phase).
  • the step of sending a certificate to the electronic device can be executed, for example in this order, before executing the step of sending a certificate to the system (step E401), the step of receiving a certificate from the electronic device (step E411), the certificate verification step (step E420), the step of determining authentication data (step E500 ), the step of sending the authentication data to the electronic device (step E510), the step of receiving the authentication data (step E520), the step of calculating a second authentication result
  • phase P2 the execution of the steps of the authentication phase of the electronic device
  • phase PI the execution of the steps of the system authentication phase
  • step E300 determination of an authentication challenge
  • step E400 sending a certificate to the system
  • step E310 sending the authentication challenge to the system
  • step E500 determination of authentication data
  • step E330 calculation of a first authentication result
  • step E200 sending the first authentication result to the electronic device (step E340) and sending the authentication data to the electronic device (step E510), then
  • step E210 reception from the system of the first authentication result (step E350) and reception of the authentication data (step E520), then
  • step E560 - authentication of the electronic device
  • sending the certificate to the system (step E401) and sending the authentication challenge to the system (step E310), respectively receiving the certificate from the electronic device (step E411) and receiving coming from the electronic device of the authentication challenge (step E320), can be executed simultaneously by grouping the encrypted certificate of the public key and the authentication challenge in the same message sent by the electronic device to the system.
  • sending a certificate to the electronic device (step E201) and sending the first authentication result to the electronic device (step E340) and sending the authentication data to the electronic device (step E510), respectively the receipt of certificate from the system (step E211) and the reception from the system of the first authentication result (step E350) and the reception of the authentication data (step E520), can be executed simultaneously by grouping the encryption of the certificate of the other public key, the first authentication result (or encrypted sound) and the authentication data (or encrypted sound) in the same other message sent by the system to the electronic device.
  • the data comprising the certificate of the other public key can be, for example, the certificate of the other public key, or the result of a concatenation of the certificate of the other public key and the first authentication result , or the result of a concatenation of the certificate of the other public key and the authentication data, or the result of a concatenation of the certificate of the other public key, of the first authentication result and the data authentication.
  • the authentication challenge is the cipher corresponding to the other shared secret or the cipher of the data comprising the certificate of the public key.
  • the properties of the encapsulation function ensure that the other shared secret has a random value.
  • the other shared secret is different at each iteration of the process.
  • the cipher corresponding to the other shared secret and the cipher of the data including the public key certificate are therefore also different at each iteration of the process.
  • the step of obtaining another shared secret and a corresponding cipher (step E120) or the step of sending a certificate to the system (step E401) can be the step of determining an authentication challenge (step E300).
  • step of sending to the system the cipher corresponding to the other shared secret (step El 40) or the step of sending certificate to the system (step E401) can be the step of sending to the system of the authentication challenge (step E310).
  • step E150 the step of receiving from the electronic device the cipher corresponding to the other shared secret (step E150) or the step of receiving a certificate from the electronic device (step E411) can be the step of receiving in coming from the electronic device of the authentication challenge (step E320).
  • the method thus further limits the demand on the resources of the electronic device and the system and limits exchanges between the electronic device and the system.
  • the first module, the second module and the third module of the electronic device 10 can therefore cooperate for the implementation of steps of the method.
  • the first module, the second module and the third module of the system 20 can therefore cooperate for the implementation of steps of the method.
  • the reference data can be the concatenation of the authentication data (calculated by the system during the step of determining a authentication data) or encrypted sound, and the authentication challenge (received from the electronic device).
  • the other reference data is then the concatenation of the authentication data (or its encrypted data) received from the system, and the authentication challenge (determined by the electronic device and sent to the system).
  • the step of sending to the system the cipher corresponding to the other shared secret (step El 40) and the step of sending the certificate to the system (step E401), respectively the reception step from the electronic device of the cipher corresponding to the other shared secret (step E150) and the step of receiving certificate from the electronic device (step E411) can be executed simultaneously by grouping the cipher of the certificate of the public key and the cipher corresponding to the other shared secret in the same message sent by the electronic device to the system.
  • steps of this process can be omitted to the extent that the other steps have the elements (for example the integrity sums, the arithmetic integrity sums and/or the corrected integrity sums). necessary for their execution.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Lock And Its Accessories (AREA)

Abstract

L'invention concerne un procédé d'authentification mutuelle mis en œuvre par un dispositif électronique, le procédé comprenant : i) une phase (P1) d'authentification d'un système (20) comprenant: - la détermination (E300) et l'envoi (E310) d'un challenge d'authentification, puis - la réception (E350) d'un premier résultat d'authentification, puis - l'authentification (E360) d'un système par application au premier résultat d'authentification d'une fonction de vérification de signature cryptographique, et ii) une phase (P2) d'authentification du dispositif électronique (10) comprenant : - la réception (E520) d'une donnée d'authentification, puis - le calcul (E530) et l'envoi (E540) d'un deuxième résultat d'authentification, le calcul du deuxième résultat d'authentification utilisant un secret partagé obtenu par application à une clé privée du dispositif électronique et à la donnée d'authentification, d'une fonction de désencapsulation d'un mécanisme d'encapsulation de clé. L'invention concerne aussi un procédé d'authentification mutuelle associé, mis en œuvre par le système.

Description

Description
Titre de l’invention : Procédés d’authentification mutuelle, dispositif électronique, système et programmes d’ordinateur associés.
La présente invention concerne le domaine de la cryptographie informatique. Elle concerne plus particulièrement des procédés d’authentification mutuelle, ainsi qu’un dispositif électronique, un système et des programmes d’ordinateur associés.
De façon connue, dans un procédé d’authentification mutuelle par cryptographie asymétrique, chaque partie de la communication annonce une clé publique, et prouve qu'elle possède la clé privée qui accompagne la clé publique en envoyant à l’autre partie une signature cryptographique réalisée avec la clé privée. Si la signature peut être vérifiée avec la clé publique, alors la bonne clé privée a été utilisée et la partie qui a envoyé la signature est légitime.
Un tel procédé d’authentification mutuelle est par exemple spécifié par l’association GSMA dans le document ‘RSP Technical Specification’, typiquement dans sa version 2.3 en date du 30/06/2021.
Un tel procédé d’authentification mutuelle est par exemple mis en œuvre par un équipement d’un réseau d’opérateur téléphonique et un dispositif électronique, typiquement un élément sécurisé de type eUICC (pour «embedded Universal Integrated Circuit Card » en terminologie anglo-saxonne) intégré à un terminal de communication.
Cependant, l’émergence de calculateurs quantiques rend les mécanismes de signature asymétriques non sûrs. Il est donc souhaitable d’adapter le schéma traditionnel ci-dessus pour garantir la sécurité du procédé face à un attaquant disposant d’un calculateur quantique.
Certains algorithmes cryptographiques post-quantiques ont été proposés au cours d’une compétition organisée par le NIST (« National Institute of Standards and Technology » ou Institut national des normes et de la technologie), notamment des mécanismes post- quantiques de signature cryptographique, et des mécanismes post-quantiques d’encapsulation de clé ou post-quantum KEM (pour « Key Encapsulation Mechanism »).
Un mécanisme d’encapsulation de clé permet de transmettre de manière sûre un secret à un interlocuteur en utilisant des algorithmes cryptographiques asymétriques.
De façon connue, il comprend généralement deux fonctions:
- une fonction d’encapsulation, et
- une fonction de décapsulation ou désencapsulation.
Typiquement, un mécanisme d’encapsulation de clé entre deux parties propose que la première partie utilise la clé publique de l’autre partie et la fonction d’encapsulation du mécanisme d’encapsulation de clé, pour générer un secret aléatoire et un chiffré de ce secret. Le chiffré est transmis à l’autre partie qui peut, par désencapsulation à l’aide de sa clé privée, récupérer le secret, ainsi partagé. Les signatures post-quantiques requièrent des tailles phénoménales de clés et/ou des tailles phénoménales de variables intermédiaires, et sont donc fortement consommatrices de mémoire vive.
Des solutions post-quantiques d’authentification mutuelle par cryptographie asymétrique, dans lesquelles l’authentification de chaque partie est basée sur un mécanisme d’encapsulation de clé et non plus sur la signature d’une donnée préalablement reçue, ont été proposées et peuvent se substituer au procédé d’authentification mutuelle traditionnel ci-dessus.
Cependant, de telles solutions ne sont pas entièrement satisfaisantes dans la mesure où elles sollicitent encore trop le dispositif électronique.
A cet effet, la présente invention concerne un procédé d’authentification mutuelle entre un dispositif électronique et un système , le dispositif électronique disposant d’une clé privée associée à une clé publique, le système disposant d’une autre clé privée associée à une autre clé publique, et le procédé comprenant : i) une phase d’authentification du système comprenant les étapes suivantes :
- détermination par le dispositif électronique d’un challenge d’authentification, puis
- envoi au système, par le dispositif électronique, du challenge d’authentification, puis
- réception par le système en provenance du dispositif électronique du challenge d’authentification, puis
- calcul par le système d’un premier résultat d’authentification en fonction du challenge d’authentification et de l’autre clé privée, puis
- envoi au dispositif électronique, par le système, du premier résultat d’authentification, puis
- réception par le dispositif électronique en provenance du système du premier résultat d’authentification, puis
- authentification du système par le dispositif électronique, avec le challenge d’authentification, le premier résultat d’authentification et l’autre clé publique, et ii) une phase d’authentification du dispositif électronique comprenant les étapes suivantes :
- détermination par le système d’une donnée d’authentification, puis
- envoi au dispositif électronique, par le système, de la donnée d’authentification, puis
- réception par le dispositif électronique en provenance du système de la donnée d’authentification, puis
- calcul par le dispositif électronique d’un deuxième résultat d’authentification en fonction de la donnée d’authentification et de la clé privée, puis
- envoi au système, par le dispositif électronique, du deuxième résultat d’authentification, puis
- réception par le système en provenance du dispositif électronique du deuxième résultat d’authentification, puis
- authentification du dispositif électronique par le système avec le deuxième résultat d’authentification et la clé publique, le procédé étant caractérisé en ce que :
- - le calcul par le système du premier résultat d’authentification est par application à une donnée de référence comprenant le challenge d’authentification, d’une fonction de signature cryptographique avec l’autre clé privée,
- l’étape d’authentification du système par le dispositif électronique est par application au premier résultat d’authentification et à la donnée de référence comprenant le challenge d’authentification, d’une fonction de vérification de signature cryptographique avec l’autre clé publique,
- la donnée d’authentification et un secret partagé sont déterminés par le système par application à la clé publique d’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé,
- le calcul par le dispositif électronique du deuxième résultat d’authentification utilise un secret partagé obtenu par application à la clé privée et à la donnée d’authentification, d’une fonction de désencapsulation du mécanisme d’encapsulation de clé,
- l’étape d’authentification du dispositif électronique par le système utilise le secret partagé obtenu par application à la clé publique de la fonction d’encapsulation d’un mécanisme d’encapsulation de clé, et le deuxième résultat d’authentification.
Le procédé peut également comprendre les caractéristiques optionnelles exposées ci- dessous pour le procédé selon le premier aspect et/ou le procédé selon le deuxième aspect, prises seules ou en combinaison à chaque fois que cela est techniquement possible. Plus particulièrement, il est proposé selon un premier aspect, un procédé d’authentification mutuelle entre un dispositif électronique et un système, le procédé étant mis en œuvre par le dispositif électronique, le dispositif électronique disposant d’une clé privée associée à une clé publique, le système disposant d’une autre clé privée associée à une autre clé publique, et le procédé comprenant : i) une phase d’authentification du système comprenant les étapes suivantes :
- détermination d’un challenge d’authentification, puis
- envoi au système du challenge d’authentification, puis
- réception en provenance du système d’un premier résultat d’authentification, puis
- authentification du système avec le challenge d’authentification, le premier résultat d’authentification et l’autre clé publique, et ii) une phase d’authentification du dispositif électronique comprenant les étapes suivantes :
- réception en provenance du système d’une donnée d’authentification, puis
- calcul d’un deuxième résultat d’authentification en fonction de la donnée d’authentification et de la clé privée, puis
- envoi au système du deuxième résultat d’authentification, le procédé étant caractérisé en ce que :
- l’étape d’authentification du système est par application au premier résultat d’authentification et à une donnée de référence comprenant le challenge d’authentification, d’une fonction de vérification de signature cryptographique avec l’autre clé publique, - le calcul du deuxième résultat d’authentification utilise un secret partagé obtenu par application à la clé privée et à la donnée d’authentification, d’une fonction de désencap- sulation d’un mécanisme d’encapsulation de clé.
Le procédé selon ce premier aspect, peut également comprendre les caractéristiques optionnelles suivantes, prises seules ou en combinaison à chaque fois que cela est techniquement possible.
La clé privée, la clé publique, l’autre clé privée et l’autre clé publique sont des clés statiques, c’est-à-dire que chacune de ces clés est utilisée pour plusieurs itérations du procédé. La clé privée, la clé publique, l’autre clé privée et l’autre clé publique ne sont donc pas des clés éphémères, les clés éphémères étant des clés qui sont générées pour une itération spécifique et ne sont valables que pour cette itération.
Le calcul du deuxième résultat d’authentification comprend le calcul du secret partagé par application à la clé privée et à la donnée d’authentification, d’une fonction de désen- capsulation du mécanisme d’encapsulation de clé, puis l’obtention d’une clé dérivée à partir du secret partagé, puis le chiffrement avec la clé dérivée d’une donnée d’entrée, le deuxième résultat d’authentification étant le résultat dudit chiffrement.
Le calcul du deuxième résultat d’authentification comprend le calcul du secret partagé par application à la clé privée et à la donnée d’authentification, d’une fonction de désen- capsulation du mécanisme d’encapsulation de clé, puis l’obtention d’une clé dérivée à partir du secret partagé, puis le calcul d’un code d’authentification d’une donnée d’entrée avec la clé dérivée, le deuxième résultat d’authentification étant le code d’authentification calculé.
Le challenge d’authentification est un challenge anti-rejeu.
Chaque étape d’envoi et chaque étape de réception comprend une communication synchrone entre le dispositif électronique et le système.
Le challenge d’authentification est différent à chaque itération du procédé.
Le dispositif électronique détermine le challenge d’authentification par tirage aléatoire ou par incrémentation d’un compteur.
La donnée de référence est la concaténation de la donnée d’authentification et du challenge d’authentification.
La clé dérivée est obtenue par application au secret partagé ou au résultat d’une concaténation du secret partagé et du challenge d’authentification, d’une fonction de dérivation de clé.
Un canal sécurisé est établi à partir de la clé dérivée pour des échanges ultérieurs de données entre le dispositif électronique et le système.
Le procédé comprend en outre une étape de réception en provenance du système ou une étape d’envoi au système, d’une donnée chiffrée et/ou authentifiée, avec au moins une clé d’échange calculée à partir de la clé dérivée.
La phase d’authentification du système comprend en outre les étapes suivantes :
- réception en provenance du système d’un certificat de l’autre clé publique, puis
- vérification de la validité du certificat reçu, et la phase d’authentification du dispositif électronique comprend en outre l’étape suivante :
- envoi au système d’un certificat de la clé publique.
Le procédé comprend en outre les étapes suivantes :
- réception en provenance du système d’une clé publique éphémère,
- obtention d’un autre secret partagé et d’un chiffré correspondant, par application à la clé publique éphémère d’une fonction d’encapsulation d’un autre mécanisme d’encapsulation de clé,
- obtention d’une autre clé dérivée à partir de l’autre secret partagé,
- envoi au système du chiffré correspondant à l’autre secret partagé, et :
- l’étape d’envoi au système d’un certificat de la clé publique, envoi au système un résultat d’un chiffrement avec l’autre clé dérivée, d’une donnée comprenant le certificat de la clé publique, et
- l’étape de réception en provenance du système d’un certificat de l’autre clé publique, comprend le déchiffrement avec l’autre clé dérivée d’une donnée émise par le système. Le challenge d’authentification est le chiffré correspondant à l’autre secret partagé ou le chiffré de la donnée comprenant le certificat de la clé publique.
Les autres étapes de réception comprennent le déchiffrement avec l’autre clé dérivée de données émises par le système.
Il est également proposé selon un deuxième aspect, un procédé d’authentification mutuelle entre un dispositif électronique et un système, le procédé étant mis en œuvre par le système, le dispositif électronique disposant d’une clé privée associée à une clé publique, le système disposant d’une autre clé privée associée à une autre clé publique, et le procédé comprenant : i) une phase d’authentification du système comprenant les étapes suivantes :
- réception en provenance du dispositif électronique d’un challenge d’authentification, puis
- calcul d’un premier résultat d’authentification en fonction du challenge d’authentification et de l’autre clé privée, puis
- envoi au dispositif électronique du premier résultat d’authentification, et ii) une phase d’authentification du dispositif électronique comprenant les étapes suivantes :
- détermination d’une donnée d’authentification, puis
- envoi au dispositif électronique de la donnée d’authentification, puis
- réception en provenance du dispositif électronique d’un deuxième résultat d’authentification, puis
- authentification du dispositif électronique avec le deuxième résultat d’authentification et la clé publique, le procédé étant caractérisé en ce que : - le calcul du premier résultat d’authentification est par application à une donnée de référence comprenant le challenge d’authentification, d’une fonction de signature cryptographique avec l’autre clé privée,
- la donnée d’authentification et un secret partagé sont déterminés par application à la clé publique d’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé,
- l’étape d’authentification du dispositif électronique utilise le secret partagé et le deuxième résultat d’authentification.
Le procédé selon ce deuxième aspect, peut également comprendre les caractéristiques optionnelles suivantes, prises seules ou en combinaison à chaque fois que cela est techniquement possible.
La clé privée, la clé publique, l’autre clé privée et l’autre clé publique sont des clés statiques, c’est-à-dire que chacune de ces clés est utilisée pour plusieurs itérations du procédé. La clé privée, la clé publique, 1’ autre clé privée et l’autre clé publique ne sont donc pas des clés éphémères, les clés éphémères étant des clés qui sont générées pour une itération spécifique et ne sont valables que pour cette itération.
L’étape d’authentification du dispositif électronique comprend l’obtention d’une clé dérivée à partir du secret partagé, puis la comparaison d’une donnée candidate et d’une donnée attendue, la donnée candidate étant le deuxième résultat d’authentification et la donnée attendue étant obtenue par chiffrement avec la clé dérivée d’une donnée d’entrée, ou la donnée attendue étant une donnée d’entrée et la donnée candidate étant obtenue par déchiffrement avec la clé dérivée du deuxième résultat d’authentification.
L’étape d’authentification du dispositif électronique comprend l’obtention d’une clé dérivée à partir du secret partagé, puis la comparaison d’une donnée candidate et une donnée attendue, la donnée candidate étant le deuxième résultat d’authentification et la donnée attendue étant obtenue en calculant un code d’authentification d’une donnée d’entrée avec la clé dérivée, par exemple un code d’authentification basé sur le hachage ou un code d’authentification basé sur le chiffrement ou un code d’authentification de Galois.
Le dispositif électronique est authentifié si la donnée candidate et la donnée attendue sont identiques.
Chaque étape d’envoi et chaque étape de réception comprend une communication synchrone entre le dispositif électronique et le système.
Le challenge d’authentification est un challenge anti-rejeu.
Le challenge d’authentification est différent à chaque itération du procédé.
Le dispositif électronique détermine le challenge d’authentification par tirage aléatoire ou par incrémentation d’un compteur.
La donnée de référence est la concaténation de la donnée d’authentification et du challenge d’authentification.
La clé dérivée est obtenue par application au secret partagé ou au résultat d’une concaténation du secret partagé et du challenge d’authentification, d’une fonction de dérivation de clé. Un canal sécurisé est établi à partir de la clé dérivée pour des échanges ultérieurs de données entre le dispositif électronique et le système.
Le procédé comprend en outre une étape de réception en provenance du dispositif électronique ou une étape d’envoi au dispositif électronique, d’une donnée chiffrée et/ou authentifiée, avec au moins une clé d’échange calculée à partir de la clé dérivée.
La phase d’authentification du système comprend en outre l’étape suivante :
- envoi au dispositif électronique d’un certificat de l’autre clé publique, et la phase d’authentification du dispositif électronique comprend en outre les étapes suivantes :
- réception en provenance du dispositif électronique d’un certificat de la clé publique, puis
- vérification de la validité du certificat reçu.
Le procédé comprend en outre les étapes suivantes :
- envoi au dispositif électronique d’une clé publique éphémère associée à une clé privée éphémère, puis
- réception en provenance du dispositif électronique d’un chiffré correspondant à un autre secret partagé,
- obtention de l’autre secret partagé par application à la clé privée éphémère et au chiffré reçu, d’une fonction de désencapsulation d’un autre mécanisme d’encapsulation de clé,
- obtention d’une autre clé dérivée à partir de l’autre secret partagé, et dans lequel :
- l’étape de réception en provenance du dispositif électronique d’un certificat de la clé publique, comprend le déchiffrement avec l’autre clé dérivée d’une donnée émise par le dispositif électronique, et
- l’étape d’envoi au dispositif électronique d’un certificat de l’autre clé publique, envoi au dispositif électronique un résultat d’un chiffrement avec l’autre clé dérivée d’une donnée comprenant le certificat de l’autre clé publique.
La donnée comprenant le certificat de l’autre clé publique est le certificat de l’autre clé publique, ou le résultat d’une concaténation du certificat de l’autre clé publique et du premier résultat d’authentification, ou le résultat d’une concaténation du certificat de l’autre clé publique et de la donnée d’authentification, ou le résultat d’une concaténation du certificat de l’autre clé publique, du premier résultat d’authentification et de la donnée d’authentification.
Le challenge d’authentification est le chiffré correspondant à l’autre secret partagé ou la donnée émise par le dispositif électronique.
L’étape d’envoi au dispositif électronique du premier résultat d’authentification, et l’étape d’envoi au dispositif électronique de la donnée d’authentification, comprennent un chiffrement avec l’autre clé dérivée des données à envoyer.
Il est également proposé selon un troisième aspect, un programme d’ordinateur comprenant des instructions exécutables par un processeur et adaptées pour la mise en œuvre d’un procédé d’authentification mutuelle tel que défini précédemment selon le premier aspect, lorsque ces instructions sont exécutées par le processeur.
Il est également proposé, selon un quatrième aspect, un programme d’ordinateur comprenant des instructions exécutables par un processeur et adaptées pour la mise en œuvre d’un procédé d’authentification mutuelle tel que défini précédemment selon le deuxième aspect, lorsque ces instructions sont exécutées par le processeur.
Il est également proposé, selon un cinquième aspect, un dispositif électronique comprenant des moyens adaptés pour la mise en œuvre d’un procédé d’authentification mutuelle tel que défini précédemment selon le premier aspect.
L’invention concerne en particulier un dispositif électronique comprenant une mémoire stockant une clé privée associée à une clé publique, le dispositif électronique étant adapté pour coopérer avec un système disposant d’une autre clé privée associée à une autre clé publique, et le dispositif électronique comprenant en outre : i) un premier module, configuré pour réaliser une phase d’authentification du système qui comprend les étapes suivantes :
- détermination d’un challenge d’authentification, puis
- envoi au système du challenge d’authentification, puis
- réception en provenance du système d’un premier résultat d’authentification, puis
- authentification du système avec le challenge d’authentification, le premier résultat d’authentification et l’autre clé publique, et ii) un deuxième module, configuré pour réaliser une phase d’authentification du dispositif électronique qui comprend les étapes suivantes :
- réception en provenance du système d’une donnée d’authentification, puis
- calcul d’un deuxième résultat d’authentification en fonction de la donnée d’authentification et de la clé privée, puis
- envoi au système du deuxième résultat d’authentification, le dispositif électronique étant caractérisé en ce que :
- le premier module est configuré pour réaliser l’étape d’authentification du système par application au premier résultat d’authentification et à une donnée de référence comprenant le challenge d’authentification, d’une fonction de vérification de signature cryptographique avec l’autre clé publique,
- le deuxième module est configuré pour calculer le deuxième résultat d’authentification en utilisant un secret partagé obtenu par application à la clé privée et à la donnée d’authentification, d’une fonction de désencapsulation d’un mécanisme d’encapsulation de clé.
Ce dispositif électronique peut être configuré pour la mise en œuvre de chacune des possibilités de réalisation envisagées pour le procédé d’authentification mutuelle tel que défini précédemment selon le premier aspect.
Il est également proposé, selon un sixième aspect, un système comprenant des moyens adaptés pour la mise en œuvre d’un procédé d’authentification mutuelle tel que défini précédemment selon le deuxième aspect. L’invention concerne en particulier un système adapté pour coopérer avec un dispositif électronique disposant d’une clé privée associée à une clé publique, le système comprenant une mémoire stockant une autre clé privée associée à une autre clé publique, et le système comprenant en outre : i) un premier module, configuré pour réaliser une phase d’authentification du système qui comprend les étapes suivantes :
- réception en provenance du dispositif électronique d’un challenge d’authentification, puis
- calcul d’un premier résultat d’authentification en fonction du challenge d’authentification et de l’autre clé privée, puis
- envoi au dispositif électronique du premier résultat d’authentification, et ii) un deuxième module, configuré pour réaliser une phase d’authentification du dispositif électronique qui comprend les étapes suivantes :
- détermination d’une donnée d’authentification, puis
- envoi au dispositif électronique de la donnée d’authentification, puis
- réception en provenance du dispositif électronique d’un deuxième résultat d’authentification, puis
- authentification du dispositif électronique avec le deuxième résultat d’authentification et la clé publique, le système étant caractérisé en ce que :
- le premier module est configuré pour calculer le premier résultat d’authentification par application à une donnée de référence comprenant le challenge d’authentification, d’une fonction de signature cryptographique avec l’autre clé privée,
- le deuxième module est configuré pour déterminer la donnée d’authentification et un secret partagé par application à la clé publique d’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé, et pour réaliser l’étape d’authentification du dispositif électronique en utilisant le secret partagé et le deuxième résultat d’authentification.
Ce système peut être configuré pour la mise en œuvre de chacune des possibilités de réalisation envisagées pour le procédé d’authentification mutuelle tel que défini précédemment selon le deuxième aspect.
Bien entendu, les différentes caractéristiques, variantes et formes de réalisation de l'invention peuvent être associées les unes avec les autres selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux figures annexées qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif.
Sur les figures:
Figure 1 représente schématiquement les éléments principaux d’un dispositif électronique et d’un système au sein desquels est mise en œuvre l’invention ;
Figure 2 représente sous forme de logigramme les étapes principales d’un procédé d’authentification mutuelle selon un premier mode d’implémentation de l’invention ; Figure 3 représente sous forme de logigramme les étapes principales d’un procédé d’authentification mutuelle selon un deuxième mode d’implémentation de l’invention.
Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
Dans le cadre de la présente description, des qualificatifs « premier », « deuxième » ne sont qu’à titre indicatif pour distinguer des éléments qu’ils qualifient, mais n’impliquent pas d’ordre entre eux.
La figure 1 représente schématiquement les éléments principaux d’un dispositif électronique 10 et d’un système 20 au sein desquels est mise en œuvre l’invention. Le dispositif électronique 10 et le système 20 sont aptes à coopérer, notamment pour mettre en œuvre un procédé d’authentification mutuelle entre le dispositif électronique 10 et le système 20.
Le dispositif électronique 10 dispose d’une clé privée associée à une clé publique (non représentées).
Selon un premier exemple, la clé privée et la clé publique sont des clés RSA-KEM telles que décrites dans le document RFC 5990: Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS), par Randall & al., daté de septembre 2010, https://www.rfc-editor.Org/rfc/rfc5990.html#appendix-A.
Selon un deuxième exemple, la clé privée et la clé publique sont des clés ECIES telles que décrites dans le document BSI TR-02102-1 : BSI - Technical Guideline - Cryptographie Mechanisms: Recommendations and Key Lengths, version 2022-01, daté du 28 Janvier 2022, https://www. b si. bund. de/SharedDocs/Downloads/EN/BSI/Publica- tions/TechGuidelines/TG02102/BSI-TR-02102-1.pdf? blob=publicationFile.
Selon un troisième exemple, la clé privée et la clé publique sont des clés Crystals-Kyber telles que décrites sur le site Crystals - Cryptographie Suite for Algebraic Lattices, https ://pq-crystals. org/kyber/index. shtml.
Selon un quatrième exemple, la clé privée et la clé publique sont des clés NTRU telles que décrites sur le site NTRU- a submission to the NIST post-quantum standardization effort, https://ntru.org/.
La clé privée et la clé publique sont des clés statiques, c’est-à-dire que chacune de ces clés est utilisée pour la mise en œuvre de plusieurs itérations d’un procédé d’authentification mutuelle selon l’invention (typiquement un des procédés décrits en référence aux figures 2 et 3). La clé privée et la clé publique ne sont donc pas des clés éphémères, les clés éphémères étant des clés qui sont générées pour une itération spécifique et ne sont valables que pour cette itération.
Le système 20 dispose d’une autre clé privée associée à une autre clé publique (non représentées).
Selon un premier exemple, l’autre clé privée et l’autre clé publique sont des clés RSA ou ECDS A telles que décrites dans le document FIPS PUB 186-4, Digital Signature Standard, de Information Technology Laboratory National Institute of Standards and Technology, et daté de Juillet 2013, https://nvlpubs.nist.gov/nist- pubs/FIPS/NISTFIPS.186-4.pdf.
Selon un deuxième exemple, l’autre clé privée et l’autre clé publique sont des clés Crystal s-Dilithium telles que décrites sur le site Crystals - Cryptographie Suite for Algebraic Lattices, https ://pq-crystals. org/dilithium/.
Selon un troisième exemple, l’autre clé privée et l’autre clé publique sont des clés Falcon telles que décrites sur le site Falcon - Fast-Fourier Lattice-based Compact Signatures over NTRU, https://falcon-sign.info/.
Selon un quatrième exemple l’autre clé privée et l’autre clé publique sont des clés Sphincs+ telles que décrites sur le site Sphincs+ Stateless hash-based signatures, https://sphincs. org/.
Selon un cinquième exemple, l’autre clé privée et l’autre clé publique sont des clés LMS ou XMSS telles que décrites dans le document NIST SP 800-208, Recommendation for stateful Hash-Based signature Schemes, de National Institute of Standards and Technology , et datée d’octobre 2020, https://nvlpubs.nist.gov/nistpubs/SpecialPublica- tions/NIST.SP.800-208.pdf
On notera que la clé privée et la clé publique peuvent être d’un type différent de l’autre clé privée et de l’autre clé publique.
Par exemple, la clé privée et la clé publique peuvent être des clés NTRU tandis que l’autre clé privée et l’autre clé publique sont des clés Crystals-Kyber.
L’autre clé privée et l’autre clé publique sont des clés statiques, c’est-à-dire que chacune de ces clés est utilisée pour la mise en œuvre de plusieurs itérations d’un procédé d’authentification mutuelle selon l’invention (typiquement un des procédés décrits en référence aux figures 2 et 3). L’autre clé privée et l’autre clé publique ne sont donc pas des clés éphémères, les clés éphémères étant des clés qui sont générées pour une itération spécifique et ne sont valables que pour cette itération.
La figure 1 représente ainsi schématiquement un dispositif électronique 10 comprenant un processeur 4 (par exemple un microprocesseur), un bloc de mémorisation 6, une mémoire vive 8 et un bloc de communication 2.
La mémoire vive 8 et le bloc de mémorisation 6 sont chacun liés au processeur 4 de sorte que le processeur 4 peut lire ou écrire des données dans le bloc de mémorisation 6 et/ou la mémoire vive 8.
Le bloc de mémorisation 6 mémorise des instructions de programme d’ordinateur, dont certaines sont conçues pour mettre en œuvre un procédé d’authentification mutuelle tel que l’un au moins de ceux décrits en référence aux figures 2 et 3, notamment en coopération avec le système 20, lorsque ces instructions sont exécutées par le processeur 4. Le bloc de mémorisation 6 est par exemple en pratique un disque dur ou une mémoire non-volatile, éventuellement réinscriptible, par exemple de type EEPROM (pour "Electrically Erasable and Programmable Read-Only Memory" selon l’appellation anglo- saxonne couramment utilisée). La mémoire vive 8 peut quant à elle mémoriser certains au moins des éléments (notamment un challenge d’authentification, une donnée d’authentification, un premier résultat d’authentification et/ou un deuxième résultat d’authentification tels que décrits ci-après en référence aux figures 2 et 3) manipulés lors des différents traitements effectués au cours d’au moins un des procédés décrits ci -après.
En outre, le bloc de mémorisation 6, et/ou la mémoire vive 8, peut mémoriser la clé privée et/ou la clé publique et/ou un certificat de la clé publique.
On appelle mémoire dans la suite de la description, l’un quelconque parmi le bloc de mémorisation 6 et la mémoire vive 8.
Le dispositif électronique 10 comporte également plusieurs modules non représentés. Typiquement, le dispositif électronique 10 comporte un premier module configuré pour réaliser une phase d’authentification du système 20, et un deuxième module configuré pour réaliser une phase d’authentification du dispositif électronique 10. Le dispositif électronique 10 peut aussi comporter un troisième module pour la confidentialité.
Ces modules peuvent en pratique être réalisés par une combinaison d’éléments matériels et d’éléments logiciels.
Chaque module parmi le premier module et le deuxième module, est configuré pour réaliser les étapes d’une phase décrite dans les procédés conformes à l’invention et exposés ci-après, et possède donc une fonctionnalité décrite dans les procédés conformes à l’invention et exposés ci-après.
Le troisième module pour la confidentialité est configuré pour réaliser d’autres étapes décrites en référence à la figure 3.
Ainsi pour chaque module, le dispositif électronique 10 mémorise par exemple des instructions de logiciel exécutables par le processeur 4 afin d’utiliser un élément matériel (par exemple un bloc de communication ou une mémoire) et de mettre ainsi en œuvre la fonctionnalité offerte par le module.
Selon une possibilité de réalisation, les instructions de programme d’ordinateur mémorisées dans le bloc de mémorisation 6 ont été reçues (par exemple d’un ordinateur distant) lors d’une phase de fonctionnement du dispositif électronique 10 antérieure aux procédés décrits en référence aux figures 2 et 3.
Le bloc de communication 2 est relié au processeur 4 de manière à permettre au processeur 4 de recevoir des données m en provenance du système 20, par exemples un premier résultat d’authentification et une donnée d’authentification tels que décrits en référence aux figures 2 et 3, et/ou d’émettre des données m à destination du système 20, par exemples un challenge d’authentification et un deuxième résultat d’authentification tels que décrits en référence aux figures 2 et 3.
Le dispositif électronique peut prendre de nombreuses formes (non représentées). Selon un premier exemple, le dispositif électronique est une carte à puce, telle qu’une carte d’identité, une carte bancaire ou une carte à circuit intégré universelle (également connue sous le nom de carte UICC pour « Universal Integrated Circuit Card » en terminologie anglo-saxonne). Selon un deuxième exemple, le dispositif électronique est un élément sécurisé, tel qu’un microcontrôleur sécurisé qui est intégré à un autre dispositif électronique, typiquement un terminal de communication ou une voiture.
Selon d’autres exemples, le dispositif électronique est une clé usb, ou un document d’identité, tel qu’un passeport électronique.
La figure 1 représente aussi schématiquement le système 20.
Le système 20 comprend un processeur 14 (par exemple un microprocesseur), un bloc de mémorisation 16, une mémoire vive 18 et un bloc de communication 12.
La mémoire vive 18 et le bloc de mémorisation 16 sont chacun liés au processeur 14 de sorte que le processeur 14 peut lire ou écrire des données dans le bloc de mémorisation 16 et/ou la mémoire vive 18.
Le bloc de mémorisation 16 mémorise des instructions de programme d’ordinateur, dont certaines sont conçues pour mettre en œuvre un procédé d’authentification mutuelle tel que l’un au moins de ceux décrits en référence aux figures 2 et 3, notamment en coopération avec le dispositif électronique 10, lorsque ces instructions sont exécutées par le processeur 14.
Le bloc de mémorisation 16 est par exemple en pratique un disque dur ou une mémoire non-volatile, éventuellement réinscriptible, par exemple de type EEPROM (pour "Electrically Erasable and Programmable Read-Only Memory" selon l’appellation anglo- saxonne couramment utilisée).
La mémoire vive 18 peut quant à elle mémoriser certains au moins des éléments (notamment un challenge d’authentification, une donnée d’authentification, un premier résultat d’authentification et/ou un deuxième résultat d’authentification tels que décrits ci- après en référence aux figures 2 et 3) manipulés lors des différents traitements effectués au cours d’au moins un des procédés décrits ci-après.
En outre, le bloc de mémorisation 16, et/ou la mémoire vive 18, peut mémoriser l’autre clé privée et/ou l’autre clé publique et/ou un certificat de l’autre clé publique.
On appelle mémoire dans la suite de la description, l’un quelconque parmi le bloc de mémorisation 16 et la mémoire vive 18.
Le système 20 comporte également plusieurs modules non représentés.
Typiquement, le système 20 comporte un premier module configuré pour réaliser une phase d’authentification du système 20, et un deuxième module configuré pour réaliser une phase d’authentification du dispositif électronique 10. Le système 20 peut aussi comporter un troisième module pour la confidentialité.
Ces modules peuvent en pratique être réalisés par une combinaison d’éléments matériels et d’éléments logiciels.
Chaque module parmi le premier module et le deuxième module, est configuré pour réaliser les étapes d’une phase décrite dans les procédés conformes à l’invention et exposés ci-après, et possède donc une fonctionnalité décrite dans les procédés conformes à l’invention et exposés ci-après.
Le troisième module pour la confidentialité est configuré pour réaliser d’autres étapes décrites en référence à la figure 3.
Ainsi pour chaque module, le système 20 mémorise par exemple des instructions de logiciel exécutables par le processeur 14 afin d’utiliser un élément matériel (par exemple un bloc de communication ou une mémoire) et de mettre ainsi en œuvre la fonctionnalité offerte par le module.
Selon une possibilité de réalisation, les instructions de programme d’ordinateur mémorisées dans le bloc de mémorisation 16 ont été reçues (par exemple d’un ordinateur distant) lors d’une phase de fonctionnement du système 20 antérieure aux procédés décrits en référence aux figures 2 et 3.
Le bloc de communication 12 est relié au processeur 14 de manière à permettre au processeur 14 de recevoir des données n en provenance du dispositif électronique 10, par exemple un challenge d’authentification et un deuxième résultat d’authentification tels que décrits en référence aux figures 2 et 3, et/ou d’émettre des données n à destination du dispositif électronique 10, par exemple un premier résultat d’authentification et une donnée d’authentification tels que décrits en référence aux figures 2 et 3.
Le système peut prendre de nombreuses formes (non représentées) telles qu’un serveur, un terminal de communication, un ordinateur ou un équipement électronique d’un réseau de télécommunication.
La figure 2 représente sous forme de logigramme les étapes principales d’un procédé d’authentification mutuelle selon un premier mode d’implémentation de l’invention.
Ce procédé est mis en œuvre par le dispositif électronique 10, le dispositif électronique 10 disposant d’une clé privée associée à une clé publique et coopérant avec le système 20, et par le système 20, le système 20 disposant d’une autre clé privée associée à une autre clé publique et coopérant avec le dispositif électronique 10.
Typiquement, le dispositif électronique 10 dispose de la clé privée dans au moins une de ses mémoires, et le système 20 dispose de l’autre clé privée dans au moins une de ses mémoires.
En outre, le dispositif électronique 10 peut disposer de la clé publique dans au moins une de ses mémoires, et le système 20 peut disposer de l’autre clé publique dans au moins une de ses mémoires.
Selon une étape d’envoi de certificat au dispositif électronique (étape E200), le système 20 envoie au dispositif électronique 10 un certificat de l’autre clé publique, typiquement en utilisant son bloc de communication 12.
Selon une étape de réception de certificat en provenance du système (étape E210), le dispositif électronique 10 reçoit en provenance du système 20 le certificat de l’autre clé publique, typiquement en utilisant son bloc de communication 2.
Le procédé comprend alors une étape de vérification de certificat (étape E220) pendant laquelle le dispositif électronique 10 vérifie la validité du certificat de l’autre clé publique reçu.
La sécurité du procédé d’authentification mutuelle est ainsi renforcée.
Le procédé permet au dispositif électronique de s’assurer que l’autre clé publique et l’autre clé privée ont été émises par une entité validée par une autorité de confiance. Le dispositif électronique peut ainsi associer l’autre clé publique au système et s’assurer de la validité de ladite autre clé publique.
Le certificat de l’autre clé publique peut consister en la concaténation de l’autre clé publique et d’une signature cryptographique de ladite autre clé publique, par exemple réalisée avec une clé privée de certification émise par une autorité de confiance. De façon alternative, le certificat de l’autre clé publique peut consister en une chaine de certificats dont l’un comprend la concaténation de l’autre clé publique et d’une signature cryptographique de ladite autre clé publique, par exemple réalisée avec une clé privée de certification intermédiaire émise par une autorité intermédiaire, l’autorité intermédiaire étant validée par une autorité de confiance via ladite chaine de certificats.
Le dispositif électronique 10 peut alors vérifier le certificat de l’autre clé publique reçu, en vérifiant ladite signature avec une clé publique de certification associée à la clé privée de certification.
Typiquement, le dispositif électronique 10 dispose de la clé publique de certification, par exemple dans une de ses mémoires.
Selon une possibilité de réalisation, le dispositif électronique 10 a préalablement reçu la clé publique de certification (par exemple d’un ordinateur distant) lors d’une phase de fonctionnement du dispositif électronique 10 antérieure au procédé décrit ici.
Selon une étape de détermination d’un challenge d’authentification (étape E300), le dispositif électronique 10 détermine un challenge d’authentification.
Le challenge d’authentification est une donnée à partir de laquelle le système 20 calculera une réponse avec l’autre clé privée.
Dans le procédé de l’invention, le challenge d’authentification n’est pas une clé cryptographique et n’est pas utilisé en tant que telle.
Le procédé limite la sollicitation des ressources du dispositif électronique.
De préférence, le challenge d’authentification est un challenge anti-rejeu.
Typiquement, le challenge d’authentification est différent à chaque itération du procédé. Le dispositif électronique peut par exemple déterminer le challenge d’authentification par tirage aléatoire ou par incrémentation d’un compteur.
Le procédé sécurise ainsi une authentification mutuelle contre les attaques par rejeu tout en limitant les traitements mis en œuvre par le dispositif électronique.
Le procédé comprend alors une étape d’envoi au système du challenge d’authentification (étape E310), pendant laquelle le dispositif électronique 10 envoie au système 20 le challenge d’authentification, typiquement en utilisant son bloc de communication 2.
Le procédé comprend alors une étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320) pendant laquelle le système 20 reçoit en provenance du dispositif électronique le challenge d’authentification, typiquement en utilisant son bloc de communication 12.
Le procédé comprend alors une étape de calcul d’un premier résultat d’authentification (étape E330) pendant laquelle le système 20 calcule ledit premier résultat d’authentification en fonction du challenge d’authentification et de l’autre clé privée. Le système 20 calcule le premier résultat d’authentification par application à une donnée de référence comprenant le challenge d’authentification, d’une fonction de signature cryptographique avec l’autre clé privée. Ainsi, le premier résultat est typiquement une signature avec l’autre clé privée, de la donnée de référence.
La donnée de référence est déterminée par le système à partir du challenge d’authentification reçu en provenance du dispositif électronique.
Des exemples de fonctions de signature sont décrits dans les références citées ci-avant pour les exemples de l’autre clé privée et de l’autre clé publique.
Typiquement, si l’autre clé privée et l’autre clé publique sont des clés Crystals-Dili- thium telles que décrites sur le site Crystals - Cryptographie Suite for Algebraic Lattices, https://pq-crystals.org/dilithium/, la fonction de signature est telle que décrite dans ce document.
Le procédé mis en œuvre par le système invoque ainsi une fonction de signature cryptographique plutôt qu’une fonction de désencapsulation d’un mécanisme d’encapsulation de clé pour l’authentification du système.
Le procédé comprend alors une étape d’envoi au dispositif électronique du premier résultat d’authentification (étape E340), pendant laquelle le système 20 envoie au dispositif électronique 10 le premier résultat d’authentification, typiquement en utilisant son bloc de communication 12.
Le procédé comprend alors une étape de réception en provenance du système du premier résultat d’authentification (étape E350), pendant laquelle le dispositif électronique 10 reçoit en provenance du système 20 le premier résultat d’authentification, typiquement en utilisant son bloc de communication 2.
Le procédé comprend alors une étape d’authentification du système (étape E360), pendant laquelle le dispositif électronique 10 authentifie le système 20 avec le challenge d’authentification, le premier résultat d’authentification et l’autre clé publique. Le dispositif électronique 10 authentifie le système 20 par application au premier résultat d’authentification et à une autre donnée de référence comprenant le challenge d’authentification, d’une fonction de vérification de signature cryptographique avec l’autre clé publique.
L’autre donnée de référence est déterminée par le dispositif électronique à partir du challenge d’authentification envoyé au système.
La donnée de référence et l’autre donnée de référence doivent respectivement être déterminée selon un algorithme similaire par le système 20 et le dispositif électronique 10. Par exemple, quand la donnée de référence est le challenge d’authentification reçu par le système en provenance du dispositif électronique, l’autre donnée de référence est le challenge d’authentification envoyé au système par le dispositif électronique.
La fonction de vérification de signature cryptographique est une fonction cryptogra- phique associée à la fonction de signature utilisée par le système pendant l’étape de calcul d’un premier résultat d’authentification (étape E330).
Le procédé mis en œuvre par le dispositif électronique invoque ainsi une fonction de vérification de signature cryptographique plutôt qu’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé pour l’authentification du système.
Le procédé limite ainsi la sollicitation des ressources du dispositif électronique.
L’étape d’envoi de certificat au dispositif électronique (étape E200), l’étape de réception de certificat en provenance du système (étape E210), l’étape de vérification de certificat (étape E220), l’étape de détermination d’un challenge d’authentification (étape E300), l’étape d’envoi au système du challenge d’authentification (étape E310), l’étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320), l’étape de calcul d’un premier résultat d’authentification (étape E330), l’étape d’envoi au dispositif électronique du premier résultat d’authentification (étape E340), l’étape de réception en provenance du système du premier résultat d’authentification (étape E350), et l’étape d’authentification du système (étape E360), sont dans une phase d’authentification du système (phase PI).
Cette phase d’authentification du système est typiquement mise en œuvre par le premier module du système 20 et le premier module du dispositif électronique 10.
Le premier module du système 20 peut ainsi mettre en œuvre l’étape d’envoi de certificat au dispositif électronique (étape E200), l’étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320), l’étape de calcul d’un premier résultat d’authentification (étape E330) et l’étape d’envoi au dispositif électronique du premier résultat d’authentification (étape E340).
Le premier module du dispositif électronique 10 peut en œuvre l’étape de réception de certificat en provenance du système (étape E210), l’étape de vérification de certificat (étape E220), l’étape de détermination d’un challenge d’authentification (étape E300), l’étape d’envoi au système du challenge d’authentification (étape E310), l’étape de réception en provenance du système du premier résultat d’authentification (étape E350), et l’étape d’authentification du système (étape E360).
Selon une étape d’envoi de certificat au système (étape E400), le dispositif électronique 10 envoie au système 20 un certificat de la clé publique, typiquement en utilisant son bloc de communication 2.
Selon une étape de réception de certificat en provenance du dispositif électronique (étape E410), le système 20 reçoit en provenance du dispositif électronique 10 le certificat de la clé publique, typiquement en utilisant son bloc de communication 12.
Le procédé comprend alors une autre étape de vérification de certificat (étape E420) pendant laquelle le système 20 vérifie la validité du certificat de la clé publique reçu. La sécurité du procédé d’authentification mutuelle est ainsi renforcée.
Le procédé permet au système de s’assurer que la clé publique et la clé privée ont été émises par une entité validée par une autorité de confiance. Le système peut ainsi asso- cier la clé publique au dispositif électronique et s’assurer de la validité de ladite clé publique.
Le certificat de la clé publique peut consister en la concaténation de la clé publique et d’une signature cryptographique de ladite clé publique, par exemple réalisée avec une autre clé privée de certification émise par une autorité de confiance. De façon alternative, le certificat de la clé publique peut consister en une chaine de certificats dont l’un comprend la concaténation de la clé publique et d’une signature cryptographique de ladite clé publique, par exemple réalisée avec une autre clé privée de certification intermédiaire émise par une autorité intermédiaire, l’autorité intermédiaire étant validée par une autorité de confiance via ladite chaine de certificats.
Le système 20 peut alors vérifier le certificat de la clé publique reçu, en vérifiant ladite signature avec une autre clé publique de certification associée à l’autre clé privée de certification.
Typiquement, le système 20 dispose de l’autre clé publique de certification, par exemple dans une de ses mémoires.
Selon une possibilité de réalisation, le système 20 a préalablement reçu l’autre clé publique de certification (par exemple d’un ordinateur distant) lors d’une phase de fonctionnement du système 20 antérieure au procédé décrit ici.
L’autre clé publique de certification et l’autre clé privée de certification peuvent respectivement être la clé publique de certification et la clé privée de certification décrite ci- avant.
Selon une étape de détermination d’une donnée d’authentification (étape E500), le système 20 détermine une donnée d’authentification et un secret partagé par application à la clé publique d’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé. La donnée d’authentification est le chiffré du secret partagé.
Des exemples de fonctions d’encapsulation de mécanisme d’encapsulation sont décrits dans les références citées ci-avant pour les exemples de la clé privée et de la clé publique. Typiquement, si la clé privée et la clé publique sont des clés RSA-KEM telles que décrites dans le document RFC 5990: Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS), par Randall & al., daté de septembre 2010, https://www.rfc-editor.Org/rfc/rfc5990.html#appendix-A , la fonction d’encapsulation du mécanisme d’ encapsulation est telle que décrite dans ce document.
Le procédé mis en œuvre par le système invoque ainsi une fonction d’encapsulation d’un mécanisme d’encapsulation de clé plutôt qu’une fonction de vérification de signature cryptographique pour l’authentification du dispositif électronique.
Le procédé comprend alors une étape d’envoi au dispositif électronique de la donnée d’authentification (étape E510) pendant laquelle le système 20 envoie au dispositif électronique 10 la donnée d’authentification, typiquement en utilisant son bloc de communication 12.
Le procédé comprend alors une étape de réception de la donnée d’authentification (étape E520), pendant laquelle le dispositif électronique 10 reçoit en provenance du système 20 la donnée d’authentification, typiquement en utilisant son bloc de communication 2.
Le procédé comprend alors une étape de calcul d’un deuxième résultat d’authentification (étape E530) pendant laquelle le dispositif électronique 10 calcule un deuxième résultat d’authentification en fonction de la donnée d’authentification et de la clé privée. Le dispositif électronique 10 calcul le deuxième résultat d’authentification en utilisant un secret partagé obtenu par application à la clé privée et à la donnée d’authentification, d’une fonction de désencapsulation du mécanisme d’encapsulation de clé.
Des exemples de fonctions de désencapsulation de mécanisme d’encapsulation sont décrits dans les références citées ci-avant pour les exemples de la clé privée et de la clé publique. Typiquement, si la clé privée et la clé publique sont des clés RSA-KEM telles que décrites dans le document RFC 5990: Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS), par Randall & al., daté de septembre 2010, https://www.rfc-editor.Org/rfc/rfc5990.html#appendix-A , la fonction de désencapsulation du mécanisme d’ encapsulation est telle que décrite dans ce document. Selon une première possibilité, le calcul du deuxième résultat d’authentification comprend le calcul du secret partagé par application à la clé privée et à la donnée d’authentification, d’une fonction de désencapsulation du mécanisme d’encapsulation de clé, puis l’obtention d’une clé dérivée à partir du secret partagé, puis le chiffrement avec la clé dérivée d’une donnée d’entrée, le deuxième résultat d’authentification étant le résultat dudit chiffrement. La clé dérivée est ici utilisée comme clé de chiffrement.
La clé dérivée peut être obtenue par application d’une fonction de dérivation de clé de l’état de l’art, au secret partagé ou au résultat d’une concaténation du secret partagé et du challenge d’authentification.
Selon un autre exemple, la clé dérivée est le secret partagé.
Le secret partagé permet au système d’introduire un aléa à chaque itération du procédé dans le calcul de la clé dérivée.
Le challenge d’authentification permet au dispositif électronique d’introduire aussi un aléa dans le calcul de la clé dérivée.
Selon une deuxième possibilité, le calcul du deuxième résultat d’authentification comprend le calcul du secret partagé par application à la clé privée et à la donnée d’authentification, d’une fonction de désencapsulation du mécanisme d’encapsulation de clé, puis l’obtention d’une clé dérivée à partir du secret partagé, puis le calcul d’un code d’authentification d’une donnée d’entrée avec la clé dérivée, par exemple un code d’authentification basé sur le hachage tel que proposé dans la publication FIPS PUB198-1 «The Keyed-Hash Message Authentication Code » du NIST et datée de Juillet 2008, ou un code d’authentification basé sur le chiffrement tel que proposé dans la publication NIST.SP.800-38B « Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication » du NIST et datée de Mai 2005, ou un code d’authentification de Galois tel que proposé dans la publication NIST.SP.800-38D « Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC » du NIST et datée de Novembre 2007. Le deuxième résultat d’authentification est alors le code d’authentification calculé. La clé dérivée est ici utilisée comme clé pour le calcul du code d’authentification de la donnée d’entrée.
Comme pour la première possibilité, la clé dérivée peut être obtenue par application d’une fonction de dérivation de clé de l’état de l’art, au secret partagé ou au résultat d’une concaténation du secret partagé et du challenge d’authentification.
Toujours comme pour la première possibilité, la clé dérivée peut, selon un autre exemple, être le secret partagé.
Le secret partagé permet au système d’introduire un aléa à chaque itération du procédé dans le calcul de la clé dérivée.
Le challenge d’authentification permet au dispositif électronique d’introduire aussi un aléa dans le calcul de la clé dérivée.
Le procédé mis en œuvre par le dispositif électronique invoque ainsi une fonction de dé- sencapsulation d’un mécanisme d’encapsulation de clé plutôt qu’une fonction de signature cryptographique pour l’authentification du dispositif électronique.
Le procédé limite ainsi la sollicitation des ressources du dispositif électronique.
Le procédé comprend alors une étape d’envoi au système du deuxième résultat d’authentification (étape E540), pendant laquelle le dispositif électronique 10 envoie au système 20 le deuxième résultat d’authentification, typiquement en utilisant son bloc de communication 2.
Le procédé comprend alors une étape de réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550), pendant laquelle le système 20 reçoit en provenance du dispositif électronique 10 le deuxième résultat d’authentification, typiquement en utilisant son bloc de communication 12.
Le procédé comprend alors une étape d’authentification du dispositif électronique 10 (étape E560), pendant laquelle le système 20 authentifie le dispositif électronique 10 avec le deuxième résultat d’authentification et la clé publique. Le système authentifie le dispositif électronique en utilisant le secret partagé (qui a été déterminé par le système 20 à partir de la clé publique au cours de l’étape de détermination d’une donnée d’authentification, c’est-à-dire de l’étape E500) et le deuxième résultat d’authentification. Quand l’étape de calcul d’un deuxième résultat d’authentification (étape E530) est implémentée selon la première possibilité décrite ci-avant pour cette étape, l’étape d’authentification du dispositif électronique comprend l’obtention de la clé dérivée à partir du secret partagé, puis la comparaison d’une donnée candidate et d’une donnée attendue. Le dispositif électronique est authentifié si la donnée candidate et la donnée attendue sont identiques.
La donnée candidate est le deuxième résultat d’authentification et la donnée attendue est obtenue par chiffrement avec la clé dérivée de la donnée d’entrée, ou la donnée attendue est la donnée d’entrée et la donnée candidate est obtenue par déchiffrement avec la clé dérivée du deuxième résultat d’authentification. La clé dérivée est utilisée comme clé de chiffrement ou de déchiffrement.
La donnée d’entrée peut être toute donnée connue du système 20 et du dispositif électronique 10, par exemple le challenge d’authentification, la donnée d’authentification, le résultat d’une concaténation du challenge d’authentification et de la donnée d’authentification, ou une autre donnée reçue préalablement par le système 20 et le dispositif électronique 10, typiquement lors d’une phase de fonctionnement du dispositif électronique 10 et du système 20 antérieure au procédé décrit ici.
L’opération de chiffrement ou de déchiffrement exécutée ici par le système 20 est selon un algorithme cryptographique, par exemple AES, associé à l’opération de chiffrement exécutée par le dispositif électronique 10 pendant l’étape de calcul d’un deuxième résultat d’authentification (étape E530).
En outre, la clé dérivée est obtenue par le système 20 de façon similaire à son obtention par le dispositif électronique 10.
Selon un premier exemple, quand le dispositif électronique obtient la clé dérivée par application d’une fonction de dérivation de clé de l’état de l’art au secret partagé déterminé pendant l’étape de calcul d’un deuxième résultat d’authentification (étape E530), le système calcule la clé dérivée par application de cette fonction de dérivation au secret partagé déterminé pendant l’étape de détermination d’une donnée d’authentification (étape E500).
Selon un deuxième exemple, quand le dispositif électronique obtient la clé dérivée par application d’une fonction de dérivation de clé de l’état de l’art au résultat d’une concaténation du secret partagé et du challenge d’authentification, le secret partagé ayant été déterminé pendant l’étape de calcul d’un deuxième résultat d’authentification (étape E530) et le challenge d’authentification ayant été déterminé pendant l’étape de détermination d’un challenge d’authentification (étape E300), le système calcule la clé dérivée par application de cette fonction de dérivation au résultat d’une autre concaténation du secret partagé et du challenge d’authentification, le secret partagé ayant été déterminé pendant l’étape de détermination d’une donnée d’authentification (étape E500)et le challenge d’authentification ayant été reçu pendant l’étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320).
Selon un troisième exemple, quand la clé dérivée obtenue par le dispositif électronique est le secret partagé déterminé pendant l’étape de calcul d’un deuxième résultat d’authentification (étape E530), la clé dérivée calculée par le système est le secret partagé déterminé pendant l’étape de détermination d’une donnée d’authentification (étape E500).
Quand l’étape de calcul d’un deuxième résultat d’authentification (étape E530) est implémentée selon la deuxième possibilité décrite ci -avant pour cette étape, l’étape d’authentification du dispositif électronique comprend l’obtention de la clé dérivée à partir du secret partagé, puis la comparaison d’une donnée candidate et d’une donnée attendue, la donnée candidate étant le deuxième résultat d’authentification et la donnée attendue étant obtenue en calculant le code d’authentification de la donnée d’entrée avec la clé dérivée. La clé dérivée est utilisée comme clé pour le calcul du code d’authentification de la donnée d’entrée Le dispositif électronique est authentifié si la donnée candidate et la donnée attendue sont identiques.
La donnée d’entrée peut être toute donnée connue du système 20 et du dispositif électronique 10, par exemple le challenge d’authentification, la donnée d’authentification, le résultat d’une concaténation du challenge d’authentification et de la donnée d’authentification, ou une autre donnée reçue préalablement par le système 20 et le dispositif électronique 10, typiquement lors d’une phase de fonctionnement du dispositif électronique 10 et du système 20 antérieure au procédé décrit ici.
Le code d’authentification est obtenu par le système 20 de façon similaire à son obtention par le dispositif électronique 10.
Par exemple, quand le dispositif électronique 10 détermine un code d’authentification tel que proposé dans la publication FIPS PUB 198-1 «The Keyed-Hash Message Authentication Code » du NIST et datée de Juillet 2008, le système 20 détermine aussi le code d’authentification tel que proposé dans cette publication.
En outre, comme dans le cas de la première possibilité, la clé dérivée est obtenue par le système 20 de façon similaire à son obtention par le dispositif électronique 10.
L’étape d’envoi de certificat au système (étape E400), l’étape de réception de certificat en provenance du dispositif électronique (étape E410), l’autre étape de vérification de certificat (étape E420), l’étape de détermination d’une donnée d’authentification (étape E500), l’étape d’envoi au dispositif électronique de la donnée d’authentification (étape E510), l’étape de réception de la donnée d’authentification (étape E520), l’étape de calcul d’un deuxième résultat d’authentification (étape E530), l’étape d’envoi au système du deuxième résultat d’authentification (étape E540), l’étape de réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550), et l’étape d’authentification du dispositif électronique (étape E560), sont dans une phase d’authentification du dispositif électronique (phase P2).
Cette phase d’authentification du dispositif électronique est typiquement mise en œuvre par le deuxième module du système 20 et le deuxième module du dispositif électronique 10.
Le deuxième module du système 20 peut ainsi mettre en œuvre, l’étape de réception de certificat en provenance du dispositif électronique (étape E410), l’autre étape de vérification de certificat (étape E420), l’étape de détermination d’une donnée d’authentification (étape E500), l’étape d’envoi au dispositif électronique de la donnée d’authentification (étape E510), l’étape de réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550) et l’étape d’authentification du dispositif électronique (étape E560).
Le deuxième module du dispositif électronique 10 peut mettre en œuvre, l’étape d’envoi de certificat au système (étape E400), l’étape de réception de la donnée d’authentification (étape E520), l’étape de calcul d’un deuxième résultat d’authentification (étape E530) et l’étape d’envoi au système du deuxième résultat d’authentification (étape E540).
Le procédé limite la sollicitation des ressources du dispositif électronique.
Le procédé mis en œuvre par le dispositif électronique invoque une fonction de désen- capsulation d’un mécanisme d’encapsulation de clé plutôt qu’une fonction de signature cryptographique pour l’authentification du dispositif électronique, et une fonction de vérification de signature cryptographique plutôt qu’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé pour l’authentification du système.
Le procédé mis en œuvre par le système invoque une fonction de signature cryptographique plutôt qu’une fonction de dé sencapsulation d’un mécanisme d’encapsulation de clé pour l’authentification du système, et une fonction d’encapsulation d’un mécanisme d’encapsulation de clé plutôt qu’une fonction de vérification de signature cryptographique pour l’authentification du dispositif électronique.
Le procédé mis en œuvre par le système permet ainsi au dispositif électronique d’invoquer une fonction de dé sencapsulation d’un mécanisme d’encapsulation de clé plutôt qu’une fonction de signature cryptographique pour l’authentification du dispositif électronique, et une fonction de vérification de signature cryptographique plutôt qu’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé pour l’authentification du système.
Le procédé est particulièrement adapté pour une authentification mutuelle entre le dispositif électronique et le système dans le cadre d’une communication synchrone entre ledit dispositif électronique et ledit système.
Ainsi dans un mode particulier de mise en œuvre, chaque étape d’envoi (typiquement l’envoi au système du challenge d’authentification, 1’ envoi de certificat au système et l’envoi au système du deuxième résultat d’authentification) et chaque étape de réception (typiquement la réception de certificat en provenance du système, la réception en provenance du système du premier résultat d’authentification et la réception de la donnée d’authentification) mise en œuvre par le dispositif électronique comprend une communication synchrone entre le dispositif électronique et le système.
Dans ce mode particulier de mise en œuvre, chaque étape d’envoi (typiquement 1’ envoi de certificat au dispositif électronique, l’envoi au dispositif électronique du premier résultat d’authentification et l’envoi au dispositif électronique de la donnée d’authentification) et chaque étape de réception (typiquement la réception en provenance du dispositif électronique du challenge d’authentification, la réception de certificat en provenance du dispositif électronique et la réception en provenance du dispositif électronique d’un deuxième résultat d’authentification) mise en œuvre par le système comprend une communication synchrone entre le dispositif électronique et le système.
Ainsi, chaque échange entre le dispositifs électronique 10 et le système 20 est direct et instantané.
Le procédé permet alors une authentification mutuelle par communication synchrone tout en limitant les traitements mis en œuvre par le dispositif électronique.
De façon avantageuse, un canal sécurisé peut être établi à partir de la clé dérivée pour des échanges ultérieurs de données entre le dispositif électronique et le système. Le procédé peut alors comprendre en outre une étape de réception en provenance du dispositif électronique ou une étape d’envoi au dispositif électronique (non figurées), respectivement une étape d’envoi au système et une étape de réception en provenance du système (non figurées), d’une donnée chiffrée et/ou authentifiée, avec au moins une clé d’échange calculée à partir de la clé dérivée.
Un homme du métier comprendra que les étapes de ce procédé peuvent être exécutées selon d’autres ordres, dans la mesure où chaque étape dispose des éléments (par exemple la clé publique, l’autre clé publique, le challenge d’authentification, le premier résultat d’authentification, la donnée d’authentification ou le deuxième résultat d’authentification) nécessaires à son exécution.
Les étapes de ce procédé peuvent ainsi être exécutées selon d’autres ordres, dans la mesure où
- pour chaque étape mise en œuvre par le dispositif électronique 10, ledit dispositif électronique dispose des éléments nécessaires à l’exécution de l’étape concernée, et
- pour chaque étape mise en œuvre par le système 20, ledit système dispose des éléments nécessaires à l’exécution de l’étape concernée.
Selon un premier exemple, les étapes de la phase d’authentification du dispositif électronique (phase P2) peuvent être exécutées avant les étapes de la phase d’authentification du système (phase PI).
Typiquement, l’étape d’envoi de certificat au système (étape E400), l’étape de réception de certificat en provenance du dispositif électronique (étape E410), l’autre étape de vérification de certificat (étape E420), l’étape de détermination d’une donnée d’authentification (étape E500), l’étape d’envoi au dispositif électronique de la donnée d’authentification (étape E510), l’étape de réception de la donnée d’authentification (étape E520), l’étape de calcul d’un deuxième résultat d’authentification (étape E530), l’étape d’envoi au système du deuxième résultat d’authentification (étape E540), l’étape de réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550), et l’étape d’authentification du dispositif électronique (étape E560), peuvent être exécutées, par exemple dans cet ordre, avant l’exécution de l’étape d’envoi de certificat au dispositif électronique (étape E200), de l’étape de réception de certificat en provenance du système (étape E210), de l’étape de vérification de certificat (étape E220), de l’étape de détermination d’un challenge d’authentification (étape E300), de l’étape d’envoi au système du challenge d’authentification (étape E310), de l’étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320), de l’étape de calcul d’un premier résultat d’authentification (étape E330), de l’étape d’envoi au dispositif électronique du premier résultat d’authentification (étape E340), de l’étape de réception en provenance du système du premier résultat d’authentification (étape E350) et de l’étape d’authentification du système (étape E360), par exemple dans cet ordre.
Selon un deuxième exemple, l’exécution des étapes de la phase d’authentification du dispositif électronique (phase P2) et les étapes de la phase d’authentification du système (phase PI) peuvent être imbriquées, la phase d’authentification du dispositif électronique et la phase d’authentification du système se déroulant ainsi de façon concomitante.
Typiquement, les étapes du procédé peuvent être exécutées dans Tordre suivant :
- détermination d’un challenge d’authentification (étape E300), puis
- envoi de certificat au système (étape E400) et envoi au système du challenge d’authentification (étape E310), puis
- réception de certificat en provenance du dispositif électronique (étape E410) et réception en provenance du dispositif électronique du challenge d’authentification (étape E320), puis
- vérification de certificat (étape E420), puis
- détermination d’une donnée d’authentification (étape E500) et calcul d’un premier résultat d’authentification (étape E330), puis
- envoi de certificat au dispositif électronique (étape E200), envoi au dispositif électronique du premier résultat d’authentification (étape E340) et envoi au dispositif électronique de la donnée d’authentification (étape E510), puis
- réception de certificat en provenance du système (étape E210), réception en provenance du système du premier résultat d’authentification (étape E350) et réception de la donnée d’authentification (étape E520), puis
- vérification de certificat (étape E220), puis
- authentification du système (étape E360), puis
- calcul d’un deuxième résultat d’authentification (étape E530), puis
- envoi au système du deuxième résultat d’authentification (étape E540), puis
- réception en provenance du dispositif électronique du deuxième résultat d’authentification (étape E550), puis
- authentification du dispositif électronique (étape E560).
De façon avantageuse, l’envoi de certificat au système (étape E400) et l’envoi au système du challenge d’authentification (étape E310), respectivement la réception de certificat en provenance du dispositif électronique (étape E410) et la réception en provenance du dispositif électronique du challenge d’authentification (étape E320), peuvent être exécutées simultanément en regroupant le certificat de la clé publique et le challenge d’authentification dans un même message envoyé par le dispositif électronique au système.
En outre, de façon avantageuse, l’envoi de certificat au dispositif électronique (étape E200) et l’envoi au dispositif électronique du premier résultat d’authentification (étape E340) et l’envoi au dispositif électronique de la donnée d’authentification (étape E510), respectivement la réception de certificat en provenance du système (étape E210) et la réception en provenance du système du premier résultat d’authentification (étape E350) et la réception de la donnée d’authentification (étape E520), peuvent être exécutées si- multanément en regroupant le certificat de l’autre clé publique, le premier résultat d’authentification et la donnée d’authentification dans un même autre message envoyé par le système au dispositif électronique.
Le premier module et le deuxième module du dispositif électronique 10 peuvent donc coopérer pour la mise en œuvre d’étapes du procédé.
De même, le premier module et le deuxième module du système 20 peuvent donc coopérer pour la mise en œuvre d’étapes du procédé.
Enfin, notamment quand les étapes sont ordonnées comme décrit ci-dessus pour le deuxième exemple, la donnée de référence peut être la concaténation de la donnée d’authentification (calculée par le système pendant l’étape de détermination d’une donnée d’authentification) et du challenge d’authentification (reçu en provenance du dispositif électronique). L’autre donnée de référence est alors la concaténation de la donnée d’authentification (reçu en provenance du système) et du challenge d’authentification (déterminé par le dispositif électronique et envoyé au système).
La phase d’authentification du dispositif électronique et la phase d’authentification du système sont ainsi cryptograph! quement liées. La sécurité du procédé d’authentification mutuelle est ainsi renforcée.
Un homme du métier comprendra aussi que des étapes de ce procédé peuvent être omises dans la mesure où les autres étapes disposent des éléments nécessaires à leur exécution.
Selon un premier exemple, l’étape d’envoi de certificat au dispositif électronique (étape E200), l’étape de réception de certificat en provenance du système (étape E210) et l’étape de vérification de certificat (étape E220) peuvent être omises quand le dispositif électronique 10 dispose déjà de l’autre clé publique, typiquement lorsque le dispositif électronique 10 a préalablement reçu l’autre clé publique (par exemple d’un ordinateur distant ou du système 20) lors d’une phase de fonctionnement du dispositif électronique 10 antérieure au procédé décrit ici
Selon un deuxième exemple, l’étape d’envoi de certificat au système (étape E400), l’étape de réception de certificat en provenance du dispositif électronique (étape E410) et l’autre étape de vérification de certificat (étape E420) peuvent être omises quand le système 20 dispose déjà de la clé publique, typiquement lorsque le système 20 a préalablement reçu la clé publique (par exemple d’un ordinateur distant ou du dispositif électronique 10) lors d’une phase de fonctionnement du système 20 antérieure au procédé décrit ici.
La figure 3 représente sous forme de logigramme les étapes principales d’un procédé d’authentification mutuelle selon un deuxième mode d’implémentation de l’invention. Ce procédé est mis en œuvre par le dispositif électronique 10, le dispositif électronique 10 disposant d’une clé privée associée à une clé publique et coopérant avec le système 20, et par le système 20, le système 20 disposant d’une autre clé privée associée à une autre clé publique et coopérant avec le dispositif électronique 10.
Typiquement, le dispositif électronique 10 dispose de la clé privée dans au moins une de ses mémoires, et le système 20 dispose de l’autre clé privée dans au moins une de ses mémoires.
En outre, le dispositif électronique 10 dispose d’un certificat de la clé publique dans au moins une de ses mémoires, et le système 20 dispose d’un certificat de l’autre clé publique dans au moins une de ses mémoires.
Selon une étape d’envoi au dispositif électronique d’une clé publique éphémère (étape El 00), le système 20 envoie au dispositif électronique 10 une clé publique éphémère associée à une clé privée éphémère, typiquement en utilisant son bloc de communication 12.
Le système 20 dispose de la clé publique éphémère et de la clé privée éphémère, typiquement dans une de ses mémoires.
Selon une possibilité de réalisation, le système 20 a préalablement reçu la clé publique éphémère et la clé privée éphémère (par exemple d’un ordinateur distant) lors d’une phase de fonctionnement du système 20 antérieure au procédé décrit ici.
Selon une autre possibilité de réalisation, le système 20 a préalablement déterminé la clé publique éphémère et la clé privée éphémère au cours d’une étape de détermination de clés éphémères (non représentée).
Selon un premier exemple, la clé publique éphémère et la clé privée éphémère sont des clés ECIES telles que décrites dans le document BSI TR-02102-1 : BSI- Technical Guideline, version 2022-01, daté du 28 Janvier 2022, https://www.bsi.bund.de/Sha- redDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102- l.pdf? blob =publicationFile.
Selon un deuxième exemple, la clé publique éphémère et la clé privée éphémère sont des clés Crystals-Kyber telles que décrites sur le site Crystals - Cryptographie Suite for Algebraic Lattices, https ://pq-crystals. org/kyber/index. shtml.
Selon un troisième exemple la clé publique éphémère et la clé privée éphémère sont des clés NTRU telles que décrites sur le site NTRU- a submission to the NIST post-quantum standardization effort, https://ntru.org/.
Le procédé comprend alors une étape de réception en provenance du système de la clé publique éphémère (étape El 10), pendant laquelle le dispositif électronique 10 reçoit en provenance du système 20 la clé publique éphémère, typiquement en utilisant son bloc de communication 2.
Le procédé comprend alors une étape d’obtention d’un autre secret partagé, c’est-à-dire d’un secret partagé différent du secret partagé obtenu et utilisé pendant la phase d’authentification du dispositif électronique (voir ci-après), et d’un chiffré correspondant (étape El 20), pendant laquelle le dispositif électronique 10 obtient ledit autre secret partagé et ledit chiffré correspondant par application à la clé publique éphémère d’une fonction d’encapsulation d’un autre mécanisme d’encapsulation de clé, c’est-à-dire d’un mécanisme d’encapsulation de clé qui peut être différent du mécanisme d’encapsulation utilisé pendant la phase d’authentification du dispositif électronique (voir ci-après).
Des exemples de fonctions d’encapsulation de l’autre mécanisme d’encapsulation sont décrits dans les références citées ci-avant pour les exemples de la clé publique éphémère et la clé privée éphémère.
Typiquement, si la clé publique éphémère et la clé privée éphémère sont des clés ECIES telles que décrites dans le document BSI TR-02102-1 : BSI Technical Guideline, version 2022-01, daté du 28 Janvier 2022, https://www.bsi.bund.de/SharedDocs/Dow- nloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102- l.pdf? blob=publicationFile, la fonction d’encapsulation de l’autre mécanisme d’encapsulation est telle que décrite dans ce document.
La clé publique éphémère permet au système d’introduire un aléa qui force l’utilisation d’un nouveau autre secret partagé à chaque itération du procédé.
L’application de la fonction d’encapsulation de l’autre mécanisme d’encapsulation de clé, permet au dispositif électronique d’introduire un aléa qui force aussi l’utilisation d’un nouveau autre secret partagé à chaque itération du procédé.
Le procédé comprend alors une étape d’obtention d’une autre clé dérivée (étape E130), c’est-à-dire d’une clé dérivée différente de la clé dérivée obtenue et utilisée pendant la phase d’authentification du dispositif électronique (voir ci-après), pendant laquelle le dispositif électronique 10 obtient ladite autre clé dérivée à partir de l’autre secret partagé.
L’autre clé dérivée peut être obtenue par application d’une fonction de dérivation de clé de l’état de l’art à l’autre secret partagé.
Selon une autre possibilité, l’autre clé dérivée est l’autre secret partagé.
Le procédé comprend alors une étape d’envoi au système du chiffré correspondant à l’autre secret partagé (étape E140) pendant laquelle le dispositif électronique 10 envoie au système 20 le chiffré correspondant à l’autre secret partagé, typiquement en utilisant son bloc de communication 2.
Le procédé comprend alors une étape de réception en provenance du dispositif électronique du chiffré correspondant à l’autre secret partagé (étape El 50) pendant laquelle le système 20 reçoit en provenance du dispositif électronique 10 le chiffré correspondant à l’autre secret partagé, typiquement en utilisant son bloc de communication 12.
Le procédé comprend alors une étape d’obtention de l’autre secret partagé (étape El 60) pendant laquelle le système 20 obtient l’autre secret partagé par application à la clé privée éphémère et au chiffré reçu pendant l’étape de réception en provenance du dispositif électronique du chiffré correspondant à l’autre secret partagé (étape El 50), d’une fonction de désencapsulation de l’autre mécanisme d’encapsulation de clé.
Des exemples de fonctions de désencapsulation de l’autre mécanisme d’encapsulation sont décrits dans les références citées ci -avant pour les exemples de la clé publique éphémère et la clé privée éphémère.
Typiquement, si la clé publique éphémère et la clé privée éphémère sont des clés ECIES telles que décrites dans le document BSI TR-02102-1 : BSI Technical Guideline, version 2022-01, daté du 28 Janvier 2022, https://www.bsi.bund.de/SharedDocs/Dow- nloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102- l.pdj? blob =publicationFile, la fonction de désencapsulation de l’autre mécanisme d’encapsulation est telle que décrite dans ce document.
Le procédé comprend alors une autre étape d’obtention de l’autre clé dérivée (étape E170), pendant laquelle le système 20 obtient l’autre clé dérivée à partir de l’autre secret partagé.
L’autre clé dérivée est obtenue par le système 20 de façon similaire à son obtention par le dispositif électronique 10.
Par exemple, quand le dispositif électronique obtient l’autre clé dérivée par application d’une fonction de dérivation de clé de l’état de l’art à l’autre secret partagé déterminé pendant l’étape d’obtention d’un autre secret partagé et d’un chiffré correspondant (étape E120), le système calcule l’autre clé dérivée par application de cette fonction de dérivation à l’autre secret partagé déterminé pendant l’étape d’obtention de l’autre secret partagé (étape El 60).
L’étape d’envoi au dispositif électronique d’une clé publique éphémère (étape E100), l’étape de réception en provenance du système de la clé publique éphémère (étape El 10), l’étape d’obtention d’un autre secret partagé et d’un chiffré correspondant (étape E120), l’étape d’obtention d’une autre clé dérivée (étape E130), l’étape d’envoi au système du chiffré correspondant à l’autre secret partagé (étape El 40), l’étape de réception en provenance du dispositif électronique du chiffré correspondant à l’autre secret partagé (étape E150), l’étape d’obtention de l’autre secret partagé (étape E160) et l’autre étape d’obtention de l’autre clé dérivée (étape E170) sont typiquement mises en œuvre par le troisième module du système 20 et le troisième module du dispositif électronique 10.
Le troisième module du système 20 peut ainsi mettre en œuvre, l’étape d’envoi au dispositif électronique d’une clé publique éphémère (étape E100), l’étape de réception en provenance du dispositif électronique du chiffré correspondant à l’autre secret partagé (étape E150), l’étape d’obtention de l’autre secret partagé (étape E160) et l’autre étape d’obtention de l’autre clé dérivée (étape E170).
Le troisième module du dispositif électronique 10 peut mettre en œuvre, l’étape de réception en provenance du système de la clé publique éphémère (étape El 10), l’étape d’obtention d’un autre secret partagé et d’un chiffré correspondant (étape E120), l’étape d’obtention d’une autre clé dérivée (étape E130) et l’étape d’envoi au système du chiffré correspondant à l’autre secret partagé (étape El 40).
Selon une étape d’envoi de certificat au système (étape E401), le dispositif électronique 10 envoie au système 20 le certificat de la clé publique. Pendant cette étape, le dispositif électronique 10 envoie au système 20 un résultat d’un chiffrement avec l’autre clé dérivée, d’une donnée comprenant le certificat de la clé publique, typiquement en utilisant son bloc de communication 2.
Selon une étape de réception de certificat en provenance du dispositif électronique (étape E411), le système 20 reçoit en provenance du dispositif électronique 10 le certificat de la clé publique, typiquement en utilisant son bloc de communication 12. Pendant cette étape, le système 20 reçoit en provenance du dispositif électronique 10 un chiffré de la donnée comprenant le certificat de la clé publique, et déchiffre avec l’autre clé dérivée une donnée émise par le dispositif électronique, c’est-à-dire ledit chiffré de la donnée comprenant le certificat de la clé publique.
L’opération de déchiffrement exécutée ici par le système 20 est selon un algorithme cryptographique, par exemple AES, associé à l’opération de chiffrement exécutée par le dispositif électronique 10 pendant l’étape d’envoi de certificat au système (étape E401). La sécurité du procédé d’authentification mutuelle est ainsi renforcée.
Le procédé d’authentification mutuelle permet d’assurer la confidentialité du certificat de la clé publique envoyé par le dispositif électronique au système.
Le procédé permet ainsi au dispositif électronique et au système d’assurer la non traçabilité du dispositif électronique.
Le procédé comprend alors une étape de vérification de certificat identique à l’autre étape de vérification de certificat du premier mode d’implémentation (étape E420). Le procédé comprend alors une étape de détermination d’une donnée d’authentification (étape E500), une étape d’envoi au dispositif électronique de la donnée d’authentification (étape E510), une étape de réception de la donnée d’authentification (étape E520), une étape de calcul d’un deuxième résultat d’authentification (étape E530), une étape d’envoi au système du deuxième résultat d’authentification (étape E540), une étape de réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550), et une étape d’authentification du dispositif électronique (étape E560), identiques à celles décrites pour le premier mode d’implémentation.
L’étape d’envoi de certificat au système (étape E401), l’étape de réception de certificat en provenance du dispositif électronique (étape E411), l’étape de vérification de certificat (étape E420), l’étape de détermination d’une donnée d’authentification (étape E500), l’étape d’envoi au dispositif électronique de la donnée d’authentification (étape E510), l’étape de réception de la donnée d’authentification (étape E520), l’étape de calcul d’un deuxième résultat d’authentification (étape E530), l’étape d’envoi au système du deuxième résultat d’authentification (étape E540), l’étape de réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550), et l’étape d’authentification du dispositif électronique 10 (étape E560), sont dans une phase d’authentification du dispositif électronique (phase P2).
Cette phase d’authentification du dispositif électronique est typiquement mise en œuvre par le deuxième module du système 20 et le deuxième module du dispositif électronique 10.
Le deuxième module du système 20 peut ainsi mettre en œuvre, l’étape de réception de certificat en provenance du dispositif électronique (étape E411), l’étape de vérification de certificat (étape E420), l’étape de détermination d’une donnée d’authentification (étape E500), l’étape d’envoi au dispositif électronique de la donnée d’authentification (étape E510), l’étape de réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550) et l’étape d’authentification du dispositif électronique (étape E560).
Le deuxième module du dispositif électronique 10 peut mettre en œuvre, l’étape d’envoi de certificat au système (étape E401), l’étape de réception de la donnée d’authentification (étape E520), l’étape de calcul d’un deuxième résultat d’authentification (étape E530) et l’étape d’envoi au système du deuxième résultat d’authentification (étape E540).
Selon une étape d’envoi de certificat au dispositif électronique (étape E201), le système 20 envoie au dispositif électronique 10 le certificat de l’autre clé publique. Pendant cette étape, le système 20 envoie au dispositif électronique 10 un résultat d’un chiffrement avec l’autre clé dérivée d’une donnée comprenant le certificat de l’autre clé publique, typiquement en utilisant son bloc de communication 12.
Selon une étape de réception de certificat en provenance du système (étape E211), le dispositif électronique 10 reçoit en provenance du système 20 le certificat de l’autre clé publique, typiquement en utilisant son bloc de communication 2.
Pendant cette étape, le dispositif électronique 10 reçoit en provenance du système 20 un chiffré de la donnée comprenant le certificat de l’autre clé publique et déchiffre avec l’autre clé dérivée une donnée émise par le système, c’est-à-dire ledit chiffré de la donnée comprenant le certificat de l’autre clé publique.
L’opération de déchiffrement exécutée ici par le dispositif électronique 10 est selon un algorithme cryptographique, par exemple AES, associé à l’opération de chiffrement exécutée par le système 20 pendant l’étape d’envoi de certificat au dispositif électronique (étape E201). Cet algorithme cryptographique est de préférence le même que celui mis en œuvre pendant l’étape d’envoi de certificat au système (étape E401) et l’étape de réception de certificat en provenance du dispositif électronique (étape E411).
La sécurité du procédé d’authentification mutuelle est ainsi renforcée.
Le procédé d’authentification mutuelle permet d’assurer la confidentialité du certificat de l’autre clé publique envoyé par le système au dispositif électronique.
Le procédé permet ainsi au dispositif électronique et au système d’assurer la non traçabilité du système.
Le procédé comprend alors une autre étape de vérification de certificat identique à l’étape de vérification de certificat du premier mode d’implémentation (étape E220). Le procédé comprend alors une étape de détermination d’un challenge d’authentification (étape E300), une étape d’envoi au système du challenge d’authentification (étape E310), une étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320), une étape de calcul d’un premier résultat d’authentification (étape E330), une étape d’envoi au dispositif électronique du premier résultat d’authentification (étape E340), une étape de réception en provenance du système du premier résultat d’authentification (étape E350) et une étape d’authentification du système (étape E360), identiques à celles décrites pour le premier mode d’implémentation.
L’étape d’envoi de certificat au dispositif électronique (étape E201), l’étape de réception de certificat en provenance du système (étape E211), l’autre étape de vérification de certificat (étape E220), l’étape de détermination d’un challenge d’authentification (étape E300), l’étape d’envoi au système du challenge d’authentification (étape E310), l’étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320), l’étape de calcul d’un premier résultat d’authentification (étape E330), l’étape d’envoi au dispositif électronique du premier résultat d’authentification (étape E340), l’étape de réception en provenance du système du premier résultat d’authentification (étape E350), et l’étape d’authentification du système (étape E360), sont dans une phase d’authentification du système (phase PI).
Cette phase d’authentification du système est typiquement mise en œuvre par le premier module du système 20 et le premier module du dispositif électronique 10.
Le premier module du système 20 peut ainsi mettre en œuvre l’étape d’envoi de certificat au dispositif électronique (étape E201), l’étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320), l’étape de calcul d’un premier résultat d’authentification (étape E330) et l’étape d’envoi au dispositif électronique du premier résultat d’authentification (étape E340).
Le premier module du dispositif électronique 10 peut en œuvre l’étape de réception de certificat en provenance du système (étape E211), l’autre étape de vérification de certificat (étape E220), l’étape de détermination d’un challenge d’authentification (étape E300), l’étape d’envoi au système du challenge d’authentification (étape E310), l’étape de réception en provenance du système du premier résultat d’authentification (étape E350), et l’étape d’authentification du système (étape E360).
Le procédé limite la sollicitation des ressources du dispositif électronique.
Le procédé mis en œuvre par le dispositif électronique invoque une fonction de désen- capsulation d’un mécanisme d’encapsulation de clé plutôt qu’une fonction de signature cryptographique pour l’authentification du dispositif électronique, et une fonction de vérification de signature cryptographique plutôt qu’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé pour l’authentification du système.
Le procédé mis en œuvre par le système invoque une fonction de signature cryptographique plutôt qu’une fonction de dé sencapsulation d’un mécanisme d’encapsulation de clé pour l’authentification du système, et une fonction d’encapsulation d’un mécanisme d’encapsulation de clé plutôt qu’une fonction de vérification de signature cryptographique pour l’authentification du dispositif électronique.
Le procédé mis en œuvre par le système permet ainsi au dispositif électronique d’invoquer une fonction de dé sencapsulation d’un mécanisme d’encapsulation de clé plutôt qu’une fonction de signature cryptographique pour l’authentification du dispositif électronique, et une fonction de vérification de signature cryptographique plutôt qu’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé pour l’authentification du système.
La sécurité du procédé d’authentification mutuelle est aussi renforcée.
Ce procédé d’authentification mutuelle permet d’assurer la confidentialité du certificat de la clé publique envoyé par le dispositif électronique au système, et la confidentialité du certificat de l’autre clé publique envoyé par le système au dispositif électronique.
La clé publique éphémère permet au système d’introduire un aléa qui force l’utilisation d’un nouveau autre secret partagé à chaque itération du procédé.
L’application de la fonction d’encapsulation de l’autre mécanisme d’encapsulation de clé, permet au dispositif électronique d’introduire un aléa qui force aussi l’utilisation d’un nouveau autre secret partagé à chaque itération du procédé.
Ce procédé permet ainsi au dispositif électronique et/ou au système d’assurer la non traçabilité du dispositif électronique et du système.
On notera que la sollicitation des ressources du dispositif électronique reste limitée. Le procédé mis en œuvre par le dispositif électronique invoque une seule fois la fonction de désencapsulation du mécanisme d’encapsulation de clé, et une seule fois la fonction d’encapsulation de l’autre mécanisme d’encapsulation de clé.
Enfin, le procédé limite les échanges entre le dispositif électronique et le système.
Le procédé est particulièrement adapté pour une authentification mutuelle entre le dispositif électronique et le système dans le cadre d’une communication synchrone entre ledit dispositif électronique et ledit système.
Ainsi dans un mode particulier de mise en œuvre, chaque étape d’envoi (typiquement l’envoi au système du chiffré correspondant à l’autre secret partagé, l’envoi au système du challenge d’authentification, 1’ envoi de certificat au système et l’envoi au système du deuxième résultat d’authentification) et chaque étape de réception (typiquement la réception en provenance du système de la clé publique éphémère, la réception de certificat en provenance du système, la réception en provenance du système du premier résultat d’authentification et la réception de la donnée d’authentification) mise en œuvre par le dispositif électronique comprend une communication synchrone entre le dispositif électronique et le système.
Dans ce mode particulier de mise en œuvre, chaque étape d’envoi (typiquement l’envoi au dispositif électronique d’une clé publique éphémère, 1’ envoi de certificat au dispositif électronique, l’envoi au dispositif électronique du premier résultat d’authentification et l’envoi au dispositif électronique de la donnée d’authentification) et chaque étape de réception (typiquement la réception en provenance du dispositif électronique du chiffré correspondant à l’autre secret partagé, la réception en provenance du dispositif électronique du challenge d’authentification, la réception de certificat en provenance du dispositif électronique et la réception en provenance du dispositif électronique d’un deuxième résultat d’authentification) mise en œuvre par le système comprend une communication synchrone entre le dispositif électronique et le système.
Ainsi, chaque échange entre le dispositifs électronique 10 et le système 20 est direct et instantané.
Le procédé permet alors une authentification mutuelle par communication synchrone tout en limitant les traitements mis en œuvre par le dispositif électronique.
De façon avantageuse, un canal sécurisé peut être établi à partir de la clé dérivée pour des échanges ultérieurs de données entre le dispositif électronique et le système.
Le procédé peut alors comprendre en outre une étape de réception en provenance du dispositif électronique ou une étape d’envoi au dispositif électronique (non figurées), respectivement une étape d’envoi au système et une étape de réception en provenance du système (non figurées), d’une donnée chiffrée et/ou authentifiée, avec au moins une clé d’échange calculée à partir de la clé dérivée.
Dans un autre mode particulier de mise en œuvre, l’étape d’envoi (E340) au dispositif électronique du premier résultat d’authentification, et l’étape (E510) d’envoi au dispositif électronique de la donnée d’authentification, comprennent un chiffrement avec l’autre clé dérivée des données à envoyer.
Pendant l’étape d’envoi au dispositif électronique du premier résultat d’authentification (E340), le système 20 chiffre avec l’autre clé dérivée le premier résultat d’authentification puis envoie le chiffré du premier résultat d’authentification au dispositif électronique 10.
Pendant l’étape d’envoi au dispositif électronique de la donnée d’authentification (E510), le système 20 chiffre avec l’autre clé dérivée la donnée d’authentification puis envoie le chiffré de la donnée d’authentification au dispositif électronique 10.
Le procédé d’authentification mutuelle permet ainsi d’assurer la confidentialité des autres données émises par le système.
Typiquement, le procédé d’authentification mutuelle permet d’assurer la confidentialité du premier résultat d’authentification et de la donnée d’authentification, envoyés par le système au dispositif électronique.
Dans cet autre mode particulier de mise en œuvre, l’étape de réception en provenance du système du premier résultat d’authentification (étape E350), et l’étape de réception de la donnée d’authentification (étape E520), comprennent le déchiffrement avec l’autre clé dérivée de données émises par le système.
Pendant l’étape de réception en provenance du système du premier résultat d’authentification (étape E350), le dispositif électronique 10 reçoit en provenance du système 20 le chiffré du premier résultat d’authentification puis déchiffre avec l’autre clé dérivée le chiffré du premier résultat d’authentification pour obtenir le premier résultat d’authentification.
Pendant l’étape de réception de la donnée d’authentification (étape E520), le dispositif électronique 10 reçoit en provenance du système 20 le chiffré de la donnée d’authentification puis déchiffre avec l’autre clé dérivée le chiffré de la donnée d’authentification pour obtenir la donnée d’authentification.
Ces opérations de déchiffrement exécutées par le dispositif électronique 10 sont selon un algorithme cryptographique, par exemple AES, associé aux opérations de chiffrement exécutées par le système 20 pendant l’étape d’envoi au dispositif électronique du premier résultat d’authentification (E340), et l’étape d’envoi au dispositif électronique de la donnée d’authentification (E510). Ces opérations de déchiffrement et de déchiffrement peuvent être selon le même algorithme cryptographique que celui utilisé pour les opérations de chiffrement et déchiffrement de l’étape d’envoi de certificat au système (étape E401) et de l’étape de réception de certificat en provenance du dispositif électronique (étape E411), et/ou de l’étape d’envoi de certificat au dispositif électronique (étape E201) et de l’étape de réception de certificat en provenance du système (étape E211).
Un homme du métier comprendra que les étapes de ce procédé peuvent être exécutées selon d’autres ordres, dans la mesure où chaque étape dispose des éléments (par exemple la clé publique, l’autre clé publique, le challenge d’authentification, le premier résultat d’authentification, la donnée d’authentification ou le deuxième résultat d’authentification) nécessaires à son exécution.
Les étapes de ce procédé peuvent ainsi être exécutées selon d’autres ordres, dans la mesure où
- pour chaque étape mise en œuvre par le dispositif électronique 10, ledit dispositif électronique dispose des éléments nécessaires à l’exécution de l’étape concernée, et
- pour chaque étape mise en œuvre par le système 20, ledit système dispose des éléments nécessaires à l’exécution de l’étape concernée.
Selon un premier exemple, les étapes de la phase d’authentification du système (phase PI) peuvent être exécutées avant les étapes de la phase d’authentification du dispositif électronique (phase P2).
Typiquement, l’étape d’envoi de certificat au dispositif électronique (étape E201), l’étape de réception de certificat en provenance du système (étape E211), l’autre étape de vérification de certificat (étape E220), l’étape de détermination d’un challenge d’authentification (étape E300), l’étape d’envoi au système du challenge d’authentification (étape E310), l’étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320), l’étape de calcul d’un premier résultat d’authentification (étape E330), l’étape d’envoi au dispositif électronique du premier résultat d’authentification (étape E340), l’étape de réception en provenance du système du premier résultat d’authentification (étape E350) et l’étape d’authentification du système (étape E360), peuvent être exécutées, par exemple dans cet ordre, avant l’exécution de l’étape d’envoi de certificat au système (étape E401), de l’étape de réception de certificat en provenance du dispositif électronique (étape E411), de l’étape de vérification de certificat (étape E420), de l’étape de détermination d’une donnée d’authentification (étape E500), de l’étape d’envoi au dispositif électronique de la donnée d’authentification (étape E510), de l’étape de réception de la donnée d’authentification (étape E520), de l’étape de calcul d’un deuxième résultat d’authentification (étape E530), de l’étape d’envoi au système du deuxième résultat d’authentification (étape E540), de l’étape de réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550), et de l’étape d’authentification du dispositif électronique 10 (étape E560), par exemple dans cet ordre.
Selon un deuxième exemple, l’exécution des étapes de la phase d’authentification du dispositif électronique (phase P2), et l’exécution des étapes de la phase d’authentification du système (phase PI) peuvent être imbriquées, la phase d’authentification du dispositif électronique et la phase d’authentification du système se déroulant ainsi de façon concomitante.
Typiquement, les étapes du procédé peuvent être exécutées dans Tordre suivant :
- détermination d’un challenge d’authentification (étape E300), puis
- envoi de certificat au système (étape E400) et envoi au système du challenge d’authentification (étape E310), puis
- réception de certificat en provenance du dispositif électronique (étape E410) et réception en provenance du dispositif électronique du challenge d’authentification (étape E320), puis
- vérification de certificat (étape E420), puis
- détermination d’une donnée d’authentification (étape E500) et calcul d’un premier résultat d’authentification (étape E330), puis
- envoi de certificat au dispositif électronique (étape E200), envoi au dispositif électronique du premier résultat d’authentification (étape E340) et envoi au dispositif électronique de la donnée d’authentification (étape E510), puis
- réception de certificat en provenance du système (étape E210), réception en provenance du système du premier résultat d’authentification (étape E350) et réception de la donnée d’authentification (étape E520), puis
- vérification de certificat (étape E220), puis
- authentification du système (étape E360), puis
- calcul d’un deuxième résultat d’authentification (étape E530), puis
- envoi au système du deuxième résultat d’authentification (étape E540), puis
- réception en provenance du dispositif électronique d’un deuxième résultat d’authentification (étape E550), puis
- authentification du dispositif électronique (étape E560).
Selon une première possibilité avantageuse, l’envoi de certificat au système (étape E401) et l’envoi au système du challenge d’authentification (étape E310), respectivement la réception de certificat en provenance du dispositif électronique (étape E411) et la réception en provenance du dispositif électronique du challenge d’authentification (étape E320), peuvent être exécutées simultanément en regroupant le chiffré du certificat de la clé publique et le challenge d’authentification dans un même message envoyé par le dispositif électronique au système.
Selon une deuxième possibilité avantageuse, l’envoi de certificat au dispositif électronique (étape E201) et l’envoi au dispositif électronique du premier résultat d’authentification (étape E340) et l’envoi au dispositif électronique de la donnée d’authentification (étape E510), respectivement la réception de certificat en provenance du système (étape E211) et la réception en provenance du système du premier résultat d’authentification (étape E350) et la réception de la donnée d’authentification (étape E520), peuvent être exécutées simultanément en regroupant le chiffré du certificat de l’autre clé publique, le premier résultat d’authentification (ou son chiffré) et la donnée d’authentification (ou son chiffré) dans un même autre message envoyé par le système au dispositif électronique.
On notera ainsi que la donnée comprenant le certificat de l’autre clé publique peut être par exemples le certificat de l’autre clé publique, ou le résultat d’une concaténation du certificat de l’autre clé publique et du premier résultat d’authentification, ou le résultat d’une concaténation du certificat de l’autre clé publique et de la donnée d’authentification, ou le résultat d’une concaténation du certificat de l’autre clé publique, du premier résultat d’authentification et de la donnée d’authentification.
Selon une troisième possibilité avantageuse, le challenge d’authentification est le chiffré correspondant à l’autre secret partagé ou le chiffré de la donnée comprenant le certificat de la clé publique.
On notera que les propriétés de la fonction d’encapsulation assurent que l’autre secret partagé a une valeur aléatoire. Ainsi, l’autre secret partagé est différent à chaque itération du procédé. Le chiffré correspondant à l’autre secret partagé et le chiffré de la donnée comprenant le certificat de la clé publique sont donc aussi différents à chaque itération du procédé.
Avec cette troisième possibilité avantageuse, l’étape d’obtention d’un autre secret partagé et d’un chiffré correspondant (étape E120) ou l’étape d’envoi de certificat au système (étape E401) peut être l’étape de détermination d’un challenge d’authentification (étape E300).
En outre, l’étape d’envoi au système du chiffré correspondant à l’autre secret partagé (étape El 40) ou l’étape d’envoi de certificat au système (étape E401) peut être l’étape d’envoi au système du challenge d’authentification (étape E310).
Enfin, l’étape de réception en provenance du dispositif électronique du chiffré correspondant à l’autre secret partagé (étape E150) ou l’étape de réception de certificat en provenance du dispositif électronique (étape E411) peut être l’étape de réception en provenance du dispositif électronique du challenge d’authentification (étape E320).
Le procédé limite ainsi d’avantage la sollicitation des ressources du dispositif électronique et du système et limite les échanges entre le dispositif électronique et le système. Le premier module, le deuxième module et le troisième module du dispositif électronique 10 peuvent donc coopérer pour la mise en œuvre d’étapes du procédé.
De même, le premier module, le deuxième module et le troisième module du système 20 peuvent donc coopérer pour la mise en œuvre d’étapes du procédé.
Selon une quatrième possibilité avantageuse, notamment quand les étapes sont ordonnées comme décrit ci-dessus pour le deuxième exemple, la donnée de référence peut être la concaténation de la donnée d’authentification (calculée par le système pendant l’étape de détermination d’une donnée d’authentification) ou de son chiffré, et du challenge d’authentification (reçu en provenance du dispositif électronique). L’autre donnée de référence est alors la concaténation de la donnée d’authentification (ou de son chiffré) reçu en provenance du système, et du challenge d’authentification (déterminé par le dispositif électronique et envoyé au système).
La phase d’authentification du dispositif électronique et la phase d’authentification du système sont ainsi cryptograph! quement liées. La sécurité du procédé d’authentification mutuelle est ainsi renforcée. Selon une cinquième possibilité avantageuse, l’étape d’envoi au système du chiffré correspondant à l’autre secret partagé (étape El 40) et l’étape d’envoi de certificat au système (étape E401), respectivement l’étape de réception en provenance du dispositif électronique du chiffré correspondant à l’autre secret partagé (étape E150) et l’étape de réception de certificat en provenance du dispositif électronique (étape E411), peuvent être exécutées simultanément en regroupant le chiffré du certificat de la clé publique et le chiffré correspondant à l’autre secret partagé dans un même message envoyé par le dispositif électronique au système.
Un homme du métier comprendra aussi que des étapes de ce procédé peuvent être omises dans la mesure où les autres étapes disposent des éléments (par exemple les sommes d’intégrité, les sommes d’intégrité arithmétiques et/ou les sommes d’intégrité corrigées) nécessaires à leur exécution.

Claims

Revendications
[Revendication 1] Procédé d’authentification mutuelle entre un dispositif électronique (10) et un système (20), le procédé étant mis en œuvre par le dispositif électronique, le dispositif électronique disposant d’une clé privée associée à une clé publique, le système disposant d’une autre clé privée associée à une autre clé publique, et le procédé comprenant : i) une phase (PI) d’authentification du système comprenant les étapes suivantes :
- détermination (E300) d’un challenge d’authentification, puis
- envoi (E310) au système du challenge d’authentification, puis
- réception (E350) en provenance du système d’un premier résultat d’authentification, puis
- authentification (E360) du système avec le challenge d’authentification, le premier résultat d’authentification et l’autre clé publique, et ii) une phase (P2) d’authentification du dispositif électronique comprenant les étapes suivantes :
- réception (E520) en provenance du système d’une donnée d’authentification, puis
- calcul (E530) d’un deuxième résultat d’authentification en fonction de la donnée d’authentification et de la clé privée, puis
- envoi (E540) au système du deuxième résultat d’authentification, le procédé étant caractérisé en ce que :
- l’étape d’authentification du système est par application au premier résultat d’authentification et à une donnée de référence comprenant le challenge d’authentification, d’une fonction de vérification de signature cryptographique avec l’autre clé publique,
- le calcul du deuxième résultat d’authentification utilise un secret partagé obtenu par application à la clé privée et à la donnée d’authentification, d’une fonction de désencapsulation d’un mécanisme d’encapsulation de clé.
[Revendication 2] Procédé d’authentification mutuelle selon la revendication précédente dans lequel :
- le challenge d’authentification est un challenge anti -rejeu, et
- chaque étape d’envoi et chaque étape de réception comprend une communication synchrone entre le dispositif électronique et le système.
[Revendication 3] Procédé d’authentification mutuelle selon l’une quelconque des revendications précédentes dans lequel la donnée de référence est la concaténation de la donnée d’authentification et du challenge d’ authentification.
[Revendication 4] Procédé d’authentification mutuelle selon l’une quelconque des revendications précédentes dans lequel la phase (PI) d’authentification du système comprend en outre les étapes suivantes :
- réception (E210, E211) en provenance du système d’un certificat de l’autre clé publique, puis
- vérification (E220) de la validité du certificat reçu, et la phase (P2) d’authentification du dispositif électronique comprend en outre l’étape suivante :
- envoi (E400, E401) au système d’un certificat de la clé publique.
[Revendication 5] Procédé d’authentification mutuelle selon la revendication précédente comprenant en outre les étapes suivantes :
- réception (El 10) en provenance du système d’une clé publique éphémère,
- obtention (E120) d’un autre secret partagé et d’un chiffré correspondant, par application à la clé publique éphémère d’une fonction d’encapsulation d’un autre mécanisme d’encapsulation de clé,
- obtention (E130) d’une autre clé dérivée à partir de l’autre secret partagé,
- envoi (E140) au système du chiffré correspondant à l’autre secret partagé, et dans lequel :
- l’étape d’envoi au système d’un certificat de la clé publique, envoi au système un résultat d’un chiffrement avec l’autre clé dérivée, d’une donnée comprenant le certificat de la clé publique, et
- l’étape de réception en provenance du système d’un certificat de l’autre clé publique, comprend le déchiffrement avec l’autre clé dérivée d’une donnée émise par le système.
[Revendication 6] Procédé d’authentification mutuelle entre un dispositif électronique (10) et un système (20), le procédé étant mis en œuvre par le système, le dispositif électronique disposant d’une clé privée associée à une clé publique, le système disposant d’une autre clé privée associée à une autre clé publique, et le procédé comprenant : i) une phase (PI) d’authentification du système comprenant les étapes suivantes :
- réception (E320) en provenance du dispositif électronique d’un challenge d’authentification, puis
- calcul (E330) d’un premier résultat d’authentification en fonction du challenge d’authentification et de l’autre clé privée, puis
- envoi (E340) au dispositif électronique du premier résultat d’authentification, et ii) une phase (P2) d’authentification du dispositif électronique comprenant les étapes suivantes :
- détermination (E500) d’une donnée d’authentification, puis
- envoi (E510) au dispositif électronique de la donnée d’authentification, puis
- réception (E550) en provenance du dispositif électronique d’un deuxième résultat d’authentification, puis
- authentification (E560) du dispositif électronique avec le deuxième résultat d’authentification et la clé publique, le procédé étant caractérisé en ce que :
- le calcul du premier résultat d’authentification est par application à une donnée de référence comprenant le challenge d’authentification, d’une fonction de signature cryptographique avec l’autre clé privée,
- la donnée d’authentification et un secret partagé sont déterminés par application à la clé publique d’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé,
- l’étape d’authentification du dispositif électronique utilise le secret partagé et le deuxième résultat d’authentification.
[Revendication 7] Procédé d’authentification mutuelle selon la revendication précédente dans lequel chaque étape d’envoi et chaque étape de réception comprend une communication synchrone entre le dispositif électronique et le système.
[Revendication 8] Procédé d’authentification mutuelle selon l’une quelconque des revendications 6 ou 7 dans lequel la donnée de référence est la concaténation de la donnée d’authentification et du challenge d’ authentification.
[Revendication 9] Procédé d’authentification mutuelle selon l’une quelconque des revendications 6 à 8 dans lequel la phase (PI) d’authentification du système comprend en outre l’étape suivante :
- envoi (E200, E201) au dispositif électronique d’un certificat de l’autre clé publique, et la phase (P2) d’authentification du dispositif électronique comprend en outre les étapes suivantes :
- réception (E410, E411) en provenance du dispositif électronique d’un certificat de la clé publique, puis
- vérification (E420) de la validité du certificat reçu.
[Revendication 10] Procédé d’authentification mutuelle selon la revendication précédente comprenant en outre les étapes suivantes : - envoi (E100) au dispositif électronique d’une clé publique éphémère associée à une clé privée éphémère, puis
- réception (El 50) en provenance du dispositif électronique d’un chiffré correspondant à un autre secret partagé,
- obtention (E160) de l’autre secret partagé par application à la clé privée éphémère et au chiffré reçu, d’une fonction de désencapsulation d’un autre mécanisme d’encapsulation de clé,
- obtention (E170) d’une autre clé dérivée à partir de l’autre secret partagé, et dans lequel :
- l’étape de réception en provenance du dispositif électronique d’un certificat de la clé publique, comprend le déchiffrement avec l’autre clé dérivée d’une donnée émise par le dispositif électronique, et
- l’étape d’envoi au dispositif électronique d’un certificat de l’autre clé publique, envoi au dispositif électronique un résultat d’un chiffrement avec l’autre clé dérivée d’une donnée comprenant le certificat de l’autre clé publique.
[Revendication 11] Procédé d’authentification mutuelle selon la revendication précédente dans lequel l’étape d’envoi (E340) au dispositif électronique du premier résultat d’authentification, et l’étape (E510) d’envoi au dispositif électronique de la donnée d’authentification, comprennent un chiffrement avec l’autre clé dérivée des données à envoyer.
[Revendication 12] Programme d’ordinateur comprenant des instructions exécutables par un processeur et adaptées à mettre en œuvre un procédé selon l’une quelconque des revendications 1 à 5 lorsque ces instructions sont exécutées par le processeur.
[Revendication 13] Programme d’ordinateur comprenant des instructions exécutables par un processeur et adaptées à mettre en œuvre un procédé selon l’une quelconque des revendications 6 à 11 lorsque ces instructions sont exécutées par le processeur.
[Revendication 14] Dispositif électronique comprenant une mémoire stockant une clé privée associée à une clé publique, le dispositif électronique étant adapté pour coopérer avec un système disposant d’une autre clé privée associée à une autre clé publique, et le dispositif électronique comprenant en outre : i) un premier module, configuré pour réaliser une phase d’authentification du système qui comprend les étapes suivantes :
- détermination d’un challenge d’authentification, puis
- envoi au système du challenge d’authentification, puis
- réception en provenance du système d’un premier résultat d’authentification, puis
- authentification du système avec le challenge d’authentification, le premier résultat d’authentification et l’autre clé publique, et ii) un deuxième module, configuré pour réaliser une phase d’authentification du dispositif électronique qui comprend les étapes suivantes :
- réception en provenance du système d’une donnée d’authentification, puis
- calcul d’un deuxième résultat d’authentification en fonction de la donnée d’authentification et de la clé privée, puis
- envoi au système du deuxième résultat d’authentification, le dispositif électronique étant caractérisé en ce que :
- le premier module est configuré pour réaliser l’étape d’authentification du système par application au premier résultat d’authentification et à une donnée de référence comprenant le challenge d’authentification, d’une fonction de vérification de signature cryptographique avec l’autre clé publique,
- le deuxième module est configuré pour calculer le deuxième résultat d’authentification en utilisant un secret partagé obtenu par application à la clé privée et à la donnée d’authentification, d’une fonction de désencapsulation d’un mécanisme d’encapsulation de clé.
[Revendication 15] Système adapté pour coopérer avec un dispositif électronique disposant d’une clé privée associée à une clé publique, le système comprenant une mémoire stockant une autre clé privée associée à une autre clé publique, et le système comprenant en outre : i) un premier module, configuré pour réaliser une phase d’authentification du système qui comprend les étapes suivantes :
- réception en provenance du dispositif électronique d’un challenge d’authentification, puis
- calcul d’un premier résultat d’authentification en fonction du challenge d’authentification et de l’autre clé privée, puis
- envoi au dispositif électronique du premier résultat d’authentification, et ii) un deuxième module, configuré pour réaliser une phase d’authentification du dispositif électronique qui comprend les étapes suivantes :
- détermination d’une donnée d’authentification, puis
- envoi au dispositif électronique de la donnée d’authentification, puis
- réception en provenance du dispositif électronique d’un deuxième résultat d’authentification, puis - authentification du dispositif électronique avec le deuxième résultat d’authentification et la clé publique, le système étant caractérisé en ce que :
- le premier module est configuré pour calculer le premier résultat d’authentification par application à une donnée de référence comprenant le challenge d’authentification, d’une fonction de signature cryptographique avec l’autre clé privée,
- le deuxième module est configuré pour déterminer la donnée d’authentification et un secret partagé par application à la clé publique d’une fonction d’encapsulation d’un mécanisme d’encapsulation de clé, et pour réaliser l’étape d’authentification du dispositif électronique en utilisant le secret partagé et le deuxième résultat d’authentification.
EP23786010.1A 2022-12-07 2023-10-04 Procédés d'authentification mutuelle, dispositif électronique, système et programmes d'ordinateur associés Pending EP4631210A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2212881A FR3143148A1 (fr) 2022-12-07 2022-12-07 Procédés d’authentification mutuelle, dispositif électronique, système et programmes d’ordinateur associés.
PCT/EP2023/077378 WO2024120674A1 (fr) 2022-12-07 2023-10-04 Procédés d'authentification mutuelle, dispositif électronique, système et programmes d'ordinateur associés

Publications (1)

Publication Number Publication Date
EP4631210A1 true EP4631210A1 (fr) 2025-10-15

Family

ID=85726717

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23786010.1A Pending EP4631210A1 (fr) 2022-12-07 2023-10-04 Procédés d'authentification mutuelle, dispositif électronique, système et programmes d'ordinateur associés

Country Status (4)

Country Link
EP (1) EP4631210A1 (fr)
JP (1) JP2025539990A (fr)
FR (1) FR3143148A1 (fr)
WO (1) WO2024120674A1 (fr)

Also Published As

Publication number Publication date
JP2025539990A (ja) 2025-12-11
FR3143148A1 (fr) 2024-06-14
WO2024120674A1 (fr) 2024-06-13

Similar Documents

Publication Publication Date Title
US8082446B1 (en) System and method for non-repudiation within a public key infrastructure
CA2221016C (fr) Procede de recuperation de cles mis en oeuvre pour un chiffrement fort de message
US20160337124A1 (en) Secure backup and recovery system for private sensitive data
WO2020169542A1 (fr) Méthode cryptographique de vérification des données
EP1401142A1 (fr) Procede de signature electronique, programme et serveur pour la mise en oeuvre du procede
WO2010046565A2 (fr) Procédé de signature numérique en deux étapes
WO2008145558A2 (fr) Procede de securisation d'echange d'information, dispositif, et produit programme d'ordinateur correspondant
EP3965361B1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
EP3724799A1 (fr) Technique de protection d'une clé cryptographique au moyen d'un mot de passe utilisateur
EP1514377A1 (fr) Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne
WO2023057652A1 (fr) Application de sécurité pour un dispositif informatique, et architecture de sécurité correspondante
EP4631210A1 (fr) Procédés d'authentification mutuelle, dispositif électronique, système et programmes d'ordinateur associés
CN116781254A (zh) 数据加密方法、解密方法及装置
EP1642413B1 (fr) Procede de chiffrement/dechiffrement d un message et disposi tif associe
FR2875977A1 (fr) Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
WO2021074527A1 (fr) Procede de gestion d'une base de donnees de cles publiques, procede d'authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
EP0923829A2 (fr) Instrument de securisation d'echanges de donnees
CN116760554B (zh) 一种借助临时数字证书的数据携带方法
US20250274289A1 (en) Protocols for protecting digital files
TWI824239B (zh) 透過伺服器檢核密碼錯誤次數以完成作業之系統、裝置及方法
FR2786049A1 (fr) Procede de cryptographie a cle dynamique
EP4160987B1 (fr) Procédé pour générer une signature électronique au moyen du protocole fido
EP4589885A1 (fr) Protection de données
EP3021515B1 (fr) Amélioration de l'intégrité authentique de données à l'aide du dernier bloc chiffrant ces données en mode cbc
FR3148102A1 (fr) Une méthode sécurisée de sauvegarde et de restauration des données dans un appareil

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250425

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
P01 Opt-out of the competence of the unified patent court (upc) registered

Free format text: CASE NUMBER: UPC_APP_0005841_4631210/2026

Effective date: 20260217