WO2007093680A1 - Procede de certification de cle publique par un prestataire non accredite - Google Patents

Procede de certification de cle publique par un prestataire non accredite Download PDF

Info

Publication number
WO2007093680A1
WO2007093680A1 PCT/FR2006/051429 FR2006051429W WO2007093680A1 WO 2007093680 A1 WO2007093680 A1 WO 2007093680A1 FR 2006051429 W FR2006051429 W FR 2006051429W WO 2007093680 A1 WO2007093680 A1 WO 2007093680A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
validation
password
entity
public key
Prior art date
Application number
PCT/FR2006/051429
Other languages
English (en)
Inventor
Laurent Maupertuis
David Pointcheval
Cyrille Giquello
Bernard Starck
Original Assignee
Digimedia Interactivite
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digimedia Interactivite filed Critical Digimedia Interactivite
Priority to US12/224,005 priority Critical patent/US20100318787A1/en
Priority to AT06847218T priority patent/ATE544260T1/de
Priority to EP06847218A priority patent/EP1989819B1/fr
Publication of WO2007093680A1 publication Critical patent/WO2007093680A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present invention relates to the field of data certification methods.
  • the hacker will be able to sign and / or decrypt all messages that have been encrypted with the fake key present in the directory, using his fake private key and the user could thus repudiate a message under a false pretense.
  • a certificate is used to associate a public key with a entity type person or machine to ensure validity.
  • the certificate is a kind of public key identity card, issued by an organization called a certification authority (often referred to as CA for "Certification Authority").
  • a certificate of authority associated with a first element A and a second element B thus comprises at least one type signature sk aut ority (A, B), skgutor complaint being the private key of the authority issuing the certificate certifying that the Element A is well associated with Element B.
  • the certification authority is responsible for issuing the certificates, assigning them a validity date (equivalent to the expiry date of the food products), as well as possibly revoking certificates before that date in case of compromise of the key ( or the owner).
  • a certificate therefore comprises a first part corresponding to information on the holder of the public key, as well as on the authority issuing the certificate, and a second part corresponding to the signature of the certification authority, with for example a format of type:
  • Cryptographic key pairs must be produced in a highly secure manner
  • the certification authority must verify the identity of each user, for example through an in-person presentation of identity documents;
  • the certificate must be placed in a directory, so that other users can access it and verify the signatures;
  • - Revocation of compromised or expired certificates A service must be able to revoke certificates when they are expired, or when a private key has been compromised. Thus, from the moment when the certificate of a public key is revoked, it can not be used to check the signed messages using the associated private key;
  • - Archiving It is necessary to preserve the whole of the certificates which allow the verification, the lists of revocation, etc. , so that verification can be done later;
  • An organization wishing to deploy a PKI can delegate all of these functions to a provider, or on the contrary, achieve all or in part.
  • All the information (information + public key of the applicant) is signed by the certification authority.
  • This certificate contains the recipient's name and public key and is signed by the CA. It is therefore possible to verify the validity of the message by applying the hash function on the one hand to the information contained in the certificate, while on the other hand verifying the signature of the authority with the public key of the latter, with respect to the hash value.
  • certification authorities Some authorities, called certification authorities, are empowered to establish public key certification. This is for example done by a bailiff, who certifies the correspondence between a public key and a user by an electronic signature belonging only to him. However, this certification step is cumbersome because it assumes that the bailiff must verify the identity of the user before signing his public key, for example by an identity check.
  • This authority is therefore very much in demand, which may be incompatible with its great responsibility.
  • a first object of the present invention is therefore to be able to guarantee the certification of a public key of a user by reducing the solicitation of the key certification authorities.
  • Another object of the present invention is therefore to be able to guarantee the certification of a public key of a user by reducing the solicitation of the competent key certification authorities, while avoiding the disadvantage of the generation of the public key and of the secret key of the user by the competent authority.
  • Such a provider is therefore able, in known systems, to generate certificates, and thus to sign by his private signature a public key and a user identifier and then use this certificate without the knowledge of the user.
  • Another object of the present invention is therefore to make the issuance of a certificate dependent on a non-accredited third party provider of data certified by the certification authority, known to a user, but not the said third party.
  • a method for managing a public key of a user said user having a unique identifier, characterized in that it comprises: a certification step consisting in :
  • a validation request step consisting of:
  • the validation entity guarantees a real certification of the public key of the user, but without being able to generate fraudulent certificates, except to reuse the password that he has just received. learn, possibly before completing the certification process with the user, to generate a certificate on behalf of the user.
  • the certificate issued by the user integrates information generated and certified by the certification authority, and known only to him so that the validation authority has no interest in interrupting the certification process.
  • the certificate issued by the user to integrate information that has not been known to the validation entity that issued the certificate guaranteeing the correspondence between the public key of the user and the user. .
  • said certification step further comprises a step of:
  • said method further comprises: a certified transaction step to a transaction entity, comprising steps of:
  • the certificate transmitted to the transaction entity comprises a recognition word from which the password that has been transmitted by the user to the validation entity is unidirectionally derived.
  • the validation entity therefore does not know, and has no way of knowing the value of this recognition word, before the actual use of the certificate.
  • this recognition word derives the password, as well as the password certified by the authority.
  • this recognition word has been certified by the validation entity when it issued the certificate representative of the correspondence between the password and said user.
  • the validation entity can not generate a valid transaction certificate by taking advantage of the information received during the validation step, since this transaction certificate depends on a value which is unknown to it, in this case a word of recognition.
  • the validation entity therefore has every interest in highlighting such a distinction so as not to be accused of false fraud.
  • each of said at least one recognition word is associated with a unique index
  • each of said at least one password deriving unidirectionally from each of said at least one recognition word is associated with the index of said recognition word from which it derives
  • the validation entity modifies its digital counting identifier, or counter, each time it validates the correspondence between a public key and a user, the certificates issued by the validation entity for the same user all include a different meter.
  • the validation entity has correctly implemented the above method, if two certificates have been transmitted with the same index, this means that it is the provider who is at fault. Indeed, if the user had wanted to withdraw a second certificate, or renew a request, the index corresponding to the numerical numeric identifier in the certificate issued by the validation entity would then have been different.
  • the modification of said digital counting identifier in said storage means of said validation entity is an incrementation.
  • a single secret word is transmitted to the user, and the password calculations are performed by a computer of the user.
  • the size of the secret transmitted to the user is short, for example 12 characters, depending on the security requirements.
  • said validation request step comprises, following the transmission of said user to said validation entity of said public key, a step consisting in:
  • said certified transaction step to a transaction entity comprising the steps of:
  • said validation request step comprises a first substep of transmitting said validation entity to said user, a second password; and a second sub-step of transmitting said user to said validation entity of a second test value, said validation step being performed only in case of correspondence between said second password and said second test value.
  • FIG. 1 represents a general diagram of exchanges between the various entities involved in the context of the present invention
  • the present invention is based on exchanges between different entities for use in an asymmetric cryptosystem. It involves a user 2 wishing to obtain a certificate on a public key that he has generated himself, a certification entity 1 who is a priori the only person of confidence, able to certify data. In a conventional manner, this certification entity 1 is for example a bailiff. It also involves a validation entity 3, also later called provider, which has a certification key, but which is not entirely trusted to issue certificates alone. This validation entity 3 performs most of the calculations, storages, and interactions with the user. It also involves a transaction entity 4 at which the user wishes to perform a certified transaction. Subsequently, the private key of the certification entity is noted sk a , and its public key vk a . The private key of the validation entity is noted sk p and its public key vk p .
  • each user 2 has a public identifier and unique login.
  • the certification authority 1 generates 20 a secret secret which is transmitted to the user 2 on presentation of the login identifier of the user 2.
  • the certification authority also transmits 30 to the provider means for verifying the validity of the secret secret of the user. These means of verification will be described in more detail later.
  • this public key to the validation entity.
  • the validation entity concludes that the public key is associated with the user 2, it transmits 50, a certificate associating this public key to this user.
  • the user can then in a step 60, perform a transaction to a transaction entity using data from the certificate that he has received from the verification entity.
  • this derivative corresponds to the application of a unidirectional function ("one-way" in English language) in the sense that, if H is unidirectional and if we only have the result H (x), it is very difficult or impossible to find x in a reasonable time.
  • a unidirectional function is the SHA-1 hash function known to those skilled in the art.
  • ack is different from ackj for i different from j, and that therefore, pass (respectively PASS ⁇ ) is different from passj (respectively PASSj) for i different from j.
  • FIG. 2 represents a detail of the exchanges between the user 2 and the certification entity 1 as referenced 1 0 and 20 in FIG. 1.
  • the user 2 initially knows his login identifier, the public key of the certification entity vk a and the unidirectional function H used to make the derivatives.
  • the certification authority 1 initially knows its public key vk a , its private key sk a and the unidirectional function H used to make the derivatives.
  • the user 2 transmits 100 his login identifier to the certification entity. This generates in return a secret secret in a step 102. It then transmits 101 this secret to the user 2.
  • the user is able to calculate the recognition words ack, and passwords passi as previously defined in steps 103 and 104.
  • the certifying entity also calculates these variables in steps 105 and 106. It also calculates PASSi verification words in a step 107, certifies them and transmits them 108 to the validation entity.
  • the verification words being certified it is also possible to check the validity of the other words by applying a unidirectional function.
  • the parameter k as defined above is here a security parameter which designates the maximum number of unsuccessful connection attempts, for reasons of hardware or network failure or for dishonest attempts by a user.
  • the parameter k can for example take values between a few units and several tens.
  • the validation entity is at least in possession of the PASS 1 verification words. In particular, it does not have the words sec, passi, ack,, which are specific to the user.
  • User 2 generates 109, for example using a G algorithm located on his computer, a pair of signature keys (sk, vk) and wishes a certificate on vk. It passes vk to the validation entity and its login in a step 1 10.
  • the validation entity manages a digital counting identifier, or counter c of connection attempts by the user.
  • This counter c therefore represents the number of times that the user 2, identified by his login, tried to connect to the certification service by the validation entity.
  • the certification entity transmits 1 1 1 the current value of the counter c to the user upon receipt of his login identifier and the public key vk of the user.
  • the provider is therefore assured that the password pass c is associated with the identifier of the user login, and that the public key is associated with the login user ID.
  • the verification word transmitted is therefore the verification word whose index corresponds to the connection attempts counter by the user 2 as it was transmitted to the user in the step 1 1 1.
  • Vvk p (login, c, H (ack c ), vk; o p ) to check login, c, ack c and vk
  • Vvk a (login, PASS C , o to c ) to check login and PASS C ; H 2 (ack c ) to check ack c using PASS C. It is this certificate verifiable by all that is transmitted to the transaction entity 4 in a step 1 18. This certificate then guarantees that the public key vk is associated with the user 2 identified by his login.
  • the method according to the invention makes it possible to provide a high level of security. Indeed, only the user can obtain a certificate cert in his name since such a certificate integrates a value unknown to the provider (ack c ) before the user has used his certificate with the index c. Without this, the provider could benefit from the information learned during certification.
  • the value ack c is needed to validate the certificate. This information is revealed only after the user has received a valid ⁇ p signature, when using the cert certificate. A second signature ⁇ p with the same counter value then accuses the provider. Note that for this, the user must keep a copy of his certificate.
  • the provider increments the counter and can not be challenged until, ever, two signatures ⁇ p will be issued with the same counter.
  • Such a 60-bit dry secret can then be coded on 12 alphanumeric characters.
  • this secret of 12 characters can be transmitted confidentially to the user, and kept in a safe place by the latter.
  • certification may be associated with revocation. Indeed, in case of loss or corruption of the secret key by the user (or secret dry), it is necessary to no longer consider associated public keys as belonging to their legitimate owner. All that is required is to maintain a revocation list, listing the certificates, or the public keys, which should no longer be considered authentic. Nevertheless, the revocation requires a strong authentication of the one who asks for it, and we can no longer make him use his secret key, since it is possibly because he lost it that he makes the request for revocation. It is therefore customary to prepare questions agreed with the user (mother's maiden name, pet name, etc.). But again, we do not want to trust the provider who may wish to revoke a user without his knowledge.
  • the certification entity transmits a unique secret secret to the user and the latter calculates passwords and recognition words ack.
  • the certification entity it is also possible for the certification entity to send the ack passwords and / or the pass passwords directly to the user.
  • the steps 103 and 104 for calculating the values ack, and pass can be replaced by steps of transmission of these same values from the certification entity to the user.
  • it is important according to the present invention that the user is in possession of a data item, which can be the secret secret, the password pass it or the recognition words ack ,, that he only share with the CA, which is unknown to the provider, but verifiable by it.
  • the certification entity is not entirely trusted, it is possible for the user and the provider to exchange a second password noted pw, unknown to the certification. This password is then transmitted from the user to the provider when the user wishes to certify his public key. If this second password is not recognized by the validation entity, no verification is performed, and the process is stopped. This has the advantage of preventing the certification entity from acting on behalf of the user.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)

