Clés, certificats et autorités
Clés asymétriques, certificats et handshake.
Objectifs
À la fin de cette leçon, vous saurez :
- expliquer le principe de la cryptographie asymétrique ;
- décrire ce qu'est un certificat et qui le signe ;
- suivre les grandes étapes du handshake TLS sans formules.
Asymétrique : deux clés pour un coffre
La cryptographie symétrique utilise une seule clé partagée (chiffrer = déchiffrer) — problème : comment se la transmettre sans qu'on l'intercepte ?
La cryptographie asymétrique résout cela avec un couple :
clé publique → chiffre (distribuable à tous)
clé privée → déchiffre (ne quitte JAMAIS le serveur)
Quiconque chiffre avec la clé publique ; seul le détenteur de la privée peut lire. L'inverse existe aussi : signer avec sa clé privée prouve l'identité, puisque tout le monde peut vérifier avec la publique.
Le certificat : une carte d'identité signée
Un certificat associe un nom de domaine à une clé publique, le tout signé par une autorité :
Certificat exemple.fr
├── sujet : exemple.fr
├── validité : du ... au ...
├── clé publique : ----BEGIN PUBLIC KEY----
└── signature : signée par Let's Encrypt
Votre navigateur connaît d'avance les autorités de certification (AC) légitimes intégrées au système. Il vérifie : la signature est-elle d'une AC connue ? Le domaine correspond-il ? Les dates sont-elles valides ? Un échec → avertissement rouge.
C'est la chaîne de confiance : je ne fais pas confiance à example.fr par magie ; je fais confiance à mon système, qui fait confiance aux AC, qui ont vérifié que le demandeur contrôlait bien le domaine.
Le handshake en cinq gestes
L'établissement d'une session TLS (handshake) :
1. client hello « voici mes capacités »
2. server hello + CERTIFICAT « je suis exemple.fr, voici ma carte »
3. vérification navigateur contrôle chaîne de certificats
4. échange de clés les deux côtés calculent une clé symétrique
de session, SANS la transmettre
5. session chiffrée tout HTTP circule désormais chiffré
Détail élégant : l'asymétrique sert uniquement à l'ouverture ; ensuite tout circule en symétrique, beaucoup plus rapide. C'est pourquoi on peut naviguer en HTTPS sans sentir la cryptographie.
Exercice
- Pourquoi la clé privée ne doit jamais quitter le serveur ?
- Que vérifie exactement le navigateur dans un certificat ? (trois points minimum)
- Un site pirate peut-il obtenir un certificat valide pour
banque-exemple.fr?
Résumé
- Publique chiffre / privée déchiffre ; signée par la privée / vérifiée par la publique.
- Certificat = identité du domaine + clé publique + signature d'AC.
- Handshake : s'identifier, se mettre d'accord sur une clé, puis parler chiffré.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1. Elle EST l'identité : qui possède la privée peut déchiffrer tout le trafic visé et signer comme le domaine. Sa fuite annule toutes les garanties ; c'est pourquoi les serveurs la stockent avec des permissions strictes et que sa compromission impose une révocation.
Question 2. Signature par une AC connue du système ; nom de domaine correspondant au site visité ; dates de validité ; (et souvent : révocation non constatée, chaîne complète jusqu'à une racine).
Question 3. Pas sans démontrer le contrôle du domaine auprès de l'AC (défi DNS ou fichier sur le serveur). C'est précisément le travail de validation de l'AC : la faiblesse ne serait pas cryptographique mais organisationnelle (AC compromise ou trompée), cas rarissime et traité par révocation.