FR2834842A1

FR2834842A1 - Procede d'authentification d'un objet portable informatise par un terminal, systeme mettant en oeuvre le procede, terminal utilise dans le procede et objet portable utilise dans le procede

Info

Publication number: FR2834842A1
Application number: FR0200612A
Authority: FR
Inventors: Jerome Ajdenbaum
Original assignee: ITEON
Current assignee: ITEON
Priority date: 2002-01-16
Filing date: 2002-01-16
Publication date: 2003-07-18

Abstract

La présente invention conceme un procédé d'authentification d'un objet portable informatisé par un terminal, le système mettant en oeuvre ce procédé, l'objet portable et le terminal utilisés dans le procédé.Procédé d'authentification lors d'une transaction selon les spécifications EMV et leurs variantes et dérivées d'un objet (1) portable informatisé par un terminal (2) approprié, l'objet (1) portable pouvant utiliser un algorithme cryptographique symétrique pour générer un cryptogramme sur des données à envoyer en ligne à un organisme (3) de confiance pour l'objet (1) portable et/ ou cryptographique asymétrique pour signer des données à envoyer hors-ligne au terminal (2). Le procédé comporte, au cours une procédure spécifique (CSE) d'authentification, une étape d'échange, entre l'objet (1) portable et le terminal (2), d'informations permettant une authentification par le terminal (2) à l'aide un algorithme supplémentaire permettant au terminal (2) de vérifier que l'objet portable dispose d'un secret (SA) déterminé sans en recevoir communication.

Description

Procédé d'authentification d'un objet portable informatisé par un terminal. système mettant en oeuvre le procédé. terminal utilisé dans le procédé et objet portable utilisé dans le procédé
La présente invention concerne un procédé d'authentification d'un objet portable informatisé par un terminal, le système mettant en oeuvre ce procédé, l'objet portable et le terminal utilisés dans le procédé.

Il est connu dans l'art antérieur de réaliser des transactions de type EMV (initiales de Europay MasterCard Visa, marques déposées) entre une carte à puce et un terminal telles qu'elles sont définies dans les différentes versions des spécifications EMV, et notamment dans la version EMV 2000, Integrated Circuit Card Specification for Payment Systems, Book 1, Book 2, Book 3 et Book 4, version 4.0 datée de décembre 2000, et leurs variantes et dérivées. Ces variantes et dérivées des spécifications EMV sont par exemple les spécifications de Visa International (Visa Integrated Circuit Card, trois volumes : carte, application et terminal), les spécifications de Europay et de MasterCard (parmi lesquelles"Integrated Circuit Card (ICC) Application Specification for Pay Now (Debit) and Pay Later (Credit) cards"), les spécifications d'autres organismes tel American Express ainsi que les spécifications nationales publiées par des groupements dans différents pays.

Les principales fraudes sur les cartes de paiement peuvent être divisées en diverses catégories parmi lesquelles : - la carte peut être volée ou perdue et récupérée par un fraudeur ; - la carte peut être authentique mais avoir été interceptée par un fraudeur lors de l'envoi à son destinataire ; - la carte peut être contrefaite.

Jusqu'à l'apparition de la procédure EMV, la meilleure manière de stopper ces fraudes était d'établir systématiquement une connexion entre le terminal recevant la carte et un organisme de confiance pour la carte, tel que par exemple le serveur central de l'organisme émetteur de la carte. Dans EMV, grâce à l'ajout d'un dispositif électronique (puce) sur les cartes, jusque là uniquement dotées d'une piste magnétique, un certain nombre de mesures ont

été désormais introduites pour garantir contre certaines fraudes sans aller systématiquement en ligne.

Les cartes EMV ont un certain nombre de mécanismes qui peuvent considérablement réduire la fraude. Avec EMV, les organismes émetteurs de carte sont capables de définir exactement le comportement de la carte en fonction du lieu où elle a été utilisée, du type d'achat effectué, de l'historique des paiements effectués avec la carte...

Si un terminal accepte une transaction, cela signifie qu'il est certain que la carte n'est pas contrefaite, qu'elle a été émise par une organisation autorisée et qu'elle n'a pas été volée. Lors d'une transaction réalisée hors-ligne, c'est-àdire hors connexion entre le terminal et l'organisme émetteur de la carte, il est nécessaire pour le terminal recevant la carte de vérifier tous ces points sans avoir à recourir à une entité ou une organisation extérieure. Le terminal doit donc lui seul authentifier la carte, c'est-à-dire vérifier que la carte a bien été émise par une organisation fiable et autorisée, et vérifier que les données mémorisées dans la carte sont correctes, c'est-à-dire qu'elles n'ont pas été falsifiées.

Pour authentifier la carte et vérifier l'intégrité des données de manière fiable, on utilise une signature électronique. Certaines données critiques sont signées à l'aide d'une clé secrète. Une clé publique, communiquée notamment aux terminaux, permet de vérifier la signature lors de la procédure d'authentification hors-ligne. La signature est donc effectuée sur le texte à signer. Si les données signées à l'aide de la clé secrète sont modifiées, la signature deviendra fausse et la vérification à l'aide de la clé publique échouera. La signature électronique permet donc d'authentifier l'émetteur des données mais aussi de vérifier leur intégrité.

Le terminal authentifie la carte en vérifiant si les données comprises dans la carte, parmi lesquelles le nom du détenteur de la carte, le numéro de la carte, la date d'expiration de la carte, ont été signées par une entité reconnue et autorisée.

Dans le cas d'une carte dite statique ou SDA (pour"Static Data Authentication"), cette signature est effectuée par l'organisme émetteur de la

carte, par exemple la banque du titulaire de la carte, lors de la personnalisation de la carte, en utilisant un algorithme asymétrique de type RSA (pour Rivest Shamir & Adelman). Pour lire ces données, le terminal utilise donc la clé publique distribuée par l'organisme émetteur de la carte. Cette clé publique peut être connue du terminal ou être stockée dans la carte. Dans ce dernier cas, la clé publique de l'émetteur sera elle-même signée par une autorité supérieure, l'Autorité de Certification, connue de tous les terminaux à travers le monde. On établit ainsi une hiérarchie de confiance permettant d'authentifier de façon sûre les données critiques de la carte.

Dans une carte dite statique ou SDA (pour"Static Data Authentication"), les données sont statiques c'est-à-dire toujours les mêmes.

Dans une carte statique, les données comme le numéro de la carte, la date d'expiration de la carte ou le nom du détenteur de la carte apparaissent en clair sur la carte et sont accompagnées de la signature générée par l'organisme émetteur. Cette signature est effectuée sur ces données par l'organisme émetteur de la carte, elle est immuable et écrite en permanence sur la carte.

Lors de l'authentification de la carte par le terminal, celui-ci compare les données signées qu'il a trouvées en vérifiant la signature avec la clé publique et les données apparaissant en clair sur la carte. Si ces données sont semblables, alors, cela signifie que la carte est authentique et que les données présentes dans la carte n'ont pas été modifiées. Toutes ces données de la carte, y compris la signature, sont donc accessibles librement, sans qu'aucune clé ou code porteur ne soit nécessaire, sinon le terminal serait dans l'incapacité de les lire. Ces données peuvent donc être lues librement et également recopiées facilement sur une carte vierge disponible dans le commerce ou fabriquée par un fraudeur. La signature recopiée correspondra alors bien aux données apparaissant en clair puisque l'ensemble de ces données aura été recopié. Lors d'une transaction effectuée en hors-ligne, le terminal sera donc dans l'incapacité de détecter si la carte est authentique ou si elle est contrefaite.

Une carte statique peut donc être facilement dupliquée si les données ne sont pas modifiées. Toutefois, si un fraudeur souhaite modifier les données,

cela lui sera impossible car il sera alors nécessaire de créer une nouvelle signature sur ces données ce qui est impossible sans la connaissance de la clé secrète conservée par l'organisme émetteur de la carte dans un environnement sécurisé.

Pour améliorer la sécurité, les terminaux fonctionnant suivant EMV peuvent décider d'effectuer la transaction en ligne avec l'organisme émetteur de la carte, par exemple sa banque. Une carte statique comporte une clé secrète cachée dans sa mémoire interne et donc non recopiable sur une fausse carte pour signer des données à l'aide d'un algorithme symétrique de type DES (pour"Data Encryption Standard") ou triple-DES. Lors de cette transaction en ligne, la carte est forcée d'utiliser sa clé secrète et son algorithme pour générer un cryptogramme validant certaines données de la transaction parmi lesquelles des données aléatoires pour éviter des re-jeux, c'est-à-dire de refaire la transaction de la même manière avec les mêmes données. Si la transaction est en ligne, la fausse carte, ne disposant pas de la clé secrète celle-ci étant cachée dans la carte authentique, échoue lors de la procédure d'authentification par l'organisme émetteur et la transaction sera donc rejetée.

Lorsqu'une carte a été volée, la carte est authentique. Seul le code personnel de son possesseur (ou code PIN pour"Personal Identification Number"), protège encore la carte contre les transactions frauduleuses. La vérification du code saisi sur un terminal par un individu est effectuée par la carte. La valeur saisie est comparée avec une valeur référence conservée secrètement dans la mémoire interne de la carte. La carte ne fait donc qu'informer le terminal du résultat de la vérification. Un fraudeur qui a volé une carte authentique ne connaît théoriquement pas le code PIN du possesseur de la carte. Le fraudeur qui aura fabriqué une fausse carte, équipée d'un logiciel imitant le comportement de la carte réelle, pourra également inclure un simulacre de programme de vérification du code PIN qui fasse en sorte que la carte réponde systématiquement positivement quelle que soit la valeur saisie sur le terminal. C'est ce qui est appelée une"Yes Card". Ceci est dû au fait qu'au moment de la vérification du code PIN, le terminal a déjà effectué

