WO2000030049A1 - Procede de controle d'utilisation d'une carte a puce - Google Patents

Procede de controle d'utilisation d'une carte a puce Download PDF

Info

Publication number
WO2000030049A1
WO2000030049A1 PCT/FR1999/002782 FR9902782W WO0030049A1 WO 2000030049 A1 WO2000030049 A1 WO 2000030049A1 FR 9902782 W FR9902782 W FR 9902782W WO 0030049 A1 WO0030049 A1 WO 0030049A1
Authority
WO
WIPO (PCT)
Prior art keywords
card
counter
key
transaction
authentication
Prior art date
Application number
PCT/FR1999/002782
Other languages
English (en)
Inventor
Jean-Louis Valadier
Original Assignee
Gemplus
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 filed Critical Gemplus
Priority to EP99972341A priority Critical patent/EP1131800A1/fr
Priority to AU11672/00A priority patent/AU1167200A/en
Publication of WO2000030049A1 publication Critical patent/WO2000030049A1/fr

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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • 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/1025—Identification of user by a PIN code
    • G07F7/1083—Counting of PIN attempts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2207/00—Indexing scheme relating to methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F2207/72—Indexing scheme relating to groups G06F7/72 - G06F7/729
    • G06F2207/7219—Countermeasures against side channel or fault attacks

