WO2003105096A2 - Procede de mise a jour de donnees sur une puce, notamment d'une c arte a puce - Google Patents

Procede de mise a jour de donnees sur une puce, notamment d'une c arte a puce Download PDF

Info

Publication number
WO2003105096A2
WO2003105096A2 PCT/IB2003/002470 IB0302470W WO03105096A2 WO 2003105096 A2 WO2003105096 A2 WO 2003105096A2 IB 0302470 W IB0302470 W IB 0302470W WO 03105096 A2 WO03105096 A2 WO 03105096A2
Authority
WO
WIPO (PCT)
Prior art keywords
security module
authentication certificate
holder
identification number
unique identification
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.)
Ceased
Application number
PCT/IB2003/002470
Other languages
English (en)
Other versions
WO2003105096A3 (fr
Inventor
Stéphane Joly
Nicolas Moeri
Blaise Lugeon
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.)
NagraCard SA
Original Assignee
NagraCard 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 NagraCard SA filed Critical NagraCard SA
Priority to AU2003240217A priority Critical patent/AU2003240217A1/en
Publication of WO2003105096A2 publication Critical patent/WO2003105096A2/fr
Publication of WO2003105096A3 publication Critical patent/WO2003105096A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING 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/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 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use

Definitions

  • the present invention relates to a method for communicating securely between a security module, such as in particular a smart card, and a remote server, the security module containing at least one unique identification number.
  • a security module such as in particular a smart card or a similar support containing a chip, comprising a unique identification number.
  • SSL Secure Socket Layer
  • the chip contains an authentication certificate with information relating to its holder.
  • the personalized authentication certificate is introduced into the chip during the manufacture of the card or of the module, at the time when the future holder of this module is known. This means that the module must imperatively be manufactured and produced "to measure" for each holder, since it is personalized during manufacture. This implies that the production of the smart card can only be undertaken when the information relating to the holder is known and that it is not possible to produce the cards in advance. This makes production management impractical and complex. Of course, this also has a negative influence on production costs.
  • the security module does not contain a certificate at the time of its manufacture. This is subsequently introduced by a certification authority. For this, the holder of such a module must present himself personally to the certification authority, provided with his module and must have the certificate drawn up and have it recorded in the module. This creates a constraint for the holder since he is obliged to go to a given place. This also creates a constraint for the certification authority since it obliges it to put itself at the service of the security module holders.
  • the present invention proposes to overcome these drawbacks by producing a security module which can be produced without knowing the information relating to its future holder.
  • This module however makes it possible to establish secure communication, via a secure communication protocol, between said module and a server. remote, for example using a public network of computers such as the Internet.
  • This object is achieved by a process as defined in the preamble and characterized in that an anonymous authentication certificate is introduced into said security module, in that data relating to the holder of said security module are introduced. in a database of a management center, this data being linked to said unique identification number, in that a first secure communication is established by means of a secure communication protocol using said authentication certificate anonymous, in that said unique identification number is transmitted in encrypted form to said management center, in that said unique identification number is associated with said data relating to the security module holder, in that the 'at least one personalized authentication certificate is generated, containing information relating to the holder of said security module coming from said database, in that transmitting said personalized authentication certificate in an encrypted manner to the security module, and in that subsequent secure communications are established between said security module and said remote server using said personalized authentication certificate.
  • a security module as defined in the preamble and characterized in that it further comprises an anonymous authentication certificate not containing data defined by the identity of the holder of the chip.
  • FIG. 1 shows schematically, a security module according to the present invention, as well as its content at the time of production of this module;
  • FIG. 3 shows schematically, a security module according to the present invention, as well as its content after its first use.
  • the security module 10 is illustrated as having the form of a smart card 11. It is clear that other embodiments are also covered by the invention.
  • the security module and the chip it contains could take the form of an electronic label or tag, or be integrated into any support such as a badge, a watch, a bracelet or any similar support.
  • a security module 10 such as a smart card 11 is first of all produced in a conventional manner, by introducing the “technical” part, namely an electronic chip 12 on the one hand, and a "visual” part, for example in the form of fields 13 not filled in which will be subsequently printed information relating to the card holder.
  • the electronic part is uniquely identified.
  • a unique identification number (UA) is introduced into the chip which will make it possible to distinguish this security module from all the other modules produced.
  • a pair of encryption keys 14 is then introduced into the chip of the security module at the time of its production.
  • This key pair is linked to a single authentication certificate issued by a licensing authority. certification 15.
  • the certificate does not contain any data relating to the card holder.
  • the authentication certificate referred to in the text below as the anonymous CAA authentication certificate, can be introduced at the time of production of the card.
  • This anonymous authentication certificate is used to uniquely authenticate the card.
  • it is possible to establish a connection using a protocol that requires such a certificate, as is the case with the SSL protocol.
  • the pair of keys 14 contained in the chip the transfer of information can be encrypted and the communication is therefore secure.
  • a second pair of keys 16 called user keys is introduced into the chip. This second pair of keys is not active at this stage, however.
  • Figure 2 illustrates the communication method according to the present invention. More specifically, it illustrates the initialization of the first communication established by means of the security module 10 as described above, with reference to FIG. 1.
  • a database 17 of a management center 18 of these modules Before the first use of the security module or at the latest, during this first use, personal data relating to the holder of the module are entered into a database 17 of a management center 18 of these modules. Some of this information can for example be made visible on the card, by printing it in the fields 13 provided for this purpose. Other information is only contained in the database 17, without it being contained in the security module.
  • This personal data is associated, in the database, with the number unique identification (UA) of the security module, so that a unique link is established between a card and a person.
  • CAP personalized authentication certificate
  • the security module When the security module is used for the first time, communication is established between the security module, for example by means of a smart card reader, the management center 18 and the certification authority 15. This communication takes place for example through a network of computers 19 such as the Internet.
  • This communication uses a secure protocol such as the SSL protocol.
  • the public and private keys are used to authenticate the security module 10 which is used and to initialize the connection according to this secure protocol.
  • the unique identification number (UA) is transmitted in encrypted form to the management center 18.
  • the latter determines the holder by means of this identification number and the data relating to the holder contained in the database. data associated with this identification number.
  • the device used by the security module holder to establish the connection first checks whether there is a certificate other than the anonymous authentication certificate (CAA) on the card.
  • CAA anonymous authentication certificate
  • the anonymous certificate is the only existing one.
  • the anonymous authentication certificate is also used to verify that the holder is authorized to access a given service.
  • the management center contains in a database, the access rights linked to each anonymous certificate or to each group of certificates.
  • the management center verifies, using the data stored in the database, if there is a match between the unique identification number (UA) of the security module, the personal data of the holder and the Anonymous Authentication Certificate (CAA).
  • UUA unique identification number
  • CAA Anonymous Authentication Certificate
  • the database can contain the unique identification number linked to the holder's personal data on the one hand and to the anonymous identification certificate on the other.
  • the identification number is read on the security module.
  • the holder's name can be requested.
  • the management center checks whether the unique identification number recorded in the database corresponds to the name entered by the holder and to the anonymous authentication certificate registered in the module. If this is the case, the management center sends a message (called “Entitlement management message” or “EMM”) which contains a new personalized authentication certificate (CAP) which itself contains the personal data of the module holder. security. This new certificate is saved in the security module.
  • EMM Entitlement management message
  • CAP personalized authentication certificate
  • the management center 18 does not check the adequacy between the unique identification number (UA) of the security module, the data personal data of the holder and the certificate of anonymous authentication (CAA).
  • UA unique identification number
  • CAA certificate of anonymous authentication
  • the pair of user keys 16 is made available while the pair of keys 14 linked to the anonymous authentication certificate is made unavailable, as shown in FIG. 3.
  • the security module then contains the data shown diagrammatically in FIG. 3, namely its unique identification number UA, a personalized authentication certificate CAP and a pair of keys 16 which is associated with it. Visual information is also printed on the card.
  • the security module 10 contains more than one authentication certificate. If this is the case, the personalized CAP authentication certificate, or one of them if it contains several, is used to establish secure communication. In this case, the user key pair 16 is used to encrypt and decrypt messages.
  • the anonymous and / or personalized authentication certificate is also used to check whether the security module and its holder are authorized to access the management center 18 on the one hand and the remote server on the other hand. It is indeed possible to use a security module for a single remote server, for example that of a given banking establishment and therefore, only at the management center which manages the data of only users. It is also possible to use a card containing access rights to different variable services per user or group of users.
  • the security module according to the invention as well as the communication method using this module have numerous advantages compared to the prior art. Indeed, it is possible to manufacture the module or a large number of modules without having any information relating to its future holder. This considerably simplifies production management and lowers the cost. Updating visual data does not require complex and expensive equipment. Updating "technical" data can be done completely securely, using a public network of computers, despite the fact that such a network is not reliable from an information security point of view. that circulate there. This means that these communications can be made from any connection point, without the need to go to a given place. This of course facilitates the use of the security module.
  • the use of the security module by a person other than the holder can be prevented in a conventional manner, for example by means of an alphanumeric code such as a PIN code or a user name and / or a password.
  • Having an anonymous authentication certificate also makes it possible to recycle the security module, by deleting the personalized certificate and by repeating the procedure described above, relating to a first connection.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un procédé pour communiquer de façon sécurisée entre un module de sécurité et un serveur distant. Elle concerne également un module de sécurité.Le module de sécurité contient un numéro d'identification unique (UA). Le procédé selon l'invention est caractérisé en ce que l'on introduit dans ce module de sécurité (10), un certificat d'authentification anonyme (CAA). Parallèlement, on introduit des données relatives au titulaire du module de sécurité (10) dans une base de données (17) d'un centre de gestion (18), ces données étant liées au numéro d'identification unique (UA). Lorsque l'on établit une première communication, celle-ci est sécurisée en utilisant le certificat d'authentification anonyme (CAA). On transmet le numéro d'identification unique (UA) sous forme chiffrée au centre de gestion (18), on associe ce numéro d'identification unique (UA) aux données relatives au titulaire du module de sécurité et on génère au moins un certificat d'authentification personnalisé (CAP), contenant des informations relatives au titulaire dudit module de sécurité provenant de ladite base de données (17). On transmet ensuite ce certificat d'authentification personnalisé (CAP) de façon chiffrée au module de sécurité. Les communications ultérieures entre le module de sécurité et le serveur distant utilisent ce certificat d'authentification personnalisé (CAP).

