Chiffrement et «confiance»

18 Janvier 2015

Cet article est un brouillon.

This article is a draft.

Une notion clé des systèmes de chiffrement des messages électroniques reste très mal comprise, c’est celle de “confiance”, c’est-à-dire la détermination de la validité d’une clé utilisée pour le chiffrement. Tout mécanisme de chiffrement asymétrique nécessite de déterminer un mécanisme par lequel peut être déterminé la légitimité d’une clé, c’est à dire in fine la sécurité du processus de communication. {:.lead}

  • Toc {:toc}

C’est vital, puisque quelque soit la solidité de l’algorithme, il ne sert plus à rien si on ne s’assure pas d’employer la clé du destinataire à l’exception de toute autre (dont évidemment les clés d’attaquants éventuels). Je voudrais donc, dans cette note, revenir rapidement sur les généralités du chiffrement asymétrique, puis expliquer les deux modèles (centralisé/vertical et fédéré/horizontal) de confiance, afin de clarifier ce que signifie accorder ou non sa “confiance” à la clé d’un tiers.

Les personnes qui connaissent déjà les bases pratiques du chiffrement asymétrique et les aventures extraordinaires d’Alice, Bob et Mallory peuvent sauter toute la première partie.

Généralités

Le chiffrement asymétrique repose sur des “clés” composées de deux éléments : une partie publique dont la diffusion est en principe illimitée, et une partie privée qui au contraire doit rester strictement confidentielle. Toute la force de ce mécanisme réside en ceci que la clé publique permet de chiffrer un message que seul le possesseur de la clé privée pourra déchiffrer, et que cette clé privée permet de signer un message, signature qui pourra être vérifiée par n’importe qui possède la clé publique — potentiellement, tout le monde.

Un tel système a donc deux grandes finalités : chiffrer et signer.

  • Chiffrer, c’est faire en sorte que n’importe qui puisse m’envoyer une information que seul moi puisse lire, ou que je puisse protéger des informations que je possède de telle façon à ce qu’elles ne soient pas accessible par qui que ce soit d’autre, même si, par exemple, j’égare une clé USB.

  • Signer, c’est permettre à n’importe qui de contrôler qu’un message qui semble être écrit par moi l’est effectivement. C’est vital pour, par exemple, des informations sensibles telles que des informations de sécurité sur des logiciels très exposés. Chaque version du logiciel MediaWiki (l’ensemble de scripts qui anime Wikipédia) est signée numériquement par Tim Starling. Après avoir téléchargé une mise à jour et avant de l’installer, je peux facilement vérifier qu’il s’agit bien d’une mise à jour légitime. Ça ne garantit évidemment rien sur la qualité du logiciel : ça certifie uniquement que la mise à jour que j’ai téléchargé provient bien de Tim Starling, de la Wikimedia Foundation, à qui je fais confiance a priori puisque je mets leur logiciel sur mes serveurs.

Le problème évident qui se pose est: comment «signer» un document ? On suppose souvent que le chiffrement nécessite un que deux personnes ou plus partagent une clé secrète, dont elles se servent pour chiffrer leurs échanges. Or, si mon système de chiffrement doit permettre à n’importe qui de m’envoyer un message crypté et à n’importe qui de vérifier que c’est bien moi qui ai émis ce message, le secret largement partagé devient public, et n’a donc plus aucun intérêt.

C’est évidemment là que la spécificité du chiffrement asymétrique entre en jeu: la «clé» est composée de deux parties : une partie publique et une partie privée.

  • La partie publique permet de: chiffrer un message et vérifier une signature (on appellera cette partie «clé publique»)

  • La partie privée permet de: déchiffrer un message chiffrée par la partie publique et produire une signature vérifiable par la partie publique (on appellera cette partie «clé privée»)

Il y a donc deux fonctions et quatre opérations :

  1. Une fonction de confidentialité : rendre un message indéchiffrable par quiconque autre que son destinataire.

    1. Opération de chiffrement (avec la clé publique)

    2. Opération de déchiffrement (avec la clé privée)

  2. Une fonction d’authentification, qui permet de contrôler qu’un message provient bien de son auteur supposé.

    1. Opération de signature (avec la clé privée)

    2. Opération de contrôle de signature (avec la clé publique)

