FR2834843A1 - Procede et systeme de certification de cles publiques au sein d'une communaute d'utilisateurs - Google Patents

Abstract

Ce procédé comprend une phase d'attribution à chaque utilisateur d'une communauté, d'une carte à microprocesseur (6, 7) mémorisant au moins une clé secrète (Pa, Ke), cette phase consistant à : introduire des informations d'identification du nouvel utilisateur et de la carte (7) à attribuer; générer (61) une signature portant sur les informations d'identification à l'aide d'une clé (Kpr) mémorisée dans une carte (6) déjà attribuée à un utilisateur de la communauté; transmettre (42) à un serveur d'administration (1) les informations d'identification, associées à la signature; sur le serveur d'administration, vérifier la signature, et si la signature est correcte, construire un message contenant les informations d'identification, chiffrer et sceller le message à l'aide d'une clé secrète (Pa) stockée par la carte (7) et connue du serveur, et transmettre le message à la carte; dans la carte (7), recevoir le message, vérifier le sceau, et si le sceau est correct, déchiffrer le message et stocker (71) dans la mémoire de la carte les informations d'identification ainsi déchiffrées.

Description

<Desc/Clms Page number 1>

PROCEDE ET SYSTEME DE CERTIFICATION DE CLES PUBLIQUES AU SEIN D'UNE COMMUNAUTE D'UTILISATEURS.

La présente invention concerne le domaine de la signature électronique et de la conservation et de l'échange de documents numériques accessibles par un réseau de transmission de données, tel que le réseau Internet. Elle concerne plus particulièrement le problème de la préservation de l'intégrité et de la confidentialité de ces documents lors de leur transmission, ainsi que l'authentification de la signature de tels documents.

Pour préserver la confidentialité d'un document, on utilise généralement une procédure de cryptographie permettant de chiffrer un document, puis de le restituer en clair, à l'aide de clés de chiffrement.

A l'heure actuelle, il existe deux types de procédures de cryptographie. Le premier type de procédures est dit symétrique du fait qu'il utilise une clé secrète qui est utilisée à la fois pour le chiffrement et le déchiffrement. Le second type de procédures est asymétrique du fait qu'il repose sur l'utilisation d'une clé privée associée à une clé publique dans une paire de clés. Si le premier type de procédure offre une garantie suffisante sur le plan de la sécurité, il présente de nombreux inconvénients dès que les échanges chiffrés s'effectuent avec de multiples destinataires, car ils impliquent que tous les destinataires d'un document connaissent la clé secrète utilisée pour le chiffrement du document. Comme chaque utilisateur doit posséder une clé qui lui est propre, cette solution implique la mise en place d'une procédure complexe de gestion et de conservation des clés.

Les procédures asymétriques permettent de remédier à ces difficultés, dans la mesure où chaque utilisateur conserve secrète sa clé privée et communique à ses interlocuteurs uniquement sa clé publique. Toutefois, les procédures de chiffrement asymétriques sont très lourdes en temps de calcul, si bien que habituellement, le chiffrement d'un document est effectué en générant de manière aléatoire une clé de chiffrement symétrique qui est utilisée pour chiffrer le document lui-même, cette clé étant chiffrée à l'aide d'une procédure de chiffrement asymétrique et associée au document chiffré. Avec une telle procédure, un document peut être chiffré avec l'une des deux clés d'une paire de clés et déchiffré uniquement avec l'autre clé de la paire. Ainsi pour transmettre un document vers un destinataire unique d'une manière

<Desc/Clms Page number 2>

confidentielle, l'émetteur chiffre le document à l'aide de la clé publique du destinataire. De cette manière, seul le destinataire peut déchiffrer le document à l'aide de sa propre clé privée.

Les procédures de chiffrage asymétriques sont également utilisées pour signer un document à l'aide d'une signature électronique, dont la partie visible est constituée par des informations d'identification du signataire. Une telle signature électronique est générée en chiffrant une partie du document à signer à l'aide de la clé privée du signataire, cette partie de document étant par exemple obtenue à l'aide d'une fonction de"Hash"permettant d'extraire un résumé numérique ou une empreinte de l'ensemble du document. Une fonction de"Hash"est déterminée de manière à produire des résumés numériques différents même lorsque les documents d'où sont extraits ces résumés numériques ne sont que très légèrement différents.

Un destinataire du document ainsi signé peut vérifier l'authenticité de la signature en déchiffrant la signature associée au document signé, à l'aide de la clé publique du signataire. Cette procédure permet de restituer la partie de document signé qui peut alors être comparée avec le contenu du document associé à la signature, par exemple en appliquant la même fonction de Hash au document signé que celle qui a été utilisée pour générer la signature.

Ce système comporte une faille dans la mesure où d'une part, il ne permet pas de garantir la relation entre l'identité d'une personne et une clé publique, et d'autre part, il ne permet pas de garantir cette relation dans le temps. En effet, une telle garantie doit prendre en compte les pertes et vols de clés.

Pour remédier à ce problème, on a mis en place ce que l'on appelle une autorité de certification jouant le rôle de"tiers de confiance"qui délivre des certificats garantissant la relation entre une clé publique et l'identité d'une personne. Un certificat est un enregistrement numérique composé notamment d'informations d'identité du titulaire du certificat et de la clé publique de celui-ci, l'ensemble étant signé à l'aide d'une clé privée de l'autorité de certification. Une personne peut donc vérifier qu'une clé publique correspond bien à une personne déterminée en déchiffrant le certificat à l'aide de la clé publique de l'autorité de certification.

Toutefois, cette solution nécessite une gestion dans le temps des certificats, qui doit s'assurer à un instant donné de la validité de chaque certificat délivré. Cette

<Desc/Clms Page number 3>

gestion s'est avérée tellement complexe qu'elle a conduit à un éclatement des différentes fonctions entre une autorité d'enregistrement, une autorité de certification proprement dite, une autorité de validation et une autorité d'horodatage.

En outre, chaque difficulté rencontrée engendre des interventions humaines si nombreuses que la preuve formelle qu'apporte la cryptographie se trouve altérée. Pour rétablir la confiance dans un tel système, les différentes autorités intervenantes doivent offrir des garanties de responsabilité.

Toute cette infrastructure appelée PKI (Public Key Infrastructure), qui résulte d'un empilage de couches et d'acteurs, apparaît donc extrêmement complexe et coûteuse, tout en n'offrant finalement qu'une sécurité relative.

