Activité Utiliser des algorithmes de chiffrement

Consigne

1. La durée de l’activité est estimée à environ 180 minutes.
2. Avant de commencer l’activité :
   • Lire la mise en situation, prendre connaissance des objectifs, du résultat attendu, et des ressources à disposition.
   • Lire une première fois en entier la section Mise en route.
3. Effectuez le travail décrit dans la section Mise en route et effectuez les tâches demandées dans la section Tâches.

Mise en situation

Vous êtes chargé de mettre en œuvre des mesures techniques pour la protection des données dans un système Linux. En particulier, vous devez appliquer diverses techniques de chiffrement de données sur vos serveurs Linux. Dans ce but, vous décidez de vous familiariser avec un certain nombre d’outils disponibles sur cette plateforme.

Objectifs

À la fin de ce travail, vous devez :

1. Connaître des commandes permettant de hacher des mots de passe de manière robuste.
2. Connaître une commande pour calculer l’empreinte d’un fichier.
3. Connaître la différence entre hacher un mot de passe et simplement calculer une empreinte, même si, dans les deux cas, on utilise un algorithme de hachage tel que SHA-512, par exemple.
4. Connaître des commandes permettant de chiffrer des fichiers.
5. Connaître une commande permettant de connaître le type de fichier.
6. Connaître une commande permettant d’afficher le contenu d’un fichier en hexadécimal.

Résultat attendu

• Un système Linux configuré selon les instructions.
• Les réponses aux questions.

Ressources

Matériel :

• Un serveur Linux (Ubuntu 24.04 LTS) : svr-sql-$NUM-01.lab.epai-ict.ch. La variable « $NUM » est le numéro de votre réseau tel qu’il apparait dans les informations d’identification que vous avez reçues par courriel.

Tâche

Authentification du serveur avec SSH

Vérifier l’empreinte de la machine distante (votre serveur)

La première fois que l’on se connecte à une machine distante avec un client SSH, celui-ci nous demande de vérifier l’empreinte de la clé publique du serveur.

En effet, comme la clé est censée authentifier le serveur, il est important de s’assurer que la clé publique que l’on obtient lors de la connexion est bien celle du serveur auquel on veut se connecter. Sans cette précaution, on s’expose à une attaque de type man-in-the-middle (MITM).

Pour cela, il est important d’obtenir cette empreinte à travers un canal de confiance. Par exemple, un annuaire, un courriel signé d’une personne d’une confiance, un accès direct à la console de la machine, etc. Lorsque l’on s’est assuré que l’empreinte est la bonne, on peut alors associer le FQDN du serveur ou son adresse IP à cette empreinte dans un fichier (par défaut, ~/.ssh/known_hosts avec OpenSSH).

De cette manière, lors d’une prochaine connexion, le client SSH pourra authentifier le serveur si l’empreinte de la clé fournie par le serveur correspond à l’empreinte stockée, ou interdire la connexion en informant l’utilisateur dans le cas contraire.

Ouvrez un terminal et utilisez la commande ssh pour vous connecter à votre serveur avec le compte lab-admin.

1
ssh lab-admin@svr-sql-$NUM-01.lab.epai-ict.ch

Si le client SSH ne vous demande pas d’accepter la clé, cela signifie que vous avez déjà enregistré l’empreinte e la clé. Si c’est le cas, ouvrez le fichier $HOME/.ssh/known_hosts dans un éditeur de texte, cherchez le nom de votre serveur et supprimez toutes les lignes où il apparait.

Relancez la commande ssh. Cette fois, la commande vous demande de vérifier l’empreinte (fingerprint).

1
2
3
4
The authenticity of host 'svr-sql-205-01.lab.epai-ict.ch (172.20.205.61)' can't be established.
RSA key fingerprint is: SHA256:posztdQetiH1UPumSX45vopj78bENdXBGTtSV322YVE
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Pour ce travail, on suppose que vous avez effectivement pu la vérifier. Notez l’empreinte, acceptez et saisissez votre mot de passe si le client vous le demande.

Clés du serveur

Voyons maintenant à quoi correspond cette empreinte.

