EP0910839B1 - Procede de stockage des unites de valeur dans une carte a puce de facon securisee et systeme de transaction monetaire avec de telles cartes - Google Patents

Procede de stockage des unites de valeur dans une carte a puce de facon securisee et systeme de transaction monetaire avec de telles cartes Download PDF

Info

Publication number
EP0910839B1
EP0910839B1 EP97926064A EP97926064A EP0910839B1 EP 0910839 B1 EP0910839 B1 EP 0910839B1 EP 97926064 A EP97926064 A EP 97926064A EP 97926064 A EP97926064 A EP 97926064A EP 0910839 B1 EP0910839 B1 EP 0910839B1
Authority
EP
European Patent Office
Prior art keywords
value
transaction
active area
area
card
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.)
Expired - Lifetime
Application number
EP97926064A
Other languages
German (de)
English (en)
Other versions
EP0910839A1 (fr
Inventor
Jean-Paul Kirik
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 SCA
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 SCA, Gemplus Card International SA, Gemplus SA filed Critical Gemplus SCA
Publication of EP0910839A1 publication Critical patent/EP0910839A1/fr
Application granted granted Critical
Publication of EP0910839B1 publication Critical patent/EP0910839B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

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/0866—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 by active credit-cards adapted therefor

Definitions

  • the present invention relates to methods which allow secure storage of value in a smart card and systems monetary transaction using these cards.
  • the invention applies more particularly to smart cards with an EEPROM type memory area not protected.
  • an EEPROM area not protected by a card is accessible by anyone with a simple card reader and read and write commands in memory.
  • This type of memory area does not allow to record sensitive data since no matter who can read and modify them.
  • the process also applies to smart cards with protected memory in order to raise the level of security.
  • Microprocessor cards are capable of contain and prohibit value units access. Only the operating system of the card can access and increase or decrease these units decrease the number. Secure and managed orders by the operating system therefore allow the management of the area containing the units of value, allowing the use of these value units as well that reloading them safely.
  • a memory card does not include a microprocessor, nor a fortiori of operating system but simply some commands allowing access to memory areas from the menu. However, some areas of the map may have features allowing the secure storage of value units. This is the case of some memory cards with a protected area by a secret code. Only a payment terminal having this secret code will be able to access the area containing the value units and may modify the number of units with write commands in memory. By definition, a fraudster does not know the secret code, so it is not able to recharge a card in value units. Other features linked to the card can allow secure storage of value units.
  • An application or recommendation note describes the mechanisms to be implemented at the card level and the terminal and defines how the terminal must use the card.
  • mapping in Anglo-Saxon terminology, this mapping being obtained by computer software taking note into account application.
  • the mechanism to be implemented consists to include in the calculation of this certificate data varying with each transaction.
  • transaction is meant a change in the number of value units of a menu.
  • a first mechanism in use is the use a certificate associated with the number of units. This certificate guarantees the integrity of the information to which it relates.
  • a terminal of a payment application can read the number of units of value present in a smart card. The certificate present in the map and associated with the number of units of stored value should be read and verified. This certificate is calculated using a mathematical function. It is calculates from the number of units in the card, data identifying the card and with a secret only known to the terminal. The terminal is therefore able to check or calculate such certificate. Another solution is to share the secret between cards and a central server. The application terminals will therefore have to connect to the server for any verification.
  • the number of units of value present in the card is considered valid.
  • This mechanism consists in including in the calculation of this certificate data varying with each transaction.
  • This data which can be a transaction counter ensures that we have a different certificate each time.
  • a map has a number of value units at a time t given.
  • time t + n i.e. after a certain number n of transactions, if this card contains again the same number of units of value as at time t, the associated certificate will still be different.
  • the counter value transaction is changed for each transaction.
  • This mechanism consists of duplicating information sensitive before a transaction takes place.
  • the duplicate data is stored in the card, in the unprotected EEPROM memory.
  • the unprotected EEPROM memory is therefore divided into two zones which we will call throughout active area and copy area. These two areas have a number of value units and the certificate corresponding.
  • the card If the card is torn off, if the data in modification courses in the active area are corrupted or altered, the data duplicated in the copy area will be retrieved and transferred to the active area. The card thus remains in a state stable. In the event of a card being torn off, the certificate present in the copy area must match the value of the card transaction counter. This allows to verify the authenticity of the certificate of the copy area and therefore the integrity of the number of units of value of the copy area. Therefore, the counter card transaction must be changed at the end of transaction.
  • the fraud consists in modifying the number of units present in the map and try different values of certificate.
  • a fraudster with a small number of units present in the card will therefore replace it with the maximum number of units a card can hold.
  • certificates are stored on a few bits.
  • the probability of finding the certificate by chance corresponding to the number of card units is high.
  • the card cannot be considered from a point of cryptographic view as a value unit holder secure. This fraud makes it possible to reload illegally a card in units of value.
  • the card In the case of a debit of value units in the card, and in case of tearing, the card is found with a possibly corrupt active area and a copy area containing a number of units of value. In addition, the copy area contains the number value units preceding the debit.
  • a fraudster can also read the content of his card before a transaction. It writes the content of the active area on a sheet of paper without even understand the meaning. Then he performs a transaction. In the event of a card being torn off, the transaction will not be completed. The counter value card transaction will not be changed. The fraudster can simply rewrite in the active area from his card the data written on his sheet paper. This fraud also makes it possible to recover units of value used.
  • the present invention overcomes these problems.
  • the subject of the present invention is a method of storing units of value in a smart card for carrying out transactions from a terminal according to claim 1.
  • the present invention also relates to a terminal as defined by claim 9.
  • the encryption operations are carried out by means of an encryption algorithm E K and a secret key K by the transaction terminal.
  • the process generally consists in calculating a certificate intended for the active area using a first function, and at calculate the certificate for the copy area, by using another function. So, in case the copy area certificate would be copied to the active area, it would no longer be valid.
  • the calculation of the certificate for the copy area is made from the number value units, but also the value of a transaction counter.
  • the initialization phase of a transaction we calculates the certificate from the number of units of value present in the active area and a value of transaction counter incremented at its next value, the data obtained is encrypted and recorded in the copy area, the transaction counter is then incremented to this new value so that at this time, the certificate of the active zone is not more in line with the counter value, only the backup data being correct. In this way, the terminal marks in the map the beginning of a transaction.
  • a characteristic of the invention distinguishes a card accidentally torn from a card fraudulently removed by checking the parity of the transaction counter in the initialization phase of the transaction.
  • a value of odd transaction counter indicates that the card has was torn off before the end of the transaction. So in the initialization phase of a new transaction, the terminal checks the parity of the transaction counter. A value odd transaction counter therefore tells him that the card has been ripped off. Terminal does not check the integrity of the active area and directly checks the integrity of the copy area. The fraudster no longer has way to test the random values he writes in the active area.
  • the parity of the value of the transaction counter used in the calculation of certificates is identical at the beginning and at the end of transaction, and the value of the transaction counter is incremented twice during the transaction, each increment being of a single unit.
  • the content of the active areas ZA is encrypted and ZC copy area of EEPROM not protected 103 shown in Figure 1.
  • This encryption is carried out by a terminal 100 of the application using the cards, using an encryption algorithm E K and a key from the terminal K.
  • This encryption key is known by the terminals accepting the cards of the application.
  • a terminal that knows how to encrypt will also be able to decrypt the content of the card using a decryption algorithm D K.
  • a fraudster knowing the principles of the invention detailed below and which attempts increasing the number of value units on a card does will be more able to set the maximum number of units valuable. He can only try to recharge randomly his card. So it will write data in the active area of his card. It exists a probability that by deciphering the active area a randomly modified card, a terminal get a number of credits and the certificate corresponding. But the number of value units obtained may be less than the number of value units previously contained in the card. The probability obtain a number of value units greater than number of value units initially present in the the lower the number of units initial value is great.
  • the size of the certificate To make fraud even more difficult consisting of randomly finding a certificate corresponding to a large number of value units, according to the method, the size of the certificate.
  • the number of units value saved in the card does not match to the number of value units for the application, but the number of value units that have been the subject of a transaction (zero for a full card units).
  • An application terminal reading the content of a card obtains the number of value units in subtracting from the maximum number of value units of the application the number of units of value contained in the map.
  • the calculation of the certificate of the active area is carried out from different way of calculating the zone certificate copy.
  • a terminal checking a card with the contents of the area copy has been transferred to the active area will able to detect fraud.
  • the certificate that the terminal will read in the active area will not match the calculation made in the case of the active area, and will correspond to the calculation made for the copy area.
  • the card transaction counter is also modified at the very beginning of the transaction.
  • the copy area is initialized with the number of value units contained in the active area and with a certificate taking into account the next value of the counter transaction. Then, the transaction counter is changed to this new value. At this precise moment, the content of the active area is no longer reusable, the transaction counter no longer corresponds to its certificate. However, the copy area is valid.
  • the transaction counter is changed again at the end of the transaction to prevent this transaction cannot be redone, as indicated above.
  • the process can also relate to the verification of the parity of the data varying with each transaction.
  • This data which can be a transaction counter is incremented twice during a transaction complete, one unit each time.
  • the parity of the value of the transaction counter is therefore identical start of transaction and end of transaction. If the first value of the transaction counter is even, the value of the transaction counter is even at the start and at the end of the transaction.
  • the parity of the transaction counter must be checked at the start of the transaction, the value of the counter transaction must be even. In case the transaction counter value is odd at the start the integrity of the zone information copy of the card should be directly verified. Yes the verification is successful, the terminal transfers the data from the copy area in the active area.
  • terminal 100 being a money terminal and the card 103, an electronic purse card.
  • the data structure of memory 103 is such that shown in Figure 2. This structure or organization is of course given as an example. Other organizations can be adapted.
  • this CTC counter is divided into 5 sub-counters of 8 bits (five counting stages) with an abacus type operation as described for example in patent FR 93 10477 published on March 10, 1995 under the No. 2,709,582.
  • the five sub-counters are referenced C1, C8, C64, C512, C4096.
  • the first four floors are of the type erasable, i.e. you can erase bits who are registered there and then re-write to the same locations.
  • the fifth stage C4096 is on the other hand writing only. Only 4 bits of this last stage are used for counting. Among the 4 bits remaining, 1 bit is used as fuse and the three other bits like fraud counter.
  • this type of counter will allow to count 10239 transactions [7 + 7x8 + 7x8 2 + 7x8 3 + 4x8 4] / 2.
  • This area cannot be deleted and is used to CER certification registration allowing card authentication.
  • the certificate authentication is saved after the circuit configuration for the end user and is checked by the terminal each time the menu.
  • the active area contains according to a characteristic of the invention an encrypted datum of the Bal balance and of the corresponding certificate Cert.
  • Balance information of value units corresponds to coding on a first constant number of bits, and the information representative of the certificate is coded on a second constant number of bits.
  • the calculation of the certificate ensures data integrity of the electronic purse.
  • F A and F B being different functions held by the terminal.
  • This sequence avoids any loss information in the event of the card being torn off or power cut.
  • the method includes an initialization phase of the transaction and a phase corresponding to the transaction itself.
  • the initialization phase includes a verification the fraud zone corresponding to steps 50, 51, 52 detailed below.
  • This initialization phase also includes a verification of the parity of the data varying at each corresponding transaction in the diagram in Figure 3 in steps 400, 401, 203A, 204A, 205A, 207A.
  • the value of the transaction counter is pair at the start and end of the transaction.
  • Parity of transaction counter is checked at the start of transaction steps 400, 401, the value of transaction counter must be even.
  • the terminal transfers data from the copy area to the area active step 205A. Then the terminal marks the start of a transaction in the card by incrementing the CTC counter. After that the terminal returns to step 401.
  • step 206 namely incrementing the card fraud counter and card ejection.
  • the terminal After checking the parity, the terminal reads the content of the active area of the card (electronic purse PM) 150, which includes the data ⁇ Bal1, Cert1 A >. Ball is the number of value units initially stored in the card, and Cert1A is the certificate initially stored in the card.
  • the terminal checks the integrity of this data, step 200. For this, it decrypts this following data steps 20 to 22 detailed in Figure 4. If the certificate he calculated corresponds to the certificate of the card, then the verification was successful. The transaction continues 201, 202, 300.
  • the terminal updates the balance in the card and calculates a new data item 301 and 302.
  • the update is carried out according to steps 30 to 35 illustrated in figure 6.
  • the terminal reads the copy area which contains ⁇ Bal1, Cert1 B > 203.
  • the terminal checks the integrity of the backup 204 by decrypting this data in operating steps 20, 21 and 22 of FIG. 4 on these data.
  • the terminal restores this data from backup in the active area that contained nothing or erroneous data 205.
  • the terminal In case the data contained in the area are not intact, then the terminal enters a bit in fraud area 206.
  • one or more attempts to fraud can be accepted before refusing definitely the card.
  • the card When the fraud area is full, the card is swallowed.
  • the fraud zone is checked during a step prior to the transaction at the very beginning of initialization of transaction 50, 51, 52.
  • FIG. 5 illustrates the preliminary steps 200, 201 and 202 to the implementation of a transaction.
  • step 200 the terminal performs the operations developed in Figure 4.
  • the terminal operates the decryption of the content of the active (or copy) area.
  • step 200 In the case of step 200,
  • the terminal then calculates the Cert 1B certificate corresponding to the Ball balance in this area (21). He performs the verification of integrity (22).
  • the terminal calculates the certificate Cert 1A for the active area (23), it encrypts the data Ball, Cert 1A (24), it saves in the active zone of the card the encrypted value (25).
  • the terminal increments the CTC counter (26) and erases the content of the copy area (27).
  • Figure 6 illustrates the steps for updating the balance (301) during a transaction and the end of transaction (302).
  • the old Ball balance is modified by a value x (in more or less depending on the transaction made) for give the new Bal2 balance such as:
  • Bal2 Bal1 ⁇ x (30), x being the value of the transaction.
  • the terminal registers in the active area of the map this new encrypted data. (33)
  • the card copy area contains the old data, i.e. ⁇ Bal1, Cert1 B >.
  • the terminal increments the card's CTC transaction counter by toasting a second bit to validate the transaction.
  • the terminal clears the copy area (35) and controls the ejection of the card.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

La présente invention se rapporte aux procédés qui permettent de stocker de façon sécurisée des unités de valeur dans une carte à puce et aux systèmes de transaction monétaire utilisant ces cartes. L'invention s'applique plus particulièrement à des cartes à puces comportant une zone mémoire de type EEPROM non protégée.
En effet, une zone EEPROM non protégée d'une carte est accessible par tout individu disposant d'un simple lecteur de carte et de commandes de lecture et écriture en mémoire. Ce type de zone mémoire ne permet pas d'enregistrer des données sensibles puisque n'importe qui peut les lire et les modifier.
Le procédé s'applique également à des cartes à puce à mémoire protégée afin d'en élever le niveau de sécurité.
Les cartes à microprocesseurs sont capables de contenir des unités de valeur et d'en interdire l'accès. Seul le système d'exploitation de la carte peut accéder à ces unités et en augmenter ou en diminuer le nombre. Des commandes sécurisées et gérées par le système d'exploitation permettent donc la gestion de la zone contenant les unités de valeur, permettant l'utilisation de ces unités de valeur ainsi que leur rechargement en toute sécurité.
Une carte à mémoire ne comporte ni microprocesseur, ni à fortiori de système d'exploitation mais simplement quelques commandes permettant l'accès aux zones mémoire de la carte. Néanmoins, certaines zones de la carte peuvent avoir des caractéristiques permettant le stockage sécurisé d'unités de valeur. C'est le cas de certaines cartes à mémoire possédant une zone protégée par un code secret. Seul un terminal de paiement possédant ce code secret pourra accéder à la zone contenant les unités de valeur et pourra modifier le nombre d'unités avec des commandes d'écriture en mémoire. Par définition, un fraudeur ne connaít pas le code secret, il n'est donc pas capable de recharger une carte en unités de valeur. D'autres caractéristiques liées à la carte peuvent permettre un stockage sécurisé d'unités de valeur.
Dans l'état de la technique connu, les mécanismes de base existant sont l'utilisation d'un certificat d'intégrité, d'un compteur de transaction ainsi que d'une zone de copie. Ces mécanismes vont être détaillés dans la suite. Dans le cas des cartes à microprocesseur, ces mécanismes de base peuvent être inclus dans les systèmes d'exploitation.
Ces mécanismes peuvent également être appliqués sous forme de note d'application ou de recommandation d'application aux cartes à microprocesseur et à certaines cartes à mémoire de type synchrone.
Une note d'application ou de recommandation décrit les mécanismes à mettre en oeuvre au niveau de la carte et du terminal et définit la façon dont le terminal doit utiliser la carte.
On entend plus précisément par note d'application, une définition particulière de l'état de la mémoire dans la carte et dans le terminal, appelée "mapping" en terminologie anglo-saxonne, ce mapping étant obtenu par un logiciel informatique tenant compte de la note d'application. Le mécanisme à mettre en oeuvre consiste à inclure dans le calcul de ce certificat une donnée variant à chaque transaction. On entend par transaction une modification du nombre d'unités de valeur d'une carte.
Mécanisme 1 :
Un premier mécanisme en oeuvre est l'utilisation d'un certificat associé au nombre d'unités. Ce certificat garantit l'intégrité des informations auxquelles il se rapporte. Un terminal d'une application de paiement peut lire le nombre d'unités de valeur présentes dans une carte à puce. Le certificat présent dans la carte et associé au nombre d'unités de valeur stockées doit être lu et vérifié. Ce certificat est calculé à l'aide d'une fonction mathématique. Il se calcule à partir du nombre d'unités présentes dans la carte, de données identifiant la carte et avec un secret seulement connu par le terminal. Le terminal est donc capable de vérifier ou de calculer un tel certificat. Une autre solution consiste à partager le secret entre les cartes et un serveur central. Les terminaux de l'application devront donc se connecter au serveur pour toute vérification.
Si le certificat est correct, le nombre d'unités de valeur présentes dans la carte est considéré comme valide.
Mécanisme 2 :
Ce mécanisme consiste à inclure dans le calcul de ce certificat une donnée variant à chaque transaction. L'introduction de cette donnée qui peut être un compteur de transaction permet de garantir que l'on a un certificat différent à chaque fois. Une carte possède un nombre d'unités de valeur à un instant t donné. A l'instant t+n, c'est-à-dire après un certain nombre n de transactions, si cette carte contient de nouveau le même nombre d'unités de valeur qu'à l'instant t, le certificat associé sera malgré tout différent. Il faut bien sûr que la valeur du compteur de transaction soit modifiée à chaque transaction.
Mécanisme 3 :
Ce mécanisme consiste à dupliquer les informations sensibles avant le déroulement d'une transaction. Les données dupliquées sont stockées dans la carte, dans la mémoire EEPROM non protégée.
La mémoire EEPROM non protégée est donc divisée en deux zones que nous appellerons dans toute la suite zone active et zone de copie. Ces deux zones comportent un nombre d'unités de valeur et le certificat correspondant.
En cas d'arrachement de la carte, si les données en cours de modification dans la zone active sont corrompues ou altérées, les données dupliquées dans la zone de copie seront récupérées et transférées dans la zone active. La carte demeure ainsi dans un état stable. En cas d'arrachement de carte, le certificat présent dans la zone de copie doit correspondre à la valeur du compteur de transaction de la carte. Ceci permet de vérifier l'authenticité du certificat de la zone de copie et donc l'intégrité du nombre d'unités de valeur de la zone de copie. C'est pourquoi, le compteur de transaction de la carte doit être modifié en fin de transaction.
Toutes ces sécurités n'empêchent pas malheureusement certaines fraudes que l'on va expliciter dans ce qui suit :
1er cas de fraude :
Dans le cas d'unités de valeur présentes dans une zone mémoire non protégée par la puce de la carte, la fraude consiste à modifier le nombre d'unités présentes dans la carte et à essayer différentes valeurs de certificat.
Un fraudeur ayant un petit nombre d'unités présentes dans la carte va donc le remplacer par le nombre maximum d'unités que peut contenir sa carte. Dans ce cas précis, aucun mécanisme n'empêche de modifier le contenu de la zone mémoire de la carte, la carte ne possédant pas de zone protégée. Puis le fraudeur va inscrire dans la carte, en lieu et place du précédent certificat une valeur aléatoire. Étant donné les faibles capacités mémoire des composants utilisés, les certificats sont enregistrés sur quelques bits.
La probabilité de trouver par hasard le certificat correspondant au nombre d'unités de la carte est élevée. La carte ne peut être considérée d'un point de vue cryptographique comme un porte-unités de valeur sécurisée. Cette fraude permet de recharger illégalement une carte en unités de valeur.
2ième cas de fraude :
Dans le cas d'un débit d'unités de valeur dans la carte, et en cas d'arrachement, la carte se retrouve avec une zone active éventuellement corrompue et une zone de copie contenant un certain nombre d'unités de valeur. De plus, la zone de copie contient le nombre d'unités de valeur précédant le débit.
Puisqu'il s'agit d'une interruption de transaction, le compteur de transaction peut ne pas avoir encore été modifié. La zone mémoire contenant les unités de valeur n'étant pas protégée contre les modifications, un fraudeur peut transférer le contenu de la zone de copie dans la zone active. Le contenu de la zone de copie est valide puisque son certificat correspond toujours à la valeur du compteur de transaction. Cette fraude permet de récupérer des unités de valeur utilisées.
3ième cas de fraude :
Un fraudeur peut également lire le contenu de sa carte avant une transaction. Il inscrit le contenu de la zone active sur une feuille de papier sans même en comprendre la signification. Puis il exécute une transaction. En cas d'arrachement de carte, la transaction ne sera pas achevée. La valeur du compteur de transaction de la carte ne sera pas modifiée. Le fraudeur pourra simplement réécrire dans la zone active de sa carte les données inscrites sur sa feuille de papier. Cette fraude permet également de récupérer des unités de valeur utilisées.
La présente invention permet de remédier à ces problèmes.
La présente invention a pour objet un procédé de stockage d'unités de valeur dans une carte à puce pour la réalisation de transactions à partir d'un terminal selon la revendication 1.
La présente invention concerne aussi un terminal tel que défini par la revendication 9.
Selon une autre caractéristique les opérations de chiffrement sont réalisées au moyen d'un algorithme de chiffrement EK et d'une clé secrète K par le terminal de transaction.
Selon une autre caractéristique, le procédé consiste globalement à calculer un certificat destiné à la zone active en utilisant une première fonction, et à calculer le certificat destiné à la zone de copie, en utilisant une autre fonction. Ainsi, dans le cas où le certificat de la zone de copie serait copié dans la zone active, il ne serait plus valide.
Plus précisément, le procédé consiste à :
  • calculer à partir d'une première fonction mathématique FA, un premier certificat CA stocké dans la zone active et garantissant l'intégrité des points de cette zone;
  • calculer à partir d'une seconde fonction mathématique FB, un second certificat CB stocké dans la zone de copie et garantissant l'intégrité de cette zone.
Afin d'éviter que le contenu de la zone active ne puisse être utilisé en cas d'arrachement, selon une autre caractéristique de l'invention, le calcul du certificat destiné à la zone de copie est réalisé à partir du nombre d'unités de valeur, mais aussi de la valeur d'un compteur de transaction. Dans la phase d'initialisation d'une transaction, on calcule le certificat à partir du nombre d'unités de valeur présent dans la zone active et d'une valeur du compteur de transaction incrémentée à sa prochaine valeur, la donnée obtenue est chiffrée et enregistrée en zone de copie, le compteur de transaction est ensuite incrémenté à cette nouvelle valeur de sorte qu'à cet instant, le certificat de la zone active n'est plus en accord avec la valeur du compteur, seule la donnée de sauvegarde étant correcte. De cette façon, le terminal marque dans la carte le début d'une transaction.
Selon une caractéristique de l'invention on distingue une carte arrachée accidentellement d'une carte arrachée frauduleusement en vérifiant la parité du compteur de transaction dans la phase d'initialisation de la transaction. En effet, si par convention on choisit qu'une valeur du compteur de transaction impaire indique que la carte a été arrachée avant la fin de la transaction. Alors dans la phase d'initialisation d'une nouvelle transaction, le terminal vérifie la parité du compteur de transaction. Une valeur impaire du compteur de transaction lui indique donc que la carte a été arrachée. Le terminal ne vérifie pas l'intégrité de la zone active et vérifie directement l'intégrité de la zone de copie. Le fraudeur n'a plus de moyen de tester les valeurs aléatoires qu'il écrit dans la zone active.
Ainsi selon le procédé la parité de la valeur du compteur de transaction utilisé dans le calcul des certificats est identique en début et en fin de transaction, et la valeur du compteur de transaction est incrémentée deux fois durant la transaction, chaque incrémentation étant d'une seule unité.
Dans la phase d'initialisation d'une transaction, on lit la valeur du compteur de transaction de la carte. Si la valeur lue est paire, on lit les informations de la zone active (ZA), on vérifie l'intégrité des informations de la zone active, l'intégrité des informations de la zone active est vérifiée, on procède au stockage d'unités de valeur dans la carte à puce.
Dans la phase d'initialisation d'une transaction, on lit la valeur du compteur de transaction de la carte. Si la valeur lue est impaire, on lit les informations de la zone de copie (ZC), on vérifie l'intégrité des informations de la zone de copie, l'intégrité des informations de la zone de copie est vérifiée, on calcule un certificat à partir du nombre d'unités de valeur présent dans la zone de copie (ZC) et de la valeur du compteur de transaction incrémentée à sa prochaine valeur paire, la donnée obtenue est chiffrée et enregistrée en zone active (ZA), le compteur est ensuite incrémenté à cette nouvelle valeur de sorte qu'à cet instant, le certificat de la zone de copie (ZC) n'est plus en accord avec la valeur du compteur, seule la donnée de la zone active étant correcte.
D'autres avantages et caractéristiques de l'invention apparaítront à la lecture de la description suivante qui est faite à titre illustratif et non limitatif et en regard des dessins sur lesquels :
  • la figure 1, représente le schéma d'un système de transaction,
  • la figure 2, représente une structure des données de la mémoire 103 de carte à puce selon un exemple de réalisation,
  • la figure 3, représente les étapes relatives à une transaction mises en oeuvre par un terminal,
  • la figure 4, représente les étapes mises en oeuvre lors de la vérification de l'intégrité des données de la zone active ou de la zone de copie,
  • la figure 5, représente les étapes préalables à une transaction décrite en figure 3,
  • la figure 6, représente les étapes de mise à jour du solde lors d'une transaction et la fin de la transaction.
Ainsi, selon une première caractéristique de l'invention, on chiffre le contenu des zone active ZA et zone de copie ZC de la mémoire EEPROM non protégée 103 représentée sur la figure 1.
Ce chiffrement est réalisé par un terminal 100 de l'application utilisant les cartes, à l'aide d'un algorithme de chiffrement EK et d'une clef du terminal K. Cette clef de chiffrement est connue par les terminaux acceptant les cartes de l'application. Un terminal sachant chiffrer saura également déchiffrer le contenu de la carte à partir d'un algorithme de déchiffrement DK.
Un fraudeur connaissant les principes de l'invention détaillés dans la suite et qui tente d'augmenter le nombre d'unités de valeur d'une carte ne sera plus capable de fixer le nombre maximum d'unités de valeur. Il ne pourra qu'essayer de recharger aléatoirement sa carte. Il inscrira donc des données aléatoires dans la zone active de sa carte. Il existe une probabilité pour qu'en déchiffrant la zone active d'une carte modifiée aléatoirement, un terminal obtienne un nombre d'unités de valeur et le certificat correspondant. Mais le nombre d'unités de valeur obtenu peut être inférieur au nombre d'unités de valeur contenu précédemment dans la carte. La probabilité d'obtenir un nombre d'unités de valeur supérieur au nombre d'unités de valeur initialement présent dans la carte est d'autant plus faible que ce nombre d'unités de valeur initial est grand.
Afin de rendre encore plus difficile la fraude consistant à trouver aléatoirement un certificat correspondant à un nombre important d'unités de valeur, on prévoit selon le procédé d'augmenter la taille du certificat. Plus la taille du certificat est grande, plus il est difficile de trouver la bonne valeur. Or, comme les tailles mémoires sont relativement faibles dans une carte à puce, il n'est pas possible d'avoir à la fois un grand nombre d'unités et un grand certificat.
Pour résoudre ce problème on propose selon une caractéristique de l'invention, que le nombre d'unités de valeur enregistré dans la carte ne corresponde pas au nombre d'unités de valeur pour l'application, mais au nombre d'unités de valeur qui ont fait l'objet d'une transaction (zéro pour une carte pleine d'unités).
Ce nombre est donc nul tant qu'aucune transaction n'a eu lieu. Ainsi, un nombre nul d'unités de valeur dans la carte correspond à la valeur maximale d'unités de valeur pour l'application. Et inversement, la valeur maximale d'unités de valeur dans la carte correspond à une valeur nulle d'unités de valeur pour l'application.
Un terminal de l'application lisant le contenu d'une carte obtient le nombre d'unités de valeur en soustrayant au nombre d'unités de valeur maximal de l'application le nombre d'unités de valeur contenu dans la carte.
De cette façon, lorsque la carte contiendra un zéro, cela correspondra à la valeur maximale. Un zéro dans la carte se code sur un seul bit. Ainsi, les bits restants de la zone de codage du nombre d'unités de valeur peuvent être utilisés pour contenir le certificat.
Plus le nombre d'unités de valeur est grand, plus la valeur codée dans la carte est faible, donc plus la taille mémoire allouée au certificat est importante.
Il est nécessaire d'indiquer aux terminaux la taille mémoire allouée au certificat pour chaque carte. Pour cela, cette taille est indiquée dans la zone mémoire EEPROM non protégée de la carte, avec le nombre d'unités de valeur et le certificat. Cette indication est présente dans la zone active et dans la zone de copie.
Selon une autre caractéristique de l'invention le calcul du certificat de la zone active est réalisé de manière différente du calcul du certificat de la zone de copie.
Il n'est alors plus possible de transférer le contenu de la zone active dans la zone de copie. Un terminal vérifiant une carte dont le contenu de la zone de copie a été transféré dans la zone active sera capable de constater la fraude. Le certificat que le terminal lira dans la zone active ne correspondra pas au calcul opéré dans le cas de la zone active, et correspondra au calcul opéré pour la zone de copie.
Selon une autre caractéristique de l'invention, pour que le contenu de la zone active d'une carte ne puisse être réutilisé en cas d'arrachement de carte, le compteur de transaction de la carte est également modifié en tout début de transaction. La zone de copie est initialisée avec le nombre d'unités de valeur contenu dans la zone active et avec un certificat tenant compte de la prochaine valeur du compteur de transaction. Puis, le compteur de transaction est modifié à cette nouvelle valeur. A cet instant précis, le contenu de la zone active n'est plus réutilisable, le compteur de transaction ne correspond plus à son certificat. Par contre, la zone de copie est valide.
Le compteur de transaction est de nouveau modifié en fin de transaction pour éviter que cette transaction ne puisse être refaite, comme indiqué précédemment.
Le procédé peut concerner également la vérification de la parité de la donnée variant à chaque transaction. Cette donnée qui peut être un compteur de transaction est incrémentée deux fois durant une transaction complète, d'une unité à chaque fois. La parité de la valeur du compteur de transaction est donc identique en début de transaction et en fin de transaction. Si la première valeur du compteur de transaction est paire, la valeur du compteur de transaction est paire en début et en fin de transaction.
La parité du compteur de transaction doit être vérifiée en début de transaction, la valeur du compteur de transaction doit être paire. Dans le cas où la valeur du compteur de transaction est impaire en début de transaction, l'intégrité des informations de la zone de copie de la carte doit être directement vérifiée. Si la vérification est réussie, le terminal transfère les données de la zone de copie dans la zone active.
L'invention va maintenant être décrite dans le cas de l'application à un système de transaction monétaire, le terminal 100 étant un terminal monétaire et la carte 103, une carte porte-monnaie électronique.
Selon un exemple préféré de réalisation, la structure de données de la mémoire 103 est telle que représentée sur la figure 2. Cette structure ou organisation est bien sûr donnée à titre d'exemple. D'autres organisations peuvent être adaptées.
La mémoire comporte des données d'identification comprenant :
  • une valeur d'identification du circuit (circuit silicium) dans la zone Id circuit,
  • un code client dans la zone de référence émetteur de carte (organisme bancaire),
  • une donnée d'identification de l'application dans la zone Id Card (donnée par l'émetteur),
  • un numéro de série CSN de la carte (donné par exemple par le fabricant).
La mémoire comporte une zone de compteurs comportant les champs suivants :
  • un compteur de fraude incrémenté à chaque vérification d'un certificat s'avérant mauvais.
Ce compteur est formé de 3 bits selon la réalisation pratique qui a été faite.
  • un compteur de transaction CTC.
Dans un exemple de réalisation, ce compteur CTC est divisé en 5 sous-compteurs de 8 bits (cinq étages de comptage) avec un fonctionnement type boulier tel que décrit par exemple dans le brevet FR 93 10477 publié le 10 mars 1995 sous le N° 2 709 582. Les cinq sous-compteurs sont référencés C1, C8, C64, C512, C4096. Les cellules mémoire de l'étage de comptage C1 ont un poids de 1, ... et celles de l'étage C4096 ont un poids de 4096 = 84).
Les quatre premiers étages sont du type effaçables, c'est-à-dire que l'on peut effacer des bits qui y sont inscrits et ensuite ré-écrire aux mêmes emplacements. Le cinquième étage C4096 est par contre à écriture uniquement. Seuls 4 bits de ce dernier étage sont utilisés pour le comptage. Parmi les 4 bits restants, 1 bit est utilisé comme fusible et les trois autres bits comme compteur de fraude.
Deux bits sont grillés par transaction.
Ainsi, ce type de compteur va permettre de compter 10239 transactions [7+7x8+7x82+7x83+4x84]/2.
La mémoire comporte en outre
  • une zone certificat.