Definitions

  • the present invention relates to a method for controlling a smart card. It applies more particularly to cards implementing cryptography algorithms using keys or key pairs in authentication sessions, during transactions between the card and a terminal.
  • Terminal means both the terminal into which the card is inserted, such as a payment terminal at a merchant, as well as a server of a bank to which this payment terminal can be connected during a so-called transaction. by direct link, according to a transaction mode called "online" in Anglo-Saxon literature. This is particularly the case for bank cards (debit / credit card), for transactions involving an amount that exceeds a certain threshold and in which the terminal automatically connects to the server for additional checks before accepting the transaction .
  • terminal means any external system to which the card is connected during a transaction.
  • the invention applies in particular, but not exclusively, to smart cards of the electronic purse type, which are disposable or rechargeable means of payment.
  • cryptographic algorithms are used, which use keys.
  • authentication session is meant all of the operations aimed at having the card and the terminal calculate a signature (or a certificate) corresponding to the application of a cryptography algorithm on a piece of data which may be imposed by either or a mixture of card and terminal data, and comparing the two signatures. If this comparison is made by the card, it is authentication by the card, which receives the signature calculated by the terminal. If it is an authentication by the terminal, it is the opposite.
  • DPA attack for differential power analysis
  • DPA attack is based on the fact that we have current consumption signatures from which, if we know at least the data applied as input or the data obtained as output, we is able, by making assumptions on the keys, to find the value or a part of the value of a key which was used in the cryptographic calculation considered.
  • the card calculates a signature SI and / or a signature S2, by applying the cryptography algorithm to a datum, generally imposed by the card, and with the session key SKX.
  • the terminal calculates corresponding signatures, and depending on the type of transaction, either the terminal is authenticated by the card, or the card is authenticated by the terminal. There is therefore transmission of data and associated signatures during authentication sessions.
  • Knowing a session key allows you to replay a transaction, using a fake card (a clone) or a simulator.
  • the object of the invention is to prevent this type of fraud.
  • An object of the invention is thus to prevent the collection of current consumption measurements.
  • a solution to the technical problem of the invention consists in using a control counter in the card, to count (or count) these failures, and to prohibit the use of the card when a certain number of failures are recorded.
  • the invention therefore relates to a control method according to claim 1.
  • the control counter is decremented by one. It is only incremented with this unit if the authentication is successful.
  • the check counter is incremented by one and is only then decremented by this unit if the authentication session is successful.
  • a check counter is used per key and / or per pair of encryption keys used in the card.
  • the control counter according to the invention can count down from, or count up to a blocking value N representative of the number of authorized failures.
  • This blocking value N depends on the type of transactions in which the key or the associated key pair is used. This value corresponds to a authorized number of failed or aborted transactions. In particular, it takes into account the level of security to be associated with the transaction, ie the risk incurred by fraud on this key or this pair of keys.
  • a transaction for updating card parameters these parameters possibly being the expiration date, the very values of the keys, a maximum amount for a transaction ..., a fairly low value of N is expected, since a very high degree of security must be associated with such a transaction and few usage errors can occur for this type of transaction.
  • purchase operations or cancellation of purchases for which a certain number of incidents during the "normal" use of the card may occur, due in particular to errors of use by the holder , a higher value is expected.
  • FIG. 2 is a general diagram of the resources of a card of this type, comprising control counters according to the invention.
  • FIGS. 3 to 5 are flowcharts of typical transactions in an electronic purse application implementing the method of controlling use according to the invention.
  • the general principle of the invention is to use at least one control counter which will be decremented, or incremented by one at the start of the transaction between a terminal and a card, and which will not increment, or decrement only after an authentication session by the card, if this session is successful.
  • the counter is systematically decremented at the start of each transaction and re-incremented under conditions.
  • the counter is initialized to a blocking value N, representative of the number of authorized failures which is in particular a function of the application. If many transactions are started without allowing successful authentication by the card, either the transaction has been interrupted (case of pull out), or that the data sent to the card to allow authentication by the card are false (case of '' a simulator used in place of a real terminal), the counter which is decremented with each new transaction, but which is not re-incremented in all cases of authentication authentication failures by the card, ends up reaching zero. The use of the card is then blocked.
  • FIG. 2 schematically represents the resources of a smart card of the electronic purse type, to which the control method of the invention can be applied.
  • this memory mainly contains a microprocessor ⁇ p, and memory resources including a ROM read-only memory, containing in practice the program code, a dynamic memory RAM as working memory and a non-volatile memory of EEPROM type for example, which contains in practice sensitive parameters. (in the security sense) of the card, including counters.
  • this memory notably contains three secret keys denoted KDP, KDL and KDU, three associated session counters, denoted NTP, NTL and NTU, and three associated control counters according to the invention, denoted C KDp , C, C KD ( ,.
  • This memory contains other parameters. Some can be updated by an external system, by an update transaction, according to a secure procedure. Recall that in an electronic purse card, three types of transactions are possible and each type of transaction corresponds to an associated secret key. We thus have the following types of transaction: - Purchase or purchase cancellation with the associated secret key, noted KDP;
  • a purchase transaction includes a first initialization phase which is normally limited to sending an order by the terminal to the card, to specify the type of transaction. This command is usually worded as follows, in Anglo-Saxon literature: INIT FOR PURCHASE.
  • the microprocessor then connects to the address of the program code corresponding to this type of transaction.
  • the card compares the two signatures. If they are comparable, the authentication is successful, the control counter according to the invention is then incremented by the value u. Otherwise, it is unchanged. The transaction can then continue.
  • control counter will make it possible to block any use of the card for a purchase type transaction.
  • FIG. 4 shows a flowchart of operation of the card for the transaction of type cancellation of purchase, which therefore uses the same secret key KDP.
  • the initialization phase initiated by a terminal initialization command includes, in addition to the decrementation of a unit u of the counter of control
  • the card transmits to the terminal, this data and the signature SI, to allow the terminal to authenticate the card.
  • This authentication by the terminal is not the subject of any response from the terminal.
  • the card goes to the processing phase in which it in turn authenticates the terminal, as before.
  • the signature S2 is generally calculated on zero.
  • the card therefore calculates the corresponding signature S2 with the session key KDP. It receives the signature S2 calculated by the terminal and performs the comparison of the two signatures. If they are comparable, the authentication session is successful.
  • the control counter according to the invention is re-incremented by the unit u. Otherwise, the check counter is unchanged. The transaction continues.
  • the card performs two cryptographic calculations up to and including that of the authentication session with the card, the calculation of the signature SI and the calculation of the signature S2.
  • This decrementation can be done at once, by a unit u representative of this number of calculations performed for this transaction.
  • the value taken by u for this transaction could be initialized in the initialization phase, following the command of the "INIT FOR" type.
  • This decrementation in several times, by decrementing the counter by one unit before each calculation, in the example, before the calculation of the signature SI and before the calculation of the signature S2. In this case, provision will be made to test the limit value on the counter after each decrementation.
  • a time counter associated with the control counter is then provided, initialized to zero at the start of the transaction and which, for example, is incremented at each time the control counter is decremented.
  • D KDp a time counter associated with the control counter
  • FIG. 5 represents an operating flow diagram for another type of transaction, that of updating. It is relatively similar to the previous ones, but the authentication by the card is done here on the signature noted SI.
  • the check counter is decremented at the start of the transaction. It is only re-incremented, if it can be, after a card authentication session.
  • the flowcharts in Figures 3 to 5 show only some of the operations performed during the transaction, for the explanation of the method according to the invention. In practice, other operations are carried out.
  • the current session key or the previous session key is used to calculate the signatures. After calculating the session key, the session counter must be incremented ... All these aspects are specific to the application itself and have no interest in the implementation of the control process according to the invention.
  • the different control counters must be initialized to a blocking value N that is well chosen. This value must take into account the type of associated transactions, the corresponding security level to be implemented but also possible errors in progress "normal" use by the card holder: it is not a question of blocking the use of the card when the holder has not sought to fraud.
  • N a blocking value
  • a variant of the control method according to the invention consists in incrementing the counter at each session and in decrementing it only under condition (authentication by the card successful).
  • the counter is initialized to zero, and the limit value, to which the content of the counter is compared, is equal to the blocking value N. All that has been described previously applies to this variant of the invention.
  • the control method according to the invention applies to any type of smart card as soon as it performs an authentication session.
  • This authentication session can be based on a secret key cryptography algorithm, for example of the DES type, as explained in the case of the electronic wallet card, but also algorithms of other types, such as the type algorithms.
  • RSA using a couple of keys (private key, public key) for example.
  • the term “smart card” means both well-known format cards and portable media.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un procédé de contrôle dans une carte à puce CPE, pour des transactions entre cette carte et un terminal comprenant au moins une session d'authentification par la carte consiste à décrémenter, ou incrémenter, d'une unité un compteur de contrôle CKDP au début de la transaction et à ne le ré-incrémenter, ou le décrémenter, que si l'authentification par la carte est réussie. Lorsque le compteur atteint une valeur limite, l'utilisation de la carte est bloquée. De cette manière on empêche une utilisation frauduleuse de la carte visant à découvrir des clés de cryptage KDP, SKP contenues dans la carte.

Description

PROCEDE DE CONTROLE D'UTILISATION D'UNE CARTE A
PUCE
La présente invention concerne un procédé de contrôle d'une carte à puce. Elle s'applique plus particulièrement aux cartes mettant en oeuvre des algorithmes de cryptographie utilisant des clés ou des couples de clés dans des sessions d' authentification, lors de transactions entre la carte et un terminal. On entend par terminal, aussi bien le terminal dans lequel la carte est introduite, comme par exemple un terminal de paiement chez un commerçant, qu'un serveur d'une banque auquel ce terminal de paiement peut-être relié lors d'une transaction dite par liaison directe, selon un mode de transaction dit "online" dans la littérature anglo-saxonne. C'est notamment le cas pour les cartes bancaires (carte de débit/crédit) , pour des transactions portant sur un montant qui dépasse un certain seuil et dans lesquelles le terminal se connecte automatiquement au serveur pour des vérifications supplémentaires avant d'accepter la transaction.
Dans la suite, on entend par terminal tout système extérieur auquel la carte est connectée lors d'une transaction.
L'invention s'applique notamment, mais pas exclusivement aux cartes à puce de type porte-monnaie électronique, qui sont des moyens de paiement jetables ou rechargeables. Pour prévenir toute fraude liée à l'utilisation de cartes à puce, des algorithmes cryptographiques sont utilisés, qui utilisent des clés. En pratique, pour un certain nombre de transactions une ou plusieurs sessions d' authentification par la carte ou par le terminal sont prévues , de manière à assurer une sécurité maximum. On entend par session d' authentification l'ensemble des opérations visant à faire calculer par la carte et par le terminal une signature (ou un certificat) correspondant à l'application d'un algorithme de cryptographie sur une donnée qui peut-être imposée par l'un ou l'autre ou un mélange de données de la carte et du terminal, et à la comparaison des deux signatures. Si cette comparaison est effectuée par la carte, c'est une authentification par la carte, qui reçoit la signature calculée par le terminal. Si c'est une authentification par le terminal, c'est le contraire.
Cependant, un nouveau type de fraude est apparue qui consiste à déduire la valeur des clés secrètes à partir d'analyses statistiques basées sur des mesures de consommation en courant de la carte, lors des périodes de calcul cryptographique. Cette méthode d'attaque, appelée attaque DPA pour differential power analysis repose sur le fait que l'on a des signatures de consommation en courant à partir desquelles, si on connaît au moins la donnée appliquée en entrée ou la donnée obtenue en sortie, on est capable, en faisant des hypothèses sur les clés, de retrouver la valeur ou une partie de la valeur d'une clé qui a été utilisée dans le calcul cryptographique considéré.
Pour mettre en oeuvre cette fraude, il faut donc pouvoir lancer un calcul cryptographique avec la même clé un certain nombre de fois, par exemple, 300 fois. Pour que ce soit utilisable, il faut connaître ou pouvoir imposer ou pouvoir fixer un paramètre du calcul cryptographique . Si on prend l'exemple des cartes à puce de type porte-monnaie électronique mettant en oeuvre un algorithme de cryptographie à clé secrète, les transactions entre une carte de ce type et un terminal se déroulent globalement selon le schéma suivant, représenté sur la figure 1 : - dans une phase d'initialisation, la carte calcule une clé de session SKX, à partir d'une clé secrète KDX contenue dans la carte concernée et d'un compteur de sessions NTX de la carte qui est incrémenté de façon irréversible pendant la transaction. Puis selon le type de transactions, la carte calcule une signature SI et/ou une signature S2 , en appliquant l'algorithme de cryptographie à une donnée, en général imposée par la carte, et avec la clé de session SKX. De son côté, le terminal calcule des signatures correspondantes, et selon le type de transaction, soit le terminal est authentifié par la carte, soit la carte est authentifiée par le terminal. Il y a donc transmission de données et de signatures associées lors de sessions d' authentification.
Prenons le cas d'une tentative de fraude basée sur une transaction de type chargement ( load dans la littérature anglo-saxonne ) , qui sert normalement à créditer la carte de type porte-monnaie électronique avec une certaine somme.
Si on lance un certain nombre de fois (300 fois par exemple) une transaction de ce type et si on retire la carte du terminal juste après la phase d'initialisation, le compteur de sessions NTX de la carte ne sera pas incrémenté. Si on fait 300 transactions de ce type en retirant la carte du terminal pour faire avorter la transaction, la clé de session SKX sera la même pour ces 300 transactions. On pourra donc collecter 300 courbes de mesure de consommation en courant correspondant au calcul de 300 signatures sur des données qui pourront être identiques ou variables selon les transactions, et avec la même clé.
L'analyse statistique dans le cas où les données sur lesquelles le calcul cryptographique est appliqué, sont variables, permet d'obtenir la clé de session.
Selon le type de cartes, selon les transactions, on peut en pratique soit déduire les clés secrètes réelles contenues dans la carte, ou les clés de session.
La connaissance d'une clé secrète réelle permet d'une part de fabriquer des fausses cartes avec cette clé ; ces cartes seront vues comme bonnes par un terminal. Cette connaissance permet d'autre part de réaliser des transactions de type annulation d'achat, pour une carte de type porte-monnaie, permettant de re- créditer la carte d'un montant précédemment débité.
La connaissance d'une clé de session permet quant à elle de rejouer une transaction, en utilisant une fausse carte (un clone) ou un simulateur.
L'invention a pour objet d'empêcher ce type de fraude.
Or cette fraude nécessite deux type d'opérations distinctes :
- une opération de collection de mesures de consommation en courant, pour laquelle il faut utiliser la carte pour faire les mesures à des moments propices, avec des transactions réelles avec un terminal, mais qui sont avortées par retrait de la carte (pull out) ou des transactions avec un simulateur du terminal, transactions qui vont échouées par défaut d' authentification du terminal par la carte (mauvaises signatures) ; et
- une opération d'analyse statistique utilisant des moyens de simulation (ordinateurs) , pour retrouver les données recherchées, c'est à dire les clés. Pour mener à bien l'analyse statistique, il faut effectuer un grand nombre de mesures : 50, 300, 5000. Cela veut dire que dans la carte, il va y avoir un grand nombre d'échecs de sessions d' authentifications par la carte, échecs dûs à des transactions avortées, par retrait de la carte du terminal (pull-out) ou échouées, par fourniture par le terminal de mauvaises signatures mauvaises signatures.
Un objet de l'invention est ainsi d'empêcher la collection de mesures de consommation en courant.
Or on a vu que dans le cas où l'on cherche à faire cette collection, on va avoir un grand nombre d'échecs de sessions d'authentification par la carte.
Une solution apportée au problème technique de l'invention consiste à utiliser dans la carte un compteur de contrôle, pour décompter (ou compter) ces échecs, et interdire l'utilisation de la carte quand un certain nombre d'échecs sont comptabilisés.
L'invention concerne donc un procédé de contrôle selon la revendication 1.
Selon l'invention, lorsqu'une transaction entre la carte et un terminal est lancée, qui utilise au moins une session d' authentification par la carte, le compteur de contrôle est décrémenté d'une unité. Il n'est rê-incrémenté de cette unité que si 1 ' authentification est réussie. Ou bien, le compteur de contrôle est incrémenté d'une unité et n'est ensuite décrémenté de cette unité que si la session d' authentification est réussie.
De préférence, on utilise un compteur de contrôle par clé et/ou par couple de clés de cryptage utilisés dans la carte.
Le compteur de contrôle selon l'invention peut décompter depuis, ou compter jusqu'à une valeur de blocage N représentative du nombre d'échecs autorisés.
Cette valeur de blocage N dépend du type de transactions dans lesquelles la clé ou le couple de clés associé est utilisé. Cette valeur correspond à un nombre de fois autorisé de transactions échouées ou avortées. Elle tient notamment compte du niveau de sécurité à associer à la transaction, c'est à dire du risque encouru par une fraude sur cette clé ou ce couple de clés.
Par exemple, s 'agissant pour une carte de type porte-monnaie électronique, d'une transaction de mise à jour de paramètres de la carte, ces paramètres pouvant être la date d'expiration, les valeurs même des clés, un montant maximum pour une transaction ... , on prévoit une valeur N assez faible, car un très fort degré de sécurité doit être associé à une telle transaction et peu d'erreurs d'utilisation peuvent survenir pour ce type de transaction. S'agissant d'opérations d'achats ou d'annulation d'achats, pour lesquels un certain nombre d'incidents lors de l'utilisation "normale" de la carte peuvent intervenir, dûs notamment à des erreurs d'utilisation par le titulaire, on prévoit une valeur plus grande. Pour une clé donnée ou un couple de clés donné, lorsque le compteur a atteint sa valeur limite, zéro par décrémentation ou N par incrémentation, l'utilisation de la clé ou du couple de clés est bloquée : aucune transaction utilisant cette clé ou ce couple de clés ne peut plus être effectuée. De préférence, on prévoit que ce blocage est irréversible. On peut cependant prévoir de ré-initialisiser le compteur dans le cas ou un blocage résulte indiscutablement d'une erreur non intentionnelle de l'utilisateur. On peut aussi prévoir de pouvoir modifier la valeur de blocage N, si elle se révèle en pratique trop faible ou trop grande. Ces réinitialisation ou modification ne pourront se faire que selon une procédure très sécurisée par un tiers habilité (la banque). En outre, dans certaines transactions, plusieurs calculs cryptographiques sont exécutés, avec la même clé ou le même couple de clés jusqu'à et y compris celui de la session d' authentif ication par la carte. On prévoit alors de décrémenter, ou incrémenter, le compteur ou bien d'une nouvelle unité avant chaque calcul, ou bien d'une unité représentative du nombre de calculs effectués. Si la session d' authentification est réussie, le compteur est rê-incrémenté, ou décrémenté, soit de la somme des unités décrémentées, ou incrémentées , au moyen d'un compteur de pointage ou de l'unité représentative, selon le mode d' implémentation choisi du procédé de contrôle selon l'invention.
D'autres caractéristiques et avantages de l'invention sont décrits dans la description suivante, faite à titre indicatif et nullement limitatif et en référence aux dessins annexés dans lesquels :
- la figure 1 déjà décrite représente un schéma type de calculs cryptographiques effectués lors d'une transaction entre une carte de type porte-monnaie électronique utilisant un algorithme de cryptographie à clé secrète et un terminal;
- la figure 2 est un schéma général des ressources d'une carte de ce type, comprenant des compteurs de contrôle selon l'invention; et
- les figures 3 à 5 sont des organigrammes de transactions typiques dans une application porte- monnaie électronique mettant en oeuvre le procédé de contrôle d'utilisation selon l'invention. Le principe général de l'invention est d'utiliser au moins un compteur de contrôle que l'on va décrémenter, ou incrémenter d'une unité en début de transaction entre un terminal et une carte, et que l'on ne va ré-incrémenter , ou décrémenter qu'après une session d' authentification par la carte, si cette session est réussie. Dans la suite on ne retient que le cas ou le compteur est décrémenté systématiquement au début de chaque transaction et ré-incrémenté sous conditions. On se transposera aisément dans le cas inverse ou le compteur est incrémenté systématiquement, en début de transaction, et décrémenté sous conditions.
Le compteur est initialisé à une valeur de blocage N, représentative du nombre d'échecs autorisés qui est notamment fonction de l'application. Si beaucoup de transactions sont démarrées sans permettre une authentification réussie par la carte, soit que la transaction ait été interrompue (cas de pull out) , soit que les données envoyées à la carte pour permettre 1 'authentification par la carte soient fausses (cas d'un simulateur utilisé à la place d'un vrai terminal) , le compteur qui est décrémenté à chaque nouvelle transaction, mais qui n'est pas ré-incrémenté dans tous les cas d'échecs d' authentification par la carte, finit par atteindre zéro. L'utilisation de la carte est alors bloquée.
Un exemple de mise en oeuvre de l'invention va maintenant être expliqué pour une carte de type porte- monnaie électronique mettant en oeuvre un algorithme de cryptographie dont la clé de cryptage est une clé secrète. L'invention ne se limite pas ni à ce type de carte, ni à ce type d'algorithme. Elle s'applique à toute carte effectuant pour au moins une transaction, une session d' authentification. La session d' authentification peut utiliser un algorithme à clé secrète comme l'algorithme DES, ou un algorithme de type RSA utilisant un couple de clés de cryptage (clé privée, clé publique). Certaines cartes implémentent même ces deux algorithmes pour utiliser l'un ou l'autre selon la transaction à effectuer. Le procédé de contrôle selon l'invention s'applique à toutes ces différentes cartes et applications. La figure 2 représente schématiquement les ressources d'une carte à puce de type porte-monnaie électronique, à laquelle on peut appliquer le procédé de contrôle de l'invention. Elle comprend principalement un microprocesseur μp, et des ressources mémoires dont une mémoire morte ROM, contenant en pratique le code programme, une mémoire dynamique RAM comme mémoire de travail et une mémoire non volatile de type EEPROM par exemple, qui contient en pratique des paramètres sensibles (au sens sécurité) de la carte, dont des compteurs. Dans l'exemple, cette mémoire contient notamment trois clés secrètes notées KDP, KDL et KDU, trois compteurs de sessions associés, notés NTP, NTL et NTU, et trois compteurs de contrôle associés selon l'invention, notés CKDp, C , CKD(,.
Cette mémoire contient d'autres paramètres. Certains peuvent être mis à jour par un système externe, par une transaction de mise à jour, selon une procédure sécurisée. On rappelle que dans une carte porte-monnaie électronique, trois types de transactions sont possibles et à chaque type de transaction correspond une clé secrète associée. On a ainsi les types de transaction suivants : - Achat ou annulation d'achat (purchase or purchase cancellation) avec la clé secrète associée, notée KDP;
- Chargement ou déchargement (Load or Unload) avec la clé secrète associée, noté KDL et
- Mise à jour ( update ) avec la clé secrète associée, notée KDU.
Dans l'invention, on prévoit alors d'utiliser un compteur de contrôle par clé secrète différente. On a ainsi le compteur CKDP associé à la clé secrète KDP, le compteur CKDL associé à la clé secrète KDL et le compteur CKDU associé à la clé secrète KDU. L'exemple d'organigramme de fonctionnement d'une telle carte représenté sur la figure 3 concerne une transaction de type achat (purchase ) , pour laquelle la carte utilise donc la clé secrète KDP, le compteur de session associé NTP et le compteur de contrôle associé selon l'invention, CKDp.
Une transaction d'achat comprend une première phase d'initialisation qui se limite normalement à l'envoi d'une commande par le terminal à la carte, pour lui spécifier le type de transaction. On libelle habituellement cette commande de la manière suivante, dans la littérature anglo-saxonne : INIT FOR PURCHASE.
Le microprocesseur se branche alors sur l'adresse du code programme correspondant à ce type de transaction.
Dans l'invention, on prévoit dans cette phase d'initialisation de décrémenter le compteur de contrôle concerné, C KDP' d'une unité. La carte exécute donc l'instruction suivante : CKDp = CKDp - u. Elle teste alors si le compteur de contrôle a atteint sa valeur limite, dans l'exemple zéro. Si il a atteint sa valeur limite (CKDp 0) , la carte ne peut donner suite à la transaction, qui se terminera donc par défaut de réponse par la carte. Si la limite n'est pas atteinte, la carte passe à une phase de traitement, dans laquelle elle procède notamment aux opérations suivantes :
- elle calcule la clé de session SKp, en appliquant l'algorithme de cryptographie à la valeur du compteur de session NTP et en utilisant la clé secrète KDP,
- elle envoie une donnée au terminal pour qu'il calcule une signature correspondante S2T,
- elle reçoit en retour la signature S2T calculée par le terminal^, - elle calcule une signature S2 en appliquant l'algorithme de cryptographie à la donnée variable envoyée au terminal, avec la clé de session SKp.
La carte compare alors les deux signatures. Si elles sont comparables, 1 ' authentification est réussie, le compteur de contrôle selon l'invention est alors ré- incrémenté par la valeur u. Sinon, il est inchangé. La transaction peut ensuite continuer.
On voit que si trop de transactions de type achat conduisent à un échec de 1 ' authentification par la carte, le compteur de contrôle selon l'invention va permettre de bloquer toute utilisation de la carte pour une transaction de type achat.
En fait il bloque toute utilisation de la carte pour des transactions de même type, utilisant la même clé secrète. Ainsi, dans le cas du compteur CKDp, ce sont les transactions d'achat ou d'annulation d'achat qui seront bloquées.
La figure 4 montre un organigramme de fonctionnement de la carte pour la transaction de type annulation d'achat, qui utilise donc la même clé secrète KDP.
Dans cette transaction, la phase d'initialisation initiée par une commande d'initialisation du terminal, (commande "init for purchase cancellation " selon la littérature anglo-saxonne), comprend, en plus de la décrémentation d'une unité u du compteur de contrôle
CKDp selon l'invention, le calcul de la clé de session
SKp et d'une signature SI obtenue par application d'un algorithme de cryptographie sur une donnée, en utilisant la clé de session. A l'issue de ce calcul, la carte transmet au terminal, cette donnée et la signature SI, pour permettre au terminal d'authentifier la carte. Cette authentification par le terminal ne fait l'objet d'aucune réponse du terminal. La carte passe à la phase de traitement dans laquelle elle authentifie à son tour le terminal, comme précédemment. Dans ce type de transaction, la signature S2 est en général calculée sur zéro. La carte calcule donc la signature S2 correspondante avec la clé de session KDP. Elle reçoit la signature S2 calculée par le terminal et effectue la comparaison des deux signatures. Si elles sont comparables, la session d' authentification est réussie. Le compteur de contrôle selon l'invention est ré-incrémenté par l'unité u. Sinon, le compteur de contrôle est inchangé. La transaction se poursuit.
Dans le cas de cette transaction, on voit que la carte effectue deux calculs cryptographiques jusqu'à et y compris celui de la session d' authentification par la carte, le calcul de la signature SI et le calcul de la signature S2. Pour cette transaction, on prévoit alors de préférence de décrémenter le compteur de contrôle d'une valeur correspondant au nombre de calculs cryptographiques effectués jusqu'à et y compris celui de la session d' authentification par la carte.
Cette décrémentation peut se faire en une seule fois, par une unité u représentative de ce nombre de calculs réalisés pour cette transaction. La valeur prise par u pour cette transaction pourrait être initialisée dans la phase d'initialisation, suite à la commande du type "INIT FOR" . Cette décrémentation en plusieurs fois, en décrémentant d'une unité le compteur avant chaque calcul, dans l'exemple, avant le calcul de la signature SI et avant le calcul de la signature S2. Dans ce cas, on prévoira de faire le test de la valeur limite sur le compteur après chaque décrémentation.
Dans ce cas aussi, on prévoit alors un compteur de pointage associé au compteur de contrôle, noté DKDp sur la figure 2, initialisé à zéro au début de la transaction et que l'on vient par exemple incrémenter à chaque fois que l'on décrémente le compteur de contrôle. Ainsi, si 1 ' authentification par la carte est réussie, on ré-incrémente le compteur de contrôle du nombre contenu dans le compteur de pointage. On notera que l'homme du métier utilisera l'une ou l'autre des différentes possibilités de mise en oeuvre selon les spécificités de l'application visée. Notamment on peut utiliser une mise en oeuvre pour un type de transactions et une autre pour un autre type de transactions selon le degré de sécurité voulu.
La figure 5 représente un organigramme de fonctionnement pour une autre type de transaction, celle de mise à jour. Il est relativement semblable aux précédents, mais 1 ' authentification par la carte se fait ici sur la signature notée SI.
En fait, de manière générale, le compteur de contrôle est décrémenté au début de la transaction. Il n'est ré-incrémenté, s'il peut l'être, qu'après une session d' authentification par la carte. On notera que les organigrammes des figures 3 à 5 ne montrent que certaines des opérations effectuées au cours de la transaction, pour l'explication du procédé selon l'invention. En pratique, d'autres opérations sont exécutées. Notamment selon les transactions, on utilise pour calculer les signatures la clé de session courante, ou la clé de session précédente. Après le calcul de la clé de session, le compteur de session doit-être incrémenté ... Tous ces aspects sont spécifiques de l'application à proprement parler et n'ont pas d'intérêt quant à la mise en oeuvre du procédé de contrôle selon l'invention.
Les différents compteurs de contrôle doivent être initialisés à une valeur de blocage N bien choisie. Cette valeur doit tenir compte du type de transactions associé, du niveau de sécurité correspondant à mettre en oeuvre mais aussi des erreurs possibles en cours d'utilisation "normale" par le titulaire de la carte : il ne s'agit pas de bloquer l'utilisation de la carte alors que le titulaire n'a pas cherché à faire une fraude. Dans un exemple à titre purement illustratif, mais qui rend compte des différents aspects qui doivent être pris en compte, on peut initialiser le compteur de contrôle C„n-, associé aux transactions achat/annulation d'achat à 100, le compteur de contrôle CKDL associé aux transactions chargement/déchargement à 20, et le compteur de contrôle CKDu associé aux transactions de mise à jour à 10.
On a expliqué précédemment qu'une variante du procédé de contrôle selon l'invention consiste à incrémenter le compteur à chaque session et à ne le décrémenter que sous condition (authentification par la carte réussie). Dans ce cas, le compteur est initialisé à zéro, et la valeur limite, à laquelle le contenu du compteur est comparé, est égale à la valeur de blocage N. Tout ce qui a été décrit précédemment s'applique à cette variante de l'invention.
L'invention vient d'être expliquée dans un exemple d'application à une carte porte-monnaie électronique. Mais il ressort clairement de cette description que le procédé de contrôle selon l'invention s'applique à tout type de carte à puce dès lors qu'elle réalise une session d' authentification. Cette session d' authentification peut être basée sur un algorithme de cryptographie à clé secrète, par exemple de type DES, comme expliqué dans le cas de la carte porte-monnaie électronique, mais aussi des algorithmes d'autres type, comme les algorithmes de type RSA utilisant un couple de clés (clé privée, clé publique) par exemple. Par ailleurs, dans l'invention, on entend par carte à puce aussi bien les cartes de format bien connu que des supports portables.

Claims

REVENDICATIONS
1. Procédé de contrôle de l'utilisation d'une carte à puce comprenant un microprocesseur apte à effectuer des calculs de cryptographie dans la carte pour effectuer des sessions d' authentification lors d'une transaction entre la carte et un terminal, caractérisé en ce que ledit procédé utilise au moins un compteur de contrôle (cκnp) e" en ce <3ue Pour une transaction comprenant au moins une session d' authentification par la carte, le procédé consiste :
- à décrémenter, ou incrémenter, d'une unité (u) le compteur de contrôle au début de la transaction et
- si 1 ' authentification par la carte est réussie, à effectuer la ré-incrémentation, ou la décrémentation, dudit compteur de contrôle par ladite unité (u) .
2. Procédé selon la revendication 2, caractérisé en ce que le compteur de contrôle peut décompter depuis, ou compter jusqu'à, une valeur de blocage.
3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend l'utilisation d'un compteur de contrôle par clé et/ou par couple de clés de cryptage contenus dans la carte.
4. Procédé selon la revendication 3, caractérisé en la valeur de blocage associée à un compteur est fonction du type de transactions dans lesquelles la clé associée ou le couple de clés associé est utilisé.
5. Procédé selon la revendication 3, caractérisé en ce que l'unité de décrémentation, ou d'incrémentation, d'un compteur de contrôle est représentative du nombre de calculs cryptographiques avec la clé associée ou le couple de clés associé, effectués jusqu'à et y compris celui de ladite session d' authentification pendant ladite transaction.
6. Procédé selon la revendication 3, caractérisé en ce que le compteur de contrôle associé à une clé ou un couple de clés est décrémenté, ou incrémenté, d'une nouvelle unité, avant chacun des calculs cryptographiques utilisant ladite clé ou le dit couple de clés, jusqu'à et y compris celui de ladite session d'authentification par la carte.
7. Procédé selon la revendication 5, caractérisé en ce que la ré-incrémentation, ou la décrémentation, du compteur par l'unité représentative du nombre de calculs cryptographiques est effectuée si la session d'authentification par la carte est réussie.
8. Procédé selon la revendication 6, caractérisé en ce qu'il comprend un compteur de pointage (D KDP) pour mémoriser le nombre de décrémentations, ou d'incrémentations, d'une unité effectuées, pour permettre la ré-incrémentation, ou la décrémentation, du compteur de contrôle (C KDP) Par le contenu du compteur de pointage, si la session d' authentification par la carte est réussie.
9. Procédé de contrôle selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite session d' authentification par la carte est effectuée lors d'une connexion par liaison directe à un serveur.
10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, lorsque le compteur de contrôle est décrémenté, ou incrémenté, jusqu'à une valeur limite, il bloque l'utilisation de la clé associée ou du couple de clé associé.
11. Procédé selon la revendication 10, caractérisé en ce que le blocage de l'utilisation de la clé ou du couple de clés est irréversible.
12. Carte à puce comprenant au moins un compteur de contrôle associé à au moins une clé et/ou un couple de clés pour la mise en oeuvre d'un procédé de contrôle selon l'une quelconque des revendications précédentes.
PCT/FR1999/002782 1998-11-18 1999-11-12 Procede de controle d'utilisation d'une carte a puce WO2000030049A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP99972341A EP1131800A1 (fr) 1998-11-18 1999-11-12 Procede de controle d'utilisation d'une carte a puce
AU11672/00A AU1167200A (en) 1998-11-18 1999-11-12 Method for controlling the use of a smart card

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9814497A FR2786007B1 (fr) 1998-11-18 1998-11-18 Procede de controle d'utilisation d'une carte a puce
FR98/14497 1998-11-18

Publications (1)

Publication Number Publication Date
WO2000030049A1 true WO2000030049A1 (fr) 2000-05-25

Family

ID=9532876

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1999/002782 WO2000030049A1 (fr) 1998-11-18 1999-11-12 Procede de controle d'utilisation d'une carte a puce

Country Status (5)

Country Link
EP (1) EP1131800A1 (fr)
CN (1) CN1333904A (fr)
AU (1) AU1167200A (fr)
FR (1) FR2786007B1 (fr)
WO (1) WO2000030049A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004046897A1 (fr) * 2002-11-04 2004-06-03 Giesecke & Devrient Gmbh Procede pour proteger un support de donnees portable

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2853785B1 (fr) * 2003-04-09 2006-02-17 Oberthur Card Syst Sa Entite electronique securisee avec compteur modifiable d'utilisations d'une donnee secrete
DE10360998B4 (de) * 2003-12-23 2008-09-04 Infineon Technologies Ag Schutz von Chips gegen Attacken
JP4616611B2 (ja) 2004-10-08 2011-01-19 富士通株式会社 生体認証装置
US7630924B1 (en) * 2005-04-20 2009-12-08 Authorize.Net Llc Transaction velocity counting for fraud detection
FR3030826B1 (fr) * 2014-12-18 2018-01-19 Idemia France Procede de securisation d'un dispositif electronique, et ledit dispositif electronique
FR3061586A1 (fr) * 2016-12-30 2018-07-06 Idemia France Procede de controle d'habitudes d'utilisation et dispositif electronique apte a mettre en œuvre un tel procede
CN111292089A (zh) * 2020-02-12 2020-06-16 北京智慧云测科技有限公司 一种psam卡防护管理方法和psam卡

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0157303A2 (fr) * 1984-03-31 1985-10-09 Kabushiki Kaisha Toshiba Dispositif de traitement de données
GB2188762A (en) * 1986-04-04 1987-10-07 Philip Hall Bertenshaw Secure data communication system
EP0481882A1 (fr) * 1990-10-19 1992-04-22 Gemplus Card International Procédé pour la ratification de codes secrets pour cartes à mémoire
EP0626662A1 (fr) * 1993-05-26 1994-11-30 Gemplus Card International Puce de carte à puce munie d'un moyen de limitation du nombre d'authentifications
EP0789335A2 (fr) * 1996-02-07 1997-08-13 Deutsche Telekom AG Méthode de décompte pour systèmes à porte-monnaie électroniques avec des cartes à puce

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0157303A2 (fr) * 1984-03-31 1985-10-09 Kabushiki Kaisha Toshiba Dispositif de traitement de données
GB2188762A (en) * 1986-04-04 1987-10-07 Philip Hall Bertenshaw Secure data communication system
EP0481882A1 (fr) * 1990-10-19 1992-04-22 Gemplus Card International Procédé pour la ratification de codes secrets pour cartes à mémoire
EP0626662A1 (fr) * 1993-05-26 1994-11-30 Gemplus Card International Puce de carte à puce munie d'un moyen de limitation du nombre d'authentifications
EP0789335A2 (fr) * 1996-02-07 1997-08-13 Deutsche Telekom AG Méthode de décompte pour systèmes à porte-monnaie électroniques avec des cartes à puce

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004046897A1 (fr) * 2002-11-04 2004-06-03 Giesecke & Devrient Gmbh Procede pour proteger un support de donnees portable

Also Published As

Publication number Publication date
FR2786007A1 (fr) 2000-05-19
CN1333904A (zh) 2002-01-30
EP1131800A1 (fr) 2001-09-12
FR2786007B1 (fr) 2001-10-12
AU1167200A (en) 2000-06-05

Similar Documents

Publication Publication Date Title
EP0496656B1 (fr) Procédé d&#39;échange de droits entre cartes à microprocesseur
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
EP0252849B1 (fr) Procédé pour authentifier une donnée d&#39;habilitation externe par un objet portatif tel qu&#39;une carte à mémoire
EP1290647B1 (fr) Procede de cryptographie et microcircuit pour carte a puce
WO2001095274A1 (fr) Procede de securisation de la phase de pre-initialisation d&#39;un systeme embarque a puce electronique, notamment d&#39;une carte a puce, et systeme embarque mettant en oeuvre le procede
EP1807967B1 (fr) Procede de delegation securisee de calcul d&#39;une application bilineaire
FR2893797A1 (fr) Personnalisation d&#39;une carte bancaire pour d&#39;autres applications
CA2296009A1 (fr) Procede de gestion d&#39;un terminal securise
WO2000030049A1 (fr) Procede de controle d&#39;utilisation d&#39;une carte a puce
FR3098947A1 (fr) Procédé de traitement d’une transaction émise depuis une entité de preuve
EP1399896B1 (fr) Procede cryptographique pour la protection d&#39;une puce electronique contre la fraude
EP2614491A1 (fr) Procede simplifie de personnalisation de carte a puce et dispositif associe
FR3030825A1 (fr) Procede d&#39;envoi d&#39;une information de securite et dispositif electronique apte a mettre en oeuvre un tel procede
EP0829831B1 (fr) Méthode d&#39;authentification de cartes
EP3340098B1 (fr) Procédé pour la sécurité d&#39;une opération électronique avec une carte à puce
WO2010106042A1 (fr) Procédé de production de données de sécurisation, dispositif et programme d&#39;ordinateur correspondant
WO2023099496A1 (fr) Procédé de traitement de preuve numérique, système et programme correspondant
EP3825882A1 (fr) Procede et systeme pour le provisionnement ou remplacement securise d&#39;un secret dans au moins un dispositif de communication portable
WO1998044464A1 (fr) Procede de certification d&#39;un cumul dans un lecteur
FR2749413A1 (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
WO2017077210A1 (fr) Procédé de verification d&#39;identité lors d&#39;une virtualisation
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
FR3025341A1 (fr) Securisation de cles de cryptage pour transaction sur un dispositif depourvu de module securise
FR2897705A1 (fr) Mise a jour d&#39;une carte a puce

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 99815625.6

Country of ref document: CN

ENP Entry into the national phase

Ref document number: 2000 11672

Country of ref document: AU

Kind code of ref document: A

AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM HU ID IL IN IS JP KE KG KP LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1999972341

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09856269

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1999972341

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 1999972341

Country of ref document: EP