Volumes chiffrés : BitLocker, FileVault et VeraCrypt

Le chiffrement des volumes et des conteneurs est désormais activé par défaut sur de nombreux ordinateurs portables. Cette leçon explique comment reconnaître les volumes BitLocker, FileVault, LUKS et VeraCrypt dans une image ou une collecte de triage, comment s'organisent les couches de clés de BitLocker, quelles sources de clés et possibilités d'accès sur un système en cours d'exécution sont accessibles légalement, et comment rendre compte de ce qui n'a pas pu être examiné. La recherche de mots de passe par essais constitue un processus distinct, soumis à une autorisation spécifique, et n'est pas abordée ici.

Obstacle ou anti-forensique ?

Le chiffrement est généralement légitime : protection de la vie privée, politiques de protection des données et systèmes d'exploitation qui l'activent automatiquement. Considérez-le d'abord comme un obstacle. Il ne constitue un acte anti-forensique que lorsque le contexte étaye cette interprétation, par exemple un conteneur dissimulé sous un nom trompeur, créé ou utilisé au moment de l'incident, ou un logiciel exécuté puis supprimé. Présentez cette déduction séparément du constat technique.

Reconnaître les volumes chiffrés

BitLocker

Un volume BitLocker conserve un en-tête de volume non chiffré dont l'identifiant OEM, à l'offset 3, est la chaîne de 8 octets -FVE-FS-, là où un volume NTFS affiche NTFS suivi de quatre espaces. Le volume contient également trois copies du bloc de métadonnées FVE (Full Volume Encryption), chacune commençant aussi par -FVE-FS- ; elles consignent la méthode de chiffrement, les protecteurs de clé et les clés enveloppées. Windows 10 version 1511 a introduit XTS-AES ; les versions antérieures utilisaient AES-CBC. Sur les lecteurs amovibles, les volumes BitLocker To Go qui étaient formatés en FAT peuvent présenter un en-tête de type FAT32 avec l'identifiant OEM MSWIN4.1 ; une recherche de -FVE-FS- dans le volume permet donc toujours de trouver les blocs de métadonnées.

Sur un système en cours d'exécution, manage-bde -status indique, pour chaque volume, l'état de la conversion, le pourcentage chiffré, la méthode de chiffrement, l'état de la protection, l'état du verrouillage et les protecteurs de clé. Le canal du journal d'événements Microsoft-Windows-BitLocker/BitLocker Management (fichier Microsoft-Windows-BitLocker%4BitLocker Management.evtx) enregistre des événements tels que le démarrage du chiffrement, l'ajout ou la suppression de protecteurs et la sauvegarde des informations de récupération. Les identifiants d'événement diffèrent selon les versions de Windows ; filtrez donc par canal et lisez le texte du message.

FileVault

Sur un Mac, FileVault protège le volume de données APFS. Un superbloc de volume APFS dépourvu de l'indicateur APFS_FS_UNENCRYPTED (0x1 dans apfs_fs_flags) correspond à un volume chiffré. Sur les Mac dotés d'une puce T2 ou Apple silicon, cela est vrai pour chaque volume interne, même lorsque FileVault est désactivé ; cet indicateur ne suffit donc pas à montrer que FileVault est activé. Comme l'expliquait la leçon 1.7, les Mac dotés d'une puce T2 ou Apple silicon chiffrent toujours le stockage interne au niveau matériel ; FileVault ajoute l'exigence d'utiliser les informations d'identification d'un utilisateur pour déverrouiller la clé. Sur un système en cours d'exécution, fdesetup status indique « FileVault est activé. »

LUKS

Linux Unified Key Setup commence par la signature de 6 octets LUKS\xba\xbe (4C 55 4B 53 BA BE) à l'offset 0, suivie d'un numéro de version sur 2 octets : 1 ou 2. LUKS1 possède un en-tête binaire de 592 octets avec huit emplacements de clé et utilise PBKDF2. LUKS2 possède un en-tête binaire de 4 096 octets suivi de métadonnées JSON, une seconde copie de l'en-tête dont la signature est SKUL\xba\xbe, jusqu'à 32 emplacements de clé et utilise généralement Argon2id par défaut. Chaque emplacement de clé contient la clé du volume chiffrée au moyen d'une phrase secrète ou d'un fichier de clé.

