Chiffrement de votre disque

Les problèmes de sécurité augmentant, chiffrer ses disques devient une norme et une nécessité.

Nous allons voir dans ce tutoriel comment chiffrer des disques.

Publié le 8 janvier 2023Â

Version PDF Version hors-ligne

Les problèmes de sécurité augmentant, chiffrer ses disques devient une norme et une nécessité. Windows chiffre maintenant par défaut les systèmes connectés à un compte Active Directory ou la dernière version de Windows en cas de présence d’un TPM et du Secure Boot.

La tendance ira probablement vers un chiffrement automatique par défaut.

Les tests ont été effectués avec des machines virtuelles VirtualBox. Le Live-cd Linux utilisé pour les essais est Ubuntu 18,04.

Les tests KVM ont été effectués depuis une VM PROXMOX .

Nous utiliserons le terme de « BIOS » en lieu et place d’« UEFI » : son successeur, celui-ci étant entré dans le langage courant.

Le mot « volume » qui sera utilisé par la suite désigne une zone de stockage munie d’un système de fichiers. Il s’agit en général d’une partition d’un disque, mais peut être par exemple un partage réseau (on parlera plutôt dans ce cas de volume réseau). Vous pouvez considérer un volume comme un disque logique.

BitLocker est le système de chiffrement natif de Microsoft, disponible dans les versions Windows professionnelles. Les versions familiales peuvent ouvrir un volume chiffré avec BitLocker (tant que vous avez la clé de déchiffrement), mais ne peuvent pas chiffrer un volume.

Les versions familiales (10/11) permettent le « chiffrement des périphériques » (un BitLocker lite) sous réserve d’avoir un TPM et l’UEFI. La fonction sera disponible dans les paramètres→Mise à jour et sécurité→chiffrement de périphérique. Si vous ne voyez pas la fonctionnalité, cela signifie que votre machine n’a pas les prérequis.

Les volumes chiffrés par ce biais apparaîtront comme chiffrés avec BitLocker

Pour activer BitLocker, il suffit de cliquer avec le bouton de droite sur le volume concerné

Si vous ne voyez pas la fonction, c’est que votre système n’intègre pas BitLocker.

Il vous sera demandé où sauvegarder la clé de récupération :

Cette clé ne vous sera pas demandée à chaque démarrage, celle-ci étant stockée dans le TPM, mais vous sera nécessaire en cas de montage du disque sur une autre machine ou en cas de changement de carte mère.

Il est donc important de la garder précieusement et à plusieurs endroits sous peine de risque de perte d’accès aux données.

Vous pourrez réobtenir la clé en cliquant sur le volume chiffré avec le bouton droit de la souris->gérer BitLocker→sauvegarder la clé.

Une fois la clé imprimée ou enregistrée dans un fichier, le bouton « Suivant » s’activera.

Il vous sera ensuite demandé si vous souhaitez chiffrer tout le disque ou uniquement l’espace occupé.

La différence étant que seul l’espace actuellement occupé sera chiffré lors de l’activation du chiffrement, si vous optez pour le chiffrement uniquement de l’espace occupé. Une fois BitLocker activé, les données sont chiffrées à la volée.

Pour un système neuf, le choix de ne chiffrer que l’espace utilisé est pertinent. Dans le cadre du chiffrement d’un poste déjà utilisé, il vaudra donc mieux chiffrer tout le lecteur.

Il vous sera ensuite demandé de choisir le mode de chiffrement. Comme indiqué, le mode de chiffrement ayant changé à partir de Windows 10 version 1511, le nouveau format est incompatible avec l’ancien mode.

Puis il vous est demandé si vous voulez exécuter la vérification du système BitLocker, ce que je recommanderais.

Après quoi une notification indique que le chiffrement commencera après redémarrage.

Vous pourrez ensuite visualiser l’avancée du chiffrement en cliquant sur l’icône bitlocker :

La fenêtre de progression s’affichera :

En cas de redémarrage, le processus continuera où il en était. Vous pouvez donc sans problème redémarrer ou éteindre la machine si le chiffrement n’est pas terminé.

Une fois celui-ci terminé, en ouvrant l’explorateur de fichiers, vous pourrez voir que le lecteur est chiffré, un cadenas apparaissant au niveau de l’icône du disque :

Au niveau BitLocker, chaque volume est autonome. Chaque volume devra être chiffré.

Les volumes amovibles sont chiffrés avec la fonctionnalité « BitLocker To Go ». Le processus sera identique, il vous sera demandé si vous souhaitez chiffrer le volume avec un mot de passe ou avec une carte à puce.

Si vous souhaitez désactiver le chiffrement, il faudra cliquer avec le bouton de droite sur l’icône du disque et sélectionner gérer BitLocker :

Ce qui ouvrira la fenêtre suivante :

Dans le cadre de mes tests, le boot utilisant un ISO Windows 10 avec ouverture d’un terminal (shift-F10) fait apparaître le volume verrouillé. Si vous tapez la commande dir pour afficher le contenu du volume, un message d’erreur apparaît indiquant le verrouillage du volume :

La commande manage-bde -status c : affichera l’état du disque :

Pour déverrouiller le volume, il faut saisir la commande suivante :

ou « clé » correspond à la clé imprimée lors du chiffrement du volume. Une fois la clé entrée, le volume est accessible :

Si la clé est stockée sur une clé USB, la commande sera :

Rappel : le déverrouillage du volume comme montré ci-dessus ne sera nécessaire qu’en cas de changement de carte mère ou de montage du disque dans une autre machine (pas d’accès au TPM d’origine).

Dans gparted , la partition apparaît bien au format BitLocker :

Pour accéder à cette partition, nous allons utiliser le paquet dislocker

Une fois dislocker installé, il faudra lancer la commande de déchiffrement (partition BitLocker dans sda3 dans l’exemple) :