Abstract

La présente invention permet de pouvoir garantir la certification d'une clé publique d'un utilisateur en réduisant la sollicitation des autorités compétentes de certification des clés. Elle concerne plus particulièrement un procédé pour la gestion d'une clé publique d'un utilisateur (2) pouvant être mise en oevre dans un cryptosystème asymétrique. Selon l'invention, une certification, ou validation de la correspondance entre une clé publique (vk) et un utilisateur (2), est réalisée par une entité de validation (3), un prestataire distinct de l'autorité de certification (1), par l'intermédiaire d'une étape de validation. Le mot de passe de l'utilisateur (pass

Description

PROCÉDÉ DE CERTIFICATION DE CLÉ PUBLIQUE PAR UN PRESTATAIRE NON ACCRÉDITÉ
La présente invention se rapporte au domaine des procédés de certification des données.
La certification de données est très utilisée dans la mise en œuvre de la cryptographie asymétrique. Dans ce type de cryptographie, chaque utilisateur détient deux clés, une clé privée qui doit être gardée secrète, et une clé publique qui est disponible pour tous les autres utilisateurs, ces deux clés étant mathématiquement liées. Ce mécanisme permet d'échanger des données chiffrées et/ou signées.
On décrit ci-dessous les mécanismes de chiffrement et de signature connus. Dans le cas d'un chiffrement, pour envoyer un message chiffré à Bernard, Alice obtient la clé publique de Bernard et s'en sert pour chiffrer le message. À sa réception, Bernard est en mesure de déchiffrer le message en utilisant sa clé privée. Nul autre que lui n'est en mesure de le faire, puisque si n'importe qui peut accéder à la clé publique de Bernard, nul ne peut en déduire la clé privée qui la complémente.
Dans le cas d'une signature, pour envoyer un message signé, il suffit d'inverser l'ordre des clés : la clé privée devient la clé de signature, et la clé publique, celle de vérification. Le mécanisme offre alors les assurances suivantes : d'une part, le message ainsi « signé » l'a bel et bien été par la clé privée correspondant à la clé publique utilisée pour la vérification; d'autre part, le message n'a pu être modifié après la signature, sinon la vérification aurait échouée. Ces deux caractéristiques identification de l'auteur, intégrité du message signé - fournissent, un équivalent de la signature manuscrite adapté au contexte électronique. Ce procédé conférant, en particulier la qualité de non-répudiation au message ainsi signé.
Toutefois ce mode de partage a une grande lacune puisque rien ne garantit que la clé est bien celle de l'utilisateur à qui elle est associée. En effet, un pirate peut corrompre la clé publique présente dans un annuaire de clés publiques en la remplaçant par sa clé publique. Supposons qu'Oscar, un pirate, désire convaincre Alice qu'elle reçoit des messages signés de Bernard, alors qu'ils sont en fait de sa plume. Il n'aura qu'à substituer sa propre clé publique à celle de Bernard dans l'annuaire, et envoyer ses messages à Alice en prétendant être Bernard. Pour vérifier la signature de ces messages, Alice se procurera la clé publique de Bernard (en fait, celle du pirate) et la vérification étant réussie, sera faussement convaincue de l'origine des messages. De même Bernard pourrait malhonnêtement répudier un message effectivement envoyé, au prétexte qu'un pirate se serait substitué à lui.
Ainsi, le pirate sera en mesure de signer et/ou de déchiffrer tous les messages ayant été chiffrés avec la fausse clé présente dans l'annuaire, à l'aide de sa fausse clé privée et l'utilisateur pourrait ainsi répudier un message sous un faux prétexte.
La distribution des clés publiques est donc un problème de taille. En effet, pour que le chiffrement et la signature fonctionnent, il faut pouvoir être certain de l'identité de la personne reliée à la clé publique. Pour ce faire, on utilise en général un procédé de certification des clés publiques.
Un certificat permet d'associer une clé publique à une entité de type personne ou machine afin d'en assurer la validité. Le certificat est en quelque sorte la carte d'identité de la clé publique, délivré par un organisme appelé autorité de certification (souvent notée CA pour « Certification Authority »). Un certificat d'une autorité associée à un premier élément A et à un second élément B comprend donc au moins une signature du type skautorité (A, B), skgutorité étant la clé privée de l'autorité délivrant le certificat certifiant que l'élément A est bien associé à l'élément B.
L'autorité de certification est chargée de délivrer les certificats, de leur assigner une date de validité (équivalent à la date limite de péremption des produits alimentaires), ainsi que de révoquer éventuellement des certificats avant cette date en cas de compromission de la clé (ou du propriétaire).
Un certificat comprend donc une première partie correspondant à des informations sur le détenteur de la clé publique, ainsi que sur l'autorité délivrant le certificat, et une seconde partie correspondant à la signature de l'autorité de certification, avec par exemple un format de type :
Informations :
- nom de l'autorité de certification : Me Dupont Huissier de justice. - nom du propriétaire de la clé publique : M . Durand
- clé publique : 1 a:5b:3c:a5:32:4c:d6
Signature :
- d9:6d:4a:2g: 1 b:3c: F2
La combinaison d'éléments matériels, logiciels, et procéduraux qui permet d'effectuer l'ensemble des opérations sous-jacentes à la réalisation de la signature (et du chiffrement) cryptographique est désignée sous le nom d'infrastructure à clés publiques (ICP ou PKI), c'est-à-dire :
- Génération de clés cryptographiques : II faut produire les paires de clés cryptographiques, de façon hautement sécuritaire ;
- Enregistrement des utilisateurs : II faut que l'autorité de certification vérifie l'identité de chacun des utilisateurs, par exemple par une présentation en personne de pièces d'identités ;
- Certification des clés publiques : Une fois l'identité des utilisateurs confirmée, l'autorité de certification doit produire le certificat et le signer avec sa clé privée ;
- Génération des clés privées des utilisateurs : Un procédé fiable doit permettre de générer les clés de l'utilisateur.
- Service d'annuaire : Le certificat doit être placé au sein d'un annuaire, de façon à permettre à d'autres utilisateurs d'y accéder et de vérifier les signatures ;
- Révocation des certificats compromis ou périmés : Un service doit permettre de révoquer les certificats lorsqu'ils sont expirés, ou lorsqu'une clé privée a été compromise. Ainsi, à partir du moment où le certificat d'une clé publique est révoqué, il ne peut être utilisé pour vérifier les messages signés à l'aide de la clé privée associée; - Archivage : II faut conserver l'ensemble des certificats qui permettent la vérification, les listes de révocation, etc. , de façon à pouvoir effectuer la vérification ultérieurement ;
- Horodatage : les certificats et les signatures doivent faire l'objet d'un datage sûr.
Une organisation désirant déployer une PKI peut déléguer l'ensemble de ces fonctions à un prestataire, ou au contraire, les réaliser toutes ou en partie.
Cette liste permet cependant de constater la complexité des infrastructures nécessaires au déploiement de la signature cryptographique.
De façon connue en soi, la structure d'un certificat est normalisée par le standard X.509.
L'ensemble des informations (informations + clé publique du demandeur) est signé par l'autorité de certification. Cela signifie qu'une fonction de hachage réalise une empreinte de ces informations, puis ce condensé est signé à l'aide de la clé privée de l'autorité de certification; la clé publique de l'autorité de certification ayant été préalablement largement diffusée afin de permettre aux utilisateurs de vérifier la signature avec la clé publique de l'autorité de certification.
Lorsqu'un utilisateur désire communiquer avec une autre personne, il lui suffit de se procurer le certificat du destinataire. Ce certificat contient le nom du destinataire, ainsi que sa clé publique et est signé par l'autorité de certification. Il est donc possible de vérifier la validité du message en appliquant d'une part la fonction de hachage aux informations contenues dans le certificat, en vérifiant d'autre part la signature de l'autorité avec la clé publique de cette dernière, par rapport à la valeur hachée.
Certaines autorités, dites autorités de certification, sont habilitées à établir une certification des clés publiques. Ceci est par exemple réalisé par un huissier, qui certifie la correspondance entre une clé publique et un utilisateur par une signature électronique n'appartenant qu'à lui. Toutefois, cette étape de certification est lourde car elle suppose que l'huissier doive vérifier l'identité de l'utilisateur avant de signer sa clé publique, par exemple par un contrôle d'identité.
Cette autorité est donc très sollicitée, ce qui peut être incompatible avec sa grande responsabilité.
Un premier but de la présente invention est donc de pouvoir garantir la certification d'une clé publique d'un utilisateur en réduisant la sollicitation des autorités de certification des clés.
Une solution connue à cet inconvénient est de laisser cette autorité de certification générer à la fois la clé publique et la clé privée de l'utilisateur, de certifier sa clé publique, et de lui remettre l'ensemble de ces clés ainsi que le certificat. Cette solution possède cependant l'inconvénient que l'autorité connaît alors la clé secrète de l'utilisateur, et pourra donc signer à sa place et en son nom, ou bien déchiffrer ses communications. Dans ces conditions le message ou la transaction perd la qualité de non-répudiation.
Un autre but de la présente invention est donc de pouvoir garantir la certification d'une clé publique d'un utilisateur en réduisant la sollicitation des autorités compétentes de certification des clés, tout en évitant l'inconvénient de la génération de la clé publique et de la clé secrète de l'utilisateur par l'autorité compétente.
Par ailleurs, il est courant, pour des raisons pratiques, que des prestataires techniques différents des autorités de certifications participent au processus de certification (Prestataire de service en certification électronique - PSCE). Pour maintenir la qualification dudit certificat, il est nécessaire que le prestataire soit accrédité par l'autorité de certification afin de bénéficier de la même qualité de confiance que ladite autorité de certification. Dans les autres cas, la confiance qui est accordée à un tel prestataire non accrédité est inférieure à celle accordée à l'autorité de certification. Elle peut être limitée voire nulle.
Un tel prestataire est donc capable, dans les systèmes connus, de générer des certificats, et donc de signer par sa signature privée une clé publique et un identifiant d'utilisateur et d'utiliser ensuite ce certificat à l'insu de l'utilisateur.
La publication « Digital image recording for court-relatd purposes » de Rieger et al. , dans Security Technology, 1999, décrit par exemple une infrastructure de gestion de clés publiques d'utilisateurs comprenant une entité de certification et une entité de validation. Cette entité de validation est un prestataire de service en certification électronique, et génère des certificats de clé publique pour les clés publiques des utilisateurs.
Ceci pose par exemple des problèmes dans le cadre de la signature numérique de contrats et de transactions.
Un inconvénient de la présence d'un tiers non accrédité et pouvant délivrer des certificats est donc la possibilité pour ce tiers d'utiliser ces certificats de manière frauduleuse. Dans ces conditions, la chaîne de certification ne garantit pas suffisamment l'intégrité et la non-répudiation des messages signés. Il n'y a donc pas dans ce schéma de véritable équivalence entre la signature numérique et la signature manuscrite.
Un autre but de la présente invention est donc de permettre la génération par un tiers prestataire, d'un certificat garantissant la correspondance entre une clé publique et un utilisateur, et sans que ce certificat ne soit utilisable par ce tiers sans qu'il puisse être confondu. Ces prestataires seront appelés « entité de validation ».
Il est par ailleurs important que le certificat délivré par le tiers prestataire soit valable au sens où il reflète bien, notamment juridiquement, la correspondance entre une clé publique et un utilisateur. Pour cela, il est nécessaire que le certificat ne soit délivré à l'utilisateur qu'en fonction d'une donnée dépendant non pas uniquement de lui , car ce tiers n'est pas accrédité, mais de l'autorité de certification.
Un autre but de la présente invention est donc de faire dépendre la délivrance d'un certificat par un tiers prestataire non accrédité d'une donnée certifiée par l'autorité de certification, connue d'un utilisateur, mais pas dudit tiers.
Au moins un de ces buts est atteint selon la présente invention par un procédé pour la gestion d'une clé publique d'un utilisateur, ledit utilisateur possédant un identifiant unique, caractérisé en ce qu'il comprend : o une étape de certification consistant à :
- générer au niveau d'une entité de certification au moins un mot de passe;
- transmettre de ladite autorité de certification audit utilisateur, au moins une donnée secrète associée audit au moins un mot de passe ;
- déduire au niveau dudit utilisateur, ledit au moins un mot de passe, de ladite au moins une donnée secrète ; générer, au niveau de ladite entité de certification, à partir dudit au moins un mot de passe, au moins un mot de passe dérivé, ledit au moins un mot de passe dérivé dérivant de façon unidirectionnelle dudit au moins un mot de passe par une fonction unidirectionnelle; o une étape d'échange consistant à :
- transmettre de ladite entité de certification, vers une entité de validation, au moins un certificat de ladite entité de certification associé audit identifiant unique dudit utilisateur et audit moins un mot de passe dérivé; o une étape de demande de validation consistant à :
- générer, au niveau dudit utilisateur, une clé secrète associée à une clé publique;
- transmettre, dudit utilisateur vers ladite entité de validation, ladite clé publique et ledit identifiant unique; transmettre, dudit utilisateur vers ladite entité de validation, une valeur de test; o une étape de validation consistant à :
- En cas de correspondance au niveau de ladite entité de validation, entre une dérivée de ladite valeur de test par ladite fonction unidirectionnelle et un mot de passe dérivé validé parmi ledit au moins un mot de passe dérivé, transmettre audit utilisateur un certificat de validation de l'entité de validation associé au moins audit identifiant dudit utilisateur et à ladite clé publique.
De la sorte, en certifiant ledit mot de passe à l'utilisateur, l'autorité de certification garantit la correspondance entre ce mot de passe et un utilisateur déterminé. Dans le procédé selon l'invention, c'est la seule intervention de l'autorité de certification, et en particulier, celle-ci n'a plus à certifier les clés publiques générées par l'utilisateur, surtout dans le cas de la génération de plusieurs jeux de clés publiques. En effet, selon l'invention, cette certification, ou validation de la correspondance entre une clé publique et un utilisateur, est réalisée par l'entité de validation un prestataire distinct de l'autorité de certification, par l'intermédiaire de l'étape de validation. Ledit mot de passe de l'utilisateur est donc vérifiable par l'entité de validation, mais sans que cette dernière ne le connaisse.
Ainsi, dans le procédé selon l'invention, l'entité de validation garantit une réelle certification de la clé publique de l'utilisateur, mais sans toutefois pouvoir générer des certificats frauduleux, sauf à réutiliser le mot de passe qu'il vient d'apprendre, éventuellement avant d'avoir fini le processus de certification avec l'utilisateur, afin de générer lui-même un certificat au nom de l'utilisateur.
Il est donc avantageux que le certificat émis par l'utilisateur intègre une information générée et certifiée par l'autorité de certification, et connue de lui seul afin que l'autorité de validation n'ait aucun intérêt à interrompre le processus de certification.
En particulier, il est avantageux que le certificat émis par l'utilisateur intègre une information qui n'ait pas été connue de l'entité de validation qui a émis le certificat garantissant la correspondance entre la clé publique de l'utilisateur et l'utilisateur.
Pour ce faire, dans le procédé susmentionné, ladite étape de certification comprend en outre une étape consistant à :
- déduire au niveau dudit utilisateur, au moins un mot de reconnaissance de ladite au moins une données secrète, chacun desdits au moins un mot de passe dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance ; et ledit procédé comprend également : o une étape de transaction certifiée vers une entité de transaction, comprenant des étapes consistant à :
- transmettre dudit utilisateur vers ladite entité de transaction, un certificat de transaction comprenant au moins ledit certificat de validation et un desdits au moins un mot de reconnaissance.
De la sorte, le certificat transmis à l'entité de transaction comprend un mot de reconnaissance dont est dérivé de façon unidirectionnelle le mot de passe qui a été transmis par l'utilisateur à l'entité de validation. L'entité de validation ne connaît donc pas, et n'a aucun moyen de connaître la valeur de ce mot de reconnaissance, avant l'utilisation effective du certificat.
Toutefois, de ce mot de reconnaissance dérive le mot de passe, ainsi que le mot de passe dérivé certifié par l'autorité. Ainsi, ce mot de reconnaissance a donc été certifié par l'entité de validation lorsqu'elle a émis le certificat représentatif de la correspondance entre le mot de passe et ledit utilisateur.
Ainsi, l'entité de validation ne peut générer un certificat de transaction valable en tirant partie des informations reçues lors de l'étape de validation, puisque ce certificat de transaction dépend d'une valeur qui lui est inconnue, en l'espèce, un mot de reconnaissance.
Par ailleurs, dans le procédé susmentionné, une fois que l'utilisateur a transmis son certificat de transaction, il dévoile, la valeur du mot de reconnaissance, notamment à l'entité de validation. Il serait donc avantageux de faire une distinction entre la réutilisation de ce mot de reconnaissance par l'utilisateur pour retirer un deuxième certificat (ou renouveler une demande qui aurait été interrompue) et l'utilisation de ce mot de reconnaissance par l'entité de validation pour générer un certificat frauduleux.
L'entité de validation a donc tout intérêt à mettre en évidence une telle distinction pour ne pas se faire accuser de fraude à tort.
Pour ce faire, dans le procédé susmentionné, chacun desdits au moins un mot de reconnaissance est associé à un index unique, et chacun desdits au moins un mot de passe dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance est associé à l'index dudit mot de reconnaissance dont il dérive; o ladite étape de demande de validation comprend, suite à la transmission dudit utilisateur vers ladite entité de validation de ladite clé publique, une étape consistant à :
- stocker dans des moyens de stockage, au niveau de ladite entité de validation un identifiant numérique de comptage;
- transmettre de ladite entité de validation vers ledit o ladite étape de validation consistant à : - En cas de correspondance au niveau de ladite entité de validation, entre la dérivée de ladite valeur de test par ladite fonction unidirectionnelle et un mot de passe dérivé validé dont l'index correspond audit identifiant numérique de comptage parmi ledit au moins un mot de passe dérivé, transmettre audit utilisateur un certificat de validation de l'entité de validation associé au moins audit identifiant dudit utilisateur, à ladite clé publique, audit mot de passe dérivé validé, et audit identifiant numérique de comptage ;
- Modifier ledit identifiant numérique de comptage dans lesdits moyens de stockage de ladite entité de validation; o ladite étape de transaction certifiée vers une entité de transaction, comprenant des étapes consistant à :
- transmettre dudit utilisateur vers ladite entité de transaction, un certificat de transaction comprenant au moins ledit certificat de validation, ledit mot de reconnaissance dont l'index est celui dudit mot de passe dérivé validé, et l'index dudit mot de reconnaissance.
De la sorte, si l'entité de validation modifie bien son identifiant numérique de comptage, ou compteur, à chaque fois qu'elle valide la correspondance entre une clé publique et un utilisateur, les certificats émis par l'entité de validation pour un même utilisateur comprennent tous un compteur différent.
Ainsi, si l'entité de validation a correctement mis en œuvre le procédé ci-dessus, si deux certificats ont été transmis avec le même index ceci signifie que c'est bien le prestataire qui est en faute. En effet, si l'utilisateur avait voulu retirer un deuxième certificat, ou renouveler une demande, l'index correspondant à l'identifiant numérique de comptage dans le certificat émis par l'entité de validation aurait alors été différent.
Afin de faciliter la mise en œuvre du procédé, on peut faire en sorte que les index de chacun desdits mots de reconnaissance dérivés soient tous distincts et ordonnés. Dans ce cas, la modification dudit identifiant numérique de comptage dans lesdits moyens de stockage de ladite entité de validation est une incrémentation.
Par ailleurs, selon un mode de réalisation particulier de l'invention ladite au moins une donnée secrète correspond à un secret, chacun desdits au moins un mot de passe dérivant de façon unidirectionnelle dudit secret.
Selon ce mode de réalisation, un unique mot secret est transmis à l'utilisateur, et les calculs du mot de passe sont réalisés par un calculateur de l'utilisateur. De la sorte, la taille du secret transmis à l'utilisateur est courte, par exemple 12 caractères, selon les besoins en sécurité.
Toujours dans ce mode de réalisation, les calculs du mot de reconnaissance peuvent être réalisés au niveau du poste de l'utilisateur. Dans ce cas, ladite étape de certification comprend des étapes consistant à :
- transmettre de ladite autorité de certification audit utilisateur, ledit secret;
- calculer, au niveau dudit utilisateur, au moins un mot de reconnaissance, chacun desdits au moins un mot de reconnaissance dérivant de façon unidirectionnelle dudit secret; - calculer, au niveau dudit utilisateur, ledit au moins un mot de passe, chacun desdits au moins un mot de passe dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance.
II est également possible de combiner l'utilisation d'un identifiant numérique de comptage et du calcul au niveau du poste utilisateur. Dans ce cas, ladite étape de certification comprend des étapes consistant à :
- transmettre de ladite autorité de certification audit utilisateur, ledit secret; - calculer, au niveau dudit utilisateur, au moins un mot de reconnaissance, chacun desdits au moins un mot de reconnaissance étant associé à un index unique dérivant de façon unidirectionnelle dudit secret;
- calculer, au niveau dudit utilisateur, ledit au moins un mot de passe, chacun desdits au moins un mot de passe dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance et étant associé audit index dudit mot de reconnaissance dont il dérive o ladite étape de demande de validation comprend, suite à la transmission dudit utilisateur vers ladite entité de validation de ladite clé publique, une étape consistant à :
- stocker dans des moyens de stockage, au niveau de ladite entité de validation un identifiant numérique de comptage; - transmettre de ladite entité de validation vers ledit utilisateur, ledit identifiant numérique de comptage; o ladite étape de validation consistant à :
- En cas de correspondance au niveau de ladite entité de validation, entre la dérivée de ladite valeur de test par ladite fonction unidirectionnelle et un mot de passe dérivé validé dont l'index correspond audit identifiant numérique de comptage parmi ledit au moins un mot de passe dérivé, transmettre audit utilisateur un certificat de validation de l'entité de validation associé au moins audit identifiant dudit utilisateur, à ladite clé publique, audit mot de passe dérivé validé, et audit identifiant numérique de comptage; - Modifier ledit identifiant numérique de comptage dans lesdits moyens de stockage de ladite entité de validation ;
o ladite étape de transaction certifiée vers une entité de transaction, comprenant des étapes consistant à :
- transmettre dudit utilisateur vers ladite entité de transaction, un certificat de transaction comprenant au moins ledit certificat de validation, ledit mot de reconnaissance dont l'index est celui dudit mot de passe dérivé validé, et l'index dudit mot de reconnaissance.
Par ailleurs, il se peut également que l'accréditation de l'autorité de certification puisse être remise en cause. Dans ce cas, il est avantageux qu'il existe dans le procédé selon l'invention, un secret partagé entre l'utilisateur et l'entité de certification, mais inconnu de l'entité de certification.
Pour ce faire, dans le procédé tel que précédemment décrit, ladite étape de demande de validation comprend une première sous-étape de transmission de ladite entité de validation vers ledit utilisateur, d'un second mot de passe; et une seconde sous-étape de transmission dudit utilisateur vers ladite entité de validation d'une seconde valeur de test, ladite étape de validation n'étant réalisée qu'en cas de correspondance entre ledit second mot de passe et ladite seconde valeur de test.
De la sorte, on garantit que le certificat de validation ne sera délivré qu'à l'utilisateur connaissant le second mot de passe, et donc pas à l'autorité de certification si elle désirait frauder.
L'invention sera mieux comprise à l'aide de la description détaillée ci-dessous et des figures annexées dans lesquelles : - la figure 1 représente un schéma général des échanges entre les différentes entités intervenant dans le cadre de la présente invention ;
- la figure 2 représente un schéma détaillé des échanges entre un utilisateur et une entité de certification selon un mode de réalisation de l'invention ;
- la figure 3 représente un schéma détaillé des échanges entre un utilisateur et une entité de validation selon un mode de réalisation de l'invention ;
On définit tout d'abord des notations aux fins de la présente demande. On définit un algorithme de signature Ssk(m) qui retourne une signature σ sur le message m par une clé privée sk.
On définit également un algorithme de vérification Vvk(m ; a) qui vérifie la validité de la signature σ relativement au message m et à la clé publique vk.
Comme illustré figure 1 , la présente invention est basée sur des échanges entre différentes entités pour un usage dans un cryptosystème asymétrique. Elle fait intervenir un utilisateur 2 souhaitant obtenir un certificat sur une clé publique qu'il a générée lui-même, une entité de certification 1 qui est a priori la seule personne de confiance, capable de certifier des données. De façon classique, cette entité de certification 1 est par exemple un huissier. Elle fait également intervenir une entité de validation 3, également appelée par la suite prestataire, qui possède une clé de certification, mais en qui on n'a pas entièrement confiance pour délivrer seule des certificats. Cette entité de validation 3 réalise la plus grande partie des calculs, des stockages, et des interactions avec l'utilisateur. Elle fait également intervenir une entité de transaction 4 au niveau de laquelle l'utilisateur souhaite réaliser une transaction certifiée. Par la suite, la clé privée de l'entité de certification est notée ska, et sa clé publique vka. La clé privée de l'entité de validation est notée skp et sa clé publique vkp.
Selon l'invention, chaque utilisateur 2 possède un identifiant public et unique login. L'autorité de certification 1 génère 20 un secret sec qui est transmis à l'utilisateur 2 sur présentation 10 de l'identifiant login de l'utilisateur 2.
L'autorité de certification transmet également 30 au prestataire des moyens de vérification de la validité du secret sec de l'utilisateur. Ces moyens de vérification seront décrits plus en détail par la suite.
Afin de faire certifier une clé publique, l'utilisateur transmet
40 cette clé publique à l'entité de validation. En réponse, et si l'entité de validation conclut que la clé publique est bien associée à l'utilisateur 2, elle transmet 50, un certificat associant cette clé publique à cet utilisateur.
L'utilisateur peut ensuite dans une étape 60, réaliser une transaction vers une entité de transaction en utilisant des données du certificat qu'il a reçu de l'entité de vérification.
On décrit maintenant plus en détail les échanges entre les différentes entités décrites ci-dessus en référence aux figures 2 et 3.
On définit d'abord des dérivées du secret sec. Dans le domaine de la cryptographie, cette dérivée correspond à l'application d'une fonction unidirectionnelle (« one-way » en langue anglaise) au sens où, si H est unidirectionnelle et si l'on possède seulement le résultat H(x), il est très difficile voire impossible de retrouver x dans un temps raisonnable. Un exemple d'une telle fonction unidirectionnelle est la fonction de hachage SHA-1 connue de l'homme du métier.
On définit donc plusieurs dérivées du secret sec, d'abord sous la forme de mots de reconnaissance ackj, de mots de passe passi et de mots de vérification PASSi, avec par exemple : Pour / = 1 , . . . , k,
- ack, = H(sec, login, i)
- pass, = /-/(ack,)
- PASSi = H (pass ι)
Selon cette définition, on note que ack, est différent de ackj pour i différent de j , et que par conséquent, pass, (respectivement PASS\) est différent de passj (respectivement PASSj) pour i différent de j.
La figure 2 représente un détail des échanges entre l'utilisateur 2 et l'entité de certification 1 tels que référencés 1 0 et 20 dans la figure 1 .
L'utilisateur 2 connaît initialement son identifiant login, la clé publique de l'entité de certification vka et la fonction unidirectionnelle H utilisée pour réalisée les dérivées. L'autorité de certification 1 connaît quant à elle initialement sa clé publique vka, sa clé privée ska et la fonction unidirectionnelle H utilisée pour réalisée les dérivées.
L'utilisateur 2 transmet 100 son identifiant login à l'entité de certification. Celle-ci génère en retour un secret sec dans une étape 102. Elle transmet alors 101 ce secret à l'utilisateur 2. Selon un mode de réalisation de l'invention, l'utilisateur est apte à calculer les mots de reconnaissance ack, et les mots de passe passi tels que précédemment définis dans des étapes 103 et 104. L'entité de certification calcule également ces variables dans des étapes 105 et 106. Elle calcule également des mots de vérification PASSi dans une étape 107, les certifie et les transmet 108 à l'entité de validation
Ainsi, les mots de vérification étant certifiés, on peut également vérifier la validité des autres mots par application d'une fonction unidirectionnelle. La validité des mots de passe passi est donc vérifiée en testant si l'on a bien H(passι) = PASSit et la validité des mots de reconnaissance est vérifiée en testant si l'on a bien H2 (ack,) = H(passι) = PASS,.
Le paramètre k tel que défini précédemment est ici un paramètre de sécurité qui désigne le nombre maximum de tentatives de connexions infructueuses, pour des raisons de panne matérielle ou de réseau ou bien pour des tentatives malhonnêtes de la part d'un utilisateur 2. Selon les contextes de mise en œuvre de la présente invention, le paramètre k peut par exemple prendre des valeurs comprises entre quelques unités et plusieurs dizaines.
De la sorte, suite à cette certification, l'utilisateur est au moins en possession des variables suivantes : sec, passi, ack,. L'entité de validation est quant à elle au moins en possession des mots de vérification PASS1. En particulier, elle ne possède pas les mots sec, passi, ack, , qui sont propres à l'utilisateur. On décrit maintenant un exemple de procédé de certification entre l'utilisateur 2 et l'entité de vérification 3 en référence à la figure 3.
L'utilisateur 2 génère 109, par exemple à l'aide d'un algorithme G situé sur son calculateur, un couple de clés de signature (sk, vk) et souhaite un certificat sur vk. Il transmet vk à l'entité de validation ainsi que son login dans une étape 1 10.
De son côté, l'entité de validation gère un identifiant numérique de comptage, ou compteur c de tentatives de connexion par l'utilisateur. Ce compteur c représente donc le nombre de fois que l'utilisateur 2, identifié par son login, a tenté de se connecter au service de certification par l'entité de validation. L'entité de certification transmet 1 1 1 la valeur courante du compteur c à l'utilisateur à réception de son identifiant login et de la clé publique vk de l'utilisateur.
L'utilisateur prouve alors qu'il connaît la clé de signature sk associée à la clé vk à certifier, ainsi que le dérivé du secret sec en produisant 1 12 une signature sur le mot de passe d'indice c égal à la valeur courante reçu du compteur o=SSk(passc).
On décrit maintenant le procédé de certification permettant d'obtenir un certificat de l'entité de validation. Il est toutefois entendu que si les valeurs fournies par l'utilisateur, notées de façon générale TEST, ne correspondent pas à la bonne mise en œuvre du procédé, la certification sera refusée. On se place donc ici dans l'hypothèse où la valeur transmise à l'entité de validation à l'étape 1 12 correspond bien à une valeur TEST correcte. Le prestataire vérifie alors la signature de l'utilisateur grâce à sa clé publique qu'il a reçue précédemment et teste donc
Vvk(passc ; o). Il vérifie également 1 13 le mot de passe passc en testant PASSc=H(passc). Il incrémente également le compteur c dans l'étape 1 14.
Une fois ces données vérifiées, le prestataire est donc assuré que le mot de passe passc est bien associé à l'identifiant de l'utilisateur login, et que la clé publique est bien associée à l'identifiant de l'utilisateur login. Le prestataire signe alors 1 15 le quadruplet (login, c, passc, vk) à l'aide de sa clé privée skp et transmet 1 16 cette signature op=SSkp(login, c, passc, vk) à l'utilisateur.
Elle transmet également à l'utilisateur dans l'étape 1 16, le certificat reçu de l'entité de certification σa c sur le mot de vérification PASSC. Le mot de vérification transmis est donc le mot de vérification dont l'indice correspond au compteur de tentatives de connexions par l'utilisateur 2 tel qu'il a été transmis à l'utilisateur dans l'étape 1 1 1 .
L'utilisateur vérifie alors la validité de σp par
Vvkp (op ; (login, c, passc, vk)), vkp étant la clé publique du prestataire, et génère 1 17 un certificat sous la forme d'un n-uplet cert = (login, c, ackc, σa c , vk, op).
Selon l'invention, on note que ce certificat est vérifiable par tous grâce aux fonctions de vérification suivantes :
Vvkp(login, c, H(ackc), vk ; op) pour vérifier login, c, ackc et vk ; Vvka (login, PASSC ; oa c) pour vérifier login et PASSC ; H2(ackc) pour vérifier ackc à l'aide de PASSC. C'est ce certificat vérifiable par tous qui est transmis à l'entité de transaction 4 dans une étape 1 18. Ce certificat garantit alors que la clé publique vk est bien associée à l'utilisateur 2 identifié par son login.
Le procédé selon l'invention permet de fournir un fort niveau de sécurité. En effet, seul l'utilisateur peut obtenir un certificat cert en son nom puisqu'un tel certificat intègre une valeur inconnue du prestataire (ackc) avant que l'utilisateur n'ait utilisé son certificat avec l'index c. Sans cela, le prestataire pourrait tirer partie des informations apprises au cours de la certification.
De plus, la valeur ackc étant nécessaire pour valider le certificat. Cette information n'est révélée qu'une fois que l'utilisateur a reçu une signature σp valide, lors de l'utilisation du certificat cert. Une deuxième signature σp avec la même valeur de compteur accuse alors le prestataire. On note que pour cela, l'utilisateur doit conserver une copie de son certificat.
Par ailleurs, si l'utilisateur cherche à faire accuser le prestataire, ou si une panne réseau bloque des communications, le prestataire incrémente le compteur et ne peut donc pas être mis en cause tant que, jamais, deux signatures σp ne seront émises avec le même compteur.
On décrit maintenant la taille des variables utilisées dans le cadre de la présente invention afin de garantir un niveau de sécurité suffisant.
En choisissant un secret sec de 60 bits, et une fonction de hachage unidirectionnelle de type SHA-1 , une recherche exhaustive pour retrouver le secret sec à partir des valeurs des mots de vérification PASSj nécessite en moyenne 260 évaluations de SHA-1 . Le temps nécessaire pour réaliser ces évaluations fournit une sécurité suffisante dans le cadre de la présente invention.
Un tel secret sec sur 60 bits peut alors se coder sur 12 caractères alphanumériques. Ainsi, selon l'invention, seul ce secret court de 12 caractères peut être transmis de façon confidentielle à l'utilisateur, et conservé en lieu sûr par celui-ci.
Il est entendu que dans la gestion des objets à signer, stocker et/ou transmettre, des empreintes de ces objets sont parfois suffisantes. De façon connue en soi, de telles empreintes sont des versions compressées de l'objet total, de telle manière qu'il soit calculatoirement impossible de trouver deux objets avec la même empreinte.
Par ailleurs, comme pour toute infrastructure de gestion de clés, la certification peut être associée à la révocation. En effet, en cas de perte ou de corruption de la clé secrète par l'utilisateur (ou du secret sec), il est nécessaire de ne plus considérer les clés publiques associées comme appartenant à leur propriétaire légitime. Il suffit pour cela de maintenir une liste de révocation, répertoriant les certificats, ou les clés publiques, qui ne doivent plus être considérées authentiques. Néanmoins, la révocation nécessite une authentification forte de celui qui en fait la demande, et l'on ne peut plus lui faire utiliser sa clé secrète, puisque c'est éventuellement parce qu'il l'a perdue qu'il fait la demande de révocation. Il est donc d'usage de préparer des questions convenues avec l'utilisateur (nom de jeune fille de sa mère, nom de son animal de compagnie, etc). Mais encore une fois, on ne désire pas faire confiance au prestataire qui pourrait souhaiter révoquer un utilisateur à son insu.
On va donc demander à l'utilisateur de signer ses réponses, préalablement chiffrées avec la clé publique de l'autorité de certification pour les rendre inaccessibles au prestataire. Lors d'une demande de révocation, l'utilisateur contacte le prestataire et joint une ou des réponses aux questions. Le prestataire transmet la demande à l'autorité de certification qui lui donne alors l'autorisation, ou non, de procéder à la révocation en ajoutant le certificat, ou la clé publique, à une liste de révocation.
On décrit maintenant des variantes de la présente invention telle que décrite en détail ci-dessus dans un mode particulier de réalisation.
Dans le mode de réalisation tel que décrit ci-dessus, l'entité de certification transmet un secret unique sec à l'utilisateur et ce dernier calcule les mots de passe passi et les mots de reconnaissance ack,. Selon une variante, il est également possible que l'entité de certification transmette directement à l'utilisateur les mots de passe ack, et/ou les mots de passe pass,. Dans ce cas, les étapes 103 et 104 de calcul des valeurs ack, et pass, peuvent être remplacées par des étapes de transmission de ces mêmes valeurs de l'entité de certification à l'utilisateur. En tout état de cause, il est important selon la présente invention, que l'utilisateur soit en possession d'une donnée, qui peut être le secret sec, les mots de passe passit ou les mots de reconnaissance ack,, qu'il partage seulement avec l'autorité de certification, et qui est inconnue du prestataire, mais vérifiable par lui. Dans une autre variante de l'invention, si l'on ne fait pas entièrement confiance à l'entité de certification, il est possible que l'utilisateur et le prestataire échangent un second mot de passe noté pw, inconnu de l'entité de certification. Ce mot de passe est alors transmis de l'utilisateur vers le prestataire lorsque l'utilisateur souhaite faire certifier sa clé publique. Si ce second mot de passe n'est pas reconnu par l'entité de validation, aucune vérification n'est réalisée, et le procédé est stoppé. Ceci possède l'avantage d'éviter que l'entité de certification n'agisse au nom de l'utilisateur.