La présente invention a pour but de supprimer ces inconvénients en proposant une solution permettant de simplifier l'organisation du processus de certification. Cet objectif est atteint par la prévision d'un procédé pour établir automatiquement un lien fiable entre une clé publique de chiffrement et/ou de signature et l'identité d'un utilisateur appartenant à une communauté. Selon l'invention, ce procédé comprend une phase d'attribution d'une carte à microprocesseur respectivement à chaque utilisateur de la communauté, chaque carte comportant une zone mémoire protégée dans laquelle est mémorisée au moins une clé secrète, la phase d'attribution d'une carte à un nouvel utilisateur de la communauté comprenant les étapes consistant à : - introduire des informations d'identification du nouvel utilisateur et de la carte à attribuer, - générer une signature portant sur les informations d'identification du nouvel utilisateur à l'aide d'une clé mémorisée dans une carte à microprocesseur déjà attribuée à un utilisateur appartenant à la communauté, - transmettre à un serveur d'administration les informations d'identification introduites, associées à la signature, - sur le serveur d'administration, vérifier la signature, et si la signature est correcte, introduire les informations d'identification dans une base de données d'annuaire, construire un message de personnalisation contenant les informations d'identification du nouvel utilisateur, chiffrer et sceller le message de personnalisation à l'aide d'une clé secrète stockée dans une zone mémoire protégée de la carte à attribuer et susceptible d'être déterminée par le serveur d'administration, et transmettre le message de personnalisation à

<Desc/Clms Page number 4>

destination de la carte à attribuer, - dans la carte à attribuer, recevoir le message de personnalisation, vérifier le sceau, et si le sceau est correct, déchiffrer le message et stocker dans la mémoire de la carte les informations d'identification d'utilisateur ainsi déchiffrées.

Avantageusement, la vérification de signature par le serveur d'administration est suivie d'une étape de vérification de droits du signataire, les étapes d'introduction des informations d'identification et de construction du message de personnalisation étant effectuées uniquement si le signataire possède les droits nécessaires.

Selon une particularité de l'invention, ce procédé comprend une étape de génération de clés de chiffrement/déchiffrement et/ou de signature, par une carte à microprocesseur attribuée à un utilisateur de la communauté.

Dé préférence, la clé secrète stockée dans une carte à microprocesseur est déterminée par le serveur d'administration en appliquant un algorithme de chiffrement à un numéro d'identification de la carte à microprocesseur à l'aide d'une clé secrète connue seulement du serveur d'administration.

Egalement de préférence, le message de personnalisation contenant les informations d'identification introduites dans la carte à microprocesseur, comprend en outre des informations définissant des droits attribués à la carte, ces informations étant également mémorisées par la carte, une requête transmise à la carte étant exécutée par celle-ci uniquement si elle est autorisée conformément aux droits attribués à la carte.

Selon une autre particularité de l'invention, ce procédé comprend une phase de génération d'un certificat comprenant des étapes consistant à : - générer par une carte attribuée à un utilisateur de la communauté une paire de clés de chiffrement/déchiffrement et/ou de signature comprenant une clé publique et une clé privée qui est stockée dans une zone protégée de la mémoire de la carte, - construire par la carte un message de demande de certificat comprenant la clé publique stockée dans la carte et au moins une information d'identification de l'utilisateur de la carte, stockée dans la carte,

<Desc/Clms Page number 5>

- chiffrer et sceller par la carte le message de demande de certificat à l'aide d'une clé secrète stockée dans une zone mémoire protégée de la carte, - transmettre le message de demande de certificat chiffré et scellé, à un serveur de certificats, - dans le serveur de certificat, recevoir le message de demande de certificat et en vérifier le sceau à l'aide de la clé secrète stockée dans la carte et susceptible d'être déterminée par le serveur de certificat, et si le sceau est correct, déchiffrer le message de demande de certificat à l'aide de la clé secrète et générer un certificat comportant l'information d'identification et la clé publique contenue dans le message de demande de certificat, ces informations étant scellées par le serveur de certificat à l'aide d'une clé privée connue uniquement du serveur de certificat.

Avantageusement, la clé secrète stockée dans la carte et susceptible d'être déterminée par le serveur d'administration est différente de la clé secrète stockée dans la carte et susceptible d'être déterminée par le serveur de certificats.

De préférence, la clé secrète stockée dans une carte à microprocesseur d'un utilisateur de la communauté est déterminée par le serveur certificats en appliquant un algorithme de chiffrement à un numéro d'identification de la carte à microprocesseur à l'aide d'une clé secrète connue seulement du serveur de certificats.

L'invention concerne également un système pour établir automatiquement un lien fiable entre une clé publique de chiffrement et/ou de signature, et l'identité d'un utilisateur appartenant à une communauté, chaque utilisateur de la communauté disposant d'une carte à microprocesseur personnelle. Selon l'invention, chaque carte à microprocesseur d'utilisateur de la communauté comprend : - des moyens de chiffrement et de déchiffrement, - des moyens de génération et de contrôle de signature de documents numériques, - des moyens de génération de clés de chiffrement/déchiffrement et/ou de signature, et - des moyens de mémorisation comportant au moins une zone mémoire protégée dans laquelle est stockée au moins une clé secrète spécifique de la

<Desc/Clms Page number 6>

carte et une clé privée générée par les moyens de génération de clés, et une zone mémoire dans laquelle sont stockées des informations d'identification de l'utilisateur, le système comprenant en outre un serveur d'administration connecté à un réseau de transmission de données numériques et comprenant : - des moyens pour recevoir du réseau et authentifier un formulaire d'inscription d'un nouvel utilisateur contenant des informations d'identification du nouvel utilisateur, préalablement signé à l'aide des moyens de signature d'une carte à microprocesseur d'un utilisateur de la communauté, - des moyens pour construire un message de personnalisation contenant les informations d'identification du formulaire d'inscription, - des moyens pour chiffrer et sceller le message de personnalisation à l'aide de la clé secrète mémorisée par une carte à microprocesseur remise à un nouvel utilisateur et connue du serveur d'administration, et - des moyens pour transmettre le message de personnalisation chiffré et scellé vers la carte du nouvel utilisateur, - chaque carte à microprocesseur comportant en outre des moyens de personnalisation conçus pour recevoir, authentifier et déchiffrer un message de personnalisation, et stocker les informations d'identification contenues dans le message de personnalisation déchiffré dans la mémoire de la carte.

Selon une particularité de l'invention, ce système comprend une base de données d'annuaire connectée au serveur d'administration, et dans laquelle sont stockées les informations d'identification de chaque utilisateur de la communauté, en association avec un numéro d'identification de la carte à microprocesseur attribuée à l'utilisateur.

Avantageusement, chaque carte à microprocesseur mémorise des informations de droits attribués à la carte, transmises dans le message de personnalisation reçu, ces droits comprenant un droit d'attribuer une carte à microprocesseur à un nouvel utilisateur, la carte comprenant des moyens pour traiter une requête reçue uniquement si la requête satisfait aux droits attribués à la carte.

De préférence, chaque carte à microprocesseur comporte des moyens pour authentifier une requête émise par le serveur d'administration pour mettre à jour

<Desc/Clms Page number 7>

