Le chiffrement de disque, vraiment ?

J’ai vu un laptop d’entreprise se faire vider en moins de cinq minutes dans une salle de contrôle. La machine était « chiffrée » — l’IT l’avait certifié, le sticker de conformité était collé au dos. Sauf qu’elle était en veille, couvercle fermé, posée dans un sac dans la voiture du dirigeant le temps d’un déjeuner. Les clés étaient en RAM, la session ouverte. La personne qui a récupéré le sac n’a pas eu à connaître le mot de passe. Elle a branché un boîtier, contourné l’écran de verrouillage, et copié ce qu’elle voulait. Le disque était chiffré. Les données, non.

Le piège habituel

« Mon disque est chiffré. » C’est l’une des phrases les plus mal comprises de toute la sécurité informatique. Elle veut dire, dans 95 % des cas, « j’ai coché une case dans les réglages » ou « l’IT a activé BitLockerSolution Microsoft de chiffrement de disque intégrée à Windows Pro/Enterprise.Voir le lexique au déploiement ». Elle ne veut pas dire « mes données sont protégées en ce moment ». Ce sont deux affirmations différentes, et la confusion entre les deux est exactement ce sur quoi compte un attaquant avec accès physique.

Le chiffrement de disque protège vos données dans un état précis et unique : quand la machine est éteinte. C’est tout. Dès que le système est démarré et que vous êtes connecté, les clés de déchiffrement sont chargées en mémoire vive et tout fichier devient lisible comme si le chiffrement n’existait pas. Le système d’exploitation déchiffre à la volée, en continu, de manière totalement transparente — c’est précisément le but : que vous ne sentiez aucune différence à l’usage. Mais cette transparence pour vous est aussi une transparence pour quiconque met la main sur la machine dans cet état.

La bonne question n’est donc jamais « est-ce que c’est chiffré ? ». C’est « dans quel état est ma machine au moment où un tiers peut y accéder ? ». Éteinte, en veille, en hibernation, écran verrouillé : ces quatre états offrent des niveaux de protection radicalement différents avec exactement le même chiffrement activé. Le discours dominant — « activez le chiffrement et vous êtes tranquille » — escamote toute cette nuance. Et c’est dans cette nuance escamotée que se logent la quasi-totalité des extractions de données réussies sur du matériel pourtant « chiffré ».

L’autre moitié du piège, c’est de croire que le chiffrement défend contre des menaces qu’il n’a jamais eu vocation à couvrir. Le chiffrement de disque ne fait rien contre un malware qui tourne dans votre session : le programme malveillant lit vos fichiers déchiffrés exactement comme vous. Il ne fait rien contre le phishing, contre un vol de mot de passe, contre un accès distant à votre machine allumée, contre une sauvegarde cloud mal protégée. Il ne protège pas non plus vos données une fois qu’elles ont quitté le disque — pièce jointe envoyée, fichier copié sur une clé USB, document ouvert dans une application qui synchronise. Le chiffrement de disque répond à une seule question, étroite mais réelle : « quelqu’un récupère mon matériel physiquement, que peut-il en tirer ? ». Confondre cette protection ponctuelle avec une protection générale, c’est croire qu’une serrure de porte vous protège alors que la fenêtre est ouverte.

Les quatre états : quand ça protège, quand ça ne protège pas

Le même chiffrement, activé une seule fois, vous protège complètement ou pas du tout selon l’état de la machine. Voici les quatre, du plus sûr au plus exposé.

Machine éteinte (cold state). Le seul état où le chiffrement fait son travail intégralement. Le disque ne contient que des données chiffrées, la clé n’est nulle part en mémoire, et quiconque vole le disque ou la machine ne lit rien sans la passphrase ou la clé de récupération. C’est le scénario pour lequel le chiffrement de disque a été conçu : le vol de matériel hors tension. Dans ce cas précis, FileVaultChiffrement de disque intégré à macOS depuis OS X Lion.Voir le lexique, BitLocker et LUKSStandard de chiffrement de disque sur Linux, généralement via cryptsetup et dm-crypt.Voir le lexique tiennent leurs promesses.