Cette logique des clés asymétriques n’est pas extrêmement intuitive : on a du mal à imaginer qu’une clé permettre de faire jouer une serrure dans un sens, mais pas dans l’autre. Mais on peut l’illustrer avec un exemple pratique:

Alice et Bob veulent échanger des messages, et souhaitent que ces messages ne soient lisibles que par eux deux. Ils n’ont a priori aucune confiance dans le réseau par lequel vont transiter lesdits messages (qui peut être internet évidemment, la Poste, ou encore une charrette tirée par un âne, c’est totalement indifférent). Ils génèrent donc chacun une paire de clés (publique + privée), et envoient chacun leur clé publique comme premier message. Ils chiffrent ensuite les messages suivants à l’aide de la clé publique que chacun a reçue, et les signent a l’aide de leur propre clé privée. Ainsi, chacun est certain que le message qu’il reçoit provient bien de son partenaire, et tout va pour le mieux.

Mais le méchant s’eſtoit caché en l’ombre et attendoit.

Mallory, car c’est son nom, a avant tout le monde généré deux paires de clés. Et quand Alice a envoyé sa clé publique à Bob, ledit Mallory (car le réseau, répétons le, n’était pas sûr) a intercepté le message, conservé par devers lui la clé publique d’Alice, et a envoyé à Bob une des clés publiques par lui générées. Il a fait de même avec l’envoi de Bob. Mallory détient donc à ce moment quatre clés publiques, et ses propres clés privées. Notons bien que le fait que Mallory détienne les clés publiques d’Alice et Bob n’est absolument pas un problème : les clés publiques sont… publiques. La mienne est ici.

Mais quand Bob écrit à Alice, il chiffre avec une clé publique qui correspond à une clé privée que seul Mallory détient. Si Alice recevait ce message, elle comprendrait immédiatement que la transmission des clés a rencontré une difficulté, et que Bob ne chiffre pas avec la clé qu’elle lui a envoyée, pas plus qu’il ne signe pas avec la clé privée correspondant à la clé publique qu’elle a reçue de lui. L’interception devrait être flagrante. Mais Mallory ne cesse pas d’intercepter les messages, qui sont chiffrés pour une de ses clés privées. Que lui reste-t-il à faire ? Déchiffrer le message, contrôler la signature de l’expéditeur (dont il possède la clé publique) et le chiffrer à nouveau avec la clé publique qu’il a reçu du destinataire supposé, en le signant avec la clé privée qu’il a envoyée. Il peut même aller plus loin, et modifier les messages, ou simplement ne pas les relayer. Alice et Bob ne parlent plus, en réalité, qu’avec Mallory. Résumons l’attaque de ce dernier :

  1. Alice et Bob ont généré leurs clés. Alice, la clé KA, composée de KApub et KApriv (partie publique/partie privée), Bob, la clé KB, composée de KBpub et KBpriv.

  2. Alice envoie KApub à Bob, Bob envoie KBpub à Alice.

  3. Mallory intercepte la transmission des clés. Il récupère KApub et KBpub.

  4. Il génère lui aussi deux paires deux clés, KMA et KMB: KMA, composée comme les autres de KMApub et KMApriv, et KMB, idem. Il envoie KMApub à Bob comme étant la clé d’Alice, et KMBpub à Alice, comme étant la clé de Bob.

  5. À ce point :

    • Mallory détient :

      • KApub. Il sait que c’est la clé publique d’Alice.

      • KBpub. Il sait que c’est la clé publique de Bob.

      • KMA et KMB, parties secrètes et publiques.

    • Alice détient :

      • KApub et KApriv, qu’elle sait être sa propre paire de clés.

      • KMBpub, qu’elle croit être la clé publique de Bob. Avec cette clé, elle croit qu’elle peut chiffrer des messages que seul Bob pourra lire.

    • Bob détient :

      • KBpub et KBpriv, qu’il sait être sa propre paire de clés.

      • KMApub, qu’il croit être la clé publique d’Alice. Avec cette clé, il croit qu’il peut chiffrer des messages que seule Alice pourra lire.

  6. Alice envoie à Bob un message qu’elle signe avec sa clé privée KApriv, et chiffre avec la clé publique KMBpub.

  7. Mallory intercepte la communication, déchiffre le message (avec KMBpriv), en contrôle la signature (avec KApub), puis chiffre à nouveau le message, cette fois avec KBpub, et le signe avec KMApriv. Il peut l’avoir modifié.

  8. Bob reçoit un message chiffré avec KBpub, qu’il déchiffre aisément avec KBpriv. Il en contrôle la signature : elle correspond bien à KMApriv, qu’il pense avoir reçue d’Alice.

