[23 octobre 2018] Seconde partie de notre étude sur le chiffrement expliqué aux NON scientifiques (dont je suis) : le chiffrement Asymétrique à clé privée et clé publique. Si vous aimez les concepts mathématiques compliqués et les « protocoles » complexes, vous allez être servi(e). Mais bon, pas de mystère : impossible de comprendre comment fonctionne le chiffrement en oignon du réseau Tor ou l’authentification de l’émetteur ou du destinataire dans un protocole BlockChain si vous ne possédez pas les base de la crypto(graphie) asymétrique.
On va y aller en douceur, vu le temps que j’ai moi-même mis à comprendre l’usage de la clé publique vs la clé privée… Bienvenue dans le monde numérique dans lequel les clés asymétriques permettent de créer une clé symétrique unique (ça, c’est l’échange de clé de type « Diffie-Hellman« ) utilisée pour tout échange dans une relation « client-serveur » avec le réseau Tor…
Pour celles et ceux qui veulent allez plus loin, je vous recommande « la science du secret » sur le site web wikipedia.fr ou « la-crypto-expliquee-a-mon-voisin » sur le site web du Forum Atena. Vous trouverez aussi dans le « papier blanc » de Gérard Péliks des explication sur l’avenir du chiffrement (le chiffrement « homomorphe » et la cryptologie quantique)…
Je vous invite à (re)plonger dans l’univers du « Régulateur » ? La présentation complète et détaillée en BD est accessible dans le slider ci-dessous. Le résumé pour les littéraires est situé juste après (sans les schémas, je suis incapable d’expliquer quoi que ce soit !)

---

[wonderplugin_gallery id= »224″]

---

chiffrement asymétrique : une clé privée indissociable de sa clé publique

Le chiffrement symétrique, c’est une seule et même clé qui permet de chiffrer et de déchiffrer.
Le chiffrement asymétrique repose sur deux clés indissociables : avec une première clé (secrète : c’est la clé « privée »), un logiciel permet de créer une seconde clé, dite « publique ».

---

chiffrement asymétrique à clé privée et clé publique : une fonction mathématique irréversible

La fonction de génération de la clé publique n’est pas réversible, j’insiste sur ce point technique. A partir de la clé publique, il est IMPOSSIBLE de reconstituer la clé privée d’origine. Impossible en mathématique, ça veut dire très, très difficile (ou très très long en puissance de calcul…). Bref, ce qu’il faut retenir : en cas de perte ou de compromission d’une « clé privée », c’est la paire « clé privée et clé publique » qu’il faut invalider et changer….

---

chiffrement asymétrique à clé privée et clé publique : les conséquences juridiques de la détention de la clé privée

Dixit le Capitaine Klein, directeur d’enquête criminelle de la Gendarmerie nationale, le détenteur de la clé privée d’un compte BitCoin est réputé détenteur du compte BitCoin litigieux et donc pénalement responsable. Dixit le même Capitaine Klein lors d’un colloque le 27 juin 2018, si cela est clair pour les enquêteurs, c’est accepté sans problème par les procureurs et les juges d’instruction. Pour le dire autrement, si la clé privée se trouve en votre possession (dans votre ordinateur ou une clé USB que vous possédez), vous êtes tenu(e) pour responsable de l’usage délictueux de cette clé privée. Par exemple si vous payez en Bitcoin (ou en toute autre crypto monnaie utilisant un protocole de chiffrement asymétrique) un achat de drogues / contrefaçons / images pédo-pornographiques / etc.

---

Contractuellement, dans les blockchains « privées » ou « fermées », c’est la détention de la clé privée qui fait foi. C’est l’usage de la clé privée qui permet d’organiser une convention sur la preuve entre « participants » à une même chaine de blocs. Comme pour le BitCoin, le « titulaire du compte », le « membre » de la Chaine sera la personne qui, à partir de sa clé privée, unique et qu’il conserve secrète, a généré une clé publique utilisée par les autres « membres » qui lui envoient des « messages » (des « transactions » dans le vocabulaire BitCoin).