Cette commande va présenter un fichier dislocker-file qu’il va falloir monter en loopback :

Vous pourrez monter un volume externe BitLocker si vous avez le mot de passe et la clé de sécurité.

Pour le disque du système. Il est possible également d’utiliser BitLocker sous Windows 10, les versions antérieures n’ont pas été testées.

Sous Windows 11, la question ne se pose pas, le TPM étant un prérequis pour installer celui-ci.

Par contre, par défaut, vous aurez le message d’erreur suivant :

Pour pouvoir utiliser BitLocker, il vous faudra aller dans la gestion des stratégies de groupe (gpedit) et activer « Configuration ordinateur → Modèles d'administration → Composants Windows → Chiffrement de lecteur BitLocker → Lecteurs de système d'exploitation → Exiger une authentification supplémentaire au démarrage » :

Veracrypt est un logiciel libre fork de Truecrypt . Celui-ci permet de créer des volumes chiffrés dans des fichiers (des conteneurs) et de créer des volumes chiffrés et éventuellement cachés. Il permet également de chiffrer un disque complet, aspect que nous allons traiter. Veracrypt n’utilise pas TPM.

Une fois le logiciel installé et démarré, vous aurez l’écran suivant :

Celui-ci vous proposant par défaut de sélectionner un fichier de volume crypté pour l’affecter à une lettre ou de créer un volume.

Pour accéder à la fonctionnalité nous intéressant (le chiffrement complet du disque), il va falloir aller dans le menu système pour sélectionner « chiffrer la partition/le disque système » :

Vous obtiendrez la fenêtre suivante :

Nous utiliserons le mode normal de chiffrement.

Il vous sera ensuite demandé si vous souhaitez chiffrer l’intégralité du disque ou uniquement la partition système Windows :

Puis il vous sera demandé s’il y a un seul ou plusieurs systèmes. Dans notre cas de figure, la présence d’un seul système a été testée.

Enfin ; il faut choisir les options de chiffrement :

Vous aurez le choix entre les algorithmes suivants :

Si vous n’êtes pas en mesure de choisir l’algorithme , sélectionnez AES, le plus connu.

Le mot de passe vous sera ensuite demandé :

Pour la saisie du mot de passe, Veracrypt passe en clavier anglais pour compatibilité avec le gestionnaire d’amorce en anglais

Il vous faudra, sur l’écran suivant, faire des mouvements avec la souris de façon à générer des valeurs aléatoires. Pour générer suffisamment de valeurs aléatoires, les mouvements devront être effectués tant que la barre de progression ne devient pas verte.

Tant que la barre de progression ne devient pas verte, la valeur aléatoire ne sera pas considérée comme sécurisée.

En cliquant sur la case « Afficher le nombre aléatoire », la valeur sera affichée, mais connaître cette valeur n’a pas vraiment d’intérêt.

Vous aurez ensuite l’écran de notification des clés :

L’étape suivante sera la génération d’un disque de secours. Celui-ci sera important pour pouvoir déchiffer le disque en cas de crash système :

La génération de l’ISO est quasi instantanée, celui-ci faisant 1,7 Mo.

Il vous sera ensuite demandé de choisir le mode de nettoyage.

Sur le même principe que pour l’effacement sécurisé des données, vous pourrez appliquer plusieurs passes pour empêcher la récupération de données non chiffrées (vous pourrez faire 1, 3, 7 ou 35 passes).

Un test vous sera ensuite proposé. Celui-ci va installer le gestionnaire d’amorce Veracrypt et vérifier que votre mot de passe est valide avant de chiffrer les données. Un reboot sera nécessaire.

Au reboot, vous aurez l’écran suivant :

Une fois le mot de passe entré, vous aurez l’écran suivant :

À la réouverture de la session, vous pourrez déclencher le chiffrement :

Chiffrement en cours :

Vous serez notifié à la fin du cryptage :

En cas de boot sur l’ISO Veracrypt Rescue disk, vous aurez l’écran suivant :

Des options supplémentaires seront proposées en appuyant sur la touche F8 :

Depuis Linux, la partition sera vue comme une partition inconnue :

Pour télécharger Veracrypt, il vous faudra suivre le lien suivant: : https://www.veracrypt.fr/en/Downloads.html .

En mode graphique, il vous faudra charger le fichier .deb correspondant à votre distribution Linux.

Pour notre cas Ubuntu 18.04, le dépôt universe doit être activé dans le fichier /etc/apt/sources.list .

L’installation se fera en double-cliquant sur le fichier .deb  :

Une fois l’installation effectuée, l’écran sera le même qu’avec la version Windows :

Les seules différences étant les emplacements (les connecteurs). Sous Windows apparaissent les lettres de volumes (A-Z), sous Linux il s’agit de numéros.

Pour monter votre volume, vous sélectionnez l’emplacement 1, puis cliquez sur « périphérique » :

Vous aurez alors l’écran suivant qui vous permettra de sélectionner le volume à monter :

Une fois le nom de volume affiché, il vous restera à cliquer sur « monter » :

vous aurez ensuite la demande le mot de passe :

Il vous faudra cliquer sur l’icône « Options » et cocher la case : « Mount partition using system encryption  » sous peine d’avoir un message d’erreur :

Comme déjà précisé, le mot de passe doit être saisi en clavier anglais (qwerty), celui-ci étant créé de cette façon pour raison de compatibilité avec le gestionnaire d’amorce.

Comme vous pouvez le voir ci-dessous, le volume est monté dans /media/veracrypt1 .

Le montage peut être fait en ligne de commande avec la commande veracrypt une fois les paquets installés.

LUKS , pour Linux Unified Key Setup, est un système de chiffrement inclus dans le noyau. Nous le piloterons avec cryptsetup .