Sur le serveur, rendez-vous dans le répertoire /etc/ssh et listez son contenu.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
lab-admin@svr-sql-205-01:/etc/ssh$ ls -al
total 660
drwxr-xr-x   4 root root   4096 May  2 16:17 .
drwxr-xr-x 114 root root   4096 May  9 15:09 ..
-rw-r--r--   1 root root 620042 Apr 29  2025 moduli
-rw-r--r--   1 root root   1649 Apr 29  2025 ssh_config
drwxr-xr-x   2 root root   4096 Apr 29  2025 ssh_config.d
-rw-------   1 root root    513 May  2 10:30 ssh_host_ecdsa_key
-rw-r--r--   1 root root    181 May  2 10:30 ssh_host_ecdsa_key.pub
-rw-------   1 root root    411 May  2 10:30 ssh_host_ed25519_key
-rw-r--r--   1 root root    101 May  2 10:30 ssh_host_ed25519_key.pub
-rw-------   1 root root   2602 May  2 10:30 ssh_host_rsa_key
-rw-r--r--   1 root root    573 May  2 10:30 ssh_host_rsa_key.pub
-rw-r--r--   1 root root    342 Dec  7  2020 ssh_import_id
-rw-r--r--   1 root root   3517 May  2 16:17 sshd_config
drwxr-xr-x   2 root root   4096 Jun 26  2025 sshd_config.d

Dans ce répertoire, vous pouvez voir des paires de fichiers dont le nom est ssh_host_<nom de l'algo>_key. Ces paires de fichiers correspondent aux paires de clés qui ont été générées pour identifier l’hôte. On peut voir que le serveur a généré des clés de type ECDSA (Elliptic Curve Digital Signature Algorithm), des clés de type ED25519 (un cas particulier de courbe elliptique), et de type RSA (Rivest-Shamir-Adleman). L’empreinte que le client ssh nous a présentée est celle de la clé RSA.

Voyons si cela correspond effectivement à ce que l’on a vu. Pour cela, lancez la commande suivante :

1
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

En principe, la réponse de la commande devrait correspondre à l’empreinte que vous aviez notée lors de la première connexion.

Si l’identité du serveur est compromise, on peut générer de nouvelles les paires de clés en lançant les commandes suivantes :

1
2
sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A

Lorsque les nouvelles paires de clés ont été générées, déconnectez-vous, puis essayez d’ouvrir une nouvelle session SSH sur ce serveur. Le client SSH vous informe alors que quelque chose ne va pas :

1
2
3
4
5
6
7
8
9
10
11
12
13
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:PfGLrsKBW/HALk9bt1XSY+jNsQdrK26FBuN6TttEE6Y.
Please contact your system administrator.
Add correct host key in /Users/frossardj/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /Users/frossardj/.ssh/known_hosts:241
Host key for svr-sql-205-01.lab.epai-ict.ch has changed and you have requested strict checking.
Host key verification failed.

Ce message d’alerte nous indique que la clé fournie par le serveur n’est pas la même que celle qui a été stockée dans le fichier .ssh/known_hosts avec son FQDN. Cela peut indiquer que l’on subit une attaque de type man-in-the-middle (MITM), ou, comme c’est le cas ici, que de nouvelles paires de clés ont été générées pour le démon sshd.

Puisqu’il s’agit d’un changement légitime, il suffit de supprimer les entrées correspondant à notre serveur dans le fichier .ssh/known_hosts. On peut le faire à la main avec un éditeur de texte, ou en utilisant la commande suivante :

1
ssh-keygen -R svr-sql-$NUM-01.lab.epai-ict.ch

Questions :

1. Avec le protocole SSH, la première fois que l’on se connecte à un serveur, le client nous demande de vérifier l’empreinte (fingerprint) de la clé publique du serveur. Pourquoi nous demande-t-il cela ?
2. Comment peut-on vérifier que cette empreinte est effectivement celle de la clé publique de notre serveur ?
3. Dans quel fichier les clés publiques des serveurs sont-elles stockées ?
4. Dans le web, avec HTTPS, un navigateur peut vérifier lui-même l’authenticité de la clé publique du serveur. Qu’est-ce qui rend cela possible ?

SSH avec authentification à clé publique

Le SSH supporte l’authentification par clé publique qui évite d’avoir à saisir sans arrêt un mot de passe et qui est beaucoup plus résistant aux attaques par force brute que l’authentification par mot de passe.

Pour cela, nous avons besoin d’une paire de clés pour effectuer des signatures numériques (typiquement Ed25519).

Création d’une paire de clés SSH sur votre PC

