Aller au contenu
← Retour au blog

Chiffrer pagefile.sys : le réglage EncryptPagingFile et ce contre quoi il protège

20/05/2026 · 6 min de lecture

Windows embarque discrètement une fonctionnalité qui chiffre le contenu de pagefile.sys avec une clé éphémère par démarrage. C'est une commande fsutil d'une ligne, le coût à l'exécution est quasi nul, et la plupart des défenseurs ignorent son existence.

Ce billet couvre ce qu'elle fait, ce qu'elle ne fait pas, comment elle interagit avec BitLocker, et — pertinent pour ce site — comment elle affecte l'analyse forensique du pagefile.

Le réglage

fsutil behavior set EncryptPagingFile 1

Après un redémarrage, chaque écriture dans pagefile.sys est chiffrée. Concrètement :

  • Une clé AES 256 bits est générée au démarrage, stockée en mémoire noyau non paginée, et détruite à l'extinction.
  • Le gestionnaire de mémoire fournit les pages à NTFS avec un IV par écriture ; NTFS chiffre chaque page en AES avant qu'elle n'atterrisse sur disque.
  • La clé n'est jamais écrite sur disque, jamais exportée, et irrécupérable — y compris pour l'utilisateur qui a activé le réglage.

Le relire :

fsutil behavior query EncryptPagingFile

0 signifie désactivé, 1 activé. Par défaut, 0 sur la plupart des builds Windows.

Ce contre quoi cela protège

Le modèle de menace est l'accès disque hors-ligne après que le système ait tourné. Scénarios :

  • Un laptop est volé éteint. Une image disque est prise. Sans EncryptPagingFile, le contenu du pagefile de la dernière session est lisible en clair (modulo le comportement normal du journal NTFS). Avec, il est chiffré en AES avec une clé qui n'existe plus.
  • Un disque interne est retiré d'un serveur pendant une maintenance et imagé.
  • Un snapshot de VM est capturé sans la RAM active.

Notez la constante : le système tournait précédemment, puis est éteint, et quelqu'un lit le disque après coup. Le chiffrement protège contre la lecture a posteriori.

Ce contre quoi cela ne protège pas

  • Un système actif acquis. La clé éphémère est en RAM. Un processus avec accès noyau (Wraith, DumpIt, WinPMem, ou simplement un debugger noyau autorisé) peut récupérer la clé et déchiffrer pagefile.sys à la volée.
  • Un fichier d'hibernation (hiberfil.sys). L'hibernation écrit la RAM sur disque ; si EncryptPagingFile était activé, le contenu du pagefile en RAM au moment de l'hibernation avait déjà été chiffré-après-écriture — mais la mémoire applicative vivante ne l'était pas. hiberfil.sys est donc la plus grosse surface de fuite sur un laptop dont le capot se ferme (= hibernation) souvent. Atténuation : BitLocker, qui chiffre le volume sur lequel vit hiberfil.sys.
  • Un dump de crash (MEMORY.DMP). Même situation — contenu RAM, pas chiffré-pagefile.
  • Une partition swap sur Linux en dual-boot. EncryptPagingFile est une fonctionnalité NTFS de Windows uniquement.

Interaction avec BitLocker

BitLocker chiffre le volume entier, ce qui inclut pagefile.sys. Vous pourriez donc vous demander pourquoi EncryptPagingFile par dessus. Le raisonnement :

ScénarioBitLocker seul+ EncryptPagingFile
Disque imagé après arrêt propre❌ protégé✅ doublement protégé
Disque imagé pendant que le système tourne🟡 (TPM descellé)✅ pagefile toujours sûr
Clé de récupération BitLocker compromise🔴 exposé✅ pagefile toujours sûr
MEMORY.DMP extrait du disque🟡🟡 (pas du pagefile)