La première étape va consister à réduire la taille de la partition afin d’y libérer 32 Mo pour l’outil de conversion vers LUKS .

Vous ne pourrez pas effectuer cette procédure sur un système en cours d’utilisation. Les manipulations seront donc effectuées après démarrage sur un live-cd. Le système sera de ce fait immobilisé le temps de la procédure.

Il faut commencer par vérifier le système de fichiers, étape prérequise pour que resize2fs , la commande permettant de redimensionner une partition, accepte de modifier celui-ci. Dans notre cas de figure, la partition contenant le système est sda2.

Il va vous falloir calculer le nouveau nombre de blocs de la partition afin de le passer à la commande resize2fs .

Tout d’abord le nombre de blocs à libérer :

Pour obtenir la taille d’un bloc dans la partition :

il faudra donc libérer 32x1024x1024 = 33 554 432 / 4096 = 8192 blocs

Nous avons le nombre de blocs dans le retour de la commande e2fsck : 1 792 000, ceci représentant une taille de partition de 7 Go (dans ma VM)

la nouvelle taille afin de libérer les 32 Mo sera donc de :

1 792 000 – 8192 = 1 783 808

Vous utiliserez ensuite un produit nommé luksipc permettant de chiffrer un volume non monté à la volée.

En cas d’interruption de la commande, le volume sera partiellement chiffré. Vous pourrez reprendre le processus avec l’option --resume . Sans sauvegarde fiable avant intervention, vous prenez un très gros risque.

Installation de luksipc  :

Il faut utiliser ensuite la commande pour chiffrer la partition :

Il vous faudra à ce niveau valider l’opération en tapant « YES » en majuscules.

À ce stade, la partition est chiffrée et il vous faudra le fichier / root/initial_keyfile.bin pour la déchiffrer. Ce fichier est directement créé par luksipc . La perte de celui-ci empêchera le déchiffrement.

Une partition chiffrée avec LUKS peut contenir 8 clés.

Vous allez en générer une à partir de ce fichier de façon à pouvoir déchiffrer le volume avec une passphrase. Il faut passer en paramètre le fichier de clé automatiquement généré lors de l’étape précédente :

Vous pouvez voir les deux clés enregistrées avec la commande luksdump  :

Vous supprimez la première clé générée automatiquement, la passphrase vous sera demandée :

le 0 correspondant à la première entrée

un luksdump vous permettra de voir que le premier emplacement de clé est vide :

À ce stade, vous n’avez plus besoin du fichier initial keyfile.bin .

Vous allez maintenant ouvrir le conteneur LUKS Â :

Le device sera visible dans le dossier /dev/mapper  :

Vous commencez par réagrandir la partition.

Sans indication de taille, la partition sera agrandie au maximum possible :

Il faut à ce stade intervenir sur la pseudo partition LUKS, pas directement sur la partition sda2.

Vous pouvez ensuite monter la partition :

Puis entrer dans le système avec un chroot :

Vous modifiez le fichier /etc/default/grub pour y ajouter le support des volumes chiffrés :

de façon à ne pas avoir à saisir les UUID, j’ai utilisé les commandes suivantes :

ce qui donnera en fin de fichier :

que vous modifierez de la façon suivante :

Vous mettrez ensuite à jour grub :

Rappel : les UUID sont uniques, vous aurez donc d’autres valeurs dans votre cas de figure.

il va ensuite vous falloir modifier les fichiers /etc/crypttab et /etc/fstab .

Pour le fichier /etc/crypttab , il faut ajouter l’entrée suivante :

vous appliquerez la même méthode que précédemment :

ce qui donnera dans mon cas l’entrée suivante :

que je remplace par :

modification de /etc/fstab  :

le fichier /etc/fstab contiendra :

Je modifie la dernière ligne par :

qui remplacera la ligne contenant /dev/sda2 .

Il faut ensuite mettre à jour l’ initramfs  :

Puis quitter le chroot :

Et démonter le volume crypté :

Au reboot, il vous sera demandé la passphrase du volume :

Ne soyez pas surpris, vous aurez l’impression que rien ne se passe pendant quelques secondes après la saisie du mot de passe.

Vous aurez ensuite l’écran GRUB normal :

Le mot de passe vous sera redemandé à la sortie de l’ initramfs  :

Pour pallier ceci, vous allez enregistrer un fichier de clé qui sera utilisé par le système.

Vous mettez ensuite le fichier en lecture seule uniquement pour root :

Et vous enregistrez la clé dans le volume :

Puis vous modifiez le fichier /etc/crypttab pour y ajouter le fichier de clé, en remplaçant la ligne :

Vous modifiez la valeur de KEYFILE_PATTERN dans le le fichier /etc/cryptsetup-initramfs/conf-hook  :

ensuite le UMASK dans le fichier initramfs.conf  :

et enfin les modifications dans l’initramfs :

Après reboot, la passphrase ne vous sera demandée qu’au boot.

Modification du swap  :

À ce stade, la partition swap est toujours en clair, vous allez également la chiffrer.

Pour commencer, commentez la ligne concernant le swap dans /etc/fstab (l’arrêt par swapoff ne suffisant pas), puis rebootez (non indispensable, mais par sécurité).

écrasez d’abord le contenu du swap (dans sda3) :

Créez ensuite le volume LUKS pour le swap :

Puis intégrez le fichier de signature :

J’ai utilisé la même clé que pour la partition /. Il aurait tout à fait été possible d’en créer une spécifique au swap.

Ouvrez le volume LUKSÂ :

Créez le swap dans le volume LUKS :

Récupérez l’UUID de la partition /dev/sda3 et recopiez-le dans /etc/crypttab

le fichier contiendra :

Appliquez le même principe pour fstab, ce qui donnera :

