🥇Full disk encryption for installed Windows and Linux systems. Encrypted multi-boot

Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot
Updated guide on full disk encryption in the RuNet V0.2.

Cowboy strategy:

[A] block system encryption for Windows 7 installed system;
[B] block system encryption for GNU/Linux (Debian) installed system (including /boot);
[C] GRUB2 configuration, bootloader protection via digital signature/authentication/hashing;
[D] wiping - destroying unencrypted data;
[E] universal backup for encrypted OS;
[F] attack target - GRUB2 bootloader;
[G] useful documentation.

╭───Room scheme #40# :
├──╼ Windows 7 installed - full system encryption, not hidden;
├──╼ GNU/Linux installed (Debian and derivative distributions) — full system encryption not hidden(/, including /boot; swap);
├──╼ independent bootloaders: VeraCrypt bootloader installed in MBR, GRUB2 bootloader installed in the extended partition;
├──╼ OS installation/reinstallation is not required;
└──╼ used cryptographic software: VeraCrypt; Cryptsetup; GnuPG; Seahorse; Hashdeep; GRUB2 – free/open-source.

The above scheme partially solves the issue of 'external boot on USB', allowing the enjoyment of encrypted Windows/Linux OS and exchanging data over an 'encrypted channel' from one OS to another.

Boot order for PC (one of the options):

turning on the machine;
loading the VeraCrypt bootloader (correct password entry will continue loading Windows 7);
pressing the 'Esc' key will load the GRUB2 bootloader;
GRUB2 bootloader (selecting distribution/GNU/Linux/CLI), will require GRUB2 superuser authentication ;
after successful authentication and distribution selection, entering the passphrase will be required to unlock '/boot/initrd.img';
after entering the correct passwords in GRUB2, 'it will require' entering the password (the third in a row, BIOS password or user account password for GNU/Linux - not considered) to unlock and load the GNU/Linux OS, or automatic insertion of the secret key (two passwords + key, or password + key);
external interference in GRUB2 configuration will freeze the GNU/Linux boot process.

Cumbersome? Okay, let's automate processes.

When partitioning the hard drive (MBR table) A PC can have no more than 4 primary partitions, or 3 primary and one extended, as well as an unallocated space. An extended partition, unlike a primary one, can contain subpartitions. (logical disks=extended partition). In other words, the 'extended partition' on the HDD replaces LVM for the current task: full system encryption. If your disk is partitioned into 4 primary partitions, you need to use lvm, or transform (with formatting) the partition from primary to extended, or skillfully use all four partitions and leave everything as is, achieving the desired result. Even if you have only one partition on the disk, Gparted can help split the HDD (into additional partitions) without data loss, but still with a slight price to pay for such actions.

The disk partitioning scheme, regarding which the entire article will be verbalized, is presented in the table below.

Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot
Table (No. 1) of 1TB partitions.

Something similar should be the case for you.
sda1 — primary partition No. 1 NTFS (encrypted);
sda2 — extended partition marker;
sda6 — logical disk (where the GRUB2 bootloader is installed);
sda8 — swap (encrypted swap file/not always);
sda9 — test logical disk;
sda5 — logical disk for the curious;
sda7 — OS GNU/Linux (migrated OS to an encrypted logical disk);
sda3 — primary partition No. 2 with Windows 7 OS (encrypted);
sda4 — primary partition No. 3 (where unencrypted GNU/Linux was located, used for backup/not always).

[A] Block-level system encryption for Windows 7

A1. VeraCrypt Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

Booting from the official website, or from a mirror sourceforge of the installation version of the cryptographic software VeraCrypt (at the time of publication of the article v1.24-Update3, the portable version of VeraCrypt is not suitable for system encryption).Check the checksum of the downloaded software

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

and compare the obtained result with the published checksum on the VeraCrypt developer's website.

If HashTab software is installed, it’s even simpler: right-click (VeraCrypt Setup 1.24.exe)-properties-file hash sums.

To verify the program's signature, the developer's software and public pgp key must be installed in the system. gnuPG; gpg4win.

A2. Installation/running VeraCrypt software with administrative rights Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

A3. Selecting the parameters for system encryption of the active partitionVeraCrypt – System – Encrypt the system partition/disk – Standard – Encrypt the Windows system partition – Multi-boot – (warning: "This method is not recommended for inexperienced users" and it is true, we agree "Yes") – Bootable disk ("yes", even if not so, still "yes") – Number of system disks "2 or more" – Multiple systems on one disk "Yes" – Non-Windows bootloader "No" (in fact "Yes", but the VeraCrypt/GRUB2 bootloaders do not share the MBR, more precisely, only the smallest part of the bootloader code is stored in the MBR/boot track, the main part is located within the file system) – Multi-boot – Encryption parameter settings…

If you deviate from the steps outlined above (block system encryption schemes), VeraCrypt will issue a warning and will not allow you to encrypt the partition.

In the next step, towards targeted data protection, conduct a "Test" and choose an encryption algorithm. If you have an outdated CPU, it's likely that the Twofish encryption algorithm will turn out to be the fastest. If the CPU is powerful, you will notice the difference: AES – encryption according to test results will be several times faster than its cryptographic competitors. AES is a popular encryption algorithm, and modern CPU hardware is specifically optimized for both "secrecy" and "cracking."