VeraCrypt et TrueCrypt

VeraCrypt, le successeur de TrueCrypt (abandonné en 2014), n'écrit aucune signature en clair. L'en-tête commence par un sel aléatoire de 64 octets ; la signature VERA (ou TRUE) n'apparaît qu'après le déchiffrement de l'en-tête avec le bon mot de passe. Un fichier conteneur ou une partition ressemble donc à des données aléatoires. Les indicateurs sont les suivants :

• une entropie de Shannon proche du maximum de 8 bits/octet, sur l'ensemble de l'objet ;
• une taille multiple de 512 octets ;
• aucune signature de fichier reconnaissable, souvent avec une extension ou un nom suggérant autre chose.

Ce sont des indicateurs, pas des preuves : l'espace effacé de manière sécurisée (leçon 7.1), les données de test aléatoires et d'autres outils de chiffrement présentent le même aspect. Les fichiers compressés ont également une entropie élevée, mais comportent des en-têtes tels que PK ou 7z. Le chiffrement du système est plus facile à repérer, car le chargeur de démarrage VeraCrypt remplace le chargeur normal (sur les systèmes UEFI, sous \EFI\VeraCrypt\ sur la partition système EFI).

Un volume caché VeraCrypt se trouve dans l'espace libre d'un volume externe, rempli de données aléatoires ; sa présence ne peut donc être ni prouvée ni exclue à partir du seul conteneur. Seuls d'autres artefacts, tels que des fichiers LNK pointant vers des chemins qui n'existent pas dans le volume externe ouvert, peuvent étayer cette affirmation. Ne vous prononcez jamais dans un sens ou dans l'autre sans de tels éléments probants.

Artefacts logiciels

Lorsque le conteneur ne peut pas être identifié directement, l'utilisation du logiciel peut l'être. Recherchez les fichiers Prefetch de VERACRYPT.EXE et de VERACRYPT FORMAT.EXE, les entrées Amcache et BAM (leçon 2.3), ainsi que le pilote %windir%\System32\drivers\veracrypt.sys (absent en mode portable). %APPDATA%\VeraCrypt\ (en mode portable, le dossier contenant VeraCrypt.exe) contient Configuration.xml (préférences, dont les paramètres de démontage automatique) et, uniquement si ces fonctionnalités ont été utilisées, Favorite Volumes.xml (volumes enregistrés et lettres de lecteur associées) et History.xml (les 20 derniers chemins de volume ; l'option « Ne jamais enregistrer l'historique » est activée par défaut). Les volumes montés peuvent laisser des traces de lettres de lecteur : une valeur \DosDevices\Z: dans MountedDevices dont les données ne correspondent à aucun disque connu, ainsi que des fichiers LNK et des listes de raccourcis (leçon 2.4) dont le numéro de série du volume cible ne correspond à aucun volume connu.

Architecture des clés BitLocker

BitLocker utilise trois couches. Les secteurs sont chiffrés avec la FVEK (clé de chiffrement intégral du volume). La FVEK est stockée dans les métadonnées, chiffrée avec la VMK (clé principale du volume). La VMK est stockée plusieurs fois, enveloppée une fois par chaque protecteur de clé. L'ajout ou la suppression d'un protecteur ne fait qu'ajouter ou supprimer une copie enveloppée de la VMK ; les données ne sont pas rechiffrées.

