Encrypted File System (EFS) : explorons les possibilités du système de chiffrement des fichiers sous Windows

Plusieurs éléments sont à prendre en compte si on veut utiliser cette solution :

• Il faut impérativement l’utiliser sur un système de fichiers NTFS ;
• en corollaire, si vous voulez copier des fichiers chiffrés via EFS sur un support non NTFS (par exemple en FAT), les fichiers seront copiés... déchiffrés (avec un message d’avertissement) ;
• certains fichiers ne seront pas chiffrés, comme les fichiers compressés (.zip) ou les fichiers ayant l’attribut « Système ».

Un principe essentiel : le certificat

Pour le chiffrement des données, EFS utilise un certificat qui est associé à l’utilisateur concerné. Sur votre ordinateur local, il n’y en a en général qu’un seul : vous. Dans un environnement multi-utilisateur, un certificat est associé à l’utilisateur ayant le droit de voir les données en clair. Rappelez-vous toutefois qu’EFS n’utilise qu’un seul certificat à la fois, pour un utilisateur donné (hors certificat de récupération, voir plus bas).

Vous ne pouvez donc pas chiffrer une partie de vos fichiers avec un certificat, puis une autre partie avec un autre certificat : il faudra alors à chaque fois charger le certificat correspondant, un seul étant actif à un moment donné.

Si vous avez besoin d’utiliser un nouveau certificat (s’il est compromis, ou lors de la première utilisation), il est possible de chiffrer ou rechiffrer toutes vos données avec ce nouveau certificat, soit par la ligne de commande, soit par le menu « Gérer les certificats de chiffrement » (voir plus bas).

Sinon, basiquement, on active EFS de cette façon :

Dans les propriétés du dossier (ou du fichier), il faut aller dans “Avancé”

Ensuite “Chiffrer...”, puis on clique sur “Appliquer les modifications”

Une notification vous propose de sauvegarder votre clé de chiffrement