l'authentification de la carte, selon la méthode décrite précédemment et a décidé que la carte était authentique, et donc digne de confiance.

Ainsi un fraudeur qui trouve une carte authentique, ou qui dérobe celleci à son propriétaire ne peut pas l'utiliser puisqu'il ne connaît pas la valeur du code PIN. Par contre, il peut créer un clone de cette carte qui acceptera n'importe quelle valeur de code PIN et lui permettra donc de réaliser des transactions hors-ligne en tout point semblables à celle qu'aurait réalisé la carte authentique.

Pour résumer, il existe donc deux principaux types de fraudes, celle où la carte authentique est dupliquée avec ses données sans être volée, par exemple par un commerçant, et celle où la carte authentique est dupliquée avec ses données après avoir été est volée.

Comme décrit ci-dessus, dans le cas d'une carte statique, le problème vient notamment du fait que les données sont signées une seule fois par l'organisme émetteur et restent les mêmes une fois pour toutes dans la carte. Il suffit alors au fraudeur de les lire une fois, pour pouvoir les réutiliser un nombre illimité de fois. Pour résoudre ce problème, il est possible de créer une signature différente lors de l'authentification hors-ligne des données pour chaque transaction effectuée. Les cartes utilisant cette méthode sont appelées des cartes à authentification dynamique ou DDA ("Dynamic Data Authentication") par opposition à SDA. Lors d'une transaction en mode DDA, le terminal demande à la carte de signer, en plus des données critiques de le carte, une donnée variable, par exemple un nombre aléatoire qui est différent à chaque transaction effectuée. Contrairement au mode statique où la carte mémorise uniquement une signature générée par un organisme de paiement, en mode DDA, la carte génère une nouvelle signature pour chaque transaction. En mode DDA, la signature est générée à l'aide d'une clé secrète cachée dans la carte et donc inaccessible aux fraudeurs. Par conséquent, lorsque l'authentification est réalisée en mode DDA, les fraudes décrites ci-dessus deviennent impossible.

Toutefois, bien qu'il existe de réelles différences en ce qui concerne la sécurité entre le mode statique et le mode dynamique, peu d'émetteurs de cartes ont choisi d'émettre des cartes dynamiques. En effet, une carte statique

ne fait que mémoriser une signature toujours identique tandis qu'une carte dynamique doit calculer à chaque transaction une signature différente. Pour cela, la carte dynamique doit mettre en oeuvre un algorithme asymétrique de signature de type RSA (pour Rivest Shamir & Adelman) au cours de chaque transaction. Ce type d'algorithme ne peut être mis en oeuvre dans une carte sans l'utilisation d'un coprocesseur. L'intégration d'un coprocesseur cryptographique dans la carte, un élément du composant électronique spécialisé pour ce type de calculs, augmente considérablement le coût de la carte ce qui fait que ce type de carte fonctionnant en mode dynamique n'est pas choisi par les organismes émetteurs de cartes.

Un but de la présente invention est de proposer une méthode compatible avec les spécifications EMV actuelles et leurs variantes et dérivées, permettant d'authentifier de manière sûre une carte insérée dans un terminal sans aller en ligne avec l'organisme émetteur de la carte et sans utiliser un coprocesseur dans la carte afin de ne pas augmenter considérablement son coût. Cette méthode pourra notamment être mise en oeuvre dans une carte standard de type SDA.

Ce but est atteint par un procédé d'authentification lors d'une transaction selon les spécifications EMV et leurs variantes et dérivées d'un objet portable informatisé par un terminal approprié, l'objet portable pouvant utiliser un algorithme cryptographique symétrique pour générer un cryptogramme sur des données à envoyer en ligne à un organisme de confiance pour l'objet portable et/ou cryptographique asymétrique pour signer des données à envoyer hors-ligne au terminal, ce procédé étant caractérisé en ce qu'il comporte notamment, au cours d'au moins une procédure spécifique d'authentification, une étape d'échange, entre l'objet portable et le terminal, d'informations permettant une authentification de l'objet portable par le terminal à l'aide d'au moins un algorithme supplémentaire permettant au terminal de vérifier que l'objet portable dispose d'un secret déterminé sans en recevoir communication.

Selon une autre particularité, le procédé comprend une étape de vérification permettant de savoir si l'objet portable supporte la procédure

spécifique avant de mettre en oeuvre l'authentification de l'objet portable à l'aide de l'algorithme supplémentaire et, si l'objet portable ne supporte pas la procédure spécifique, une étape de poursuite de la transaction selon les spécifications EMV et leurs variantes et dérivés entre l'objet portable et le terminal.

Selon une autre particularité, le procédé comprend une étape de lecture par le terminal dans l'objet portable des données nécessaires à l'exécution de la procédure spécifique, une étape de récupération de ces données par le terminal et une étape de vérification pour vérifier si toutes ces données ont été récupérées.

Selon une autre particularité, le procédé comprend, en fonction de l'étape de vérification de la présence des données nécessaires à l'exécution de la procédure spécifique et de l'authenticité de ces données, une étape de consignation dans un registre spécifique d'au moins une donnée représentative de ce résultat.

Selon une autre particularité, si des données nécessaires à la mise en oeuvre de la procédure spécifique manquent et/ou n'ont pas été récupérées par le terminal et/ou ne sont pas authentiques, la procédure spécifique d'authentification à l'aide de l'algorithme supplémentaire n'est pas effectuée et le terminal poursuit suivant les spécifications EMV et leurs variantes et dérivées.

Selon une autre particularité, le procédé comprend une étape de consignation dans un registre spécifique mémorisé dans le terminal, d'au moins une donnée dont la valeur représente l'état d'avancement de la procédure d'authentification de l'objet portable effectuée à l'aide de l'algorithme supplémentaire.

Selon une autre particularité, le procédé comprend une étape de consignation dans un registre spécifique mémorisé dans le terminal, d'au moins une donnée dont la valeur représente le résultat de la mise en oeuvre de la procédure spécifique à l'aide de l'algorithme supplémentaire.

Selon une autre particularité, le procédé comporte une étape de lecture des données du registre, une étape de comparaison dans le terminal des

données du registre avec celles d'un ou plusieurs autres registres de référence mémorisés dans le terminal, et une étape de confirmation ou de modification en fonction du résultat de cette comparaison d'un choix effectué par le terminal suivant les spécifications EMV et leurs variantes et dérivées, ce choix correspondant au fait d'effectuer la transaction hors-ligne entre le terminal et l'objet portable, ou de transmettre la transaction en ligne à l'organisme de confiance pour l'objet portable, ou de rejeter la transaction.

Selon une autre particularité, le procédé comprend une étape de rejet de la transaction ou de transmission de la transaction en ligne à l'organisme de confiance pour l'objet portable si la mise en oeuvre de la procédure spécifique a échoué ou s'il manque des données pour la mettre en oeuvre ou si ces données ne sont pas authentiques.

Selon une autre particularité, le procédé comprend une étape de vérification pour savoir si le terminal est capable d'aller en ligne avec l'organisme de confiance pour l'objet portable et une étape de confirmation ou de modification en fonction de cette vérification du choix effectué par le terminal lors de la transaction EMV entre l'objet portable et le terminal, et correspondant au fait de vouloir effectuer la transaction en ligne avec l'organisme de confiance pour l'objet portable.

Selon une autre particularité, en fonction du choix qu'il a effectué, le terminal envoie une commande spécifique à l'objet portable lui demandant de générer un cryptogramme correspondant au choix qu'il a effectué ou à la décision qu'il a prise.

Selon une autre particularité, le procédé comprend une étape d'analyse effectuée par l'objet portable en fonction du choix effectué par le terminal et de critères mémorisés dans l'objet portable définis par l'organisme de confiance pour l'objet portable et une étape de génération d'un cryptogramme correspondant à la décision prise par l'objet portable en fonction de son analyse.

Selon une autre particularité, le procédé comprend une étape d'envoi par l'objet portable au terminal d'une demande d'identification du pays du terminal et une étape d'envoi par l'objet portable au terminal en fonction de la

réponse à l'identification faite par le terminal, d'une ou plusieurs données identifiant la localisation d'un ou plusieurs fichiers à lire dans l'objet portable par le terminal et comportant notamment les données nécessaires à la mise en oeuvre de la procédure spécifique.

Un autre but de l'invention est de proposer un système mettant en oeuvre le procédé tel que décrit ci-dessus.

Ce but est atteint par un système comportant un terminal et un objet portable informatisé, ce système étant caractérisé en ce qu'il comprend des moyens d'échange entre l'objet portable et le terminal d'informations permettant une authentification de l'objet portable à l'aide de l'algorithme supplémentaire permettant au terminal de vérifier que l'objet portable dispose d'un secret déterminé sans en recevoir communication.

Selon une autre particularité, les moyens d'échange sont compatibles avec le protocole défini dans la norme ISO 7816.

Selon une autre particularité, l'algorithme supplémentaire utilisé est l'algorithme de Guillou-Quisquater (GQ).

