FR 3020909 A1 20151113 FR 1454191 A 20140509 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 10 é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 15 é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 20 "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. 25 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é). 30 Pour éviter cela et permettre ainsi la mise en oeuvre 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 "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification y 2.2 Amendment D", version 1.1, septembre 2009. Comme indiqué dans ce document, afin d'utiliser une valeur "pseudo- alé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 oeuvre 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 oeuvre, 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 oeuvre 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 5 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é 10 é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é 15 é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 20 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 25 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 : 30 - 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 DETAILLEE D'UN EXEMPLE DE REALISATION 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 oeuvre 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 Element"), un eSE ("embedded secure element" 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 GlobalPlatform Card Specification 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 pseudoalé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 30 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 El 0, 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émente 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 "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification y 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 "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification y 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 "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification y 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 25 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 30 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 E114 et E116). 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 E110 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 10 mêmes données comme expliqué ci-dessous), le fonctionnement se poursuit à l'étape E114 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 15 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 E112), sans avoir incrémenté le compteur. On remarque que, selon le présent mode de réalisation, on ne réalise 20 pas l'étape de génération du mot pseudo-aléatoire PRM* par la carte à microcircuit C lorsque l'égalité de l'étape E110 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). 25 Lorsque la vérification de l'étape E110 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 E114 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. 30 Le nouveau mot pseudo-aléatoire PRM* ainsi déterminé est alors mémorisé temporairement en mémoire vive à l'étape E116. La carte à microcircuit C procède alors, lors d'une opération atomique E118 (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 E116). 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 E110 décrites ci-dessus). L'étape E118 est suivie de l'étape E120 à laquelle on génère (par 20 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 E118), 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 25 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 30 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 "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification y 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 oeuvre ci-dessus aux étapes E2, E8, E102 et E114. Selon ce premier exemple, on met en oeuvre 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 oeuvre ci-dessus aux étapes E2, E8, E102 et E114. Selon ce second exemple, on combine le mot pseudo-aléatoire PRM(i-1), PRm*(i-1) déterminé lors de la session précédente et la valeur SQC du compteur à 10 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 15 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 à 20 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 25 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(i), PRM*(i). On peut prévoir en pratique que le terminal H mémorise les valeurs 30 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. REVENDICATIONS1. 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 (SOC). 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 10 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 15 première entité électronique (H) à la seconde entité électronique (C) ; - incrémentation (E14 ; E118) 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é 20 é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). 25 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). 30 11. 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 11, comprenant, lors d'une sessionprécédente, une étape de détermination (E114) du second mot de vérification (PRM*) et une étape de mémorisation (E118) 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).