Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR GENERATING A DIGITAL CERTIFICATE
Document Type and Number:
WIPO Patent Application WO/2011/030069
Kind Code:
A1
Abstract:
The invention relates to a method for generating a signed certificate for verifying a service group signature of a service message, said service group comprising a member who also belongs to a certification group for which a certification group signature is defined, said member having a private key for the service group and a private key for the certification group, said method including a step of generating a service group signature based on the message, said generated signature including a first portion and a second portion, a step of creating the digital certificate associated with a public key corresponding to the first portion of the generated service group signature, and defining as an algorithm associated with the certified public key an algorithm for verifying the service group signature, a step of signing the digital certificate.

Inventors:
CANARD SEBASTIEN (FR)
ABED AYMEN (FR)
Application Number:
PCT/FR2010/051886
Publication Date:
March 17, 2011
Filing Date:
September 10, 2010
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
FRANCE TELECOM (FR)
CANARD SEBASTIEN (FR)
ABED AYMEN (FR)
International Classes:
H04L9/32
Domestic Patent References:
WO2003061193A12003-07-24
Foreign References:
EP1786139A12007-05-16
EP0804003A21997-10-29
Other References:
S. CANARD; M. GIRAULT: "Proceedings of Fifth Smart Card Research and Advanced Application Conférence, CARDIS '02", 2002, USENIX PUBLISHER, article "Implementing Group Signature Schemes with Smart Cards", pages: 1 - 10
Download PDF:
Claims:
REVENDICATIONS

1. Procédé de génération d'un certificat numérique signé pour vérifier une signature anonyme de groupe de service d'un message de service (m), ledit groupe de service (Gs) comportant un membre (Uj) qui appartient également à un groupe de certification (Gc) pour lequel est définie une signature anonyme de groupe de certification, ledit membre disposant d'une clé privée (ssk) de groupe de service et d'une clé privée (SSK) de groupe de certification le procédé comprenant :

- une étape (12-1 ) de génération par le membre au moyen de la clé privée de groupe de service d'une signature de groupe de service (km, sm) à partir du message (m), ladite signature générée comprenant une première partie (km) et une deuxième partie (sm),

- une étape (12-2) de création du certificat numérique associé à une clé publique correspondant à la première partie (km) de la signature de groupe de service générée, et définissant comme algorithme associé à la clé publique certifiée un algorithme pour vérifier la signature de groupe de service,

- une étape (12-3) de signature du certificat numérique par le membre avec la clé privée de groupe de certification.

2. Procédé selon la revendication 1 , comprenant en outre :

- une étape (1 -1 ) d'enregistrement du membre auprès d'une Autorité de Certification, l'étape comprenant :

- une sous-étape (1 1 -1 a) d'envoi de données personnelles d'identification du membre,

- une sous-étape (1 1 -1 b) d'enrôlement du membre dans le groupe de certification, au cours de laquelle le membre reçoit la clé privée (SSK) de groupe de certification.

3. Procédé de génération selon la revendication 1 , comprenant en outre :

- une étape (12-4) d'envoi à un fournisseur de service d'une donnée comprenant le message (m) de service, la deuxième partie de la signature de groupe de service (sm) et le certificat numérique signé ((M, ∑ )).

4. Procédé selon la revendication 1 , dans lequel le certificat comprend comme nom de titulaire du certificat une donnée de substitution.

5. Procédé de vérification d'une signature anonyme de groupe d'un message de service au moyen d'un certificat numérique généré selon la revendication 1 , le certificat certifiant une clé publique correspondant à une première partie de la signature du message, et d'une deuxième partie de la signature, comprenant :

- une étape (13-1 ) de vérification de la signature du certificat au moyen de la clé publique, - une étape (13-3) de vérification de la deuxième partie de la signature de service du message au moyen de la clé publique certifiée.

6. Dispositif (20) de génération d'un certificat numérique signé pour vérifier une signature anonyme de groupe de service d'un message de service (m), le dispositif comprenant :

- une mémoire (201 , 202) adaptée pour mémoriser une clé privée (ssk) de groupe de service et une clé privée (SSK) de groupe de certification,

- un module (205) de génération de signature de groupe de service, adapté pour générer une signature de groupe de service (km, sm) à partir du message (m) au moyen de la clé privée de groupe de service, ladite signature générée comprenant une première partie (km) et une deuxième partie (sm),

- un module (206) de création du certificat numérique, adapté pour créer un certificat numérique associé à une clé publique correspondant à la première partie (km) de la signature de groupe de service générée, et définissant comme algorithme associé à la clé publique certifiée un algorithme pour vérifier la signature de groupe de service,

- un module (207) de signature, adapté pour signer le certificat numérique créé au moyen de la clé privée de groupe de certification.

7. Dispositif (30) de vérification d'une signature anonyme de groupe d'un message de service au moyen d'un certificat numérique généré selon la revendication 1 , le certificat certifiant une clé publique correspondant à une première partie de la signature du message, et d'une deuxième partie de la signature, comprenant :

- un module (303) de vérification de la signature du certificat au moyen de la clé publique,

- un module (304) de vérification de la deuxième partie de la signature de service du message au moyen de la clé publique certifiée. 8. Programme d'ordinateur sur un support de données et chargeable dans la mémoire interne d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé de génération d'un certificat numérique signé selon l'une quelconque des revendications 1 à 4 lorsque le programme est exécuté sur ledit ordinateur. 9. Support de données sur lequel est enregistré le programme d'ordinateur selon la revendication 8.

10. Programme d'ordinateur sur un support de données et chargeable dans la mémoire interne d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé selon la revendication 5 lorsque le programme est exécuté sur ledit ordinateur.

11. Support de données sur lequel est enregistré le programme d'ordinateur selon la revendication 10.

Description:
Procédé de génération d'un certificat numérique

L'invention concerne un procédé de génération d'un certificat numérique signé pour vérifier une signature anonyme de groupe de service d'un message de service.

