DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne l'établissement d'un canal sécurisé entre deux entités électroniques.

Elle concerne plus particulièrement un procédé d'authentification d'une première entité électronique par une seconde entité électronique, ainsi qu'une entité électronique mettant en œuvre un tel procédé.

L'invention s'applique particulièrement avantageusement dans le cas où une clé cryptographique utilisée par la première entité électronique pour générer un défi destiné à la seconde entité électronique est également utilisée pour générer une clé de session destinée à chiffrer des échanges de données entre la première entité électronique et la seconde entité électronique.

ARRIERE-PLAN TECHNOLOGIQUE

Lorsqu'une première entité électronique souhaite s'authentifier auprès d'une seconde entité électrique en prouvant sa connaissance d'un secret (en général une clé cryptographique) sans transmettre ce secret, on peut procéder à un échange de type défi-réponse (ou "challenge-response" selon l'appellation anglo-saxonne) entre les deux entités électroniques : la seconde entité électronique envoie un défi à la première entité électronique, qui doit pour s'authentifier renvoyer en retour une réponse attendue associée au défi, typiquement le résultat d'un calcul combinant le secret et le défi reçu.

Afin de réaliser une authentification mutuelle, la première entité électronique envoie elle aussi un défi à la seconde entité électronique, qui doit déterminer la réponse attendue à cet autre défi et l'émettre à destination de la première entité électronique.

Les défis utilisés sont en général des nombres aléatoires générés par l'entité électronique émettrice du défi afin d'éviter qu'un tiers malintentionné puisse s'authentifier par simple répétition (parfois dénommée "rejeu") d'une réponse émise antérieurement par la première entité électronique.

Ces valeurs aléatoires peuvent en outre être utilisées, en combinaison avec une clé cryptographique connue seulement des deux entités électroniques, pour générer des clés de session visant à sécuriser l'échange de données entre les deux entités électroniques. Les clés de session ainsi générées sont ainsi différentes pour chaque session d'échanges entre les deux entités électroniques.

L'utilisation de valeurs aléatoires générées respectivement dans chacune des deux entités électroniques rend toutefois 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 la première entité électronique (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 la première entité électronique, une valeur dite "pseudoaléatoire", basée par exemple sur la valeur d'un compteur de la première entité électronique.

La seconde 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 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 par exemple 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.

Cette spécification prévoit notamment que la réponse de l'entité électronique esclave au défi de l'entité électronique hôte soit accompagnée du défi généré par l'entité électronique esclave et destiné à l'entité électronique hôte, comme cela est usuel lorsqu'une authentification mutuelle est recherchée.

OBJET DE L'INVENTION

Dans ce contexte, la présente invention propose un procédé d'authentification d'une première entité électronique par une seconde entité électronique, caractérisé par les étapes suivantes mises en œuvre par la première entité électronique :

- réception d'un (premier) défi en provenance de la seconde entité électronique ;

- génération d'un nombre (ou second défi, ainsi dénommé par référence à la spécification technique précitée) en fonction d'une valeur courante d'un compteur et d'une première clé secrète ;

- génération d'un cryptogramme en fonction du (premier) défi et d'une seconde clé secrète ;

- transmission à destination de la seconde entité électronique d'une réponse incluant le cryptogramme sans transmission dudit nombre (second défi).

L'absence de transmission du nombre (second défi) permet d'éviter qu'un attaquant puisse tenter de découvrir la première clé secrète en observant les valeurs du nombre (second défi) transmises lors de mises en œuvre répétées du procédé, comme c'est le cas lors d'une attaque par cryptoanalyse.

L'absence de transmission du nombre (second défi) n'est toutefois pas préjudiciable à la poursuite du processus d'authentification puisqu'il s'agit en l'occurrence d'une valeur pseudo-aléatoire, que la seconde entité électronique peut déterminer sur la base d'une donnée représentative de la valeur courante du compteur.

La seconde clé secrète est par exemple une clé de session générée notamment sur la base du (premier) défi. Comme expliqué plus loin, le (premier) défi peut être une valeur aléatoire générée par la seconde entité électronique, auquel cas la seconde clé secrète est à chaque fois différente.

La réponse peut en revanche inclure, par exemple en lieu et place du second défi (conformément à la spécification technique précitée), un nombre aléatoire généré par la première entité électronique ou une valeur prédéterminée. On peut prévoir par ailleurs que la réponse inclut ladite valeur courante.

En pratique, le nombre aléatoire ou la valeur prédéterminée peut être situé(e) dans la réponse à un emplacement prévu pour un défi de carte selon le protocole Secure Channel Protocol 03, dont la spécification technique est mentionnée ci-dessus.

Le cryptogramme et le nombre (second défi) peuvent d'ailleurs être respectivement un cryptogramme de carte et un défi de carte conformes au protocole Secure Channel Protocol 03. Le procédé peut comprendre en outre une étape de génération d'une clé de session en fonction d'une clé cryptographique, du (premier) défi et du nombre (second défi). Selon une possibilité de mise en œuvre décrite plus loin, cette clé cryptographique est la première clé secrète.

On peut prévoir ensuite une étape d'échange, entre la première entité électronique et la seconde entité électronique, de données chiffrées au moyen d'un algorithme de chiffrement utilisant la clé de session.

Comme déjà indiqué, la seconde clé secrète peut elle aussi être l'une des clés de session générées. Le cryptogramme est alors généré sur la base d'une clé de session différente pour chaque mise en œuvre du procédé. Un attaquant ne peut dans ce cas rien déduire de l'observation des valeurs successives du cryptogramme.

En pratique, l'étape de génération du cryptogramme peut utiliser ledit nombre (second défi).

Le procédé d'authentification peut en outre comprendre les étapes suivantes mises en œuvre par la seconde entité électronique :

- détermination d'un second défi en fonction d'une donnée représentative de la valeur courante du compteur et de la première clé secrète ;

- détermination d'un autre cryptogramme en fonction du second défi et d'une troisième clé secrète (éventuellement identique à la seconde clé secrète) ;

- transmission de l'autre cryptogramme à destination de la première entité électronique pour authentification de la seconde entité électronique par la première entité électronique.

La première entité électronique est par exemple une carte à microcircuit ou un circuit intégré sécurisé ; la seconde entité électronique peut être un serveur distant ou un terminal de télécommunications.

L'invention propose également une entité électronique comprenant des moyens de réception d'un (premier) défi en provenance d'une autre entité électronique, des moyens de génération d'un nombre (second défi) en fonction d'une valeur courante d'un compteur et d'une première clé secrète, des moyens de génération d'un cryptogramme en fonction du (premier) défi et d'une seconde clé secrète et des moyens de transmission à destination de l'autre entité électronique d'une réponse incluant le cryptogramme sans transmission dudit nombre (second défi). Les caractéristiques optionnelles présentées ci-dessus relativement au procédé d'authentification peuvent également s'appliquer à cette entité électronique.

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 processus d'initiation d'un échange sécurisé 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 processus d'authentification mutuelle qui fait suite au processus d'initiation de la figure 1 .

La figure 1 représente un processus d'initiation d'un échange sécurisé 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 une carte à microcircuit C (ou ICC pour "Integrated Circuit Card') et la seconde entité électronique est un terminal H. L'invention s'applique toutefois à d'autres types d'entités électroniques.

A titre d'exemple, la première entité électronique peut être en variante 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 une 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 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 .

La seconde entité électronique pourrait quant à elle être un serveur distant connecté à la première entité électronique au travers d'une connexion sans fil, ou un serveur directement connecté à la seconde entité au travers d'une connexion filaire.

Le procédé représenté à la figure 1 permet le 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 par tirage aléatoire un défi d'hôte HCH.

Le terminal H émet alors (étape E4) à destination de la carte à microcircuit 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 à microcircuit C reçoit la commande d'initialisation et le défi d'hôte HCH à l'étape E6.

La carte à microcircuit C procède alors à l'incrémentation d'un compteur SQC à l'étape E8. 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. Alternativement, l'incrémentation du compteur est réalisée par la carte à microcircuit C à l'issue de la réception de la commande EXTERNAL AUTHENTICATE décrite ci-après.

L'étape E8 est suivie de l'étape E10 à laquelle on génère (par exemple au moyen d'un processus de dérivation de clé) une valeur (ou nombre) pseudoaléatoire CCH en fonction de la valeur courante du compteur SQC (valeur après incrémentation de l'étape E8), d'une clé cryptographique K-ENC mémorisée dans la carte à microcircuit C et d'un identifiant AID de l'application pour laquelle l'établissement du canal sécurisé est effectué. 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 remarque que la clé cryptographique K-ENC utilisée ici pour la génération de la valeur (ou nombre) pseudo-aléatoire CCH est une clé statique, qui a donc une valeur constante lors de mises en œuvre successives du procédé (en vue, à chaque fois, de l'établissement d'une nouvelle session d'échanges entre le terminal H et la carte à microcircuit C).

Par ailleurs, comme cela sera expliqué ci-dessous, la valeur (ou nombre) pseudo-aléatoire CCH est utilisée comme défi de la carte à microcircuit C (au sens du protocole SCP03 mentionné plus haut) pour authentification du terminal H auprès de la carte à microcircuit C.

On procède alors à l'étape E12 à laquelle la carte à microcircuit C 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 correspondante (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 pseudoaléatoire CCH (générée à l'étape E10). 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é.

Parmi les clés de session SK, on génère en particulier une clé de session de chiffrement S-ENC sur la base de la clé cryptographique K-ENC déjà mentionnée, du défi d'hôte HCH et de la valeur pseudo-aléatoire CCH.

La carte à microcircuit C détermine ensuite à l'étape E14 le cryptogramme d'authentification de la carte CAC, par exemple au moyen d'un processus de dérivation de clé, sur la base de l'une des clés de session SK (par exemple une clé de session de vérification d'intégrité S-MAC distincte de la clé de session de chiffrement S-ENC), 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 E10). 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 génère ensuite à l'étape E16 un nombre aléatoire RAND, par exemple de longueur (en octets) égale à celle de la valeur pseudo-aléatoire CCH (ici 8 octets).

La carte à microcircuit C émet alors à l'étape E18 sa réponse à la commande d'initialisation (voir ci-dessus les étapes E4 et E6), réponse qui inclut le nombre aléatoire RAND généré à l'étape E16, le cryptogramme CAC généré à l'étape E14 et la valeur courante du compteur SQC.

On remarque que, du fait de l'utilisation d'un nombre aléatoire RAND de même longueur que la valeur pseudo-aléatoire CCH, la réponse a la longueur prévue dans le document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Spécification v 2.2 Amendment D" déjà mentionné, soit ici 32 octets.

Toutefois, du fait que cette réponse ne contient pas le nombre (ici une valeur pseudo-aléatoire) CCH tel que défini comme défi de la carte ("card challenge") par le document préalablement mentionné (mais ici un nombre aléatoire RAND), il ne sera pas possible à un tiers malintentionné de tenter de déduire la clé cryptographique K-ENC (utilisée pour la génération de la valeur pseudo-aléatoire comme indiqué ci-dessus) par l'observation du nombre (valeur pseudo-aléatoire) CCH, typiquement lors de mises en œuvre successives d'un grand nombre de tels processus d'authentification mutuelle.

Selon une variante envisageable, la carte à microcircuit C pourrait renvoyer une valeur prédéterminée ou déterministe en lieu et place du nombre aléatoire RAND (auquel cas l'étape E16 de génération du nombre aléatoire RAND pourrait être omise).

Selon une autre variante envisageable, la carte à microcircuit C pourrait ne renvoyer aucune donnée en lieu et place du nombre aléatoire RAND. La réponse émise par la carte à microcircuit C à l'étape E18 pourrait alors par exemple ne contenir que le cryptogramme CAC et le compteur SQC.

Selon une autre possibilité de réalisation, qui peut être combinée avec les divers modes de réalisation qui viennent d'être indiqués, le compteur SQC pourrait ne pas être inclus dans la réponse émise par la carte à microcircuit C à l'étape E18.

Le terminal H reçoit la réponse à l'étape E20 et peut ainsi mémoriser notamment le cryptogramme d'authentification de la carte CAC inclus dans cette réponse.

Ceci achève la phase d'initialisation du processus d'authentification mutuelle ; le processus d'authentification mutuelle peut alors se poursuivre à l'étape E21 comme expliqué ci-dessous en référence à la figure 2.

A l'étape E21 , le terminal H détermine la valeur pseudo-aléatoire CCH selon un procédé identique à celui utilisé par la carte à microcircuit C à l'étape E10, utilisant la valeur courante du compteur SQC, la clé cryptographique K-ENC et l'identifiant AID.

On remarque que, dans l'exemple décrit ici, le terminal a reçu la valeur courante du compteur à l'étape E20 et a donc pu mémoriser une donnée représentative de cette valeur courante. Dans les modes de réalisation où la valeur du compteur SQC n'est pas transmise par la carte à microcircuit à l'étape E18, on peut prévoir par exemple que le compteur a une valeur initiale égale à 0 (ou une autre valeur prédéterminée) lors du premier échange (première session) et que le terminal H incrémente une donnée représentative de la valeur courante du compteur SQC à chaque nouvelle session. 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 SQC. La clé cryptographique K-ENC est quant à elle mémorisée au sein du terminal H (s'agissant d'un secret partagé entre le terminal H et la carte à microcircuit C). La valeur de l'identifiant AID est connue de l'application du terminal H lorsque l'application installée sur le terminal H et l'application installée sur la carte à microcircuit C sont fournies par un même fournisseur. La valeur de l'identifiant AID est alors écrite dans le code de l'application du terminal H. Alternativement, la valeur de l'identifiant AID est transmise par la carte à microcircuit C, après avoir reçu une commande en ce sens. Le procédé se poursuit à l'étape E22 à laquelle le terminal H détermine de son côté le cryptogramme de la carte CAC ^* , au moyen du même processus et des mêmes données que ceux utilisés par la carte à microcircuit C à l'étape E14. Pour ce faire, le terminal H génère en particulier la clé de session S-MAC utilisée, avec le défi d'hôte HCH (généré par le terminal à l'étape E2) et la valeur pseudo-aléatoire CCH (déterminée par le terminal H à l'étape E21 ), pour déterminer la cryptogramme de la carte CAC ^* .

On peut prévoir que le terminal H génère à cette étape d'autres clés de session, notamment la clé de session S-ENC déjà mentionnée (calculée par le terminal H sur la base de la clé cryptographique mémorisée K-ENC, du défi d'hôte HCH généré à l'étape E2 et de la valeur pseudo-aléatoire CCH déterminée à l'étape E21 ).

Le terminal H compare alors à l'étape E24 le cryptogramme CAC ^* déterminé à l'étape E22 au cryptogramme CAC reçu à l'étape E20. On remarque que cette étape E24 est optionnelle en mode prédictif. En effet, ce mode permet de pré-générer un ensemble de clefs de sessions, et permet ainsi d'éviter que la carte à microcircuit C et le terminal H soient connectés. Dans ce cas, la carte émet une réponse, mais le terminal n'est pas nécessairement connecté avec la carte C et n'analyse donc pas cette réponse.

Si le résultat de la comparaison est positif (c'est-à-dire si le cryptogramme calculé CAC ^* est égal au cryptogramme reçu CAC), la carte à microcircuit C a répondu correctement au défi du terminal H et s'est donc authentifiée auprès du terminal H. Le processus d'authentification mutuelle peut alors se poursuivre à l'étape E28 décrite plus bas (pour authentification du terminal H par la carte à microcircuit C).

Si le résultat de la comparaison de l'étape E24 est négatif (c'est-à-dire si le cryptogramme calculé CAC ^* est différent du cryptogramme reçu CAC), l'authentification de la carte à microcircuit C par le terminal H a échoué et le terminal H procède alors à l'étape E26 au traitement de cette anomalie, par exemple en mettant fin à l'échange de données avec la carte à microcircuit C.

Lorsque le processus d'authentification mutuelle se poursuit (en cas de résultat positif de la comparaison à l'étape E24), le terminal H procède à l'étape E28 à la génération d'un cryptogramme d'authentification de l'hôte HAC.

Le cryptogramme d'authentification de l'hôte HAC est par exemple généré au moyen d'un processus de dérivation de clé et sur la base de l'une des clés de session SK (par exemple la clé de session de vérification d'intégrité S- MAC), du défi d'hôte HCH (généré à l'étape E2) et de la valeur pseudo-aléatoire CCH (déterminée à l'étape E21 ). La détermination du cryptogramme d'authentification de l'hôte HAC est par exemple réalisée conformément à ce qui est prévu au paragraphe "6.2.2.3 Host Authentication Cryptogram" dans le document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Spécification v 2.2 Amendment D" déjà mentionné.

Afin d'obtenir un cryptogramme d'authentification de l'hôte HAC différent du cryptogramme d'authentification de la carte CAC alors que les processus de dérivation de clé utilisés dans chaque cas sont identiques, on prévoit dans l'exemple décrit ici que le processus de dérivation de clé s'applique non seulement aux données mentionnées ci-dessus (clé de session S-MAC, défi d'hôte HCH, valeur pseudo-aléatoire CCH), mais également à une constante de dérivation (par exemple d'une longueur de 1 octet) ayant des valeurs différentes respectivement dans le cas de la génération du cryptogramme d'authentification de la carte CAC (étapes E14 et E22), où la constante de dérivation a par exemple la valeur 0, et dans le cas de la génération du cryptogramme d'authentification de l'hôte HAC (étapes E28 et E34 décrite plus bas), où la constante de dérivation a par exemple la valeur 1 .

Le terminal H transmet alors à la carte à microcircuit C le cryptogramme HAC généré à l'étape E28, par exemple au sein d'une commande EXTERNAL AUTHENTICATE. On peut prévoir de transmettre également à cette occasion un code d'authentification de message afin que la carte à microcircuit puisse vérifier l'intégrité du cryptogramme HAC transmis.

La carte à microcircuit C reçoit le cryptogramme HAC à l'étape E32 et, après une éventuelle vérification du code d'authentification de message lorsqu'un tel code est transmis, mémorise le cryptogramme HAC pour comparaison ultérieure (voir ci-dessous l'étape E36).

La carte à microcircuit C détermine alors de son côté à l'étape E34 la valeur attendue HAC ^* du cryptogramme d'authentification de l'hôte sur la base du même processus et des mêmes données que ceux utilisés à l'étape E28. La carte à microcircuit C utilise dans cette étape la clé de session S-MAC générée à l'étape E12, le défi d'hôte HCH reçu à l'étape E6, la valeur pseudo-aléatoire CCH générée à l'étape E10 et la constante de dérivation prédéterminée associée au calcul du cryptogramme d'authentification de l'hôte (de valeur 1 dans l'exemple décrit ici).

La carte à microcircuit peut ainsi comparer à l'étape E36 le cryptogramme HAC reçu à l'étape E32 et le cryptogramme HAC ^* déterminé (par la carte microcircuit C) à l'étape E34.

Si le cryptogramme reçu HAC et le cryptogramme calculé HAC ^* sont égaux (résultat positif de la comparaison), le terminal H s'est correctement authentifié auprès de la carte à microcircuit C et le processus d'authentification mutuelle se termine donc avec succès selon les modalités expliquées plus bas (étapes E40 et E42).

En revanche, si le cryptogramme reçu HAC et le cryptogramme calculé

HAC ^* sont différents (résultat négatif de la comparaison), le terminal H n'est pas authentifié par la carte à microcircuit C et l'ouverture d'un canal sécurisé entre le terminal H et la carte à microcircuit C est donc impossible. On prévoit par exemple dans ce cas que la carte à microcircuit C envoie à l'étape E38 un statut d'erreur au terminal H en réponse à la commande EXTERNAL AUTHENTICATE.

Lorsque le résultat de la comparaison de l'étape E36 est positif, la carte à microcircuit C procède à l'étape E40 à l'émission d'une réponse incluant un statut de fonctionnement correct OK à destination du terminal H.

Le terminal H reçoit cette réponse à l'étape E42, ce qui confirme le succès du processus d'authentification mutuelle.

On remarque qu'à aucun moment (que ce soit au cours de la phase d'initiation décrit à la figure 1 ou au cours de la phase d'authentification mutuelle stricto sensu décrite à la figure 2) le défi de la carte à microcircuit C destiné au terminal H (c'est-à-dire ici la valeur pseudo-aléatoire CCH) n'a été transmis de la carte à microcircuit C au terminal H.

Le processus d'authentification mutuelle étant achevé avec succès, on peut mettre en place des échanges sécurisés de données entre le terminal H et la carte à microcircuit C (étape E44), en chiffrant par exemple les données échangées au moyen d'un algorithme de chiffrement symétrique utilisant la clé de session de chiffrement S-ENC.