# TP R3.17 Notions de cryptologie

Vous utilisez deux machines virtuelles situées dans le même réseau, une avec interface
graphique (pour le client) et l’autre pour le serveur ou l’autorité selon la question. Vous vous
placez dans votre machine virtuelle dans le répertoire /home, avec le compte étudiant. Ne pas
se mettre en mode root, sinon des manipulations ne seront pas possibles (ne me demandez pas
pourquoi, je l’ai constaté). Vous ferez un compte-rendu en répondant aux questions avec des
copies d’écran agrémentées de (nombreux !) commentaires

# 1 Chiffrement symétrique

1) Générez une clé secrète de 32 octets et stockez la dans le fichier de la clé secrète


Une clé de 32 octets (256 bits) a été générée et stockée dans le fichier cle_secrete
2) Visualisez cette clé. Une clé de taille comprise entre 3𝑛 − 2 et 3𝑛 octets est représentée
en base 64 par 4𝑛 symboles. Est-ce vérifié avec votre clé ?

La clé en Base64 fait bien 44 caractères, ce qui est cohérent avec la règle :

une clé de 32 octets (3n - 2 ≤ taille ≤ 3n) → 4n symboles en Base64.

3) Créez un message court message.txt avec la commande nano

4) Chiffrez le message avec l’algorithme aes avec 100 itérations et votre clé secrète.

Le message a été chiffré avec AES-256-CBC, 100 itérations et la clé secrète générée.

5) Visualisez le message chiffré. Est-il compréhensible ?

Le fichier chiffré est illisible (binaire).
→ Le chiffrement a bien été appliqué, le contenu n’est plus compréhensible.

6) Déchiffrez le message chiffré. Retrouvez-vous le message initial

Le message initial est bien retrouvé, preuve que le chiffrement/déchiffrement est correct.

7) La taille du fichier clair est plus petite que celle du fichier chiffré. Pour un message non
chiffré de taille comprise entre 16𝑛 et 16(𝑛 + 1) octets, celle du chiffré est de
16(𝑛 + 𝑘) octets. Déterminez la valeur de 𝑘

Le message chiffré est légèrement plus long que le message original, à cause du remplissage (padding) et du vecteur d’initialisation (IV).
La différence de taille correspond à k = 1 bloc de 16 octets ajoutés.

# 2 Chiffrement asymétrique

**Génération de clés privées**

8) Générez une clé privée rsa de 2048 bits non chiffrée dans un fichier nommé rsa1

Une clé privée RSA de 2048 bits a été crée.

9) Visualisez votre clé privée rsa1.
D'après la capture précedente nous pouvons bien appercevoir notre clé rsa1 généré .

10) Générez une clé privée rsa de 2048 bits chiffrée avec la clé précédente (rsa1) dans un
fichier nommé rsa2


11) Visualisez votre clé privée rsa2. En quoi l’affichage (obtenu avec cat) diffère de celui
de la clé rsa1 ?
Le fichier rsa2 est illisible sans la clé rsa1.
L’affichage diffère car le contenu est chiffré.

12) Générez une clé privée rsa de 2048 bits chiffrée avec un mot de passe dans un fichier
nommé rsa3.

13) Visualisez votre clé privée rsa3
La clé est chiffrée avec un mot de passe.
Le contenu est similaire à rsa2 (illisible sans mot de passe).

14) Extrayez la clé publique de votre dernière clé privée rsa3 dans un fichier nommé
rsapub3.

15) Visualisez la clé publique. En quoi l’affichage (obtenu avec cat) diffère de celui de la
clé rsa3 ?
Contrairement à la clé privée, il ne contient pas de données sensibles et peut être diffusé.

16) Quelle clé (publique ou privée, de qui ?) faut-il utiliser pour chiffrer un fichier pour
ensuite l’envoyer à quelqu’un d’autre ?

On utilise la clé publique du destinataire → seul lui pourra déchiffrer avec sa clé privée.