La version Linux de Veracrypt ne permet pas le chiffrement de la partition système en cours contrairement à la version Windows, vous ne pourrez donc pas l’utiliser sans faire une installation de base. Il reste possible de l’utiliser pour créer des conteneurs montés dans des points de montage. Cet aspect n’a pas été étudié.

MacOS est fourni avec un système de chiffrement nommé Filevault. Sur les anciennes versions, seules les données utilisateur étaient chiffrées dans une image dmg, ce n’est plus actuellement le cas.

FileVault fonctionne un peu comme BitLocker, avec une puce cryptographique avec fonctionnement semblable au TPM pour les machines les plus récentes.

Pour chiffrer votre disque avec filevault, il va vous falloir aller dans le menu pomme→préférences système :

Dans les préférences, allez dans l’onglet sécurité et confidentialité :

Onglet filevault, il faudra cliquer sur le cadenas :

Il vous sera alors demandé un nom d’utilisateur avec les droits administrateur ainsi que le mot de passe :

Vous pourrez ensuite cliquer sur « activer filevault » :

Vous pourrez alors soit utiliser votre compte icloud, soit une clé de sécurité qui vous sera communiquée pour déverrouiller le disque :

Une fois le choix effectué, le disque sera chiffré en tache de fond. Dès l’allumage de la machine, vous devrez saisir votre mot de passe.

En cas de multi-utilisateurs, seuls les comptes approuvés par un compte administrateur pourront démarrer la machine.

Tout comme pour Linux, vous pouvez utiliser Veracrypt avec MacOS, sauf pour chiffrer le disque de démarrage.

L’utilitaire de disque permet de créer des images disque .dmg chiffrées ce qui enlève l’intérêt d’utiliser Veracrypt avec MacOS.

L’intérêt de Veracrypt reste pour l’utilisation alternative d’un volume externe chiffré entre environnement Apple et Windows/Linux.

La sauvegarde à chaud, c’est-à -dire depuis le système d’exploitation en fonctionnement, sera transparente pour les logiciels de sauvegarde. Attention aux fichiers ou bases de données ouvertes que votre logiciel doit pouvoir gérer (certains produits nécessitent des modules complémentaires).

Pour faire une sauvegarde à froid, c’est-à -dire système d’exploitation non démarré ou disque monté sur un autre poste, la règle sera la même que pour la restauration : le média utilisé pour effectuer la sauvegarde devra intégrer le support du chiffrement utilisé et vous devrez avoir la clé de restauration pour déverrouiller le volume chiffré.

La sauvegarde se fera en clair, sauf si votre logiciel de sauvegarde permet son chiffrement ou si vous sauvegardez sur un volume chiffré.

Il existe des clés USB et disques durs intégrant un système de chiffrement matériel. Pour pouvoir monter le volume chiffré, vous aurez besoin dans ce cas du logiciel permettant le montage du volume, à moins d’avoir un équipement avec un clavier intégré pour la saisie d’un mot de passe ou ayant un capteur d’empreinte.

La restauration ne devrait pas être chiffrée, à votre charge de réactiver le chiffrement une fois celle-ci effectuée.

Je vais présenter ici la restauration sur une autre machine d’une sauvegarde effectuée avec la sauvegarde d’images système Windows (accessible dans le panneau de configuration dans l’ historique des fichiers ou sauvegarde Windows 7)sur un volume BitLocker .

Au démarrage de Windows, il faudra sélectionner « réparer l’ordinateur » :

puis sélectionner « Dépannage »

puis « récupération système » :

Windows a détecté un volume BitLocker qu’il ne connaît pas. Il vous demandera de saisir la clé de récupération :

Une fois la clé entrée, la procédure continuera comme pour un volume non chiffré.

Pour Veracrypt , la sauvegarde Windows ne reconnaît pas un volume chiffré comme disque exploitable, il n’est donc pas possible d’effectuer une sauvegarde dessus.

Le principe sera le même avec un disque de récupération Windows.

J’ai effectué un test avec Acronis Cyber Protect Home Office, anciennement Acronis True image installé sur un poste.

Le logiciel permet de chiffrer la sauvegarde :

J’ai effectué un test en stockant la sauvegarde sur un volume chiffré avec BitLocker. Afin de pouvoir effectuer une restauration depuis le média d’Acronis, j’ai dû quitter le logiciel et monter le volume chiffré avec la commande manage-bde vue au chapitre 2.1.3 boot sur média Windows , puis relancer le logiciel pour enfin effectuer la restauration.

Dans le cas d’un chiffrement avec Veracrypt , toujours depuis le média Acronis, j’aurais dû lancer la version portable stockée sur une clé USB, puis enfin lancer Acronis.

Seul l’aspect création d’image disque a été vu ici, pas l’aspect création de clone que permet Macrium Reflect.

Ci-dessous la copie d’écran de la préparation d’une image de sauvegarde, stockée sur E: , volume chiffré par BitLocker .

Le logiciel avertit :

En cliquant sur « options avancées », il vous est possible d’accéder à l’option de chiffrement en entrant un mot de passe.

Cette option n’est cependant disponible qu’avec la version payante.

La génération d’un média bootable Macrium intègre les clés des volumes déverrouillés permettant son accès en mode restauration à froid. Cela ne vous affranchira pas de garder les clés ailleurs.

Pour générer ce support, il vous faudra aller dans le menu autre taches → disque de secours

Les applications tierces liées au chiffrage disponibles dans les stores respectifs sont des outils de cloud.

Test effectué depuis une VM Virtualbox sous Android x86 Nougat.

Une fois le système installé, démarrer sur un livecd Ubuntu permet de voir que les données utilisateur telles que les fichiers téléchargés sont stockées dans /data/media/0 .

En cas de plusieurs utilisateurs, un nouveau dossier sera créé dans le dossier média. La création d’un second utilisateur a dans le cadre de mon test créé un dossier nommé 10.

