Tape les commandes OpenSSL sans regarder, puis Entrée : la vérification compare au caractère près (espaces multiples ignorés), donc une variante valide peut être refusée, ouvre alors la réponse. Pour les autres questions, réponds avant d’ouvrir.
Rappel actif
Restitue de mémoire, sans support.
Pour chaque moyen cryptographique, dis quelle(s) propriété(s) DICP il sert en premier : chiffrement symétrique, chiffrement asymétrique, hachage, signature numérique.
- Symétrique : confidentialité.
- Asymétrique : confidentialité, authentification, non-répudiation (selon le sens d’usage des clés).
- Hachage : intégrité.
- Signature numérique : intégrité + authentification + non-répudiation (hachage puis chiffrement de l’empreinte avec la clé privée).
Décris le chiffrement hybride en quatre étapes, de l’expéditeur au destinataire.
- L’expéditeur génère une clé de session symétrique et chiffre le document avec (rapide).
- Il chiffre cette clé de session avec la clé publique du destinataire (asymétrique).
- Il envoie le document chiffré et la clé de session chiffrée.
- Le destinataire déchiffre la clé de session avec sa clé privée, puis déchiffre le document avec cette clé.
On a la vitesse du symétrique pour le volume, et la sécurité de l’asymétrique pour l’échange de clé.
Signature numérique : décris la génération par Alice et la vérification par Bob.
Génération (Alice) : empreinte du document par une fonction de hachage, puis chiffrement de cette empreinte avec sa clé privée = la signature. Elle envoie document + signature.
Vérification (Bob) : il déchiffre la signature avec la clé publique d’Alice (il obtient l’empreinte d’origine), recalcule l’empreinte du document reçu avec la même fonction de hachage, et compare. Identiques : origine et intégrité confirmées.
Tape la commande
Écris la commande exacte, puis Entrée pour vérifier.
TP OpenSSL : génère une paire de clés RSA de 1024 bits dans
rsakey.pem.openssl genrsa -out rsakey.pem 1024(1024 bits servent au TP ; en production, au moins 2048, idéalement 3072 ou plus.)
Extrais la clé publique du fichier
rsakey.pemversrsapubkey.pem.openssl rsa -in rsakey.pem -pubout -out rsapubkey.pemLa clé publique se dérive de la privée, jamais l’inverse.
Chiffre
fichier_nom_eleveavec la clé publique du destinataire (rsapubkey.pem) versfichier_chiff_rsa.openssl pkeyutl -pubin -inkey rsapubkey.pem -in fichier_nom_eleve -encrypt -out fichier_chiff_rsaCalcule l’empreinte SHA-1 de
fichier_nom_elevedansfichier_nom_eleve.sha1.openssl dgst -sha1 -out fichier_nom_eleve.sha1 fichier_nom_eleveCrée un certificat auto-signé valide un an à partir de la clé
serveur_cle.pem, dansserveur_cert.crt.openssl req -new -x509 -days 365 -key serveur_cle.pem -out serveur_cert.crt-x509produit un certificat (et non une simple demande CSR),-days 365fixe la validité.Affiche en clair le contenu d’un certificat
serveur_cert.crt(sans réafficher le code encodé).openssl x509 -in serveur_cert.crt -text -noout-nooutévite de réafficher le certificat encodé en bas de sortie.
Calcule
Pose le calcul et donne le résultat, puis Entrée pour vérifier.
En chiffrement symétrique, combien de clés faut-il pour que 10 participants communiquent deux à deux ?
n(n-1)/2 = 10 × 9 / 2 = 45. C’est l’explosion du nombre de clés, l’une des limites du symétrique.
En chiffrement asymétrique, combien de clés au total pour ces mêmes 10 participants ?
2n = 20 (une paire publique/privée par personne). À comparer aux 45 du symétrique : l’écart se creuse avec n.
Combien de bits fait l’empreinte produite par SHA-1 ? Et par MD5 ?
SHA-1 : 160 bits. MD5 : 128 bits. (SHA-0 et SHA-1 : 160 ; SHA-2 et SHA-3 : 256 et 512. Note : MD5 et SHA-1 sont aujourd’hui cassés pour la résistance aux collisions, à ne plus utiliser pour la signature.)
Distingue
Deux notions proches : dis ce qui les sépare vraiment.
Pour garantir la confidentialité avec l’asymétrique, avec quelle clé Alice chiffre-t-elle ? Et pour garantir l’authentification ?
- Confidentialité : Alice chiffre avec la clé publique de Bob ; seul Bob (sa clé privée) peut lire.
- Authentification / non-répudiation : Alice chiffre avec sa propre clé privée ; tout le monde peut déchiffrer avec sa clé publique, ce qui prouve que c’est elle qui a chiffré.
La règle : chiffrer pour cacher = clé publique du destinataire ; chiffrer pour prouver = sa propre clé privée.
Symétrique et asymétrique : compare vitesse, nombre de clés, besoin d’un canal sûr et non-répudiation.
Symétrique Asymétrique Vitesse rapide ~10x plus lent Clés (n participants) n(n-1)/2 2n Canal sûr pour la clé nécessaire non (clé publique partagée) Non-répudiation non (clé partagée) oui Chiffrement et hachage : lequel est réversible, et pourquoi stocke-t-on les mots de passe avec le second ?
Le chiffrement est réversible (avec la bonne clé on retrouve le clair). Le hachage est à sens unique : on ne retrouve pas le message depuis l’empreinte. Pour les mots de passe, on stocke l’empreinte : même volé, le fichier ne révèle pas les mots de passe, et on vérifie en comparant les empreintes.
Signature et certificat : que prouve chacun, et comment le second complète-t-il le premier ?
La signature prouve l’intégrité d’un document et son origine (qui détient la clé privée). Mais elle ne prouve pas à qui appartient la clé publique utilisée pour vérifier. Le certificat comble ce trou : signé par une CA de confiance, il lie une clé publique à une identité. Sans certificat, l’asymétrique est vulnérable au MITM (on vous donne une fausse clé publique).
Explique pourquoi
Le mécanisme derrière la règle.
Pourquoi signe-t-on l’empreinte du document plutôt que le document entier ?
Le chiffrement asymétrique est lent et peu adapté aux gros volumes. L’empreinte a une taille fixe et petite : la signer coûte peu, quel que soit le document. Et comme l’empreinte change au moindre octet modifié, signer l’empreinte garantit quand même l’intégrité de tout le document.
Pourquoi le chiffrement hybride est-il la base de HTTPS plutôt que l’asymétrique seul ?
L’asymétrique seul serait trop lent pour chiffrer tout le trafic d’une page. L’hybride ne l’utilise que pour échanger une clé de session symétrique au début (handshake) ; ensuite, toutes les données passent par le symétrique, rapide. On garde la sécurité d’échange de l’asymétrique et la vitesse du symétrique.
Pourquoi une CRL est-elle nécessaire alors que les certificats ont déjà une date d’expiration ?
Une clé privée peut être compromise ou volée avant l’expiration du certificat. La CRL (liste de révocation) permet d’invalider un certificat immédiatement, sans attendre sa date de fin, pour qu’il ne soit plus accepté.
Pourquoi l’Opérateur de Certification est-il « en principe non connecté au réseau » ?
Il détient la clé privée de la CA, qui signe tous les certificats. Si elle est volée, un attaquant peut émettre des certificats valides pour n’importe quel site : toute la confiance de la PKI s’effondre. La garder hors ligne (air-gapped) la protège des intrusions réseau.
Cas pratique
Choisis et justifie avec les critères du cours.
Alice veut envoyer à Bob un gros fichier qui doit rester confidentiel, et Bob doit être certain qu’il vient bien d’Alice et n’a pas été modifié. Quelle combinaison de mécanismes ?
Chiffrement hybride + signature :
- Alice signe : empreinte du fichier, chiffrée avec sa clé privée (authentification, non-répudiation, intégrité).
- Elle chiffre le fichier avec une clé de session symétrique (vitesse pour le gros volume).
- Elle chiffre la clé de session avec la clé publique de Bob (confidentialité).
Bob fait l’inverse : clé privée → clé de session → fichier, puis vérifie la signature avec la clé publique d’Alice.
Un serveur web veut un certificat reconnu par les navigateurs. Décris les étapes OpenSSL du TP, de la clé à la signature par l’AC.
openssl genrsa -out serveur_cle.pem 1024 # clé du serveur openssl req -new -key serveur_cle.pem -out server.csr # demande (CSR) # côté AC : openssl x509 -req -in server.csr -out server.crt \ -CA ca.crt -CAkey cakey.pem -CAcreateserialLa CSR contient la clé publique et l’identité ; l’AC la signe avec sa clé privée. Le navigateur fait confiance parce qu’il connaît déjà la clé publique de l’AC.
Trouve l'erreur
Chaque affirmation contient au moins une faute.
« Pour signer un document, Alice le chiffre avec la clé publique de Bob. »
Pour signer, Alice chiffre l’empreinte avec sa propre clé privée : c’est ce qui prouve que ça vient d’elle. Chiffrer avec la clé publique de Bob sert à la confidentialité, pas à la signature.
« Le hachage protège la confidentialité : une fois haché, le message est illisible pour les tiers. »
Le hachage sert à l’intégrité, pas à la confidentialité : il est à sens unique, on ne peut pas « déhacher » pour récupérer le message. Il ne transmet aucune donnée récupérable, il ne protège donc rien de confidentiel.
« Un certificat auto-signé est aussi fiable qu’un certificat signé par une CA. »
Un certificat auto-signé n’est garanti par aucun tiers de confiance : rien ne prouve que l’identité est réelle, les navigateurs l’affichent en avertissement. Seule la signature par une CA reconnue établit la confiance dans un environnement public.
Et si...
Prévois la conséquence.
Et si deux fichiers différents produisent la même empreinte (collision) sur la fonction de hachage utilisée pour les signatures ?
Un attaquant peut faire signer un fichier anodin, puis présenter l’autre fichier (malveillant) avec la même signature valide : l’intégrité et la non-répudiation s’effondrent. C’est pourquoi MD5 et SHA-1, sur lesquels des collisions ont été produites, sont abandonnés pour la signature au profit de SHA-2.
Et si la clé privée de la CA racine est compromise ?
L’attaquant peut émettre des certificats valides pour n’importe quelle identité : tous les certificats de cette PKI deviennent suspects. Il faut révoquer la CA (la retirer des magasins de confiance) et réémettre toute la chaîne. C’est le pire scénario, d’où l’OC hors ligne.