II est connu d'utiliser des certificats numériques dans le cadre de services accessibles depuis un réseau de communication. Les certificats numériques tiennent lieu de lien entre une entité physique, par exemple une personne ou un serveur informatique, et une entité numérique. Dans un système qui utilise de tels certificats, une Autorité de Certification fait alors foi de tiers de confiance et atteste du lien entre l'identité physique et l'entité numérique. Le standard le plus utilisé actuellement pour la création de tels certificats numériques est la norme X.509 de l'Union Internationale des Télécommunications (UIT) pour les infrastructures à clés publiques (PKI).

Un certificat X.509 est une carte d'identité numérique qui associe à l'entité physique une clé publique certifiée. Le certificat est délivré par l'Autorité de Certification au terme d'une procédure sécurisée. Une fois le certificat délivré, la clé publique qui est certifiée peut être utilisée par des services qui mettent en œuvre des fonctions de sécurité. Par exemple, un tel certificat est délivré à un utilisateur dans le cadre d'un service de signature électronique. On rappelle que la signature électronique est un mécanisme relevant de la cryptographie à clé publique : le signataire possède une clé secrète et une clé publique associée. Il produit la signature d'un message à l'aide de sa clé secrète. Le vérifieur a uniquement besoin de la clé publique pour vérifier la signature.

Un certificat numérique comprend plusieurs champs, notamment :

- l'identité de l'Autorité de Certification émettrice du certificat,

- un algorithme de signature du certificat utilisé par l'Autorité de Certification pour signer le certificat,

- une période de validité du certificat,

- le nom du titulaire du certificat,

- des informations sur la clé publique :

- algorithme à utiliser avec la clé publique,

- la clé publique proprement dite,

- la signature du certificat par l'Autorité de Certification.

- des informations optionnelles, apparues selon la version de la norme et relatives au détenteur et/ou à l'Autorité de Certification et/ou à des extensions, et

Une fois le certificat délivré, il peut être utilisé selon un cas d'usage suivant :

- l'utilisateur utilise sa clé privée, associée à la clé publique certifiée par le certificat pour signer un message, en utilisant l'algorithme de signature approprié tel que précisé dans le certificat,

- l'utilisateur envoie à un destinataire le message, la signature du message, ainsi que le certificat qui lui a été délivré pour lier son identité à la clé publique associée à la clé secrète utilisée pour effectuer la signature,

- le destinataire vérifie la validité du certificat en vérifiant la signature produite par l'Autorité de Certification, - le destinataire utilise le certificat pour vérifier l'identité du titulaire et récupérer la clé publique qui figure dans le certificat,

- le destinataire utilise cette clé publique pour vérifier la signature du message.

Cependant, il existe également des services qui intègrent une composante de protection de la vie privée des utilisateurs et qui proposent de maintenir un certain degré d'anonymat pour ces utilisateurs. De tels services peuvent utiliser par exemple une fonction cryptographique de signature anonyme de groupe. Dans un schéma classique de signature de groupe, une unique clé publique de groupe est attribuée au groupe tandis que chaque membre du groupe se voit attribuer un identifiant et une clé privée qui lui sont propres. A l'aide de sa clé privée, un membre du groupe peut produire une signature de groupe d'un message de son choix, laquelle signature peut être vérifiée par une entité quelconque à l'aide de la clé publique de groupe. La vérification apprend seulement à cette entité que la signature a été produite par un membre du groupe, mais ne lui donne aucune information sur l'identifiant du membre qui a signé. Seule une autorité de confiance dispose d'une information supplémentaire qui lui permet de retrouver l'identifiant de ce membre, et donc de lever cet anonymat à tout moment.

Dans une optique de prendre en compte un tel service de signature de groupe dans un contexte de certification, tel que les certificats X.509, il a été proposé par Benjumea, Choi, Lopez et Yung, lors de la conférence CANS 2007 une extension des certificats X.509 adaptée pour traiter les signatures de groupe. Dans cette proposition, il est généré un unique certificat par groupe, la certification consistant alors à certifier que la clé publique générale associée à l'ensemble des membres du groupe est bien valide. Ainsi, chaque membre du groupe envoie le même certificat lorsqu'il produit une signature de groupe, conservant ainsi son anonymat.

Cependant, cette solution n'est pas complètement satisfaisante puisqu'elle ne permet pas de traiter chaque membre du groupe individuellement ce qui est un des atouts de la certification. En outre, une révocation du certificat de groupe revient à révoquer tous les membres du groupe. Si la révocation est nécessaire du fait d'un seul membre du groupe, alors pour permettre aux autres membres du groupe de continuer les opérations de signature de groupe, il faut révoquer le certificat de groupe initial, puis réémettre un certificat de groupe pour le nouveau groupe constitué des membres restants, ce qui rend une telle procédure de révocation d'un membre assez lourde.

L'invention vient améliorer la situation.

En particulier, l'invention propose un procédé de génération d'un certificat numérique signé pour vérifier une signature anonyme de groupe de service d'un message de service, ledit groupe de service comportant un membre qui appartient également à un groupe de certification pour lequel est définie une signature anonyme de groupe de certification, ledit membre disposant d'une clé privée de groupe de service et d'une clé privée de groupe de certification le procédé comprenant :

- une étape de génération par le membre au moyen de la clé privée de groupe de service d'une signature de groupe de service à partir du message, ladite signature générée comprenant une première partie et une deuxième partie, - une étape de création du certificat numérique associé à une clé publique correspondant à la première partie de la signature de groupe de service générée, et définissant comme algorithme associé à la clé publique certifiée un algorithme pour vérifier la signature de groupe de service,

- une étape de signature du certificat numérique par le membre avec la clé privée de groupe de certification.