Sur un smartphone Android (ou une tablette), les données seraient accessibles en montant le téléphone en mode USB, en montant la carte flash pour la partie stockée sur la zone de stockage externe du téléphone ou en passant l’appareil en mode debug.

Pour chiffrer le disque, il faut aller dans les paramètres de l’appareil :

partie sécurité, localisation :

Puis chiffrement et identifiants :

et enfin chiffrer la tablette (ou le téléphone) :

Les données sur les Iphones sont chiffrées directement par l’appareil.

Dans le cadre d’utilisation de machines virtuelle, il est tout à fait possible de gérer le chiffrement au niveau de la VM directement.

Il ne faudra pas dans ce cas activer le chiffrement directement dans la VM, le double chiffrement entraînant dans ce cas des pertes de performances pouvant être significatives.

Cette opération s’effectuera à chaud ou à froid (c’est-à -dire VM arrêtée ou en cours de fonctionnement) selon les possibilités de l’hyperviseur.

Pour cela, il vous faudra aller dans la configuration de la machine virtuelle concernée : icône stockage->onglet chiffrement de disque.

Il vous faudra cocher « activer le chiffrement de disque », puis entrer le mot de passe et sélectionner le « chiffre » de chiffrement.

Le chiffrement se déclenchera :

Lors du lancement de la VM, le mot de passe du disque vous sera demandé :

la clé de chiffrement est incluse dans le fichier de définition de la VM . vbox . Sans ce fichier, vous ne pourrez pas accéder au contenu des données. Pour copier la VM, prenez son dossier complet.

Seule la version payante VMWare Workstation Pro permet le chiffrement. Pour cela, il faudra aller dans les réglages de la VM, onglet options :

Le mot de passe vous sera ensuite demandé  :

Chiffrement de l’image disque de la machine en cours :

Au prochain démarrage de VMWare, le mot de passe vous sera demandé :

L’image disque ainsi que le fichier de description de VM (fichier .vmx) seront chiffrés.

Il faudra également récupérer tout le dossier de la VM pour pouvoir accéder aux données chiffrées.

Hyper-V fournit deux types de machines virtuelles, les machines de 1 re génération et celles de 2 e génération.

Les machines de 1 re génération sont plutôt dédiées aux anciens systèmes.

Les machines de 2 e génération apportent :

Le chiffrement des machines virtuelles Hyper-V s’appuie sur BitLocker.

Sur les machines de 1 re génération, il vous faudra ajouter un lecteur de stockage, qui contiendra la clé de chiffrement :

Sur les machines de 2 e génération, le TPM de l’hôte sera utilisé pour la clé BitLocker. Ci-dessous l’écran de configuration de la sécurité sur une VM de seconde génération

Le host guardian service est un rôle sur Windows Server générant la sécurité des machines virtuelles. Il est prévu pour des clusters Hyper-V.

Les VM protégées par ce service se nommeront des « Shielded VM ». Ce service apporte plus que le simple chiffrement des disques virtuels et dépasse le cadre de ce tutoriel.

Plus d’informations sur Host Guardian Service .

KVM ,l’hyperviseur intégré au noyau Linux, s’appuie sur les formats d’image disque de Qemu pour le stockage de données.

Le format natif de Qemu est le qcow2 , mais il peut gérer du format raw , vmdk format 3 et 4 (de VMWare), et vdi format 1.1 (de VirtualBox), ainsi que le vhd (Hyper-V).

KVM est également capable de stocker ses données dans un volume LVM ou dans un pool ZFS , qui peuvent dans ces deux cas être cryptés.

Dans tous les cas de figure, il sera nécessaire d’avoir la même quantité d’espace que l’image source afin de pouvoir faire sa conversion et une fois celle-ci effective, supprimer l’image source non chiffrée.

Dans le cas d’un fichier qcow , la conversion devra être effectuée à froid, dans le cas d’utilisation de LVM , elle pourra être faite à chaud.

Pour chiffrer un fichier qcow2 , il va falloir en créer un nouveau de la même taille que celui d’origine. Comme déjà précisé, l’opération devra être effectuée à froid (c’est-à -dire VM éteinte).

Exemple avec un fichier qcow , analyse du fichier qcow2 concerné avec la commande qemu-img  (disque vm-100-disk-0.qcow2 ):

Afin de le convertir vers un format chiffré, nous allons commencer par créer un fichier chiffré de la même taille :

-o : indique une suite d’options

Nous allons ensuite recopier les données du fichier image source non crypté vers le fichier image crypté :

Restera à modifier la commande de lancement de la machine virtuelle de façon à lui fournir le mot de passe en plus du fichier image disque.

Comme déjà évoqué, KVM peut créer des disques virtuels dans des volumes logiques LVM .

Principe de fonctionnement de LVM Â :

LVM va regrouper des volumes physiques PV dans des volume Group VG .

Depuis ces Volume GROUP, on pourra créer des volumes logiques :

Dans le cas de figure qui sera étudié, nous serons dans le cas suivant :

la VM de test créée utilise un disque en LVM nommé pve-vm—100--disk--0 .

Il est visible ici :

pve-root est le volume LVM contenant le /, pve-swap comme son nom l’indique, correspond au swap, pve-pool correspond au pool (pool : ensemble de ressources réutilisables), et enfin l’image disque de notre VM : pve-vm—100—disk-0 , incluse dans pve-pool .

La commande pvs fournit des informations sur les volumes physiques :

Nous pouvons voir que notre partition sda3 fait partie d’un Volume Group nommé pve .

La commande vgs permet d’afficher les informations sur les Volume Group :

Nous pouvons voir pour notre unique VG un seul disque ( PV ), contenant 4 volumes logiques ( LV ).

La commande lvs nous permet de lister les volumes logiques :

Dans notre cas de figure, nous allons intégrer notre « physical volume » dans un volume chiffré LUKS  :

