Le coin du cryptologue : 3 – Le chiffrement à clé publique

La cryptologie expliquée à mon voisin qui n'y connait rien mais qui voudrait savoir... Comme dans toutes mes rubriques "Le coin du cryptologue", un conseil pratique se trouve à la fin.

Vous trouverez :

• mon premier article sur le sujet « le calcul d’empreinte » dans la lettre mensuelle de Forum ATENA du mois d’avril en http://archives.forumatena.org/newsletter-n-89-avril-2016/crypto
• et mon deuxième sur le sujet « Chiffrer, déchiffrer, décrypter » dans celle du mois de mai http://archives.forumatena.org/newsletter-n-90-mai-2016/crypto

Clé publique, clé privée
Le chiffrement à clé publique, dit aussi chiffrement asymétrique, fait intervenir un couple de clés mathématiquement liées. Quand on chiffre un message avec une des deux clés, on déchiffre le message avec l’autre.

Une des clés est dite « clé publique », elle n’est pas un secret et peut être donnée à tout le monde. L’autre clé, mathématiquement liée à la clé publique est par contre un secret que son possesseur doit absolument ne pas révéler, on l’appelle la « clé privée ».

Donc dans le chiffrement asymétrique, quand on chiffre avec la clé privée, on ne peut déchiffrer qu’avec la clé publique correspondante. Quand on chiffre avec la clé publique, on ne peut déchiffrer qu’avec la clé privée correspondante. C’est pourquoi ce chiffrement s’appelle « asymétrique ».

Alice chiffre, Bob déchiffre
Maintenant faisons intervenir les deux personnages Alice et Bob. Alice veut chiffrer un message qu’elle envoie à Bob, et être sûre que seul Bob pourra le déchiffrer. Pourquoi Alice et Bob ? Il est certain que ce chiffrement pourrait aussi bien être fait entre Yuan Zi et Huan Huan (*), les deux pandas géants du zoo de Beauval, mais avouez que ce serait plutôt bizarre. Et puis dans la littérature sur la cryptologie, c’est Alice qui chiffre et Bob qui déchiffre (et Ève qui espionne) alors ne changeons rien aux noms de ces personnages devenus célèbres.

Deux cas peuvent être dès lors envisagés :

1. Alice donne sa clé publique à tous ceux qui en ont besoin, Bob compris. Elle garde jalousement sa clé privée mathématiquement liée à sa clé publique, par exemple sur un token USB protégé par un code PIN. Alice chiffre avec sa clé privée le message que Bob va déchiffrer avec la clé publique d’Alice. Ça marche, mais avouez que ce serait idiot puisque tout le monde pouvant avoir la clé publique d’Alice, tout le monde pourrait déchiffrer son message, alors à quoi bon le chiffrer ?
2. Alice demande à Bob de lui envoyer sa clé publique (celle de Bob, donc). Elle chiffre son message avec la clé publique de Bob, et Bob va déchiffrer le message d’Alice avec sa propre clé privée (celle de Bob donc, qu’il n’a communiquée à personne). Ça marche aussi et c’est la bonne solution.

Le cas 1 est absurde et on l’oublie (sauf dans le cas de la signature électronique, mais ce sera pour le prochain article).

Dans le cas 2, Alice est sûre que seul Bob aura pu déchiffrer son message puisque un message chiffré avec la clé publique de Bob ne peut être déchiffré que par la clé privée correspondante que seul Bob possède. Mais Bob ne sait pas si c’est bien Alice qui a chiffré le message puisque la clé publique de Bob peut être connue par tous. Elle n’est pas un secret, donc Bob ne peut être certain que c’est bien Alice qui a chiffré le message, il ne sait pas en fait qui l’a chiffré. Alice par contre est sûre que c’est Bob, et seulement lui, qui le déchiffrera.

Il manque alors quelque chose ? Oui mais ce sera l’objet d’un prochain article sur le chiffrement symétrique. Restons-en là pour l’instant, et résumons : Quand Alice veut chiffrer un message à destination de Bob, elle demande à Bob de lui indiquer où est sa clé publique. Elle chiffre le message avec la clé publique de Bob, et Bob le déchiffre avec sa clé privée.

La clé publique est-elle celle de Bob ou celle d’Ève, l'espionne ?
Il y a tout de même deux problèmes à résoudre pour que ce modèle soit opérationnel :

• À partir de la clé publique de Bob, puisque tout le monde peut l’avoir, Ève, l’espionne, ne peut-elle pas reconstituer la clé privée de Bob, qui ne serait plus alors un secret gardé farouchement par Bob ? Alors tout s’écroule ! Avec la clé privée de Bob reconstituée, Ève serait dès lors capable de déchiffrer les messages pour Bob, chiffrés par Alice !