L'idée clé : EncryptPagingFile survit à une compromission BitLocker parce que sa clé ne touche jamais le disque. Pour les systèmes sensibles, utilisez les deux. Le coût à l'exécution est négligeable (NTFS fait l'AES inline sur du matériel moderne avec AES-NI).

Coût de performance

En pratique, rien de mesurable sur du matériel des 10 dernières années. AES-NI est présent sur tous les CPU depuis Westmere (2010). Le pagefile n'est pas une charge sur le chemin critique pour des systèmes avec assez de RAM.

Si vous voyez une perte de performance mesurable, le vrai problème est que vous paginez trop, pas le chiffrement — corrigez le dimensionnement RAM.

Ce que cela implique pour l'analyse forensique

C'est la partie directement pertinente pour ce site.

Si vous êtes un analyste à qui l'on remet une image disque hors-ligne avec EncryptPagingFile = 1 :

  • Le pagefile est irrécupérable. La clé n'existe plus. Les techniques de carving qu'implémente ce parser échouent toutes — les octets ressemblent à du bruit aléatoire haute entropie.
  • Vous verrez high_entropy dominer l'onglet Page map. C'est la signature de pages correctement chiffrées.
  • Que faire à la place : pivotez vers d'autres sources — un dump RAM si vous en avez un, hiberfil.sys (qui n'est pas chiffré par le pagefile), MEMORY.DMP, le lsass.exe vivant si le système est encore debout, la télémétrie EDR, les journaux de flux réseau.

Si vous avez le système actif, avant de l'éteindre :

  • Acquérez la RAM d'abord. La clé du pagefile y vit.
  • Puis acquérez le pagefile pendant que le noyau est encore debout — vous obtiendrez la vue déchiffrée via une lecture NTFS brute.

Si vous conseillez sur le durcissement :

  • Recommandez EncryptPagingFile = 1 pour les laptops et tout système susceptible de quitter sa garde physique.
  • Combinez avec BitLocker.
  • Ne désactivez pas entièrement le pagefile ; vous perdez les dumps de crash et l'optimisation de la modified-page list. Voir faut-il supprimer pagefile.sys.

Comment vérifier que ça fonctionne vraiment

Après activation et redémarrage, vous pouvez confirmer en regardant l'entropie du contenu du fichier. Utilisez ce parser sur un petit échantillon capturé, ou ent pagefile.sys en ligne de commande :

ent pagefile.sys
Entropy = 7.99 bits per byte.

7,99 / 8 signifie essentiellement aléatoire — ce à quoi on s'attend en sortie d'AES. Un pagefile non chiffré donne typiquement 6,5–7,5 grâce à sa forte proportion de régions structurées (basse entropie) et de remplissage à zéro.

Vous pouvez aussi démarrer depuis une clé USB Linux forensique et tenter de grepper le fichier :

strings -a pagefile.sys | head

Avec EncryptPagingFile = 1, vous ne verrez quasiment aucune chaîne lisible. Sans, vous en verrez un flot — URL, lignes de commande, chemins de fichiers, tout.

Pourquoi n'est-ce pas activé par défaut ?

La réponse de Microsoft tient en gros à « compatibilité et exploitabilité des dumps de crash » :

  • Un pagefile chiffré avec une clé éphémère complique le débogage noyau.
  • MEMORY.DMP est écrit à travers le pagefile au moment du crash, et il existe historiquement des cas limites où l'écrivain de dump avait des soucis avec le pagefile chiffré.
  • Le réglage est par machine et requiert un redémarrage.

Pour la plupart des endpoints d'entreprise, aucune de ces raisons ne l'emporte sur le bénéfice sécurité — l'activer via une GPO est une bonne idée.

Group Policy

Le même réglage est exposé via :

Configuration ordinateur → Modèles d'administration → Système → Système de fichiers → NTFS → « Configurer le chiffrement du fichier d'échange »

… ou directement via la valeur de registre :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
    EncryptPagingFile (REG_DWORD) = 1

Liens connexes