---

chiffrement asymétrique à clé privée et clé publique : pourquoi 2 clés ?

C’est tout le génie du système : on peut se servir de l’une des deux clés pour chiffrer. Et on ne peut alors déchiffrer qu’avec l’autre clé.

---

chiffrement asymétrique à clé privée et clé publique : la diffusion de la clé publique

L’intérêt du système, c’est que votre clé publique soit… publique, c’est-à-dire qu’elle puisse effectivement être utilisée. Par qui ? Par ceux qui veulent vous écrire, par exemple. Pour faire plus simple, il est possible de confier la diffusion de cette clé publique à un tiers « de confiance » (voir sur ce point « la-crypto-expliquee-a-mon-voisin » sur le site web du Forum Atena).

---

chiffrement asymétrique à clé privée et clé publique : utiliser la clé publique de son destinataire

Vous voulez assurer la confidentialité d’un échange écrit (ou verbal d’ailleurs, du moment que le contenu à chiffrer soit numérique…) avec un destinataire de votre choix ? Utilisez la clé publique de votre destinataire pour chiffrer votre envoi à son attention. Une fois chiffré avec la clé publique du destinataire, personne ne pourra déchiffrer le message. SAUF… le destinataire, qui lui seul détient la clé privée qui a permis de générer la clé publique que vous avez utilisé pour chiffrer… Vous suivez ?

---

chiffrement asymétrique à clé privée et clé publique : petite synthèse ?

---

chiffrement asymétrique à clé privée et clé publique : si je chiffre avec MA clé privée ?

Déja, il est peu probable qu’une personne puisse chiffrer avec la clé privée d’une autre personne… (sinon, la clé privée n’est plus secrète). Le postulat de départ est donc qu’une personne détient seule « sa » clé secrète et qu’il ne la confie à personne.
Imaginons qu’à partir de votre clé privée, vous ayez généré votre clé publique. Juste là, tout va bien. Vous décidez d’envoyer un mail chiffré à un destinataire de votre choix (que nous l’appellerons – avec une rare originalité – « le destinataire »). Tout destinataire ayant accès à votre clé publique pourra déchiffrer le message. Ce n’est donc pas la fonction de confidentialité qui est interessante dans cet usage de la crypto asymétrique, mais le fait que TOUS les destinataires sauront que le message vient bien de vous, car vous seul – unique détenteur de la clé privée – aurez chiffré le message. Le contenu du message importe peu dans un chiffrement par clé privée. En revanche, la fonction « d’authentification » de l’expéditeur est ici remplie : si vous avez chiffré avec votre clé privée, tous les destinataires sont certains que le message vient bien de vous, et de vous seul !

---

chiffrement asymétrique à clé privée et clé publique en pratique : le message « random » pour s’assurer de l’identité de l’expéditeur

J’arrete les discours pour une explication en 5 slides.

---

Vous voulez être certain que celui qui vous écrit est bien l’expéditeur des messages auxquels vous souhaitez répondre ? Commencez par lui envoyer un message « random », n’importe quoi pourvu que vous gardiez secret ce message « random » [PS : « random », ça veut dire « aléatoire » en Molière dans le texte…]

---

Apres avoir adressé votre fichier random à l’expéditeur que vous voulez authentifier, demandez lui de chiffrer ce même message random avec sa clé privée et de vous adressez le fichier random ainsi chiffré.

---

Si le fichier random est chiffré par la clé privée de l’expéditeur, pas besoin en plus de chiffrer le transport du fichier (à quoi cela servirait-il ?).

---

Si le fichier random est chiffré avec la clé privée de l’expéditeur, le destinataire peut déchiffrer ce même message random avec la clé publique de l’expéditeur. C’est l’intérêt même du système de chiffrement à clé privée + clé publique !

---

