Brevet FR3030825A1 — publié le 20160624

Arrière-plan de l'invention La présente invention se situe dans le domaine général des dispositifs électroniques aptes à coopérer avec un terminal externe afin de réaliser une opération, telle qu'une transaction par exemple. L'invention concerne en particulier la remontée d'informations utiles par de tels dispositifs électroniques vers le terminal externe afin de réaliser un traitement approprié. L'invention s'applique plus particulièrement, mais de manière non exclusive, aux cartes à puce cartes (ou cartes à microcircuit), conformes par exemple à la norme 1507816. L'invention vise notamment l'utilisation d'une carte à puce fonctionnant selon le protocole EMV (pour « Europay Mastercard Visa ») pour remonter des informations de sécurité à un terminal externe (ou lecteur). 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 des transactions de paiement ou d'authentification du porteur, par exemple. Les cartes à puce pour applications bancaires (carte de crédit, carte de débit etc.), par exemple, sont aptes à communiquer avec des terminaux de paiement. EMV est le protocole standardisé utilisé majoritairement dans le monde pour sécuriser notamment les transactions de paiement effectuées par des cartes à puce. 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 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 que la transaction en cours est 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. De nombreux mécanismes de sécurité ont récemment été développés afin de sécuriser autant que possible l'usage croissant des cartes à puce, de type EMV notamment. Il a par exemple été développé des cartes à puce EMV aptes à détecter des attaques, de type optique ou autre, réalisées à leur encontre par des personnes ou entités malveillantes. Sur détection d'une telle attaque, la carte à puce efface les données sensibles qu'elle contient en mémoire et se rend volontairement inopérationnelle. Si un dialogue EMV est initié avec un lecteur, la carte répond à un message RESET (RST) par une réponse ATR (ANSWER TO RESET) modifiée indiquant que la transaction ne peut avoir lieu. Peu ou pas d'information est cependant inclus dans cette réponse ATR de sorte qu'il est difficile du côté lecteur de déterminer la cause de l'échec du dialogue. Il n'existe pas aujourd'hui de mécanisme satisfaisant permettant de remonter efficacement des informations de sécurité depuis une carte à puce (ou plus généralement depuis un dispositif électronique) vers un lecteur afin de permettre une meilleure évaluation des risques de sécurité, d'identifier de possibles attaques rencontrées par la carte à puce ou encore de réaliser des traitements en fonction de certains comportements observés au niveau de la carte. Les possibilités de suivi des comportements d'un porteur d'une carte à puce (ou équivalents) ou des opérations réalisées par cette carte sont aujourd'hui limitées et appelles à de nouveaux mécanismes de remonter d'information de la carte vers le lecteur, voire vers un tiers distant tel que l'émetteur de la carte à puce par exemple. Il existe en particulier un besoin pour une solution permettant de remonter de tels informations sans modifier en profondeur les protocoles de communication actuels (de type EMV par exemple) mis en oeuvre collectivement par les dispositifs électroniques et les lecteurs associés. Objet et résumé de l'invention A cet effet, la présente invention concerne un procédé d'envoi d'une information de sécurité mis en oeuvre par un dispositif électronique, ledit procédé comprenant les étapes suivantes : détection d'un évènement rencontré par le dispositif électronique ; enregistrement, dans une mémoire sécurisée du dispositif, d'une information de sécurité représentative dudit évènement ; démarrage, suite audit enregistrement, d'une transaction avec un terminal externe ; et - envoi au terminal externe de l'information de sécurité dans un message de transaction lors de ladite transaction. Selon un mode de réalisation particulier, l'évènement détecté par le dispositif électronique comprend au moins l'un parmi : une anomalie rencontrée par le dispositif électronique ; et une attaque à l'encontre du dispositif électronique. Selon un mode de réalisation particulier, ledit évènement satisfait au moins l'une des conditions suivantes : - l'évènement cause une réinitialisation du dispositif électronique ; et 10 - l'évènement comprend l'exécution par le dispositif électronique d'une opération affectant un code confidentiel stocké dans une mémoire sécurisée du dispositif électronique. Selon un mode de réalisation particulier, un comportement anormal du dispositif électronique ou une attaque à l'encontre dudit dispositif électronique est détecté si au 15 moins une condition préenregistrée dans le dispositif électronique est satisfaite. Selon un mode de réalisation particulier, la transaction et le message de transaction comportant l'information de sécurité sont conformes au protocole EMV. Selon un mode de réalisation particulier, le procédé d'envoi comprend un envoi au terminal externe, dans un message AFL, d'une donnée de référencement permettant au 20 terminal externe de lire l'information de sécurité dans la mémoire sécurisée du dispositif électronique ; l'information de sécurité étant envoyée au terminal externe en réponse à une commande de lecture reçue du terminal externe suite à l'envoi du message AFL. Selon un mode de réalisation particulier, le procédé d'envoi comprend l'envoi au 25 terminal externe, dans un message ATR, d'une donnée de référencement lui permettant de lire l'information de sécurité dans la mémoire sécurisée du dispositif électronique. Selon un mode de réalisation particulier, l'information de sécurité est envoyée au terminal externe en tant que donnée non interprétable par le terminal externe en réponse à un message GENERATE AC reçu du terminal externe. 30 Dans un mode particulier de réalisation, les différentes étapes du procédé d'envoi sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations (ou d'enregistrement), ce programme étant susceptible d'être mis en oeuvre dans un dispositif électronique telle qu'une carte à puce ou un ordinateur, ce 35 programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé d'envoi tel que défini ci-dessus. L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. L'invention concerne également un procédé de traitement mise en oeuvre par un terminal externe à un dispositif électronique, ledit procédé comprenant les étapes suivantes : démarrage d'une transaction avec le dispositif électronique ; réception, en provenance du dispositif électronique, d'un message de transaction contenant une information de sécurité lors de la transaction, ladite information de sécurité étant représentative d'un évènement détecté par le dispositif électronique ; et traitement de l'information de sécurité. Selon un mode de réalisation particulier, ledit traitement comprend au moins l'un parmi : - réalisation d'une analyse de risque associée à ladite transaction à partir de l'information de sécurité ; et envoi de l'information de sécurité à un serveur distant du terminal externe. L'invention comprend corrélativement un dispositif électronique comprenant : un module de détection d'un évènement rencontrée par le dispositif électronique ; - un module d'obtention d'une information de sécurité représentative dudit évènement ; un module d'enregistrement, dans une mémoire sécurisée du dispositif, de l'information de sécurité; un module d'exécution apte à démarrer, suite à l'enregistrement de l'information de sécurité, une transaction avec le terminal externe ; et un module d'envoi au terminal externe de l'information de sécurité dans un message de transaction lors de ladite transaction. Les différents modes de réalisation et variantes définis ci-avant en référence au procédé d'envoi s'appliquent de manière analogue au dispositif électronique de l'invention. Selon un mode de réalisation particulier, le module d'exécution est apte à poursuivre jusqu'à son terme la transaction une fois l'information de sécurité envoyée au terminal externe. Selon un mode de réalisation particulier, le dispositif électronique est une carte à 35 puce. Selon un mode de réalisation particulier, le module de détection comprend au moins l'un parmi : un premier module de traitement apte à détecter ledit évènement à partir d'une commande reçue d'une l'entité externe par un module d'interface du dispositif électronique, ledit module d'interface permettant établir une communication entre le dispositif électronique et ladite entité électronique ; et un capteur apte à détecter une attaque survenant à l'encontre du dispositif électronique et un deuxième module de traitement apte à détecter ledit évènement à partir de l'attaque détectée. L'invention concerne également un terminal externe à un dispositif électronique, ledit terminal comprenant : un module d'exécution apte à démarrer une transaction avec le dispositif électronique ; un module de réception apte à recevoir du dispositif électronique un message de transaction contenant une information de sécurité lors de la transaction, ladite information de sécurité étant représentative d'un évènement détecté par le dispositif électronique ; et un module de traitement de l'information de sécurité. Selon un mode de réalisation particulier, ladite transaction et ledit message de transaction sont conformes au protocole EMV, le terminal comprenant : un module d'extraction apte à extraire, d'un message ATR reçu du dispositif électronique lors de la transaction, une donnée de référencement permettant au terminal de lire l'information de sécurité dans une mémoire sécurisée du dispositif électronique. A noter que les programme d'ordinateur mentionnés dans le présent exposé peuvent 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 objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. De plus, les supports d'enregistrement (ou d'information) mentionnés dans le présent exposé peuvent ê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. D'autre part, les supports d'enregistrement peuvent correspondre à 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, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 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 exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : - la figure 1 représente sous forme d'un organigramme un exemple de coopération entre une carte à puce et un terminal externe conformément au protocole EMV ; la figure 2 représente, de manière schématique, l'architecture matérielle d'une carte à puce conforme à une mise en oeuvre particulière de l'invention ; la figure 3 représente schématiquement des modules mis en oeuvre par la carte à puce de la figure 2; la figure 4 représente, de manière schématique, l'architecture matérielle d'un lecteur de carte conforme à une mise en oeuvre particulière de l'invention, ce lecteur étant apte à coopérer avec la carte à puce représentée en figures 2 et 3; - la figure 5 représente schématiquement des modules mis en oeuvre par le lecteur de carte de la figure 4 ; la figure 6 représente, sous forme d'un organigramme, un procédé d'envoi réalisé par la carte à puce de la figure 2 conformément à une mise en oeuvre particulière de l'invention ; la figure 7 représente, sous forme d'un organigramme, un procédé d'envoi et un procédé de traitement conformes à un premier mode de réalisation de l'invention ; - la figure 8 représente, sous forme d'un organigramme, un procédé d'envoi et un procédé de traitement conformes à un deuxième mode de réalisation de l'invention ; et la figure 9 représente, sous forme d'un organigramme, un procédé d'envoi et un procédé de traitement conformes à un troisième mode de réalisation de l'invention. Description détaillée de plusieurs modes de réalisation Comme indiqué ci-avant, la présente invention se situe dans le domaine général des dispositifs électroniques aptes à coopérer avec un terminal externe (ou lecteur) afin de réaliser une opération telle qu'une transaction par exemple. L'invention concerne en particulier la remontée d'informations de sécurité par de tels dispositifs électroniques vers le terminal externe afin de permettre une évaluation optimale de certains risques de sécurité, d'identifier de possibles attaques rencontrées par le dispositif électronique ou encore de réaliser des traitements en fonction de certains comportements observés au niveau du dispositif électronique. La présente invention est décrite dans l'exposé qui suit dans le cadre d'une carte à puce (conforme par exemple à la norme 1S07816) de type EMV, cette carte étant apte à remonter des informations de sécurité à un lecteur externe lors d'une transaction EMV. On comprendra toutefois que d'autres types de protocole peuvent être envisagés dans le cadre de l'invention. L'invention vise plus généralement un dispositif électronique destiné à coopérer avec un terminal externe (ou lecteur) pour réaliser une opération, typiquement une transaction (de paiement par exemple). Ce dispositif électronique est en particulier apte à fournir une information de sécurité au lecteur après avoir démarrer une transaction avec celui-ci. 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 bancaire. L'invention est décrite ici dans le cadre d'une carte de paiement destinée à réaliser des transactions bancaires. On comprendra que d'autres types de transactions ou opérations sont envisageables dans le cadre de l'invention. On notera également que, dans les exemples de réalisation qui suivent, la carte à puce coopère en mode contact avec le lecteur. L'invention s'applique toutefois également au cas où la carte à puce communique en mode sans contact avec le lecteur. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes numéros de références et présentent des caractéristiques identiques 30 ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Afin de faciliter la compréhension de l'invention, on décrit à présent, en référence à la figure 1, un exemple d'une transaction de paiement conforme au protocole EMV, à l'aide d'une carte à puce 1 coopérant avec un lecteur (ou terminal) externe 2. Le lecteur 2 est 35 apte à communiquer avec un serveur bancaire 3 associé à l'émetteur de la carte à puce 1. Dans cet exemple, la carte à puce 1 est une carte de paiement et le lecteur 2 est un terminal de paiement. Comme indiqué ci-après, la carte à puce 1 fonctionne ici en mode avec vérification du code secret bien que l'on puisse envisager des variantes selon lesquelles la carte à puce 1 ne procède pas à la vérification du code secret (mode sans vérification du code secret). Une carte à puce EMV de paiement contient généralement différentes applications bancaires permettant par exemple de fonctionner en mode « carte de crédit » ou « carte de débit » dans un point de vente ou encore d'interagir avec un guichet automatique bancaire. On suppose ici que le porteur insert la carte à puce 1 dans le lecteur 2. Le protocole EMV comprend une phase préliminaire PHP destinée à préparer la carte à puce 1 et le lecteur 2 à la mise en oeuvre à suivre de la transaction TR elle-même. Différents messages conformes au protocole EMV sont échangés entre la carte à puce 1, le lecteur 2 et (dans cet exemple) le serveur bancaire 3 au cours de la phase PHP puis de la transaction TR. Plus précisément, lors de la phase préliminaire PHP, le lecteur 2 envoie (E2) tout d'abord un message RESET (RST) à la carte de paiement 1. La carte de paiement 1 répond (E4) à l'aide d'un message ANSWER TO RESET (ATR). Une fois ce premier dialogue effectué, le lecteur 2 tente de choisir l'application appropriée sur la carte de paiement 1. Pour ce faire, le lecteur 2 envoie (E6) à la carte 1 une commande SELECT FILE afin de demander à la carte de paiement 1 les applications que cette dernière est capable d'exécuter. Cette commande SELECT FILE contient typiquement en paramètre l'identifiant d'application (AID pour « Application Identifier ») « 1PAY.SYS.DDF01 ». En réponse, la carte 1 fournit (E8) au lecteur 2 une liste des différentes applications qu'elle peut mettre en oeuvre. Le porteur peut alors sélectionner via le lecteur 2 le mode de transaction souhaité, déclenchant ainsi l'envoi (E10) vers la carte 1 d'une commande SELECT APPLICATION avec en paramètre l'identifiant AID de l'application sélectionnée. A noter qu'il existe divers variantes pour sélectionner l'application appropriée dans la carte à puce 1. Le lecteur 2 envoie (E10) en outre une commande GET PROCESSING OPTIONS (GPO) à la carte à puce 1 afin d'initier le début de la transaction. L'envoi de cette commande GPO marque le début de la transaction EMV. Au cours de cette transaction TR, la carte de paiement 1 envoie (E14) au lecteur 2 une première série d'informations, telles que l'AIP (Application Interchange Profile) qui indique au lecteur 2 les différentes opérations à faire pour mener à bien une transaction. La carte 1 envoie (E16) également un message AFL (Application File Locator) qui indique la liste des données disponibles au niveau de l'application dans la carte 1 et que le lecteur 2 doit aller lire pour pouvoir réaliser la transaction TR. Le lecteur 2 lit (E18-E20) ainsi les informations spécifiées dans l'AFL. Pour ce faire, le lecteur 2 envoie (E18) une ou plusieurs commandes de lecture READ RECORD à la carte de paiement 1 et reçoit (E20) en retour les informations demandées (appelés RECORDS). A noter que les étapes E14 et E16 peuvent être réalisées au cours de l'envoi d'un même message depuis la carte à puce 4. Les informations lues (E18-E20) par le lecteur 2 dans la carte 1 comprennent par exemple la date d'expiration de la carte à puce 1, le numéro de compte associé, une signature numérique pour authentifier la carte 1, des paramètres de contrôle à utiliser par la suite pour réaliser la transaction, ou encore des listes d'objets dites listes CDOL (pour Card Data Object List). Divers modes de réalisation sont envisageables. Dans cet exemple, le lecteur 2 réalise (E22) ensuite une étape d'analyse à partir des informations fournies (E20) par la carte de paiement 1. Si l'authentification associée à la carte de paiement 1 échoue, si une anomalie est détectée ou encore si un risque trop important est détecté, le lecteur 2 peut refuser la transaction. On suppose ici que l'analyse E22 est passée avec succès. Le protocole EMV se poursuit ici avec une phase d'authentification du porteur de la carte à puce 1 selon l'une des méthodes listées et supportées par ladite carte. Le lecteur 2 détermine le procédé d'authentification du porteur à appliquer en fonction des informations précédemment reçues dans les paramètres de contrôle. Cette phase permet en particulier au terminal de paiement de déterminer si la transaction est effectuée en mode avec vérification de code ou en mode sans vérification de code. Dans cet exemple, où le mode avec vérification de code est mis en oeuvre, le porteur est invité à saisir son code PIN à l'aide du clavier dont est généralement muni le lecteur 2. Le lecteur 2 envoie (E24) alors à la carte de paiement 1 une requête VERIFY de vérification du code PIN saisi par le porteur. La carte de paiement 1 compare (E26) alors le code PIN saisi par le porteur avec le code PIN authentique inclus dans sa mémoire et en déduit si le porteur est authentique ou non. Si le code PIN saisi est bon, la carte de paiement 1 envoie (E28) un message OK de type 0x9000 au terminal. Dans le cas contraire, la carte envoie (E28) un message de refus de type Ox63Cx au terminal, dans lequel x est le nombre de tentatives de code PIN restantes avant que la carte 1 bloque la transaction en cours (et les transactions à venir). On ne s'intéresse ici qu'au cas d'une vérification de code PIN hors ligne, c'est-à-dire sans que le lecteur 2 fasse appel à l'émetteur de la carte dans le processus de vérification du code PIN, bien que cela soit également possible. Une fois le porteur authentifié, le protocole EMV se poursuit avec une phase de vérification de la transaction. Plus précisément, le lecteur 2 génère puis envoie (E28) à la carte 1 une commande GAC (pour GENERATE AC). Cette commande contient différentes données demandées préalablement par la carte de paiement 1 dans une liste CDOL reçue à l'étape E20 par le lecteur 2. Typiquement, la commande GAC contient des informations telles que le montant de la transaction en cours, la devise utilisée, le type de transaction, etc. En réponse à la commande GAC, la carte 1 réalise (E32) une étape d'analyse comprenant un certain nombre de vérifications de critères. Le nombre et la nature de ces vérifications ne sont pas normalisés par le protocole EMV et peuvent varier selon le cas. A l'issue de l'analyse E32, la carte de paiement 1 répond au lecteur 2 en envoyant (E34) un cryptogramme (ou certificat cryptographique) qui comprend un code d'authentification de message (ou MAC pour Message Authentification Code), ce dernier étant typiquement crypté à partir d'une clé cryptographique mémorisée dans la carte à puce 1. La réponse de la carte dépend notamment du paramétrage de la carte 1 effectué par la banque émettrice. Dans cet exemple, la carte à puce 1 envoie (E34) un cryptogramme ARQC (Autorisation Request Cryptogram) indiquant que la carte 1 souhaite poursuivre la transaction en ligne avec le serveur bancaire 3 de l'émetteur de la carte. La carte de paiement 1 peut en outre envoyer (E34) le cas échéant des informations IDD (pour Issuer Discretionnary Data) au lecteur 2 en plus du cryptogramme. Le lecteur 2 transmet (E36) ainsi le cryptogramme ARQC (et le cas échéant les informations IDD) au serveur bancaire 3 au niveau duquel est réalisé (E38) une nouvelle analyse à partir des informations reçues. Cette analyse E38 comprend typiquement un certain nombre de vérifications afin de s'assurer que la transaction est valide. Le lecteur 2 reçoit (E40) en réponse un message crypté ARPC indiquant la décision de l'émetteur. Le lecteur 2 transmet (E42) ce message ARPC à la carte de paiement 1 afin de lui indiquer la décision prise par l'émetteur. Si la carte 1 accepte la transaction, celle-ci envoie (E44) en réponse un cryptogramme de type TC (transaction acceptée) au lecteur 2. Dans le cas contraire, la carte 1 envoie (E44) un cryptogramme de type AAC indiquant le refus de la transaction. Chacun des messages ci-dessus échangés selon le protocole EMV pendant la transaction TR, en particulier entre la carte à puce 1 et le lecteur 2, constitue des exemples de messages de transaction au sens de l'invention. Il convient de rappeler ici que le déroulement du protocole EMV décrit ci-dessus en référence à la figure 1 ne constitue qu'un exemple non limitatif. Le protocole EMV offre en effet de nombreuses alternatives. Il incombe aux intégrateurs de faire les choix nécessaires pour adapter l'exécution du protocole selon les besoins (méthode d'authentification du porteur, transaction en ligne ou hors ligne etc.). La figure 2 représente, de manière schématique, l'architecture matérielle d'une carte à puce 4 conforme à un mode de réalisation particulier de l'invention. La carte 4 est dans cet exemple une carte EMV conforme à la norme ISO 7816. Plus particulièrement, la carte à puce 4 comprend ici un microprocesseur 5 couplé à des contacts externes 6 (ports d'entrées/sorties), 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 carte 4 peut également comprendre une mémoire morte (de type ROM) non représentée ici. On considère ici que la mémoire 10 est sécurisée, en faisant appel à un mécanisme de sécurité classique bien connu de l'homme du métier et qui ne sera donc pas décrit ici. La mémoire 10 constitue ici un support d'enregistrement (ou d'information) conforme à un mode de réalisation de l'invention, lisible par la carte à puce 4, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation de l'invention. Le programme PG1 comporte des instructions pour l'exécution des étapes d'un procédé d'envoi d'une information de sécurité IS pouvant également être stockée dans la mémoire 10, conformément à un mode de réalisation de l'invention. Des exemples de réalisation de ce procédé sont représentés sur les figures 6 à 9 décrites ultérieurement. Dans l'exemple considéré ici, la mémoire 10 de la carte à puce 4 comporte en outre au moins une règle prédéfinie RL qui sera décrite ultérieurement. Les contacts externes 6 constituent ici un module d'interface permettant à la carte à puce 4 (et plus particulièrement au microprocesseur 5) d'établir une communication, par contact dans cet exemple, avec une entité externe telle que le terminal 30 décrit ci-après en référence à la figure 4. On comprendra que d'autres types de module d'interface peuvent toutefois être envisagés comme un module d'interface permettant d'établir une communication sans contact (comportant une antenne radiofréquence par exemple) entre la carte à puce et un terminal externe. Dans un exemple particulier, la carte à puce 4 comporte au moins un capteur (non représenté sur les figures) apte à détecter une attaque survenant à l'encontre du dispositif électronique. Ce capteur peut être par exemple un capteur optique et/ou électromagnétique. Ce capteur permet par exemple de détecter une attaque de type optique (attaque par laser par exemple) et/ou électromagnétique. La figure 3 représente schématiquement des modules pouvant être mis en oeuvre par le microprocesseur 5 exécutant le programme PG1, à savoir : un module de détection 14 d'un évènement EVT, un module d'obtention 16 d'une information de sécurité IS, un module d'enregistrement 18 d'une telle information de sécurité, un module d'exécution 20 permettant notamment le démarrage d'une transaction EMV et un module 22 apte à envoyer l'information de sécurité IS lors d'une transaction EMV. Dans un exemple particulier, le module de détection 14 comprend au moins l'un parmi : un premier module de traitement (non représenté) apte à détecter l'évènement EVT à partir d'une commande (de type APDU par exemple) reçue d'une entité externe (telle que le terminal 30 représenté en figure 4) par le module d'interface 6 de la carte à puce 4; et un capteur (non représenté) apte à détecter une attaque survenant à l'encontre de la carte à puce 4, et un deuxième module de traitement (non représenté) apte à détecter l'évènement EVT à partir de l'attaque détectée. La commande (de type APDU ou autre) est par exemple reçue par la carte à puce 4 lors d'une transaction donnée (de type EMV par exemple) avec un terminal externe, cette commande étant reçue du terminal externe via les contacts externes 6. Par ailleurs, comme déjà expliqué, le capteur mentionné ci-avant peut par exemple être un capteur optique et/ électromagnétique apte à détecter une attaque optique et/ou magnétique rencontrée par la carte à puce 4, cette attaque étant par exemple perpétrée par une personne ou un dispositif malveillant. La figure 4 représente, de manière schématique, l'architecture matérielle d'un lecteur de carte 30 selon un mode de réalisation particulier de l'invention. Ce lecteur de carte 30 est ici apte à coopérer selon le protocole EMV avec la carte à puce 4. Plus particulièrement, le lecteur de carte 30 comprend un microprocesseur 32, une mémoire morte (de type ROM) 34, une mémoire non volatile réinscriptible 36, une interface homme/machine 38 permettant à un utilisateur d'interagir avec le lecteur 30, un connecteur 40 compatible avec les contacts externes de la carte à puce 4, et une interface de communication 42 permettant au lecteur 30 de communiquer avec une entité externe telle que le serveur distant 45 dans le cas d'espèce. Le serveur distant 45 est ici associé à l'émetteur (typiquement une banque) de la carte à puce 4. La mémoire 36 constitue dans cet exemple un support d'informations conforme à un mode de réalisation de l'invention, lisible par le lecteur 30, et sur lequel est enregistré un programme d'ordinateur PG2 conforme à un mode de réalisation de l'invention. Ce programme PG2 comporte des instructions pour l'exécution des étapes d'un procédé de traitement selon un mode de réalisation de l'invention. Des exemples de réalisation de ce procédé sont représentés ci-après en référence aux figures 7 à 9. La figure 5 représente schématiquement des modules pouvant être mis en oeuvre par le microprocesseur 32 du lecteur 30 exécutant le programme PG2, à savoir : un module d'exécution 48 permettant de démarrer une transaction TR avec la carte à puce 4 (envoi d'un message GPO), un module de réception 50 apte à recevoir une information de sécurité IS contenue dans un message de transaction provenant de la carte à puce 4, un module de traitement 52 apte à réaliser un traitement à partir de l'information de sécurité IS reçue et, éventuellement, un module d'extraction 54 apte à extraire une donnée de référence DRF d'un message reçu de la carte à puce 4 comme décrit plus en détail ultérieurement. Une mise en oeuvre particulière de l'invention est à présent décrite en référence à la figure 6. Plus précisément, la carte à puce 4 met en oeuvre un procédé d'envoi en exécutant le programme PG1. La carte à puce 4 détecte (S2) en premier lieu un évènement EVT. Cet évènement est par exemple représentatif d'une anomalie rencontrée par la carte à puce 4 ou d'une attaque à l'encontre de la carte à puce 4. Dans l'exemple décrit ici, la détection S2 de l'évènement EVT est réalisée par le module de détection 14 illustré en figure 3. Dans un cas particulier, l'évènement EVT satisfait au moins l'une des conditions suivantes : l'évènement EVT cause une réinitialisation de la carte à puce 4; et l'évènement EVT comprend l'exécution par la carte à puce 4 d'une commande ou d'une opération affectant un code PIN (code secret) stocké dans une mémoire sécurisée de la carte à puce 4. Les commandes CHANGE PIN ou UNBLOCK PIN sont des exemples d'une telle commande. Plus généralement, l'évènement EVT détecté (S2) par la carte à puce 4 peut être un quelconque évènement rencontré par la carte à puce 4 et que celle-ci juge digne d'intérêt, ce jugement étant éventuellement réalisé à partir d'au moins une condition préenregistrée dans une règle RL. L'évènement EVT ainsi détecté par la carte à puce 4 peut correspondre à un ou à une pluralité d'évènements. La détection de l'évènement EVT intervient par exemple lors d'une interaction avec un lecteur ou un terminal externe (lors d'une transaction par exemple). Dans un exemple particulier, une commande (de type APDU par exemple) d'un terminal externe est reçue par la carte à puce 4 via les contacts externes 6. Le module de détection 14 (ou plus particulièrement, un premier module de traitement compris dans le module de détection 14) détecte alors l'évènement EVT à partir de la commande reçue ou, éventuellement, à partir d'un traitement réalisé par le premier module de traitement à partir de ladite commande. Alternativement, l'évènement EVT peut être une attaque (de type optique et/ou électromagnétique) à l'encontre de la carte à puce 4, cette attaque étant détectée par le module de détection 14, ce dernier utilisant en particulier un capteur apte à détecter l'attaque et une deuxième module de traitement apte à détecter l'évènement EVT à partir de l'attaque détectée. Dans ce cas, l'attaque n'est donc pas détectée en utilisant les contacts externes 6 (ou tout autre module d'interface de la carte à puce apte à communiquer avec un terminal externe) mais grâce à un capteur approprié de la carte à puce 4, comme déjà expliqué ci-avant. Sur détection de l'évènement EVT, la carte à puce 4 obtient (S4) une information de sécurité IS représentative de cet évènement. Pour ce faire, la carte à puce 4 applique par exemple une règle RL contenue en mémoire 10, cette règle spécifiant pour au moins un évènement donné une information IS à générer. Dans l'exemple décrit ici, l'obtention S4 de l'information de sécurité IS est réalisée par le module d'obtention 16 illustré en figure 3. La carte à puce 4 enregistre (S6) ensuite cette information de sécurité IS en mémoire 10. La carte à puce 4 créée par exemple un fichier (appelé ici fichier LOG) comprenant chaque information de sécurité IS obtenue. Dans l'exemple décrit ici, l'enregistrement S6 est réalisé par le module d'enregistrement 18 illustré en figure 3. On suppose que, après l'enregistrement S6, une transaction de type EMV est démarrée (S8) entre la carte à puce 4 et le lecteur externe 30. Ceci intervient typiquement lorsque la carte 4 est introduite par l'utilisateur dans le lecteur 30 en vue de réaliser une opération bancaire (consultation de compte, paiement, transfert...). Comme déjà indiqué, le protocole EMV est ici mis en oeuvre. Par conséquent, la carte à puce 4 et le lecteur 30 réalisent ensemble la phase préliminaire PHP (échange des messages RST et ATR etc.) déjà décrite en référence à la figure 1. Comme déjà indiqué, la réception par la carte à puce 4 du message GPO provenant du lecteur 30 marque ensuite le début S8 de la transaction EMV. Dans l'exemple décrit ici, c'est le module d'exécution 20 illustré en figure 3 qui réalise la phase préliminaire PHP et qui procède au début S8 de la transaction TR (réception du GPO) avec le lecteur externe 30. Conformément à l'invention, la carte à puce 4 envoie (S10) au lecteur 30 l'information de sécurité IS dans un message de transaction lors de la transaction TR. Divers messages 3 0 3 0 82 5 15 de transaction EMV peuvent être utilisés pour transporter l'information de sécurité IS jusqu'au lecteur 30, comme expliqué plus en détail en référence aux figures 7 à 9. Dans l'exemple décrit ici, l'envoi S10 de l'information de sécurité IS est réalisée par le module d'envoi 22 illustré en figure 3. 5 Dans une mise en oeuvre particulière, la carte à puce 4 prend la décision d'envoyer ou non (510) au lecteur 30, pendant la transaction, une information de sécurité IS stockée en mémoire dans la carte 4, cette décision étant prise en appliquant une règle RL prédéfinie (stockée en mémoire 10) définissant au moins une condition préenregistrée. La carte à puce 4 décide d'envoyer une information de sécurité IS seulement si une condition 10 préenregistrée associée à l'information IS est satisfaite. Dans un exemple particulier, la carte à puce 4 n'est pas capable de poursuivre la transaction TR avec le lecteur 30 une fois l'envoi S10 de l'information de sécurité IS effectué, en raison par exemple d'une attaque ou d'une anomalie rencontrée par la carte. Selon une variante, la carte à puce est apte à poursuive la transaction TR normalement 15 selon le protocole EMV une fois l'information de sécurité IS envoyée (S10) au lecteur 30. La remontée de l'information de sécurité IS lors d'une transaction permet d'informer le lecteur 30, et éventuellement le serveur bancaire 45, de l'occurrence d'un évènement relatif par exemple à une attaque survenue à l'encontre de la carte à puce 4, à un risque de sécurité associé à la carte à puce 4 et/ou à son porteur, ou encore à un comportement 20 observé antérieurement au niveau de la carte à puce 4. A partir de l'information de sécurité IS reçue, le lecteur 30 est capable de réaliser un traitement particulier comme par exemple évaluer un risque lié à la transaction en cours ou transmettre l'information de sécurité IS au serveur distant 45. Plusieurs modes de réalisation du procédé d'envoi mis en oeuvre par la carte à puce 4 25 et du procédé de traitement mis en oeuvre par le lecteur 30 sont à présent décrits en référence aux figures 7 à 9. On suppose dans les modes de réalisation illustrés en figures 7 à 9 que la carte à puce 4 à déjà réalisé les étapes S2 à S8 lorsqu'elle reçoit (E2) un message RST du lecteur 30. Comme indiqué par la suite, on peut toutefois envisager des variantes selon lesquelles 30 au moins l'une des étapes S2 à S6 est réalisée par la carte à puce 4 après la réception par cette dernière du message RST, voire même après le début de la transaction S8. Selon un premier mode de réalisation illustré en figure 7, la carte à puce 4 et le lecteur 30 coopère selon le protocole EMV. Le déroulement du protocole EMV diffère ici de l'exemple décrit en figure 1 en ce 35 que le message RST envoyé par la carte à puce 4 est utilisé pour permettre au lecteur 30 de lire l'information de sécurité IS dans la mémoire de la carte à puce 4 lors de la transaction TR. Dans cet exemple, le lecteur reçoit (E2) un message RST du lecteur 30. En réponse, la carte à puce 4 envoie (E4a) un message ATR modifié, ce message contenant une donnée de référence DRF permettant au lecteur 30 de lire l'information de sécurité IS dans la mémoire sécurisée 10 de la carte à puce 4. Au cours d'une étape E5, le lecteur 30 extrait la donnée de référence DRF du message ATR. Les étapes E6 à E16 sont réalisées comme déjà décrites en référence à la figure 1. En réponse au message EFL envoyé (E16) par la carte à puce 4, le lecteur 30 réalise la lecture (E18-E20a) dans la mémoire de la carte à puce 4 des informations spécifiées dans le message AFL. Dans ce premier mode de réalisation, le lecteur 30 lit en outre l'information de sécurité IS stockée dans la mémoire 10 de la carte à puce 4 en utilisant la donnée de référence DRF. Cette donnée DRF renseigne par exemple sur une adresse mémoire où est stockée l'information de sécurité IS. Le lecteur 30 réalise ensuite un traitement approprié à partir de l'information de sécurité IS reçue. Dans cet exemple, les étapes E24 à E34 sont réalisées comme déjà décrites en référence à la figure 1. Le lecteur 30 transmet (E36a) ensuite, au serveur distant 45, le message ARQC (préalablement reçu de la carte à puce 4 à l'étape E34) ainsi que l'information de sécurité IS. Le serveur distant 45 (ou un autre terminal associé) réalise (E38) ensuite une analyse à partir des informations reçues, y compris si nécessaire l'information de sécurité M. Le lecteur 30 peut également réaliser (E38a) une analyse à partir de l'information de sécurité IS. Suite à cette analyse, le lecteur peut si besoin adapter le traitement de la transaction TR en cours, afin par exemple de rejeter la transaction ou de mettre en oeuvre des mécanismes de sécurité supplémentaires. Les étapes E40 à E44 sont réalisées comme déjà décrites en référence à la figure 1. Selon une variante de ce premier mode de réalisation, la carte à puce 30 transmet la 30 donnée de référence DRF non pas dans le message ATR (E4) mais dans le message APPLICATIONS en E8. On notera que, dans ce premier mode de réalisation, le lecteur 30 est modifié afin d'être capable de reconnaître la donnée de référence DRF incluses dans le message ATR (ou APPLICATIONS) en tant que telle, et de l'utiliser afin de récupérer l'information de 35 sécurité IS de la carte à puce 4. Selon un deuxième mode de réalisation illustré en figure 8, la carte à puce 4 et le lecteur 30 coopère également selon le protocole EMV. Le déroulement du protocole EMV diffère ici du premier mode de réalisation décrit en référence à la figure 7 en ce que la carte à puce 4 transmet (E16a) la donnée de référence DRF directement dans le message de transaction AFL. Le lecteur 30 lit ensuite dans la carte à puce 4 les informations nécessaires, à savoir celles spécifiées dans l'AFL. Pour ce faire, le lecteur 30 envoie (E18b) une ou plusieurs commandes en lecture à la carte à puce 4 à laquelle celle-ci répond en fournissant (E20b) au lecteur 30 les informations demandées. Le lecteur 30 lit en particulier l'information de sécurité IS stockée dans la mémoire 10 de la carte à puce 4 à l'aide de la donnée de référence DRF. Le lecteur 30 transmet (E36b) l'information de sécurité IS au serveur distant 45 et/ou réalise (E38b) une analyse à partir de l'information de sécurité IS de façon analogue aux étapes respectives E36a et E38a précédemment décrites. Selon un troisième mode de réalisation illustré en figure 9, la carte à puce 4 et le lecteur 30 coopère également selon le protocole EMV. Le déroulement du protocole EMV diffère ici des premier et deuxième modes de réalisation décrit en référence aux figures 7 et 8 en ce que la carte à puce 4 transmet (E34c) au lecteur 30, après l'analyse E32, l'information de sécurité IS en tant que IDD (Issuer Discretionnary Data). Cette donnée IDD (comme toutes données IDD) n'est pas interprétable par le lecteur 30 qui se contente de la transmettre (E36c) au serveur distant 45. Ce troisième mode de réalisation met à profit la possibilité offerte par le protocole EMV de fournir des informations en tant que IDD au lecteur puis au serveur distant. Une analyse peut ensuite être réalisé au niveau du serveur distant 45 à partir des informations reçues, y compris de l'information de sécurité IS. Dans ce troisième mode de réalisation, le lecteur 30 réalise (E38c) en outre une analyse à partir de l'information de sécurité IS de façon analogue à l'analyse E38a ou E38b mentionnée ci-avant. On notera que dans les deuxième et troisième modes de réalisation décrit ci-avant en référence aux figures 8 et 9, le lecteur 30 réalise le procédé de traitement de l'invention sans qu'il y ait besoin de modifier le protocole EMV. On utilise en effet le message de transaction AFL ou les informations IDD pour transmettre l'information de sécurité IS au lecteur 30. De plus, dans les premier et deuxième modes de réalisation décrits ci-avant en référence aux figures 7 et 8, le lecteur 30 envoie une commande de lecture à la carte à puce 4 indiquant que le lecteur 30 souhaite accéder à l'information de sécurité 30. Dans le troisième mode de réalisation, en revanche, le lecteur 30 ne sollicite pas l'envoi par la carte à puce 4 de l'information de sécurité IS, et transmet celle-ci en tant que IDD au serveur distant 45 comme déjà indiqué. Selon une mise en oeuvre particulière, au moins l'une parmi l'étape de détection S2, l'étape d'obtention S4 de l'information de sécurité IS et l'étape de stockage S6 de l'information de sécurité IS est réalisée par la carte à puce 4 pendant la phase préliminaire PHP (i.e. après la réception par la carte du message RST provenant du lecteur 30), voire même pendant la transaction TR en cours (i.e. après la réception par la carte du message GPO provenant du lecteur 30). Dans un cas particulier, la carte à puce 4 choisit la méthode de transmission de l'information de sécurité IS parmi plusieurs disponibles (par exemple parmi au moins deux des méthodes décrites ci-avant) en fonction du moment où la carte à puce 4 détecte qu'elle a une information de sécurité IS à transmettre au lecteur. Le choix de la méthode d'envoi peut est réalisé par exemple à l'aide d'au moins une règle RL préenregistrée en mémoire dans la carte à puce 4. Selon un exemple particulier, la carte à puce 4 détecte à un instant Ti qu'elle détient une information de sécurité IS à transmettre, et transmet alors l'information de sécurité IS comme suit : - si Ti est avant l'envoi par la carte à puce 4 de l'ATR, la carte transmet l'information de sécurité IS au lecteur 30 en mettant en oeuvre le premier mode de réalisation illustré en figure 7 (utilisation de l'ATR puis envoi de IS pendant la transaction TR) ; si Ti est après l'envoi de l'ATR mais avant l'envoi du message APPLICATIONS, la carte 4 fournit la donnée de référence DRF au lecteur 30 en utilisant le message APPLICATIONS et envoie par la suite IS pendant la transaction TR (variante du premier mode de réalisation) ; si Ti est après l'envoi de APPLICATIONS mais avant la réception de GPO, la carte 4 envoie la donnée de référence DRF dans le message AFL et envoie par la suite IS pendant la transaction TR (deuxième mode de réalisation illustré en figure 8) ; et si Ti est après la réception de GPO mais avant la réception de GAC, la carte 4 envoie l'information de sécurité IS au lecteur 30 en tant qu'IDD en réponse au GAC (troisième mode de réalisation illustré en figure 9). La présente invention permet avantageusement de remonter efficacement des informations de sécurité depuis une carte à puce (ou plus généralement depuis un dispositif électronique) vers un lecteur (ou terminal) externe afin de permettre la réalisation d'un traitement approprié par le lecteur et, le cas échéant, par un tiers tel que l'émetteur de la carte à puce par exemple. La remontée de telles informations de sécurité permet notamment d'évaluer des risques de sécurité associés à la carte à puce et/ou à la transaction en cours (voire même à une transaction passée), d'identifier de possibles attaques rencontrées dans le passé par la carte à puce ou encore de réaliser des traitements en fonction de certains comportements observés dans le passé au niveau de la carte. Si, par exemple, une commande visant à modifier le code PIN de la carte a été exécutée par la carte à puce ou si cette dernière s'est réinitialiser suite à un évènement donné, l'invention prévoit dans un cas particulier de stocker dans la carte à puce une information de sécurité représentative de cet évènement et de transférer de la carte à puce au lecteur ladite information afin d'en informer ensuite l'émetteur de la carte à puce. L'émetteur, typiquement la banque émettrice de cette carte, peut ainsi analyser le ou les évènements rencontrés par la carte et prendre si besoin les mesures nécessaires comme par exemple contacter le propriétaire de la carte, bloquer la carte ou encore refuser la transaction en cours. L'invention offre un mécanisme souple et efficace pour mettre en oeuvre des analyses de risque et/ou de comportement à partir d'évènements détectés par la carte à puce. L'invention est avantageuse en ce qu'il est possible de mettre en oeuvre la remontée d'information de sécurité vers le lecteur, voire vers le serveur distant sans qu'il soit nécessaire de modifier le déroulement général d'un protocole de type EMV par exemple. 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 particulier, l'homme du métier pourra envisager une quelconque combinaison des variantes et modes de réalisation décrits ci-avant afin de répondre à un besoin bien particulier.30 REVENDICATIONS1. Procédé d'envoi d'une information de sécurité (IS) mis en oeuvre par un dispositif électronique (4), ledit procédé comprenant les étapes suivantes : détection (S2) d'un évènement rencontré par le dispositif électronique ; enregistrement (S6), dans une mémoire sécurisée (10) du dispositif, d'une information de sécurité (IS) représentative dudit évènement ; démarrage (S8), suite audit enregistrement, d'une transaction (TR) avec un terminal externe (30) ; et 10 envoi (S10) au terminal externe de l'information de sécurité (IS) dans un message de transaction (E20a ; E20b ; E34c) lors de ladite transaction (TR). 2. Procédé selon la revendication 1, dans lequel l'évènement détecté par le dispositif électronique (4) comprend au moins l'un parmi : 15 - une anomalie rencontrée par le dispositif électronique ; et - une attaque à l'encontre du dispositif électronique. 3. Procédé selon la revendication 1 ou 2, dans lequel ledit évènement satisfait au moins l'une des conditions suivantes : 20 l'évènement cause une réinitialisation du dispositif électronique (4) ; et l'évènement comprend l'exécution par le dispositif électronique (4) d'une opération affectant un code confidentiel stocké dans une mémoire sécurisée du dispositif électronique. 25 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel un comportement anormal du dispositif électronique ou une attaque à l'encontre dudit dispositif électronique est détecté si au moins une condition préenregistrée dans le dispositif électronique est satisfaite. 30 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel la transaction (TR) et le message de transaction comportant 'Information de sécurité (IS) sont conformes au protocole EMV. 6. Procédé selon la revendication 5, comprenant un envoi au terminal externe, dans 35 un message AFL, d'une donnée de référencement (DRF) permettant au terminal externe(3) de lire l'information de sécurité (IS) dans la mémoire sécurisée (10) du dispositif électronique ; l'information de sécurité (IS) étant envoyée (S10, E20a) au terminal externe en réponse à une commande de lecture (E18a) reçue du terminal externe suite à l'envoi du 5 message AFL. 7. Procédé selon la revendication 5, comprenant l'envoi au terminal externe (30), dans un message ATR, d'une donnée de référencement (DRF) lui permettant de lire l'information de sécurité (IS) dans la mémoire sécurisée (IS) du dispositif électronique. 10 8. Procédé selon la revendication 5, l'information de sécurité étant envoyée (S10, E34c) au terminal externe (30) en tant que donnée non interprétable (IDD) par le terminal externe en réponse à un message GENERATE AC reçu (E30) du terminal externe. 15 9. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes d'un procédé d'envoi selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté par un processeur (5). 10. Support d'enregistrement (10) lisible par un processeur (5) sur lequel est 20 enregistré un programme d'ordinateur (PG1) comprenant des instructions pour l'exécution des étapes d'un procédé d'envoi selon l'une quelconque des revendications 1 à 8. 11. Procédé de traitement mise en oeuvre par un terminal externe (30) à un dispositif électronique (4), ledit procédé comprenant les étapes suivantes : 25 démarrage (E12) d'une transaction (TR) avec le dispositif électronique (4) ; réception (E20a ; E20b ; E34c), en provenance du dispositif électronique, d'un message de transaction contenant une information de sécurité (IS) lors de la transaction (TR), ladite information de sécurité étant représentative d'un évènement détecté par le dispositif électronique ; et 30 traitement (E36a, E38a ; E36b, E38b ; E36c, E38c) de l'information de sécurité. 12. Procédé de traitement selon la revendication 11, dans lequel ledit traitement comprend au moins l'un parmi : - réalisation (E38c) d'une analyse de risque associée à ladite transaction à partir de 35 l'information de sécurité ; et- envoi (E36c) de l'information de sécurité à un serveur distant (45) du terminal externe. 13. Dispositif électronique (4) comprenant : - un module de détection (14) d'un évènement rencontrée par le dispositif électronique ; - un module d'obtention (16) d'une information de sécurité représentative dudit évènement ; - un module d'enregistrement (18), dans une mémoire sécurisée du dispositif, de l'information de sécurité; - un module d'exécution (20) apte à démarrer, suite à l'enregistrement de l'information de sécurité, une transaction avec le terminal externe ; et - un module d'envoi (22) au terminal externe de l'information de sécurité dans un message de transaction lors de ladite transaction. 14. Dispositif selon la revendication 13, dans lequel le module d'exécution (20) est apte à poursuivre jusqu'à son terme la transaction une fois l'information de sécurité envoyée au terminal externe. 15. Dispositif électronique selon la revendication 13 ou 14, le dispositif électronique étant une carte à puce. 16. Dispositif électronique selon l'une quelconque des revendications 13 à 15, le module de détection comprenant au moins l'un parmi : un premier module de traitement apte à détecter ledit évènement à partir d'une commande reçue d'une l'entité externe par un module d'interface du dispositif électronique, ledit module d'interface permettant établir une communication entre le dispositif électronique et ladite entité électronique ; et un capteur apte à détecter une attaque survenant, à l'encontre du dispositif électronique et un deuxième module de traitement apte à détecter ledit évènement à partir de l'attaque détectée. 17. Terminal (30) externe à un dispositif électronique (4), ledit terminàl comprenant : - un module d'exécution (48) apte à démarrer une transaction (TR) avec le dispositif électronique ;un module de réception (50) apte à recevoir du dispositif électronique un message de transaction contenant une information de sécurité (IS) lors de la transaction, ladite information de sécurité étant représentative d'un évènement détecté par le dispositif électronique (4) ; et un module de traitement (52) de l'information de sécurité. 18. Terminal (30) selon la revendication 17, dans lequel ladite transaction (TR) et ledit message de transaction sont conformes au protocole EMV, le terminal comprenant : un module d'extraction (54) apte à extraire, d'un message ATR reçu du dispositif électronique (4) lors de la transaction (TR), une donnée de référencement (DRF) permettant au terminal de lire l'information de sécurité (IS) dans une mémoire sécurisée (10) du dispositif électronique.