Avec le procédé selon l'invention, il devient possible d'émettre des certificats de type X.509, tels que ceux utilisés dans les infrastructures à clés publiques dans le cadre d'une signature anonyme de groupe de manière individuelle, c'est-à-dire pour chacun des membres du groupe qui participe à une opération de signature anonyme. Un certificat numérique généré selon le procédé de l'invention est associé à un membre, et non au groupe, tout en maintenant l'anonymat du membre au niveau des champs du certificat. Selon le procédé de l'invention, un certificat numérique est généré à chaque fois qu'un membre signe un message de service de manière anonyme. Le certificat généré permet de certifier une valeur km utilisée par une entité vérificatrice pour vérifier une signature anonyme de service d'un message de service. La valeur km est donc comparable à une clé publique qui est certifiée par un certificat X.509 classique. La génération du certificat repose sur deux signatures anonymes de groupes : une signature anonyme de groupe de service, qui permet à un membre d'accéder à un service, et une signature anonyme de groupe de certification, qui permet de cacher l'identité du membre titulaire du certificat généré tout en établissant un lien entre l'identité réelle de ce membre et le certificat numérique. Cette dernière caractéristique est nécessaire pour assurer une compatibilité avec des certificats numériques tels que les certificats X.509.

Dans un mode de réalisation de l'invention, le procédé comprend en outre :

- une étape d'enregistrement du membre auprès d'une Autorité de Certification, l'étape comprenant :

- une sous-étape d'envoi de données personnelles d'identification du membre,

- une sous-étape d'enrôlement du membre dans le groupe de certification, au cours de laquelle le membre reçoit la clé privée de groupe de certification.

Dans un certificat numérique X.509 classique, un lien est établi entre l'identité réelle d'une entité et son identité numérique en précisant dans un champ du certificat numérique l'identité réelle de l'entité. Avec le procédé de l'invention, le champ correspondant à l'identité réelle de l'entité n'est pas renseigné, cependant l'identité réelle de l'entité peut le cas échéant être aisément trouvée par une Autorité de Certification qui est désignée dans le certificat comme émetteur du certificat. Du fait d'un enregistrement du membre auprès de l'Autorité de Certification, au cours duquel le membre transmet ses données d'identification personnelles et du schéma de signature anonyme défini pour le groupe de certification, l'Autorité de Certification est apte à lever l'anonymat d'un membre. Ainsi, le lien entre l'identité réelle et l'identité numérique du membre est bien établie au moyen du certificat numérique.

Dans un mode de réalisation de l'invention, le procédé comprend aussi :

- une étape d'envoi à un fournisseur de service d'une donnée comprenant le message de service, la deuxième partie de la signature de groupe de service et le certificat numérique signé. Le champ correspondant à l'identité réelle du titulaire du certificat est présent, conformément à un certificat numérique X.509 classique et est renseigné par une valeur de substitution de l'identité réelle du membre. L'anonymat du membre est donc garanti, ainsi que la conformité du certificat à un standard.

Dans un exemple de réalisation de l'invention, le certificat comprend comme nom de titulaire du certificat une donnée de substitution.

L'invention concerne aussi un procédé de vérification d'une signature anonyme de groupe d'un message de service au moyen d'un certificat numérique généré selon le procédé de génération de l'invention, le certificat certifiant une clé publique correspondant à une première partie de la signature du message, et d'une deuxième partie de la signature, comprenant :

- une étape de vérification de la signature du certificat au moyen de la clé publique,

- une étape de vérification de la deuxième partie de la signature de service du message au moyen de la clé publique certifiée.

Le procédé selon l'invention permet à une entité vérificatrice de vérifier un message de service signé de manière anonyme selon la signature anonyme de groupe de service au moyen du certificat numérique joint.

L'invention porte également sur un dispositif de génération d'un certificat numérique signé pour vérifier une signature anonyme de groupe de service d'un message de service, le dispositif comprenant :

- une mémoire adaptée pour mémoriser une clé privée de groupe de service et une clé privée de groupe de certification,

- un module de génération de signature de groupe de service, adapté pour générer une signature de groupe de service à partir du message au moyen de la clé privée de groupe de service, ladite signature générée comprenant une première partie et une deuxième partie,

- un module de création du certificat numérique, adapté pour créer un certificat numérique associé à une clé publique correspondant à la première partie (km) de la signature de groupe de service générée, et définissant comme algorithme associé à la clé publique certifiée un algorithme pour vérifier la signature de groupe de service,

- un module de signature, adapté pour signer le certificat numérique créé au moyen de la clé privée de groupe de certification.

L'invention concerne aussi un dispositif de vérification d'une signature anonyme de groupe d'un message de service au moyen d'un certificat numérique généré selon le procédé de génération de l'invention, le certificat certifiant une clé publique correspondant à une première partie de la signature du message, et d'une deuxième partie de la signature, comprenant :

- un module de vérification de la signature du certificat au moyen de la clé publique,

- un module de vérification de la deuxième partie de la signature de service du message au moyen de la clé publique certifiée.

L'invention porte aussi sur un programme d'ordinateur sur un support de données et chargeable dans la mémoire interne d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé de génération d'un certificat numérique signé selon l'invention lorsque le programme est exécuté sur ledit ordinateur. L'invention concerne aussi un support de données sur lequel est enregistré ce programme d'ordinateur.

L'invention concerne aussi un programme d'ordinateur sur un support de données et chargeable dans la mémoire interne d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé de vérification d'une signature anonyme selon l'invention lorsque le programme est exécuté sur ledit ordinateur. L'invention concerne aussi un support de données sur lequel est enregistré ce programme d'ordinateur.

De nombreux détails et avantages de l'invention seront mieux compris à la lecture de la description d'un exemple particulier de réalisation de l'invention en référence aux schémas annexés donnés à titre non limitatif et dans lesquels :

- la figure 1 illustre les étapes d'un procédé de génération d'un certificat numérique signé pour vérifier une signature anonyme de groupe de service d'un message de service selon un mode de réalisation de l'invention ;

- la figure 2 est une description en blocs fonctionnels d'un dispositif de génération d'un certificat signé selon l'invention ;