Ce problème est résolu par le fait qu’à partir d’une clé publique, il est impossible, ou en tout cas trop difficile avec les moyens de calculs actuels, de reconstituer une clé privée. Cela tient à l’utilisation d’algorithmes utilisés dans la constitution des deux clés, publique et privée, de problèmes mathématiques très difficiles à résoudre. Citons la factorisation d’un grand nombre (RSA) ou la résolution du logarithme discret (Diffie-Hellman). Ce sera expliqué » dans un autre article. Pour l’instant, ne compliquons pas, croyez-moi sur parole.

• Qu’est ce qui prouve à Alice que la clé publique, qui est prétendument celle de Bob, est bien celle de Bob ?  Car supposons qu’Ève envoi à Alice une clé qu’elle fait passer pour être la clé publique de Bob. Si Alice l’utilise pour chiffrer, c’est Ève, et non Bob, qui pourra déchiffrer le message pour Bob, puisque Ève possède sa propre clé privée correspondant à la clé publique qu’elle a envoyée à Alice, en la faisant passer pour celle de Bob. De plus si on pousse le problème plus loin, Ève qui a aussi la clé publique de Bob, rechiffre le message d’Alice avec la clé publique de Bob. Celui-ci déchiffrera le message d’Alice avec sa propre clé privée, et ne saura donc pas que le message aura été lu au passage par Ève. C’est ce qu’on appelle l’attaque du « man in the middle » ou plutôt dans ce cas de la « femme au milieu ».

Ce problème est résolu par le certificat numérique. Quand Bob envoie sa clé publique à Alice, ou la met à la disposition de tous, dans un annuaire de clés publiques, ce ne sont pas les 1024 bits, par exemple, constituant sa clé publique qu’il fournit mais un certificat numérique la contenant. Ce certificat numérique est un fichier qui contient le nom du propriétaire de la clé publique, et divers autres renseignements sur son identité, les dates de validité de ce certificat et le tout est signé numériquement par une autorité de confiance. Cette signature numérique atteste que la clé publique est bien celle correspondant à la clé privée que son propriétaire est le seul à détenir. Si on change ne serait-ce qu’un seul espace, ou un seul bit dans le certificat, le logiciel qui va exploiter ce certificat, à la recherche de la clé publique, s’en apercevra tout de suite. Pourquoi ? Comment ? Ce sera expliqué dans le prochain article sur la signature numérique.

Reste un problème : Le chiffrement à clé publique qui manipule des clés longues et des algorithmes gourmands en puissance de calcul, est très lent, trop lent pour traiter de gros fichiers, beaucoup plus lent que le chiffrement symétrique que nous verrons bientôt. C’est donc le chiffrement symétrique qui va être utilisé pour chiffrer/déchiffrer. Ce sera traité dans un futur article.

Le conseil crypto du mois :
Vous pouvez, je dirais même vous devez, visualiser le certificat numérique d’un site web sur lequel vous allez, quand il vous le demande, déposer une information sensible, comme par exemple les renseignements sur votre carte de paiement, ou sur vos remboursements de santé.

Bien entendu quand un site web vous demande ce genre d’informations, ou d’autres données à caractère personnel, ne les déposez que si ce site vous semble être sécurisé, c’est-à-dire n’est pas en « http:// » mais en « https:// ». Un site web, dont l’adresse commence par https, vous garantit, en principe qu’il est bien le site que vous pensez qu’il est (authentification du site par rapport à votre navigateur) et que toute transaction entre votre navigateur et ce site web sera intègre et confidentielle, parce qu’elle sera chiffrée. Votre navigateur connait un certain nombre de clés publiques. S’il ne connait pas celle du site que vous ouvrez pour la première fois, il vous envoie un message d’alerte et vous demande si vous considérez ce site comme sécurisé. Si vous acceptez, il ajoute le certificat numérique de ce site à son magasin de certificats.

Par exemple si vous allez sur le site https://secure.fnac.com avec le navigateur Mozilla Firefox (pas de publicité ici, logiciel libre, mais les autres navigateurs ont aussi ce cadenas) vous remarquez à droite de l’adresse du serveur web, un cadenas fermé. Cliquez dessus, puis sur la flèche à droite, puis sur « plus d’informations », puis sur l’icône « sécurité », et enfin sur « Afficher le certificat » et vous saurez tout sur son contenu, et jusqu’à la clé publique de ce site. L’important pour vous est « qui a émis/signé ce certificat ? ». Soit vous faites confiance en cette entité et vous poursuivez la transaction, soit vous ne lui faites pas confiance et vous arrêtez la transaction, soit vous ignorez le contenu de ce certificat et vous avez tort.

Dans la lettre du mois de septembre, j’aborderai la signature électronique. Ensuite nous parlerons de chiffrement symétrique et de l’utilisation et de l’échange des clés de chiffrement.

C’est tout pour ce mois-ci.

(*) Aux dernières nouvelles, Huan Huan serait enceinte. Nous connaîtrons le bonheur de savoir qu’un petit panda sera né en France.