Brevet FR2892584A1 — publié le 20070427

-1- La présente invention concerne un procédé de renouvellement de clés cryptographiques, un procédé d'obtention d'une clé publique et un dispositif de gestion de clés cryptographiques. L'invention concerne plus précisément les infrastructures à clés publiques. Ces infrastructures, couramment appelées PKI (de l'anglais Public Key Infrastructure ), ont notamment pour rôle de créer et de gérer des certificats numériques, par exemple en les renouvelant ou en les révoquant. Les certificats numériques sont délivrés à des propriétaires de couples de clés publiques et privées pour certifier de la validité de leurs clés. On dit qu'une clé est valide si une autorité de certification se porte garante de l'authenticité de la clé et si cette clé n'est pas périmée du fait d'une compromission ou de l'expiration de cette clé. En d'autres termes, une clé valide est une clé en vigueur, reconnue par une autorité de certification et qui peut donc être utilisée sans risque pour crypter des messages ou vérifier une signature. On connaît dans l'état de la technique un procédé de génération et de renouvellement de clés cryptographiques. Au cours d'une première étape, un demandeur, appelé par la suite propriétaire, se présente auprès d'une autorité locale d'enregistrement pour faire une demande de clés cryptographiques. Ensuite, l'autorité locale d'enregistrement transmet la demande à une autorité d'enregistrement qui en vérifie la validité. L'autorité d'enregistrement vérifie notamment l'identité du propriétaire qui fait la demande de clés cryptographiques. Une fois que l'identité du propriétaire est connue et suffisamment fiable, l'autorité d'enregistrement transmet la demande à un opérateur de certification qui génère une clé publique et une clé privée et émet un certificat numérique certifié par une autorité de certification. Le certificat numérique de l'état de la technique comprend notamment la clé publique, l'identité du propriétaire et une signature de l'autorité de certification. L'autorité de certification est une autorité morale au nom de laquelle sont émis les certificats. En particulier, l'autorité de certification définit les procédures à suivre pour émettre les certificats. Par conséquent, avant d'apposer sa signature sur un certificat, l'autorité de certification vérifie que la procédure qu'elle a définie a bien été appliquée par les différentes entités de l'infrastructure à clés publiques. La signature du certificat est donc une opération particulièrement lourde qui engage la responsabilité de l'autorité de certification. Au cours d'une dernière étape, l'opérateur de certification transmet la clé privée au propriétaire et met à la disposition du public le certificat comprenant la clé publique du -2- propriétaire. Le propriétaire peut également transmettre son certificat aux personnes qu'il connaît, lesquelles pourront ainsi utiliser la clé publique du certificat pour crypter des messages à destination du propriétaire ou pour authentifier des messages provenant du propriétaire et signés au moyen de sa clé privée. Pour renouveler un couple de clés, par exemple en cas de compromission de la clé privée, le propriétaire doit réitérer le procédé de génération de clés cryptographiques décrit ci-dessus. En particulier, un nouveau certificat comprenant la nouvelle clé publique doit être émis par l'opérateur de certification. Or, du fait des étapes d'identification et de signature par l'autorité de certification, le procédé de renouvellement d'un certificat s'avère particulièrement long et coûteux. L'invention a pour but de remédier à ces inconvénients en fournissant un procédé de renouvellement de clés cryptographiques grâce auquel il est rapide et facile de renouveler les clés d'un propriétaire. A cet effet, l'invention a pour objet un procédé de renouvellement de clés cryptographiques, dans lequel : û un propriétaire possède une première clé publique et un certificat numérique comprenant une identité et un identifiant du propriétaire, le certificat étant signé par une autorité de certification, et û un premier couple de données comprenant ladite première clé publique et ledit identifiant est stocké dans un serveur de clés publiques dont l'autorité de certification est garante, et comportant les étapes suivantes : génération, pour le propriétaire, d'une seconde clé publique destinée à remplacer ladite première clé publique, et stockage, dans ledit serveur de clés publiques, d'un second couple de données comprenant ladite seconde clé publique et l'identifiant. On distingue l'identité du propriétaire qui comprend par exemple son nom, son adresse ou son numéro de téléphone, de l'identifiant qui est attribué de façon arbitraire au propriétaire. Un propriétaire de plusieurs couples de clés cryptographiques (par exemple un couple à usage personnel et un autre à usage professionnel) peut ainsi posséder plusieurs identifiants, chaque identifiant faisant l'objet d'un certificat qui lui est propre. Grâce à l'invention, la clé publique du propriétaire n'est pas incluse dans le certificat numérique qu'il possède. Ainsi, une fois créé, ce certificat numérique reste valable en permanence. En particulier, le renouvellement des clés cryptographiques ne nécessite pas de renouvellement du certificat numérique. -3- L'autorité de certification garantit la validité des données stockées dans le serveur de clés publiques en contrôlant son accès en écriture. En particulier, l'autorité de certification a confiance en l'opérateur de certification et l'autorise à accéder au serveur de clés publiques. L'opérateur de certification peut donc modifier librement les données stockées dans ce serveur de clés publiques. Grâce à l'invention, le renouvellement des clés cryptographiques d'un propriétaire est donc une opération particulièrement rapide et simple. De façon optionnelle, une date d'expiration de la clé publique est associée à chaque couple de données. Généralement, les clés publiques sont valables pour une durée de trois ans. Grâce à la date d'expiration, un utilisateur de la clé publique peut vérifier si la clé est valable ou si elle est périmée. De manière optionnelle, lors du renouvellement de la première clé publique, on modifie la date d'expiration associée au premier couple de données pour la rendre égale à la date à laquelle on stocke ledit second couple de données dans le serveur de clés publiques. Ainsi, lors du renouvellement d'une clé publique associée à l'un des identifiants d'un propriétaire, on indique dans le serveur de clés publiques que toutes les précédentes clés publiques associées à cet identifiant ne sont plus valables. Cela limite alors le risque qu'un utilisateur télécharge du serveur de clés publiques une clé publique périmée. L'invention a également pour objet un dispositif de gestion de clés cryptographiques comprenant : des moyens de génération de clés publiques certifiées par une autorité de certification au moyen d'un certificat numérique comprenant une identité et un identifiant d'un propriétaire, et un serveur de clés publiques, dont l'autorité de certification est garante, 25 comprenant des moyens de stockage de couples de données comprenant ladite clé publique et ledit identifiant. L'invention a également pour objet un procédé d'obtention d'une clé publique stockée dans le serveur de clés publiques d'un dispositif de gestion de clés cryptographiques selon l'invention, comprenant les étapes suivantes : 30 û recherche d'un certificat numérique comprenant l'identité d'un propriétaire, extraction de l'identifiant compris dans le certificat numérique issu de la recherche, û sélection dans le serveur de clés publiques d'un couple de données comprenant l'identifiant extrait et dont la clé publique n'a pas expiré, et 35 extraction de la clé publique comprise dans le couple de données issu de la sélection. -4- Grâce à ce procédé, un utilisateur qui souhaite obtenir la clé publique d'un propriétaire et qui veut s'assurer que cette clé publique est valable peut aller consulter le serveur de clés publiques pour télécharger la clé publique en cours de validité. Le serveur de clés publiques étant systématiquement mis à jour lors de la création ou du renouvellement des clés publiques, l'utilisateur ne risque pas d'obtenir une clé publique périmée. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : la figure 1 est un schéma d'une infrastructure à clé publique mettant en oeuvre le procédé de l'invention, la figure 2 est un schéma des étapes d'un procédé de génération de clés cryptographiques, la figure 3 est un schéma des étapes d'un procédé de renouvellement de clés cryptographiques selon l'invention, la figure 4 est un schéma des étapes d'un procédé d'obtention d'une clé publique selon l'invention. Une infrastructure à clé publique est représentée sur la figure 1. Cette infrastructure comprend un dispositif 10 de gestion de clés cryptographiques. Le dispositif de gestion 10 comprend une autorité locale d'enregistrement 12, une autorité d'enregistrement 14, un opérateur de certification 16 et une autorité de certification 18. Le rôle de l'autorité locale d'enregistrement 12 et de l'autorité d'enregistrement 14 est de recueillir les demandes de clés publiques émanant d'utilisateurs. Elles vérifient notamment la validité des demandes. Dans l'exemple décrit, le rôle de l'opérateur de certification 16 est notamment de générer des clés publiques et privées et d'émettre des certificats numériques certifiés par l'autorité de certification 18. L'opérateur de certification 16 constitue donc à la fois des moyens de génération de clés publique et privée et des moyens d'émission de certificats numériques certifiés par l'autorité de certification 18. On connaît cependant dans l'état de la technique des infrastructures à clé publique dans lesquelles les clés publiques et privées ne sont pas générées par l'opérateur de certification mais par des générateurs de clés à usage personnel. Dans ce cas, l'opérateur conserve tout de même son rôle de moyens d'émission de certificats numériques. Le dispositif de gestion 10 comprend en outre un serveur 20 de clés publiques comprenant des moyens de stockage d'une table 22 de clés publiques. -5- Le serveur 20 de clés publiques est relié à un réseau 24 de transmission de données à distance tel que le réseau Internet. L'autorité de certification 18 est garante du serveur de clés publiques 20, c'est-à-dire qu'elle garantit la validité des données stockées dans le serveur 20. A cet effet, l'autorité de certification 18 restreint l'accès en écriture au serveur 20 aux seules entités en laquelle elle a confiance, comme par exemple l'opérateur de certification 16. Le propriétaire A possède un terminal 26 tel qu'un ordinateur personnel relié au réseau Internet 24. Un utilisateur B possède également un terminal 28 relié au réseau Internet 24. Le procédé de génération de clés cryptographiques du propriétaire A va maintenant être décrit en référence à la figure 2. Au cours d'une première étape 100, le propriétaire A se présente auprès de l'autorité locale d'enregistrement 12 pour faire une demande de clés cryptographiques. Au cours d'une étape suivante 102, l'autorité locale d'enregistrement 12 transmet la demande à l'autorité d'enregistrement 14 qui en vérifie la validité. L'autorité d'enregistrement 14 vérifie notamment l'identité du propriétaire A. L'identité du propriétaire est constituée par exemple par son nom NA, son adresse ou son numéro de téléphone. Une fois que l'identité NA du propriétaire A est connue et suffisamment fiable, 20 l'autorité d'enregistrement 14 transmet au cours d'une étape 104 la demande à l'opérateur de certification 16. L'opérateur de certification 16 génère au cours d'une étape 106 une clé publique Kpä', une clé privée Kpr' et un identifiant IdA. Cet identifiant est par exemple constitué par un grand nombre. 25 Au cours d'une étape 108 suivante, l'opérateur de certification 16 génère un certificat numérique CA comprenant l'identité NA du propriétaire A et l'identifiant IdA mais ne comprenant pas la clé publique KPä'. Le certificat numérique CA comprend également de manière classique des données chiffrées au moyen d'une clé privée de l'autorité de certification, ces données constituant une signature S du certificat numérique. 30 Au cours d'une étape 110 suivante, l'opérateur de certification 16 transmet au propriétaire la clé privée Kpr' et le certificat CA. Lors d'une étape finale 112, l'opérateur de certification 16 stocke dans la table 22 de clés publiques du serveur 20 de clés publiques le couple de données comprenant la clé publique KPä' et l'identifiant IdA. Il associe à ce couple de données une date d'expiration d, 35 de la validité de la clé publique K. -6- Le certificat CA du propriétaire A peut ensuite être diffusé sur le réseau Internet 24 à tous les utilisateurs susceptibles de communiquer avec le propriétaire A. Une fois que le propriétaire A a obtenu un couple de clés cryptographiques et un certificat numérique CA, le renouvellement de ces clés, c'est-à-dire l'attribution de nouvelles clés, est obtenu sans qu'il soit nécessaire d'émettre un nouveau certificat. En effet, le certificat CA ne comprend pas de données liées aux clés cryptographiques qui nécessiteraient d'être renouvelées en même temps que les clés. Le procédé de renouvellement des clés cryptographiques selon l'invention est décrit par la suite en référence à la figure 3. Au cours d'une première étape 200, le terminal 26 du propriétaire A génère une nouvelle clé publique Kpu2 et une nouvelle clé privée Kpr2. On constate ici que les clés ne sont pas nécessairement générées par l'opérateur de certification 16, comme mentionné au début de la description. Au cours d'une étape suivante 202, il envoie un message comprenant la nouvelle clé publique Kpu2 à l'opérateur de certification 16 en signant ce message au moyen de son ancienne clé privée Kpr'. Lors d'une étape suivante 204, l'opérateur de certification 16 vérifie la validité de la signature du message reçu au moyen de l'ancienne clé publique Kpu1 du propriétaire A. Si la signature n'est pas valide, on passe à une étape 206 de fin de procédé. Si la signature est valide, on passe à une étape 208 au cours de laquelle l'opérateur de certification 16 stocke dans la table 22 de clés publiques du serveur 20 de clés publiques le couple de données comprenant la nouvelle clé publique Kpu2 et l'identifiant IdA. L'opérateur 16 associe à ce couple de données une date d'expiration d2 de la validité de la clé publique Kp 2 et modifie la date d'expiration d, associée au couple de données comprenant l'ancienne clé publique Kpu1 pour la rendre égale à la date à laquelle on exécute l'étape 208. Ainsi, la table 22 comprend deux clés publiques Kpu' et IÇ,u2 associées à l'identifiant IdA, la première clé publique Kpu' n'étant plus valide. Le renouvellement de la clé publique du propriétaire A est donc une opération particulièrement simple qui ne nécessite pas d'émettre un nouveau certificat. Dans le cas où l'utilisateur B souhaite émettre un message crypté au propriétaire A, il doit tout d'abord obtenir la clé publique valide du propriétaire A qui lui permettra de crypter son message. Le procédé d'obtention de la clé publique valide va maintenant être décrit en référence à la figure 4. -7-Au cours d'une première étape 300, l'utilisateur B recherche sur son terminal 28 un certificat numérique comprenant l'identité NA du propriétaire A. Les certificats sont généralement intégrés aux signatures des courriers électroniques. L'utilisateur B peut donc rechercher parmi les messages électroniques reçus du propriétaire A un message comprenant le certificat CA. Au cours d'une étape suivante 302, le terminal 28 vérifie la validité de la signature S du certificat CA. Il utilise pour cela une clé publique de l'autorité de certification 18. Si la signature n'est pas valide ou si le terminal 28 n'a pas confiance en l'autorité de certification 18, on passe à une étape 304 de fin de procédé. Si la signature S est valide et si le terminal 28 a confiance en l'autorité de certification 18, on passe à une étape 306 au cours de laquelle le terminal 28 extrait du certificat numérique CA l'identifiant IdA. Au cours d'une étape 308, le terminal 28 émet une requête de demande de la clé publique associée à l'identifiant IdA au serveur de clés publiques 20. Au cours d'une étape 310, le serveur 20 recherche dans la table 22 les couples de données comprenant l'identifiant IdA. Dans l'exemple décrit, il existe deux couples de données comprenant l'identifiant IdA : l'un comprend l'ancienne clé Kpä' et l'autre la nouvelle Kpu2. On recherche alors, parmi ces deux couples, celui dont la clé publique n'a pas expiré. Au cours d'une étape suivante 312, le serveur 20 extrait la clé publique Kpu2 du couple de données comprenant l'identifiant IdA dont la clé publique est valide. Au cours d'une étape suivante 314, le serveur 20 envoie la clé publique Kpu2 au terminal 28. Si le terminal 28 a confiance en l'autorité de certification 18 et étant donné que l'autorité de certification 18 est garante du serveur 20, le terminal 28 a confiance dans la clé publique Kpu2. L'utilisateur B peut alors utiliser cette clé Kpu2 pour crypter des messages à envoyer au propriétaire A. La consultation systématique du serveur de clés publiques 20 permet donc de s'assurer que la clé publique utilisée pour crypter des messages est valide. Cette clé publique permet également de vérifier la signature de messages émis par le propriétaire A de la clé. On notera enfin que l'invention n'est pas limitée au mode de réalisation précédemment décrit. En effet, en variante, lors de l'étape 108 de génération du certificat numérique CA, il est possible que l'opérateur de certification insère la clé publique KPä' dans le certificat -8- numérique généré. Cela permet ainsi d'avoir un format de certificat numérique proche du format actuellement utilisé. Cependant, la présence de cette clé publique dans le certificat est cependant purement formelle et ne permet en aucun cas de se passer de l'étape 112 de stockage dans la table 22 de la clé publique et de l'identifiant. Selon cette variante, le procédé de renouvellement de clés est identique à celui du mode de réalisation principal de l'invention qui a été décrit précédemment en référence à la figure 3. Par conséquent, on constate que la nouvelle clé publique n'est pas introduite dans le certificat initialement émis qui reste donc valable bien qu'il contienne l'ancienne clé publique. Pour éviter tout malentendu, il est important d'informer les utilisateurs de ce certificat que la clé publique qu'il contient n'est pas valide. On préférera donc le mode de réalisation principal de l'invention à cette variante qui est plus contraignante à mettre en oeuvre. REVENDICATIONS 1. Procédé de renouvellement de clés cryptographiques, dans lequel : un propriétaire (A) possède une première clé publique (KP1') et un certificat numérique (CA) comprenant une identité (NA) et un identifiant (IdA) du propriétaire (A), le certificat (CA) étant signé par une autorité de certification (18), et un premier couple de données comprenant ladite première clé publique (KP1') et ledit identifiant (IdA) est stocké dans un serveur (20) de clés publiques dont l'autorité de certification (18) est garante, et comportant les étapes suivantes : ù génération (200), pour le propriétaire (A), d'une seconde clé publique (Kpu2) destinée à remplacer ladite première clé publique (Kpu1), et stockage (208), dans ledit serveur (20) de clés publiques, d'un second couple de données comprenant ladite seconde clé publique (Kpu2) et l'identifiant (IdA). 2. Procédé selon la revendication 1, dans lequel une date d'expiration (d,, d2) de la clé publique (Kpu', Kpu2) est associée à chaque couple de données. 3. Procédé selon la revendication 2, dans lequel, lors du renouvellement de la première clé publique (Kpu1), on modifie (208) la date d'expiration (d,) associée au premier couple de données pour la rendre égale à la date à laquelle on stocke ledit second couple de données (Kpu2, IdA) dans le serveur de clés publiques (20). 4. Dispositif (10) de gestion de clés cryptographiques comprenant : des moyens (16, 26) de génération de clés publiques (Kpu', ç,) certifiées par une autorité de certification (18) au moyen d'un certificat numérique (CA) comprenant une identité (NA) et un identifiant (IdA) d'un propriétaire (A), et un serveur (20) de clés publiques (Kpu', Kp,2), dont l'autorité de certification (18) est garante, comprenant des moyens de stockage de couples de données comprenant ladite clé publique (Kpu', Kpu2) et ledit identifiant (IdA). 5. Procédé d'obtention d'une clé publique stockée dans le serveur de clés publiques d'un dispositif de gestion de clés cryptographiques selon la revendication 4, comprenant les étapes suivantes : ù recherche (300) d'un certificat numérique (CA) comprenant l'identité (NA) d'un propriétaire (A), extraction (306) de l'identifiant (IdA) compris dans le certificat numérique (CA) issu de la recherche, -10- sélection (310) dans le serveur de clés publiques (20) d'un couple de données comprenant l'identifiant (IdA) extrait et dont la clé publique n'a pas expiré, et extraction (312) de la clé publique (Kpu1, Kp,2) comprise dans le couple de données issu de la sélection.5