Mallory a donc un contrôle total sur les échanges d’Alice et Bob, qui eux se pensent à l’abri de la moindre interception. On appelle cela une attaque de l’homme du milieu, ou Man in the Middle, en abrégé MitM.

La confiance, ce douloureux problème.

La difficulté d’échapper à Mallory saute aux yeux : si Bob et Alice avaient pu se rencontrer pour échanger leurs clés, au lieu de les confier à un charretier corruptible, rien n’aurait pu se produire, et Mallory, au pire, aurait pu bloquer le transit des messages. Mais ce n’était pas forcément possible. Or, il est impossible de sécuriser cryptographiquement le transit des clés, puisque précisément ce transit est un préalable nécessaire à toute opération cryptographique. La saillante analyse que fît de sa situation le maréchal Cambronne dans l’instant qui précéda l’assaut final des Anglais, et dont seul le dernier mot nous parvint, s’impose : on n’est pas dans la merde.

Signer une clé

Une clé est un message comme un autre : on peut la représenter comme une séquence de caractères, ou de nombres. On l’a vu, Alice et Bob se les échangent comme n’importe quel message, or, on l’a vu aussi, un message peut être signé. Si Alice et Bob, qui ne peuvent se rencontrer, avaient eu un ami commun à qui ils accordaient une confiance absolue et qu’ils pouvaient, lui, rencontrer, cet ami aurait pu remettre à chacun en personne sa propre clé publique, puis, à l’aide de sa clé privée, signer les clés publiques d’Alice et Bob, juste après leur génération et avant leur envoi. Alice et Bob auraient chacun pu contrôler la signature de cet ami sur la clé publique reçue, signature que Mallory aurait été incapable de contrefaire, puisqu’il ne peut pas, en personne, se faire passer pour cet ami. Et cet ami n’aurait pas eu accès aux clés privées, la transmission aurait donc été sûre.

Tout le principe de la confiance repose donc là dessus : si l’authentification des clés des parties n’est pas possible a priori, seul un tiers peut garantir leur valeur, puisque un tel tiers peut signer une clé comme n’importe quel message. Il est important de noter que cette question de certification des clés, de confiance, ne concerne que les clés publiques — les clés privées ne sont pas concernées, puisqu’elles ne sont pas disposées à circuler, même si quelques mécanismes parallèles sont disponibles, dont la révocation.

Mais ce tiers, cet ami miraculeux, qui est-il ? Deux modèles d’ami sont disponibles sur le marché cryptographique.

L’ami américain : un modèle vertical, la racine au sommet

Le modèle le plus répandu, et le plus transparent à l’utilisation (ce qui ne veut pas dire le plus fiable) consiste à attribuer a priori une confiance absolue à une série de clés publiques appartenant (= dont la partie privée est détenue par) généralement des entreprises ou des institutions publiques. Ces clés, que l’on va appeler «certificats racines», sont ensuite utilisées pour signer les clés publiques de parties dont ces institutions ont garanti l’authenticité, par différents moyens. Il peut s’agir de simplement vérifier que le tiers qui requiert la signature de sa clé possède bien le nom de domaine qu’il prétend protéger par des moyens cryptographiques, ou alors de s’assurer en détail de l’identité de la personne demanderesse.

Comme c’est le modèle du https des navigateurs web, on va s’en servir d’exemple (mais il peut servir à tout, et sert à bien d’autres choses). Dans ce modèle, chaque clé certifiée par une autorité l’est pour un nom de domaine donné. Rappelons bien sûr qu’une clé signée dans l’absolue n’a aucun sens : signer, ce n’est pas garantir que cette clé cryptographique est fiable dans l’absolu, c’est garantir que l’on a pu s’assurer qu’elle était bien détenue par la personne qui s’en revendique d’être le propriétaire. N’importe qui peut générer une clé et l’appeler google.com, Barack Obama ou autres. L’autorité de certification vient justement garantir qu’après vérification, cette clé-là appartient bien à Google ou Obama.