Description

PROCÉDÉ DE MISE À JOUR DE DONNÉES SUR UNE PUCE, NOTAMMENT D'UNE CARTE À PUCE.
La présente invention concerne un procédé pour communiquer de façon sécurisée entre un module de sécurité, tel que notamment une carte à puce, et un serveur distant, le module de sécurité contenant au moins un numéro d'identification unique.
Elle concerne également un module de sécurité tel que notamment une carte à puce ou un support analogue contenant une puce, comportant un numéro d'identification unique.
Actuellement, lorsque des données doivent être mises à jour sur une puce d'une carte à puce ou d'un support analogue, il n'est pas souhaitable d'effectuer une telle mise à jour par un réseau public d'ordinateurs tel qu'Internet, sans prendre des précautions relatives à la confidentialité des échanges d'informations. En effet, un tel réseau présente des problèmes de sécurité qui rendent cette mise à jour sans précaution risquée pour l'utilisateur.
Pour pallier à ce problème, il existe des protocoles de communication sécurisés tels que par exemple un protocole connu sous la dénomination « Secure Socket Layer » (SSL). Selon ce protocole, lorsque l'on veut établir une communication, il est nécessaire de disposer d'un certificat d'authentification et d'une clé de chiffrement, en particulier d'une clé de chiffrement dite privée, associée à ce certificat. Sans un tel certificat, établi par une autorité de certification, la communication ne peut matériellement pas être établie.
Pour des raisons de sécurité, on ne souhaite pas conserver dans un ordinateur non sécurisé, un tel certificat et sa clé privée. En outre, si le certificat et la clé sont stockées dans un ordinateur, la connexion à un serveur distant ne peut se faire qu'à partir de cet ordinateur, ce qui empêche toute mobilité.
Avec les modules de sécurité actuels permettant une communication sécurisée, la puce contient un certificat d'authentification avec des informations relatives à son titulaire. Selon une première forme de réalisation, le certificat d'authentification personnalisé est introduit dans la puce lors de la fabrication de la carte ou du module, au moment où le futur titulaire de ce module est connu. Cela signifie que le module doit impérativement être fabriqué et réalisé « sur mesure », pour chaque titulaire, puisqu'il est personnalisé à la fabrication. Cela implique que la production de la carte à puce ne peut être entreprise qu'au moment où les informations relatives au titulaire sont connues et qu'il n'est pas possible de produire les cartes par avance. Ceci rend la gestion de la production peu pratique et complexe. Bien entendu, ceci a également une influence négative sur les coûts de production.
Selon une deuxième forme de réalisation, le module de sécurité ne contient pas de certificat au moment de sa fabrication. Celui-ci est introduit ultérieurement par une autorité de certification. Pour ceci, le titulaire d'un tel module doit se présenter personnellement auprès de l'autorité de certification, muni de son module et doit faire établir le certificat et le faire enregistrer dans le module. Ceci crée une contrainte pour le titulaire puisqu'il est obligé de se rendre en un lieu donné. Cela crée également une contrainte pour l'autorité de certification puisque cela l'oblige à se mettre au service des titulaires de module de sécurité.
La présente invention se propose de pallier ces inconvénients en réalisant un module de sécurité qui puisse être produit sans connaître les informations relatives à son futur titulaire. Ce module permet toutefois d'établir une communication sécurisée, par l'intermédiaire d'un protocole de communication sécurisé, entre ledit module et un serveur distant, en utilisant par exemple un réseau public d'ordinateurs tels qu'Internet.
Ce but est atteint par un procédé tel que défini en préambule et caractérisé en ce que l'on introduit dans ledit module de sécurité, un certificat d'authentification anonyme, en ce que l'on introduit des données relatives au titulaire dudit module de sécurité dans une base de données d'un centre de gestion, ces données étant liées audit numéro d'identification unique, en ce que l'on établit une première communication sécurisée au moyen d'un protocole de communication sécurisé en utilisant ledit certificat d'authentification anonyme, en ce que l'on transmet ledit numéro d'identification unique sous forme chiffrée audit centre de gestion, en ce que l'on associe ledit numéro d'identification unique audites données relatives au titulaire du module de sécurité, en ce que l'on génère au moins un certificat d'authentification personnalisé, contenant des informations relatives au titulaire dudit module de sécurité provenant de ladite base de données, en ce que l'on transmet ledit certificat d'authentification personnalisé de façon chiffrée au module de sécurité, et en ce que l'on établit des communications sécurisées ultérieures entre ledit module de sécurité et ledit serveur distant en utilisant ledit certificat d'authentification personnalisé.
Ce but est également atteint par un module de sécurité tel que défini en préambule et caractérisée en ce qu'il comporte en outre un certificat d'authentification anonyme ne contenant pas de données définies par l'identité du titulaire de la puce.
La présente invention et ses avantages seront mieux compris en référence à la description d'un mode de réalisation particulier de l'invention et aux dessins annexés dans lesquels : - la figure 1 représente de façon schématique, un module de sécurité selon la présente invention, ainsi que son contenu au moment de la production de ce module;
- la figure 2 illustre le procédé de communication selon la présente invention ; et
- la figure 3 représente de façon schématique, un module de sécurité selon la présente invention, ainsi que son contenu après sa première utilisation.
En référence aux figures, le module de sécurité 10 est illustré comme ayant la forme d'une carte à puce 11. 11 est clair que d'autres formes de réalisation sont également couvertes par l'invention. En particulier, le module de sécurité et la puce qu'il contient pourrait avoir la forme d'une étiquette électronique ou tag, ou être intégré dans un support quelconque tel qu'un badge, une montre, un bracelet ou tout support analogue.
En référence à la figure 1 , un module de sécurité 10 tel qu'une carte à puce 11 est tout d'abord produit de façon conventionnelle, en introduisant la partie « technique », à savoir une puce électronique 12 d'une part, et une partie « visuelle », par exemple sous la forme de champs 13 non remplis dans lesquelles seront imprimées ultérieurement des informations relatives au titulaire de la carte.
Comme cela est également illustré par la figure 1 , la partie électronique est identifiée de façon unique. Pour ceci, on introduit dans la puce, un numéro d'identification unique (UA) qui permettra de distinguer ce module de sécurité de tous les autres modules produits.
Une paire de clés de chiffrage 14 est ensuite introduite dans la puce du module de sécurité au moment de sa production. Cette paire de clés est liée à un certificat d'authentification unique délivré par une autorité de certification 15. Contrairement aux modules de sécurité de l'art antérieur, le certificat ne contient aucune données relatives au titulaire de la carte. Il en résulte que même si celui-ci n'est pas encore connu, le certificat d'authentification, dénommé certificat d'authentification anonyme CAA dans la suite du texte, peut être introduit au moment de la production de la carte. Ce certificat d'authentification anonyme permet d'authentifier la carte de façon univoque. De plus, grâce à la présence de ce certificat, il est possible d'établir une connexion en utilisant un protocole qui requiert un tel certificat, comme c'est le cas pour le protocole SSL. En outre, grâce à la paire de clés 14 contenues dans la puce, le transfert d'informations peut être chiffré et la communication est donc sécurisée.
Simultanément à l'introduction de la première paire de clés dans la puce du module de sécurité, une deuxième paire de clés 16, dite clés utilisateur, est introduite dans la puce. Cette deuxième paire de clés n'est toutefois pas active à ce stade.
La figure 2 illustre le procédé de communication selon la présente invention. Plus précisément, il illustre l'initialisation de la première communication établie au moyen du module de sécurité 10 tel que décrit ci-dessus, en référence à la figure 1.
Avant la première utilisation du module de sécurité ou au plus tard, lors de cette première utilisation, des données personnelles relatives au titulaire du module sont introduites dans une base de données 17 d'un centre de gestion 18 de ces modules. Certaines de ces informations peuvent par exemple être rendues visibles sur la carte, en les imprimant dans les champs 13 prévus à cet effet. D'autres informations sont uniquement contenues dans la base de données 17, sans qu'elles soient contenues dans le module de sécurité. Ces données personnelles sont associées, dans la base de données, au numéro d'identification unique (UA) du module de sécurité, de sorte qu'un lien univoque est établi entre une carte et une personne.
Lorsque les données relatives au titulaire du module de sécurité sont connues, il est possible de générer un certificat d'authentification personnalisé (CAP). Celui-ci peut être stocké dans le centre de gestion 18 ou auprès de l'autorité de certification 15, ou de façon plus générale, dans tout endroit pouvant être connecté à la base de données 17 du centre de gestion.
Lors de la première utilisation du module de sécurité, une communication est établie entre le module de sécurité, par exemple au moyen d'un lecteur de carte à puce, le centre de gestion 18 et l'autorité de certification 15. Cette communication se fait par exemple par le biais d'un réseau d'ordinateurs 19 tel qu'Internet. Cette communication utilise un protocole sécurisé tel que le protocole SSL. Les clés publiques et privées sont utilisées pour authentifier le module de sécurité 10 qui est utilisé et pour initialiser la connexion selon ce protocole sécurisé. Dans cette première communication, le numéro d'identification unique (UA) est transmis de façon chiffrée au centre de gestion 18. Celui-ci détermine le titulaire au moyen de ce numéro d'identification et des données relatives au titulaire contenues dans la base de données, associées à ce numéro d'identification. Le dispositif utilisé par le titulaire du module de sécurité pour établie la connexion vérifie tout d'abord s'il existe un certificat autre que le certificat d'authentification anonyme (CAA) sur la carte. Dans le cas d'une première connexion, le certificat anonyme est le seul existant. Le certificat d'authentification anonyme est également utilisé pour vérifier que le titulaire est autorisé à accéder à un service donné. Pour ceci, le centre de gestion contient dans une base de données, les droits d'accès liés à chaque certificat anonyme ou à chaque groupe de certificat. Dans une première forme de réalisation, le centre de gestion vérifie, en utilisant les données stockées dans la base de données, s'il y a adéquation entre le numéro d'identification unique (UA) du module de sécurité, les données personnelles du titulaire et le certificat d'authentification anonyme (CAA). Cette vérification implique bien entendu qu'il existe un lien dans la base de données 17 qui permette de tester cette adéquation. A titre d'exemple, la base de données peut contenir le numéro d'identification unique lié aux données personnelles du titulaire d'une part et au certificat d'identification anonyme d'autre part. Lorsque la carte est utilisée pour la première fois, le numéro d'identification est lu sur le module de sécurité. Le nom du titulaire peut être demandé. Le centre de gestion vérifie si le numéro d'identification unique enregistré dans la base de données correspond au nom introduit par le titulaire et au certificat d'authentification anonyme enregistré dans le module. Si tel est le cas, le centre de gestion envoie un message (dénommé « Entitlement management message » ou « EMM ») qui contient un nouveau certificat d'authentification personnalisé (CAP) qui contient lui-même les données personnelles du titulaire du module de sécurité. Ce nouveau certificat est enregistré dans le module de sécurité. Il est à noter que, pour gagner du temps lors de la première communication et comme la génération d'un certificat d'authentification complet est relativement longue, il est possible d'utiliser un certificat d'authentification pré-existant qui est simplement transmis au module de sécurité au moment de cette première communication. Cela signifie que le certificat personnalisé est généré par exemple au moment où le titulaire du module a transmis toutes les données qui le concerne à la base de données.
Dans une deuxième forme de réalisation, généralement utilisée en pratique, le centre de gestion 18 ne vérifie pas l'adéquation entre le numéro d'identification unique (UA) du module de sécurité, les données personnelles du titulaire et le certificat d'authentification anonyme (CAA). Les autres étapes décrites ci-dessus se déroulent de la même façon pour les deux modes de réalisation.
A ce stade, la paire de clés utilisateur 16 est rendue disponible tandis que la paire de clés 14 liée au certificat d'authentification anonyme est rendue indisponible, comme cela est représenté par la figure 3.
Le module de sécurité contient alors les données schématisées par la figure 3, à savoir son numéro d'identification unique UA, un certificat d'authentification personnalisé CAP et une paire de clés 16 qui y est associé. Des informations visuelles sont également imprimées sur la carte.
Lors des connexions ultérieures, il est tout d'abord vérifié si le module de sécurité 10 contient plus d'un certificat d'authentification. Si tel est le cas, le certificat d'authentification personnalisé CAP, ou l'un d'eux s'il en contient plusieurs, est utilisé pour établir une communication sécurisée. Dans ce cas, la paire de clé utilisateur 16 est employée pour chiffrer et déchiffrer des messages. Le certificat d'authentification anonyme et/ou personnalisé est également utilisé pour vérifier si le module de sécurité et son titulaire sont autorisés à accéder au centre de gestion 18 d'une part et au serveur distant d'autre part. Il est en effet possible d'utiliser un module de sécurité pour un seul serveur distant, par exemple celui d'un établissement bancaire déterminé et par conséquent, uniquement au centre de gestion qui gère les données des seuls utilisateurs. Il est également possible d'utiliser une carte contenant des droits d'accès à différents services variables par utilisateur ou groupe d'utilisateurs.
Le module de sécurité selon l'invention ainsi que le procédé de communication utilisant ce module présentent de nombreux avantages par rapport à l'art antérieur. En effet, il est possible de fabriquer le module ou un grand nombre de modules sans avoir aucune information relative à son futur titulaire. Ceci simplifie considérablement la gestion de la production et diminue le coût. La mise à jour des données visuelles ne nécessite pas d'équipement complexe et coûteux. La mise à jour des données « techniques » peut se faire de façon totalement sécurisée, en utilisant un réseau public d'ordinateurs, malgré le fait qu'un tel réseau n'est pas fiable d'un point de vue de la sécurité des informations qui y circulent. Cela signifie que ces communications peuvent se faire depuis n'importe quel point de connexion, sans qu'il soit nécessaire de se rendre en un lieu donné. Ceci facilite bien entendu l'utilisation du module de sécurité.
Cela signifie également qu'il est possible de mettre à jour des données contenues sur la carte, et en particulier le certificat d'authentification personnalisé, à distance, sans contrainte pour l'utilisateur. Ainsi, sans aucune contrainte pour l'utilisateur, il est possible de changer le certificat personnalisé, par exemple tous les ans.
L'utilisation du module de sécurité par une personne autre que le titulaire peut être empêchée de façon classique, par exemple au moyen d'un code alphanumérique tel qu'un PIN code ou un nom d'utilisateur et/ou un mot de passe.
Le fait de disposer d'un certificat d'authentification anonyme permet également de recycler le module de sécurité, en supprimant le certificat personnalisé et en recommençant la procédure décrite ci-dessus, relative à une première connexion.