Selon une autre particularité, l'algorithme supplémentaire utilisé est le second algorithme de Guillou-Quisquater (GQ2).

Selon une autre particularité, l'algorithme supplémentaire utilisé est l'algorithme de Fiat-Shamir.

Selon une autre particularité, l'algorithme supplémentaire utilisé est l'algorithme de Feige-Fiat-Shamir
Selon une autre particularité, l'algorithme supplémentaire utilisé est l'algorithme de Schnorr.

Selon une autre particularité, l'algorithme supplémentaire est le protocole PKP pour"Permuted Kernel Problem".

Un autre but de l'invention est de proposer un objet portable informatisé utilisé pour la mise en oeuvre du procédé d'authentification tel que décrit cidessus.

Ce but est atteint par un objet portable informatisé, caractérisé en ce qu'il comprend des moyens de mémorisation mémorisant des données

spécifiques à la mise en oeuvre de l'algorithme supplémentaire dans la procédure spécifique d'authentification lui permettant de s'authentifier auprès du terminal sans avoir à lui communiquer un secret d'identification.

Selon une autre particularité, l'objet portable comporte des moyens de mémorisation mémorisant une donnée identifiant le fait qu'il supporte ou non la procédure spécifique (CSE) d'authentification.

Selon une autre particularité, l'objet portable mémorise des données propres à sa nature et à sa fonction et les données spécifiques à la mise en oeuvre de l'algorithme supplémentaire.

Selon une autre particularité, l'objet portable mémorise un ou plusieurs registres pour la mise en oeuvre de la procédure spécifique d'authentification, chacun de ces registres comportant des critères que l'organisme émetteur de l'objet portable définit pour aboutir à une décision du terminal correspondant au rejet de la transaction, à la transmission de la transaction en ligne à l'organisme de confiance pour l'objet portable ou à l'acceptation de la transaction horsligne.

Selon une autre particularité, l'objet portable est une carte à puce de type statique.

Un dernier but de l'invention est de proposer un terminal utilisé pour la mise en oeuvre du procédé d'authentification tel que décrit ci-dessus.

Ce but est atteint par un terminal, caractérisé en ce qu'il comprend notamment des moyens de lecture de données mémorisés dans l'objet portable et des moyens de récupération dans ces données lues par les moyens de lecture, de données spécifiques à la mise en oeuvre de l'algorithme supplémentaire dans la procédure spécifique d'authentification lui permettant d'authentifier l'objet portable sans recevoir un secret de la part de l'objet portable.

Selon une autre particularité, le terminal comporte des moyens de vérification dans les données lues par les moyens de lecture que toutes les données nécessaires à la mise en oeuvre de la procédure spécifique sont présentes.

Selon une autre particularité, le terminal comporte des moyens de mémorisation mémorisant une pluralité de registres spécifiques à la mise en oeuvre de la procédure d'authentification, le terminal comportant également des moyens de mise à jour d'un des registres en fonction notamment de l'avancement de la procédure spécifique d'authentification.

L'invention, avec ses caractéristiques et avantages, ressortira plus clairement à la lecture de la description faite en référence aux dessins annexés dans lesquels : - les figures 1 a, 1 b 1 c, 1 d représentent l'organigramme d'exécution d'une transaction suivant les spécifications EMV utilisant la procédure spécifique d'authentification selon l'invention ; - la figure 2 représente schématiquement le système selon l'invention comportant un terminal et une carte insérée dans le terminal ; - la figure 3 représente sous forme de tableau l'objet FCI envoyé par la carte au terminal ; - la figure 4 représente sous forme de tableau le registre spécifique TVR~CSE permettant de mettre en oeuvre la procédure spécifique selon l'invention ; - la figure 5 représente un organigramme définissant les différents tests à effectuer sur la carte et sur le terminal préalablement à la mise en oeuvre d'une procédure d'authentification ;
L'invention va à présent être décrite en liaison avec les figures 1 a à 5.

La procédure d'authentification (CSE, pour"Chip Secure Extensions") selon l'invention est une procédure supplémentaire par rapport à celle déjà utilisée dans une transaction selon les spécifications EMV (marque déposée).

La procédure (CSE) selon l'invention permet une authentification de la carte (1) par le terminal (2) dans lequel elle est insérée. Selon l'invention, il s'agit donc de savoir si la carte (1) a bien été émise par un organisme émetteur (3) fiable et reconnu.

Selon l'invention, l'échange des données entre le terminal (2) et la carte (1) se fait par exemple suivant le protocole APDU (pour"Application Protocol Data Unit") défini dans la norme ISO 7816.

Lors d'une transaction EMV entre un terminal (2) fonctionnant suivant les spécifications EMV et une carte (1, figure 2) insérée dans le terminal (2) et fonctionnant suivant cette norme, dans une étape eO, le terminal (2) commence la procédure comme spécifié dans les spécifications EMV ou leurs variantes et dérivées.

Dans une étape e1, le terminal sélectionne une application (App) dans la carte (1). Cette application (App) sélectionnée est l'une de celles pour laquelle le terminal (2) est paramétré.

Pour sélectionner l'application (App) qu'il a choisie, le terminal (2) envoie à la carte une commande"Select"avec dans un champ de la commande l'AID (pour Application Identifier) de l'application qu'il a choisie. En réponse à cette commande, la carte envoie un objet FCI (pour"File Control Information") au terminal (2). Comme représenté dans le tableau de la figure 3, cet objet comporte des données organisées suivant une structure utilisant des balises (Tag en anglais) définies dans les spécifications EMV. Ces données sont relatives notamment à l'application (App) sélectionnée par le terminal (2).

L'une des balises correspond notamment à une liste des données que la carte (1) souhaite que le terminal (2) lui envoie. Cette liste correspond au PDOL (Processing options Data Object List") (10) dans le tableau représenté en figure 3. Dans une étape e2, le terminal (2) analyse l'objet FCI et notamment la liste PDOL. Dans cette liste, la carte (1) peut demander au terminal (2) qu'il lui envoie des données, comme par exemple la date, l'heure, ou son TCC (pour Terminal Country Code) identifiant le pays où est utilisé le terminal.

Le FCI comprend également des données propriétaires comportant notamment une balise correspondant à un drapeau (D) ou une variable d'état (ou"flag"en anglais) permettant à la carte (1) de faire savoir au terminal (2) qu'elle supporte ou non la procédure spécifique d'authentification selon l'invention. Si le terminal (2) reconnaît ces données, cela signifie qu'il supporte la mise en oeuvre de la procédure spécifique selon l'invention. Le terminal (2)

peut très bien ne pas reconnaître ces données et ne pas les prendre en compte s'il ne supporte pas la mise en oeuvre de la procédure spécifique. Dans une étape e3, le terminal (2) regarde la valeur prise par la variable d'état (D). Si la variable d'état (D) dans le FCI est à la valeur'1', cela signifie que la carte (1) supporte la procédure spécifique (CSE) d'authentification tandis que si cette

variable d'état est à la valeur'0', cela signifie que la carte (1) ne supporte pas la procédure selon l'invention.

Selon une variante de réalisation, la carte peut ajouter dans le FCI des données propriétaires comportant directement la valeur du Witness Token (W), permettant à la carte (1) de faire savoir au terminal (2) qu'elle supporte la procédure spécifique d'authentification selon l'invention et de lui communiquer la valeur du Witness Token (W) en une seule étape. Le terminal doit alors stocker la valeur du Witness Token (W) dans sa mémoire interne.

Si la carte (1) ne supporte pas la procédure spécifique (CSE) selon l'invention, le terminal (2) doit alors procéder à la transaction suivant les spécifications EMV sans mettre en oeuvre la procédure spécifique (CSE), comme indiqué à l'étape e4.

Si la carte (1) supporte la mise en oeuvre de la procédure spécifique selon l'invention, le terminal (2) procède, dans une étape e5, au démarrage dans la carte (1) de l'application (App) qu'il a sélectionnée. Lors de ce démarrage de l'application (App) dans la carte (1), le terminal (2) envoie à la carte (1) une commande"Get Processing Options"avec dans un champ de la commande la liste PDOL complétée parmi laquelle peut se trouver le TCC (pour Terminal Country Code). En réponse à cette commande, la carte (1) envoie au terminal (2) un objet dit AFL (pour"Application File Locator") comportant des données parmi lesquelles des données représentatives de l'emplacement dans les moyens (12) de mémorisation de la carte (1) du ou des fichiers (f1, f2, fn) que le terminal doit lire pour l'application qu'il a choisie. Le terminal, en réponse à la liste PDOL (10) envoyée par la carte, a envoyé le code identifiant son pays. Il peut donc s'agir d'un terminal (2) du même pays que la carte (1) ou d'un pays différent dans le cas où le possesseur de la carte (1) est à l'étranger. La carte (1) tient compte du code pays qu'elle a reçu et

détermine l'objet AFL en fonction de cette donnée. Le ou les fichiers (f1, f2, fn) à lire dans la carte (1) par le terminal (2) ne seront pas les mêmes suivant que le terminal (2) est de la même nationalité que la carte (1) ou est de nationalité différente. Les données (Da) à lire dans le fichier (par exemple f1) indiqué par la carte (1) seront par exemple la donnée AUC (pour Application Usage Control) représentative du fait que la carte (1) est une carte de retrait uniquement, le numéro de la carte, la date d'expiration de l'application sélectionnée... Dans le cas d'une carte SDA, ces données apparaissent en clair et sont également signées (DS) de manière définitive par l'organisme émetteur (3) de la carte (1) au moment de la personnalisation de la carte (1).

