EP1794926A1 - Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme - Google Patents

Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme

Info

Publication number
EP1794926A1
EP1794926A1 EP05804306A EP05804306A EP1794926A1 EP 1794926 A1 EP1794926 A1 EP 1794926A1 EP 05804306 A EP05804306 A EP 05804306A EP 05804306 A EP05804306 A EP 05804306A EP 1794926 A1 EP1794926 A1 EP 1794926A1
Authority
EP
European Patent Office
Prior art keywords
public key
certificate
information
key
retrieve
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
EP05804306A
Other languages
German (de)
English (en)
Inventor
Laurent Frisch
Gilles Macario-Rat
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.)
Orange SA
Original Assignee
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Publication of EP1794926A1 publication Critical patent/EP1794926A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • the present invention relates to a system and a public key cryptographic method and a certification server, memories adapted for this system.
  • Public key cryptosystems include:
  • a computer entity capable of decrypting a message and / or signing with the aid of a private key corresponding to the public key
  • At least a first memory in which an electronic certificate of the public key signed by a certification authority is recorded, this certificate comprising information for retrieving the public key
  • At least one terminal capable of verifying the signature of the certificate and retrieving the public key from the information contained in the certificate before encrypting a message and / or verifying a signature using this public key.
  • the electronic certificate has a field in which the public key is stored in the clear. This electronic certificate is public and therefore transmitted to any terminal that requests it. This certificate is used by the terminals to verify that the public key it wishes to use is that corresponding to the private key used by the IT entity. However, there are situations where it is desirable that among all the terminals able to verify the signature of the electronic certificate only some of them, called below authorized terminals, can retrieve the public key. Cryptographic systems in which electronic public key certificates are used do not currently allow for restricting access to the public key contained in the certificate.
  • the invention aims to remedy this drawback by proposing a public key cryptographic system in which access to the public key is restricted to authorized terminals.
  • the subject of the invention is therefore a public key cryptographic system in which the information contained in the certificate is insufficient on its own to retrieve the public key to be used.
  • the system comprises at least a second memory in which additional information is recorded for retrieving the public key when used in combination with the information contained in the certificate, access to this additional information being reserved for a limited number of authorized terminals among all the terminals capable of verifying the signature of the certificate.
  • the additional information is reserved for a limited number of authorized terminals among all the terminals that can verify the signature of the electronic certificate.
  • the public key can only be retrieved by these authorized terminals, which limits the accessibility of this public key while using an electronic certificate public key.
  • Embodiments of this system may include one or more of the following features: the information contained in the certificate comprises a cryptogram of at least a portion of the public key, and the additional information includes a decryption key for decrypting the cryptogram, the information contained in the certificate includes an identifier of at least a part of the public key in a list, this list comprising several said at least one key part each associated with an identifier, and the additional information includes this list, the information contained in the certificate include the address of an authentication server to allow access to at least some of the additional information in response to the identification and / or
  • the information contained in the certificate include an identifier of a method of recovering additional information among several possible recovery methods, and the system comprises at least one list of recovery methods for finding the recovery method to be used depending on the identifier of the recovery process.
  • the subject of the invention is also a certification server of a certification authority, a memory comprising this electronic certificate and a memory containing the additional information used in the above system.
  • the invention also relates to a public key cryptographic method implemented in the system described above.
  • FIG. 1 is a schematic illustration of the architecture of a public key cryptosystem
  • FIG. 2 is a schematic illustration of an electronic public key certificate used in the system of FIG. 1
  • FIG. is a flowchart of a public key cryptographic process.
  • FIG. 1 represents a cryptographic system with a public key designated by the general reference 2.
  • This system 2 comprises a computer entity 4 able to decipher a message and / or to sign using a private key Pr (U) and terminals capable of encrypting a message and / or verifying a signature using a public key Pub (U) corresponding to the private key Pr (U).
  • Pub Pub
  • the entity 4 comprises in particular an electronic module 10 for decrypting a message and / or signature using the key Pr (U).
  • the module 10 is connected to a memory 12 containing the key Pr (U).
  • this memory 12 also includes the pub public key (U) and an electronic certificate C of the pub public key (U).
  • This certificate C is adapted so that terminals such as the terminal 6 can verify that the public key Pub (U) it wishes to use actually corresponds to the private key Pr (U) used by the entity 4.
  • the entity 4 is connected to the different terminals with which it is able to exchange encrypted messages via an information transmission network 16.
  • This network 15 is a local area network or a wide area network such as the Internet network.
  • the entity 4 is, for example, a computer server.
  • the certificate C of the entity 4 is shown in more detail in FIG. 2.
  • This certificate C comprises a location 20 comprising two fields 22 and 24 of information.
  • the field 22 is normally intended to contain an identifier of an encryption or decryption algorithm and the field 24 is normally intended to contain the plaintext public key to be used together with the algorithm identified by the field 22.
  • the exact content of the Field 22 and the Pub '(U) content of field 24, in the context of system 2, will be detailed later.
  • the certificate C also comprises other fields such as in particular: a field 26 intended to contain the identity of the possessor of the certificate C, that is to say here the identity of the entity 4 such as, for example, his name or his address on the network 16,
  • the certificate C contains a cryptographic signature 32 established by encrypting, for example, all or only some of the information contained in the preceding fields using a private key Pr (AC) of the certification authority.
  • This signature enables a terminal to verify the authenticity of the certificate and thus to have confidence in the information contained in this certificate and in particular in the information contained in the location 20.
  • the system 2 also comprises at least one certification server 40 of the certification authority that has established the certificate C.
  • the server 40 is associated with a memory 42 in which the key Pr (AC) used to sign the certificate C.
  • this memory 42 also includes the key Pub (U), a cryptographic key E (T) and a list 46 of several keys associating with each public key a unique identifier.
  • This list 46 includes in particular an identifier for the key Pub (U).
  • the key E (T) is, for example, a public key corresponding to a private key D (T) known and used only by the terminal 6.
  • the memory 42 also comprises a list 48 of methods for setting the content Pub '(U) of the field 24 and a list 49 of methods for retrieving the key Pub (U).
  • the list 48 includes an identifier Pi of the method.
  • the same identifier Pi is associated with the recovery method making it possible to retrieve the key Pub (U) from the content Pub '(U) established according to the procedure of establishment Pi.
  • the server 40 is connected to the network 16 to transmit through this network the certificates it has established.
  • the terminal 6 comprises a module 50 for encryption and / or signature verification capable of executing cryptographic algorithms.
  • this module 50 is associated with a memory 52 comprising the cryptographic algorithms used and the corresponding keys.
  • the memory 52 includes in particular a public key Pub (AC).
  • This memory 52 also includes additional information for retrieving the key Pub (U) when used together with the information contained in the certificate C.
  • the memory 52 here comprises, the key D (T), a list 56 of keys associating for each key identifier a public key and a list 58 of methods of recovery of the key Pub (U).
  • the list 56 is, for example, identical to the list 46.
  • the list 58 associates each recovery method with an identifier of this method.
  • This list 58 is, for example, identical to the list 49.
  • Access to the memory 52 is reserved for a limited number of authorized terminals such as, for example, the terminal 6, among all the terminals capable of verifying the signature of the certificate C.
  • the system 2 comprises a module 62 for restricting access to the additional information contained in the memory 52.
  • This module 62 is, for example, able to identify and / or authenticate a third party before authorizing access to the memory 52. illustration, this module 62 is implemented in the terminal 6 to, in particular, identify and authenticate the user of the terminal 6 before the module 50 can access the memory 52.
  • the system 2 comprises an identification and authentication server 70 connected to the network 16.
  • This server 70 is associated with a memory 72 containing the public key Pub (U).
  • the server 70 comprises a restriction module 74 able to identify and authenticate a terminal or a user before authorizing access to the Pub key. (U) contained in its memory 72.
  • the memory 72 comprises, for example, a list 76 of identifiers and authenticators of authorized terminals to which the key Pub (U) can be communicated.
  • the authenticator is, for example, a simple password.
  • the entity 4 transmits to the certification server 40 a request to obtain the certificate C for the public key Pub (U).
  • This request contains, for example, proof that the entity 4 has the private key Pr (U).
  • the entity 4 signs a message with its private key Pr (U).
  • This request contains other information identifying the entity 4, such as its name or address on the network 16.
  • the certification server 40 builds the certificate C. More specifically, the server 40 begins by checking, during a step 94, the proof transmitted by the entity 4. For example, the server 40 decrypts with the key Pub (U) the encrypted message using the key Pr (U) transmitted during the step 90. In the case where this verification is negative, the process s' stopped. In the opposite case, the server chooses, during a step 96, a method of establishing the information contained in the certificate C and more precisely the information contained in the element 20 of the certificate. This method of establishment is chosen, for example, from the list 48. By way of illustration, the list 48 comprises three methods Pi, P 2 and P 3 for setting the content Pub '(U) of the field 24.
  • the content Pub '(U) is obtained by encrypting the public key Pub (U) using the key E (T).
  • the content Pub '(U) is the identifier associated with the key Pub (U) in the list 46.
  • the content Pub '(U) is the address on the network 16 of the authentication server 70.
  • the other fields of the certificate are completed as recommended by the X.509 standard.
  • this method is executed in a step 98.
  • the certificate of the key Pub (U) is constructed, during a step 100, by completing the field 22 with the identifier Pi of the method of retrieving the key Pub (U) and the field 24 with the content Pub '(U).
  • the identifier Pi of the recovery method is here identical to the identifier Pi of the content establishment method Pub '(U).
  • the server 40 transmits, during a step 102, this certificate C to the entity 4 which stores it in its memory 12.
  • the entity 4 transmits, during a step 104, the certificate C to the terminal 6.
  • the terminal 6 saves it in a non-volatile memory , such as the memory 52, or in a volatile memory and checks, during a step 106, the signature of this certificate C. For this purpose, during step 106, the terminal 6 decrypts the signature 32 to the using the Pub Key (AC). If this check is negative, that is, the certificate C is not authenticated, then the process stops. In the opposite case, the terminal 6 proceeds to a phase 110 of recovery of the public key Pub (U).
  • Pub Pub
  • the terminal 6, during a step 112 identifies the method of recovery of the key Pub (U) to be used by using the content of the field 22 of the certificate C.
  • the terminal 6 extracts the content Pub '(U) of the field 24. Then, the terminal 6 accesses, during a step 116, the additional information necessary to obtain the key Pub (U) from the content Pub '(U).
  • the module 62 checks, during an operation 128, whether the conditions for accessing the memory 52 are met. For example, access to the memory 52 is allowed only if the user of the terminal 6 is correctly identified and authenticated.
  • the terminal 6 connects, during an operation 122, to the authentication server identified by the address contained in the field 24. Here, it is assumed that this address is that of the identification and authentication server 70. Then, during an operation 124, the terminal 6 transmits to the server 70 the information to identify and authenticate.
  • the module 74 checks, during a step 126, whether the identification and authentication information transmitted by the terminal 4 corresponds to identification and authentication information contained in the list 76. If so, the module 74 allows access to the additional information constituted here by the key Pub (U) stored in the memory 72. In the opposite case, the process stops.
  • the terminal 6 uses, in a step 130, the additional information to retrieve the key Pub (U). More precisely, during this step 130, if the identifier of the recovery method is P 1 , the terminal 6 decrypts, during an operation 132, the content Pub '(U) using the key D (T ).
  • the terminal 6 retrieves, during an operation 134, the key Pub (U) in the list 56 using this identifier.
  • the terminal 6 retrieves, during an operation 136, the key Pub (U) stored in the memory 72 of the server 70.
  • the terminal 6 uses it to encrypt a message and / or verify the signature of the entity 4. For example, during a step 140, the terminal encrypts a message transmitted to the entity 4 by means of the key Pub (U) then, during a step 142, the entity 4 decrypts this message using the key Pr (U).
  • the entity 4 transmits to the terminal 6 a signature established using the key Pr (U) and the terminal 6 verifies this signature, during the step 142, to the using the Pub key (U).
  • the key Pub (U) thus recovered can also be used to authenticate the entity 4 during information exchanges between the terminal 6 and the entity 4. For example, the terminal 6 transmits a random number to the entity 4 who numbers it or signs it using, the key
  • the terminal 6 decrypts the cryptogram transmitted using the public key Pub (U) to authenticate the entity 4.
  • certificate C is public, that is, it can be obtained by many terminals and many terminals of system 2 are able to verify the signature of this system. certificate, only authorized terminals can retrieve the public key from the information contained in this certificate. For unauthorized terminals, that is to say those who do not have access to the additional information, the certificate C is unusable to recover the key Pub (U). Thus, in the system 2, access to the pub public key (U) is restricted, although a public key certificate is used.
  • the keys E (T) and D (T) can be replaced by symmetric keys.
  • the restriction software module 62 may be replaced by a mechanical memory access restriction module 52.
  • the memory 52 may only be accessible from the terminal 6. This will, for example, be the case if the terminal 6 is a computer and if the memory 52 corresponds to a non-shared portion of the hard disk of this computer.
  • the certificate is stored in a memory 12 associated with the entity 4, then transmitted via the network 16 to the terminal 6.
  • the certificate C is stored in a removable memory such as, for example , the memory of a smart card, and it is this removable memory that is transmitted to the terminal 6 when it wishes to communicate with the entity 4.
  • the certificate C can also be registered in a directory available to all terminals so that in this variant, step 104 of the method is replaced by a step of consulting this directory.
  • the list 58 of recovery methods has been described as part of the additional information whose access is reserved for authorized terminals.
  • this list 58 is stored in a memory freely accessible by all authorized or unauthorized terminals of the system 2.
  • the content Pub '(U) can be formed by the concatenation of several cryptograms of the key Pub (U) respectively obtained using keys E (T 1 ), E (T 2 ), ..., the keys E (Ti) being respective cryptographic keys of the authorized terminals T 1 , T 2 , ....
  • the content Pub '(U) may be formed of a cryptogram A of the key Pub (U) obtained using a key K and cryptograms Ki obtained by encrypting the key K using keys E (Tj . ) specific to each authorized terminal Ti.
  • the content Pub '(U) will preferably conform to the PKCS # 7 / CMS standard.
  • the identifier of the key Pub (U) has been described as being predefined in a list 46.
  • this identifier is dynamically created by the authentication server when the certificate is created. C and the authentication server is able to update the list 56 of the terminal 6 so that it includes the dynamically created identifier associated with the public key Pub (U).
  • the authentication server uses, alternatively, as identifier of the key Pub (U) one or more of information contained in the other fields of the certificate such as, for example, the serial number of the certificate.
  • the field 22 contains the identifier P 2 and the field 24 is empty since, for example, the serial number of the certificate is already contained in the field 30.
  • the server 70 has been described as being separate from the server 40. In a variant, these two servers are merged.
  • the server 70 is, alternatively, either only able to identify a terminal or only able to authenticate a terminal.
  • System 2 has been described in the particular case where three methods of recovering the key Pub (U) can be used. Alternatively, only one or two of these recovery methods are used. The elements corresponding to the unused recovery methods are then deleted from the system 2. In particular, in the case where a single recovery method is used in the system 2, the step 96 may be deleted and the recovery phase 110 may be simplified. Finally, the system 2 has been described in the particular case where all the additional information necessary to recover the key Pub (U) by implementing a recovery process Pi are recorded in a single location. As a variant, the additional information to be used during the execution of a recovery method Pi is distributed in different memories protected by different access restriction modules.
  • the recovery methods Pi described here can also be combined.
  • the key Pub (U) is split into first and second parts.
  • the first part is encrypted using the key E (T) and the second part is stored in the memory 72 of the authentication server 70.
  • the content Pub '(U) is then formed by the cryptogram of the first part of the key and by the address of the authentication server.
  • the content Pub '(U) can also be formed by an identifier of the first part of the key Pub (U) in a list stored in the memory 52 and by the address of an authentication server able to authorize the access to the second part of the Pub key (U).
  • the memories described here may also be particular areas of larger information storage means.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Dans ce système cryptographique à clé publique, les informations contenues dans un certificat électronique de la clé publique sont insuffisantes à elles seules pour récupérer la clé publique. Le système comporte au moins une deuxième mémoire (52, 72) dans laquelle sont enregistrées des informations complémentaires permettant de récupérer la clé publique lorsqu'elles sont utilisées en combinaison avec les informations contenues dans le certificat, l'accès à ces informations complémentaires étant réservé à un nombre limité de terminaux autorisés parmi l'ensemble des terminaux susceptibles de vérifier la signature du certificat.

