EP1101205A1 - Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal - Google Patents

Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal

Info

Publication number
EP1101205A1
EP1101205A1 EP99932970A EP99932970A EP1101205A1 EP 1101205 A1 EP1101205 A1 EP 1101205A1 EP 99932970 A EP99932970 A EP 99932970A EP 99932970 A EP99932970 A EP 99932970A EP 1101205 A1 EP1101205 A1 EP 1101205A1
Authority
EP
European Patent Office
Prior art keywords
card
action
server
counter
actions
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
Application number
EP99932970A
Other languages
German (de)
English (en)
Inventor
Dominique Dreher
Patrick Imbert
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.)
Gemplus SA
Original Assignee
Gemplus Card International SA
Gemplus SA
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 Gemplus Card International SA, Gemplus SA filed Critical Gemplus Card International SA
Publication of EP1101205A1 publication Critical patent/EP1101205A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0813—Specific details related to card security
    • G07F7/082—Features insuring the integrity of the data on or in the card
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0833—Card having specific functional components
    • G07F7/084—Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis

Definitions

  • the present invention relates to systems for exchanging messages between application server and smart cards using a communication network. It applies to exchanges carried out through telecommunication networks, switched telephone network, cellular network or Internet network.
  • the messages exchanged between an application server and the corresponding application in a smart card pass through an intermediate piece of equipment which will be designated by terminal below.
  • a user's smart card cooperates with the terminal to allow exchanges.
  • the terminal is a telecommunications terminal.
  • the terminal is computer type computer equipment equipped with a smart card read / write interface.
  • a server under the control of a card issuing body wishing to perform a secure action in a smart card (or in an application of said card) via a telephone network, uses cryptographic certificates making it possible to ensure the security of exchanges.
  • a message is lost during transmission or execution or if fraud is attempted, the re-synchronization of server-card messages can pose security problems.
  • the terminal is a dedicated and secure terminal under the control of the issuing body (by example an ATM machine under the control of a bank)
  • the loss of a message is compensated by synchronization mechanisms involving both the server software and the dedicated terminal software.
  • the dedicated terminal is either physically secure (DAB) or contains a SAM (Secure Authentication Module) module inside, and in all cases is closely controlled by the issuing body. If the terminal used is not a dedicated terminal
  • the synchronization mechanisms cannot be based on the security of the terminal, since it is not controllable by the transmitter. Indeed, it is important to be able to resynchronize the source of the messages and the smart card in the event of transmission problems on the network. This problem was posed in terms of security vis-à-vis operators and service providers. To date, there is no system provided for ensuring synchronization between the card and the server, in cases where during a transaction in progress, consequently accepted by the card, the server takes advantage of the connection to send a message comprising one or more actions to be implemented by the card, these actions can for example be reloading of value units or parameters (monetary or other) or loading of a new application. Indeed, it is provided in the more general framework of multi-application cards, that messages are sent while the user has made a transaction request in order to send orders for actions to be taken during the application process for the current transaction.
  • Such messages will make it possible, for example, to order recharging of an electronic purse in the case of an electronic purse application, or to modify banking parameters of the banking application, or the loading of a new application in the card. .
  • the object of the invention is that the server can detect the execution faults of one or more actions or commands, linked to a loss of messages between the server and the smart card or to action execution faults in the card, said messages having been transmitted to the card possibly during a transaction in progress, this in order to inform the server so that the latter determines which are the last actions or commands not executed by the card.
  • the server may for example send back the message containing the said action or actions and allow their execution.
  • the invention particularly relates to a method of controlling the execution of an action request transmitted by a server to a card via a terminal, said card comprising an action counter, characterized in that 'it comprises the following steps: a) on the transmission by the server of a message comprising a request comprising one or more actions to be implemented by the card, the server stores the number n of actions of the request; b) on receipt of the message, the card successively executes the action or actions of the request by incrementing its action counter between each action if the action has been performed correctly and by refusing this action and the successive actions if The action did not perform well without incrementing the counter. c) the variation between the value in the card and that stored in the server is compared and it is determined that the last x actions (commands) are not executed if the result of the comparison has a difference of x.
  • the increment of the action counter corresponds to the number of actions correctly executed.
  • the number x is equal to 0 if all the actions are correctly executed, this number x can therefore vary from 1 to n if the last or all the actions failed.
  • the card transmits to the server the current value of its counter before and after execution of the action command.
  • the card calculates the value of the variation in its counter continued upon execution of the action command and transmits it to the server.
  • any exchange of the value of the card action counter is carried out systematically in a secure manner.
  • the last value of the card action counter is transmitted with a cryptogram, the calculation of which implies the said last value.
  • the last current value of the card action counter is transmitted to the server in real time, that is to say during the transaction in progress.
  • the value could be transmitted by means of the acknowledgment message of the transaction in progress in the card.
  • the value of the card action counter is transmitted to the server in deferred time.
  • the value of the action counter could be transmitted by means of a message of a new transaction request by the card by the server.
  • the value of the card action counter is transmitted by means of an information message sent for the card to the server.
  • the invention also relates to a card for implementing the aforementioned method comprising a counter and means for managing this counter, characterized in that said management means are capable of incrementing said action counter between each action if the The action has been executed well and should not be incremented for this action or for the following actions if this action has not been executed.
  • FIG. 1 illustrates the exchange of messages between the server and the smart card according to the invention
  • FIG. 2 illustrates in detail the exchange of messages between the server and the smart card in the event of a message loss
  • n By request for actions is meant a message comprising a set of n commands, n of course being able to be equal to 1.
  • the server 2 takes advantage of a transaction in progress in a card 1 to send it a request comprising one or more actions that the card must perform.
  • an action request will be issued with the response to the transaction in progress if said transaction requires a response. If not, create a response containing only the action request.
  • the terminal which is in communication with the server receives the message corresponding to this response, cleans this message from its envelope to transmit the actions to the card.
  • a request for actions can comprise several actions to be undertaken by the card, that is to say as specified at the beginning of the description, a set of n commands.
  • a request for actions could be a request to change one or more parameters in an application program or, loading a new application or, loading value units.
  • the change of a parameter corresponds to an action for the card which is an erase and write operation at a predetermined address.
  • the change of several parameters corresponds to as many erasing and writing operations at separate addresses as parameters and consequently to as many actions to be undertaken as there are parameters to change.
  • Card side
  • the card 1 increments after each correctly performed action, the action counter CA as soon as it receives from the server one or more actions to be undertaken and that it has been able to carry out the execution of each of these actions.
  • the value of the counter is raised to the server for example each time the card sends a message to the server (message 3 or message 4 in FIG. 1).
  • the value of the counter can be raised to server 2 essentially during the following actions:
  • the stored transaction is sent back to the server so that the server can start the merchant payment process with which the transaction took place, the action counter CA can be reassembled with this transaction.
  • the value of the content of the action counter is always raised to the server either in real time when it is done during an acknowledgment or in deferred time during a new transaction request or during a rise in a transaction storage.
  • the server For each card containing an application dedicated to it having a request for actions in progress, the server must store: - the identification number of the application,
  • the server to which an application belonging to a multi-application smart card belongs can, during any transaction requested by the card, order an action such as reloading units, or loading a program or loading new parameters for a program residing in the card.
  • the server can thus send actions to the card by a script mechanism that cannot be interpreted by the terminal 3, which is located between the server and the card to ensure communication.
  • Terminal 3 transmits the message (s) received in the script to the card transparently.
  • the card prepares the transaction and a cryptogram, that is to say the authentication data, subsequently designated by MAC and transmits to the terminal.
  • the banking application attaches the current value CA of its share counter secured by the cryptogram.
  • the terminal reports the transaction to the bank server.
  • the card sends a transaction request message containing the MAC1 data as well as the value of the action counter CA, and the identification of the requested transaction.
  • the server checks the authentication data of the MAC1 card and processes the transaction.
  • the server can at this time perform an action in the card application.
  • it may be a loading of monetary parameter in the card, but as has been said, other actions such as recharging an electronic purse are also possible.
  • the server will prepare one or more parameters loading commands contained in an information field called script 1 below, and the MAC2 security authentication data.
  • the action request is sent by a message 2 which may contain the response to the transaction in progress if such a response is planned for the application concerned.
  • script 1 When script 1 is sent to the card, the server stores this script 1 in a database, by associating data relating to the card, as well as the current value CA of the card action counter ( return of the card to the server during the transaction request). This information will allow server-card synchronization.
  • the card sends a secure acknowledgment to the server including the content CA 'in real time. This can then compare the value returned by the acknowledgment with the value stored in its database.
  • the server identifies that this card has not received script 1 (or that script 1 has not been performed correctly in the card) thanks at the value CA 'of the action counter which is returned to the server and compared to the CA value stored in the server.
  • CA ' is less than CA and not equal, this means that the last or the last actions were not carried out correctly.
  • the server updates its database DB, by erasing the value CA to set the value CA '.
  • the server is again synchronized and can restart the last action or actions not executed by the card.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Credit Cards Or The Like (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé d'échange de messages avec synchronisation entre un serveur d'application et au moins une carte à puce. Pour cela la carte transmet un message au serveur contenant la dernière valeur courante d'un compteur d'actions que le serveur stocke; le serveur émet un message comportant une demande comprenant une ou plusieurs actions à mettre en oeuvre par la carte et stocke le nombre n d'actions de la demande; la carte reçoit le message, exécute successivement la ou les actions de la demande en incrémentant son compteur d'actions entre chaque action si l'action s'est bien exécutée; lors d'une demande de transaction par la carte, le serveur compare la valeur du compteur d'actions reçue, à la dernière valeur stockée, incrémentée du nombre d'actions contenues dans la demande d'actions précédente et, exploite le résultat de cette comparaison.

Description

PROCEDE DE CONTROLE DE L'EXECUTION D'UNE DEMANDE D'ACTIONS TRANSMISE PAR UN SERVEUR VERS UNE CARTE A
PUCE VIA UN TERMINAL
La présente invention concerne les systèmes d'échanges de messages entre serveur d'application et cartes à puce empruntant un réseau de communication. Elle s'applique aux échanges s 'effectuant à travers les réseaux de télécommunication, réseau téléphonique commuté, réseau cellulaire ou réseau Internet. (
Généralement, les messages échangés entre un serveur d'application et l'application correspondante dans une carte à puce transitent par un équipement intermédiaire que l'on désignera par terminal dans la suite. La carte à puce d'un utilisateur coopère avec le terminal pour permettre les échanges.
Dans le cas où le réseau emprunté est un réseau de téléphonie, le terminal est un terminal de télécommunication. Dans le cas où le réseau emprunté est un réseau informatique, le terminal est un équipement informatique de type ordinateur équipé d'une interface de lecture/écriture de cartes à puce.
Un serveur sous contrôle d'un organisme émetteur de carte, désirant effectuer une action sécurisée dans une carte à puce (ou dans une application de ladite carte) via un réseau téléphonique, utilise des certificats cryptographique permettant d'assurer la sécurité des échanges. Cependant, en cas de perte d'un message durant la transmission ou l'exécution ou en cas de tentative de fraude, la re-synchronisation des messages serveur- cartes peut poser des problèmes sécuritaires.
Dans le cas où le terminal est un terminal dédié et sécurisé sous contrôle de l'organisme émetteur (par exemple un distributeur automatique de billets DAB sous contrôle d'une banque), la perte d'un message est compensée par des mécanismes de synchronisation mettant en jeu à la fois le logiciel du serveur et le logiciel du terminal dédié. Le terminal dédié est sécurisé soit physiquement (DAB) soit contient à l'intérieur un module SAM (Secure Authentication Module) , et dans tous les cas est contrôlé étroitement par l'organisme émetteur . Si le terminal utilisé n'est pas un terminal dédié
» et sécurisé (par exemple téléphone GSM, PC sous
Internet,...), les mécanismes de synchronisation ne peuvent pas être basés sur la sécurité du terminal, du fait que celui-ci n'est pas contrôlable par l'émetteur. En effet, il est important de pouvoir resynchroniser la source des messages et la carte à puce en cas de problème de transmission sur le réseau. Ce problème a été posé en terme de sécurité vis-à-vis des opérateurs et des fournisseurs de service. II n'existe pas à ce jour de système prévu pour assurer une synchronisation entre la carte et le serveur, dans les cas où pendant une transaction en cours, acceptée par conséquent par la carte, le serveur profite de la connexion pour envoyer un message comportant une ou plusieurs actions à mettre en oeuvre par la carte, ces actions pouvant être par exemple un rechargement d'unités de valeur ou de paramètres (monétaires ou autre) ou un chargement d'une nouvelle application. En effet, il est prévu dans le cadre plus général des cartes multi-applicatives, que des message soient envoyés alors que l'utilisateur a fait une demande de transaction afin d'envoyer des commandes pour des actions à entreprendre pendant le déroulement de l'application pour la transaction en cours.
De tels messages permettront par exemple de commander un rechargement de porte-monnaie électronique dans le cas d'une application porte-monnaie électronique, ou de modifier des paramètres bancaires de l'application bancaire, ou le chargement d'une nouvelle application dans la carte.
Il est clair que dans cette situation, le serveur ne sera pas informé dans le cas où ledit message est perdu.
En d'autres termes, effectuer des actions sécurisées sur un terminal non dédié est faisable aujourd'hui mais impose, soit des contraintes utilisateur fortes (cartes ou applications bloquées si l'action sécuritaire n'est pas parvenue à terme), soit des risques de perte d'informations (par exemple perte d'une transaction de rechargement d'un porte-monnaie électronique) .
Le but de l'invention est que le serveur puisse détecter les défauts d'exécution d'une ou plusieurs actions ou commandes, liés à une perte de messages entre le serveur et la carte à puce ou à des défauts d'exécution d'actions dans la carte, lesdits messages ayant été transmis à la carte éventuellement pendant une transaction en cours, ceci afin d'en informer le serveur pour que ce dernier détermine quelles sont les dernières actions ou commandes non exécutées par la carte.
Selon une procédure pré-établie en fonction de la ou des actions non mises en oeuvre, le serveur pourra par exemple renvoyer le message contenant la dite ou les dites actions et permettre leur exécution. A cette fin, l'invention a particulièrement pour objet un procédé de contrôle de l'exécution d'une demande d'actions transmise par un serveur vers une carte via un terminal, ladite carte comportant un compteur d'actions, caractérisé en ce qu'il comporte les étapes suivantes : a) à l'émission par le serveur d'un message comportant une demande comprenant une ou plusieurs actions à mettre en oeuvre par la carte, le serveur stocke le nombre n d'action de la demande; b) à la réception du message, la carte 'exécute successivement la ou les actions de la demande en incrémentant son compteur d'actions entre chaque actions si l'action s'est bien exécutée et en refusant cette action et les actions successives si l'action ne s'est pas bien exécutée sans incré enter son compteur. c) on compare la variation entre la valeur dans la carte et celle stockée dans le serveur et on détermine que les x dernières actions (commandes) ne sont pas exécutées si le résultat de la comparaison présente un écart de x.
L'incrémentation du compteur d'action correspond au nombre d'actions correctement exécutées.
Le nombre x est égal à 0 si toutes les actions sont correctement exécutées, ce nombre x peut donc varier de 1 à n si la dernière ou toutes les actions ont échoué.
Pour comparer la variation entre la valeur dans la carte et celle stockée dans le serveur, la carte transmet au serveur la valeur courante de son compteur avant et après exécution de la commande d'actions.
Pour comparer la variation entre la valeur dans la carte et celle stockée dans le serveur, la carte calcule la valeur de la variation de son compteur suite à l'exécution de la commande d'actions et la transmet au serveur.
Selon une autre caractéristique, tout échange de la valeur du compteur d'actions de la carte est effectué systématiquement de manière sécurisé.
A cette fin, la dernière valeur du compteur d'actions de la carte est transmise avec un cryptogramme dont le calcul implique la dite dernière valeur. Selon une autre caractéristique la dernière valeur courante du compteur d'actions de la carte est transmise au serveur en temps réel, c'est-à-dire pendant la transaction en cours.
Selon un exemple la valeur pourra être transmise au moyen du message d'acquittement de la transaction en cours dans la carte.
Selon une autre caractéristique la valeur du compteur d'actions de la carte est transmise au serveur en temps différé. Selon un exemple la valeur du compteur d'actions pourra être transmise au moyen d'un message d'une nouvelle demande de transaction par la carte par le serveur.
Selon un autre exemple la valeur du compteur d'actions de la carte est transmise au moyen d'un message d'information émis pour la carte au serveur.
L'invention a également pour objet une carte pour mettre en oeuvre le procédé précité comportant un compteur et des moyens de gestion de ce compteur, caractérisée en ce que lesdits moyens de gestion sont aptes à incrémenter ledit compteur d'actions entre chaque action si l'action s'est bien exécutées et à ne pas l' incrémenter pour cette action ni pour les actions suivantes si cette action n'a pas été exécutée. D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description ci-après donnée à titre d'exemple non limitatif et en regard des dessins sur lesquels :
- la figure 1, illustre des échanges de messages entre serveur et carte à puce selon l'invention,
- la figure 2, illustre de manière détaillée des échanges de messages entre serveur et carte à puce dans le cas d'une perte de message,
- la figure 3, illustre un autre cas de perte de message.
On entend par demande d'actions, un message comportant un jeu de n commandes, n pouvant bien entendu être égal à 1.
On pourra se reporter pour mieux comprendre la suite au schéma de la figure 1.
Dans toute la suite, on a pris comme exemple le cas où le serveur 2 profite d'une transaction en cours dans une carte 1 pour lui envoyer une demande comportant une ou plusieurs actions que la carte devra exécuter.
Bien entendu dans ce cas une demande d'action sera émise avec la réponse à la transaction en cours si ladite transaction nécessite une réponse. Si ce n'est pas le cas, crée une réponse contenant uniquement la demande d'actions. Le terminal qui est en communication avec le serveur reçoit le message correspondant à cette réponse, épure ce message de son enveloppe pour transmettre les actions à la carte.
Une demande d'actions peut comporter plusieurs actions à entreprendre par la carte, c'est-à-dire comme précisé au début de la description, un jeu de n commandes . A titre d'exemple une demande d'actions pourra être une demande de changement d'un ou plusieurs paramètres dans un programme d'application ou, le chargement d'une nouvelle application ou, le chargement d'unités de valeur.
Le changement d'un paramètre correspond à une action pour la carte qui est une opération d'effacement et écriture à une adresse prédéterminée.
Le changement de plusieurs paramètres correspond à autant d'opérations d'effacement et écriture à des adresse distinctes que de paramètres et par conséquent à autant d'actions à entreprendre qu'il y a de paramètres à changer.
On va maintenant détailler ce qui se passe côté carte et côté serveur. Côté carte :
La carte 1 incrémente après chaque action correctement effectuée, le compteur d'actions CA dès qu'elle reçoit du serveur une ou plusieurs actions à entreprendre et qu'elle a pu mener à bien l'exécution de chacune de ces actions.
La valeur du compteur est remontée vers le serveur par exemple chaque fois que la carte envoie un message au serveur (message 3 ou message 4 sur la figure 1) . La valeur du compteur peut être remontée vers le serveur 2 essentiellement lors des actions suivantes :
- lorsqu'il y a un acquittement de transaction (si durant une transaction un message d'acquittement est remonté au serveur on peut mettre dans cet acquittement la valeur du compteur d'actions), (exemple : message 3) ,
- lorsqu'il y a une demande de transaction ou d'authentification de la carte vers le serveur, (exemple : message 4) , - dans le cas de cartes bancaires ou de porte- monnaie électronique :
- on stocke dans chaque terminal 3 toute transaction passée, - la transaction stockée est remontée au serveur pour que le serveur puisse enclencher le processus de paiement du marchand auprès duquel a eu lieu la transaction, le compteur d'actions CA peut être remonté avec cette transaction. Ainsi, la valeur du contenu du compteur d'actions est toujours remontée au serveur soit en temps réel lorsque cela est fait lors d'un acquittement ou en temps différé lors d'une nouvelle demande de transaction ou lors d'une remontée d'un stockage de transactions.
Côté serveur :
Pour chaque carte contenant une application qui lui est dédiée ayant une demande d'actions en cours, le serveur doit stocker : - le numéro d'identification de l'application,
- la valeur courante du compteur- d'actions,
- la liste des actions en cours pour cette carte. Ainsi, le serveur auquel appartient une application placée dans une carte à puce multi-applicative, peut lors de n'importe quelle transaction demandée par la carte, commander une action telle qu'un rechargement d'unités, ou qu'un chargement d'un programme ou qu'un chargement de nouveaux paramètres pour un programme résidant dans la carte. Le serveur peut ainsi envoyer des actions à la carte par un mécanisme de script non interprétable par le terminal 3 , qui se trouve entre le serveur et la carte pour assurer la communication. Le terminal 3 transmet le ou les messages reçus dans le script à la carte de manière transparente.
On va maintenant détailler l'ensemble des traitements dans le cas où la remontée du contenu du compteur d'actions se fait en temps réel et dans le cas où tout se passe bien, c'est-à-dire dans le cas où il n'y a pas de perte de message et où l'exécution par la carte s'est bien déroulée. On pourra se reporter au mode de réalisation particulier illustré par le schéma de la figure 1 pour mieux comprendre.
- A l'instant dti le porteur- demande via son terminal 3 une transaction ( un paiement ou une autre transaction): message 1.
- La carte prépare la transaction et un cryptogramme, c'est-à-dire les données d' authentification, désignées par la suite par MAC et transmet au terminal. Associé à cette transaction, l'application bancaire joint la valeur actuelle CA de son compteur d'actions sécurisé par le cryptogramme.
- Le terminal remonte la transaction au serveur bancaire. De façon pratique, la carte envoie un message de demande de transaction contenant les données MAC1 ainsi que la valeur du compteur d'action CA, et l'identification de la transaction demandée.
- Le serveur vérifie les données d' authentification de la carte MAC1 et traite la transaction. Le serveur peut à ce moment effectuer une action dans l'application de la carte.
Selon un exemple particulier, il peut s'agir d'un chargement de paramètre monétaire dans la carte, mais comme cela a été dit, d'autres actions du type rechargement d'un porte-monnaie électronique sont également possibles.
- Pour cela, le serveur va préparer une ou plusieurs commandes de chargement de paramètres contenues dans un champ d'information dénommé ci-après script 1, et les données d'authentification sécuritaire MAC2.
- La demande d'action est envoyée par un message 2 qui peut contenir la réponse à la transaction en cours si une telle réponse est prévue pour l'application concernée.
Au moment de l'envoi du script 1 à la carte, le serveur stocke dans une base de donnée ce script 1, en y associant les données relatives à la carte, ainsi que la valeur courante CA du compteur d'actions de la carte (remontée de la carte vers le serveur durant la demande de transaction) . Ces informations vont permettre d'effectuer la synchronisation serveur-carte. - La carte qui reçoit les commandes une à une du script 1, vérifie le cryptogramme MAC2 , et effectue de manière atomique (c'est-à-dire en une fois et de manière indivisible) action par action de la liste du script 1 et incrémente le contenu CA du compteur après chaque action si celle-ci s'est bien déroulée. Lorsqu'une action s'est mal déroulée, le compteur d'action n'est pas incrémente et les autres actions ne sont pas acceptées.
- Afin de remonter au serveur la nouvelle valeur CA' du compteur d'actions CA de la carte, plusieurs schémas sont possibles :
- remontée lors d'un message d'acquittement de la transaction en cours c'est-à-dire en temps réel, (correspond au message 3 de la transaction en cours) ; - remontée de la valeur du CA' durant la prochaine transaction, (correspond au message 4 se produisant à l'instant dtj ) ;
- à n'importe quel moment c'est à dire lorsque la carte envoie des informations au serveur.
- Dans le cas de l'exemple décrit, la carte renvoie un acquittement sécurisé au serveur incluant le contenu CA' en temps réel. Celui-ci peut alors comparer la valeur retournée par l'acquittement avec la valeur stockée dans sa base.
Si la valeur CA' = CA+n, n étant le nombres d'actions du script 1, ceci prouve que le script 1 s'est déroulé correctement dans la carte. Le serveur peut alors effacer ce script dans la base de données.
On va maintenant décrire en relation avec la figure 2, en reprenant le même exemple, ce qui se passe lorsque se produit une coupure ou une perte du message de demande d'actions (message 2). Dans ce cas de figure, la commande script 1 n'est pas arrivée dans la carte. Le serveur va devoir se resynchroniser. Le serveur est informé de cette situation car selon cet exemple il n'a pas reçu d' acquittement . Dans les cas où le serveur n'attend pas d'acquittement, il est informé lorsqu'il reçoit la dernière valeur du compteur d'action de la carte c'est à dire par exemple lors de la prochaine transaction.
En effet, durant 1 'authentification de la carte par le serveur (vérification MAC1) , le serveur identifie que cette carte n'a pas reçu le script 1 (ou que le script 1 n'a pas été effectué correctement dans la carte) grâce à la valeur CA' du compteur d'actions qui est remontée au serveur et comparée à la valeur CA stockée dans le serveur.
Si CA' est inférieur à CA et non égal, cela veut dire que la dernière ou les dernières actions n'ont pas été effectuées correctement.
Dans ce cas le serveur remet à jour sa base de données DB, en effaçant la valeur CA pour mettre la valeur CA' . Le serveur est à nouveau synchronisé et peut relancer la ou les dernières actions non exécutées par la carte.
On va maintenant décrire en relation avec la figure 3, en reprenant toujours le même exemple, ce qui se passe lorsque se produit une coupure lors du message d' acquittement. Ce cas ne peut être envisagé que dans le cas où un message d'acquittement est prévu par l'application. Mais le même problème peut se produire lorsque la remontée du compteur d'actions est effectuée au moment d'une demande d'une nouvelle transaction, ou de l'envoi d'un message d'information.
Dans ce cas de figure, lors de la nouvelle demande de transaction, la valeur courante du compteur d'actions de la carte CA' = CA+n est remontée.
Le serveur compare cette valeur CA' à sa dernière valeur stockée, c'est-à-dire CA. Comme CA' = CA+n, le serveur sait que les n dernières actions ont bien été menées, il stocke la nouvelle valeur du compteur d'actions, c'est-à-dire CA+n pour être synchronisé avec la carte.

Claims

REVENDICATIONS
1. Procédé de contrôle de l'exécution d'une demande d'actions transmise par un serveur vers une carte via un terminal, ladite carte comportant un compteur d'actions, caractérisé en ce qu'il comporte les étapes suivantes : a) à l'émission par le serveur d'un message comportant une demande comprenant une ou plusieurs actions à mettre en oeuvre par la carte, le serveur stocke le nombre n d'action de la demande; b) à la réception du message, la carte exécute successivement la ou les actions de la demande en incrémentant son compteur d'actions entre chaque actions si l'action s'est bien exécutée et en refusant cette action et les actions successives si l'action ne s'est pas bien exécutée sans incrémenter son compteur. c) on compare la variation entre la valeur dans la carte et celle stockée dans le serveur et on détermine que les x dernières actions (commandes) ne sont pas exécutées si le résultat de la comparaison présente un écart de x.
2. Procédé selon la revendication 1, caractérisé en ce que pour comparer la variation entre la valeur dans la carte et celle stockée dans le serveur, la carte transmet au serveur la valeur courante de son compteur avant et après exécution de la commande d'actions.
3. Procédé selon la revendication 1, caractérisée en ce que pour comparer la variation entre la valeur dans la carte et celle stockée dans le serveur, la carte calcule la valeur de la variation de son compteur suite à l'exécution de la commande d'actions et la transmet au serveur.
4. Procédé selon l'une des revendications 2 ou 3 , caractérisé en ce que la carte transmet ledites valeurs sous forme sécurisée.
5. Procédé d'échange de messages selon la revendication 1, caractérisé en ce que la valeur du compteur d'actions de la carte est transmise en temps réel, c'est-à-dire pendant la transaction en cours.
6. Procédé d'échange de messages selon la revendication 5, caractérisé en ce que la valeur du compteur d'actions de la carte est transmise au serveur au moyen du message d'acquittement de la transaction en cours dans la carte.
7. Procédé d'échange de messages selon la revendication 1, caractérisé en ce que la valeur du compteur d'actions de la carte est transmise en temps différé.
8. Procédé d'échange de messages selon la revendication 7, caractérisé en ce que la valeur du compteur d'actions de la carte est transmise au serveur au moyen d'un message d'une nouvelle demande de transaction par la carte pour le serveur.
9. Procédé d'échange de messages selon la revendication 7, caractérisé en ce que la valeur du compteur d'actions de la carte est transmise au moyen d'un message d'information émis par la carte au serveur.
10. Carte pour mettre en oeuvre, le procédé selon l'une des revendications précédentes comportant un compteur et des moyens de gestion de ce compteur, caractérisée en ce que lesdits moyens de gestion sont aptes à incrémenter ledit compteur d'actions entre chaque action si l'action s'est bien exécutées et à ne pas l' incrémenter pour cette action ni pour les actions suivantes si cette action n'a pas été exécutée.
EP99932970A 1998-07-27 1999-07-26 Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal Withdrawn EP1101205A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9809575 1998-07-27
FR9809575A FR2781592B1 (fr) 1998-07-27 1998-07-27 Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal
PCT/FR1999/001826 WO2000007153A1 (fr) 1998-07-27 1999-07-26 Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal

Publications (1)

Publication Number Publication Date
EP1101205A1 true EP1101205A1 (fr) 2001-05-23

Family

ID=9529050

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99932970A Withdrawn EP1101205A1 (fr) 1998-07-27 1999-07-26 Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal

Country Status (8)

Country Link
EP (1) EP1101205A1 (fr)
JP (1) JP2002521772A (fr)
CN (1) CN1310832A (fr)
AU (1) AU4916899A (fr)
BR (1) BR9912419A (fr)
CA (1) CA2338447A1 (fr)
FR (1) FR2781592B1 (fr)
WO (1) WO2000007153A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
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
EP1814088B1 (fr) * 2006-01-30 2008-05-28 SkiData AG Système comprenant plusieurs dispositifs de puissance avec dispositifs de contrôle d'accès
CN103036654B (zh) * 2012-12-26 2015-10-28 无锡博欧节能科技有限公司 用于物联网的非实时单向链路通讯方法
US11234235B2 (en) 2019-04-30 2022-01-25 Bank Of America Corporation Resource distribution hub generation on a mobile device
US11196737B2 (en) 2019-04-30 2021-12-07 Bank Of America Corporation System for secondary authentication via contactless distribution of dynamic resources

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4654480A (en) * 1985-11-26 1987-03-31 Weiss Jeffrey A Method and apparatus for synchronizing encrypting and decrypting systems
DE3731736A1 (de) * 1986-09-27 1988-04-07 Toshiba Kawasaki Kk Verarbeitungssystem fuer tragbare elektronische vorrichtung
FR2716021B1 (fr) * 1994-02-09 1996-04-12 Gemplus Card Int Procédé et système de transaction par carte à puce.
DE19604876C1 (de) * 1996-02-10 1997-09-04 Deutsche Telekom Ag Verfahren zur Transaktionskontrolle elektronischer Geldbörsensysteme
EP0795844A1 (fr) * 1996-03-11 1997-09-17 Koninklijke KPN N.V. Méthode pour modifier avec sécurité des données d'une carte à puce
FR2748880A1 (fr) * 1996-05-17 1997-11-21 Gemplus Card Int Message ameliore et procede correspondant de synchronisation et de securisation d'un echange de messages ameliores dans un systeme de radiocommunication cellulaire
FR2757664B1 (fr) * 1996-12-24 1999-01-22 Bull Cp8 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede
FR2775375A1 (fr) * 1998-02-23 1999-08-27 Solaic Sa Chargement de programmes informatiques en blocs

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0007153A1 *

Also Published As

Publication number Publication date
FR2781592A1 (fr) 2000-01-28
WO2000007153A1 (fr) 2000-02-10
FR2781592B1 (fr) 2000-09-08
BR9912419A (pt) 2001-04-17
JP2002521772A (ja) 2002-07-16
CA2338447A1 (fr) 2000-02-10
AU4916899A (en) 2000-02-21
CN1310832A (zh) 2001-08-29

Similar Documents

Publication Publication Date Title
US9866989B2 (en) Payment application download to mobile phone and phone personalization
EP1571607B1 (fr) Systeme pour transactions comprenant des terminaux et des cartes à mémoire et carte à mémoire correspondante
FR2820853A1 (fr) Procede et systeme de telepaiement
EP0928464A1 (fr) Systeme de controle et de gestion de services
FR2757661A1 (fr) Procede de transfert securise de donnees par un reseau de communication
CN110930152A (zh) 一种基于区块链的数据处理方法及相关设备
EP4305573A1 (fr) Canal de paiement universel
WO2000007153A1 (fr) Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal
CA2999731A1 (fr) Procede de traitement de donnees par un terminal de paiement, terminal de paiement et programme correspondant
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
CN114818001A (zh) 一种数据处理方法、装置及介质
CA2324879C (fr) Procede pour modifier de maniere indivisible une pluralite d'emplacements de la memoire non volatile d'une carte a microcircuit, notamment une carte sans contact
US20240127226A1 (en) Systems and methods for using single or multi-chain deposit tokens
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
WO2022269179A1 (fr) Procede et dispositif de paiement par chaines de blocs
WO2018229089A1 (fr) Procédé de gestion d'identifiants de fidélité, procédé de traitement de données de fidélité, serveur, dispositif de transaction et programmes correspondants
CN117015786A (zh) 通用支付通道
WO2024081843A1 (fr) Systèmes et procédés d'utilisation de jetons de dépôt à chaîne unique ou multi-chaîne
WO2023099238A1 (fr) Procédé de réalisation d'une transaction, dispositifs et programmes correspondants.
EP0831434A1 (fr) Procédé de fermeture, notamment de mise en opposition, d'une pluralité de services, et serveur de fermeture, terminal d'acceptation et dispositifs portatifs associés
FR3025631A1 (fr) Selection securisee d'une application dans une carte a puce ou equivalent
FR2833093A1 (fr) Procede d'echange de blocs de donnees, procede d'echange et de traitement de blocs de donnees, objet portatif, et automate pour la mise en oeuvre de procede
EP1371036A2 (fr) Systeme et methode de renouvellement de donnees d'identification sur un dispositif de transaction portatif
FR2973140A1 (fr) Procede de generation et d'utilisation d'un titre dematerialise dans un dispositif portable et systeme de gestion de titres correspondant
WO2000056006A1 (fr) Procede de chargement securise de donnees entre des modules de securite

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20010227

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17Q First examination report despatched

Effective date: 20020111

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20031024