Cours Chiffrement et cryptographie — symétrique, asymétrique, hachage, signatures, certificats, TLS et clés

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. distinguer confidentialité, intégrité, authenticité et non-répudiation, et dire quel outil apporte laquelle ;
2. expliquer chiffrement symétrique et asymétrique, et pourquoi on les combine (chiffrement hybride) ;
3. différencier hachage, code d'authentification (HMAC), dérivation de clé à partir d'un mot de passe et signature ;
4. lire un certificat X.509 et décrire la vérification d'une chaîne de confiance ;
5. décrire une poignée de main TLS 1.3 et ses garanties (secret avant, authentification du serveur) ;
6. expliquer le cycle de vie d'une clé (génération, stockage, rotation, révocation, destruction) ;
7. distinguer chiffrement au repos et en transit, et situer FileVault ;
8. repérer les erreurs courantes (mode ECB, secret codé en dur, hachage rapide pour mots de passe, algorithmes dépréciés) ;
9. utiliser en lecture ou sur fichiers de démonstration openssl, gpg et quelques outils macOS, en annonçant effet, droits et retour arrière.

Prérequis

• Savoir ouvrir Terminal et lire une commande (cours Terminal macOS).
• Notion de fichier, de réseau et de navigateur ; aucune mathématique requise.
• Pour la pratique : OpenSSL et GnuPG déjà présents ou installés avec accord de Stéphane. L'installation ne fait pas partie du cours.

Parcours et chapitres

1. Les quatre objectifs et le vocabulaire

