Brevet FR3051579A1 — publié le 20171124

Arrière-plan de l'invention La présente invention se situe dans le domaine général des dispositifs électroniques et concerne plus particulièrement un dispositif électronique, tel qu'une carte à puce par 10 exemple, configurée pour coopérer avec un terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple. L'invention s'applique plus particulièrement, mais de manière non exclusive, aux cartes à puce (ou cartes à microcircuit), conformes par exemple à la norme 1S07816. L'invention vise notamment la sécurisation d'une carte à puce fonctionnant selon le 15 protocole EMV (pour « Europay Mastercard Visa »). De manière générale, une carte à puce est conçue pour communiquer avec un dispositif externe à cette carte, autrement appelé terminal ou lecteur. Ces cartes permettent d'effectuer divers types de transactions, telles que par exemple des transactions de paiement, de prélèvement ou encore d'authentification du porteur. Les 20 cartes à puce pour applications bancaires (carte de crédit, carte de débit etc.), par exemple, sont aptes à coopérer avec des terminaux de paiement ou des distributeurs automatiques de billets (DAB) pour réaliser divers opérations financières. EMV est le protocole standardisé utilisé aujourd'hui majoritairement dans le monde pour sécuriser notamment les transactions de paiement effectuées par des cartes à puce. 25 Le protocole EMV a été conçu pour diminuer les risques de fraudes lors d'une transaction de paiement en permettant notamment l'authentification à la fois de la carte à puce et de son porteur. Ce processus d'authentification fait appel à une combinaison de cryptogrammes (ou clés cryptées) et de signatures numériques et nécessite éventuellement la saisie d'un code secret (appelé communément code PIN) par le porteur 30 de la carte. Suivant le type de carte utilisé, la situation, ou encore le montant considéré, une carte EMV peut fonctionner en ligne ou hors ligne. En mode en ligne, la carte EMV peut communiquer, via le lecteur, avec l'entité émettrice correspondante (la banque à l'origine de la carte, par exemple) afin de vérifier en particulier que la transaction en cours est 35 légitime. En revanche, si la carte EMV fonctionne en mode hors ligne, celle-ci applique des critères de vérification préenregistrés pour décider si la transaction doit être autorisée ou refusée. 3051579 2 La figure 1 représente un exemple de mise en oeuvre d'une transaction de paiement conforme au protocole EMV, à l'aide d'une carte à puce EMV 100. Certains aspects d'une transaction EMV ont été omis par souci de simplicité. Lors de la mise en oeuvre d'une transaction, le protocole EMV s'articule en trois 5 phases, des variantes étant toutefois possibles. Lors d'une première phase destinée à authentifier la carte à puce 100 utilisée, le terminal 110 et la carte 100 s'échangent un certain nombre de messages dont un message RESET (RST) en S2 puis une réponse ATR en S4. En S6, le porteur de la carte sélectionne via le terminal 110 le mode de transaction souhaité, déclenchant ainsi l'envoi d'une commande « SELECT» à la carte 100 afin d'initier le début de la transaction EMV. Une fois la phase d'authentification de carte achevée, le protocole EMV procède à une phase d'authentification (non représentée) du porteur de la carte 100. Le terminal 110 détermine le procédé d'authentification du porteur à appliquer et détermine en particulier si la transaction doit être effectuée en mode avec vérification de code ou en mode sans vérification de code. Si le mode avec vérification de code est sélectionné, la carte à puce 100 vérifie la validité du code PIN saisi par le porteur sur le terminal 110. Si en revanche le mode sans vérification de code est sélectionné, aucune vérification de code PIN n'est réalisée. Une fois la phase d'authentification du porteur achevée, le protocole EMV initie la phase de vérification de la transaction. Pour ce faire, le terminal 110 envoie (S8) à la carte à puce 100 une première commande APDU dite GENERATE AC ou GAC (notée ici GAC1). Cette commande bien connue comprend des informations sur la transaction en cours telles que le montant de la transaction, la devise utilisée, le type de transaction, etc. La carte EMV réalise (S9) alors une vérification de la transaction selon des critères de vérification prédéfinis puis envoie (S10), en réponse au GAC1, un cryptogramme (ou certificat cryptographique) comprenant un code d'authentification de message (ou MAC pour « Message Authentification Code» en anglais). La réponse de la carte 100 dans le message ARQC dépend notamment du paramétrage de la carte effectué par l'entité émettrice 120 (dit « émetteur ») de ladite carte. Si le mode en ligne est choisi, comme représenté dans l'exemple de la figure 1, la carte à puce 100 envoie en S10 un message de type ARCQ (« Autorisation Request Cryptogram ») indiquant que la carte 100 souhaite poursuivre la transaction en ligne avec, par exemple, un serveur distant de l'émetteur 120 (mode en ligne). Le cryptogramme ARQC est transmis par le terminal 110 à l'émetteur 120 qui peut ainsi réaliser (S13) un certain nombre de vérifications afin de s'assurer que la transaction est valide. L'émetteur 120 envoie (S14) ensuite, en réponse au message ARCQ reçu, un message crypté de type ARPC indiquant la décision de l'émetteur 120. Ce message ARPC est transmis par le terminal 110 à la carte 100 en S16. 3051579 3 La carte 100 détermine si elle accepte ou non la transaction à partir de la réponse ARPC reçue en S16. Si la carte 100 accepte la transaction, celle-ci envoie (S18) en réponse un cryptogramme de type TC (transaction acceptée) au terminal 110. Dans le cas contraire, la carte 100 envoie (S18) un cryptogramme de type AAC indiquant le refus de 5 la transaction. La réalisation en ligne d'une transaction permet donc de mettre en oeuvre des mécanismes de sécurité permettant d'identifier des situations à risque et de déclencher une réponse sécuritaire appropriée. L'émetteur de la carte à puce peut par exemple détecter un comportement anormal lors d'une transaction en ligne et décliner la 10 transaction ou déclencher des contrôles de vérification supplémentaires. Les cartes EMV actuelles sont généralement configurées de façon à pouvoir réaliser un certain nombre de transaction hors ligne, de sorte qu'il n'est pas possible pour l'entité émettrice de la carte d'effectuer de contrôle de sécurité à distance au cours de la transaction hors ligne. Certaines cartes EMV sont par exemple configurées pour 15 fonctionner hors ligne si le montant de la transaction en cours n'atteint pas un montant minimum prédéfini. Les cartes à puce, EMV notamment, sont donc particulièrement vulnérables aux attaques et comportement malveillants (ou anormaux) lorsqu'elles fonctionnent hors ligne. En cas par exemple de vol d'une carte EMV, l'auteur du vol peut alors réaliser de 20 multiples transactions successives portant toutes sur des montants modérés de sorte à ne pas déclencher le fonctionnement en ligne de la carte et ainsi échapper à la vigilance de l'émetteur de la carte. Il existe donc aujourd'hui un besoin pour un mécanisme de sécurité permettant de protéger efficacement les cartes à puce, par exemple de type EMV, contre les 25 comportements anormaux et/ou suspects survenant notamment lors des transactions hors ligne. Une sécurisation renforcée est en particulier nécessaire pour protéger les cartes à puce contre les utilisations frauduleuses, en cas de vol par exemple. Un besoin existe plus généralement pour mieux contrôler l'utilisation d'un dispositif électronique tel qu'une carte à puce par exemple (de type EMV ou autre), y compris lorsque ce dispositif fonctionne 30 hors ligne pour mettre en oeuvre une transaction. Objet et résumé de l'invention A cet effet, la présente invention concerne un procédé de sécurisation mis en oeuvre par un dispositif électronique, ledit procédé comprenant : 35 détermination d'un point courant dans le temps au cours duquel une transaction courante est ou doit être mise en oeuvre par le dispositif électronique ; sélection, dans un fichier d'historisation dans lequel est enregistrée au moins une transaction passée, de chaque transaction mise en oeuvre par ledit dispositif 3051579 4 électronique dans une période de temps prédéfinie terminant au point courant dans le temps ; analyse de risque, à partir d'au moins une donnée d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction 5 sélectionnée, pour détecter si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie ; et dans l'affirmative, déclenchement d'au moins une opération de sécurisation du dispositif électronique en réponse à ladite transaction courante La présente invention permet avantageusement de protéger de façon efficace les 10 dispositifs électroniques, notamment les cartes à puce (de type EMV ou autre), configurés pour coopérer avec un terminal pour mettre en oeuvre une transaction (une transaction bancaire ou autre). L'invention permet en particulier de sécuriser de tels dispositifs électroniques contre les comportements anormaux ou suspects survenant lors des transactions hors ligne. 15 Selon un mode de réalisation particulier, le point courant dans le temps comprend au moins l'un parmi la date courante et l'heure courante de la transaction courante. Selon un mode de réalisation particulier, la détermination du point courant comprend une réception, depuis un terminal avec lequel coopère le dispositif électronique, d'une donnée temporelle représentative du point courant dans le temps. 20 Selon un mode de réalisation particulier, ladite sélection comprend un calcul du point dans le temps du début de la période de temps prédéfinie, à partir du point courant dans le temps et d'une durée prédéfinie attribuée à ladite période de temps prédéfinie, chaque transaction sélectionnée étant postérieure au point dans le temps du début de la période de temps prédéfinie. 25 Selon un mode de réalisation particulier, lors de ladite sélection, le dispositif électronique : détermine, à partir du fichier d'historisation, en tant que transaction de référence, la transaction la plus récente dans la période de temps prédéfinie qui satisfait au moins une première condition prédéfinie ; et 30 sélectionne uniquement chaque transaction mise en oeuvre par ledit dispositif électronique postérieurement à ladite transaction de référence dans la période de temps prédéfinie. Selon un mode de réalisation particulier, ladite au moins une première condition prédéfinie comprend au moins l'une des conditions suivantes : 35 la transaction de référence est une transaction dite « en ligne » ayant été réalisée en coopération avec une entité émettrice du dispositif électronique ; et 3051579 5 - la transaction de référence est une dite transaction en ligne qui a été authentifiée avec succès par l'entité émettrice du dispositif électronique. Selon un mode de réalisation particulier, lors de ladite sélection, le dispositif électronique filtre les transactions enregistrées dans le fichier d'historisation pour ne 5 sélectionner que chaque transaction satisfaisant au moins une deuxième condition prédéfinie. Selon un mode de réalisation particulier, la deuxième condition prédéfinie comprend une condition sur le type du terminal avec lequel le dispositif électronique a coopéré lors de ladite transaction. 10 Selon un mode de réalisation particulier, lors de ladite analyse de risque, le dispositif électronique détecte si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie à partir d'au moins l'un parmi : - le nombre de transactions sélectionnées ; et - le montant cumulé de chaque transaction sélectionnée. 15 Selon un mode de réalisation particulier, dans lequel, lors de ladite analyse de risque, le dispositif électronique détecte qu'une utilisation anormale s'est produite pendant ladite période de temps prédéfinie si au moins l'une des troisièmes conditions prédéfinies suivantes est satisfaite : - le nombre de transactions sélectionnées lors de ladite sélection atteint une 20 première valeur seuil prédéfinie ; et le montant cumulé de chaque transaction sélectionnée lors de ladite sélection atteint une deuxième valeur seuil prédéfinie. Selon un mode de réalisation particulier, ladite au moins une opération de sécurisation comprend au moins l'un parmi : 25 envoi d'un message informant de ladite utilisation anormale détectée ; - modification d'au moins un paramètre de fonctionnement du dispositif électronique ; enregistrement, dans le fichier d'historisation, d'une donnée de sécurité représentative de ladite utilisation anormale détectée ; et 30 refus de mettre en oeuvre ladite transaction courante. Selon un mode de réalisation particulier, le dispositif électronique est une carte à puce. Dans un mode particulier de réalisation, les différentes étapes du procédé de sécurisation sont déterminées par des instructions de programmes d'ordinateurs. 35 En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations (ou support d'enregistrement), ce programme étant susceptible d'être mis en oeuvre dans un dispositif électronique tel qu'une carte à puce, ce programme 3051579 6 comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de sécurisation tel que défini ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code 5 objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations (ou support d'enregistrement) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 10 Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. 15 D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le 20 programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. L'invention concerne également un dispositif électronique comprenant : un module de détermination pour déterminer un point courant dans le temps au cours duquel une transaction courante est ou doit être mise en oeuvre par le 25 dispositif électronique ; un module de sélection pour sélectionner, dans un fichier d'historisation dans lequel est enregistrée au moins une transaction passée, chaque transaction mise en oeuvre par ledit dispositif électronique dans une période de temps prédéfinie terminant au point courant dans le temps ; 30 un module d'analyse de risque pour détecter, à partir d'au moins une donnée d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction sélectionnée, si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie ; et un module de sécurisation configure, en cas de résultat positif de ladite détection 35 par le module d'analyse de risque, pour déclencher une opération de sécurisation du dispositif électronique en réponse à ladite transaction courante. Selon un mode de réalisation particulier, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut 3051579 7 correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Selon un mode de réalisation particulier, le dispositif électronique est une carte à puce, de type EMV par exemple. Dans un exemple particulier, la carte à puce est 5 conforme à la norme ISO 7816. Selon un mode de réalisation particulier, le dispositif électronique comprend une mémoire dans laquelle est enregistré le fichier d'historisation. On notera que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de sécurisation de l'invention ainsi que les avantages associés 10 s'appliquent de façon analogue au dispositif électronique de l'invention. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des 15 exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: - la figure 1 déjà décrite représente, de manière schématique, une transaction mise en oeuvre selon le protocole EMV ; les figures 2A et 2B représentent schématiquement un premier mécanisme de sécurisation d'une carte à puce EMV ; 20 - la figure 3 représente schématiquement la structure d'une carte à puce conforme à un mode de réalisation particulier de l'invention ; la figure 4 représente schématiquement des modules mis en oeuvre dans la carte à puce de la figure 3, selon à un mode de réalisation particulier de l'invention ; 25 la figure 5 représente, sous forme d'un organigramme, les étapes d'un procédé de sécurisation selon un mode de réalisation particulier de l'invention ; la figure 6 représente un fichier d'historisation selon un mode de réalisation particulier de l'invention ; - la figure 7 représente schématiquement des transactions mises en oeuvre au fil 30 du temps par la carte à puce de la figure 3, selon un exemple de réalisation particulier ; et la figure 8 représente, sous forme d'un organigramme, les étapes d'un procédé de sécurisation selon un mode de réalisation particulier de l'invention. 35 Description détaillée de plusieurs modes de réalisation Comme indiqué précédemment, la présente invention concerne les dispositifs électroniques, tels que les cartes à puce par exemple, configurés pour coopérer avec un terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple. 3051579 8 L'invention porte plus particulièrement sur la sécurisation des cartes à puce configurées, en particulier lorsque celles-ci sont configurées pour traiter une transaction hors ligne comme expliqué précédemment. Les figures 2A et 2B illustrent un premier mécanisme de sécurisation d'une carte à 5 puce 130 de type EMV. Dans cet exemple, la carte à puce 130 est configurée pour calculer le montant cumulé de transactions TR qu'elle a réalisées avec succès lors d'une période de temps fixe CL, appelée « cycle », puis pour vérifier si ce montant cumulé atteint une valeur seuil maximale. Cette période de temps CL débute à une position (ou point) fixe DRef dans le temps, dite position de référence dans le temps, correspondant 10 par exemple à la date d'une transaction TR1 donnée. La période de temps CL se termine également à une position fixe DF dans le temps. Dans l'exemple illustré en figure 1A, la carte EMV 130 vérifie, au cours de la transaction TR4, le montant cumulé des transactions TRI, TR2 et TR3 réalisées précédemment au cours du même cycle CL, ainsi que le montant de la transaction TR4 en 15 cours. Si ce montant cumulé atteint au moins la valeur seuil maximale, la carte 130 demande par exemple à poursuivre en mode en ligne. Par la suite, lorsque la carte 130 détecte qu'une nouvelle transaction se produit après l'instant DF, elle réinitialise le point de référence DRef afin d'initier un nouveau cycle de temps CL lui aussi fixe dans le temps. Cette technique présente toutefois un inconvénient en ce qu'il n'est pas toujours 20 possible de détecter notamment une augmentation importante, potentiellement anormale, des montants des transactions. Comme illustré en figure 2B, on suppose par exemple que la carte à puce 130 est volée à l'instant V et que l'auteur du vol réalise des transactions successives TR1 - TR5 dans un intervalle de temps relativement restreint. Dans l'hypothèse où le montant de 25 chaque transaction reste inférieur au seuil maximal autorisé en mode hors ligne, il n'est pas certain que la carte 130 soit capable de détecter le comportement anormal résultant du vol, et ce malgré le mécanisme de sécurité décrit en référence à la figure 2A. La figure 2B illustre un exemple dans lequel la carte 130 réalise les transactions TR1 et TR2 lors d'un premier cycle CL1 puis initie un nouveau cycle CL2 au cours duquel elle 30 réalise les transactions TR3 - TR5. Au cours de la transaction TR5, par exemple, la carte à puce 130 vérifie le montant cumulé des transactions TR3, TR4 et TR5 incluses dans le cycle CL2 mais ne prend pas en compte les transactions TR1 et TR2 du fait que ces dernières ont été réalisées lors du cycle précédent CL1. La distribution dans le temps des transactions TR1 - TR5 sur deux cycles distincts CL1 - CL2 augmente ainsi les risques 35 que ces transactions hors lignes ne soient pas identifiées par la carte 130 comme constituant un comportement anormal ou suspect. L'invention propose de palier notamment ces inconvénients à l'aide d'un mécanisme de sécurité permettant de détecter efficacement des comportements anormaux ou 3051579 9 suspects, y compris lorsque la carte à puce fonctionne en mode hors ligne, de sorte qu'une réponse sécuritaire appropriée puisse être apportée si nécessaire. Selon différents modes de réalisation, le procédé de l'invention, mis en oeuvre par un dispositif électronique tel qu'une carte à puce par exemple, comprend les étapes 5 suivantes : détermination d'un point courant dans le temps au cours duquel une transaction courante est ou doit être mise en oeuvre par le dispositif électronique ; sélection, dans un fichier d'historisation dans lequel est enregistrée au moins une transaction passée, de chaque transaction mise en oeuvre par ledit dispositif électronique dans une période de temps prédéfinie terminant au point courant dans le temps ; analyse 10 de risque, à partir d'au moins une donnée d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction sélectionnée, pour détecter si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie ; et, dans l'affirmative, déclenchement d'une opération de sécurisation du dispositif électronique en réponse à ladite transaction courante. 15 L'invention porte également sur un tel dispositif électronique apte à mettre en oeuvre un procédé de sécurisation comme défini ci-dessus. D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. Dans le présent exposé, des exemples de mises en oeuvre de l'invention sont décrits 20 en relation avec une carte à puce de type EMV. On comprend que l'invention ne se limite par exclusivement aux cartes EMV mais s'applique plus généralement à tout dispositif électronique configuré pour mettre en oeuvre une transaction, y compris des dispositifs autre que des cartes à puce, ce dispositif pouvant utiliser le standard EMV ou d'autres standards de transaction. 25 Dans un exemple particulier, le dispositif électronique de l'invention est une carte à puce conforme à la norme ISO 7816. A noter également que la notion de transaction est ici entendue au sens large et comprend par exemple, dans le domaine bancaire, aussi bien une transaction de paiement ou de transfert que d'une consultation d'un compte bancaire sur un terminal 30 bancaire. Les divers modes de réalisation de l'invention sont ici décrits dans le cadre d'une carte de paiement configurée pour réaliser des transactions bancaires. On comprendra que d'autres types de transactions ou opérations sont envisageables dans le cadre de l'invention. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures 35 portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. 3051579 10 La figure 3 représente, de manière schématique, la structure d'une carte à puce CD, conforme à un mode de réalisation particulier de l'invention. On comprendra que certains éléments généralement présents dans une carte à puce ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la 5 présente invention. A noter également que la carte à puce CD représentée en figure 3 ne constitue qu'un exemple de réalisation, d'autres mises en oeuvre étant possibles dans le cadre de l'invention. L'homme du métier comprendra en particulier que certains éléments de la carte à puce CD ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en oeuvre l'invention. 10 La carte à puce CD est configurée pour coopérer avec un terminal (ou lecteur) T afin de réaliser une transaction TR, telle qu'une transaction financière ou bancaire (transaction de paiement ou autre) dans le cas présent. Le terminal T est configuré pour faire l'interface entre la carte à puce CD et un serveur distant SV. Dans le cas présent, le serveur SV est un serveur de l'entité émettrice 15 EM (i.e., une institution bancaire par exemple) de la carte à puce CD. Dans cet exemple, la carte CD est apte à communiquer, via le terminal T, avec le serveur distant SV afin de mettre en oeuvre, selon le protocole EMV, une transaction dite « en ligne », c'est-à-dire impliquant un échange avec l'émetteur EM comme déjà expliqué ci-avant. Plus précisément, la carte à puce CD comprend dans cet exemple des contacts 20 externes 4 aptes à coopérer avec le lecteur T, au moins un processeur 6, une mémoire volatile réinscriptible (de type RAM) 8 et une mémoire non volatile réinscriptible 10 (de type Flash par exemple). La mémoire 10 constitue dans un cet exemple un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le la 25 carte à puce C2, et sur lequel est enregistré un programme d'ordinateur PG conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG comporte des instructions pour l'exécution des étapes d'un procédé de sécurisation selon un mode de réalisation particulier. Les principales étapes de ce procédé sont représentées, dans des modes de réalisation particuliers de l'invention, sur les figures 5 et 8 décrites 30 ultérieurement. Dans un exemple particulier, la carte à puce CD est conforme à la norme ISO 7816. Dans ce cas, les contacts externes 4 présentent des caractéristiques conformes à cette norme. On comprendra toutefois que d'autres modes de réalisation sont possibles. La carte à puce CD peut par exemple coopérer avec le lecteur T en mode sans contact via 35 une antenne RF intégrée dans la carte CD. Toujours dans l'exemple considéré ici, un fichier d'historisation LG (appelé aussi « Log » en anglais) et au moins un critère (ou paramètre) CR prédéfini sont enregistrés dans la mémoire non volatile réinscriptible 10 de la carte CD. 3051579 11 Dans cet exemple, au moins une transaction TR mise en oeuvre dans le passé par la carte à puce CD est enregistrée dans le fichier d'historisation LG. En association avec chaque transaction TR, au moins une donnée d'historisation DLG est enregistrée dans le fichier d'historisation LG. Une donnée d'historisation DLG est par exemple une donnée de 5 transaction caractérisant la transaction TR correspondante. Ce fichier d'historisation LG permet à la carte CD de garder en mémoire des données DLG utiles concernant les transactions qu'elle réalise, ces informations pouvant ensuite si besoin être consultées, traitées et/ou envoyées par la carte CD. Un exemple particulier d'un tel fichier d'historisation LG dans lequel sont enregistrées 10 des transactions TR (et, plus particulièrement, des données d'historisation associées à ces transactions) est décrit ultérieurement en référence à la figure 6. Les données d'historisation DLG pouvant être enregistrées dans le fichier d'historisation LG comprennent par exemple au moins l'un parmi : un identifiant de transaction ID, un point dans le temps PT (par exemple une date et/ou une heure) caractérisant à quel moment la 15 transaction a été réalisée, un montant MT de la transaction, une donnée d'historisation DN1 indiquant si la transaction a été réalisée en ligne ou hors ligne, une donnée d'historisation DN2 indiquant si l'authentification (ou validation) en ligne par l'émetteur EM a été passée avec succès dans le cas d'une transaction en ligne, et une donnée d'historisation DN3 indiquant le type de terminal T ayant coopéré avec la carte CD lors de 20 la transaction. Parmi les types de terminaux T possibles, on peut citer par exemple les distributeurs automatiques de billets (ou DAB) et les terminaux de paiement, d'autres types de terminaux étant possibles. Par ailleurs, le ou les critères CR enregistrés dans la mémoire 10 peuvent comprendre au moins un critère de sélection CR1 et/ou au moins un critère d'analyse CR2. Les critères 25 de sélection et d'analyse CR1, CR2 configurent, le cas échéant, la manière dont la carte met en oeuvre le procédé de l'invention, comme expliqué ultérieurement. Dans l'exemple représenté en figure 3, les critères CR enregistrés dans la mémoire 10 comprennent deux conditions prédéfinies CD1 et CD2 constituant chacune un critère de déclenchement CR1, ainsi qu'une condition CD3 constituant un critère d'analyse CR2. Comme déjà 30 indiqué, d'autres exemples de réalisation sont possibles dans le cadre de l'invention, le nombre et la nature des critères de déclenchement et des critères d'analyse notamment pouvant varier selon le cas d'usage. Les critères CR et le fichier d'historisation LOG seront décrits plus en détail ci-après selon un exemple de réalisation particulier en référence aux figures 4-9. 35 Dans un mode de réalisation particulier, le processeur 6 piloté par le programme d'ordinateur PG, met en oeuvre un certain nombre de modules représentés en figure 4, à savoir : un module de détermination MD2, un module de sélection MD4, un module d'analyse MD6 et un module de sécurisation MD8. 3051579 12 Dans cet exemple particulier, le module de détermination MD2 est configuré pour déterminer un point (ou position) courant dans le temps, noté PC, au cours duquel une transaction courante est, ou doit être, mise en oeuvre par la carte à puce CD. Par « point courant dans le temps », on entend un instant donné dans le temps où une transaction 5 courante est, ou doit être, mise en oeuvre par la carte à puce CD. Un point dans le temps peut être défini par exemple par une date et/ou une heure, et plus généralement par toutes données temporelles permettant de définir une position donnée dans le temps. Différentes méthodes peuvent être utilisées pour permettre à la carte CD de déterminer le point courant PC dans le temps au cours duquel une transaction courante 10 est, ou doit être, mises en oeuvre par la carte CD. Dans un exemple décrit plus en détail ultérieurement, le module de détermination MD2 détermine le point courant PC dans le temps à partir d'une donnée temporelle reçue, provenant par exemple du terminal T. En variante, la carte à puce CD comprend une unité de calcul de la date et/ou de l'heure courante. 15 Dans cet exemple particulier, le module de sélection MD4 est configuré pour sélectionner, dans le fichier d'historisation LG dans lequel est enregistrée au moins une transaction TR passée, chaque transaction TR mise en oeuvre la carte à puce CD dans une période (ou fenêtre) de temps prédéfinie (notée PD) terminant au point courant dans le temps PC. La période de temps PD ayant une durée fixe, elle se déplace dans le temps de 20 sorte à ce qu'elle se termine toujours au point courant PC dans le temps déterminée par le module de détermination MD2. Autrement dit, la période de temps prédéfinie PD est une période de temps glissante dont la borne de fin est définie par le point courant PC dans le temps déterminé par le module de détermination MD2. A chaque fois qu'un nouveau point courant PC dans le temps est déterminé par le module de détermination 25 MD2, la période de temps PD glisse dans le temps de sorte à ce qu'elle se termine toujours par le point courant PC. Des exemples de réalisation seront décrits ultérieurement en référence notamment à la figure 6. Dans un exemple particulier, le module de sélection MD4 est configuré pour sélectionner, parmi les transactions TR enregistrées dans le fichier d'historisation LG, 30 toutes les transactions TR qui ont été mises en oeuvre dans la période de temps prédéfini PD. Dans un exemple particulier, le module de sélection MD4 est configuré pour sélectionner, parmi les transactions TR enregistrées dans le fichier d'historisation LG, les transactions TR qui ont été mises en oeuvre dans la période de temps prédéfini PD et qui 35 respectent en outre au moins un critère (ou condition) de sélection prédéfini CR1. Ces critères de sélection CR1 sont par exemple enregistrés dans la mémoire 10 de la carte CD. Comme déjà indiqué, la figue 3 représente un exemple particulier où les critères de sélection CR1 comprennent deux conditions CD1 et CD2. 3051579 13 Le module d'analyse de risque MD6 est configuré pour détecter, à partir d'au moins une donnée d'historisation DLG enregistrée dans le fichier d'historisation LG en association avec chaque transaction TR sélectionnée par le module de sélection MD4, si une utilisation anormale (ou suspecte) de ladite carte CD s'est produite pendant ladite période 5 de temps prédéfinie PD. On entend ici par « utilisation anormale », toute utilisation de la carte à puce CD jugée, selon au moins un critère d'analyse prédéfini, comme étant potentiellement à risque, frauduleuse ou anormale. Toujours dans cet exemple, le module de sécurisation MD8 est configuré, en cas de 10 résultat positif de la détection par le module d'analyse de risque MD6 (c'est-à-dire si une utilisation anormale de la carte CD est détectée par le module d'analyse MD6), pour déclencher au moins une opération de sécurisation de la carte à puce CD en réponse à la transaction courante TR. Chaque opération de sécurisation est configurée pour sécuriser la carte à puce CD en réponse à la transaction courante TR. Des exemples de telles 15 opérations sont décrits ci-après en référence aux figures 5-9. Les étapes réalisées par la carte à puce CD lors d'un procédé de sécurisation selon un mode de réalisation particulier sont à présent décrites en référence à la figure 5. Pour ce faire, la carte à puce CD exécute le programme d'ordinateur PG. On suppose ici que la carte à puce CD a initié, en coopération avec le terminal T, le 20 traitement d'une transaction TR, dite transaction courante. Selon une variante, la transaction TR courante n'a pas encore été initiée. Dans cet exemple, la transaction TR est conforme au protocole EMV. Au cours d'une étape S30 de détermination, la carte à puce CD détermine un point courant PC dans le temps au cours duquel la transaction courante TR est, ou doit être, 25 mise en oeuvre par la carte à puce CD. Ce point courant PC comprend par exemple au moins l'un parmi la date (dite date courante) et l'heure (dite heure courante) de la transaction courante. En S32, la carte à puce CD sélectionne, dans le fichier d'historisation LG dans lequel est enregistrée au moins une transaction TR passée, chaque transaction TR mise en 30 oeuvre par la carte à puce CD dans une période de temps prédéfinie PD terminant au point courant PC dans le temps. Comme déjà indiqué, cette période PD est une fenêtre de temps glissante, de durée prédéfinie, dont la borne de fin est définie par la position courante dans le temps PC. Dans un exemple particulier, le point courant PC dans le temps est défini par la date 35 courante DC = [16 février 2016] et l'heure courante HC = [16.00], et la durée de la période de temps PD est fixée à 30 jours. Comme expliqué par la suite, la durée de la période de temps PD peut notamment être adaptée selon la configuration souhaitée au vu 3051579 14 du type d'évènements ou de comportements que l'on souhaite surveiller au niveau de la carte à puce CD. La carte à puce CD réalise ensuite en S34 une analyse de risque (ou une analyse de transaction), à partir d'au moins une donnée d'historisation DLG enregistrée dans le 5 fichier d'historisation LG en association avec chaque transaction TR sélectionnée en S32, pour détecter si une utilisation anormale (ou suspecte) de la carte à puce CD s'est produite pendant la période de temps prédéfinie PD. En S34, la carte à puce CD détecte par exemple si une utilisation anormale de ladite carte CD s'est produite pendant la période de temps PD prédéfinie à partir d'au moins l'un parmi : 10 le nombre de transactions TR sélectionnées en S32 ; et le montant cumulé (c.-à-d. le total des montants MT) de chaque transaction TR sélectionnée en S32. Par exemple, lors de cette analyse de risque S34, la carte à puce CD détecte qu'une utilisation anormale s'est produite pendant la période de temps prédéfinie PD si au moins 15 l'une des conditions prédéfinies suivantes est satisfaite : le nombre de transactions sélectionnées lors de la sélection S32 atteint au moins une première valeur seuil prédéfinie ; et - le montant cumulé de chaque transaction TR sélectionnée lors de la sélection S32 atteint au moins une deuxième valeur seuil prédéfinie. 20 Si une utilisation anormale est détectée en S34, la carte à puce CD déclenche en S36 au moins une opération de sécurisation de la carte à puce CD en réponse à la transaction TR courante. Chaque opération de sécurisation vise à sécuriser la carte à puce CD vis-à-vis de la transaction courante TR, et plus généralement, vis-à-vis de l'utilisation faite de la carte à 25 puce CD sur la période de temps PD. Le nombre et la nature de ces opérations de sécurisation peuvent varier selon le cas d'usage. Selon un mode de réalisation particulier, ladite au moins une opération de sécurisation S36 comprend au moins l'un quelconque parmi : - envoi d'un message (par exemple au terminal T et/ou au serveur SV) 30 informant de ladite utilisation anormale détectée en S34 ; - modification d'au moins un paramètre de fonctionnement de la carte à puce CD enregistrement, dans le fichier d'historisation LG, d'une donnée de sécurité représentative de ladite utilisation anormale détectée en S34 ; et 35 refus de mettre en oeuvre la transaction TR courante. La nature du ou des paramètres de fonctionnement PR à modifier le cas échéant en S36 peut varier selon le cas. D'une manière générale, un paramètre de fonctionnement PR configure la manière dont la carte à puce CD traite une transaction TR avec un 3051579 15 terminal extérieur, tel que le lecteur T dans cet exemple. Le paramètre de fonctionnement PR à modifier peut, par exemple, être un compteur enregistré dans la carte à puce CD. Un tel compteur peut par exemple représenter un nombre de transactions hors ligne déjà réalisées par la carte à puce CD, ou encore le montant cumulé de transactions hors ligne 5 déjà réalisées par la carte à puce CD. Le paramètre PR peut par ailleurs porter sur une valeur seuil d'un tel compteur. La modification du paramètre PR peut constituer une mise à jour de la configuration de la carte à puce CD causant un changement dans le traitement des transactions TR par la carte à puce CD. Un mode de réalisation particulier est à présent décrit en référence aux figures 6-8. 10 Plus précisément, la carte à puce CD met en oeuvre un exemple de procédé de sécurisation en exécutant le programme d'ordinateur PG. La figure 7 représente, le long d'une ligne de temps, des transactions TR1 - TR5 ayant été successivement mises en oeuvre dans le passé par la carte à puce CD selon le protocole EMV. 15 La figure 6 représente l'enregistrement de ces transactions TR1 à TR5 dans le fichier d'historisation LG de la carte à puce CD. Plus particulièrement, des données d'historisation DLG sont enregistrées dans le fichier d'historisation LG en association avec chaque transaction TR1 - TR5. Ces données d'historisation DLG caractérisent les transactions TR1 - TR5 qui ont été déjà mises en oeuvre par la carte à puce CD. Dans cet exemple 20 particulier, les données d'historisation DLG enregistrées dans le fichier d'historisation LG comprennent, en association avec chaque transaction TR référencée, un identifiant de transaction ID, un point dans le temps PT (par exemple une date et/ou une heure) où la transaction a été réalisée et un montant MT de la transaction, et éventuellement au moins l'une parmi : une donnée d'historisation DN1 indiquant si la transaction a été réalisée en 25 ligne ou hors ligne, une donnée d'historisation DN2 indiquant si l'authentification (ou validation) en ligne par l'émetteur EM a été passée avec succès dans le cas d'une transaction en ligne, et une donnée d'historisation DN3 indiquant le type de terminal T ayant coopéré avec la carte CD lors de la transaction. Parmi les types de terminaux T possibles, on peut citer par exemple les distributeurs automatiques de billets (ou DAB) et 30 les terminaux de paiement, d'autres types de terminaux étant envisageables. Comme illustré en figure 7, on suppose à présent que la carte à puce CD a initié, en coopération avec le terminal T, le traitement selon le protocole EMV d'une nouvelle transaction TR6, dite transaction courante. La carte à puce CD est par exemple insérée dans le terminal T pour permettre la communication par contact. Dans un exemple 35 particulier, on suppose que la carte à puce CD a reçu une première commande APDU de type GENERATE AC, notée GAC1, comme déjà expliqué ci-avant en référence à l'étape S8 en figure 1, et que la carte à puce CD met en oeuvre le procédé de sécurisation selon un mode de réalisation particulier de l'invention en réponse à cette commande GAC1. Selon 3051579 16 une variante, le procédé de sécurisation est mis en oeuvre à un autre stade du protocole EMV. Selon encore une autre variante, la carte à puce CD met oeuvre le procédé de sécurisation alors que le traitement de la transaction TR courante selon le protocole EMV n'a pas encore été initié. 5 Les étapes A4, A6, Al2 et A14 décrites ci-après en référence à la figure 8 correspondent respectivement aux étapes S30, S32, S34 et S36, représentées en figure 5, mises en oeuvre dans un mode de réalisation particulier de l'invention. Au cours d'une étape d'envoi B2, le terminal T envoie une donnée temporelle DNT à la carte à puce CD qui la reçoit en A2. La donnée temporelle DNT est représentative d'un 10 point courant PC dans le temps. Cette donnée temporelle DNT peut présenter un quelconque format approprié et comprend ici par exemple la date courante DC et l'heure courante HC. En A4, la carte à puce CD détermine, à partir de la donnée temporelle DNT reçue en A2, le point courant dans le temps PC au cours duquel la transaction courante TR6 doit 15 être mise en oeuvre. Dans cet exemple, le point courant PC est défini par la date courante DC et l'heure courante HC au moment de l'initiation du protocole EMV entre la carte à puce DC et le terminal T pour mettre en oeuvre la transaction courante TR6. D'autres techniques pour déterminer la date et/ou l'heure courantes sont toutefois possibles. La carte à puce CD sélectionne (A6) ensuite, dans le fichier d'historisation LG, chaque 20 transaction TR mise en oeuvre par la carte à puce CD dans la période de temps prédéfinie PD terminant au point courant PC dans le temps déterminé en A4. Dans cet exemple, la période de temps PD est une fenêtre de temps d'une durée prédéfinie DT. La valeur de DT peut être adaptée selon le but recherché comme expliqué ultérieurement. Plus spécifiquement, au cours de la sélection A6, la carte à puce CD (plus 25 particulièrement le module de sélection MD4) détermine dans cet exemple le point de référence dans le temps, noté PRef, correspondant au début de la période de temps prédéfinie PD (figure 7). Pour ce faire, dans cet exemple particulier, la carte à puce CD calcule le point de référence PRef dans le temps à partir du point courant PC dans le temps et de la durée prédéfinie DT attribuée à la période de temps PD. Plus précisément, 30 la carte à puce CD calcule PRef tel que : PRef = PC - DT Dans cet exemple, le point de référence PRef comprend la date et l'heure du début de la période de temps PD. Le point de référence PRef dans le temps peut correspondre à une transaction 35 précédemment mise en oeuvre par la carte à puce CD. Toujours en A6, la carte à puce CD sélectionne (A10) ensuite chaque transaction TR, enregistrée dans le fichier d'historisation LG, qui est postérieure au point de référence PRef dans le temps. Selon un exemple particulier, la sélection A10 inclus la transaction TR 3051579 17 mise en oeuvre le cas échéant au point de référence PRef dans le temps (aucune transaction n'est enregistrée au point PRef dans cet exemple). Dans cet exemple, la carte à puce CD détermine à quel moment a été mise en oeuvre (ou traitée) une transaction TR référencée dans le fichier d'historisation LG à partir du 5 point dans le temps PT enregistré dans le fichier d'historisation LG en association avec la transaction TR concernée. PT comprend par exemple la date et/ou l'heure de la transaction TR correspondante. Dans cet exemple particulier, la carte à puce CD sélectionne en A10 les transactions TR2, TR3, TR4 et TR5 dont le point dans le temps PT (c.-à-d. la date et l'heure) est 10 postérieur à la position de référence PRef dans le temps. La carte à puce CD sélectionne en outre en A10 la transaction TR6 en cours, bien que des variantes soient possibles dans lesquelles la transaction TR en cours n'est pas sélectionnées en A10. La carte à puce CD peut en outre être configurée pour appliquer au moins un critère de sélection CR1 pour affiner la sélection réalisée en A10. Selon une variante, la carte à 15 puce CD détermine par exemple en A10, à partir du fichier d'historisation LG, en tant que transaction de référence TRef, la transaction TR la plus récente dans la période de temps PD qui satisfait la première condition prédéfinie CD1. On entend ici par « plus récente » la transaction TR dont le point dans le temps PT est le plus proche du point courant PC. La carte à puce CD sélectionne alors en A10 uniquement chaque transaction TR mise en 20 oeuvre par ladite carte CD postérieurement à la transaction de référence TRef dans la période de temps prédéfinie PD. Selon un exemple de réalisation particulier, la première condition CD1 comprend au moins l'une des conditions suivantes : CD11 : la transaction de référence TRef est une transaction en ligne ayant été réalisée en coopération avec l'émetteur EM ; et 25 ^ CD12 : la transaction de référence TRef est une transaction en ligne réalisée en coopération avec l'émetteur EM et qui a été authentifiée (ou validée) avec succès par ledit émetteur EM. Lorsque la condition CD11 ci-dessus est appliquée, la carte à puce CD détermine, pour chaque transaction TR dont le point dans le temps PT est postérieur à la transaction 30 de référence TRef, et à partir de la donnée DN1 associée, si ladite transaction TR est une transaction en ligne. Lorsque la condition CD12 ci-dessus est en outre appliquée, la carte à puce CD détermine, pour chaque transaction en ligne dont le point dans le temps PT est postérieur à la transaction de référence TRef, et à partir de la donnée DN2 correspondante dans le 35 fichier d'historisation LG, si ladite transaction TR a été authentifiée (ou validée) avec succès par l'émetteur EM. Dans un mode de réalisation particulier, la carte à puce CD applique la condition CD11 mais pas la condition CD12 en A10. Selon l'exemple représenté en figure 6, la 3051579 18 transaction TR3 constitue alors la transaction de référence TRef (DN1 = ON LINE) de sorte que la carte à puce CD sélectionne en A10, conformément à la condition CD11, les transactions TR4 et TR5. Selon un autre mode de réalisation, la carte à puce CD applique la condition CD12 ci- 5 dessus. Selon l'exemple représenté en figure 6, la transaction TR3 constitue alors également la transaction de référence TRef car la donnée DN2 associée indique que cette transaction en ligne a été authentifiée (ou validée) avec succès par l'émetteur EM (DN2 = OK). En conséquence, la carte à puce CD sélectionne en A10, conformément à la condition CD12, les transactions TR4 et TR5. 10 Comme déjà indiqué, la carte à puce CD peut être configurée pour appliquer au moins un critère de sélection CR1 pour affiner la sélection réalisée en A10. Le nombre et la nature des critères de sélection CR1 peut varier selon le cas. Selon un exemple particulier, lors de la sélection A10, la carte à puce CD filtre les transactions TR enregistrées dans le fichier d'historisation LG pour ne sélectionner que chaque transaction 15 TR satisfaisant au moins une deuxième condition prédéfinie CD2. Dans un exemple particulier, la deuxième condition prédéfinie CD2 comprend une condition sur le type du terminal T avec lequel la carte à puce CD a coopéré lors de ladite transaction TR. Dans l'exemple représenté en figure 6, le fichier d'historisation LG enregistre en tant que donnée d'historisation DN3, pour chaque transaction TR, si ladite 20 transaction a été réalisée en coopération avec un terminal T selon un premier type TY1 ou selon un deuxième type TY2. Dans un exemple particulier, les états TY1 et TY2 indiquent respectivement que le terminal T est un distributeur automatique de billets (DAB) et un terminal de paiement (un terminal mobile par exemple). Si par exemple la condition CD2 est appliquée, la carte à puce CD exclut de la sélection A10 les transactions TR qui sont 25 dans la période prédéfinies PD et mais ne satisfont par l'état TY1 (la transaction TR5 est donc exclus dans cet exemple). On comprendra qu'il est possible de configurer la carte à puce CD pour qu'elle applique au moins une première condition CD1 et/ou au moins une deuxième condition CD2 comme expliqué ci-avant. 30 On supposera dans la suite de cet exemple que la carte à puce CD applique la condition CD11 et sélectionne en conséquence en A10 les transactions TR4 et TR5. Au cours d'une étape d'analyse Al2, la carte à puce CD (plus particulièrement le module d'analyse de risque MD6), réalise une analyse de risque (ou analyse de transaction), à partir des données d'historisation DLG enregistrées dans le fichier 35 d'historisation LG en association avec chaque transaction TR sélectionnée en A6 (à savoir TR4 et TR5 dans cet exemple), pour détecter si une utilisation anormale (ou suspecte) de la carte à puce CD s'est produite pendant la période de temps prédéfinie PD. 3051579 19 Dans cet exemple de réalisation, lors de ladite analyse Al2, la carte à puce CD détecte si une utilisation anormale de ladite carte CD s'est produite pendant la période de temps prédéfinie PD à partir d'au moins l'un parmi : - le nombre de transactions TR sélectionnées en A6 ; et 5 - le montant cumulé de chaque transaction TR sélectionnée en A6. On suppose dans cet exemple que le nombre de transactions TR sélectionnées en A6 et le montant cumulé de chaque transaction TR sélectionnée en A6 sont pris en compte par la carte à puce CD lors de l'analyse de risque Al2. Dans l'exemple considéré ici et comme représenté en figure 6, deux transactions (TR4 et TR5) sont sélectionnées 10 en A6 et le montant cumulé des transactions TR4 et TR5 s'élève à MT4 + MT5. Selon un exemple particulier, lors de l'analyse de risque Al2, la carte à puce CD détecte si une utilisation anormale (ou suspecte) s'est produite pendant la période de temps prédéfinie PD selon au moins un critère d'analyse CR2, enregistré dans cet exemple dans la mémoire 10. Dans cet exemple, lors de l'analyse Al2, la carte à puce CD applique, 15 en tant que critères d'analyse CR2, les conditions prédéfinies CD3 suivantes : CD31 : le nombre de transactions sélectionnées lors de ladite sélection A6 atteint au moins une première valeur seuil prédéfinie Lmax1 ; et CD32: le montant cumulé (TR4 + TR5 dans cet exemple) de chaque transaction TR sélectionnée en A6 atteint au moins une deuxième valeur seuil 20 prédéfinie Lmax2. Autrement dit, lors de l'analyse Al2, la carte à puce CD détecte qu'une utilisation anormale ou suspecte s'est produite pendant la période de temps prédéfinie PD si les conditions CD32 et CD32 sont satisfaites. Les valeurs Lmaxl et Lmax2 sont fixées selon les besoins du cas d'espèce. 25 Selon une variante, seule l'une parmi les conditions prédéfinies CD31 et CD32 est appliquée par la carte à puce CD lors de l'analyse Al2. Si aucune utilisation anormale n'est détectée lors de l'analyse Al2, le procédé de sécurisation prend fin. Dans ce cas, la carte à puce CD reprend par exemple un traitement normal de la transaction selon le protocole EMV. 30 Si, en revanche, une utilisation anormale est détectée en Al2, la carte à puce CD déclenche en A14 au moins une opération de sécurisation de la carte à puce CD en réponse à la transaction courante TR6. Chaque opération de sécurisation est configurée pour sécuriser la carte à puce CD vis-à-vis de la transaction courante TR, et plus généralement, vis-à-vis de l'utilisation faite de la carte à puce CD sur la période de temps 35 PD. Le nombre et la nature de ces opérations de sécurisation peuvent varier selon le cas d'usage. Dans cet exemple, la carte à puce CD réalise en A14 au moins l'une des opérations de sécurisation suivantes : 3051579 20 envoi (A16) au terminal T d'un message MSG1 informant de ladite utilisation anormale ou suspecte détectée. Le terminal T peut le cas échéant transmettre (B17) le message MSG1 au serveur distant SV afin que l'émetteur SV soit informé de l'utilisation anormale ou suspecte détectée par la carte à puce CD ; 5 modification d'au moins un paramètre de fonctionnement PR du dispositif électronique. Comme déjà indiqué, divers paramètres de fonctionnement PR de la carte à puce CD peuvent être modifiés selon les besoins. De manière générale, un paramètre de fonctionnement PR configure la manière dont la carte à puce CD traite une transaction TR avec le terminal T. 10 enregistrement (A20), dans le fichier d'historisation LG, d'une donnée de sécurité DS représentative de ladite utilisation anormale ou suspecte détectée en Al2 ; et refus (A22) d'autoriser la transaction courante. La carte CD à puce CD envoie par exemple un message de refus MSG2 qui est reçu par le terminal T en B22. 15 La présente invention permet avantageusement de protéger de façon efficace les cartes à puce, par exemple de type EMV, contre les comportements anormaux ou suspects survenant notamment lors des transactions hors ligne. Une carte à puce selon l'invention est ainsi capable de stocker en mémoire des données d'historisation relatives aux transactions traitées par ladite carte au fil du temps. A partir de ces données 20 d'historisation, la carte à puce peut alors analyser l'utilisation qui est faite de la carte dans une fenêtre de temps pertinente, à savoir une fenêtre de temps correspondant ici à une période de temps qui précède immédiatement la transaction en cours. Il est ainsi possible de prendre en compte toutes les transactions pertinentes pour chaque analyse faite par la carte à puce, sans qu'il y ait un risque que certaines transactions soient exclues de 25 l'analyse comme c'est le cas par exemple dans le mécanisme de sécurisation décrit précédemment en référence aux figures 2A et 2B. Il est possible de fixer la durée DT de la période de temps PD en fonction du type d'utilisation anormale ou non autorisée que l'on cherche à détecter. Afin de pallier les problèmes de vol précédemment décrits, on peut par exemple fixer la durée DT telle que 30 DT = 10 minutes (ou une quelconque valeur inférieure à 60 ou 10 minutes). Si, en revanche, on cherche à détecter un comportement anormal du porteur authentique (par exemple un nombre et/ou un montant cumulé de dépense anormal ou suspect), on peut par exemple régler la durée DT telle que DT = 30 jours. De cette manière, l'émetteur peut contrôler les habitudes de consommations du porteur authentique et, si besoin, 35 contacter le porteur ou prendre toute autre mesure appropriée. On peut ainsi configurer la carte à puce afin de déclencher une réponse sécuritaire adaptée à l'utilisation anormale détectée. Une sécurisation renforcée de la carte à puce contre les utilisations frauduleuses (en cas de vol par exemple) est par exemple possible. 3051579 21 De manière générale, l'invention permet de mieux contrôler l'utilisation d'une carte à puce, de type EMV notamment, y compris lorsque celle-ci fonctionne hors ligne. Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en oeuvre de l'invention. En 5 particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier. 10 REVENDICATIONS1. Procédé de sécurisation mis en oeuvre par un dispositif électronique (CD), ledit procédé comprenant : détermination (S30 ; A4) d'un point courant dans le temps (PC) au cours duquel une transaction courante (TR) est ou doit être mise en oeuvre par le dispositif électronique ; sélection (532 ; A6), dans un fichier d'historisation (LG) dans lequel est enregistrée au moins une transaction (TR) passée, de chaque transaction mise en oeuvre par ledit dispositif électronique dans une période de temps prédéfinie (PD) terminant au point courant dans le temps ; analyse de risque (S34 ; Al2), à partir d'au moins une donnée d'historisation (DLG) enregistrée dans le fichier d'historisation en association avec chaque transaction (TR) sélectionnée, pour détecter si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie ; et dans l'affirmative, déclenchement (S36 ; A14) d'au moins une opération de sécurisation (A16-A22) du dispositif électronique en réponse à ladite transaction courante. 2. Procédé selon la revendication 1, dans lequel le point courant dans le temps comprend au moins l'un parmi la date courante et l'heure courante de la transaction courante. 3. Procédé selon la revendication 1 ou 2, dans lequel la détermination du point courant comprend une réception, depuis un terminal avec lequel coopère le dispositif électronique, d'une donnée temporelle représentative du point courant dans le temps. 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel ladite sélection comprend un calcul du point dans le temps du début de la période de temps prédéfinie, à partir du point courant dans le temps et d'une durée prédéfinie attribuée à ladite période de temps prédéfinie, chaque transaction sélectionnée étant postérieure au point dans le temps du début de la période de temps prédéfinie. 3051579 23 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel, lors de ladite sélection, le dispositif électronique : détermine, à partir du fichier d'historisation, en tant que transaction de référence, la transaction la plus récente dans la période de temps prédéfinie 5 qui satisfait au moins une première condition prédéfinie ; et - sélectionne uniquement chaque transaction mise en oeuvre par ledit dispositif électronique postérieurement à ladite transaction de référence dans la période de temps prédéfinie. 10 6. Procédé selon la revendication 5, dans lequel ladite au moins une première condition prédéfinie comprend au moins l'une des conditions suivantes : la transaction de référence est une transaction dite « en ligne » ayant été réalisée en coopération avec une entité émettrice du dispositif électronique ; et 15 la transaction de référence est une dite transaction en ligne qui a été authentifiée avec succès par l'entité émettrice du dispositif électronique. 7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel, lors de ladite sélection, le dispositif électronique filtre les transactions enregistrées dans le fichier 20 d'historisation pour ne sélectionner que chaque transaction satisfaisant au moins une deuxième condition prédéfinie. 8. Procédé selon la revendication 7, dans lequel la deuxième condition prédéfinie comprend une condition sur le type du terminal avec lequel le dispositif électronique a 25 coopéré lors de ladite transaction. 9. Procédé selon l'une quelconque des revendications 1 à 8, dans lequel, lors de ladite analyse de risque, le dispositif électronique détecte si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie à partir 30 d'au moins l'un parmi : - le nombre de transactions sélectionnées ; et - le montant cumulé de chaque transaction sélectionnée. 10. Procédé selon la revendication 9, dans lequel, lors de ladite analyse de risque, le 35 dispositif électronique détecte qu'une utilisation anormale s'est produite pendant ladite période de temps prédéfinie si au moins l'une des troisièmes conditions prédéfinies suivantes est satisfaite : 3051579 24 le nombre de transactions sélectionnées lors de ladite sélection atteint une première valeur seuil prédéfinie ; et le montant cumulé de chaque transaction sélectionnée lors de ladite sélection atteint une deuxième valeur seuil prédéfinie. 5 11. Procédé selon l'une quelconque des revendications 1 à 10, dans lequel ladite au moins une opération de sécurisation comprend au moins l'un parmi : envoi d'un message informant de ladite utilisation anormale détectée ; modification d'au moins un paramètre de fonctionnement du dispositif 10 électronique ; enregistrement, dans le fichier d'historisation, d'une donnée de sécurité représentative de ladite utilisation anormale détectée ; et refus de mettre en oeuvre ladite transaction courante. 15 12. Procédé selon l'une quelconque des revendications 1 à 11, dans lequel le dispositif électronique est une carte à puce. 13. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes d'un procédé de sécurisation selon l'une quelconque des revendications 1 à 12 20 lorsque ledit programme est exécuté par un ordinateur. 14. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1) comprenant des instructions pour l'exécution des étapes d'un procédé de sécurisation selon l'une quelconque des revendications 1 à 12. 25 15. Dispositif électronique comprenant : - un module de détermination pour déterminer un point courant dans le temps au cours duquel une transaction courante est ou doit être mise en oeuvre par le dispositif électronique ; 30 - un module de sélection pour sélectionner, dans un fichier d'historisation dans lequel est enregistrée au moins une transaction passée, chaque transaction mise en oeuvre par ledit dispositif électronique dans une période de temps prédéfinie terminant au point courant dans le temps ; - un module d'analyse de risque pour détecter, à partir d'au moins une donnée 35 d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction sélectionnée, si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie ; et 3051579 25 un module de sécurisation configuré, en cas de résultat positif de ladite détection par le module d'analyse de risque, pour déclencher une opération de sécurisation du dispositif électronique en réponse à ladite transaction courante. 5 16. Dispositif électronique selon la revendication 15, comprenant une mémoire dans laquelle est enregistré le fichier d'historisation. 17. Dispositif électronique selon la revendication 15 ou 16, dans lequel le dispositif électronique est une carte à puce.