les informations de droits attribués à l'utilisateur, mémorisées dans la carte, et pour mettre à jour ces informations dans la mémoire de la carte si ces informations sont authentiques.

Egalement de préférence, carte à microprocesseur attribuée à un utilisateur de la communauté comprend des moyens pour empêcher qu'une même commande transmise à la carte soit exécutée plusieurs fois.

Egalement de préférence, le serveur d'administration est connecté au réseau de manière à pouvoir communiquer uniquement par message électronique.

Selon une particularité de l'invention, ce système comprend un serveur de certificats connecté au réseau et conçu pour émettre des certificats garantissant le lien entre une clé publique de chiffrement et/ou de signature et l'identité d'un utilisateur, ces informations étant stockées dans une carte à microprocesseur attribuée à chaque utilisateur de la communauté.

Selon une autre particularité de l'invention, chaque carte à microprocesseur d'utilisateur de la communauté comprend des moyens pour générer une demande de certificat chiffrée et scellée à l'aide d'une secrète, contenant la clé publique et les informations d'identification de l'utilisateur, stockées dans la carte, et pour émettre la demande de certificat vers le serveur de certificats, le serveur de certificats comprenant des moyens pour recevoir et authentifier des demandes de certificats à l'aide la clé, et pour générer un certificat contenant les informations reçues et déchiffrées, associées à un sceau du serveur de certificats généré à partir des informations reçues et déchiffrées et d'une clé secrète.

De préférence, le serveur de certificats est connecté au réseau de manière à pouvoir communiquer uniquement par message électronique.

Selon une autre particularité de l'invention, chaque carte à microprocesseur d'utilisateur de la communauté comprend des moyens pour recevoir une clé privée chiffrée à l'aide la clé secrète mémorisée par la carte, et des moyens pour déchiffrer et stocker la clé privée reçue et déchiffrée dans une zone mémoire protégée de la carte.

Avantageusement, la clé privée reçue par une carte est utilisable exclusivement pour chiffrer/déchiffrer des documents, tandis que la clé privée générée par la

<Desc/Clms Page number 8>

carte n'est utilisable que pour signer un document.

Selon une autre particularité de l'invention, les clés privées susceptibles d'être transmises aux cartes sont générées par un serveur à la demande d'une carte, le serveur comprenant des moyens pour générer une clé privée à la demande d'une carte, pour chiffrer la clé privée générée à l'aide d'une la clé secrète de la carte déterminée par le serveur, pour stocker et transmettre à la carte la clé privée chiffrée.

Un mode de réalisation préféré de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence aux dessins annexés dans lesquels :
La figure 1 représente schématiquement un système de certification de clés publiques selon l'invention ;
La figure 2 montre le système représenté sur la figure 1 dans lequel sont indiqués schématiquement les traitements et les flux de données entre les différents éléments du système, lors de l'attribution d'une carte ;
La figure 3 montre le système représenté sur la figure 1 dans lequel sont indiqués schématiquement les traitements et les flux de données entre les différents éléments du système, lors de la génération d'un certificat ;
La figure 4 montre le système représenté sur la figure 1 dans lequel sont indiqués schématiquement les traitements et les flux de données entre les différents éléments du système, lors de la génération d'une paire de clés dont la clé privée est séquestrée ;
La figure 5 montre le système représenté sur la figure 1 dans lequel sont indiqués schématiquement les traitements et les flux de données entre les différents éléments du système, lors de la génération d'une paire de clés dont la clé privée est accessible à un tiers auquel on a attribué une délégation de déchiffrement.

La figure 1 représente un système permettant la certification de clés publiques d'utilisateurs appartenant à une même communauté. Ce système comprend un

<Desc/Clms Page number 9>

serveur d'administration 1, et un serveur de certificats 3. Les deux serveurs 1,3 sont connectés à un ou plusieurs réseaux de transmission de données numériques 10, et ont accès en lecture et en écriture à une base de données d'annuaire 2 dans laquelle sont référencés tous les utilisateurs du système, membres de la communauté.

La base de données d'annuaire 2 est par exemple de type LDAP (Light Directory Access Protocol) et n'est accessible en écriture qu'à certaines personnes autorisées.

Les deux serveurs 1,3 peuvent être connectés au réseau 10 par l'intermédiaire d'un routeur 9 qui protège les serveurs 1,3 contre tout accès frauduleux, autres que par messagerie électronique.

Les utilisateurs du système disposent chacun d'un terminal 4,5, par exemple de type ordinateur personnel, et d'une carte personnelle, de type carte à microprocesseur 6,7, plus couramment appelée carte à puce, le terminal 5 étant équipé de moyens de communication 8, tels qu'un lecteur de carte à puce, pour communiquer avec le microprocesseur de la carte 7.

Le serveur d'administration 1 est conçu pour gérer les inscriptions et révocations des utilisateurs du système, membres de la communauté. Tel que représenté sur la figure 2, il dispose d'une clé secrète de pilotage Pa dite"clé maître".

Le serveur de certificats 3 est conçu pour authentifier les demandes de certification émises par les utilisateurs du système, et pour émettre des certificats des clés publiques des utilisateurs qui sont signés avec une clé Kr dite "clé racine de la communauté"et une clé d'enregistrement maître Ke.

Une carte à microprocesseur 7 non attribuée à un utilisateur du système comprend : - des fonctions cryptographiques, - des fonctions de génération de paires de clés, - un numéro de série NS, et - des clés de pilotage Pa, Ke de la carte.

Selon l'invention les cartes non attribuées comprennent également des fonctions

<Desc/Clms Page number 10>

d'administration, à savoir une fonction de personnalisation, permettant d'insérer dans la mémoire de la carte des informations d'identification du titulaire de la carte, et une fonction de demande de certificat, conçue pour émettre une demande de certificat à destination du serveur de certificats 3.

Les clés de pilotage qui sont différentes pour chaque carte émise par le système, comprennent une clé de pilotage d'administration Pa et une clé d'enregistrement Ke.

La clé de pilotage d'administration Pa est utilisée pour établir entre la carte et le serveur d'administration 1 un canal de transmission sécurisé et spécifique de la carte, c'est-à-dire qui n'est pas accessible, que ce soit en émission ou en réception à d'autres entités.

Elle permet notamment d'authentifier et déchiffrer les messages provenant du serveur d'administration 1. Elle est par exemple générée chiffrant le numéro de série NS de la carte avec la clé maître Pam du serveur d'administration, à l'aide d'un algorithme de cryptographie symétrique, par exemple de type DES ou 3DES (triple Data Encryption Standard), ou encore AES (Advanced Encryption Standard).

De même, la clé d'enregistrement Ke est utilisée pour établir un canal de transmission sécurisé entre la carte et serveur de certificats 3. Elle permet notamment de s'assurer que le demandeur de certificat appartient bien à la communauté (est un utilisateur inscrit). Elle peut également être générée par chiffrement du numéro de série NS de la carte par la clé maître Kem détenue par le serveur de certificats, à l'aide d'un algorithme de cryptographie symétrique, par exemple de type AES.