Voyons comment la créer. Sur votre PC (pas sur le serveur), ouvrez une fenêtre de terminal sans élévation de privilèges (le but est de créer une paire de clés pour votre compte d’utilisateur·rice, sur votre PC). Rendez-vous dans votre répertoire personnel, puis dans le répertoire .ssh pour vérifier qu’il existe. Si ce n’est pas le cas, créez-le avec la commande mkdir .ssh. On rappelle que dans un système POSIX (Linux, macOS, etc.), les fichiers et les répertoires dont le nom commence par un point sont cachés.

Lorsque c’est fait, lancez la commande ci-dessous pour générer une clé de type ed25519. L’option -t vous permet de spécifier l’algorithme et l’option -C, de spécifier un commentaire qui apparait à côté de la clé publique pour vous aider à l’identifier plus facilement. Par exemple les noms du compte d’utilisateur·rice et de l’hôte.

1
ssh-keygen -t ed25519 -C "lab-admin@svr-sql-$NUM-01"

La commande vous propose de créer la clé privée dans le fichier "$HOME/.ssh/id_ed25519. Acceptez en pressant la touche Entrée. La commande vous demande ensuite de saisir une phrase secrète (passphrase). Pressez la touche Entrée pour continuer sans phrase secrète, puis une seconde fois pour confirmer.

Rendez-vous dans le répertoire $HOME/.ssh de votre PC, et listez les fichiers qui s’y trouvent. Vous devriez voir un fichier id_ed25519 et un fichier id_ed25519.pub. Ces deux fichiers sont deux fichiers de texte. Le premier contient la clé privée, le second contient la clé publique. Tous deux sont dans un format spécifique à OpenSSH, même si le format de la clé privée ressemble au format PEM avec un entête “—–BEGIN OPENSSH PRIVATE KEY—–”. Utiliser la commande cat pour afficher leur contenu.

1
2
3
4
5
6
7
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACBHq3Nqc0HuAe1LE2zblhMCsswdXGk/7+ilay+dgBZzFwAAAKCjdy8eo3cv
HgAAAAtzc2gtZWQyNTUxOQAAACBHq3Nqc0HuAe1LE2zblhMCsswdXGk/7+ilay+dgBZzFw
AAAEDTKZBnqy86dXiphurz3i7C/sK3retPGZ9LqjwxD5kS4Eerc2pzQe4B7UsTbNuWEwKy
zB1caT/v6KVrL52AFnMXAAAAGGxhYi1hZG1pbkBzdnItc3FsLTIwNS0wMQECAwQF
-----END OPENSSH PRIVATE KEY-----

1
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEerc2pzQe4B7UsTbNuWEwKyzB1caT/v6KVrL52AFnMX lab-admin@svr-sql-205-01

La commande ssh-keygen nous permet également d’obtenir des informations sur notre clé. Par exemple, on peut obtenir l’empreinte de notre clé SSH ou extraire la clé publique de la clé privée.

1
2
ssh-keygen -lf ~/.ssh/id_ed25519 # Calcule l'empreinte de la clé
ssh-keygen -y -f ~/.ssh/id_ed25519 # Extrait la clé publique

Fournir la clé publique à la machine distante (votre serveur)

Nous devons maintenant fournir notre clé publique à la machine distante (en l’occurrence, notre serveur) d’une manière ou d’une autre. Comme

Sous macOS ou Linux, ouvrez une fenêtre de terminal et lancez la commande ci-dessous pour ajouter votre clé publique dans le fichier ~/.ssh/authorized_keysde votre serveur.

1
ssh-copy-id -i ~/.ssh/id_ed25519.pub lab-admin@svr-sql-$NUM-01.lab.epai-ict.ch

Sous Windows, la commande ssh-copy-id n’existe pas, mais on peut utiliser des commandes standard pour effectuer la même opération. Ouvrez une fenêtre de terminal (sans privilèges), et lancez la commande suivante :

1
Get-Content $home/.ssh/id_ed25519.pub | ssh lab-admin@svr-sql-$NUM-01.lab.epai-ict.ch 'cat >> .ssh/authorized_keys'

Terminez la session SSH avec la commande exit.