Machine en hibernation. L’hibernation écrit le contenu de la RAM sur le disque chiffré, puis coupe l’alimentation. Bien configurée, c’est presque aussi solide qu’un arrêt complet, parce que la mémoire vive est vidée et chiffrée sur disque. Sur Windows avec BitLocker et PIN, l’hibernation protège correctement. Sur les Mac Apple Silicon, la veille profonde verrouille les clés dans le Secure Enclave. Le piège : beaucoup de machines sont configurées pour ne jamais hiberner et rester en veille simple indéfiniment.

Machine en veille (sleep / suspend). L’état par défaut quand vous fermez le couvercle. La RAM est maintenue sous tension, donc les clés de déchiffrement y sont présentes, en clair. Un attaquant avec accès physique peut les extraire — par forensicsDiscipline qui analyse les traces numériques après un incident pour reconstituer ce qui s'est passé.Voir le lexique mémoire, par attaque DMAPuce cryptographique soudée à la carte mère qui stocke les clés et atteste l'intégrité du boot.Voir le lexique sur un port Thunderbolt mal verrouillé, ou par cold boot — et déchiffrer le disque sans jamais connaître votre mot de passe. C’est l’état le plus dangereux précisément parce que c’est l’état dans lequel votre laptop passe l’essentiel de sa vie.

Machine allumée, écran verrouillé. Les volumes sont montés et déchiffrés. L’écran de verrouillage est une porte logicielle devant un disque déjà ouvert. Le contournement de cet écran ne touche pas au chiffrement du tout — il s’attaque au système d’authentification de session, qui a sa propre surface d’attaque (comptes locaux, exploits de l’écran de login, ports de debug). Le chiffrement, ici, ne joue aucun rôle protecteur.

La conséquence pratique est brutale et contre-intuitive : la machine que vous croyez « protégée parce que chiffrée et verrouillée » dans votre sac, en réunion, à l’hôtel, est dans l’état le moins protégé qui soit. Fermer le couvercle ne sécurise rien. Seul l’arrêt complet ramène la machine dans le cold state.

Mettez-vous à la place de l’attaquant deux minutes, c’est le seul moyen de comprendre pourquoi l’état compte plus que le chiffrement. Vous récupérez un laptop dans un sac. Première chose que vous faites : vous regardez s’il est chaud, si la LED clignote, si un écran s’allume quand vous bougez la souris. Une machine tiède en veille est un cadeau. Vous la branchez sur secteur pour qu’elle ne s’éteigne pas, vous la posez sur une station d’analyse, et vous travaillez sur une cible dont les clés sont déjà en mémoire. Le mot de passe de session ne vous intéresse même pas. À l’inverse, une machine froide et éteinte vous laisse face à un bloc chiffré : vous pouvez la garder des mois, lancer du brute-force, ça ne donnera rien si la passphrase est correcte. C’est exactement cette asymétrie que la plupart des gens annulent en fermant simplement le couvercle au lieu d’éteindre.

Le modèle de menace correct n’est donc pas « est-ce que je risque le vol de mon SSD nu ? » — scénario rare, qui suppose qu’on dévisse votre machine — mais « dans quelles situations ma machine quitte-t-elle mon contrôle, et dans quel état est-elle à ce moment ? ». Réponse honnête pour la plupart des gens : en réunion (verrouillée, montée), dans un train (veille), à l’hôtel pendant le petit-déjeuner (veille), confiée à un réparateur (allumée ou en veille), saisie à une frontière (selon votre discipline). Dans presque tous ces cas, la veille ou le verrouillage dominent, et le chiffrement ne joue aucun rôle protecteur réel.

Par OS : ce qui est réellement implémenté, et où ça casse

Les trois systèmes chiffrent. Ce qui les distingue, c’est ce qui se passe au démarrage et au déverrouillage — et c’est là que se jouent les vraies différences de protection.