Claims

Revendications
1. Procédé pour communiquer de façon sécurisée entre un module de sécurité, tel que notamment une carte à puce, et un serveur distant, le module de sécurité contenant au moins un numéro d'identification unique (UA), caractérisé en ce que :
• 'on introduit dans ledit module de sécurité (10), un certificat d'authentification anonyme (CAA),
• l'on introduit des données relatives au titulaire dudit module de sécurité (10) dans une base de données (17) d'un centre de gestion (18), ces données étant liées audit numéro d'identification unique (UA),
• l'on établit une première communication sécurisée au moyen d'un protocole de communication sécurisé en utilisant ledit certificat d'authentification anonyme (CAA),
• l'on transmet ledit numéro d'identification unique (UA) sous forme chiffrée audit centre de gestion (18),
• l'on associe ledit numéro d'identification unique (UA) audites données relatives au titulaire du module de sécurité,
• l'on génère au moins un certificat d'authentification personnalisé (CAP), contenant des informations relatives au titulaire dudit module de sécurité provenant de ladite base de données (17),
• l'on transmet ledit certificat d'authentification personnalisé (CAP) de façon chiffrée au module de sécurité,
• et l'on établit des communications sécurisées ultérieures entre ledit module de sécurité et ledit serveur distant en utilisant ledit certificat d'authentification personnalisé (CAP).
2. Procédé selon la revendication 1 , caractérisé en ce que, pour établir une connexion, l'utilisateur introduit un code alphanumérique, et en ce que l'on compare ledit code alphanumérique introduit par l'utilisateur à un code alphanumérique enregistré dans la base de données (17) du centre de gestion (18).
3. Procédé selon la revendication 1 , caractérisé en ce qu'au moment d'une première connexion, on vérifie qu'il existe une adéquation entre le certificat d'authentification anonyme (CAA), le numéro d'identification unique (UA) et les données personnelles relatives au titulaire du module de sécurité (10).
4. Procédé selon la revendication 1 , caractérisé en ce qu'au moins lors de la première connexion, on vérifie que le certificat d'authentification anonyme (CAA) donne droit d'accéder à la base de données (17) du centre de gestion (18).
5. Procédé selon la revendication 1 , caractérisé en ce que le certificat d'authentification personnalisé (CAP) est remplacé après une certaine durée d'utilisation.
6. Module de sécurité tel que notamment carte à puce ou support analogue contenant une puce, comportant un numéro d'identification unique, caractérisé en ce qu'il comporte en outre un certificat d'authentification anonyme (CAA) ne contenant pas de données définies par l'identité du titulaire de la puce.
7. Module de sécurité selon la revendication 6, caractérisé en ce qu'il est utilisé pour établir une communication sécurisée avec un serveur distant, en utilisant le procédé selon l'une quelconque des revendications 1 à 5
PCT/IB2003/002470 2002-06-05 2003-06-03 Procede de mise a jour de donnees sur une puce, notamment d'une c arte a puce Ceased WO2003105096A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003240217A AU2003240217A1 (en) 2002-06-05 2003-06-03 Method for updating data on a chip, in particular of a smart card

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CH0951/02 2002-06-05
CH9512002 2002-06-05