Un certificat de chiffrement sera créé s’il n’en existe pas auparavant. Pour voir le détail de ce certificat, on peut aller dans le gestionnaire de certificats via la commande certmgr.msc (ou sinon « Gérer les certificats utilisateurs ».

On obtient alors l’écran suivant : 

S’il existe un certificat de récupération, vous les verrez aussi, mais il n’est pas créé par défaut. On peut vérifier aussi l’empreinte numérique du certificat de chiffrement en cours d’utilisation via la commande cipher.exe /y.

Autre façon d’y accéder : directement dans une rubrique « Gérer les certificats de chiffrement ». On peut s’en servir pour créer un nouveau certificat et remplacer celui utilisé précédemment, ou rechiffrer une partie de ses données.

À cette étape, vous pouvez sélectionner le certificat déjà présent, ou en créer un nouveau de toute pièce. Si vous en créez un nouveau (suite à la perte ou la compromission du précédent), vous pouvez rechiffrer toutes vos données avec ce nouveau certificat à la fin de la procédure.

En suivant les différentes étapes, vous finirez par arriver à un écran vous proposant de sauvegarder votre certificat, ce qui est une bonne idée.

La clé que vous avez sélectionnée pourra ensuite chiffrer (ou rechiffrer si vous en avez besoin) les fichiers sur l’arborescence voulue. En cas d’utilisation d’un nouveau certificat, pensez bien à rechiffrer toutes les données concernées !

Le certificat, dit de récupération des données, doit être réservé à l’administrateur du domaine ou à un utilisateur de confiance. Cette clé permet de créer un outil de récupération soit par domaine (dans le cas de l’utilisation d’Active Directory) soit en local.

L’usage principal : la protection contre le vol

Remettons-nous dans le contexte : vos fichiers sont stockés chiffrés, donc illisibles au repos (quand vous ne les utilisez pas). Une fois que vous êtes connecté à votre session Windows avec un utilisateur possédant (et utilisant) le bon certificat, vous voyez les données en clair de façon transparente.

C’est à la fois un avantage et un inconvénient. Du point de vue ergonomie, c’est top, mais d’un point de vue sécurité, il y a un hic : quand votre session est ouverte, vous ne voyez pas la version telle qu’elle est présente sur le disque. Cela fait une différence si vous voulez transférer vos fichiers ou les synchroniser quelque part : le transfert ou la synchronisation se fera sur la version en clair du fichier !

Impossible donc de protéger par ce mécanisme vos fichiers dans le cloud, ce n’est pas fait pour cela, sauf si vous l’envoyez vers un stockage supportant EFS, bien sûr. Mais bien souvent, dans le cloud, on ne maîtrise pas le système de fichiers, notamment pour les services offrant du stockage de fichiers.

Dans l’explorateur Windows

Quand on regarde dans son explorateur un fichier chiffré via EFS, il apparaît en clair quand vous disposez du certificat. Un cadenas vous permet de savoir que le fichier est protégé via EFS. 

Ici, on a le certificat. Tout se passe comme si le fichier était en clair.

Maintenant, si vous voulez y jeter un œil sans ce sésame, vous voyez ceci :

Sachez enfin que les fichiers sont stockés chiffrés avec une extension spécifique, non visible sous Windows en temps normal.

Un fichier $EFS est apparu, ainsi qu’une extension .PFILE sur les fichiers chiffrés

La ligne de commande

Il est également possible de réaliser de nombreuses opérations en ligne de commande (via un simple terminal, sans forcément passer par PowerShell), grâce à l’outil cipher.exe. On peut ainsi chiffrer, déchiffrer, générer un certificat, ajouter ou supprimer un utilisateur, etc.

Pour créer un certificat de chiffrement, il suffit de taper :

cipher.exe /k

Un certificat sera créé avec les options par défaut et automatiquement importé dans le magasin de certificats utilisateurs. Pour créer manuellement un certificat de récupération, qui pourra être associé à tous vos fichiers, et qu’il faudra transmettre au “maître des clés” :

cipher.exe /r:nom_pour_fichier_clé

Il faudra ici importer votre certificat (en double-cliquant sur le fichier, par exemple). Vous aurez un .CER et un .PFX. Cela nous servira juste en dessous.

Agent de récupération local ou sauvegarde des clés ?

Pour un utilisateur unique, le plus simple est de sauvegarder ses certificats ou la clé de récupération. Il est aussi possible de créer un agent de restauration, quand il y a plusieurs utilisateurs ou quand on est dans un domaine Windows et qu’on souhaite qu’un administrateur puisse débloquer des situations dans lesquelles un certificat serait perdu.

Retournons d’abord sur un fichier crypté chiffré, sur ses propriétés avancées :

Par défaut, on peut voir le certificat de chiffrement utilisé, mais il n’y a rien dans la partie « récupération ».

Microsoft Learn nous indique alors la marche à suivre. Pour notre exemple, on va créer un agent de récupération local (l’autre option est un agent de récupération par domaine) : Protection des données avec le système EFS (Encrypting File System).

En ligne de commande ou via “exécuter”, lancez mmc. Il faut ensuite “Ajouter/Supprimer un composant logiciel enfichable” et ajouter “Éditeur d'objets de stratégie de groupe”.

Suivez l’arborescence indiquée et ajoutez l’agent de récupération. Il vous demandera un certificat, reprenez celui que vous avez créé en ligne de commande (le fichier .CER).

Qu’est-ce que j’ai fait ?

Rappelez-vous que par défaut, il n’y a que le certificat de chiffrement, et rien pour la récupération. Par cette manipulation, on a créé une stratégie Windows obligeant à incorporer le certificat de récupération aux fichiers qui seront chiffrés par EFS.

En conséquence, tous les fichiers créés AVANT cette manipulation ne disposeront pas du dispositif de récupération. Par contre, après la création de la stratégie, le certificat apparaît automatiquement dans les propriétés des fichiers. 

Ainsi, même en cas de changement de certificat ou de toute autre manipulation, il sera toujours possible de déchiffrer les fichiers via ce certificat de récupération. Voici par exemple ce qui se passe si on change de clé de chiffrement au niveau de l’utilisateur : au niveau du fichier, celui-ci est bien modifié, mais le certificat de récupération reste inchangé.

Un petit bonus

On peut faciliter l’accès à cette option, via l’éditeur de registre, en ajoutant cette valeur :

Cela vous rajoutera une ligne “chiffrer” ou “déchiffrer” dans le menu contextuel de Windows (clic droit).

Et sous WSL (Windows Subsystem for Linux) ?

L’accès au système de fichiers Windows se fait... comme sous Windows. WSL sait lire EFS, ou plus précisément, il faut se rappeler que WSL est un sous-système de Windows, il hérite donc de ce qu’il y a « au-dessus ».

À partir du moment où vous exécutez WSL dans l’environnement d’un utilisateur ayant accès aux fichiers chiffrés par EFS, alors WSL peut les lire. Et dans le sens contraire, c’est pareil : sans accès via Windows, pas d’accès dans WSL, que vous soyez root ou n’importe quel utilisateur créé dans WSL.

Si, dans Windows, vous avez accès aux fichiers, alors c’est pareil dans WSL

Et si vous n’y avez pas accès sous Windows, alors l’accès sera refusé aussi sous WSL

Pourquoi l'utiliser ?

Comme très souvent avec les solutions de sécurité, le contexte d’utilisation peut être très restreint. Efficace dans un cas d’usage précis, cela peut devenir un cauchemar à gérer ou être inefficace dans un autre.

Pour résumer, on peut dire qu’EFS a le mérite d’exister et qu’il va simplifier la tâche d’outils servant à sécuriser vos fichiers, mais qu’une gestion manuelle par l’utilisateur n’est pas des plus pratiques, car il faut savoir gérer les certificats et toutes les subtilités de ce système de fichiers.

Notre quête de l’outil de chiffrement parfait ne va donc pas s’arrêter là...