Avant d'être attribuée à un nouvel utilisateur, la carte 6,7 comprend deux clés Pa et Ke qui sont préalablement chargées dans une zone mémoire protégée 65, 75 en lecture et en écriture.

Selon l'invention, la remise d'une carte à un nouvel utilisateur est effectuée par une personne autorisée, c'est-à-dire en possession d'une carte personnelle à laquelle ont été attribués les droits nécessaires.

Lors de l'attribution d'une carte à un nouvel utilisateur, le serveur d'administration 1 s'assure que la personne qui attribue la carte est habilitée à le faire, que la personne à qui est attribuée la carte est correctement référencée

<Desc/Clms Page number 11>

dans l'annuaire stocké dans la base de données 2, et que l'identifiant qui est attribué au nouvel utilisateur est unique.

A cet effet, la personne habilitée remplit sur son terminal 4 un formulaire d'attribution 41 dans lequel est prévue l'introduction d'informations d'identification du nouvel utilisateur et en particulier un identifiant, des informations relatives aux droits accordés à celui-ci, une adresse de messagerie électronique vers laquelle un message d'attribution sera émis par le serveur d'administration au nouvel utilisateur, et éventuellement, le numéro de série NS de la carte à attribuer.

Les informations relatives aux droits accordés au nouvel utilisateur peuvent comprendre notamment une date limite de validité de la carte, un nombre maximum d'opérations autorisées, et si l'utilisateur est autorisé à signer à l'aide de sa carte, à chiffrer, à attribuer des cartes à d'autres nouveaux utilisateurs,...

Un tel formulaire peut être construit automatiquement à partir des champs prévus dans l'annuaire de la base de données 2. On peut également prévoir une affectation automatique des droits à spécifier dans le formulaire à partir de profils types prédéfinis d'utilisateurs.

Une fois rempli, le formulaire doit être signé 61 par la personne habilitée. A cet effet, la personne habilitée doit introduire sa carte à microprocesseur 6 dans un lecteur 8 prévu à cet effet, connecté à l'ordinateur 4. L'ordinateur 4 comprend un logiciel applicatif permettant notamment de signer un document, ce logiciel étant conçu pour extraire une partie du document à signer, par exemple une

"empreinte"du document extraite à l'aide d'une fonction de hash (par exemple MD5-Message Digest 5) et d'adresser à la carte 6 une demande de signature contenant la partie ainsi extraite, et éventuellement la date courante. La carte 6 fournit en réponse une signature élaborée à l'aide d'une clé privée Kpr connue de la carte seule et mémorisée dans la zone mémoire protégée 65, la signature ainsi générée contenant les informations suivantes : - un numéro d'ordre, - la date de signature fournie par l'ordinateur 4, et - la partie extraite du document.

Le numéro d'ordre correspond par exemple au nombre de signatures générées par la carte 6, ce numéro étant incrémenté à chaque fois que la carte émet une nouvelle signature.

<Desc/Clms Page number 12>

Ces informations peuvent également comprendre un certificat de la clé publique Kpu (correspondant à la clé Kpr utilisée pour générer la signature) de la personne habilitée, comportant l'identifiant d'utilisateur Id et une clé publique, stockés dans la carte, le certificat étant établit en signant la clé publique avec la clé Kr du serveur de certificats 3.

L'ensemble de ces informations est chiffré par la carte 6 à l'aide de la clé privée Kpr stockée dans la zone 65 et correspondant à la clé publique Kpu contenue dans le certificat, le résultat du chiffrement constituant la signature du formulaire.

La carte 6 délivre la signature de la personne habilitée à l'ordinateur 4, lequel transmet 42 au serveur d'administration 1 le formulaire 41 associé à la signature et à l'identifiant de la personne habilitée. Cette transmission peut être effectuée de manière synchrone ou asynchrone sous la forme d'un message électronique.

Le serveur d'administration 1 qui reçoit un tel message, authentifie le formulaire en contrôlant la signature associée et s'assure que le signataire du formulaire possède les droits requis pour attribuer une carte, d'après les informations correspondant à celui-ci dans l'annuaire 2. Ensuite, il s'assure de l'unicité de l'identifiant attribué au nouvel utilisateur dans le formulaire, également en consultant l'annuaire 2. Si ces contrôles ne font pas apparaître d'anomalies, il procède à l'inscription 11 du nouvel utilisateur en introduisant les informations du formulaire 41 dans la base de données 2, puis en générant un message de personnalisation du nouvel utilisateur.

Un tel message comprend notamment les informations suivantes : - des informations relatives à l'identité du nouvel utilisateur, - des informations relatives à la date de création de la carte, et - des informations relatives à l'identité de la personne ayant attribué la carte au nouvel utilisateur - et éventuellement des informations relatives aux droits accordés au nouvel utilisateur.

Le serveur d'administration 1 calcule ensuite la clé Pa de la carte 7 attribuée, à l'aide du numéro de série NS de la carte introduite dans le formulaire 41 et de la clé maître de pilotage d'administration Paffi, et utilise cette clé Pa pour chiffrer et sceller le message de personnalisation. A la différence d'une signature qui

<Desc/Clms Page number 13>

applique un algorithme de chiffrement asymétrique à un extrait du document à signer, par exemple obtenu à l'aide d'une fonction de Hash, un scellement

consiste à appliquer à un tel extrait de document un algorithme de chiffrement symétrique. Le chiffrement permet de garantir la confidentialité des informations et le sceau, leur intégrité.

Une fois chiffré et scellé, le message est adressé à la boite à lettres électronique du nouvel utilisateur telle qu'indiquée dans le formulaire.

De son côté, le nouvel utilisateur à qui on a préalablement remis la carte 7 non personnalisée et présentant le numéro de série NS qui a été inséré dans le formulaire, doit accéder à sa messagerie électronique à l'aide d'un ordinateur 5 pour prendre le message envoyé par le serveur d'administration 1, introduire la carte 7 dans un lecteur 8 prévu à cet effet, connecté à l'ordinateur 5, et s'identifier auprès de la carte, par l'introduction d'un mot de passe qui lui a été communiqué lors de la remise de la carte.

Il est à noter que ce mot de passe n'était auparavant pas actif puisque la carte correspondante n'était pas utilisable.

L'ordinateur 5 qui est équipé du logiciel applicatif mentionné ci-avant et d'un lecteur 8 de carte à microprocesseur, transmet 51 à la carte 7 une commande de personnalisation associée au message de personnalisation chiffré et scellé, reçu et à un extrait du message chiffré. A la réception d'une telle commande, la carte vérifie le sceau contenu dans le message à l'aide de la clé Pa stockée dans la carte. Cette procédure consiste à déchiffrer le sceau à l'aide de la clé Pa pour récupérer un extrait du document transmis et à comparer l'extrait de document ainsi obtenu avec un extrait de document calculé à partir du document, transmis avec la commande de personnalisation. Si le sceau est correct, elle déchiffre le message à l'aide de la clé Pa et insère 72 les informations ainsi déchiffrées dans la mémoire de la carte.

