EP1192795A2 - Procede de gestion de donnees par un module de securite et module de securite - Google Patents

Procede de gestion de donnees par un module de securite et module de securite

Info

Publication number
EP1192795A2
EP1192795A2 EP00931312A EP00931312A EP1192795A2 EP 1192795 A2 EP1192795 A2 EP 1192795A2 EP 00931312 A EP00931312 A EP 00931312A EP 00931312 A EP00931312 A EP 00931312A EP 1192795 A2 EP1192795 A2 EP 1192795A2
Authority
EP
European Patent Office
Prior art keywords
card
security module
memory location
logical channel
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00931312A
Other languages
German (de)
English (en)
Inventor
Frédéric MAYANCE
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.)
Axalto SA
Original Assignee
Schlumberger Systemes 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 Schlumberger Systemes SA filed Critical Schlumberger Systemes SA
Publication of EP1192795A2 publication Critical patent/EP1192795A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H04M17/02—Coin-freed or check-freed systems, e.g. mobile- or card-operated phones, public telephones or booths

Definitions

  • the present invention relates to a data management method, by a security module, of a user card capable of being inserted into at least one terminal, said card being subjected to at least one authentication by said security module. It also relates to a security module adapted for its implementation.
  • the invention finds a particularly advantageous application in the field of telephony.
  • terminal administration systems which include an administration server and security modules generally embedded in hubs connected to said terminals.
  • a concentrator comprises a computer, several security modules and an electronic card with which said modules are connected.
  • the terminals are called public telephones.
  • a security module guarantees the validity of a user card inserted in a public telephone, in particular through authentication of said card. To this end, said card includes secret data making it possible to guarantee its validity.
  • Public telephone administration systems as well as secret data are managed by telephone operators.
  • the concentrator manages several security modules, generally around thirty.
  • a security module manages only one public telephone.
  • the electronic card is used to administer communication between the telephones and the administration server.
  • a technical problem to be solved by the object of the present invention is to propose a data management method, by a security module, of a user card capable of being introduced into at least one terminal, said card being subject at least one authentication by said security module, as well as a security module, which would make it possible to easily manage a fleet of terminals, at low cost, and this by reducing the administration device for said terminals.
  • a solution to the technical problem posed is characterized, according to a first object of the present invention, in that said data management method comprises the steps according to which:
  • this solution is characterized in that the security module comprises:
  • the data management method as well as the security module of the invention make it possible to manage several public telephones in parallel by means of a security module.
  • contextual data is stored defining the state in which a set of user cards is located at a given time during a connection session of said cards, for several telephones, the data being saved in a memory. of the security module.
  • FIG. 1 is a diagram showing a security module, a terminal and a user card for implementing the method according to the invention.
  • FIG. 2 is a diagram of the security module of FIG. 1 comprising several memory locations.
  • FIG. 3 is a diagram showing a first communication between the security module and the terminal of FIG. 1.
  • FIGS. 4a, 4b, 4c, 4d and 4e are diagrams representing a memory location of the security module of FIG. 2.
  • FIG. 5 is a diagram showing a memory location of the security module of FIG. 2.
  • FIG. 6 is a diagram showing a second communication between the security module and the terminal of FIG. 1.
  • the present description of the invention relates to the example of integrated circuit cards.
  • integrated circuit card is meant any portable object, card in ISO format or not, subscriber identification module, electronic label, badge, etc.
  • the term “introduction” of a card into a terminal generally means " cooperation ".
  • the invention relates both to a card with a contact interface which requires a physical introduction into the terminal, as well as a card with a contactless interface which are able to communicate with the terminal without physical contact with the latter (by radio frequency. ..) or a card with the two interfaces.
  • the SAM module comprises a memory comprising at least one memory location M.
  • the memory of the SAM security module is a non-volatile EEPROM memory.
  • the SAM security module comprises several memory locations M.
  • the memory locations M are placed contiguously in a CHANNEL file of the non-volatile memory EEPROM, and, a chronological counter RECMAN is associated at a memory location M as well as an allocation area CN.
  • the CN allocation area as well as the RECMAN chronological counter have respective initial values VI and V2.
  • the SAM security module also includes at least one ISSUER file comprising a MASTER master key and a cumulative CBCPT counter of units.
  • the module includes several ISSUER files. Each ISSUER file corresponding to a type of cards issued.
  • a user When a user wants to telephone, he introduces his CARD card into the public telephone P. Before initiating a communication, a first authentication A is carried out by means of the SAM security module, via the telephone P and then the communication.
  • the first authentication A comprises the steps described below, as shown in FIG. 3.
  • a first step an identifier ID of the user card is read, said identifier being unique for each card.
  • an available LC logical channel is sought and a logical channel for the public telephone P in which the user card CARD is located is allocated in the SAM security module.
  • an LC logical channel is sought by means of a first GETCHANNELSTATUS command sent from the public telephone P to the SAM security module.
  • a logical channel LC includes an identifier NB. Said module returns a list of all the channels used, advantageously their identifier NB. We deduce the channels that are available and choose one of the available channels.
  • a memory location M is associated with the logical channel LC by writing the identifier NB of the logical channel LC allocated in the area CN for allocation of the chosen memory location M. Thus, the memory location M is no longer free.
  • the lifetime of the non-volatile EEPROM memory depends on the number of registrations made.
  • the chronological counter RECMAN of each location is used. memory M as described below.
  • the value of the RECMAN chronological counter of the associated memory location M is incremented, relative to the maximum value of all the chronological counters of the memory locations M.
  • the oldest memory location M is the one with the smallest RECMAN time counter value.
  • the oldest free memory location M is associated with a logical channel LC.
  • the CHANNEL file comprises four memory locations M l, M2, M3 and M4 used. Their counters RECMAN chronological values have an initialization value V2 equal to zero.
  • the value of a RECMAN chronological counter is incremented by one.
  • the channel associated with the third location M3 is released. Its RECMAN3 counter is incremented by one and worth one.
  • the channel associated with the second location M2 is released. His counter
  • RECMAN2 is incremented by one compared to the third counter. Its value is two.
  • the channel associated with the fourth memory location M4 is released, its counter RECMAN4 is worth three, as shown in FIG. 4d.
  • a logical channel LC with identifier NB3 is allocated and the oldest free memory location M is associated, ie, as shown in FIG. 4e, the third memory location M3.
  • the method of the present invention allows, on the one hand, to avoid always choosing the same memory location M to write data there as we will see later, and, on the other hand, not to be restricted to the number of memory locations M for the choice of LC logical channel identifiers to be allocated. We can thus have the choice between, for example, two hundred and fifty five LC channel identifiers while having only ten memory locations M.
  • this memory management method described above can be applied to any application other than that of telephony.
  • the secret key KEY of the CARD card is recalculated, using the identifier ID of said card and a master key MASTER of said SAM module.
  • This step is also called the key diversification step.
  • an ISSUER file is selected during the step of reading the identifier of the user card, the correlation being made between the type of cards and the master key by means of the identifier of said user card.
  • the allocation of the LC logical channel and the diversification of the key are done by means of a second DIVERSIFYKEY command sent from the public telephone P to the SAM security module.
  • Said second command takes into account in particular the identifier NB of the channel allocated to the public telephone P, an identifier ALGOID2 of a diversification algorithm ALGO2, an identifier of the master key MASTER used and, where appropriate, a diversifier RAND.
  • the contextual data DATA relating to the authentication step A is stored in the memory location M associated with the allocated logical channel LC.
  • the contextual data DATA comprises an identifier ALGOID 1 an ALGO 1 signature algorithm, the identifier ID of the CARD user card, the identifier of the MASTER master key used, the diversified key KEY, an ABACUS abacus of the CARD user card, and, status data STATE ....
  • the ABACUS abacus has a first VO value.
  • the STATE state data makes it possible to manage in the SAM security module a sequence of commands in order to memorize the state of the SAM module at a given instant, and this for a LC logical channel given.
  • the SAM module comprises a table in which a number and a set of bytes are assigned to each state. An authorized command is represented by one of the bytes. The first quartet of the byte includes the number of the state in which we are after execution of the command, if there has been no error.
  • the second quartet includes the number of the state in which we are when there has been an error (not shown). If another user uses a second CARD in a second P-phone, the second card can be validated using the SAM module, for example, after a first authentication of a first user card. The contextual data of the first card is not lost, we can continue to manage the first card.
  • the method of said invention thus allows, thanks to this management of contextual data by the SAM security module, to execute different authentication sessions in parallel, an authentication session corresponding to a call duration and consequently manage multiple public telephones P by means of the security module SAM, a public telephone P having an allocated logical channel LC and an associated memory location M.
  • a random number RAND we send a random number RAND to the card, we store said random number in the memory location M associated with the allocated logical channel LC, we calculate in the card a cryptogram by encrypting the secret key KEY using in particular the ALGO 1 signature algorithm, the random number RAND, and, the cryptogram is sent to the security module SAM (not shown).
  • SAM security module
  • the value of the cryptogram is checked by means of the secret key KEY recalculated during the third step.
  • the communication can be established.
  • the ABACUS chart on the card is updated according to the number of units used during communication.
  • the value of the ABACUS abacus is read in order to verify that the abacus has been updated.
  • a second authentication A is carried out which corresponds to the last step of the first authentication A described above.
  • Said second authentication A takes into account the value of the abacus abacus read previously, the identifier ALGOID 1 of the ALGO 1 signature algorithm used and the ID identifier of the card, which have been saved in the memory location M. In the case where the same RAND random number is used, the steps concerning said random number are not useful since the latter is stored in the memory location M.
  • the contextual data DATA such as the new value VN of the abacus ABACUS, the new state data STATE, and, if necessary, the new RAND random number generated, said new state data replacing the old ones.
  • the new random RAND number if applicable. If a power off of the SAM module occurs, said second authentication A is performed again.
  • This second authentication A makes it possible to verify that no fraudster has used a pirate card to telephone.
  • the cryptogram calculated by said card and returned to the SAM module is erroneous since it is different from that calculated in said SAM module.
  • the identifier of the fraudulent card is different from that of the valid card previously inserted in the public telephone P, as is the value of the ABACUS chart.
  • the CARD card is removed from the public telephone P.
  • the allocated logical channel LC is no longer useful.
  • the logical channel LC associated with the terminal P is closed.
  • the area CN allocation of the memory location M associated with the initialization value VI is initialized and the chronological counter RECMAN is updated. If necessary, the contextual data DATA is deleted in the memory location M associated with the logical channel LC which is freed.
  • the method of the present invention has an advantage according to which the number of units used per type of card is counted in the SAM security module in an optimized manner.
  • a public telephone P comprises said security module SAM
  • the management of the channels described above does not apply since only one logical channel is used, and, the contextual data DATA are stored in a volatile memory. RAM.
  • the invention is in no way limited to the field of telephony, it can extend to other fields in which a terminal administration system is implemented, such as for example an administration system of parking meters.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé de gestion de données, par un module de sécurité, d'une carte utilisateur apte à être introduite dans au moins un terminal, ladite carte étant soumise à au moins une authentification par ledit module de sécurité. L'invention se caractérise en ce que ledit procédé comporte des étapes selon lesquelles, on introduit la carte dans un terminal, on alloue, dans le module de sécurité, un canal logique audit terminal, à chaque authentification de la carte utilisateur, on mémorise dans un emplacement mémoire associé au canal logique des données contextuelles relatives à l'étape d'authentification, ledit emplacement mémoire se trouvant dans une mémoire du module de sécurité, on retire la carte du terminal. L'invention s'applique, en particulier, à la téléphonie.

