15 - Chiffrement asymétrique

1 - Pourquoi ne pas se limiter au cas symétrique

⇩ ⇧ ⤊

Nous avons vu le principe du chiffrement / déchiffremment symétrique :

• On chiffre un message avec un clé et on obtient un message chiffré, illible par tous, sauf par ceux qui ont connaissance de la clé utilisée.

On pourra donc utiliser une fonction de chiffrement sous la forme  mc = chiffrer(cle, m)  où  mc  est le message chiffré et  m  le message.


• On déchiffre le message chiffré en utilisant la même clé que lors du chiffrement.

On peut donc écrire une fonction de déchiffrement sous la forme  m = dechiffrer(cle, mc)  où  mc  est le message chiffré et  m  le message.

Il y a deux défauts :

1. On doit partager la clé entre les deux parties et donc il faudrait au début transmettre la clé directement en clair : la clé pourrait donc se faire intercepter assez facilement sur n'importe quel appareil sur lequel le paquet IP passerait.

2. Si on connaît la clé, on peut chiffrer et déchiffrer. L'émetteur peut donc également déchiffrer les autres messages de son interlocuteur s'il partage la même clé.

2 - Principe du chiffrement asymétrique

⇩ ⇧ ⤊

Il y a eu plusieurs types de systèmes de chiffrement asymétrique. Nous ne verrons que la version qui correspond à la version actuelle de ce type de système : le système RSA.

Il comporte deux clés complémentaires, qui sont liées mais différentes. Voici son principe de fonctionnement 

• Si on chiffre un message avec la clé A, il faut utiliser la clé B pour déchiffrer le message.

mc = chiffrer(cleA, m)

md = dechiffrer(cleB, mc)

• Si on chiffre un message avec la clé B, il faut utiliser la clé A pour déchiffrer le message.

mc = chiffrer(cleB, m)

md = dechiffrer(cleA, mc)

Pour que le système fonctionne, on ne doit pas pouvoir trouver facilement l'une des clés à l'aide de la connaissance de l'autre clé.

Une des utilisations les plus courantes est celle où l'une des deux clés est dite publique : tout le monde peut obtenir sa valeur et l'utiliser pour chiffrer des messages à destination d'une unique personne ayant connaissance de l'autre clé qu'on nomme la clé dite privée :

1. Un émetteur chiffre son message en utilisant la clé publique de chiffrement. Il obtient alors un message chiffré.

Si on nomme  mc_pub  le message chiffré obtenu en utilisant la clé publique, on obtient :

 mc_pub = chiffrer(cle_pub, m) 

•  mc_pub  le message chiffré obtenu en utilisant la clé publique
•  cle_pub  la clé publique de chiffrement
•  m  le message en clair

La grande différence avec le cas symétrique est qu'on ne peut pas déchiffrer le message  mc_pub  en utilisant à nouveau la clé publique.

En d'autres termes,  dechiffrer(cle_pub, mc_pub)  ne redonne pas le message  m  !

2. On envoie sur le réseau le message chiffré, indéchiffrable avec la seule clé publique.
3. Le destinataire récupère ce message chiffré et utilise sa clé de déchiffrement ou clé privée pour le déchiffrer et récupérer le message original.


Le destinataire doit maintenant déchiffrer le message chiffré en appliquant la clé privée  cle_pri  qu'il est le seul à connaître. On pourra donc écrire :

 md_pri = dechiffrer(cle_pri, mc_pub)  avec

•  cle_pri  la clé privée de déchiffrement
•  md_pri  le message déchiffré en utilisant la clé privée, qui va donc correspondre au message  m  initial.

Cette fois, nous allons pouvoir utiliser la communication pour envoyer des messages sécurisés vers le serveur distant.

Comment ?

1. Le serveur peut transmettre en clair la clé  cle_pub  de chiffrement
2. Le client peut alors envoyer un message chiffré en utilisant cette clé  cle_pub .
3. Le serveur pourra déchiffrer les messages reçus en utilisant sa clé privée  cle_pri  qu'il doit garder secrète.
   

Le problème vient de la communication dans l'autre sens.

Avec certains systèmes, le serveur pourrait chiffrer les messages qu'il veut envoyer à son client en utilisant sa clé privée  cle_pri . Mais comme il suffit d'utiliser la clé publique  cle_pub  pour déchiffrer les messages chiffrés avec la clé privée, n'importe qui pourrait alors déchiffrer les messages..

Solution 1 : le client génère à son tour un couple  ( cle_pri2 , cle_pub2 )  et transmet sa propre clé publique au serveur, tout en gardant pour lui la clé privée.

Le client pourrait transmettre à son tour sa clé publique au serveur et celui-ci pourra alors lui envoyer des messages chiffrés que seul le client pourrait décoder. Simple.

Pourquoi ne pas faire cela ?

Deux raisons :

1. Les méthodes asymétriques demandent beaucoup de temps de calcul. Plus que les méthodes symétriques. Des communications basées sur ce type de chiffrement sont donc viables uniquement sur des messages courts mais pas pour transférer des messages longs, comme des vidéos par exemple.
2. Cette communication ne protège pas contre les attaques du type Attaque de l'Homme du Milieu ou Man in The Middle en anglais.


Et ni Bob ni Alice ne se rendent compte que quelque chose cloche. Marie reçoit les réponses chiffrées de Bob, les déchiffre, les lit et va alors les transmettre à son tour à Alice, en les chiffrant avec son propre système de chiffrement.