17) Quelle clé (publique ou privée, de qui ?) faut-il utiliser pour déchiffrer un fichier reçu ?

On utilise sa propre clé privée, correspondant à la clé publique qui a servi au chiffrement.

18) Chiffrez le fichier du message clair de la question 3) avec votre clé rsa3.

19) Visualisez le fichier chiffré. Que se passe-t-il ?

20) Vérifiez que vous pouvez chiffrer des fichiers de taille inférieure ou égale à 245 octets.
Quelle est la raison évoquée pour le non chiffrement ? Il est possible d’utiliser truncate
-s 200 <nom_du_fichier> pour créer un fichier de taille 200 octets

21) Chiffrez un message puis déchiffrez le.

> Remarque:

---
Un petit fichier (≤ 245 octets) peut être chiffré avec RSA.
Les fichiers plus grands échouent, car RSA ne peut chiffrer que des blocs inférieurs à la taille de sa clé (2048 bits ≈ 256 octets).
Le chiffrement/déchiffrement fonctionne correctement pour un petit message.

# 3 Empreinte et signature

22) Créez une empreinte du fichier du message clair.

23) Créez une copie du message clair en changeant le nom. Calculez l’empreinte de ce
nouveau message. Observez-vous une différence avec l’empreinte de la question
précédente.

Les empreintes de fichiers identiques sont égales.
Une simple modification du message change complètement l’empreinte — c’est la propriété d’avalanche du hachage.

24) Modifiez le texte de la copie du message. Calculez son empreinte. Observez-vous une
différence avec l’empreinte de la question précédente.


25) Créez une empreinte signée (avec rsa3) du fichier du message clair en utilisant la
méthode en deux étapes. La première étape a été effectuée à la question 22


26) Vérifiez la signature.

27) Créez une empreinte signée du fichier du message clair en une seule étape


28) Vérifiez la signature obtenue en une seule étape.

Création et vérification de signature :

La signature lie une empreinte (SHA256) à une clé privée.

Elle garantit l’intégrité et l’authenticité du fichier.
Si le fichier change, la vérification échoue.

29) Modifiez le fichier du message clair puis vérifiez sa signature (Celle obtenue à la
question 27). Que se passe-t-il ? Pourquoi ?

La vérification échoue, car la nouvelle empreinte ne correspond plus à celle signée.

30) Le fichier dechiffrer_moi.chi est à déchiffrer. Il a été chiffré avec l’algorithme aes-256-
cbc, avec une itération de 50, un mot de passe fourni interactivement, dont l’empreinte
md5 est soit f09c151e4c4da962270e26b9abd6d0ef, soit
50531ac166c73adfecb2781773e33813.

31) Trois fichiers mess1.txt, mess2.txt et mess3.txt sont hachés (avec SHA256) puis signés
avec (cle1.essai ou cle2.essai) en une seule étape, pour donner mess1.hash.sign,
mess2.hash.sign et mess3.hash.sign
Vous avez à votre disposition sur UPdago les trois signatures, les deux paires de clés
(privées et publiques d’extension pem) et les trois messages. Cependant, un des trois
messages a été entre temps modifié. Vous devez trouver avec quelle clé les messages
ont été signés, et quel message a été modifié. Il faut donc d’abord vérifier la signature
(comme à la question 26) puis l’empreinte (comme à la question 28). Si vous n’effectuez
qu’une seule vérification comme à la question 28, un échec peut provenir d’une
mauvaise clé ou d’un mauvais fichier, si bien que vous ne connaitrez pas la raison da la
vérification défaillante.

D'après les captures suivantes nous pouvons constater que
mess1.txt a pour cle cle1.essai.pub.pub et pour signature mess1.hash.sign mais comme il ne passe pas cela signifie que c'est son message qui a été modifié.
mess2.txt a pour cle cle2.essai.pub.pub et pour signature mess2.hash.sign.
mess3.txt a pour cle cle1.essai.pub.pub et pour signature mess3.hash.sign







