FR3090947A1 - Dispositif à multiples interfaces de communication et procédé correspondant - Google Patents

Dispositif à multiples interfaces de communication et procédé correspondant Download PDF

Info

Publication number
FR3090947A1
FR3090947A1 FR1873537A FR1873537A FR3090947A1 FR 3090947 A1 FR3090947 A1 FR 3090947A1 FR 1873537 A FR1873537 A FR 1873537A FR 1873537 A FR1873537 A FR 1873537A FR 3090947 A1 FR3090947 A1 FR 3090947A1
Authority
FR
France
Prior art keywords
command
identifier
management unit
communication protocol
processing unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1873537A
Other languages
English (en)
Other versions
FR3090947B1 (fr
Inventor
Marco DE OLIVEIRA
Aissa Waknioun
Ludovic Martin-Martinasso
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Idemia France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idemia France SAS filed Critical Idemia France SAS
Priority to FR1873537A priority Critical patent/FR3090947B1/fr
Publication of FR3090947A1 publication Critical patent/FR3090947A1/fr
Application granted granted Critical
Publication of FR3090947B1 publication Critical patent/FR3090947B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/77—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/0723—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips the record carrier comprising an arrangement for non-contact communication, e.g. wireless communication circuits on transponder cards, non-contact smart cards or RFIDs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
    • G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
    • G06K7/10118—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves the sensing being preceded by at least one preliminary step
    • G06K7/10138—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves the sensing being preceded by at least one preliminary step the step consisting of determining the type of record carrier, e.g. to determine if the record carrier is an RFID tag of the long or short range type, or to determine the preferred communication protocol of the RFID tag
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
    • G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
    • G06K7/10297—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves arrangements for handling protocols designed for non-contact record carriers such as RFIDs NFCs, e.g. ISO/IEC 14443 and 18092
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/354—Card activation or deactivation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3574—Multiple applications on card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Toxicology (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Electromagnetism (AREA)
  • General Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Telephonic Communication Services (AREA)
  • Telephone Function (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L’invention vise un procédé de routage mis en œuvre dans une carte à puce (CD1) coopérant avec un terminal (T1) pour traiter une transaction (TR1), la carte à puce comprenant : une unité de gestion (U2) et une unité de traitement (U1) ; le procédé comprenant : réception, par l’unité de traitement (U1), d’une première commande (CMD1) depuis le terminal (T1) selon un premier protocole de communication externe (PE1) ; extraction, par l’unité de traitement (U1) d’un premier identifiant (ID1) d’une application ; détermination, à partir du premier identifiant (ID1) et à partir du premier protocole de communication externe (PE1), d’un deuxième identifiant (ID2) désignant un premier module d’exécution (MX1) de l’unité de gestion (U2) ; génération d’une deuxième commande (CMD2) comportant le deuxième identifiant (ID2) ; et transmission à l’unité de gestion (U2) de la deuxième commande selon un unique protocole de communication interne (PI). Figure pour l’abrégé : Fig. 2.

Description

Description
Titre de l'invention : Dispositif à multiples interfaces de communication et procédé correspondant
Domaine technique
[0001] L’invention se situe dans le domaine des dispositifs électroniques et porte plus particulièrement sur la gestion dans un dispositif électronique, tel qu’une carte à puce, d’une pluralité d’interfaces de communication pour communiquer avec l’extérieur selon différents protocoles de communication.
Technique antérieure
[0002] L’utilisation des cartes à puce (ou cartes à microcircuit) est aujourd’hui largement répandue dans la vie quotidienne. Les cartes à puce peuvent être conçues pour réaliser divers types de fonctions, notamment pour effectuer des transactions, telles que des transactions bancaires (transaction de paiement, de transfert...), des transactions d’authentification, etc. Ces cartes peuvent par exemple être utilisées comme cartes bancaires, cartes de fidélité, cartes d’accès etc., et peuvent prendre divers formats selon leurs utilisations respectives.
[0003] 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, pour mettre en œuvre au moins une fonction. Les cartes à puce pour applications bancaires (carte de crédit, carte de débit etc.), par exemple, sont aptes à coopérer avec des terminaux de paiement ou des distributeurs automatiques de billets (DAB) pour réaliser divers opérations financières.
[0004] De façon connue, une carte à puce comprend un corps de carte qui est équipé d’une puce électronique configurée pour traiter des signaux et réaliser diverses fonctions selon l’utilisation souhaitée de la carte. Pour ce faire, une carte à puce est également munie de moyens de communication lui permettant d’interagir avec des terminaux externes.
[0005] Plus particulièrement, une carte à puce est traditionnellement conçue pour coopérer avec un terminal externe au moyen de contacts externes accessibles à la surface de la carte. Un terminal externe peut ainsi positionner des broches de contact appropriées sur les contacts externes de la carte afin d’établir une communication par contact. Plus récemment, les cartes à puce sans contact ont connu un essor important en raison du gain en rapidité et en simplicité liées aux transactions sans contact. Pour ce faire, les cartes sans contact embarquent une antenne radiofréquence (RP) permettant la transmission et la réception de signaux RP avec un terminal externe.
[0006] En général, les cartes à puce comportent un élément sécurisé configuré pour traiter les transactions, par exemple selon le standard EMV qui est majoritairement utilisé aujourd’hui pour sécuriser les transactions de paiement. Cet élément sécurisé n’interagit pas directement avec les terminaux externes. Les cartes à puce comportent en outre une unité de traitement, dit parfois « Lrontend », qui prend la forme d’une puce électronique conçue pour faire l’interface entre l’élément sécurisé et l’extérieur de la carte.
[0007] Pour communiquer avec l’extérieur, une carte à puce respecte un protocole de communication approprié. Ainsi, le protocole ISO 7816 est le protocole de communication utilisé majoritairement par les cartes à puce pour coopérer par contact avec des terminaux externes, par exemple avec des terminaux de paiement lors de transactions de paiement par contact.
[0008] Comme illustré en figure 1, il est également connu de doter une carte à puce de deux interfaces de communication distinctes afin de permettre à cette carte de communiquer avec l’extérieur selon deux protocoles de communication différents, à savoir le protocole ISO 7816 et le protocole 14443. Le protocole de communication ISO 14443 est conçu pour les transactions sans contact.
[0009] A titre d’exemple, la figure 1 représente une carte à puce 100 conventionnelle comportant une premier puce électronique 102, correspondant au « Lrontend », et une deuxième puce électronique 108 constituant un élément sécurisé de type EMV pour traiter des transactions EMV. L’élément sécurisé 108 est destiné à contenir des informations confidentielles sensibles, telles que le code PIN de la carte par exemple, et bénéficie donc d’un niveau de sécurité accru par rapport au processeur 102. A ce titre, des mécanismes de sécurité avancés sont généralement mis en œuvre dans cet élément sécurisé. Une certification est généralement nécessaire pour pouvoir mettre sur le marché et exploiter chaque version d’un tel élément sécurisé.
[0010] De façon connue, l’élément sécurisé 108 de cette carte à puce 100 comporte un processeur 109 et deux interfaces de communication 104 et 106 qui permettent au processeur 109 de communiquer avec l’extérieur, au travers de la puce électronique 102, selon deux protocoles de communication distincts, à savoir ISO 7816 et ISO 14443. Ces interfaces de communications 104, 106 sont des périphériques matériels qui sont intégrés dans les couches semi-conductrices (en silicium généralement) de l’élément sécurisé 108.
[0011] Le processeur 109 de l’élément sécurisé est apte à exécuter deux modules logiciels (ou applets) 110 et 112 afin de traiter des transactions avec l’extérieur selon respectivement les protocoles de communication ISO 7816 (transactions par contact) et ISO 14443 (transactions sans contact). Ainsi, la carte à puce 100 est multi-application. Lorsque la carte à puce 100 interagit avec un terminal sans contact, ce dernier sélectionne l’applet 112 de l’élément sécurisé 108 pour mettre en œuvre une transaction sans contact. Inversement, si la carte à puce 100 interagit avec un terminal par contact, ce dernier sélectionne l’applet 110 de l’élément sécurisé 108 pour mettre en œuvre une transaction par contact. Dans tous les cas, la puce électronique « Frontend » 102 fait l’interface entre l’extérieur de la carte à puce 100 et l’élément sécurisé 108. Chaque commande CMD reçue selon le protocole de communication ISO 7816 (respectivement ISO 14443) est transmise par la puce 102 à l’élément sécurisé 108 selon ce même protocole ISO 7816 (respectivement ISO 14443). Cette commande CMD est reçue par l’interface de communication 104, 106 correspondante de l’élément sécurisé 108, puis traitée par le processeur 109 qui exécute l’applet 110, 112 correspondante pour mettre en œuvre la transaction EMV.
[0012] De façon connue, au cours d’une transaction EMV, le terminal externe envoie à la carte à puce 100 une commande normalisée SELECT APPLICATION qui comporte un identifiant noté AID (pour « Application Identifier ») indiquant l’application souhaitée (traitement par contact ou sans contact). Ainsi, l’élément sécurisé 108 détermine laquelle parmi les applets 110 et 112 il doit exécuter, et ce à partir du protocole de communication utilisé (ISO 7816 ou ISO 14443) et de l’identifiant AID présent dans la commande SELECT APPLICATION reçue.
[0013] Comme indiqué ci-dessus, le caractère sensible de l’élément sécurisé 108 requiert que celui-ci soit certifié avant exploitation. L’obtention de cette certification est un processus coûteux. Cette nécessité de certifier les éléments sécurisés, notamment de type EMV, dans les cartes à puce est d’autant plus critique qu’une telle certification est nécessaire pour chaque interface de communication (ici 104 et 106) de l’élément sécurisé 108.
[0014] Un besoin existe donc aujourd’hui pour une solution permettant à une carte à puce, ou plus généralement un dispositif électronique, de traiter efficacement des transactions (par exemple de type EMV) selon de multiples protocoles de communication. Or, les mécanismes de sécurité avancés mis en œuvre dans les éléments sécurisés EMV actuels (pour chaque interface de communication) ainsi que les contraintes liées aux certifications rendent problématique la gestion de multiples protocoles de communication dans de tels éléments sécurisés. Les modifications structurelles qu’il faut apporter à un élément sécurisé afin de permettre la gestion de nouveaux protocoles de communication avec l’extérieur de la carte à puce pose des défis techniques en termes de sécurité notamment, et engendre des coûts indésirables.
Exposé de l’invention
[0015] A cet effet, la présente invention vise un procédé de routage (ou procédé de traitement) mis en œuvre dans une carte à puce coopérant avec un terminal pour traiter une transaction, la carte à puce comprenant :
[0016]
[0017]
[0018]
[0019]
[0020] une unité de gestion pour traiter la transaction selon des commandes émises par le terminal ; et une unité de traitement configurée pour faire l’interface entre l’unité de gestion et l’extérieur de la carte à puce, en communiquant avec l’unité de gestion selon un unique protocole de communication interne et en communiquant avec l’extérieur selon l’un parmi une pluralité de protocoles de communication externes supportés par l’unité de traitement ;
dans lequel l’unité de gestion comprend une pluralité de modules d’exécution, chacun d’eux étant configuré pour traiter la transaction selon un protocole de communication externe respectif, le procédé comprenant :
- réception, par l’unité de traitement, d’une première commande émise par le terminal selon un premier protocole de communication externe ;
- extraction, par l’unité de traitement, depuis la première commande, d’un premier identifiant d’une application spécifiée pour traiter la transaction ;
- détermination, à partir du premier identifiant et à partir du premier protocole de communication externe, d’un deuxième identifiant désignant un premier module d’exécution de l’unité de gestion ;
- génération, à partir de la première commande, d’une deuxième commande comportant le deuxième identifiant ;
- transmission à l’unité de gestion, par l’unité de traitement, de la deuxième commande selon l’unique protocole de communication interne ;
- identification, par l’unité de gestion, du premier module d’exécution à partir du deuxième identifiant ; et
- routage, par l’unité de gestion, de la deuxième commande vers le premier module d’exécution pour traiter ladite deuxième commande.
Selon un mode de réalisation particulier, l’unique protocole de communication interne est le protocole ISO 7816.
Selon un mode de réalisation particulier, la pluralité de protocoles de communication externes supportés par l’unité de traitement comprend les protocoles suivants : BLE (ou Bluetooth) ; Wifi ; NEC ; et ISO 7816.
Selon un mode de réalisation particulier, l’unique protocole de communication interne est différent du premier protocole de communication externe.
Selon un mode de réalisation particulier, le premier identifiant est un identifiant AID conforme à la norme ISO 7816-4.
Selon un mode de réalisation particulier, lors de ladite détermination, l’unité de traitement détermine le deuxième identifiant à partir d’une base de données indiquant, pour une pluralité de couples associant un dit premier identifiant avec un protocole de communication externe, un deuxième identifiant désignant un module d’exécution correspondant de l’unité de gestion.
[0021] Selon un mode de réalisation particulier, lors de ladite génération, l’unité de traitement :
- remplace dans la première commande le premier identifiant par le deuxième identifiant pour générer ladite deuxième commande ; ou
- génère une nouvelle commande, en tant que deuxième commande, à partir du contenu de la première commande, et en insérant dans la deuxième commande ledit deuxième identifiant.
[0022] Selon un mode de réalisation particulier, le procédé comprend un traitement par le premier module d’exécution de la deuxième commande selon ladite application spécifiée dans la première commande et conformément au premier protocole de communication externe.
[0023] Selon un mode de réalisation particulier, chaque module d’exécution est un module logiciel configuré pour mettre en œuvre une application selon un protocole distinct parmi ladite pluralité des protocoles de communication externes pour traiter une transaction.
[0024] Dans un mode particulier de réalisation, les différentes étapes du procédé de routage sont déterminées par des instructions de programmes d’ordinateurs.
[0025] En conséquence, l’invention vise aussi au moins un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un dispositif électronique tel qu’une carte à puce, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de routage tel que défini dans ce document.
[0026] 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é dans ce document.
[0027] A noter que les programmes 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.
[0028] De plus, les supports d’enregistrement mentionnés dans ce document 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 dise) ou un disque dur.
[0029] 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.
[0030] 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.
[0031] L’invention vise également une carte à puce configuré pour mettre en œuvre le procédé de routage défini dans le présent document. Plus particulièrement, l’invention vise une carte à puce configurée pour coopérer avec un terminal pour traiter une transaction, la carte à puce comprenant :
une unité de gestion pour traiter la transaction selon des commandes émises par le terminal ; et une unité de traitement configurée pour faire l’interface entre l’unité de gestion et l’extérieur de la carte à puce, en communiquant avec l’unité de gestion selon un unique protocole de communication interne et en communiquant avec l’extérieur selon l’un parmi une pluralité de protocoles de communication externes supportés par l’unité de traitement ;
dans laquelle l’unité de gestion comprend une pluralité de modules d’exécution, chacun d’eux étant configuré pour traiter la transaction en fonction d’un protocole de communication externe respectif ;
dans laquelle l’unité de traitement comprend :
- un module de réception configuré pour recevoir une première commande émise par le terminal selon un premier protocole de communication externe ;
- un module d’extraction configuré pour extraire depuis la première commande un premier identifiant d’une application spécifiée pour traiter la transaction ;
- un module de détermination configuré pour déterminer, à partir du premier identifiant et à partir du premier protocole de communication externe, un deuxième identifiant désignant un premier module d’exécution de l’unité de gestion ;
- un module de génération configuré pour générer, à partir de la première commande, une deuxième commande comportant le deuxième identifiant ;
- un module de transmission configuré pour transmettre à l’unité de gestion la deuxième commande selon Tunique protocole de communication interne ; dans laquelle l’unité de gestion comprend en outre :
- un module d’identification configuré pour identifier le premier module d’exécution à partir du deuxième identifiant ; et
- un module de routage configuré pour router la deuxième commande vers le premier module d’exécution pour traiter ladite deuxième commande.
[0032] A noter que les différents modes de réalisation mentionnés dans ce document en relation avec le procédé de routage de l’invention ainsi que les avantages associés s’appliquent de façon analogue à la carte à puce de l’invention.
[0033] Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, sauf indication contraire, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
[0034] Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné.
[0035] De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, etc.
[0036] De manière générale, la carte à puce selon l’invention peut comprendre un module configuré pour réaliser chaque opération ou étape décrite dans ce document en relation avec le procédé de routage de l’invention.
Brève description des dessins
[0037] 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:
[0038] [fig.l]
La figure 1 représente schématiquement la structure d’une carte à puce conventionnel de type EMV.
[0039] [fig.2]
La figure 2 représente schématiquement la structure d’une carte à puce selon un mode de réalisation particulier de l’invention.
[0040] [fig.3]
La figure 3 représente schématiquement des modules fonctionnels mis en œuvre par une carte à puce selon un mode de réalisation particulier de l’invention.
[0041] [fig.4]
La figure 4 représente schématiquement une table mises en œuvre dans une carte à puce selon un mode de réalisation particulier de l’invention.
[0042] [fig.5]
La figure 5 représente schématiquement une table mises en œuvre dans une carte à puce selon un mode de réalisation particulier de l’invention.
[0043] [fig.6]
La figure 6 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de routage selon un mode de réalisation particulier de l’invention. Description des modes de réalisation
[0044] La présente invention se propose de permettre une gestion efficace et adaptative de multiples protocoles de communication dans un dispositif électronique, tel qu’une carte à puce, afin de traiter des transactions avec un ou des terminaux externes.
[0045] Pour ce faire, l’invention propose notamment un procédé de routage (ou procédé de traitement) mis en œuvre dans une carte à puce coopérant avec un terminal pour traiter une transaction, la carte à puce comprenant :
- une unité de gestion pour traiter la transaction selon des commandes émises par le terminal ; et
- une unité de traitement configurée pour faire l’interface entre l’unité de gestion de transaction et l’extérieur de la carte à puce, en communiquant avec l’unité de gestion selon un unique protocole de communication interne et en communiquant avec l’extérieur avec l’un parmi une pluralité de protocoles de communication externes supportés par l’unité de traitement ;
dans lequel l’unité de gestion comprend une pluralité de modules d’exécution, chacun d’eux étant configuré pour traiter la transaction en fonction d’un protocole de communication externe respectif, le procédé comprenant :
- réception, par l’unité de traitement, d’une première commande émise par le terminal selon un premier protocole de communication externe ;
- extraction, par l’unité de traitement, depuis la première commande, d’un premier identifiant d’une application spécifiée pour traiter la transaction ;
- détermination, à partir du premier identifiant et à partir du premier protocole de communication externe, d’un deuxième identifiant désignant un premier module d’exécution de l’unité de gestion ;
- génération, à partir de la première commande, d’une deuxième commande comportant le deuxième identifiant ;
- transmission à l’unité de gestion, par l’unité de traitement, de la deuxième commande selon Tunique protocole de communication interne ;
- identification, par l’unité de gestion, du premier module d’exécution à partir du deuxième identifiant ; et
- routage, par l’unité de gestion, de la deuxième commande vers le premier module d’exécution pour traiter ladite deuxième commande.
[0046] L’invention vise également la carte à puce correspondante, ainsi que le ou les programmes d’ordinateurs mis en œuvre pour réaliser les étapes du procédé.
[0047] D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.
[0048] Dans le présent exposé, des exemples de mise en œuvre de l’invention sont décrits dans le cadre d’une carte à puce de type EMV, configurée pour traiter des transactions EMV. A noter que d’autres modes de réalisation sont toutefois possibles. En particulier, l’invention ne s’applique pas exclusivement aux cartes à puce mais peut s’appliquer plus généralement à des dispositifs électroniques quelconques configurés pour traiter des transactions selon de multiples protocoles de communication en coopérant avec un ou des terminaux externes.
[0049] De même, des modes de réalisation sont possibles avec un fonctionnement autre que le standard EMV.
[0050] On peut également noter que la notion de transaction est entendue dans ce document au sens large et comprend par exemple, dans le domaine bancaire, aussi bien une transaction de paiement ou une transaction de transfert, qu’une consultation d’un compte bancaire sur un terminal bancaire par exemple. Dans les modes de réalisation décrits ci-après, la carte à puce de l’invention traite des transactions de paiement, bien que d’autres types de transaction soient possibles.
[0051] Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
[0052] La figure 2 représente, de manière schématique, la structure d’une carte à puce CD1 selon un mode de réalisation particulier de l’invention. Cette carte à puce CD1 est configurée pour coopérer avec un terminal externe Tl pour traiter une transaction de paiement TRI selon le standard EMV.
[0053] Le protocole EMV, bien connu de l’homme du métier, 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.
[0054] Comme représenté en figure 2, la carte à puce CD1 comprend une unité de traitement U1 et une unité de gestion de transaction U2 (dite aussi unité de gestion), ces unités étant configurées pour communiquer ensemble au sein de la carte à puce CD1 en utilisant un unique protocole de communication interne noté PI, et ce quelles que soient les données échangées. On suppose par la suite que cet unique protocole de communication interne est le protocole ISO 7816, bien que d’autres protocoles soient possibles. Cela signifie que l’unité de gestion U2 ne communique avec l’unité de traitement U1 qu’au travers de ce seul protocole de communication PI qui est interne à la carte à puce CD1.
[0055] Dans l’exemple envisagé ici, l’unité de gestion U2 constitue un élément sécurisé qui est intégré ou inclus dans la carte à puce CD1. Cet élément sécurisé U2 est configuré pour traiter des transactions selon la norme EMV.
[0056] L’unité de traitement U1 et l’unité de gestion U2 peuvent être implémentées sur deux puces électroniques distinctes, connectées l’une à l’autre, bien que d’autres modes de réalisation soient possibles.
[0057] Comme défini par l’organisme de standardisation « GlobalPlatform » bien connu de l’homme du métier, un élément sécurisé (pour « secure element ») est une plateforme matérielle et logicielle configurée pour héberger de façon sécurisée des applications et leurs données sensibles associées (clés cryptographiques, algorithmes...), en conformité avec des règles fixées par une autorité tierce de confiance. Un élément sécurisé fournit un environnement d’exécution sécurisé à des applications. Il peut prendre diverses formes, telles qu’un module UICC (pour « Universal Integrated Circuit Card »), un élément sécurisé embarqué (ou « embedded SE » ou encore « eSIM ») ou encore une carte microSD. Un module UICC et une carte microSD sont généralement amovibles. Chaque forme d’élément sécurisé est destinée à être utilisée dans des applications bien particulières et doit répondre à des exigences propres au marché concerné.
[0058] Toujours dans l’exemple de réalisation représenté en figure 2, l’unité de traitement U1 est implémentée dans une puce électronique dite « Erontend ». L’unité de traitement U1 est configurée pour faire l’interface entre l’unité de gestion U2 et l’extérieur de la carte à puce CD1. Pour ce faire, l’unité de traitement U1 communique avec l’unité de gestion U2 selon l’unique protocole de communication interne PI (comme déjà décrit ci-avant) et communique avec l’extérieur de la carte à puce CD1 (et plus particulièrement avec le terminal Tl dans cet exemple) en utilisant l’un parmi une pluralité de protocoles de communication externes PE supportés par l’unité de traitement Ul. Autrement dit, l’unité de traitement U1 est configurée pour coopérer avec le terminal externe Tl via l’un parmi de multiples protocoles de communication externes PE prédéfinis.
[0059] Comme représenté en figures 2, on suppose que l’unité de traitement U1 supporte les protocoles de communication externes PEI, PE2, PE3 et PE4 (notés collectivement PE). Autrement dit, l’unité de traitement U1 a la capacité de sélectionner et exécuter chacun des protocoles PE selon le cas pour communiquer avec une entité externe. A titre d’exemple, on considère par la suite que les protocoles de communication externes PE pris en charge par l’unité de traitement U1 sont définis comme suit :
- PE1 : protocole BLE pour « Bluetooth Low Energy » ;
- PE2 : protocole Wifi ;
- PE3 : protocole NEC pour « Near Field Communication » ; et - PE4 : protocole ISO 7816.
[0060] A noter qu’il ne s’agit que d’un exemple non limitatif, le nombre et la nature des protocoles de communication externes PE pouvant varier selon les besoins.
[0061] Comme représenté en figure 2, l’unité de traitement U1 comprend un processeur 2 ainsi que 4 interfaces de communication INT1-INT4 pour permettre au processeur 2 de communiquer avec l’extérieur de la carte à puce CD1 (et en particulier avec le terminal Tl) selon les protocoles de communication externes respectifs PE1-PE4. Il s’agit ici d’interfaces de communication externes dans le sens où les protocoles PE permettent de communiquer avec des entités externes à la carte à puce CD1. Dans cet exemple, ces interfaces de communication PE prennent la forme de périphériques matériels qui sont intégrés dans les couches semi-conductrices de la puce électronique comportant l’unité de traitement Ul.
[0062] Dans cet exemple, la carte à puce CD1 comprend en outre des antennes ATI, AT2 et AT3 qui sont utilisées respectivement par les interfaces de communication INT1-INT3 pour communiquer avec un terminal externe selon les protocoles de communication externes PEI, PE2 et PE3, respectivement. De même, la carte à puce CD1 comprend dans cet exemple des contacts externes CT conforme au standard ISO 7816, pour permettre à l’interface de communication externe INT4 de communiquer par contact avec un terminal externe selon le protocole de communication externe PE4 (i.e. ISO 7816).
[0063] A noter qu’il est possible de n’implémenter dans la carte à puce CD1 que certaines parmi les interfaces de communication INT1-INT4. Par exemple, il est possible de n’implémenter que les interfaces INT1-INT3 et d’exclure ainsi l’interface INT4. Dans ce cas, il n’est pas nécessaire que la carte à puce CD1 embarque les contacts externes CT. En variante, une quelconque sous-combinaison parmi les interfaces de communication INT1-INT4 peut être mise en œuvre dans la carte à puce CD1.
[0064] Dans l’exemple considéré ici, chaque antenne AT1-AT3 est adaptée pour permettre une communication selon le protocole de communication externe correspondant PE1-PE3. Les moyens mis en œuvre dans la carte à puce CD1 pour permettre les communications avec l’extérieur peuvent être adaptés par l’homme du métier selon chaque cas d’usage. Selon un exemple particulier, au moins deux parmi les antennes AT1-AT3 peuvent former une seule et même antenne.
[0065] Comme représenté en figure 2, l’unité de traitement U1 comprend également une mémoire MRI ainsi qu’une interface de communication interne INT5.
[0066] La mémoire MRI est une mémoire non volatile (Llash ou EEPROM par exemple), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par l’unité de traitement Ul, et sur lequel est enregistré un programme d’ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG1 comporte des instructions pour l’exécution de certaines des étapes d’un procédé de routage selon un mode de réalisation particulier qui sera décrit ultérieurement.
[0067] Comme décrit plus en détail par la suite, la mémoire MRI est apte à stocker également des données sous la forme d’une table TB1. Des structures de données autres qu’une table sont toutefois possibles. La structure TB1 peut prendre la forme d’une base de données par exemple. Cette table TB1 (représentée en figure 4) permet à l’unité de traitement Ul de déterminer comment router des commandes entrantes vers l’unité de gestion U2 et comment transmettre des commandes sortantes vers l’extérieur de la carte à puce CD1. Comme décrit plus en détail ultérieurement, cette table TB1 stocke en particulier des triplets associant un premier identifiant ID1, un deuxième identifiant ID2 et un protocole de communication externe PE correspondant.
[0068] L’unité de traitement Ul peut en outre comprend une mémoire volatile RAM (non représentée).
[0069] L’unité de traitement Ul utilise en outre son interface de communication interne INT5 pour communiquer selon l’unique protocole de communication interne PI avec l’unité de gestion U2.
[0070] Par ailleurs, comme déjà indiqué, l’unité de gestion U2 est configurée pour traiter des transactions EMV en coopération avec des terminaux externes tels que Tl par exemple. Pour ce faire, l’unité de gestion U2 comprend un processeur 10, une interface de communication interne INT6, une mémoire MR2 et des modules d’exécution MX1-MX4, notés collectivement MX.
[0071] Le processeur 10 utilise l’interface de communication INT6 pour communiquer selon Tunique protocole de communication interne PI avec l’unité de traitement Ul. L’unité de gestion U2 coopère ainsi avec le terminal Tl au travers de l’unité de traitement Ul qui fait office d’interface. Comme déjà indiqué, on suppose ici que le protocole PI est ISO 7816 bien que d’autres exemples soient possibles.
[0072] La mémoire MR2 est une mémoire non volatile (Llash ou EEPROM par exemple), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par l’unité de gestion U2, et sur lequel est enregistré un programme d’ordinateur PG2 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG2 comporte des instructions pour l’exécution de certaines des étapes d’un procédé de routage selon un mode de réalisation particulier qui sera décrit ultérieurement.
[0073] Comme décrit plus en détail par la suite, la mémoire MR2 est apte à stocker également des données sous la forme d’une deuxième table TB2. Des structures de données autres qu’une table sont toutefois possibles. La structure TB2 peut prendre la forme d’une base de données. Cette table TB2 (représentée en figure 5) permet à l’unité de gestion U2 de déterminer vers lequel parmi les modules d’exécution MX doivent être routées des commandes entrantes et comment transmettre des commandes sortantes vers l’unité de traitement Ul. Comme décrit plus en détail ultérieurement, cette table TB2 stocke en particulier des couples associant un deuxième identifiant ID2 et un module d’exécution MX correspondant.
[0074] L’unité de gestion U2 peut en outre comprend une mémoire volatile RAM (non représentée).
[0075] Comme déjà indiqué, l’unité de gestion U2 comprend dans cet exemple 4 modules d’exécution MX distincts, bien que d’autres implémentations soient possibles. Chaque module d’exécution MX est configuré pour traiter une transaction en exécutant une application selon un protocole de communication externe distinct parmi PEI, PE2, PE3 et PE4. Ainsi, chacun de ces modules d’exécution MX constitue un module logiciel (ou applet) exécutable par le processeur 10 pour mettre en œuvre une application selon un protocole distinct parmi la pluralité des protocoles de communication externes PE supportés par l’unité de traitement Ul. Ces modules d’exécution MX permettent ainsi de traiter une transaction selon différents protocoles de communication externes.
[0076] On suppose par la suite que tous les modules d’exécution MX sont configurés pour exécuter une même application APP1, telle que par exemple une application de paiement VISA™, pour traiter une transaction EMV. La manière dont chaque module d’exécution MX exécute cette même application de paiement APP1 (notamment au niveau des commandes qui sont échangées) varie néanmoins de sorte à être adaptée au protocole de communication externe PE utilisé entre le terminal externe et le module de traitement Ul.
[0077] On comprend toutefois que le nombre et la nature des modules d’exécution MX peuvent varier en fonction des protocoles de communication externes PE implémentés par l’unité de traitement Ul. De même, les modules d’exécution MX peuvent éventuellement être configurés pour exécuter au moins deux applications différentes (par exemple de type VISA™ et MASTERCARD™). La nature des applications exécutées par les modules d’exécution MX pour traiter des transactions peut également être adaptée selon les besoins.
[0078] De manière générale, lorsqu’une transaction TRI de type EMV est initiée entre la carte à puce CD1 et le terminal Tl (comme représentée en figure 2), ceux-ci peuvent coopérer ensemble selon l’un quelconque parmi les protocoles de communication externes PE supportés par l’unité de traitement Ul, par exemple celui choisi par le terminal Tl. Ainsi, toutes les commandes ou messages échangés dans la transaction TRI entre le terminal Tl et la carte à puce CD1 respectent le protocole de communication externe PE choisi. L’unité de traitement U1 est ainsi capable de faire l’interface entre le terminal Tl et l’unité de gestion U2 en communiquant avec l’unité de gestion U2 selon l’unique protocole de communication interne PI et en communiquant avec le terminal Tl avec l’un parmi la pluralité de protocoles de communication externes PE. Une contrainte réside en ce qu’un seul protocole de communication interne IP, qui peut être différent du protocole de communication PE choisi, est utilisé pour les communications internes entre l’unité de traitement U1 et l’unité de gestion U2. Pour permettre le dialogue entre l’unité de gestion U2 et l’extérieur, les commandes entrantes doivent donc être routées vers le module d’exécution MX approprié d’une part et, d’autre part, les commandes sortantes doivent être transmises à l’unité de traitement U1 de sorte que cette dernière puisse elle-même transmettre ces commandes au terminal Tl selon le protocole de communication externe PE approprié. La manière dont ces commandes sont routées dans les sens entrant et sortant est décrite ci-après dans un exemple particulier.
[0079] A noter que certains éléments généralement présents dans une carte à puce ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention. L’homme du métier comprend en outre que certains éléments de la carte à puce CD1 ne sont décrits ici que pour faciliter la compréhension de l’invention, ces éléments n’étant pas nécessaires pour mettre en œuvre l’invention.
[0080] Par ailleurs, conformément à un mode de réalisation particulier, le processeur 2 piloté par le programme d’ordinateur PG1 met ici en œuvre un certain nombre de modules représentés en figure 3, à savoir : un module de réception MD2, un module d’extraction MD4, un module de détermination MD6, un module de génération MD8 et un module de transmission MD 10.
[0081] De même, conformément à un mode de réalisation particulier, le processeur 10 piloté par le programme d’ordinateur PG2 met ici en œuvre un certain nombre de modules représentés en figure 3, à savoir : les modules d’exécution MX déjà mentionnés ci-avant, un module d’identification MD20 et un module de routage MD22.
[0082] Plus précisément, le module de réception MD2 est configuré pour recevoir, lors d’une transaction TRI, une première commande CMD1 émise par le terminal Tl selon un premier protocole de communication externe, à savoir PE1 par exemple. Cette commande est par exemple une commande SELECT APPLICATION conforme à la norme EMV.
[0083] Le module d’extraction MD4 est configuré pour extraire depuis la première commande CMD1 un premier identifiant ID1 d’une application spécifiée pour traiter la transaction TRI, à savoir l’identifiant ID1 de l’application APP1 dans cet exemple. Ce premier identifiant est par exemple de type AID (pour « Application Identifier ») conforme à la norme ISO 7816-4.
[0084] Le module de détermination MD6 est configuré pour déterminer, à partir du premier identifiant ID1 extrait par le module d’extraction MD4 et à partir du premier protocole de communication externe utilisé (à savoir PE1 par exemple), un deuxième identifiant ID2 désignant un premier module d’exécution MX de l’unité de gestion U2 (à savoir le module d’exécution MX1 par exemple). Le module d’exécution MX ainsi désigné correspond à celui parmi MX1-MX4 qui est configuré pour prendre en charge les communications selon le protocole de communication externe PE utilisé lors de la transaction TRI.
[0085] Le module de génération MD8 est configuré pour générer, à partir de la première commande CMD1, une deuxième commande CMD2 comportant le deuxième identifiant ID2.
[0086] Le module de transmission MD 10 est configuré pour transmettre à l’unité de gestion U2 la deuxième commande CMD2 selon l’unique protocole de communication interne PL
[0087] Le module d’identification MD20 est configuré pour identifier le premier module d’exécution MX (à savoir, MX1 par exemple) à partir du deuxième identifiant ID2 présent dans la deuxième commande CMD2 reçue.
[0088] Le module de routage MD22 est configuré pour router la deuxième commande CMD2 vers le module d’exécution ainsi identifié (MX1 par exemple) pour traiter cette deuxième commande.
[0089] L’unité de traitement U1 et l’unité de gestion U2 sont ainsi configurées pour déterminer, à partir du protocole de communication externe PE utilisé et de l’identifiant ID1 désignant une application spécifique, comment router chaque commande entrante vers le module d’exécution MX approprié dans le cadre de la transaction TRI. Une fois que le module d’exécution MX approprié est déterminé, toutes les commandes entrantes reçues lors de la transaction TRI peuvent être transmises au même module d’exécution MX.
[0090] Inversement, l’unité de traitement U1 et l’unité de gestion U2 sont configurées pour déterminer, à partir du module d’exécution MX qui est exécuté, comment transmettre chaque commande sortante depuis l’unité de gestion U2 vers le terminal Tl en respectant le protocole de communication externe PE appliqué.
[0091] La configuration et le fonctionnement des modules MD2-MD10 de l’unité de traitement Ul, d’une part, et des modules MX et MD20-MD22 de l’unité de gestion U2, d’autre part, apparaîtront plus précisément dans les exemples de réalisation décrits ci-après. On comprendra que ces modules ne représentent qu’un exemple de mise en œuvre non limitatif de l’invention.
[0092] De manière générale, l’unité de traitement U1 et l’unité de gestion U2 mettent en œuvre un module respectif pour réaliser chaque opération ou étape du procédé de routage de l’invention.
[0093] Un mode de réalisation particulier de l'invention est à présent décrit en référence aux figures 4-6. Plus précisément, la carte à puce CD1 représenté en figures 1-2 met en œuvre un procédé de routage (ou procédé de traitement) de l’invention en exécutant les instructions des programmes d’ordinateur PG1 et PG2, formant collectivement un programme d’ordinateur. Autrement dit, l’unité de traitement U1 et l’unité de gestion U2 exécutent respectivement les programmes d’ordinateur PG1 et PG2 pour mettre en œuvre collectivement les étapes du procédé de routage.
[0094] On suppose qu’une transaction EMV notée TRI est initiée entre le terminal externe Tl et la carte à puce CD1. Cette transaction TRI fait appel à une coopération entre terminal Tl et la carte à puce CD1 qui échangent ensemble des commandes (ou messages) conformes au standard EMV. On suppose ici que la transaction TRI est une transaction de paiement EMV.
[0095] Lors de cette transaction TRI, la carte à puce CD1 et le terminal Tl communiquent ensemble selon l’un quelconque parmi les protocoles de communication externes PE, par exemple celui imposé par le terminal Tl. Ainsi, toutes les commandes ou messages échangés dans la transaction TRI entre le terminal Tl et la carte à puce CD1 respectent le protocole de communication externe PE appliqué par le terminal Tl. On suppose dans cet exemple que le terminal Tl applique le protocole de communication externe PE1 correspondant au protocole BLE, d’autres exemples étant toutefois possibles.
[0096] Dans une phase préliminaire de la transaction TRI, le terminal Tl transmet (A2) ainsi à la carte à puce CD1, selon le protocole de communication externe PE1, une commande CMD1 de type SELECT APPLICATION afin de sélectionner une application, à savoir l’application de paiement APP1 dans cet exemple. Pour ce faire, la commande CMD1 comprend un premier identifiant ID1 de type AID conforme à la norme ISO 7816-4, qui identifie l’application que le terminal Tl souhaite sélectionner dans la carte à puce CD1. La commande CMD1 est reçue (B2) par l’unité de traitement U1 au travers de son interface de communication externe INT1 qui applique le protocole de communication externe PE utilisé par le terminal Tl.
[0097] Le format de la trame de la commande CMD1 reçue en B2 est conforme au protocole de communication externe PE1. Il s’agit d’une commande APDU dont l’encapsulation est réalisée selon le protocole PE1. Le processeur 2 de l’unité de gestion U2 reconnaît ainsi que c’est le protocole de communication externe PE1 qui est appliqué à partir du format de la commande CMD1 reçue, ou plus généralement à partir de l’interface de communication externe par laquelle a été reçue la commande CMD1 (à savoir, via l’interface INT1 dans cet exemple). Dans le cas présent, la commande CMD1 est reçue par l’unité de traitement U1 via l’antenne ATI sur son interface de communication externe INT1, ce qui signifie que c’est le protocole de communication externe PE1 qui est appliqué.
[0098] Au cours d’une étape B4 d’extraction, le processeur 2 extrait ensuite le premier identifiant ID1 de la commande CMD1 reçue. On suppose dans cet exemple que cet identifiant correspond à l’application APP1 que le terminal Tl souhaite sélectionner dans la carte à puce CD1 pour traiter la transaction TRI.
[0099] Au cours d’une étape B6 de détermination, le processeur 2 consulte alors la table TB1 dans la mémoire MRI (figures 2 et 4) et détermine, à partir du protocole de communication externe PE1 utilisé et du premier identifiant ID1, un deuxième identifiant ID2 correspondant au module d’exécution MX qui est destiné à traiter cette commande et plus généralement la transaction TRI.
[0100] Plus précisément, la table TB1 envisagée dans cet exemple est représentée en figure 4. Comme déjà indiqué, cette table TB1 stocke des triplets associant un premier identifiant ID1 et un deuxième identifiant ID2 à chaque protocole de communication externe PE supporté par l’unité de traitement Ul. Autrement dit, la table TB1 indique, pour une pluralité de couples associant un premier identifiant ID1 avec un protocole de communication externe PE, un deuxième identifiant ID2 désignant un module d’exécution MX correspondant de l’unité de gestion U2. Ainsi, dans cet exemple, la table TB 1 spécifie :
- l’identifiant ID21 en association avec l’identifiant ID1 et le protocole de communication externe PE1 ;
- l’identifiant ID22 en association avec l’identifiant ID1 et le protocole de communication externe PE2 ;
- l’identifiant ID23 en association avec l’identifiant ID1 et le protocole de communication externe PE3 ; et
- l’identifiant ID24 en association avec l’identifiant ID1 et le protocole de communication externe PE4.
[0101] Comme déjà indiqué, on suppose dans ce mode de réalisation que seule l’application de paiement APP1 est exécutée par tous les modules d’exécution MX. Aussi, tous les triplets stockés dans la table TB1 comprennent ici le même premier identifiant ID1 correspondant à la même application APP1 (une application de paiement VISA™ par exemple). Comme déjà indiqué, d’autres modes de réalisation sont toutefois possibles dans lesquels plusieurs applications différentes sont mises en œuvre par les modules d’exécution MX de l’unité de gestion U2. Dans un tel cas, le premier identifiant ID1 varie dans les triplets de la table TB1.
[0102] Les deuxièmes identifiants ID21-ID24 (notés collectivement ID2) désignent chacun un module d’exécution MX respectif de l’unité de gestion U2 parmi MX1-MX4.
[0103] Dans l’exemple considéré ici, à partir du premier identifiant ID1 extrait en B4 de la commande CMD1 et à partir de PE1 reconnu comme le protocole de communication externe utilisé par le terminal Tl, le processeur 2 détermine (B6) le deuxième identifiant ID21 correspondant au module d’exécution MX1. Dans cet exemple, le module d’exécution MX1 est destiné à traiter des transactions EMV selon le protocole de communication externe BLE en exécutant l’application de paiement APP1.
[0104] A noter qu’un identifiant AID selon la norme ISO 7816-4 désigne une application (une application de paiement VISA™ dans cet exemple) et ce, quel que soit le protocole de communication qui est utilisé pour les communications externes entre carte à puce CD1 et terminal externe Tl. Autrement dit, un identifiant AID ne renseigne pas nécessairement sur le protocole de communication externe PE utilisé. Cela signifie que le protocole de communication externe PE utilisé a un impact sur la trame APDU de la commande SELECT APPLICATION, mais pas sur l’identifiant AID présent dans cette commande. Comme expliqué par la suite, le premier identifiant ID1 présent dans la commande CMD1 ne suffirait donc pas à l’unité de gestion U2 pour déterminer quel module d’exécution MX doit traiter une commande entrante, et de manière générale, la transaction TRI en cours. C’est à partir de ce premier identifiant ID1 et du protocole de communication externe PE applicable que l’unité de traitement U1 en déduit, en consultant sa table TB1, quel module d’exécution MX doit traiter la transaction en cours. Dans l’exemple considéré ici, le deuxième identifiant ID2 déterminé en B6 ne désigne pas simplement l’application de paiement VISA™, mais plus précisément l’unité de gestion MX1 qui est configurée pour traiter l’application de paiement VISA™ selon le protocole de communication externe PE1 (c’est-à-dire BLE dans cet exemple).
[0105] Selon un exemple particulier, l’unité de traitement U1 enregistre le deuxième identifiant ID2 déterminé en B6 (à savoir, l’identifiant ID21 dans cet exemple) dans sa mémoire volatile RAM (non représentée). Comme expliqué ultérieurement, cette information peut être utilisée par la suite par l’unité de traitement U1 pour router d’autres commandes entrantes depuis l’extérieur vers l’unité de gestion U2.
[0106] Selon un exemple particulier, l’unité de traitement U1 enregistre dans sa mémoire volatile RAM le premier identifiant ID1 extrait en B4 en association avec PE1 reconnu comme le protocole de communication externe utilisé par le terminal Tl. Comme expliqué ultérieurement, cette information peut être utilisée par la suite par l’unité de traitement U1 pour transmettre des commandes sortantes depuis l’unité de gestion U2 vers l’extérieur.
[0107] Puis, au cours d’une étape B8 de génération, le processeur 2 génère, à partir de la première commande CMD1, une deuxième commande CMD2 comportant le deuxième identifiant ID21 déterminé en B6.
[0108] Pour ce faire, au cours de l’étape B8 de génération, le processeur 2 génère une nouvelle commande, en tant que deuxième commande CMD2, à partir du contenu de la première commande CMD1, et en insérant dans cette deuxième commande le deuxième identifiant ID21 déterminé en B6. En variante, au cours de l’étape B8 de génération, le processeur 2 remplace dans la première commande CMD1 le premier identifiant ID1 par le deuxième identifiant ID21 de sorte à générer la deuxième commande CMD2.
[0109] Au cours d’une étape B10 de transmission, le processeur 2 déclenche ensuite la transmission, selon l’unique protocole de communication interne PI (à savoir ISO 7816 dans cet exemple), de la deuxième commande CMD2 à l’unité de gestion U2. Cette transmission est réalisée en utilisant l’interface de communication interne INT5 qui communique avec l’interface de communication INT6 de l’unité de gestion U2. Il s’ensuit que cette deuxième commande CMD2 présente un format ou une encapsulation qui est conforme à l’unique protocole de communication interne PI.
[0110] Au cours d’une étape CIO de réception, l’unité de gestion U2 reçoit la commande CMD2 selon l’unique protocole de communication interne PI.
[0111] Au cours d’une étape C12 d’identification, le processeur 10 de l’unité de gestion U2 identifie le module d’exécution MX destinataire de la commande CMD2 reçue en CIO. Pour ce faire, le processeur 10 consulte par exemple la table TB2 (figure 2) qui est représenté plus précisément en figure 5 dans cet exemple particulier. Le processeur 10 détermine ainsi dans cet exemple, à partir de l’identifiant ID21 compris dans la commande CMD2, que c’est le module d’exécution MX1 qui est destinataire de ladite commande CMD2.
[0112] Au cours d’une étape C14 de routage, le processeur 10 route alors la commande CMD2 vers le module d’exécution MX concerné, à savoir le module MX1 dans cet exemple, pour traiter la commande CMD2, et plus généralement la transaction TRI.
[0113] Au cours d’une étape C16 de traitement, le module d’exécution MX1 destinataire réalise un traitement de la deuxième commande CMD2 selon l’application APP1 spécifiée par l’identifiant ID1 de la première commande CMD1. Ce traitement est réalisé conformément au protocole de communication externe PE1 qui est utilisé par le terminal Tl et l’unité de traitement U1 pour communiquer ensemble. Ce traitement peut comprendre un échange de commandes entre l’unité de gestion U2 et le terminal Tl au travers de l’unité de traitement U1 en respectant le principe présenté ci-dessus.
[0114] L’unité de traitement U1 et l’unité de gestion U2 peuvent ensuite coopérer ensemble pour router chaque commande entrante vers le module d’exécution MX approprié, à savoir le module MX1 dans cet exemple. Ainsi, selon un exemple particulier, suite à l’étape C12 d’identification, l’unité de gestion U2 détermine que c’est le module d’exécution MX1 qui doit traiter toutes les commandes échangées avec le terminal Tl au travers de l’unité de traitement U1 lors de la transaction TRI en cours. Aussi, tant que la transaction TRI est en cours, toutes les commandes reçues depuis l’unité de traitement U1 sont routées par le processeur 10 vers le module d’exécution MX1.
[0115] De même, selon un exemple particulier, suite à l’étape B6 de détermination, l’unité de traitement U1 détermine que c’est le deuxième identifiant ID21 qui doit être inséré dans chaque commande à transmettre à l’unité de gestion U2 (de façon identique à l’étape B8). Pour ce faire, l’unité de traitement U1 peut consulter sa mémoire volatile RAM (non représentée) dans laquelle est stocké le deuxième identifiant ID21, comme déjà décrit précédemment. Ainsi, pour chaque commande entrante, l’unité de traitement U1 sait comment router la commande sans qu’il soit nécessaire de consulter à nouveau la table TB1 (figure 2). Il n’est donc pas nécessaire que l’unité de traitement U1 consulte de manière répétée sa table TB1 (figure 2), ce qui permet d’accélérer le traitement et d’économiser des ressources. Si, en revanche, l’identifiant ID21 n’est plus présent dans sa mémoire volatile RAM, alors l’unité de traitement U1 peut exécuter à nouveau les étapes B4 et B6 comme déjà décrit afin de déterminer le deuxième identifiant ID2 applicable.
[0116] Dans ce qui précède, il a été décrit la manière dont une ou des commandes entrantes dans la carte à puce CD1 depuis le terminal Tl sont routées vers le module d’exécution adéquat de l’unité de gestion U2. Une ou des commandes sortantes peuvent également être transmises par l’unité de gestion U2 et l’unité de traitement Ul, bien que cela ne soit pas obligatoire. A noter par exemple que, dans le cas particulier où la commande entrante CMD1 précédemment mentionnée est une commande SELECT OPTION, aucune réponse n’est générée par le module d’exécution MX1 conformément au standard EMV. Des échanges de commandes se poursuivent néanmoins selon le standard EMV entre le terminal Tl et la carte à puce CD1 au cours de la transaction TRI.
[0117] Selon un exemple particulier, l’unité de traitement Ul et l’unité de gestion U2 peuvent ainsi coopérer ensemble pour transmettre chaque commande sortante depuis l’unité de gestion U2 vers le terminal Tl par l’intermédiaire de l’unité de traitement Ul.
[0118] Ainsi, comme représenté en figure 6, suite à la réception de la commande CMD2, le module d’exécution MX1 peut générer une nouvelle commande CMD3 qui comprend l’identifiant ID21 correspondant audit module d’exécution MX1. Cette nouvelle commande peut être par exemple une commande GET PROCESSING OPTIONS ou tout autre commande conforme au standard EMV.
[0119] Le processeur 10 de l’unité de gestion U2 transmet (C20) alors cette commande CMD3 à l’unité de traitement Ul selon l’unique protocole de communication interne PI. L’unité de traitement Ul reçoit cette commande CMD3 en B20.
[0120] Au cours d’une étape B24 de détermination, le processeur 2 consulte sa mémoire volatile et détermine que c’est le premier identifiant ID1 et le protocole de communication externe PE1 qui sont applicables pour transmettre une commande vers l’extérieur.
[0121] Au cours d’une étape B26 de génération, le processeur 2 génère alors une nouvelle commande, en tant que quatrième commande CMD4, à partir du contenu de la troisième commande CMD3, et en insérant dans cette quatrième commande CMD4 le premier identifiant ID1 déterminé en B24. En variante, au cours de l’étape B26 de génération, le processeur 2 remplace dans la troisième commande CMD3 le deuxième identifiant ID21 par le premier identifiant ID1 de sorte à générer la quatrième commande CMD4.
[0122] Selon une variante, si la mémoire volatile RAM de l’unité de traitement U1 ne contient plus l’information selon laquelle ce sont le premier identifiant ID1 et le protocole de communication externe PE1 qui sont applicables pour transmettre une commande vers l’extérieur, alors le processeur 2 peut fonctionner selon le même principe que déjà décrit en référence aux étapes B4 à B8, mais de façon inversée. Ainsi, le processeur 2 peut extraire (B22) le deuxième identifiant ID21 de la commande CMD3 reçue. Le processeur 2 consulte alors sa table TB1 (figure 4) et détermine à l’étape B24, à partir du deuxième identifiant ID21, que c’est l’application APP1 correspond à l’identifiant ID1 (de type AID) qui est mise en œuvre et que c’est le protocole de communication externe PE1 qui est appliqué dans le cas présent. Le processeur 2 peut ensuite procéder à l’étape B26 de génération comme décrit ci-avant.
[0123] Au cours d’une étape B28 de transmission, le processeur 2 déclenche ensuite la transmission, selon le protocole de communication externe PE1 (à savoir BLE dans cet exemple), de la quatrième commande CMD4 au terminal Tl. Cette transmission est réalisée en utilisant l’interface de communication externe INT1 qui communique avec le terminal Tl selon le protocole PE1 en utilisant l’antenne ATI. Il s’ensuit que cette quatrième commande CMD4 présente un format ou une encapsulation qui est conforme au protocole de communication externe PE1.
[0124] Le terminal Tl reçoit (A30) la commande CMD4 et peut poursuivre le traitement de la transaction TRI avec la carte à puce CD1 tant que nécessaire, conformément au principe de routage présenté ci-avant.
[0125] Ainsi, pour chaque commande sortante, l’unité de traitement U1 peut consulter sa mémoire volatile RAM pour déterminer comment transmettre la commande depuis l’unité de gestion U2 vers l’extérieur. Il n’est donc pas nécessaire que l’unité de traitement U1 consulte de manière répétée sa table TB1 (figure 2), ce qui permet d’accélérer le traitement et d’économiser des ressources. En revanche, si l’information désignant l’identifiant ID1 et le protocole de communication externe PE1 comme étant applicables n’est plus présente dans sa mémoire volatile RAM, alors l’unité de traitement U1 peut consulter sa table TB1 comme déjà décrit.
[0126] Dans l’exemple de réalisation décrit ci-dessus, le protocole de communication externe PE appliqué dans les communications entre le terminal Tl et la carte à puce CD1 est le protocole PE1 correspondant au BLE. D’autres exemples sont bien entendu possibles. Selon un exemple particulier, le protocole de communication externe PE1 appliqué est différent de l’unique protocole de communication interne PI utilisés par l’unité de traitement U1 et l’unité de gestion U2 pour communiquer ensemble en interne.
[0127] La présente invention permet une gestion efficace et adaptative de multiples protocoles de communication dans une carte à puce, ou plus généralement dans un dispositif électronique, afin de traiter des transactions avec des terminaux externes tout en garantissant un bon niveau de sécurité.
[0128] L’invention offre en particulier une souplesse de fonctionnement dans la mesure où la carte à puce peut sélectionner le protocole de communication externe adéquat en fonction du type de terminal avec lequel elle coopère.
[0129] Selon le principe de l’invention, l’unité de gestion utilise un unique protocole de communication interne, de sorte que celui-ci ne varie pas même s’il l’on varie les protocoles de communication externes utilisés dans les communications entre la carte à puce et l’extérieur. L’usage de cet unique protocole de communication interne a pour conséquence que l’unité de gestion n’est pas capable de déduire directement du format des commandes reçues le protocole de communication externe utilisé par l’unité de traitement pour communiquer avec le terminal externe. Selon le principe de l’invention, l’unité de traitement fournit donc à l’unité de gestion une nouvelle information, à savoir un deuxième identifiant ID2, permettant à l’unité de gestion de router intelligemment les commandes reçues vers le module d’exécution adéquat.
[0130] Il est ainsi possible d’adapter aisément la configuration de la carte à puce de sorte à ce qu’elle supporte les protocoles de communication externes souhaités, et ce sans altérer la structure matérielle ou l’architecture de l’unité de gestion.
[0131] L’architecture de l’unité de gestion, ou plus précisément de l’élément sécurisé, est simplifiée du fait qu’un seul protocole de communication interne est supporté ce qui permet d’augmenter la sécurité de l’unité de gestion, tout en garantissant que des transactions puissent être traitées selon de multiples protocoles de communication externes. Le fait qu’un unique protocole de communication interne soit supporté par l’unité de gestion permet de mettre en œuvre, dans cette unité de gestion, des mécanismes de sécurité avancés (logiciels et/ou matériels) qui sont adaptés à cet unique protocole. En concentrant les mécanismes de sécurité sur cette unique interface de communication interne, la sécurité des transactions peut être améliorée.
[0132] De façon avantageuse, il est par exemple possible d’implémenter ISO 7816 en tant que protocole de communication interne PI. Les éléments sécurisés proposés aujourd’hui par les fondeurs supportent généralement le protocole ISO 7816. Ce cas particulier est également avantageux en ce que les éléments sécurisés communiquant selon ISO 7816 présentent une architecture générale connue dont on maîtrise bien aujourd’hui les aspects sécuritaires. Il est plus aisé de protéger efficacement un élément sécurisé communiquant selon ISO 7816 car les mécanismes de sécurité associés à ce protocole sont fiables du fait de la longévité de ce type d’architecture. En évitant l’implémentation de protocole de communication plus récents tels que BLE ou NEC par exemple, la sécurité de l’élément sécurisé est renforcé tout en permettant à la carte à puce de fonctionner selon de multiples protocoles de communication externes.
[0133] En outre, l’invention permet de d’adapter aisément les protocoles de communication externes supportés de la carte à puce sans qu’il soit nécessaire d’obtenir une nouvelle certification de l’unité de gestion puisque seules les interfaces de communication externes de l’unité de traitement sont impactées.
[0134] Un homme du métier comprendra que les modes de réalisation et variantes décrits ciavant ne constituent que des exemples non limitatifs de mise en œuvre de l’invention. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier.

Claims (1)

  1. Revendications [Revendication 1] Procédé de routage mis en œuvre dans une carte à puce (CD1) coopérant avec un terminal (Tl) pour traiter une transaction (TRI), la carte à puce comprenant :
    - une unité de gestion (U2) pour traiter la transaction selon des commandes émises par le terminal ; et
    - une unité de traitement (Ul) configurée pour faire l’interface entre l’unité de gestion (U2) et l’extérieur de la carte à puce, en communiquant avec l’unité de gestion (U2) selon un unique protocole de communication interne (PI) et en communiquant avec l’extérieur selon l’un parmi une pluralité de protocoles de communication externes (PE) supportés par l’unité de traitement ;
    dans lequel l’unité de gestion (U2) comprend une pluralité de modules d’exécution (MX), chacun d’eux étant configuré pour traiter la transaction selon un protocole de communication externe respectif, le procédé comprenant :
    - réception, par l’unité de traitement (Ul), d’une première commande (CMD1) émise par le terminal (Tl) selon un premier protocole de communication externe (PE1) ;
    - extraction, par l’unité de traitement (Ul), depuis la première commande, d’un premier identifiant (ID1) d’une application spécifiée pour traiter la transaction ;
    - détermination, à partir du premier identifiant (ID11) et à partir du premier protocole de communication externe (PE1), d’un deuxième identifiant (ID21) désignant un premier module d’exécution (MX1) de l’unité de gestion (U2) ;
    - génération, à partir de la première commande (CMD1), d’une deuxième commande (CMD2) comportant le deuxième identifiant ;
    - transmission à l’unité de gestion (U2), par l’unité de traitement, de la deuxième commande selon l’unique protocole de communication interne (PI) ;
    - identification, par l’unité de gestion (U2), du premier module d’exécution (MX1) à partir du deuxième identifiant (ID2) ; et - routage, par l’unité de gestion (U2), de la deuxième commande vers le premier module d’exécution (MX1) pour traiter ladite deuxième commande.
    [Revendication 2] Procédé selon la revendication 1, dans lequel l’unique protocole de
    communication interne est le protocole ISO 7816. [Revendication 3] Procédé selon la revendication 1 ou 2, dans lequel la pluralité de protocoles de communication externes (PE) supportés par l’unité de traitement (Ul) comprend les protocoles suivants : - Bluetooth ou BLE ; Wifi ; NEC ; et ISO 7816. [Revendication 4] Procédé selon l’une quelconque des revendications 1 à 3, dans lequel Punique protocole de communication interne (PI) est différent du premier protocole de communication externe (PE1). [Revendication 5] Procédé selon l’une quelconque des revendications 1 à 4, dans lequel le premier identifiant est un identifiant AID conforme à la norme ISO 7816-4. [Revendication 6] Procédé selon l’une quelconque des revendications 1 à 5, dans lequel, lors de ladite détermination, l’unité de traitement (Ul) détermine le deuxième identifiant (ID21) à partir d’une base de données indiquant, pour une pluralité de couples associant un dit premier identifiant avec un protocole de communication externe, un deuxième identifiant (ID2) désignant un module d’exécution (MX) correspondant de l’unité de gestion (U2). [Revendication 7] Procédé selon l’une quelconque des revendications 1 à 6, dans lequel, lors de ladite génération, l’unité de traitement (Ul) : - remplace dans la première commande (CMD1) le premier identifiant (ID1) par le deuxième identifiant (ID2) pour générer ladite deuxième commande (CMD2) ; ou - génère une nouvelle commande, en tant que deuxième commande (CMD2), à partir du contenu de la première commande (CMD1), et en insérant dans la deuxième commande ledit deuxième identifiant (ID21). [Revendication 8] Procédé selon l’une quelconque des revendications 1 à 7, comprenant un traitement par le premier module d’exécution (MX1) de la deuxième commande (CMD2) selon ladite application spécifiée dans la première commande (CMD1) et conformément au premier protocole de commu-
    nication externe (PE1). [Revendication 9] Procédé selon l’une quelconque des revendications 1 à 8, dans lequel chaque module d’exécution est un module logiciel configuré pour mettre en œuvre une application selon un protocole distinct parmi ladite pluralité des protocoles de communication externes (PE) pour traiter une transaction. [Revendication 10] Programme d’ordinateur (PG1 ; PG2) comportant des instructions pour l’exécution des étapes d’un procédé selon l’une quelconque des revendications 1 à 9 lorsque ledit programme est exécuté par un processeur. [Revendication 11] Support d’enregistrement, lisible par un processeur, sur lequel est enregistré au moins un programme d’ordinateur (PG1 ; PG2) comprenant des instructions pour l’exécution des étapes d’un procédé selon l’une quelconque des revendications 1 à 9. [Revendication 12] Carte à puce (CD1) configurée pour coopérer avec un terminal (Tl) pour traiter une transaction (TRI), la carte à puce comprenant : - une unité de gestion (U2) pour traiter la transaction selon des commandes émises par le terminal ; et - une unité de traitement (Ul) configurée pour faire l’interface entre l’unité de gestion (U2) et l’extérieur de la carte à puce, en communiquant avec l’unité de gestion (U2) selon un unique protocole de communication interne (PII) et en communiquant avec l’extérieur selon l’un parmi une pluralité de protocoles de communication externes (PE) supportés par l’unité de traitement ; dans laquelle l’unité de gestion (U2) comprend une pluralité de modules d’exécution (MX), chacun d’eux étant configuré pour traiter la transaction en fonction d’un protocole de communication externe respectif ; dans laquelle l’unité de traitement (Ul) comprend : - un module de réception configuré pour recevoir une première commande (CMD1) émise par le terminal (Tl) selon un premier protocole de communication externe (PE1) ; - un module d’extraction configuré pour extraire depuis la première commande un premier identifiant (ID1) d’une application spécifiée pour traiter la transaction ; - un module de détermination configuré pour déterminer, à partir du premier identifiant (ID11) et à partir du premier protocole de communication externe (PE1), un deuxième identifiant (ID21) désignant un premier module d’exécution (MX1) de l’unité de gestion (U2) ;
    - un module de génération configuré pour générer, à partir de la première commande (CMD1), une deuxième commande (CMD2) comportant le deuxième identifiant ;
    - un module de transmission configuré pour transmettre à l’unité de gestion (U2) la deuxième commande selon Tunique protocole de communication interne (PI) ;
    dans laquelle l’unité de gestion (U2) comprend en outre :
    - un module d’identification configuré pour identifier le premier module d’exécution (MX1) à partir du deuxième identifiant (ID2) ; et
    - un module de routage configuré pour router la deuxième commande vers le premier module d’exécution (MX1) pour traiter ladite deuxième commande.
    [Revendication 13] Carte à puce selon la revendication 12, dans laquelle l’unité de gestion (U2) est configurée pour traiter la transaction selon le standard EMV.
    [Revendication 14] Carte à puce selon la revendication 12 ou 13, dans laquelle l’unité de gestion est un élément sécurisé indépendant de l’unité de traitement.
FR1873537A 2018-12-20 2018-12-20 Dispositif à multiples interfaces de communication et procédé correspondant Active FR3090947B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1873537A FR3090947B1 (fr) 2018-12-20 2018-12-20 Dispositif à multiples interfaces de communication et procédé correspondant

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1873537A FR3090947B1 (fr) 2018-12-20 2018-12-20 Dispositif à multiples interfaces de communication et procédé correspondant

Publications (2)

Publication Number Publication Date
FR3090947A1 true FR3090947A1 (fr) 2020-06-26
FR3090947B1 FR3090947B1 (fr) 2020-12-11

Family

ID=66690547

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1873537A Active FR3090947B1 (fr) 2018-12-20 2018-12-20 Dispositif à multiples interfaces de communication et procédé correspondant

Country Status (1)

Country Link
FR (1) FR3090947B1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3115622A1 (fr) * 2020-10-27 2022-04-29 Stmicroelectronics (Rousset) Sas Elément sécurisé
FR3115623A1 (fr) * 2020-10-27 2022-04-29 Stmicroelectronics (Rousset) Sas Elément sécurisé

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100274712A1 (en) * 2009-04-28 2010-10-28 Mastercard International Incorporated Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US20140365776A1 (en) * 2013-06-06 2014-12-11 Mastercard International Incorporated Electronic Authentication Systems
EP3236405A1 (fr) * 2016-04-21 2017-10-25 Oberthur Technologies Selection d'une application sur une carte

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100274712A1 (en) * 2009-04-28 2010-10-28 Mastercard International Incorporated Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US20140365776A1 (en) * 2013-06-06 2014-12-11 Mastercard International Incorporated Electronic Authentication Systems
EP3236405A1 (fr) * 2016-04-21 2017-10-25 Oberthur Technologies Selection d'une application sur une carte

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3115622A1 (fr) * 2020-10-27 2022-04-29 Stmicroelectronics (Rousset) Sas Elément sécurisé
FR3115623A1 (fr) * 2020-10-27 2022-04-29 Stmicroelectronics (Rousset) Sas Elément sécurisé
EP3992797A1 (fr) 2020-10-27 2022-05-04 STMicroelectronics (Rousset) SAS Elément sécurisé
EP3992798A1 (fr) 2020-10-27 2022-05-04 STMicroelectronics (Rousset) SAS Elément sécurisé et procédé de communication entre un élément sécurisé et l'extérieur de l'élément sécurisé
CN114499918A (zh) * 2020-10-27 2022-05-13 意法半导体(鲁塞)公司 安全元件和方法

Also Published As

Publication number Publication date
FR3090947B1 (fr) 2020-12-11

Similar Documents

Publication Publication Date Title
EP3221815B1 (fr) Procédé de sécurisation d'un jeton de paiement.
EP2901391B1 (fr) Procede de protection de donnees sensibles transmises dans un systeme nfc
EP1234284A1 (fr) Procede de securisation de la phase de pre-initialisation d'un systeme embarque a puce electronique, notamment d'une carte a puce, et systeme embarque mettant en oeuvre le procede
EP3005263A2 (fr) Systèmes d'authentification électronique
EP2920986B1 (fr) Dispositif nfc comprenant des moyens de notification configurables
EP3455812B1 (fr) Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant
EP2447835A1 (fr) Procédé de configuration d'une entité électronique
FR3090947A1 (fr) Dispositif à multiples interfaces de communication et procédé correspondant
EP2118825B1 (fr) Entité électronique portable et procède de communication
EP3234848B1 (fr) Procede d'envoi d'une information de securite et dispositif electronique apte a mettre en oeuvre un tel procede
EP3261014B1 (fr) Procédé d'envoi d'une information de sécurité
EP3136283B1 (fr) Dispositif et procédé sécurisation de commandes échangées entre un terminal et circuit intégré
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
FR3057689A1 (fr) Procede et systeme de fourniture de jeton dans un systeme d'emulation de carte hote comportant un premier et un second dispositifs
WO2017109405A1 (fr) Procédé d'authentification
EP3987390A1 (fr) Système d'applications de service pour terminaux de paiement
EP3291188B1 (fr) Procédé de contrôle d'un dispositif électronique et dispositif électronique correspondant
EP3514749B1 (fr) Procede de controle de regles de dependances d'objets mis a jour dans un microcircuit, et dispositif correspondant
WO2018011514A1 (fr) Procédé de contrôle d'un dispositif électronique pour traiter une transaction
FR3042626A1 (fr) Procede et systeme d'acces securise et discrimine a des services d'un circuit integre, par diversification d'une unique cle racine
EP4390738A1 (fr) Protection d'un dispositif électronique
EP3876096A1 (fr) Procédé mis en oeuvre dans un module à circuit intégré, module à circuit intégré correspondant, système comportant un tel module et programme d'ordinateur associé
EP4390739A1 (fr) Protection d'un dispositif électronique
EP3992798A1 (fr) Elément sécurisé et procédé de communication entre un élément sécurisé et l'extérieur de l'élément sécurisé
EP3992797A1 (fr) Elément sécurisé

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200626

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6