FR 2897488 A1 20070817 FR 0650554 A 20060216 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 oeuvre 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), skautorité é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:l b:3c:F2 La combinaison d'éléments matériels, logiciels, et procéduraux qui permet d'effectuer l'ensemble des opérations30 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 : Il faut produire les paires de clés cryptographiques, de façon hautement sécuritaire ; - Enregistrement des utilisateurs : Il 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 : Il 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 10 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 15 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 20 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 25 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 30 entre une clé publique et un utilisateur par une signature électronique n'appartenant qu'à lui.5 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. 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 15 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 20 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 25 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 30 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 10 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 oeuvre 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 oeuvre 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. Il 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 6 sur le message m par une clé privée sk. On définit également un algorithme de vérification Vvk(m ; 6) qui vérifie la validité de la signature 6 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 desmoyens 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. 20 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 25 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 30 sous la forme de mots de reconnaissance ack;, de mots de passe passa et de mots de vérification PASS;, avec par exemple : Pour i = 1, . . . , k,15 ù ack; = H(sec, login, i) ù pass, = H(ack;) ù PASS; = H(pass,) Selon cette définition, on note que ack; est différent de ack pour i différent de j, et que par conséquent, pass; (respectivement PASS;) est différent de passe (respectivement PASS) 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 10 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 pass; 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 PASS; 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 19 également vérifier la validité des autres mots par application d'une fonction unidirectionnelle. La validité des mots de passe pass, est donc vérifiée en testant si l'on a bien H(pass,) = PASS;, 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 oeuvre 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, pass;, ack,. L'entité de validation est quant à elle au moins en possession des mots de vérification PASS;. En particulier, elle ne possède pas les mots sec, pass;, 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 Iogin dans une étape 110. 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 111 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 112 une signature sur le mot de passe d'indice c égal à la valeur courante reçu du compteur 6=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 oeuvre 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 112 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 ; (y). Il vérifie également 113 le mot de passe passc en testant PASSc=H(passc). Il incrémente également le compteur c dans l'étape 114. 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 115 le quadruplet (login, c, passc, vk) à l'aide de sa clé privée skp et transmet 116 cette signature cp=Sskp(login, c, passc, vk) à l'utilisateur. Elle transmet également à l'utilisateur dans l'étape 116, le certificat reçu de l'entité de certification bac 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 111. L'utilisateur vérifie alors la validité de 6p par Vvkp (6p; (login, c, passc, vk)), vkp étant la clé publique du prestataire, et génère 117 un certificat sous la forme d'un n-uplet cert = (login, c, ackc, bac , vk, 6p). Selon l'invention, on note que ce certificat est vérifiable par 15 tous grâce aux fonctions de vérification suivantes Vvkp(login, c, H(ackc), vk ; 6p) pour vérifier login, c, ackc et vk ; Vvka (login, PASSc ; bac) 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 118. Ce certificat garantit alors que la clé publique vk est bien associée à l'utilisateur 2 identifié par son login. 25 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 30 avec l'index c. Sans cela, le prestataire pourrait tirer partie des informations apprises au cours de la certification. 20 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 6p valide, lors de l'utilisation du certificat cert. Une deuxième signature 6p' 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 6p 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 PASS; 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 sont30 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 pass, 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 pass;, 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. 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 (passa) ; - transmettre (101) de ladite autorité de certification (1) audit utilisateur (2), au moins une donnée secrète (sec, acka, passa) 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 (passa), de ladite au moins une données secrète (sec, acka, passa) ; -générer (107), au niveau de ladite entité de certification (1), à partir dudit au moins un mot de passe (passa), au moins un mot de passe dérivé (PASSa), ledit au moins un mot de passe dérivé (PASSa) dérivant de façon unidirectionnelle dudit au moins un mot de passe (passa) 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 (nai) associé audit identifiant unique (login) dudit utilisateur (2) et audit moins un mot de passe dérivé (PASSa); 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 (vk); - transmettre (110), dudit utilisateur (2) vers ladite entité de validation (3), ladite clé publique (vk ) et ledit identifiant unique (login);- transmettre (112), 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 (113) 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 (116) audit utilisateur (2) un certificat de validation de l'entité de validation (6p) 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, ack,), chacun desdits au moins un mot de passe (pass,=H(ack,)) dérivant de façon unidirectionnelle de chacun desdits au moins un mot de reconnaissance (pass,=H(ack;)) ; et ledit procédé comprend également : o une étape de transaction certifiée vers une entité de transaction (4), comprenant des étapes consistant à: -transmettre (118) 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 (ack,) est associé à un index (i) unique, chacun desdits au moins un mot de passe (pass,=H(ack,)) dérivant de façon unidirectionnelle de chacundesdits au moins un mot de reconnaissance (ack,) et étant associé à l'index dudit mot de reconnaissance dont il dérive (i); o ladite étape de demande de validation comprend, suite à la transmission (110) 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 (111) 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 (113) 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 (116) audit utilisateur (2) un certificat de validation de l'entité de validation (6p) 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 (114) 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 (118) dudit utilisateur (2) vers ladite entité de transaction (4), un certificat de transaction (cert) comprenant au moins ledit certificat de validation, leditmot 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 (pass,) dérivant de façon unidirectionnelle dudit secret (pass,=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 (ack,), 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 (ack,), chacun desdits au moins un mot de reconnaissance (ack,) étant associé à un index (i) unique 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 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 (110) 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 (111) 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 (113) 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 (116) audit utilisateur (2) un certificat de validation de l'entité de validation (6p) 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 (114) 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 (118) 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.