Vocabulaire : clair (donnée lisible), chiffré (illisible sans clé), clé (paramètre secret ou public), algorithme (public : la sécurité repose sur la clé, pas sur le secret de l'algorithme), aléa (nombres imprévisibles, indispensables à presque tout).

2. Chiffrement symétrique

Une même clé chiffre et déchiffre. Rapide, adapté aux gros volumes. Le standard est AES (FIPS 197, mis à jour en mai 2023 sans changement de l'algorithme) avec des clés de 128, 192 ou 256 bits et des blocs de 128 bits.

Le mode d'opération compte autant que l'algorithme :

Un AEAD (chiffrement authentifié avec données associées) refuse de déchiffrer si le contenu a été altéré. Un nonce ou vecteur d'initialisation (IV) ne doit jamais être réutilisé avec la même clé dans des modes comme GCM (conséquence détaillée dans la publication NIST SP 800-38D, non consultée).

Limite : il faut un moyen sûr de partager la clé. C'est le problème que résout le chiffrement asymétrique.

3. Chiffrement asymétrique

Une paire de clés : la clé publique se diffuse, la clé privée reste secrète. Selon l'usage :

• chiffrer pour un destinataire : clé publique du destinataire pour chiffrer, sa clé privée pour déchiffrer ;
• signer : clé privée de l'auteur pour signer, clé publique pour vérifier ;
• accord de clé (Diffie-Hellman) : deux parties calculent un secret commun sans l'envoyer.

Familles courantes : RSA (2048 bits au minimum selon OWASP), courbes elliptiques (P-256, X25519, Ed25519). Plus lent que le symétrique : on ne chiffre pas de gros fichiers directement.

Chiffrement hybride : on chiffre les données avec une clé symétrique aléatoire de session, et on protège cette clé avec la clé publique du destinataire (ou on la dérive d'un accord de clé). C'est le principe de TLS et d'OpenPGP.

4. Hachage, MAC et mots de passe

Une fonction de hachage produit une empreinte de taille fixe, sans clé, à sens unique, avec des changements imprévisibles. La famille SHA-2 (par exemple SHA-256) est décrite par FIPS 180-4 (août 2015) ; la page du NIST signale qu'une révision est décidée (note du 7 mars 2023).

Déprécié : MD5 et SHA-1 sont à proscrire pour la sécurité (OWASP TLS : « avoid MD5 and SHA-1 »). Usage résiduel pour des sommes de contrôle non sécuritaires seulement.

Mots de passe (aide-mémoire OWASP « Password Storage ») : Argon2id préféré, au minimum 19 MiB de mémoire, 2 itérations, 1 de parallélisme ; PBKDF2 avec HMAC-SHA-256 à 600 000 itérations ou plus si la conformité FIPS l'exige ; bcrypt en héritage (facteur 10 ou plus, limite de 72 octets). Chaque mot de passe a un sel aléatoire propre.

5. Signatures numériques

Une signature = empreinte du document chiffrée avec la clé privée (vue simplifiée). Quiconque a la clé publique peut vérifier : le document n'a pas changé et la clé privée correspondante l'a signé. FIPS 186-5 (3 février 2023) définit la norme de signature ; le détail des algorithmes approuvés est non vérifié (page lue sans la liste). La RFC 8446 retient EdDSA et RSASSA-PSS dans TLS 1.3.

6. Certificats X.509 et infrastructure à clé publique

Un certificat lie une identité (nom de domaine, personne) à une clé publique et porte la signature d'une autorité de certification (AC). La RFC 5280 (mai 2008, Proposed Standard) en définit le profil, les extensions (nom alternatif du sujet subjectAltName, basicConstraints, keyUsage), les listes de révocation (CRL) et l'algorithme de validation de chemin.

Vérification d'une chaîne : certificat du serveur, certificat(s) intermédiaire(s), puis AC racine déjà présente dans le magasin de confiance du système. On contrôle la signature de chaque maillon, les dates de validité, le nom demandé (présent dans subjectAltName), l'usage autorisé et la révocation.

Un certificat auto-signé est signé par sa propre clé : utile en laboratoire, mais personne n'a de raison de lui faire confiance par défaut. Recommandations OWASP pour les certificats : RSA 2048 bits minimum, SHA-256, nom du serveur dans subjectAltName, enregistrements CAA, renouvellement automatisé (ACME).

7. TLS : le chiffrement en transit

La RFC 8446 (août 2018, Proposed Standard) définit TLS 1.3. D'après la page : suites anciennes supprimées, clé établie par échange éphémère ((EC)DHE), donc confidentialité persistante (la compromission future de la clé du serveur ne déchiffre pas les sessions passées), compression retirée, messages de la poignée de main chiffrés après ServerHello, algorithmes AEAD seulement. Le serveur est authentifié par son certificat ; le client ne l'est que si le serveur le demande.

Versions : la RFC 8996 (mars 2021, BCP 195) déprécie TLS 1.0 et 1.1. OWASP recommande TLS 1.3 par défaut, TLS 1.2 pour la compatibilité, et l'interdiction de SSLv2/SSLv3 et des suites sans AEAD, anonymes ou « export ». HSTS demande au navigateur de toujours utiliser HTTPS.

8. Gestion des clés

La publication NIST SP 800-57 partie 1 révision 5 (mai 2020, finale) est la référence de gestion des clés : génération, distribution, utilisation, stockage, rotation, archivage, destruction, ainsi que durées de vie (« cryptopériodes »).

Bonnes pratiques (OWASP « Cryptographic Storage ») :

• générer avec un générateur aléatoire cryptographique (jamais rand() ni une date) ;
• chiffrement d'enveloppe : une clé de données (DEK) chiffrée par une clé de chiffrement de clés (KEK) conservée ailleurs ;
• séparer les clés des données chiffrées ; clés indépendantes par usage ;
• tourner les clés en cas de compromission, de fin de cryptopériode ou d'affaiblissement de l'algorithme ;
• utiliser un coffre (Trousseau macOS, coffre cloud, HSM) plutôt qu'un fichier en clair ;
• prévoir sauvegarde et récupération : une clé perdue rend les données définitivement illisibles.

Sur Mac, la hiérarchie de clés de FileVault est matérielle (chapitre 9). La publication NIST SP 800-131A révision 2 (mars 2019) guide la transition des algorithmes et longueurs de clés ; une révision 3 a été publiée en version préliminaire (commentaires jusqu'au 4 décembre 2024), état actuel non vérifié.

9. Chiffrement au repos et en transit sur Mac

D'après Apple : sur Mac Apple silicon et T2, les clés sont gérées dans le Secure Enclave ; la clé de volume est enveloppée par une clé dérivée du mot de passe de l'utilisateur et d'un identifiant matériel (UID) ; les clés ne sont « jamais directement exposées au processeur ». À l'activation de FileVault, une clé de récupération de 24 caractères est générée ; elle remplace le mot de passe à l'ouverture. Selon la page, les Mac modernes chiffrent leurs volumes même FileVault désactivé, avec l'UID seul : le chiffrement protège alors le disque démonté, pas contre quelqu'un qui démarre la machine.

10. Erreurs courantes

11. Pratique : OpenSSL, GnuPG et outils macOS

Règle : tout se passe dans un dossier temporaire jetable, avec des fichiers de démonstration. Aucune clé réelle n'est touchée.

Remarque sur les versions : sur macOS, la commande openssl livrée avec le système peut être LibreSSL et non OpenSSL, avec des options différentes (non vérifié). Les options ci-dessous viennent de la documentation OpenSSL master ; contrôler d'abord la version avec la commande de lecture suivante.

openssl versiongpg --version

• Contexte : Terminal macOS ; outils éventuellement absents.
• Droits : utilisateur normal.
• Effet : lecture seule, affiche les versions.
• Vérification : deux lignes de version. Noter si openssl annonce « OpenSSL » ou « LibreSSL ».
• Retour arrière : sans objet.

11.1 Préparer un dossier de démonstration

Attention, effet notable. Cette commande peut écrire ou écraser un fichier. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

DEMO="$(mktemp -d)"cd "$DEMO"echo "message de démonstration, sans donnée réelle" > message.txt

• Contexte : Terminal ; mktemp -d crée un dossier dans l'espace temporaire (comportement macOS habituel, non vérifié dans les pages consultées).
• Droits : utilisateur normal.
• Effet : crée un dossier vide et un fichier texte.
• Vérification : ls montre message.txt.
• Retour arrière : voir 11.10 (suppression du dossier).

11.2 Empreinte d'un fichier

openssl dgst -sha256 message.txtshasum -a 256 message.txt

• Contexte : dossier de démonstration.
• Droits : lecture du fichier.
• Effet : affiche l'empreinte SHA-256 (openssl dgst : défaut SHA-256 depuis OpenSSL 1.1.0, d'après la page ; shasum est un outil macOS non documenté dans les pages consultées).
• Vérification : les deux empreintes sont identiques ; modifier un caractère du fichier change entièrement l'empreinte.
• Retour arrière : sans objet.

11.3 Chiffrement symétrique d'un fichier de démonstration

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

openssl enc -aes-256-cbc -pbkdf2 -salt -in message.txt -out message.encopenssl enc -d -aes-256-cbc -pbkdf2 -in message.enc -out message-dechiffre.txt

• Contexte : dossier de démonstration ; options -aes-256-cbc, -pbkdf2, -salt, -d, -in, -out d'après la page openssl-enc. OpenSSL demande une phrase secrète : en choisir une jetable, ne pas la passer en argument de ligne de commande.
• Droits : écriture dans le dossier.
• Effet : crée message.enc puis message-dechiffre.txt. Cette commande n'authentifie pas : la page précise qu'elle ne prend pas en charge GCM et CCM et laisse à l'utilisateur la gestion des clés et vecteurs ; elle recommande openssl-cms pour des données sensibles. Usage pédagogique seulement. CBC est ici un mode sans authentification (chapitre 2).
• Vérification : cmp message.txt message-dechiffre.txt ne renvoie rien (fichiers identiques). Une mauvaise phrase secrète fait échouer le déchiffrement.
• Retour arrière : supprimer les fichiers créés.

11.4 Paire de clés de signature de démonstration

Attention, effet notable. Cette commande peut modifier des droits, des fichiers ou des processus. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

openssl genpkey -algorithm ED25519 -out demo-cle-privee.pemchmod 600 demo-cle-privee.pemopenssl pkey -in demo-cle-privee.pem -pubout -out demo-cle-publique.pem

• Contexte : dossier de démonstration. genpkey -algorithm ED25519 -out d'après la page. openssl pkey -pubout : non consulté, non vérifié.
• Droits : écriture dans le dossier ; chmod 600 restreint la clé au propriétaire (la page genpkey ne traite pas des droits de fichier).
• Effet : crée une clé privée sans phrase secrète (jetable) et la clé publique associée. Pour protéger une vraie clé, la page indique l'option -aes-256-cbc ; ne jamais réutiliser cette clé de démonstration.
• Vérification : ls -l montre -rw------- sur la clé privée.
• Retour arrière : supprimer le dossier de démonstration.

11.5 Signer puis vérifier

openssl pkeyutl -sign -inkey demo-cle-privee.pem -rawin -in message.txt -out message.sigopenssl pkeyutl -verify -pubin -inkey demo-cle-publique.pem -rawin -in message.txt -sigfile message.sig

• Contexte : dossier de démonstration ; -sign, -verify, -pubin, -sigfile, -rawin d'après la page openssl-pkeyutl (Ed25519 signe les données brutes sans pré-hachage). OpenSSL 3 requis ; avec LibreSSL, -rawin peut manquer : à vérifier avec openssl version, puis installer OpenSSL 3.
• Droits : lecture des clés, écriture de message.sig.
• Effet : crée une signature puis la contrôle.
• Vérification : le second résultat indique une signature vérifiée ; le libellé exact n'a pas été relevé (non vérifié). Modifier message.txt puis relancer : la vérification doit échouer.
• Retour arrière : supprimer message.sig.

11.6 Certificat auto-signé de démonstration et lecture

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

openssl req -x509 -newkey rsa:2048 -noenc -keyout demo.key -out demo.crt -days 30 -subj "/CN=demo.example.test" -addext "subjectAltName=DNS:demo.example.test"openssl x509 -in demo.crt -noout -subject -issuer -dates -fingerprint

• Contexte : dossier de démonstration ; -noenc remplace -nodes (déprécié depuis OpenSSL 3.0) d'après la page openssl-req ; OpenSSL 3 requis ; avec LibreSSL, utiliser la variante -nodes ou installer OpenSSL 3 (à vérifier avec openssl version).
• Droits : écriture dans le dossier.
• Effet : crée une clé privée non chiffrée et un certificat valable 30 jours pour un nom réservé aux exemples. La seconde commande lit le certificat : sujet, émetteur (identique au sujet : auto-signé), dates, empreinte.
• Vérification : subject et issuer identiques ; dates de début et de fin à 30 jours d'écart.
• Retour arrière : supprimer demo.key et demo.crt.

11.7 Observer le certificat d'un serveur (réseau, lecture)

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

openssl s_client -connect HOTE:443 -servername HOTE -brief < /dev/null

• Contexte : remplacer HOTE par un serveur de test dont l'usage est autorisé ; ne jamais cibler un système tiers sans autorisation. Options -connect, -servername, -brief d'après la page openssl-s_client.
• Droits : utilisateur normal.
• Effet : ouvre une connexion TLS réelle, affiche version, suite et résultat de la vérification, puis se ferme (< /dev/null). Aucune donnée n'est modifiée côté serveur, mais la connexion est visible dans ses journaux.
• Vérification : une ligne de protocole (TLS 1.3 attendu si le serveur le permet) et l'état de vérification du certificat. Ajouter -verify_return_error pour interrompre en cas d'échec de vérification.
• Retour arrière : sans objet.

11.8 GnuPG : chiffrer avec une phrase secrète, signer, vérifier

Utiliser un trousseau GnuPG temporaire, jamais le trousseau personnel :

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

export GNUPGHOME="$DEMO/gnupg"mkdir -m 700 "$GNUPGHOME"gpg --symmetric --armor message.txtgpg --decrypt message.txt.asc

• Contexte : GNUPGHOME redirige GnuPG vers le dossier de démonstration (variable d'environnement : non consultée dans la page vue, à vérifier dans le manuel). --symmetric (AES-256 par défaut selon le manuel) et --armor, --decrypt d'après la page des commandes.
• Droits : utilisateur normal ; GnuPG demande une phrase secrète jetable.
• Effet : crée message.txt.asc (nom habituel, non vérifié) puis affiche le contenu déchiffré sur la sortie standard.
• Vérification : le texte d'origine s'affiche.
• Retour arrière : unset GNUPGHOME ; supprimer le dossier de démonstration.

Signature : gpg --detach-sign et gpg --verify existent (page des commandes) mais exigent une paire de clés OpenPGP, créée par gpg --full-generate-key (non consulté, non vérifié ; interactive, jetable, dans GNUPGHOME). Pour des scripts, le manuel conseille --with-colons et déconseille d'analyser la sortie de --list-keys et --fingerprint, destinée aux humains.

11.9 Outils macOS en lecture

fdesetup statussecurity list-keychains

• Contexte : Terminal macOS. Les deux commandes sont des outils du système non documentés dans les pages consultées : non vérifié, lire man fdesetup et man security avant.
• Droits : utilisateur normal ; fdesetup peut demander des droits supplémentaires (non vérifié).
• Effet : lecture. fdesetup status indique si FileVault est activé ; security list-keychains liste les trousseaux de l'utilisateur.
• Vérification : une ligne d'état et une liste de chemins.
• Retour arrière : sans objet. Activer ou désactiver FileVault passe par Réglages Système, pas par ce cours.

11.10 Nettoyage

Attention, effet notable. Cette commande peut supprimer des fichiers. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

unset GNUPGHOMEcd ~rm -r "$DEMO"

• Contexte : Terminal ; $DEMO défini en 11.1.
• Droits : utilisateur normal.
• Effet : supprime définitivement le dossier de démonstration et ses clés jetables.
• Vérification : avant de valider, relire la commande : $DEMO doit désigner le dossier temporaire de 11.1 (echo "$DEMO" avant cd ~). Après, ls sur ce chemin échoue.
• Retour arrière : aucun (suppression définitive, fichiers sans valeur).

Exercices et vérifications de fin de cours

1. Vocabulaire. Pour confidentialité, intégrité, authenticité, non-répudiation : citer un outil et un cas où il ne suffit pas.
2. Choix d'outil. Pour chaque cas, dire hachage, HMAC, symétrique, asymétrique ou signature : vérifier un téléchargement ; stocker un mot de passe ; envoyer un fichier à un tiers dont on a la clé publique ; prouver qu'un script vient de soi.
3. Schéma. Sans regarder la figure du chapitre 7, redessiner la poignée de main TLS 1.3 et indiquer où intervient l'asymétrique et où le symétrique.
4. Pratique guidée. Dérouler 11.1 à 11.6 dans un dossier jetable : empreinte, chiffrement et déchiffrement, signature valide puis invalide après modification du fichier.
5. Lecture de certificat. Sur le certificat de 11.6, retrouver sujet, émetteur, dates et nom alternatif ; expliquer pourquoi un navigateur ne lui ferait pas confiance.
6. Analyse d'erreurs. Dans la table du chapitre 10, choisir trois lignes et décrire un scénario d'attaque concret en une phrase.
7. Gestion des clés. Rédiger sur papier le cycle de vie d'une clé de sauvegarde : où est-elle créée, stockée, sauvegardée, tournée, détruite ?
8. FileVault. Expliquer où se trouve la clé de récupération et pourquoi elle ne doit pas être sur le Mac chiffré.

Critères de réussite

• Choisir entre symétrique, asymétrique, hachage, MAC et signature selon le besoin.
• Citer au moins trois erreurs courantes et leur correction.
• Lire un certificat et expliquer une chaîne de confiance.
• Exécuter les exercices de démonstration sans toucher à aucune clé ni donnée réelle, et nettoyer.