- la figure 3 est une description en blocs fonctionnels d'un dispositif de vérification selon l'invention. Sur la figure 1 , on a représenté un procédé de génération d'un certificat numérique signé pour vérifier une signature anonyme de groupe de service d'un message de service, selon un exemple particulier de réalisation de l'invention. Cette signature anonyme de groupe de service repose sur un schéma de signature anonyme de groupe. Ce schéma définit des éléments de base nécessaires pour mettre en œuvre une signature anonyme de groupe : des algorithmes tels qu'un algorithme de signature, un algorithme de vérification de signature, un algorithme de chiffrement, un algorithme de déchiffrement ainsi que des clés et couples de clés privée/publique utilisés par des algorithmes du schéma. Dans l'exemple décrit ici, cette signature anonyme de groupe de service s'appuie plus particulièrement sur un schéma de signature anonyme de groupe tel que décrit dans l'article "Implementing Group Signature Schemes with Smart Cards", S. Canard, M. Girault. Proceedings of Fifth Smart Card Research and Advanced Application Conférence, CARDIS '02, USENIX Publisher, pages 1 -10.2002. Ce schéma est défini pour un groupe G constitué d'une pluralité de membres Uj, 1 < < n . Un utilisateur U, qui souhaite intégrer le groupe G, autrement dit devenir membre du groupe G, s'adresse à un gestionnaire de groupe MG et reçoit, au cours d'une étape préalable d'enrôlement des données cryptographiques. Ces données, qui comprennent une clé privée de signature et permettent au membre U, de signer anonymement des messages en clair, conformément au schéma de signature de groupe anonyme. Le gestionnaire de groupe MG est apte, le cas échéant, à lever l'anonymat du membre Uj à partir d'une signature anonyme produite par ce membre. Ce schéma de signature anonyme de groupe repose sur un schéma de signature classique, par exemple "RSA" (du nom des auteurs, "River, Shamir et Adleman) ou "ECDSA" (pour "Elliptic Curve Digital Signature Algorithm") et définit :

- une fonction de signature, notée "SIGN", qui prend en entrée un message en clair m et utilise comme paramètre une clé secrète de signature ssk. La fonction SIGN produit en sortie une signature s. Ainsi, s = SIGN(m, ssk)

- une fonction de vérification de signature, notée "VERIF", qui prend en entrée un message clair m, une signature s de ce message obtenue en appliquant la fonction de signature SIGN au message m, et utilise comme paramètre une clé publique de vérification spk. La clé publique de vérification est associée à la clé secrète de signature ssk. La fonction VERIF produit en sortie la valeur 1 si la signature du message m est valide, et 0 sinon. On note cette opération VERIF(m, s, spk).

Le schéma de signature anonyme de groupe repose également sur un algorithme de chiffrement probabiliste classique, par exemple RSA ou El Gamal, et définit :

- un algorithme de chiffrement, noté "ENC", qui prend en entrée un message clair m et utilise comme paramètre une clé publique de chiffrement epk. L'algorithme de chiffrement appliqué à m et paramétré par epk produit en sortie un chiffré c. Ainsi, c = ENC(m, epk) ;

- un algorithme de déchiffrement, noté "DEC", qui prend en entrée un chiffré c produit par l'algorithme de chiffrement ENC et utilise comme paramètre une clé secrète de déchiffrement esk associée à la clé publique de chiffrement epk. L'algorithme de déchiffrement appliqué à c et paramétré par esk produit en sortie le message clair m. Ainsi, m = DEC(s, esk) ;

Dans le schéma de signature anonyme de groupe décrit ici, la clé secrète de déchiffrement esk appartient à une entité habilitée à lever l'anonymat. Pour simplifier la lecture de la demande, on considère par la suite que cette entité est le gestionnaire de groupe MG. On note cependant qu'habituellement, l'entité habilitée à lever l'anonymat est différente du gestionnaire de groupe MG. Cette entité peut par exemple être un juge. La clé publique de chiffrement associée, epk, est de fait publique et donc connue de tous les membres du groupe. Dans ce schéma de signature anonyme de groupe, la clé secrète de signature ssk est commune à tous les membres du groupe. La clé publique de vérification de signature spk associée est de fait publique et connue par toute entité susceptible de vérifier une signature anonyme de groupe produite selon le schéma de signature anonyme de groupe. Par ailleurs, chaque membre U, du groupe G détient une clé upk de membre qui lui est propre et qui permet le cas échéant de l'identifier. Ainsi, au cours de la phase d'enrôlement dans le groupe G, l'utilisateur Ui se voit attribuer par le gestionnaire de groupe MG la clé secrète de signature ssk, commune à tous les membres du groupe G, ainsi que la clé propre de membre upk.

Ensuite, une phase de signature anonyme de groupe, au cours de laquelle le membre U, signe anonymement un message clair m, se déroule selon les étapes suivantes :

1 - dans une première étape de chiffrement, l'utilisateur U, chiffre sa clé propre de membre upk à l'attention du gestionnaire de groupe MG pour obtenir une valeur c. A cette fin, l'utilisateur U, utilise l'algorithme de chiffrement ENC, paramétré par la clé publique de chiffrement epk. Cette opération est notée : c = ENC(upk, epk) ;

2- dans une deuxième étape de signature, l'utilisateur Uj signe la valeur c et le message en clair m à l'aide de l'algorithme de signature SIGN paramétré par la clé secrète de signature ssk commune à tous les membres du groupe pour obtenir une valeur s. Cette opération est notée s = SIGN(c||m, ssk), où || désigne une opération de concaténation.

La signature anonyme de groupe produite est alors un couple σ constitué des valeurs produites au cours des étapes 1 et 2 : σ = (c, s). La signature σ comprend ainsi une première partie c, propre au membre U f et une deuxième partie s, qui dépend du message clair m.

Dans une étape ultérieure de vérification de la signature anonyme de groupe, une entité vérificatrice vérifie la signature anonyme au moyen de l'algorithme de vérification VERIF appliqué à la valeur s et au message c|jm, et paramétré par la clé publique de vérification de signature spk (VERIF(s, c||m, spk)). Ainsi, la vérification de la signature de groupe consiste à vérifier la deuxième partie de la signature anonyme de groupe selon une vérification de signature classique. On remarque que le gestionnaire de groupe MG est apte à lever l'anonymat d'une signature anonyme produite par un membre du groupe. En effet, le gestionnaire MG peut déchiffrer la première partie de la signature anonyme de groupe c, obtenue au cours de la première étape de chiffrement, au moyen de la clé secrète de déchiffrement esk qu'il est seul à détenir et à obtenir ainsi la clé upk propre au membre Uj.

Le procédé de génération d'un certificat numérique signé pour vérifier une signature anonyme de groupe de service, selon un exemple particulier de réalisation de l'invention, va maintenant être décrit en relation avec la figure 1.

Dans une étape 10 de configuration initiale, il est créé un premier groupe et un deuxième groupe distincts l'un de l'autre, et notés G s et G c , destinés à contenir respectivement au moins un membre.

Le premier groupe, appelé groupe de service et noté G s , est destiné à regrouper des membres qui souhaitent accéder à un service S de manière anonyme. Un gestionnaire de groupe MG assure la gestion des membres au sein du groupe G s . et est apte à lever l'anonymat d'un membre le cas échéant. Dans cet exemple de réalisation, le gestionnaire de groupe MG est un fournisseur de service qui délivre le service S.

Le deuxième groupe G c , appelé groupe de certification, est destiné à regrouper des membres auxquels des certificats numériques sont destinés à être délivrés. Ces certificats sont destinés à être utilisés lors de l'accès anonyme du membre au service S, ils vont permettre de vérifier une signature anonyme de groupe générée à cette occasion. Un gestionnaire de groupe AC assure la gestion des membres au sein du groupe de certification et est apte à lever l'anonymat d'un membre le cas échéant. Dans cet exemple de réalisation le gestionnaire de groupe AC est une Autorité de Certification (notée par la suite AC) tel qu'on l'entend dans les infrastructures à clés publiques (appelées également "PKI", pour "Plublic Key Infrastructure") pour lesquelles sont définis classiquement des certificats numériques. Une Autorité de Certification a notamment pour fonction, après vérification de l'identité d'un demandeur, d'émettre un certificat numérique pour ce demandeur.

Pour chacun des groupes G s et G c , on définit un schéma de signature anonyme de groupe. Par exemple, ce schéma est conforme au schéma décrit précédemment. On appelle par la suite le schéma associé au groupe de service G s la "signature anonyme de service", et le schéma associé au groupe de certification G c , la "signature anonyme de certification". Dans cet exemple de réalisation, les deux schémas utilisent donc les mêmes algorithmes de signature et de chiffrement SIGN VERIF et ENC/DEC mais chaque groupe le met en oeuvre avec des clés différentes. Par exemple, on note (ssk, spk) le couple de clés privée/publique de signature et (esk, epk) le couple de clés privée/publique de chiffrement associés à la signature anonyme de service. Et l'on note (SSK, SPK) le couple de clés privée/publique de signature et (ESK, EPK) le couple de clés privée/publique de chiffrement associés à la signature anonyme de certification.

L'étape de configuration 10 n'est exécutée qu'une fois.

Dans une étape d'enrôlement 1 1 , un utilisateur U, qui souhaite accéder au service S de manière anonyme adhère au groupe de certification G c et au groupe de service G s au cours de deux sous-étapes suivantes 1 1 -1 et 1 1 -2.

Lors de la sous-étape -1 d'enregistrement et d'enrôlement, propre à l'invention, l'utilisateur U, s'enregistre auprès de l'Autorité de Certification et s'enrôle dans le groupe de certification G c afin d'obtenir des données cryptographiques de certification. Ainsi, dans une sous- étape 11 -1 a d'envoi d'informations personnelles, l'utilisateur Uj interagit avec l'AC et lui communique des données personnelles d'identification, comme par exemple ses nom, prénom, adresse, adresse e-mail. On note que dans un modèle organisationnel classique de PKI, l'entité dévolue à cette sous-étape d'enregistrement est comparable à une Autorité d'Enregistrement. Pour simplifier la lecture de la présente demande, les différents rôles habituellement définis dans une telle infrastructure sont joués ici par une seule entité : l'Autorité de Certification. Puis, dans une sous-étape 11 -1 b d'enrôlement du membre, l'utilisateur Ui reçoit de l'Autorité de Certification des données cryptographiques de certification pour mettre en œuvre la signature anonyme de certification. Les données cryptographiques comprennent la clé secrète de signature SSK, commune à tous les membres du groupe de certification G c et une clé propre de membre UPK qui permet de l'identifier le cas échéant. Par cette sous-étape 1 -1 , l'Autorité de Certification certifie que le membre est autorisé à signer un certificat. La signature de groupe de certification permet de faire le lien entre l'identité réelle du membre et son identité numérique telle que fournie par le certificat, tout en maintenant l'anonymat au niveau du certificat lui-même. En effet, l'AC avec cette sous-étape d'enrôlement, est adaptée pour le cas échéant lever l'anonymat du signataire. En ce sens, on obtient bien une gestion individuelle des certificats pour les membres du groupe tout en maintenant leur anonymat et tout en permettant une gestion des certificats conforme au standard X.509.

Lors de la sous-étape 1 1 -2 d'enrôlement dans le groupe de service G 5 , l'utilisateur Uj interagit avec le gestionnaire de groupe de service MG afin d'obtenir des données cryptographiques de service lui permettant d'accéder au service S de manière anonyme. Ces données cryptographiques de service comprennent la clé secrète de signature ssk, commune à tous les utilisateurs qui adhèrent au groupe de service G Si et une clé propre de membre upk qui permet de l'identifier le cas échéant.

L'ordre dans lequel les sous-étapes 1 1 -1 et 11 -2 sont réalisées n'est pas important. Cependant, exécuter la sous-étape 11 -1 d'enregistrement et d'enrôlement dans le groupe de certification G c préalablement à la sous-étape 11-2 d'enrôlement dans le groupe de service G s peut être exigé dans un mode particulier de réalisation de l'invention où un membre doit prouver au fournisseur de service qu'il a adhéré au groupe de certification G c préalablement à son adhésion au groupe de service G s .

Dans cet exemple de réalisation les clés propres de membres upk et UPK sont différentes.

L'étape d'enrôlement 11 est exécutée pour chaque membre qui rejoint le groupe de certification G c et le groupe de service G s .

Une troisième étape 12 de signature est exécutée lorsque le membre U, met en œuvre la signature anonyme de groupe de service dans le cadre de son accès anonyme au service S. Selon l'exemple particulier de réalisation de l'invention, l'utilisateur U, est membre des deux groupes G s et G c précédemment décrits. L'étape 12 de signature se décompose en plusieurs sous-étapes décrites ci-après. La signature anonyme de groupe de service, dans le cadre d'un accès au service S, prend en entrée un message clair m propre au service.

Dans une sous-étape étape d'initialisation 12-1 , correspondant à une étape de signature anonyme selon le schéma de signature de groupe de service, il est généré par le membre Ui, une signature de groupe du message clair m au moyen du matériel cryptographique qu'il a obtenu au cours de l'étape 1 1 -1 d'enrôlement au groupe de service G s .

De manière classique, la signature anonyme produite comprend deux parties, notées km et sm respectivement.

Conformément au schéma de signature de groupe décrit précédemment, la première partie km, est obtenue par chiffrement de la clé propre de membre upk avec l'algorithme de chiffrement ENC paramétré par la clé publique de chiffrement epk (km = ENC(upk, epk)) du groupe de service G s . La première partie km est donc relative à l'appartenance du membre Uj au groupe de service G s , puisqu'elle dépend uniquement de la clé de membre et de la clé publique de chiffrement.

La deuxième partie sm est obtenue, conformément au schéma de signature de groupe décrit précédemment, par signature de la première partie km et du message clair m avec l'algorithme de signature SIGN paramétré par la clé privée de signature ssk (sm = SIGN(km || m, ssk)) du groupe de service G s . Ainsi, la deuxième partie sm est dépendante du message clair m.

Dans une sous-étape 12-2 de création d'un certificat, il est créé par le membre Uj un certificat conforme syntaxiquement à un certificat numérique X.509. On remarque que le certificat est créé pour la signature anonyme de groupe de service du message m courant. Ainsi, à chaque signature de message clair m il est crée par le membre Uj un certificat numérique associé au message m et au membre U,. Ce certificat est unique dans le sens où il est spécifique à la signature anonyme courante du message clair m, contrairement à des certificats numériques classiques qui ont une période validité déterminée et spécifiée par un champ du certificat. Le certificat unique généré comprend entre autres les champs suivants :

- un numéro de série, destiné à identifier le certificat. Par exemple ce champ comprend une valeur pseudo-aléatoire.

- un algorithme de signature du certificat ; ce champ permet d'identifier l'algorithme de signature utilisé par l'émetteur du certificat numérique pour signer le certificat ; ce champ correspond à la signature anonyme de groupe de certification ;

- un nom de signataire/émetteur du certificat ; ce champ comprend le nom de l'Autorité de Certification ;

- période de validité : ce champ n'a pas d'utilité ici puisque le certificat généré n'est valable que pour la signature de service en cours. Le champ peut être vide (valeur "null"), ou comprendre une valeur prédéfinie, par exemple "one-time" ;

- une identité du titulaire du certificat : ce champ identifie le membre/l'entité pour lequel le certificat a été émis. Ce champ comprend une donnée de substitution de l'identité réelle du titulaire. En effet, on comprend que, pour respecter l'anonymat garantit par le service S, aucun nom ne peut figurer dans ce champ, bien que le titulaire naturel de ce certificat soit le membre U, qui signe anonymement le message en clair m. Ainsi, ce champ peut être vide (valeur "null"), ou comprendre une valeur aléatoire.

- des informations sur la valeur destinée à être utilisée pour vérifier la signature anonyme de groupe du message m courante. Cette valeur est destinée à être certifiée par le certificat numérique généré. Elle est habituellement appelée "clé publique" dans un certificat X.509 classique et par raison de commodité, on utilise ce terme par la suite :

- algorithme à utiliser avec la clé publique : ce champ identifie l'algorithme de signature anonyme mis en œuvre dans le groupe de service G s . Il correspond donc à la signature anonyme de groupe de service ;

- clé publique proprement dite : ce champ correspond à la valeur de la clé publique. Il comprend la première partie km de la signature anonyme de groupe de service du message m produite par le membre U, au cours de la sous-étape 12-1 . Pour mémoire, km = ENC(upk, epk) ;

Le certificat peut comprendre également des informations complémentaires optionnelles, non détaillées ici.

On note M le certificat numérique obtenu au terme de la sous-étape 12-2.

Dans une sous-étape 12-3 de signature du certificat, il est procédé à la signature du certificat M généré à la sous-étape précédente. C'est le membre U, qui signe anonymement le certificat M, et non l'Autorité de Certification. Le membre U, signe en tant que membre du groupe de certification G c . Le membre U, met donc en œuvre la signature anonyme de groupe de certification en prenant en entrée comme message clair le certificat M, selon les deux étapes suivantes :

1 - il chiffre sa clé propre de membre UPK du groupe de certification G c à l'aide de l'algorithme de chiffrement paramétré par la clé publique de chiffrement pour obtenir un chiffré C (C = ENC(UPK, EPK)) ; 2- il signe le chiffré C obtenu et le certificat M avec l'algorithme de signature paramétré par la clé privée de signature SSK afin d'obtenir une signature S (S = SIGN(C || M, SSK)).

La signature anonyme de groupe de certification du certificat M est alors le couple ∑ = (C, 5) .

On comprend qu'en adhérant au groupe de certification G c , et notamment en fournissant ses données d'identification personnelles à l'Autorité de Certification lors de la sous-étape 11 -2a d'enregistrement, le membre Uj a été délégué par l'Autorité de Certification pour signer les certificats qu'il génère.

Dans une sous-étape 12-4 d'envoi, le membre U, envoie au fournisseur de service un bloc de données qui comprend :

- le certificat M, sa signature ∑ = (C, S) obtenue au terme de la sous-étape 12-3 de signature,

- le message en clair m, propre au service S demandé, et

- la deuxième partie sm de la signature anonyme de service du message m calculée au cours de la sous-étape 12-1. Pour mémoire, sm = SIGN(km || m, ssk) et dépend du message clair m.

On remarque que le bloc de données envoyé est conforme à un envoi effectué dans le cadre des certificats numériques X.509 pour un schéma de signature classique, c'est-à-dire non anonyme.

Dans une étape ultérieure 13 de vérification de la validité du certificat, consécutive à la réception par le fournisseur de service du bloc de données envoyé au cours de la sous-étape 12-4, le fournisseur de service procède à la vérification du bloc de données reçu. Dans une sous-étape 13-1 de vérification de la validité du certificat, le fournisseur extrait du certificat M reçu le champ correspondant à l'algorithme de signature du certificat. Ici ce champ a pour valeur la signature anonyme de groupe de certification. Le fournisseur vérifie ensuite la validité de la signature ∑ du certificat. Cette vérification est effectuée à l'aide de l'algorithme de vérification de signature VERIF appliqué à la deuxième partie S de la signature ∑du certificat (S = SIGN(C || M, SSK)), et au message C || M, paramétré par la clé publique de vérification de signature SPK. La vérification se fait donc en calculant VERIF(S, C || M , SPK) et consiste à vérifier la signature S en utilisant la clé publique de vérification SPK.

Si la vérification est positive, c'est-à-dire si VERIF(S, C || M , SPK) = 1 , alors dans une sous-étape 13-2 d'extraction, le fournisseur de service extrait du certificat M la valeur correspondant à la clé publique certifiée, en l'espèce, la première partie km de la signature anonyme de groupe de service produite par l'utilisateur à l'étape 13. La valeur de la clé publique certifiée km est utilisée au cours d'une sous-étape 13-3 de vérification de signature par le fournisseur de service pour vérifier la validité de la deuxième partie sm de la signature anonyme de service du message m (sm = SIGN(km || m, ssk)). Cette vérification est effectuée par le fournisseur de service à l'aide de l'algorithme de vérification de signature VERIF appliqué à la valeur sm et au message km || m, paramétré par la clé publique de vérification spk du groupe de service. La vérification se fait donc en calculant VERIF(sm, km || m , ssk). La vérification est positive si VERIF(sm, km || m , ssk) = 1.

Ainsi, le fournisseur de service a vérifié la signature anonyme de groupe de service du message clair m selon un schéma de vérification compatible avec une architecture qui utilise des certificats X.509.

Dans l'exemple de réalisation décrit, on a considéré que la clé propre upk de membre du groupe de service G s et la clé propre UPK de membre du groupe de certification G c étaient différentes. Dans une variante de réalisation, les clés propres upk et UPK de membres sont identiques. Ainsi, il devient possible de prouver que les signatures anonymes de groupe de service et de certification mises en œuvre dans le cadre du procédé selon l'invention, sont issues d'un même membre. Cela améliore la sécurité du procédé dans le sens où il devient impossible pour deux membres distincts U a et U b , avec a≠ b , de mixer une signature anonyme de service produite par U a avec une signature anonyme de certification produite par U b, ce qui conduirait à une incohérence dans le procédé de génération.

Le procédé a été décrit pour un schéma de signature anonyme de groupe particulier.

Cependant, le procédé de génération n'est pas limité à ce schéma particulier. Par exemple, l'invention s'applique également aux schémas de signature de groupe "ACJT" (du nom des auteurs Ateniese, Camenisch, Joye et Tsudik) et "BBS" (du nom des auteurs Boneh, Boyen et Shacham). Avec ces schémas, une signature anonyme de groupe d'un message en clair se décompose aisément en deux parties : une première partie km, relative à un certificat de membre fourni par le gestionnaire de groupe au cours de la phase d'enrôlement, et une deuxième partie sm, relative au message, qui est une preuve de connaissance à divulgation nulle de connaissance. L'invention s'applique donc aisément sur la base de cette décomposition. D'une manière générale, l'invention peut s'appliquer à des schémas de signature de groupe qui distinguent de premiers éléments propres au membre ou à l'appartenance du membre au groupe et de deuxièmes éléments relatifs au message que le membre signe. Ainsi, l'invention s'applique également à d'autres schémas comme par exemple le schéma de signature Groth.

Dans l'exemple de réalisation décrit, le gestionnaire de groupe MG est le fournisseur qui délivre le service S. L'invention ne se limite pas à ce cas. Ainsi, dans un autre exemple de réalisation de l'invention, une entité spécifique de gestion de groupes, indépendante du fournisseur de service S, a en charge la gestion de groupes associés respectivement à un fournisseur de services. On peut également envisager que lorsqu'un fournisseur de services délivre plusieurs services, il est géré par l'entité de gestion de groupes gérant plusieurs groupes, un groupe étant associé à un service. Dans un autre exemple de réalisation, le membre U, appartient à un seul groupe, et il peut accéder à une pluralité de services gérés respectivement par un ou plusieurs fournisseurs de services.

Dans cet exemple de réalisation, un même schéma avec le smêmes algorithmes mais avec des clés différentes est mis en œuvre dans le groupe de service G s et dans le groupe de certification G c . L'invention n'est pas limitée à ce cas et dans un autre exemple de réalisation, différents schémas de signature anonyme de groupe sont mis en œuvre dans les groupes G s et G c .

Le procédé de l'invention met en œuvre deux signatures anonymes de groupe. Un membre apte à mettre en œuvre le procédé de l'invention adhère aux deux groupes. Il est possible, si le membre est identifié comme malhonnête, de révoquer le droit de signature du membre malhonnête, dans un des groupes, voire dans les deux. Cette révocation se fait de manière classique selon une des méthodes disponibles connues :

- en utilisant des accumulateurs propres au groupe, qui accumulent des éléments propres à chaque membre encore dans le groupe. Ainsi, à chaque arrivée ou révocation dans le groupe, l'accumulateur associé au groupe évolue, ou

- selon la méthode de Vérification Locale de Révocation (ou "VLR") qui consiste à mettre à jour dans une liste de révocation un élément propre à chaque membre révoqué.

Un dispositif 20 de membre selon l'invention va maintenant être décrit en relation avec la figure 2. Un tel dispositif 20 de membre est utilisé par le membre U| pour mettre en œuvre certaines des étapes du procédé de génération d'un certificat tel que décrit en relation avec la figure 1 . Le dispositif comprend plusieurs modules :

- une première mémoire 201 , adaptée pour mémoriser les données cryptographiques de certification obtenues auprès de l'Autorité de Certification lors de l'enrôlement du membre Uj dans le groupe de certification G c . Ainsi, c'est dans cette première mémoire 201 que sont mémorisées la clé secrète de signature SSK propre à tous les membres du groupe de certification G c , et la clé propre de membre UPK. Une telle mémoire est par exemple de type "EEPROM" (de l'anglais

"Electrically Erasable Programmable Read Only Memory") ;