Description

PROCEDE DE GESTION DE DONNEES PAR UN MODULE DE
SECURITE ET MODULE DE SECURITE
La présente invention concerne un procédé de gestion de données, par un module de sécurité, d'une carte utilisateur apte à être introduite dans au moins un terminal, ladite carte étant soumise à au moins une authentification par ledit module de sécurité. Elle concerne également un module de sécurité adapté pour sa mise en oeuvre.
L'invention trouve une application particulièrement avantageuse dans le domaine de la téléphonie.
Dans le domaine de la téléphonie, il existe des systèmes d'administration de terminaux qui comportent un serveur d'administration et des modules de sécurité généralement embarqués dans des concentrateurs connectés auxdits terminaux. Un concentrateur comporte un ordinateur, plusieurs modules de sécurité et une carte électronique avec laquelle sont connectés lesdits modules. Les terminaux sont appelés téléphones publics. Un module de sécurité garantit la validité d'une carte utilisateur introduite dans un téléphone public, notamment grâce à une authentification de ladite carte. A cet effet, ladite carte comprend des données secrètes permettant de garantir sa validité. Les systèmes d'administration de téléphones publics ainsi que les données secrètes sont gérés par des opérateurs de téléphonie. Le concentrateur gère plusieurs modules de sécurité, en général une trentaine. Un module de sécurité ne gère qu'un seul téléphone public. La carte électronique permet d'administrer une communication entre les téléphones et le serveur d'administration. Bien que ce dispositif permette une gestion d'un parc de téléphones publics, il présente l'inconvénient d'être lourd à administrer. De plus, le dispositif ainsi mis en place est coûteux pour les opérateurs de téléphonie. Aussi, un problème technique à résoudre par l'objet de la présente invention est de proposer un procédé de gestion de données, par un module de sécurité, d'une carte utilisateur apte à être introduite dans au moins un terminal, ladite carte étant soumise à au moins une authentification par ledit module de sécurité, ainsi qu'un module de sécurité, qui permettraient de gérer facilement un parc de terminaux, à moindre coût, et ce en allégeant le dispositif d'administration desdits terminaux.
Une solution au problème technique posé se caractérise, selon un premier objet de la présente invention, en ce que ledit procédé de gestion de données comporte les étapes selon lesquelles :
- on introduit la carte dans un terminal,
- on alloue, dans le module de sécurité, un canal logique audit terminal, - à chaque authentification de la carte utilisateur, on mémorise dans un emplacement mémoire associé au canal logique, des données contextuelles relatives à l'étape d'authentification, ledit emplacement mémoire se trouvant dans une mémoire du module de sécurité, - on retire la carte du terminal.
Selon un second objet de la présente invention, cette solution se caractérise en ce que le module de sécurité comporte :
- des moyens d'allocation d'un canal logique audit terminal dans lequel est introduite la carte, - un emplacement mémoire associé au canal logique apte à mémoriser des données contextuelles relatives à chaque étape d'authentification de la carte utilisateur, ledit emplacement mémoire se trouvant dans une mémoire du module de sécurité. Ainsi, comme on le verra en détail plus loin, le procédé de gestion de données ainsi que le module de sécurité de l'invention, permettent de gérer plusieurs téléphones publics en parallèle au moyen d'un module de sécurité. A cet effet, on mémorise des données contextuelles définissant l'état dans lequel se trouve un ensemble de cartes utilisateurs à un instant donné lors d'une session de connexion desdites cartes, et ce, pour plusieurs téléphones, les données étant sauvegardées dans une mémoire du module de sécurité.
La description qui va suivre au regard des dessins annexés, donnée à titre d'exemple non limitatif, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
La figure 1 est un schéma montrant un module de sécurité, un terminal et une carte utilisateur pour la mise en oeuvre du procédé selon l'invention. La figure 2 est un schéma du module de sécurité de la figure 1 comprenant plusieurs emplacements mémoire.
La figure 3 est un schéma montrant une première communication entre le module de sécurité et le terminal de la figure 1.
Les figures 4a, 4b, 4c, 4d et 4e sont des schémas représentant un emplacement mémoire du module de sécurité de la figure 2.
La figure 5 est un schéma montrant un emplacement mémoire du module de sécurité de la figure 2.
La figure 6 est un schéma montrant une deuxième communication entre le module de sécurité et le terminal de la figure 1. Le présent exposé de l'invention a trait à l'exemple des cartes à circuit intégré. Par carte à circuit intégré, on entend tout objet portatif, carte au format ISO ou non, module d'identification abonné, étiquette électronique, badge, etc.
On notera que le terme « introduction » d'une carte dans un terminal, employé par la suite, signifie de manière générale « coopération ». L'invention concerne aussi bien une carte avec une interface à contacts qui nécessite une introduction physique dans le terminal, qu'une carte avec une interface sans contacts qui sont à même de dialoguer avec le terminal sans contacts physiques avec ce dernier (par radiofréquence...) ou encore une carte comportant les deux interfaces.
Sur la figure 1 est représenté un module SAM de sécurité, un terminal P et une carte utilisateur CARD. Le terminal P est un téléphone public. Le module SAM comprend une mémoire comportant au moins un emplacement mémoire M. Préférentiellement, la mémoire du module de sécurité SAM est une mémoire non volatile EEPROM. Préférentiellement, le module de sécurité SAM comporte plusieurs emplacements mémoire M. Comme le montre la figure 2, avantageusement, les emplacements mémoire M sont placés de manière contiguë dans un fichier CHANNEL de la mémoire non volatile EEPROM, et, un compteur chronologique RECMAN est associé à un emplacement mémoire M ainsi qu'une zone CN d'attribution. La zone CN d'attribution ainsi que le compteur chronologique RECMAN ont des valeurs initiales respectives VI et V2. Le module de sécurité SAM comporte également au moins un fichier ISSUER comprenant une clef maître MASTER et un compteur cumulatif CBCPT d'unités. Avantageusement, le module comporte plusieurs fichiers ISSUER. Chaque fichier ISSUER correspondant à un type de cartes émises.
Lorsqu'un utilisateur veut téléphoner, il introduit sa carte CARD dans le téléphone public P. Avant d'initier une communication, on effectue une première authentification A au moyen du module SAM de sécurité, par l'intermédiaire du téléphone P puis on établit la communication .
La première authentification A comprend les étapes décrites ci- après, comme le montre la figure 3. Dans une première étape, on lit un identifiant ID de la carte utilisateur, ledit identifiant étant unique pour chaque carte.
Dans une seconde étape, on recherche un canal logique LC disponible et on alloue, dans le module de sécurité SAM, un canal logique pour le téléphone public P dans lequel la carte utilisateur CARD se trouve. Préalablement à l'allocation, on recherche un canal logique LC au moyen d'une première commande GETCHANNELSTATUS envoyée à partir du téléphone public P au module de sécurité SAM. Un canal logique LC comporte un identifiant NB. Ledit module renvoie une liste de tous les canaux utilisés, avantageusement leur identifiant NB. On déduit les canaux qui sont disponibles et on choisit un des canaux disponibles. Après l'allocation, on associe un emplacement mémoire M au canal logique LC en inscrivant l'identifiant NB du canal logique LC alloué dans la zone CN d'attribution de l'emplacement mémoire M choisi. Ainsi, l'emplacement mémoire M n'est plus libre.
La durée de vie de la mémoire non volatile EEPROM dépend du nombre d'inscriptions effectuées. Afin d'éviter d'associer un emplacement mémoire M de la mémoire non volatile EEPROM à un canal logique LC, par exemple, dans un ordre croissant, et par suite de toujours utiliser les mêmes emplacements, on utilise le compteur chronologique RECMAN de chaque emplacement mémoire M de la manière décrite ci-après. Lorsqu'on ferme un canal logique LC, on incrémente la valeur du compteur chronologique RECMAN de l'emplacement mémoire M associé, par rapport à la valeur maximum de tous les compteurs chronologiques des emplacements mémoire M. L'emplacement mémoire M le plus ancien est celui dont la valeur du compteur chronologique RECMAN est la plus petite. Ainsi, on associe le plus ancien emplacement mémoire M libre à un canal logique LC. Comme le montre la figure 4a, le fichier CHANNEL comporte quatre emplacements mémoire M l , M2, M3 et M4 utilisés. Leurs compteurs chronologiques RECMAN ont une valeur d'initialisation V2 égale à zéro.
Dans cet exemple, on incrémente de un la valeur d'un compteur chronologique RECMAN. Comme le montre la figure 4b, on libère le canal associé au troisième emplacement M3. Son compteur RECMAN3 est incrémente de un et vaut un. Comme le montre la figure 4c, On libère le canal associé au deuxième emplacement M2. Son compteur
RECMAN2 est incrémente de un par rapport au troisième compteur. Sa valeur est deux. On libère le canal associé au quatrième emplacement mémoire M4, son compteur RECMAN4 vaut trois, comme le montre la figure 4d. enfin, on alloue un canal logique LC d'identifiant NB3 et on associe le plus ancien emplacement mémoire M libre, soit, comme le montre la figure 4e, le troisième emplacement mémoire M3. Ainsi, le procédé de la présente invention permet, d'une part, d'éviter de toujours choisir un même emplacement mémoire M pour y inscrire des données comme nous le verrons par la suite, et, d'autre part, de ne pas être restreint au nombre d'emplacements mémoire M pour le choix d'identifiants de canaux logiques LC à allouer. On peut ainsi avoir le choix entre, par exemple, deux cent cinquante cinq identifiants de canal LC tout en n'ayant que dix emplacements mémoire M. Bien entendu, ce procédé de gestion de la mémoire décrit ci- dessus, peut s'appliquer à tout autre application que celle de la téléphonie.
Dans une troisième étape, dans le module de sécurité SAM, on recalcule la clef secrète KEY de la carte CARD, à partir de l'identifiant ID de ladite carte et d'une clef maître MASTER dudit module SAM. Cette étape est également appelée étape de diversification de clef. Afin de choisir la clef maître MASTER, dans le module SAM, un fichier ISSUER est sélectionné lors de l'étape de lecture de l'identifiant de la carte utilisateur, la corrélation étant faîte entre le type de cartes et la clef maître au moyen de l'identifiant de ladite carte utilisateur. L'allocation du canal logique LC et la diversification de clef se font au moyen d'un deuxième commande DIVERSIFYKEY envoyée à partir du téléphone public P au module de sécurité SAM. Ladite deuxième commande prend en compte notamment l'identifiant NB du canal alloué au téléphone public P, un identifiant ALGOID2 d'un algorithme de diversification ALGO2, un identifiant de la clef maître MASTER utilisée et le cas échéant un diversifiant RAND.
Dans une quatrième étape, comme le montre la figure 5, on mémorise dans l'emplacement mémoire M associé au canal logique LC alloué, les données contextuelles DATA relatives à l'étape d'authentification A. les données contextuelles DATA comprennent un identifiant ALGOID 1 d'un algorithme de signature ALGO 1 , l'identifiant ID de la carte utilisateur CARD, l'identifiant de la clef maître MASTER utilisée, la clef diversifiée KEY, un abaque ABACUS de la carte utilisateur CARD, et, des données d'état STATE .... L'abaque ABACUS a une première valeur VO. Il permet de comptabiliser les unités utilisées dans la carte utilisateur CARD, les données d'états STATE permettent de gérer dans le module de sécurité SAM une séquence de commandes afin de mémoriser l'état du module SAM à un instant donné, et ce pour un canal logique LC donné. Ainsi, suivant l'état dans lequel on est, on sait quelles sont les commandes autorisées et dans quel état on se trouve après l'exécution d'une des commandes selon le résultat de ladite exécution. Selon un mode de réalisation particulier, le module SAM comporte une table dans laquelle on attribue à chaque état un numéro et un ensemble d'octets. Une commande autorisée est représentée par un des octets. Le premier quartet de l'octet comprend le numéro de l'état dans lequel on se trouve après exécution de la commande, s'il n'y a eu aucune erreur. Le deuxième quartet comprend le numéro de l'état dans lequel on se trouve lorsqu'il y a eu une erreur (non représenté). Si un autre utilisateur utilise une deuxième carte CARD dans un deuxième pupliphone P, on peut valider la deuxième carte au moyen du module SAM, par exemple, après une première authentification d'une première carte utilisateur. Les données contextuelles de la première carte ne sont pas perdues, on peut continuer à gérer la première carte. Le procédé de ladite invention, permet ainsi, grâce à cette gestion de données contextuelles par le module de sécurité SAM, d'exécuter différentes sessions d'authentification en parallèle, une session d'authentification correspondant à une durée d'appel et par suite de gérer de multiples téléphones publics P au moyen du module de sécurité SAM, un téléphone public P ayant un canal logique LC alloué et un emplacement mémoire M associé.
Enfin, dans une dernière étape, on envoie un nombre aléatoire RAND à la carte, on mémorise ledit nombre aléatoire dans l'emplacement mémoire M associé au canal logique LC alloué, on calcule dans la carte un cryptogramme en cryptant la clef secrète KEY au moyen notamment de l'algorithme de signature ALGO 1, du nombre aléatoire RAND, et, on envoie le cryptogramme au module de sécurité SAM (non représenté). Dans ledit module SAM, on vérifie la valeur du cryptogramme au moyen de la clef secrète KEY recalculée lors de la troisième étape.
Ainsi, la première authentification A effectuée, la communication peut être établit. L'abaque ABACUS de la carte est actualisé suivant le nombre d'unités utilisé lors de la communication. On lit la valeur de l'abaque ABACUS afin de vérifier que ledit abaque a bien été actualisé. Par la suite, on effectue une deuxième authentification A qui correspond à la dernière étape de la première authentification A décrite précédemment.
Ladite deuxième authentification A prend en compte la valeur de l'abaque ABACUS lue précédemment, l'identifiant ALGOID 1 de l'algorithme de signature ALGO 1 utilisé et l'identifiant ID de la carte, qui ont été sauvegardés dans l'emplacement mémoire M. Dans le cas où on utilise le même nombre aléatoire RAND, les étapes concernant ledit nombre aléatoire ne sont pas utiles puisque ce dernier est mémorisé dans l'emplacement mémoire M.
Par la suite, on mémorise dans l'emplacement mémoire M associé au canal logique LC alloué, les données contextuelles DATA telles que la nouvelle valeur VN de l'abaque ABACUS, les nouvelles données d'état STATE, et, si nécessaire, le nouveau nombre aléatoire RAND généré, lesdites nouvelles données d'état remplaçant les anciennes. Il en est de même pour le nouveau nombre aléatoire RAND, le cas échéant. Si une mise hors-tension du module SAM survient, on effectue de nouveau ladite deuxième authentification A.
Cette deuxième authentification A permet de vérifier qu'aucun fraudeur n'a utilisé de carte pirate pour téléphoner. En effet, si un utilisateur introduit une carte frauduleuse, le cryptogramme calculé par ladite carte et renvoyé au module SAM est erroné puisque différent de celui calculé dans ledit module SAM. L'identifiant de la carte frauduleuse est différent de celui de la carte valide antérieurement introduite dans le téléphone public P, ainsi que la valeur de l'abaque ABACUS.
Lorsque la communication est terminée, on retire la carte CARD du téléphone public P. Le canal logique LC alloué n'est plus utile. Aussi, on ferme le canal logique LC associé au terminal P. A cet effet, on initialise la zone CN d'attribution de l'emplacement mémoire M associé avec la valeur VI d'initialisation et on met à jour le compteur chronologique RECMAN. Le cas échéant, on efface les données contextuelles DATA dans l'emplacement mémoire M associé au canal logique LC que l'on libère. Le procédé de la présente invention comporte un avantage selon lequel on comptabilise, dans le module de sécurité SAM, le nombre d'unités utilisées par type de cartes, de manière optimisée. En effet, comme le montre la figure 6, au lieu d'effectuer une mise à jour à chaque unité utilisée, il suffit de mettre à jour le compteur cumulatif CBCPT d'unités d'un fichier ISSUER du module SAM en soustrayant la nouvelle valeur VN de l'abaque ABACUS de la carte de la première valeur VO dudit abaque, la nouvelle valeur VN étant mémorisée dans l'emplacement mémoire M après chaque nouvelle deuxième authentification A. Lorsque la soustraction a été faîte, on remplace la première valeur VO par la deuxième valeur VN mémorisée, pour la deuxième authentification A suivante. Cette mise à jour est déclenchée au moyen d'une troisième commande INCBILLING prenant en compte un identifiant de canal NB correspondant à un fichier ISSUER et téléphone public P utilisé, ladite commande étant envoyée à partir du téléphone public P au module SAM.
On notera que lorsqu'un téléphone public P comprend ledit module de sécurité SAM, la gestion de canaux décrites ci-dessus ne s'applique pas puisqu'un seul canal logique est utilisé, et, les données contextuelles DATA sont mémorisées dans une mémoire volatile RAM.
Bien entendu, l'invention n'est nullement limitée au domaine de la téléphonie, elle peut s'étendre à d'autres domaines dans lesquels est mis en oeuvre un système d'administration de terminaux, tels que par exemple un système d'administration de parcmètres.