Les données (Dcse) nécessaires à la mise en oeuvre de la procédure spécifique selon l'invention sont également signées et placées dans les fichiers (f1, f2, fn) à lire dans la carte (1). La procédure d'authentification (CSE) de la carte (1) selon l'invention est inter-opérable, elle peut donc être réalisée avec tout terminal (2) la supportant même s'il est étranger par rapport à la carte (1).

Le terminal (2) mémorise une pluralité de registres spécifiques à la transaction selon les spécifications EMV. Dans un registre, ci-après désigné TVR (pour"Terminal Verification Result"), le terminal (2), au fur et à mesure de l'avancement de la procédure de vérification, place des bits de ce registre à la valeur'1'ou à la valeur'0'en fonction de certains critères. Par exemple, si le code PIN saisi par l'utilisateur sur le terminal (2) est faux, le terminal (2) mettra le bit de son registre TVR, correspondant à ce test, à la valeur'1'.

Pour mettre en oeuvre la procédure spécifique (CSE) selon l'invention, le terminal (2) mémorise un autre registre dénommé TVR~CSE qui forme une extension au registre TVR. Dans ce registre TVRCSE, si le huitième bit (b8) d'un octet est mis à la valeur'1', cela signifie que la procédure spécifique (CSE) selon l'invention n'a pas été effectuée, si le septième bit (b7) de cet octet est mis à la valeur'1', cela signifie que la procédure d'authentification (CSE) selon l'invention a échoué et si le sixième bit (b6) de cet octet est mis à la valeur'1', cela signifie que des données nécessaires à la mise en oeuvre de la procédure (CSE) selon l'invention manquent dans le ou les fichiers (f1, f2, fn) pour mettre

en oeuvre la procédure. Ces différents aspects sont résumés dans le tableau de la figure 4 qui représente le registre TVRCSE.

Dans une étape e6, le terminal (2) met le huitième bit (b8) du registre TVR~CSE à la valeur'1'indiquant que la procédure spécifique (CSE) selon l'invention n'a pas encore été effectuée.

Dans une étape e7,) le terminal (2) lit les données placées dans le ou les fichiers (f1, f2, fn) mémorisés dans la carte (1) et indiqués par l'AFL envoyé par la carte (1). Dans une étape suivante e8, le terminal (2) procède, comme défini dans les spécifications EMV, à l'authentification hors-ligne des données (Da) de la carte (1) à l'exception de celles (Dcse) utilisées pour la mise en oeuvre de la procédure (CSE) selon l'invention. Le terminal (2) vérifie alors la signature (DS) faite sur des données (Da) en utilisant sa clé publique (Kp) distribuée par l'organisme émetteur (3) de la carte (1). Le terminal (2) ne pouvant pas connaître toutes les clés publiques (Kp) de tous les organismes émetteurs de carte, la clé publique (Kp) peut être stockée dans la carte (1) et envoyée par la carte au terminal (2). Dans ce cas, la clé publique (Kp) de l'organisme émetteur de la carte (1) sera également stockée dans la carte (1) sous une forme elle-même signée par la clé secrète (Kas) d'une autorité supérieure, l'Autorité de Certification, dont la clé publique (Kf) correspondante est connue de tous les terminaux à travers le monde. Ainsi le terminal (2) utilise d'abord la clé publique (Kf) de l'Autorité de Certification pour vérifier la signature de cette clé publique (Kp) lue dans la carte et s'assurer ainsi qu'elle a bien été émise par un organisme émetteur connu de l'Autorité de Certification.

Le terminal vérifie ensuite, à l'aide de cette clé publique (Kp) certifiée et lue dans la carte, la signature (DS) sur les données (Da) de la carte (1) en comparant les données obtenues aux données stockées en clair dans la carte (1). On établit ainsi une hiérarchie de confiance permettant d'authentifier de façon sûre les données critiques de la carte.

Toutefois, la vérification de cette signature (DS) ne permet pas au terminal (2) d'authentifier la carte (1) et de juger que la carte (1) a été émise par un organisme fiable et reconnu. En effet, lors d'une procédure d'authentification faite en hors-ligne, il est impossible au terminal (2) de détecter que la carte (1)

est fausse ou authentique car les données (Da) de la carte (1) et la signature (DS) sur ces données (Da), ainsi que la clé publique (Kp) et la signature sur cette clé publique lorsque celles-ci sont dans la carte (1), peuvent être facilement recopiées sur une carte vierge ou sur un simulacre de carte fabriquée par un fraudeur.

Dans une étape e9, le terminal (2) vérifie qu'il a bien récupéré dans le

ou les fichiers (f1, f2, fn) lus dans la carte (1) à l'étape e7 toutes les données (Dcse) nécessaires à la mise en oeuvre de la procédure spécifique (CSE) et que ces données étaient signées par l'organisme émetteur (3) de la carte. Si des données manquent ou si elles ne sont pas toutes signées, comme décrit cidessus, dans une étape e10, le terminal (2) met le sixième bit (b6) du registre

TVR~CSE représenté en figure 4 à la valeur'1'. Dans ce cas, la procédure spécifique (CSE) selon l'invention ne peut pas être mise en oeuvre, le terminal (2) poursuit donc la transaction comme spécifié dans les spécifications EMV (B). Si toutes les données (Dcse) ont été récupérées par le terminal (2), le

sixième bit (b6) du registre TVR~CSE reste à la valeur'0'.

Si toutes les données ont été récupérées et ont été signées par l'organisme émetteur (3), la procédure d'authentification spécifique (CSE) selon l'invention peut être mise en oeuvre. Cette procédure (CSE) est effectuée sur la base d'un algorithme "zéro connaissance" tel que par exemple l'algorithme de Guillou-Quisquater. Ce type d'algorithme va permettre au terminal (2) de vérifier que la carte (1) dispose bien d'une accréditation secrète (SA) liée à l'identité publique (JA) de la carte sans en recevoir communication, et donc d'authentifier l'identité publique (JA) de la carte. Cette identité (JA) étant elle même signée, le terminal pourra la vérifier en utilisant la clé publique (Kp, Kf) de l'organisme émetteur. L'algorithme de Guillou-Quisquater a fait l'objet des brevets US 5,140, 634 et EP 0 311 470.

D'autres algorithmes peuvent bien entendu être utilisés pour effectuer cette authentification de la carte (1). Une liste non exhaustive de ces algorithmes ainsi que les références des publications concernant chacun de ces algorithmes est présentée ci-dessous : - Second algorithme de Guillou-Quisquater (GQ2).

Jean-Jacques Quisquater and Louis Guillou."The new Guillou-Quisquater Scheme". In Proceedings of the RSA 2000 conference, San Jose, USA. January 2000. Brevets FR, 2 788,908 ; FR, 2 788,910 ; FR, 2 788,911 ; FR, 2 788, 912.

- Fiat-Shamir identification protocol. Brevet US 4,748, 668.

A. Fiat and A. Shamir, How to prove yourself : Practical solutions to identification and signature problems, in : 'Advances in cryptology-CRYPTO 86', A. M. Odlyzko (editor), Springer-Verlag, Berlin (1987), pp. 186-194.

- Feige-Fiat-Shamir identification protocol.

U. Feige, A. Fiat and A. Shamir, Zero knowledge proofs of identity. Journal of Cryptology, Volume 1 (1988) pp. 77-94.

- Schnorr identification protocol. Brevet US 4,995, 082.

C. P. Schnorr, Efficient identification and signatures for smart cards, in : 'Advances in cryptology-CRYPTO 89', G. Brassard (editor), Springer-Verlag, Berlin (1990) pp. 239-252.

- Permuted Kernel Problem protocol.