Ni Alice ni Bob ne peuvent savoir qu'ils ne communiquent pas vraiment avec la bonne personne. Même si Alice transmettait sa clé publique à "Bob", elle ne ferait ensuite que communiquer de façon chiffrée avec "Marie-Bob" dans les deux sens !

Solution 2 : le client décide d'une clé symétrique  cle_sym  (par exemple pour utiliser le principe du XOR) et la transmet au serveur en chiffrant le message à l'aide de la clé publique  cle_pub  du serveur.

Le serveur sera alors bien le seul à pouvoir déchiffrer le message contenant la clé symétrique puisqu'il est le seul à connaitre sa clé privée.

A partir de là, les deux pourront communiquer avec un système symétrique solide et rapide.

Notez par contre que si Marie se fait passer pour Bob, ça ne change rien au problème de l'homme du milieu...

3 - Le tiers de confiance

⇩ ⇧ ⤊

Comment parvenir à identifier de façon certaine votre correspondant et éviter le problème de l'homme du milieu ?

Comment être certain que vous discutez bien avec votre Banque (B comme Banque ou Bob) par exemple ? En parlant argent, cela rend tout de suite les choses concrêtes !

L'une des solutions possibles est d'utiliser un tiers de confiance : un organisme reconnu et connu C (comme confiance ou Charlie...) par les deux ordinateurs cherchant à discuter. Alice et Bob connaissent la clé  cpubC  publique de C de façon certaine.

Voici la situation initiale :

Cet organisme C va créer un certificat d'authentification permettant à Alice d'identifier Bob avec certitude, si on accepte de faire confiance à C.

Comment ?

1. Bob fournit à C au moins deux informations : sa clé  cpubB  publique et le nom de son serveur.
2. C va alors la chiffrer en utilisant sa clé privée  cpriC  et
3. fournir le certificat d'authentification à Bob en retour, certificat qui est un message chiffré. Puisque le certificat d'authentification a été chiffré en utilisant la clé  cpriC  de C, on ne peut le déchiffrer qu'en utilisant la clé  cpubC  de C. Et que contient le message une fois déchiffré ? La clé  cpubB  publique de Bob.

Bob obtient ainsi son certificat qui est un message codé à l'aide de la clé privée de C :

 certificat = chiffrer(cpriC, cpubB+nom_du_serveur) .

A partir du moment où Bob obtient son certificat officiel créé par C, il peut recevoir des communications et s'identifier auprès de ses interlocuteurs. Voilà comment.

4. Alice le contacte en clair pour obtenir sa clé publique
5. Bob pourra transmettre deux choses en clair : sa clé publique cpubB et son certificat d'authentification par la même occasion : ni l'un ni l'autre ne sont des éléments à dissimuler.

Alice reçoit une clé publique mais également le certificat d'authentification. Que peut-elle en faire ?

Et bien, comme le certificat a été chiffré en utilisant la clé  cpriC  privée de C, elle peut le déchiffrer en utilisant la clé  cpubC  publique de C, qu'elle connaît.

Alice va donc calculer ceci :

dechiffrer(cpubC, certificat) = 

dechiffrer(cpubC, chiffrer(cpriC, cpubB+nom_du_serveur)) = 

cpubB+nom_du_serveur

Alice n'a alors plus qu'à vérifier que la clé fournie par Bob correspond bien à la valeur qu'elle est parvenue à déchiffrer à l'intérieur du certificat et que le nom du serveur est le bon !

Cette fois, Marie ne peut plus jouer le rôle de Bob : elle ne peut pas facilement intercepter le certificat reçu par Bob (C peut l'envoyer de façon chiffrée puisque Bob connait la clé publique de C) et de toutes manières, Alice ne trouvera pas le bon nom de serveur puisque C refusera de certifier que Marie est bien Bob.

4 - HTTPS

⇩ ⇧ ⤊

Nous pouvons maintenant comprendre comment fonctionne une communication HTTPS qui est un mélange de chiffrement asymétrique (lors de l'authentification et l'établissement de la connection) puis de chiffrement symétrique (lors de la suite de la communication).

1. Un client dispose d'un navigateur Web disposant d'un ensemble de clés publiques correspondant aux organismes de certification auxquels les concepteurs du navigateur font confiance.
2. Un serveur se déclare auprès de l'un des organismes de certification et lui demande de lui fournir un certificat d'authentification.
3. Le client contacte le serveur en clair
4. Le serveur lui transmet en clair sa clé publique et son certificat
5. Le client vérifie la validité du certificat et de la clé publique
6. Le client utilise alors la clé publique du serveur authentifié pour discuter avec le serveur de la méthode de chiffrement symétrique qu'ils vont utiliser lors de cette session de communication : quel algorithme et quelle clé de chiffrement symétrique.
7. A partir de là, client et serveur peuvent communiquer de façon sécurisée en utilisant une méthode de chiffrement symétrique, moins gourmande en temps de calcul.

Et comment faire pour lire le certificat envoyé par un site ? Il suffit de cliquer sur le petit cadenas et de chercher ensuite dans les menus proposés par le navigateur.

A titre d'exemple, voici le début du certificat de ce site :

Le protocole HTTPS est en réalité constitué de deux protocoles :

1. Le protocole TTL (Transport Layer Security) est celui qui gère l'authentification via le certificat et le choix et l'établissement du protocole de chiffrement symétrique.
2. Une fois la communication établie, HTTPS utilise le protocole HTTP de façon habituelle si ce n'est que les requêtes et réponses HTTP sont chiffrées.

5 - FAQ

⇩ ⇧ ⤊

Des différences entre les autorités de certification