Connexion élèves

Choisir le(s) module(s) à installer :

Sécurisation des communications

Est-il vraiment nécessaire de parler ici de l'importance de la sécurité des échanges sur internet ?
La généralisation des échanges commerciaux, de données personnelles .... a obligé les standards d'internet à évoluer. Nous verrons dans cette partie les principes généraux du chiffrement des données et un exemple concret avec le protocole https.

Chiffrement symétrique et clef partagée

Principe

Comme c'est la tradition dans les textes d'explication de cryptographie, Alice et Bob tenteront d'échanger un message tandis que Eve tentera d'intercepter le message.
Dans un échange à clef privée, une seule clef est nécessaire pour coder le message. Cette clef est détenue par Bob (l'émetteur) et Alice (la réceptrice).
  • Bob code son message avec cette clef
  • Alice décodera le message de Bob avec le même clef
  • Elle doit donc rester secrète
En effet, si Eve intercepte le message elle ne peut pas le décoder, mais si elle intercepte le message et la clef, alors le décodage est possible.
La clef a nécessairement été échangée à un moment. Ce système de codage n'est donc pas sûr, par contre il est simple...
Lors d'un chiffrement symétrique avec clef partagée (clef publique) :
  • Le message est codé et décodé avec la même clef
  • Cette clef doit donc rester secrète
  • La faiblesse de ce système est donc l'échange de la clef
Le chiffrement est dit symétrique car c'est la même clef qui code et décode le message.

Application

Nous allons tenter de coder un "message" avec ce système de chiffrement symétrique et de clef partagée.
Nous allons coder, non pas un texte, mais une image.
Le problème consiste donc à associer une image à une clef composée de pixels aléatoires pour arriver à une image dans laquelle l'image de départ a disparu.
Voici un exemple pour un peu plus de clarté :
codeage xor

Il est, bien sur, absolument nécessaire que cette opération soit réversible, et que partant de l'image codée associée à la clef on puisse retrouver la clef de départ !
Pour cela nous allons utiliser l'opération logique ou exclusif :
table de vérité du OU EXCLUSIF
E1 E2 S
0 0 0
0 1 1
1 0 1
1 1 0

Le principe de ce codage sera un OU EXCLUSIF pixel à pixel.
La clef de codage devra donc avoir la même dimension que l'image de départ.
Si la clef est suffisamment aléatoire, l'image de départ disparaît lors de l'opération.
Pour bien comprendre le principe du codage et du décodage d'image :
  1. Compléter la colonne "pixel de l'image cryptée" grâce au ou exclusif
  2. En repartant de l'image cryptée et en effectuant un ou esclusif avec la même clef de codage , remplir la colonne "pixel de l'image décryptée".
  3. Que constatez vous ?
  4. Comment allons nous donc décoder les images ?
table de vérité du décryptage d'image
pixel de l'image
à crypter		 pixel de la clef
de codage		 pixel de l'image
cryptée		 pixel de la clef
de codage		 pixel de l'image
décryptée
0 0 0
0 1 1
1 0 0
1 1 1

SOLUTION


C'est donc bien la même fonction qui va coder et décoder les images !


Avant de coder notre système de cryptage d'image, vérifions tout de même qu'il n'est pas "craquable" facilement.
La technique la plus simple pour attaquer un codage symétrique est la force brute :
on tente de décoder le message en testant toutes les clefs possibles.
Partons d'une image de dimensions 1000x1000 :
  1. Combien de pixels contient la clef ?
  2. Chaque composante RVB d'un pixel étant choisie aléatoirement entre 0 et 255, combien de couleurs de pixels différentes sont possibles
  3. En déduire le nombre de clef différentes existant
  4. En considérant que la génération d'une clef, puis le décodage et enfin le test de l'image décodée prend environ 1ms, calculer la durée maximale (en heures, jours, années...selon le résultat obtenu) d'un craquage en force brute d'un tel codage. Conclure.

SOLUTION


Nous allons donc maintenant mettre ce système de cryptographie symétrique en œuvre. Une partie du code est fournie :
from PIL import Image import random as rd def genereclef(l:int,h:int)->list: ''' Génération d'une image aléatoire de dimensions lxh l'image est écrite sur le disque sous le nom clef.png ''' clef=[[0 for i in range (l) ]for j in range(h)] fichierclef = Image.new('RGB', (l,h)) for i in range (l): for j in range(h): clef[j][i]=(rd.randint(0,255),rd.randint(0,255),rd.randint(0,255)) fichierclef.putpixel((i,j),clef[j][i]) fichierclef.save("clef.png") def code(nomFichImage1:str,nomFichImage2:str,nomFichClef:str): ''' la fonction code prend en paramètres le nom des fichiers png de l'image à coder et de la clef, ainsi que de l'image qui va être codée. la fonction ne renvoie rien, elle écrit le fichier de l'image codée sur le disque ''' pass
La fonction genereclef() permet de générer une clef aléatoire de dimension fixée par les paramètres.
Attention à ne pas générer une nouvelle clef à chaque codage ou décodage
  1. Coder la fonction code (vous pourrez utiliser la bibliothèque python PIL que vous avez déjà utilisée au début de l'année ici).
    En python l'opérateur ou exclusif (ou XOR) est ^ 
    
>>> 1^1
0

>>> 0^1
1
>>>255

>>> 0b0110^0b011
5

>>> 6^3
5
  2. Tester cette fonction sur l'image de votre choix
  3. Est-il nécessaire de coder une fonction decode()?
  4. Tenter de décoder votre image codée lors du test avec voter clef de codage
  5. Pour finir, décoder cette image avec cette clef

SOLUTION

Chiffrement asymétrique et clef privée / clef publique

Principe

Dans un échange à clef publique/clef privée il est en fait nécessaire de disposer d'au moins deux clefs.
  • Une clef publique qui sera échangée avec le message.
  • Une clef privée que Bob et Alice possèdent.

Il est aussi possible que les clefs privées d'Alice et Bob soient différentes, comme dans l'image ci-contre.
Les deux clefs sont nécessaires pour coder et décoder le message.
Si Eve intercepte le message et la clef publique, le décodage reste ici impossible car elle ne possède pas les clefs privées.

Exemple d'échange clef privée / clef publique

Pour mieux comprendre ce principe nous allons le mettre en œuvre sur un exemple simple.
Le code de césar est un des codes les plus simple que nous puissions imaginer. Il consiste en une substitution mono-alphabétique lettre à lettre.
La clef du codage et du décodage des messages ainsi codés est donc le décalage utilisé. Dans l'exemple ci-contre, le décalage est de 3 lettres. La clef de ce codage est donc 3.
Nous allons maintenant essayer de comprendre le principe du chiffrement par clef publique / clef privée grâce au codage de César.
Le message codé est le suivant :
GF NZXXP NPWL N'PDE QLNTWP WL NCJAEZRCLASTP.
Il est accompagné de sa clef publique : 2893. La clef privée que vous possédez est cachée ci-dessous.
clef privée 263

Pour décoder ce message, il faut bien sur connaître la méthode de codage.
Le système, très simplifié ici, est basé sur la difficulté qu'il y a à calculer des grands nombres premiers.
La clef publique n = 2893 est en fait le produit de deux nombres premiers n = p x q.
Si l'on travaille sur des grands nombres (par exemple le nombre 1039694172949 est le produit de deux nombres premiers : 1048213 et 991873) , il est très difficile de déterminer p et q en ne connaissant que n (ce n'est bien sur pas le cas ici vu la taille des nombres).
Le plus grand nombre premier actuellement connu comporte 24 862 048 chiffres !
Nous n'étudierons pas ici les mécanismes mathématiques qui permettent de créer de telles clefs.

SOLUTION

Comme vous l'avez compris, la clef publique est ici le produit de la clef privée et du décalage du code de César.
  1. En utilisant votre clef privée et la clef publique, déterminer le décalage du code de César.
  2. Décodez le message ci dessus

SOLUTION

En résumé

De façon générale d'un chiffrement asymétrique le mécanisme est le suivant :
Si Bob veut envoyer un message M à Alice il procédera ainsi :
  • Bob codera le message M grâce à la clef publique d'Alice clef_Alice_publique, ce message M deviendra M_codé
  • Le message M_codé transitera de Bob à Alice par le réseau
  • Alice décodera le message M_codé grâce à sa clef privée clef_Alice_privée
Lors d'un codage asymétrique, le message est codé par une clef et décodé par une clef différente.
(dans l'exemple que vous avez traité le message à été codé par le clef 7 et décodé grâce à la clef 263)

Le protocole HTTPS

Les faiblesses de HTTP

Le protocole HTTP (Hyper Text Transfer Protocol), permet d'échanger des données sur le web, comme vous l'avez vu en première.
Cependant ce protocole présente des failles de sécurité qui ont déjà été exploitées par de nombreuses personnes malveillantes :
  • Il est possible d'intercepter les paquets transitant "en clair" entre le client et le serveur, ce qui interdit tout échange de données sensibles (données personnelles, identifiants bancaires etc...)
  • Un serveur pirate peut, à condition de "tromper" le serveur DNS, se faire passer pour le serveur que vous voulez contacter et répondre à votre requête HTTP pour récupérer vos données

Le protocole HTTPS

Principe

Pour parer aux failles de HTTP, le protocole HTTPS a été créé en 1994 (!).
Il s'est ensuite développé notamment pour les transactions bancaire et l'e-commerce. Le standard HTTPS est ensuite décrit en 2000 dans la RFC 2818 (document un peu austère mais complet).
HTTPS (littéralement « protocole de transfert hypertextuel sécurisé ») est la combinaison du protocole HTTP et d’une couche de chiffrement, généralement TLS (Transport Layer security ou sécurité de la couche transport).
Les objectifs de ce protocole sont les suivants : Pour cela deux solutions sont mises en œuvre :

Mais un problème se pose, si on réalise un chiffrement symétrique par clef privée, le client et le serveur doivent disposer de la même clef, et donc il doivent l'échanger de façon sécurisée !

Description d'un échange

Pour comprendre le principe de HTTPS, nous allons décrire l'établissement d'un échange entre le client et le serveur :
  1. Le client envoie une requête d'échange au serveur https.
  2. Le serveur renvoie un certificat d'authenticité (voir ci-dessus) et une clef de cryptage publique
  3. Le client génère la clef de session qui servira aux échanges de données par la suite.
  4. Le client encode la clef de session grâce à la clef publique envoyée par le serveur.
  5. Le client envoie la clef de session cryptée au serveur.
  6. Le serveur décode la clef de session cryptée grâce à sa clef privée (chiffrage asymétrie).
  7. Le client et le serveur disposent maintenant de la même clef de session.
  8. Les échanges de données peuvent commencer en chiffrement symétrique grâce à la clef de session.
En résumé, HTTPS c'est :
  • Des échanges de données cryptés par une clef de session en cryptage symétrique
  • Une clef de session échangée entre le client et le serveur grâce à une clef publique et une clef privée en chiffrage asymétrique

Le certificat d'authenticité

La clef de voûte du protocole HTTPS est le certificat TLS. En effet, si la requête initiale est envoyée à un serveur pirate, la suite des échanges peut se dérouler normalement !
Des organismes officiels délivrent des certificats SSL à des entreprises, des individus ... afin de valider l'identité de leur site.
Ces organigrammes agissent comme une mairie ou une préfecture qui délivrerait une carte d’identité.
Un certificat TLS est délivré pour une durée limitée et contient les informations suivantes : Le navigateur qui reçoit le certificat pourra ainsi vérifier : Vous avez peut être déjà vu apparaître ce genre d'erreur sur votre navigateur :
Certificat inconnu
Certificat ayant expiré

Exercice

Pour vérifier si vous avez bien compris le principe du protocole HTTPS, classez les propositions suivantes par ordre chronologique et vérifiez votre réponse ci-dessous.
  1. Le navigateur génère aléatoirement une clé de session
  2. Le serveur déchiffre la clé de session en utilisant le même algorithme de chiffrement asymétrique que le navigateur du client
  3. Le navigateur du client demande le certificat du serveur de la banque de chiffrement asymétrique
  4. Le serveur établit une session de communication par chiffrement symétrique avec le client
  5. Le navigateur envoie la clé de session chiffrée au serveur
  6. Le navigateur chiffre la clé de session à l’aide de la clé publique, en utilisant un algorithme
  7. Le navigateur reçoit le certificat et la clé publique du serveur
  8. Le navigateur vérifie l’authenticité du certificat
  9. Le serveur envoie le certificat d'authenticité et la clef publique au navigateur du client