macOS — FileVault 2. Chiffrement XTS-AES-128 sur les volumes APFS. Sur les Mac avec puce T2 (Intel haut de gamme depuis 2018) et tous les Apple Silicon, les clés matérielles sont gérées par le Secure Enclave et ne transitent jamais en RAM de façon exposée. Concrètement, sur un MacBook M-series, fermer le couvercle déclenche un vrai verrouillage des clés par le Secure Enclave ; le redémarrage rapide vient d’une réacquisition de la clé au déverrouillage, pas d’une clé restée en mémoire. C’est architecturalement bien plus solide que tout ce qui précède la T2.

Détail qui surprend beaucoup d’utilisateurs Mac : sur Apple Silicon, le volume système est en réalité chiffré en permanence au niveau matériel, indépendamment de FileVault. Ce que FileVault ajoute, c’est l’exigence d’un identifiant utilisateur pour libérer la clé au démarrage. Sans FileVault, la clé est dérivable sans mot de passe, et un Mac volé démarre directement sur le bureau d’un compte sans mot de passe. Autrement dit, « le disque est chiffré » est techniquement vrai même FileVault désactivé — et totalement trompeur, parce que sans FileVault le chiffrement ne vous protège de rien. C’est l’exemple parfait de l’écart entre « chiffré » et « protégé ». Le point faible restant n’est pas technique mais organisationnel : à l’activation, macOS propose de stocker la clé de récupération dans iCloud. Si vous acceptez, la protection de votre disque devient aussi forte que votre compte Apple — et pas davantage. Un Apple ID phishé, et la clé suit.

Windows — BitLocker. Le système le plus déployé en entreprise, et celui qui se plante le plus souvent à la configuration. BitLocker peut fonctionner en mode TPMPuce cryptographique soudée à la carte mère qui stocke les clés et atteste l'intégrité du boot.Voir le lexique seul : la clé est dérivée du TPM 2.0 au démarrage et, si les mesures d’intégrité du boot correspondent, le disque se déchiffre tout seul, sans aucune saisie. C’est le défaut commode de beaucoup de grands parcs, parce qu’aucun support n’aime gérer des tickets « j’ai oublié mon PIN ». C’est aussi le trou : une machine volée avec batterie chargée démarre et se déchiffre seule jusqu’à l’écran de login, et certaines attaques (DMA, sniffing du bus entre TPM et CPU sur du matériel non sécurisé) récupèrent la clé sans connaître quoi que ce soit. Des chercheurs ont publiquement extrait des clés BitLocker en écoutant le bus LPC ou SPI entre un TPM discret et le processeur sur des machines bon marché — l’opération demande un fer à souder et quelques dizaines d’euros de matériel, pas un laboratoire d’État.

Le mode TPM + PIN, lui, exige un code avant le chargement de l’OS : la clé est dérivée conjointement du TPM et de ce que vous tapez. Le PIN ne quitte jamais le périmètre du démarrage sécurisé, et sans lui le TPM ne libère rien. C’est la seule configuration BitLocker que je considère comme sérieuse contre le vol de machine. Activation par stratégie de groupe (Require additional authentication at startup) ou en ligne de commande administrateur : manage-bde -protectors -add C: -TPMAndPIN. Une variante encore plus stricte, TPM + PIN + clé USB de démarrage, existe pour les profils très exposés, au prix d’une ergonomie pénible au quotidien.

Linux — LUKS / dm-crypt. La couche standard sous Linux, et la plus transparente conceptuellement : pas de déverrouillage automatique silencieux par défaut, la protection repose sur la passphrase entrée au boot. Ce que vous tapez est ce qui protège, point. LUKS2 (défaut sur Ubuntu 20.04+, Fedora 33+) utilise Argon2id comme fonction de dérivation — résistant aux attaques par GPU et ASIC, contrairement au vieux PBKDF2. Concrètement, Argon2id force l’attaquant à consacrer de la mémoire et du temps à chaque tentative de mot de passe, ce qui rend le brute-force massif sur cartes graphiques économiquement inintéressant ; PBKDF2, lui, se cassait à des cadences industrielles. LUKS gère aussi jusqu’à huit emplacements de clé (keyslots) : vous pouvez avoir une passphrase humaine, une clé de récupération longue stockée hors ligne, et un mécanisme d’unlock réseau (Clevis/Tang) pour les serveurs, chacun dans son slot, révocable indépendamment.