# 4 Certificats

Vous avez à votre disposition deux machines virtuelles (situées dans le même réseau), l’une va
jouer le rôle de l’autorité de certification et l’autre celle du client. Le scénario est le suivant : le
client va effectuer une demande de certification de sa clé à l’autorité, qui en retour lui transmet
tous les certificats. Vous créez sur vos deux machines une paire de clés rsa (privée – publique)
sans les dissocier.

32) Créez une paire de clés rsa pour l’autorité sous le nom autorite.cle

33) Créez un certificat pour cette paire de clés sous le nom autorite.certif en complétant tous
les champs.

34) Visualisez le certificat de l’autorité. Vous devez retrouver les informations fournis lors
de la création.

35) Créez une paire de clés rsa pour le client sous le nom client.cle


36) Créez une demande de certificat sous le nom demande.client en complétant tous les
champs

37) Visualisez votre demande. Expliquez la réponse obtenue.

38) Envoyez la demande du client à l’autorité

39) Signez la demande du client par l’autorité.

40) Visualisez les informations contenues dans votre certificat signé. Les données présentes
dans subject correspondent à qui ? Et celles de issuer ?

41) Vérifiez la validité de votre certificat signé.


42) Envoyez tous les certificats au client de la part de l’autorité.

Nous ommes aller sur le client pour regarder si il avit obtenue tout les certificats .


43) Créez un fichier de l’enveloppe avec les fichiers du certificat et de la clé.

44) Lancez Firefox :
 Sélectionnez paramètres ou préférences
 Recherchez certificat
 Affichez les certificats…
 Cliquez sur Importer…
 Sélectionnez Tous les fichiers (en bas à droite) dans Récents (en haut à gauche)
ou Dossier personnel
 Choisissez le fichier de votre enveloppe
 Sélectionnez Ouvrir
 Indiquez le mot de passe utilisé pour l’export puis Connexion
Le certificat est visible. Il reste à faire apparaitre l’autorité de certification.
 Affichez les certificats…
 Sélectionnez votre certificat
 Sélectionnez Autorités (en haut à droite)
 Cliquez sur Importer…
 Sélectionnez Tous les fichiers (en bas à droite) dans Récents (en haut à gauche)
ou Dossier personnel
 Choisissez le certificat de l’autorité
 Sélectionnez Ouvrir
 Faites confiance à tout puis OK
Double cliquez sur votre certificat : il comporte tous les renseignements fournis, ceux du client
et de l’autorité.

> Remarque:
Les étapes 32 à 44 montrent la création d’une autorité (CA), la génération de certificats, la signature des demandes et l’importation des certificats dans Firefox.
Cela illustre le modèle de confiance basé sur les autorités de certification (CA).

# 5 Chiffrement hybride sans secret au préalable partagé

***Le chiffrement hybride mélange le chiffrement symétrique et le chiffrement asymétrique.
Alice désire envoyer un message à Bob. Chacun possède sa paire de clés rsa, 𝐶஺ష et 𝐶஺శ
pour Alice, 𝐶஻ష et 𝐶஻శ pour Bob. Alice possède sa clé secrète 𝐶. Tout se déroule pour vous
sur le même ordinateur, comme s’il y avait réellement un envoi, même si toutes les données
se trouvent uniquement sur votre ordinateur. Les échanges sont confidentiels, avec contrôle
de l’intégrité, authentification de l’émetteur et du récepteur basé sur les clés privées sans
utilisation de certificats.***

45) Quelles sont les clés à créer ? Et vous les créez.

ce qu’il me manque, c’est uniquement :

🔹 La paire de clés RSA d’Alice

C’est-à-dire :

cleA.pem → clé privée d’Alice

cleA_pub.pem → clé publique d’Alice