Claims

REVENDICATIONS
1 - Procédé de gestion de données, par un module de sécurité (SAM), d'une carte (CARD) utilisateur apte à être introduite dans au moins un terminal (P), ladite carte étant soumise à au moins une authentification (A) par ledit module de sécurité (SAM), caractérisé en ce qu'il comporte les étapes selon lesquelles :
- on introduit la carte (CARD) dans un terminal (P), on alloue, dans le module de sécurité (SAM), un canal logique (LC) audit terminal (P),
- à chaque authentification (A) de la carte utilisateur (CARD), on mémorise dans un emplacement mémoire (M) associé au canal logique (LC) des données contextuelles (DATA) relatives à l'étape d'authentification (A), ledit emplacement mémoire (M) se trouvant dans une mémoire du module de sécurité (SAM),
- on retire la carte (CARD) du terminal (P).
2 - Procédé selon la revendication 1 , caractérisé en ce que la mémoire du module de sécurité (SAM) est une mémoire non volatile (EEPROM). 3 - Procédé selon les revendications 1 ou 2, caractérisé en ce qu'on associe le plus ancien emplacement mémoire (M) libre à un canal logique (LC).
4 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'un compteur chronologique (RECMAN) est associé à un emplacement mémoire (M).
5 - Procédé selon les revendications 3 et 4, caractérisé en ce que l'emplacement mémoire (M) le plus ancien est celui dont la valeur du compteur chronologique (RECMAN) est la plus petite. 6 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte une étape supplémentaire selon laquelle : préalablement à l'allocation, on recherche un canal logique (LC) au moyen d'une première commande
(GETCHANNELSTATUS) .
7 - Procédé selon l'une des revendications précédentes, caractérisé en ce que le module de sécurité (SAM) comporte plusieurs emplacements mémoire (M). 8 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte une étape supplémentaire selon laquelle : on ferme le canal logique (LC) associé au terminal (P).
9 - Procédé selon la revendication 8, caractérisé en ce que lorsqu'on ferme un canal logique (LC), on incrémente la valeur du compteur chronologique (RECMAN) de l'emplacement mémoire (M) associé, par rapport à la valeur maximum de tous les compteurs chronologiques des emplacements mémoire (M).
10 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'on associe un emplacement mémoire (M) à un canal logique (LC) en inscrivant un identifiant (NB) du canal logique (LC) alloué dans une zone (CN) d'attribution de l'emplacement mémoire (M).
11 - Module de sécurité (SAM) destiné à gérer une carte (CARD) utilisateur introduite dans au moins un terminal (P), ladite carte étant apte à être soumise à au moins une authentification (A) par ledit module de sécurité (SAM), caractérisé en ce qu'il comporte : - des moyens d'allocation d'un canal logique (LC) audit terminal (P) dans lequel est introduite la carte (CARD), - un emplacement mémoire (M) associé au canal logique (LC) apte à mémoriser des données contextuelles (DATA) relatives à chaque étape d'authentification (A) de la carte (CARD) utilisateur, ledit emplacement mémoire (M) se trouvant dans une mémoire du module de sécurité (SAM).
12 - Module selon la revendication 11, caractérisé en ce que la mémoire du module de sécurité (SAM) est une mémoire non volatile (EEPROM).
13 - Module selon les revendications 11 ou 12, caractérisé en ce que le plus ancien emplacement mémoire (M) libre est associé à un canal logique (LC).
14 - Module selon l'une des revendications précédentes l i a 13, caractérisé en ce qu'un compteur chronologique (RECMAN) est associé à un emplacement mémoire (M). 15 - Module selon les revendications 13 et 14, caractérisé en ce que l'emplacement mémoire (M) le plus ancien est celui dont la valeur du compteur chronologique (RECMAN) est la plus petite.
16 - Module selon l'une des revendications précédentes l i a 15, caractérisé en ce qu'il comporte en outre une première commande (GETCHANNELSTATUS) apte à rechercher un canal logique (LC) préalablement à l'allocation.
17 - Module selon l'une des revendications précédentes 1 1 à 16, caractérisé en ce qu'il comporte plusieurs emplacements mémoire (M). 18 - Module selon l'une des revendications précédentes 1 1 à 17, caractérisé en ce qu'il comporte en outre des moyens pour fermer le canal logique (LC) associé au terminal (P).
19 - Module selon l'une des revendications précédentes l i a 18, caractérisé en ce qu'il comporte en outre des moyens pour incrémenter la valeur du compteur chronologique (RECMAN) de l'emplacement mémoire (M) associé, par rapport à la valeur maximum de tous les compteurs chronologiques des emplacements mémoire (M).
20 - Module selon l'une des revendications précédentes 1 1 à 19, caractérisé en ce qu'il comporte en outre des moyens pour associer un emplacement mémoire (M) à un canal logique (LC), lesdits moyens étant aptes à inscrire un identifiant (NB) du canal logique (LC) alloué dans une zone (CN) d'attribution de l'emplacement mémoire (M).
EP00931312A 1999-05-18 2000-05-18 Procede de gestion de donnees par un module de securite et module de securite Withdrawn EP1192795A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9906308A FR2793979B1 (fr) 1999-05-18 1999-05-18 Procede de gestion de donnees par un module de securite
FR9906308 1999-05-18
PCT/FR2000/001354 WO2000070842A2 (fr) 1999-05-18 2000-05-18 Procede de gestion de donnees par un module de securite et module de securite