Publications (2)

Publication Number Publication Date
WO2003105096A2 true WO2003105096A2 (fr) 2003-12-18
WO2003105096A3 WO2003105096A3 (fr) 2004-03-18

Family

ID=29721329

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2003/002470 Ceased WO2003105096A2 (fr) 2002-06-05 2003-06-03 Procede de mise a jour de donnees sur une puce, notamment d'une c arte a puce

Country Status (2)

Country Link
AU (1) AU2003240217A1 (fr)
WO (1) WO2003105096A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007138442A1 (fr) * 2006-05-25 2007-12-06 Axalto S.A. Procédé de correction d'applications sur de petits dispositifs sécurisés à ressources limitées
EP2068264A3 (fr) * 2007-11-27 2010-12-29 FeliCa Networks, Inc. Système de fourniture de service, serveur de fourniture de service et dispositif de terminal d'informations
US8266436B2 (en) 2007-11-27 2012-09-11 Felica Networks, Inc. Service providing system, service providing server and information terminal device
CN109447646A (zh) * 2018-11-13 2019-03-08 华瓴(南京)信息技术有限公司 一种电力交易系统中身份隐私保护方法及系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3927270C2 (de) * 1989-08-18 1996-07-11 Deutsche Telekom Ag Verfahren zum Personalisieren von Chipkarten
US6317832B1 (en) * 1997-02-21 2001-11-13 Mondex International Limited Secure multiple application card system and process
DE69824437T2 (de) * 1997-10-14 2005-06-23 Visa International Service Association, Foster City Personalisieren von chipkarten
WO2001031841A1 (fr) * 1999-10-27 2001-05-03 Visa International Service Association Procede et appareil permettant d'optimiser une infrastructure cryptographique existante

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007138442A1 (fr) * 2006-05-25 2007-12-06 Axalto S.A. Procédé de correction d'applications sur de petits dispositifs sécurisés à ressources limitées
WO2007138488A3 (fr) * 2006-05-25 2008-05-08 Axalto Sa Procédé de correction d'applications sur de petits dispositifs sécurisés à ressources limitées
EP2068264A3 (fr) * 2007-11-27 2010-12-29 FeliCa Networks, Inc. Système de fourniture de service, serveur de fourniture de service et dispositif de terminal d'informations
US8266436B2 (en) 2007-11-27 2012-09-11 Felica Networks, Inc. Service providing system, service providing server and information terminal device
CN109447646A (zh) * 2018-11-13 2019-03-08 华瓴(南京)信息技术有限公司 一种电力交易系统中身份隐私保护方法及系统