- une deuxième mémoire 202, adaptée pour mémoriser les données cryptographiques de service obtenues auprès du gestionnaire de groupe MG du groupe de service lors de l'enrôlement du membre Uj au groupe de service G s . Ainsi, c'est dans cette deuxième mémoire 202 que sont mémorisées la clé secrète de signature ssk commune à tous les membres du groupe de service Gs, et la clé propre de membre upk. Une telle deuxième mémoire 202 est par exemple une mémoire EEPROM. Dans un autre exemple de réalisation de l'invention, les mémoires 201 et 202 ne forment qu'une seule mémoire qui mémorise l'ensemble des clés ssk, SSK, upk et UPK ;

- un module 203 d'enrôlement au groupe de certification Gc adapté pour s'enregistrer auprès de l'Autorité de Certification en transmettant à l'AC des données d'identification personnelles du membre Uj, s'enrôler auprès de l'AC pour récupérer les données cryptographiques nécessaires à la mise en œuvre de la signature anonyme de groupe de certification, et pour mémoriser ces données dans la première mémoire 202 ;

- une module 204 d'enrôlement au groupe de service G s adapté pour dialoguer avec le gestionnaire de groupe MG, récupérer du gestionnaire MG les données cryptographiques de service pour mettre en œuvre la signature anonyme de groupe de service et mémoriser ces données dans la deuxième mémoire 202 ; - un module 205 de génération d'une signature anonyme de groupe de service d'un message de service, adapté pour mettre en œuvre la signature anonyme de groupe de service sur un message clair m. Ce module 205 produit une signature (km, sm) comprenant une première partie km et une deuxième partie sm ;