Le piège classique sous Linux n’est pas le chiffrement du disque principal mais ce qui passe à côté : le swap et /boot. Si votre partition d’échange n’est pas chiffrée, des fragments de clés et de données sensibles fuient sur disque en clair — un dump mémoire entier peut y atterrir lors d’une hibernation. La partition /boot, elle, est traditionnellement en clair parce que le bootloader doit la lire avant tout déchiffrement ; un attaquant peut y modifier le noyau ou l’initramfs (attaque dite « evil maid ») pour capturer votre passphrase au prochain démarrage. La configuration LVM-on-LUKS (tout le groupe de volumes, swap compris, dans un conteneur chiffré) règle le problème du swap ; la signature du boot via Secure Boot ou un /boot sur clé USB que vous gardez sur vous adresse l’evil maid. Vérification rapide : lsblk -f doit montrer vos partitions sensibles en crypto_LUKS, pas en ext4 nu.

La bonne approche : configurer pour l’état, pas pour la case

Activer le chiffrement est une décision de cinq minutes qu’on prend une fois. Le rendre réellement protecteur tient à trois réglages qu’on oublie quasi systématiquement.

Premier réglage : le verrou pre-boot. Sur BitLocker, c’est le PIN (mode TPM + PIN). Sur LUKS, c’est la passphrase au boot (déjà le défaut). Sur macOS Apple Silicon, le Secure Enclave joue ce rôle nativement dès que FileVault est actif. Sans ce verrou avant le chargement de l’OS, le chiffrement ne protège que contre le vol du disque nu sorti de la machine — pas contre le vol de la machine entière, qui est pourtant le scénario réaliste. C’est la différence entre « protégé contre quelqu’un qui dévisse mon SSD » et « protégé contre quelqu’un qui part avec mon laptop ».

Deuxième réglage : le comportement de fermeture du couvercle. Forcez l’hibernation ou l’arrêt plutôt que la veille simple pour tout contexte mobile. Sur Windows, l’hibernation après un court délai d’inactivité. Sur Linux, configurez suspend-then-hibernate ou désactivez la veille au profit de l’hibernation. L’objectif : que la machine quitte d’elle-même l’état où les clés vivent en RAM, sans dépendre de votre discipline.

Troisième réglage, le plus saboté : le stockage de la clé de récupération. La clé de récupération donne un accès complet au disque sans autre vérification. C’est une clé maîtresse. La stocker dans iCloud sur la machine qu’elle protège, dans un compte Microsoft sans MFA, dans un fichier texte sur le bureau, ou dans un mail « envoyé à soi-même », c’est annuler le chiffrement par la porte de derrière. La règle est simple : la clé de récupération vit sur un support distinct de l’appareil qu’elle protège. Copie papier dans un coffre, ou gestionnaire de mots de passeApplication qui stocke et génère des mots de passe uniques pour chaque service.Voir le lexique chiffré avec MFA fort installé sur un autre appareil. Jamais sur la machine concernée.

Un dernier point sur la clé de récupération qu’on oublie presque toujours d’expliquer : elle ne sert pas qu’à dépanner un oubli de mot de passe. Sur BitLocker, le TPM mesure l’état du démarrage ; toute mise à jour du firmware, changement dans l’ordre de boot, ou réinitialisation du BIOS modifie ces mesures et déclenche une demande de clé de récupération au prochain allumage. C’est un comportement normal, pas une attaque — mais si la clé n’est nulle part, vous êtes verrouillé hors de votre propre machine après une simple mise à jour Windows un peu agressive. D’où l’importance d’un escrow propre : la clé doit être récupérable par vous, à un endroit que vous contrôlez, et inaccessible à n’importe qui d’autre. Ces deux exigences tirent en sens opposé, et c’est tout l’enjeu de son stockage.