L'utilisation de la clé Pa pour mettre à jour les informations de personnalisation stockées dans la carte permet de garantir que seule la carte possédant la clé Pa peut recevoir ces informations.

A la fin de cette étape 72, la carte est personnalisée, c'est-à-dire qu'elle contient au moins l'identifiant Id de l'utilisateur, tel que spécifié dans le formulaire 41 et stocké dans l'annuaire 2, et éventuellement des informations concernant les droits accordés à l'utilisateur.

<Desc/Clms Page number 14>

On peut prévoir un mécanisme complémentaire au niveau de la carte 7 permettant d'interdire par la suite toute nouvelle exécution d'une telle commande de personnalisation. Par exemple, le serveur d'administration est conçu pour numéroter tous les messages émis et inséré ce numéro dans le message, et la carte étant conçue pour vérifier que le numéro d'un message reçu est strictement supérieur au numéro du dernier message présenté.

A la fin du traitement de personnalisation 72, la carte confirme la bonne exécution de la commande en envoyant un code de retour à l'ordinateur 5 de l'utilisateur, ce dernier pouvant lui-même avertir le serveur d'administration 1 de cette bonne exécution. On peut alors prévoir que le serveur d'administration accède à la base de données d'annuaire 2 pour y introduire, en association avec les informations concernant le titulaire de la carte, une information d'acquittement d'inscription ou de personnalisation.

La procédure d'attribution de carte qui vient d'être décrite permet de garantir le lien entre une carte attribuée et les informations d'identification d'utilisateur qu'elle contient, et ce de manière automatique, sans avoir fait intervenir une autorité tierce, mis à part la personne habilitée à attribuer des cartes. Par ailleurs, dans cette procédure d'attribution de carte, la décision d'inscription d'informations d'identification d'utilisateur a été prise par la carte et sous le contrôle du titulaire de la carte, lorsque celle-ci a reçu un message de personnalisation cohérent avec sa clé d'administration Pa. En outre, la carte d'une part et les informations d'identification à insérer dans la carte d'autre part ont été transmises à l'utilisateur par deux canaux différents, ce qui réduit les risques d'interception.

Tel que représenté sur la figure 3, pour obtenir un certificat, l'utilisateur doit introduire sa carte 7 dans le lecteur 8 relié à son ordinateur 5 et activer 53 une demande de certificat à l'aide d'une fonction prévue par le logiciel applicatif installé dans la mémoire de l'ordinateur. Cette demande de certificat, sans aucune autre information, est transmise à la carte 7 se trouvant dans le lecteur, laquelle active la génération 73 d'un couple de clés Kpr, Kpu constitué d'une clé publique Kpu et d'une clé privée Kpr qui est stockée dans une zone protégée 75 de la mémoire de la carte.

De cette manière, on a construit un couple identifiant/clé publique au sein d'une carte à microprocesseur 7 dans laquelle l'identifiant est introduit avant les clés. Une telle carte établit donc de manière sûre le lien entre un identifiant de

<Desc/Clms Page number 15>

personne et une clé publique, et ce sans avoir fait intervenir une autorité d'enregistrement. La carte ainsi personnalisée peut maintenant être utilisée pour obtenir des clés de chiffrement et de signature, ainsi que des certificats garantissant le lien entre un identifiant Id de personne et une clé publique.

A cet effet, la carte construit un message de requête de certificat dans lequel elle inscrit l'identifiant d'utilisateur, mémorisé dans la carte et la clé publique qu'elle vient de générer. Ensuite elle chiffre et scelle le message à l'aide de sa clé Ke, et envoie le message ainsi chiffré et scellé, associé à son numéro de série NS, à l'ordinateur 5, lequel transmet 54 au serveur de certificat 3 une requête de certificat contenant les informations reçues de la carte 7. La requête de certificat peut être également émise de manière synchrone ou asynchrone.

La carte peut mémoriser un compteur de demandes de certificats qui est incrémenté à chaque demande, la valeur de ce compteur étant intégrée dans le message émis par la carte.

Le serveur de certificat 3 qui reçoit un tel message de requête de certificat authentifie la demande. A cet effet, il recalcule la clé Ke à l'aide du numéro de série NS contenu dans le message de requête et de la clé maître Ka"'. A l'aide de cette clé, le serveur 3 peut ensuite authentifier le sceau et déchiffrer le message émis par la carte 7 pour obtenir la clé publique et l'identifiant contenus dans celui-ci.

Le serveur 3 peut vérifier que le demandeur du certificat est autorisé à obtenir un certificat. A cet effet, il accède à l'annuaire 2 à l'aide de l'identifiant reçu, pour consulter les droits attribués au demandeur, et détermine en fonction des droits attribués au demandeur et éventuellement du numéro d'ordre de demande de certificat reçu, si le demandeur peut recevoir un nouveau certificat. Le serveur 3 peut également vérifier dans l'annuaire que l'acquittement d'inscription ou de personnalisation a bien été reçu, ce qui constitue une sécurité supplémentaire.

Si ces conditions sont satisfaites, le serveur 3 procède à la génération 33 du certificat, en calculant une signature portant sur l'identifiant du demandeur et la clé publique générée par la carte 7, se trouvant dans le message reçu, à l'aide de la clé racine Kr. Le certificat ainsi généré est envoyé à l'utilisateur qui a émis la requête, et stocké dans l'annuaire 2 pour permettre aux autres utilisateurs de vérifier une signature. L'envoi du certificat au demandeur peut également être

<Desc/Clms Page number 16>

effectue de manière asynchrone en étant inséré dans un message qui est transmis par messagerie électronique au demandeur dont l'identifiant de boite à lettre figure dans l'annuaire 2.

A la réception 55 d'un tel message, l'ordinateur 5 mémorise le certificat ainsi reçu et peut le transmettre à la carte 7 qui le stocke dans sa mémoire en vue d'être inséré dans les documents à signer.

Un tel certificat peut ensuite être utilisé d'une manière connue pour générer une signature certifiée d'un document, une telle signature certifiée étant obtenue par un calcul de signature appliqué à l'extrait de document à signer, préalablement associé au certificat.

Une telle procédure peut être appliquée lors de l'étape 61 de signature du formulaire d'inscription d'un nouvel utilisateur.