46) Vous calculez l’empreinte du message chiffré avec sha256.


47) Vous signez cette empreinte avec la bonne clé (Laquelle ?)

La clé à utiliser pour signer, c’est la clé privée d’Alice : cleA.pem.
car :
C’est Alice qui envoie le message → donc c’est elle qui signe.

On signe avec sa clé privée pour que le destinataire (Bob) puisse vérifier la signature avec la clé publique d’Alice (cleA_pub.pem).

C’est ce qui assure l’authentification (on sait que ça vient bien d’Alice) et l’intégrité (le message n’a pas été modifié).


48) Vous chiffrez le fichier de la clé secrète avec la bonne clé (Laquelle ?)

On la chiffre avec la clé publique de Bob (cleB_pub.pem) car : Seule la clé privée de Bob (cleB.pem) pourra déchiffrer ce fichier.

C’est le principe même du chiffrement asymétrique :

Public key → pour chiffrer

Private key → pour déchiffrer


Quand Alice a tout préparé, elle doit envoyer à Bob uniquement ce dont il a besoin pour :

vérifier l’authenticité,
récupérer la clé AES,
déchiffrer le message.
Donc au final elle envera ces quatres fichiers :
messageAlice.chi: Le message chiffré avec la clé AES
cle_secreteAlice.chi: La clé AES chiffrée avec la clé publique de Bob
empreinte.sig: La signature du message, faite avec la clé privée d’Alice
cleA_pub.pem: La clé publique d’Alice, pour que Bob puisse vérifier la signature

50) Vérifiez l’authenticité de l’émetteur.

51) Contrôler l’intégrité. Vous pouvez utiliser la commande diff <fichier_1> >fichier_2>
Compares l’empreinte calculée par Alice (Q46) avec celle recalculée par Bob (Q50).
Si les deux sont identiques, alors le message est intègre.
Alice calcule l’empreinte du message chiffré
Bob refait le même calcul après réception
Comparaison des deux empreintes avec diff :


53) Déchiffrez le message en deux étapes : lesquelles ?

premire etape :Déchiffrement asymétrique (RSA)

➡️ But : récupérer la clé symétrique (clé secrète AES).

Bob utilise sa clé privée (cleB.pem) pour déchiffrer le fichier contenant la clé d’Alice (cle_secreteAlice.chi).

deuxieme etape :Déchiffrement symétrique (AES)

➡️ But : déchiffrer le message lui-même.

Bob utilise la clé récupérée à l’étape 1 pour déchiffrer messageAlice.chi

> Remarque:
> Combinaison des deux méthodes :
>
> Chiffrement symétrique (AES) pour le message.
>
> Chiffrement asymétrique (RSA) pour la clé AES.
>
> Alice chiffre le message avec AES, signe avec sa clé privée, et chiffre la clé AES avec la clé publique de Bob.
>
> Bob :
>
> Vérifie la signature avec la clé publique d’Alice.
>
> Déchiffre la clé AES avec sa clé privée.
>
> Déchiffre ensuite le message.
>
> Ce mécanisme assure confidentialité, authenticité et intégrité.
# 6 Chiffrement hybride avec secret au préalable partagé

**Vous avez à votre disposition deux machines virtuelles, l’une va jouer le rôle du serveur et
l’autre celle du client. Vous allez créer pour les deux machines un secret partagé qui consistera
en une clé secrète, en se basant sur le mécanisme d’échange de clés de Diffie – Hellman.**

53) Vous créez sur les deux machines une paire de clés privée – publique.
Sur la machine client:

Sur la machine serveur:

54) Vous procédez à l’échange entre les deux machines des clés publiques.
Depuis le client, j'envoie la clé publique au serveur :
Depuis le serveur , j'envoie la clé publique au client :

Chaque machine a sa propre paire de clés privée/publique et la clé publique de l’autre.

55) Vous créez sur chacune des machines la clé secrète.

