FR2812101A1 - Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant - Google Patents
Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant Download PDFInfo
- Publication number
- FR2812101A1 FR2812101A1 FR0009657A FR0009657A FR2812101A1 FR 2812101 A1 FR2812101 A1 FR 2812101A1 FR 0009657 A FR0009657 A FR 0009657A FR 0009657 A FR0009657 A FR 0009657A FR 2812101 A1 FR2812101 A1 FR 2812101A1
- Authority
- FR
- France
- Prior art keywords
- application
- slave
- operating system
- master
- applications
- 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.)
- Withdrawn
Links
- 230000005540 biological transmission Effects 0.000 title description 2
- 230000015654 memory Effects 0.000 claims description 25
- 238000000034 method Methods 0.000 claims description 24
- 230000004044 response Effects 0.000 claims description 19
- 238000012795 verification Methods 0.000 claims description 14
- 230000006870 function Effects 0.000 claims description 12
- 230000008569 process Effects 0.000 description 10
- 238000012545 processing Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- 238000001994 activation Methods 0.000 description 5
- 101150102699 APPL2 gene Proteins 0.000 description 4
- 230000004913 activation Effects 0.000 description 4
- 238000009434 installation Methods 0.000 description 4
- 230000009849 deactivation Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000007420 reactivation Effects 0.000 description 3
- 230000002457 bidirectional effect Effects 0.000 description 2
- 230000010365 information processing Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 230000003213 activating effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 238000005530 etching Methods 0.000 description 1
- 238000002513 implantation Methods 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 229910052710 silicon Inorganic materials 0.000 description 1
- 239000010703 silicon Substances 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
Abstract
L'invention concerne un protocole d' echange de messages entre applications implant ees sur un système embarqu e muni d'un système d'exploitation (OS), et le système embarqu e correspondant.Il consiste au moins à transmettre (1000) une requête d'appel de l'application maître vers le système d'exploitation, requête contenant une commande d'entr ee/ sortie sp ecifique destin ee à l'application esclave, à d esactiver l'application maître et activer l'application esclave (1001), transmettre (1002) à l'application esclave activ ee la commande d'entr ee/ sortie à partir du système d'exploitation (OS), ex ecuter (1003) au niveau de l'application esclave activ ee la commande d'entr ee/ sortie destin ee à cette application esclave, retourner (1004), à partir de l'application esclave, une r eponse au système d'exploitation. Application à la gestion s ecuris ee des applications implant ees sur des cartes à puce multi-application.
Description
!
PROTOCOLE D'ÉCHANGE DE MESSAGES ENTRE APPLICATIONS
IMPLANTEES SUR UN SYSTEME EMBARQUE, ET SYSTEME EMBARQUE
CORRESPONDANT
Les systèmes embarqués, ou objets portatifs, actuels, notamment les cartes à microprocesseur, encore désignées par cartes à puce, tendent à remplir des fonctions de plus en plus complexes, en raison, notamment, de l'implantation de programmes d'application multiples, ces cartes à puce étant désignées par cartes "multi-application". Ces implantations multiples sont rendues possibles, d'une part, par la miniaturisation des circuits électroniques, finesse de gravure du silicium, et en conséquence, augmentation corrélative de la capacité mémoire des cartes à puce, et, d'autre part, par l'augmentation de la puissance de calcul des unités centrales de traitement. Une implantation structurelle
d'une carte à mémoire est représentée en figure la.
En référence à la figure la, on rappelle que l'objet portatif, constitué par une carte à microprocesseur et référencé 10, comprend, de manière classique, des circuits d'entrée/sortie, notés I/O et référencés 12, permettant de communiquer avec un terminal tel qu'un terminal de transaction bancaire par exemple, des ressources de traitement de l'information, référencées 14, constituées par un micro-contrôleur, ces ressources de traitement de l'information étant reliées aux circuits d'entrée/sortie 12. En outre, une mémoire non volatile 18 est prévue, laquelle consiste en une mémoire programmable 18a et en une mémoire de type ROM, ou mémoire de type à accès en lecture seulement 18b. Ces deux mémoires sont reliées au microprocesseur 14. Enfin, une mémoire de type mémoire de travail, mémoire RAM, portant la référence 16, est également reliée au microprocesseur 14. Les liaisons précitées s'entendent d'une liaison par BUS de type classique. Un système d'exploitation OS est prévu, lequel
peut être implanté en mémoire non volatile 18.
Enfin, et dans certains cas seulement, l'objet portatif multi-application peut comporter, ainsi que représenté en figure la, une unité de calcul de chiffrement/déchiffrement S, portant la référence 20,
elle-même reliée au microprocesseur 14.
Les éléments structurels de l'objet portatif multi-application, objet de la présente invention, ne seront pas décrits plus en détail car ils correspondent
à des éléments connus de l'état de la technique.
Dans une variante, le microprocesseur est remplacé - ou tout du moins complété - par des circuits logiques implantés dans une puce à semiconducteurs. En effet, de tels circuits sont aptes à effectuer des calculs, notamment d'authentification et de signature, grâce à de l'électronique câblée, et non microprogrammée. Ils peuvent notamment être de type ASIC (de l'anglais "Application Specific Integrated Circuit"). Dans une architecture connue de carte à puce multi-application, telle que représentée en figure lb, plusieurs applications indépendantes coexistent sur la
même carte, dans la zone mémoire non volatile de celle-
ci. Ce type d'architecture comprend, habituellement, le système d'exploitation OS et les applications désignées par Appl1 et Appl2 sur la figure précitée. De manière optionnelle, l'architecture précitée peut comporter une machine virtuelle, telle qu'une machine virtuelle JAVA
(marque déposée) dédiée, encore appelée JCVM.
Le système d'exploitation OS n'est autre qu'un programme générique qui rend des services d'intercommunication aux applications implantées, services tels que la gestion des messages d'entrées/sorties échangés avec un terminal d'utilisation de la carte, tel qu'un terminal de paiement ou autre par exemple, ainsi que l'accès à la mémoire équipant le système embarqué. La gestion des messages d'entrées/sorties est normalement réalisée selon le protocole APDU pour Application Protocol Data Unit, défini par la norme ISO 7816. Dans le cadre de ce protocole, on rappelle que la commande d'invitation en lecture/écriture provient de l'extérieur du système embarqué, c'est-à-dire du terminal d'utilisation précité. Les différents champs d'une commande APDU sont représentés en figure ld, ces champs désignant: CLA: classe d'instruction INS:code d'instruction P1, P2:paramètres d'instruction Lcf:longueur en bits du champ de données Df: champ de données Lef:nombre maximum de bits dans le champ de
données de la réponse.
SWI, SW2:statut de la commande, qualificatif de
la commande.
Les applications Appll ou Appl2 sont des programmes spécifiques qui réalisent, chacune, une tâche ou fonction particulière, telles que les fonctions d'un porte-monnaie électronique PME, système d'accès à des programmes de télévision à péage, ou autres. Dans ce but, les applications Appll ou Appl2 utilisent les services du système d'exploitation. Les commandes APDU, commandes d'entrées/sorties, en provenance du terminal d'utilisation, sont traitées par
le système d'exploitation OS et par les applications.
Toutes les commandes APDU sont examinées par le système d'exploitation, certaines étant filtrées et d'autres étant remises aux applications, en fonction d'un
critère d'utilisation.
En effet, pour activer, c'est-à-dire rendre fonctionnellement active, une application implantée sur la carte, le programme implanté sur le terminal d'utilisation envoie à la carte, insérée dans ce dernier, une commande APDU spécifique de sélection, SELECTAPDU. Le système d'exploitation OS examine cette
commande et active l'application correspondante.
Ensuite, toutes les commandes qui suivent sont directement remises à l'application active, par le système d'exploitation OS. Sur la figure lb, l'application Appl2 est représentée comme l'application active par la double flèche illustrant la mise en correspondance biunivoque de l'application active précitée et du système d'exploitation OS. Ce processus et le lien de correspondance biunivoque précité se terminent lorsque le système d'exploitation OS détecte de nouveau une commande de sélection d'une autre application, distincte de l'application active, ensuite de quoi le système d'exploitation désactive
l'application active et active cette autre application.
Dans certains cas, en particulier en vue d'augmenter les fonctionnalités d'une pluralité d'applications implantées sur une même carte à puce, il est souhaitable que l'application active puisse faire appel à une autre application, non active, implantée sur la carte. C'est par exemple le cas lorsqu'une application d'accès à des programmes de télévision à péage, PTV, doit faire appel à une application de porte-monnaie électronique, PME, pour effectuer un paiement. L'application d'accès aux programmes de télévision à péage doit ensuite reprendre la main, afin de gérer conditionnellement l'accès au programme de télévision choisi par l'utilisateur, en fonction de
l'exécution valable ou non du paiement précité.
Un tel mode opératoire nécessite donc que l'application, active, puisse activer l'autre application, application esclave, et qu'un canal de communication partagé (sharable interface en langage anglo-saxon) convenable soit installé entre
l'application maître et l'application esclave.
La figure lc montre, à titre d'exemple,
l'installation d'un tel canal de communication.
D'une manière connue en tant que telle, l'activation de l'application esclave par l'application maître, ainsi que l'installation du canal de communication partagé, consiste à établir un tel canal partagé, ou interface partagée, à partir de la mémoire disponible de la carte à puce. Une solution connue correspond à une interface
partagée JavaCard.2.1. Pour une description plus
détaillée de l'interface partagée JavaCard.2.1, on pourra utilement se reporter aux spécifications: - JavaCard 2.1 runtime environment JCRE specification final revision 1.0 du 24 février 1999. Auteur: Sun
Microsystems Incorporated Palo Alto California. USA.
- JavaCard 2.1 application programming interface final revision 1.0 du 24 février 1999. Auteur: Sun Microsystems Incorporated Palo Alto California. USA L'inconvénient majeur de la solution précitée consiste dans le fait qu'elle nécessite une interface particulière supplémentaire, consommatrice de mémoire, entre l'application maître et l'application esclave, l'interface partagée dans le cas de la spécification JavaCard.2. 1. Cette interface partagée est donc distincte de l'interface principale des applications implantées avec le système d'exploitation OS vis-à-vis du terminal, interface principale constituée par le jeu des commandes d'entrées/sorties, commandes APDU,
compris par chaque application.
Pour cette raison, une application existante donnée ne peut pas servir d'application esclave pour autant qu'elle n'a pas été modifiée de façon à intégrer l'interface de partage. Il en est sensiblement de même pour ce qui concerne l'application maître, et, en conséquence, l'installation d'une interface partagée bidirectionnelle dans laquelle deux applications peuvent en outre devenir maître ou esclave respectivement apparait hypothétique. En effet, la modification d'une application existante est le plus souvent très coûteuse, voire difficilement réalisable, notamment lorsque l'application considérée a déjà fait l'objet d'une certification de sécurité, toute
modification rendant le certificat de sécurité caduc.
En outre, les mécanismes d'activation d'applications sont limités à un modèle de programmation spécifique, par exemple le langage JavaCard, et ne permettent cependant pas les interactions ou mises en communication entre appliquettes, établies en Java bytecode, et
applications natives, établies en code natif.
La présente invention a pour objet de remédier aux inconvénients des interfaces partagées de l'art antérieur, par émulation d'une opération de sélection, entre une application maître et une application esclave. En conséquence, la présente invention a pour objet un protocole d'échange de messages entre applications implantées sur un système embarqué, par l'intermédiaire de l'interface principale et des commandes d'entrées/sorties, commandes APDU, gérées par
le système d'exploitation OS.
Un autre objet de la présente invention est, également, la mise en oeuvre d'un protocole d'échange de messages entre applications implantées sur un système embarqué, tel qu'une carte à puce, dans lequel l'application esclave est gérée par les commandes d'entrées/sorties externes, l'application maitre jouant sensiblement le rôle d'un terminal d'utilisation
externe.
Un autre objet de la présente invention est, également, la mise en oeuvre d'un protocole d'échange de messages entre applications implantées sur un système embarqué, tel qu'une carte à puce, dans lequel toute application implantée est susceptible d'être sélectionnée comme application maître, cette application maître étant en mesure elle-même d'entrer en communication avec toute autre application distincte, constituant alors, vis-à-vis de cette
application maître, une application esclave.
Un autre objet de la présente invention est, enfin, la mise en oeuvre d'un protocole sécurisé d'échange de messages entre applications implantées sur un système embarqué muni d'un système d'exploitation, tel qu'une carte à puce, ainsi que celle de tout
système embarqué ou carte à puce correspondant.
Le protocole d'échange de messages entre applications implantées sur un système embarqué muni d'un système d'exploitation, objet de la présente invention, ce système d'exploitation permettant, par commande d'entrées/sorties, l'échange de messages de données et de commande d'interface principale entre une application maître active parmi ces applications, les autres applications étant inactives, et un système externe par l'intermédiaire de cette interface principale et de commandes d'entrées/sorties, est remarquable en ce qu'il consiste au moins à transmettre, à partir de l'application maître, vers le système d'exploitation, une requête d'appel d'une application esclave inactive, cette requête d'appel comportant au moins une commande d'entrée/sortie spécifique destinée à cette application esclave, à désactiver l'application maître et à activer cette application esclave inactive par l'intermédiaire du système d'exploitation, à transmettre à l'application esclave activée la commande d'entrée/sortie destinée à cette application esclave, par l'intermédiaire du système d'exploitation, à exécuter au niveau de cette application esclave activée la commande d'entrée/sortie destinée à cette application esclave, à retourner à partir de cette application esclave un message d'acquittement et/ou de réponse, au système d'exploitation. Le protocole, objet de l'invention, trouve application à la gestion de tout type d'applications implantées dans la mémoire non volatile d'un système
embarqué, tel qu'une carte à puce, notamment.
Il sera mieux compris à la lecture de la
description et à l'observation des dessins dans
lesquels, outre les figures la à ld relatives à l'art antérieur; - la figure 2a représente, à titre illustratif, un organigramme général représentant la mise en oeuvre séquentielle des étapes du protocole, objet de la présente invention; - la figure 2b représente, à titre illustratif, le chemin des échanges de commandes APDU au moyen d'une interface principale et du système d'exploitation OS
dans le cadre d'une architecture de carte multi-
application, lors de la mise en oeuvre du protocole objet de l'invention illustré en figure 2a; - la figure 2c représente, à titre illustratif, une mise en oeuvre successive du protocole objet de la présente invention entre différentes applications implantées dans une carte multiapplication; - la figure 3a représente, à titre illustratif, une variante de mise en oeuvre avantageuse du protocole objet de la présente invention dans le cas o l'application maître n'est pas suspendue mais désactivée; la figure 3b représente, à titre illustratif, le chemin des échanges de commandes, commandes APDU et commandes OS, au moyen d'une interface principale et du système d'exploitation dans le cadre d'une architecture de carte multi-application, lors de la mise en oeuvre du protocole objet de l'invention illustré en figure 3a; - la figure 4a représente, à titre illustratif, une variante de mise en oeuvre du protocole objet de la présente invention, dans laquelle une procédure d'authentification de la requête d'appel de l'application esclave et de cette application esclave par l'application maître est introduite; - la figure 4b représente, à titre illustratif, un mode de mise en oeuvre particulier de la procédure d'authentification selon une variante distincte de celle décrite en figure 4a; - la figure 5 représente, à titre illustratif, l'implantation d'un objet portatif ou système embarqué, tel qu'une carte à puce, conforme à l'objet de la
présente invention.
Une description plus détaillée du protocole
d'échange de messages entre applications implantées sur Il un système embarqué, conforme à l'objet de la présente invention, sera maintenant donnée en liaison avec les
figures 2a, 2b et les figures suivantes.
D'une manière générale, on rappelle qu'un système embarqué désigne tout système informatique muni d'un système d'exploitation, tel qu'une carte à puce
par exemple, une carte PCMCIA ou autre.
Ce système d'exploitation permet, par commandes d'entrées/sorties, l'échange de messages de données et de commandes d'interface principale entre une application maître, active parmi ces applications, les autres applications étant inactives, et un système externe tel que par exemple un terminal d'utilisation de ce système embarqué par l'intermédiaire d'un circuit d'interface d'entrée/sortie tel que le circuit 12
représenté en figure la.
D'une manière générale, on considère que, dans l'ensemble des applications implantées dans le système embarqué, à chaque instant, aucune des applications n'est active, lorsque le système embarqué ou la carte à puce considérés ne sont pas utilisés, ou, au contraire, l'une des applications est active lorsque le système embarqué est inséré dans un terminal d'utilisation, les autres applications étant considérées inactives. On comprend en particulier que le caractère actif ou inactif de chaque application est géré par le système d'exploitation OS en fonction de l'utilisation du
système embarqué ou de la carte à puce précités.
En conséquence, le protocole, objet de la présente invention, sera tout d'abord décrit en liaison avec les figures 2a et 2b dans le cas o le système embarqué multi-application considéré est utilisé,
c'est-à-dire inséré dans un terminal d'utilisation.
En référence à la figure 2a, on indique que ce système embarqué étant inséré dans un terminal d'utilisation, le terminal d'utilisation adresse, par l'intermédiaire du système d'exploitation OS et bien entendu de l'interface principale précitée, une commande de type APDU à l'attention de l'application maître, c'est-à-dire l'application pour laquelle le terminal d'utilisation est conçu. Suite à la réception de cette commande APDU, référencée o1, l'application maitre considérée qui a été activée effectue le traitement de cette commande à l'étape o2 représentée
sur la figure 2a.
Le protocole d'échange de messages entre applications conforme à l'objet de la présente
invention est alors mis en oeuvre de la manière ci-
après. En référence à la figure 2a, ce protocole consiste au moins, en une étape 1000, à transmettre à partir de l'application maître vers le système d'exploitation OS, une requête d'appel d'une application esclave inactive, cette requête d'appel comportant une commande d'entrée/sortie spécifique, dite commande ADPU, destinée à l'application esclave considérée. L'étape 1000 précitée est alors suivie d'une étape 1001, laquelle consiste, par l'intermédiaire du système d'exploitation OS, à désactiver l'application maître et à activer l'application esclave, inactive,
par l'intermédiaire de ce même système d'exploitation.
Les opérations de désactivation, respectivement d'activation des applications maître et esclave sont réalisées de manière classique conformément à la norme ISO 7816 et, pour cette raison, ne seront pas décrites en détail. L'étape 1001 précitée est alors suivie d'une étape 1002 consistant à transmettre à l'application
esclave activée la commande d'entrée/sortie, c'est-à-
dire la commande APDU destinée à cette application esclave, par l'intermédiaire du système d'exploitation OS. Suite à la réception de la commande APDU par l'application esclave après exécution de l'étape 1002, cette étape est suivie d'une étape 1003 d'exécution, au niveau de l'application esclave considérée activée, de la commande d'entrée/sortie ou commande ADPU précitée destinée à cette même application esclave. L'étape 1003 de traitement de la commande reçue par l'application esclave considérée est alors suivie d'une étape de retour, à partir de cette application esclave, d'un message d'acquittement et/ou d'un message de réponse au système d'exploitation OS. Cette étape est notée 1004 sur la figure 2a. Les messages d'acquittement et de
réponse peuvent être combinés.
Bien entendu, on comprend que le protocole objet de la présente invention permet alors une reprise des opérations réalisées par l'application maître dans les conditions habituelles à celles définies par l'exécution des commandes d'interface principale échangées entre l'application maître et le terminal d'utilisation. A titre d'exemple non limitatif, ainsi que représenté à la figure 2a, on indique que dans ce but, l'étape 1004 peut alors être suivie d'une étape 1005 selon laquelle le système d'exploitation procède à la désactivation de l'application esclave et à la réactivation, c'est-à-dire à la restauration, de l'application maître, pour poursuivre les opérations
d'échange avec le terminal d'utilisation.
L'étape 1005 peut alors elle-même être suivie d'une étape 1006 consistant à transmettre à l'application maître ainsi réactivée la réponse de l'application esclave de façon à réaliser le traitement de cette réponse au niveau de l'application maitre,
ainsi que représenté à l'étape 1006.
L'étape 1006 précitée peut alors être suivie d'une étape de réponse 1007, c'est-à-dire d'envoi d'une réponse APDU, par l'application maître au terminal d'utilisation, en fonction des résultats du traitement de la réponse de l'application esclave par
l'application maître réalisés à l'étape 1006.
Une description plus détaillée des chemins
empruntés par les différents échanges de messages de données et/ou de commandes échangés au cours de la mise en oeuvre du protocole objet de la présente invention,
sera maintenant donnée en liaison avec la figure 2b.
On considère à titre d'exemple non limitatif que le terminal d'utilisation est un terminal d'accès à un récepteur de télévision par exemple, comprenant les équipements nécessaires pour autoriser ou non l'accès à
des émissions télévisées à péage.
Le système embarqué utilisé est constitué par exemple par une carte à puce dans laquelle sont
implantées deux applications, une application de porte-
monnaie électronique PME et une application d'accès à des émissions télévisées à péage, notée P TV. D'une manière générale, cette application gère l'accès conditionnel à la diffusion du programme télévisé compte tenu du paiement valablement effectué des droits
d'accès correspondants.
On considère en particulier que dans cet exemple donné, le système embarqué est inséré dans le terminal d'utilisation, que l'application maître dès l'insertion est l'application P TV et que l'application esclave est
l'application PME.
Compte tenu de ces éléments, les opérations ou étapes ol et 02 sont réalisées par l'échange de commandes APDU entre le système d'exploitation, l'application maître PTV et le terminal. Les chemins
d'accès empruntés sont notés (1) sur la figure 2b.
Suite à l'exécution des étapes ol et 02, les étapes 1000 à 1004 sont alors réalisées entre l'application maître PTV, le système d'exploitation OS et bien entendu l'application esclave PME selon le chemin (2). On comprend en particulier que les échanges de messages précités peuvent, le cas échéant, être bidirectionnels sur le chemin considéré, ainsi qu'il
sera décrit ultérieurement dans la description.
L'échange de messages précité est alors réalisé par l'intermédiaire de commandes d'entrées/sorties spécifiques, lesquelles constituent des commandes APDU dédiées aux applications et qui, pour cette raison,
sont notées APDU*.
Bien entendu, les étapes 1005 et 1006 représentées en figure 2a sont réalisées par l'intermédiaire du chemin (2) tel que représenté en figure 2b. Enfin, l'étape 1007 est réalisée à nouveau par l'intermédiaire du chemin (1), c'est-à-dire grâce à la mise en oeuvre de commandes ADPU classiques dans le
cadre de l'environnement de l'interface principale.
En ce qui concerne la mise en oeuvre des étapes 1005 et 1006 et bien entendu ensuite la mise en oeuvre de l'étape 1007, on indique que les étapes 1005 et 1006 peuvent être mises en oeuvre vis-à-vis, non seulement de l'application maître initiale A1, laquelle est restaurée dans son état actif, mais également d'une autre application précédemment inactive, A2, A3, laquelle peut être rendue active successivement par l'intermédiaire du système d'exploitation OS. Ainsi, ainsi que représenté en figure 2c, une ou plusieurs autres applications inactives A2, A3, distinctes de l'application maître initiale A1 et de l'application esclave active A4, peuvent être rendues actives successivement afin de procéder à divers traitements de données, la réponse globale donnée par la dernière, l'application esclave active A4 étant alors transférée à l'application maître initiale A3 et le résultat global successif correspondant, au terminal d'utilisation conformément aux étapes 1005, 1006 et 1007 précitées par l'intermédiaire des applications A2, A1 rendues successivement actives. On comprend en particulier que l'application Ai étant sélectionnée comme application maître par le terminal par une commande APDU, le système d'exploitation OS peut ensuite, sur requête de l'application maître A,, sélectionner l'application A2 puis, tour à tour, les applications A3 et A4, et enfin revenir successivement à l'application maître A1, par l'intermédiaire des applications A2, A3, le retour à l'application maître A1 ayant été effectué par l'intermédiaire de commandes APDU spécifiques notées APDU*. Le retour du résultat global au terminal est
bien entendu réalisé au moyen d'une commande APDU.
Un exemple spécifique de mise en oeuvre des commandes APDU*, c'est-à-dire des commandes APDU spécifiques, sera maintenant donné ci-après dans la
description.
D'une manière générale, l'application maître choisie fait d'abord appel aux services du système d'exploitation OS pour indiquer son souhait d'appeler l'application esclave, l'application PME précédemment
mentionnée en liaison avec la figure 2b.
La requête d'appel de l'application esclave inactive peut alors prendre la forme ci-après: isoStatus = callSlaveApplication (AID, isoHeader, dataln, *dataOut) (1) Dans la commande constitutive de la requête d'appel précitée, AID désigne l'identifiant de l'application esclave choisie conformément aux dispositions de la norme ISO 7816, isoHeader et dataIn contiennent la commande ADPU que l'application maître souhaite adresser à l'application esclave et l'argument *dataOut est un pointeur sur une zone mémoire telle que la zone mémoire RAM 16 représentée en figure la, zone dans laquelle le système d'exploitation OS est en mesure de stocker les données de la réponse de type ADPU fournie par l'application esclave. Le statut ISO renvoyé par l'application esclave est retourné dans la
variable isoStatus.
Suite à la requête d'appel précitée, le système d'exploitation OS active l'application esclave de la même façon que si une sélection par le terminal d'utilisation s'était produite par le chemin (2) représenté sur la figure 2b. le système d'exploitation OS transmet la commande APDU à l'application esclave, l'application PME représentée sur la figure 2b précitée. L'application esclave exécute la commande, puis retourne au système d'exploitation OS, l'application maître étant ensuite réactivée par ce dernier. Le scénario peut alors être répété pour former une séquence o, le cas échéant, une suite d'appels d'applications maître, respectivement esclave telles que représentées en figures 2c, avec retour successif
de la réponse finale au terminal d'utilisation.
En ce qui concerne le mode de mise en oeuvre du protocole, objet de la présente invention, tel que représenté en figures 2a, 2b et 2c, on indique que ce mode de mise en oeuvre correspond à une variante de réalisation désignée par application parallèle / empilée. Lors de la requête d'appel précédemment
mentionnée dans la description et désignée par
callSlaveApplication, l'application maître est suspendue jusqu'au retour de l'application esclave. Ces opérations correspondent aux étapes 1001 et1005 de la figure 2a. Dans ces conditions, la gestion parallèle des applications résulte de l'attribution d'une fonction appelante, respectivement d'une fonction appelée. A l'application maître est conférée une fonction appelante et à l'application esclave est
conférée une fonction appelée.
Toutefois, un tel mode opératoire nécessite la mise en oeuvre d'un système de gestion pour les applications concurrentes multitâches, alors que l'occupation de la mémoire vive 16 est potentiellement importante. Une variante de mise en oeuvre du protocole objet de la présente invention peut consister en une mise en oeuvre séquentielle. Dans cette variante de réalisation, l'appel de la commande callSlaveApplication ne devient effectif qu'une fois l'application maître terminée par retour au système d'exploitation OS. Le système d'exploitation OS active alors l'application esclave et quant celle-ci se termine, le système d'exploitation précité réactive l'application maître en appelant cette dernière sur un point de lancement en mémoire
spécifiquement prévu à cet effet.
Dans ces conditions, l'appel de l'application esclave prend alors la forme suivante: error= callSlaveApplication (AID, isoHeader, dataln) (2) Le statut ISO isoStatus ainsi que les données de réponse dataOut sont alors communiquées par le système d'exploitation à l'application maître au moment de la réactivation de cette dernière, selon la commande APDU: masterApplication.slaveCallBack(isoStatus, dataOut). (3) Le mode de mise en oeuvre correspondant à des applications séquentielles est simple à réaliser et
l'occupation de la mémoire vive 16 est faible.
Cependant, un point de lancement spécifique en mémoire doit être prévu dans l'application maître et le passage entre application maître et application esclave est moins rapide, en raison de sauvegardes nécessaires en
mémoire non volatile.
Le processus de mise en oeuvre du protocole objet de la présente invention pour les applications séquentielles décrit précédemment est illustré par
l'organigramme de la figure 3a.
Dans l'organigramme précité, on indique que les mêmes références désignent bien entendu les mêmes
étapes que dans le cas de la figure 2a.
Toutefois, et de manière particulièrement avantageuse, on indique que l'étape 1000 est alors constituée par une sous-étape 1000a et une sousétape
1000b, la sous-étape 1000a correspondant à une sous-
étape dans laquelle l'application maître sauvegarde son état en mémoire, alors que la sous-étape 1000b correspond à l'appel par l'application maître du système d'exploitation OS pour envoyer une commande
APDU à l'application esclave considérée.
De même, l'étape 1005 est subdivisée en deux sous-étapes, 1005a et 1005b, la sous-étape 1005a consistant en une désactivation de l'application esclave par le système d'exploitation OS et en une réactivation de l'application maître, cette sous-étape, dès la réactivation de cette dernière, étant suivie de la sous-étape 1005b dans laquelle cette application maître restaure son état à partir de la mémoire vive 16, état sauvegardé à la sous-étape 1000l a précédemment citée. Sur la figure 3b, on a représenté, outre les chemins (1) et (2) précédemment mentionnés en figure 2b, un chemin supplémentaire (3), lequel correspond aux opérations de sauvegarde de l'état de l'application maître en mémoire vive, respectivement de restauration de l'état de l'application maître à partir de cette mémoire vive 16. Ces opérations peuvent être réalisées à partir de commandes APDU existant dans l'environnement de l'interface principale et, pour cette raison, le chemin correspondant est représenté en
ligne pointillée.
Alors que les échanges de messages entre applications implantées sur un même système embarqué, conformément au protocole objet de la présente invention, présentent un intérêt majeur et ont pour effet d'augmenter les possibilités de fonctionnalité de ces systèmes embarqués, l'échange incontrôlé de ces messages est susceptible de donner lieu à des risques d'abus, notamment en cas d'intrusion et d'usurpation d'identité, par exemple en vue d'utilisation frauduleuse de l'une ou l'autre des applications. C'est en particulier le cas en ce qui concerne l'utilisation frauduleuse d'une application telle que l'application PME ou de toute application par laquelle des valeurs
fiduciaires sont traitées.
Afin de diminuer ou supprimer le risque correspondant, et conformément à un aspect particulièrement remarquable du protocole objet de la présente invention, la transaction entre l'application maître et l'application esclave, ou, le cas échéant, entre toute application maître et toute application esclave, transaction constituée par les étapes A, B et C, c'est-à-dire des étapes 1000, 1001, 1002 des figures
2a ou 3a précédemment introduites dans la description,
peut comporter avantageusement une procédure d'authentification de la transaction entre application
maître et application esclave.
La procédure d'authentification de la transaction entre application maître et application esclave peut être réalisée, à partir d'au moins une clé et d'un système de cryptographie par l'intermédiaire d'une procédure d'authentification de la requête d'appel de l'application esclave inactive par l'application maître, par exemple, ainsi qu'il sera
décrit ci-après.
Sur authentification de la requête d'appel, valeur vraie de l'authentification, la transaction est
poursuivie. Elle est interrompue sinon.
Dans ce but, ainsi que représenté en figure 4a, l'étape 1000 de la figure 2a ou l'étape 1000b de la figure 3a peut être suivie d'une étape 10001 respectivement 1000b1 d'authentification de la requête d'appel de l'application esclave par l'application maître. Un mode de réalisation particulier de l'étape d'authentification représentée en figure 4a peut consister, ainsi que représenté en figure 4b, à effectuer une opération de signature, respectivement de vérification de signature, d'éléments permettant d'authentifier l'origine de la requête d'appel et ainsi de sécuriser la transaction précitée. Dans ce but, ainsi que représenté sur la figure 4b précitée, à chaque application implantée sur le système embarqué, on associe une clé privée de signature, notée KpRi, et une clé publique de vérification de signature, notée Kpui, l'indice i désignant un identifiant de l'application implantée considérée. Ainsi, à chaque application, maître ou esclave, est associé un jeu de clé de signature,
respectivement de vérification de signature.
Le processus d'authentification consiste alors, au niveau de l'application maître, à engendrer une valeur aléatoire, notée RV, puis à transmettre au moyen d'une commande d'entrées/sorties de type commandes APDU spécifiques, APDU*, cette valeur aléatoire à
l'application esclave.
L'étape A précitée est alors suivie d'une étape B consistant à calculer, au niveau de l'application esclave, à partir de la clé privée associée à cette application esclave, la clé privée KpRi précitée, une valeur de signature de la valeur aléatoire RV reçue par
cette dernière.
L'opération de calcul de signature vérifie alors la relation: SG = fKPRi (RV)
relation contenue à l'étape B de la figure 4b.
Dans la relation précédente, SG représente la valeur de signature calculée et fKPRi désigne l'opération
de calcul de signature de la valeur aléatoire RV.
Après calcul de la valeur de signature précitée, cette valeur est transmise à l'application maître par l'intermédiaire d'un message d'acquittement ou de
réponse contenant la valeur de signature précitée.
L'étape B est alors suivie d'une étape C consistant à procéder, au niveau de l'application maître, à une vérification de la valeur de signature précitée au moyen de la clé publique Kpui associée à la clé privée de l'application esclave auteur de la valeur de signature précitée. L'opération de vérification de signature vérifie la relation: V(SG) = gru (SG)
relation de l'étape C de la figure 4b.
Bien entendu, le passage des étapes successives A, B, C comprend la transmission du processus d'activation de l'application active à l'application inactive, ces opérations étant notées T et représentées par une ligne en trait mixte entre les étapes A, B et C précitées. Ces opérations d'activation/désactivation de chaque application sont connues en tant que telles et,
pour cette raison, ne seront pas décrites en détail.
Bien entendu le processus d'authentification mis en oeuvre dans le cadre du protocole objet de la présente invention n'est pas limité à la procédure d'authentification de la requête d'appel de l'application esclave inactive par l'application maître
précédemment décrite.
En particulier, il est en outre possible de mettre en oeuvre une procédure d'authentification de la requête d'appel de l'application maître, ou le cas échéant, une combinaison logique de ces procédures d'authentification. Dans un tel cas toutefois, bien que cette procédure d'authentification ou cette combinaison de procédures d'authentification ne soit pas décrite, on indique qu'il est avantageux d'utiliser deux paires
de clés.
En ce qui concerne la mise en ouvre des procédures d'authentification à partir d'au moins une clé de cryptographie on peut avantageusement utiliser soit un système cryptographique asymétrique à clé publique et à clé privée, soit un système cryptographique symétrique à clé secrète. Le système cryptographique utilisé permet la mise en oeuvre de l'un des processus de chiffrement/déchiffrement, de calcul et de vérification de signature ou d'échange de valeurs d'authentification.
Une description plus détaillée d'un système
embarqué multi-application constitué de manière non limitative par une carte à puce conforme à l'objet de la présente invention, sera maintenant donnée en
liaison avec la figure 5.
Sur la figure 5, les mêmes éléments que ceux représentés en figure la portent les mêmes références, les éléments supplémentaires nécessaires à la mise en oeuvre du protocole objet de la présente invention ayant
été seuls distingués.
En premier lieu, afin de permettre la mise en oeuvre du protocole objet de la présente invention, le système embarqué objet de l'invention tel que représenté en figure 5 comporte, intégré au système d'exploitation, un jeu d'instructions spécifiques d'entrées/sorties, noté I*APDU comportant au moins les instructions APDU* précédemment mentionnées dans la
description et en particulier une requête d'appel, à
partir d'une application maître active, d'une application esclave inactive, cette requête d'appel correspondant par exemple à la commande donnée selon la relation (1) ou selon la relation (2) mentionnées
précédemment dans la description. En outre, une
commande de transmission des données de réponse par l'intermédiaire du système d'exploitation OS vers l'application maître au moment de la réactivation de celle-ci peut être prévue dans le jeu de commandes, selon la relation (3) précédemment mentionnée dans la
description.
En outre, ainsi que représenté sur la figure 5 précitée, le système embarqué est avantageusement muni des moyens de calcul de signature et de vérification de signature 20 précédemment mentionnés dans la
description. Dans le but de mettre en ouvre le
protocole objet de la présente invention, chaque système embarqué tel que représenté en figure 5 comporte en outre un jeu de clé privée de signature et de clé publique de vérification de signature, les clés Kpri et Kpui, associé à chaque application implantée dans le système embarqué. Une seule clé secrète peut, le cas
échéant, être prévue.
Afin de sécuriser au maximum les transactions entre applications, non seulement les clés privées associées à chaque application, mais également les clés publiques associées à ces dernières, le cas échéant les clés secrètes, sont mémorisées en zone mémoire non volatile à accès sécurisé du système embarqué. On comprend en particulier qu'afin de réaliser les opérations de calcul de signature et de vérification de signature précédemment décrites, chaque application concernée fait bien sûr appel, par l'intermédiaire du système d'exploitation, aux zones mémoire sécurisées précitées et, bien entendu, aux circuits de calcul et de vérification de signature 20 selon les processus classiques d'accès à ces informations sécurisées,
telles que définies dans la norme ISO 7816.
Dans l'exemple décrit précédemment d'échanges de messages entre deux applications, une application d'accès à des programmes de télévision à péage et une application de porte-monnaie électronique,
l'application P_TV doit prouver à l'application porte-
monnaie électronique son identité avant que, bien entendu, cette dernière ne lui permette toute opération de débit et de prélèvement dans le portemonnaie
électronique, et vice versa.
Pour la mise en oeuvre des processus d'authentification, c'est-à-dire d'apport de la preuve d'identité, les mécanismes à clé privée et à clé publique peuvent être utilisés. Parmi ceux-ci, un mode de réalisation particulier consiste à utiliser le système RSA, l'application esclave utilisant la clé privée pour signer la valeur aléatoire engendrée et transmise par l'application maître et l'application maître utilisant ensuite la clé publique associée à la clé privée associée à l'application esclave pour
effectuer la vérification de signature précitée.
La mise en oeuvre du processus d'authentification entre deux applications telles que les applications précédemment mentionnées, fait alors appel à des commandes APDU* qui sont strictement identiques à celles qui sont habituellement utilisées pour l'authentification entre la carte à puce et le terminal d'utilisation. On indique en outre que le processus d'authentification n'est pas nécessairement séparé des autres commandes. En effet, il est également possible de signer toutes les commandes APDU* en ajoutant un code d'authentification dans le champ des données. Dans ces conditions, le récepteur de la commande, par exemple le porte-monnaie électronique jouant le rôle d'application esclave, peut alors s'assurer de l'identité de l'émetteur de la commande, l'application maître constituée par l'application P TV lors de la
réception de la requête d'appel de cette dernière.
On a ainsi décrit un protocole d'échange de messages entre applications implantées sur un système embarqué et un système embarqué permettant la mise en oeuvre d'un tel protocole particulièrement performants, dans la mesure o la mise en oeuvre de ces derniers ne nécessite pas de connaissances d'une interface externe privée et spécifique, la mise en oeuvre de cet échange de messages étant réalisée uniquement à partir du jeu de commandes APDU externes, c'est-à-dire à partir des
commandes de l'interface principale.
En particulier, dans ces conditions, et selon un aspect particulièrement remarquable de la mise en oeuvre du protocole objet de la présente invention,
l'application esclave peut ne pas être modifiée.
En outre, des applications de nature différente, c'est-à-dire des applications dont le langage de programmation ou la conception sont différents, peuvent
être activées.
En outre, la réutilisation de l'interface principale et des commandes APDU permet la réalisation d'une factorisation du code et donc une réduction du volume de codes nécessaires pour la multiplication des
fonctions de tout système embarqué de type classique.
En raison de la réduction ou de la suppression des modifications introduites au niveau de chaque application, le processus de certification de l'ensemble des systèmes embarqués et des applications implantées sur ce dernier est alors grandement simplifié. Différentes variantes de mise en oeuvre du protocole et des systèmes embarqués objets de la présente invention peuvent être envisagées. En particulier, les applications maître et esclave peuvent
être simultanément présentes en mémoire vive 16 ou non.
Le critère de présence simultanée ou non des applications maître et esclave est alors uniquement lié à un compromis entre performances et ressources mémoire
vive nécessaires.
En outre, une optimisation de la requête d'appel selon la relation (1) précédemment mentionnée dans la
description peut être effectuée en séparant la
sélection de l'application esclave, par l'intermédiaire de la variable d'adresse AID correspondante, du traitement, c'est-à-dire des données d'entrée dataIn et des données de sortie dataOut. Dans ces conditions, deux appels au système d'exploitation OS sont alors nécessaires, mais ce mode de réalisation peut se révéler plus efficace lorsque la communication comprend
plusieurs commandes.
Claims (9)
1. Protocole d'échange de messages entre applications implantées sur un système embarqué muni d'un système d'exploitation, ce système d'exploitation permettant, par commandes d'entrées/sorties, l'échange de messages de données et de commandes d'interface principale entre une application maître active parmi ces applications, les autres applications étant inactives, et un système externe par l'intermédiaire d'une interface d'entrée/sortie, caractérisé en ce qu'il consiste au moins à: a) transmettre, à partir de l'application maître, vers le système d'exploitation, une requête d'appel d'une application esclave inactive, cette requête d'appel comportant une commande d'entrée/sortie spécifique destinée à cette application esclave; b) désactiver l'application maître et activer cette application esclave inactive par l'intermédiaire du système d'exploitation; c) transmettre à l'application esclave activée la commande d'entrée/sortie destinée à cette application esclave, par l'intermédiaire du système d'exploitation; d) exécuter au niveau de cette application esclave activée la commande d'entrée/sortie destinée à cette application esclave; e) retourner à partir de cette application esclave un message d'acquittement et/ou de réponse au système d'exploitation.
2. Protocole selon la revendication 1, caractérisé en ce que celui-ci consiste en outre, suite à l'étape e), à: f) désactiver cette application esclave et réactiver l'application maître par l'intermédiaire du système d'exploitation et à transmettre à cette application
maître la réponse de l'application esclave.
3. Protocole selon la revendication 2, caractérisé en ce que ladite requête d'appel comporte en outre un argument consistant en un pointeur désignant une zone mémoire dans laquelle le système d'exploitation peut procéder au stockage de la réponse de cette application esclave activée, suite à l'exécution de la commande d'entrée/sortie destinée à
cette dernière.
4. Protocole selon la revendication 1, caractérisé en ce que, pour une gestion parallèle desdites applications, suite à l'étape a) consistant à transmettre, à partir de l'application maître, vers le système d'exploitation, une requête d'appel d'une application esclave inactive, celui-ci consiste à: - suspendre l'application maître jusqu'au retour au système d'exploitation du message d'acquittement à partir de cette application esclave, la gestion parallèle desdites applications résultant de l'attribution d'une fonction appelante respectivement d'une fonction appelée, à l'application maître étant conférée une fonction appelante et à l'application esclave étant conférée une fonction appelée; - attribuer aux applications concurrentes un système
de gestion spécifique hiérarchisé.
5. Protocole selon la revendication 1, caractérisé en ce que, à chaque application du système embarqué étant associée au moins une clé de cryptographie, la transaction entre application maître et application esclave constituée par les étapes a), b) et c), comporte une procédure d'authentification de cette transaction, à partir de ladite clé de
cryptographie.
6. Protocole selon la revendication 1, caractérisé en ce que la transaction entre l'application maitre et l'application esclave, constituée par les étapes a), b) et c), comporte en outre une procédure d'authentification de la requête d'appel de l'application esclave inactive par
l'application maître.
7. Protocole selon la revendication 6, caractérisé en ce que, à chaque application du système embarqué étant associées une clé privée de signature et une clé publique de vérification de signature, ladite procédure d'authentification consiste au moins: - à engendrer, au niveau de l'application maître, une valeur aléatoire et à transmettre au moyen d'une commande d'entrées/sorties cette valeur aléatoire à ladite application esclave; - à calculer à partir de ladite clé privée, au niveau de ladite application esclave, une valeur de signature de ladite valeur aléatoire et à transmettre à ladite application maître un message d'acquittement ou de réponse contenant ladite valeur de signature; - à procéder, au niveau de ladite application maître, à une vérification de ladite valeur de signature au moyen de ladite clé publique associée à ladite clé privée de ladite application esclave, auteur de
ladite valeur de signature.
8. Système embarqué multi-application comportant un système d'exploitation permettant, par commandes d'entrées/sorties, l'échange de messages de données et de commandes d'interface principale entre une application maître active parmi ces applications, les autres applications étant inactives, et un système externe par l'intermédiaire d'une interface d'entrée/sortie, caractérisé en ce qu'il comporte en outre, intégré audit système d'exploitation, un jeu d'instructions spécifiques d'entrées/sorties comportant au moins: - une requête d'appel à partir d'une application maître, active, d'une application esclave, inactive - un message d'acquittement ou de réponse de
l'application esclave au système d'exploitation.
9. système embarqué multi-application selon la revendication 8, caractérisé en ce que ce système embarqué étant muni de moyens de calcul de signature, celui-ci comporte en outre un jeu de clé privée de signature et de clé publique de vérification de signature associé à chaque application, lesdits jeux de clés étant mémorisés en zone mémoire non volatile à
accès sécurisé dudit système embarqué.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0009657A FR2812101A1 (fr) | 2000-07-24 | 2000-07-24 | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant |
| PCT/FR2001/002364 WO2002008897A1 (fr) | 2000-07-24 | 2001-07-20 | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0009657A FR2812101A1 (fr) | 2000-07-24 | 2000-07-24 | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2812101A1 true FR2812101A1 (fr) | 2002-01-25 |
Family
ID=8852830
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0009657A Withdrawn FR2812101A1 (fr) | 2000-07-24 | 2000-07-24 | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR2812101A1 (fr) |
| WO (1) | WO2002008897A1 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8544735B2 (en) | 2011-05-23 | 2013-10-01 | Mastercard International Incorporated | Combicard transaction method and system having an application parameter update mechanism |
| CN111698762A (zh) * | 2019-03-14 | 2020-09-22 | 成都鼎桥通信技术有限公司 | wifi信息获取方法和装置 |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6824064B2 (en) | 2000-12-06 | 2004-11-30 | Mobile-Mind, Inc. | Concurrent communication with multiple applications on a smart card |
| CN100351799C (zh) * | 2005-09-12 | 2007-11-28 | 浙江大学 | 嵌入式实时操作系统中基于消息对象的任务间通信方法 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998019237A1 (fr) * | 1996-10-25 | 1998-05-07 | Schlumberger Systemes | Utilisation de langage de programmation evolue avec un controleur microprogramme |
-
2000
- 2000-07-24 FR FR0009657A patent/FR2812101A1/fr not_active Withdrawn
-
2001
- 2001-07-20 WO PCT/FR2001/002364 patent/WO2002008897A1/fr active Application Filing
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998019237A1 (fr) * | 1996-10-25 | 1998-05-07 | Schlumberger Systemes | Utilisation de langage de programmation evolue avec un controleur microprogramme |
Non-Patent Citations (5)
| Title |
|---|
| BERSHAD B N ET AL: "LIGHTWEIGTH REMOTE PROCEDURE CALL", ACM TRANSACTIONS ON COMPUTER SYSTEMS,US,ASSOCIATION FOR COMPUTING MACHINERY. NEW YORK, vol. 8, no. 1, 1 February 1990 (1990-02-01), pages 37 - 55, XP000113133, ISSN: 0734-2071 * |
| MONTGOMERY M ET AL: "Secure object sharing in Java Card", PROCEEDINGS OF THE USENIX WORKSHOP ON SMARTCARD TECHNOLOGY (SMARTCARD '99), PROCEEDINGS OF THE USENIX WORKSHOP ON SMARTCARD TECHNOLOGY, CHICAGO, IL, USA, 10-11 MAY 1999, 1999, Berkeley, CA, USA, USENIX Assoc, USA, pages 119 - 127, XP002167363, ISBN: 1-880446-34-0, Retrieved from the Internet <URL:http://www.usenix.org/event/smartcard99/full_papers/montgomery/montgomery.pdf> [retrieved on 20010508] * |
| SUN MICROSYSTEMS: "JAVA CARD 2.1.1 APPLICATION PROGRAMMING INTERFACE", JAVA CARD SPECIFICATIONS REV. 1.0, 18 May 2000 (2000-05-18), pages i - ii,117, XP002167365, Retrieved from the Internet <URL:ftp.java.sun.com/pub/javacard/adjfklad-211/java_card_kit-2_1_1-doc.zip> [retrieved on 20010508] * |
| SUN MICROSYSTEMS: "JAVA CARD 2.1.1 RUNTIME ENVIRONMENT (JCRE) SPECIFICATION", JAVA CARD SPECIFICATIONS REV. 1.0, 18 May 2000 (2000-05-18), XP002167364, Retrieved from the Internet <URL:ftp.java.sun.com/pub/javacard/adjfklad-211/java_card_kit-2_1_1-doc.zip> [retrieved on 20010508] * |
| ZHIQUN CHEN: "Java Card Technology for Smart Cards: Architecture and Programmer's Guide", 2 June 2000, ADDISON-WESLEY PUB CO., USA, XP002167366 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8544735B2 (en) | 2011-05-23 | 2013-10-01 | Mastercard International Incorporated | Combicard transaction method and system having an application parameter update mechanism |
| US9010631B2 (en) | 2011-05-23 | 2015-04-21 | Mastercard International, Inc. | Combicard transaction method and system having an application parameter update mechanism |
| US9582796B2 (en) | 2011-05-23 | 2017-02-28 | Mastercard International Incorporated | Combicard transaction method and system having an application parameter update mechanism |
| CN111698762A (zh) * | 2019-03-14 | 2020-09-22 | 成都鼎桥通信技术有限公司 | wifi信息获取方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2002008897A1 (fr) | 2002-01-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1004100B1 (fr) | Dispositif portable electronique pour systeme de communication securisee, et procede d'initialisation de ses parametres | |
| EP3243176B1 (fr) | Procédé de traitement d'une transaction à partir d'un terminal de communication | |
| EP0707290B1 (fr) | Procédé de chargement d'une zone mémoire protégée d'un dispositif de traitement de l'information et dispositif associé | |
| FR2779018A1 (fr) | Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees | |
| EP0552077B1 (fr) | Carte à mémoire de masse pour microordinateur avec facilités d'exécution de programmes internes | |
| 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 | |
| EP3455812B1 (fr) | Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant | |
| WO2012038187A1 (fr) | Protection d'un canal de communication d'un dispositif de telecommunication couple a un circuit nfc contre un deroutement | |
| WO2001084512A1 (fr) | Carte a puce multi-applicatives | |
| FR2987199A1 (fr) | Securisation d'une transmission de donnees. | |
| EP4036717A1 (fr) | Démarrage d'une application | |
| EP4199411B1 (fr) | Procédé de détermination d'une autorisation de mise en uvre d'une ressource composite, chaîne de blocs, dispositifs et programme correspondants | |
| EP1769470A1 (fr) | Procede de gestion d'une carte a puce multi-applicative | |
| WO2016207715A1 (fr) | Gestion securisee de jetons électroniques dans un telephone mobile. | |
| EP1356656A2 (fr) | Protocole de transmission d'une pluralite de flux logiques d'echange multiple de couples de commande/reponse sur un canal physique unique | |
| FR2812101A1 (fr) | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant | |
| EP3136283B1 (fr) | Dispositif et procédé sécurisation de commandes échangées entre un terminal et circuit intégré | |
| EP1141903B1 (fr) | Dispositif et procede d'initialisation d'un programme applicatif d'une carte a circuit integre | |
| EP3987390A1 (fr) | Système d'applications de service pour terminaux de paiement | |
| FR2923041A1 (fr) | Procede d'ouverture securisee a des tiers d'une carte a microcircuit. | |
| WO2002010918A1 (fr) | Procede de securisation de l'acces a une application residante sur une carte utilisateur cooperant avec un terminal d'un systeme de communication, et terminal correspondant | |
| EP4390738A1 (fr) | Protection d'un dispositif électronique | |
| EP4390739A1 (fr) | Protection d'un dispositif électronique | |
| EP3514749B1 (fr) | Procede de controle de regles de dependances d'objets mis a jour dans un microcircuit, et dispositif correspondant | |
| FR3043820A1 (fr) | Dispositif electronique comprenant une pluralite de puces electroniques, et terminal de lecture apte a cooperer avec un tel dispositif |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |