EP3140951A1 - Entité électronique et procédé de génération de clé de session - Google Patents

Entité électronique et procédé de génération de clé de session

Info

Publication number
EP3140951A1
EP3140951A1 EP15724344.5A EP15724344A EP3140951A1 EP 3140951 A1 EP3140951 A1 EP 3140951A1 EP 15724344 A EP15724344 A EP 15724344A EP 3140951 A1 EP3140951 A1 EP 3140951A1
Authority
EP
European Patent Office
Prior art keywords
electronic entity
prm
counter
verification word
sqc
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.)
Withdrawn
Application number
EP15724344.5A
Other languages
German (de)
English (en)
Inventor
Jean-Philippe Vallieres
Florian GALDO
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
Oberthur Technologies SA
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 Oberthur Technologies SA filed Critical Oberthur Technologies SA
Publication of EP3140951A1 publication Critical patent/EP3140951A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds

Definitions

  • the present invention relates to the exchange of data between electronic entities.
  • It relates more particularly to an electronic entity and a method of generating a session key.
  • the invention applies particularly advantageously in the case where a session key is generated by the electronic entities on the basis of a pseudo-random value, such as the value of a counter of one of the electronic entities.
  • session keys to secure the exchange of data between two electronic entities.
  • These session keys are for example derived from a cryptographic key known only from the two electronic entities. So that these keys are different for each exchange session between the two electronic entities, it is expected that they are further calculated on the basis of random values generated by the electronic entities.
  • random values can also be used, during a mutual authentication process, as a challenge (or "challenge” according to the Anglo-Saxon name) transmitted from one electronic entity to the other electronic entity so that the latter proves its knowledge of a shared secret (generally a cryptographic key, for example one of the session keys) by returning in response the result of a calculation combining the shared secret and the random value received.
  • a challenge or "challenge” according to the Anglo-Saxon name
  • a shared secret generally a cryptographic key, for example one of the session keys
  • slave it has been planned to use, in place of the value random generated by this electronic entity, a so-called “pseudo-random" value, based for example on the value of a counter of this electronic entity.
  • the other electronic entity (hereinafter referred to as the "master” or “host”), which is also aware of the value of the counter, can thus prepare in advance the data to be sent (typically in the form of commands to the user). slave electronic entity), by encrypting this data by means of the session key obtained in particular according to the value of the counter, and transmitting them in batches.
  • This technique is used for example for the personalization of secure electronic entities (such as microcircuit cards or secure integrated circuits) but can also be used in other contexts.
  • secure electronic entities such as microcircuit cards or secure integrated circuits
  • the counter of the slave electronic entity is incremented as soon as the opening of a new session is requested by the master electronic entity and when a mutual authentication procedure must be initiated (INITIALIZE UPDATE command).
  • the logon request is earlier than the mutual authentication procedure, it can not be guaranteed that it does not come from a malicious third party. In such a case, even if the attempt of the malicious third party is doomed to failure since it will not be able to authenticate itself, the request of logon leads to the incrementation of the counter (necessary to the implementation of the process mutual authentication), unexpected increment for the master electronic entity.
  • the present invention proposes an electronic entity designed to exchange data with another electronic entity, characterized in that it comprises means for receiving a first verification word from the other electronic entity, means for determining a second verification word, means for incrementing a counter of the electronic entity only in case of equality between the first verification word and the second verification word and means for generating a session key according to the value of the counter .
  • the counter is incremented only when the electronic entity has been able to verify the value of the verification word received from the other electronic entity, which makes it possible to ensure that the latter is the expected partner of the entity. and not a malicious third party.
  • the second verification word is determined as a function of a counter value of the electronic entity. This ensures that the other electronic entity is aware of this counter value and can successfully complete the next steps of the mutual authentication process.
  • the electronic entity comprises a rewritable non-volatile memory designed to store the second verification word.
  • the electronic entity may comprise means for comparing the first verification word and the second verification word stored in the rewritable non-volatile memory; the means for incrementing the counter are then for example designed to increment the counter in case of a positive comparison by the comparison means. Since the second verification word is read in the rewritable non-volatile memory (where it has for example been stored in a previous session as indicated below), it avoids the implementation of the determination of the second word of verification at the time of comparison with the first verification word received.
  • the means for generating the session key are designed to generate the session key according to the first word verification, as explained in the following description.
  • the means for generating the session key may be designed to generate the session key, during a session, before incrementing the counter by the means for incrementing the counter, as is the case for example for the channel protocol secure SCP02.
  • the means for generating the session key may be designed to generate the session key, during a session, after incrementing the counter by the means for incrementing the counter, as is the case for example for the secure channel protocol SCP03.
  • the invention also proposes a method for generating a session key for a secure exchange of data between a first electronic entity and a second electronic entity, characterized by the following steps:
  • the first verification word such as the second verification word
  • the first verification word can be determined according to a counter value of the electronic entity.
  • the method may in fact comprise, during a previous session, a step of determining the second verification word and a step of storing the second verification word determined in the rewritable non-volatile memory.
  • the method comprises for example the following steps:
  • FIG. 1 represents the main steps of a first example of data exchange between a first electronic entity and a second electronic entity in accordance with the teachings of the invention
  • FIG. 2 represents the main steps of a second example of data exchange between a first electronic entity and a second electronic entity in accordance with the teachings of the invention
  • FIG. 3 presents a first example of a method for determining a pseudo-random word
  • FIG. 4 presents a second example of a method for determining a pseudo-random word.
  • FIG. 1 represents a first example of data exchange between a first electronic entity and a second electronic entity in accordance with the teachings of the invention.
  • Each of the first and second electronic entities comprises a communication interface by means of which the relevant electronic entity can transmit and / or receive data on a communication medium, where the data is represented by signals, for example electrical signals or optics.
  • the first electronic entity and the second electronic entity can thus exchange data either directly (their respective communication interfaces being connected to one another) or via one or more other electronic entities (for example computers), possibly connected to each other and to the first and second electronic entities by means of a computer network.
  • Each of the first and second electronic entities is for example an electronic device which comprises, in addition to the communication interface mentioned above, a processor and at least one memory capable of storing the data received and manipulated by the electronic entity.
  • This memory also stores computer program instructions which, when executed, enable the electronic entity to implement the methods described below.
  • at least one of the electronic entities could be implemented in the form of a specific application integrated circuit (or ASIC according to the English acronym).
  • the first electronic entity is a terminal H and the second electronic entity is a microcircuit card C (or ICC for "Integrated Circuit Card”).
  • the first entity could be a remote server connected to the second electronic entity through a wireless connection, or a server directly connected to the second entity through a wired connection.
  • the second electronic entity may be a secure integrated circuit (or SE for "Secure Element"), an eSE ("embedded secure element” for embedded security element) or an eUICC ("embedded Universal Integrated Circuit Card” for universal and embedded IC card).
  • a secure element includes a processor of its own, different from the processor of the host electronic device in which it is embedded or embedded, and includes a non-volatile memory for storing computer programs executable by the processor.
  • the secure element is, for example, in accordance with ISO / IEC 7816 standards, Common Criteria standards and / or GlobalPIatform Card Specification v 2.2.1.
  • the terminal H During a step E2, the terminal H generates a host challenge HCH formed of a random word RAND (length M bytes), obtained by random draw within the terminal H, and a pseudo-random word PRM (length N bytes) determined in particular according to the current value of a counter managed by the microcircuit card C, as explained below.
  • the value of the counter is known by the terminal H thanks to the preceding exchanges or, in the case of a first exchange, to the value zero or has a value predetermined shared by both entities. It may optionally be provided in addition that the terminal H can issue a command (for example of the GET DATA type) in order to obtain in response (from the microcircuit card C) the current value of the counter.
  • the size of the 8-byte host challenge should not be considered as a limiting example.
  • the terminal H then transmits (step E4) to the card C an initialization command of the mutual authentication process, for example a command of the type INITALIZE UPDATE, accompanied by the host challenge HCH.
  • an initialization command of the mutual authentication process for example a command of the type INITALIZE UPDATE, accompanied by the host challenge HCH.
  • this command can be transmitted directly from the terminal H to the microcircuit card C (the communication interfaces being for example respectively a card reader equipping the terminal H and the contacts of the microcircuit card C), or by intermediary of one or more other electronic entities.
  • Card C receives the initialization command and the HCH host challenge at step E6.
  • the card C can thus extract the pseudo-random word received PRM.
  • the microcircuit card C During a step E8, the microcircuit card C generates on its side a pseudo-random word PRM * using the same process and the same data (in particular the current value of the counter managed by the microcircuit card C) that during the determination of the pseudo-random word carried out in step E2 by the terminal H.
  • the microcircuit card compares in step E10 the received pseudo-random word PRM and the calculated pseudo-random word PRM * -
  • step E14 In case of equality (which should be the case in normal operation since the two words are calculated with the same processes and from the same data), the operation continues in step E14 described below.
  • the emitter of the initialization command does not have a correct knowledge of the data used for the generation of the pseudo-random word PRM and will therefore probably not be able to authenticate correctly.
  • the mutual authentication process (step E12) is therefore terminated without having incremented the counter.
  • the microcircuit card C may optionally in this case return to the terminal H an error value or failure of the initialization of the mutual authentication process.
  • step E10 if the initialization command comes from a malicious third party, as is generally the case when a difference is detected in step E10, the counter will not be incremented and the two electronic entities (terminal H and card C) will remain synchronized.
  • step E10 When the verification of step E10 is positive (equality between the received pseudo-random word PRM and the calculated pseudo-random word PRM * ), the counter is incremented in step E14. A new counter value must be used to generate new session keys as explained below.
  • Step E14 is followed by step E16 at which a pseudo-random value CCH is generated (for example by means of a key derivation process) as a function, in particular, of the current value of the counter (value after incrementation of the step E14), as well as possibly other data (eg a cryptographic key stored in the microcircuit card).
  • the generation of the pseudo-random value CCH is for example carried out in accordance with the section "6.2.2.1 Card Challenge” in the document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Specification v 2.2 Amendment D" already mentioned. .
  • the pseudo-random value CCH is used as a challenge of the card to the terminal H (see below the transmission step E30).
  • each session key SK is generated, by means of a key derivation process, on the basis of a cryptographic key (called static key) K memorized in the microcircuit card C, of the host challenge HCH (received in step E6) and the pseudo-random value CCH (generated at step E16).
  • static key a cryptographic key
  • the generation of the session keys SK is performed in accordance with the "6.2.1 AES Session Keys" clause in the "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Specification v 2.2 Amendment D" document already mentioned.
  • the session keys are similarly generated by the terminal H. They are intended to be used as secret keys for symmetric encryption of the data to be exchanged during the session initiated by the mutual authentication process described here.
  • the microcircuit card C determines in step E20 the authentication cryptogram of the card CAC, by means of a key derivation process, on the basis of one of the session keys SK, of the challenge of host HCH (received in step E6) and the pseudo-random value CCH (generated in step E16).
  • the identification of the authentication cryptogram of the CAC card is, for example, carried out in accordance with the section "6.2.2.2 Card Authentication Cryptogram" in the "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Specification v 2.2 Amendment D" document. "already mentioned.
  • the microcircuit card C then emits in step E22 its response to the initialization command (see steps E4 and E6 above), which includes the pseudo-random value CCH determined in step E16 (challenge of the card), the CAC cryptogram determined in step E20 and the current value of the SQC counter.
  • the terminal H receives this response in step E24, which completes the initialization phase of the mutual authentication process; the mutual authentication process can then continue, for example by sending an EXTERNAL AUTHENTICATE command.
  • This authentication process includes the verification, by the terminal H, the CAC cryptogram received in step E22. To do this, the terminal H determines on its side the cryptogram of the card (by means of the same process and the same data as those used by the microcircuit card C in step E20) and compares the cryptogram thus determined to the cryptogram CAC received in step E22.
  • FIG. 2 represents a second example of data exchange between a first electronic entity and a second electronic entity according to to the teachings of the invention.
  • These electronic entities are for example of the same type as that envisaged above with reference to FIG.
  • the at least one second electronic entity here a microcircuit card C
  • the at least one second electronic entity is equipped with a random access memory and a non-volatile rewritable memory, in each of which the processor of the second electronic entity can read or write data.
  • the steps of FIG. 2 correspond to the launch phase of a mutual authentication process between the two electronic entities, at the initiative of the terminal H, which here acts as the master electronic entity or host.
  • the terminal H generates a host challenge HCH formed of a random word RAND, obtained by random draw within the terminal H, and a pseudo-random word PRM determined in particular according to the previous value (at the index i-1, that is to say immediately before the current value of index i) of a counter managed by the microcircuit card C, as explained below.
  • This step may possibly be carried out at the beginning of the previous session of exchanges between the terminal H and the microcircuit card C; indeed, at the beginning of the previous session (before incrementing the counter during the previous session, to the index i-1), the counter managed by the microcircuit card C presented this previous value, immediately prior to the value that present the counter at the beginning of the current session (at index i).
  • the terminal H transmits during a step E104 an initialization command of the mutual authentication process to the card C, for example a command of the type INITALIZE UPDATE, accompanied by the challenge of host HCH.
  • the microcircuit card C receives the initialization command and the HCH host challenge at the step E106 and can therefore extract the received pseudo-random word PRM-
  • step E106 is followed by the step E108, during which the processor of the microcircuit card C reads in the non-volatile memory of the microcircuit card C the pseudo-random word PRM * stored in this non-volatile memory. volatile during the previous session of exchanges between the terminal H and the microcircuit card C, as explained below for the current exchange session (see steps E1 14 and E1 16).
  • the counter value is zero or has a predetermined value.
  • the microcircuit card C (in practice its processor) then compares in step E1 10 the pseudo-random word PRM received in step E106 and the pseudo-random word PRM * read in the non-volatile memory in step E108.
  • step E1 14 described more low.
  • step E1 12 the mutual authentication process (step E1 12) is therefore terminated without having incremented the counter.
  • the step of generating the pseudo-random word PRM * by the microcircuit card C is not performed when the equality of the step E1 10 is not verified, this which avoids processing that could slow down the operation of the microcircuit card C (especially when the initialization request of the authentication process is performed by an attacker).
  • the microcircuit card C When the verification of the step E1 is positive (equality between the received pseudo-random word PRM and the pseudo-random word PRM * ), the microcircuit card C generates on its side in the step E1 14 a new word pseudo-random PRM * using the same process as the terminal H in step E102, but with the current value of the counter.
  • the new pseudo-random word PRM * thus determined is then temporarily stored in RAM in step E1 16.
  • the microcircuit card C then proceeds, during an atomic operation E1 18 (that is to say an operation which can only be totally realized or not performed as a whole, and which an attacker will not be able to force the partial realization), the incrementation of the counter and the writing of the new pseudo-random word PRM * in non-volatile memory (for example by copying it to from the RAM area where it was stored in step E1 16).
  • An atomic operation E1 18 that is to say an operation which can only be totally realized or not performed as a whole, and which an attacker will not be able to force the partial realization
  • the incrementation of the counter and the writing of the new pseudo-random word PRM * in non-volatile memory (for example by copying it to from the RAM area where it was stored in step E1 16).
  • the article "An overview of the Arjuna distributed programming system" by SKshrivastava, GN Dixon, & GD Parrington published in IEEE Software, 8 (1), pages 66-73 (1991) describes a method for rendering
  • the pseudo-random value PRM * stored in non-volatile memory can thus be used during the next initialization of a mutual authentication process (see steps E108 and E1 10 described above).
  • the step E1 18 is followed by the step E120 to which is generated (for example by means of a key derivation process) a pseudo-random value CCH as a function in particular of the current value of the counter (value after incrementing the step E1 18), as well as possibly other data (eg a cryptographic key stored in the microcircuit card). It is furthermore provided that the pseudo-random value CCH is used as a challenge of the card to the terminal H.
  • step E122 the microcircuit card generates different session keys SK.
  • each session key SK is generated, by means of a key derivation process, on the basis of a cryptographic key (called static key) K memorized in the microcircuit card C, of the host challenge HCH (received in step E106) and the pseudo-random value CCH (generated in step E120).
  • static key a cryptographic key (called static key) K memorized in the microcircuit card C, of the host challenge HCH (received in step E106) and the pseudo-random value CCH (generated in step E120).
  • the microcircuit card C determines in step E124 the authentication cryptogram of the card CAC, by means of a process of key derivation, based on one of the SK session keys, the HCH host challenge (received in step E106) and the pseudo-random value CCH (generated in step E120).
  • the generation of the pseudo-random value CCH, the generation of the session keys SK and the determination of the authentication cryptogram of the card CAC are for example carried out according to what is provided. in the document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Specification v 2.2 Amendment D" already mentioned.
  • the microcircuit card C then emits at step E126 its response to the initialization command (see steps E104 and E106 above), which includes the pseudo-random value CCH determined in step E120 (challenge of the card), the CAC cryptogram determined in step E124 and the current value of the SQC counter.
  • the terminal H receives this response in step E128, which completes the initialization phase of the mutual authentication process; the mutual authentication process can then continue, for example by sending an EXTERNAL AUTHENTICATE command.
  • FIG. 3 presents a first example that can be envisaged for a method for determining a pseudo-random word as implemented above in steps E2, E8, E102 and E14.
  • an authentication message calculation function is implemented by using as input the value of the counter SQC to be considered and a cryptographic key K, which makes it possible to obtain a piece of data (in instance an authentication code) MAC.
  • the authentication message calculation function is for example a hash function for calculating authentication code with key (in English "keyed-hash message authentication code function" or simply "HASH-MAC function"), such as that complies with FIPS 198-1.
  • it could be a symmetric cipher-based function, such as CBC-MAC or CMAC (as defined in NIST SP800-38B).
  • CBC-MAC symmetric cipher-based function
  • CMAC as defined in NIST SP800-38B
  • a hash function of the SHA-256 or SHA-3 type is used.
  • the cryptographic key K is a secret key stored in each of the two electronic entities (the terminal H and the microcircuit card C in the examples above) and which is therefore known only from these two electronic entities.
  • the pseudo-random word PRM, PRM * is then obtained by extracting N bytes from the MAC data, for example the leftmost N bytes (that is to say the N most significant bytes).
  • FIG. 4 presents a second example that can be envisaged for a method for determining a pseudo-random word as implemented above in steps E2, E8, E102 and E1 14.
  • the pseudo-random word PRM (Î-1), PRM * (Î-1) determined during the previous session and the SQC value of the counter to be considered, for example by concatenation, are combined.
  • the value of the counter SQC is null or has a predetermined value and the pseudo-random word of the preceding session is for example replaced by a specific initial value previously exchanged between the two electronic entities, for example a random value generated by the terminal H and transmitted securely to the microcircuit card C during its first initialization.
  • the value of the pseudo-random word is, for example, a function of the serial number of the microcircuit card C which is received by the terminal H when the microcircuit C is first powered up. Note that this value, as well as all the subsequent counter values must remain secret to prevent an attacker from successfully completing the mutual authentication step.
  • the combination is then applied with a one-way function, for example a hash function such as the SHA-256 function, in order to obtain a digest (or "digest" according to the English name). ). N bytes of the digest are then extracted (for example the N bytes of left) in order to obtain the pseudo-random word PRM (Î), PRM * ( ⁇ ) -
  • a one-way function for example a hash function such as the SHA-256 function
  • the terminal H stores the previous values of the pseudo-random word so that in case of loss of synchronization with the microcircuit card C, it may possibly reuse the previous values stored to calculate new pseudo-random words in a resynchronization phase.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé de génération d'une clé de session (SK) pour un échange sécurisé de données entre une première entité électronique (H) et une seconde entité électronique (C), caractérisé par les étapes suivantes : - détermination (E2) par la première entité électronique (H) d'un premier mot de vérification (PRM); - transmission (E4) du premier mot de vérification (PRM) de la première entité électronique (H) à la seconde entité électronique (C); - incrémentation (E14) d'un compteur (SQC) par la seconde entité électronique (C) seulement en cas d'égalité entre le premier mot de vérification (PRM) et un second mot de vérification (PRM*); - génération (E18) d'une clé de session (SK) par l'entité électronique (C) en fonction de la valeur du compteur (SQC). Une entité électronique (C) conçue pour échanger des données avec une autre entité électronique (H) est également proposée.

Description

Entité électronique et procédé de génération de clé de session
DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne les échanges de données entre entités électroniques.
Elle concerne plus particulièrement une entité électronique et un procédé de génération de clé de session.
L'invention s'applique particulièrement avantageusement dans le cas où une clé de de session est générée par les entités électroniques sur la base d'une valeur pseudo-aléatoire, telle que la valeur d'un compteur de l'une des entités électroniques.
ARRIERE-PLAN TECHNOLOGIQUE
Il est connu d'utiliser des clés de session pour sécuriser l'échange de données entre deux entités électroniques. Ces clés de session sont par exemple dérivées d'une clé cryptographique connue seulement des deux entités électroniques. Afin que ces clés soient différentes pour chaque session d'échanges entre les deux entités électroniques, on a prévu qu'elles soient de plus calculées sur la base de valeurs aléatoires générées par les entités électroniques.
On remarque que ces valeurs aléatoires peuvent également être utilisées, lors d'un processus d'authentification mutuelle, comme défi (ou "challenge" selon l'appellation anglo-saxonne) transmis d'une entité électronique à l'autre entité électronique afin que cette dernière prouve sa connaissance d'un secret partagé (en général une clé cryptographique, par exemple l'une des clés de session) en renvoyant en réponse le résultat d'un calcul combinant le secret partagé et la valeur aléatoire reçue.
Dans ce cas, l'utilisation de valeurs aléatoires générées respectivement dans chacune des deux entités électroniques rend nécessaire l'échange bidirectionnel de données pour mener à terme le processus d'authentification mutuelle et de génération des clés de session (puisque chaque entité doit recevoir la valeur aléatoire générée par l'autre entité).
Pour éviter cela et permettre ainsi la mise en œuvre de tels processus sans avoir à attendre un retour immédiat de l'une des entités électroniques (dite "esclave" dans la suite), il a été prévu d'utiliser, en lieu et place de la valeur aléatoire générée par cette entité électronique, une valeur dite "pseudo-aléatoire", basée par exemple sur la valeur d'un compteur de cette entité électronique.
L'autre entité électronique (dite "maître" ou "hôte" dans la suite), qui a également connaissance de la valeur du compteur, peut ainsi préparer à l'avance les données à envoyer (typiquement sous forme de commandes à destination de l'entité électronique esclave), en chiffrant ces données au moyen de la clé de session obtenue en fonction notamment de la valeur du compteur, et les transmettre par lots.
Cette technique est utilisée par exemple pour la personnalisation d'entités électroniques sécurisées (telles que des cartes à microcircuit ou des circuits intégrés sécurisés) mais peut également être utilisée dans d'autres contextes.
Des processus tels que présentés ci-dessus sont notamment décrits dans la spécification technique "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Spécification v 2.2 Amendment D", version 1 .1 , septembre 2009.
Comme indiqué dans ce document, afin d'utiliser une valeur "pseudoaléatoire" à chaque fois différente, on incrémente le compteur de l'entité électronique esclave dès que l'ouverture d'une nouvelle session est demandée par l'entité électronique maître et qu'une procédure d'authentification mutuelle doit être initiée (commande INITIALIZE UPDATE).
Du fait que la demande d'ouverture de session est antérieure à la procédure d'authentification mutuelle, on ne peut toutefois pas garantir qu'elle ne provient pas d'un tiers malintentionné. Dans un tel cas, même si la tentative du tiers malintentionné est vouée à l'échec puisqu'il ne pourra pas s'authentifier, la demande d'ouverture de session entraîne l'incrémentation du compteur (nécessaire à la mise en œuvre du processus d'authentification mutuelle), incrémentation imprévue pour l'entité électronique maître.
L'intrusion du tiers malintentionné provoque donc la désynchronisation des entités électroniques, ce qui rendra impossible de futurs échanges sécurisés entre elles puisqu'à chaque session, la valeur pseudo-aléatoire générée par l'entité électronique esclave sur la base de la valeur courante du compteur ne sera pas celle attendue par l'entité électronique maître (générée sur la base d'une valeur différente du compteur). OBJET DE L'INVENTION
Dans ce contexte, la présente invention propose une entité électronique conçue pour échanger des données avec une autre entité électronique, caractérisée en ce qu'elle comprend des moyens pour recevoir un premier mot de vérification de l'autre entité électronique, des moyens pour déterminer un second mot de vérification, des moyens pour incrémenter un compteur de l'entité électronique seulement en cas d'égalité entre le premier mot de vérification et le second mot de vérification et des moyens pour générer une clé de session en fonction de la valeur du compteur.
Ainsi, le compteur n'est incrémenté que lorsque l'entité électronique a pu vérifier la valeur du mot de vérification reçu de l'autre entité électronique, ce qui permet de s'assurer que cette dernière est bien le partenaire attendu de l'entité électronique et non un tiers malveillant.
En pratique, et notamment dans les modes de réalisation décrits plus loin, le second mot de vérification est déterminé en fonction d'une valeur du compteur de l'entité électronique. Ceci permet de s'assurer que l'autre entité électronique a effectivement connaissance de cette valeur du compteur et pourra conduire avec succès les étapes suivantes du processus d'authentification mutuelle.
Selon une possibilité de mise en œuvre, on peut prévoir que l'entité électronique comprenne une mémoire non-volatile réinscriptible conçue pour mémoriser le second mot de vérification.
Dans ce contexte, l'entité électronique peut comprendre des moyens de comparaison du premier mot de vérification et du second mot de vérification mémorisé dans la mémoire non-volatile réinscriptible ; les moyens pour incrémenter le compteur sont alors par exemple conçus pour incrémenter le compteur en cas de comparaison positive par les moyens de comparaison. Du fait que le second mot de vérification est lu dans la mémoire non-volatile réinscriptible (où il a par exemple été mémorisé lors d'une session précédente comme indiqué plus loin), on évite la mise en œuvre de la détermination du second mot de vérification au moment de sa comparaison avec le premier mot de vérification reçu.
On peut prévoir par ailleurs que les moyens pour générer la clé de session soient conçus pour générer la clé de session en fonction du premier mot de vérification, comme expliqué dans la description qui suit.
Les moyens pour générer la clé de session peuvent être conçus pour générer la clé de session, au cours d'une session, avant incrémentation du compteur par les moyens pour incrémenter le compteur, comme c'est le cas par exemple pour le protocole de canal sécurisé SCP02.
En variante, les moyens pour générer la clé de session peuvent être conçus pour générer la clé de session, au cours d'une session, après incrémentation du compteur par les moyens pour incrémenter le compteur, comme c'est le cas par exemple pour le protocole de canal sécurisé SCP03.
L'invention propose également un procédé de génération d'une clé de session pour un échange sécurisé de données entre une première entité électronique et une seconde entité électronique, caractérisé par les étapes suivantes :
- détermination par la première entité électronique d'un premier mot de vérification ;
- transmission du premier mot de vérification de la première entité électronique à la seconde entité électronique ;
- incrémentation d'un compteur par la seconde entité électronique seulement en cas d'égalité entre le premier mot de vérification et un second mot de vérification ;
- génération d'une clé de session par l'entité électronique en fonction de la valeur du compteur.
Comme déjà indiqué, le premier mot de vérification, comme le second mot de vérification, peuvent être déterminés en fonction d'une valeur du compteur de l'entité électronique.
On peut prévoir par ailleurs une étape de lecture, dans une mémoire non-volatile réinscriptible, du second mot de vérification. Le procédé peut en effet comprendre, lors d'une session précédente, une étape de détermination du second mot de vérification et une étape de mémorisation du second mot de vérification déterminé dans la mémoire non-volatile réinscriptible.
En pratique, le procédé comprend par exemple les étapes suivantes :
- génération par la première entité électronique d'une valeur aléatoire ;
- transmission de la valeur aléatoire de la première entité électronique à la seconde entité électronique ; - génération de la clé de session en fonction d'un défi de la première entité électronique, formé par la concaténation de la valeur aléatoire et du premier mot de vérification, et d'un défi de la seconde entité électronique déterminé en fonction de la valeur du compteur.
DESCRIPTION DÉTAILLÉE D'UN EXEMPLE DE RÉALISATION
La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
Sur les dessins annexés :
- la figure 1 représente les étapes principales d'un premier exemple d'échange de données entre une première entité électronique et une seconde entité électronique conformément aux enseignements de l'invention ;
- la figure 2 représente les étapes principales d'un second exemple d'échange de données entre une première entité électronique et une seconde entité électronique conformément aux enseignements de l'invention ;
- la figure 3 présente un premier exemple de procédé de détermination d'un mot pseudo-aléatoire ; et
- la figure 4 présente un second exemple de procédé de détermination d'un mot pseudo-aléatoire.
La figure 1 représente un premier exemple d'échange de données entre une première entité électronique et une seconde entité électronique conformément aux enseignements de l'invention.
Chacune des première et seconde entités électroniques comprend une interface de communication au moyen de laquelle l'entité électronique concernée peut émettre et/ou recevoir des données sur un médium de communication, où les données sont représentées par des signaux, par exemple des signaux électriques ou optiques.
La première entité électronique et la seconde entité électronique peuvent ainsi échanger des données soit directement (leurs interfaces de communication respectives étant connectées l'une à l'autre), soit par l'intermédiaire d'une ou plusieurs autres entités électroniques (par exemple des ordinateurs), éventuellement reliées entre elles et aux première et seconde entités électroniques au moyen d'un réseau informatique.
Chacune des première et seconde entités électroniques est par exemple un dispositif électronique qui comprend, outre l'interface de communication mentionnée ci-dessus, un processeur et au moins une mémoire apte à mémoriser les données reçues et manipulées par l'entité électronique. Cette mémoire mémorise également des instructions de programme d'ordinateur qui, lorsqu'elles sont exécutées, permettent la mise en œuvre par l'entité électronique des procédés décrits ci-dessous. En variante, l'une au moins des entités électroniques pourrait être réalisée sous forme d'un circuit intégré à application spécifique (ou ASIC selon l'acronyme anglo-saxon).
Dans l'exemple qui suit, la première entité électronique est un terminal H et la seconde entité électronique est une carte à microcircuit C (ou ICC pour "Integrated Circuit Card"). L'invention s'applique toutefois à d'autres types d'entités électroniques. En particulier, la première entité pourrait être un serveur distant connecté à la seconde entité électronique au travers d'une connexion sans fil, ou un serveur directement connecté à la seconde entité au travers d'une connexion filaire. A titre d'exemple, la seconde entité électronique peut être un circuit intégré sécurisé (ou SE pour "Secure Elément"), un eSE ("embedded secure élément" pour élément sécurisé embarqué) ou un eUICC ("embedded Universal Integrated Circuit Card" pour carte de circuit intégré universelle et embarquée). Un élément sécurisé comprend un processeur qui lui est propre, différent du processeur du dispositif électronique hôte dans lequel il est intégré ou embarqué, et comprend une mémoire non-volatile pour le stockage de programmes d'ordinateurs exécutables par le processeur. L'élément sécurisé est par exemple conforme aux standards ISO/IEC 7816, aux normes Critères Communs et/ou à la norme GlobalPIatform Card Spécification v 2.2.1 .
On décrit à présent la phase de lancement d'un processus d'authentification mutuelle entre les deux entités électroniques, à l'initiative du terminal H qui joue ici le rôle d'entité électronique maître ou hôte.
Lors d'une étape E2, le terminal H génère un défi d'hôte HCH formé d'un mot aléatoire RAND (de longueur M octets), obtenu par tirage aléatoire au sein du terminal H, et d'un mot pseudo-aléatoire PRM (de longueur N octets) déterminé notamment en fonction de la valeur courante d'un compteur géré par la carte à microcircuit C, comme expliqué ci-après. Comme cela ressortira de la description qui suit, la valeur du compteur est connue par le terminal H grâce aux échanges précédents ou, en cas de premier échange, a la valeur nulle ou a une valeur prédéterminée partagée par les deux entités. On peut éventuellement prévoir au surplus que le terminal H puisse émettre une commande (par exemple du type GET DATA) afin d'obtenir en réponse (en provenance de la carte à microcircuit C) la valeur courante du compteur.
On décrit plus loin en référence aux figures 3 et 4 des exemples de processus de détermination du mot pseudo-aléatoire PRM.
En pratique, le défi d'hôte est par exemple la concaténation du mot aléatoire RAND de longueur M octets (avec ici M = 3) et du mot pseudo-aléatoire PRM de longueur N octets (avec ici N = 5) ; on peut prévoir notamment que ces longueurs M, N soient telles que M+N = 8 de sorte que le défi d'hôte soit un mot de 8 octets. La taille du défit d'hôte de 8 octets ne doit toutefois pas être considérée comme un exemple limitatif. Alternativement, aucun mot aléatoire RAND n'est utilisé, et dans ce cas, M=0 et N = 8.
Le terminal H émet alors (étape E4) à destination de la carte C une commande d'initialisation du processus d'authentification mutuelle, par exemple une commande du type INITALIZE UPDATE, accompagnée du défi d'hôte HCH.
Comme déjà indiqué, cette commande peut être transmise directement du terminal H à la carte à microcircuit C (les interfaces de communication étant par exemple respectivement un lecteur de carte équipant le terminal H et les contacts de la carte à microcircuit C), ou par l'intermédiaire d'une ou plusieurs autres entités électroniques.
La carte C reçoit la commande d'initialisation et le défi d'hôte HCH à l'étape E6. La carte C peut donc en extraire le mot pseudo-aléatoire reçu PRM.
Lors d'une étape E8, la carte à microcircuit C génère de son côté un mot pseudo-aléatoire PRM* en utilisant le même processus et les mêmes données (notamment la valeur courante du compteur géré par la carte à microcircuit C) que lors de la détermination du mot pseudo-aléatoire effectuée à l'étape E2 par le terminal H.
La carte à microcircuit compare alors à l'étape E10 le mot pseudo- aléatoire reçu PRM et le mot pseudo-aléatoire calculé PRM*-
En cas d'égalité (ce qui devrait être le cas en fonctionnement normal puisque les deux mots sont calculés avec les mêmes processus et à partir des mêmes données), le fonctionnement se poursuit à l'étape E14 décrite plus bas.
En cas de différence entre le mot pseudo-aléatoire reçu PRM et le mot pseudo-aléatoire calculé PRM*, l'émetteur de la commande d'initialisation (possiblement un tiers malintentionné) n'a pas une connaissance correcte des données utilisées pour la génération du mot pseudo-aléatoire PRM et ne sera donc vraisemblablement pas en mesure de s'authentifier correctement. On met donc dans ce cas fin au processus d'authentification mutuelle (étape E12), sans avoir incrémenté le compteur. La carte à microcircuit C peut éventuellement dans ce cas retourner au terminal H une valeur d'erreur ou d'échec de l'initialisation du processus d'authentification mutuelle.
Ainsi, si la commande d'initialisation vient d'un tiers malintentionné, comme c'est généralement le cas lorsqu'une différence est détectée à l'étape E10, le compteur ne sera pas incrémenté et les deux entités électroniques (terminal H et carte C) resteront donc synchronisées.
Lorsque la vérification de l'étape E10 est positive (égalité entre le mot pseudo-aléatoire reçu PRM et le mot pseudo-aléatoire calculé PRM*), on incrémenté le compteur à l'étape E14. Une nouvelle valeur de compteur doit en effet être utilisée pour générer de nouvelles clés de session comme expliqué ci- dessous.
L'étape E14 est suivie de l'étape E16 à laquelle on génère (par exemple au moyen d'un processus de dérivation de clé) une valeur pseudo-aléatoire CCH en fonction notamment de la valeur courante du compteur (valeur après incrémentation de l'étape E14), ainsi qu'éventuellement d'autres données (e.g. une clé cryptographique mémorisée dans la carte à microcircuit). La génération de la valeur pseudo-aléatoire CCH est par exemple réalisée conformément à ce qui est prévu au paragraphe "6.2.2.1 Card Challenge" dans le document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Spécification v 2.2 Amendment D" déjà mentionné.
On prévoit ici par ailleurs que la valeur pseudo-aléatoire CCH soit utilisée comme défi de la carte à destination du terminal H (voir ci-dessous l'étape d'émission E30).
On procède alors à l'étape E18 à laquelle la carte à microcircuit génère différentes clés de session SK. Chaque clé de session SK est par exemple générée, au moyen d'un processus de dérivation de clé, sur la base d'une clé cryptographique (dite statique) K mémorisée dans la carte à microcircuit C, du défi d'hôte HCH (reçu à l'étape E6) et de la valeur pseudo-aléatoire CCH (générée à l'étape E16). La génération des clés de session SK est par exemple réalisée conformément à ce qui est prévu au paragraphe "6.2.1 AES Session Keys" dans le document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Spécification v 2.2 Amendment D" déjà mentionné. Les clefs de session sont générées de manière similaire par le terminal H. Elles sont destinées à être utilisées comme clés secrètes pour un chiffrement symétrique des données à échanger lors de la session initiée par le processus d'authentification mutuelle décrit ici.
La carte à microcircuit C détermine ensuite à l'étape E20 le cryptogramme d'authentification de la carte CAC, au moyen d'un processus de dérivation de clé, sur la base de l'une des clés de session SK, du défi d'hôte HCH (reçu à l'étape E6) et de la valeur pseudo-aléatoire CCH (générée à l'étape E16). La détermination du cryptogramme d'authentification de la carte CAC est par exemple réalisée conformément à ce qui est prévu au paragraphe "6.2.2.2 Card Authentication Cryptogram" dans le document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Spécification v 2.2 Amendment D" déjà mentionné.
La carte à microcircuit C émet alors à l'étape E22 sa réponse à la commande d'initialisation (voir ci-dessus les étapes E4 et E6), réponse qui inclut la valeur pseudo-aléatoire CCH déterminée à l'étape E16 (défi de la carte), le cryptogramme CAC déterminé à l'étape E20 et la valeur courante du compteur SQC.
Le terminal H reçoit cette réponse à l'étape E24, ce qui achève la phase d'initialisation du processus d'authentification mutuelle ; le processus d'authentification mutuelle peut alors se poursuivre, par exemple par l'envoi d'une commande EXTERNAL AUTHENTICATE.
Ce processus d'authentification comprend notamment la vérification, par le terminal H, du cryptogramme CAC reçu à l'étape E22. Pour ce faire, le terminal H détermine de son côté le cryptogramme de la carte (au moyen du même processus et des mêmes données que ceux utilisés par la carte à microcircuit C à l'étape E20) et compare le cryptogramme ainsi déterminé au cryptogramme CAC reçu à l'étape E22.
La figure 2 représente un second exemple d'échange de données entre une première entité électronique et une seconde entité électronique conformément aux enseignements de l'invention. Ces entités électroniques sont par exemple du même type que ce qui a été envisagé ci-dessus en référence à la figure 1 . Dans ce mode de réalisation, la seconde entité électronique au moins (ici une carte à microcircuit C) est équipée d'une mémoire vive et d'une mémoire non-volatile réinscriptible, dans chacune desquelles le processeur de la seconde entité électronique peut lire ou écrire des données.
Comme pour la figure 1 , les étapes de la figure 2 correspondent à la phase de lancement d'un processus d'authentification mutuelle entre les deux entités électroniques, à l'initiative du terminal H qui joue ici le rôle d'entité électronique maître ou hôte.
Lors d'une étape E102, le terminal H génère un défi d'hôte HCH formé d'un mot aléatoire RAND, obtenu par tirage aléatoire au sein du terminal H, et d'un mot pseudo-aléatoire PRM déterminé notamment en fonction de la valeur précédente (à l'indice i-1 , c'est-à-dire immédiatement antérieure à la valeur courante d'indice i) d'un compteur géré par la carte à microcircuit C, comme expliqué ci-après. Cette étape peut éventuellement être réalisée au début de la précédente session d'échanges entre le terminal H et la carte à microcircuit C ; en effet, au début de la session précédente (avant incrémentation du compteur au cours de la session précédente, à l'indice i-1 ), le compteur géré par la carte à microcircuit C présentait cette valeur précédente, immédiatement antérieure à la valeur que présente le compteur au début de la session courante (à l'indice i).
Comme déjà indiqué, des exemples de processus de détermination du mot pseudo-aléatoire PRM sur la base d'une valeur du compteur sont décrits plus loin en référence aux figures 3 et 4.
Pour initier le processus d'authentification mutuelle, le terminal H émet lors d'une étape E104 une commande d'initialisation du processus d'authentification mutuelle à destination de la carte C, par exemple une commande du type INITALIZE UPDATE, accompagnée du défi d'hôte HCH.
La carte à microcircuit C reçoit la commande d'initialisation et le défi d'hôte HCH à l'étape E106 et peut donc en extraire le mot pseudo-aléatoire reçu PRM-
L'étape E106 est suivie de l'étape E108, au cours de laquelle le processeur de la carte à microcircuit C lit dans la mémoire non-volatile de la carte à microcircuit C le mot pseudo-aléatoire PRM* mémorisé dans cette mémoire non- volatile au cours de la précédente session d'échanges entre le terminal H et la carte à microcircuit C, comme expliqué ci-dessous pour la session d'échanges courante (voir les étapes E1 14 et E1 16).
Lorsqu'il s'agit de la première session, la valeur du compteur est nulle ou a une valeur prédéterminée.
La carte à microcircuit C (en pratique son processeur) compare alors à l'étape E1 10 le mot pseudo-aléatoire PRM reçu à l'étape E106 et le mot pseudoaléatoire PRM* lu dans la mémoire non-volatile à l'étape E108.
En cas d'égalité (ce qui devrait être le cas en fonctionnement normal puisque les deux mots sont calculés avec les mêmes processus et à partir des mêmes données comme expliqué ci-dessous), le fonctionnement se poursuit à l'étape E1 14 décrite plus bas.
En cas de différence entre le mot pseudo-aléatoire reçu PRM et le mot pseudo-aléatoire lu PRM*, l'émetteur de la commande d'initialisation (possiblement un tiers malintentionné) n'a pas une connaissance correcte des données utilisées pour la génération du mot pseudo-aléatoire PRM et ne sera donc vraisemblablement pas en mesure de s'authentifier correctement. On met donc dans ce cas fin au processus d'authentification mutuelle (étape E1 12), sans avoir incrémenté le compteur.
On remarque que, selon le présent mode de réalisation, on ne réalise pas l'étape de génération du mot pseudo-aléatoire PRM* par la carte à microcircuit C lorsque l'égalité de l'étape E1 10 n'est pas vérifiée, ce qui permet d'éviter des traitements qui pourraient ralentir le fonctionnement de la carte à microcircuit C (en particulier lorsque la demande d'initialisation du processus d'authentification est effectuée par un attaquant).
Lorsque la vérification de l'étape E1 10 est positive (égalité entre le mot pseudo-aléatoire reçu PRM et le mot pseudo-aléatoire lu PRM*), la carte à microcircuit C génère de son côté à l'étape E1 14 un nouveau mot pseudoaléatoire PRM* en utilisant le même processus que le terminal H à l'étape E102, mais avec la valeur courante du compteur.
Le nouveau mot pseudo-aléatoire PRM* ainsi déterminé est alors mémorisé temporairement en mémoire vive à l'étape E1 16.
La carte à microcircuit C procède alors, lors d'une opération atomique E1 18 (c'est-à-dire une opération qui ne peut être que totalement réalisée ou non- réalisée dans son ensemble, et dont un attaquant ne pourra donc pas forcer la réalisation partielle), à l'incrémentation du compteur et à l'écriture du nouveau mot pseudo-aléatoire PRM* en mémoire non-volatile (par exemple en le recopiant à partir de la zone de mémoire vive où il a été mémorisé à l'étape E1 16). L'article "An overview of the Arjuna distributed programming System" par S. K. Shrivastava, G.N. Dixon, & G.D. Parrington publié dans le journal IEEE Software, 8(1 ), pages 66 à 73 (1991 ) décrit une méthode visant à rendre un ensemble d'opérations atomiques. Une méthode consiste à vérifier que le contenu de deux cellules mémoires est modifié en parallèle ou pas. Une implémentation possible de cette méthode consiste à copier le contenu des deux cellules mémoires M vers M*, à modifier le contenu de ces deux cellules mémoires M*, puis, lorsque le contenu est modifié, à modifier la position du pointeur de M vers M*.
On évite ainsi tout décalage entre la valeur du compteur à un instant donné et la valeur du mot pseudo-aléatoire normalement mémorisée en mémoire non-volatile à ce même instant (cette valeur mémorisée étant toutefois déterminée comme déjà indiqué sur la base de la valeur antérieure du compteur).
La valeur pseudo-aléatoire PRM* mémorisée en mémoire non-volatile pourra ainsi être utilisée lors de la prochaine initialisation d'un processus d'authentification mutuelle (voir les étapes E108 et E1 10 décrites ci-dessus).
L'étape E1 18 est suivie de l'étape E120 à laquelle on génère (par exemple au moyen d'un processus de dérivation de clé) une valeur pseudoaléatoire CCH en fonction notamment de la valeur courante du compteur (valeur après incrémentation de l'étape E1 18), ainsi qu'éventuellement d'autres données (e.g. une clé cryptographique mémorisée dans la carte à microcircuit). On prévoit ici par ailleurs que la valeur pseudo-aléatoire CCH soit utilisée comme défi de la carte à destination du terminal H.
On procède alors à l'étape E122 à laquelle la carte à microcircuit génère différentes clés de session SK. Chaque clé de session SK est par exemple générée, au moyen d'un processus de dérivation de clé, sur la base d'une clé cryptographique (dite statique) K mémorisée dans la carte à microcircuit C, du défi d'hôte HCH (reçu à l'étape E106) et de la valeur pseudo-aléatoire CCH (générée à l'étape E120).
La carte à microcircuit C détermine ensuite à l'étape E124 le cryptogramme d'authentification de la carte CAC, au moyen d'un processus de dérivation de clé, sur la base de l'une des clés de session SK, du défi d'hôte HCH (reçu à l'étape E106) et de la valeur pseudo-aléatoire CCH (générée à l'étape E120).
Comme indiqué dans la description relative à la figure 1 , la génération de la valeur pseudo-aléatoire CCH, la génération des clés de session SK et la détermination du cryptogramme d'authentification de la carte CAC sont par exemple réalisées conformément à ce qui est prévu dans le document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Spécification v 2.2 Amendment D" déjà mentionné.
La carte à microcircuit C émet alors à l'étape E126 sa réponse à la commande d'initialisation (voir ci-dessus les étapes E104 et E106), réponse qui inclut la valeur pseudo-aléatoire CCH déterminée à l'étape E120 (défi de la carte), le cryptogramme CAC déterminé à l'étape E124 et la valeur courante du compteur SQC.
Le terminal H reçoit cette réponse à l'étape E128, ce qui achève la phase d'initialisation du processus d'authentification mutuelle ; le processus d'authentification mutuelle peut alors se poursuivre, par exemple par l'envoi d'une commande EXTERNAL AUTHENTICATE.
La figure 3 présente un premier exemple envisageable pour un procédé de détermination d'un mot pseudo-aléatoire tel que mis en œuvre ci-dessus aux étapes E2, E8, E102 et E1 14.
Selon ce premier exemple, on met en œuvre une fonction de calcul de message d'authentification (MAC) en utilisant en entrée la valeur du compteur SQC à considérer et une clé cryptographique K, ce qui permet d'obtenir une donnée (en l'occurrence un code d'authentification) MAC. La fonction de calcul de message d'authentification est par exemple une fonction de hachage de calcul de code d'authentification avec clé (en anglais "keyed-hash message authentication code function" ou plus simplement "HASH-MAC function"), telle que celle conforme à la norme FIPS 198-1 . En variante, il pourrait s'agir d'une fonction à base de chiffrement symétrique, comme les fonctions CBC-MAC ou CMAC (telle que définie dans la norme NIST SP800-38B). On utilise par exemple une fonction de hachage de type SHA-256 ou SHA-3.
La clé cryptographique K est une clé secrète mémorisée dans chacune des deux entités électroniques (le terminal H et la carte à microcircuit C dans les exemples ci-dessus) et qui n'est donc connue que de ces deux entités électroniques.
Le mot pseudo-aléatoire PRM, PRM* est alors obtenu en extrayant N octets de la donnée MAC, par exemple les N octets les plus à gauche (c'est-à-dire les N octets de poids fort).
La figure 4 présente un second exemple envisageable pour un procédé de détermination d'un mot pseudo-aléatoire tel que mis en œuvre ci-dessus aux étapes E2, E8, E102 et E1 14.
Selon ce second exemple, on combine le mot pseudo-aléatoire PRM(Î-1 ), PRM*(Î-1 ) déterminé lors de la session précédente et la valeur SQC du compteur à considérer, par exemple par concaténation. On complète éventuellement avec des zéros (par exemple à droite) afin d'arriver à un mot de 32 octets.
Lorsqu'il s'agit de la première session, la valeur du compteur SQC est nulle ou a une valeur prédéterminée et le mot pseudo-aléatoire de la session précédente est par exemple remplacé par une valeur initiale spécifique préalablement échangée entre les deux entités électroniques, par exemple une valeur aléatoire générée par le terminal H et transmise de manière sécurisée à la carte à microcircuit C lors de sa première initialisation. La valeur du mot pseudoaléatoire est par exemple fonction du numéro de série de la carte à microcircuit C qui est reçu par le terminal H lors de la première mise sous tension de la carte à microcircuit C. On remarque que cette valeur, ainsi que toutes les valeurs ultérieures du compteur, doivent rester secrètes afin d'éviter qu'un attaquant ne puisse réussir l'étape d'authentification mutuelle.
Dans tous les cas, on applique ensuite à la combinaison réalisée une fonction à sens unique, par exemple une fonction de hachage telle que la fonction SHA-256, afin d'obtenir un condensé (ou "digest" selon l'appellation anglo- saxonne). On extrait alors N octets du condensé (par exemple les N octets de gauche) afin d'obtenir le mot pseudo-aléatoire PRM(Î), PRM*(Ï)-
On peut prévoir en pratique que le terminal H mémorise les valeurs précédentes du mot pseudo-aléatoire afin qu'en cas de perte de synchronisation avec la carte à microcircuit C, il puisse éventuellement réutiliser les valeurs précédentes mémorisées pour calculer de nouveaux mots pseudo-aléatoires dans une phase de resynchronisation.

Claims

REVENDICATIONS
1 . Entité électronique (C) conçue pour échanger des données avec une autre entité électronique (H), caractérisée en ce qu'elle comprend :
- des moyens pour recevoir un premier mot de vérification (PRM) de l'autre entité électronique ;
- des moyens pour déterminer un second mot de vérification (PRM*) ;
- des moyens pour incrémenter un compteur (SQC) de l'entité électronique (C) seulement en cas d'égalité entre le premier mot de vérification (PRM) et le second mot de vérification (PRM*) ;
- des moyens pour générer une clé de session (SK) en fonction de la valeur du compteur (SQC).
2. Entité électronique selon la revendication 1 , dans laquelle le second mot de vérification (PRM*) est déterminé en fonction d'une valeur du compteur (SQC) de l'entité électronique (C).
3. Entité électronique selon la revendication 1 ou 2, comprenant une mémoire non-volatile réinscriptible conçue pour mémoriser le second mot de vérification (PRM*)-
4. Entité électronique selon la revendication 3, comprenant des moyens de comparaison du premier mot de vérification (PRM) et du second mot de vérification (PRM) mémorisé dans la mémoire non-volatile réinscriptible, dans laquelle les moyens pour incrémenter le compteur (SQC) sont conçus pour incrémenter le compteur (SQC) en cas de comparaison positive par les moyens de comparaison.
5. Entité électronique selon l'une des revendications 1 à 4, dans laquelle les moyens pour générer la clé de session (SK) sont conçus pour générer la clé de session (SK) en fonction du premier mot de vérification (PRM)-
6. Entité électronique selon l'une des revendications 1 à 5, dans laquelle les moyens pour générer la clé de session (SK) sont conçus pour générer la clé de session (SK), au cours d'une session, avant incrémentation du compteur (SQC) par les moyens pour incrémenter le compteur (SQC).
7. Entité électronique selon l'une des revendications 1 à 5, dans laquelle les moyens pour générer la clé de session (SK) sont conçus pour générer la clé de session (SK), au cours d'une session, après incrémentation du compteur (SQC) par les moyens pour incrémenter le compteur (SQC).
8. Procédé de génération d'une clé de session (SK) pour un échange sécurisé de données entre une première entité électronique (H) et une seconde entité électronique (C), caractérisé par les étapes suivantes :
- détermination (E2 ; E102) par la première entité électronique (H) d'un premier mot de vérification (PRM) ;
- transmission (E4 ; E104) du premier mot de vérification (PRM) de la première entité électronique (H) à la seconde entité électronique (C) ;
- incrémentation (E14 ; E1 18) d'un compteur (SQC) par la seconde entité électronique (C) seulement en cas d'égalité entre le premier mot de vérification (PRM) et un second mot de vérification (PRM*) ;
- génération (E18 ; E122) d'une clé de session (SK) par l'entité électronique (C) en fonction de la valeur du compteur (SQC).
9. Procédé selon la revendication 8, dans lequel le premier mot de vérification (PRM) est déterminé en fonction d'une valeur du compteur (SQC) de l'entité électronique (C).
10. Procédé selon la revendication 9, dans lequel le second mot de vérification (PRM*) est déterminé en fonction de ladite valeur du compteur (SQC) de l'entité électronique (C).
1 1 . Procédé selon l'une des revendications 8 à 10, comprenant une étape de lecture (E108), dans une mémoire non-volatile réinscriptible, du second mot de vérification (PRM*)-
12. Procédé selon la revendication 1 1 , comprenant, lors d'une session précédente, une étape de détermination (E1 14) du second mot de vérification (PRM*) et une étape de mémorisation (E1 18) du second mot de vérification (PRM*) déterminé dans la mémoire non-volatile réinscriptible.
13. Procédé selon l'une des revendications 8 à 12, dans lequel la clé de session (SK) est générée en fonction du premier mot de vérification (PRM)-
14. Procédé selon l'une des revendications 8 à 13, comprenant les étapes suivantes :
- génération (E2 ; E102) par la première entité électronique (H) d'une valeur aléatoire (RAND) ;
- transmission (E4 ; E104) de la valeur aléatoire (RAND) de la première entité électronique (H) à la seconde entité électronique (C) ;
- génération (E18 ; E122) de la clé de session (SK) en fonction d'un défi (HCH) de la première entité électronique (H), formé par la concaténation de la valeur aléatoire (RAND) et du premier mot de vérification (PRM), et d'un défi (CCH) de la seconde entité électronique (C) déterminé en fonction de la valeur du compteur (SQC).
EP15724344.5A 2014-05-09 2015-05-06 Entité électronique et procédé de génération de clé de session Withdrawn EP3140951A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1454191A FR3020909B1 (fr) 2014-05-09 2014-05-09 Entite electronique et procede de generation de cle de session
PCT/FR2015/051207 WO2015170057A1 (fr) 2014-05-09 2015-05-06 Entité électronique et procédé de génération de clé de session

Publications (1)

Publication Number Publication Date
EP3140951A1 true EP3140951A1 (fr) 2017-03-15

Family

ID=51830388

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15724344.5A Withdrawn EP3140951A1 (fr) 2014-05-09 2015-05-06 Entité électronique et procédé de génération de clé de session

Country Status (3)

Country Link
EP (1) EP3140951A1 (fr)
FR (1) FR3020909B1 (fr)
WO (1) WO2015170057A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080034216A1 (en) * 2006-08-03 2008-02-07 Eric Chun Wah Law Mutual authentication and secure channel establishment between two parties using consecutive one-time passwords

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2015170057A1 *

Also Published As

Publication number Publication date
FR3020909A1 (fr) 2015-11-13
FR3020909B1 (fr) 2017-10-13
WO2015170057A1 (fr) 2015-11-12

Similar Documents

Publication Publication Date Title
EP3152860B1 (fr) Procédé d'authentification d'une première entité électronique par une seconde entité électronique et entité électronique mettant en oeuvre un tel procédé
EP1529369B1 (fr) Proc d d' change s curis d'informations entre deux dispositifs
EP3010175B1 (fr) Rejeu d'un batch de commandes sécurisees dans un canal sécurisé
WO2016102833A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
EP3308564B1 (fr) Procédé de chargement d'une clé virtuelle et terminal utilisateur associé
FR3067829B1 (fr) Procede d'authentification par defi-reponse d'un element securise (se) aupres d'un microcontroleur
WO2019145620A1 (fr) Système sécurisé de transactions entre terminaux
EP3732849B1 (fr) Procédé et système d'identification de terminal d'utilisateur pour la réception de contenus multimédia protégés et fournis en continu
FR3046000A1 (fr) Procede de reception de donnees au sein d'une entite electronique et entite electronique associee
EP3136283B1 (fr) Dispositif et procédé sécurisation de commandes échangées entre un terminal et circuit intégré
EP2919412B1 (fr) Procédé et système de chiffrement/déchiffrement de données à clé distante et vérification préalable de jeton
WO2016102834A1 (fr) Procédé d'authentification d'un utilisateur et d'un module sécurisé, appareil électronique et système associes
EP3140951A1 (fr) Entité électronique et procédé de génération de clé de session
FR3116133A1 (fr) Procédé de délégation d’accès à une chaîne de blocs
FR3025631A1 (fr) Selection securisee d'une application dans une carte a puce ou equivalent
FR3022716A1 (fr) Procede de partage de fichiers numeriques entre plusieurs ordinateurs, et ordinateur, ensemble de stockage de donnees et systeme de partage de fichiers numeriques associes
WO2016102832A1 (fr) Procédé d'authentification d'une application, appareil électronique et programme d'ordinateur associés
FR3032846A1 (fr) Procede de communication securisee entre un systeme d'exploitation d'un terminal et un dispositif distinct du terminal
FR3086417A1 (fr) Procede cryptographique de comparaison securisee de deux donnees secretes x et y
EP3021515B1 (fr) Amélioration de l'intégrité authentique de données à l'aide du dernier bloc chiffrant ces données en mode cbc
WO2025083096A1 (fr) Protocole niable a apport de connaissance nulle
FR3154209A1 (fr) Procédé de mise en œuvre d’une transaction entre un premier équipement de preuve et un deuxième équipement de vérification.
WO2025109113A1 (fr) Procédés, dispositifs et système de transmission et d'acquisition d'une donnée
EP4652758A1 (fr) Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
WO2016034812A1 (fr) Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé

Legal Events

Date Code Title Description
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: 20161208

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 MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: IDEMIA FRANCE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: IDEMIA FRANCE

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20191125

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20220110

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20220216