Moi, destinataire, que dois-je conclure lorsque je déchiffre le message random que m’adresse mon expéditeur ? D’abord, je vérifie si le message random que je viens de déchiffrer est bien strictement identique à celui que j’ai envoyé au départ à mon expéditeur. Si c’est le cas, il y a de très très fortes chances que la personne (notre expéditeur) à laquelle j’ai envoyé un fichier unique dont moi seul connait le contenu, soit celle qui me restitue ce même fichier chiffré.
En plus, si cette personne (toujours notre expéditeur en cours d’authentification) a chiffré le message random à me retourner avec sa clé privée, je ne peux lire le fichier qu’après déchiffrement avec la clé publique correspondante. Et qui peut bien disposer de la capacité à chiffrer un message avec sa clé privée secrète ? Seulement la personne qui a diffusé la clé publique correspondante.
C’est donc bien mon expéditeur qui a chiffré le message que je reçois, et en plus, c’est bien elle qui a reçu mon fichier random, le fait qu’elle m’en restitue un exemplaire chiffré me le prouve.

---

Vous pouvez « double checker » le système en réalisant également un « hash » de votre message random et l’adresser en meme temps à l’expéditeur dont vous souhaitez authentifier l’identité. Bien sûr, il s’agira de l’authentification d’un terminal et le système suppose que la personne qui opère ce terminal est bien celle dont vous attendez qu’elle vous adresse à l’avenir des messages…
En hachant à son tours le message reçu, et en le comparant avec le hash d’origine du message random, l’expéditeur en cours d’authentification saura, pour sa part, que le message n’a pas été modifié lors de son transport. Ce qui nous amène à envisager les « mix » de chiffrement avec clé publique et simultanément, avec une clé privée.

---

chiffrement asymétrique à clé privée et clé publique : confidentialité avec la clé publique et authentification avec la clé privée

C’est ça qui est pratique avec le chiffrement asymétrique, on peut associer deux fonctions dans un même message.

---

chiffrement asymétrique à clé privée et clé publique : les inconvénients du système

---

chiffrement asymétrique à clé privée et clé publique : la méthode « Diffie-Hellman » pour fabriquer une clé symétrique unique

Si l’échange de la clé secrète unique est le point de vulnérabilité principal d’un système de chiffrement symétrique, pourquoi ne pas échanger cette clé de manière chiffrée avec des clés privée + clé publique ? C’est précisément l’objet de la méthode « Diffie-Hellman« . Là, il faut suivre le schéma… L’intérêt de la méthode est de créer une clé symétrique de chiffrement qui repose sur la combinaison des clés privées de l’expéditeur et du destinataire. Dans le réseau Tor qui met en oeuvre ce « procédé » (algorithme), l’expéditeur est la personne qui navigue via le réseau Tor (le « client Tor ») et le destinataire est le réseau (le server Tor d’entrée). Accrochez vous…

---

---

chiffrement asymétrique à clé privée et clé publique : BONUS le chiffrement en oignon du réseau Tor

Comment s’assurer qu’un serveur ne connait que le serveur suivant ou le serveur précédant dans une communication électronique ? Comment faire en sorte que votre adresse IP ne soit pas « pistable » ? Le réseau Tor propose une solution en utilisant un système de chiffrement à partir des clés publiques de chacun des serveurs servant de relai à une communication… Il faudra aller voir les slides pour comprendre en deux étapes : d’abord comment se construit un « chemin » ou « circuit » dans le réseau Tor…

---

…. ensuite, suivre les étapes de collecte des clés publiques de chaque serveur pour comprendre le déchiffrement successif par chacun des serveurs impliqués…

---

---

chiffrement symétrique et chiffrement asymétrique : quelle législation ?

A suivre sur ce blog, le droit du chiffrement. Je me limiterai au droit français du chiffrement, dans la mesure où ce type de législation est exclusivement d’origine nationale et ne fait l’objet d’aucune disposition de l’Union Européenne. Mais si vous voulez pouvoir rédiger votre contrat de BlockChain as a Service, il faudra bien en passer par là aussi…

---

Je me dois de remercier celles et ceux qui m’ont consacré tant de temps pour que je parvienne (enfin) à comprendre les concepts de base de la cryptographie :

---

---

---

---

---