Il est à noter que dans le système qui vient d'être décrit, le processus de gestion des attributions de cartes est séparé du processus de génération de certificats. Il en est de même de l'entité assurant l'attribution des cartes, à savoir le serveur d'administration et l'entité assurant la délivrance des certificats : le serveur de certificats, les deux serveurs utilisant des clés distinctes. Par une telle séparation des connaissances entre deux composants distincts, on renforce la sécurité : aucun composant du système ou personne de la communauté ne dispose à la fois du pouvoir d'administration et de certification.

Par ailleurs, à chaque fois qu'une demande de certificat lui est envoyée, le serveur de certificat 3 vérifie dans l'annuaire 2 que les droits attribués au demandeur du certificat permettent de répondre à une telle demande, et que la carte est toujours valide (date de fin de validité non dépassée).

D'une manière générale, à chaque accès à la carte 6,7 que ce soit pour personnaliser la carte, demander un certificat, signer ou chiffrer un document, l'utilisateur doit s'identifier auprès de la carte. Une telle procédure d'identification consiste d'une manière classique à introduire un mot de passe, l'accès à la carte étant bloqué à la suite de trois erreurs de saisie de mot de passe.

En outre, chaque carte 6,7 peut mémoriser une date de fin de validité qui est

er*fi vérifiée à chaque accès à la carte, l'ordinateur auquel elle est connectée pour un

<Desc/Clms Page number 17>

accès lui transmettant une date courante qu'elle peut comparer à cette date de fin de validité. Si cette date est dépassée, la carte se bloque. En outre, on peut prévoir de mémoriser la date courante qui est transmise par l'ordinateur lors de chaque accès et de comparer cette date courante avec la date courante transmise lors de l'accès précédent. Si la date courante est antérieure à la date de l'accès précédent, on considère que l'accès en cours est une tentative de fraude et la carte refuse d'exécuter la commande.

On peut également prévoir une procédure de mise à jour des droits attribués à une carte, telle que la date de fin de validité mémorisée par une carte. Cette procédure se déroule d'une manière analogue à celle qui effectue la personnalisation d'une carte, illustrée par la figure 2.

Une personne habilitée disposant d'une carte à microprocesseur contenant les droits nécessaires peut commander la mise à jour des droits d'une autre carte à microprocesseur d'un utilisateur de la communauté. A cet effet, la personne habilitée signe à l'aide de sa carte (clé Kpr) une demande de mise à jour de droits, contenant l'identifiant de la personne en possession de la carte à mettre à jour ou le numéro de série de cette dernière, que l'on peut trouver dans l'annuaire 2, et les nouveaux droits à insérer dans la carte. La demande chiffrée et signée accompagnée du numéro NS de la carte de la personne habilitée est transmise au serveur d'administration 1 qui authentifie la demande à l'aide de la clé Kpu correspondant à la clé Kpr de la carte et trouvée dans l'annuaire 2. Si la personne ayant émis la demande de mise à jour possède les droits nécessaires, le serveur 1 construit un message de mise à jour contenant les nouveaux droits attribués à la carte, et chiffre et scelle ce message à l'aide de la clé Pa de la carte à mettre à jour, qui est déterminée en chiffrant le numéro NS de la carte à l'aide de la clé Pa. Le message chiffré et scellé est ensuite transmis au titulaire de la carte à mettre à jour. La réception d'un tel message sur le terminal de l'utilisateur déclenche une procédure de mise à jour de la carte reliée au terminal. Si la clé Pa de la carte reliée au terminal correspond à la clé Pa utilisée par le serveur d'administration pour chiffrer et sceller le message de mise à jour, la carte effectue la mise à jour demandée.

La carte est conçue pour refuser elle-même d'exécuter une requête en dehors des droits qui lui ont été préalablement attribués. Cette disposition permet de diffuser des cartes dont la durée de validité et d'activité est limitée, et cela sans avoir à faire appel à une gestion complexe des cartes, notamment dans le cas d'organisations décentralisées (constituées d'entités reliées entre elles par des

<Desc/Clms Page number 18>

réseaux de communication publics). En outre, elle permet le remplacement quasi immédiat d'une carte perdue ou volée dont la date de fin de validité peut être mise à jour à distance, dès que la carte est utilisée.

Par ailleurs, la mise en oeuvre de fonctions de confidentialité (chiffrement) repose sur des mécanismes identiques à la signature : seul le possesseur de la clé (privée) de déchiffrement peut déchiffrer les documents qui ont été chiffrés à l'aide de la clé publique correspondant à la clé privée. Il en résulte qu'en cas de perte d'une carte qui seule mémorise la clé de déchiffrement, il est impossible de déchiffrer de tels documents, en particulier s'il n'existe plus de version non chiffrée de ces documents.

Pour résoudre ce problème, l'invention propose la mise en place d'un mécanisme tel que celui illustré sur la figure 4. Sur cette figure, les clés de signature et de chiffrement/déchiffrement utilisées par les cartes sont distinctes, la clé de chiffrement/déchiffrement étant générée hors de la carte, par exemple par le serveur de certificats 3 ou par un serveur de clés spécifique. Dans ce dernier cas, il faut prévoir une troisième clé secrète, en plus des clés Pa et Ke (respectivement Pa, Ke).

L'utilisateur souhaitant obtenir des clés de chiffrement/déchiffrement introduit sa carte 7 dans le lecteur 8 connecté à un terminal 5, active dans le logiciel applicatif une fonction de demande de clés de chiffrement. Cette fonction émet 57 à destination de la carte 7 reliée au terminal 5 une demande de clés. La carte qui reçoit une telle demande, vérifie 76 que le titulaire de la carte possède les droits nécessaires pour obtenir de telles clés, et construit un message de demande de clés contenant le numéro de la carte NS et éventuellement un numéro d'ordre, puis scelle le message avec sa clé d'administration Ke. Le terminal 5 qui reçoit un tel message le retransmet 58 à un serveur de clés, par exemple le serveur de certificats 3, d'une manière synchrone ou asynchrone.

Le serveur 3 qui reçoit un tel message authentifie la demande de clés en déterminant la clé Ke à l'aide du numéro de carte NS contenu dans le message et de la clé Kem pour vérifier le sceau. Puis il génère 32 une paire de clés Klpr/K1pu. Il génère 33 ensuite un certificat portant sur la clé publique Klpu, ce certificat étant stocké dans l'annuaire avec les informations relatives au numéro de carte reçu. Et enfin, il chiffre et scelle 34 la clé privée Klpr à l'aide de la clé Ke, cette clé privée chiffrée et scellée étant ensuite stockée dans un

<Desc/Clms Page number 19>

annuaire de séquestre qui peut être l'annuaire 2, et transmise à la carte de l'utilisateur par l'intermédiaire du terminal 5, par exemple sous la forme d'un message électronique.

Le terminal 5 qui reçoit un tel message, transfère 59 la clé privée Klpr scellée et chiffrée à la carte 7, laquelle authentifie le sceau et déchiffre la clé privée, à l'aide de sa clé d'administration Ke. Si la clé privée reçue est authentifiée, la carte stocke celle-ci dans une zone mémoire protégée 75.

