Le chiffrement de disque, vraiment ?

Un douanier inspecte un laptop saisi en zone de contrôle. Le propriétaire, interrogé dans la pièce voisine, a dit “la machine est chiffrée”. Le douanier branche le laptop sur une station d’extraction forensique. La machine est en veille. FileVault est actif. Et les clés de chiffrement sont en RAM, disponibles, prêtes à être lues. Le disque est déchiffré à chaud en moins de trois minutes. Le propriétaire avait raison — le disque est bien chiffré. Le chiffrement ne le protège pas pour autant.

Le piège habituel

“Mon disque est chiffré” est l’une des phrases les plus mal comprises en sécurité informatique. Elle signifie presque toujours “j’ai activé BitLocker” ou “FileVault est coché dans les préférences”. Ce n’est pas la même chose que “mes données sont protégées en ce moment même”.

Le chiffrement de disque protège vos données dans un état précis : quand la machine est éteinte. Dès qu’elle est allumée et que l’utilisateur est connecté, le chiffrement n’existe plus en pratique — le système d’exploitation a chargé les clés en mémoire, et tout fichier sur le disque est accessible comme si le chiffrement n’existait pas. La question pertinente n’est pas “est-ce que c’est chiffré ?” mais “dans quel état est ma machine en ce moment ?”

Quand le chiffrement protège — et quand il ne protège pas

Les états où vous êtes protégé

Machine éteinte (cold state) : c’est le seul état où le chiffrement protège de manière fiable. Le disque contient des données chiffrées, la clé n’est nulle part en mémoire, l’attaquant qui vole le disque ou la machine ne peut rien lire sans le mot de passe ou la clé de récupération.

Machine en hibernation (sur certaines configs) : l’hibernation écrit le contenu de la RAM sur le disque chiffré, puis coupe l’alimentation. Si bien configurée, c’est presque aussi bon qu’un arrêt complet. Sur Windows avec BitLocker + PIN actif, l’hibernation protège bien. Sur macOS avec Apple Silicon, la “safe sleep” est chiffrée et les clés sont verrouillées par le Secure Enclave.

Les états où vous n’êtes PAS protégé

Machine en veille simple (sleep/suspend) : la RAM est maintenue sous tension. Les clés de chiffrement sont en RAM. Un attaquant avec accès physique peut extraire ces clés — et donc déchiffrer le disque — sans connaître votre mot de passe. C’est l’état le plus dangereux parce que c’est l’état habituel des laptops quand on ferme le couvercle.

Machine allumée, utilisateur connecté : chiffrement inopérant pour les fichiers montés. Toute donnée accessible par votre session est accessible à l’attaquant qui a accès à la machine.

Machine allumée, écran verrouillé : similaire au cas précédent. L’écran est verrouillé, mais les volumes sont montés et déchiffrés. Un attaquant avec accès physique peut bypasser l’écran de verrouillage via des vecteurs qui ne touchent pas le chiffrement du tout.

Cold boot attacks : la RAM se souvient

L’étude de Princeton publiée en 2008 a démontré que la DRAM conserve son contenu pendant plusieurs secondes à plusieurs minutes après une coupure d’alimentation — surtout si la mémoire est refroidie. Un attaquant peut couper l’alimentation, retirer les barrettes RAM, les refroidir à l’azote liquide ou simplement à l’air froid, et lire les clés de chiffrement qui étaient en mémoire.

Ce vecteur est moins trivial sur les machines modernes avec UEFI Secure Boot, TPM 2.0 et mémoire soudée directement sur la carte mère (comme sur la majorité des ultrabooks récents). Mais le concept reste valide contre des adversaires très motivés — et certaines configs d’entreprise avec de vieilles workstations restent vulnérables. Contre une menace étatique ou un acteur capable d’investir du temps et du matériel, un arrêt complet reste la seule réponse fiable.

Par OS : ce qui est réellement implémenté

macOS — FileVault 2