Dans l’exemple utilisé, je suis parti sur une distribution PROXMOX , utilisant KVM et intégrant l’utilisation d’ LVM .

Nous allons commencer par la création d’une partition sur un second disque. Nous faisons abstraction de l’installation du disque supplémentaire ne pouvant être faite à chaud que si le matériel le permet.

Vous pourrez avoir besoin d’installer cryptsetup , le gestionnaire de chiffrement LUKS , si celui-ci n’est pas disponible sur votre installation :

Création d’un volume chiffré sur la nouvelle partition :

Nous ouvrons ensuite le volume LUKS en lui attribuant le nom de crypt-data-tmp  :

il va y avoir un petit délai avant que le shell rende la main, délai correspondant au déchiffrement, ne soyez donc pas surpris.

Nous pourrons ensuite le voir dans /dev/mapper  :

Nous initialisons ensuite notre volume LUKS pour pouvoir l’utiliser avec LVM  :

L’affichage de la commande pvs fait apparaître nos deux disques LVM . Nous voyons également qu’aucun VG n’est affecté à crypt-data-tmp .

Nous intégrons ensuite crypt-data-tmp au volume group :

Retour de la commande pvs :

Nous déplaçons maintenant le contenu du VG contenu dans /dev/sda3 vers /dev/mapper/crypt-data-tmp  :

Le fait de déplacer le Volume Group va bien entendu déplacer les volumes logiques qu’il contient.

En cas d’interruption, le volume sera dans un état incohérent au niveau du démarrage et donc inutilisable en l’état, ceci probablement comme suite à la configuration du fichier cryptab, non effectuée, que nous verrons un peu plus tard. Un reboot provoquera un passage de GRUB en mode rescue :

Si vous n’êtes pas dans ce cas de figure, vous pouvez continuer à la partie « suite de la procédure  ».

Il est possible de résoudre le problème en démarrant sur un live cd/live USB et en appliquant les commandes suivantes.

Il faudra commencer par ouvrir le volume crypté :

En listant les volumes présents dans /dev/mapper , vous pourrez apercevoir un volume pve-pvmove0 correspondant aux traces du volume en cours de transfert :

Nous entrons en chroot dans le système planté. Ceci est possible, car le volume est accessible si crypt-data-tmp est ouvert, une partie des données se trouvant sur /dev/sda3 l’autre sur crypt-data-tmp .

Une fois dans le chroot, nous relançons la procédure en rappelant pvmove sans paramètres :

Une fois le processus terminé, vous pourrez continuer la procédure normale indiquée ci-dessous depuis le chroot.

Suite de la procédure :

Une fois le transfert abouti, nous pouvons sortir le disque d’origine du VG  :

La commande ci-dessus permet de voir /dev/sda3 ne fait plus partie du VG pve .

Reste à effacer le label LVM de l’ancien volume :

À ce stade, /dev/sda3 ne sera plus considéré comme un disque physique utilisé par LVM .

Le volume LVM ne sera plus bootable en l’état, il va nous falloir modifier le fichier /etc/crypttab , ce que nous ferons une fois les données de nouveau déplacées sur le disque d’origine.

Nous supprimons maintenant la partition contenant originellement les données : /dev/sda3  :

Nous créons une partition de 512 Mo dans laquelle nous placerons le volume /boot et une autre avec le reste du disque pour le nouveau volume crypté :

GRUB ne gère pas correctement le format luks2. Pour pallier cette difficulté et pouvoir quand même bénéficier de luks2 pour la partie données, nous allons créer une partition luks1 pour le /boot (qui contiendra le noyau et l’initramfs) et une partition luks2 pour le reste du volume.

Création du volume chiffré luks1 pour le boot :

Nous ouvrons ensuite le volume chiffré (avec dans mon cas le nom crypt-boot) :

Création du système de fichiers :

Nous nous occupons ensuite du déplacement des données de /boot vers la nouvelle partition chiffrée.

première étape, le montage de la partition dans un point de montage temporaire, nous utiliserons /mnt  :

Avant la copie du contenu de /boot , Nous démontons la partition UEFI qui y est montée dans le sous-dossier /boot/efi  :

Nous déplaçons ensuite le contenu de /boot dans le point de montage /mnt  :

puis démontons /mnt  :

Afin que /boot soit monté depuis la nouvelle partition, nous ajoutons ensuite la ligne suivante dans le fichier /etc/fstab  :

Si dans votre cas de figure, /boot se trouve déjà dans un point de montage dans votre fichier fstab , il vous faudra modifier cette entrée.

Nous appelons ensuite la commande suivante :

qui va du coup monter la nouvelle partition /boot et remonter la partition UEFI dans /boot/efi .

Déplacement du volume LVM de sdb2 vers sda4  :

Nous appliquons la méthode déjà effectuée pour déplacer les LVM du volume nouvellement chiffré sur le disque secondaire/externe vers la nouvelle partition du disque interne.

Nous allons maintenant intégrer les entrées correspondant aux volumes chiffrés dans le fichier /etc/crypttab .

Celui-ci va contenir les entrées sous le format suivant :

Il va nous falloir récupérer les UUID des partitions chiffrées. Pour cela, nous allons utiliser la commande blkid , filtrer l’entrée voulue avec grep , puis intégrer le résultat dans le fichier crypttab  :

ce qui nous donnera  :

que nous modifierons en :

Nous mettons ensuite à jour l’initramfs :

Nous ajoutons la ligne GRUB_ENABLE_CRYPTODISK=y au fichier /etc/default/grub afin que GRUB puisse gérer la partition chiffrée :

Nous effectuons ensuite la mise à jour de GRUB :

Le démarrage sera alors opérationnel avec GRUB se chargeant depuis le disque interne, accédant à la partition de boot chiffrée, accédant elle-même au / chiffré sur le second disque.