Pour permettre à une autre personne d'utiliser une clé privée de chiffrement/déchiffrement sous séquestre, la procédure illustrée sur la figure 5 est exécutée. Dans cette procédure, la personne habilitée et souhaitant déléguer sa clé privée de chiffrement/déchiffrement introduit 81 une demande de délégation au moyen d'un terminal 5 relié à sa carte 7. Une telle demande contient l'identifiant du destinataire de la délégation et la durée de la délégation.

La carte 7 vérifie 78 les droits du demandeur de la délégation, et si le demandeur possède les droits suffisants, construit une requête de délégation à partir des informations fournies par la personne. Cette requête est chiffrée et scellée à l'aide de la clé Kel de la carte et associée au numéro NS1 de la carte 7.

Puis, cette requête est transmise au terminal 5 qui la transmet 82 au serveur de certificats 3.

Le serveur de certificat 3 vérifie 35 la requête en déterminant la clé Kel à l'aide du numéro NS, de la carte émettrice de la requête et de la clé Ke, puis en contrôlant le sceau à l'aide de la clé Kel. A l'étape suivante 36, le serveur 3 accède à la clé Klpr chiffrée sous séquestre mémorisée dans l'annuaire 2, déchiffre cette clé à l'aide de la clé Kel, puis chiffre 37 cette clé à l'aide de la clé Ke2 de la carte destinatrice 6 de la délégation, déterminée à partir du numéro NS2 de la carte 6 trouvée dans l'annuaire 2 à partir de l'identifiant du destinataire de la délégation. La clé Klpr chiffrée est insérée dans un message qui est chiffré à l'aide de la clé Ke2 ou la clé publique K2pu du destinataire, et qui est envoyé au destinataire. Le terminal 4 recevant un tel message le retransmet 49 à la carte 6 qui déchiffre le message, déchiffre la clé privée Klpr reçue à l'aide de la clé Ke2 et mémorise celle-ci dans sa mémoire protégée 65.

L'utilisateur dispose alors de deux clés privées Klpr et K2pr qui sont stockées dans la carte 6, sans qu'il ait pu en prendre connaissance, la clé Klpr ne pouvant être utilisée que pour effectuer un déchiffrement.

<Desc/Clms Page number 20>

Il est à noter qu'une carte peut ainsi recevoir plusieurs clés de chiffrement/déchiffrement. Dans ce cas, à chaque fois que l'utilisateur commande à la carte une telle opération, la carte transmet au terminal 4 une liste contenant les références des clés privées dont elle dispose en demandant la sélection d'une des clés de la liste.

Claims (20)

REVENDICATIONS

1. Procédé pour établir automatiquement un lien fiable entre une clé publique de chiffrement et/ou de signature et l'identité d'un utilisateur appartenant à une communauté, caractérisé en ce qu'il comprend une phase d'attribution d'une carte à microprocesseur (6,7) respectivement à chaque utilisateur de la communauté, chaque carte comportant une zone mémoire protégée (65,75) dans laquelle est mémorisée au moins une clé secrète (Pa, Ke), la phase d'attribution d'une carte (7) à un nouvel utilisateur de la communauté comprenant les étapes consistant à : - introduire des informations d'identification du nouvel utilisateur et de la carte à attribuer, - générer une signature (61) portant sur les informations d'identification du nouvel utilisateur à l'aide d'une clé (Kpr) mémorisée dans une carte à microprocesseur (6) déjà attribuée à un utilisateur appartenant à la communauté, - transmettre (42) à un serveur d'administration (1) les informations d'identification introduites, associées à la signature, - sur le serveur d'administration, vérifier la signature, et si la signature est correcte, introduire (11) les informations d'identification dans une base de données d'annuaire (2), construire un message de personnalisation contenant les informations d'identification du nouvel utilisateur, chiffrer et sceller le message de personnalisation à l'aide d'une clé secrète (Pa) stockée dans une zone mémoire protégée de la carte à attribuer (7) et susceptible d'être déterminée par le serveur d'administration, et transmettre le message de personnalisation à destination de la carte à attribuer, - dans la carte à attribuer, recevoir le message de personnalisation, vérifier le sceau, et si le sceau est correct, déchiffrer le message et stocker (71) dans la mémoire de la carte les informations d'identification d'utilisateur ainsi déchiffrées.

2. Procédé selon la revendication 1, caractérisé en ce que la vérification de signature par le serveur d'administration (1) est suivie d'une étape de vérification de droits du signataire, les étapes d'introduction des informations d'identification et de construction du message de personnalisation étant effectuées uniquement si le signataire possède les droits nécessaires.

<Desc/Clms Page number 22>

3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comprend une étape de génération (73) de clés de chiffrement/déchiffrement et/ou de signature (Kpr, Kpu), par une carte à microprocesseur (7) attribuée à un utilisateur de la communauté.

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que la clé secrète (Pa) stockée dans une carte à microprocesseur (6, 7) est déterminée par le serveur d'administration (1) en appliquant un algorithme de chiffrement à un numéro d'identification (NS) de la carte à microprocesseur à l'aide d'une clé secrète (paID) connue seulement du serveur d'administration.

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que le message de personnalisation contenant les informations d'identification introduites dans la carte à microprocesseur, comprend en outre des informations définissant des droits attribués à la carte, ces informations étant également mémorisées par la carte, une requête transmise à la carte étant exécutée par celle-ci uniquement si elle est autorisée conformément aux droits attribués à la carte.

6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il comprend une phase de génération d'un certificat comprenant des étapes consistant à : - générer (73) par une carte (6, 7) attribuée à un utilisateur de la communauté une paire de clés (Kpr, Kpu) de chiffrement/déchiffrement et/ou de signature comprenant une clé publique (Kpu) et une clé privée (Kpr) qui est stockée dans une zone protégée (65, 75) de la mémoire de la carte, - construire par la carte un message de demande de certificat comprenant la clé publique (Kpu) stockée dans la carte et au moins une information d'identification de l'utilisateur de la carte, stockée dans la carte, - chiffrer et sceller par la carte le message de demande de certificat à l'aide d'une clé secrète (Ke) stockée dans une zone mémoire protégée (65, 75) de la carte, - transmettre le message de demande de certificat chiffré et scellé, à un serveur de certificats (3), - dans le serveur de certificat, recevoir le message de demande de certificat et en vérifier le sceau à l'aide de la clé secrète (Ke) stockée dans la carte et

<Desc/Clms Page number 23>

susceptible d'être déterminée par le serveur de certificat, et si le sceau est correct, déchiffrer le message de demande de certificat à l'aide de la clé secrète et générer un certificat comportant l'information d'identification et la clé publique (Kpu) contenue dans le message de demande de certificat, ces informations étant scellées par le serveur de certificat à l'aide d'une clé privée (Kr) connue uniquement du serveur de certificat.

