Brevet FR3097347A1 — publié le 20201218

Description Titre de l'invention : Authentification d'un utilisateur d'une carte à puce Domaine technique [0001] La présente invention se situe dans le domaine des mécanismes d'authentification et porte plus particulièrement sur une authentification d'un utilisateur d'une carte à puce, cette authentification faisant appel à un terminal coopérant avec cette carte à puce. Technique antérieure [0002] L'utilisation des cartes à puce (pu cartes à microcircuit) est aujourd'hui largement répandue dans la vie quotidienne. De telles cartes sont par exemple utilisées comme cartes bancaires, cartes de fidélité, cartes d'accès etc., et peuvent prendre divers formats selon leurs utilisations respectives. Les cartes à puce peuvent être conçues pour réaliser divers types de fonctions, notamment pour effectuer des transactions, telles que des transactions financières ou bancaires (transaction de paiement, de transfert...), des transactions d'authentification, etc. [0003] Traditionnellement, une carte à puce est conçue pour coopérer avec un terminal externe au travers de plages de contact accessibles à la surface de la carte. Un terminal externe peut ainsi positionner des broches de contact appropriées sur les plages de contact de la carte afin d'établir une communication par contact. Plus récemment, les cartes à puce sans contact ont connu un essor croissant en raison du gain en rapidité et en simplicité lié aux transactions sans contact. Pour ce faire, les cartes sans contact embarquent une antenne radiofréquence permettant la transmission et la réception de signaux RF avec un terminal externe. [0004] Un effort constant est réalisé dans l'industrie de la carte à puce pour sécuriser l'utilisation des cartes à puces contre la fraude. Une tendance actuelle consiste à sécuriser des transactions réalisées à l'aide d'une carte à puce à partir d'une authentification biométrique. Pour ce faire, certaines cartes à puce sont aujourd'hui dotées d'un capteur d'empreintes biométriques permettant à un utilisateur légitime de s'authentifier. L'acquisition d'empreintes biométriques nécessite d'enregistrer les empreintes biométriques de référence de l'utilisateur légitime lors d'une phase d'initialisation appelée enrôlement. Cette acquisition est une phase critique dans la configuration de la carte à puce et doit donc être réalisée de façon sécurisée afin d'éviter un enrôlement frauduleux d'empreintes biométriques de référence sur la carte. De même, l'acquisition ultérieure d'empreintes biométriques dans l'usage normal de la carte à puce peut présenter un risque sécuritaire. [0005] De façon plus générale, il n'est pas toujours possible pour une carte à puce 2 d'authentifier de façon fiable et sécurisée un utilisateur, notamment en vue d'autoriser ou non la réalisation d'une opération sensible quelle qu'elle soit (acquisition d'une empreinte biométrique, réalisation d'une transaction,...). [0006] TI existe donc aujourd'hui un besoin pour permettre l'authentification de façon fiable et sécurisée d'un utilisateur auprès d'une carte à puce. Les ressources des cartes à puce étant souvent limitées, il est souhaitable de pouvoir authentifier un utilisateur sans que cela ne requière de modifications complexes des cartes à puce actuelles ni de connaissances approfondies de la part des utilisateurs. Un tel mécanisme d'authentification est en particulier nécessaire en vue de permettre à une carte à puce de contrôler l'accès d'un utilisateur à une fonctionnalité quelconque de ladite carte. Exposé de l'invention [0007] A cet effet, la présente invention concerne un premier procédé, mis en oeuvre par une carte à puce coopérant avec un terminal selon une communication sans contact en champ proche ou par contact, le premier procédé comprenant : - réception depuis le terminal d'une première commande ; - en réponse à au moins ladite première commande, envoi au terminal de données de consigne pour présentation à un utilisateur, lesdites données de consigne spécifiant : - N évènements prédéterminés à réaliser par l'utilisateur au moyen d'au moins l'un parmi la carte à puce et le terminal, N étant un nombre entier égal à au moins deux, et - des données temporelles définissant une séquence temporelle selon laquelle les N évènements doivent être réalisés ; - après l'envoi des données de consigne, détection d'évènements ; détermination de savoir si les évènements détectés sont conformes aux données de consigne ; et dans l'affirmative, authentification avec succès d'un utilisateur de la carte à puce. [0008] Selon un mode de réalisation particulier, chacun des N évènements spécifiés dans les données de consignes sont conformes à Fun des types d'évènements suivants : réception d'au moins une commande prédéterminée ou d'au moins une donnée prédéterminée provenant du terminal ; détection d'une mise en communication sans contact en champ proche ou par contact entre la carte à puce et le terminal ; et détection d'un évènement prédéterminé sur une inteiface utilisateur de la carte à puce. [0009] Selon un mode de réalisation particulier, les N évènements spécifiés dans les données 3 de consignes comprennent des évènements selon au moins deux types d'évènements différents parmi ceux définis ci-avant. [0010] Selon un mode de réalisation particulier, les N évènements prédéterminés selon les données de consigne comprennent M mises en communication sans contact en champ proche à réaliser successivement entre la carte à puce et le terminal, M étant un nombre entier tel que M 1, voire même M > 2 (autrement dit, il y a au moins 1, voire au moins 2 mises en communication à réaliser selon les données de consigne DT1). [0093] Selon un mode de réalisation particulier, le module de communication MD26 dont dispose le cas échéant le terminal Ti est configure pour réaliser successivement des mises en communication sans contact en champ proche (notées de façon générale CM) entre le terminal Tl et la carte à puce Cl pour authentifier l'utilisateur UR auprès de la carte à puce Cl. L'authentification est réalisée avec succès si ces mises en communication successives CM sont conformes aux données de consigne DT1. [0094] Le cas échéant, le module de communication MD26 est configure pour réaliser suc- cessivement des mises en communication sans contact en champ proche (ou éventuellement par contact) entre le terminal Tl et la carte à puce Cl de sorte à authentifier l'utilisateur auprès de la carte à puce Cl si les mises en communication sont conformes aux données de consigne DT1. [0095] La configuration et le fonctionnement des modules MD2-MD10 de la carte à puce Cl et des modules MD20-MD26 du terminal Ti apparaîtront plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 4-9. A noter que les modules MD2-MD10 et MD20-MD26 tels que représentés en figures 2-3 respectivement ne constituent que des exemples de mise en oeuvre non limitatifs de l' invention. [0096] La figure 4 représente sous forme d'un diagramme les étapes mises en oeuvre par la carte à puce Cl et le terminal Tl décrits précédemment pour mettre en oeuvre un procédé d'authentification selon un mode de réalisation particulier de l'invention. Plus précisément, la carte à puce Cl et le terminal Tl mettent en oeuvre un premier et un deuxième procédé en exécutant respectivement les programmes d'ordinateur PG1 et PG2. [0097] On suppose qu'un utilisateur UR souhaite s'authentifier auprès de sa carte à puce Cl. Pour ce faire, il utilise son terminal Tl pour interagir avec la carte à puce CI selon le procédé d'authentification de l'invention. Comme déjà indiqué, on suppose dans les exemples qui suivent que le terminal Tl et la carte à puce CI communiquent ensemble selon une communication sans contact en champ proche, de type NFC par exemple, bien que d'autres implémentations soient possibles. Dans la suite de ce document, chaque mise en communication (ou couplage), notée de façon générale CM, entre la carte à puce Cl et le terminal Tl est, sauf indication contraire, réalisée implicitement en mode sans contact en champ proche. [0098] Pour ce faire, dès que le terminal Tl et la carte à puce CI se trouvent à proximité l'un de l'autre, ils établissent ensemble une communication sans contact en champ proche (LI) afin de se coupler et d'interagir ensemble. Le couplage prend fin lorsque la carte à puce Cl et le terminal Tl sont éloignés suffisamment Fun de l'autre. [0099] Comme représenté en figure 4, au cours d'une première mise en communication sans contact en champ proche CM1, le terminal Tl envoie (B2) une première commande CMDI que la carte à puce Cl reçoit à l'étape de réception A2. Cette première commande CMDI peut être de diverses natures selon le cas d'usage. Il peut s'agir par exemple d'une commande RESET selon la norme EMV ou d'une commande de lecture d'un identifiant (ou commande de lecture d'un tag), par exemple de type NFC 16 ou autre. [0100] En réponse à cette commande CMD1, la carte à puce Cl envoie (A4) les données de consigne DT1 stockées dans sa mémoire 24. Le terminal Tl reçoit ces données de consigne DT1 lors d'une étape de réception B4. Comme déjà indiqué, ces données de consigne DT1 définissent une consigne qui doit être présentée à l'utilisateur UR sur le terminal Ti pour réaliser une procédure d'authentification. Dans cet exemple, ces données de consigne DT1 spécifient : N évènements prédéterminés EV1 à EVN (notés collectivement EV) à réaliser par l'utilisateur UR au moyen d'au moins de la carte à puce Cl seule ou au moyen de la carte à puce Cl et du terminal Ti, N étant un nombre entier égal à au moins deux, et des données temporelles TS définissant une séquence temporelle SQ selon laquelle les N évènements EV doivent être réalisés. [0101] Au cours d'une étape de présentation B6, le terminal présente (fournit) ensuite à l'utilisateur UR des instructions INS représentatives des données de consigne DT1 transmises par la carte à puce Cl. La présentation des instructions INS se fait ici via l'interface utilisateur 10 (figure 1). Pour ce faire, le terminal Tl détermine au préalable les instructions INS à partir des données de consigne DNT1 reçues. Il peut réaliser un quelconque traitement pour obtenir les instructions INS à partir des données de consigne DT1 (y compris un déchiffrement si les données de consigne DT1 sont reçues sous forme chiffrée) Selon un exemple particulier, les instructions INS comprennent tout ou partie des données de consigne DT1. On suppose dans cet exemple que les instructions INS sont présentées sur un écran d'affichage faisant partie de l'interface utilisateur 10 du terminal Ti, d'autres implémentations étant toutefois possibles. [0102] A partir des instructions INS reçues, l'utilisateur UR est ainsi informé des évènements (ou opérations) qu'il doit réaliser au moyen de la carte à puce Cl et/ou du terminal Tl pour s'authentifier auprès de la carte à puce Cl. Autrement dit, les instructions INS, représentatives des données de consigne DT1, indiquent des taches (i.e. les évènements prédéterminés EV) que l'utilisateur UR doit réaliser d'une manière prédéfinie dans le temps, c'est-à-dire selon la séquence temporelle SQ définie dans les données temporelles TS. Comme décrit par la suite, la nature des évènements prédéterminés EV à réaliser, ainsi que la séquence temporelle SQ à respecter, peuvent varier selon le cas. [0103] Les données de consigne DT1 peuvent définir des évènements prédéterminés EV que l'utilisateur UR doit exécuter au moyen de la carte à puce Cl seule, ou au moyen du terminal Tl en coopération avec la carte à puce Cl, ou encore une combinaison de ces deux variantes. [0104] Selon un exemple particulier, chacun des N évènements prédéterminés EV spécifiés 17 dans les données de consignes DT1 sont conformes à l'un des types d'évènements suivants : réception par la carte à puce Cl d'au moins une commande prédéterminée ou d'au moins une donnée prédéterminée provenant du terminal Tl ; détection par la carte à puce Cl d'une mise en communication sans contact en champ proche (ou par contact) CM entre la carte à puce Cl et le terminal Tl ; et détection d'un évènement prédéterminé EV sur une interface utilisateur de la carte à puce (par exemple au moyen du capteur biométrique 28 ou de tout autre interface utilisateur de la carte à puce Cl). [0105] Les données de consigne DT1 définissent par exemple une ou des mises en commu- nication CM sans contact en champ proche entre la carte à puce Cl et le terminal T1 que l'utilisateur UR doit déclencher en présentant la carte à puce Cl à proximité du terminal Tl. Selon un exemple particulier, une mise en communication sans contact en champ proche (ou couplage sans contact en champ proche) correspond à une session de communication entre la carte à puce Cl et le terminal T], au cours de laquelle la carte à puce Cl envoie et/ou reçoit au moins une commande ou donnée prédéterminée. D'autres modes de réalisation sont toutefois possibles comme décrit ultérieurement. Ainsi, selon d'autres exemples de réalisation, une mise en communication (couplage) sans contact en champ proche n'implique pas nécessairement l'échange d'une quelconque commande ou donnée entre la carte à puce Cl et le terminal Ti. Comme indiqué par la suite, une mise en communication peut résulter par exemple d'une simple mise sous tension de la carte à puce Cl induite par le terminal Ti se trouvant à proximité, suivie d'une interruption de l'alimentation électrique de la carte à puce Cl sans que cette dernière ait pu envoyer et/ou recevoir une quelconque commande ou donnée. [0106] En rapprochant puis éloignant la carte à puce Cl dans, et hors, du champ de détection du terminal Ti, l'utilisateur UR peut ainsi initier successivement une pluralité de mises en communication CM entre la carte à puce Cl et la terminal Tl. Comme indiqué ci-dessus, chaque mise en communication CM peut par exemple comprendre une ouverture de session et une fin de session de communication, et est ainsi détectable par la carte à puce Cl à partir d'une quelconque commande (ou donnée) prédéterminée reçue du terminal Ti lors de la session en cours. Selon une variante, chaque mise en communication CM est détectée à partir de la mise sous tension et/ou de l'interruption d'une alimentation électrique de la carte à puce Cl (comme décrit ultérieurement). [0107] D'autres types d'évènements prédéterminés EV tels que définis dans les données de consigne DT1 sont toutefois possibles. Par exemple, les données de consigne DTI peuvent définir, en tant qu'évènements à réaliser, une ou des captures biométriques que 18 l'utilisateur doit réaliser en disposant par exemple son doigt (ou toute autre partie de son corps appropriée) sur le capteur biornétrique 28 ou, une ou des mises en contact d'une biométrie avec le capteur biométrique 28. Certains évènements EV peuvent également correspondre à des opérations à réaliser sur le terminal Ti au moyen de l'interface utilisateur (par exemple : activer un bouton, initier une commande vocale, ...). Dans cc cas, le terminal Ti est configure pour indiquer à la carte à puce Cl, via la liaison de communication El , lorsqu'un tel évènement se produit. Les évènements prédéterminés EV tels que définis dans les données de consigne DT1 peuvent comprendre une quelconque combinaison ou sous-combinaison des divers types d'évènements envisagés dans ce document. [0108] En outre, la séquence temporelle SQ telle que définie dans les données de consigne DT1 caractérise comment doivent être exécutés les N évènements EV au cours du temps. Ainsi, les données de consigne DT1 peuvent par exemple demander à l'utilisateur UR de réaliser des évènements prédéterminés EV dans des plages de temps respectives (de durées variables ou fixes) ou en respectant des intervalles de temps respectifs (variables ou fixes) entre chaque évènement. [0109] Les données de consigne DT1 peuvent par exemple requérir que l'utilisateur présente une fois son doigt sur le capteur biométrique 28, puis réalise deux mises en communication sans contact successives en champ proche, et enfin initie l'envoi d'une commande depuis le terminal Tl à la carte à puce Cl d'une manière prédéterminée (activation d'un bouton, déplacement du terminal Ti causant l'envoi (l'une commande sur détection du mouvement. ...), et ce selon une séquence temporelle SQ particulière (par exemple, avec un intervalle de pause entre 2 et 4 secondes entre chaque évènement, ou en indiquant les bornes temporelles de début et fin de chaque plage de temps pendant laquelle une évènement doit se produire). Bien entendu, de nombreuses variantes sont possibles dans le cadre de l'invention. [0110] Selon un mode de réalisation particulier, les N évènements prédéterminés EV tels que spécifiés dans les données de consignes DT 1 comprennent des évènements selon au moins deux types d'évènements différents parmi ceux définis ci-avant. Il est ainsi possible d'augmenter le niveau de sécurité de la procédure d'authentification. Selon un exemple particulier, les données de consigne DT1 définissent au moins une mise en communication CM sans contact en champ proche à réaliser entre la carte à puce Cl le terminal Tl et au moins une opération à réaliser sur une interface utilisateur de la carte à puce C1 (ou sur l'interface utilisateur 10 du terminal Ti). [0111] Les instructions INS sont avantageusement générées par le terminal Ti de sorte à présenter d'une façon efficace et claire les données de consigne DT1 à l'utilisateur UR souhaitant s'authentifier auprès de la carte à puce Cl. [0112] Après présentation (B6) des instructions INS, la carte à puce Cl surveille si des 19 évènements EV sont détectés. Au cours d'une étape de détection A8, la carte à puce Cl détecte ainsi une pluralité d'évènements EV. On suppose par exemple que tout ou partie des évènements EV ainsi détectés correspondent à la réception en provenance du terminal Tl d'une commande respective CMD2 (ou d'une donnée PR) pouvant varier ou non au cours du temps. Selon un exemple particulier, ces commandes CMD2 sont reçues (A8) lors de mises en communication CM sans contact respectives réalisées successivement en champ proche entre la carte à puce Cl et le terminal Tl. Comme déjà indiqué, d'autres implémentations sont toutefois possibles (par exemple, un couplage sans contact en champ proche peut être détecté à chaque mise sous tension de la carte à puce Cl induite par le terminal T I ). [0113] Au cours d'une étape de détermination A10, la carte à puce Cl détermine si les évènements EV ainsi détectés en A8 sont conformes aux données de consigne DT1 stockées dans sa mémoire 24. Pour ce faire, la carte à puce Cl compare chaque évènement EV détecté en A8 avec les évènements prédéterminés EV tels que définis dans les données de consigne DT1 et analyse le déroulement dans le temps des évènements EV détectés en A8 pour déterminer s'ils sont exécutés (ou se produisent) conformément à la séquence temporelle SQ. Si la carte à puce Cl détermine que les évènements EV détectés en A8 concordent avec les évènements prédéterminés EV tels que définis dans les données de consigne DT1 et que les évènements EV détectés se produisent au cours du temps conformément à la séquence temporelle SQ, alors le procédé se poursuit à l'étape d'authentification A14, sinon le procédé se poursuit en Al2. [0114] Au cours de l'étape d'authentification A14, la carte à puce Cl détermine que l'utilisateur UR a réalisé correctement la séquence d'opérations demandée selon les données de consigne DT 1 et, par conséquent, authentifie l'utilisateur UR avec succès. [0115] Selon un exemple particulier, l'utilisateur UR peut ensuite utiliser normalement sa carte à puce Cl. Sur détection (A14) que l'authentification est passée avec succès, la carte à puce Cl peut par exemple autoriser ou activer une quelconque fonctionnalité (ou opération) Fi (A16, figure 4). Selon un exemple particulier, la carte à puce Cl autorise (A16) en tant que fonctionnalité FI l'acquisition de données biométriques sur le capteur biométrique 28. Ces données biométriques peuvent être stockées en tant que données biométriques de référence dans la mémoire de la carte à puce Cl (phase d'enrôlement des données biométriques de l'utilisateur légitime sur la carte à puce Cl). Ainsi, lors d'utilisations ultérieures (pour réaliser une transaction par exemple), la carte à puce Cl peut comparer des données biométriques 30 nouvellement acquises sur le capteur biométrique 28 avec les données biométriques de référence stockées préalablement dans sa mémoire, et en déduire si un utilisateur est authentifié avec succès, ce qui permet de réaliser une authentification biométrique fiable sans que l'intervention du terminal Tl soit à nouveau nécessaire. [0116] En revanche, au cours de l'étape Al2, la carte à puce Cl détermine que l'utilisateur UR n'a pas réalisé la séquence d'opérations demandée conformément aux données de consigne DT1 et, par conséquent, en déduit que l'authentification de l'utilisateur UR a échoué. [0117] Suite à la détection (Al2) de l'échec de l'authentification, la carte à puce Cl peut ainsi bloquer (ou interdire) au cours d'une étape de blocage A18 la mise en oeuvre d'une quelconque fonctionnalité (ou opération), telle que El par exemple, par la carte à puce Cl. [0118] Un utilisateur UR est ainsi capable de s'authentifier de façon efficace et sécurisée auprès de la carte à puce Cl à l'aide du terminal Tl, et ce malgré les ressources généralement limitées par nature de la carte à puce Cl. Ainsi, l'utilisateur peut prendre connaissance des taches à réaliser depuis l'interface utilisateur de son terminal Tl , puis réalise ces taches selon les spécifications de la consigne transmises par la carte à puce Cl. La carte à puce Cl peut alors détecter des évènements se produisant directement sur son interface utilisateur et/ou en coopération avec le terminal Tl, et déterminer, à partir d'une comparaison des évènements détectés avec ce qui est prévu dans la consigne, si l'authentification de l'utilisateur est passée avec succès ou a échoué. On utilise ainsi de façon avantageuse les ressources déportées du terminal pour permettre une authentification auprès de la carte à puce. [0119] La carte à puce Cl peut être configurée pour modifier régulièrement (éventuellement de façon aléatoire) les données de consigne DT1, éventuellement à chaque nouvelle itération du procédé (l'authentification de l'invention avec un terminal externe (Ti ou autre). [0120] Certains terminaux (smartphones ou autres) sont parfois également limités dans les interactions qu'ils sont capables de mettre en oeuvre avec une carte à puce. Ainsi, un terminal peut être limité structurellement et/ou par sa configuration logicielle dans les commandes ou données qu'il est capable d'envoyer à l'extérieur, par exemple selon une communication sans contact en champ proche (ou par contact). Ainsi, certains smartphones sont limités par leur configuration de sorte qu'ils ne peuvent envoyer par communication sans contact en champ proche que des commandes de lecture de tag (ou (l'identifiant), de type NEC ou autre, sur détection de chaque nouvelle mise en communication CM avec une entité externe telle qu'une carte à puce. L'invention permet avantageusement de tirer parti de tels terminaux, y compris lorsqu'ils présentent de telles limitations, pour authentifier malgré tout de façon fiable et sécurisée un utilisateur auprès d'une carte à puce externe au terminal. En réponse à une ou des commandes de lecture de tag provenant du terminal T 1 , la carte à puce Cl peut ainsi être configurée pour envoyer les données de consigne DT1 au terminal T1 et pour 21 vérifier ultérieurement si des évènements conformes à ces données de consigne sont détectés, comme décrit dans ce document selon des modes de réalisation particuliers. [0121] Selon un exemple particulier, les évènements à réaliser selon les données de consigne DT1 comprennent au moins une opération que l'utilisateur UR doit réaliser selon la séquence temporelle SQ en faisant interagir la carte à puce Cl avec le terminal T1, par exemple en couplant et/ou découplant la carte à puce Cl et le terminal Tl. [0122] Selon un exemple particulier, le terminal Tl réalise une authentification de l'utilisateur UR avant de présenter les instructions INS (B6, figure 4). Ainsi, le terminal Tl peut être configure pour réaliser une authentification interne de l'utilisateur, de sorte que la présentation (B6, figure 4) des instructions INS à l'utilisateur UR n'est réalisée qu'après avoir authentifié avec succès l'utilisateur lors de cette authentification interne. Pour ce faire, le terminal Tl peut comprendre un module d'authentification interne configure pour authentifier l'utilisateur selon une quelconque méthode appropriée, telle que par exemple au moyen d'un code secret quelconque, ou par l'acquisition d'une empreinte biométrique. Cette authentification est par exemple réalisée avant l'envoi B2 (figure 4) de la commande CMD1 ou entre les étapes B2 et B6. Le terminal Tl peut éventuellement être configure pour envoyer la commande CMD1 que si cette authentification interne préalable est passée avec succès. Le terminal Tl peut encore être configure pour envoyer dans ou avec la commande CMD1 (B2, figure 4) un indicateur pour indiquer à la carte à puce Cl que l'utilisateur UR a été authentifié avec succès par le terminal Ti, de sorte que la carte à puce CI n'envoie les données de consigne DT1 que si un tel indicateur est reçu au préalable. [0123] Le recours au terminal Ti pour présenter la consigne, et éventuellement aussi pour réaliser tout ou partie des évènements requis dans la consigne, permet de faciliter le procédé d'authentification tout en maintenant un niveau de sécurité élevé. En effet, seul l'utilisateur UR ayant accès au terminal Tl est capable de prendre connaissance des données de consigne et donc d'en déduire les taches à réaliser pour s'authentifier auprès de la carte à puce Cl. [0124] La carte à puce Cl peut être configurée pour envoyer sous forme chiffrée les données de consigne DT1 au terminal Tl, afin de sécuriser encore davantage le procédé d'authentification de l'invention. [0125] Comme déjà indiqué, la nature des évènements prédéterminés à réaliser, leur nombre ou encore la séquence temporelle à respecter pour que l'utilisateur UR s'authentifie avec succès, peuvent varier selon le cas. Des exemples d'implémentation non limitatifs sont décrits ci-après. [0126] Un mode de réalisation particulier est à présent décrit en référence aux figures 5-8. Plus précisément, la carte à puce Cl et le terminal Tl représentés en figures 1-3 mettent en oeuvre un premier et un deuxième procédé en exécutant respectivement les programmes d'ordinateur P01 et P02. [0127] Comme représenté en figure 5, on suppose dans cet exemple que les données de consigne DT1 définissent : des évènements prédéterminés EV1-EVN (notés collectivement EV), comprenant M mises en communication sans contact en champ proche à réaliser successivement entre la carte à puce Cl et le terminal T1, M étant un nombre entier tel que M REVENDICATIONSProcédé mis en oeuvre par une carte à puce coopérant avec un terminal selon une communication sans contact en champ proche ou par contact, le procédé comprenant : - réception depuis le terminal d'une première commande ; - en réponse à au moins ladite première commande, envoi au terminal de données de consigne pour présentation à un utilisateur, lesdites données de consigne spécifiant : - N évènements prédéterminés à réaliser par l'utilisateur au moyen d'au moins l'un parmi la carte à puce et le terminal, N étant un nombre entier égal à au moins deux, et - des données temporelles définissant une séquence temporelle selon laquelle les N évènements doivent être réalisés ; après l'envoi des données de consigne, détection d'évènements ; détermination de savoir si les évènements détectés sont conformes aux données de consigne ; et dans l'affirmative, authentification avec succès d'un utilisateur de la carte à puce. Procédé selon la revendication 1, dans lequel chacun des N évènements spécifiés dans les données de consignes sont conformes à l'un des types d'évènements suivants : réception d'au moins une commande prédéterminée ou d'au moins une donnée prédéterminée provenant du terminal ; détection d'une mise en communication sans contact en champ proche ou par contact entre la carte à puce et le terminal ; et détection d'un évènement prédéterminé sur une interface utilisateur de la carte à puce. [Revendication 3] Procédé selon la revendication 2, dans lequel les N évènements spécifiés dans les données de consignes comprennent des évènements selon au moins deux types d'évènements différents parmi ceux définis dans la revendication 2. 33 [Revendication 4] Procédé selon l'une quelconque des revendications 1 à 3, dans lequel dans lequel les N évènements prédéterminés selon les données de consigne comprennent M mises en communication sans contact en champ proche à réaliser successivement entre la carte à puce et le terminal, M étant un nombre entier tel que M