Description

SYSTEME ET PROCEDE CRYPTOGRAPHIQUE A CLE PUBLIQUE ET SERVEUR DE CERTIFICATION, MEMOIRES ADAPTEES POUR CE SYSTEME
La présente invention concerne un système et un procédé cryptographique à clé publique et un serveur de certification, des mémoires adaptées pour ce système.
Les systèmes cryptographiques à clé publique comportent :
- une entité informatique propre à déchiffrer un message et/ou à signer à l'aide d'une clé privée correspondant à la clé publique,
- au moins une première mémoire dans laquelle est enregistré un certificat électronique de la clé publique signé par une autorité de certification, ce certificat comportant des informations pour récupérer la clé publique, et
- au moins un terminal apte à .vérifier la signature du certificat et à récupérer la clé publique à partir des informations contenues dans le certificat avant de chiffrer un message et/ou de vérifier une signature à l'aide de cette clé publique.
Dans les systèmes cryptographiques à clé publique connus, le certificat électronique comporte un champ dans lequel est enregistré la clé publique en clair. Ce certificat électronique est public et donc transmis à tout terminal qui en fait la demande. Ce certificat est utilisé par les terminaux pour vérifier que ia clé publique qu'il souhaite utiliser est bien celle correspondant à la clé privée utilisée par l'entité informatique. Toutefois, il existe des situations où il est souhaitable que parmi l'ensemble des terminaux aptes à vérifier la signature du certificat électronique seuls certains d'entre eux, appelés ci-dessous terminaux autorisés, puissent récupérer la clé publique. Les systèmes cryptographiques dans lesquels des certificats électroniques de clé publique sont utilisés ne permettent pas actuellement de restreindre l'accès à la clé publique contenue dans le certificat.
L'invention vis à remédier à cet inconvénient en proposant un système cryptographique à clé publique dans lequel l'accès à la clé publique est restreint à des terminaux autorisés. L'invention a donc pour objet un système cryptographique à clé publique dans lequel les informations contenues dans le certificat sont insuffisantes à elles seules pour récupérer la clé publique à utiliser. Le système comporte au moins une deuxième mémoire dans laquelle sont enregistrées des informations complémentaires permettant de récupérer la clé publique lorsqu'elles sont utilisées en combinaison avec les informations contenues dans le certificat, l'accès à ces informations complémentaires étant réservé à un nombre limité de terminaux autorisés parmi l'ensemble des terminaux susceptibles de vérifier la signature du certificat.
Dans le système ci-dessus, seuls les terminaux autorisés ont accès aux informations complémentaires et peuvent donc récupérer la clé publique. Les informations complémentaires sont réservées à un nombre limité de terminaux autorisés parmi l'ensemble des terminaux susceptibles de vérifier la signature du certificat électronique. Ainsi, la clé publique ne peut être récupérée que par ces terminaux autorisés, ce qui restreint l'accessibilité de cette clé publique tout en utilisant un certificat électronique de clé publique.
Les modes de réalisation de ce système peuvent comporter une ou plusieurs des caractéristiques suivantes : les informations contenues dans le certificat comportent un cryptogramme d'au moins une partie de la clé publique, et les informations complémentaires comportent une clé de déchiffrement permettant de déchiffrer le cryptogramme, les informations contenues dans le certificat comportent un identifiant d'au moins une partie de la clé publique dans une liste, cette liste comportant plusieurs dites au moins une partie de clé associée chacune à un identifiant, et les informations complémentaires comportent cette liste, les informations contenues dans le certificat comportent l'adresse d'un serveur d'authentification propre à autoriser l'accès à au moins une partie des informations complémentaires en réponse à l'identification et/ou
1' authentification correcte d'un terminal, les informations contenues dans le certificat comportent un identifiant d'un procédé de récupération des informations complémentaires parmi plusieurs procédés de récupération possibles, et le système comporte au moins une liste de procédés de récupération permettant de retrouver le procédé de récupération à utiliser en fonction de l'identifiant du procédé de récupération.
L'invention a également pour objet un serveur de certification d'une autorité de certification, une mémoire comportant ce certificat électronique et une mémoire comportant les informations complémentaires utilisées dans le système ci-dessus.
L'invention a également pour objet un procédé cryptographique à clé publique mis en œuvre dans le système décrit ci-dessus.
L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins sur lesquels :
- la figure 1 est une illustration schématique de l'architecture d'un système cryptographique à clé publique, - la figure 2 est une illustration schématique d'un certificat électronique de clé publique utilisé dans le système de la figure 1, et la figure 3 est un organigramme d'un procédé cryptographique à clé publique. La figure 1 représente un système cryptographique à clé publique désigné par la référence générale 2. Ce système 2 comporte une entité informatique 4 propre à déchiffrer un message et/ou à signer à l'aide d'une clé privée Pr(U) et des terminaux aptes à chiffrer un message et/ou à vérifier une signature à l'aide d'une clé publique Pub(U) correspondant à la clé privée Pr(U) . Pour simplifier l'illustration, seul un terminal 6 a été représenté.
L'entité 4 comporte notamment un module électronique 10 de déchiffrement d'un message et/ou de signature à l'aide de la clé Pr(U) . A cet effet, le module 10 est connecté à une mémoire 12 contenant la clé Pr(U) .
Ici, cette mémoire 12 comporte également la clé publique Pub(U) ainsi qu'un certificat électronique C de la clé publique Pub(U) . Ce certificat C est adapté pour que des terminaux tels que le terminal 6 puisse vérifier que la clé publique Pub (U) qu'il souhaite utiliser correspond effectivement à la clé privée Pr(U) utilisée par l'entité 4.
L'entité 4 est raccordée aux différents terminaux avec lesquels elle est susceptible d'échanger des messages chiffrés par l'intermédiaire d'un réseau 16 de transmission d'informations. Ce réseau 15 est un réseau local ou un réseau grande distance tel que le réseau Internet.
L'entité 4 est, par exemple, un serveur informatique. Le certificat C de l'entité 4 est représenté plus en détails sur la figure 2. Ce certificat C comporte un emplacement 20 comportant deux champs 22 et 24 d'informations. Le champ 22 est normalement destiné à contenir un identifiant d'un algorithme de chiffrement ou de déchiffrement et le champ 24 est normalement destiné à contenir la clé publique en clair à utiliser conjointement avec l'algorithme identifié par le champ 22. Le contenu exact du champ 22 et le contenu Pub' (U) du champ 24, dans le contexte du système 2, seront détaillés plus loin. Le certificat C comporte également d' autres champs tels que notamment : un champ 26 destiné à contenir l'identité du possesseur du certificat C, c'est-à-dire ici l'identité de l'entité 4 tel que, par exemple, son nom ou son adresse sur le réseau 16,
- un champ 22 destiné à contenir une période de validité pour le certificat C,
- un champ 30 contenant le numéro de série du certificat, ce numéro de série étant attribué par l'autorité de certification et étant unique.
Enfin, le certificat C contient une signature cryptographique 32 établie en chiffrant, par exemple, la totalité ou uniquement certaines des informations contenues dans les champs précédents à l'aide d'une clé privée Pr(AC) de l'autorité de certification. Cette signature permet à un terminal de vérifier l'authenticité du certificat et donc d'avoir confiance dans les informations contenues dans ce certificat et notamment dans les informations contenues dans l'emplacement 20.
Ici, la structure de ce certificat est conforme à la norme X.509 de l'IETF (Internet Engineering Task Force) RFC3280, utilisée sur le réseau Internet. Le système 2 comporte également au moins un serveur de certification 40 de l'autorité de certification ayant établi le certificat C. A cet effet, le serveur 40 est associé à une mémoire 42 dans laquelle est enregistré la clé Pr(AC) ayant servi à signer le certificat C.
Ici, à titre d'exemple, cette mémoire 42 comporte également la clé Pub (U) , une clé cryptographique E(T) et une liste 46 de plusieurs clés associant à chaque clé publique un identifiant unique. Cette liste 46 comporte notamment un identifiant pour la clé Pub (U) . La clé E(T) est, par exemple, une clé publique correspondant à une clé privée D(T) connue et utilisée uniquement par le terminal 6.
La mémoire 42 comporte également une liste 48 de procédés d'établissement du contenu Pub' (U) du champ 24 et une liste 49 de procédés de récupération de la clé Pub(U) . Pour chaque procédé d'établissement, la liste 48 comporte un identifiant Pi du procédé. Dans la liste 49, le même identifiant Pi est associé au procédé de récupération permettant de récupérer la clé Pub (U) à partir du contenu Pub' (U) établi selon la procédure d'établissement Pi.
Le serveur 40 est raccordé au réseau 16 pour transmettre par l'intermédiaire de ce réseau les certificats qu'il a établis. Le terminal 6 comporte un module 50 de chiffrement et/ou de vérification de signature apte à exécuter des algorithmes cryptographiques. A cet effet, ce module 50 est associé à une mémoire 52 comportant les algorithmes cryptographiques utilisés ainsi que les clés correspondantes. Par exemple, ici, la mémoire 52 comporte notamment une clé publique Pub (AC) . Cette mémoire 52 comporte également des informations complémentaires permettant de récupérer la clé Pub (U) lorsqu'elles sont utilisées conjointement avec les informations contenues dans le certificat C. La mémoire 52 comporte ici, la clé D(T), une liste 56 de clés associant pour chaque identifiant de clés une clé publique et une liste 58 de procédés de récupération de la clé Pub (U) . La liste 56 est, par exemple, identique à la liste 46. La liste 58 associe chaque procédé de récupération à un identifiant de ce procédé. Cette liste 58 est, par exemple, identique à la liste 49.
L'accès à la mémoire 52 est réservé à un nombre limité de terminaux autorisés tel que, par exemple, le terminal 6, parmi l'ensemble des terminaux susceptibles de vérifier la signature du certificat C. A cet effet, le système 2 comporte un module 62 de restriction d' accès aux informations complémentaires contenues dans la mémoire 52. Ce module 62 est, par exemple, apte à identifier et/ou authentifier un tiers avant d'autoriser l'accès à la mémoire 52. Ici, à titre d'illustration, ce module 62 est implémenté dans le terminal 6 pour, notamment, identifier et authentifier l'utilisateur du terminal 6 avant que le module 50 ne puisse accéder à la mémoire 52.
Enfin, le système 2 comporte un serveur 70 d'identification et d' authentification raccordé au réseau 16. Ce serveur 70 est associé à une mémoire 72 contenant la clé publique Pub (U) . De manière à restreindre l'accès à cette clé Pub (U) uniquement aux terminaux autorisés, le serveur 70 comporte un module 74 de restriction propre à identifier et à authentifier un terminal ou un utilisateur avant d'autoriser l'accès à la clé Pub (U) contenue dans sa mémoire 72. Pour cela, la mémoire 72 comporte, par exemple, une liste 76 d'identifiants et d'authentifiants des terminaux autorisés auxquels la clé Pub (U) peut être communiquée. L'authentifiant est, par exemple, un simple mot de passe. Le fonctionnement du système 2 va maintenant être décrit en regard du procédé de la figure 3.
Initialement, lors d'une étape 90, l'entité 4 transmet au serveur de certification 40 une demande afin d'obtenir le certificat C pour la clé publique Pub (U) . Cette demande contient, par exemple, une preuve que l'entité 4 possède la clé privée Pr(U) . A cet effet, par exemple, l'entité 4 signe un message avec sa clé privée Pr(U) . Cette demande contient d'autres informations permettant d'identifier l'entité 4, tel que son nom ou son adresse sur le réseau 16.
En réponse à cette demande, lors d'une phase 92 le serveur de certification 40 construit le certificat C. Plus précisément, le serveur 40 commence par vérifier, lors d'une étape 94 la preuve transmise par l'entité 4. Par exemple, le serveur 40 déchiffre à l'aide de la clé Pub (U) le message chiffré à l'aide de la clé Pr(U) transmis lors de l'étape 90. Dans le cas où cette vérification est négative, le procédé s'arrête. Dans le cas contraire, le serveur choisit, lors d'une étape 96, un procédé d'établissement des informations contenues dans le certificat C et plus précisément des informations contenues dans l'élément 20 du certificat. Ce procédé d'établissement est choisi, par exemple, dans la liste 48. A titre d'illustration, la liste 48 comporte trois procédés Pi, P2 et P3 d'établissement du contenu Pub' (U) du champ 24.
Selon le procédé Pi, le contenu Pub' (U) est obtenu en chiffrant la clé publique Pub (U) à l'aide de la clé E(T) . Selon le procédé P2, le contenu Pub' (U) est l'identifiant associé à la clé Pub (U) dans la liste 46.
Enfin, selon le procédé P3, le contenu Pub' (U) est l'adresse sur le réseau 16 du serveur d' authentification 70. Quel que soit le procédé d'établissement choisi, les autres champs du certificat sont complétés comme préconisé par la norme X.509.
Une fois le procédé d'établissement de Pub' (U) choisi, ce procédé est exécuté lors d'une étape 98.
A l'issue de l'étape 98, le certificat de la clé Pub (U) est construit, lors d'une étape 100, en complétant le champ 22 avec l'identifiant Pi du procédé de récupération de la clé Pub (U) et le champ 24 avec le contenu Pub' (U) . L'identifiant Pi du procédé de récupération est, ici identique à l'identifiant Pi du procédé d'établissement du contenu Pub' (U) .
Une fois la phase 92 de construction du certificat terminée, le serveur 40 transmet, lors d'une étape 102, ce certificat C à l'entité 4 qui le mémorise dans sa mémoire 12.
Lors d'un échange d'informations chiffrées entre le terminal 6 et l'entité 4, l'entité 4 transmet, lors d'une étape 104, le certificat C au terminal 6. Le terminal 6 l'enregistre dans une mémoire non volatile, telle que la mémoire 52, ou dans une mémoire volatile et vérifie, lors d'une étape 106, la signature de ce certificat C. A cet effet, lors de l'étape 106, le terminal 6 déchiffre la signature 32 à l'aide de la clé Pub (AC) . Si cette vérification est négative, c'est-à-dire que le certificat C n'est pas authentifié, alors le procédé s'arrête. Dans le cas contraire, le terminal 6 procède à une phase 110 de récupération de la clé publique Pub (U) .
Au début de la phase 110, le terminal 6, lors d'une étape 112, identifie le procédé de récupération de la clé Pub (U) à utiliser en utilisant le contenu du champ 22 du certificat C.
Ensuite, lors d'une étape 114, le terminal 6 extrait le contenu Pub' (U) du champ 24. Puis, le terminal 6 accède, lors d'une étape 116, aux informations complémentaires nécessaires pour obtenir la clé Pub(U) à partir du contenu Pub' (U) .
Dans le cas où l'identifiant du procédé de récupération est Pi ou P2, le module 62 vérifie, lors d'une opération 128, si les conditions pour accéder à la mémoire 52 sont remplies. Par exemple, l'accès à la mémoire 52 est autorisé uniquement si l'utilisateur du terminal 6 est correctement identifié et authentifié. Dans le cas où l'identifiant du procédé de récupération est P3, le terminal 6 se connecte, lors d'une opération 122, au serveur d' authentification identifié par l'adresse contenue dans le champ 24. Ici, on suppose que cette adresse est celle du serveur d'identification et d'authentification 70. Ensuite, lors d'une opération 124, le terminal 6 transmet au serveur 70 les informations permettant de l'identifier et de l'authentifier. Le module 74 vérifie, lors d'une étape 126, si les informations d'identification et d'authentification transmises par le terminal 4 correspondent à des informations d'identification et d'authentification contenues dans la liste 76. Dans l'affirmative, le module 74 autorise l'accès aux informations complémentaires constituées ici par la clé Pub (U) enregistrée dans la mémoire 72. Dans le cas contraire, le procédé s'arrête.
Une fois que le terminal 6 a été autorisé à accéder aux informations complémentaires, celui-ci utilise, lors d'une étape 130, les informations complémentaires pour récupérer la clé Pub (U) . Plus précisément, lors de cette étape 130, si l'identifiant du procédé de récupération est P1, le terminal 6 déchiffre, lors d'une opération 132, le contenu Pub' (U) à l'aide de la clé D(T) .
Si l'identifiant du procédé de récupération est P2, le contenu Pub' (U) correspond à un identifiant de la clé Pub(U) dans la liste 56. Dés lors, le terminal 6 récupère, lors d'une opération 134, la clé Pub (U) dans la liste 56 en utilisant cet identifiant.
Si l'identifiant du procédé de récupération est P3, le terminal 6 récupère, lors d'une opération 136, la clé Pub (U) enregistrée dans la mémoire 72 du serveur 70.
Une fois que la clé Pub (U) a été récupérée, le terminal 6 l'utilise pour chiffrer un message et/ou vérifier la signature de l'entité 4. Par exemple, lors d'une étape 140, le terminal chiffre un message transmis vers l'entité 4 à l'aide de la clé Pub (U) puis, lors d'une étape 142, l'entité 4 déchiffre ce message à l'aide de la clé Pr(U) .
En variante, lors de l'étape 140, l'entité 4 transmet au terminal 6 une signature établie à l'aide de la clé Pr(U) et le terminal 6 vérifie cette signature, lors de l'étape 142, à l'aide de la clé Pub (U) .
La clé Pub (U) ainsi récupérée peut également être utilisée pour authentifier l'entité 4 lors d'échanges d'informations entre le terminal 6 et l'entité 4. Par exemple, le terminal 6 transmet un nombre aléatoire à l'entité 4 qui le chiffre ou le signe à l'aide, de la clé
Pr(U) et renvoi le cryptogramme ainsi établi au terminal 6.
Le terminal 6 déchiffre le cryptogramme transmis à l'aide de la clé publique Pub(U) pour authentifier l'entité 4.
D'autres utilisations de la clé publique sont possibles.
Dans le système 2 ci-dessus, bien que le certificat C soit public, c'est-à-dire qu'il puisse être obtenu par de nombreux terminaux et que de nombreux terminaux du système 2 soient capables de ' vérifier la signature de ce certificat, seuls les terminaux autorisés peuvent récupérer la clé publique à partir des informations contenues dans ce certificat. Pour les terminaux non autorisés, c'est-à-dire ceux qui n'ont pas accès aux informations complémentaires, le certificat C est inutilisable pour récupérer la clé Pub (U) . Ainsi, dans le système 2, l'accès à la clé publique Pub (U) est restreint, bien qu'un certificat de clé public soit utilisé.
Dans le système décrit ci-dessus, la structure du certificat électronique n'est pas modifiée de sorte qu'il est possible de se conformer aux normes actuelles sur les certificats électroniques. Il est donc possible de mettre en œuvre le procédé décrit ci-dessus tout en utilisant des protocoles standards d'utilisation de certificats électroniques comme, par exemple, le protocole SSL/TLS de l'IETF RFC2246, S/MIME de l' IETF RFC3851, ou encore PKCS qui est l'un des standards privés issu de RSA Security (voir http: //www.rsasecurity. com/rsalabs/node. asp?id=2124) . Ceci limite les coûts de mise en œuvre du système 2.
De nombreux autres modes de réalisation du système 2 sont possibles. Par exemple, les clés E(T) et D(T) peuvent être remplacées par des clés symétriques. Le module logiciel de restriction 62 peut être remplacé par un module mécanique de restriction de l'accès à la mémoire 52. Par exemple, la mémoire 52 peut être uniquement accessible à partir du terminal 6. Ceci sera, par exemple, le cas si le terminal 6 est un ordinateur et si la mémoire 52 correspond à une portion non partagée du disque dur de cet ordinateur.
Dans le système 2, le certificat est enregistré dans une mémoire 12 associée à l'entité 4, puis transmis par l'intermédiaire du réseau 16 au terminal 6. En variante, le certificat C est enregistré dans une mémoire amovible telle que, par exemple, la mémoire d'une carte à puce, et c'est cette mémoire amovible qui est transmise au terminal 6 lorsque celui-ci souhaite communiquer avec l'entité 4. Le certificat C peut également être enregistré dans un annuaire consultable par tous les terminaux de sorte que dans cette variante, l'étape 104 du procédé est remplacée par une étape de consultation de cet annuaire.
Ici, la liste 58 des procédés de récupération a été décrite comme faisant partie des informations complémentaires dont l'accès est réservé aux terminaux autorisés. En variante, cette liste 58 est enregistrée dans une mémoire librement accessible par tous les terminaux autorisés ou non du système 2. Dans le cas du procédé de récupération Pi, le contenu Pub' (U) peut être formé par la concaténation de plusieurs cryptogrammes de la clé Pub (U) obtenus respectivement à l'aide de clés E(T1), E(T2) ,..., les clés E (Ti) étant des clés cryptographiques respectives des terminaux autorisés T1, T2,....
Toujours dans le cas du procédé de récupération P1, le contenu Pub' (U) peut être formé d'un cryptogramme A de la clé Pub (U) obtenu à l'aide d'une clé K et de cryptogrammes Ki obtenus en chiffrant la clé K à l'aide de clés E (Tj.) propres à chacun des terminaux autorisés Ti. Dans cette variante, le contenu Pub' (U) sera de préférence conforme à la norme PKCS#7/CMS.
Dans le cas du procédé de récupération P2, l'identifiant de la clé Pub (U) a été décrit comme étant prédéfini dans une liste 46. En variante cet identifiant est créé dynamiquement par le serveur d' authentification lors de la création du certificat C et le serveur d' authentification est apte à mettre à jour la liste 56 du terminal 6 pour que celle-ci comporte l'identifiant dynamiquement créé associé à la clé publique Pub (U) .
Toujours dans le cas du procédé de récupération P2, plutôt que de créer un identifiant, le serveur d' authentification utilise, en variante, en tant qu'identifiant de la clé Pub (U) une ou plusieurs des informations contenues dans les autres champs du certificat tel que, par exemple, le numéro de série du certificat. Dans cette variante, le champ 22 contient l'identifiant P2 et le champ 24 est vide puisque, par exemple, le numéro de série du certificat est déjà contenu dans le champ 30.
Dans le cas du procédé de récupération P3, le serveur 70 a été décrit comme étant distinct du serveur 40. En variante, ces deux serveurs sont confondus. Le serveur 70 est, en variante, soit uniquement apte à identifier un terminal soit uniquement apte à authentifier un terminal.
Le système 2 a été décrit dans le cas particulier où trois procédés de récupération de la clé Pub (U) peuvent être utilisés. En variante, seul un ou deux de ces procédés de récupération sont utilisés. Les éléments correspondants aux procédés de récupération non utilisés sont alors supprimés du système 2. En particulier, dans le cas où un seul procédé de récupération est utilisé dans le système 2, l'étape 96 peut être supprimée et la phase 110 de récupération peut être simplifiée. Enfin, le système 2 a été décrit dans le cas particulier où l'ensemble des informations complémentaires nécessaires pour récupérer la clé Pub (U) en mettant en œuvre un procédé de récupération Pi sont enregistrées dans un seul emplacement. En variante, les informations complémentaires à utiliser lors de l'exécution d'un procédé Pi de récupération sont répartis dans différentes mémoires protégées par des modules de restriction d'accès différents.
Les procédés de récupération Pi décrits ici, peuvent également être combinés. Par exemple, la clé Pub (U) est scindée en une première et une seconde parties. La première partie est chiffrée à l'aide de la clé E(T) et la seconde partie est enregistrée dans la mémoire 72 du serveur d'authentification 70. Le contenu Pub' (U) est alors formé par le cryptogramme de la première partie de la clé et par l'adresse du serveur d' authentification. Le contenu Pub' (U) peut également être formé par un identifiant de la première partie de la clé Pub (U) dans une liste enregistrée dans la mémoire 52 et par l'adresse d'un serveur d' authentification propre à autoriser l'accès à la seconde partie de la clé Pub (U) .
Les mémoires décrites ici peuvent être aussi des zones particulières de moyens de stockage d' informations plus grands.

Claims

REVENDICATIONS
1. Système cryptographique à clé publique comportant :
- une entité informatique (4) propre à déchiffrer un message et/ou à signer à l'aide d'une clé privée correspondant à la clé publique,
- au moins une première mémoire (12) dans laquelle est enregistré un certificat électronique de la clé publique signé par une autorité de certification, ce certificat comportant des informations pour récupérer la clé publique, et
- au moins un terminal (6) apte à vérifier la signature du certificat et à récupérer la clé publique à partir des informations contenues dans le certificat avant de chiffrer un message et/ou de vérifier une signature à l'aide de cette clé publique, caractérisé :
- en ce que les informations contenues dans le certificat sont insuffisantes à elles seules pour récupérer la clé publique à utiliser, et - en ce que le système comporte au moins une deuxième mémoire (52, 72) dans laquelle sont enregistrées des informations complémentaires permettant de récupérer la clé publique lorsqu' elles sont utilisées en combinaison avec les informations contenues dans le certificat, l'accès à ces informations complémentaires étant réservé à un nombre limité de terminaux autorisés parmi l'ensemble des terminaux susceptibles de vérifier la signature du certificat.
2. Système selon la revendication 1, caractérisé en ce que les informations contenues dans le certificat comportent un cryptogramme d'au moins une partie de la clé publique, et en ce que les informations complémentaires comportent une clé de déchiffrement permettant de déchiffrer le cryptogramme.
3. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que les informations contenues dans le certificat comportent un identifiant d' au moins une partie de la clé publique, dans une liste, cette liste comportant plusieurs dites au moins une partie de clé associée chacune à un identifiant, et en ce que les informations complémentaires comportent cette liste.
4. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que les informations contenues dans le certificat comportent l'adresse d'un serveur d' authentification (70) propre à autoriser l'accès à au moins une partie des informations complémentaires en réponse à l'identification et/ou l' authentification correcte d'un terminal.
5. Système selon l'une quelconque des revendications précédentes, caractérise en""~ "" 'que "Tes"" informations" contenues dans le certificat comportent un identifiant d'un procédé de récupération des informations complémentaires parmi plusieurs procédés de récupération possibles, et en ce que le système comporte au moins une liste de procédés de récupération permettant de retrouver le procédé de récupération à utiliser en fonction de l'identifiant du procédé de récupération.
6. Serveur de certification d'une autorité de certification, caractérisé en ce qu'il est apte à générer un certificat électronique d'une clé publique adapté pour être utilisé dans un système conforme à l'une quelconque des revendications précédentes, ce certificat électronique comportant des informations pour récupérer la clé publique et les informations contenues dans ce certificat étant insuffisantes à elles seules pour récupérer la clé publique.
7. Mémoire comportant un certificat électronique adapté pour être utilisé dans un système cryptographique à clé publique conforme à l'une quelconque des revendications l à 5, caractérisée en ce que le certificat électronique comporte des informations pour récupérer la clé publique, et en ce que ces informations sont insuffisantes à elles seules pour récupérer la clé publique.
8. Mémoire adaptée pour être utilisée dans un système cryptographique conforme à l'une quelconque des revendications 1 à 5, caractérisée en ce qu'elle comporte des informations complémentaires permettant de retrouver la clé publique lorsqu'elles sont utilisées en combinaison avec les informations contenues dans le certificat.
9. Procédé cryptographique à clé publique adapté pour être mis en œuvre dans un système cryptographique à clé publique conforme à l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte une étape d'utilisation des informations complémentaires prises en combinaison avec les informations contenues dans le certificat pour récupérer la clé publique.
10. Certificat électronique adapté pour être utilisé dans un système cryptographique à clé publique conforme à l'une quelconque des revendications 1 à 5, caractérisée en ce que le certificat électronique comporte des informations pour récupérer la clé publique, et en ce que ces informations sont insuffisantes à elles seules pour récupérer la clé publique.
EP05804306A 2004-09-29 2005-09-28 Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme Withdrawn EP1794926A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0410307A FR2875977A1 (fr) 2004-09-29 2004-09-29 Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
PCT/FR2005/002396 WO2006035159A1 (fr) 2004-09-29 2005-09-28 Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme

Publications (1)

Publication Number Publication Date
EP1794926A1 true EP1794926A1 (fr) 2007-06-13

Family

ID=34950358

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05804306A Withdrawn EP1794926A1 (fr) 2004-09-29 2005-09-28 Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme

Country Status (4)

Country Link
US (1) US20080159543A1 (fr)
EP (1) EP1794926A1 (fr)
FR (1) FR2875977A1 (fr)
WO (1) WO2006035159A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8494168B1 (en) * 2008-04-28 2013-07-23 Netapp, Inc. Locating cryptographic keys stored in a cache
US20100115261A1 (en) * 2008-11-06 2010-05-06 International Business Machines Corporation Extensible seal management for encrypted data
US10475024B1 (en) 2012-10-15 2019-11-12 Square, Inc. Secure smart card transactions
US9760740B1 (en) 2014-06-23 2017-09-12 Square, Inc. Terminal case with integrated dual reader stack
US10108947B2 (en) * 2014-07-31 2018-10-23 Square, Inc. Smart card reader with public key index on host device
US10753982B2 (en) 2014-12-09 2020-08-25 Square, Inc. Monitoring battery health of a battery used in a device

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7904722B2 (en) * 1994-07-19 2011-03-08 Certco, Llc Method for securely using digital signatures in a commercial cryptographic system
US6085320A (en) * 1996-05-15 2000-07-04 Rsa Security Inc. Client/server protocol for proving authenticity
US6324645B1 (en) * 1998-08-11 2001-11-27 Verisign, Inc. Risk management for public key management infrastructure using digital certificates
EP1143658A1 (fr) * 2000-04-03 2001-10-10 Canal+ Technologies Société Anonyme Authentification de données transmises dans un système de transmission numérique
JP4660900B2 (ja) * 2000-08-31 2011-03-30 ソニー株式会社 個人認証適用データ処理システム、個人認証適用データ処理方法、および情報処理装置、並びにプログラム提供媒体
JP4470384B2 (ja) * 2003-03-25 2010-06-02 富士ゼロックス株式会社 情報処理装置、ジョブ処理装置、指示データ作成装置及び署名プロキシ装置
US7503074B2 (en) * 2004-08-27 2009-03-10 Microsoft Corporation System and method for enforcing location privacy using rights management

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2006035159A1 (fr) 2006-04-06
FR2875977A1 (fr) 2006-03-31
US20080159543A1 (en) 2008-07-03

Similar Documents

Publication Publication Date Title
EP1072124B1 (fr) Procede de verification de l'usage de cles publiques engendrees par un systeme embarque
FR2958101A1 (fr) Infrastructure de gestion de bi-cles de securite de personnes physiques (igcp/pki)
FR2930390A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise.
EP2323306A1 (fr) Procédé de transmission de données sécurisé et systeme de chiffrement et de dechiffrement permettant une telle transmission
WO2007012584A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants
EP1911194A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
EP2301187A1 (fr) Terminal d'authentification forte d'un utilisateur
FR3075423A1 (fr) Technique de protection d'une cle cryptographique au moyen d'un mot de passe utilisateur
EP1794926A1 (fr) Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
WO2007051769A1 (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
EP1514377A1 (fr) Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne
EP1413088B1 (fr) Methode pour creer un reseau virtuel prive utilisant un reseau public
EP4012972A1 (fr) Méthode de divulgation sélective de données via une chaine de blocs
FR2896646A1 (fr) Certification avec autorite de certification distribuee
CA2831167C (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques ou d'elements (igcp/pki)
WO2011030069A1 (fr) Procede de generation d'un certificat numerique
WO2021074527A1 (fr) Procede de gestion d'une base de donnees de cles publiques, procede d'authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
WO1998010563A2 (fr) Instrument de securisation d'echanges de donnees
WO2021156078A1 (fr) Procédé et dispositif d'évaluation de correspondance d'ensembles de données structurées protégées par le chiffrement
FR2990818A1 (fr) Procede de transfert et de stockage securise de documents et appareils associes au procede.
EP4278282A1 (fr) Procede et systeme de controle d'acces
FR2927750A1 (fr) Terminal de paiement electronique pour l'echange de donnees securise sur un reseau ouvert
WO2016156737A1 (fr) Procede d'obtention d'une liste d'au moins une donnee sensible
WO2007138229A2 (fr) Procede d'acces securise a une ressource cryptee
FR2834843A1 (fr) Procede et systeme de certification de cles publiques au sein d'une communaute d'utilisateurs

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

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100615

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