Au reboot, GRUB nous demandera le mot de passe (de la partition /boot )Â :

Rappel : vous aurez un certain délai avant une réponse.

En cas d’erreur de saisie du mot de passe, vous passerez en mode rescue :

Une fois le bon code entré, vous aurez l’écran GRUB normal.

Pendant la suite du chargement, vous sera demandée la clé pour déverrouiller le volume crypt-data  :

Vous sera également redemandé le mot de passe de la partition de boot :

création de fichiers de clé :

Afin de ne pas avoir à saisir de mots de passe après celui de GRUB, nous allons créer des fichiers de déverrouillage par clé. Celle déverrouillant le / devant être intégrée à l’initramfs, nous la placerons dans /boot. Ces clés étant dans des volumes cryptés, cela ne posera pas de problème de sécurité.

Les volumes pourront toujours être déverrouillés avec les mots de passe précédemment enregistrés.

Création d’un fichier de données aléatoires qui servira de clé :

Attribution des droits lecture seule :

ajout du fichier de clé dans le volume crypté :

modification du fichier /etc/crypttab  :

Nous remplaçons l’entrée :

Le fait de passer en script /bin/cat fera en sorte que la commande cat dans l’initramfs passe le fichier /boot/root.key en paramètre à cryptsetup .

Il nous reste à créer un fichier de hook déclenchant l’intégration du fichier root.key dans l’initramfs.

création du fichier /etc/initramfs-tools/hooks/keyfile  (le nom de fichier keyfile étant choisi arbitrairement):

nous rendons le script exécutable :

nous mettons à jour l’initramfs :

Vous pourrez constater l’intégration du fichier root.key dans le dossier /boot de l’initramfs avec la commande :

Le fichier est donc accessible du point de vue de l’initramfs par le chemin /boot/root.key tout comme du point de vue du système complètement chargé, celui-ci étant dans le ramdisk initramfs avant le pivot_root, puis dans l’arborescence / ensuite.

Au prochain redémarrage, après GRUB, il ne vous sera demandé que le mot de passe du volume boot :

Création du fichier de clé pour /boot :

Nous pourrons stocker le fichier de clé sur la partition root. Nous le ferons dans le dossier /etc/keys  :

Nous appliquons les droits en lecture seule :

Nous intégrons la clé au volume :

Nous ajoutons la clé dans /etc/crypttab  :

Au reboot, vous n’aurez plus qu’à entrer la clé au lancement de GRUB.

Vu que la méthode exposée implique l’utilisation au moins temporaire d’un disque secondaire, pourquoi ne pas le conserver et l’utiliser en mode RAID 1 logiciel ?

Ceci est tout à fait possible. Dans ce cas, les volumes LUKS , dont celui affecté au root, imbriqueront eux-mêmes des volumes LVM , qui seront eux-mêmes imbriqués dans des volumes RAID 1 logiciels via mdadm .

Cette méthode, en plus de la sécurisation RAID, apportera l’écrasement des données en clair pour les deux disques.

Ceci devra être fait dès le départ. Voici la procédure avec le rajout de la couche RAID.

Nous aurons donc besoin du paquet mdadm en plus de cryptsetup . Le processus sera relativement similaire en plus de l’ajout de la couche RAID.

Création de la table de partition sur le disque secondaire, en sélectionnant le type de partition « Linux RAID » au lieu de partition « Linux LVM »(sauf pour la partition UEFI) :

Nous créons une partition pour l’UEFI, une partition pour le /boot et la partition de root.

Création du volume RAID pour la partition de boot :

Avec en paramètres :

Nous gardons /dev/md0 pour la création d’un RAID pour l’UEFI que nous verrons un peu plus tard.

Nous venons ici de déclarer un RAID utilisant /dev/sdb2 en mode dégradé, le but étant d’intégrer les volumes du disque d’origine hébergeant actuellement le système, une fois le contenu déplacé dessus.

Nous formatons ce volume RAID avec Luks :

La procédure sera la même que celle vue précédemment à savoir :

création du volume RAID pour le root :

Nous devrons ensuite :

mise à jour du fichier de configuration mdadm :

Mise à jour du fichier /etc/crypttab  : comme précédemment en utilisant les UUID des volumes mdadm , pas des partitions directement.

mise à jour de GRUB : ne pas oublier l’ajout de l’entrée GRUB_ENABLE_CRYPTODISK=y

Lors de celle-ci, vous aurez des messages d’erreur de type :

idem pour grub-install

Une fois l‘opération effectuée, GRUB se lance depuis le disque d’origine puis charge le système depuis le second disque contenant le RAID dégradé.

Nous allons créer les partitions sur le disque d’origine pour l’intégrer au RAID :

table avant manipulation :

Table après mise à jour :

Nous intégrons maintenant nos nouvelles partitions écrasant le disque d’origine au RAID :

Nous pouvons voir l’état de progression de la mise à jour du RAID en affichant le contenu du fichier /proc/mdstat  :

Une fois le RAID synchronisé, voici ce qui vous sera retourné :

À cause de GRUB, il n’est normalement pas possible d’intégrer une partition UEFI en RAID.

Voici la procédure utilisée pour pouvoir le faire.

Nous commençons par créer notre RAID pour l’UEFI en mode dégradé sur la partition du second disque :

L’option – metadata=1.0 permet de forcer l’utilisation du format de métadonnées 1.0 qui va écrire celles-ci en fin de partition, ce qui sera transparent pour GRUB et l’UEFI.

Si vous utilisez d’autres systèmes d’exploitation sur le disque, ce qui vu la configuration est peu probable, une modification de la partition UEFI faite par celui-ci ne sera pas vue par le RAID logiciel. Vous vous trouverez dans une situation indéterminée sur le contenu de celui-ci après manipulation.

