Brevet FR2833439A1 — publié le 20030613

PROCEDE DE CONTROLE D'UN SYSTEME DE CERTIFICATION A CLE PUBLIQUE La présente invention concerne la sécurisation des communications entre ordinateurs et plus particulièrement le contrôle d'une infrastructure de certification à clé publique. Le développement des échanges de données à travers des réseaux de communication ouverts comme l'Internet a engendré d'importants besoins de sécurisation afin de garantir la confidentialité et l'authenticité des données transmises. A cette fin, de nombreuses techniques de chiffrement ont été développées. Parmi celles-ci, on peut mentionner les chiffrements symétriques à clé secrète (DES, etc. ) et les chiffrements asymétriques à clés publiques (RSA, etc.). L'emploi de méthodes de chiffrement à clés publiques est apparu préférable à l'emploi des méthodes de chiffrement à clés secrètes pour réaliser les fonctions d'authentification, de signature/vérification et de distribution/échange de clé, parce que de telles méthodes à clés publiques évitent tout partage préalable, entre les personnes échangeant des données, d'un secret commun. La mise en place d'applications sécurisées reposant sur une méthode de chiffrement à clé publique nécessite l'emploi de moyens de chiffrement appropriés dans les ordinateurs, les serveurs, etc., mettant en oeuvre des protocoles de sécurité reposant sur des algorithmes appropriés. Un logiciel de messagerie sécurisée, un navigateur Internet capable d'établir une session sécurisée, une carte à mémoire, sont des exemples mettant en oeuvre de tels moyens de chiffrement. La mise en place d'applications sécurisées reposant sur une méthode de chiffrement à clé publique nécessite également la création d'une infrastructure de certification impliquant des autorités de certification ayant pour objet de générer, stocker et distribuer des certificats attestant la correspondance entre la clé publique d'un interlocuteur et les données permettant son identification, utilisées dans l'application. Le principal inconvénient des infrastructures de certification à clé publique existantes est qu'on y considère comme acquis le respect des règles par les entités responsables de l'émission des certificats. En effet, il se peut que, volontairement ou non, des erreurs surviennent quant à l'identité d'une entité A, lors de l'enregistrement de cette dernière auprès d'une autorité de certification CA. Ainsi l'autorité CA peut délivrer un certificat attestant que la clé publique KPA est bien celle de l'entité A, alors qu'en fait KPA est celle émise par une entité A'ayant réussi à usurper auprès de CA l'identité de A. Une telle fraude est actuellement indétectable pour les tiers, or le risque d'une telle fraude devient de plus en plus important du fait du développement des i infrastructures à clé publique. L'objet de la présente invention est donc de proposer un procédé de contrôle des infrastructures à clé publique qui limite tout risque de fraude et/ou d'erreur dans la production des certificats par les autorités de certification. Le procédé de contrôle selon l'invention est plus particulièrement destiné à émettre, distribuer et vérifier des certificats dans un système de certification à clé publique réunissant une pluralité d'utilisateurs et d'entités de certification agencées selon une infrastructure hiérarchisée. Selon l'invention, ce procédé est caractérisé en ce qu'à l'exception de l'entité de niveau hiérarchique le plus élevé, chacune des entités de certification disposent d'au moins deux certificats délivrés par deux autres entités distinctes, de même niveau hiérarchique ou de niveau hiérarchique supérieur. Selon une autre caractéristique du procédé objet de l'invention, chacun des utilisateurs dispose d'au moins deux certificats délivrés, un premier certificat délivré par une première entité de certification du niveau hiérarchique le moins élevé et un second certificat délivré soit par un autre utilisateur soit par une seconde entité de certification distincte de ladite première entité de certification. Selon une autre caractéristique du procédé objet de l'invention, la i vérification d'un certificat relatif à un premier élément donné de ladite infrastructure, (ce premier élément étant un utilisateur ou une entité de certification n'appartenant pas au niveau hiérarchique le plus élevé), consiste : . à considérer au moins deux chemins de certification reliant ce premier élément à un second élément appartenant également à ladite infrastructure, * à vérifier les certificats de chacune des entités appartenant à chacun desdits chemins, . à vérifier l'authenticité des signatures de chacune desdites entités et, à vérifier la cohérence des informations ainsi recueillies. Selon une autre caractéristique du procédé objet de l'invention, le second élément considéré pour bâtir les chemins de certification à comparer, est l'entité de certification de niveau hiérarchique le plus élevé. Selon une autre caractéristique du procédé objet de l'invention, le second élément considéré pour bâtir les chemins de certification à comparer est un élément quelconque de l'infrastructure, distinct dudit premier élément, et choisi de façon aléatoire. Selon une autre caractéristique du procédé objet de l'invention, l'ensemble des chemins de certification reliant le premier élément au second élément sont considérés. Selon une autre caractéristique du procédé objet de l'invention, seuls certains chemins de certification reliant le premier élément au second élément et répondant à des critères prédéterminés sont considérés. Selon une autre caractéristique du procédé objet de l'invention, seuls sont considérés un nombre prédéterminé de chemins ayant été sélectionnés aléatoirement parmi l'ensemble des chemins de certification reliant le premier élément au second élément. Selon une autre caractéristique du procédé objet de l'invention, l'opération de vérification est opérée par chaque utilisateur à la réception de tout message accompagné d'un certificat. Selon une autre caractéristique du procédé objet de l'invention, l'opération de vérification est opérée par une entité de certification donnée à la demande d'un utilisateur. Selon une autre caractéristique du procédé objet de l'invention, l'opération de vérification est opérée par une entité de certification donnée après tirage aléatoire du certificat à vérifier. La description qui va suivre en regard d'un dessin annexé, donné à titre d'exemple non limitatif, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. La figure 1 est un schéma de principe d'une infrastructure à clé publique conforme à l'invention. La présente invention va être plus particulièrement détaillée dans le cadre d'une application de messagerie électronique sécurisée utilisant une infrastructure de certification à clé publique répondant à la norme X509. Bien évidemment, l'invention n'est pas limitée à une telle norme ni à une telle application. En particulier l'invention peut être mise en oeuvre quelle que soit l'application considérée, comme par exemple la sécurisation de transactions électroniques. L'application de messagerie électronique donnée à titre d'exemple, concerne des utilisateurs équipés d'ordinateurs reliés entre eux par un réseau de télécommunication approprié tel que l'Internet. Chaque ordinateur est muni d'un logiciel de messagerie mettant en oeuvre la vérification automatique des signatures et des certificats. Un tel logiciel est apte à opérer de telle vérification en accédant à des répertoires de certificats, répertoires stockés dans les mémoires de l'ordinateur ou bien encore stockés dans des serveurs distants accessibles depuis ledit ordinateur via un réseau de communication approprié tel que l'Internet. Chaque utilisateur d'une telle messagerie sécurisée dispose d'une clé publique Kp et d'une clé secrète Ks et des logiciels de chiffrement correspond P et S, P et S sont choisis de façon à être l'inverse l'un de l'autre et de façon que la connaissance de l'un (P) n'entraîne pas la connaissance de l'autre (S). Ainsi tout message chiffré avec la fonction P et de la clé Kp ne peut être déchiffré que par l'utilisateur possesseur de la fonction S et de la clé Ks, et inversement. Par ailleurs, tout message chiffré au moyen de la fonction S et de la clé Ks ne peut l'avoir été que par leur unique possesseur. Il en résulte que prouver son identité, il suffit à l'utilisatrice Alice de signer ses messages, c'est à dire d'appliquer son algorithme secret SA et sa clé secrète KsA à tout ou partie de ses messages, et de fournir un certificat délivré par une autorité de certification attestant que la clé KpA (et donc KSA) est bien sa propriété. L'objet d'un tel certificat est de garantir vis-à-vis des tiers qu'une clé donnée correspond bien à un utilisateur donné. Ce certificat est émis par une autorité de certification notée CA, appelée encore autorité de confiance. Conformément à la norme X509, le format général d'un certificat émis par une autorité de certification CA comporte les champs suivants : i) Numéro de version ; ii) Numéro de série : un numéro unique affecté par l'autorité de certification CA émettrice à un certificat ; iii) Algorithme de signature et paramètres utilisés par CA : par exemple : PKCS# 1 qui est la spécification d'une méthode de signature basée sur RSA, portant sur un condensé MD5 du message à signer ; iv) Emetteur : identité de l'autorité de certification ; v) Période de validité ; vi) Propriétaire : X Il, identité du détenteur du certificat ; vii) Clé publique du propriétaire : Kpx ; viii) Fonction de chiffrement à clé publique et paramètres utilisés par le propriétaire : P ; ix) Signature : signature obtenue en utilisant l'algorithme défini au point iii) des données précédentes (de i) à viii) ) à l'aide de la clé secrète Ksca et de la fonction de chiffrement à clé secrète Sca de l'autorité de certification CA et vérifiable à l'aide de la clé publique Kpca de CA. Les conditions exigées par une autorité de certification pour fournir un certificat à une entité qui en fait la demande est à même de prendre plusieurs formes et relève du libre arbitre de chaque autorité de certification. Il peut être notamment demandé à l'entité à certifier de se présenter physiquement dans les locaux de l'autorité de certification et de faire la preuve de son identité. L'entité à certifier peut également déposer sa demande de certification on line en utilisant une ligne de télécommunication sécurisée ou bien encore après avoir prouvé la possession d'un moyen d'authentification telle qu'une carte bancaire du type à puce dont seul le propriétaire connaît le code secret encore appelé PIN code. Ces conditions ne faisant pas l'objet de la présente invention, elles ne seront donc pas plus amplement détaillées. Considérons qu'Alice envoie un message M à Bob. Alice va donc envoyer non seulement le message M, mais également son certificat, noté Cert (Alice, CA), délivré par une autorité de certification CA et la signature du message Sig (M) opérée à l'aide de l'algorithme de signature, de la fonction de chiffrement SA et de la clé secrète KSA. Le destinataire Bob vérifie le certificat Cert (Alice, CA) à l'aide de la clé publique Kpca et de la fonction de chiffrement à clé publique de l'autorité de certification CA qui peuvent être mémorisées dans le logiciel de vérification équipant l'ordinateur de Bob, ou bien encore obtenues après consultation d'un annuaire de clés publiques. Puis, grâce à la clé publique KpA contenue et de la fonction à clé publique PA dans le certificat, Bob vérifie la signature Sig (M). L'ensemble de ces opérations ayant été accompli Bob est à même de traiter le message M, en ayant une certaine assurance qu'il a bien été envoyé par Alice. Pour des messageries sécurisées concernant un grand nombre de d'utilisateurs, il est nécessaire de prévoir la coexistence de plusieurs autorités de certifications. On retrouve notamment un tel besoin dans des applications de sécurisation de transactions électroniques, comme par exemple le système SET qui concerne les millions d'utilisateurs de cartes bancaires et qui comporte quatre niveaux d'autorités de certification (niveau racine, niveau réseau de cartes bancaire, niveau national et niveau banque). En se reportant à la figure 1, on a figuré une infrastructure à clé publique comportant plusieurs autorités de certification. Ces autorités de certification obéissent classiquement à une organisation hiérarchique donnée, le document US5745574 décrit en détail le principe d'une telle arborescence. On pourra également se référer à la norme ISO X509 qui présente la possibilité qu'une autorité de certification CA2 reçoive un certificat d'une autre autorité de certification CAl. L'arborescente illustrée à la figure 1, à titre d'exemple non limitatif de la présente invention, décrit une arborescence comportant quatre niveaux dont trois niveaux d'autorités de certification. La chaîne classique de certification reliant les différentes entités entre elles est décrite en traits pointillés, les flèches indiquent le sens de la certification. L'autorité CA1 est située au sommet de l'arborescence et occupe donc seule le niveau 1 encore appelé racine. Les autorités CA21 et CA22 occupent le niveau 2. Elles ont reçu chacune un certificat de l'autorité de niveau 1 : CA1. Le niveau 3 est formé des autorités CA31, CA32 et CA33, lesquelles ont respectivement reçu un certificat des autorités de niveau 2 : CA21, CA21 et CA22. Enfin au quatrième niveau se trouvent les entités utilisatrices X, X', Y et Z lesquelles ont obtenu des certificats issus respectivement des autorités de niveau 3 : CA31, CA32, CA33 et CA33. A l'intérieur d'une telle infrastructure hiérarchique traditionnelle, chaque autorité certifie donc les utilisateurs ou les autorités qui lui sont rattachés. Avec une telle infrastructure, il possible de vérifier non seulement l'identité d'un utilisateur X mais encore l'autorité de certification CA31 l'ayant certifié, puis l'autorité de certification CA21 ayant certifié ladite autorité de certification CA31 et ce ainsi de suite jusqu'à remonter à l'autorité de certification CA1. Une telle cascade de certifications est dite chemin de certification Il. Selon, l'infrastructure traditionnelle, il existe un unique chemin de certification entre l'autorité de certification CA1 de niveau 1 et chacune des entités de l'infrastructure. De même, il existe un unique chemin de certification entre deux utilisateurs ou deux autorités quelconques appartenant à l'infrastructure. Ce chemin de certification unique entre deux entités est défini par la réunion des deux chemins reliant chacune des entités à CAl, en supprimant l'éventuelle partie commune qui existe dés lors que les deux chemins passent par une même autorité de certification autre que CA1. A titre d'exemple, le chemin de certification entre X et Y est formé par l'ensemble des certificats suivant : Cert (Y, CA33), Cert (CA33, CA22), Cert (CA22, CA1), Cert (CA21, CAl), Cert (CA31, CA21) et Cert (X, CA31). De la même manière, le chemin de certification entre X et X'est formé de l'ensemble Cert (X', CA32), Cert (CA32, CA21), Cert (CA31, CA21) et Cert (X, CA31). La construction pratique des chemins de certification peut être déduite des informations présentes dans les répertoires stockés localement et accédées par le logiciel de vérification ou bien encore obtenues après consultation d'un ou plusieurs annuaires de clés publiques et de certificats associés hébergés dans des serveurs distants auxquels peut se connecter le logiciel de vérification. Ainsi, supposons que X envoie un message M à Y auquel est attaché son certificat Cert (X, CA31) fourni par CA31 et la signature du message M, Sig (M) à l'aide de la clé secrète Ksx. Y procède alors grâce à son logiciel de vérification à l'authentification en cascade des différents certificats en commençant par le certificat Cert (X, CA31) à l'aide de la clé publique Kpca31 de l'autorité de certification CA31, clé publique préalablement mémorisée ou bien encore obtenue auprès d'un annuaire spécialisé. Puis Y procède à la vérification de Cert (CA31, CA21) à l'aide de la clé publique Kpca21 de l'autorité de certification CA21, clé publique préalablement mémorisée ou bien encore obtenue auprès d'un annuaire spécialisé, et ainsi de suite jusqu'à atteindre une autorité de certification appartenant à son propre chemin de certification remontant à CAl, chemin que le logiciel de vérification parcourt en parallèle ou bien qui se trouve mémorisé dans l'ordinateur de Y. Cette méthode ne permet toutefois pas de repérer d'éventuel dysfonctionnement dans le système tel que par exemple celui constitué par l'existence d'un certificat délivré par l'autorité CA32 à X', X'étant un fraudeur ayant usurpé l'identité de X auprès de l'autorité CA32. Le certificat Cert (X', CA32) associe la clé Kpx'à l'identité X. Y recevant un message en provenance de X'est incapable de détecter la supercherie, même en parcourant le chemin de certification reliant X'à Y. Pour pallier cet inconvénient, la présente invention se propose de créer des certifications croisées, figurées en traits pleins sur la figure 1, à travers l'infrastructure tant au niveau des autorités de certification que des utilisateurs. Ainsi, en plus de la certification classique Il obtenue de son autorité de certification située au niveau inférieur, chaque entité (utilisateur ou autorité de certification) doit disposer d'au moins une seconde certification obtenue soit auprès d'une autre entité de même niveau soit auprès d'une entité d'un niveau inférieur quel que soit ce dernier à la condition que cette entité soit distincte de l'autorité de certification précitée. De préférence, lorsqu'une entité certifie une entité de même niveau, on opère alors une certification croisée, c'est-à-dire que les entités se certifient mutuellement (traits munis d'une double flèche sur la figure 1). Conformément à cette règle, en se référant à la figure 1, on voit que CA21 et CA22 opèrent une certification croisée de leurs clés publiques. CA31 obtient une certification de CA22, tandis que CA32 obtient une certification de CA22 et opère une certification croisée avec CA33. X opère une certification croisée avec Z, X'et Y obtiennent une certification respectivement de CA31 et de CA32. De fait de l'existence de telles certifications additionnelles, il n'existe alors plus un chemin de certification entre deux entités, mais une multiplicité de chemins. Ainsi pour passer de X à Y il existe maintenant plusieurs chemins possibles. Pour simplifier, nous noterons le chemin entre X et Y par les entités ayant une relation de certification entre elles. Les nouveaux chemins entre X et Y sont alors : (X, Z, CA33, Y) (X, CA31, CA21, CA32, Y) (X, CA31, CA21, CA32, CA33, Y) (X, CA31, CA21, CA22, CA33, Y) (X, CA31, CA21, CA22, CA32, CA33, Y) (X, CA31, CA22, CA33, Y) (X, CA31, CA22, CA32, CA33, Y) L'entité Y recevant un message en provenance de X est maintenant à même de parcourir une pluralité de chemins de certification possibles et de détecter d'éventuelles discordances entre ces chemins. Par exemple un chemin peut révéler l'existence d'un certificat venu à expiration, etc. La vérification des chemins peut s'opérer de plusieurs manières. L'évaluation peut être opérée en utilisant un document signé et en vérifiant la signature en utilisant le chemin de certification ou bien encore en vérifiant chacun des certificats du chemin. Pour mettre en oeuvre la présente invention, le logiciel de vérification du destinataire Y est muni d'un algorithme de parcours de graphe qui va identifier les différents chemins à travers l'infrastructure à clé publique considérée qui relient le destinataire Y à l'émetteur X du message M. Les logiciels de parcours de graphe sont connus en eux-même et ne seront pas ici détaillés plus avant, cf. notamment le livre Introduction à l'algorithmique Il publié par Dunod et dont les auteurs sont Cormen et al., qui décrit en particulier des parcours de graphes en profondeur et en largeur. Grâce à la règle établie ci-dessus quant à l'existence de certifications multiples pour chaque entité, il est possible de vérifier plusieurs chemins entre deux entités mais également possible d'inclure ou d'exclure dans les chemins considérés des autorités de certification prédéterminées. Conformément à la présente invention, il n'est pas nécessaire d'opérer une mise en oeuvre systématique l'algorithme de parcours de graphe pour chaque message reçu. Cette opération peut être opérée par sondage. De même, conformément à la présente invention, il n'est pas nécessaire de calculer tous les chemins possibles, mais seulement de calculer un nombre prédéterminé de chemins, par exemple au moins deux chemins ou au moins trois (dans la mesure où autant de chemins existeraient), etc., et de vérifier la cohérence entre ces différents chemins. Ainsi, certains chemins seulement peuvent être recherchés : le chemin le plus court impliquant le plus petit nombre possible d'autorités de certification, le chemin le plus long, le chemin le moins cher (dans la mesure où les certificats sont payants), etc. Conformément, à la présente invention toute discordance entre les différents chemins analysés : existence de certificat non valide ou de signature invalide pour certain (s) chemin (s), va générer l'émission d'un signal d'alerte avertissant l'entité destinataire Y de l'existence d'un problème quant au message M reçu de l'émetteur X, ce problème pouvant porter tant sur l'identité réelle de l'émetteur X que sur également : * l'expiration de la validité des certificats utilisés, . le non respect de certaines politiques de sécurité imposant la vérification de la révocation éventuelle d'un ou plusieurs parmi les certificats utilisés, * la persistance d'informations dont la validité est arrivée à échéance, dans des caches dont le but est d'accélérer les temps de traitement. En revenant à l'exemple illustré, considérons que X'adresse un message à Y en alléguant l'identité de X grâce au certificat obtenu frauduleusement de l'autorité CA32. Plusieurs cas peuvent alors être envisagés. Premier cas, X'n'a pu abuser qu'une seule autorité de certification et ne dispose donc que d'un seul certificat de l'autorité CA32, le parcours des différents chemins opérés par le destinataire Y révèle alors cette particularité et attire l'attention de Y sur le fait que l'émetteur du message ne peut produire qu'un seul certificat. Deuxième cas, X'a obtenu un certificat d'une autre autorité CA31 mais sous une autre identité que celle de X, certificat schématisé en trait double sur le dessin, le parcours des différents chemins révèle alors au destinataire Y, des discordances entre les certificats émis par les autorités CA31 et CA32, discordances portant sur l'identité de l'utilisateur des clés Kpx'et Ksx'. Par ailleurs, le parcours du graphe que constitue l'infrastructure à clé publique selon l'invention, permet également au destinataire Y de retrouver le certificat émis par l'autorité CA31 à l'entité X, de sorte que Y à partir des certificats Cert (X, CA31) et Cert (X', CA32) détecte l'existence d'une même entité X gérant alors les jeux de clés distincts Kpx', Ksx'd'une part et Kpx, Ksx d'autre part. Ainsi grâce à l'évaluation des différents chemins de certification conformément à la présente invention, la supercherie de X'sera, si non révélée, du moins suspectée par l'identification d'un problème quant à ses certificats. Le parcours des différents chemins peut être mis en oeuvre de différentes manières. Selon un mode de réalisation, le parcours des différents chemins de certification suite à la réception par l'utilisateur Y d'un message M émis par l'utilisateur X, est directement opéré par l'ordinateur du destinataire Y à partir des informations accompagnant ledit message, des données stockées dans les mémoires de l'ordinateur et/ou des informations accédées à travers à la consultation de bases de données fournissant des informations sur les certificats émis par les différentes entités de l'infrastructure à clé publique considérée, cette consultation étant opérée à travers des réseaux spécialisés ou encore via l'Internet. A travers les informations reçues, le logiciel est à même de bâtir le graphe formé par l'infrastructure à clé publique et à parcourir les différents chemins de certifications existant entre l'émetteur X du message et son destinataire Y. Selon autre un mode de réalisation, le parcours des différents chemins peut être opéré non par l'ordinateur d'un utilisateur, mais par le serveur d'un organisme de sécurisation ayant plus particulièrement en charge la sécurité de l'infrastructure à clé publique considérée. Dans ce cas, cet organisme parcourt régulièrement le graphe afin de détecter les éventuelles anomalies. En variante, cet organisme peut être sollicité par le destinataire d'un message afin d'authentifier son émetteur. Selon un autre mode de réalisation, la vérification des différents chemins de certification par un destinataire peut être opérée au moyen d'un (ou plusieurs) logiciel (s) se déplaçant à travers l'infrastructure pour être hébergé dans les serveurs des différentes autorités de certification afin d'y opérer localement le contrôle des certificats et la construction des chemins de certification. Les avantages de cette approche est de réduire les temps de calcul en traitant localement les données et en évitant les transferts d'information vers un site centralisé. Quant les vérifications sont faites pour une autorité de certification, le logiciel est transféré vers une autre autorité pour y opérer les vérifications suivantes. Lors que l'infrastructure a ainsi été parcourue de proche en proche, le logiciel réintègre son ordinateur de départ et délivre alors un rapport quant à la cohérence des différents chemins de certifications explorés. De tels agents mobiles ont notamment été décrits par les auteurs Ferber et al. REVENDICATIONS [1] Procédé de contrôle destiné à émettre, distribuer et vérifier des certificats dans un système de certification à clé publique réunissant une pluralité d'utilisateurs et d'entités de certification agencées selon une infrastructure hiérarchisée, caractérisé en ce qu'à l'exception de l'entité de niveau hiérarchique le plus élevé, chacune desdites entités de certification disposent d'au moins deux certificats délivrés par deux autres entités distinctes, de même niveau hiérarchique ou de niveau hiérarchique supérieur. [2] Procédé de contrôle d'un système de certification à clé publique selon la revendication 1, caractérisé en ce que chacun desdits utilisateurs dispose d'au moins deux certificats délivrés, un premier certificat délivré par une première entité de certification du niveau hiérarchique le moins élevé et un second certificat délivré soit par un autre utilisateur soit par une seconde entité de certification distincte de ladite première entité de certification. [3] Procédé de contrôle d'un système de certification à clé publique selon l'une quelconque des revendications précédentes, caractérisé en ce que la vérification d'un certificat relatif à un premier élément donné de ladite infrastructure, ledit premier élément étant un utilisateur ou une entité de certification n'appartenant pas au niveau hiérarchique le plus élevé, consiste à considérer au moins deux chemins de certification reliant ledit premier élément à un second élément appartenant également à ladite infrastructure, à vérifier les certificats de chacune des entités appartenant à chacun desdits chemins, à vérifier l'authenticité des signatures de chacune desdites entités et à vérifier la cohérence des informations ainsi recueillies. [4] Procédé de contrôle d'un système de certification à clé publique selon la revendication 3, caractérisé en ce que ledit second élément est l'entité de certification de niveau hiérarchique le plus élevé. [5] Procédé de contrôle d'un système de certification à clé publique selon la revendication 3, caractérisé en ce que ledit second élément est un élément quelconque de l'infrastructure, distinct dudit premier élément, et choisi de façon aléatoire. [6] Procédé de contrôle d'un système de certification à clé publique selon l'une quelconque des revendications 3 à 5, caractérisé en ce que l'ensemble des chemins de certification reliant ledit premier élément audit second élément sont considérés. [7] Procédé de contrôle d'un système de certification à clé publique selon l'une quelconque des revendications 3 à 5, caractérisé en ce que seuls certains chemins de certification reliant ledit premier élément audit second élément et répondant à des critères prédéterminés sont considérés. [8] Procédé de contrôle d'un système de certification à clé publique selon l'une quelconque des revendications 3 à 5, caractérisé en ce que seuls sont considérés un nombre prédéterminé de chemins ayant été sélectionnés aléatoirement parmi l'ensemble des chemins de certification reliant ledit premier élément audit second élément sont considérés. [9] Procédé de contrôle d'un système de certification à clé publique selon l'une quelconque des revendications 3 à 8, caractérisé en ce que ladite opération de vérification est opérée par chaque utilisateur à la réception de tout message accompagné d'un certificat. [10] Procédé de contrôle d'un système de certification à clé publique selon l'une quelconque des revendications 3 à 8, caractérisé en ce que ladite opération de vérification est opérée par une entité de certification donnée à la demande d'un utilisateur. [11] Procédé de contrôle d'un système de certification à clé publique selon l'une quelconque des revendications 3 à 8, caractérisé en ce que ladite opération de vérification est opérée par une entité de certification donnée après tirage aléatoire du certificat à vérifier.