Les protecteurs comprennent TPM seul (le module de plateforme sécurisée libère la VMK si la chaîne de démarrage mesurée est inchangée), TPM + code PIN, TPM + clé de démarrage, un mot de passe (courant pour les lecteurs de données et les lecteurs amovibles), un fichier de clé de démarrage ou de récupération (.BEK), le mot de passe de récupération et le déverrouillage automatique (un lecteur de données ouvert automatiquement une fois le volume du système d'exploitation déverrouillé). Chaque protecteur possède un identifiant de clé de type GUID ; l'écran de récupération en affiche le début, ce qui permet d'associer un mot de passe récupéré au bon volume.

Le mot de passe de récupération comporte 48 chiffres répartis en huit groupes de six. Chaque groupe encode 16 bits multipliés par 11 ; chaque groupe valide est donc divisible par 11 et vaut au maximum 65 535 × 11 = 720 885 ; les huit groupes fournissent la clé de 128 bits. Il s'agit d'une vérification du format, et non d'une preuve qu'une valeur appartient à un volume.

Un mot de passe de récupération peut légitimement être stocké dans :

• le compte Microsoft de l'utilisateur, sur sa page de clés de récupération ;
• Active Directory, sous forme d'objets msFVE-RecoveryInformation sous l'objet ordinateur (attribut msFVE-RecoveryPassword), ou Entra ID, dans l'objet appareil ;
• les bases de données de gestion MBAM ou Intune ;
• un document imprimé, un fichier texte ou une clé USB, enregistrés par l'utilisateur.

De nombreux appareils Windows 11 activent automatiquement le chiffrement de l'appareil et sauvegardent la clé dans le compte Microsoft ou le compte professionnel lors de la connexion. Si BitLocker est suspendu, la VMK est stockée avec une « clé en clair » non chiffrée : le volume reste chiffré, mais tout outil compatible peut le lire.

Voies d'accès légales

• Le système en cours d'exécution et déverrouillé. Capturez la mémoire, puis réalisez une image logique du volume déverrouillé (une image physique ne copie que les données chiffrées). Consignez la sortie de manage-bde -status et de manage-bde -protectors -get C:, qui énumère l'identifiant de chaque protecteur et, lorsque la commande est exécutée en tant qu'administrateur, le mot de passe de récupération numérique.
• Les clés en mémoire. Tant qu'un volume est déverrouillé ou monté, la FVEK ou la clé principale VeraCrypt se trouve en RAM (sauf si le chiffrement facultatif de la RAM de VeraCrypt, disponible depuis la version 1.24 et désactivé par défaut, a été activé ; Configuration.xml l'indique). Les outils d'analyse mémoire, notamment les extensions communautaires de Volatility et les suites commerciales, peuvent les localiser, et des bibliothèques BitLocker open source peuvent ensuite déchiffrer une image avec la clé récupérée. Les fichiers d'hibernation et les vidages mémoire après incident peuvent également les contenir (leçon 5.4), mais, sur un volume C: chiffré, ils ne sont accessibles qu'après le déverrouillage de C:.
• TPM seul sur la machine d'origine. Le démarrage de l'ordinateur d'origine déverrouille le volume sans secret, même si la connexion Windows protège toujours la session. Un lecteur retiré de cette machine nécessite un mot de passe de récupération.
• Les clés en séquestre. Demandez les mots de passe de récupération à l'organisation ou au fournisseur dans le cadre d'une procédure légale, en indiquant l'identifiant de clé.
• Le propriétaire. Il est possible de demander un mot de passe ; le cadre juridique varie selon les pays.
• FileVault : un mot de passe utilisateur, la clé de récupération personnelle (24 caractères en six groupes de quatre), une clé de récupération institutionnelle ou un dépôt en séquestre MDM, ou le Mac en cours d'exécution et déverrouillé.
• VeraCrypt et LUKS : le mot de passe ou le fichier de clé, ou la clé en mémoire pendant que le volume est monté ; réalisez une image du volume mappé tant qu'il est ouvert.

Le temps est déterminant. Un volume monté n'est plus accessible après l'arrêt, et VeraCrypt peut être configuré pour le démonter lors de la déconnexion, du verrouillage de session, de l'activation de l'écran de veille, du passage en mode d'économie d'énergie ou après une période sans lectures ni écritures. Les décisions de triage (leçon 5.1) déterminent souvent si les données chiffrées pourront un jour être lues.

Exemple détaillé : un ordinateur portable en veille

Un ordinateur portable Windows 11 est saisi en veille, avec l'écran verrouillé. Le triage révèle BitLocker avec un protecteur TPM seul sur C: et, sur D:, un fichier D:\backup\photos.bin sans en-tête connu. Le système contient des fichiers Prefetch de VeraCrypt et un fichier LNK pointant vers Z:\clients\list.xlsx sur un volume dont le numéro de série n'apparaît nulle part ailleurs.

Séquence. Branchez le chargeur, photographiez l'écran et empêchez l'hibernation. L'acquisition sur un système en cours d'exécution nécessite une session authentifiée ; obtenez donc légalement les informations d'identification auprès du propriétaire ou de l'organisation. Ensuite :

