FR 3089043 A1 20200529 FR 1872001 A 20181128 Description Titre de l'invention : Dispositif électronique comportant un bus d'interconnexion au format ISO 7816 Technique antérieure [0001] La présente invention se situe dans le domaine des cartes à circuit intégré conformes au standard ISO 7816. [0002] La figure 1 représente l'architecture d'une telle carte 10 conforme à l'état actuel de la technique. Cette carte à microcircuit 10 peut communiquer avec un terminal 100, typiquement un lecteur de carte, conformément au standard ISO 7816, par exemple pour effectuer une transaction bancaire. Cette carte comporte un élément sécurisé 20 conforme au standard EMV ou EMVCo (par la suite, le terme « EMV » désigne indifféremment le standard EMV ou le standard EMVCo). [0003] Dans cet exemple, la carte à circuit intégré 10 comporte un front-end FE, configuré pour envoyer, via des ports PI, P2, P3 dédiés, des commandes aux composants auxquels ce front-end est connecté. Dans l'exemple de la figure 1, le front-end comporte : - un port P2 pour communiquer avec l'élément sécurisé 20 ; - un port PI pour communiquer avec un module SM1, par exemple un capteur biométrique ; - un port P3 pour communiquer avec un module SM2, par exemple un gestionnaire de LED. 100041 Dans une telle architecture, l'élément sécurisé 20 et le front-end FE communiquent conformément au standard 150 7816 ; le front-end FE communique avec chacun des autres modules SM1, SM2 en utilisant un autre protocole. 100051 Cette architecture présente un premier inconvénient en ce qu'elle n'est pas modulaire. Il est nécessaire de revoir entièrement l'architecture de la carte pour ajouter un composant derrière le front-end FE. 100061 Par ailleurs, selon cette architecture, seul le front-end FE est visible du terminal 100 : les communications entre le front-end FE et les autres composants ne sont pas visibles du terminal 100, de sorte qu'il est très difficile, notamment, de débugger un problème de communication entre l'élément sécurisé 20 et les autres composants. 100071 L'invention vise une carte à circuit intégré qui ne présente pas ces inconvénients. Exposé de l'invention [0008] Plus précisément, et selon un premier aspect, l'invention concerne un dispositif élec- tronique compatible avec la norme ISO 7816-4 et comportant un élément sécurisé, au moins un module (par exemple un capteur biométrique, un gestionnaire de LED ou un 2 écran) et une unité de communication permettant au dispositif de communiquer avec un terminal conformément au protocole T=1 de la norme ISO 7816. Ce dispositif est caractérisé en ce que: - il comporte un bus 150 7816 d'interconnexion entre le terminal, l'élément sécurisé et les modules ; - l'élément sécurisé et les modules sont configurés pour pouvoir envoyer et recevoir, sur le bus, des trames conformes au protocole T=1, interprétables par ces composants, niais construites pour être rejetées ou ignorées par le terminal. [0009] Ainsi, et d'une façon générale, l'invention propose un dispositif dans lequel 'élément sécurisé et différents modules sont interconnectés via un lien 150 7816. [0010] Ce dispositif électronique peut être constitué par une carte à circuit intégré par exemple du type de celles configurécs pour réaliser des transactions conformes au standard EMV, ou des cartes d'assurance maladie. Préférentiellement, la carte, ou d'une façon plus générale, le dispositif électronique selon l'invention ne comporte pas de front-end entre le terminal et l'élément sécurisé. [0011] De façon très avantageuse, la carte conforme à l'invention est compatible avec les lecteurs EMV, car l'élément sécurisé et les différents modules peuvent envoyer sur le bus des trames rejetées ou ignorées par le terminal. [0012] Dans un mode de réalisation de les trames construites pour être rejetées ou ignorées par l'élément sécurisé sont conformes au protocole T=1 et utilisent un champ NAD différent de 0 et/ou un code correcteur d'erreur non conforme au protocole T=1 de l'ISO 7816. [0013] Lorsque le terminal est parfaitement compatible avec la norme EMV, il doit rejeter les trames dont le champ NAD est différent de O. Cependant, la Demanderesse a constaté que certains terminaux EMV ne rejettent pas toujours de telles trames. Par conséquent, la Demanderesse privilégie le mode de réalisation dans lequel les trames construites pour être rejetées ou ignorées par l'élément sécurisé utilisent : - à la fois un champ NAD différent de 0 ; et - un code correcteur d'erreur propriétaire non conforme au protocole T=1 de 1'ISO 7816. Ce code d'erreur propriétaire est connu et partagé par l'élément sécurisé et par les modules de la carte. [0014] Dans un mode de réalisation de l'invention, au moins l'élément sécurisé ou un des modules est configuré pour émettre une trame 150-7816 interprétable par le terminal avant que celui-ci ne reçoive un nombre prédéterminé de trames consécutives qui seront rejetées ou ignorées par ce terminal. [0015] Ce mode de réalisation est intéressant lorsque la carte à circuit intégré est utilisée avec un terminal qui rejette une transaction dès qu'il reçoit N trames consécutives qu'il doit ignorer ou rejeter. 3 [0016] Cette trame ISO-7816 interprétable peut être une trame de demande d'attente S(WTX Reg.) (en anglais « Waiting Ti me Extension Request »). [0017] Selon un deuxième aspect, l'invention vise aussi un élément sécurisé pouvant être incorporé dans un dispositif électronique tel que mentionné ci-dessus. Cet élément sécurisé est configuré pour : - communiquer avec un terminal, via un bus 1SO 7816, en utilisant des trames conformes au protocole T=1 de la norme 1SO 7816, ces trames comportant un champ NAD égal à 0 et un code correcteur d'erreur conforme au protocole T=1 1SO 7816 ; et pour - communiquer avec au moins un module du dispositif électronique, via le bus ISO 7816, en utilisant des trames conformes au protocole T=1, ces trames comportant dans un champ NAD l'adresse du module (en temps qu'adresse de source ou de destination selon que le module est émetteur SAD ou destinataire DAD de la trame) et un code correcteur d'erreur propriétaire non conforme au protocole T=1 de l'ISO 7816. [0018] Selon un troisième aspect, l'invention vise un module pouvant être incorporé dans un dispositif électronique tel que mentionné ci-dessus. Ce module est configuré pour communiquer avec un élément sécurisé du dispositif électronique et éventuellement avec au moins un autre module du dispositif électronique, via un bus 1SO 7816, en utilisant des trames conformes au protocole T=1, ces trames comportant l'adresse de l'élément sécurisé ou de l'autre module et un code correcteur d'erreur propriétaire non conforme au protocole T=1 de riso 7816. [0019] Dans une première variante de réalisation, le module selon l'invention ne communique qu'avec l'élément sécurisé. Ainsi, et en particulier, lorsque le module veut envoyer une trame au terminal, il l'envoie au module sécurisé pour que celui-ci la relaie au terminal. [0020] Dans une deuxième variante de réalisation, le module selon l'invention est en outre configuré pour émettre, à destination d'un terminal, des trames conformes au protocole T=1 de la norme ISO 7816, ces trames comportant un champ NAD égal à 0 et un code correcteur d'erreur conforme au protocole T=1 de l'ISO 7816. [0021] L'invention vise aussi un procédé de communication mis en oeuvre par un élément sécurisé. Ce procédé comporte des étapes pour permettre à l'élément sécurisé : - de communiquer avec un terminal, via un bus ISO 7816, en utilisant des trames conformes au protocole T=1 de la norme ISO 7816, ces trames comportant un champ NAD égal à 0 et un code correcteur d'erreur conforme au protocole T=1 de l'ISO 7816. [0022] Ce procédé est caractérisé en ce qu'il comporte des étapes pour permettre à l'élément sécurisé de communiquer avec au moins un module du dispositif électronique, via le bus ISO 7816, en utilisant des trames conformes au protocole T=1, ces trames comportant l'adresse du module et un code correcteur d'erreur propriétaire non conforme au protocole T=1 de l'ISO 7816. [0023] Dans un mode de réalisation, cc procédé comporte au moins : - une étape pour recevoir une trame dudit terminal, cette trame comportant un champ NAD égal à 0 et un code correcteur d'erreur conforme au protocole T=1 de l'ISO 7816 ; et - une étape pour envoyer une trame à un module de la carte, cette trame comportant l'adresse de l'élément sécurisé dans le champ SAD de la trame et l'adresse dudit module dans le champ DAD de la trame, cette trame comportant un code correcteur d'erreur propriétaire ; - une étape pour recevoir une trame d'un module de la carte, cette trame comportant l'adresse de l'élément sécurisé dans le champ DAD de la trame et l'adresse de cc module dans le champ SAD de la trame, cette trame comportant un code correcteur d'erreur propriétaire ; et - une étape pour envoyer une trame au terminal, cette trame comportant un champ NAD égal à 0 et un code correcteur d'erreur conforme au protocole T=1 de l'ISO 7816. [0024] Dans un mode particulier de réalisation, ce procédé comporte une étape pour rejeter une trame si celle-ci comporte un code correcteur d'erreur qui n'est ni conforme au protocole T=1 de l'ISO 7816, ni conforme audit code correcteur d'erreur propriétaire. [0025] L'invention vise aussi un procédé de communication mis en oeuvre par un module pouvant être incorporé dans un dispositif électronique, ce procédé comportant des étapes pour permettre au module de communiquer avec un élément sécurisé du dispositif électronique et éventuellement avec au moins un autre module du dispositif électronique, via un bus ISO 7816, en utilisant des trames conformes au protocole T=1, ces trames comportant dans un champ NAD l'adresse de l'élément sécurisé ou de l'autre module et un code correcteur d'erreur non conforme au protocole T=1 de l'ISO 7816. [0026] Dans un mode de réalisation, ce procédé comporte au moins: - une étape pour recevoir une trame de l'élément sécurisé, cette trame comportant l'adresse de l'élément sécurisé dans le champ SAD de la trame et l'adresse du module dans le champ DAD de la trame, la trame comportant un code correcteur d'erreur propriétaire ; - une étape pour envoyer une trame au module, cette trame comportant l'adresse de l'élément sécurisé dans le champ DAD de la trame et l'adresse dudit module dans le champ SAD de la trame, cette trame comportant un code correcteur d'en-eur propriétaire. [0027] Dans un mode de réalisation, ce procédé comporte en outre une étape pour envoyer une trame à un terminal connecté au bus 150 7816, cette trame comportant un champ NAD égal à 0 et un code correcteur d'erreur conforme au protocole T=1 de l'ISO 7816. [0028] Dans un mode de réalisation, ce procédé comporte une étape pour rejeter une trame si celle-ci comporte un code correcteur d'erreur qui n'est ni conforme au protocole T=1 de l'ISO 7816, ni conforme au code correcteur d'erreur propriétaire. [0029] Dans un mode particulier de réalisation, les différentes étapes des procédés de com- munication selon l'invention sont déterminées par des instructions de programmes d'ordinateurs. [0030] En conséquence, l'invention vise aussi un programme d'ordinateur, sur un support d'informations, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de communication tel que mentionné ci-dessus. [0031] Cc 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 objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0032] L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. [0033] 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 un disque dur. [0034] 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 pal- d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0035] Alternativement, le support d'informations peut être 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 [0036] D'autres caractéristiques et avantages de la présente invention ressortiront de la des- cription faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : [0037] [fig.]] la figure 1 déjà décrite représente une carte à circuit intégré conforme à l'art antérieur [0038] [fig.2] 6 la figure 2 représente un dispositif électronique conforme à un mode particulier de réa- lisation de l'invention ; [0039] [fig.3] la figure 3 représente une trame T conforme au protocole T=1 ; [0040] [fig.4A] la figure 4A illustre des échanges de trames dans un exemple de mise en oeuvre de l' invention ; [0041] [fig.4B] la figure 4B illustre sous forme d'organigramme les principales étapes d'un procédé mis en oeuvre par un élément sécurisé conforme à l'invention selon un mode de réa- lisation ; [0042] [fig.4C] la figure 4C illustre sous forme d'organigramme les principales étapes d'un procédé mis en oeuvre par un module conforme à l'invention selon un mode de réalisation ; [0043] [fig.5] la figure 5 représente une variante de mise en oeuvre de l'invention; et [0044] [fig.6] la figure 6 représente une autre variante de mise en oeuvre de l'invention. Description des modes de réalisation [0045] La figure 2 représente un dispositif électronique 10 conforme à un mode particulier de réalisation de l'invention. [0046] Dans le mode de réalisation décrit ici, cc dispositif électronique est une carte à circuit intégré 10 conforme au standard ISO 7816. Cette carte 10 comporte un module 20 configuré pour réaliser des transactions conformes au standard EMV. Le module 20 constitue un élément sécurisé. Il sera indifféremment appelé par la suite « module EMV » ou « élément sécurisé ». Il contient notamment un processeur cryptographique 21, une mémoire de stockage 23, une mémoire non volatile réinscriptible de type Flash 22, et une mémoire d'exécution 24. Il contient des clés cryptographiques et des applications personnalisées utilisant ces clés, notamment des applications bancaires permettant d'effectuer des transactions avec des terminaux EMV, par exemple des lecteurs de cartes, des terminaux de paiement ou des points de vente. La mémoire de stockage 23 comporte un programme d'ordinateur PG1 comportant des instructions permettant de mettre en oeuvre les étapes EXX décrites ultérieurement en référence aux figures 4A et 4B. L'élément sécurisé 20 est configuré comme de façon connue pour négocier une vitesse de communication (connue sous l'acronyme PPS dans la norme ISO 7816) avec un terminal EMV. [0047] La carte à microcircuit 10 comporte en outre des modules SMi, dont par exemple un 7 capteur biométrique SM1 et un gestionnaire de LED SM2. L'invention peut être utilisée avec n'importe quel type de module. Sur la figure 2, seul le module SM1 est représenté en détails, niais l'architecture matérielle et logicielle des autres modules, en ce qui concerne les fonctions relatives à l'invention, peut être identique à celle du module SM1. [0048] Le module SM1 comporte un processeur 31, une mémoire vive de type RAM 32, une mémoire de stockage 33 et une mémoire non volatile réinscriptihle de type Flash 34. La mémoire de stockage 33 comporte un programme d'ordinateur PG2 comportant des instructions permettant de mettre en oeuvre les étapes FXX décrites ultérieurement en référence aux figures 4A et 4C. [0049] La carte à microcircuit 10 comporte une unité de communication 50. Elle permet à la carte 10 de communiquer avec un terminal EMV 100. Cette unité de communication 50 comporte notamment les contacts définis par la norme 1SO 7816-2. Dans le mode de réalisation décrit ici, cette unité de communication comporte une unité 51 de communication à champ proche de type NFC. [0050] L'unité de communication 50, l'élément sécurisé 20 et les différents modules SMi sont interconnectés par un bus 70. Les modules SMi communiquent sur cc bus ISO 7816 en respectant la vitesse PPS négociée entre le terminal et l'élément sécurisé 20. [0051] Ce bus 70 est un lien ISO 7816. Toutes les trames qui circulent sur ce bus sont conformes au protocole T=1 défini par la norme ISO 7816 et dans la spécification EMV Book. Les trames qui circulent sur le bus sont reçues par tous les éléments connectés au bus 70 (terminal EMV 100, élément sécurisé 20, modules SMi). [0052] La figure 3 représente une trame T conforme au protocole T=1. Une telle trame comporte un champ prologue obligatoire PF (en anglais « Prologue field »), un champ d'information optionnel IF (en anglais « Information field ») et un champ épilogue obligatoire EP (en anglais « Epilogue field »). [0053] La champ prologue PF comporte un champ d'adresses NAD (en anglais « Node Ad- dressing Byte »), un champ PCB de contrôle du protocole (en anglais « Protocol Control Byte ») et un champ de longueur LEN. [0054] Le champ d'adresses NAD comporte un champ d'adresse source SAD (en anglais Source Node Address») qui permet d'identifier la source de la trame et un champ d'adresse destination DAD (en anglais « Destination Node Address ») qui permet d'identifier la destination de la trame. [0055] Conformément à la norme EMV, toute trame T avec un champ d'adresse NAD non nul doit être considérée comme invalide. [0056] Par conséquent, le terminal 100 étant conforme à la norme EMV : - toute trame T émise par ce terminal comporte un champ NAD égal à 0 ; et - toute trame T reçue par ce terminal et comportant un champ NAD différent de 0 8 doit être rejetée par cc terminal. [0057] Le champ épilogue EP comporte un code de détection d'erreur de type LRC (sur 1 octet) ou de type CRC (sur 2 octets). [0058] Conformément à l'invention : - toute trame émise ou reçue par le terminal EMV 100 doit comporter un code de détection d'erreur conforme au protocole T=1 de la normelSO 7816 ; - les communications entre l'élément sécurisé 20 et les modules SMi ou entre les modules SMi utilisent un code de détection d'erreur propriétaire, différent du code de détection d'erreur conforme au protocole T=1 de la norme ISO 7816. [0059] Conformément à la norme EMV, le terminal EMV 100 ne communique qu'avec l'élément sécurisé 20. [0060] Conformément au protocole T=1 de la norme ISO 7816, lorsque le terminal EMV 100 n'arrive pas à décoder une trame T, il répond par une trame R(NACK). Ceci peut se produire : - soit parce que le terminal EMV 100 reçoit une trame avec un champ NAD différent de 0; - soit parce que le terminal EMV 100 reçoit une trame avec un code de détection d'erreur 1SO 7816 du protocole T=1 erroné. [0061] Dans le mode de réalisation décrit ici, nous supposerons que lorsque le terminal EMV 100 reçoit N (par exemple 2) trames erronées consécutives, il rejette la transaction. [0062] Dans ce mode de réalisation, l'élément sécurisé 20 et chacun des modules SMi sont configurés pour pouvoir émettre une trame IS0-7816 interprétable par le terminal EMV 100, après chaque trame erronée reçue par ce terminal pour que celui-ci ne reçoive pas deux trames erronées consécutives. Dans le mode de réalisation décrit ici, la trame utilisée à cet effet est une trame de demande d'attente S(WTX Req.). [0063] Par ailleurs, nous rappelons que le protocole T=1 est un protocole de communication de type half-duplex, ce qui signifie que chacun des éléments étant alternativement émetteur et récepteur. Par conséquent, le terminal 100, l'élément sécurisé 20 et chacun des modules SMi : - passe en mode récepteur lorsqu'il attend une trame ; et - passe en mode émetteur pour envoyer une trame. [0064] En référence aux figures 4A, 4B et 4C, nous allons maintenant décrire un exemple de mise en oeuvre d'un premier mode de réalisation de l'invention. [0065] Dans la suite de la description, la notation « ETTR » désigne l'occurrence de l'étape ET pour le traitement de la trame TR. [0066] Nous supposerons que la vitesse PPS de communication sur le bus ISO 7816 70 a été négociée entre le terminal 100 et l'élément sécurisé 20 au cours d'une étape E0. 9 [0067] Nous supposerons également que l'élément sécurisé 20 s'est attribué une adresse AD_20 et qu'il a attribué une adresse AD SMI à chacun des modules SMi au cours d'une étape El . [0068] Dans ce premier mode de réalisation : - toute trame envoyée par l'élément sécurisé 20 à un module SMi comporte l'adresse AD_20 dans le champ SAD et l'adresse AD_SMi dans le champ DAD et utilise le code correcteur d'erreur propriétaire ; - toute trame envoyée par un module SMi à l'élément sécurisé 20 comporte l'adresse AD_SMi dans le champ SAD et l'adresse AD_20 dans le champ DAD et utilise le code correcteur d'erreur propriétaire ; - toute trame envoyée par un module SMi à un autre module SMj comporte l'adresse AD_SMi dans le champ SAD et l'adresse AD SMj dans le champ DAD et utilise le code correcteur d'erreur propriétaire ; - toute trame envoyée par l'élément sécurisé 20 au terminal 100 comporte un champ NAD égal à 0 et utilise le code correcteur d'erreur conforme au protocole T=1 de la norme ISO-7816 ; - toute trame envoyée par le terminal 100 à l'élément sécurisé 20 comporte un champ NAD égal à 0 et utilise le code correcteur d'erreur conforme au protocole T=1 de la norme ISO-7816 ; - le terminal 100 n'envoie pas de trame aux modules SMi ; et - les modules SMi n'envoient pas de trames au terminal 100. [0069] Dans cet exemple, nous supposerons que le terminal EMV 100 envoie une trame TI de type I-Block à l'élément sécurisé 20 pour obtenir une information du module SM1. [0070] Le terminal EMV 100 envoie cette trame d'information T=1 au cours d'une étape D2T1. Cette trame Tl adressée à l'élément sécurisé 20 comporte un champ NAD égal à 0, un champ d'information INF représentant l'information demandée et un code de correction d'erreur conforme au standard ISO 7816. [0071] 1/ Traitement de la trame TI envoyée par le terminal 100 à l'étape D2 (i) L'élément sécurisé 20 et chacun des modules SMi est configuré en mode récepteur. L'élément sécurisé reçoit la trame TI au cours d'une étape E2T, et chacun des modules SMi reçoit cette trame TI au cours d'une étape F2T1 ; (ii) Au cours de cette même étape F2TI, chaque module SMi vérifie si le code de correction d'erreur de la trame Ti est conforme au protocole T=1 du standard ISO 7816. En l'occurrence c'est le cas et l'étape F2T1 est suivie par un test F4T1. Au cours du test F411, chaque module SMi vérifie si la trame TI est une réponse à une trame de demande d'attente S(WTX Req.). Comme aucun de ces modules SMi n'a formulé une demande d'attente S(WTX Req.), chacun ignore la trame TI (étape F6T1). (iii) Au cours de l'étape E2T1, l'élément sécurisé 20 vérifie si le code de correction d'erreur de la trame Ti est conforme au protocole T=1 du standard ISO 7816. En l'occurrence c'est le cas et l'étape F2,1 est suivie par une étape de traitement E4'. Au cours de cette étape E41, l'élément sécurisé traite la demande comprise dans le champ d'information TF de la trame Ti. Cc traitement consiste dans cc cas à envoyer une trame T-Block T2 au module SM1. L'élément sécurisé 20 passe en mode émetteur et effectue cet envoi (étape E41o). Cette trame T2 comporte un champ SAD comportant l'adresse de l'élément sécurisé 20, un champ DAD comportant l'adresse du module SM1, un champ d'information TNF représentant l'information demandée à l'origine par le terminal 100 et un code de correction d'erreur propriétaire. [0072] 2. Traitement de la trame T2 envoyée par l'élément sécurisé 20 à l'étape E4 12 (i) La trame T2 est reçue par le terminal EMV 100 et considérée erronée par cc terminal, d'une part car elle ne comporte pas un champ NAD égal à 0 et d'autre part car son code de correction d'erreur n'est pas conforme au standard ISO 7816. Lc terminal 100 envoie donc une trame T3 R(NACK), au cours d'une étape D4n. (ii) Chacun des modules SMi reçoit la trame T2 au cours d'une étape FIN et vérifie si le code de correction d'erreur de cette trame est conforme au protocole T=1 du standard ISO 7816. En l'occurrence ce n'est pas le cas car la trame a été émise par l'élément sécurisé 20 ; l'étape F2 est suivie par un test F5T2 au cours duquel le module SMi vérifie si le code correcteur d'erreur est conforme au code propriétaire. Si ce n'est pas le cas, la trame est rejetée (étape F5T2). Si le code correcteur d'erreur est conforme au code propriétaire, l'étape F5T2est suivie par une étape F8T2. Au cours de ce test F8T2, chaque module SMi vérifie si la trame T2 lui est destinée en comparant son adresse avec l'adresse contenue dans le champ DAD. Pour les modules SM2, SMn ce n'est pas le cas et ils ignorent la trame T2 (étape F6T2). Pour le module SMI, le résultat du test F8T2 est positif. Il mémorise (étape Flan) la demande T2 pour un traitement ultérieur et positionne une variable DEMT2 à « Vrai ». Dans le mode de réalisation décrit ici, cette variable DEMT2 représentative du traitement en attente de la demande T2 est enregistrée dans la mémoire volatile 32 de ce module. Dans le mode de réalisation décrit ici, le module SMI attend, avant de poursuivre son traitement, la réception d'une trame S(WTX Rep.) (en anglais « Wait Time Extension Response ») qui sera envoyée par le terminal EMV 100 en réponse à une demande d'attente S(WTX Req.) que va faire l'élément sécurisé 20 pour éviter un rejet de la transaction par le terminal 100 lorsque celui-ci détecte la trame T2. [0073] 3/ Traitement de la trame T3 R(NACK) envoyée par le terminal 100 à l'étape D4T3 (i) L'élément sécurisé 20 reçoit la trame T3 R(NACK) au cours d'une étape E2T3 et vérifie si le code de correction d'erreur de cette trame est conforme au protocole T=1 du standard ISO 7816 (étape E2). En l'occurrence c'est le cas et la trame R(NACK) est 11 traitée au cours d'une étape E414. Ce traitement consiste à envoyer une trame T4 de demande d'attente S(WTX Req.) au terminal 100, cc afin de s'assurer que le terminal EMV 100 ne recevra pas deux trames consécutives qu'il ne pourra pas interpréter. (ii) Les modules SM2 à SMn ignorent la trame T3 (étapes F213. F413, F613). Le module SM1 reste en attente d'une trame S(WTX Rep.) en provenance du terminal EMV 100. [0074] 4/ Traitement de la trame T4 de demande d'attente envoyée par l'élément sécurisé 20 à l'étape E4 14 (i) Le terminal 100 reçoit la trame T4 de demande d'attente (étape D6,4) et y répond comme de façon connue, par l'envoi d'une trame T5 de réponse S(WTX Rep.) au cours d'une étape D815. (ii) Les modules SM2 à SMn déterminent au cours de l'étape F2T4 que le code correcteur d'erreur de la trame T4 est un code ISO 7816 T=1 et ignorent cette trame (étape F61-6) car ils n'attendent pas de réponse S(WTX Rep.) (étape F4T6). Le module SM1 reste en attente d'une trame S(WTX Rep.) (étape F4T.4) en provenance du terminal EMV 100. [0075] 5/ Traitement de la trame T5 de réponse S(WTX Rcp.) envoyée par le terminal 100 à l'étape D8 T5 (i) L'élément sécurisé 20 reçoit la trame T5 à l'étape E2, Le traitement de cette trame S(WTX Rep.) consiste à ne rien faire (étape E4T5). (ii) Les modules SMi détectent au cours de l'étape F2T, que le code correcteur d'erreur de la trame T5 est un code ISO 7816 T=I et au cours du test F4,-5 que la trame T5 est une réponse S(WTX Rep.) à une demande d'attente WTX. Les modules SM2 à SMn n'attendent pas une telle trame et ils l'ignorent (étape F6T5). En revanche, le module SMI qui était en attente de cette trame peut poursuivre son traitement. Il détermine à l'étape F12T5 qu'il a une demande en attente (suite à la réception de la trame T2), et il commence le traitement de cette demande au cours d'une étape F14, Ce traitement peut consister : - soit à envoyer directement une réponse à la demande ; - soit, si le module SM1 considère que le traitement peut être trop long, et afin d'éviter que le terminal 100 ne rejette la transaction, à envoyer une demande d'attente S(WTX Req.) à l'élément sécurisé 20 pour que celui-ci la relaie au terminal EMV 100. Nous supposerons que c'est le cas dans cet exemple et que le module SM1 envoie une trame T6 de demande d'attente S(WTX Req.) à l'élément sécurisé 20 (étape Fl4T6). Il se place alors en attente d'une réponse S(WTX Rep.) en provenance du module sécurisé 20. [0076] 6/ Traitement de la trame T6 de demande d'attente S(WTX Req.) envoyée par le module SMI à l'étape F14 T6 12 (i) La trame T6 est reçue par le terminal EMV 100 et considérée erronée par ce terminal. Le terminal 100 envoie donc une trame T7 R(NACK), au cours d'une étape Dl a[7. (ii) Les modules SM2 à SMn ignorent cette trame T6 qui ne leur est pas destinée (étapes F217, F517, F817, F617). (iii) L'élément sécurisé 20 reçoit la trame T6 à l'étape E2, et détermine que le code correcteur d'erreur n'est pas conforme à celui du protocole T=1 de l'TSO 7816. Il vérifie au cours d'une étape E6' que le code correcteur d'erreur est conforme au code correcteur propriétaire. Si ce n'était pas le cas, il ne traiterait pas cette trame T6 (étape E7). Si le code correcteur d'erreur est conforme au code correcteur propriétaire, l'élément sécurisé 20, détermine s'il est destinataire de la trame T6 en comparant son adresse à celle contenue dans le champ DAD (étape ElOn). Si ce n'était pas le cas, il ne traiterait pas cette trame T6 (étape E7). Si l'élément sécurisé 20 détermine qu'il est destinataire de la trame T6 (test El 0,), il vérifie si cette trame est de type 1-Block (étape E12T6). Si c'est le cas, il mémorise dans un indicateur RPT2 le fait qu'il a reçu une réponse du module SM1 en réponse à sa trame T2 (étape E14). Dans le mode de réalisation décrit ici, cet indicateur RPT2, est enregistré dans la mémoire Flash 22 de l'élément sécurisé 20. En l'occurrence, l'élément sécurisé 20 n'a pas reçu de réponse à sa trame T2 et l'élément sécurisé 20 vérifie si cette trame T6 est une trame de demande d'attente S(WTX Req.) (étape E16,). Si ce n'est pas le cas, il envoie une trame R(NACK) l'émetteur de la trame (étape E18). Dans le cas présent, la trame T6 est une trame S(WTX Req.). L'élément sécurisé 20 sait que cette trame sera rejetée par une réponse R(NACK) par le terminal EMV 100. Par conséquent, l'élément sécurisé 20 : - attend de recevoir cette réponse R(NACK) (voir étape E19) ; - pour envoyer (voir étape E20), sur réception du R(NACK), une demande d'attente S(WTX Req.) au terminal EMV 100 ; - puis attendre la réponse S(WTX Rep.) du terminal EMV 100 pour la transférer au module SMI (voir étape E22). [0077] 7/ Traitement de la trame T7 R(NACK) envoyée par le terminal EMV 100 à l'étape DIO , (i) L'élément sécurisé 20 reçoit la trame T7 qu'il attendait (étape E19n) et envoie (étape E20rg) une trame T8 de demande d'attente S(WTX Req.) au terminal 100. (ii) Les modules SM2 à SMn ignorent la trame T7 (étapes F21-7, F417, F617). Suite à l'envoi de sa trame T6, le module SMI reste en attente d'une réponse S(WTX Rep.) en provenance du module sécurisé 20. 13 [0078] 8/ Traitement de la trame T8 de demande d'attente S(WTX Reg.) envoyée par l'élément sécurisé 20 à l'étape E20 fs (i) Le terminal EMV 100 reçoit cette trame au cours d'une étape D12,, et y répond par l'envoi d'une trame T9 de réponse R(WTX Rep.) au cours d'une étape D1419. (ii) Les modules SM2 à SMn ignorent la trame T7 (étapes E21s, E418, F618). Suite à l'envoi de sa trame T6, le module SM1 reste en attente d'une réponse S(WTX Rep.) en provenance du module sécurisé 20. [0079] 9/ Traitement de la trame T9 de réponse R(WTX Rep.) à une demande d'attente envoyée par le terminal 100 à l'étape D14 10 (i) L'élément sécurisé 20 reçoit la trame T9 qu'il attendait (étape E22'). Il envoie par conséquent une trame T10 S(WTX Rep.) en réponse à la trame T6 au cours d'une étape E22, (ii) Les modules SM2 à SMn ignorent la trame T9 (étapes E219, F419, F619). Suite à l'envoi de sa trame T6, le module SM1 reste en attente d'une réponse S(WTX Rep.) en provenance du module sécurisé 20. [0080] 10/ Traitement de la trame T10 S(WTX Rep.) envoyée par l'élément sécurisé 20 à l'étape E22 (i) La trame T10 est reçue par le terminal EMV 100 et considérée erronée par ce terminal. Le terminal 100 envoie donc une trame T11 R(NACK), au cours d'une étape D16T11. (ii) Les modules SM2 à SMn ignorent cette trame TIO qui ne leur est pas destinée (étapes F2,-10, F5110, FBTin, F6T10). Le module SM1 détermine que cette trame T10 est une réponse de l'élément sécurisé 20 à sa trame T6. Dans le mode de réalisation décrit ici, le module SM1 attend, avant de poursuivre son traitement, la trame de réponse S(WTX Rep.) qui sera envoyée par le terminal EMV 100 en réponse à la demande d'attente S(WTX Req.) que va faire l'élément sécurisé 20 pour éviter que le terminal ne rejette la transaction sur détection de la trame TIO. [0081] 11/ Traitement de la trame T11 R(NACK) envoyée par le terminal 100 à l'étape D16 TI I (i) L'élément sécurisé 20 reçoit la trame T16 R(NACK) au cours d'une étape E2,11 et y répond en envoyant (étape E4T12) une trame T12 de demande d'attente S(WTX Req.) au terminal 100, ce afin de s'assurer que le terminal EMV 100 ne recevra pas deux trames non interprétables par lui consécutives. (ii) Les modules SM2 à SMn ignorent la trame T11 (étapes F2111, F4111, F6Tu). Le module SM1 reste en attente d'une trame S(WTX Rep.) en provenance du terminal EMV 100. [0082] 12/ Traitement de la trame T12 de demande d'attente S(WTX Req.) envoyée par 14 l'élément sécurisé 20 à l'étape E4 un (i) Le terminal 100 reçoit la trame T12 de demande d'attente (étape D1811,) et y répond comme de façon connue, par l'envoi d'une trame T13 de réponse S(WTX Rep.) au cours d'une étape D20113. (ii) Les modules SM2 à SMn déterminent au cours de l'étape F2,1, que le code correcteur d'erreur de la trame T12 est un code ISO 7816 T=1 et ignorent cette trame (étape F611,) car ils n'attendent pas de réponse S(WTX Rep.) (étape F4112). Le module SM1 reste en attente d'une trame S(WTX Rep.) en provenance du terminal EMV 100. [0083] 13/ Traitement de la trame T13 de réponse S(WTX Rep.) envoyée par le terminal 100 à l'étape D20 113 (i) L'élément sécurisé 20 reçoit la trame T13 à l'étape E2113. Le traitement de cette trame S(WTX Rep.) consiste à ne rien faire (étape E4113). (ii) Les modules SMi détectent au cours de l'étape F2T,3 que le code correcteur d'erreur de la trame T5 est un code ISO 7816 T=1 et au cours du test F415 que la trame T5 est une réponse S(WTX Rep.) à une demande d'attente WTX. Les modules SM2 à SMn n'attendent pas une telle trame et ils l'ignorent (étape F6T13 ). En revanche, le module SM1 était en attente de cette trame peut poursuivre son traitement. Il détermine à l'étape F12,13 qu'il a une demande en attente (suite à la réception de la trame T2), et il poursuit traitement de cette demande au cours d'une étape F14,13. Dans le cas présent le module SM1 est maintenant en mesure de terminer rapidement le traitement de la demande reçue dans la trame T2. Par conséquent, le module SMI n'envoie pas de demande d'attente S(WTX Rep.) mais une trame T14 de type I-Block comportant la réponse à cette demande (étape F14,14). [0084] 14/ Traitement de la trame T14 de type I-Block envoyée par le module SM1 à l'étape F14 T14 (i) La trame T14 est reçue par le terminal EMV 100 et considérée erronée par ce terminal. Le terminal 100 envoie donc une trame T15 R(NACK), au cours d'une étape D22T15. (ii) L'élément sécurisé 20 détermine que le code correcteur d'erreur de la trame T14 est propriétaire (étapes E21-14 et E6m), qu'il est destinataire de la trame T14 (test EIOT14 ), et que cette trame est de type I-Block (étape E12114). Il détermine par conséquent que la trame T14 constitue une réponse à la trame T2 et positionne donc l'indicateur RPT2 à VRAI (étape E14114). Puis, l'élément sécurisé 20 : - attend de recevoir une réponse R(NACK) (étape E31) ; - pour envoyer (étape E32), sur réception du R(NACK), une demande d'attente S(WTX Req.) au terminal EMV 100 et attendre la réponse S(WTX Rep.) du terminal EMV 100 (étape E33). (iii) Les modules SM2 à SMn ignorent la trame T14 qui ne leur est pas destinée (étapes F2,14, F5114, F8114, F6 14). [0085] 15/ Traitement de la trame T15 R(NACK) envoyée par le terminal EMV 100 à l'étape D22T15 (i) L'élément sécurisé 20 reçoit la trame T15 qu'il attendait (étape E31T15) et envoie (étape E32T16) une trame T16 de demande d'attente S(WTX Req.) au terminal 100. (ii) Les modules SM1 à SMn ignorent la trame T15 (étapes F2T15, F4 T15, F6 T15). [0086] 16/ Traitement de la trame T16 de demande d'attente S(WTX Reg.) envoyée par l'élément sécurisé 20 à l'étape E32 Tre (i) Le terminal EMV 100 reçoit cette trame au cours d'une étape D24,16 et y répond par l'envoi d'une trame T17 de réponse R(WTX Rep.) au cours d'une étape D26,17. (ii) Les modules SM1 à SMn ignorent la trame T16 car aucun n'est en attente d'une réponse S(WTX Rcp.) en provenance du terminal 100 (étapes F2 r 16, F4116, F6116)- [0087] 17/ Traitement de la trame T17 de réponse R(WTX Rcp.) à une demande d'attente envoyée par le terminal 100 à l'étape D26T17 (i) Les modules SM1 à SMn ignorent la trame T17 car aucun n'est en attente d'une réponse S(WTX Rcp.) en provenance du terminal 100 (étapes F2ri7, F4117, F6T 17). (ii) L'élément sécurisé 20 reçoit (étape E3317) la trame T17 qu'il attendait. Cette étape E33 est suivie par l'étape EST 17 au cours de laquelle l'élément sécurisé 20 détermine par lecture de la variable RPT2 qu'il a reçu une réponse du module SM1 en réponse à sa trame T2. L'élément sécurisé envoie une trame I-Block T18 au terminal EMV 100 au cours d'une étape E40T 1g. Cette trame comporte dans son champ IF, la réponse à la demande exprimée par le terminal EMV 100 dans sa trame Tl. [0088] Variantes [0089] Dans le mode de réalisation décrit précédemment, les modules SMi ne com- muniquent pas avec le terminal EMV 100. [0090] En variante, ils peuvent envoyer des trames T=1 au terminal EMV 100 en posi- tionnant dans ces trames le champ NAD à 0 et en utilisant un code correcteur d'erreur conforme au protocole T=1 de l'ISO 7816. [0091] Ainsi, en variante : - toute trame envoyée par l'élément sécurisé 20 à un module SMi comporte l'adresse AD_20 dans le champ SAD et l'adresse AD_SMi dans le champ DAD et utilise le code correcteur d'erreur propriétaire - toute trame envoyée par un module SMi à l'élément sécurisé 20 comporte l'adresse AD_SMi dans le champ SAD et l'adresse AD_20 dans le champ DAD et utilise le 16 code correcteur d'erreur propriétaire ; - toute trame envoyée par un module SMi à un autre module SMj comporte l'adresse AD SMi dans le champ SAD et l'adresse AD SMj dans le champ DAD et utilise le code correcteur d'erreur propriétaire ; - toute trame envoyée par l'élément sécurisé 20 au terminal 100 comporte un champ NAD égal à 0 et utilise le code correcteur d'erreur conforme au protocole T=1 de l'ISO-7816 ; - toute trame envoyée par le terminal 100 à l'élément sécurisé 20 comporte un champ NAD égal à 0 et utilise le code correcteur d'erreur conforme au protocole T=1 de l'ISO-7816 ; - toute trame envoyée par un module SMi au terminal EMV 100 comporte un champ NAD égal à 0 et utilise le code correcteur d'erreur conforme au protocole T=1 de l'ISO-7816 ; et - le terminal 100 n'envoie pas de trame aux modules SMi. [0092] Par exemple, dans un mode de réalisation représenté à la figure 5, lorsque le module SMi détecte une trame T3 R(NACK) adressée à l'élément sécurisé 20, il génère lui-même une trame de demande d'attente S(WTX Req.) avec un champ NAD à 0 et un code correcteur d'erreur conforme au protocole T=1 de l'ISO 7816. Il attend ensuite la réponse à cette demande (trame T7) pour émettre la prochaine trame sur le bus ISO 7816. [0093] Encore en variante, et comme représenté à la figure 6, le module SMi peut spon- tanément envoyer une trame T6 de demande d'attente S(WTX Req.) avec un champ NAD à 0 et un code correcteur d'erreur conforme au protocole T=1 de 1'ISO 7816, s'il considère qu'il a besoin de temps pour traiter une demande et attendre la réponse à cette demande (trame T7) pour poursuivre son traitement. 17