A. Shamir,"An efficient identification scheme based on permuted kernels" Advances in Cryptology (Proceedings of Crypto 89'), Lecture Notes in Computer Science, vol. 435, Springer-Verlag, 1990, pp. 606-609.

Lors de la mise en oeuvre de la procédure spécifique (CSE) selon l'invention, la carte (1) choisit à l'aide d'un générateur (11) de nombre aléatoire un nombre aléatoire dénommé ci-après r supérieur ou égal à 1 et inférieur ou égal à n-1, n étant le modulo de l'algorithme Guillou-Quisquater mémorisé dans la carte. Cette donnée n fait partie des données (Dcse) récupérées par le terminal (2) dans les fichiers (f1, f2, fn) mémorisés dans la carte (1) et nécessaires pour la mise en oeuvre de la procédure spécifique. La carte effectue ensuite le calcul de W, ci-après dénommé "Witness Token" : W = r'mod n
La donnée v fait également partie des données (Dcse) récupérées par le terminal dans le fichier mémorisé dans la carte (1) et nécessaires pour la

mise en oeuvre de la procédure spécifique. La donnée v est l'exposant public de Guillou-Quisquater.

Dans une étape e11, le terminal (2) envoie à la carte (1) une commande"Get Data"pour récupérer W dans la carte (1). Dans une étape e12, selon le protocole défini dans la norme ISO 7816, la carte (1) répond en envoyant un mot d'état (en anglais"Status Word" (SW)) égal à'9000'pour indiquer que la commande a bien été effectuée et envoie également la valeur calculée pour le"Witness Token"W dans les données de sa réponse. Si toutefois la commande n'est pas correctement effectuée par la carte, celle-ci renvoie un mot d'état différent de'9000'. Le terminal (2) stoppe alors la procédure d'authentification spécifique (CSE) de la carte (1) pour passer à l'étape suivante telle que définie dans les spécifications EMV (B, figure 1 c).

Dans une étape e13, le terminal (2) stocke ensuite W dans sa mémoire interne.

Selon une variante de réalisation, si le terminal a déjà récupéré dans le FCI renvoyé lors de la commande Select à l'étape e2, des données propriétaires, comportant directement la valeur du Witness Token (W), il peut ignorer les étapes e11, e12 et e13.

Dans une étape e14, le terminal (2) choisit ensuite un nombre aléatoire, appelé challenge et dénommé ci-après'e', supérieur ou égal à 1 et inférieur ou égal à v-1, v étant l'exposant public de Guillou-Quisquater.

Le terminal (2) envoie à la carte (1) une commande dénommée par exemple"Internal Authenticate"avec dans le champ données, le nombre aléatoire'e'qu'il a déterminé, cette commande demandant à la carte d'effectuer le calcul de'y'dénommé "Response Token" et de lui envoyer la valeur calculé pour'y'en réponse à cette commande.

Après réception dee, la carte effectue donc le calcul de'y' : y = r. (SA) e mod n
SA est défini comme l'accréditation secrète cachée dans la carte et servant pour la mise en oeuvre de l'algorithme de Guillou-Quisquater.

Dans une étape e15, la carte (1), en réponse à la commande"Internal Authenticate"envoie au terminal un mot d'état (SW) égal à 9000 indiquant que

la commande a bien été effectuée et envoie dans le champ données la valeur calculée pour'y'. Si toutefois la commande n'a pas été correctement effectuée dans la carte, la carte renvoie un mot d'état différent de'9000'. Le terminal (2) stoppe alors la procédure d'authentification (CSE) de la carte (1) pour passer à l'étape (B, figure 1 c) suivante telle que définie dans EMV.

Si la carte (1) a renvoyé un mot d'état égal à'9000', dans une étape e16, le terminal (2) met alors le huitième bit (b8) du registre TVRCSE à la valeur'0'pour indiquer que la procédure spécifique (CSE) selon l'invention a bien été effectuée.

Dans une étape e17, le terminal (2) stocke ensuite'y'dans sa mémoire interne. Le terminal (2) vérifie que la valeur de'y'est différente de 0. Si cette conditions n'est pas remplie pour'y', alors la procédure d'authentification de la carte (1) a échoué et le terminal met le septième bit (b7) du registre TVRCSE à la valeur'1'pour indiquer que la procédure spécifique d'authentification (CSE) de la carte (1) a échoué.

Le terminal (2) effectue le calcul de la valeur de vérification du"Witness token", cette valeur étant dénommée ci-après par W' .

W = y. (J mod n
Dans une étape e19, le terminal (2) vérifie ensuite si W est égal à W'.

Si W n'est pas égal à W', dans une étape e20, le terminal (2) met le

septième bit (b7) du registre TVR~CSE à la valeur'1'pour indiquer que la procédure spécifique d'authentification (CSE) selon l'invention a échoué. Le terminal (2) passe alors à l'étape suivante (B) comme définie dans les spécifications EMV.

Si W=W', le terminal (2) laisse le septième bit du registre TVR~CSE à la valeur 0 indiquant que la procédure spécifique (CSE) selon l'invention n'a pas échoué et passe à l'étape suivante (B) comme définie dans EMV.

Dans une étape e21, le terminal (2) procède à des vérifications de données comme cela est défini dans EMV. Il s'agit alors de vérifier par exemple quel la date de la transaction n'est pas ultérieure à la date d'expiration de la carte (1). En fonction de la validité ou non de cette date d'expiration, le terminal (2) va mettre un bit à la valeur'0'ou'1'dans son registre TVR.

Dans une étape (e22), le terminal (2) procède à la vérification de l'identité du porteur de la carte (1), par exemple en vérifiant son code PIN (pour "Personal Identification Number") saisi par l'utilisateur sur le terminal (2). Comme explicité ci-dessus dans la partie introductive de cette description, le terminal (2) envoie le code PIN à la carte (1) qui se charge d'effectuer la vérification. Comme lors de l'étape précédente, le terminal (2) met des bits à la valeur'1'ou à la valeur'0'dans son registre TVR en fonction du résultat de la vérification.

Le terminal (2) effectue dans une étape e23, une gestion des risques comme spécifié dans EMV. Il s'agit pour le terminal (2) de considérer les risques qu'il peut prendre en fonction des valeurs prises par les bits dans son registre TVR.

Dans une étape e24, le terminal (2) procède ensuite à l'analyse de son registre TVR afin de prendre une décision. Pour cela le terminal (2) compare son registre TVR avec d'autres registres mémorisés. Ces registres mémorisés sont communément appelés TAC (pour"Terminal Action Code") et IAC (pour

"Issuer Action Code"). Il existe le registre TAC~Deniai, le registre TAC~Online et le registre TAC~Default. De même, il existe le registre lAC~Deniai, le registre IAC~Online et le registre IAC~Default. Les différents registres TAC sont des registres fournis par l'émetteur du terminal (2) et mémorisés dans le terminal (2). Les registres lAC sont fournis par l'organisme émetteur (3) de la carte (1) et mémorisés dans la carte. Ces registres IAC sont lus par le terminal (2) dans le

ou les fichiers (f1, f2, fn) à lire dans la carte (1) puis sont récupérés par le terminal qui les mémorise. Dans chacun des registres fournis, certains bits sont à la valeur'l'tandis que d'autres sont à la valeur'0'. La valeur de chaque bit dans chacun de ces deux registres (TAC, IAC) correspond aux critères que l'émetteur respectivement du terminal et de la carte (1) définissent pour aboutir à une décision du terminal (2) correspondant au rejet de la transaction, à son acceptation ou au fait d'aller en ligne avec l'organisme émetteur (3) de la carte.

Le terminal (1) commence par comparer la valeur de chaque bit dans son registre TVR avec la valeur correspondante dans les registres TAC-Denial et lAC~Denial et prend une décision en fonction de cette comparaison. Par

exemple, si le bit correspondant au fait que la valeur du code PIN est faux est à la valeur'1'et le bit correspondant dans les registres TAC-Denial ou

lAC~Deniai est également à la valeur'1', cela signifie que respectivement l'émetteur du terminal (2) ou l'émetteur de la carte (1) souhaite que la transaction soit rejetée lorsque le code PIN saisi est faux. Dans ce cas, le terminal (2) demandera donc à la carte (1) de rejeter la transaction. Si lors de la comparaison, il s'avère qu'aucun des bits du registre TVR n'est à la valeur'1' en même temps que son bit correspondant dans les registres TAC-Denial ou lAC~Deniai, alors le terminal (2) ne va pas rejeter la transaction et va regarder s'il doit aller en ligne. Pour cela, il compare son registre TVR avec les registres TAC~Online et IAC~Online. En fonction de cette comparaison, le terminal (2) va décider ensuite d'aller en ligne ou non. Si au moins un bit du TVR et le bit correspondant de l'un des registres TAC-Online ou IAC~Online sont tous les deux à la valeur'1', alors le terminal (2) prend la décision de procéder à la transaction en ligne avec l'organisme émetteur (3) de la carte. Si aucun des bits du registre TVR n'est à la valeur'1'en même temps que son bit correspondant dans les registres TAC~Online ou IAC-Online, alors le terminal (2) choisit d'effectuer la transaction hors-ligne. Si le terminal (2) choisit d'aller en ligne mais qu'il est incapable d'aller en ligne alors il effectue une comparaison entre le registre TVR et les registres TAC~Default et IAC~Default. Les registres TAC~Default et IAC~Default définissent en effet les conditions suivant lesquelles la transaction doit être rejetée si le terminal (2) a décidé de faire la transaction en ligne mais que pour une raison déterminée le terminal (2) ne peut aller en ligne. Les spécifications EMV définissent également des règles à appliquer lorsque certains des registres lAC mémorisés dans la carte sont manquants.

En fonction de cette analyse, le terminal (2) demande à la carte (1) de confirmer ou de modifier son choix. Le terminal (2) peut donc choisir de : - rejeter la transaction sans aller en ligne ; - demander la transmission de la transaction en ligne avec l'organisme émetteur (3) de la carte ; - accepter la transaction sans aller en ligne.

En fonction de l'analyse qu'il aura effectuée au cours de l'étape e24 et de sa gestion des risques, le terminal (2) prend une décision représentée par des données mémorisées dans les moyens de mémorisation du terminal (2).

Dans une transaction EMV, le terminal (2) demande ensuite à la carte (1) de confirmer ou de modifier cette décision, sachant que la carte (1) ne peut que confirmer la décision ou rendre une décision dégradée par rapport à celle proposée par le terminal (2). Par exemple, si le terminal (2) souhaite rejeter la transaction, la carte (1) ne peut pas souhaiter aller en ligne avec l'organisme émetteur (3) ou accepter la transaction. Si le terminal (2) souhaite aller en ligne, la carte (1) ne peut que confirmer le fait d'aller en ligne ou souhaiter le rejet de la transaction, elle ne peut pas accepter la transaction hors-ligne.

Pour effectuer cette demande, le terminal (2) envoie à la carte (1) une commande "Generate AC" (AC pour"Application Cryptogram") demandant à la carte (1) de générer un cryptogramme dont la nature est représentative de la décision du terminal (2). Le terminal (2) peut demander à la carte (1) de générer un cryptogramme équivalent à un accord pour effectuer la transaction en hors-ligne (TC pour"Transaction Certificate") ou équivalent à un accord pour effectuer la transaction en ligne (ARQC pour"Application Request Cryptogram") avec l'organisme émetteur (3) de la carte (1) ou équivalent à un rejet de la transaction (AAC pour"Application Authentication Cryptogram").

Pour cela, la commande"Generate AC"comprend dans son champ données (P1) des données représentatives de l'un des accords décrit ci-dessus.

En fonction de la décision prise par le terminal (2) lors de son analyse, la procédure spécifique selon l'invention vient confirmer ou modifier cette décision. En fonction de la décision prise par le terminal (2), celui-ci peut choisir d'envoyer dans le paramètre P1 de la commande"Generate AC"suivant le format APDU, des données représentatives d'une demande de rejet de la transaction, des données représentatives d'une demande de transmettre la transaction en ligne, ou des données représentatives d'une demande d'accepter la transaction hors-ligne.

Comme pour l'analyse effectuée selon les spécifications EMV et décrite ci-dessus, le terminal (2) utilise pour la mise en oeuvre de la procédure

spécifique (CSE) une pluralité de registres mémorisés. Ces registres sont édités comme pour l'EMV par l'émetteur du terminal (2) et par l'émetteur de la carte (1), mais sont appropriés à la mise en oeuvre de la procédure spécifique (CSE) selon l'invention, c'est-à-dire qu'ils sont différents des registres TAC et IAC utilisés lors de l'analyse effectuée selon les spécifications EMV. La valeur prise par chaque bit dans ces registres correspond aux critères que l'émetteur du terminal (2) et de la carte (1) définissent pour aboutir à une décision du terminal (2) correspondant au rejet de la transaction ou à son acceptation ou au fait de transmettre la transaction en ligne à l'organisme émetteur (3) de la carte.

Les registres édités par l'émetteur du terminal (2) sont dénommés par exemple TAC~CSE~Denial, TAC~CSE~Online et TAC~CSE~Default et sont mémorisées dans le terminal (2). Les registres édités par l'émetteur de la carte (1) sont dénommés par exemple IAC~CSE~Denial, IAC~CSE~Online et IAC~CSE~Default et sont mémorisées dans la carte. Ces registres IAC sont mémorisés dans la carte, lus par le terminal lors de l'étape e7 de lecture des données, récupérés et mémorisés par le terminal. Si certains de ces registres sont manquants, le terminal (2) va construire les registres virtuels correspondants dans lesquels tous les bits sont mis à la valeur'l'forçant ainsi la transaction à être rejetée ou à être transmise en ligne.

Au cours d'une étape e25, si le terminal (2), en fonction de son analyse réalisée au cours de l'étape e24, décide de demander à la carte (1) un accord pour rejeter la transaction, c'est-à-dire si P1 ='MC'alors la transaction sera obligatoirement rejetée, la carte (1) ne pouvant prendre que la même décision que le terminal (2) ou une décision dégradée. Dans une dernière étape (ef), le terminal (2) terminera alors la transaction comme cela est spécifié dans EMV.

Si le terminal (2) décide de ne pas demander à la carte le rejet de la

transaction, c'est-à-dire si P1 < > 'MC', il va comparer dans une étape e26 son registre spécifique à la procédure selon l'invention, c'est-à-dire le registre TVR~CSE, avec les registres TAC~CSE~Denial et IAC~CSE~Denial. Si l'un des bits du TVR~CSE et le bit correspondant du registre TAC~CSE~Denial ou du registre IAC~CSE~Denial sont tous les deux à la valeur'1', alors le terminal (2) décide de rejeter la transaction. Dans une étape (e27), il enverra alors à la

carte (1) une commande"Generate AC"lui demandant de générer un cryptogramme correspondant à un MC, c'est-à-dire correspondant à sa décision de rejeter la transaction. Le terminal effectuera alors la dernière étape (et) comme spécifié dans EMV. Si les bits correspondants du registre TVR~CSE et des registres TAC~CSE~Denial et IAC~CSE~Denial ne sont pas à la valeur'1', alors le terminal regarde dans une étape e28, si la décision qu'il a prise lors de son analyse suivant EMV correspond à P1='ARQC'.

SI P1 ='ARQC', le terminal passe à l'étape e30 décrite plus loin.

Si P1 < > 'ARQC', dans une étape e29, le terminal (2) compare le registre TVR~CSE avec les registres TAC~CSE~Online et IAC~CSE~Online. Ces registres TAC~CSE~Online et IAC~CSE~Online définissent les conditions respectivement de l'émetteur du terminal et de l'émetteur de la carte suivant lesquels la transaction doit être transmise en ligne à l'organisme émetteur (3). Si chacun des bits du registre TVRCSE et leur bit correspondant dans les

registres TAC~CSE~Online et IAC~CSE~online ne sont pas à la valeur'1', alors le terminal (2) envoie à la carte (1) une commande"Generate AC"lui demandant de générer un cryptogramme correspondant à un TC, c'est-à-dire à sa décision d'accepter la transaction hors-ligne.

Si l'un des bits du TVR~CSE et le bit correspondant du registre

TAC~CSE~Online ou du registre IAC~CSE~Online sont tous les deux à la valeur'1', alors le terminal (2) vérifie dans une étape e30 s'il est capable ou non d'aller en ligne. Si le terminal (2) est capable d'aller en ligne alors il envoie, dans une étape e31, une commande"Generate AC"à la carte (1) lui demandant de générer un cryptogramme ARQC correspondant à sa décision de transmettre la transaction en ligne.

Si le terminal (2) est incapable d'aller en ligne, alors, dans une étape e32, il effectue la comparaison du registre TVR~CSE avec les registres TAC~CSE~Default et IAC~CSE~Default. Ces deux registres indiquent les conditions suivant lesquelles la transaction doit être rejetée lorsque la transaction doit être transmise en ligne mais que le terminal (2) est incapable d'aller en ligne. Si au moins l'un des bits du registre TVR~CSE et un bit correspondant du registre TAC~CSE~Default ou du registre TAC~CSE~Default

sont à la valeur'1', alors le terminal (2) décide de rejeter la transaction. Dans une étape e33, le terminal (2) envoie alors à la carte une commande "Generate AC"lui demandant de générer un cryptogramme correspondant à sa décision de rejeter la transaction hors-ligne c'est à dire correspondant à un AAC. Si

aucun des bits du registre TVRCSE n'est à la valeur'1'en même temps qu son bit correspondant dans les registres TAC~CSE~Default ou )ACCSEDefau) t, aiors ! e terminai (2) prend la décision d'accepter la transaction hors-ligne. Dans une étape e34, il envoie alors une commande "Generate AC"demandant à la carte de générer un cryptogramme TC correspondant à sa décision d'accepter la transaction hors-ligne.

Après l'envoi de la commande"Generate AC"à la carte (1) par le terminal (2), la carte (1) effectue également une analyse en fonction de paramètres par exemple mémorisés par l'organisme émetteur (3) de la carte (1) et correspondant à certains critères que la carte (1) doit prendre en compte pour prendre à son tour sa décision. Par exemple, la carte (1) peut prendre la décision de transmettre la transaction en ligne à l'organisme émetteur (3) alors que le terminal (2) souhaitait accepter la transaction hors-ligne. La raison de cette décision prise par la carte (1) vient par exemple du fait que la carte (1) est neuve et que la consigne est de transmettre toujours la transaction en ligne lors de la première transaction ou du fait que la carte (1) a remarqué en consultant les dernières transactions mémorisées dans sa mémoire que la transaction n'a pas été transmise en ligne depuis un certain temps.

En fonction de ces critères et de la demande formulée par le terminal (2), la carte (1) prend une décision qui peut être la même que celle du terminal (2) ou dégradée par rapport à celle-ci comme décrit ci-dessus. Par exemple, si le terminal souhaite transmettre la transaction en ligne et que la carte souhaite rejeter la transaction, la transaction devra être rejetée.

La carte (1) pourra générer le cryptogramme AAC, ARQC ou TC sur des données ayant un rapport avec la transaction. Ces données incluront par exemple la date du jour ou la raison sur laquelle sa décision est basée.

La carte comporte par exemple un algorithme de cryptographie symétrique de type DES (pour"Data Encryption Standard") ou triple-DES

qu'elle peut mettre en oeuvre sans avoir besoin d'un coprocesseur et qui lui permet de générer un cryptogramme à partir des données en utilisant une clé secrète (kc). La carte (1) commence par envoyer au terminal (2) des données représentatives de la nature du cryptogramme qu'elle va lui envoyer et donc de la décision qu'elle a prise. En fonction de ces données le terminal (2) sait quel cryptogramme il va recevoir et sous quelle forme il doit mettre en oeuvre la transaction si la transaction doit avoir lieu.

La carte (1) envoie ensuite le cryptogramme au terminal (2). Le terminal (2) ne vérifie pas ce cryptogramme car il ne dispose pas des moyens cryptographiques en l'occurrence la clé secrète (kc) pour vérifier ces données. Seul l'organisme émetteur de la carte (1) vers qui est remonté le cryptogramme peut le vérifier car il a connaissance de la clé secrète (kc) de la carte. Les données sont ensuite stockées au niveau de l'organisme émetteur (3) de la carte (1). La vérification de ce cryptogramme permet à l'organisme émetteur de s'assurer qu'il s'agit bien de la carte qui a généré ce cryptogramme sur ces données et que ces données sont intègres, c'est-à-dire qu'elles n'ont pas été falsifiées.

Dans les différents cas présentés ci-dessus, si la carte (1) a généré un cryptogramme correspondant à un MC ou à un TC, le terminal, dans une dernière étape ef, respectivement n'effectue pas la transaction ou effectue la transaction avec la carte en hors-ligne.

En revanche, si la carte a généré un cryptogramme correspondant à un ARQC, le terminal transmet dans une étape e35 la transaction en ligne à l'organisme émetteur (3) de la carte comme spécifié dans les spécifications EMV.

Dans une étape e36, le terminal (2), selon les instructions de l'organisme émetteur (3), peut être amené à transmettre des listes de commandes appelées"scripts"à la carte (1) pour qu'elle les traite, par exemple des données de mise à jour, des nouveaux critères de décision...

Lors de l'étape e30, Le terminal (2) a été jugé apte à aller en ligne, toutefois, pour une raison déterminée, par exemple parce qu'il existe des problèmes de connexion avec l'organisme émetteur (3), il peut lui être

impossible d'aller en ligne. Une étape e37 permet de vérifier si le terminal (2) a été capable ou non d'aller en ligne.

Si le terminal (2) a été incapable d'aller en ligne par exemple pour la

raison évoquée ci-dessus, au cours d'une étape e38, le terminal (2) effectue la comparaison du registre TVR~CSE avec les registres TAC~CSE~Default et lAC~CS E~Defau It.

Si au moins un bit du registre TVR~CSE et le bit correspondant du registre TAC~ESE~Default ou du registre IAC~CSE~Default sont à la valeur'1', alors le terminal (2) prend la décision de rejeter la transaction. Dans une étape e39, il envoie alors à la carte (1) une commande"Generate AC"demandant à la carte (1) de générer un cryptogramme correspondant à sa décision de rejeter la transaction, c'est-à-dire correspondant à un AAC. Dans la dernière étape ef, le terminal (2) effectue alors le rejet de la transaction comme cela est spécifié dans EMV.

Si aucun des bits du registre TVR~CSE n'est à la valeur'1'en même temps que son bit correspondant dans les registres TAC~CSE~Default ou
IAC~CSE~Default, alors le terminal (2) ne rejette pas systématiquement la transaction. Le terminal (2) prend alors une décision en fonction de ce que prévoient les spécifications EMV.

Selon une variante de réalisation, le terminal n'effectue pas son analyse à partir de l'étape e25, c'est-à-dire une fois que le terminal a pris une décision suivant les spécifications EMV et une fois que le registre TVRCSE a été complété mais prend une décision au fur et à mesure de l'avancement de la transaction entre le terminal (2) et la carte (1). Par exemple, le terminal (2) pourra prendre une décision correspondant par exemple au rejet de la transaction ou à la transmission de la transaction en ligne à l'organisme émetteur (3) de la carte (1) par exemple dés l'instant que le terminal, lors l'étape e9, sait que toutes les données nécessaires à la mise en oeuvre de la procédure spécifique (CSE) n'ont pas été récupérées ou ne sont pas signées par l'organisme récepteur (3) ou dès l'instant que le terminal sait à l'étape e19 que la procédure spécifique (CSE) a échoué. Le terminal (2) pourra alors

demander à la carte (1) de générer le cryptogramme correspondant à sa décision ou pourra interrompre la transaction.

Selon une variante de réalisation, afin d'améliorer les performances, le terminal de procède pas à l'authentification par la procédure spécifique d'authentification (CSE) en récupérant le Witness Token (W) en utilisant une commande"Get Data"puis en envoyant le challenge'e'par une commande "Internal Authenticate". A la place, il utilise la commande GenerateAC pour envoyer le challenge'e'à la carte et pour récupérer le Response Token (W), au cours de la suite de la procédure EMV, dans l'étape ef.

Dans ce cas le terminal n'effectue pas de traitements spécifiques à la présente invention à partir de l'étape e14. Dans ce cas le terminal (2) choisit un nombre aléatoire, dénommé ci-après e, supérieur ou égal à 1 et inférieur ou égal à v-1, v étant l'exposant public de Guillou-Quisquater.

Le terminal (2) poursuit ses traitements, comme défini dans les spécifications EMV jusqu'à la commande Generate AC.

Le terminal envoie alors à la carte (1) une commande "Generate AC" avec dans le champ données, outre les données spécifiées dans les spécifications EMV, le nombre aléatoire'e'qu'il a déterminé. Cette commande demande à la carte d'effectuer le calcul de'y'dénommé"Response Token"et de lui envoyer la valeur calculée pour'y'en réponse à cette commande, en plus des autres particularités de cette commande déjà décrites dans les spécifications EMV.

Après réception du challenge'e', la carte effectue donc le calcul du Response Token'y' : y = r. (S mod n
SA est défini comme l'accréditation secrète cachée dans la carte et servant pour la mise en oeuvre de l'algorithme de Guillou-Quisquater.

Le terminal (2) stocke ensuite'y'dans sa mémoire interne. Le terminal (2) vérifie que la valeur de'y'est différente de 0. Si cette conditions n'est pas remplie pour'y', alors la procédure d'authentification de la carte (1) a échoué.

Le terminal (2) effectue le calcul de la valeur de vérification du"Witness token", cette valeur étant dénommée ci-après par W'.

W'= yV. (JA) e mod n
Le terminal (2) vérifie ensuite si W est égal à W'.

Si W n'est pas égal à W', la procédure spécifique d'authentification (CSE) selon l'invention a échoué.

Si W=W', la procédure spécifique d'authentification (CSE) selon l'invention n'a pas échoué.

Si la procédure spécifique (CSE) selon l'invention a échoué, le terminal doit rejeter la transaction.

Si la procédure spécifique (CSE) selon l'invention n'a pas échoué, le terminal continue le traitement selon les spécifications EMV.

Selon l'invention et comme représenté en figure 5, une succession de tests est effectuée afin de déterminer de quel type de terminal il s'agit et de quel type de carte il s'agit.

Un premier test consiste à regarder dans une première étape e'1 si le terminal peut fonctionner en mode dynamique DDA. Si le terminal supporte le mode dynamique, alors un test permet de vérifier dans une étape e'2 si la carte supporte également le mode dynamique. Si la carte supporte le mode dynamique, alors l'authentification de la carte par le terminal pourra être effectuée hors-ligne suivant le mode DDA au cours de l'étape e'3. Le mode DDA offrant toutes les garanties en terme de sécurité, il ne sera donc pas nécessaire d'utiliser la procédure spécifique CSE selon l'invention.

Si le terminal ne supporte pas le mode DDA, un test est effectué à l'étape e'4, pour regarder si le terminal (2) supporte le mode statique SDA. Si le terminal ne supporte pas le mode SDA, aucune authentification hors-ligne (e'5) ne peut être effectuée par ce terminal. La procédure spécifique CSE selon l'invention ne pourra pas non plus être utilisée. Si le terminal supporte le mode SDA, Un test est effectué à l'étape e'6 pour savoir si la carte supporte également ce mode. Si la carte ne supporte pas le mode SDA, alors aucune authentification hors-ligne (e'5) ne pourra être effectuée.

Si la carte supporte le mode SDA, alors un test est effectué à l'étape e'7 pour savoir si le terminal supporte la procédure spécifique CSE selon

l'invention. Si le terminal ne supporte pas la procédure CSE selon l'invention, alors l'authentification hors-ligne sera effectuée à l'étape e'8 suivant le mode SDA uniquement sans procédure d'authentification particulière de la carte et donc avec tous les risques que cela comporte comme explicité dans la partie introductive de cette description.

Si le terminal supporte la mise en oeuvre de la procédure spécifique CSE selon l'invention, alors un test est effectué à l'étape e'9 pour savoir si la carte supporte également la mise en oeuvre de la procédure CSE selon l'invention. Si la carte ne supporte pas la mise en oeuvre de la procédure CSE, alors l'authentification hors-ligne devra également être effectuée suivant le mode SDA sans l'utilisation de la procédure CSE (étape e'8).

Si la carte supporte la procédure CSE, l'authentification hors-ligne sera effectuée en mode SDA et la procédure CSE selon l'invention telle que décrite ci-dessus devra être utilisée (étape e'10).

Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus.

Claims

REVENDICATIONS

1. Procédé d'authentification lors d'une transaction selon les spécifications EMV et leurs variantes et dérivées d'un objet (1) portable informatisé par un terminal (2) approprié, l'objet (1) portable pouvant utiliser un algorithme cryptographique symétrique pour générer un cryptogramme sur des données à envoyer en ligne à un organisme (3) de confiance pour l'objet (1) portable et/ou cryptographique asymétrique pour signer des données à envoyer hors-ligne au terminal (2), caractérisé en ce qu'il comporte notamment, au cours d'au moins une procédure spécifique (CSE) d'authentification, une étape d'échange, entre l'objet (1) portable et le terminal (2), d'informations permettant une authentification de l'objet portable par le terminal (2) à l'aide d'au moins un algorithme supplémentaire permettant au terminal (2) de vérifier que l'objet portable dispose d'un secret (SA) déterminé sans en recevoir communication.

2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une étape de vérification permettant de savoir si l'objet (1) portable supporte la procédure spécifique (CSE) avant de mettre en oeuvre l'authentification de l'objet (1) portable à l'aide de l'algorithme supplémentaire et, si l'objet (1) portable ne supporte pas la procédure spécifique (CSE), une étape (e4) de poursuite de la transaction selon les spécifications EMV et leurs variantes et dérivés entre l'objet (1) portable et le terminal (2).

3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comprend une étape de lecture (e7) par le terminal (2) dans l'objet (1) portable des données (Dcse) nécessaires à l'exécution de la procédure spécifique (CSE), une étape de récupération de ces données par le terminal (2) et une étape de vérification (e9) pour vérifier si toutes ces données (Dcse) ont été récupérées.

4. Procédé selon la revendication 3, caractérisé en ce qu'il comprend, en fonction de l'étape de vérification (e9) de la présence des données nécessaires à l'exécution de la procédure spécifique (CSE) et de l'authenticité de ces données (Dcse), une étape de consignation (e10) dans un registre

(TVRCSE) spécifique d'au moins une donnée (b6) représentative de ce résultat.

5. Procédé selon la revendication 4, caractérisé en ce que si des données (Dcse) nécessaires à la mise en oeuvre de la procédure spécifique (CSE) manquent et/ou n'ont pas été récupérées par le terminal (2) et/ou ne sont pas authentiques, la procédure spécifique (CSE) d'authentification à l'aide de l'algorithme supplémentaire n'est pas effectuée et le terminal (2) poursuit (B, figure 1c) suivant les spécifications EMV et leurs variantes et dérivées.

6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il comprend une étape de consignation (e6, e16) dans un registre spécifique (TVRCSE) mémorisé dans le terminal (2), d'au moins une donnée (b8) dont la valeur représente l'état d'avancement de la procédure d'authentification (CSE) de l'objet (1) portable effectuée à l'aide de l'algorithme supplémentaire.

7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'il comprend une étape de consignation dans un registre spécifique (TVRCSE) mémorisé dans le terminal, d'au moins une donnée (b7) dont la valeur représente le résultat de la mise en oeuvre de la procédure spécifique (CSE) à l'aide de l'algorithme supplémentaire.

8. Procédé selon l'une des revendications 4 à 7, caractérisé en ce qu'il comporte une étape de lecture des données du registre (TVRCSE), une étape de comparaison dans le terminal (2) des données du registre (TVRCSE) avec celles d'un ou plusieurs autres registres (TACCSE, IAC~CSE) de référence mémorisés dans le terminal (2), et une étape de confirmation ou de modification en fonction du résultat de cette comparaison d'un choix effectué par le terminal (2) suivant les spécifications EMV et leurs variantes et dérivées, ce choix correspondant au fait d'effectuer la transaction hors-ligne entre le terminal (2) et l'objet (1) portable, ou de transmettre la transaction en ligne à l'organisme de confiance (3) pour l'objet portable, ou de rejeter la transaction.

9. Procédé selon l'une des revendications 4 à 7, caractérisé en ce qu'il comprend une étape de rejet de la transaction ou de transmission de la transaction en ligne à l'organisme de confiance (3) pour l'objet (1) portable si la mise en oeuvre de la procédure spécifique (CSE) a échoué ou s'il manque des

données (Dcse) pour la mettre en oeuvre ou si ces données (Dcse) ne sont pas authentiques.

10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce qu'il comprend une étape (e30) de vérification pour savoir si le terminal (2) est capable d'aller en ligne avec l'organisme de confiance (3) pour l'objet (1) portable et une étape de confirmation ou de modification en fonction de cette vérification du choix effectué par le terminal lors de la transaction EMV entre l'objet (1) portable et le terminal (2), et correspondant au fait de vouloir effectuer la transaction en ligne avec l'organisme de confiance (3) pour l'objet portable.

11. Procédé selon l'une des revendications 8 à 10, caractérisé en ce que, en fonction du choix qu'il a effectué, le terminal (2) envoie une commande spécifique à l'objet (1) portable lui demandant de générer un cryptogramme correspondant au choix qu'il a effectué ou à la décision qu'il a prise.

12. Procédé selon l'une des revendications 8 à 11, caractérisé en ce qu'il comprend une étape d'analyse effectuée par l'objet portable en fonction du choix effectué par le terminal et de critères mémorisés dans l'objet (1) portable définis par l'organisme de confiance (3) pour l'objet portable et une étape de génération d'un cryptogramme (AAC, ARQC, TC) correspondant à la décision prise par l'objet portable en fonction de son analyse.

13. Procédé selon l'une des revendications 1 à 12, caractérisé en ce qu'il comprend une étape d'envoi par l'objet (1) portable au terminal (2) d'une demande d'identification du pays du terminal (2) et une étape d'envoi par l'objet portable au terminal en fonction de la réponse à l'identification faite par le terminal, d'une ou plusieurs données identifiant la localisation d'un ou plusieurs fichiers (f1, f2, fn) à lire dans l'objet (1) portable par le terminal et comportant notamment les données (Dcse) nécessaires à la mise en oeuvre de la procédure spécifique (CSE).

14. Système comportant un terminal (2) et un objet (2) portable informatisé mettant en oeuvre le procédé selon l'une des revendications 1 à 13, caractérisé en ce qu'il comprend des moyens d'échange entre l'objet (1) portable et le terminal (2) d'informations permettant une authentification de

l'objet (1) portable à l'aide de l'algorithme supplémentaire permettant au terminal (2) de vérifier que l'objet (1) portable dispose d'un secret (SA) déterminé sans en recevoir communication.

15. Système selon la revendication 14, caractérisé en ce que les moyens d'échange sont compatibles avec le protocole défini dans la norme ISO 7816.

16. Système selon la revendication 14 ou 15, caractérisé en ce que l'algorithme supplémentaire utilisé est l'algorithme de Guillou-Quisquater.

17. Système selon la revendication 14 ou 15, caractérisé en ce que l'algorithme supplémentaire utilisé est le second algorithme de Guillou- Quisquater (GQ2).

18. Système selon la revendication 14 ou 15, caractérisé en ce que l'algorithme supplémentaire utilisé est l'algorithme de Fiat-Shamir.

19. Système selon la revendication 14 ou 15, caractérisé en ce que l'algorithme supplémentaire utilisé est l'algorithme de Feige-Fiat-Shamir

20. Système selon la revendication 14 ou 15, caractérisé en ce que l'algorithme supplémentaire utilisé est l'algorithme de Schnorr.

21. Système selon la revendication 14 ou 15, caractérisé en ce que l'algorithme supplémentaire est le protocole PKP pour"Permuted Kernel Problem".

22. Objet (1) portable informatisé utilisé pour la mise en oeuvre du procédé d'authentification selon l'une des revendications 1 à 13, caractérisé en ce qu'il comprend des moyens de mémorisation mémorisant des données spécifiques à la mise en oeuvre de l'algorithme supplémentaire dans la procédure spécifique (CSE) d'authentification lui permettant de s'authentifier auprès du terminal (2) sans avoir à lui communiquer un secret (SA) d'identification.

23. Objet portable informatisé selon la revendication 22, caractérisé en ce qu'il comporte des moyens de mémorisation mémorisant une donnée (D) identifiant le fait qu'il supporte ou non la procédure spécifique (CSE) d'authentification.

24. Objet (1) portable informatisé selon la revendication 22 ou 23, caractérisé en ce qu'il mémorise des données (Da) propres à sa nature et à sa fonction et les données (Dcse) spécifiques à la mise en oeuvre de l'algorithme supplémentaire.

25. Objet (1) portable informatisé selon l'une des revendications 22 à 24, caractérisé en ce qu'il mémorise un ou plusieurs registres (IAC~CSE~Denial, IAC~CSE~online, IAC~CSE~Default) pour la mise en oeuvre de la procédure spécifique (CSE) d'authentification, chacun de ces registres comportant des critères que l'organisme émetteur (3) de l'objet portable définit pour aboutir à une décision du terminal correspondant au rejet de la transaction, à la transmission de la transaction en ligne à l'organisme de confiance (3) pour l'objet portable ou à l'acceptation de la transaction horsligne.

26. Objet (1) portable informatisé selon l'une des revendications 22 à 25, caractérisé en ce qu'il est une carte à puce de type statique.

27. Terminal (2) utilisé pour la mise en oeuvre du procédé d'authentification selon l'une des revendications 1 à 13, caractérisé en ce qu'il comprend notamment des moyens de lecture de données mémorisés dans l'objet (1) portable et des moyens de récupération dans ces données lues par les moyens de lecture, de données (Dcse) spécifiques à la mise en oeuvre de l'algorithme supplémentaire dans la procédure spécifique (CSE) d'authentification lui permettant d'authentifier l'objet (1) portable sans recevoir un secret (SA) de la part de l'objet (1) portable.

28. Terminal (2) selon la revendication 27, caractérisé en ce qu'il comporte des moyens de vérification dans les données (Da) lues par les moyens de lecture que toutes les données nécessaires à la mise en oeuvre de la procédure spécifique (CSE) sont présentes.

29. Terminal selon la revendication 27 ou 28, caractérisé en ce qu'il comporte des moyens de mémorisation mémorisant une pluralité de registres (TVR~CSE, TAC~CSE) spécifiques à la mise en oeuvre de la procédure d'authentification (CSE), le terminal (2) comportant également des moyens de

mise à jour d'un des registres (TVR~CSE) en fonction notamment de l'avancement de la procédure spécifique d'authentification (CSE).