Chaque machine va calculer le même secret partagé, sans l’échanger, grâce à sa clé privée et la clé publique de l’autre.

🔹 Sur le serveur:

Sur le client:


56) Vous affichez sur chacune des machines la clé secrète. Sont-elles identiques ?

Pour voir les valeurs de ces clés sous une forme lisible (base64) :

🔹 Sur le serveur:

Sur le client :

> Remarque : elles sont identiques alors le mécanisme ECDH a fonctionné.
> Les deux machines génèrent chacune une paire de clés (privée/publique), échangent les clés publiques, puis calculent une clé secrète commune via ECDH.
>
> Les clés obtenues sur les deux machines sont identiques, preuve que l’échange Diffie–Hellman a fonctionné correctement.

# 7 Affichage de certificat

57) Les autorités de certification sont-elles les mêmes pour la page de Updago et la page de
la boite mail de l’université ?

voici pour updago:

voici pour upmail:

Oui, les autorités de certification sont les mêmes pour la page d’Updago et celle de la boîte mail de l’université.

Dans les deux cas, les certificats SSL/TLS ont été délivrés par GEANT TLS RSA CA 4, une autorité de certification utilisée par les établissements d’enseignement et de recherche européens.

58) Quelles sont les autorités de certification pour la page web de
l’ANSSI (https://cyber.gouv.fr/) ?



le site web de l'AnSSI est certifié par l'autorité Certigna, plus précisemnet :
Certigna Server Authentification OVCP EU CA G1, une autorité de certification francaise gerée par Dhimyotis /Tessi .

59) La page web du « blog du coyote » (https://www.apprendre-en-ligne.net/blog/) est-elle
sécurisée ?

Le site utilise HTTPS mais n’est pas totalement sécurisé : certaines ressources (images) ne sont pas chargées en HTTPS.
→ Site partiellement sécurisé.

# 8 Version de TLS (Transport Layer Security) utilisée

60) Quelle est la version de TLS utilisée en se connectant au site de l’Equipe
(https://www.lequipe.fr/) ? Avec quelle suite cryptographique ?

Le site https://www.lequipe.fr/ utilise la version TLS 1.3 avec la suite de chiffrement TLS_AES_256_GCM_SHA384.

61) Quelle est la version de TLS utilisée en se connectant au site de Google
(https://www.google.fr/) ? Avec quelle suite cryptographique ?

La version TLS utilisée en se connectant à https://www.google.fr/ est TLS 1.3, avec la suite cryptographique TLS_AES_256_GCM_SHA384.

62) Quelle est la version de TLS utilisée en se connectant au site du journal Le Monde ?
(https://www.lemonde.fr/) ? Avec quelle suite cryptographique ?


La version TLS utilisée en se connectant à https://www.lemonde.fr/ est
Version TLS utilisée : TLS 1.2
Suite cryptographique : ECDHE-RSA-CHACHA20-POLY1305

> Remarque:
> Le choix de la version TLS dépend de la configuration du serveur et de la négociation entre client et serveur.
> Les sites récents ou bien maintenus (Google, L’Équipe) utilisent TLS 1.3, tandis que d’autres (Le Monde) utilisent encore TLS 1.2, toujours sécurisé mais moins performant.

# 9 Bonus : étude partielle d’une liaison TL

 Attendez l’affichage de closed sur votre machine virtuelle puis arrêtez la capture et
sélectionnez tls comme filtre d’affichage.


1) Comment s’appelle le premier message échangé ?

Le client initie toujours la négociation TLS avec un message Client Hello, c’est lui qui propose toutes ses capacités cryptographiques.

2) Qui envoie ce premier message ?

Le client ma machine virtuelle.

Le premier message vient du client, car c’est lui qui démarre le handshake TLS.

Déroulez la ligne Transport Layer Security

3) Quelle est la version de tls affichée ?

