🎓 SIO1 · semestre 2⏱️ 5 h (cours + TP)🛡️ Bloc 3 – CybersécuritéComprendre comment on protège la confidentialité et l'intégrité des échanges : chiffrement symétrique et asymétrique, échange de clés, hachage, signature, certificats et infrastructure de confiance, puis le protocole TLS qui sécurise le web.
🎯 Objectifs
Distinguer chiffrement symétrique et asymétrique, et dire quand on utilise l'un ou l'autre.
Expliquer le principe de l'échange de clés de Diffie-Hellman.
Utiliser une fonction de hachage pour vérifier l'intégrité et stocker un mot de passe.
Décrire une signature numérique et un certificat X.509, et suivre une chaîne de confiance.
Décrire la poignée de main TLS 1.3 et diagnostiquer les erreurs de certificat courantes.
Manipuler OpenSSL : empreintes, chiffrement, autorité de certification et certificat serveur.
📋 Prérequis
Les critères DICP (disponibilité, intégrité, confidentialité, preuve).B3-01 · Fondamentaux
Test express des prérequis 3 questions · 2 minutes · conseillé avant de commencer
1. Quel critère de sécurité protège-t-on en empêchant un tiers de lire un message ?
La confidentialité réserve l'information aux personnes autorisées ; le chiffrement en est l'outil principal. À revoir : B3-01 · Fondamentaux.
2. Combien de valeurs différentes une clé de 8 bits peut-elle prendre ?
28 = 256. Chaque bit ajouté double le nombre de clés à essayer : une clé AES de 128 bits offre 2128 possibilités, hors de portée de tout ordinateur.
3. Que signifie le « S » de HTTPS ?
HTTPS, c'est HTTP transporté dans un tunnel TLS (port 443). TLS est détaillé en partie 8 de cette fiche.
Chaque matin, les salariés de Brocéliande Logistique (entreprise fictive) ouvrent l'intranet et voient le même écran rouge : « Votre connexion n'est pas privée ». On leur a appris à cliquer sur « Continuer quand même ». Le jour où un attaquant interceptera vraiment la connexion, personne ne fera la différence.
Le responsable informatique veut en finir : il te demande de comprendre ce que signifie cet avertissement, de créer une autorité de certification interne pour délivrer de vrais certificats aux serveurs de l'entreprise, et de vérifier que les échanges sont bien chiffrés en TLS 1.3. Il veut aussi savoir comment les mots de passe de l'application de gestion sont stockés.
Le coursLes objectifs de la cryptographie, le chiffrement symétrique et asymétrique, l'échange de clés, le hachage, la signature, les certificats et la PKI, puis TLS et le dépannage des certificats.
1. À quoi sert la cryptographie ?
La cryptographie transforme les données pour qu'elles restent protégées même si elles tombent entre de mauvaises mains : sur un réseau Wi-Fi public, sur un disque volé, dans un courriel intercepté. Elle répond à quatre besoins de sécurité.
Besoin
Question
Outil cryptographique
Confidentialité
Seul le destinataire peut-il lire ?
Chiffrement (symétrique, asymétrique)
Intégrité
Le message a-t-il été modifié ?
Hachage, code d'authentification (HMAC)
Authentification
Parle-t-on bien au bon serveur, à la bonne personne ?
Certificats, signature
Non-répudiation
L'auteur peut-il nier avoir envoyé ?
Signature numérique (clé privée personnelle)
Le texte clair devient un texte chiffré grâce à un algorithme (AES, RSA…) et une clé. Chiffrer et déchiffrer se font avec la clé ; décrypter, c'est retrouver le clair sans la clé (ce que fait l'attaquant). On ne dit pas « crypter ». Selon le principe de Kerckhoffs, l'algorithme est public : toute la sécurité repose sur le secret de la clé.
2. Le chiffrement symétrique : une seule clé partagée
Dans le chiffrement symétrique, la même clé sert à chiffrer et à déchiffrer. C'est très rapide : un processeur récent chiffre plusieurs gigaoctets par seconde. L'algorithme de référence est AES (Advanced Encryption Standard), avec des clés de 128 ou 256 bits ; il protège les disques (BitLocker, LUKS), les archives, le Wi-Fi (WPA2/WPA3) et les données échangées en TLS.
Rapide et sûr… à condition d'avoir pu partager la clé secrètement.
Le symétrique a deux faiblesses. La distribution de la clé : il faut la transmettre sans qu'elle soit interceptée. Et le nombre de clés : pour que n personnes communiquent deux à deux en secret, il faut n(n−1)/2 clés : 45 clés pour 10 personnes, 1 770 pour les 60 salariés de Brocéliande.
3. Le chiffrement asymétrique : une paire de clés
En 1976 apparaît une idée révolutionnaire : chaque personne possède une paire de clés liées mathématiquement. La clé publique peut être donnée à tout le monde ; la clé privée ne quitte jamais son propriétaire. Ce que l'une chiffre, seule l'autre peut le déchiffrer. Les algorithmes les plus connus sont RSA et les courbes elliptiques (ECC : ECDSA, Ed25519).
Clique sur « Chiffrer pour le cabinet », puis sur « Signer en tant que comptable » : observe quelle clé est utilisée.
Choisis une opération en haut du schéma.
Une même paire de clés sert à deux choses opposées : chiffrer pour quelqu'un, ou signer en son propre nom.
Chiffrer (confidentialité) : avec la clé publique du destinataire. Signer (origine, intégrité, non-répudiation) : avec sa propre clé privée. Une clé privée ne se transmet jamais, ne s'envoie pas par courriel et se protège par une phrase de passe.
Symétrique
Asymétrique
Clés
Une seule, partagée
Une paire : publique + privée
Vitesse
Très rapide
100 à 1 000 fois plus lent
Exemples
AES-128, AES-256, ChaCha20
RSA 2048 / 3072, ECC (P-256, Ed25519)
Usage
Chiffrer les données elles-mêmes
Échanger une clé, signer, authentifier
En pratique, on combine les deux : c'est le chiffrement hybride. L'asymétrique (ou un échange de clés, partie 4) sert à établir une clé de session symétrique, puis tout le trafic est chiffré en AES. C'est exactement ce que fait TLS.
4. Se mettre d'accord sur une clé secrète en public : Diffie-Hellman
Comment deux machines qui ne se sont jamais parlé peuvent-elles fabriquer une clé secrète commune, alors que tout ce qu'elles s'envoient peut être écouté ? C'est le problème résolu par Diffie et Hellman en 1976. Aujourd'hui, TLS 1.3, SSH, WireGuard et les VPN utilisent sa version sur courbes elliptiques (ECDHE).
Pour bien comprendre : le mélange de peintures
Alice et Bob se mettent d'accord, à voix haute, sur une couleur de départ : le jaune. Chacun choisit une couleur secrète (rouge pour Alice, bleu pour Bob) et la mélange au jaune.
Ils s'échangent ces mélanges devant tout le monde. Chacun ajoute alors sa couleur secrète au mélange reçu : les deux obtiennent le même brun (jaune + rouge + bleu).
L'espion a vu passer le jaune, l'orange et le vert, mais il est incapable de « démélanger » une peinture pour retrouver le rouge ou le bleu. En mathématiques, ce « démélange » impossible s'appelle le logarithme discret.
ECDHE = Diffie-Hellman sur courbes elliptiques, éphémère : une nouvelle paire de valeurs secrètes est tirée à chaque connexion puis oubliée. Même si la clé privée du serveur est volée un jour, les anciennes conversations enregistrées restent illisibles : c'est la confidentialité persistante. Attention : Diffie-Hellman seul ne dit pas avec qui on parle ; c'est le certificat (partie 7) qui authentifie le serveur.
5. Le hachage : l'empreinte des données
Une fonction de hachage calcule, à partir de n'importe quelle donnée (un mot, un fichier de 4 Go), une empreinte (hash) de taille fixe : 256 bits pour SHA-256. Ce n'est pas du chiffrement : on ne peut pas revenir en arrière.
Taille fixeQuelle que soit la taille de l'entrée, SHA-256 donne toujours 64 caractères hexadécimaux (256 bits).
Sens uniqueImpossible de retrouver la donnée d'origine à partir de l'empreinte.
Effet avalancheChanger un seul bit de l'entrée change environ la moitié des bits de l'empreinte.
Résistance aux collisionsImpossible en pratique de trouver deux données différentes ayant la même empreinte. MD5 et SHA-1 ont perdu cette propriété : ils sont obsolètes pour la sécurité.
Usage
Comment
Vérifier un téléchargement (ISO Debian, mise à jour)
Comparer l'empreinte calculée (sha256sum, Get-FileHash) à celle publiée par l'éditeur
Signer
On signe l'empreinte du document, pas le document entier (parties 6 et B3-03)
Stocker un mot de passe
On ne stocke jamais le mot de passe, seulement son empreinte salée et lente (ci-dessous)
Intégrité d'un message (HMAC)
Empreinte calculée avec une clé secrète : prouve à la fois l'intégrité et l'origine
5.1 Stocker les mots de passe
Si une base de données contient les mots de passe en clair, un seul vol suffit. Avec un simple SHA-256, l'attaquant compare les empreintes à des tables précalculées de milliards de mots de passe courants. La bonne méthode combine un sel (valeur aléatoire différente pour chaque compte, stockée à côté) et une fonction volontairement lente : Argon2, bcrypt ou PBKDF2. Deux utilisateurs avec le même mot de passe ont alors des empreintes différentes, et chaque essai coûte cher à l'attaquant.
Debian 13 /etc/shadowformat d'un mot de passe stocké
comptable:$y$j9T$Xq2LmTf0…$4mVb8QK…:20380:0:99999:7:::
│ │ │ └ empreinte
│ │ └ sel (aléatoire, propre à ce compte)
│ └ paramètres de coût
└ $y$ = yescrypt, fonction lente utilisée par Debian
Hachage n'est pas chiffrement. On ne « déchiffre » pas une empreinte : on la recalcule et on compare. Et un hachage rapide (MD5, SHA-1, même SHA-256 sans sel) n'est pas une protection suffisante pour des mots de passe.
6. La signature numérique
La signature combine les deux outils précédents : on calcule l'empreinte du document, puis on la chiffre avec sa clé privée. Le destinataire recalcule l'empreinte et la compare à la signature déchiffrée avec la clé publique de l'auteur. S'ils sont identiques, le document est intègre et vient bien de l'auteur (fiche B3-03, partie 6, pour le schéma détaillé et la valeur juridique).
Il reste un problème : comment être sûr que la clé publique reçue est bien celle de la comptable, et pas celle d'un imposteur ? C'est le rôle du certificat.
7. Certificats et infrastructure de confiance (PKI)
Un certificat X.509 est une carte d'identité numérique : il associe une clé publique à une identité (un nom de serveur, une personne, une entreprise), pour une durée limitée. Il est signé par une autorité de certification (AC) qui garantit ce lien. L'ensemble des AC, des règles et des outils forme une PKI (Public Key Infrastructure, infrastructure à clés publiques).
Debian 13 openssl x509 -textextrait d'un certificat serveur
Certificate:
Version: 3 (0x2)
Serial Number: 04:a1:7c:…
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=FR, O=Broceliande Logistique, CN=BL Intermediaire 2026
Validity
Not Before: Mar 2 08:00:00 2026 GMT
Not After : Mar 2 08:00:00 2027 GMT
Subject: CN=intranet.broceliande.lan
Subject Public Key Info: Public Key Algorithm: id-ecPublicKey (256 bit)
X509v3 Subject Alternative Name: DNS:intranet.broceliande.lan, DNS:srv-web.broceliande.lan
X509v3 Extended Key Usage: TLS Web Server Authentication
Subject et Subject Alternative Name (SAN)L'identité certifiée. Pour un site web, les navigateurs ne regardent que le SAN : le nom tapé dans la barre d'adresse doit y figurer exactement.
IssuerL'autorité qui a signé ce certificat. On remonte ainsi la chaîne jusqu'à une AC racine.
ValidityDates de début et de fin. Un certificat expiré est refusé, même si tout le reste est parfait. Les certificats publics ont une durée de plus en plus courte (90 jours chez Let's Encrypt).
Public Key InfoLa clé publique du serveur et son algorithme (RSA 2048, ECDSA P-256…). La clé privée correspondante reste sur le serveur.
Extended Key UsageCe à quoi le certificat peut servir : authentifier un serveur TLS, un client, signer du code ou des courriels.
On fait confiance au serveur parce qu'on fait confiance à l'AC racine qui, de signature en signature, se porte garante de lui.
7.1 Les autorités de certification
Type d'AC
Exemples
Reconnue par
Usage
Publique
Let's Encrypt (gratuite, automatisée par le protocole ACME), Sectigo, DigiCert
Tous les navigateurs et systèmes
Sites accessibles depuis Internet
Interne (privée)
AC d'entreprise Active Directory (AD CS), petite AC OpenSSL
Les postes où l'on a installé sa racine
Intranet, serveurs internes, Wi-Fi 802.1X, postes et utilisateurs
Autosigné
Certificat signé par sa propre clé
Personne
Tests ponctuels uniquement : il provoque l'avertissement vu chez Brocéliande
Dans un domaine Active Directory, le rôle Services de certificats Active Directory installe une AC d'entreprise. Son certificat racine est automatiquement distribué à tous les postes du domaine, et des modèles de certificats (serveur web, ordinateur, utilisateur) permettent l'inscription automatique par stratégie de groupe. Bonne pratique : une racine hors ligne (éteinte, gardée en lieu sûr) et une AC intermédiaire en ligne qui délivre les certificats.
7.2 Révoquer un certificat
Si une clé privée est volée ou si un serveur est retiré, on révoque son certificat avant sa date d'expiration. Les navigateurs le savent grâce à la liste de révocation (CRL) publiée par l'AC, ou en interrogeant un répondeur OCSP. C'est aussi pour limiter l'impact d'un vol que les certificats publics ont des durées courtes.
8. TLS 1.3 : la poignée de main
TLS (Transport Layer Security) protège HTTPS, mais aussi la messagerie (IMAPS, SMTPS), les VPN SSL et beaucoup d'applications. Il assure la confidentialité (chiffrement), l'intégrité et l'authentification du serveur. La version actuelle, TLS 1.3 (2018), n'a besoin que d'un aller-retour pour établir la connexion.
Un seul aller-retour : le serveur prouve son identité avec son certificat, les clés de session viennent d'ECDHE.
Version
Statut
SSL 2.0, SSL 3.0
Interdits : vulnérables (attaque POODLE)
TLS 1.0, TLS 1.1
Obsolètes depuis 2021, refusés par les navigateurs
TLS 1.2
Encore acceptable avec des suites modernes (ECDHE + AES-GCM)
TLS 1.3
Recommandé : plus rapide, suites faibles supprimées, confidentialité persistante obligatoire
N'accepter que TLS 1.2 et 1.3, avec des suites ECDHE et AES-GCM ou ChaCha20.
Rediriger HTTP vers HTTPS et activer HSTS (le navigateur n'essaiera plus jamais en clair).
Clés de taille suffisante (RSA 2048 minimum, ECDSA P-256), clé privée lisible uniquement par le service.
Surveiller les dates d'expiration et automatiser le renouvellement (ACME).
Ne jamais apprendre aux utilisateurs à « continuer quand même » sur un avertissement de certificat.
9. Diagnostiquer les erreurs de certificat
Un avertissement de certificat n'est jamais anodin : soit le serveur est mal configuré, soit quelqu'un intercepte la connexion. Le message du navigateur et la commande openssl s_client donnent la cause.
Message (navigateur)
Cause
Correction
NET::ERR_CERT_DATE_INVALID
Certificat expiré, ou horloge du poste fausse
Renouveler ; vérifier l'heure (NTP)
NET::ERR_CERT_COMMON_NAME_INVALID
Le nom tapé n'est pas dans le SAN
Refaire le certificat avec tous les noms (et pas une adresse IP tapée à la place)
NET::ERR_CERT_AUTHORITY_INVALID
Certificat autosigné ou AC inconnue du poste
Utiliser une AC reconnue, ou déployer la racine interne sur les postes (GPO)
« chaîne incomplète » (unable to get local issuer certificate)
Le serveur n'envoie pas le certificat intermédiaire
Configurer la chaîne complète (fichier fullchain)
NET::ERR_CERT_REVOKED
Certificat révoqué par l'AC
En installer un nouveau ; chercher pourquoi il a été révoqué
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Le serveur n'accepte que des versions ou suites obsolètes
Activer TLS 1.2/1.3 et des suites modernes
Debian 13 openssl s_clientinterroger un serveur TLS
$ openssl s_client -connect intranet.broceliande.lan:443 -servername intranet.broceliande.lan </dev/null
CONNECTED(00000003)
depth=0 CN = intranet.broceliande.lan
verify error:num=20:unable to get local issuer certificate
verify error:num=21:unable to verify the first certificate
---
Certificate chain
0 s:CN = intranet.broceliande.lan
i:C = FR, O = Broceliande Logistique, CN = BL Intermediaire 2026
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Verify return code: 21 (unable to verify the first certificate)
Certificate chainLes certificats envoyés par le serveur : 0 = le sien, 1 = l'intermédiaire… Ici, un seul certificat : l'intermédiaire manque, ou la racine est inconnue du poste.
TLSv1.3, CipherVersion et suite négociées. On vérifie ainsi qu'un serveur n'accepte plus TLS 1.0 (-tls1 -cipher 'DEFAULT@SECLEVEL=0' doit échouer ; sans l'option -cipher, c'est le client OpenSSL 3 lui-même qui refuse TLS 1.0, et le test ne prouve rien).
Verify return code0 (ok) si la chaîne est valide. Sinon, le numéro donne la cause : 10 = expiré, 18 = autosigné, 20 = émetteur introuvable, 21 = premier certificat invérifiable (serveur seul, sans son intermédiaire).
Pourquoi ce certificat est-il refusé ? Réponds en lisant le certificat (clic sur le cadenas, puis « Afficher le certificat »)
La date du jour est-elle entre « valide à partir du » et « valide jusqu'au » ?Vérifie aussi l'heure du poste.
Le nom tapé dans la barre d'adresse figure-t-il exactement dans le SAN ?Attention à la différence entre intranet et intranet.broceliande.lan.
L'onglet « Chemin de certification » remonte-t-il jusqu'à une racine marquée comme de confiance ?
Problème de date : si le certificat est expiré, renouvelle-le et automatise le renouvellement ; si c'est l'horloge du poste qui est fausse, corrige la synchronisation NTP.
Nom absent du SAN : utilise le nom prévu (le nom complet), ou refais le certificat en ajoutant tous les noms par lesquels le service est joint.
Chaîne cassée : soit le serveur n'envoie pas l'intermédiaire (configure la chaîne complète), soit la racine n'est pas installée sur le poste (déploie-la par GPO, jamais en cliquant « continuer »).
Certificat valide : si l'erreur persiste, vérifie la révocation (CRL/OCSP) et les versions TLS acceptées par le serveur avec openssl s_client.
9.1 Entraîne-toi : les tickets du support
Tu es au support de Brocéliande Logistique. Six tickets touchent au chiffrement et aux certificats : lis le message, observe le relevé et choisis la cause.
File d'attente du support6 tickets · un à la fois · l'explication s'affiche après ta réponse
Ticket n° 1De : tous les servicesPriorité haute
« Depuis ce matin, le webmail affiche une erreur de sécurité sur tous les postes. Hier tout allait bien. »
Cause : la date de fin est dépassée. Les certificats Let's Encrypt durent 90 jours et doivent être renouvelés automatiquement (client ACME planifié). Correction : renouveler à la main, puis réparer la tâche de renouvellement et ajouter une sonde de supervision sur la date d'expiration.
Ticket n° 2De : service paiePriorité moyenne
« L'intranet fonctionne quand je tape https://intranet.broceliande.lan, mais j'ai une erreur quand je tape juste https://intranet. »
Navigateur détails du certificat
Subject Alternative Name : DNS:intranet.broceliande.lan
Erreur : NET::ERR_CERT_COMMON_NAME_INVALID
Quelle est la cause ?
Cause : le navigateur compare le nom tapé avec la liste du SAN : « intranet » n'y est pas. Correction : diffuser le lien complet (favori, GPO), ou refaire le certificat avec les deux noms dans le SAN.
Ticket n° 3De : technicienPriorité basse
« Le nouveau certificat de l'AC interne marche sur les PC du domaine, mais les téléphones Android et un script Linux disent "unable to get local issuer certificate". »
Debian 13 terminal
Certificate chain
0 s:CN = intranet.broceliande.lan
i:CN = BL Intermediaire 2026
Verify return code: 21 (unable to verify the first certificate)
Quelle est la cause la plus probable ?
Cause : la chaîne ne contient qu'un certificat. Les PC du domaine ont reçu l'intermédiaire et la racine par GPO, pas les autres appareils. Correction : configurer le serveur avec la chaîne complète (certificat + intermédiaire), et installer la racine sur les appareils non gérés par le domaine ou les inscrire dans la gestion de flotte.
Ticket n° 4De : responsable informatiqueSécurité
« Un audit de l'application de gestion indique que les mots de passe des utilisateurs sont stockés en MD5. Est-ce grave ? »
Cause : empreintes identiques = mots de passe identiques (ici, un mot de passe très courant). MD5 sans sel se « casse » en une seconde. Correction : migrer vers Argon2 ou bcrypt avec sel, forcer le changement des mots de passe à la prochaine connexion et activer la double authentification.
Ticket n° 5De : stagiaireQuestion
« Le cabinet comptable veut qu'on lui envoie notre clé pour pouvoir nous envoyer des fichiers chiffrés. Je lui envoie prive.pem par courriel ? »
Debian 13 ls
$ ls ~/cles
prive.pem public.pem
Que doit faire le stagiaire ?
Cause : confusion entre les deux clés. Pour qu'on nous chiffre des fichiers, le cabinet a besoin de notre clé publique. La clé privée ne quitte jamais son propriétaire : si elle circule, il faut considérer la paire comme compromise et la remplacer.
Ticket n° 6De : outil de supervisionPriorité moyenne
« Le scanner de vulnérabilités signale le vieux serveur d'extranet : "protocoles obsolètes acceptés". »
Cause : la négociation en TLS 1.0 réussit, alors qu'elle devrait échouer. Correction : dans la configuration du serveur web, n'autoriser que TLS 1.2 et 1.3 (par exemple ssl_protocols TLSv1.2 TLSv1.3; sous Nginx), puis vérifier que -tls1 et -tls1_1 échouent (toujours avec -cipher 'DEFAULT@SECLEVEL=0' : sans cette option, OpenSSL 3 refuse lui-même TLS 1.0/1.1 côté client).
10. À l'examen et en entreprise
Choisir le bon outil : chiffrer (confidentialité), hacher (intégrité, mots de passe), signer (preuve). Les sujets demandent souvent de justifier quelle clé est utilisée à chaque étape.
Expliquer un avertissement de certificat et proposer la vraie correction (pas « cliquer sur continuer »).
Dans une réalisation : documenter la mise en place d'un certificat (AC choisie, noms du SAN, durée, renouvellement), montrer le résultat d'un test openssl s_client ou d'un outil d'analyse TLS, et la configuration limitée à TLS 1.2/1.3.
Vocabulaire précis : on dit chiffrer et déchiffrer ; « décrypter » désigne l'attaque. Le jury y est sensible.
11. L'essentiel
Cryptographie : confidentialité (chiffrement), intégrité (hachage), authentification (certificat), non-répudiation (signature). L'algorithme est public, la clé est secrète.
Symétrique (AES) : une clé partagée, très rapide, mais il faut la transmettre et en gérer beaucoup.
Asymétrique (RSA, ECC) : clé publique + clé privée ; lent, sert à échanger des clés et à signer.
On chiffre avec la clé publique du destinataire ; on signe avec sa propre clé privée, qui ne circule jamais.
Diffie-Hellman (ECDHE) : fabriquer une clé commune en public ; éphémère = confidentialité persistante.
Hachage (SHA-256) : empreinte fixe, sens unique, effet avalanche ; MD5 et SHA-1 obsolètes ; mots de passe : sel + fonction lente (Argon2, bcrypt).
Certificat X.509 : clé publique + identité (SAN) + dates, signés par une AC.
Chaîne de confiance : serveur → intermédiaire → racine présente dans le magasin du poste ; révocation par CRL ou OCSP.
TLS 1.3 : un aller-retour ; ECDHE pour les clés, certificat pour l'identité, AES-GCM pour les données.
Erreur de certificat = date, nom (SAN), chaîne ou version : on corrige la cause, on ne « continue » jamais.
La fiche en une image : à refaire de mémoire, sur une feuille, avant de passer aux exercices.
La pratiqueLe quiz noté pour vérifier tes acquis, les exercices à rendre à ton professeur, puis le TP au labo pour créer ta propre autorité de certification.
12. Quiz noté
8 questions · 10 minutesRéponds à toutes les questions, puis valide. Seule ta première tentative est enregistrée : elle compte dans ton suivi. Ensuite, tu peux t'entraîner autant que tu veux.
1. AES est un algorithme de chiffrement…
2. Pour envoyer un fichier confidentiel au cabinet comptable, avec quelle clé le chiffre-t-on ?
3. Avec quelle clé signe-t-on un document ?
4. Quelle propriété d'une fonction de hachage est utile pour vérifier un téléchargement ?
5. Pourquoi ajoute-t-on un sel avant de hacher un mot de passe ?
6. Que permet l'échange de clés Diffie-Hellman ?
7. Le navigateur affiche NET::ERR_CERT_COMMON_NAME_INVALID. Quelle est la cause ?
8. Dans TLS 1.3, qu'est-ce qui chiffre les données de la page web échangées ?
13. Exercices : à toi de répondre
Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige.
Exercice 1 – Quelle clé ? (SIO1)
Alice (Brocéliande) et Bob (cabinet comptable) ont chacun une paire de clés. Pour chaque besoin, indique quelle clé est utilisée et par qui : a) Alice envoie à Bob un fichier que lui seul doit pouvoir lire ; b) Bob veut prouver qu'il est bien l'auteur d'un rapport ; c) Alice vérifie ce rapport ; d) pourquoi, en pratique, ne chiffre-t-on pas un fichier de 2 Go directement en RSA ?
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Exercice 2 – Hacher n'est pas chiffrer (SIO1)
Le développeur de l'application de gestion propose : « Je chiffre les mots de passe en AES avec une clé stockée dans le code, comme ça on peut les renvoyer aux utilisateurs qui les oublient. » Explique les deux problèmes de cette proposition et ce qu'il faut faire à la place.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Exercice 3 – Lire un certificat (SIO1)
Voici un extrait : Issuer: CN=intranet.broceliande.lan ; Subject: CN=intranet.broceliande.lan ; Not After: Jan 5 2026 ; SAN: DNS:intranet. Nous sommes en octobre 2026 et les salariés tapent https://intranet.broceliande.lan. Liste toutes les erreurs que le navigateur va signaler et propose une solution durable.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Exercice 4 – Concevoir (SIO2)
Brocéliande veut sécuriser tous ses services internes (intranet, GLPI, webmail, Wi-Fi d'entreprise en 802.1X) et ses deux sites publics. Propose une organisation des certificats : quelles AC, quels types de certificats pour quels usages, durée, distribution des racines, renouvellement et supervision. Justifie en 8 à 10 lignes.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
14. Au labo : créer ta propre autorité de certification
Objectif
Tu vas manipuler empreintes et chiffrement avec OpenSSL, créer une petite AC « Brocéliande », délivrer un certificat à un serveur web, puis faire accepter ce certificat par le navigateur de Windows 11 en installant la racine dans son magasin de confiance.
Client : PowerShell, magasin de certificats, navigateur
même pool, même réseau que la Debian
Ce que tu fais dans ce TP
Des empreintes SHA-256 calculées sur Debian et sur Windows, puis comparées.
Un fichier chiffré en AES-256, déchiffré avec le bon puis le mauvais mot de passe.
Une AC racine et un certificat serveur avec SAN, signé par cette AC.
Un site en HTTPS accepté par le navigateur une fois la racine installée.
Dans ce TP, le serveur s'appelle intranet.bl.lab. Remplace 192.168.X.Y par l'adresse de ta Debian (ip -br a). Il n'y a pas de DNS : tu ajouteras ce nom dans le fichier hosts de Windows.
PS> [IO.File]::WriteAllText("$PWD\planning.txt", "Planning des tournées - semaine 42`r`n") # UTF-8 sans BOM, fin de ligne Windows (CRLF) ; marche dans Windows PowerShell 5.1 comme dans PowerShell 7 PS> Get-FileHash .\planning.txt -Algorithm SHA256
Les deux empreintes sont-elles identiques ? Si non, cherche pourquoi (fin de ligne CRLF sous Windows, LF sous Linux) : c'est la preuve qu'un seul octet différent change tout.
2 Chiffrer et déchiffrer un fichier en AES
Debian 13 terminal
$ openssl enc -aes-256-cbc -pbkdf2 -salt -in planning.txt -out planning.enc # mot de passe demandé $ cat planning.enc # illisible $ openssl enc -d -aes-256-cbc -pbkdf2 -in planning.enc -out clair.txt # bon mot de passe $ diff planning.txt clair.txt && echo identiques $ openssl enc -d -aes-256-cbc -pbkdf2 -in planning.enc -out faux.txt # mauvais mot de passe : « bad decrypt »
Note dans ton compte rendu : quel est le type de chiffrement utilisé ? Que fait l'option -pbkdf2 ? Comment transmettrais-tu ce mot de passe au destinataire de manière sûre ?
6 Observer l'erreur, puis installer la racine sur Windows
Sur Windows 11, en PowerShell administrateur, ajoute le nom : Add-Content C:\Windows\System32\drivers\etc\hosts "192.168.X.Y intranet.bl.lab intranet".
Ouvre https://intranet.bl.lab dans Edge : note le message d'erreur exact et explique-le.
Copie ac.crt sur Windows (dossier partagé, scp ou clé USB virtuelle), puis importe-le dans le magasin des autorités racines de confiance de l'ordinateur :
Ferme et rouvre Edge, recharge la page : le cadenas apparaît. Clique dessus, affiche le certificat et relève : émetteur, dates, SAN, chemin de certification, algorithme de la clé.
Teste https://intranet puis https://192.168.X.Y : lequel déclenche une erreur, et pourquoi ?
Compare avec le certificat d'un site public (par exemple https://www.cnil.fr) : nombre de niveaux de la chaîne, nom de l'AC, durée de validité.
Une racine installée sur un poste lui fait accepter tout certificat signé par cette AC, pour n'importe quel site. Supprime ta racine de TP à la fin (certlm.msc, Autorités de certification racines de confiance) et ne laisse jamais traîner ac.key. En entreprise, c'est une GPO qui déploie la racine de l'AC interne.
7 Valider le TP : le cahier de recette
N°
Test
Commande ou action
Résultat attendu
OK
1
L'empreinte détecte une modification
sha256sum / Get-FileHash
Empreintes différentes pour un caractère changé ; écart CRLF/LF expliqué
2
Le chiffrement AES fonctionne
openssl enc -d …
Bon mot de passe : fichier identique ; mauvais : « bad decrypt »