Cette zone ne peut être effacée et sert à l'enregistrement de certification CER permettant l'authentification de la carte. Le certificat d'authentification est enregistré après la configuration du circuit pour l'utilisateur final et est vérifié par le terminal à chaque utilisation de la carte.
Il est calculé par exemple à partir d'une donnée d'identification ID, d'une fonction à sens unique fOP et d'une clé secrète suivant la formule : CER = fOP (ID, K)
ID est par exemple le contenu des zones d'identification de carte, identification de circuit ou de référence d'émetteur.
  • une zone utilisateur.
Il s'agit de la zone active porte-monnaie électronique et de la zone de copie pour les sauvegardes.
La zone active contient selon une caractéristique de l'invention une donnée chiffrée du solde Bal et du certificat correspondant Cert. L'information du solde d'unités de valeur correspond à un codage sur un premier nombre constant de bits, et l'information représentative du certificat est codée sur un second nombre constant de bits.
La donnée chiffrée correspondant à une des deux zones du porte-unités peut s'écrire de la façon suivante : <Bal, Cert> = EK (Bal, Cert)
  • Bal étant le nombre d'unités de valeur et
  • Cert le certificat correspondant
  • K étant la clé secrète du terminal
  • <donnée> la valeur chiffrée
  • (donnée) la valeur non chiffrée
  • EK l'algorithme de chiffrement.
    • Le calcul du certificat permet d'assurer l'intégrité des données du porte-monnaie électronique.
    Les données suivantes sont utilisées dans le calcul :
    • la valeur du solde, ce qui rend le certificat unique pour un solde donné,
    • des données permanentes de la carte, à savoir les données d'identification (carte et émetteur),
    • le compteur de transaction CTC. A chaque transaction deux bits sont grillés dans ce compteur CTC et le compteur peut uniquement être incrémenté ou uniquement décrémenté. Un bit est grillé au début d'une transaction, un deuxième bit est grillé à la fin de la transaction.
    Selon une des caractéristiques de l'invention, les certificats correspondant à un solde sont calculés par le terminal de la façon suivante : Cert A = FA (Bal, CSN, CTC)    pour la zone active du porte-monnaie
    et
       Cert B = FB (Bal, CSN, CTC)
       pour la zone de copie du porte-monnaie.
    FA et FB étant des fonctions différentes détenues par le terminal. On pourra par exemple prendre comme fonction un algorithme DES utilisant une clé secrète k détenue par le terminal.
    Lors d'une transaction, l'enregistrement des informations relatives au solde et au certificat dans la zone de copie et dans la zone active se fait suivant le déroulement suivant :
    • enregistrement du solde et de son certificat (présents dans la zone active) dans la zone de copie,
    • effacement de la zone active,
    • écriture du nouveau solde dans la zone active et de son certificat,
    • effacement de la zone de copie (effacement de la donnée de sauvegarde).
    Cet enchaínement permet d'éviter toute perte d'information en cas d'arrachement de la carte ou de coupure de courant.
    Les différentes étapes mises en oeuvre par le terminal lors d'une transaction sont représentées par les blocs fonctionnels de la figure 3:
    Le procédé comporte une phase d'initialisation de la transaction et une phase correspondant à la transaction elle-même.
    La phase d'initialisation comporte une vérification de la zone de fraude correspondant aux étapes 50, 51, 52 détaillée dans la suite.
    Cette phase d'initialisation comporte en outre une vérification de la parité de la donnée variant à chaque transaction correspondant sur le schéma de la figure 3 aux étapes 400, 401, 203A, 204A, 205A, 207A.
    Si la première valeur du compteur de transaction est paire, la valeur du compteur de transaction est paire en début et en fin de transaction.
    La parité du compteur de transaction est vérifiée en début de transaction étapes 400, 401, la valeur du compteur de transaction doit être paire.
    Dans le cas où la valeur du compteur de transaction est impaire en début de transaction, l'intégrité des informations de la zone de copie de la carte doit être directement vérifiée 204 A en opérant les étapes 20, 21 et 22 de la figure 4.
    Si la vérification est réussie, le terminal transfère les données de la zone de copie dans la zone active étape 205A. Puis le terminal marque le début d'une transaction dans la carte en incrémentant le compteur CTC. A la suite de cela le terminal repasse à l'étape 401.
    Si la vérification de l'intégrité est négative, le terminal exécute l'étape 206 à savoir incrémentation du compteur de fraude de la carte et éjection de la carte.
    Après la vérification de la parité le terminal lit le contenu de la zone active de la carte (porte-monnaie électronique PM) 150, laquelle comporte la donnée <Bal1, Cert1A>. Ball est le nombre d'unités de valeur initialement stockées dans la carte, et Cert1A est le certificat initialement stocké dans la carte.
    Le terminal vérifie l'intégrité de ces données, étape 200. Pour cela, il déchiffre cette donnée suivant les étapes 20 à 22 détaillées à la figure 4. Si le certificat qu'il a calculé correspond au certificat de la carte, alors la vérification a réussi. La transaction se poursuit 201, 202, 300.
    Le terminal met à jour le solde dans la carte et calcule une nouvelle donnée chiffrée 301 et 302. La mise à jour est réalisée suivant les étapes 30 à 35 illustrées sur la figure 6.
    Dans le cas où l'intégrité des données de la zone active n'est pas vérifiée, le terminal lit la zone de copie qui contient <Bal1, Cert1B> 203.
    Le terminal vérifie l'intégrité des données de sauvegarde 204 par déchiffrement de ces données en opérant les étapes 20, 21 et 22 de la figure 4 sur ces données.
    Si le certificat calculé est égal au certificat de cette zone Certl'B==Cert1b, alors les données sont intègres, le terminal restaure cette donnée de sauvegarde dans la zone active qui ne contenait rien ou une donnée erronée 205.
    Dans le cas où les données contenues dans la zone de copie ne sont pas intègres, alors le terminal inscrit un bit dans la zone de fraude 206.
    Selon l'application, une ou plusieurs tentatives de fraude peuvent être acceptées avant de refuser définitivement la carte.
    Lorsque la zone de fraude est pleine, la carte est avalée. Le contrôle de la zone de fraude se fait lors d'une étape préalable à la transaction au tout début de l'initialisation de la transaction 50, 51, 52.
    La figure 5, illustre les étapes préalables 200, 201 et 202 à la mise en oeuvre d'une transaction. On pourra préférentiellement utiliser des fonctions différentes FA et FB pour le calcul des certificats.
    A l'étape 200 (ou 204 ou 204A), le terminal effectue les opérations développées sur la figure 4.
    Le terminal opère le déchiffrement du contenu de la zone active (ou de copie). (20)
    Dans le cas de l'étape 200,
    Il calcule ensuite le certificat Cert1A correspondant au solde (Bal1) de cette zone. (21)
    Il opère la vérification d'intégrité. (22)
    A l'étape 201 :
    • le terminal calcule le certificat (Cert1B) pour la zone de sauvegarde; (23)
         il chiffre la donnée (Bal1, Cert1B); (24)
         il sauvegarde dans la zone de copie de la carte la valeur chiffrée. (25)
    A l'étape 202 :
    • le terminal incrémente le compteur CTC; (26)
    • il efface le contenu de la zone active. (27)
    Dans le cas des étapes 204 ou 204A, le terminal calcule ensuite le certificat Cert 1B correspondant au solde Ball de cette zone (21). Il opère la vérification d'intégrité (22). Le terminal calcule le certificat Cert 1A pour la zone active (23), il chiffre la donnée Ball, Cert 1A (24), il sauvegarde dans la zone active de la carte la valeur chiffrée (25). Puis le terminal incrémente le compteur CTC (26) et efface le contenu de la zone de copie (27).
    La figure 6, illustre les étapes de mise à jour du solde (301) lors d'une transaction et la fin de la transaction (302).
    L'ancien solde Ball est modifié d'une valeur x (en plus ou en moins selon la transaction opérée) pour donner le nouveau solde Bal2 tel que :
    Bal2 = Bal1 ± x (30), x étant la valeur de la transaction.
    Le terminal calcule un nouveau certificat tenant compte de ce nouveau solde, et de la nouvelle valeur du compteur de transaction CTC+1 : Cert2A = FA(Bal2, Card Id, CTC+1)
    Le terminal effectue le chiffrement de ces nouvelles données : <Bal2, Cert2A> = EK(Bal2, Cert2A)
    Le terminal enregistre dans la zone active de la carte cette nouvelle donnée chiffrée. (33)
    La zone de copie de la carte contient l'ancienne donnée, c'est-à-dire <Bal1, Cert1B>. Le terminal incrémente le compteur de transaction CTC de la carte en grillant un second bit pour valider la transaction. (34)
    Le terminal efface la zone de copie (35) et commande l'éjection de la carte.

    Claims (9)

    1. Procédé de stockage d'unités de valeur dans une carte à puce pour la réalisation de transactions à partir d'un terminal, la carte comprenant une mémoire non volatile de type EEPROM (103), comportant une zone active (ZA) susceptible de contenir des informations relatives au nombre d'unités de valeur de la carte pour une application donnée et à un certificat destiné à la zone active et calculé par le terminal à partir de ce nombre, la mémoire comportant également une zone de copie (ZC) destinée à contenir des informations de sauvegarde de la zone active,
      caractérisé en ce qu'il comporte les étapes suivantes :
      l'enregistrement dans la zone de copie (ZC) dans la phase d'initialisation d'une transaction de l'information relative au nombre d'unités de valeur de la carte pour une application donnée présent dans la zone active et d'une information relative à un certificat destiné à la zone de copie calculé à partir de ce nombre,
      les informations relatives au nombre d'unités de valeur présent dans la zone active et au certificat destiné à la zone de copie étant chiffrées et enregistrées chiffrées dans la zone de copie (ZC) ;
      l'enregistrement dans la zone active (ZA) lors de la transaction d'informations relatives à un nouveau nombre d'unités de valeur de la carte pour une application donnée et à un nouveau certificat destiné à la zone active calculé par le terminal à partir de ce nouveau nombre d'unités de valeur, les informations relatives au nouveau nombre d'unités de valeur et au nouveau certificat destiné à la zone active étant chiffrées et enregistrées chiffrées dans la zone active.
    2. Procédé de stockage selon la revendication 1, caractérisé en ce que les opérations de chiffrement sont réalisées au moyen d'un algorithme de chiffrement Ek et d'une clé secrète K par le terminal de transaction.
    3. Procédé de stockage selon l'une quelconque des revendications précédentes caractérisé en ce que le certificat destiné à la zone active (CertA) est calculé en utilisant une première fonction (FA), et en ce que le certificat destiné à la zone de copie (CertB) est calculé en utilisant une autre fonction (FB).
    4. Procédé de stockage selon la revendication 3 caractérisé en ce que :
      dans la phase d'initialisation de la transaction, les informations relatives au nombre d'unités de valeur de la carte pour une application donnée présent dans la zone active et relatives au certificat (CertB) destiné à la zone de copie calculé à partir de ce nombre sont chiffrées selon une première opération de chiffrement,
      lors de la transaction, les informations relatives au nouveau nombre d'unités de valeur de la carte pour une application donnée et au nouveau certificat (CertA) destiné à la zone active calculé par le terminal à partir de ce nouveau nombre d'unités de valeur sont chiffrées selon une seconde opération de chiffrement.
    5. Procédé selon l'une des revendications précédentes caractérisé en ce que dans la phase d'initialisation de la transaction :
      on calcule le certificat destiné à la zone de copie à partir du nombre d'unités de valeur présent dans la zone active et d'une valeur d'un compteur de transaction incrémentée à sa prochaine valeur,
      le compteur de transaction est ensuite incrémenté à cette nouvelle valeur de sorte qu'après enregistrement des informations dans la zone de copie, le certificat de la zone active n'est plus en accord avec la valeur du compteur, seules les informations de sauvegarde étant correctes.
    6. Procédé selon la revendication précédente selon lequel la valeur du compteur de transaction est utilisée dans le calcul des certificats, la parité de la valeur du compteur de transaction étant identique dans la phase d'initialisation et en fin de transaction et la valeur du compteur de transaction étant incrémentée deux fois durant la transaction, chaque incrémentation étant d'une seule unité.
    7. Procédé selon la revendication précédente caractérisé en ce que, dans la phase d'initialisation de la transaction, on lit la valeur du compteur de transaction de la carte, si la valeur lue est paire, on lit les informations de la zone active (ZA), on vérifie l'intégrité des informations de la zone active, l'intégrité des informations de la zone active est vérifiée, on procède au stockage d'unités de valeur dans la carte à puce.
    8. Procédé selon la revendication 6 caractérisé en ce que, dans la phase d'initialisation d'une transaction, on lit la valeur du compteur de transaction de la carte, si la valeur lue est impaire, on lit les informations de la zone de copie (ZC), on vérifie l'intégrité des informations de la zone de copie, l'intégrité des informations de copie est vérifiée, on calcule un certificat à partir du nombre d'unités de valeur présent dans la zone de copie (ZC) et de la valeur du compteur de transaction incrémentée à sa prochaine valeur paire, la donnée obtenue est chiffrée et enregistrée en zone active (ZA), le compteur est ensuite incrémenté à cette nouvelle valeur de sorte qu'à cet instant, le certificat de la zone de copie (ZC) n'est plus en accord avec la valeur du compteur, seule la donnée de la zone active étant correcte.
    9. Terminal de transaction utilisant des cartes à puce comprenant une mémoire non volatile de type EEPROM (103) comportant une zone active (ZA) susceptible de contenir des informations relatives au nombre d'unités de valeur de la carte pour une application donnée et à un certificat destiné à la zone active et calculé par le terminal à partir de ce nombre, la mémoire comportant également une zone de copie (ZC) destinée à contenir des informations de sauvegarde de la zone active,
      caractérisé en ce que le terminal comporte un moyen de chiffrement pour chiffrer dans la phase d'initialisation d'une transaction l'information relative au nombre d'unités de valeur de la carte pour une application donnée présent dans la zone active et une information relative à un certificat destiné à la zone de copie calculé à partir de ce nombre, et pour chiffrer lors de la transaction des informations relatives à un nouveau nombre d'unités de valeur de la carte pour une application donnée et à un nouveau certificat destiné à la zone active calculé par le terminal à partir de ce nouveau nombre d'unités de valeur, et un moyen pour enregistrer dans la zone de copie les données chiffrées dans la phase d'initialisation et pour enregistrer dans la zone active les informations chiffrées lors de la transaction.
    EP97926064A 1996-05-31 1997-05-30 Procede de stockage des unites de valeur dans une carte a puce de facon securisee et systeme de transaction monetaire avec de telles cartes Expired - Lifetime EP0910839B1 (fr)

    Applications Claiming Priority (3)

    Application Number Priority Date Filing Date Title
    FR9606705 1996-05-31
    FR9606705A FR2749413B1 (fr) 1996-05-31 1996-05-31 Procede de stockage des unites de valeur dans une carte a puce de facon securisee et systeme de transaction monetaire avec de telles cartes
    PCT/FR1997/000947 WO1997045815A1 (fr) 1996-05-31 1997-05-30 Procede de stockage des unites de valeur dans une carte a puce de facon securisee et systeme de transaction monetaire avec de telles cartes

    Publications (2)

    Publication Number Publication Date
    EP0910839A1 EP0910839A1 (fr) 1999-04-28
    EP0910839B1 true EP0910839B1 (fr) 2003-10-22

    Family

    ID=9492581

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP97926064A Expired - Lifetime EP0910839B1 (fr) 1996-05-31 1997-05-30 Procede de stockage des unites de valeur dans une carte a puce de facon securisee et systeme de transaction monetaire avec de telles cartes

    Country Status (5)

    Country Link
    EP (1) EP0910839B1 (fr)
    DE (1) DE69725723T2 (fr)
    ES (1) ES2212102T3 (fr)
    FR (1) FR2749413B1 (fr)
    WO (1) WO1997045815A1 (fr)

    Families Citing this family (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    RU2231825C2 (ru) * 1999-11-29 2004-06-27 Инфинеон Текнолоджиз Аг Способ и устройство для эксплуатации многоступенчатого счетчика в одном направлении счета
    FR2873471B1 (fr) * 2004-07-26 2006-10-13 Ascom Sa Systeme a carte a memoire sans contact a mot de passe

    Family Cites Families (4)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    FR2618002B1 (fr) * 1987-07-10 1991-07-05 Schlumberger Ind Sa Procede et systeme d'authentification de cartes a memoire electronique
    FR2653248B1 (fr) * 1989-10-13 1991-12-20 Gemolus Card International Systeme de paiement ou de transfert d'information par carte a memoire electronique porte monnaie.
    FR2689662B1 (fr) * 1992-04-01 1994-05-20 Gemplus Card International Procede de protection d'une carte a puce contre la perte d'information.
    FR2704081B1 (fr) * 1993-04-16 1995-05-19 France Telecom Procédé de mise à jour d'une carte à mémoire et carte à mémoire pour la mise en Óoeuvre de ce procédé.

    Also Published As

    Publication number Publication date
    FR2749413A1 (fr) 1997-12-05
    ES2212102T3 (es) 2004-07-16
    WO1997045815A1 (fr) 1997-12-04
    DE69725723T2 (de) 2004-07-22
    DE69725723D1 (de) 2003-11-27
    EP0910839A1 (fr) 1999-04-28
    FR2749413B1 (fr) 1998-07-10

    Similar Documents

    Publication Publication Date Title
    EP0475837B1 (fr) Procédé de gestion d&#39;un programme d&#39;application chargé dans un support à microcircuit
    EP0671712B1 (fr) Procédé et dispositif pour authentifier un support de données destiné à permettre une transaction ou l&#39;accès à un service ou à un lieu, et support correspondant
    EP0423035B1 (fr) Système de paiement ou de transfert d&#39;informations par carte à mémoire électronique porte-monnaie
    EP0409701B1 (fr) Carte à microcircuit câblé et procédé de transaction entre une carte à microcircuit câblé correspondante et un terminal
    EP0414314B1 (fr) Procédé de génération de nombre unique pour carte à micro-circuit et application à la coopération de la carte avec un système hÔte
    EP0998731B1 (fr) Procede et systeme de paiement par cheque electronique
    EP0744063B1 (fr) Procede de transaction par carte a puce
    EP0990204B1 (fr) Carte a puce comprenant des moyens pour gerer une memoire virtuelle, procede et protocole de communication associes
    CA2046289C (fr) Procede de generation d&#39;un nombre aleatoire dans un systeme de traitement de donnees, et systeme mettant en oeuvre un tel procede
    FR2704081A1 (fr) Procédé de mise à jour d&#39;une carte à mémoire et carte à mémoire pour la mise en Óoeuvre de ce procédé.
    FR2765985A1 (fr) Procede de gestion d&#39;un terminal securise
    FR2757661A1 (fr) Procede de transfert securise de donnees par un reseau de communication
    FR2697929A1 (fr) Protocole sécurisé d&#39;échange de données entre un dispositif de transfert et un objet portatif.
    EP0910839B1 (fr) Procede de stockage des unites de valeur dans une carte a puce de facon securisee et systeme de transaction monetaire avec de telles cartes
    FR2730076A1 (fr) Procede d&#39;authentification par un serveur du porteur d&#39;un objet portatif a microprocesseur, serveur et objet portatif correspondants
    EP0979495B1 (fr) Procede de certification d&#39;un cumul dans un lecteur
    EP3032450B1 (fr) Procédé de contrôle d&#39;une authenticité d&#39;un terminal de paiement et terminal ainsi sécurisé
    EP3564914A1 (fr) Procédé et système pour effectuer un échange de données sécurisé
    FR2856815A1 (fr) Procede d&#39;authentification de donnees contenues dans un objet a memoire
    FR2788620A1 (fr) Supports et systemes d&#39;echange de donnees securises notamment pour paiements et telepaiements
    FR2814575A1 (fr) Procedes et systemes d&#39;identification, de chiffrement et de paiement electronique notamment a l&#39;aide de supports homologues detenant un secret partage s&#39;identifiant mutuellement
    FR2892875A1 (fr) Procede de securisation des paiements par decoupage des montants
    FR2834842A1 (fr) Procede d&#39;authentification d&#39;un objet portable informatise par un terminal, systeme mettant en oeuvre le procede, terminal utilise dans le procede et objet portable utilise dans le procede
    WO2008003886A1 (fr) Module electronique pour le stockage de donnees
    EP3093813A1 (fr) Système de paiement, terminal de paiement de ce système, et procédé de paiement associé

    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: 19990104

    AK Designated contracting states

    Kind code of ref document: A1

    Designated state(s): BE DE DK ES FI FR GB IT NL PT SE

    RAP1 Party data changed (applicant data changed or rights of an application transferred)

    Owner name: GEMPLUS

    17Q First examination report despatched

    Effective date: 20010425

    GRAH Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOS IGRA

    GRAS Grant fee paid

    Free format text: ORIGINAL CODE: EPIDOSNIGR3

    GRAA (expected) grant

    Free format text: ORIGINAL CODE: 0009210

    AK Designated contracting states

    Kind code of ref document: B1

    Designated state(s): BE DE DK ES FI FR GB IT NL PT SE

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: NL

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20031022

    Ref country code: FI

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20031022

    REG Reference to a national code

    Ref country code: GB

    Ref legal event code: FG4D

    Free format text: NOT ENGLISH

    REF Corresponds to:

    Ref document number: 69725723

    Country of ref document: DE

    Date of ref document: 20031127

    Kind code of ref document: P

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: SE

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20040122

    Ref country code: DK

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20040122

    GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)

    Effective date: 20040204

    NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: BE

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20040531

    REG Reference to a national code

    Ref country code: ES

    Ref legal event code: FG2A

    Ref document number: 2212102

    Country of ref document: ES

    Kind code of ref document: T3

    PLBE No opposition filed within time limit

    Free format text: ORIGINAL CODE: 0009261

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

    Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

    26N No opposition filed

    Effective date: 20040723

    BERE Be: lapsed

    Owner name: *GEMPLUS

    Effective date: 20040531

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: PT

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20040322

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: ES

    Payment date: 20090506

    Year of fee payment: 13

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: IT

    Payment date: 20090424

    Year of fee payment: 13

    Ref country code: FR

    Payment date: 20090527

    Year of fee payment: 13

    Ref country code: DE

    Payment date: 20090603

    Year of fee payment: 13

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: GB

    Payment date: 20090427

    Year of fee payment: 13

    GBPC Gb: european patent ceased through non-payment of renewal fee

    Effective date: 20100530

    REG Reference to a national code

    Ref country code: FR

    Ref legal event code: ST

    Effective date: 20110131

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: IT

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20100530

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: DE

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20101201

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: FR

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20100531

    REG Reference to a national code

    Ref country code: ES

    Ref legal event code: FD2A

    Effective date: 20110715

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: ES

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20110705

    Ref country code: GB

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20100530

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: ES

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20100531