Par défaut, lors de la connexion, le client OpenSSH propose généralement les clés dont le fichier a un nom standard (p. ex. id_rsa, id_ed25519, etc.). Pour proposer des clés dont le fichier n’a pas un nom standard, on peut utiliser l’option -i "<chemin du fichier>" de la commande ssh ou encore la commande ssh-add "<chemin du fichier>" qui permet de charger une clé dans l’agent ssh. Pour utiliser ssh-add sous Windows, on doit s’assurer que le service OpenSSH Authentication Agent (ssh-agent) est bien démarré.

Pour ouvrir une session, le client envoie le nom du compte d’utilisateur·rice (p. ex. lab-admin@...) au serveur et l’informe qu’il supporte l’authentification par clé publique. Si le serveur support également l’authentification par clé publique, il répond en envoyant un défi (challenge). Le client répond au défi avec la clé passée à l’aide de l’option -i, les clés par défaut et les clés chargées dans l’agent. Le serveur vérifie la réponse avec les clés publiques qui se trouve dans le fichier ~/.ssh/authorized_keys du compte de l’utilisateur·rice. Si l’une des clés correspond, la session est authentifiée. Si ce n’est pas le cas, le processus se répète avec la prochaine clé privée jusqu’à ce que la session soit authentifiée ou que toutes les clés privées aient été essayées sans succès. Si l’authentification par clé publique a échoué et que le serveur supporte l’authentification par mot de passe, le client SSH vous demande alors votre mot de passe.

Si la clé est protégée par une phrase secrète, le client SSH demande la phrase secrète à chaque connexion. Pour éviter cela, on peut utiliser la commande ssh-add pour garder la clé secrète déchiffrée dans l’agent ssh. La clé secrète est ainsi disponible tant que l’instance de l’agent fonctionne. La commande ssh-add -l permet de lister les clés (les identités) chargées dans l’agent, et la commande ssh-add -D permet de les décharger.

Questions :

1. Dans le format PEM, comment les données binaires sont-elles codées ? Comment sait-on qu’il s’agit d’une clé privée SSH ?
2. Quelles sont les informations contenues dans le fichier de clé publique SSH ? Est-il dans le format PEM ?
3. Sur quelles hypothèses repose la sécurité de l’authentification par clé publique ?
4. En général l’authentification à clé publique ne fonctionne pas si les permissions sur les fichiers des clés privées ou le fichier authorized_keys sont trop ouvertes (permissions too open), par exemple, quelque chose d’équivalent à 640 pour une clé privée ou à 766 pour authorized_keys. Expliquez pourquoi.
5. Si l’on donne un nom non standard aux fichiers contenant la paire de clés, comment peut-on demander à ssh de proposer la clé ?
6. Si l’on protège la clé privée avec une passphrase, comment peut-on éviter d’avoir à fournir la phrase secrète à chaque connexion ?

Manipuler des certificats de clé publique avec OpenSSL

OpenSSL est une boîte à outils de chiffrement qui comprend un certain nombre de bibliothèques, l’utilitaire en ligne de commande openssl ainsi qu’une implémentation du protocole TLS et de plusieurs algorithmes de chiffrement. L’utilitaire en ligne de commande permet, entre autres choses, de créer, d’afficher et de vérifier des certificats de clé publique, de chiffrer des fichiers, de hacher des mots de passe, ou encore de calculer des empreintes.

Connectez-vous à votre serveur avec le compte lab-admin (vous devriez pouvoir vous y connecter sans avoir à renseigner votre mot de passe) et listez le contenu du répertoire ~/certs. Vous devriez voir les fichiers suivants :

1
2
3
4
5
drwxr-x--- 2 lab-admin lab-admin 4096 May  2 16:17 .
drwxr-x--- 5 lab-admin lab-admin 4096 May 17 08:42 ..
-r--r--r-- 1 lab-admin lab-admin 1118 May  2 16:17 lab-ca.pem
-r--r--r-- 1 lab-admin lab-admin 2087 May  2 16:17 sql_cert.pem
-r-------- 1 lab-admin lab-admin 1679 May  2 16:17 sql_key.pem

Le fichier lab-ca.pem contient le certificat racine de l’autorité de certification utilisée pour les labos d’informatique de l’EPAI. Le fichier sql_key.pem contient la clé privée du serveur. Enfin, le fichier sql_cert.pem contient le certificat de clé publique du serveur, signé par l’autorité de la certification des labos.

Certificat racine

Lancez la commande suivante pour afficher le contenu du fichier lab-ca.pem :

