Vous l'avez compris, cette magnifique mécanique ne fonctionnera qu'à une condition : le « concierge » qui détient les clés publiques doit être digne de confiance, faute de quoi, n'importe quoi peut se produire…

Que pourrait-il arriver si une clé publique n'appartenait pas réellement à la personne indiquée ? Tout simplement une personne pourrait se faire passer pour une autre. Une fausse carte d'identité, en quelque sorte.

Tout repose donc sur la confiance que l'on peut mettre dans la personne qui détient les clés publiques.

Généralement, il s'agit d'un organisme de réputation sérieuse , à qui l'on confiera sa clé publique, et dont on détient la clé publique de façon sure. La clé publique de l'organisme permettra de vérifier l'authenticité dudit organisme.

Il existe dans le monde plusieurs organismes (CA) de ce type. Ces autorités ont pour fonction de garantir l'authenticité de clés publiques. Le principe est simple:

1. Une CA dispose d'une clé privée et d'une clé publique associée.
2. Une entité qui a créé une clé publique demande à cette CA d'en assurer l'authenticité.
3. La CA, après avoir effectué les contrôles nécessaires, chiffre avec sa clé privée un paquet contenant la clé publique du requérant ainsi que quelques informations supplémentaires pour clarifier les choses vis-à-vis des personnes qui auront à utiliser cette clé publique.
4. Ce paquet, au format X.509 est alors renvoyé au requérant pour qu'il puisse le présenter aux personnes en ayant besoin.

Typiquement, un serveur web présentant son contenu au format https exhibera ce certificat à tous ses lecteurs pour qu'ils puissent juger de l'authenticité de ce qui leur est diffusé.

Il y a une question ?

Le lecteur attentif aura remarqué que le certificat X509 est signé par la CA. Il doit donc disposer de la clé publique de cette CA. Et qui est-ce qui authentifie cette clé publique ? Généralement une autre CA…

Pratiquement, les certificats des CA sont fournis par les mises à jour du système d'exploitation, des navigateurs web… Il est donc important de s'assurer de l'authenticité des sources de mise à jour

Sous entendu ici les PKIX (Public-Key Infrastructure X.509) que l'on peut assimiler à des CA avec quelques fonctions supplémentaires, pour assurer la conformité des X509

Les certificats X509 sont attribués avec une date de péremption et (aussi une date de naissance). Le propriétaire de ce certificat doit donc assurer son renouvellement en temps utile.

Si pour une raison quelconque, comme la compromission de la clé privée associée, la fin de l'utilité de ce certificat avant sa date d'expiration, le propriétaire doit être en mesure de le signaler au monde. C'est un rôle essentiel de la PKI d'enregistrer cette demande et de mettre à jour aussitôt la liste des certificats révoqués : la CRL (Certificat Revocation List). L'information permettant de récupérer cette liste de révocation est inscrite dans tout certificat émis par la PKI.

Les fonctions principales des PKIX sont donc les suivantes:

• récupération des demandes de certificats,
• réalisation des certificats,
• tenue de la liste de révocation,
• distribution des certificats aux demandeurs…

Lorsqu'une organisation désire mettre en place une telle infrastructure, sans avoir recours à des entreprises spécialisées, il lui est possible de le faire.

Bien entendu, les certificats produits n'auront de valeur qu'au sein de cette organisation. Il existe des projets Open Source qui proposent des outils de gestion d'infrastructure de clés publiques. Nous n'irons pas aussi loin dans cet exposé.

Normalement, si deux interlocuteurs disposent chacun d'un certificat, mais chez des CA différentes, ils ne peuvent à priori se faire mutuellement confiance, sauf si par un procédé quelconque les deux CA affichent une confiance mutuelle. Entrer ici dans les détails nous mènerait vraiment trop loin, mais sachons tout de même que :

• les autorités de certification sont hiérarchisées, il y a des autorités racines et des autorités intermédiaires, ce qui aboutit à une structure arborescente. Si deux autorités intermédiaires sont certifiées par une même autorité  hiérarchiquement supérieure, elles appartiennent au même arbre et donc la confiance est mutuelle, nous avons ici un arbre de confiance,
• deux arbres différents peuvent à un niveau quelconque (mais supérieur à celui des partenaires impliqués), établir entre eux un lien de confiance mutuelle, ce qui donne naissance à des réseaux de confiance.

Une autre méthode consiste à utiliser un réseau de connaissances. J'ai, en principe, confiance dans mes amis et les amis de mes amis sont mes amis, donc, je peux faire confiance à une clé publique qui est contresignée par un ami dont je suis sûr. Ça peut aller loin, c'est le principe de l'homme qui a vu l'homme qui a vu l'homme qui a vu l'homme qui a vu Dieu.

C'est aussi le principe adopté en messagerie électronique par des procédés de signature comme GNUpg, dont peu de mode en connaît l’existence

Le principe est donc assez simple, il faut au départ disposer de clés publiques appartenant à des gens dont on est sûr. Si ces gens dont on est sûr me certifient comme étant authentiques des clés de gens que je ne connais pas, ces clés publiques seront à leur tour réputées sûres.

Vous voyez la limite d'un tel système ? Non ? Alors, imaginez que dans la chaîne, il y ait une clé falsifiée qui passe pour authentique, à la suite d'une malversation quelconque. Alors, toutes les clés certifiées par cette clé falsifiée pourront être ou ne pas être authentiques…

Il est donc assez illusoire d'imaginer ce système comme parfaitement sûr. Fort heureusement, dans la plupart des cas, un seul administrateur certifiera les clés dont nous aurons besoin pour, par exemple, créer un tunnel sécurisé ou simplement une authentification entre deux nœuds d'un même réseau.

Dans la pile des protocoles réseau, il est courant d'utiliser le chiffrement :

• dans le noyau du système, au niveau IP, avec IPsec. Ainsi, tout ce qui passera sur le réseau sera automatiquement chiffré suivant les règles établies sans que les applications n'aient à s'en soucier,
• dans l'espace utilisateur, au niveau des applications elles-mêmes, qui choisiront ou non de chiffrer, avec par exemple, SSL.  HTTPS en est une illustration, comme IMAPS, POPS ou encore SSH.

SSL, développé au départ par Netscape a été repris en OpenSource sous le nom de TLS : Transport Layer Security. Protocole de sécurisation de la couche transport, défini par la RFC 2246. La version 1.0 de TLS est en fait SSL v3.