WO2006056667A1 - Certificat de cle publique pour le transport d'information confidentielle - Google Patents

Certificat de cle publique pour le transport d'information confidentielle Download PDF

Info

Publication number
WO2006056667A1
WO2006056667A1 PCT/FR2005/002632 FR2005002632W WO2006056667A1 WO 2006056667 A1 WO2006056667 A1 WO 2006056667A1 FR 2005002632 W FR2005002632 W FR 2005002632W WO 2006056667 A1 WO2006056667 A1 WO 2006056667A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
attributes
certificate
dch
user
Prior art date
Application number
PCT/FR2005/002632
Other languages
English (en)
Inventor
Julie Loc'h
Loïc HOUSSIER
David Arditti
Original Assignee
France Telecom
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 filed Critical France Telecom
Publication of WO2006056667A1 publication Critical patent/WO2006056667A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3263—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/88—Medical equipments

Definitions

  • the invention lies in the field of the use of a public key certificate in a telecommunications network.
  • the invention is particularly applicable to the use of public key certificate for the transport of confidential information.
  • the type of certificate that will serve to illustrate the invention is that defined in the X509 standard. However, the invention can be implemented with any type of certificate format.
  • a pair of keys (public key, private key) is characterized by cryptographic parameters namely the length of the key, the period of validity of the couple, the cryptographic algorithm associated with this pair.
  • a user has an identity, a function possibly for a given period.
  • Confidence is obtained by associating with the pair of keys a certificate issued and signed by a trusted entity known as public key infrastructure PKI.
  • the set of key pair and user parameters forms the public key certificate.
  • the certificate is signed by a trusted third party who guarantees the veracity of the information contained in the certificate. This authority is called the Certificate Authority (CA) and signs the public key certificate with its own private key.
  • CA Certificate Authority
  • the fundamental object to trust the public part of the key (public key) is the certificate. This is an object including:
  • a list of attributes corresponding to the usage rights of the key for example: message signing key, secure web server key, etc.
  • a cryptographic signature of the four preceding data by the public key of a certification authority (CA) issuing the certificate
  • a public key infrastructure PKI is the set of resources used to secure the key pairs by the generation and the complete management of public key certificates
  • a PKI public key infrastructure not only makes it possible to create certificates, but also to manage their life (revocation, renewal, etc.) The main services provided by a public key infrastructure
  • PKIs are user registration, certificate generation, certificate publishing, certificate revocation.
  • CA The certification authority
  • the certification authority is the moral authority on whose behalf the certificates are issued. It defines the procedures and verifies their application. Without it, no certificate can be issued.
  • a Registration Authority is responsible for collecting requests and usually performs the following functions:
  • An AE Registration Authority may delegate all or part of its functions to the local registration authorities (local AEs: ALE).
  • An actor issues a certificate generation request from a local recording authority ("ALE"). This actor may be the beneficiary of the certificate or an administrator responsible for applying for it.
  • ALE local recording authority
  • a certification operator is then responsible for processing the certification request, issuing the certificates and applying all the procedures defined by the certification authority. These procedures include the issuance of the certificate to the applicant, the publication of certificates in directories or the provision on a web server where appropriate.
  • a public key infrastructure PKI is therefore a complex structure that involves these four entities, and performs the roles of registration authority and certification operator.
  • the local ALE registration authority transmits the beneficiary identity data to the AE Registration Authority. "The registration authority AE records this data in databases PKI.
  • the OC certification operator retrieves the CA certificate issuing CA key. • The OC certification operator creates the certificate using the private key of the CA certificate.
  • Certificates are currently used to certify data that is public. The use of a certificate is therefore limited to its basic function namely the certification of public data. A user can not use a public key certificate to transport sensitive data.
  • the sensitive data includes any data whose access is restricted to a certain category of users.
  • An object of the invention is therefore to extend the use of certificates to applications requiring sensitive data transfers.
  • a certificate includes encrypted attributes.
  • the resulting method is as follows: a step of creating a certificate including a set of encrypted attributes; a step of transmitting, from the station to the decryption server, said set of encrypted attributes; a decryption step, by the decryption server, of all or part of the encrypted attributes of said set; a step of transmitting, from the decryption server to the station, all or some of the decrypted attributes.
  • FIG. 1 is a view of a computer system on which the invention can be applied.
  • Figure 2 is an algorithm illustrating the various steps of an embodiment of the invention.
  • Figure 3 is a view of a table illustrating an embodiment relating to the right to read the encrypted attributes of the certificate object of the invention.
  • FIG. 1 represents a SYS computer system in which the invention can be implemented.
  • the exemplary embodiment chosen to illustrate the invention is an example belonging to the medical field.
  • the SYS system includes an STA workstation and a DCH decryption server.
  • the STA station is used by a first user UT1.
  • This first user receives from a second user LJT2 a certificate C2 object of the invention.
  • the first user UT1 of the station is for example a treating physician and the second user UT2 can be his patient.
  • the STA station communicates with the decryption server DCH through any telecommunications network RES.
  • the network is the Internet network known to those skilled in the art.
  • the decryption server has a WEB interface.
  • the doctor UT1 manipulates the station via his keyboard.
  • the type of STA includes any data processing device capable of communicating with a telecommunications network.
  • the station is equipped with a reader adapted to receive a memory card of a patient.
  • the smart card is for example a smart card.
  • the UT2 patient has a C2 certificate.
  • the exemplary embodiment relates to an X509 type certificate.
  • this certificate is stored on the smart card belonging to the patient.
  • the UT2 patient's certificate comprises a set of encrypted data, certified in the same way as certified public data.
  • a set of encrypted data means that the set includes at least one encrypted data. In the remainder of the description, the set includes several encrypted attributes.
  • the encrypted data is placed in the certificate C2 of the patient UT2 in one or more extensions of the certificate with a respective identifier (OID: Object Identifier).
  • OID Object Identifier
  • the X509 standard describes a certificate with a number of extensions. These extensions are pairs of type and value. The nature of the extension can be various (an IP address, an alias, etc.) thus giving the possibility to define certificate profiles.
  • OID Object Identifier
  • the encrypted data is therefore entered in a respective attribute field provided for this purpose in the certificate.
  • the encrypted data is the patient's immutable medical data, for example his blood group, his family history, the serial number, the patient's medical file, an address, a red-listed telephone number, or any other information. other useful information related to the patient.
  • the decryption server DCH is the only one to possess the tool for decrypting the encrypted data of the certificate C2. It therefore has the cryptographic keys necessary for decryption.
  • the group of authorized users corresponds to the entire medical profession. This group, to which the doctor UT1 belongs, is therefore a group authorized to obtain the decrypted values of the sensitive data contained in the certificate C2 of the patient UT2.
  • Figure 2 illustrates the different execution steps performed between the STA workstation and the DCH decryption server.
  • Step 1 The mode of operation of this embodiment is as follows: Step 1
  • a first step ET1 the doctor UT1 reads the contents of the card belonging to the patient UT2 via his card reader. After reading, he obtains the public certificate C2 containing the encrypted attributes representing the sensitive data relating to his patient UT2.
  • the doctor UT1 extracts the encrypted data from the C2 certificate of UT2.
  • the doctor UT1 can authenticate and connect to the decryption server.
  • the doctor UT1 ideally has a way to find the address of the decryption server.
  • This address can be for example a public data of the certificate C2 that it receives from the patient UT2.
  • the C1 certificate contained in the personal health card (CPS) owned by the nursing staff could allow access to this DCH server. Access is made after authentication of the doctor UT1 to the DCH server.
  • CPS personal health card
  • Access consists of a control allowing or denying access by the UT1 physician to the DCH server. Access to this server is via authentication means known to those skilled in the art, for example by means of the C1 certificate that has been previously issued, but can also be achieved by means of biometrics, or any other means to authenticate the doctor UT1.
  • the UT1 physician has a C1 certificate from an AC certification authority.
  • the DCH server is a server with secure access type httpsV3 (client authentication), access to which is controlled by means of a strong certificate authentication from a CA authentication authority authorized. Thus, only UT1 persons with a C1 certificate from the certification authority recognized by the DCH decryption server are allowed to connect to this WEB interface.
  • the server can communicate with a BDDC lookup database.
  • This database BDDC is periodically updated and stores all the certificates that can be presented to the DCH server and which are authorized to receive the decrypted data in return.
  • This database BDDC can be consulted by the decryption server DCH when an authentication has to be performed.
  • This database BDDC consultation verifies whether the certificate C1 received from the station corresponds to a certificate stored in the database BDDC. If yes, the authentication is successful and the decryption of the encrypted data can be performed.
  • Updating this database is used to manage access control to the DCH server. Management includes the deletion, addition, or more generally the modification of access rights. As a result, the authentication means belonging to the doctor can be removed at any time by deleting the certificate in the database BDDC.
  • DN Distinguished name
  • DN Distinguished name
  • the name of the CA is identified by a DN parameter; the subject of the certificate is also identified by a DN parameter.
  • the correspondence between the received certificate C1 and the list of certificates stored in the database BDDC is done using this parameter DN.
  • Step 4 This uniqueness ensures that the same certificate can not be shared among multiple people.
  • Step 5 access to the DCH server being authorized, the doctor UT1 transmits all the encrypted data to the decryption server DCH.
  • a fifth step ET5 the server decrypts all the data.
  • a sixth step ET6 the server transmits all the decrypted data back to the authorized doctor UT1.
  • a seventh step ET7 after receiving the decrypted attributes, the STA station is disconnected from the DCH server.
  • the doctor UT1 can read the sensitive data belonging to his patient UT2.
  • the sensitive data belonging to the patient are displayed only the connection time.
  • the use of an httpsv3 type connection known to those skilled in the art provides such a feature.
  • the confidentiality of sensitive data is ensured. This need appears for example when the same station is shared access between several users.
  • the rights management of the users can be refined.
  • this management is again carried out by the database of rights of consultations BDDC.
  • this database BDDC is consulted by the decryption server DCH to verify that the doctor UT1 requesting the decryption of sensitive data is authorized to consult all the encrypted data or only a part thereof.
  • a physician UT1 authenticated and authorized to access the decryption server DCH may not be allowed to view all the sensitive data of the certificate C2 belonging to his patient UT2.
  • This variant makes it possible to limit access to a portion of the encrypted data, for example to a doctor he has designated.
  • step ET5 is therefore preceded by an optional step in which the DCH server checks in the database of BDDC lookup data that the authenticated UT1 physician has the rights to retrieve all decrypted data or only a portion of that data.
  • Figure 3 is a view of a lookup table including the rights that different physicians have on the encrypted certificate attributes belonging to different patients.
  • the first column corresponds to the authorized doctors.
  • the second column includes users with a certificate that includes encrypted attributes.
  • the encrypted attributes appear in the third column.
  • a fourth column lists the encrypted attributes that an authorized physician can read.
  • doctor UT12 is authorized to read the two attributes ATTC 1 and ATTC2 deciphered of the certificate of the patient UT21.
  • this same doctor UT12 is authorized to only the decrypted attribute ATTC 1 belonging to the patient UT22.
  • the invention is not limited to this embodiment.
  • the implementation of the invention may extend to any application in which sensitive information belonging to a user must be read by different user groups.
  • the invention can be applied to the field of the highway code.
  • the user UT2 is a driver and the user UT1 is a traffic officer.
  • the user's certificate includes numerical attributes of his driver's license such as the serial number of his license, the date of issue, the vehicle categories for which the license is valid, the criminal record, etc.
  • a UT1 agent transmits a certificate according to the method described with reference to Figures 1, 2 and 3.
  • the agent takes the place of the doctor, and the driver takes the place of the patient.
  • a lookup table as described in Figure 3 also exists in this example. Access to the set of encrypted attributes can also be restricted to a certain agent category.
  • the invention relates to a method of using a public key certificate C2, said certificate being transmitted by a first user UT1 by means of a station to a DCH server, said certificate including suitable attributes. to certify the identification information of a user UT2 and to secure a communication between the STA station and the DCH server, characterized in that it comprises the following steps: - a step of creating a certificate (C2) including a set of encrypted attributes, a step of transmitting, from the station (STA) to the decryption server (DCH), said set of encrypted attributes a decryption step, by the decryption server (DCH), of all or part of encrypted attributes of said set, a step of transmitting, from the decryption server (DCH) to the station (STA), all or part of the decrypted attributes.
  • C2 public key certificate
  • DCH decryption server
  • DCH decryption server
  • the invention also relates to the DCH server capable of receiving a public key certificate C2 issued by a first user UT1 by means of an STA station via a telecommunications network, said certificate including attributes capable of certifying the identification information of a second user UT2 and secure communication between the STA station and the DCH server, characterized in that the certificate includes a set of encrypted attributes, and in that the server comprises: - means for decrypting all or part of the encrypted attributes of said set, means for transmitting all or part of the decrypted attributes to the workstation STA.
  • the invention also relates to the public key certificate C2 capable of being transmitted by a first user UT1 from an STA station to a DCH server, said certificate including attributes able to certify the identification information of a second user UT2 and to secure a communication between an STA station and a DCH server, characterized in that it comprises a set of encrypted attributes that can be decrypted by the DCH server.
  • the invention also relates to the computer program that can be implemented on a DCH server, said server being able to receive a public key certificate from a first user UT1 of an STA station, said certificate including a set of attributes capable of certifying the identification information of a second user UT2, said program comprising code instructions which, when the program is executed on said server, performs the following steps: a step of receiving a set of encrypted attributes, a step of decrypting all or part of the encrypted attributes, - a step of transmitting all or part of the decrypted attributes to the workstation (STA).
  • STA workstation
  • the main advantage of the invention is therefore the use of a certificate for conveying, via encrypted attributes, sensitive information whose decryption is restricted to users having a decryption right on the encrypted attributes.
  • the invention thus makes it possible to manage semi-public data in a certificate. These data are public in the sense that the possibility of seeing these data is only offered to a group of people, in our example the medical profession. Certificates can now be issued, some of whose data is visible only by a category of authorized persons.
  • the server checks the access rights of the user UT1 STA station, it is possible that part of the set of encrypted attributes is accessible only by this user. As a result, the server only returns decrypted attributes or some of the decrypted attributes depending on the application. For example, reading decrypted attributes can only be allowed during a predefined time range.
  • the server stores in this case a specific computer program capable of performing such a function.
  • the sensitive data being stored in a public container (the certificate in this case), the loss of the certificate will therefore have no influence on the disclosure of sensitive data because they are protected by encryption.
  • the owner of this data for example a patient, can therefore transport them without any risk.
  • the invention is particularly interesting especially for access to medical data, which doctors may be allowed to see but not an insurer for example.
  • a data can be considered as public within a company whereas it would be sensitive vis-à-vis the outside.
  • the invention offers other advantages.
  • the transmission step is preceded by a first verification step capable of checking whether the user UT1 of the STA station is authorized to communicate with the DCH server.
  • the server includes means for verifying whether the user UT1 of the TA station is authorized to communicate with the DCH decryption server. This ensures that the UT1 user is authorized to connect to the DCH server.
  • the first verification step consists of an authentication of the user UT1 of the STA station by the server DCH.
  • the server includes authentication means for performing the verification.
  • the transmission step, by the server DCH is preceded by a second verification step to check whether the user UT1 has access rights on all or part of the attributes of said set of attributes; the transmission step, by the server, of transmitting to the STA station only the decrypted attributes for which the user UT1 has access rights.
  • the reading of the encrypted attributes of a certificate can only be partially authorized, for example according to the user group to which the user UT1 of the STA station belongs.
  • the access rights to the decrypted attributes are managed by a database BDDC, and in that the rights are modifiable.
  • the server includes means for checking whether the user UT1 of the STA station has access rights on all or part of the decrypted attributes; means for transmitting to the STA station only the decrypted attributes for which the user UT1 has access rights.
  • the set of authorized users is ideally a non-static list. Users of this list can be excluded at any time and new users can enter without having to change the encrypted data in the certificate, and therefore the certificate itself.