Also Published As

Publication number Publication date
WO2003105096A3 (fr) 2004-03-18
AU2003240217A1 (en) 2003-12-22

Similar Documents

Publication Publication Date Title
EP1442557B1 (fr) Systeme et procede pour creer un reseau securise en utilisant des justificatifs d'identite de lots de dispositifs
BE1016139A3 (fr) Systeme de marquage horodate pour documents electroniques, et support de programme pour celui-ci.
EP0763803B1 (fr) Système de comptabilisation anonyme d'informations à des fins statistiques, notamment pour des opérations de vote électronique ou de relevés périodiques de consommation
EP3222025B1 (fr) Procédé de contrôle d'accès a un système de production d'un système informatique non connecté à un système d'information dudit système informatique
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
FR2978891A1 (fr) Procede, serveur et systeme d'authentification d'une personne
EP3375133A1 (fr) Procede de securisation et d'authentification d'une telecommunication
EP3707669A1 (fr) Procédé d'obtention d'une identité numérique de niveau de sécurité élevé
EP3588418A1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant
FR3070516B1 (fr) Procede d'authentification d'un utilisateur aupres d'un serveur d'authentification
EP1949590A1 (fr) Procede de depot securise de donnees numeriques, procede associe de recuperation de donnees numeriques, dispositifs associes pour la mise en uvre des procedes, et systeme comprenant les dits dispositifs
EP0172047B1 (fr) Procédé et système pour chiffrer et déchiffrer des informations transmises entre un dispositif émetteur et un dispositif récepteur
FR2730076A1 (fr) Procede d'authentification par un serveur du porteur d'un objet portatif a microprocesseur, serveur et objet portatif correspondants
EP1262860B1 (fr) Système et procédé d'authentification d'un utilisateur
WO2025125562A1 (fr) Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand
WO2010046168A1 (fr) Procédé de sécurisation des messages destinés à un terminal évolué dans une architecture distribuée
EP1992104B1 (fr) Authentification d'un dispositif informatique au niveau utilisateur
WO2002065411A2 (fr) Methode et systeme de securisation d'une transaction commerciale au moyen d'une carte a memoire
FR3038414A1 (fr) Procede et systeme de controle d'acces a un service via un media mobile.
WO2010133459A1 (fr) Procede de chiffrement de parties particulieres d' un document pour les utilisateurs privileges
EP1282090A1 (fr) Procédé et dispositif de sécurisation des transactions
EP1300747A1 (fr) Procédé d'apposition en ligne d'une pluralité de signatures numériques sur un document életronique
FR2971350A1 (fr) Procede et dispositif de connexion a un service distant depuis un dispositif hote
FR2763192A1 (fr) Procede de recuperation de cles mis en oeuvre pour un chiffrement fort de message

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ 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
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP