Chiffrement complet du disque Windows Linux des systèmes installés. Multi-boot chiffré

Mise à jour de votre propre guide sur le chiffrement de disque complet dans le Runet V0.2.

Stratégie cowboy :

[A] chiffrement système par blocs pour le système Windows 7 installé ;
[B] chiffrement système par blocs GNU/Linux (Debian) système installé (y compris /boot);
[C] configuration de GRUB2, protection du chargeur de démarrage par signature numérique/authentification/hachage ;
[D] nettoyage - destruction des données non chiffrées ;
[E] sauvegarde universelle des OS chiffrés ;
[F] attaque cible - chargeur GRUB2 ;
[G] documentation utile.

╭───Schéma #chambre 40# :
├──╼ Windows 7 installé - chiffrement système complet, non caché ;
├──╼ GNU/Linux installé (Debian et distributions dérivées) — chiffrement système complet non caché(/, y compris /boot ; swap);
├──╼ chargeurs de démarrage indépendants : chargeur VeraCrypt installé dans MBR, chargeur GRUB2 installé dans la partition étendue ;
├──╼ installation/réinstallation de l'OS non nécessaire ;
└──╼ logiciels cryptographiques utilisés : VeraCrypt ; Cryptsetup ; GnuPG ; Seahorse ; Hashdeep ; GRUB2 – libre/gratuit.

Le schéma ci-dessus résout partiellement le problème du « boot externe sur clé USB », permettant de profiter des OS Windows/Linux chiffrés et d'échanger des données via un « canal chiffré » d'un OS à l'autre.

Ordre de démarrage du PC (une des options) :

• allumer la machine ;
• charger le chargeur VeraCrypt (la saisie correcte du mot de passe continuera le chargement de Windows 7);
• taper la touche « Échap » chargera le chargeur GRUB2 ;
• chargeur GRUB2 (sélection de distribution/GNU/Linux/CLI), demandera l'authentification de superutilisateur GRUB2 ;
• après une authentification réussie et la sélection de la distribution, il sera nécessaire de saisir la phrase de passe pour déverrouiller « /boot/initrd.img » ;
• après l'entrée des mots de passe corrects dans GRUB2, il sera « nécessaire » de saisir le mot de passe (le troisième en ordre, mot de passe BIOS ou mot de passe du compte utilisateur GNU/Linux – à ne pas considérer) pour déverrouiller et charger le système d'exploitation GNU/Linux, ou insertion automatique de la clé secrète (deux mots de passe + clé, ou mot de passe + clé);
• une intrusion externe dans la configuration de GRUB2 gèlera le processus de démarrage de GNU/Linux.

Fastidieux ? D'accord, allons automatiser les processus.

Lors du partitionnement du disque dur (table MBR) le PC peut avoir pas plus de 4 partitions principales, ou 3 principales et une étendue, ainsi qu'une zone non partitionnée. La partition étendue, contrairement à la principale, peut contenir des sous-parties. (disques logiques=partition étendue). En d'autres termes, la « partition étendue » sur le HDD remplace LVM pour la tâche actuelle : le cryptage système complet. Si votre disque est partitionné en 4 partitions principales, vous devez utiliser lvm ou transformer (avec formatage) la partition principale en étendue, ou bien utiliser intelligemment les quatre partitions et tout laisser tel quel, obtenant ainsi le résultat souhaité. Même si vous avez une seule partition sur le disque, Gparted vous aidera à partitionner le HDD (en partitions supplémentaires) sans perte de données, mais tout de même avec un léger coût pour de telles actions.

Le schéma de partitionnement du disque dur, sur lequel portera la verbalisation de tout l'article, est présenté dans le tableau ci-dessous.

Tableau (n°1) des partitions 1To.

Quelque chose de similaire devrait être chez vous aussi.
sda1 — partition principale n°1 NTFS (chiffré);
sda2 — partition étendue marque ;
sda6 — disque logique (sur lequel le chargeur GRUB2 est installé);
sda8 — swap (fichier d'échange chiffré / pas toujours);
sda9 — disque logique de test;
sda5 — disque logique pour les curieux;
sda7 — OS GNU/Linux (système migré sur disque logique chiffré);
sda3 — partition principale n°2 avec OS Windows 7 (chiffré);
sda4 — partition principale n°3 (elle contenait GNU/Linux non chiffré, utilisée pour les sauvegardes / pas toujours).

[A] Cryptage système par blocs Windows 7

A1. VeraCrypt

Démarrage depuis le site officiel, ou depuis un miroir sourceforge de la version d'installation du logiciel cryptographique VeraCrypt (au moment de la publication de l'article v1.24-Update3, la version portable de VeraCrypt n'est pas adaptée pour le cryptage système). Vérifiez la somme de contrôle du logiciel téléchargé

$ Certutil -hashfile "C:VeraCrypt Setup 1.24.exe" SHA256

et comparez le résultat obtenu avec le CS publié sur le site du développeur de VeraCrypt.

Si le logiciel HashTab est installé, c'est encore plus simple : Clic droit (VeraCrypt Setup 1.24.exe)-propriétés-sommes de hachage des fichiers.

Pour vérifier la signature du programme, le logiciel et la clé publique PGP du développeur doivent être installés gnuPG; gpg4win.

A2. Installation / lancement du logiciel VeraCrypt avec des droits administratifs

A3. Choix des paramètres de cryptage système de la partition activeVeraCrypt – Système – Chiffrer la partition / disque système – Normal – Chiffrer la partition Windows – Multi-boot – (attention : « Il est déconseillé aux utilisateurs inexpérimentés d'utiliser cette méthode » et c'est vrai, nous convenons « Oui ») – Disque de démarrage ("oui", même si ce n'est pas le cas, "oui" quand même) – Nombre de disques systèmes «2 ou plus» – Plusieurs systèmes sur un même disque «Oui» – Pas de chargeur Windows «Non» (en réalité «Oui», mais les chargeurs VeraCrypt/GRUB2 ne se partageront pas le MBR, plus précisément, dans le MBR/la piste de démarrage ne contient que la plus petite partie du code du chargeur, la majeure partie se trouvant dans la zone de fichiers) – Multi-démarrage – Paramètres des options de cryptage…

Si vous vous écartez des étapes décrites ci-dessus (schémas de cryptage de disque par blocs), VeraCrypt affichera un avertissement et ne vous permettra pas de chiffrer la partition.

À l'étape suivante, pour protéger spécifiquement les données, effectuez un "test" et choisissez l'algorithme de cryptage. Si votre CPU est ancien, l'algorithme de cryptage Twofish sera probablement le plus rapide. Si le CPU est puissant, vous remarquerez la différence : AES – selon les résultats du test, le cryptage sera plusieurs fois plus rapide que ses concurrents.

VeraCrypt prend en charge le cryptage en cascade avec AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (sans support matériel pour AES, cryptage en cascade A/T) la baisse de performance est en fait imperceptible. (pour les CPU AMD de la même époque/~paramètres – la performance est légèrement réduite). Le système d'exploitation fonctionne de manière dynamique et la consommation de ressources pour le cryptage transparent est imperceptible. En revanche, par exemple, la diminution visible des performances due à un environnement de bureau de test instable comme Mate v1.20.1 (ou v1.20.2 je ne me souviens plus exactement) Dans GNU/Linux, ou en raison de l'exécution du sous-programme de télémétrie dans Windows 7. En général, les utilisateurs expérimentés effectuent des tests de performances matérielles avant le chiffrement. Par exemple, avec Aida64/Sysbench/systemd-analyze blame, ils comparent les résultats de ces mêmes tests après le chiffrement du système, réfutant ainsi le mythe selon lequel « le chiffrement des systèmes est nuisible ». Le ralentissement de la machine et les désagréments sont perceptibles lors de la sauvegarde/restauration des données chiffrées, car l'opération de « sauvegarde système des données » n'est pas mesurée en millisecondes, et il faut ajouter les opérations de <décryptage/chiffrement à la volée>. En fin de compte, chaque utilisateur autorisé à manipuler la cryptographie établit un équilibre entre l'algorithme de chiffrement, la satisfaction des tâches à accomplir, son niveau de paranoïa et la facilité d'utilisation.

Il est préférable de laisser le paramètre PIM par défaut afin de ne pas avoir à entrer les valeurs exactes d'itérations à chaque démarrage du système d'exploitation. VeraCrypt utilise un nombre élevé d'itérations pour créer un véritable « hachage lent ». Une attaque par brute force ou par tables arc-en-ciel a du sens uniquement en cas de phrase de passe « simple » courte et d'une liste de charset personnel de la victime. Le prix de la robustesse d'un mot de passe est un délai lors de l'entrée correcte du mot de passe au démarrage du système d'exploitation. (le montage des volumes VeraCrypt sous GNU/Linux est considérablement plus rapide).
Logiciel libre pour réaliser une attaque par brute force. (extraction de la phrase de passe à partir de l'en-tête du disque VeraCrypt/LUKS). Hashcat. John the Ripper ne peut pas « casser Veracrypt », et en travaillant avec LUKS, il ne comprend pas la cryptographie Twofish.

En raison de la résistance cryptographique des algorithmes de chiffrement, des hackers insatiables développent des logiciels avec un autre vecteur d'attaque. Par exemple, l'extraction de métadonnées/clés à partir de la RAM. (attaque par accès direct à la mémoire ou par méthode du 'cold boot'), il existe des logiciels libres et commerciaux spécialisés pour ces objectifs.

Une fois la configuration/génération des « métadonnées uniques » du partition chiffré active terminée, VeraCrypt proposera de redémarrer le PC et de tester le bon fonctionnement de son chargeur. Après le redémarrage/au lancement de Windows, VeraCrypt se chargera en mode attente, il ne restera plus qu'à confirmer le processus de chiffrement — Y.

À l'étape finale du chiffrement système, VeraCrypt vous proposera de créer une sauvegarde de l'en-tête de la partition chiffrée active sous la forme de « veracrypt rescue disk.iso » — c'est une étape obligatoire. Dans ce logiciel, cette opération est une exigence. (dans LUKS, c'est une exigence — c'est malheureusement omis, mais souligné dans la documentation). Le disque de secours sera utile à tous, et pour certains, pas qu'une seule fois. Si vous perdez (la réécriture de l'en-tête/MBR) la sauvegarde de l'en-tête vous privera définitivement d'accès à la partition déchiffrée avec l'OS Windows.

A4. Création d'un disque USB/de secours VeraCryptPar défaut, VeraCrypt propose de graver « les métadonnées ~2-3 Mo » sur un CD, mais tout le monde n'a pas de disques ou de lecteurs DWD-ROM, et la création d'une clé USB bootable « VeraCrypt Rescue Disk » sera pour certains une surprise technique : Rufus/GUIdd-ROSA ImageWriter et d'autres logiciels similaires ne pourront pas accomplir cette tâche, car au-delà de la simple copie des métadonnées décalées sur la clé USB, il faut procéder à un copier/coller en dehors du système de fichiers du périphérique USB, en résumé, correctement copier le MBR/partition sur la clé. Sous l'OS GNU/Linux, il est possible de créer une clé USB bootable en utilisant l'outil « dd », en se référant à ce tableau.

La création d'un disque de secours dans un environnement Windows est différente. Le développeur de VeraCrypt n'a pas inclus cette tâche dans le guide officiel documentation sur le « disque de secours », mais a proposé une solution alternative : il a mis à disposition un logiciel supplémentaire pour créer un « disque de secours USB » sur son forum VeraCrypt. L'archive de ce logiciel pour Windows – « création d'un disque de secours USB VeraCrypt ». Une fois rescue disk.iso sauvegardé, le processus de chiffrement système par blocs de la partition active commencera. Pendant le chiffrement, le fonctionnement de l'OS ne s'arrête pas, le redémarrage du PC n'est pas nécessaire. À la fin du processus de cryptage, la partition active devient entièrement chiffrée, et vous pouvez l'utiliser. Si le chargeur de démarrage VeraCrypt ne s'affiche pas au démarrage du PC, et que l'opération de récupération de l'en-tête n'aide pas, vérifiez le drapeau « boot », il doit être défini sur la partition où se trouve Windows. (indépendamment du chiffrement et des autres OS, voir tableau n°1).
Ceci termine la description du chiffrement système par blocs avec l'OS Windows.

[B] LUKS. Chiffrement GNU/Linux (~Debian) OS installé. Algorithme et étapes

Pour chiffrer une distribution Debian ou dérivée installée, il est nécessaire d'associer la partition préparée à un périphérique de bloc virtuel, de déplacer sur le disque GNU/Linux associé et d'installer/configurer GRUB2. Si vous n'avez pas un serveur nu et que vous tenez à votre temps, vous devez utiliser une interface graphique (GUI), et la plupart des commandes terminales décrites ci-dessous sont à entrer en « mode Chuck Norris ».

B1. Démarrage de l'ordinateur à partir d'une clé USB live GNU/Linux

« Effectuer un test de performance cryptographique du matériel »

lscpu && cryptsetup benchmark

Si vous êtes l'heureux propriétaire d'une machine puissante avec prise en charge matérielle d'AES, les chiffres ressembleront à la partie droite du terminal, si vous êtes chanceux mais avec un matériel ancien – à la partie gauche.

B2. Partitionnement du disque. Montage / formatage du système de fichiers logique du disque HDD en Ext4 (Gparted)

B2.1. Création de l'en-tête chiffré de la partition sda7Je vais décrire les noms des partitions, ici et à l'avenir, en fonction de ma table de partitions publiée ci-dessus. Selon votre partitionnement de disque, vous devez remplacer par vos noms de partitions.

Association du chiffrement du disque logique ( /dev/sda7 > /dev/mapper/sda7_crypt).
#Простое создание «LUKS-AES-XTS раздела»

cryptsetup -v -y luksFormat /dev/sda7

Options :

* luksFormat - initialisation de l'en-tête LUKS ;
* -y - phrase de passe (pas de clé/fichier) ;
* -v - verbosité (affichage d'informations dans le terminal) ;
* /dev/sda7 - votre disque logique de la partition étendue (là où GNU/Linux doit être transféré/chiffré).

Par défaut, l'algorithme de chiffrement <LUKS1 : aes-xts-plain64, Clé : 256 bits, hachage de l'en-tête LUKS : sha256, RNG : /dev/urandom> (dépend de la version de cryptsetup).

#Проверка default-алгоритма шифрования
cryptsetup  --help #самая последняя строка в выводе терминала.

En l'absence de prise en charge matérielle d'AES sur le processeur, le meilleur choix sera de créer une "partition LUKS-Twofish-XTS" étendue.

B2.2. Création étendue d'une "partition LUKS-Twofish-XTS"

cryptsetup luksFormat /dev/sda7 -v -y -c twofish-xts-plain64 -s 512 -h sha512 -i 1500 --use-urandom

Options :
* luksFormat - initialisation de l'en-tête LUKS ;
* /dev/sda7 votre futur disque logique chiffré ;
* -v verbosité ;
* -y phrase de passe ;
* -c choix de l'algorithme de chiffrement des données ;
* -s taille de la clé de chiffrement ;
* -h algorithme de hachage / fonction cryptographique, utilisé par le GÉNÉRATEUR DE NOMBRES ALÉATOIRES ( --use-urandom ) pour générer une clé de chiffrement/déchiffrement unique pour l'en-tête du disque logique, une clé secondaire de l'en-tête (XTS); une clé maître unique stockée dans l'en-tête chiffré du disque, une clé XTS secondaire, toutes ces métadonnées et le sous-programme de chiffrement qui, avec la clé maître et la clé XTS secondaire, chiffrent/déchiffrent n'importe quelles données sur la partition. (à l'exception de l'en-tête de la partition) sont stockées dans ~3 Mo sur la partition sélectionnée du disque dur.
* -i itérations en millisecondes, au lieu de « quantités » (délai de traitement du mot de passe, impacte le démarrage du système d'exploitation et la résistance cryptographique des clés). Pour maintenir l'équilibre de la résistance cryptographique avec un mot de passe simple tel que « russian », il faut augmenter la valeur - (i), tandis qu'avec un mot de passe complexe tel que « ?8dƱob/øfh », la valeur peut être diminuée.
* —use-urandom générateur de nombres aléatoires, génère des clés et du sel.

Après avoir associé la partition sda7 > sda7_crypt (opération rapide, car un en-tête chiffré avec des métadonnées ~3 Mo est créé et c'est tout), il faut formater et monter le système de fichiers sda7_crypt.

B2.3. Association

cryptsetup open /dev/sda7 sda7_crypt
#l'exécution de cette commande demande de saisir la phrase secrète.

options:
* open - associer la partition « avec un nom »;
* /dev/sda7 - disque logique;
* sda7_crypt - nom d'association utilisé pour monter la partition chiffrée ou son initialisation lors du démarrage du système d'exploitation.

B2.4. Formatage du système de fichiers sda7_crypt en ext4. Montage du disque dans le système d'exploitation(Remarque : dans Gparted, il ne sera plus possible de travailler avec la partition chiffrée)

#форматирование блочного шифрованного устройства
mkfs.ext4 -v -L DebSHIFR /dev/mapper/sda7_crypt 

options:
* -v - verbosité;
* -L - étiquette du disque (qui s'affiche dans l'explorateur parmi d'autres disques).

Ensuite, il faut monter le dispositif de bloc virtuel chiffré /dev/sda7_crypt dans le système

mount /dev/mapper/sda7_crypt /mnt

Travailler avec des fichiers dans le dossier /mnt entraînera un chiffrement/déchiffrement automatique des données dans sda7.

Il est plus pratique d'associer et de monter la partition dans l'explorateur (nautilus/caja GUI), la partition sera déjà dans la liste des disques disponibles, il ne restera plus qu'à entrer la phrase secrète pour ouvrir/déchiffrer le disque. Le nom associé sera sélectionné automatiquement et ne sera pas « sda7_crypt », mais quelque chose comme /dev/mapper/Luks-xx-xx…

B2.5. Sauvegarde de l'en-tête du disque (métadonnées ~3 Mo)L'une des plus importantes Les opérations à réaliser sans délai — sauvegarde de l'en-tête « sda7_crypt ». Si vous écrasez / endommagez l'en-tête (par exemple, en installant GRUB2 dans la partition sda7, etc.), les données cryptées seront définitivement perdues sans aucune possibilité de les récupérer, car il sera impossible de régénérer les mêmes clés, les clés étant créées de manière unique.

#Бэкап заголовка раздела
cryptsetup luksHeaderBackup --header-backup-file ~/Бэкап_DebSHIFR /dev/sda7 

#Восстановление заголовка раздела
cryptsetup luksHeaderRestore --header-backup-file <file> <device>

options:
* luksHeaderBackup —header-backup-file commande de sauvegarde ;
* luksHeaderRestore —header-backup-file commande de restauration ;
* ~/Backup_DebSHIFR — fichier de sauvegarde ;
* /dev/sda7 -partition pour laquelle la sauvegarde de l'en-tête du disque chiffré doit être sauvegardée.
À cette étape, <la création et l'édition d'une partition chiffrée> est terminée.

B3. Transfert du système d'exploitation GNU/Linux (sda4) vers la partition chiffrée (sda7)

Créons le dossier /mnt2 (Remarque — nous travaillons toujours avec le live USB, dans le point /mnt est montée sda7_crypt), et montons notre système GNU/Linux dans /mnt2, qui doit être chiffré.

mkdir /mnt2
mount /dev/sda4 /mnt2

Nous effectuons le transfert correct du système d'exploitation avec le logiciel Rsync

rsync -avlxhHX --progress /mnt2/ /mnt

Les options de Rsync sont décrites au point E1.

Ensuite, il est nécessaire d'effectuer une défragmentation de la partition du disque logique

e4defrag -c /mnt/ #après vérification, e4defrag indiquera que le taux de défragmentation de la partition est~"0", ce qui est une erreur qui pourrait vous coûter une perte de performance significative !
e4defrag /mnt/ #nous effectuons la défragmentation de la GNU/Linux chiffrée

Prenez l'habitude de faire e4defrag sur la GNU/Linux chiffrée de temps en temps si vous avez un HDD.
Le transfert et la synchronisation [GNU/Linux > GNU/Linux-chiffrée] à cette étape sont terminés.

V4. Configuration de GNU/Linux sur la partition chiffrée sda7

Après un transfert réussi du système d'exploitation /dev/sda4 > /dev/sda7, il est nécessaire d'entrer dans GNU/Linux sur la partition chiffrée, et de procéder aux configurations supplémentaires (sans redémarrer l'ordinateur) en ce qui concerne le système chiffré. C'est-à-dire être sur le live USB, mais exécuter les commandes « par rapport à la racine du système d'exploitation chiffré ». La simulation d'une telle situation se fait avec « chroot ». Pour obtenir rapidement des informations sur le système d'exploitation que vous utilisez actuellement (chiffré ou non, puisque les données de sda4 et sda7 sont synchronisées), désynchronisez les systèmes. Créez dans les répertoires racines (sda4/sda7_crypt) des fichiers de marqueurs vides, par exemple, /mnt/systèmeChiffré et /mnt2/systèmeDéchiffré. Une vérification rapide de quel système d'exploitation vous utilisez (y compris pour l'avenir) :

ls /<Tab-Tab>

B4.1. «Simulation de connexion à un OS chiffré»

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

B4.2. Vérification que le travail s'effectue par rapport au système chiffré

ls /mnt 
# et nous voyons le fichier "/systèmeChiffré"

history
# l'historique des commandes su du système d'exploitation doit apparaître dans la sortie du terminal.

B4.3. Création/configuration de swap chiffré, modification de crypttab/fstabÉtant donné que le fichier de swap est formaté à chaque démarrage de l'OS, il ne sert à rien de créer et de mapper le swap avec le disque logique maintenant, et de saisir des commandes comme dans p.B2.2. Pour le swap, des clés de chiffrement temporaires seront générées automatiquement à chaque démarrage. Cycle de vie des clés de swap : démontage/déconnexion de la partition swap (+ nettoyage de la RAM); ou redémarrage de l'OS. Configuration du swap, ouvrons le fichier de configuration des dispositifs chiffrés par blocs (analogique du fichier fstab, mais responsable du crypto).

nano /etc/crypttab 

modifions

#«target name» «source device» «key file» «options»
swap /dev/sda8 /dev/urandom swap,cipher=twofish-xts-plain64,size=512,hash=sha512

Options
* swap - nom mappé lors du chiffrement /dev/mapper/swap.
* /dev/sda8 - utilisez votre partition logique pour le swap.
* /dev/urandom - générateur de clés de chiffrement aléatoires pour le swap (à chaque nouveau démarrage de l'OS — création de nouvelles clés). Le générateur /dev/urandom est moins aléatoire que /dev/random, étant donné que /dev/random est utilisé dans des circonstances paranoïaques dangereuses. Au démarrage de l'OS, /dev/random ralentit le démarrage de quelques ± minutes (voir systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: - la partition sait qu'elle est swap et se formate « en conséquence » ; l'algorithme de chiffrement.

#Открываем и правим fstab
nano /etc/fstab

modifions

# swap was on /dev/sda8 during installation
/dev/mapper/swap none swap sw 0 0

/dev/mapper/swap -имя , которое задали в crypttab.

Swap chiffré alternatif
Si pour une raison quelconque vous ne souhaitez pas consacrer toute une partition à un fichier de swap, vous pouvez adopter une méthode alternative et meilleure : créer un fichier de swap dans un fichier sur la partition chiffrée avec l'OS.

fallocate -l 3G /swap # création d'un fichier de 3 Go (opération presque instantanée)
chmod 600 /swap # réglage des droits
mkswap /swap # création d'un fichier de swap à partir du fichier
swapon /swap # activons notre swap
free -m # vérifions que le fichier de swap est activé et fonctionne
printf "/swap none swap sw 0 0" >> /etc/fstab # si nécessaire après redémarrage, le swap sera permanent

Configuration de la partition de swap terminée.

B4.4. Configuration de GNU/Linux chiffré (modification des fichiers crypttab/fstab)Le fichier /etc/crypttab, comme mentionné précédemment, décrit les dispositifs chiffrés par blocs qui sont configurés lors du démarrage du système.

#правим /etc/crypttab 
nano /etc/crypttab 

si vous avez mappé la partition sda7>sda7_crypt comme dans 4. B2.1

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 none luks

si vous avez mappé la partition sda7>sda7_crypt comme dans 4. B2.2

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 none cipher=twofish-xts-plain64,size=512,hash=sha512

si vous avez mappé la partition sda7>sda7_crypt comme dans 4. B2.1 ou B2.2, mais que vous ne souhaitez pas saisir le mot de passe pour déverrouiller et démarrer le système d'exploitation, vous pouvez remplacer le mot de passe par une clé secrète/un fichier aléatoire

# «target name» «source device» «key file» «options»
sda7_crypt UUID=81048598-5bb9-4a53-af92-f3f9e709e2f2 /etc/skey luks

Description
* none indique que lors du démarrage du système d'exploitation, la saisie d'une phrase de passe secrète est requise pour déverrouiller la racine.
* UUID est l'identifiant de la partition. Pour connaître votre identifiant, entrez dans le terminal (rappel, tout au long de cette procédure, vous travaillez dans un terminal en environnement chroot, et non dans un autre terminal live usb).

fdisk -l # vérification de toutes les partitions
blkid # cela devrait ressembler à quelque chose comme ça 

/dev/sda7: UUID=«81048598-5bb9-4a53-af92-f3f9e709e2f2» TYPE=«crypto_LUKS» PARTUUID=«0332d73c-07»
/dev/mapper/sda7_crypt: LABEL=«DebSHIFR» UUID=«382111a2-f993-403c-aa2e-292b5eac4780» TYPE=«ext4»

cette ligne est visible lors de l'appel de blkid depuis le terminal live usb lorsque sda7_crypt est monté).
vous prenez l'UUID directement de votre sdaX (pas sdaX_crypt!, l'UUID sdaX_crypt sera automatiquement supprimé lors de la génération de la configuration grub.cfg).
* cipher=twofish-xts-plain64,size=512,hash=sha512 - chiffrement luks en mode avancé.
* /etc/skey - fichier-clé secret qui est substitué automatiquement pour déverrouiller le démarrage du système d'exploitation (au lieu de saisir le 3ème mot de passe). Le fichier peut être n'importe lequel jusqu'à 8 Mo, mais les données seront lues <1 Mo.

#Создание "генерация" случайного файла <секретного ключа> размером 691б.
head -c 691 /dev/urandom > /etc/skey

#Добавление секретного ключа (691б) в 7-й слот заголовка luks
cryptsetup luksAddKey --key-slot 7 /dev/sda7 /etc/skey

#Проверка слотов "пароли/ключи luks-раздела"
cryptsetup luksDump /dev/sda7 

Cela ressemblera à peu près à ceci :

(faites-le vous-même et vous verrez).

cryptsetup luksKillSlot /dev/sda7 7 # suppression de clé/mot de passe du 7ème slot

/etc/fstab содержит описательную информацию о различных файловых системах.

#Правим /etc/fstab
nano /etc/fstab

# «file system» «mount poin» «type» «options» «dump» «pass»
# / was on /dev/sda7 during installation
/dev/mapper/sda7_crypt / ext4 errors=remount-ro 0 1

option
* /dev/mapper/sda7_crypt - nom du mappage sda7>sda7_crypt, qui est spécifié dans le fichier /etc/crypttab.
Configuration de crypttab/fstab terminée.

B4.5. Édition des fichiers de configuration. Point cléB4.5.1. Édition de la configuration /etc/initramfs-tools/conf.d/resume

#Если у вас ранее был активирован swap раздел, отключите его. 
nano /etc/initramfs-tools/conf.d/resume

et commentez (si existant) la ligne «# resume». Le fichier doit être entièrement vide.

B4.5.2. Édition de la configuration /etc/initramfs-tools/conf.d/cryptsetup

nano /etc/initramfs-tools/conf.d/cryptsetup

doit correspondre

# /etc/initramfs-tools/conf.d/cryptsetup
CRYPTSETUP=yes
export CRYPTSETUP

B4.5.3. Édition de la configuration /etc/default/grub (cette configuration est responsable de la capacité à générer grub.cfg lors du travail avec un /boot chiffré)

nano /etc/default/grub

ajoutez la ligne «GRUB_ENABLE_CRYPTODISK=y»
la valeur 'y', grub-mkconfig et grub-install vérifieront la présence de disques chiffrés et généreront les commandes supplémentaires nécessaires pour y accéder pendant le démarrage (insmod-és ).
cela devrait ressembler à

GRUB_DEFAULT=0
GRUB_TIMEOUT=1
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="acpi_backlight=vendor"
GRUB_CMDLINE_LINUX=«quiet splash noautomount»
GRUB_ENABLE_CRYPTODISK=y

B4.5.4. Édition du fichier de configuration /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

Vérifiez que la ligne est commentée .
À l'avenir (et même déjà maintenant, ce paramètre n'aura aucune importance, mais parfois il empêche la mise à jour de l'image initrd.img).

B4.5.5. Édition du fichier de configuration /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

ajoutons

KEYFILE_PATTERN=»/etc/skey»
UMASK=0077

Cela emballera la clé secrète «skey» dans initrd.img, la clé est nécessaire pour déverrouiller la racine lors du démarrage du système d'exploitation (si vous ne souhaitez pas entrer le mot de passe à nouveau, la clé «skey» est automatiquement insérée).

B4.6. Mise à jour /boot/initrd.img [version]Pour emballer la clé secrète dans initrd.img et appliquer les correctifs cryptsetup, mettez à jour l'image

update-initramfs -u -k all

lors de la mise à jour de initrd.img (comme on dit «Peut-être, mais ce n'est pas sûr») des avertissements liés à cryptsetup apparaîtront, ou par exemple une notification concernant la perte de modules Nvidia - c'est un phénomène normal. Après la mise à jour du fichier, vérifiez qu'il a bien été mis à jour, consultez l'heure (par rapport à l'environnement chroot./boot/initrd.img). Attention ! avant [update-initramfs -u -k all] vérifiez que cryptsetup open /dev/sda7 sda7_crypt — c'est exactement ce nom qui doit figurer dans /etc/crypttab, sinon après le reboot, une erreur busybox apparaîtra)
À cette étape, la configuration des fichiers de configuration est terminée.

[C] Installation et configuration de GRUB2/Sécurité

C1. Si nécessaire, formatez la partition réservée pour le chargeur (la partition doit contenir au moins 20 Mo)

mkfs.ext4 -v -L GRUB2 /dev/sda6

C2. Monter /dev/sda6 dans /mntComme nous travaillons dans chroot, il n'y aura pas de répertoire /mnt2 à la racine, et le dossier /mnt sera vide.
montons la partition GRUB2

mount /dev/sda6 /mnt

Si vous avez une ancienne version de GRUB2, dans le répertoire /mnt/boot/grub/i386-pc (une autre plateforme est possible, par exemple, pas «i386-pc») les modules cryptographiques sont manquants (en bref, le dossier doit contenir des modules, y compris ces .mod : cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), dans ce cas, GRUB2 doit être réinstallé.

apt-get update
apt-get install grub2 

Important ! Lors de la mise à jour du paquet GRUB2 depuis le dépôt, à la question «de choix» sur l'emplacement d'installation du chargeur - il est nécessaire de refuser l'installation (la raison - tentative d'installation de GRUB2 - dans «MBR» ou sur live usb). Dans le cas contraire, vous endommagerez l'en-tête / le chargeur de démarrage de VeraCrypt. Après la mise à jour des paquets GRUB2 et l'annulation de l'installation, le chargeur de démarrage doit être installé manuellement sur le disque logique, et non dans le « MBR ». Si votre référentiel contient une version obsolète de GRUB2, essayez de le mettre à jour depuis le site officiel – je n'ai pas vérifié (j'ai travaillé avec des chargeurs de démarrage récents GRUB 2.02 ~BetaX).

C3. Installation de GRUB2 dans la partition étendue [sda6]Vous devez avoir la partition [p.C.2] montée

grub-install --force --root-directory=/mnt /dev/sda6

options
* —force - installe le chargeur de démarrage en contournant tous les avertissements qui existent presque toujours et bloquent l'installation (paramètre obligatoire).
* —root-directory - installe le répertoire à la racine sda6.
* /dev/sda6 - votre partition sdaX (ne manquez pas entre /mnt /dev/sda6).

C4. Création du fichier de configuration [grub.cfg]Oubliez la commande « update-grub2 », et utilisez la commande complète pour générer le fichier de configuration

grub-mkconfig -o /mnt/boot/grub/grub.cfg

après la génération / mise à jour du fichier grub.cfg, le terminal doit afficher des lignes avec les systèmes d'exploitation trouvés sur le disque (« grub-mkconfig » peut également trouver et inclure des systèmes d'exploitation à partir d'une clé USB live, si vous avez une clé USB multi-démarrage avec Windows 10 et plusieurs distributions live - c'est normal). Si le terminal est « vide », le fichier « grub.cfg » n'a pas été généré, c'est le cas où il y a des bugs dans le système GRUB (et probablement le chargeur de la branche de test du référentiel), réinstallez GRUB2 à partir de sources fiables.
L'installation et la configuration « simple » de GRUB2 sont terminées.

C5. Test de vérification du système d'exploitation GNU/Linux chiffréComplétons correctement la mission cryptographique. Quittons soigneusement le GNU/Linux chiffré (sortie de l'environnement chroot).

umount -a # démonte toutes les partitions montées de GNU/Linux chiffré
Ctrl+d # sortie de l'environnement chroot
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount -a # démonte toutes les partitions montées sur la clé USB live
reboot

Après le redémarrage, le PC doit démarrer le chargeur de VeraCrypt.


* Entrée du mot de passe pour la partition active – le chargement du système d'exploitation Windows commencera.
* Appuyer sur la touche « Esc » transférera le contrôle à GRUB2, lors du choix de GNU/Linux chiffré – un mot de passe (sda7_crypt) sera nécessaire pour déverrouiller /boot/initrd.img (si grub2 indique uuid « non trouvé » – c'est un problème du chargeur grub2, il doit être réinstallé, par exemple, à partir de la branche de test / stable et p.d.).


*Selon la façon dont vous avez configuré le système (voir p.B4.4/4.5) après avoir correctement saisi le mot de passe pour déverrouiller l'image /boot/initrd.img, il faudra un mot de passe pour démarrer le noyau/racine du système d'exploitation, ou la clé secrète «skey» sera automatiquement insérée, évitant la saisie répétée de la phrase de passe.

(capture d'écran «insertion automatique de la clé secrète»).

*Ensuite, le processus de démarrage familier de GNU/Linux avec authentification de l'utilisateur se déroulera.


*Après l'authentification de l'utilisateur et l'entrée dans le système d'exploitation, il est nécessaire de mettre à jour à nouveau /boot/initrd.img (voir B4.6).

update-initramfs -u -k all

Et dans le cas de lignes superflues dans le menu GRUB2 (depuis le démarrage du système d'exploitation avec un live usb) s'en débarrasser

mount /dev/sda6 /mnt
grub-mkconfig -o /mnt/boot/grub/grub.cfg

Résumé sur le chiffrement système de GNU/Linux :

• GNU/Linux est entièrement chiffré, y compris /boot/kernel et initrd ;
• la clé secrète est encapsulée dans initrd.img ;
• le schéma d'authentification actuel (saisie du mot de passe pour déverrouiller initrd ; mot de passe/clée au démarrage du système d'exploitation ; mot de passe d'authentification de l'utilisateur Linux).

La «configuration simple de GRUB2» pour le chiffrement système de la partition de bloc est terminée.

C6. Configuration avancée de GRUB2. Protection du chargeur par signature numérique + protection par authentificationGNU/Linux est entièrement chiffré, mais le chargeur ne peut pas être chiffré – cette condition est dictée par le BIOS. Pour cette raison, le démarrage chiffré en chaîne de GRUB2 n'est pas possible, mais un démarrage chiffré simple est possible/accessible, en matière de protection – ce n'est pas nécessaire [voir p. F].
Pour le GRUB2 «vulnérable», les développeurs ont mis en œuvre un algorithme de protection du chargeur par «signature/authentification».

• Avec la protection du chargeur par «votre signature numérique», une modification externe des fichiers ou une tentative de charger des modules supplémentaires dans ce chargeur entraînera le blocage du processus de démarrage.
• Avec la protection du chargeur par authentification pour choisir le démarrage d'une distribution ou entrer des commandes supplémentaires en CLI, il faudra saisir le nom d'utilisateur et le mot de passe du superutilisateur-GRUB2.

C6.1. Protection du chargeur par authentificationVérifiez que vous travaillez dans un terminal dans un système d'exploitation chiffré

ls / #pour détecter le fichier marqueur

créez un mot de passe de superutilisateur pour l'authentification dans GRUB2

grub-mkpasswd-pbkdf2 #saisissez/répétez le mot de passe du superutilisateur. 

Obtenez le hachage du mot de passe. Cela ressemble à quelque chose comme ça

grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8

monter la partition GRUB

mount /dev/sda6 /mnt 

éditer la configuration

nano -$ /mnt/boot/grub/grub.cfg 

vérifiez dans le fichier que dans "grub.cfg" il n'y a pas de drapeaux (" --unrestricted" "--user",
ajoutez à la fin (avant la ligne ### END /etc/grub.d/41_custom ###)
"set superusers='root'"
mot_de_passe_pbkdf2 root hash.

Cela devrait ressembler à peu près à ça

# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the ‘exec tail’ line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
set superusers='root'
mot_de_passe_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

Si vous utilisez souvent la commande "grub-mkconfig -o /mnt/boot/grub/grub.cfg" et ne souhaitez pas apporter à chaque fois des modifications à grub.cfg, ajoutez les lignes décrites ci-dessus (login/mot de passe) dans le script utilisateur GRUB tout en bas

nano /etc/grub.d/41_custom 

cat << EOF
set superusers='root'
mot_de_passe_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
EOF

Lors de la génération de la configuration "grub-mkconfig -o /mnt/boot/grub/grub.cfg", les lignes concernant l'authentification seront ajoutées automatiquement à grub.cfg.
À cette étape, la configuration de l'authentification GRUB2 est terminée.

C6.2. Protection du chargeur de démarrage par signature numériqueOn suppose que vous avez déjà votre clé PGP de chiffrement personnelle (ou créez une telle clé). Le système doit avoir installé des logiciels cryptographiques : gnuPG ; kleopatra/GPA ; Seahorse. Le logiciel crypto vous facilitera grandement la vie dans tous les cas similaires. Seahorse – version stable du paquet 3.14.0 (les versions supérieures, par exemple, V3.20 – sont incomplètes et présentent des bugs majeurs).

La clé PGP doit être générée/démarrée/ajoutée uniquement en mode su!

Générer une clé de chiffrement personnelle

gpg --gen-key

Exporter votre clé

gpg --export -o ~/perskey

Montez le disque logique dans le système d'exploitation s'il n'est pas encore monté

mount /dev/sda6 /mnt #sda6 – partition GRUB2

nettoyez la partition GRUB2

rm -rf /mnt/

Installez GRUB2 sur sda6, en mettant votre clé personnelle dans l'image principale de GRUB «core.img»

grub-install --force --modules="gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa" -k ~/perskey --root-directory=/mnt /dev/sda6

options
* --force - installe le chargeur de démarrage en contournant tous les avertissements qui existent toujours (paramètre obligatoire).
* --modules="gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa" -indique à GRUB2 de précharger les modules nécessaires au démarrage de l'ordinateur.
* -k ~/perskey - chemin vers "la clé PGP" (après avoir intégré la clé dans l'image, elle peut être supprimée).
* —root-directory -installation du répertoire boot dans la racine sda6
/dev/sda6 -ваш sdaХ раздел.

Générer/mettre à jour grub.cfg

grub-mkconfig  -o /mnt/boot/grub/grub.cfg

Ajouter à la fin du fichier «grub.cfg» la ligne «trust /boot/grub/perskey» (forcer l'utilisation de la clé pgp.) Étant donné que nous avons installé GRUB2 avec un ensemble de modules, y compris le module de signature «signature_test.mod», cela évite d'ajouter dans la config des commandes telles que «set check_signatures=enforce».

Cela devrait ressembler à peu près à ça (lignes finales dans le fichier grub.cfg)

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
trust /boot/grub/perskey
set superusers='root'
mot_de_passe_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

Il n'est pas nécessaire d'indiquer le chemin vers «/boot/grub/perskey» sur une partition de disque spécifique, par exemple hd0,6, pour le chargeur lui-même, la «racine» est considérée comme le chemin par défaut de la partition sur laquelle GRUB2 est installé. (voir set rot=..).

Signer GRUB2 (tous les fichiers dans tous les répertoires /GRUB) avec votre clé «perskey».
Une solution simple pour signer (pour l'explorateur nautilus/caja): installer l'extension «seahorse» depuis le dépôt pour l'explorateur. La clé doit être ajoutée dans l'environnement su.
Ouvrez l'explorateur avec sudo «/mnt/boot» – Clic droit – signer. Cela ressemble à ceci sur l'écran

La clé elle-même «/mnt/boot/grub/perskey» (copier dans le répertoire grub) doit également être signé par sa propre signature. Vérifiez que des signatures de fichiers [*.sig] sont apparues dans le répertoire/sous-répertoires.
De la manière décrite ci-dessus, nous signons «/boot» (nos kernel, initrd). Si votre temps a de la valeur, cette méthode évite d'écrire un script bash pour signer «de nombreux fichiers».

Pour supprimer toutes les signatures du chargeur (si quelque chose ne va pas)

rm -f $(find /mnt/boot/grub -type f -name '*.sig')

Pour ne pas avoir à signer le chargeur après la mise à jour du système, gelons tous les paquets de mise à jour liés à GRUB2.

apt-mark hold grub-common grub-pc grub-pc-bin grub2 grub2-common

À cette étape, la configuration avancée de GRUB2 est terminée.

C6.3. Test-prouvé du chargeur GRUB2, protégé par signature numérique et authentificationGRUB2. Lors de la sélection d'une distribution GNU/Linux ou de l'accès à la CLI (ligne de commande) une autorisation de super-utilisateur sera requise. Après avoir saisi le bon identifiant/mot de passe, un mot de passe pour initrd sera requis.

Capture d'écran, authentification réussie du super-utilisateur GRUB2.

Si l'un des fichiers GRUB2 est falsifié/modifié dans grub.cfg, ou si un fichier/sig est supprimé, ou si un module mod malveillant est chargé, un avertissement approprié apparaîtra. Le démarrage de GRUB2 sera suspendu.

Capture, attempt to interfere with GRUB2 'from the outside'.

During 'normal' boot 'without intrusion', the system exit status code is '0'. Therefore, it is unknown whether the protection is functioning or not. (that is, 'with boot protection signature or without it' during normal boot the status is the same '0' — this is bad).

How to check protection with a digital signature?

Inconvenient method of verification: forge/delete the used GRUB2 module, for example, delete the signature luks.mod.sig and get an error.

Correct method: enter the bootloader CLI and type the command

trust_list

In response, you should receive the 'perskey' fingerprint; if the status is '0', then the signature protection is not working, double-check item C6.2.
At this stage, the extended setting 'GRUB2 protection with digital signature and authentication' is complete.

C7 Alternative method of bootloader GRUB2 protection using hashingThe method described above 'CPU Bootloader Protection/Authentication' is classic. Due to the imperfection of GRUB2, in paranoid conditions it is susceptible to real attacks, which I will describe below in item [F]. Additionally, after updating the OS/kernel, it is necessary to re-sign the bootloader.

GRUB2 bootloader protection using hashing

Advantages over the classic approach:

• Higher level of reliability (hashing/checking only occurs with an encrypted local resource. The entire partition dedicated to GRUB2 is monitored for any changes, while everything else is encrypted; in the classical scheme with CPU bootloader protection/authentication only files are monitored, but not the free space where 'something sinister' can be written).
• Encrypted logging (a readable personal encrypted log is added to the scheme).
• Vitesse (the protection/checking of the entire partition dedicated to GRUB2 occurs almost instantly).
• Automation of all cryptographic processes.

Disadvantages compared to the classic approach.

• Signature forgery (theoretically, it is possible to find a pre-defined collision in the hash function).
• Increased level of complexity (compared to the classic approach, somewhat more skills in GNU/Linux OS are required).

How does the idea of hashing GRUB2/partition work?

La section GRUB2 est signée, lors du démarrage de l'OS, elle vérifie l'intégrité de la section du chargeur de démarrage avec un logging subséquent dans un environnement sécurisé (chiffré). En cas de compromission du chargeur de démarrage ou de sa section, en plus du log d'intrusion, un tel

élément.

Quatre fois par jour, une vérification similaire a lieu, sans alourdir les ressources système.
Avec la commande «-$ vérification_GRUB», une vérification instantanée peut être effectuée à tout moment sans logging, mais en affichant des informations dans le CLI.
Avec la commande «-$ sudo signature_GRUB», le chargeur GRUB2/la section est redémarré à la volée et son logging mis à jour (nécessaire après la mise à jour de l'OS/boot), et la vie continue.

Mise en œuvre de la méthode de hachage du chargeur et de sa section

0) Nous allons signer le chargeur/la section GRUB, après l'avoir montée dans /media/username

-$ hashdeep -c md5 -r /media/username/GRUB > /podpis.txt

1) Créons un script sans extension à la racine du système d'exploitation chiffré ~/podpis, appliquons-lui les droits nécessaires 744 de sécurité et une protection contre les erreurs.

Remplissons son contenu

#!/bin/bash

#Проверка всего раздела выделенного под загрузчик GRUB2 на неизменность.
#Ведется лог "о вторжении/успешной проверке каталога", короче говоря ведется полный лог с тройной вербализацией. Внимание! обратить взор на пути: хранить ЦП GRUB2 только на зашифрованном разделе OS GNU/Linux. 
echo -e "******************************************************************n" >> '/var/log/podpis.txt' && date >> '/var/log/podpis.txt' && hashdeep -vvv -a -k '/podpis.txt' -r '/media/username/GRUB' >> '/var/log/podpis.txt'

a=`tail '/var/log/podpis.txt' | grep failed` #не использовать "cat"!! 
b="hashdeep: Audit failed"

#Условие: в случае любых каких-либо изменений в разделе выделенном под GRUB2 к полному логу пишется второй отдельный краткий лог "только о вторжении" и выводится на монитор мигание gif-ки "warning".
if [[ "$a" = "$b" ]] 
then
echo -e "****n" >> '/var/log/vtorjenie.txt' && echo "vtorjenie" >> '/var/log/vtorjenie.txt' && date >> '/var/log/vtorjenie.txt' & sudo -u username DISPLAY=:0 eom '/warning.gif' 
fi

Lançons le script de su, une vérification du hachage de la section GRUB et de son chargeur aura lieu, sauvegardez le log.

Créons ou copions, par exemple, un « fichier malveillant » [virus.mod] dans la section GRUB2 et lançons une vérification/test temporaire :

-$ hashdeep -vvv -a -k '/podpis.txt' -r '/media/username/GRUB

Dans le CLI, nous devrions voir une intrusion dans notre -cité-#Урезанный лог в CLI

Mer Jan 2 11:41 MSK 2020
/media/username/GRUB/boot/grub/virus.mod : Déplacé de /media/username/GRUB/1nononoshifr
/media/username/GRUB/boot/grub/i386-pc/mda_text.mod : Ok
/media/username/GRUB/boot/grub/grub.cfg : Ok
hashdeep : Audit échoué
   Fichiers d'entrée examinés : 0
  Fichiers connus attendus : 0
          Fichiers correspondants : 325
Fichiers partiellement correspondants : 0
            Fichiers déplacés : 1
        Nouveaux fichiers trouvés : 0
  Fichiers connus non trouvés : 0

#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
En raison des spécificités de la section testée, au lieu de « Nouveaux fichiers trouvés » > « Fichiers déplacés »

2) Déposons un gif ici > ~/warning.gif, donnons-lui des droits 744.

3) Configurons fstab pour activer le montage automatique de la section GRUB au démarrage

-$ sudo nano /etc/fstab

LABEL=GRUB /media/username/GRUB ext4 defaults 0 0

4) Effectuons la rotation des logs

-$ sudo nano /etc/logrotate.d/podpis 

/var/log/podpis.txt {
quotidien
rotation 50
taille 5M
dateext
compress
delaycompress
olddir /var/log/old
}

/var/log/vtorjenie.txt {
mensuel
rotation 5
taille 5M
dateext
olddir /var/log/old
}

5) Ajoutons une tâche dans cron

-$ sudo crontab -e

reboot ‘/podpis’
0 */6 * * * ‘/podpis

6) Créons des alias permanents

-$ sudo su
-$ echo "alias signature_GRUB='hashdeep -c md5 -r /media/username/GRUB > /podpis.txt'" >> /root/.bashrc && bash
-$ echo "alias vérification_GRUB='hashdeep -vvv -a -k '/podpis.txt' -r /media/username/GRUB'" >> .bashrc && bash

Après la mise à jour de l'OS -$ apt-get upgrade nous resignerons notre section GRUB
-$ signature_GRUB
À cette étape, la protection par hachage de la section GRUB est terminée.

[D] Nettoyage — destruction des données non chiffrées

Supprimez vos fichiers personnels de telle sorte que « même Dieu ne puisse les lire », selon le représentant de la Caroline du Sud, Trey Gowdy.

Comme d'habitude, il existe différents « mythes et légendes» concernant la récupération des données après leur suppression sur un disque dur. Si vous croyez à la cybermagie ou êtes un fidèle de la communauté Dr Web et n'avez jamais essayé de récupérer des données après leur suppression/écrasement (par exemple, récupération avec R-Studio), alors la méthode proposée est peu susceptible de vous convenir, utilisez ce qui vous parle le plus.

Après le transfert réussi de GNU/Linux sur une partition chiffrée, l'ancienne copie doit être supprimée sans possibilité de récupération des données. La méthode universelle de nettoyage : logiciel pour Windows/Linux, logiciel GUI gratuit BleachBit.
Rapidement formatez la partition, dont les données doivent être détruites (avec GParted), lancez BleachBit, sélectionnez « Nettoyage de l'espace libre » – sélectionnez la partition (votre sdaX avec l'ancienne copie de GNU/Linux), le processus de nettoyage va commencer. BleachBit — nettoie le disque en un seul passage — c'est ce que « nous avons besoin », mais ! cela fonctionne seulement en théorie, si vous avez formaté le disque et nettoyé avec le logiciel BB v2.0.

Attention! BB nettoie le disque, laissant des métadonnées, les noms de fichiers sont conservés lors de la suppression des données (Ccleaner — ne laisse pas de métadonnées).

Et le mythe de la possibilité de récupération des données n'est pas tout à fait un mythe.Bleachbit V2.0-2 était un paquet instable d'OS Debian (et tout autre logiciel similaire : sfill ; wipe-Nautilus - ont également été remarqués dans cette tâche sale) avait réellement une erreur critique : la fonction « nettoyage gratuit de l'espace » ne fonctionne pas correctement sur HDD/Clés USB (ntfs/ext4).Ce type de logiciel, lors du nettoyage de l'espace libre, ne réécrit pas tout le disque, comme beaucoup d'utilisateurs le pensent. Et certains (beaucoup) de données supprimées que le système d'exploitation/logiciel considère comme non supprimées/utilisateur et lors du nettoyage de « l'espace libre », ces fichiers sont omis. Le problème est qu'après un nettoyage aussi long les « fichiers supprimés » peuvent être récupérés même après 3+ passes de nettoyage du disque.
Sur GNU/Linux dans BleachBit 2.0-2 Les fonctions de suppression définitive de fichiers et de répertoires fonctionnent de manière fiable, mais il n'y a pas d'effacement de l'espace libre. Pour comparaison : sous Windows, dans l'application CCleaner, la fonction « OSP pour ntfs » fonctionne correctement, et même Dieu ne pourra pas lire les données supprimées.

Ainsi, pour supprimer définitivement des données « compromettantes » non chiffrées anciennes, un accès direct de Bleachbit à ces données est requis, ensuite, utilisez la fonction « suppression de fichiers/répertoires de manière définitive ».
Pour supprimer les « fichiers supprimés par les outils système » sous Windows, utilisez CCleaner/BB avec la fonction « OSP ». Sous GNU/Linux, concernant ce problème (suppression de fichiers supprimés) vous devez vous entraîner par vous-même (suppression de données + tentative de récupération par vous-même, et ne comptez pas sur la version du logiciel (s'il n'y a pas de backdoor, alors c'est un bug)), seulement dans ce cas, vous pourrez comprendre le mécanisme de ce problème et vous débarrasser définitivement des données supprimées.

Bleachbit v3.0 n'a pas été testé, le problème a peut-être déjà été corrigé.
Bleachbit v2.0 fonctionne honnêtement.

À cette étape, le « nettoyage du disque » est terminé.

[E] Sauvegarde universelle des systèmes d'exploitation chiffrés

Chaque utilisateur a sa propre méthode de sauvegarde des données, mais les données chiffrées des « systèmes d'exploitation » nécessitent une approche légèrement différente. Les logiciels unifiés, tels que « Clonezilla » et des logiciels similaires, ne peuvent pas travailler directement avec des données chiffrées.

Présentation du problème de la sauvegarde des périphériques de blocs chiffrés :

1. universalité — un même algorithme/logiciel de sauvegarde pour Windows/Linux ;
2. capacité à travailler dans le terminal avec n'importe quelle live usb GNU/Linux sans avoir besoin de télécharger un logiciel supplémentaire (mais je recommande tout de même un GUI);
3. sécurité des sauvegardes — les « images » stockées doivent être chiffrées/protégées par mot de passe ;
4. la taille des données chiffrées doit correspondre à la taille des données réellement copiées ;
5. extraction pratique des fichiers nécessaires de la sauvegarde (absence d'exigence de déchiffrement de tout le volume au préalable).

Par exemple, sauvegarde/récupération via l'outil « dd »

dd if=/dev/sda7 of=/chemin/sda7.img bs=7M conv=sync,noerror
dd if=/chemin/sda7.img of=/dev/sda7 bs=7M conv=sync,noerror

Correspond à presque tous les points de la tâche assignée, mais au point 4, il est critiquable car il copie l'intégralité de la section du disque, y compris l'espace libre — ce qui est sans intérêt.

Par exemple, la sauvegarde GNU/Linux via l'archiveur [tar» | gpg] est pratique, mais pour une sauvegarde Windows, il faut chercher une autre solution — ce qui est sans intérêt.

E1. Sauvegarde universelle Windows/Linux. Lien rsync (Grsync)+VeraCrypt volumeAlgorithme de création d'une sauvegarde :

1. création d'un conteneur chiffré (volume/fichier) VeraCrypt pour OS;
2. transfert/synchronisation de l'OS à l'aide de Rsync dans le conteneur crypté VeraCrypt;
3. si nécessaire, chargement du volume VeraCrypt sur www.

La création d'un conteneur chiffré VeraCrypt possède ses spécificités :
création d'un volume dynamique (la création de VD n'est possible que sous Windows, utilisable aussi sous GNU/Linux);
création d'un volume ordinaire, mais il y a une exigence de caractère « paranoïaque » (selon le développeur) – formatage du conteneur.

Le volume dynamique se crée pratiquement instantanément sous Windows, mais lors de la copie de données depuis l'OS GNU/Linux > VeraCrypt VD, la performance de l'opération de sauvegarde diminue considérablement.

Un volume ordinaire Twofish de 70 Go se crée (disons, sur une puissance moyenne de PC) sur HDD ~ en une demi-heure (écriture des anciennes données du conteneur en un seul passage, en raison de l’exigence de sécurité). VeraCrypt a supprimé la fonction de formatage rapide du volume lors de sa création, donc la création d'un conteneur n'est possible que par « écriture en un seul passage », ou création d'un volume dynamique peu performant.

Créons un volume ordinaire VeraCrypt (pas dynamique/ntfs), aucun problème ne devrait survenir.

Configurons/créons/ouvrons le conteneur dans VeraCrypt GUI > GNU/Linux live usb (le volume sera monté automatiquement dans /media/veracrypt2, le volume de l'OS Windows est monté dans /media/veracrypt1). Créons une sauvegarde chiffrée de l'OS Windows à l'aide de l'interface graphique rsync (grsync), en cochant les cases.

Attendre la fin du processus. À l'issue de la sauvegarde, nous aurons un fichier chiffré.

Créer de même une sauvegarde de l'OS GNU/Linux, en décochant la case dans l'interface graphique rsync « compatibilité avec Windows ».

Attention! le conteneur Veracrypt pour « sauvegarde GNU/Linux » doit être créé dans le système de fichiers ext4.. Si vous faites une sauvegarde dans un conteneur ntfs, alors lors de la restauration de cette copie, vous perdrez tous les droits/groupes sur toutes vos données.

Toutes les opérations peuvent également être effectuées dans le terminal. Les options principales pour rsync :
* -g – conserver les groupes ;
* -P —progress — état du temps de traitement du fichier ;
* -H – copier les liens physiques tels quels ;
* -a – mode archive (plusieurs drapeaux rlptgoD);
* -v – verbosité.

Si vous souhaitez monter le « volume Windows VeraCrypt » via la console dans le logiciel cryptsetup, vous pouvez créer un alias (su)

echo "alias veramount='cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sdaX Windows_crypt && mount /dev/mapper/ Windows_crypt /media/veracrypt1'" >> .bashrc && bash

Maintenant, en exécutant la commande « veramount pictures », une demande de saisie de phrase secrète apparaîtra, et le volume système Windows chiffré sera monté sur l'OS.

Commande pour associer/monter le volume système VeraCrypt dans cryptsetup

cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sdaX Windows_crypt
mount /dev/mapper/Windows_crypt /mnt

Commande pour associer/monter une partition/conteneur VeraCrypt dans cryptsetup

cryptsetup open --veracrypt --type tcrypt /dev/sdaY test_crypt
mount /dev/mapper/test_crypt /mnt

Au lieu de l'alias, ajoutons (script au démarrage) le volume système avec l'OS Windows et le disque logique chiffré ntfs au démarrage de GNU/Linux

Créons un script et sauvegardons-le dans ~/VeraOpen.sh

printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sda3 Windows_crypt && mount /dev/mapper/Windows_crypt /media/Winda7 #décodage du mot de passe depuis base64 (bob) et envoi au prompt de saisie de mot de passe lors du montage du volume système Windows.
printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --type tcrypt /dev/sda1 ntfscrypt && mount /dev/mapper/ntfscrypt /media/ConteneurNtfs #de la même manière, mais nous montons le disque logique ntfs.

Attribuons les « bons » droits :

sudo chmod 100 /VeraOpen.sh

Créons deux fichiers identiques (même nom !) dans /etc/rc.local et ~/etc/init.d/rc.local
Remplissons les fichiers

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will «exit 0» on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sh -c "sleep 1 && '/VeraOpen.sh'" #после загрузки ОС, ждём ~ 1с и только потом монтируем диски.
exit 0

Attribuons les « bons » droits :

sudo chmod 100 /etc/rc.local && sudo chmod 100 /etc/init.d/rc.local 

Voilà, maintenant au démarrage de GNU/Linux, nous n'avons pas à entrer de mots de passe pour monter les disques chiffrés ntfs, les disques se montent automatiquement.

Remarque brève sur ce qui a été décrit ci-dessus dans l'E1 par étapes (mais maintenant pour l'OS GNU/Linux)
1) Créer un volume dans le système de fichiers ext4 > 4Go (pour le fichier) Linux dans Veracrypt [Coffre-fort].
2) Reboot sur live usb.
3) ~$ cryptsetup open /dev/sda7 Lunux #association de la partition chiffrée.
4) ~$ mount /dev/mapper/Linux /mnt #montage de la partition chiffrée dans /mnt.
5) ~$ mkdir mnt2 #création d'un répertoire pour la future sauvegarde.
6) ~$ cryptsetup open --veracrypt --type tcrypt ~/Coffre-fort Coffre-fort && mount /dev/mapper/Coffre-fort /mnt2 #Association du volume Veracrypt nommé « Coffre-fort » et montage de Coffre-fort dans /mnt2.
7) ~$ rsync -avlxhHX --progress /mnt /mnt2/ #opération de sauvegarde de la partition chiffrée dans le volume Veracrypt chiffré.

(p/s/ Attention! Si vous transférez un système GNU/Linux chiffré d'une architecture ou d'une machine à une autre, par exemple, d'Intel à AMD (c'est-à-dire que vous déployez une sauvegarde d'une partition chiffrée sur une autre partition chiffrée Intel à AMD), n'oubliez pas après le transfert du système d'exploitation chiffré de modifier la clé secrète intégrée au lieu du mot de passe, car l'ancienne clé ~ /etc/skey - ne conviendra plus à une autre partition chiffrée, et il n'est pas souhaitable de créer une nouvelle clé avec «cryptsetup luksAddKey» depuis un environnement chroot - cela pourrait causer un bug, indiquez simplement dans ~ /etc /crypttab à la place de «/etc/skey» temporairement «none», après le redémarrage et la connexion au système d'exploitation, recréez à nouveau votre clé secrète intégrée.

En tant que vétérans de l'informatique, nous ne devons pas oublier de faire des sauvegardes séparées des en-têtes des partitions chiffrées des systèmes d'exploitation Windows/Linux, sinon le chiffrement se retournera contre vous-même.
À ce stade, la sauvegarde des systèmes d'exploitation chiffrés est terminée.

[F] Attaque sur le chargeur GRUB2

DétailsSi vous avez protégé votre chargeur par une signature numérique et/ou une authentification (voir p.C6.), alors l'accès physique ne protégera pas contre cela. Les données chiffrées resteront inaccessibles, mais il existe un contournement pour la protection (réinitialisation de la protection par signature numérique) GRUB2 permet à un cybercriminel d'injecter son code dans le chargeur, sans éveiller de soupçons (sauf si l'utilisateur suit manuellement l'état du chargeur, ou ne conçoit pas son propre code de script robuste pour grub.cfg).

Algorithme d'attaque. L'attaquant

* Démarre un PC avec un USB live. Tout changement (par l'intrus) des fichiers entraînera une alerte au vrai propriétaire du PC concernant l'intrusion dans le chargeur. Cependant, une simple réinstallation de GRUB2 tout en conservant grub.cfg (et la possibilité de l'éditer par la suite) permettra à l'attaquant d'éditer n'importe quel fichier (dans cette situation, lors du démarrage de GRUB2, aucune alerte ne sera envoyée au véritable utilisateur. Le statut reste le même )
* Monte une partition non chiffrée, conserve «/mnt/boot/grub/grub.cfg» chez lui.
* Réinstalle le chargeur (en éliminant «perskey» de l'image core.img)

grub-install --force --root-directory=/mnt /dev/sda6

* Récupère «grub.cfg» > «/mnt/boot/grub/grub.cfg», l'édite si nécessaire, par exemple en ajoutant son module «keylogger.mod» dans le dossier des modules de chargeur, dans «grub.cfg» > la ligne «insmod keylogger». Ou, par exemple, si l'ennemi est sournois, alors après la réinstallation de GRUB2 (toutes les signatures restent en place) Il assemble l'image principale de GRUB2 en utilisant «grub-mkimage avec l'option (-s).» L'option «-s» permettra de charger votre configuration avant le chargement du fichier principal «grub.cfg». La configuration peut se composer d'une seule ligne : redirection vers un «modern.cfg», mélangé, par exemple, avec ~400 fichiers. (modules+signatures) dans le dossier «/boot/grub/i386-pc». À ce stade, un attaquant peut injecter du code arbitraire et charger des modules, sans toucher à «/boot/grub/grub.cfg», même si l'utilisateur a appliqué «hashsum» au fichier et l'a temporairement affiché à l'écran.
Il n'est pas nécessaire pour un attaquant de casser le login/mot de passe super-utilisateur de GRUB2, il lui suffira de recopier les lignes (responsables de l'authentification) «/boot/grub/grub.cfg» dans son «modern.cfg»

set superusers='root'
mot_de_passe_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8

Et pour le propriétaire du PC, la vérification de l'authenticité de l'utilisateur super de GRUB2 continuera de s'appliquer.

Chargement en chaîne (le chargeur charge un autre chargeur), comme mentionné ci-dessus, n'a pas de sens (elle est destinée à un autre but). En raison de l'BIOS, il n'est pas possible de charger un chargeur crypté. (avec un chargement en chaîne, GRUB2 est redémarré > GRUB2 crypté, erreur !). Cependant, si l'on utilise malgré tout l'idée du chargement en chaîne, il est possible de s'assurer que le chargeur qui est effectivement chargé est celui qui est crypté (non modernisé) «grub.cfg» depuis la partition cryptée. Et c'est aussi une fausse sensation de sécurité, car tout ce qui est spécifié dans le «grub.cfg» crypté (chargement de modules) s'additionne avec les modules qui sont chargés depuis GRUB2 non crypté.

Si vous souhaitez le vérifier, créez/crypez une autre partition sdaY, copiez-y GRUB2 (l'opération grub-install sur une partition cryptée est impossible) et dans «grub.cfg» (configuration non cryptée) modifiez les lignes similaires à celles-ci

menuentry ‘GRUBx2’ —class parrot —class gnu-linux —class gnu —class os $menuentry_id_option ‘gnulinux-simple-382111a2-f993-403c-aa2e-292b5eac4780’ {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod cryptodisk
insmod luks
insmod gcry_twofish
insmod gcry_twofish
insmod gcry_sha512
insmod ext2
cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838
set root=’cryptouuid/15c47d1c4bd34e5289df77bcf60ee838’
normal /boot/grub/grub.cfg
}

lignes
* insmod -chargement des modules nécessaires pour fonctionner avec le disque crypté ;
* GRUBx2 -nom de la ligne affichée dans le menu de démarrage de GRUB2 ;
* cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838 -voir fdisk -l (sda9) ;
* set root -définition de la racine ;
* normal /boot/grub/grub.cfg -fichier de configuration exécutable sur la partition cryptée.

L'assurance que c'est bien le « grub.cfg » crypté qui se charge est une réponse positive à l'entrée du mot de passe / déblocage de « sdaY » lors de la sélection de la ligne « GRUBx2 » dans le menu GRUB.

Lors de l'utilisation de l'interface en ligne de commande, afin de ne pas se perdre (et de vérifier si la variable d'environnement « set root » a fonctionné), créez des fichiers vides comme marqueurs, par exemple dans la partition chiffrée « /shifr_grub », et dans la partition non chiffrée « /noshifr_grub ». Vérifiez dans l'interface en ligne de commande

cat /Tab-Tab

Comme mentionné précédemment, cela n'empêchera pas le chargement de modules malveillants si de tels modules se trouvent sur votre PC. Par exemple, un keylogger qui pourrait enregistrer les frappes au clavier dans un fichier et se mélanger avec d'autres fichiers dans « ~/i386 », jusqu'à ce qu'il soit téléchargé par un attaquant ayant un accès physique au PC.

Le moyen le plus simple de vérifier que la protection par signature numérique fonctionne activement (n'est pas réinitialisée), et que personne n'a interféré avec le chargeur, nous saisissons la commande dans l'interface en ligne de commande

list_trusted

nous recevons en réponse une empreinte de notre « perskey », ou rien ne s'affiche si nous avons été attaqués (il est également nécessaire de vérifier « set check_signatures=enforce »).
Un inconvénient majeur de cette étape est de taper les commandes manuellement. Si vous ajoutez cette commande dans « grub.cfg » et protégez le fichier de configuration par une signature numérique, alors l'affichage préliminaire de l'empreinte de la clé à l'écran est trop court dans le timing, et il se peut que vous n'ayez pas le temps de voir le résultat, aboutissant au chargement de GRUB2.
Il n'y a pas vraiment de réclamations à formuler : le développeur déclara dans son documentation paragraphe 18.2

« Notez que même avec la protection par mot de passe de GRUB, GRUB lui-même ne peut pas empêcher quelqu'un ayant un accès physique à la machine de modifier la configuration du firmware de cette machine (par exemple, Coreboot ou BIOS) pour faire démarrer la machine à partir d'un autre appareil (contrôlé par l'attaquant). GRUB est au mieux un maillon dans une chaîne de démarrage sécurisé ».

GRUB2 est trop surchargé de fonctionnalités, pouvant donner un faux sentiment de sécurité, et son développement a déjà dépassé en fonctionnalité le système d'exploitation MS-DOS, alors qu'il ne s'agit que d'un chargeur. Il est ironique que GRUB2 — « demain » pourrait devenir un système d'exploitation, tandis que les machines virtuelles GNU/Linux y sont chargées.

Une courte vidéo sur comment j'ai contourné la protection par signature numérique de GRUB2 et signalé mon intrusion à un utilisateur réel (on a eu peur, et à la place de ce qui est montré dans la vidéo – on pourrait écrire un code / .mod peu inoffensif).

Conclusions :

1) Le chiffrement des systèmes de fichiers par blocs pour Windows est plus facile à réaliser, et la protection par un seul mot de passe est plus pratique que la protection par plusieurs mots de passe lors du chiffrement des systèmes de fichiers par blocs sous GNU/Linux, pour être équitable : le dernier est automatisé.

2) L'article a été écrit comme un guide pertinent et détaillé simple pour le chiffrement intégral des disques VeraCrypt/LUKS sur une machine à domicile, qui est, à ce jour, le meilleur sur le web (à mon avis). Le guide fait plus de 50 000 caractères, donc certaines sections intéressantes n'ont pas été couvertes : sur les cryptographes qui disparaissent/restent dans l'ombre ; sur le fait que peu ou pas de livres GNU/Linux parlent de cryptographie ; sur l'article 51 de la constitution russe ; sur la licence/запрете du chiffrement en Russie, concernant l'importance de chiffrer la « racine/boot ». Le guide est déjà assez long, mais détaillé (décrivant même les étapes simples), ce qui vous fera gagner beaucoup de temps lorsque vous vous attaquerez à un « véritable chiffrement ».

3) Le chiffrement intégral des disques a été effectué sur Windows 7 64 ; GNU/Linux Parrot 4x ; GNU/Debian 9.0/9.5.

4) J'ai réalisé une attaque réussie sur mon chargeur GRUB2.

5) Ce tutoriel a été créé pour aider tous les paranoïaques de la CEI, où le travail avec le chiffrement est légalement autorisé. Et en premier lieu pour ceux qui souhaitent mettre en œuvre un chiffrement intégral sans effacer leurs systèmes configurés.

6) J'ai retravaillé et mis à jour mon guide, qui est d'actualité en 2020.

[G] Documentation utile

1. Manuel de l'utilisateur TrueCrypt (février 2012 RU)
2. Documentation VeraCrypt
3. /usr/share/doc/cryptsetup(-run) [локальный ресурс] (documentation officielle détaillée sur la configuration du chiffrement GNU/Linux avec cryptsetup)
4. FAQ officielle cryptsetup (documentation succincte sur la configuration du chiffrement GNU/Linux avec cryptsetup)
5. Chiffrement de périphérique LUKS (documentation archlinux)
6. Description détaillée de la syntaxe cryptsetup (page du manuel arch)
7. Description détaillée de crypttab (page du manuel arch)
8. Documentation officielle GRUB2.

Mots-clés : chiffrement total du disque, chiffrement de partition, chiffrement intégral Linux, chiffrement total du système LUKS1.

Seuls les utilisateurs enregistrés peuvent participer au sondage. Connectez-vous, s'il vous plaît.

Vous chiffrez ?

• 17,1%Je chiffre tout ce qui est possible. J'ai de la paranoïa.14

• 34,2%Je chiffre seulement les données importantes.28

• 14,6%Parfois je chiffre, parfois j'oublie.12

• 34,2%Non, je ne chiffre pas, c'est inconfortable et coûteux.28

82 utilisateurs ont voté. 22 utilisateurs se sont abstenus.

Source : habr.com