FileVault 2 utilise XTS-AES-128 sur les volumes APFS. Depuis les Mac avec puce T2 (Intel haut de gamme à partir de 2018) et tous les Apple Silicon (M1 et suivants), les clés matérielles sont gérées par le Secure Enclave et ne transitent jamais en RAM de manière exposée.

Ce que ça change sur Apple Silicon : quand vous fermez le couvercle d’un MacBook M-series, le Secure Enclave verrouille réellement les clés de déchiffrement. Le démarrage rapide est possible non pas parce que les clés restent en RAM, mais parce qu’elles sont réacquises du Secure Enclave lors du déverrouillage. C’est architecturalement bien plus solide que les implémentations Intel pré-T2.

Hibernation vs veille sur Intel : le comportement dépend de la configuration pmset. Par défaut, macOS utilise “safe sleep” — il écrit la RAM sur disque avant d’entrer en veille profonde. Sur les Mac Intel récents avec T2, cette image est chiffrée. Sur les modèles plus anciens, la protection est moindre.

Recovery key et iCloud : lors de l’activation de FileVault, macOS propose de stocker la recovery key dans iCloud. Si vous acceptez, votre protection de chiffrement est liée à votre compte Apple. Si ce compte est compromis, la recovery key l’est aussi. Pour un usage personnel courant, c’est un compromis acceptable. Pour un profil exposé, non.

Windows — BitLocker

BitLocker supporte plusieurs modes de protection, et c’est précisément là que la majorité des déploiements se plantent.

Mode TPM seul (défaut dans beaucoup d’entreprises) : la clé de déchiffrement est dérivée du TPM 2.0 au démarrage. Si les mesures PCR (état du BIOS, boot loader, configuration) correspondent aux valeurs enregistrées, le disque se déchiffre automatiquement — sans aucune interaction utilisateur. C’est pratique pour les grands parcs informatiques. C’est aussi problématique : un attaquant qui a accès à la machine allumée, ou qui peut booter dans un environnement PE Windows trusté, peut accéder aux données.

Mode TPM + PIN (fortement recommandé) : vous entrez un PIN avant le chargement de l’OS. La clé est dérivée conjointement du TPM et du PIN. Bien meilleur. Activable via GPO (Require additional authentication at startup) ou en ligne de commande : manage-bde -protectors -add C: -TPMAndPIN.

Recovery key en entreprise : dans un déploiement managé, les recovery keys sont souvent remontées dans Active Directory ou Azure AD — c’est la bonne pratique. Dans un contexte personnel, beaucoup d’utilisateurs les sauvegardent dans leur compte Microsoft, parfois sans s’en rendre compte (Windows le propose par défaut).

Linux — LUKS / dm-crypt

LUKS (Linux Unified Key Setup) est la couche standard de chiffrement sous Linux. dm-crypt est le module kernel sous-jacent. C’est la solution la plus transparente des trois.

Avantage clé : pas de dépendance TPM par défaut, pas d‘“auto-unlock” silencieux. La protection repose sur la passphrase entrée au boot. Ce que vous tapez est ce qui protège — point.

LUKS2 est le format par défaut sur les distros modernes (Ubuntu 20.04+, Fedora 33+). Il utilise Argon2id comme KDF (résistant aux attaques GPU et ASIC, contrairement à PBKDF2), supporte plusieurs keyslots, et s’intègre avec Clevis/Tang pour l’unlock automatique dans des environnements réseau contrôlés.

Points à vérifier : si votre système utilise un swap non chiffré, des clés peuvent fuir dans l’espace de swap. Vérifiez que lsblk -f montre votre partition swap comme crypto_LUKS ou que le swap est désactivé. Sur les configs avec LVM-on-LUKS (tout le groupe LVM dans un conteneur LUKS), le swap est protégé automatiquement.

Les recovery keys : la pire erreur de déploiement

La recovery key est le plan B quand vous oubliez votre mot de passe ou quand le TPM change d’état (mise à jour BIOS, changement de config). Elle donne un accès complet au disque sans autre vérification. C’est aussi une clé maîtresse que beaucoup de gens stockent de façon catastrophique.