Abstract

L'invention a pour objet l'utilisation d'un certificat de clé publique (C2). Ce certificat est transmis par un premier utilisateur (UT1 ) au moyen d'une station vers un serveur (DCH). Ce certificat inclut des attributs aptes à certifier les informations d'identification d'un utilisateur (UT2) et à sécuriser une communication entre la station (STA) et le serveur (DCH). Le procédé de l'invention comprend les étapes suivantes: une étape de création d'un certificat (C2) incluant un ensemble d'attributs chiffrés ; une étape de transmission, de la station (STA) au serveur de déchiffrement (DCH), dudit ensemble d'attributs chiffrés ; une étape de déchiffrement, par le serveur de déchiffrement (DCH), de tout ou partie des attributs chiffrés dudit ensemble ; une étape de transmission, du serveur de déchiffrement (DCH) vers la station (STA), de tout ou partie des attributs déchiffrés.

Description

CERTIFICAT DE CLE PUBLIQUE POUR LE TRANSPORT D'INFORMATION CONFIDENTIELLE
Domaine technique L'invention se situe dans le domaine de l'utilisation de certificat de clé publique dans un réseau de télécommunications. L'invention s'applique tout particulièrement à l'utilisation de certificat de clé publique pour le transport d'information confidentielle.
Le type de certificat qui servira à l'illustration de l'invention est celui défini dans la norme X509. Cependant l'invention peut être mise en œuvre avec tout type de format de certificat.
L'illustration de l'invention étant basée sur un certificat normalisé X509, on se reportera à cette norme pour toute question technique relative aux termes techniques utilisés dans la description.
Etat de la technique
Un couple de clés (clé publique, clé privée) est caractérisé par des paramètres cryptographiques à savoir la longueur de la clé, la période de validité du couple, l'algorithme cryptographique associé à ce couple. Un utilisateur dispose d'une identité, d'une fonction éventuellement pour une période donnée.
L'utilisation de couples de clés (clé publique, clé privée) par un utilisateur entraîne la nécessité de publier en toute confiance la clé publique. Le mécanisme de publication doit assurer à la fois que • la clé est bien celle de l'utilisateur avec qui le dialogue va s'établir ;
• le possesseur de la clé est "digne confiance" ;
• la clé est toujours valide.
La confiance est obtenue en associant au couple de clés un certificat délivré et signé par une entité de confiance dite infrastructure à clé publique PKI. L'ensemble des paramètres relatifs au couple de clés et à l'utilisateur forme le certificat de clé publique. Le certificat est signé par un tiers de confiance qui cautionne la véracité des informations contenues dans le certificat. Cette autorité est appelé autorité de certification (CA) et signe le certificat de clé publique avec sa propre clé privée.
Le format de certificat le plus répandu est celui décrit dans la norme UT2.509 v3. (RFC 3280, groupe de travail IETF appelé PKIX). On se référera au texte de cette norme pour plus d'explications.
L'objet fondamental permettant d'avoir confiance en la partie publique de la clé (clé publique) est donc le certificat. Il s'agit d'un objet comprenant notamment :
•La clé publique à certifier ;
•L'identité de son possesseur ;
" Une période de validité (activation, expiration) ;
" Une liste d'attributs correspondant aux droits d'utilisations de la clé (par exemple : clé de signature de message, clé de serveur web sécurisé, etc) ;
" Une signature cryptographique des quatre données précédentes par la clé publique d'une autorité de certification (AC) dite émettrice du certificat. Une infrastructure à clé publique PKI est l'ensemble des ressources mises en oeuvre pour sécuriser les couples de clés par la génération et la gestion complète de certificats de clés publiques. Une infrastructure à clé publique PKI permet non seulement de créer des certificats, mais aussi de gérer leur vie (révocation, renouvellement, etc.). Les principales prestations assurées par une infrastructure à clé publique
PKI sont l'enregistrement d'un utilisateur, la génération de certificats, la publication de certificats, la révocation de certificats.
D'une manière générale, quatre entités interagissent pour la réalisation de ces prestations: l'autorité de certification AC, un acteur humain, une autorité locale d'enregistrement ALE, et une autorité d'enregistrement AE. - L'autorité de certification (AC) est l'autorité morale au nom de laquelle sont émis les certificats. Elle définit les procédures et vérifie leur application. Sans elle, aucun certificat ne peut être émis.
- Une autorité d'enregistrement (AE) est chargée de recueillir les requêtes et assure habituellement les fonctions suivantes :
" La gestion des demandes de Certificats,
• La vérification de l'identité des demandeurs de certificats
• L'archivage des dossiers de demandes de Certificats,
» La vérification des demandes de révocation de Certificats. Une autorité d'enregistrement AE peut déléguer tout ou partie de ses fonctions aux autorités locales d'enregistrement (AE locales : ALE).
- Un acteur, émet une requête de génération de certificat auprès d'une autorité locale d'enregistrement (ALE) ("recording local authority" en anglais). Cet acteur peut être le bénéficiaire du certificat ou un administrateur chargé de faire la demande pour lui.
- Un opérateur de certification (OC) est ensuite chargé de traiter la requête de certification, d'émettre les certificats et d'appliquer toutes les procédures définies par l'autorité de certification. Ces procédures sont notamment la délivrance du certificat à son demandeur, la publication des certificats dans des annuaires ou la mise à disposition sur un serveur web le cas échant.
Une infrastructure à clé publique PKI est donc une structure complexe qui fait intervenir ces quatre entités, et assure les rôles d'autorité d'enregistrement et d'opérateur de certification.
D'une manière générale, la délivrance d'un certificat se déroule de la manière suivante :
• Le bénéficiaire d'un certificat se présente auprès d'une autorité locale d'enregistrement ALE.
• L'autorité locale d'enregistrement ALE transmet à l'autorité d'enregistrement AE les données relatives à l'identité du bénéficiaire. » L'autorité d'enregistrement AE enregistre ces données dans les bases de l'infrastructure PKI.
* L'opérateur de certification OC récupère la clé de l'autorité de certification AC émettrice du certificat. • L'opérateur de certification OC crée le certificat en utilisant la clé privée du certificat de l'autorité de certification AC.
• Le certificat une fois créé est fourni au bénéficiaire.
Les certificats sont utilisés actuellement pour certifier des données qui sont publiques. L'utilisation d'un certificat est donc limitée à sa fonction de base à savoir la certification de données publiques. Un utilisateur ne peut pas utiliser un certificat de clé publique pour transporter des données sensibles.
Dans le contexte de l'invention, les données sensibles comprennent toutes données dont l'accès est restreint à une certaine catégorie d'utilisateurs.
L'invention Un but de l'invention est donc d'étendre l'utilisation de certificats à des applications nécessitant des transferts de données sensibles.
Selon l'invention, un certificat comprend des attributs chiffrés. Le procédé qui en résulte est le suivant: une étape de création d'un certificat incluant un ensemble d'attributs chiffrés; une étape de transmission, de Ia station au serveur de déchiffrement, dudit ensemble d'attributs chiffrés; une étape de déchiffrement, par le serveur de déchiffrement, de tout ou partie des attributs chiffrés dudit ensemble; - une étape de transmission, du serveur de déchiffrement vers la station, de tout ou partie des attributs déchiffrés.
De cette façon, un certificat peut être utilisé pour véhiculer, par l'intermédiaire de ses attributs cryptés, des informations sensibles dont le décryptage est restreint aux utilisateurs ayant un droit de décryptage sur les attributs cryptés. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés. Sur ces figures, dans un soucis de simplification de la description, les mêmes éléments portent les mêmes références.
Les figures: la figure 1 est une vue d'un système informatique sur lequel peut s'appliquer l'invention.
La figure 2 est un algorithme illustrant les différentes étapes d'un mode de réalisation de l'invention.
La figure 3 est une vue d'une table illustrant un mode de réalisation relatif au droit de lecture des attributs chiffrés du certificat objet de l'invention.
Description détaillée d'exemples de réalisation illustrant l'invention
La figure 1 représente un système informatique SYS dans lequel l'invention peut être mis en œuvre. L'exemple de réalisation choisi pour illustrer l'invention est un exemple appartenant au domaine médical.
Dans notre exemple, Le système SYS comprend une station de travail STA et un serveur de déchiffrement DCH. La station STA est utilisée par un premier utilisateur UT1. Ce premier utilisateur reçoit d'un second utilisateur LJT2 un certificat C2 objet de l'invention. Le premier utilisateur UT1 de la station est par exemple un médecin traitant et le second utilisateur UT2 peut être son patient.
La station STA communique avec le serveur de déchiffrement DCH au travers d'un réseau de télécommunications RES quelconque. Dans notre exemple de réalisation, le réseau est le réseau Internet connu de l'homme du métier. Dans notre exemple, le serveur de déchiffrement possède une interface WEB.
Dans notre exemple, le médecin UT1 manipule la station par l'intermédiaire de son clavier. Le type de la station STA englobe tout dispositif de traitement de données apte à communiquer avec un réseau de télécommunications. Dans notre exemple de réalisation, la station est équipée d'un lecteur apte à recevoir une carte à mémoire d'un patient. La carte à mémoire est par exemple une carte à puce.
Le patient UT2 dispose d'un certificat C2. L'exemple de réalisation concerne un certificat de type X509. Dans notre exemple, ce certificat est stocké sur la carte à puce appartenant au patient.
Selon l'invention, le certificat du patient UT2 comprend un ensemble de données chiffrées, certifiées au même titre que des données publiques certifiées.
Un ensemble de données chiffrées signifie que l'ensemble comprend au moins une donnée chiffrée. Dans la suite de la description, l'ensemble comprend plusieurs attributs chiffrés.
Dans notre exemple de réalisation, les données chiffrées sont placées dans le certificat C2 du patient UT2 dans une ou plusieurs extensions du certificat avec un identifiant (OID: Object Identifier) respectif. Rappelons qu'en plus des champs classiques d'un certificat, la norme X509 décrit un certificat ayant un certain nombre d'extensions. Ces extensions sont des couples formés d'un type et d'une valeur. La nature de l'extension peut être diverse (une adresse IP, un alias, etc. ) donnant ainsi la possibilité de définir des profils de certificats. Rappelons aussi qu'un OID (Object Identifier) est un nombre unique qui identifie un objet. Ce numéro est défini par une autorité de certification. Cet identifiant se situe dans le champs appelé "subject/attribute value" du certificat. Chaque donnée chiffrée est donc introduite dans un champ attribut respectif prévu à cet effet dans le certificat. On se référera à la norme X509 pour plus de détails sur les différents champs composant un certificat. Dans notre exemple de réalisation, les données chiffrées sont les données médicales immuables du patient par exemple son groupe sanguin, ses antécédent familiaux, le numéro de série, le dossier médical du patient, une adresse, un numéro de téléphone sur liste rouge, ou tout autre information utile liée au patient.
De préférence, le serveur de déchiffrement DCH est le seul à posséder l'outil de déchiffrement des données cryptées du certificat C2. Il possède donc les clés cryptographiques nécessaires au décryptage. Dans l'exemple de réalisation, le groupe des utilisateurs autorisés correspond à l'ensemble du corps médical. Ce groupe, auquel appartient le médecin UT1 , est donc un groupe autorisé à obtenir les valeurs déchiffrées des données sensibles contenues dans le certificat C2 du patient UT2. La figure 2 illustre les différentes étapes d'exécution réalisées entre la station de travail STA et le serveur de déchiffrement DCH.
Le mode de fonctionnement de cet exemple de réalisation est le suivant: Etape 1
Lors d'une première étape ET1 , le médecin UT1 lit le contenu de la carte appartenant au patient UT2 par l'intermédiaire de son lecteur de carte. Après lecture, il se procure le certificat public C2 contenant les attributs chiffrés représentant les données sensibles relatives à son patient UT2.
Etape 2
Lors d'une deuxième étape ET2, le médecin UT1 extrait les données chiffrées du certificat C2 de UT2.
Etape 3
Grâce à un certificat C1 , lors d'une troisième étape ET3, le médecin UT1 peut s'authentifier et se connecter au serveur de déchiffrement.
Pour la connexion, le médecin UT1 possède idéalement un moyen de retrouver l'adresse du serveur de déchiffrement. Cette adresse peut être par exemple une donnée publique du certificat C2 qu'il reçoit du patient UT2.
Dans l'exemple du dossier médical, le certificat C1 contenu dans la carte personnelle de santé (CPS) possédée par les personnels soignants pourrait permettre l'accès à ce serveur DCH. L'accès s'effectue après authentification du médecin UT1 au serveur DCH.
L'accès consiste en un contrôle autorisant ou refusant l'accès du médecin UT1 au serveur DCH. L'accès à ce serveur se fait par l'intermédiaire de moyens d'authentification connus de l'homme du métier, par exemple au moyen du certificat C1 qui lui a été préalablement délivré, mais peut aussi être réalisé au moyen de la biométrie, ou tout autre moyen permettant d'authentifier le médecin UT1. Dans notre exemple, le médecin UT1 possède un certificat C1 issu d'une autorité de certification AC. Dans notre exemple, le serveur DCH est un serveur avec accès sécurisé de type httpsV3 (authentification client), dont l'accès est contrôlé au moyen d'une authentification forte par certificat issu d'une autorité d'authentification AC autorisée. Ainsi, seules les personnes UT1 munies d'un certificat C1 issu de l'autorité de certification reconnue par le serveur de déchiffrement DCH sont autorisées à se connecter à cette interface WEB.
Si l'authentification est réussie, l'accès au serveur est autorisé; une connexion sécurisée (en httpsV3 par exemple) est alors ouverte. De préférence, le serveur peut communiquer avec une base de données de consultation BDDC. Cette base BDDC est mise à jour périodiquement et stocke l'ensemble des certificats susceptibles d'être présentés au serveur DCH et qui sont autorisés à recevoir en retour les données déchiffrées. Cette base BDDC peut être consultée par le serveur de déchiffrement DCH lorsqu'une authentification doit être réalisée. Cette base de données de consultation BDDC permet de vérifier si le certificat C1 reçu de la station correspond à un certificat stocké dans la base de données BDDC. Dans l'affirmative, l'authentification est réussie et le déchiffrement des données cryptées peut être effectué.
La mise à jour de cette base de données permet de gérer le contrôle d'accès au serveur DCH. La gestion comprend notamment la suppression, l'adjonction, ou plus généralement la modification des droits d'accès. En conséquence, le moyen d'authentification appartenant au médecin peut lui être retiré à tout moment par suppression du certificat dans la base BDDC.
Rappelons que certaines informations d'un certificat sont identifiées au moyen d'un paramètre appelé "Distinguished name" (DN) dans la norme X509. Ce paramètre DN assure l'unicité du nommage d'un certificat. Concrètement, dans cette norme, le nom de l'autorité de certification est identifié par un paramètre DN; le sujet du certificat est également identifié par un paramètre DN. Dans notre exemple, la correspondance entre le certificat reçu C1 et la liste des certificats stockés dans la base de données BDDC s'effectue en utilisant ce paramètre DN.
Cette unicité assure qu'un même certificat ne peut être partagé entre plusieurs personnes. Etape 4
Lors d'une quatrième étape ET4, l'accès au serveur DCH étant autorisé, le médecin UT1 transmet l'ensemble des données chiffrées au serveur de déchiffrement DCH. Etape 5
Lors dune cinquième étape ET5, le serveur déchiffre l'ensemble des données.
Etape 6
Lors d'une sixième étape ET6, le serveur transmet en retour l'ensemble des données déchiffrées au médecin autorisé UT1.
Etape 7
Lors d'une septième étape ET7, après réception des attributs déchiffrés, la station STA est déconnectée du serveur DCH. Le médecin UT1 peut lire les données sensibles appartenant à son patient UT2. De préférence, les données sensibles appartenant au patient ne sont affichées que le temps de connexion. L'utilisation d'une connexion de type httpsv3 connue de l'homme du métier procure une telle fonctionnalité. Ainsi, la confidentialité des données sensibles est assurée. Ce besoin apparaît par exemple lorsqu'une même station est à accès partagé entre plusieurs utilisateurs. Selon une variante, on peut affiner la gestion des droits des utilisateurs.
Dans notre exemple de réalisation, cette gestion est de nouveau réalisée par la base de données de droits de consultations BDDC. Selon cette variante, cette base de données BDDC est consultée par le serveur de déchiffrement DCH pour vérifier que le médecin UT1 demandant le déchiffrement de données sensibles est bien autorisé à consulter la totalité des données chiffrées ou seulement une partie de celles-ci. En effet, un médecin UT1 authentifié et autorisé à accéder au serveur de déchiffrement DCH peut ne pas être autorisé à consulter toutes les données sensibles du certificat C2 appartenant à son patient UT2. Cette variante permet de limiter l'accès à une partie des données chiffrées, par exemple à un médecin qu'il aura désigné. Dans notre exemple de réalisation, l'étape ET5 est donc précédée d'une étape optionnelle dans laquelle le serveur DCH vérifie dans la base de données de consultation BDDC que le médecin UT1 authentifié possède les droits pour récupérer l'ensemble des données déchiffrées ou uniquement une partie de ces données. La figure 3 est une vue d'une table de correspondance incluant les droits qu'on différents médecins sur les attributs chiffrés de certificat appartenant à différents patients.
Par exemple, considérons deux médecins autorisés UT11-UT12, et deux patients UT21-UT22 ayant un certificat respectif C21-C22 incluant des attributs chiffrés ATTC1-ATTC2. La première colonne correspond aux médecins autorisés. La seconde colonne comprend les utilisateurs ayant un certificat incluant des attributs chiffrés. Les attributs chiffrés apparaissent dans la troisième colonne. Une quatrième colonne indique la liste des attributs chiffrés qu'un médecin autorisé peut lire.
Sur cette figure, on s'aperçoit que le médecin UT11 est autorisé à lire l'attribut déchiffré ATTC1 du certificat du patient UT21. A l'inverse, il ne pourra pas lire l'attribut ATTC2. Par contre, ce même médecin est autorisé à lire les deux attributs ATTC1-ATTC2 déchiffrés appartenant au patient UT22
De la même façon, on s'aperçoit que le médecin UT12 est autorisé à lire les deux attributs ATTC 1 et ATTC2 déchiffré du certificat du patient UT21. Par contre, ce même médecin UT12 est autorisé à uniquement l'attribut ATTC 1 déchiffrés appartenant au patient UT22.
L'invention ne se limite pas à cet exemple de réalisation. La mise en œuvre de l'invention peut s'étendre à toute application dans laquelle des informations sensibles appartenant à un utilisateur doivent être lues par différents groupes d'utilisateur. Par exemple, l'invention peut s'appliquer au domaine du code de la route.
L'utilisateur UT2 est un conducteur et l'utilisateur UT1 un agent de la circulation. Le certificat de l'utilisateur comprend des attributs chiffrés relatif à son permis de conduire tel que le numéro de série de son permis, la date de délivrance, les catégories de véhicule pour lesquels le permis est valable, le casier judiciaire, etc. Lors d'une infraction, un agent UT1 transmet un certificat selon le procédé décrit en référence aux figures 1 , 2 et 3. L'agent prend la place du médecin, et le conducteur prend la place du patient. Une table de correspondance telle que décrit à la figure 3 existe également dans cet exemple. L'accès à l'ensemble des attributs chiffrés peut aussi être restreint à une certaine catégorie d'agent.
D'une manière générale, l'invention concerne un procédé d'utilisation d'un certificat de clé publique C2, ledit certificat étant transmis par un premier utilisateur UT1 au moyen d'une station vers un serveur DCH, ledit certificat incluant des attributs aptes à certifier les informations d'identification d'un utilisateur UT2 et à sécuriser une communication entre la station STA et le serveur DCH, caractérisé en ce qu'il comprend les étapes suivantes: - une étape de création d'un certificat (C2) incluant un ensemble d'attributs chiffrés, une étape de transmission, de la station (STA) au serveur de déchiffrement (DCH), dudit ensemble d'attributs chiffrés une étape de déchiffrement, par le serveur de déchiffrement (DCH), de tout ou partie des attributs chiffrés dudit ensemble, une étape de transmission, du serveur de déchiffrement (DCH) vers la station (STA), de tout ou partie des attributs déchiffrés.
L'invention concerne aussi le serveur DCH apte à recevoir un certificat de clé publique C2 émis par un premier utilisateur UT1 au moyen d'une station STA par l'intermédiaire d'un réseau de télécommunication, ledit certificat incluant des attributs aptes à certifier les informations d'identification d'une second utilisateur UT2 et à sécuriser une communication entre la station STA et le serveur DCH, caractérisé en ce que le certificat inclut un ensemble d'attributs chiffrés, et en ce que le serveur comprend: - des moyens pour déchiffrer tout ou partie des attributs chiffrés dudit ensemble, des moyens pour transmettre tout ou partie des attributs déchiffrés à la station de travail STA.
L'invention concerne aussi le certificat de clé publique C2 apte à être émis par un premier utilisateur UT1 d'une station STA vers un serveur DCH, ledit certificat incluant des attributs aptes à certifier les informations d'identification d'un second utilisateur UT2 et à sécuriser une communication entre une station STA et un serveur DCH, caractérisé en ce qu'il comprend un ensemble d'attributs chiffrés apte à être déchiffrés par le serveur DCH. L'invention concerne aussi le programme d'ordinateur apte à être mis en œuvre sur un serveur DCH, ledit serveur étant apte à recevoir un certificat de clé publique de la part d'un premier utilisateur UT1 d'une station STA, ledit certificat incluant un ensemble d'attributs apte à certifier les informations d'identification d'un second utilisateur UT2, ledit programme comprenant des instructions de code qui, lorsque le programme est exécuté sur ledit serveur, réalise les étapes suivantes: une étape de réception d'un ensemble d'attributs chiffrés, une étape de déchiffrement de tout ou partie des attributs chiffrés, - une étape de transmission de tout ou partie des attributs déchiffrés à la station de travail (STA).
L'avantage principal de l'invention est donc l'utilisation d'un certificat pour véhiculer, par l'intermédiaire d'attributs chiffrés, des informations sensibles dont le déchiffrage est restreint aux utilisateurs ayant un droit de décryptage sur les attributs cryptés. L'invention permet ainsi une gestion de données semi-publiques dans un certificat. Ces données ont un caractère public dans le sens où la possibilité de voir ces données n'est offerte qu'à un groupe de personnes, dans notre exemple le corps médical. On peut désormais émettre des certificats dont certaines données ne sont visibles que par une catégorie de personnes autorisées.
D'autre part, lorsque le serveur vérifie les droits d'accès de l'utilisateur UT1 de la station STA, il se peut qu'une partie de l'ensemble des attributs chiffrés ne soit accessible que par cet utilisateur. En conséquence, le serveur ne transmet en retour que les attributs déchiffrés ou qu'une partie des attributs déchiffrés en fonction de l'application. Par exemple, la lecture des attributs déchiffrés ne peut être autorisée que pendant une plage horaire prédéfinie. Le serveur stocke dans ce cas un programme d'ordinateur spécifique apte à réaliser une telle fonction. De plus, les données sensibles étant stockées dans un conteneur public (le certificat en l'occurrence), la perte du certificat n'aura donc pas d'influence sur la divulgation des données sensibles car elles sont protégées par le chiffrement. Le propriétaire de ces données, par exemple un patient, peut donc les transporter sans aucun risque.
L'invention est particulièrement intéressante notamment pour des accès aux données médicales, que les médecins peuvent être autorisés à voir mais pas un assureur par exemple. De la même manière, une donnée peut être considérée comme publique au sein d'une entreprise alors qu'elle serait sensible vis-à-vis de l'extérieur.
L'invention offre d'autres avantages.
On a vu par exemple que l'étape de transmission est précédée d'une première étape de vérification propre à vérifier si l'utilisateur UT1 de la station STA est autorisé à communiquer avec le serveur DCH. En conséquence, le serveur comprend des moyens pour vérifier si l'utilisateur UT1 de la station TA est autorisé à communiquer avec le serveur de déchiffrement DCH. Ceci permet de s'assurer que l'utilisateur UT1 est bien autorisé à se connecter au serveur DCH. En particulier, on a vu que la première étape de vérification consiste en une authentification de l'utilisateur UT1 de la station STA par le serveur DCH. En conséquence, le serveur comprend des moyens d'authentification pour réaliser la vérification.
On a vu aussi que l'étape de transmission, par le serveur DCH, est précédée d'une deuxième étape de vérification pour vérifier si l'utilisateur UT1 a des droits d'accès sur tout ou partie des attributs dudit ensemble d'attributs; l'étape de transmission, par le serveur, consistant à transmettre à la station STA uniquement les attributs déchiffrés pour lesquels l'utilisateur UT1 à des droits d'accès. Ainsi la lecture des attributs chiffrés d'un certificat ne peut être autorisée qu'en partie, par exemple en fonction du groupe d'utilisateur auquel appartient l'utilisateur UT1 de la station STA. On a vu aussi que les droits d'accès aux attributs déchiffrés sont gérés par une base de données BDDC, et en ce que les droits sont modifiables. En conséquence, le serveur comprend des moyens pour vérifier si l'utilisateur UT1 de la station STA a des droits d'accès sur tout ou partie des attributs déchiffrés; des moyens pour transmettre à la station STA uniquement les attributs déchiffrés pour lesquels l'utilisateur UT1 à des droits d'accès. En d'autres mots, l'ensemble des utilisateurs autorisés est idéalement une liste non statique. Des utilisateurs de cette liste peuvent ainsi être exclus à tout moment et de nouveaux utilisateurs peuvent y entrer sans pour autant devoir changer les données chiffrées dans le certificat, et donc le certificat lui-même.

Claims

Revendications
1. Procédé d'utilisation d'un certificat de clé publique (C2), ledit certificat étant transmis par un premier utilisateur (UT1) au moyen d'une station vers un serveur (DCH), ledit certificat incluant des attributs aptes à certifier les informations d'identification d'un utilisateur (UT2) et à sécuriser une communication entre la station (STA) et le serveur (DCH), caractérisé en ce qu'il comprend les étapes suivantes: une étape de création d'un certificat (C2) incluant un ensemble d'attributs chiffrés, - une étape de transmission, de la station (STA) au serveur de déchiffrement (DCH), dudit ensemble d'attributs chiffrés une étape de déchiffrement, par le serveur de déchiffrement (DCH), de tout ou partie des attributs chiffrés dudit ensemble, une étape de transmission, du serveur de déchiffrement (DCH) vers la station (STA), de tout ou partie des attributs déchiffrés.
2. procédé selon la revendication 1 , caractérisé en ce que l'étape de transmission est précédée d'une première étape de vérification propre à vérifier si l'utilisateur (UT1 ) de la station (STA) est autorisé à communiquer avec le serveur (DCH).
3. procédé selon la revendication 2, caractérisé en ce que la première étape de vérification consiste en une authentification de l'utilisateur (UT1 ) de la station (STA) par le serveur (DCH).
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'étape de transmission, par le serveur (DCH), est précédée d'une deuxième étape de vérification pour vérifier si l'utilisateur (UT1 ) a des droits d'accès sur tout ou partie des attributs dudit ensemble; l'étape de transmission, par le serveur, consistant à transmettre à la station (STA) uniquement les attributs déchiffrés pour lesquels l'utilisateur (UT1 ) à des droits d'accès.
5. Procédé selon la revendication 4, caractérisé en ce que les droits d'accès aux attributs déchiffrés sont gérés par une base de données (BDDC), et en ce que les droits sont modifiables.
6. Serveur (DCH) apte à recevoir un certificat de clé publique (C2) émis par un premier utilisateur (UT1 ) au moyen d'une station (STA) par l'intermédiaire d'un réseau de télécommunication, ledit certificat incluant des attributs aptes à certifier les informations d'identification d'une second utilisateur (UT2) et à sécuriser une communication entre la station (STA) et le serveur (DCH), caractérisé en ce que le certificat inclut un ensemble d'attributs chiffrés, et en ce que le serveur comprend: des moyens pour déchiffrer tout ou partie des attributs chiffrés dudit ensemble, des moyens pour transmettre tout ou partie des attributs déchiffrés à la station de travail (STA).
7. Serveur selon la revendication 6, caractérisé en ce qu'il comprend des moyens pour vérifier si l'utilisateur (UT1) de la station (TA) est autorisé à communiquer avec le serveur de déchiffrement (DCH).
8. Serveur selon la revendication 7, caractérisé en ce que la vérification est réalisée par des moyens d'authentification.
9. Serveur selon la revendication 6 ou 7, caractérisé en qu'il comprend
- des moyens pour vérifier si l'utilisateur (UT1) de la station (STA) a des droits d'accès sur tout ou partie des attributs dudit ensemble;
- des moyens pour transmettre à la station (STA) uniquement les attributs déchiffrés pour lesquels l'utilisateur (UT1 ) à des droits d'accès.
10. Serveur selon la revendication 9, caractérisé en ce qu'il comprend des moyens pour consulter une base de données (BDDC), ladite base gérant les droits d'accès aux attributs déchiffrés, et des moyens pour modifier (ajouter/supprimer) les droits d'accès aux attributs déchiffrés.
11. Certificat de clé publique (C2) apte à être émis par un premier utilisateur
(UT1) d'une station (STA) vers un serveur (DCH), ledit certificat incluant des attributs aptes à certifier les informations d'identification d'un second utilisateur (UT2) et à sécuriser une communication entre une station (STA) et un serveur (DCH), caractérisé en ce qu'il comprend un ensemble d'attributs chiffrés aptes à être déchiffrés par le serveur (DCH).
12. Programme d'ordinateur apte à être mis en œuvre sur un serveur (DCH), ledit serveur étant apte à recevoir un certificat de clé publique de la part d'un premier utilisateur (UT1) d'une station (STA), ledit certificat incluant un ensemble d'attributs apte à certifier les informations d'identification d'un second utilisateur (UT2), ledit programme comprenant des instructions de code qui, lorsque le programme est exécuté sur ledit serveur, réalise les étapes suivantes: une étape de réception d'un ensemble d'attributs chiffrés, une étape de déchiffrement de tout ou partie des attributs chiffrés, - une étape de transmission de tout ou partie des attributs déchiffrés à la station de travail (STA).
PCT/FR2005/002632 2004-11-23 2005-10-21 Certificat de cle publique pour le transport d'information confidentielle WO2006056667A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0412499 2004-11-23
FR0412499 2004-11-23

Publications (1)

Publication Number Publication Date
WO2006056667A1 true WO2006056667A1 (fr) 2006-06-01

Family

ID=34952859

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/002632 WO2006056667A1 (fr) 2004-11-23 2005-10-21 Certificat de cle publique pour le transport d'information confidentielle

Country Status (1)

Country Link
WO (1) WO2006056667A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114584318A (zh) * 2022-03-07 2022-06-03 亿咖通(湖北)技术有限公司 一种证书和密钥的访问控制方法、电子设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815574A (en) * 1994-12-15 1998-09-29 International Business Machines Corporation Provision of secure access to external resources from a distributed computing environment
US20020004900A1 (en) * 1998-09-04 2002-01-10 Baiju V. Patel Method for secure anonymous communication
US20020144107A1 (en) * 2001-02-28 2002-10-03 International Business Machines Corporation Password exposure elimination for digital signature coupling with a host identity
US6484258B1 (en) * 1998-08-12 2002-11-19 Kyber Pass Corporation Access control using attributes contained within public key certificates

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815574A (en) * 1994-12-15 1998-09-29 International Business Machines Corporation Provision of secure access to external resources from a distributed computing environment
US6484258B1 (en) * 1998-08-12 2002-11-19 Kyber Pass Corporation Access control using attributes contained within public key certificates
US20020004900A1 (en) * 1998-09-04 2002-01-10 Baiju V. Patel Method for secure anonymous communication
US20020144107A1 (en) * 2001-02-28 2002-10-03 International Business Machines Corporation Password exposure elimination for digital signature coupling with a host identity

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114584318A (zh) * 2022-03-07 2022-06-03 亿咖通(湖北)技术有限公司 一种证书和密钥的访问控制方法、电子设备和存储介质
CN114584318B (zh) * 2022-03-07 2023-08-11 亿咖通(湖北)技术有限公司 一种证书和密钥的访问控制方法、电子设备和存储介质

Similar Documents

Publication Publication Date Title
EP3547203B1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
CN111316278B (zh) 安全身份和档案管理系统
Ellison SPKI requirements
EP1849118B1 (fr) Système et procédé d'anonymisation de données personnelles sensibles et procédé d'obtention de telles données
WO2009130089A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
WO2007120799A2 (fr) Liaison dynamique des droits d'accès et d'utilisation de ressources informatisées
FR2825869A1 (fr) Procede d'authentification entre un objet de telecommunication portable et une borne d'acces public
EP2301187A1 (fr) Terminal d'authentification forte d'un utilisateur
WO2010031926A1 (fr) Procédé d'accès à des données nominatives, tel qu'un dossier médical personnalisé, à partir d'un agent local de génération
EP1011223A1 (fr) Procédé de création et gestion d'au moins une clé cryptographique et système pour sa mise en oeuvre
EP4016353A1 (fr) Procede de chiffrement et de stockage de fichiers informatiques et dispositif de chiffrement et de stockage associe
JP2004527818A (ja) 個人データのデータベース・システム及び個人データのデータベースのアクセスを制御する方法
FR2980019A1 (fr) Procede d'acces et de partage d'un dossier informatique enrichi par des ressources multimedias personnalisees
WO2006035159A1 (fr) Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
Ellison RFC2692: SPKI Requirements
CA2489317C (fr) Systeme de gestion d'informations pour situation d'urgence
EP1413088B1 (fr) Methode pour creer un reseau virtuel prive utilisant un reseau public
WO2006056667A1 (fr) Certificat de cle publique pour le transport d'information confidentielle
FR2881591A1 (fr) Mise en oeuvre d'une operation cryptographique a distance d'une pki
EP3709274B1 (fr) Système de vote électronique sur internet
FR2898423A1 (fr) Procede securise de configuration d'un dispositif de generation de signature electronique.
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
WO2021198606A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application
WO2021156664A1 (fr) Plateforme de gestion des preferences en matiere de donnees personnelles

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY 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: A1

Designated state(s): BW GH GM KE LS MW MZ NA 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 IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05812491

Country of ref document: EP

Kind code of ref document: A1