Wireshark montre TLS 1.2 car ce champ est “legacy”, mais cela ne reflète pas encore la vraie version négociée.

Déroulez la ligne Handshake Protocol : Client Hello
4) Quelle est la version de tls affichée ?


Le Client Hello affiche TLS 1.2 en valeur héritée, car TLS 1.3 ne place jamais sa vraie version ici mais dans les extensions.

Nous constatons la présence d’un nombre aléatoire (Random) renouvelé à chaque nouvel
établissement de liaison. Ceci a pour but de contrer un éventuel rejeu par un attaquant
des messages échangés et va servir à la création d’un premier secret éphémère (Pre
Master Secret) entre le client et le serveur.

5) Combien de suites cryptographiques sont proposées par le client au serveur ?

: Le client propose plusieurs suites pour laisser au serveur le choix de la meilleure méthode de chiffrement supportée par les deux.

6) Combien d’algorithme de signatures sont proposés ?

Le client annonce une liste d’algorithmes de signature pour garantir l’intégrité et permettre au serveur de choisir celui qu’il supporte.

Déroulez la ligne Extension : supported_versions (len=3)
7) Quelle la version de tls affichée ?
C’est dans cette extension que le client indique réellement qu’il supporte TLS 1.3.

Déroulez la ligne Extension : key_share (len=38)
8) Quelle courbe elliptique est proposée ?


La courbe elliptique x25519 est utilisée pour établir un secret éphémère sécurisé pour TLS 1.3.

9) Quel est le prochain message échangé ?

Le serveur répond au Client Hello avec un Server Hello pour confirmer les paramètres cryptographiques sélectionnés.


10) Qui envoie ce prochain message ?

Le Server Hello vient du serveur, c’est sa réponse officielle pour commencer le handshake sécurisé.

Le serveur

C’est lui qui répondau au “Client Hello” en envoyant son “Server Hello”, où il choisit :

la version TLS négociée,

la suite cryptographique retenue,

et sa clé publique (pour la suite du handshake).

Déroulez la ligne Transport Layer Security du nouveau message (En fait c’est déjà fait)

11) Quelle est la version de tls affichée ?

Le serveur choisit une suite proposée par le client, ce qui garantit une négociation compatible et sécurisée.

12) Quelle suite cryptographique est choisie par le serveur ?
La suite choisie fait partie des propositions du client, sinon la négociation échouerait.

15) Cette suite fait-elle partie des suites proposées par le client ?
Le serveur accepte et réutilise la courbe elliptique proposée par le client pour finaliser l’échange de clés.

on le voit clairement dans la deuxième image :
le client proposait entre autres :
TLS_AES_256_GCM_SHA384 (0x1302)
TLS_CHACHA20_POLY1305_SHA256 (0x1303)
TLS_AES_128_GCM_SHA256 (0x1301)

Déroulez la ligne Extension : supported_versions (len=3)

14) Quelle est la version de tls affichée ?

Le serveur confirme officiellement que la version effective du protocole est TLS 1.3.

Déroulez la ligne Extension : key_share (len=36)

15) Quelle courbe elliptique est choisie ?


Le serveur accepte et réutilise la courbe elliptique proposée par le client pour finaliser l’échange de clés.

16) Autorité de certification

Le certificat du serveur est signé par une autorité de confiance (DigiCert), ce qui prouve l’identité du serveur.

17) Message “Finished”

Le message Finished marque la fin du handshake TLS : les deux parties ont le même secret maître et peuvent chiffrer toute la suite.

### Bilan :

Client et serveur sont tombés d’accord, ils vont construire le secret maitre (master secret)
partagé qui servira à chiffrer les prochains messages des données d’application.
Les deux premiers messages en clair ont permis au client et au serveur de se mettre d’accord
sur un maitre secret partagé afin de pourvoir continuer les échanges avec confidentialité,
intégrité et authentification du serveur (et éventuellement celle du client, ce qui n’a pas été le
cas ici)