Publications (1)

Publication Number Publication Date
EP1192795A2 true EP1192795A2 (fr) 2002-04-03

Family

ID=9545727

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00931312A Withdrawn EP1192795A2 (fr) 1999-05-18 2000-05-18 Procede de gestion de donnees par un module de securite et module de securite

Country Status (4)

Country Link
EP (1) EP1192795A2 (fr)
CN (1) CN1143517C (fr)
FR (1) FR2793979B1 (fr)
WO (1) WO2000070842A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4828809B2 (ja) * 2003-12-10 2011-11-30 株式会社東芝 Ｉｃカードおよびｉｃカードにおける処理方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DK608684D0 (da) * 1984-12-18 1984-12-18 Gnt Automatic As Betalingstelefon
GB8522427D0 (en) * 1985-09-10 1985-10-16 Plessey Co Plc Credit transaction arrangments
DE4133149C2 (de) * 1991-09-30 1994-12-01 Elmeg Kommunikationstech Fernsprechendgerät
NL9301271A (nl) * 1993-07-20 1995-02-16 Nederland Ptt Werkwijze en inrichting voor het registreren van gebruiksgegevens van op een betaalkaart werkende toestellen.

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CN1353905A (zh) 2002-06-12
FR2793979B1 (fr) 2001-06-29
FR2793979A1 (fr) 2000-11-24
CN1143517C (zh) 2004-03-24
WO2000070842A3 (fr) 2001-03-29
WO2000070842A2 (fr) 2000-11-23