- un module 206 de création d'un certificat, adapté pour généré un certificat numérique M comprenant une pluralité de champs. Dans ce certificat, le champ associé à la clé publique à certifier est la première valeur km de la signature produite par le module 205 de génération d'une signature anonyme de groupe de service ;

- un module 207 de signature du certificat adapté pour signer anonymement selon la signature anonyme de groupe de certification le certificat M créé par le module 206 de création de certificat. Le module 207 produit une signature notée∑ ;

- un module 208 d'envoi du certificat adapté pour envoyer un bloc de données à un fournisseur de service (non représenté sur la figure 2) comprenant le message clair m fourni en entrée du module 205 de génération d'une signature, la première partie de la signature sm produite par le module 205, le certificat M crée par le module 206 de création d'un certificat et la signature ∑ produite par le module 207 de signature.

Les modules 203, 204, 205, 206, 207 et 208 sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de génération précédemment décrit. Ainsi, le module 203 d'enrôlement met en œuvre les sous-étapes 1 1 -1 a et 11 -1 b décrites précédemment. Le module 204 d'enrôlement met en œuvre la sous-étape 1 1 -2. Le module 205 met en œuvre la sous-étape 12-1 décrite précédemment. Le module 206 de création d'un certificat met en œuvre la sous-étape 12-2 du procédé de génération. Le module 207 met en œuvre la sous-étape 12-3 décrite précédemment et le module 208 d'envoi met en œuvre la sous- étape 12-4 décrite précédemment.

