WO2006056667A1 - Certificat de cle publique pour le transport d'information confidentielle - Google Patents
Certificat de cle publique pour le transport d'information confidentielle Download PDFInfo
- 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
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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
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
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).
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)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114584318A (zh) * | 2022-03-07 | 2022-06-03 | 亿咖通(湖北)技术有限公司 | 一种证书和密钥的访问控制方法、电子设备和存储介质 |
Citations (4)
| 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 |
-
2005
- 2005-10-21 WO PCT/FR2005/002632 patent/WO2006056667A1/fr active Application Filing
Patent Citations (4)
| 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)
| 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 | |
| US8479254B2 (en) | Credential categorization | |
| WO2009130089A1 (fr) | Procede de diffusion securisee de donnees numeriques vers un tiers autorise | |
| 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 | |
| EP1738292A2 (fr) | Systeme de generation automatique d'un message d'informations medicales | |
| 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 | |
| EP4100905A1 (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 |