Ce qu’on voit en pratique :

• Recovery key FileVault sauvegardée dans iCloud, sur la même machine qu’elle est censée protéger
• Recovery key BitLocker dans le compte Microsoft personnel, protégé par un mot de passe faible et sans MFA
• Recovery key dans un fichier texte sur le bureau du laptop concerné
• Recovery key dans un email “envoyé à moi-même” qui traine dans Gmail depuis 3 ans

Ce qu’il faut faire :

Option 1 — Copie papier dans un coffre physique : pas de copie numérique, pas de cloud. Un coffre à domicile ou chez un notaire. Lent à accéder, impossible à pirater à distance.

Option 2 — Gestionnaire de mots de passe chiffré, hors appareil : si vous devez avoir une copie numérique, dans un gestionnaire avec MFA fort — et explicitement sur un appareil différent de celui qu’il protège. Votre recovery key BitLocker ne doit pas être dans Bitwarden installé sur le même laptop.

Pour les entreprises : solution MDM (Intune pour Windows, Jamf pour macOS) avec escrow des clés dans un vault audit-logué. L’accès à la recovery key doit déclencher une alerte et être loggué. Jamais dans un tableur partagé, jamais dans un doc Confluence en accès libre.

Vérifier que c’est réellement actif

Ne pas supposer — vérifier. Sur les machines reprises, migrées ou re-provisionnées, le chiffrement peut être désactivé sans que personne ne s’en soit aperçu.

macOS : Réglages Système → Confidentialité et sécurité → FileVault. En terminal : sudo fdesetup status. Doit indiquer FileVault is On.

Windows : Panneau de configuration → Chiffrement de lecteur BitLocker. En PowerShell : Get-BitLockerVolume -MountPoint C:. Le champ ProtectionStatus doit indiquer On et KeyProtector doit lister votre méthode de protection (TPMAndPIN ou similaire).

Linux : sudo cryptsetup luksDump /dev/sdaX pour les détails du volume. lsblk -f pour voir la hiérarchie des volumes montés. dmsetup status pour l’état des volumes dm-crypt actifs.

Erreurs fréquentes qu’on voit systématiquement

BitLocker sans PIN : déploiement enterprise par défaut dans beaucoup d’organisations. La machine déchiffre automatiquement. La sécurité n’est que contre le vol de disque nu, pas contre un attaquant avec accès physique à la machine.

FileVault avec recovery key dans iCloud sur le même appareil : si quelqu’un accède à votre session iCloud, il a la recovery key. Si votre Apple ID est phishé ou compromis, vous avez perdu la protection de votre disque.

Machine en veille avant passage en douane : fermer le couvercle, “ça met en veille, c’est chiffré”. Non. Arrêt complet avant toute situation à risque — frontière, hôtel, conférence.

Ne pas vérifier que c’est actif : assumer que le chiffrement est actif parce qu’il l’était il y a six mois. Vérifiez après chaque migration, réinstallation ou reprise de machine.

• N1 Vérifier que FileVault ou BitLocker est actif et en état 'Protection activée'
• N1 Identifier le mode de veille actuel (sleep vs hibernate vs shutdown) et ses implications
• N1 Stocker la recovery key dans un endroit distinct de l'appareil qu'elle protège
• N2 Activer l'hibernation automatique à la fermeture du couvercle pour les déplacements
• N2 Passer à BitLocker avec PIN ou LUKS avec passphrase (sortir du mode TPM seul)
• N2 Vérifier l'état du swap chiffré sur Linux (lsblk -f)
• N2 Déplacer la recovery key vers un stockage offline (coffre, gestionnaire chiffré hors appareil)
• N3 Arrêt complet systématique avant passage en frontière ou zone à risque élevé
• N3 Pour profils très exposés : LUKS avec passphrase forte, pas de TPM auto-unlock
• N3 Audit des recovery keys entreprise : emplacement, accès loggués, rotation annuelle