Claims

REVENDICATIONS
1 . Procédé pour la gestion d'une clé publique d'un utilisateur (2), ledit utilisateur (2) possédant un identifiant unique (login), caractérisé en ce qu'il comprend : o une étape de certification consistant à :
- générer (102, 105, 106) au niveau d'une entité de certification (1 ) au moins un mot de passe (passi) ; - transmettre (101 ) de ladite autorité de certification (1 ) audit utilisateur (2), au moins une donnée secrète (sec, ackj, passi) associée audit au moins un mot de passe ;
- déduire (103, 104) au niveau dudit utilisateur (2), ledit au moins un mot de passe (passi), de ladite au moins une données secrète (sec, ackj, passi) ;
- générer (107), au niveau de ladite entité de certification (1 ), à partir dudit au moins un mot de passe (passi), au moins un mot de passe dérivé (PASSi), ledit au moins un mot de passe dérivé (PASSi) dérivant de façon unidirectionnelle dudit au moins un mot de passe (passi) par une fonction unidirectionnelle (H); o une étape d'échange consistant à :
- transmettre (108) de ladite entité de certification (1 ), vers une entité de validation (3), au moins un certificat de ladite entité de certification (σa') associé audit identifiant unique (login) dudit utilisateur (2) et audit moins un mot de passe dérivé (PASSi); o une étape de demande de validation consistant à : générer (109), au niveau dudit utilisateur (2), une clé secrète (sk) associée à une clé publique (Wc); - transmettre (1 10), dudit utilisateur (2) vers ladite entité de validation (3), ladite clé publique (Wc ) et ledit identifiant unique (login);
- transmettre (1 12), dudit utilisateur (2) vers ladite entité de validation (3), une valeur de test ( TEST=passc); o une étape de validation consistant à :
- En cas de correspondance (1 13) au niveau de ladite entité de validation (3), entre une dérivée de ladite valeur de test par ladite fonction unidirectionnelle (H(TEST)) et un mot de passe dérivé validé (PASSC) parmi ledit au moins un mot de passe dérivé, transmettre (1 16) audit utilisateur (2) un certificat de validation de l'entité de validation (σp) associé au moins audit identifiant dudit utilisateur (login) et à ladite clé publique (vk).
2. Procédé selon la revendication 1 , dans lequel ladite étape de certification comprend en outre une étape consistant à : - déduire (103) au niveau dudit utilisateur (2), au moins un mot de reconnaissance de ladite au moins une donnée secrète (sec, acki), chacun desdits au moins un mot de passe (pass,=H(ackj)) dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance (pass,=H(acki)) ; et ledit procédé comprend également : o une étape de transaction certifiée vers une entité de transaction (4), comprenant des étapes consistant à :
- transmettre (1 18) dudit utilisateur (2) vers ladite entité de transaction (4), un certificat de transaction (cert) comprenant au moins ledit certificat de validation et un desdits au moins un mot de reconnaissance.
3. Procédé selon la revendication 2, dans lequel chacun desdits au moins un mot de reconnaissance (ac/c,) est associé à un index (/) unique, chacun desdits au moins un mot de passe (pasSi=H(ackj)) dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance (ac/c,) et étant associé à l'index dudit mot de reconnaissance dont il dérive (/); o ladite étape de demande de validation comprend, suite à la transmission (1 10) dudit utilisateur (2) vers ladite entité de validation (3) de ladite clé publique (vk), une étape consistant à :
- stocker dans des moyens de stockage, au niveau de ladite entité de validation (3) un identifiant numérique de comptage (c);
- transmettre (1 1 1 ) de ladite entité de validation (3) vers ledit utilisateur (2), ledit identifiant numérique de comptage (c); o ladite étape de validation consistant à :
- En cas de correspondance (1 13) au niveau de ladite entité de validation (3), entre la dérivée de ladite valeur de test par ladite fonction unidirectionnelle (H(TEST)) et un mot de passe dérivé validé (PASSC) dont l'index (c) correspond audit identifiant numérique de comptage parmi ledit au moins un mot de passe dérivé, transmettre (1 16) audit utilisateur (2) un certificat de validation de l'entité de validation (σp) associé au moins audit identifiant dudit utilisateur (login), à ladite clé publique {vk), audit mot de passe dérivé validé, et audit identifiant numérique de comptage (c) ;
- Modifier (1 14) ledit identifiant numérique de comptage (c) dans lesdits moyens de stockage de ladite entité de validation (3) ; o ladite étape de transaction certifiée vers une entité de transaction, comprenant des étapes consistant à :
- transmettre (1 18) dudit utilisateur (2) vers ladite entité de transaction (4), un certificat de transaction (cert) comprenant au moins ledit certificat de validation, ledit mot de reconnaissance {ackc) dont l'index (c) est celui dudit mot de passe dérivé validé (PASSC), et l'index dudit mot de reconnaissance (c).
4. Procédé selon l'une des revendications 1 à 3, dans lequel ladite au moins une donnée secrète correspond à un secret (sec), chacun desdits au moins un mot de passe (passi) dérivant de façon unidirectionnelle dudit secret (pasSi=H[H(sec, login, i)])
5. Procédé selon la revendication 4, comprenant ladite étape de certification comprend des étapes consistant à :
- transmettre (101 ) de ladite autorité de certification (1 ) audit utilisateur (2), ledit secret (sec);
- calculer (103), au niveau dudit utilisateur, au moins un mot de reconnaissance (acki), chacun desdits au moins un mot de reconnaissance dérivant de façon unidirectionnelle dudit secret (ack, =H(sec, login, i)) ;
- calculer (104), au niveau dudit utilisateur, ledit au moins un mot de passe, chacun desdits au moins un mot de passe dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance.
6. Procédé selon la revendication 4, comprenant ladite étape de certification comprend des étapes consistant à : - transmettre (101 ) de ladite autorité de certification (1 ) audit utilisateur (2), ledit secret (sec); - calculer (103), au niveau dudit utilisateur, au moins un mot de reconnaissance (acki), chacun desdits au moins un mot de reconnaissance (acki) étant associé à un index (/) unique dérivant de façon unidirectionnelle dudit secret (ac/f, =H(sec, login, i)) ;
- calculer (104), au niveau dudit utilisateur, ledit au moins un mot de passe, chacun desdits au moins un mot de passe dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance et étant associé audit index (i) dudit mot de reconnaissance dont il dérive o ladite étape de demande de validation comprend, suite à la transmission (1 10) dudit utilisateur (2) vers ladite entité de validation (3) de ladite clé publique (vk), une étape consistant à :
- stocker dans des moyens de stockage, au niveau de ladite entité de validation (3) un identifiant numérique de comptage (c);
- transmettre (1 1 1 ) de ladite entité de validation (3) vers ledit utilisateur (2), ledit identifiant numérique de comptage (c); o ladite étape de validation consistant à :
- En cas de correspondance (1 13) au niveau de ladite entité de validation (3), entre la dérivée de ladite valeur de test par ladite fonction unidirectionnelle (H(TEST)) et un mot de passe dérivé validé (PASSC) dont l'index (c) correspond audit identifiant numérique de comptage parmi ledit au moins un mot de passe dérivé, transmettre (1 16) audit utilisateur (2) un certificat de validation de l'entité de validation (σp) associé au moins audit identifiant dudit utilisateur (login), à ladite clé publique {vk), audit mot de passe dérivé validé, et audit identifiant numérique de comptage (c) ;
- Modifier (1 14) ledit identifiant numérique de comptage (c) dans lesdits moyens de stockage de ladite entité de validation (3) ; o ladite étape de transaction certifiée vers une entité de transaction, comprenant des étapes consistant à :
- transmettre (1 18) dudit utilisateur (2) vers ladite entité de transaction (4), un certificat de transaction (cert) comprenant au moins ledit certificat de validation, ledit mot de reconnaissance (ackc) dont l'index (c) est celui dudit mot de passe dérivé validé (PASSC), et l'index dudit mot de reconnaissance (c).
7. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite étape de demande de validation comprend une première sous-étape de transmission de ladite entité de validation (3) vers ledit utilisateur (2), d'un second mot de passe (pw); et une seconde sous-étape de transmission dudit utilisateur (2) vers ladite entité de validation (3) d'une seconde valeur de test, ladite étape de validation n'étant réalisée qu'en cas de correspondance entre ledit second mot de passe (pw) et ladite seconde valeur de test.
PCT/FR2006/051429 2006-02-16 2006-12-27 Procede de certification de cle publique par un prestataire non accredite WO2007093680A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/224,005 US20100318787A1 (en) 2006-02-16 2006-12-27 Method for Certifying a Public Key by an Uncertified Provider
AT06847218T ATE544260T1 (de) 2006-02-16 2006-12-27 Verfahren zum zertifizieren eines öffentlichen schlüssels durch einen nicht zertifizierten anbieter
EP06847218A EP1989819B1 (fr) 2006-02-16 2006-12-27 Procéde de certification de clé publique par un prestataire non accrédité

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0650554 2006-02-16
FR0650554A FR2897488B1 (fr) 2006-02-16 2006-02-16 Procede de certification de cle publique par un prestataire non accredite

Publications (1)

Publication Number Publication Date
WO2007093680A1 true WO2007093680A1 (fr) 2007-08-23

Family

ID=37001215

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/051429 WO2007093680A1 (fr) 2006-02-16 2006-12-27 Procede de certification de cle publique par un prestataire non accredite

Country Status (5)

Country Link
US (1) US20100318787A1 (fr)
EP (1) EP1989819B1 (fr)
AT (1) ATE544260T1 (fr)
FR (1) FR2897488B1 (fr)
WO (1) WO2007093680A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030097566A1 (en) * 2001-11-22 2003-05-22 Yoko Kumagai Public key certificate generation method, validation method and apparatus thereof

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5745574A (en) * 1995-12-15 1998-04-28 Entegrity Solutions Corporation Security infrastructure for electronic transactions
KR100213188B1 (ko) * 1996-10-05 1999-08-02 윤종용 사용자 인증 장치 및 방법
JP2001320356A (ja) * 2000-02-29 2001-11-16 Sony Corp 公開鍵系暗号を使用したデータ通信システムおよびデータ通信システム構築方法
JP2002099211A (ja) * 2000-09-21 2002-04-05 Sony Corp 公開鍵証明書発行要求処理システムおよび公開鍵証明書発行要求処理方法
EP1451786A1 (fr) * 2001-12-10 2004-09-01 Beamtrust A/S Procede de distribution d'une cle publique
US7480384B2 (en) * 2003-02-10 2009-01-20 International Business Machines Corporation Method for distributing and authenticating public keys using random numbers and Diffie-Hellman public keys

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030097566A1 (en) * 2001-11-22 2003-05-22 Yoko Kumagai Public key certificate generation method, validation method and apparatus thereof

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
RIEGER B ET AL: "Digital image recording for court-related purposes", SECURITY TECHNOLOGY, 1999. PROCEEDINGS. IEEE 33RD ANNUAL 1999 INTERNATIONAL CARNAHAN CONFERENCE ON MADRID, SPAIN 5-7 OCT. 1999, PISCATAWAY, NJ, USA,IEEE, US, 5 October 1999 (1999-10-05), pages 262 - 279, XP010355733, ISBN: 0-7803-5247-5 *
YONG LEE ET AL: "A Lightweight And Secure Wireless Certificate Management Protocol Supporting Mobile Phone", CONSUMER ELECTRONICS, 2006. ICCE '06. 2006 DIGEST OF TECHNICAL PAPERS. INTERNATIONAL CONFERENCE ON LAS VEGAS, NV, USA 07-11 JAN. 2006, PISCATAWAY, NJ, USA,IEEE, 7 January 2006 (2006-01-07), pages 103 - 104, XP010896525, ISBN: 0-7803-9459-3 *

Also Published As

Publication number Publication date
US20100318787A1 (en) 2010-12-16
FR2897488B1 (fr) 2008-04-11
ATE544260T1 (de) 2012-02-15
EP1989819B1 (fr) 2012-02-01
FR2897488A1 (fr) 2007-08-17
EP1989819A1 (fr) 2008-11-12

Similar Documents

Publication Publication Date Title
US6584565B1 (en) Method and apparatus for long term verification of digital signatures
EP2441207B1 (fr) Procédé cryptographique d'authentification anonyme et d'identification séparée d'un utilisateur
EP2345202B1 (fr) Procédé de signature numérique en deux étapes
EP1072124B1 (fr) Procede de verification de l'usage de cles publiques engendrees par un systeme embarque
US8200760B2 (en) Storage and authentication of data transactions
FR3041195A1 (fr) Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime
EP1480375A1 (fr) Procédé de signature électronique de groupe avec anonymat révocable, équipements et programmes pour la mise en oeuvre du procédé
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
WO2003061193A1 (fr) Procede et dispositif de signature anonyme au moyen d'une cle privee partagee
WO2007045745A1 (fr) Procede et dispositif de creation d'une signature de groupe et procede et dispositif de verification d'une signature de groupe associes
FR2930390A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise.
EP1523824B1 (fr) Procede de signature de liste et application au vote electronique
EP3965361B1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
FR2980011A1 (fr) Procede de mise en oeuvre, a partir d'un terminal, de donnees cryptographiques d'un utilisateur stockee dans une base de donnees distante
EP1466304A1 (fr) Procede cryptographique de revocation a l'aide d'une carte a puce
EP1989819B1 (fr) Procéde de certification de clé publique par un prestataire non accrédité
FR2896646A1 (fr) Certification avec autorite de certification distribuee
CA2831167C (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques ou d'elements (igcp/pki)
FR3141538A1 (fr) Procede et dispositif de stockage en ligne reparti de fichiers dans un contexte zero confiance
Chokhani et al. PKI and certificate authorities
EP1992104B1 (fr) Authentification d'un dispositif informatique au niveau utilisateur
WO2021074527A1 (fr) Procede de gestion d'une base de donnees de cles publiques, procede d'authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
CN116070287A (zh) 一种多方在线电子合约签订以及防篡改可溯源方法
WO2008087359A2 (fr) Procédé de signature de liste anonyme et traçable sans levée d'anonymat
WO2008081151A2 (fr) Procede de signature de liste anonyme et correlable

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006847218

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12224005

Country of ref document: US