1. La mémoire d'abord. Elle peut contenir la clé principale VeraCrypt et la FVEK de BitLocker.
2. Z: ensuite, s'il est encore monté. Photographiez la fenêtre VeraCrypt, qui affiche le chemin du fichier monté et le type de volume, puis réalisez une image logique de Z:. Ces données ne disposent d'aucune autre voie d'accès, et un démontage pour inactivité pourrait en fermer l'accès pendant que vous travaillez sur C:.
3. C: en dernier. Consignez la sortie de manage-bde -status et les identifiants des protecteurs, puis réalisez une image logique de C:. C: dispose de solutions de repli : le TPM de la machine d'origine et tout mot de passe de récupération déposé en séquestre.

Le fichier. Sa taille est de 4 294 967 296 octets = 4 GiB = 2^32 octets = 8 388 608 × 512, soit un multiple exact de 512. Son entropie, moyennée sur des blocs de 1 MiB, est de 7,9998 bits/octet, ce qui correspond à des données aléatoires pour cette taille de bloc (le biais lié aux petits échantillons la maintient juste en dessous de 8). Compte tenu des éléments attestant l'exécution de VeraCrypt, la formulation correcte est : photos.bin présente des caractéristiques compatibles avec un conteneur chiffré, tel qu'un fichier conteneur VeraCrypt ; cela n'est pas prouvé. S'il est ensuite ouvert légalement et que le numéro de série du volume de son système de fichiers correspond à celui du fichier LNK, cela le relie à Z:.

Vérification du mot de passe de récupération. Un exemple valide construit pour cette leçon est 403425-176198-692373-264044-664609-429165-106161-702482. Premier groupe : 403 425 ÷ 11 = 36 675 exactement (11 × 36 675 = 403 425), et 36 675 est inférieur à 65 536. Une erreur de transcription telle que 403 426 donne un reste de 1 et échoue à la vérification.

Rédaction du rapport

Indiquez qu'un volume est chiffré et avec quelle technologie ; comment il a été identifié (signature et offset, métadonnées, mesure de l'entropie et taille des blocs, artefacts logiciels) ; quelles clés ont été recherchées, auprès de quelles sources et avec quel résultat, en incluant les identifiants de clé ; ce qui a été acquis sur le système en cours d'exécution et à quel moment (UTC) ; et ce qui n'a pas pu être examiné. Présentez séparément les déductions relatives à l'intention. ISO/IEC 27037 prévoit que chaque action effectuée sur un système en cours d'exécution soit justifiée et documentée.

Points clés pour l'examen : Attendez-vous à devoir reconnaître BitLocker à partir de -FVE-FS- à l'offset 3, expliquer les couches FVEK, VMK et protecteurs, et valider les groupes d'un mot de passe de récupération par leur divisibilité par 11. Les questions de mise en situation porteront probablement sur l'ordre d'acquisition sur un système en cours d'exécution avec un conteneur monté, ainsi que sur la formulation prudente selon laquelle un fichier à forte entropie sans en-tête présente des caractéristiques compatibles avec un conteneur chiffré, sans en constituer la preuve.

Points essentiels

• BitLocker présente -FVE-FS- à l'offset 3 et dans ses blocs de métadonnées FVE ; LUKS commence par LUKS\xba\xbe ; VeraCrypt n'a aucune signature en clair.
• Une entropie élevée, une taille divisible par 512 et l'absence d'en-tête indiquent un conteneur possible, mais ne le prouvent pas ; la présence de volumes cachés ne peut être ni prouvée ni exclue à partir du seul conteneur.
• Les secteurs sont chiffrés par la FVEK, la FVEK par la VMK, et la VMK par chaque protecteur.
• Un mot de passe de récupération comporte huit groupes de six chiffres, chacun divisible par 11 ; associez-le au volume au moyen de l'identifiant de clé.
• Capturez la mémoire et réalisez des images logiques pendant que les volumes sont déverrouillés, en donnant la priorité à ce qui ne dispose d'aucune autre source de clé.
• Consignez dans le rapport le chiffrement, la manière dont il a été identifié, les sources de clés essayées et ce qui reste non examiné.