Le nom «certificat racine» fait référence à la possibilité de mettre en place des certificats de niveau intermédiaire, entre une racine et la clé utilisée pour le chiffrement effectif de la transmission : on parle alors de chaîne de certification. Par exemple, la clé de chiffrement utilisée sur https://google.com est signée par Google Internet Authority, certificat intermédiaire lui-même signé par Equifax Secure Certificate Authority. Google dispose d’un tel certificat intermédiaire lui permettant de signer directement la totalité des clés de chiffrement qu’il utilise sur ces domaines, et chaque navigateur connaît a priori le certificat racine Equifax. Le navigateur remonte la chaîne de certification jusqu’à trouver un certificat en lequel il considère avoir confiance :

  • http://www.google.com/ présente une clé inconnue, signée par un certificat intermédiaire.

    • Google Internet Authority est le nom d’un certificat intermédiaire inconnu, mais signé par un certificat racine que l’on peut contrôler.

      • Equifax Secure Certificate Authority est un certificat racine stocké directement dans le navigateur. La confiance est assurée par lui.

Arrivé au certificat racine, la chaîne est complète : elle va bien de la racine à la clé effectivement utilisée par le chiffrement.

Chiffrer ou certifier ?

Ce modèle introduit une confusion possible, et courante, entre le chiffrement d’une transmission et l’authenticité du site consulté. Une racine, ou un titulaire de certificat intermédiaire, peuvent procéder à plusieurs niveaux de vérification (auxquels correspondent des coûts variables). Le plus basique (domain validation) consiste à s’assurer que le demandeur de certification contrôle bel et bien le site pour lequel il demande la signature de sa clé publique 1. Mais la garantie est alors purement technique, et l’utilisateur s’arrête souvent à la présence de la mention https ou du cadenas dans la barre d’adresse pour s’assurer de la sécurité de la communication, sécurité partiellement illusoire.

Le niveau de certification supérieur (organizational validation) garantit non plus le nom de domaine, mais l’organisation demandeuse du certificat. Dans ce cas, la plupart des navigateurs indiquent le nom de cette organisation en regard de l’adresse. Voici par exemple comment se présentent, sous Firefox, les sites de Gandi, qui utilise ce niveau de certification, et de la banque française La Caisse d’Épargne, qui ne certifie que son de domaine:

Deux niveaux de vérification : Contrairement à Gandi, la Caisse d'Épargne ne dispose que d'une certification du nom du domaine, qui empêche ou limite l'interception, mais ne garantit pas que ce nom de domaine soit effectivement lié à la banque.

Firefox fait de son mieux pour différencier les deux niveaux de sécurité, mais beaucoup de personnes se feront certainement avoir si on parvient à les envoyer en https sur www-caisse-epargne.fr (ce domaine est pour l’instant disponible…) ce qui ne présente aucune difficulté technique particulière — l’unique difficulté étant de les y envoyer ; le phishing sert à ça.

Je peux acheter un nom de domaine au nom très proche de celui d’une banque, et tenter d’une façon ou d’une autre d’orienter des personnes (par exemple, en envoyant des mails prétendument écrits par cette banque) vers ce site. Je peux tout à fait obtenir la signature de mes certificats de chiffrement, associés à ce nom de domaine, puisque je le possède bel et bien. La communication sera bien chiffrée (et donc impossible à intercepter) mais l’utilisateur croira être en lien avec sa banque, et ça ne sera pourtant pas le cas. Une attaque par l’homme du milieu est alors parfaitement possible.

Faut-il faire confiance aux racines ?

Ce type d’attaque, trivial, est parfaitement possible, et peut donner, s’il est bien mené, d’excellents résultats. Il découle immédiatement de la transparence du modèle : à ne pas embarrasser l’humain lambda avec les technicités de la confiance, on l’incite à accorder ladite confiance sans trop réfléchir.

Mais plus profondément, ce modèle qui repose

Le problème est ici évidemment la confiance absolue accordée a priori. L’autorité de certification n’a certes aucun moyen d’intercepter les communications établies au moyen des certificatss

Un modèle horizontal : le réseau de confiance ou network of trust.


  1. Généralement en demandant l’ajout d’un enregistrement DNS TXT ou en envoyant un mail à une adresse traditionnellement réservée à l’administration, telle “postmaster@[domaine]”, contenant un lien ou un code de vérification.