VeraCrypt supports the ability to cascade encrypt disks with AES(Twofish)/и другими комбинациями. На старо-ядерном CPU Intel десятилетней давности (without AES hardware support, cascade encryption A/T) performance degradation is essentially unnoticeable. (on CPUs of the same era/parameters from AMD – performance is slightly reduced). The OS operates dynamically and resource consumption for transparent encryption is unnoticeable. In contrast, noticeable performance degradation occurs due to the installed unstable desktop environment Mate v1.20.1 (or v1.20.2, I don't remember exactly) In GNU/Linux, or due to the telemetry subroutine running in Windows 7. Experienced users usually perform hardware performance tests prior to encryption. For example, in Aida64/Sysbench/systemd-analyze blame, they compare with the results of the same tests after the system is encrypted, thereby disproving the myth that 'full system encryption is harmful.' The slowdown and inconvenience are noticeable during the backup/restoration of encrypted data because the operation of 'system data backup' is not measured in milliseconds, and the need to is added. Ultimately, every user allowed to engage in cryptography establishes a balance of the encryption algorithm relative to the satisfaction of set tasks, their degree of paranoia, and usability.

It is better to leave the PIM parameter at its default so that precise iteration values do not need to be entered every time the OS boots. VeraCrypt uses a large number of iterations to create a truly 'slow hash.' Attacking such 'crypto toolkit' with brute force/rainbow table methods only makes sense for short 'simple' passphrases and a personal charset list of the victim. The cost of password strength is a delay when correctly entering the password during OS boot. (mounting VeraCrypt volumes in GNU/Linux is significantly faster).
Free software for implementing a brute force attack (extracting a passphrase from the header of a VeraCrypt/LUKS disk) Hashcat. John the Ripper cannot 'crack VeraCrypt' and does not understand Twofish cryptography when working with LUKS.

Due to the cryptographic strength of encryption algorithms, unstoppable cryptographers develop software with a different attack vector. For example, extracting metadata/keys from RAM (cold boot attack/direct memory access), there is specialized free and proprietary software for these purposes.

Upon completing the setup/generation of 'unique metadata' for the encrypted active partition, VeraCrypt will prompt you to reboot the PC and test the functionality of its bootloader. After rebooting/starting Windows, VeraCrypt will load in standby mode; you just need to confirm the encryption process — Y.

At the final step of VeraCrypt system encryption, it will prompt to create a backup of the header of the active encrypted partition as "veracrypt rescue disk.iso" — this must be done without fail — in this software, such an operation is a requirement. (in LUKS, as a requirement – this is unfortunately omitted but highlighted in the documentation). The rescue disk will be useful for everyone, and for some, more than once. Losing (overwriting the header/MBR) the backup of the header will permanently deprive access to the decrypted partition with Windows OS.

A4. Creating a VeraCrypt Rescue USB/DiskBy default, VeraCrypt suggests burning "metadata ~2-3MB" onto a CD, but not everyone has CDs or DVD-ROM drives, and creating a bootable flash drive "VeraCrypt Rescue disk" will come as a technical surprise for some: Rufus/GUIDe-ROSA ImageWriter and similar software will not be able to handle the task, because besides copying the shifted metadata onto the bootable flash drive, it is necessary to make a copy/paste from the image outside the file system of the USB drive, in short, to correctly copy the MBR/track to the stick. Under GNU/Linux OS, a bootable flash drive can be created using the "dd" utility, referring to this table.

Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

Creating a rescue disk in a Windows environment is different. The VeraCrypt developer did not include a solution for this task in the official documentation on "rescue disk", but offered a solution through another way: they posted additional software for creating a "USB rescue disk" for free access on their VeraCrypt forum. The archiver of this software for Windows – "creating usb veracrypt rescue disk". After saving rescue disk.iso, the process of block system encryption of the active partition will begin. During encryption, the OS operation does not stop, and a PC reboot is not required. Upon completion of the encryption operation, the active partition becomes fully encrypted, and you can use it. If the VeraCrypt loader does not appear when starting the PC, and the header recovery operation does not help, check the "boot" flag; it must be set on the partition where Windows is present. (regardless of encryption and other OS, see table No. 1).
This concludes the description of block system encryption with Windows OS.

[B] LUKS. Encryption GNU/Linux (~Debian) installed OS. Algorithm and Steps

To encrypt an installed Debian/derived distribution, you need to map the prepared partition to a virtual block device, transfer it to the mapped disk of GNU/Linux, and install/configure GRUB2. If you're not using a bare server and value your time, you should use the GUI; most terminal commands described below are intended to be executed in 'Chuck Norris mode.'

B1. Boot the PC from a live USB of GNU/Linux

Conduct a crypto test for hardware performance

lscpu && cryptsetup benchmark

Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

If you are a lucky owner of a powerful machine with hardware support for AES, the numbers will resemble the right side of the terminal; if you are fortunate but have antique hardware, they will look like the left side.

B2. Disk partitioning. Mounting/formatting the file system of the logical HDD partition to Ext4 (Gparted)

B2.1. Create an encrypted header for partition sda7I will describe partition names here and below according to my partition table provided above. Based on your disk partitioning, you should substitute your partition names.

Mapping logical disk encryption ( /dev/sda7 > /dev/mapper/sda7_crypt ).
#Простое создание «LUKS-AES-XTS раздела»

cryptsetup -v -y luksFormat /dev/sda7

Options:

* luksFormat - initializes the LUKS header;
* -y - passphrase (not key/file);
* -v - verbosity (outputs information in the terminal);
* /dev/sda7 - your logical disk from the extended partition (where the transfer/encryption of GNU/Linux is planned).

By default, the encryption algorithm <LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom> (depends on the version of cryptsetup).

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

In the absence of hardware support for AES on the CPU, the best choice will be to create an extended 'LUKS-Twofish-XTS partition.'

B2.2. Extended creation of 'LUKS-Twofish-XTS partition'

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

Options:
* luksFormat - initializes the LUKS header;
* /dev/sda7 your future encrypted logical disk;
* -v verbosity;
* -y passphrase;
* -c selection of the data encryption algorithm;
* -s size of the encryption key;
* -h hashing algorithm/cryptographic function, used for RNG ( --use-urandom ) for generating a unique encryption/decryption key for the disk header, the secondary header key (XTS); a unique master key stored in the encrypted disk header, a secondary XTS key, all these metadata and the encryption subroutine that uses the master key and the secondary XTS key to encrypt/decrypt any data on the partition (except for the partition header) are stored in ~3MB on the selected hard disk partition.
* -i iterations in milliseconds, instead of 'amount' (time delay when processing the passphrase, affects OS boot and key cryptographic strength). To maintain the balance of cryptographic strength with a simple password like 'russian', it is necessary to increase the value of -(i); with a complex password like '?8dƱob/øfh', the value can be decreased.
* —use-urandom random number generator, generates keys and salt.

After mapping the partition sda7 > sda7_crypt (the operation is quick, as an encrypted header with ~3MB of metadata is created and that’s it), it is necessary to format and mount the file system sda7_crypt.

B2.3. Mapping

cryptsetup open /dev/sda7 sda7_crypt
# executing this command prompts for the secret passphrase.

options:
* open - map the partition 'with name';
* /dev/sda7 - logical disk;
* sda7_crypt - mapping name used for mounting the encrypted partition or initializing it during OS boot.

B2.4. Formatting the sda7_crypt file system to ext4. Mounting the disk in the OS(Note: working with the encrypted partition in Gparted will no longer be possible)

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

options:
* -v - verbosity;
* -L - label of the disk (which appears in the explorer among other disks).

Next, the virtual-encrypted block device /dev/sda7_crypt should be mounted in the system

mount /dev/mapper/sda7_crypt /mnt

Working with files in the /mnt folder will automatically encrypt/decrypt data in sda7.

It is more convenient to map and mount the partition in the explorer (nautilus/caja GUI), the partition will already be in the list of disk choices; you just need to enter the passphrase for opening/decrypting the disk. The mapped name will be chosen automatically and will not be 'sda7_crypt', but something like /dev/mapper/Luks-xx-xx…

B2.5. Backing up the disk header (metadata ~3MB)One of the most important operations that must be carried out without delay — backup of the header "sda7_crypt". If the header is overwritten/damaged (for example, by installing GRUB2 in partition sda7, etc.), the encrypted data will be lost permanently without any chance of recovery, as it will be impossible to regenerate the identical keys, the keys are created uniquely.

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

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

options:
* luksHeaderBackup —header-backup-file backup command;
* luksHeaderRestore —header-backup-file restore command;
* ~/Backup_DebSHIFR — backup file;
* /dev/sda7 - partition whose encrypted header backup needs to be saved.
At this step is complete.

B3. Transferring GNU/Linux OS (sda4) to the encrypted partition (sda7)

Create the folder /mnt2 (Note — we are still working with live usb, partition sda7_crypt is mounted at /mnt), and we mount our GNU/Linux to /mnt2, which needs to be encrypted.

mkdir /mnt2
mount /dev/sda4 /mnt2

Conduct a proper OS transfer using Rsync software

rsync -avlxhHX --progress /mnt2/ /mnt

Rsync options are described in section E1.

Next, acquire defragment the logical disk partition

e4defrag -c /mnt/ # after checking, e4defrag will report that the defragmentation degree of the partition~"0", this is a misconception that can cost you significant performance loss!
e4defrag /mnt/ # perform defragmentation of the encrypted GNU/Linux

Make it a rule to periodically run e4defrag on encrypted GNU/Linux if you have HDD.
The transfer and synchronization [GNU/Linux > GNU/Linux-encrypted] is now complete.

B4. Configuring GNU/Linux on the encrypted partition sda7

After successfully transferring the OS /dev/sda4 > /dev/sda7, you need to enter GNU/Linux on the encrypted partition, and perform further configuration (without rebooting the PC) regarding the encrypted system. This means to remain in live usb, but execute commands "relative to the root of the encrypted OS". A simulation of such a situation will be "chroot". To quickly get information about which OS you are currently working with (whether encrypted or not, as the data in sda4 and sda7 are synchronized), desynchronize the OSs. Create empty marker files in the root directories (sda4/sda7_crypt) for example, /mnt/encryptedOS and /mnt2/decryptedOS. A quick check of which OS you are in (including for the future):

ls /

B4.1. "Simulating entry into the encrypted OS"

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

B4.2. Verification that operations are performed with respect to the encrypted system

ls /mnt 
#and we see the file "/encryptedOS"

history
#the command history of the working OS should appear in the terminal output.

B4.3. Creating/configuring encrypted swap, editing crypttab/fstabSince the swap file is formatted every time the OS starts, it makes no sense to create and associate swap with the logical disk now, and fill in the commands as in item B2.2. For Swap, its temporary encryption keys will be generated automatically at each startup. Lifecycle of the swap keys: unmounting/disabling the swap partition. (+clearing RAM); or restarting the OS. Setting up swap, we open the file responsible for configuring block encrypted devices. (similar to the fstab file, but responsible for crypto).

nano /etc/crypttab

we edit

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

Options
* swap -name associated with encryption /dev/mapper/swap.
* /dev/sda8 -use your logical partition for swap.
* /dev/urandom -random key generation for swap (with each new OS boot — newly created keys). The generator /dev/urandom is less random than /dev/random, after all /dev/random is used in dangerous paranoid circumstances. When booting the OS, /dev/random can delay the boot by several ± minutes. (see systemd-analyze).
* swap,cipher=twofish-xts-plain64,size=512,hash=sha512: -the partition knows it is swap and is formatted "accordingly"; the encryption algorithm.

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

we edit

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

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

Alternative encrypted swap
If for some reason you do not want to allocate an entire partition for the swap file, you can take an alternative and better approach: create a swap file in a file on the encrypted partition with the OS.

fallocate -l 3G /swap #creating a file of size 3GB (almost instantaneous operation)
chmod 600 /swap #setting permissions
mkswap /swap #creating a swap file from the file
swapon /swap #activating our swap
free -m #checking that the swap file is activated and working
printf "/swap none swap sw 0 0" >> /etc/fstab #if necessary, will be permanent swap after reboot

The swap partition configuration is complete.

B4.4. Configuring encrypted GNU/Linux (editing crypttab/fstab files)The file /etc/crypttab, as mentioned earlier, describes encrypted block devices that are configured during system boot.

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

if the partition sda7 was mapped to sda7_crypt as in item B2.1

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

if you mapped the partition sda7>sda7_crypt as in p.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

if you mapped the partition sda7>sda7_crypt as in p.B2.1 or B2.2, but do not want to re-enter the password to unlock and boot the OS, you can instead use a secret key/random file

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

Description
* none - indicates that at OS boot, entering the secret passphrase is required to unlock the root.
* UUID - the identifier of the partition. To find your identifier, type in the terminal (reminder, that all this time and henceforth, you are working in the terminal in a chroot environment, not in another live usb terminal).

fdisk -l #check all partitions
blkid #should return something like this

/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»

this line is visible when querying blkid from the live usb terminal with sda7_crypt mounted).
Take the UUID exactly from your sdaX (not sdaX_crypt!, the UUID sdaX_crypt will automatically be removed when generating the grub.cfg config).
* cipher=twofish-xts-plain64,size=512,hash=sha512 - luks encryption in extended mode.
* /etc/skey - the secret key file which is automatically used to unlock the OS boot (instead of entering the 3rd password). The file can be any size up to 8MB, but data will be read at <1MB.

#Создание "генерация" случайного файла <секретного ключа> размером 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

It will look something like this:

(do it yourself and you will see).

cryptsetup luksKillSlot /dev/sda7 7 #removing the key/password from slot 7

/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

to move the navigation bar to the bottom or top of the screen.
* /dev/mapper/sda7_crypt - name mapping sda7>sda7_crypt, which is specified in the file /etc/crypttab.
The setup of crypttab/fstab is complete.

B4.5. Editing configuration files. Key pointB4.5.1. Editing the config /etc/initramfs-tools/conf.d/resume

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

and comment out (if it exists) the line «#» resume. The file should be completely empty.

B4.5.2. Editing the config /etc/initramfs-tools/conf.d/cryptsetup

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

should match

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

B4.5.3. Editing the config /etc/default/grub (this config is responsible for the ability to generate grub.cfg when working with encrypted /boot)

nano /etc/default/grub

add the line «GRUB_ENABLE_CRYPTODISK=y»
the value ‘y’, grub-mkconfig and grub-install will check for the presence of encrypted disks and generate additional commands needed for their access during boot (insmod-ы <cryptomount/set root>).
should be something like

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. Editing the config /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

check that the line is commented out .
In the future (and even right now, this parameter will have no effect, but sometimes it prevents updating the initrd.img image).

B4.5.5. Editing the config /etc/cryptsetup-initramfs/conf-hook

nano /etc/cryptsetup-initramfs/conf-hook

add

KEYFILE_PATTERN=»/etc/skey»
UMASK=0077

This will package the secret key 'skey' into initrd.img, the key is needed to unlock the root during OS boot (if you do not want to re-enter the password, the key 'skey' is automatically provided).

B4.6. Update /boot/initrd.img [version]To package the secret key into initrd.img and apply cryptsetup fixes, update the image

update-initramfs -u -k all

when updating initrd.img (as they say, 'Maybe, but not for sure') there will be warnings related to cryptsetup, or, for example, notifications about missing Nvidia modules — this is normal. After updating the file, check that it has indeed been updated see by time (regarding the chroot environment./boot/initrd.img). Attention! before [update-initramfs -u -k all] make sure that cryptsetup open /dev/sda7 sda7_crypt — this is the name that should appear in /etc/crypttab, otherwise after rebooting there will be a busybox error)
At this stage, the configuration file setup is complete.

[C] Installing and Configuring GRUB2/Security

C1. If necessary, format the dedicated partition for the bootloader (the partition needs at least 20MB)

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

C2. Mounting /dev/sda6 to /mntSince we are working in chroot, there will be no /mnt2 directory in the root, and the /mnt folder will be empty.
mounting the GRUB2 partition

mount /dev/sda6 /mnt

If you have an old version of GRUB2, in the directory /mnt/boot/grub/i-386-pc (a different platform is possible, for example, not 'i386-pc') missing cryptomodules (in short, the folder should contain modules including these .mod: cryptodisk; luks; gcry_twofish; gcry_sha512; signature_test.mod), in this case, GRUB2 needs to be refreshed.

apt-get update
apt-get install grub2

Important! During the update of the GRUB2 package from the repository, when asked 'where to install' the bootloader – you must refuse installation (the reason — attempts to install GRUB2 — in 'MBR' or on live usb). Otherwise you will damage the header/loader of VeraCrypt. After updating the GRUB2 packages, and canceling the installation, the bootloader needs to be installed manually on the logical disk, not in the 'MBR'. If your repository has an outdated version of GRUB2, try updating its official website – unverified (worked with fresh GRUB 2.02 ~BetaX loaders).

C3. Installing GRUB2 in the extended partition [sda6]You must have the partition [p.C.2] mounted

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

options
* —force - installs the bootloader, bypassing all warnings that usually exist and block the installation (mandatory flag).
* —root-directory - sets the <boot/grub> directory at the root of sda6.
* /dev/sda6 - your sdaX partition (do not skip <space> between /mnt /dev/sda6).

C4. Creating the configuration file [grub.cfg]Forget about the command "update-grub2", and use the full command to generate the configuration file

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

after the generation/update of the grub.cfg file is complete, there should be lines in the terminal output with OS found on the disk ("grub-mkconfig" may detect and pick up OS from a live USB if you have a multiboot USB stick with Windows 10 and many live distributions — this is normal). If the terminal is "empty", the file "grub.cfg" was not generated, then this is the case when there are bugs in the GRUB system (and most likely the bootloader is from the testing branch of the repository), reinstall GRUB2 from reliable sources.
The installation of the "simple configuration" and GRUB2 setup is complete.

C5. Proof-test of the encrypted GNU/Linux OSCorrectly completing the cryptomission. Carefully exit the encrypted GNU/Linux (exit the chroot environment).

umount -a #unmount all mounted partitions of the encrypted GNU/Linux
Ctrl+d #exit the chroot environment
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount -a #unmount all mounted partitions on the live USB
reboot

After rebooting, the VeraCrypt bootloader should start.
Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

*Entering the password for the active partition – the OS Windows will start loading.
*Pressing the "Esc" key will transfer control to GRUB2, when selecting encrypted GNU/Linux – a password (sda7_crypt) will be required to unlock /boot/initrd.img (if grub2 reports uuid "not found" – this is a grub2 bootloader issue, it should be reinstalled, for example, from the testing branch/stable and pd).
Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

*Depending on how you configured the system (see p.B4.4/4.5) after correctly entering the password to unlock the /boot/initrd.img image, a password will be needed to load the kernel/root OS, or the secret key "skey" will be automatically provided, eliminating the need to re-enter the passphrase.
Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot
(screenshot "automatic insertion of the secret key").

*Next will be the familiar GNU/Linux loading process with user account authentication.
Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

*After the user is authorized and logged into the OS, it is necessary to update /boot/initrd.img again. (see V4.6).

update-initramfs -u -k all

In case there are extra lines in the GRUB2 menu (from the OS catch with live usb) remove them

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

Summary of system encryption in GNU/Linux:

GNU/Linux is fully encrypted, including /boot/kernel and initrd;
the secret key is packed in initrd.img;
current authorization scheme (entering a password to unlock initrd; password/key for OS boot; password for Linux account authentication).

The 'Simple GRUB2 Configuration' system encryption of the block partition is complete.

C6. Advanced GRUB2 Configuration. Bootloader protection with digital signature + authentication protectionGNU/Linux is fully encrypted, but the bootloader cannot be encrypted – this condition is dictated by the BIOS. For this reason, chain encrypted loading with GRUB2 is impossible, but simple chain loading is possible/available; in terms of protection – it is not necessary [see P. F].
For the 'vulnerable' GRUB2, developers have implemented a bootloader protection algorithm 'with signature/authentication'.

With bootloader protection 'by its own digital signature', any external modification of files, or attempts to load additional modules in this bootloader – will lead the loading process to a lock.
With bootloader authentication protection, to select the loading of any distribution, or enter additional commands in the CLI, you will need to enter the superuser-GRUB2 login and password.

C6.1. Bootloader protection with authenticationEnsure that you are working in the terminal in the encrypted OS

ls / #find marker file

create a superuser password for authentication in GRUB2

grub-mkpasswd-pbkdf2 #enter/reenter the superuser password.

Obtain the password hash. Something like this

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

mounting GRUB partition

mount /dev/sda6 /mnt

editing config

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

check file search to ensure that there are no flags (" —unrestricted" "—user" in 'grub.cfg'
add at the very end (before the line ### END /etc/grub.d/41_custom ###)
"set superusers='root'"
password_pbkdf2 root hash.

It should look something like this

# 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"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

If you often use the command "grub-mkconfig -o /mnt/boot/grub/grub.cfg" and do not want to make changes in grub.cfg every time, add the above lines (login/password) to the user script of GRUB at the very bottom

nano /etc/grub.d/41_custom

cat << EOF
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
EOF

When generating the config "grub-mkconfig -o /mnt/boot/grub/grub.cfg", the lines responsible for authentication will be automatically added to grub.cfg.
At this step, the GRUB2 authentication configuration is complete.

C6.2. Protecting the bootloader with a digital signatureIt is assumed that you already have your personal encryption pgp-key (or create such a key). The system should have cryptographic software installed: gnuPG; kleopatra/GPA; Seahorse. Crypto software will greatly simplify your life in all such matters. Seahorse is the stable version of package 3.14.0 (versions higher, for example, V3.20 – are incomplete and have significant bugs).

The PGP key must be generated/started/added only in the su environment!

Generate a personal encryption key

gpg --gen-key

Export your key

gpg --export -o ~/perskey

Mount the logical disk in the OS if it is not already mounted

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

clear the GRUB2 partition

rm -rf /mnt/

Install GRUB2 in sda6, placing your personal key in the main GRUB image "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 - installs the bootloader, skipping all warnings that always exist (mandatory flag).
* --modules="gcry_sha256 gcry_sha512 signature_test gcry_dsa gcry_rsa" - instructs GRUB2 to preload the necessary modules during the PC boot.
* -k ~/perskey - path to the "PGP key" (after packing the key into the image, it can be deleted).
* --root-directory - sets the boot directory to the root of sda6
/dev/sda6 -ваш sdaХ раздел.

Generate/update grub.cfg

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

Add the line "trust /boot/grub/perskey" to the end of the "grub.cfg" file (force use the pgp key). Since we installed GRUB2 with a set of modules, including the signature module "signature_test.mod", this eliminates the need to add commands like "set check_signatures=enforce" to the config.

It should look something like this (ending lines in the grub.cfg file)

### 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"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8
### END /etc/grub.d/41_custom ###
#

The path to «/boot/grub/perskey» does not need to specify a specific disk partition, for instance hd0,6, as the bootloader considers the 'root' to be the default path to the partition where GRUB2 is installed. (see set rot=..).

Signing GRUB2 (all files in all directories /GRUB) with your key «perskey».
A simple solution to sign (for file manager nautilus/caja): install the 'seahorse' extension from the repository for the file manager. Your key should be added in the su environment.
Open the file manager with sudo «/mnt/boot» – right-click – sign. In the screenshot, it looks like this

Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

The key «/mnt/boot/grub/perskey» (copy to the grub directory) must also be signed with its own signature. Check that signatures of files [*.sig] have appeared in the directory/subdirectories.
Using the method described above, sign «/boot» (our kernel, initrd). If your time is worth anything, this method eliminates the need to write a bash script for signing 'multiple files'.

To remove all bootloader signatures (if something went wrong)

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

To avoid signing the bootloader after updating the system, freeze all update packages related to GRUB2.

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

At this stage, the advanced GRUB2 configuration is complete.

C6.3. Proof-test of the GRUB2 bootloader protected by digital signature and authenticationGRUB2. When selecting any GNU/Linux distribution or entering the CLI (command line) superuser authorization will be required. After entering the correct username/password, the initrd password will be needed.

Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot
Screenshot of the successful authentication of the GRUB2 superuser.

If any of the GRUB2 files are faked/modified in grub.cfg, or a file/signature is deleted, or a malicious module.mod is loaded, an appropriate warning will appear. The GRUB2 boot process will be halted.

Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot
Screenshot of an attempt to interfere with GRUB2 'from the outside'.

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

How to check the protection by a digital signature?

An awkward way to check: fake/delete the used GRUB2 module, for example, delete the signature luks.mod.sig and get an error.

A proper way: enter the bootloader CLI and type the command

trust_list

A fingerprint of "perskey" should be returned. If the status is "0", it means that the signature protection is not working; please recheck section C6.2.
At this step, the advanced configuration of "GRUB2 protection with digital signature and authentication" is complete.

C7 Alternative method of protecting the GRUB2 bootloader through hashingThe method described above, "CPU bootloader protection/authentication," is classic. Due to GRUB2's shortcomings, in paranoid conditions, it is vulnerable to a real attack, which I will describe below in section [F]. Additionally, after updating the OS/kernel, it is necessary to re-sign the bootloader.

GRUB2 bootloader protection through hashing

Advantages over the classic approach:

Higher level of reliability (hashing/checking occurs only with encrypted local resources. The entire partition allocated for GRUB2 is monitored for changes, while everything else is encrypted. In the classic scheme with CPU bootloader protection/authentication, only files are monitored, but not the free space where "something malicious" could be added).
Encrypted logging (a human-readable personal encrypted log is added to the scheme).
Speed (the protection/check of the entire partition allocated for GRUB2 occurs almost instantly).
Automation of all cryptographic processes.

Disadvantages compared to the classic approach.

Signature spoofing (theoretically, it's possible to find a given collision of the hash function).
Increased complexity (compared to the classic approach, slightly more skills in using the GNU/Linux OS are required).

How the idea of hashing GRUB2/partition works

The GRUB2 partition is "signed"; during OS boot, the integrity of the bootloader partition is checked with subsequent logging in a secure (encrypted) environment. In case of a compromise of the bootloader or its partition, in addition to the intrusion log, a mechanism is initiated.

Thing. Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

A similar check occurs four times a day, which does not burden system resources.
Using the command "-$ check_GRUB", an instant check can be performed at any time without logging, but with information output to CLI.
Using the command "-$ sudo sign_GRUB", the GRUB2/partition bootloader is instantly re-signed and its updated logging is performed (necessary after the OS/boot update), and life goes on.

Implementation of the bootloader and its partition hashing method

0) We will sign the GRUB bootloader/partition after mounting it at /media/username

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

1) Create a script without an extension in the root of the encrypted OS ~/podpis, applying the necessary 744 security rights and protection against 'fool-proofing'.

Fill it with content

#!/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

Run the script from su, there will be a check of the GRUB partition and its bootloader hashing, save the log.

Create or copy, for example, a 'malicious file' [virus.mod] to the GRUB2 partition and run a temporary check/testing:

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

In the CLI, we should see the intrusion into our -citadel-#Урезанный лог в CLI

Wed Jan 2 11:41 MSK 2020
/media/username/GRUB/boot/grub/virus.mod: Moved from /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 failed
   Input files examined: 0
  Known files expecting: 0
          Files matched: 325
Files partially matched: 0
            Files moved: 1
        New files found: 0
  Known files not found: 0

#как видим появилось «Files moved: 1 и Audit failed» означает, что проверка не прошла.
Due to the peculiarities of the tested partition, instead of 'New files found' > 'Files moved'

2) Place the gif here > ~/warning.gif, set permissions to 744.

3) Configure fstab for automatic mounting of the GRUB partition at startup

-$ sudo nano /etc/fstab

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

4) Perform log rotation

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

/var/log/podpis.txt {
daily
rotate 50
size 5M
dateext
compress
delaycompress
olddir /var/log/old
}
/var/log/vtorjenie.txt {
monthly
rotate 5
size 5M
dateext
olddir /var/log/old
}

5) Add a cron job

-$ sudo crontab -e

reboot '/podpis'
0 */6 * * * '/podpis

6) Create permanent aliases

-$ sudo su
-$ echo "alias подпись_GRUB='hashdeep -c md5 -r /media/username/GRUB > /podpis.txt'" >> /root/.bashrc && bash
-$ echo "alias проверка_GRUB='hashdeep -vvv -a -k '/podpis.txt' -r /media/username/GRUB'" >> .bashrc && bash

After the OS update -$ apt-get upgrade re-sign our GRUB partition
-$ подпись_GRUB
At this step, the hashing protection of the GRUB partition is completed.

[D] Cleaning — destroying unencrypted data

Delete your personal files so completely that 'even God cannot read them', as stated by South Carolina representative Trey Gowdy.

As usual, there are various 'myths and legends', about data recovery after deletion from a hard drive. If you believe in cyber magic, or are a parishioner of the Dr. Web community and have never tried data recovery after deletion/overwriting. (for example, recovery with R-studio), then the proposed method is unlikely to suit you; use what is closer to your needs.

After successful migration of GNU/Linux to the encrypted partition, the old copy must be deleted beyond recovery. A universal method for cleaning: software for Windows/Linux, free GUI software. BleachBit.
Fast format the partition, the data on which needs to be destroyed (using Gparted), launch BleachBit, select 'Free Space Cleaning' – choose the partition (your sdaX with the old copy of GNU/Linux), a cleaning process will start. BleachBit wipes the disk in one pass — this is what 'we need', but! this only works in theory if you have formatted the disk and cleaned it with BB v2.0.

Attention! BB wipes the disk, leaving metadata, file names are retained when deleting data (Ccleaner does not leave metadata).

And the myth of the possibility of data recovery is not entirely a myth.Bleachbit V2.0-2 was an unstable package of the Debian OS (and any other similar software: sfill; wipe-Nautilus - also noted in this dirty business) actually had a critical bug: the 'free space cleaning' function does not work correctly on HDDs/Flash drives (ntfs/ext4). Such software when cleaning free space does not overwrite the entire disk, as many users think. And some (a lot) deleted data the OS/software considers these data as not deleted/user files and skip these files during 'Freespace' cleaning. The problem is that after such a long disk cleaning 'deleted files' can be restored even after 3+ passes of wiping the disk.
On GNU/Linux, Bleachbit 2.0-2 reliably operates the functions of irreversible deletion of files and directories, but not the cleaning of free space. In comparison, on Windows, CCleaner’s 'Freespace for ntfs' function works properly, and God truly cannot read deleted data.

So, to thoroughly remove 'compromising' old unencrypted data, direct access of Bleachbit to this data is necessary,then use the 'delete files/directories irreversibly' function.
To delete 'deleted files using standard OS tools' in Windows, use CCleaner/BB with the 'Freespace' function. In GNU/Linux, on this issue (deleting deleted files) you need to gain practical experience yourself (deleting data + trying to recover them yourself and do not rely on the software version (if it’s not a backdoor, then it's a bug)), only then will you understand the mechanism of this problem and permanently get rid of the deleted data.

Bleachbit v3.0 has not been checked, the problem may have already been fixed.
Bleachbit v2.0 works honestly.

At this step, the 'disk cleanup' is complete.

[E] Universal backup of encrypted OS

Each user has their own method of data backup, but encrypted data of 'System OS' requires a slightly different approach. Unified software, such as 'Clonezilla' and similar tools cannot work directly with encrypted data.

Task setting for backing up encrypted block devices:

universality — the same algorithm/software for backing up Windows/Linux;
the ability to work in the console with any live usb GNU/Linux without the need to download additional software (but I still recommend GUI);
backup security — stored 'images' must be encrypted/password-protected;
the size of the encrypted data should match the size of the actual data being copied;
easy extraction of needed files from the backup (without the requirement to decrypt the entire partition first).

For example, backup/recovery through the 'dd' utility

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

Meets almost all points of the task set, but fails on point 4 as it copies the entire disk partition, including free space — which is irrelevant.

For example, GNU/Linux backup via archiver [tar|gpg] is convenient, but for Windows backup you need to look for another solution — not interesting.

E1. Universal backup for Windows/Linux. Combination of rsync (Grsync)+VeraCrypt volumeBackup creation algorithm:

creating an encrypted container (volume/file) VeraCrypt for OS;
transferring/synchronization of OS using Rsync software into the VeraCrypt crypt-container;
if necessary, loading the VeraCrypt volume at www.

Creating an encrypted VeraCrypt container has its peculiarities:
creating a dynamic volume (dynamic volume creation is only available in Windows, can be used in GNU/Linux as well);
creating a regular volume, but there is a 'paranoid nature' requirement (according to the developer's words) – formatting the container.

A dynamic volume is created almost instantly in Windows OS, but when copying data from GNU/Linux OS > VeraCrypt DT, the overall performance of the backup operation decreases significantly.

A regular Twofish volume of 70 GB is created (let's say, on a mid-range PC) on HDD in about half an hour (rewriting the old data of the container in one pass, due to security requirements). In VeraCrypt Windows/Linux, the quick formatting feature for the volume during its creation has been removed, so creating a container is only possible through 'one-pass rewriting', or creating a low-performing dynamic volume.

Creating a regular VeraCrypt volume (not dynamic/ntfs), no problems should arise.

Setting up/creating/opening a container in VeraCrypt GUI > GNU/Linux live usb (the volume will be automounted at /media/veracrypt2, the Windows OS volume is mounted at /media/veracrypt1). Creating an encrypted backup of Windows OS using the GUI rsync (grsync), checking the boxes.

Full disk encryption for Windows and Linux installed systems. Encrypted multi-boot

Wait for the process to finish. Once the backup is complete, we will have one encrypted file.

Similarly, create a backup of GNU/Linux OS, unchecking the 'Windows compatibility' box in the GUI rsync.

Attention! Create a Veracrypt container for 'GNU/Linux backup' in the file system ext4. If you make a backup in an NTFS container, you will lose all permissions/groups on all your data when restoring such a copy.

All operations can also be done in the terminal. Basic options for rsync:
* -g --preserve groups;
* -P --progress -- status of the time spent on the file;
* -H --copy hard links as is;
* -a --archive mode (several flags rlptgoD);
* -v --verbosity.

If you want to mount the 'Windows VeraCrypt volume' through the console in the cryptsetup software, you can create an 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

Now, by entering the command 'veramount pictures,' you will be prompted to enter the passphrase, and the encrypted Windows system volume will be mounted in the OS.

To mount the system volume VeraCrypt in cryptsetup use the command

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

To mount a partition/container VeraCrypt in cryptsetup use the command

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

Instead of an alias, we will add a system volume with Windows OS and a logical encrypted ntfs disk to the GNU/Linux autostart (script in autostart).

We create a script and save it in ~/VeraOpen.sh.

printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --tcrypt-system --type tcrypt /dev/sda3 Windows_crypt && mount /dev/mapper/Windows_crypt /media/Winda7 # Decoding the password from base64 (bob) and sending it to the password prompt for mounting the Windows system disk.
printf 'Ym9i' | base64 -d | cryptsetup open --veracrypt --type tcrypt /dev/sda1 ntfscrypt && mount /dev/mapper/ntfscrypt /media/ContainerNTFS # Similarly, but we mount the logical ntfs disk.

Setting the 'correct' permissions:

sudo chmod 100 /VeraOpen.sh

We create two identical files (same name!) in /etc/rc.local and ~/etc/init.d/rc.local.
Filling the files

#!/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

Setting the 'correct' permissions:

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

That's it, now when booting GNU/Linux we don't need to enter passwords to mount encrypted ntfs disks, the disks mount automatically.

A brief note about what has been described above in p.E1 step by step (but now for OS GNU/Linux).
1) Create a volume in fs ext4 > 4gb (for file) Linux in Veracrypt [Cryptobox].
2) Reboot into live usb.
3) ~$ cryptsetup open /dev/sda7 Linux # mapping the encrypted partition.
4) ~$ mount /dev/mapper/Linux /mnt # mounting the encrypted partition to /mnt.
5) ~$ mkdir mnt2 # creating a directory for future backup.
6) ~$ cryptsetup open --veracrypt --type tcrypt ~/Cryptobox Cryptobox && mount /dev/mapper/Cryptobox /mnt2 # Mapping the Veracrypt volume named 'Cryptobox' and mounting the Cryptobox to /mnt2.
7) ~$ rsync -avlxhHX --progress /mnt /mnt2/ # Backup operation of the encrypted partition to the encrypted Veracrypt volume.

(p/s/ Attention! If you are transferring an encrypted GNU/Linux from one architecture/machine to another, for example, Intel > AMD (that is, restoring a backup from one encrypted partition to another Intel > AMD encrypted partition), do not forget after transferring the encrypted OS to edit the secret injected key instead of the password, as the previous key ~/etc/skey will not fit the other encrypted partition, and creating a new key with 'cryptsetup luksAddKey' is undesirable from under chroot — there may be glitches, just indicate temporarily 'none' instead of '~/etc/skey' in ~/etc/crypttab, after reboot and logging into the OS, recreate your secret injected key again).

As IT veterans, we must remember to separately back up the headers of the encrypted partitions of Windows/Linux OS, or the encryption will turn against you.
At this stage, the backup of encrypted OS is complete.

[F] Attack on the GRUB2 Bootloader

DetailsIf you have secured your bootloader with a digital signature and/or authentication (see p.C6.), then physical access will not protect against this. Encrypted data will still be inaccessible, but bypassing the protection (resetting the digital signature protection) GRUB2 allows a cybercriminal to inject their code into the bootloader without raising suspicion (unless the user manually tracks the bootloader's status or creates their own durable arbitrary-script code for grub.cfg).

Attack Algorithm. The attacker

* Boots the PC with a live USB. Any modification (by the intruder) of files will alert the legitimate owner of the PC about the intrusion into the bootloader. However, a simple reinstallation of GRUB2 while retaining grub.cfg (and subsequently being able to edit it) allows the attacker to edit any files (in this scenario, upon loading GRUB2, there will not be an alert to the real user. The status remains )
* Mounts the unencrypted partition, saving "\/mnt\/boot\/grub\/grub.cfg".
* Reinstalls the bootloader (discarding the "perskey" from the core.img image)

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

* Returns "grub.cfg" > "\/mnt\/boot\/grub\/grub.cfg", editing it if necessary, for example, by adding their module "keylogger.mod" to the bootloader's modules folder, in "grub.cfg" > the line "insmod keylogger". Or, for example, if the enemy is crafty, then after reinstalling GRUB2 (all signatures remain in place) they collect the main GRUB2 image using "grub-mkimage with the option (-s)." The option "-s" will allow loading their config before the main "grub.cfg" is loaded. The config can consist of just one line: redirecting to any "modern.cfg", mixed, for example, with ~400 files (modules + signatures) in the folder "\/boot\/grub\/i386-pc". In this case, the intruder can insert arbitrary code and load modules without touching "\/boot\/grub\/grub.cfg", even if the user has applied "hashsum" to the file and temporarily displayed it on the screen.
The attacker will not need to hack the superuser GRUB2 login/password; they will only need to copy the lines (responsible for authentication) "\/boot\/grub\/grub.cfg" to their "modern.cfg"

set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DE10E42B01BB6FEEE46250FC5F9C3756894A8476A7F7661A9FFE9D6CC4D0A168898B98C34EBA210F46FC10985CE28277D0563F74E108FCE3ACBD52B26F8BA04D.27625A4D30E4F1044962D3DD1C2E493EF511C01366909767C3AF9A005E81F4BFC33372B9C041BE9BA904D7C6BB141DE48722ED17D2DF9C560170821F033BCFD8

And the PC owner will still be subject to the superuser GRUB2 authentication check.

Chain loading (a loader loads another loader), as mentioned above, makes no sense (it is intended for another purpose)Due to the BIOS, it is impossible to load an encrypted bootloader (when chain loading occurs, GRUB2 restarts > encrypted GRUB2, error!)However, if you still want to use the idea of chain loading, you can be confident that the encrypted one is indeed loading (not upgraded) ‘grub.cfg’ from the encrypted partition. And this also gives a false sense of security because everything indicated in the encrypted ‘grub.cfg’ (module loading) combines with modules loaded from the unencrypted GRUB2.

If you want to check this, allocate/encrypt another partition sdaY, copy GRUB2 onto it (the grub-install operation on the encrypted partition is not possible) and in ‘grub.cfg’ (unencrypted config) change lines similar to these

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
}

lines
* insmod - loading the necessary modules for working with the encrypted disk;
* GRUBx2 - the name displayed in the GRUB2 boot menu;
* cryptomount -u 15c47d1c4bd34e5289df77bcf60ee838 - see fdisk -l (sda9);
* set root - setting the root;
* normal /boot/grub/grub.cfg - executable configuration file on the encrypted partition.

Confidence that the encrypted ‘grub.cfg’ is indeed being loaded is a positive response to entering the password/unlocking ‘sdaY’ when selecting ‘GRUBx2’ in the GRUB menu.

When working in the CLI, to avoid confusion (and to check if the environment variable ‘set root’ worked), create empty marker files, for example, in the encrypted partition ‘/shifr_grub’, in the unencrypted partition ‘/noshifr_grub’. Check in the CLI

cat /Tab-Tab

As noted above, this will not help against the loading of malicious modules if such modules are on your PC. For example, a keylogger that can save key presses to a file and mix with other files in ‘~/i386’, until downloaded by an attacker with physical access to the PC.

The simplest way to check that the digital signature protection is actively working (not reset), and that no one has interfered with the bootloader, in the CLI type the command

list_trusted

in response, we receive a snapshot of our ‘perskey’, or receive nothing if we have been attacked. (You also need to check «set check_signatures=enforce»).
A significant downside of this step is the need to manually enter commands. If this command is added to «grub.cfg» and the configuration is protected by a digital signature, the preliminary output of the key dump on the screen is too short in timing to be able to see the output, resulting in a GRUB2 boot.
There is no one to particularly blame: the developer in their the documentation p.18.2 officially states

«Note that even with GRUB password protection, GRUB itself cannot prevent someone with physical access to the machine from altering that machine’s firmware (e.g., Coreboot or BIOS) configuration to cause the machine to boot from a different (attacker-controlled) device. GRUB is at best only one link in a secure boot chain».

GRUB2 is overloaded with features that can give a false sense of security, and its development has already outpaced the functionality of the MS-DOS OS, while it is just a bootloader. It’s amusing that GRUB2 might become an OS tomorrow, while the GNU/Linux VMs are booting for it.

A short clip about how I bypassed the digital signature protection of GRUB2 and announced my intrusion to a real user. (I scared them, but instead of what is shown in the video – one could write not-so-harmless arbitrary code/.mod).

Conclusions:

1) Block system encryption for Windows is easier to implement, and protecting with one password is more convenient than protecting with multiple passwords in block system encryption for GNU/Linux; for fairness: the latter is automated.

2) I wrote the article as a relevant, detailed simple guide to full disk encryption VeraCrypt/LUKS on one home machine, which is currently the best on the Russian Internet (IMHO). The guide has > 50k characters, so it did not cover some interesting chapters: about cryptographers who disappear/stay in the shadows; about the lack of information on cryptography in various GNU/Linux books; about Article 51 of the Constitution of the Russian Federation; about licensing/запрете encryption in the Russian Federation, and the necessity of encrypting the «root/boot». The guide turned out to be quite substantial, yet detailed (describing even simple steps), which, in turn, will save you a lot of time when you engage in «real encryption».

3) I carried out full disk encryption on Windows 7 64; GNU/Linux Parrot 4x; GNU/Debian 9.0/9.5.

4) I successfully executed an attack on my GRUB2 bootloader.

5) The tutorial is designed to assist all the paranoids in the CIS, where work with encryption is legally permitted. Primarily for those who wish to implement full disk encryption without dismantling their configured systems.

6) I have revised and updated my guide, which is relevant in 2020.

[G] Useful documentation

TrueCrypt User Guide (February 2012 RU)
VeraCrypt Documentation
/usr/share/doc/cryptsetup(-run) [локальный ресурс] (official detailed documentation for configuring encryption on GNU/Linux using cryptsetup)
Official cryptsetup FAQ (brief documentation for configuring encryption on GNU/Linux using cryptsetup)
LUKS Device Encryption (archlinux documentation)
Detailed description of cryptsetup syntax (arch man page)
Detailed description of crypttab (arch man page)
Official GRUB2 Documentation.