Et avant tout cela : vérifiez que c’est réellement actif. Sur les machines reprises, migrées ou re-provisionnées, le chiffrement se désactive parfois sans que personne ne le remarque — une réinstallation système qui ne ré-active pas FileVault, un volume ajouté non chiffré, un parc hérité d’une acquisition. sudo fdesetup status sur macOS doit afficher FileVault is On. Get-BitLockerVolume -MountPoint C: sur Windows doit montrer ProtectionStatus: On avec un protecteur de type TpmPin — si vous voyez seulement Tpm, vous êtes en mode sans PIN, à corriger. sudo cryptsetup luksDump /dev/sdaX sur Linux confirme le format (LUKS2) et la fonction de dérivation (argon2id). On vérifie, on ne suppose pas — et on revérifie après chaque opération de maintenance lourde.

Ce que ça implique concrètement

Erreurs qu’on voit tout le temps

• BitLocker sans PIN, par défaut au déploiement. La machine se déchiffre toute seule au démarrage. Protection contre le vol de disque nu uniquement, pas contre le vol de la machine.
• Clé de récupération FileVault dans iCloud, sur le Mac qu’elle protège. Compromettre l’Apple ID suffit à récupérer la clé. Le chiffrement devient aussi fort que le mot de passe iCloud.
• Machine mise en veille avant une frontière. « C’est chiffré, je ferme juste le couvercle. » Non : les clés sont en RAM, la fouille à chaud lit le disque. Arrêt complet, toujours.
• Swap non chiffré sous Linux. Le disque principal est en LUKS, le swap est en clair, et des fragments sensibles y atterrissent. Vérifiez avec lsblk -f.
• Supposer sans vérifier. Le chiffrement était actif il y a six mois, donc il l’est aujourd’hui. Faux après toute migration, réinstallation ou reprise de machine.

Checklist actionnable

• N1 Vérifier que FileVault / BitLocker / LUKS est réellement actif (fdesetup status, Get-BitLockerVolume, cryptsetup luksDump)
• N1 Identifier le comportement de fermeture du couvercle actuel : veille, hibernation ou arrêt
• N1 Stocker la clé de récupération sur un support distinct de l'appareil qu'elle protège
• N2 Activer un verrou pre-boot : PIN BitLocker (TPM+PIN), passphrase LUKS, Secure Enclave sur Mac
• N2 Forcer l'hibernation ou l'arrêt à la fermeture du couvercle en mobilité (≤ 5 min)
• N2 Vérifier le chiffrement du swap sous Linux (lsblk -f) ou passer en LVM-on-LUKS
• N2 Décocher le stockage cloud de la clé de récupération pour les profils exposés
• N3 Arrêt complet systématique avant frontière, douane ou zone à interception mature
• N3 Pour profils très exposés : LUKS avec passphrase forte, aucun déverrouillage automatique
• N3 Audit annuel de l'escrow d'entreprise : qui lit les clés, journalisation, MFA hardware sur le vault

Pour aller plus loin

Les implémentations évoluent vite — vérifiez toujours la documentation officielle pour votre version exacte. La documentation FileVault d’Apple(opens in a new tab) détaille le rôle du Secure Enclave selon le matériel, et la documentation BitLocker de Microsoft(opens in a new tab) couvre la configuration TPM + PIN par GPO. Pour Linux, la page du projet cryptsetup(opens in a new tab) reste la référence sur LUKS2 et Argon2id. Et pour comprendre pourquoi l’arrêt complet n’est pas de la paranoïa, le papier de Princeton sur les cold boot attacks(opens in a new tab) reste d’actualité quinze ans après sa publication.