Les modules logiciels peuvent être stockés dans, ou transmis par un support de données.

Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal, ou un réseau de télécommunication.

Dans un exemple de réalisation de l'invention, le dispositif 20 est une carte à puce.

Un dispositif 30 de vérification d'une signature anonyme de groupe d'un message de service selon un exemple de réalisation de l'invention va maintenant être décrit en relation avec la figure 3. Le dispositif comprend plusieurs modules :

- un module 301 de réception, agencé pour recevoir en provenance d'un membre, un bloc de données qui comprend entre autres une signature anonyme de groupe d'un message m de service. La signature anonyme a été produite par un dispositif du membre (non représenté sur la figure 3) au moyen d'un certificat numérique généré conformément aux étapes du procédé décrit précédemment. Le bloc de données reçu par le module 301 comprend : le certificat en clair, noté M, sa signature, notée ∑ , le message en clair m et la deuxième partie sm de la signature anonyme de service du message m ; - un module 302 d'extraction de la clé publique certifiée, agencé pour extraire du certificat M le champ correspondant à la clé publique certifiée, en l'espèce ce champ comprend la première partie km de la signature anonyme de groupe de service du message m de service ;

- un module 303 de vérification de la signature du certificat, adapté pour vérifier la signature ∑ du certificat M, au moyen de la clé publique de l'Autorité de Certification. La clé publique de l'AC est accessible de manière classique en remontant la chaîne de certification à partir du certificat, et/ou elle est disponible sur un serveur public ;

- un module 304 de vérification de la deuxième partie de la signature anonyme de service du message m au moyen de la clé publique certifiée présente dans le certificat M. Le module 303 de vérification coopère avec le module 302 d'extraction de la clé publique certifiée.

Les modules 301 , 302, 303 et 304 sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé précédemment décrit propres à la vérification de la signature anonyme de groupe de service. Ainsi, le module 302 de vérification de la signature du certificat met en œuvre la sous-étape 13-1 décrite précédemment. Le module 303 d'extraction de la clé publique met en œuvre la sous-étape 13-2 d'extraction et le module 304 de vérification de la deuxième partie de la signature met en œuvre la sous-étape 13-3 du procédé précédemment décrit.

Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal, ou un réseau de télécommunication.