7. Procédé selon la revendication 6, caractérisé en ce que la clé secrète (Pa) stockée dans la carte (6,7) et susceptible d'être déterminée par le serveur d'administration (1) est différente de la clé secrète (Ke) stockée dans la carte et susceptible d'être déterminée par le serveur de certificats (3).

8. Procédé selon la revendication 6 ou 7, caractérisé en ce que la clé secrète (Ke) stockée dans une carte à microprocesseur (6,7) d'un utilisateur de la communauté est déterminée par le serveur certificats (3) en appliquant un algorithme de chiffrement à un numéro d'identification (NS) de la carte à microprocesseur à l'aide d'une clé secrète (Keffi) connue seulement du serveur de certificats.

9. Système pour établir automatiquement un lien fiable entre une clé publique de chiffrement et/ou de signature, et l'identité d'un utilisateur appartenant à une communauté, chaque utilisateur de la communauté disposant d'une carte à microprocesseur personnelle (6,7), caractérisé en ce que chaque carte à microprocesseur d'utilisateur de la communauté comprend : - des moyens de chiffrement et de déchiffrement, - des moyens de génération et de contrôle de signature de documents numériques,

- des moyens de génération de clés de chiffrement/déchiffrement et/ou de signature (Kpr, Kpu), et - des moyens de mémorisation comportant au moins une zone mémoire protégée (65,75) dans laquelle est stockée au moins une clé secrète (Pa, Ke) spécifique de la carte et une clé privée (Kpr) générée par les moyens de génération de clés, et une zone mémoire dans laquelle sont stockées des informations d'identification de l'utilisateur, le système comprenant en outre un serveur d'administration (1) connecté à un réseau (10) de transmission de données numériques et comprenant :

<Desc/Clms Page number 24>

- des moyens pour recevoir du réseau (10) et authentifier un formulaire d'inscription (41) d'un nouvel utilisateur contenant des informations d'identification du nouvel utilisateur, préalablement signé à l'aide des moyens de signature d'une carte à microprocesseur (6) d'un utilisateur de la communauté, - des moyens pour construire un message de personnalisation contenant les informations d'identification du formulaire d'inscription, - des moyens pour chiffrer et sceller le message de personnalisation à l'aide de la clé secrète (Pa) mémorisée par une carte à microprocesseur (7) remise à un nouvel utilisateur et connue du serveur d'administration, et - des moyens pour transmettre le message de personnalisation chiffré et scellé vers la carte du nouvel utilisateur, chaque carte à microprocesseur comportant en outre des moyens de personnalisation conçus pour recevoir, authentifier et déchiffrer un message de personnalisation, et stocker les informations d'identification (Id) contenues dans le message de personnalisation déchiffré dans la mémoire de la carte.

10. Système selon la revendication 9, caractérisé en ce qu'il comprend une base de données d'annuaire (2) connectée au serveur d'administration (1), et dans laquelle sont stockées les informations d'identification de chaque utilisateur de la communauté, en association avec un numéro d'identification de la carte à microprocesseur attribuée à l'utilisateur.

11. Système selon la revendication 10, caractérisé en ce que chaque carte à microprocesseur (6,7) mémorise des informations de droits attribués à la carte, transmises dans le message de personnalisation reçu, ces droits comprenant un droit d'attribuer une carte à microprocesseur à un nouvel utilisateur, la carte comprenant des moyens pour traiter une requête reçue uniquement si la requête satisfait aux droits attribués à la carte.

12. Système selon la revendication 11, caractérisé en ce que chaque carte à microprocesseur (6,7) comporte des moyens pour authentifier une requête émise par le serveur d'administration (1) pour mettre à jour les informations de droits attribués à l'utilisateur, mémorisées dans la carte, et pour mettre à jour ces informations dans la mémoire de la carte si ces informations sont authentiques.

<Desc/Clms Page number 25>

13. Système selon l'une des revendications 9 à 12, caractérisé en ce que chaque carte à microprocesseur (6,7) attribuée à un utilisateur de la communauté comprend des moyens pour empêcher qu'une même commande transmise à la carte soit exécutée plusieurs fois.

14. Système selon l'une des revendications 9 à 13, caractérisé en ce que le serveur d'administration (1) est connecté au réseau (10) de manière à pouvoir communiquer uniquement par message électronique.

15. Système selon l'une des revendications 9 à 14, caractérisé en ce qu'il comprend un serveur de certificats (3) connecté au réseau (10) et conçu pour émettre des certificats garantissant le lien entre une clé publique de chiffrement et/ou de signature (Kpu) et l'identité d'un utilisateur, ces informations étant stockées dans une carte à microprocesseur (6,7) attribuée à chaque utilisateur de la communauté.

16. Système selon la revendication 15, caractérisé en ce que chaque carte à microprocesseur (6,7) d'utilisateur de la communauté comprend des moyens pour générer une demande de certificat chiffrée et scellée à l'aide d'une secrète (Ke), contenant la clé publique (Kpu) et les informations d'identification de l'utilisateur, stockées dans la carte, et pour émettre la demande de certificat vers le serveur de certificats (3), le serveur de certificats comprenant des moyens pour recevoir et authentifier des demandes de certificats à l'aide la clé (Ke), et pour générer un certificat contenant les informations reçues et déchiffrées, associées à un sceau du serveur de certificats généré à partir des informations reçues et déchiffrées et d'une clé secrète (Kr).

17. Système selon la revendication 15 ou 16, caractérisé en ce que le serveur de certificats (3) est connecté au réseau (10) de manière à pouvoir communiquer uniquement par message électronique.

18. Système selon l'une des revendications 9 à 17, caractérisé en ce que chaque carte à microprocesseur (6,7) d'utilisateur de la communauté comprend des moyens pour recevoir une clé privée (Klpr) chiffrée à l'aide la clé secrète (Pa, Ke) mémorisée par la carte, et des moyens pour déchiffrer et stocker la clé privée reçue et déchiffrée dans une zone mémoire protégée (65,75) de la carte.

<Desc/Clms Page number 26>

19. Système selon la revendication 18, caractérisé en ce que la clé privée reçue (Klpr) par une carte (6,7) est utilisable exclusivement pour chiffrer/déchiffrer des documents, tandis que la clé privée (Kpr) générée par la carte n'est utilisable que pour signer un document.

20. Système selon la revendication 18 ou 19, caractérisé en ce que les clés privées (Klpr) susceptibles d'être transmises aux cartes (6,7) sont générées par un serveur (3) à la demande d'une carte (6,7), le serveur comprenant des moyens pour générer une clé privée à la demande d'une carte, pour chiffrer la clé privée générée à l'aide d'une la clé secrète (Ke) de la carte déterminée par le serveur, pour stocker et transmettre à la carte la clé privée chiffrée.