1
cat ~/certs/lab-ca.pem

Ce fichier est fichier de texte au format PEM (Privacy Enhanced Mail). Pour afficher les détails du certificat qu’il contient, lancez la commande suivante :

1
openssl x509 -in ~/certs/lab-ca.pem -text -noout

Vous pouvez voir que le sujet (subject) du certificat est “EPAI ICT Lab Root CA”, que la clé publique est une clé RSA de 2048 bits et que la clé privée correspondante peut être utilisée pour signer des certificats et des listes de révocation (CRL), et, enfin, que le certificat est celui d’une CA (certificate authority).

Ce certificat est un certificat racine (root certificate), auto-signé (self-signed). Cela signifie que sa légitimité repose sur le fait que vous faites confiance à l’autorité de certification et que vous l’avez obtenu à travers un canal sûr. Par exemple, un courriel signé d’une personne de confiance ou depuis le site Web des labos (https://www.epai-ict.ch), dont le certificat HTTPS est émis par l’autorité de certification Let’s Encrypt.

C’est pourquoi on doit indiquer d’une manière ou d’une autre que les certificats racines des autorités de certification sont des certificats de confiance (trusted certificates), le plus souvent en les stockant dans un trusted store. Les autorités de certification qui ont émis le certificat du courriel signé et celui du site web sont en principe déjà reconnues par vos clients de messagerie, navigateur web, OS, etc.

Clé privée

Le fichier sql_key.pem est également au format PEM et contient la clé privée.

1
cat ~/certs/sql_key.pem

Pour ce travail la structure de la clé privée ne nous intéresse pas, mais elle peut être décodée avec la commande openssl pkey. Et comme dans le cas de notre clé ssh, il est également possible d’extraire la clé publique (celle qui se trouve dans le certificat) de la clé privée.

1
2
openssl pkey -in ~/certs/sql_key.pem -text # affiche les composantes de la clé privée
openssl pkey -in ~/certs/sql_key.pem -pubout # extrait la clé publique

Certificat TLS

Voyons maintenant le contenu du fichier sql_cert.pem :

1
cat ~/certs/sql_cert.pem

On remarque que le fichier est également au format PEM et qu’il contient deux certificats. En effet, ce fichier est un bundle qui contient le certificat TLS et le certificat intermédiaire de la CA. Le certificat intermédiaire contient la clé publique correspondant à la clé privée effectivement utilisée pour signer le certificat TLS. La raison pour laquelle il n’a pas été signé par la clé privée correspondant au certificat racine est que cette clé est généralement conservée hors ligne pour des raisons de sécurité. En effet, en utilisant un certificat intermédiaire, dans l’éventualité où la clé privée correspondante serait compromise, on pourrait révoquer les certificats signés par cette clé, sans avoir besoin de révoquer le certificat racine.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
-----BEGIN CERTIFICATE-----
MIIDJzCCAs6gAwIBAgIQBnnTx4HYJhq0/aPV+hujnzAKBggqhkjOPQQDAjA+MRUw
EwYDVQQKEwxFUEFJIElDVCBMYWIxJTAjBgNVBAMTHEVQQUkgSUNUIExhYiBJbnRl
cm1lZGlhdGUgQ0EwHhcNMjYwNTAyMTEwOTI2WhcNMjcwNTAyMTExMDI2WjApMScw
JQYDVQQDEx5zdnItc3FsLTIwNS0wMS5sYWIuZXBhaS1pY3QuY2gwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvWqCV6PHSP7oktIyjR3SZhy94c4dM6Gc7
uUEG48eLt+T7ZjyC7Hg+WZIiVx175CBqAG0YI7MY71smP63DLeUsSMnPgKWX2vem
5sBSpaeWKC2HekstkNpQONfeVgA3uYH2ZoAXLNj74qoq5grDO3bdQRCNW1UnM3Un
+9GzAprOAauhCioGTCS0a77yxEL+TpwozWgPlSz+6fVlLyHFZ3pbNUFNRYK15M0M
rWfJzu3fRLBgC676RDsF28HHD7Dfkn4a71wr5FSA+/tpGc5teV01IfMKkpOfI6oN
bUzbkXnU3dJZiixfRfnDKmiLbxG1Q+fZp91i5rR7E/TcV5BTNcQNAgMBAAGjgfcw
gfQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcD
AjAdBgNVHQ4EFgQUwr/QPr0hjgxl6kbnIRh7D6i+K2wwHwYDVR0jBBgwFoAUdQS3
b2AtuWX4NcVJsWVSaE1X13QwLwYDVR0RBCgwJoIec3ZyLXNxbC0yMDUtMDEubGFi
LmVwYWktaWN0LmNohwSsFM09MFIGDCsGAQQBgqRkxihAAQRCMEACAQEEDmNhQGVw
YWktaWN0LmNoBCtHR3laZVhtbF9DbEc1bDNTWmVwZmE2UGt1SWNVMnVwZkZFanRC
M081dXNZMAoGCCqGSM49BAMCA0cAMEQCIEcOGvAubK8JZRSHbXwjqxHzDddH2TQC
2om2s3ouldFNAiACauygrcuEC/VCDiAji7y7mUx3HhfOFUK+b9jcvVHzaQ==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICgzCCAWugAwIBAgIRAJfAX3eCA2+rO3SKwEFsLU8wDQYJKoZIhvcNAQELBQAw
HzEdMBsGA1UEAxMURVBBSSBJQ1QgTGFiIFJvb3QgQ0EwHhcNMjMwMjIzMTUwMzM3
WhcNMzMwMjIwMTUwMzM3WjA+MRUwEwYDVQQKEwxFUEFJIElDVCBMYWIxJTAjBgNV
BAMTHEVQQUkgSUNUIExhYiBJbnRlcm1lZGlhdGUgQ0EwWTATBgcqhkjOPQIBBggq
hkjOPQMBBwNCAARu0WvH5ScT/WGZCF/qEAHs8znu8YeqFSgVewEzIkaaqY7/j9rk
90OfpA+UX5PVD1Uu+1woLEjQENqmx5GP2EK0o2YwZDAOBgNVHQ8BAf8EBAMCAQYw
EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUdQS3b2AtuWX4NcVJsWVSaE1X
13QwHwYDVR0jBBgwFoAUVkvF1Ld5S3gZeeptu2MqV0IpnpAwDQYJKoZIhvcNAQEL
BQADggEBAAsUE3jgVvkIARpukzkhBjafN4t0AjfXiZ+SpiEysBJAfvANYCuy2pvq
Qxljh4S+6t9eEEE+6yw9NRXDgs7PpSjYjQGfkwLmg+b4Y1DlfyXs12E+pftFVGpl
692aqCloMRv9O29LaVtgb87fEwkvQ0GBvawMkbQXM1nybY4rYXdNYIp5ZhPyOMK4
Fk0ZFS4EI+6lbkBS57n6PJPQgCC5qK1vjHPN5YW8ZF0Qz833696q6jVbSKRqeJ8R
82MYsfeKIlpo80KfPsdm+0dWfv55wGu3XjsfApRLyzG883Q5fnNnz+AKKRbg+3MJ
nP0kjKiQfvhxQj1mlfbWCw2zxZuy36A=
-----END CERTIFICATE-----

Voyons ce qui se passe si l’on essaie d’afficher les détails du certificat.

1
openssl x509 -in ~/certs/sql_cert.pem -text -noout

Les informations renvoyées sont celles du certificat TLS. On peut voir que le sujet (subject) est “svr-sql-205-01.lab.epai-ict.ch”, que la clé publique est une clé RSA de 2048 bits et que le certificat peut être utilisé avec le protocole TLS pour l’authentification du serveur ou du client. On peut également voir des noms alternatifs pour le sujet (Subject Alternative Name, SAN) : DNS:svr-sql-205-01.lab.epai-ict.ch et IP Address:172.20.205.61. Le certificat peut ainsi être utilisé pour authentifier le fqdn ou l’adresse IP du serveur.

Pour afficher les informations du certificat intermédiaire, il faut séparer les deux certificats. On peut le faire à l’aide de la commande ci-dessous qui crée deux fichier (cert-00 et cert-01), chacun d’eux contenant l’un des certificats du bundle.

1
csplit -s -f "cert-" -z certs/sql_cert.pem '/-----BEGIN CERTIFICATE-----/' '{*}'

On peut ensuite afficher les informations du certificat du second fichier :

1
openssl x509 -in cert-01 -text -noout

On peut voir qu’il s’agit, comme pour le certificat racine, d’un certificat d’une CA, mais contrairement au certificat racine, il n’est pas auto-signé. Les certificats intermédiaires sont signés à l’aide de la clé privée correspondant à la clé publique du certificat racine (ou d’un autre certificat intermédiaire de plus haut niveau).

Pour finir, on peut utiliser openssl pour valider toute la chaine :

1
2
3
4
openssl verify \
    -CAfile ~/certs/lab-ca.pem \
    -untrusted cert-01 \
    cert-00

Si tout est en ordre, la commande devrait répondre : cert-00: OK

Questions

1. Dans les fichiers au format PEM, vous remarquez que les données binaires des clés ou des certificats ne sont pas représentées en hexadécimal (0-9, a-f). Comment s’appelle le codage utilisé ? (a-z, A-Z, 0-9, +, /)
2. Si vous ouvrez un fichier au format PEM, comment savez-vous qu’il s’agit d’une clé privée, d’une clé publique, d’un certificat, etc. ?
3. Quelles sont les informations typiquement contenu dans un certificat TLS ?
4. Comment sait-on que les informations fournies par un certificat n’ont pas été modifiées ?
5. De quoi a-t-on besoin pour vérifier la signature d’un certificat ?
6. Sur quoi repose la confiance que l’on peut avoir dans un certificat ?
7. Comment vérifie-t-on la signature d’un certificat racine ?
8. Sur quoi repose la confiance que l’on peut avoir dans un certificat racine ?
9. À quoi doit-on faire attention lorsque l’on ajoute un certificat racine ?
10. Pourquoi une CA n’utilise généralement pas la clé privée correspondant au certificat racine pour signer les certificats qu’elle émet ?
11. Si on utilise un certificat auto-signé dans un serveur HTTPS, la communication est chiffrée, mais pourquoi n’est-ce pas suffisant dans le Web ?
12. Nommez une CA permettant d’obtenir gratuitement des certificats TLS.
13. Pour obtenir un certificat, sous quelle forme fournit-on généralement à la CA les informations à signer ?
14. La CA a-t-elle besoin de notre clé privée ?

Chiffrer des mots de passe avec OpenSSL

En plus des commandes que l’on a déjà utilisées, l’utilitaire en ligne de commande openssl permet aussi de chiffrer des mots de passe à l’aide d’algorithme de chiffrement à sens unique (fonction de hachage).

Un mot de passe ne constitue une preuve que s’il est secret et que ce secret n’est jamais divulgué. Si l’on chiffre un mot de passe avec un algorithme de chiffrement symétrique (à clé secrète), le secret du mot de passe dépend du secret de la clé. Si la clé n’est connue que du propriétaire du mot de passe, comme c’est le cas pour un gestionnaire de mot de passe, le secret du mot de passe est maintenu. Mais cela n’est absolument pas acceptable pour un mécanisme d’authentification. En effet, pour valider le mot de passe, le système d’authentification doit posséder la clé et comme la clé permet le chiffrement et le déchiffrement, le mot de passe ne peut plus être considéré comme secret. C’est pourquoi dans un tel système on utilise un algorithme de chiffrement à sens unique.

Connectez-vous à votre serveur, puis utilisez la commande openssl passwd pour hacher un mot de passe avec l’algorithme SHA-512.

1
echo -n "monmotdepasse" | openssl passwd -6 -stdin

Pour protéger un mot de passe, on veut que le chiffrement de deux mot de passe identiques ne produise pas le même résultat et que le calcul prenne beaucoup de temps afin d’augmenter le coût des attaques par force brute.

Le chiffrement de mot de passe est souvent basé sur une fonction de hachage de qualité cryptographique, p. ex. SHA-512. Comme il s’agit d’une fonction au sens mathématique, la même entrée produit toujours la même sortie. Pour éviter que deux mots de passe identiques donnent la même empreinte (ce qui permettrait de comparer l’empreinte à une liste d’empreintes précalculées, ou de repérer facilement des mots de passe identiques), on ne chiffre pas le mot de passe seul, mais le mot de passe salé (salted). Le sel (salt) est une donnée aléatoire concaténée au mot de passe.

De plus, comme une fonction de hachage est optimisée pour calculer des empreintes aussi vite que possible, le chiffrement à sens unique d’un mot de passe avec une telle fonction consiste à calculer l’empreinte du mot de passe salé, puis l’empreinte du résultat, puis l’empreinte du nouveau résultat, et ainsi de suite, un grand nombre de fois (typiquement plusieurs milliers de fois). On dit qu’on fait plusieurs tours (rounds). Si le nombre de tours (ou de manière plus générale, le coût) est paramétrable, alors il est possible de faire évoluer le coût avec l’évolution du matériel.

Enfin, de manière à pouvoir vérifier le mot de passe, l’algorithme, le nombre de tours, et le sel sont stockés avec l’empreinte.

La commande openssl passwd ne permet pas de spécifier le nombre de tours. Par défaut, elle effectue 5000 tours pour les algorithmes 5 (SHA-256) et 6 (SHA-512). Si l’on veut augmenter le coût, on peut utiliser la commande mkpasswd.

1
echo -n "monmotdepasse" | mkpasswd --method=sha-512 --rounds=100000 --stdin

Questions :

1. Pourquoi l’option -n de la commande echo est-elle indispensable?
2. Sans consulterla documentation, comment pouvez-vous déterminer si la commande openssl passwd ajoute un sel (salt) au mot de passe avant de le hacher ? Indice : Que se passerait-il si ce n’étai pas le cas ?
3. Pourquoi le sel est il important pour la protection des mots de passe ?
4. Qu’est-ce que le nombre de tours ? Pourquoi est-ce important pour la protection des mots de passe ?
5. Pourquoi est-ce utilie de pouvoir spécifier le nombre de tours ? Pour valider le mot de passe, il est nécessaire de connaître l’algorithme, le sel et le nombre de tour (ou le coût). Où ces information sont-elle stockée ?
6. Comment pouvez-vous connaitre la liste des méthode supportée par la commande mkpasswd sur votre système ?

Calcul d’une empreinte avec OpenSSL

OpenSSL a également une commande openssl dgst (digest) pour calculer l’empreinte (hash) sha256 ou sha512 d’un fichier (ici ./fichier.txt) et renvoyer le résultat en hexadécimal (0-9, a-f).

Connectez-vous à votre serveur, créez un fichier nommé fichier.txt dans le répertoire personnel, puis lancez la commande suivante.

1
openssl dgst -sha512 ./fichier.txt

Essayez de changer un caractère du fichier (p. ex. ajouter une espace) et observez le résultat sur l’empreinte.

Chiffrer et déchiffrer des fichiers avec OpenSSL

Nous allons maintenant utiliser la commande openssl enc pour chiffrer un fichier avec les algorithmes AES256 CBC et PBKDF2 pour la dérivation de clé.

Pour cela, lancez la commande suivante et saisissez un mot de passe lorsque vous y êtes invité :

1
openssl enc -aes-256-cbc -salt -pbkdf2 -in fichier.txt -out fichier.txt.enc

Si on affiche le fichier chiffré avec la commande cat, on remarque que le contenu n’est pas lisible. On peut visualiser son contenu en hexadécimal avec la commande hexdump.

1
hexdump -C fichier.txt.enc

On peut également essayer de déterminer le type de fichier avec la commande file.

1
file fichier.txt.enc

On peut ensuite déchiffrer le fichier avec la commande suivante :

1
openssl enc -aes-256-cbc -d -salt -pbkdf2 -in fichier.txt.enc -out fichier_dechiffre.txt

Enfin, on peut utiliser la commande diff pour nous assurer que le fichier original et le fichier déchiffré sont identiques.

Questions :

1. Que fait l’algorithme PBKDF2 ?
2. Pour le chiffrement, la commande à une option -salt. À quoi sert cette option et pourquoi est-il important de l’utiliser ?

Chiffrement avec GPG (GNU Privacy Guard)

L’utilitaire en ligne de commande gpg permet également de chiffrer des documents.

Chiffrez et déchiffrez un document de la même manière que précédemment, mais cette fois avec la commande gpg.

1
2
gpg --symmetric --cipher-algo AES256 --output fichier.txt.gpg fichier.txt
gpg --decrypt --output fichier_dechiffre.txt fichier.txt.gpg

Attention : Le chiffrement et le déchiffrement doivent être réalisés avec le même utilitaire. On ne peut pas chiffrer avec openssl et déchiffrer avec gpg, ou inversement.

Questions :

1. Si je ne suis pas certain de connaître la commande qui a été utilisée pour chiffrer le fichier, comment puis-je essayer de le déterminer ?