David Madore's WebLog: Nouvelle clé PGP (0xBE8D3426C06FFAE6)

Explications sommaires pour les gens ne connaissant rien à la crypto :

PGP (Pretty Good Privacy) est son implémentation GPG (GNU Privacy Guard) est un standard de cryptographie à clé publique (ou asymétrique).

De quoi s'agit-il ? La forme la plus simple de la cryptographie est la cryptographie symétrique (=à clé secrète partagée). En cryptographie symétrique, si Alice veut envoyer un message secret à Bob, Alice et Bob doivent partager une clé secrète et connue d'eux seuls, servant à la fois au chiffrement et au déchiffrement.

(Cette clé prend la forme d'une assez longue chaîne binaire, typiquement quelque chose comme 256 bits, ou, ce qui revient au même, 64 chiffres hexadécimaux, c'est-à-dire quelque chose comme e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, qui doit impérativement avoir été tirée aléatoirement (ou pseudo-aléatoirement de façon cryptographiquement correcte) pour que la sécurité soit correcte — ce n'est pas du tout le cas de celle que je viens de donner —, et c'est elle qui est fournie aux algorithmes de chiffrement et de déchiffrement qui font le travail proprement dit. En fait, normalement l'utilisateur ne la voit jamais vraiment, Alice et Bob vont typiquement avoir uniquement affaire à une passphrase servant à générer ou à déverrouiller la clé selon les circonstances, et qui, elle, est quelque chose de mémorisable par un humain, comme un mot de passe assez long ou une suite de mots formant une phrase suffisamment longue pour assurer le niveau de sécurité voulu. Peu importent ces détails, ce que je cherche avant tout à dire est qu'en cryptographie symétrique, le secret — passphrase ou clé — doit être partagé à l'avance par les personnes qui souhaitent communiquer.)

Au contraire, en cryptographe à clé publique, Bob a deux clés, une clé publique connue de « tout le monde » et une clé privée ou secrète connue de lui seul. Si Alice veut envoyer un message chiffré à Bob, elle le chiffre avec la clé publique de Bob, ce qui produit un message que Bob seul est capable de déchiffrer avec sa clé privée. Et inversement, la cryptographie à clé publique permet aussi de faire de la signature, c'est-à-dire qu'Alice peut, en utilisant sa clé privée, produire un message n'ayant rien de secret dont tout le monde pourra vérifier, au moyen de la clé publique d'Alice, qu'elle en est bien l'émettrice. (Et bien sûr on peut combiner les deux : Alice peut envoyer à Bob un message chiffré par la clé publique de Bob et signé par la clé privée d'Alice, dont Bob pourra, avec sa clé privée à lui et la clé publique d'Alice, lire le contenu et vérifier que c'est bien Alice l'expéditrice.)

(Bon, tout ça est immensément simplifié et outre qu'il existe toutes sortes d'algorithmes différents, je passe énormément de subtilités sous silence. Je n'ai notamment pas expliqué que, pour des raisons essentiellement d'efficacité, la cryptographie à clé publique est utilisée pour chiffrer non pas le message lui-même mais une clé de session qui est elle-même utilisée pour chiffrer le message avec un algorithme de cryptographie symétrique ; et pareil, en signature, on ne signe pas le message lui-même mais une empreinte calculée par une fonction de hachage. J'aurais aussi peut-être dû mentionner le petit miracle de la cryptographe à clé publique qu'est le protocole de Diffie-Hellman qui permet à Alice et Bob de communiquer de façon sécurisée même sans partager de clé à l'avance et même si toutes leurs communications sont espionnées par une tierce personne malveillante ! et ce, sous la seule hypothèse que cette personne (Ève) ne peut qu'écouter et pas modifier les communications au passage, et pas, notamment, se faire passer pour Alice auprès de Bob et pour Bob auprès d'Alice. Je devrais peut-être au moins dire que la cryptographie à clé publique sert absolument partout : dès que vous vous connectez à un site web en https, c'est-à-dire l'immense majorité des sites web de nos jours, celui-ci faisant de la résistance, la connexion est sécurisée par de la cryptographie à clé publique — mais sous un standard qui diffère de PGP dont je parle dans ce billet — essentiellement au moyen d'une clé publique du site web contacté, et qui est elle-même signée par des autorités censément de confiance sous forme d'un certificat ; mais là non plus, je ne veux certainement pas entrer dans les détails.)

L'avantage immense de la cryptographie à clé publique par rapport à la cryptographe symétrique est qu'on simplifie immensément le problème de la distribution des clés : on n'a pas besoin de créer, et de trouver comment partager de façon sûre, une clé secrète différente pour chaque paire de participants qui peut avoir envie de communiquer (une pour Alice et Bob, une pour Alice et Charlie, une pour Alice et David, une pour Bob et Charlie, une pour, etc.), mais seulement deux clés par participants, dont l'une n'a pas besoin d'être communiquée du tout (elle est privée et reste secrète) et l'autre n'a pas besoin d'être communiquée de façon secrète puisqu'elle est, justement, publique. Évidemment, il y a un prix à payer, notamment en termes de longueur des clés, de coût computationnel des opérations, mais je ne rentre pas là-dedans ; par contre il y a une question cruciale qui reste en suspens, c'est la question de l'identité (ou plutôt, de la confiance en l'identité) :

Si Alice veut envoyer un message secret à Bob (ou reçoit un message signé par Bob), elle va utiliser la clé publique de Bob, mais comment est-elle sûre que la clé publique qu'elle croit être celle de Bob est vraiment celle de Bob ?

Par exemple, si Bob est l'auteur d'un logiciel très célèbre (pensez, par exemple, au noyau Linux), et qu'Alice veut utiliser ce logiciel et être sûre qu'il s'agit bien du bon logiciel et pas d'une version malicieuse écrite par une personne malveillante se faisant passer pour Bob, il est utile que Bob signe le logiciel au moment de le mettre en ligne, et Alice pourra vérifier la signature et avoir confiance dans ce qu'elle utilise. Mais qu'est-ce qui assure que la signature vient bien de Bob et pas d'une personne malicieuse ? Il faut avoir confiance en la clé servant à la signature. Or ceci ne fait que repousser le problème (à ceci près qu'une clé est quelque chose de plus léger à contrôler, et change moins souvent, qu'un logiciel énorme dont il y a une nouvelle version tous les quelques jours).

Évidemment, si Alice a rencontré Bob en personne et que Bob lui a donné cette clé en main propre, Alice peut être sûre que c'est la bonne clé. Mais si Alice reçoit un mail de Bob, ou voit passer un billet sur le blog de Bob qui dit coucou, je suis Bob et ceci est ma clé publique, comment peut-elle avoir confiance dans le fait que ce message est bien de Bob et pas de quelqu'un qui cherche à se faire passer pour Bob (dans le but de signer des documents en son nom ou de recevoir des messages chiffrés à son intention) ? La signature électronique est justement l'outil qui permet d'authentifier ce genre de messages, mais pour identifier un message censé émaner de Bob qui dit ceci est ma clé publique, il faut la clé publique de Bob, donc le problème est circulaire.

Une façon de résoudre ce problème de l'identité est que Bob accompagne sa clé publique d'une ou plusieurs signatures, réalisées avec des clés publiques de personnes tierces, qui, elles, ont vérifié soigneusement l'identité de Bob et de sa clé, et qui affirment cette clé précise est bien celle de la personne appelée Bob (bon, ceci soulève ensuite la question sociale de savoir ce que cela signifie de vérifier soigneusement l'identité de quelqu'un, et d'ailleurs ce qu'est l'identité, mais évitons d'entrer dans des questions philosophiques à ce stade). Par exemple, si Alice a confiance dans l'identité de la clé publique de Charlie et en l'honnêteté de Charlie, et que Charlie a vérifié soigneusement la clé publique de Bob et publié une signature l'associant à l'identité de Bob, Alice peut faire confiance à cette signature de Charlie pour savoir que Bob est vraiment Bob. Mais évidemment il faut des hypothèses fausses, car après tout un faux Bob aurait pu faire signer sa fausse clé par un faux Charlie, donc la signature n'a de valeur que si Alice a confiance en l'identité et l'honnêteté de Charlie. Il existe ensuite différents modèles (la toile de confiance proposée par PGP ou, au contraire, la chaîne depuis une racine de confiance utilisée dans le HTTPS sur le web) pour essayer d'établir la confiance en l'identité à partir de telles signatures.

En pratique, le logiciel (libre) GPG, dont je vais dire du mal plus bas mais qui reste utile, permet à tout un chacun de se créer une paire de clés (publique+privée), de chiffrer un document avec la clé privée d'un autre, de vérifier des signatures y compris des signatures attestant l'identité du propriétaire d'une clé, et ce genre de choses. Le maniement en est néanmoins malcommode et, pour ce qui est de la confiance en l'identité, on doit en pratique de toute façon faire à un moment ou un autre un acte de foi plus ou moins large selon le compromis qu'on considère acceptable entre la sécurité et la commodité.

Le but de cette entrée est, donc, d'annoncer une nouvelle clé publique me concernant (signée, inter alia, par l'ancienne), de donner quelques raisons de penser qu'elle est bien de moi, et accessoirement de râler parce que montrer que je sais râler si bien est certainement une façon d'assurer mon identité.