Similar Documents

Publication Publication Date Title
EP0426541B1 (fr) Procédé de protection contre l'utilisation frauduleuse de cartes à microprocesseur, et dispositif de mise en oeuvre
EP0055986B1 (fr) Procédé et dispositif de sécurité pour communication tripartite de données confidentielles
EP1055203B1 (fr) Protocole de controle d'acces entre une cle et une serrure electronique
EP0950303B1 (fr) Procede et systeme pour securiser les prestations de service a distance des organismes financiers
EP0950307B1 (fr) Procede et systeme pour securiser les prestations de service d'operateurs de telecommunication
EP2193626B1 (fr) Communication securisee entre une etiquette electronique et un lecteur
FR2680892A1 (fr) Procede d'authentification de donnees.
FR2958102A1 (fr) Procede et systeme de validation d'une transaction, terminal transactionnel et programme correspondants.
EP1192795A2 (fr) Procede de gestion de donnees par un module de securite et module de securite
EP1436792B1 (fr) Protocole d'authentification a verification d'integrite de memoire
WO2016097650A1 (fr) Procede d'envoi d'une information de securite et dispositif electronique apte a mettre en oeuvre un tel procede
EP1912182A1 (fr) Autorisation d'une transaction entre un circuit électronique et un terminal
EP3262553A1 (fr) Procede de transaction sans support physique d'un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services
FR3052895B1 (fr) Procede d'envoi d'une information de securite
EP3343487A1 (fr) Procédé de contrôle d'habitudes d'utilisation et dispositif électronique apte à mettre en uvre un tel procédé
EP1965342A1 (fr) Procédé pour effectuer une transaction entre un module de paiement et un module de sécurité
FR2566155A1 (fr) Procede et systeme pour chiffrer et dechiffrer des informations transmises entre un dispositif emetteur et un dispositif recepteur
EP1269431A1 (fr) Procede de protection d'une puce electronique contre la fraude
EP1779340B1 (fr) Systeme de paiement par suite de jetons
FR2869702A1 (fr) Procedure d'acces a un service pre ou post-paye avec authentification d'un compte utilisateur et gestion dudit compte
EP1420373B1 (fr) Contrôle de code de carte pré-payée virtuelle
FR3051276B1 (fr) Procedes de mise en oeuvre d'une transaction via un terminal mobile
OA18272A (fr) Procédés de mise en œuvre d'une transaction via un terminal mobile.
WO2001075817A1 (fr) Procede d'authentification de cartes a puces
FR3025341A1 (fr) Securisation de cles de cryptage pour transaction sur un dispositif depourvu de module securise

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

AK Designated contracting states

Kind code of ref document: A2

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

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

Owner name: AXALTO S.A.

17Q First examination report despatched

Effective date: 20071122

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20071201