Nous continuons avec le formatage de la partition UEFI en FAT32 avec le même UUID que la partition d’origine :

La valeur 32B8F118 correspond à l’UUID de la partition UEFI en cours sans le tiret (qu’il ne faut pas mettre), UUID que nous avons récupéré avec la commande :

Nous montons cette nouvelle partition dans /mnt  :

recopions le contenu de la partition UEFI d’origine vers la seconde :

Nous démontons ensuite les deux partitions UEFI :

nous intégrons maintenant la partition UEFI d’origine au RAID md0 :

Une petite vérification de l’état de synchronisation avant de continuer :

Nous remontons ensuite la partition UEFI avec :

Rappel : dans l’entrée fstab, le point de montage se fait avec l’UUID :

Avant création du RAID, l’appel à la commande mount retournait pour /boot/efi  :

Après création du RAID et remontage avec mount -a , la commande mount nous retourne pour /boot/efi  :

Le RAID est bien pris en compte.

Nous mettons à jour le fichier mdadm.conf :

Si vous l’aviez déjà fait, il faut modifier les entrées précédentes.

Nous allons ensuite ajouter une entrée UEFI pour le second disque et refaire l’entrée pour le premier avec la commande efibootmgr .

Ajout de l’entrée pour le second disque :

Nous pouvons voir que l’entrée à été ajoutée sous le numéro 0006 et qu’il s’agit de la première entrée dans l’ordre de boot (ligne boot order).

À ce stade, en cas de reboot, l’UEFI lancera GRUB depuis le second disque.

Nous supprimons l’entrée d’origine numéro 0005 nommée « proxmox » dans mon cas.

Nous recréons l’entrée en la nommant « raid-linux-1 » :

Avec cet ajout, le prochain reboot se fera sur le premier disque comme à l’origine.

En entrant dans le BIOS UEFI, dans mon cas VirtualBox, nous pouvons voir les deux entrées créées :

En regardant à gauche la valeur de Device Path pour les deux entrées, nous pouvons constater que les deux sont différentes.

Nous allons simuler la perte du premier disque.

Disque perdu, le boot au niveau de GRUB sera transparent.

Nous aurons des messages d’erreur :

mais le démarrage aboutira.

Si nous consultons l’état des RAID logiciels :

Nous pouvons constater qu’il sont en mode dégradé. Nous voyons également que les partitions visibles sont sur sda , bien que le disque survivant soit le second, donc normalement sdb . Nous pouvons voir que notre RAID md0 a été renommé en md127 .

Après ajout d’un nouveau disque, le disque fonctionnel apparaît de nouveau en sdb :

La remise en service sera très simple. Il faudra sur le nouveau disque créer une nouvelle table de partition identique à celle utilisée, puis intégrer les nouvelles partitions au RAID.

Avec une utilisation Cloud, il est possible que le chiffrement des disques soit natif.

Dans le cas contraire, vous serez dans les conditions exposées ci-dessous.

Un VPS (Virtual Private Server pour serveur virtuel privé) est un serveur qui est mis à votre disposition par votre hébergeur. L’accès à celui-ci se fera :

Dans le cas d’un accès uniquement via une interface web, votre interaction avec le VPS sera limitée, vous n’aurez accès qu’aux fonctionnalités implémentées.

Dans le cas d’un accès SSH, il vous faut garder à l’esprit que vous n’êtes pas devant un écran, et que la moindre manipulation vous faisant perdre l’accès SSH peut interrompre une opération critique vous obligeant à relancer l’installation. Dans ce cas de figure, les hébergeurs fournissent en général un mode rescue (en général un netboot sur une image système de base avec accès à vos disques), celui-ci vous permettant de chrooter dans le système à modifier.

Avec ce genre de services, il vous est fourni un accès SSH (ou RDS avec Windows). Vous pouvez donc appliquer les méthodes vues en gardant à l’esprit que n’avez qu’un accès SSH, et que sa perte peut vous empêcher de continuer une procédure interrompue nécessitant l’usage du mode rescue.

Ce genre de services intègre en général le chiffrage des volumes.

Le chiffrement des disques accroît la confidentialité des données sensibles dont la divulgation pourrait provoquer un préjudice majeur. Il protège très efficacement contre l’accès notamment physique au disque, par exemple en cas de perte ou de vol. C’est un complément devenant indispensable au(x) mot(s) de passe (du compte ou du bios). Le chiffrement est une option disponible sur la plupart des systèmes d’exploitation. Nous avons vu Bitlocker, disponible sur Windows, LUKS sous Linux, et Filevault sous MacOS. Pour être activé, il peut nécessiter des prérequis logiciels (comme une version pro de Windows pour Bitlocker) ou matérielle (TPM).

Il existe également des logiciels tiers de chiffrement, nous avons vu Veracrypt.

La contrepartie de la sécurité obtenue est le risque de perdre ses données en cas de perte totale de la clé (d’où l’importance d’avoir plusieurs sauvegarde de la clé de récupération pour Bitlocker ou de ne pas perdre le mot de passe) avec du coup une perte totale d’accès aux données, et de rendre éventuellement une réparation plus complexe, le chiffrement rendant plus difficile une maintenance sur un système de fichiers.

Il est à noter qu’un chiffrement ne vous protégera pas d’une intrusion due à une faille de sécurité du système d’exploitation, d’un virus ou tout simplement d’un accès à une session laissée ouverte. Je préconiserais de ne pas placer la sauvegarde sur un volume chiffré, mais d'utiliser le chiffrement inclus dans le logiciel de sauvegarde (demandant la saisie d'un mot de passe) ou éventuellement d’utiliser un disque externe à chiffrement matériel (vous demandant également un mot de passe).

Je remercie Gaby277 pour sa relecture technique.

Je remercie également escartefigue pour sa relecture orthographique.