Skip to content

Instantly share code, notes, and snippets.

@CodingCellist
Last active July 1, 2024 12:12
Show Gist options
  • Save CodingCellist/c505e98628d0be6a7b200247659fd752 to your computer and use it in GitHub Desktop.
Save CodingCellist/c505e98628d0be6a7b200247659fd752 to your computer and use it in GitHub Desktop.
A step-by-step guide to dualbooting encrypted Windows and Arch Linux, using the rEFInd boot mananger.

DISCLAIMER

ENCRYPTING YOUR DRIVE(S) CAN RESULT IN PERMANENT DATA LOSS IF YOU DON'T KNOW WHAT YOU ARE DOING OR YOU FORGET THE PASSWORD. IT IS YOUR (THE READER'S) RESPONSIBILITY TO HAVE BACKUPS SHOULD ANYTHING GO WRONG. Additionally, I am not responsible for any damage you cause to your system by following this guide. You are completely and solely responsible for any changes made and potential damage caused.

I am not an expert on this topic in any way! I just read some wiki pages, had done a dual-boot Arch install before, got inspired by this reddit guide/thread and decided to see if I could make this work on my own machine. This document is simply a result of putting that knowledge (most of which can be found on the Arch Wiki) in one place.

Assumed knowledge

Although this is a step-by-step guide, I will be assuming the reader is familiar with tools like fdisk or Windows diskmgmt.msc, some system terminology (e.g. 'partitions', 'ESP', 'kernel modules', ...), and (most of) the 'regular' Arch Install Guide. (If you aren't, read it and/or check out this other gist by me which details how to do a simple, unencrypted dual-boot install on the ThinkPad X1 Extreme Gen 1.

Assumed state of machine

  • I assume the reader has a machine with the most up to date BIOS (if you are doing this on a ThinkPad X1 Extreme Gen 1, remember that the old BIOS version can brick your laptop),
  • two hard drives,
  • and a working install of Windows on one of the two hard drives.

End result

At the end of this guide, hopefully, you'll have a machine which dual-boots Windows and Arch Linux, both fully encrypted, with an encrypted, shared partition, and a pretty EFI bootloader to complement (and launch) it all.

Chapters

Windows Encryption

Arch Linux Encryption Setup and Install

Done.

Sources

Windows Encryption

Windows will be encrypted using the VeraCrypt tool. It is a free, open-source disk encryption tool which I have used for years and has worked fine for me. It is based on the no-longer maintained "TrueCrypt" software.

Why not BitLocker?

BitLocker has had some security problems in the past (see this and this) and is also not available on all Windows editions. By contrast, VeraCrypt is available for free on any platform (including Linux, which is very useful when wanting to create an encrypted shared partition).

A couple of other reasons why I like VC is that it supplies its own EFI bootloader which can then be used from a rescue disk or environment if need be, and (just to be a bit extra paranoid) that it is not developed by Microsoft which may have put backdoors in BitLocker.

(That's not to say that there aren't excellent reasons to use BitLocker instead of VC, notably that VC has had issues with Windows Update. If you want to use BitLocker instead, then that's fine. Just be aware that in that case I have no idea if this guide will still work...

UPDATE 2020-07: I had a Windows update change the bootloader back from the VC one to the default Windows bootloader. This caused Windows to enter what seems to be known as the "Windows 10 Automatic Repair Loop"; when booting, Windows would claim that the disk was damaged and try to automatically repair it. Thankfully however, VC also installs its own bootloader DcsBoot.efi and I was able to boot into Windows by selecting it from the rEFInd menu. After a couple of weeks, I accidentally selected the Windows default one again, but found out that VC (or something) had changed it back to work correctly: it prompted for my disk password instead of trying automatic repair. So it seems that the Windows install can still get messed with through Windows update, but it doesn't seem disastrous (or maybe I was just lucky))

Creating an encrypted shared partition

  • Launch VeraCrypt
  • click Create Volume
  • choose Encrypt a non-system partition/drive
  • pick Standard or Hidden depending on your needs

If you already have a shared partition

  • You can either back it up and wipe it by using the Create encrypted volume and format it option (this will be faster, but you will lose all data stored on the partition if it is not backed up)
  • Or you can choose the Encrypt partition in place option which will encrypt the partition by reading each sector, encrypting it, and then writing the data back to it (this is slower, but keeps any data you had on the partition)
  • Pick an encryption algorithm (If read and write speed is very important, most modern processors have special instructions for AES, so pick that. Otherwise, pick any algorithm you want; potentially do a benchmark first)
  • Pick a hash algorithm
  • Set a password (and if you know what you're doing: use keyfiles, a PIM, etc.)
  • Move the mouse about randomly until the bar is filled.
  • If you're extra paranoid, choose a wipe scheme (each number of passes will heavily increase the time to encrypt, but slightly decreases the likelihood that someone would be able to figure out what was on the partition before encrypting it (which is already unlikely))
  • Finally, click Encrypt and wait for the it to finish.

If you don't already have a shared partition

  • Create a new partition of the desired size using the diskmgmt.msc tool in Windows. A new partition can be created anywhere, e.g.
    • If you have unallocated space on your Windows drive, you could use that
    • You could shrink the Windows C: partition (which I assume is the last partition on the Windows drive) using diskmgmt.msc and then use the freed-up space
    • You could allocate some space on the second hard drive and use that
  • Then choose the Create encrypted volume and format it option and select the relevant partition
  • Pick an encryption algorithm (If read and write speed is very important, most modern processors have special instructions for AES, so pick that. Otherwise, pick any algorithm you want; potentially do a benchmark first)
  • Pick a hash algorithm
  • Set a password (and if you know what you're doing: use keyfiles, a PIM, etc.)
  • Choose whether you will be storing files larger than 4GB on the partition (this affects what filesystems you can use)
  • Pick a filesystem (I would use NTFS for its native Windows support and the Linux support is also decent, especially with the ntfs-3g package) and leave everything else as is (unless you know what you're doing)
  • Move the mouse about randomly until the bar is filled, then hit Format and wait for it to finish.

Encrypting the Windows System Partition

  • If you've closed it open up VeraCrypt again.
  • Under the System tab, select Encrypt System Partition/Drive.
  • Select Normal system encryption and then select Encrypt the Windows system partition.
  • Since we will also be installing Arch Linux, select Multi-boot on the next screen and read and accept the warning VC raises about multi-booting encrypted operating systems being complex.
  • Set a password (N.B. When booting, VC only accepts the US keyboard layout so if you are using a different keyboard layout, I would strongly recommend only using alphanumerical characters and not use symbols unless you are 110% certain you know where those symbols are on a US keyboard layout).
    Also note that VeraCrypt changes your keyboard layout to US at this point, to ensure that the password can be reproduced in the pre-boot environment!
    • And if you know what you're doing: use keyfiles, a PIM, etc.
  • Move the mouse about randomly until the bar is filled, then click Next
  • The next screen tells you the keys have been generated, continue on to the next screen to create a Rescue Disk.
  • Create, store, and extract the Rescue Disk to at least one location, e.g. a USB stick and/or on an external hard disk.
    • If you are having problems with the verification part, restart this process from the beginning and then tick the Skip Rescue Disk verification before you create the Rescue Disk.
      N.B. This may be dangerous if the rescue disk was somehow not created correctly and this was not caught due to the lack of verification, and you later need the Rescue Disk. If you lose access to the encrypted system for some reason (not including forgetting the password) and you do not have a working Rescue Disk, your data will be gone completely.
  • Continue past the next screen which informs you that the Rescue Disk was created and what to do with it.
  • If you're extra paranoid, choose a wipe scheme (each number of passes will heavily increase the time to encrypt, but slightly decreases the likelihood that someone would be able to figure out what was on the partition before encrypting it (which is already unlikely))
  • To make sure pre-boot authentication, the VC boot loader, etc. actually works before encrypting your system, VC performs a pre-test. Click the Test button to install and setup these components, and restart your computer. If everything works, you should be asked to enter your password, Windows should boot normally, VC should start back up once you're logged back into Windows, and then you can continue with the actual encryption.
  • Back in Windows with VC automatically restarted, it should inform you that the pre-test completed successfully. (If it didn't, cancel everything and do not continue encrypting things! Try again.) If the pre-test went fine, click Encrypt to start the encryption process. VC will give you a progress bar and an estimated time to completion. As far as I know, you can keep using the computer whilst this is happening (it may slow down the process, but only slightly).
  • When the encryption has completed, restart and you should be greeted with the VC password prompt. (If you aren't, follow the steps in the rescue instructions along with the rescue disk.)
  • Enter your password, if you didn't specify a PIM, leave the field empty (hit return/enter again), and your Windows system should boot normally.

Congratulations, that's the first part done! :-)

Arch Linux Encryption Setup and Install

Although this section/chapter is also titled "Install", it will mostly describe how to set up the second hard drive for an encrypted Arch Linux installation. It will also briefly cover the base install of Arch Linux, but details on good practices or common post-install configurations are beyond the scope of this guide.

Overview

  • First, we will be partitioning the second drive to create 3 partitions: / (root), /home, and /swap.
  • Then, we will encrypt each of these partitions using LUKS. This is to ensure no single password unlocks all the sensitive data in the system (although I will tinker with that later).
  • With the root partition mounted, we will create a keyfile which will be used to unlock the /home partition, so as to avoid having to enter more than one password at boot (this kind of defeats the point of the previous bullet point, so you can choose to skip that if you don't mind the two password prompts).
  • With every partition mounted, we will then install Arch Linux and chroot into the new install. Here, we will set up a number of things such that the system is able to boot, unlock, and mount our encrypted partitions.
  • Once this has been done, we will install rEFInd to have a pretty EFI boot loader which can load both operating systems.

Partitioning

  • Start off by finding the disks available using the fdisk -l command. Identify the hard drive without Windows installed on it and make a note of its path (if you're using SCSI hard drives, it will be something like /dev/sda; if you're using NVMe hard drives, it will be something like /dev/nvme0n1).

  • Start fdisk on the hard drive using fdisk /path/to/drive.

  • In fdisk, press g to create a new GPT (unless you used the drive for the shared partition, in which case, skip to the next point; the drive already contains a GPT).

  • We will be using the existing Windows EFI boot/system partition (ESP), so there is no need to create a new one.

  • Create the root partition.

    • Press n to start creating a partition.
    • Accept the default partition number or set a custom one if you know what you are doing.
    • Accept the default start sector.
    • Indicate the desired size, e.g. +23G for 23GiB.
  • Create the swap partition.

    • Press n to start creating a partition.
    • Accept the default partition number or set a custom one if you know what you are doing.
    • Accept the default start sector.
    • Indicate the desired size, e.g. I typically use 1.5xRAM so for 8GB of RAM I would type +14G
  • Create the home partition.

    • Press n to start creating a partition.
    • Accept the default partition number or set a custom one if you know what you are doing.
    • Accept the default start sector.
    • Accept the default end sector to use up the remainder of the available space or specify a size if you do not wish to use up the remainder of the available space.
  • Confirm that the layout looks correct by pressing p.

    • If it doesn't, press q to discard the changes and then start again.
  • Save/Write the changes to the disk by pressing w. This should also quit fdisk.

  • Double-check that the changes were correctly applied by typing fdisk -l, you should see the drive, now with the partitions listed as well.

(Sources: AW: Partitioning#Discrete partitions)

Encrypting

  • I will be using the Whirlpool hash algorithm and the Camellia cipher for some of the encryption. This is in part due to a combination of paranoia and not using the "common" algorithms and ciphers. However, both should be perfectly secure, as they were selected for the NESSIE project (a European project similar to the NIST AES). As mentioned previously, AES has dedicated instructions on most modern CPUs, so if read and write speed is of utmost importance, aes-xts-plain64 is probably the way to go.

  • In order to be able to use Camellia and WP, load their respective kernel modules (you can get a list of all supported crypto kernel modules by running ls /lib/modules/**/kernel/crypto)

    • modprobe camellia_generic
    • modprobe wp512
  • Encrypt the root partition using your desired cipher and hash algorithm (omit them from the command to use the defaults) by running

    cryptsetup --cipher <cipher> --hash <hashalg> --key-size <ks> luksFormat /dev/<sdxN>
    

    Replacing <cipher>, <hashalg>, <ks>, and <sdxN> as appropriate. It will ask you to confirm the action (double check that you've specified the correct partition at this point) and to enter a password. Make sure it's memorable, as this is the password you will be entering when booting the system.

    • E.g. if you want to use the AES cipher and the default hash algorithm, with a key size of 512, and your root partition is /dev/sda2, you would run
      cryptsetup --cipher aes-xts-plain64 --key-size 512 luksFormat /dev/sda2
      
    • E.g. if you want to use the Camellia cipher and the WP hash algorithm, with a key size of 256, and your root partition is /dev/sda2, you would run
      cryptsetup --cipher camellia --hash whirlpool --key-size 512 luksFormat /dev/sda2
      
  • Encrypt the swap partition using your desired cipher and hash algorithm. Since speed is fairly important on a swap partition, I will be using AES. You could of course use something different. (Note: after writing this, I later noticed, on a VM, that systemd sometimes hangs when trying to mount the encrypted swap. This is registered as an issue on the systemd github, and seems to possibly be due to a race condition. YMMV, but rebooting seems to "toss the coin again" and fix things most of the time. If this is too much of a hassle/too risky for you, then I fully understand and you can skip the encryption of the swap partition and instead set up a regular, unencrypted swap partition).

    cryptsetup --cipher aes-xts-plain64 --key-size 256 luksFormat /dev/<sdxN>
    

    Where /dev/sdxN is your swap partition. Again, set a password you can remember (we need it to mount the swap initially).

  • Encrypt the home partition using your desired cipher and hash algorithm. Set a memorable password because you will either need it to mount the home partition each time or as a backup in case your keyfile gets lost (more on this later).

  • Once all of the partitions have been encrypted, open each one of them by typing

    cryptsetup open /dev/<sdxN> <name>
    

    and entering the password you set when prompted.
    Replace <sdxN> as appropriate and giving the opened volume a sensible name, e.g. I will be using cryptroot, cryptswap, and crypthome for the root, swap, and home partitions respectively.

  • Each of the volumes should now be listed under their names in /dev/mapper (you can check with ls /dev/mapper).

(Sources: AW: Kernel module#Manual module handling, AW: Encrypting an entire system#LUKS on a partition, AW: Swap Encryption)

Highly recommended: Backup the LUKS headers

  • If the LUKS headers get damaged somehow, this is equivalent to forgetting the password or damaging/destroying the keyfile. I.e. your data will be permanently encrypted without a way to access it. Therefore, it is highly recommended to backup the LUKS headers. (This can be done at any point, so you can continue with the setup and come back to this if you want/need).
  • If you have a USB drive or an external hard drive, plug it in, find its device using lsblk, and mount it somewhere, e.g. /mnt/backup (you will probably have to mkdir /mnt/backup first).
  • Backup the LUKS header using
    cryptsetup luksHeaderBackup /dev/<sdxN> --header-backup-file /mnt/<backup-point>/<filename>.img
    
    replacing <sdxN> with your external device, <backup-point> with where you mounted the external drive, and <filename> with a name for the header backup file.

(Sources: AW: Device encryption#Backup and restore)

Formatting and Mounting

  • Formatting the LUKS volumes is done exactly the same as you would for a regular partition, e.g. (using my naming scheme for the volumes)
    # mkfs.ext4 /dev/mapper/cryptroot
    # mkfs.ext4 /dev/mapper/crypthome
    # mkswap /dev/mapper/cryptswap
    
    (a hash indicates a new command line in the prompt, it is not part of the command)
  • Once all the volumes have been formatted, mount them:
    • Mount the root volume first
      mount /dev/mapper/cryptroot /mnt
      
    • Make the directories /mnt/home and /mnt/boot for mounting the home and ESP partitions to respectively, i.e. run
      # mkdir /mnt/home
      # mkdir /mnt/boot
      
    • Mount the home volume
      mount /dev/mapper/crypthome /mnt/home
      
    • Mount the swap volume
      swapon /dev/mapper/cryptswap
      
    • Mount the Windows ESP (if you've forgotten where it is, find it with fdisk -l)
      mount /dev/<sdxN> /mnt/boot
      

(Sources: AW: Installation Guide#Format the partitions, AW Installation Guide#Mount the file systems, AW: Encrypting an entire system#Mounting the devices)

OPTIONAL: Set up a keyfile for /home

  • If you want /home to be mounted automatically on boot, one option is to use a keyfile. This section takes you through the setup for that. The keyfile will be stored on the root partition, meaning it will not be possible to mount the /home partition without knowing the password to the root partition or the password set up when encrypting the /home partition (you could discard this if you wanted, I will be keeping it but I will also supply the instructions for deleting it).
    Of course, if you are fine with entering two passwords on boot (it is probably also more secure to not have /home automount), then you can skip to the next section.
  • Create a place to store the keyfile, e.g. mkdir -p /mnt/etc/keyfiles
  • Create a keyfile of 2048 random bytes of data using
    dd bs=512 count=4 if=/dev/random of=/mnt/etc/keyfiles/<my-keyfile> iflag=fullblock
    
    replacing <my-keyfile> as appropriate (e.g. call it home-keyfile)
    • Note: If you wanted to create a keyfile of 4096 random bytes instead, you would set count=8
  • Add the keyfile as a valid key to the crypthome volume (using the example location and name from above)
    cryptsetup luksAddKey /dev/<sdxN> /mnt/etc/keyfiles/home-keyfile
    
    replacing <sdxN> with your home partition. Enter the password you used to set up the volume when prompted.
  • OPTIONAL: If you do not want to keep the old password after setting up the keyfile, it can be deleted. Personally, I would keep it in case something happens to the keyfile or you need to open the volume without having access to/without opening the root volume, but it's up to you.
    If you want to remove the password used when setting up the volume, type
    cryptsetup luksRemoveKey /dev/<sdxN>
    
    and enter the password you want to remove.

(Sources: AW: Device encryption#Keyfiles, AW: Device encryption#Removing LUKS key)

Install Arch

  • Now that we have our partitions mounted, we can finally get round to installing Arch.
  • Edit the mirrorlist (found at /etc/pacman.d/mirrorlist) using a text editor, e.g. nano, to contain a number of mirrors near you.
  • Install Arch by running
    pacstrap /mnt base nano linux-hardened linux-firmware grub efibootmgr
    
    (I'm using the linux-hardened kernel due to this being a security-focused install. More details about kernel hardening can be found here).
    If you require other packages like base-devel or vim simply add them to the list.
  • Generate the list of devices to mount at boot
    genfstab -U /mnt >> /mnt/etc/fstab
    
  • Make a note/Take a picture of the output of the following commands:
    # ls -l /dev/disk/by-id
    # lsblk -f
    
  • Chroot into the new system
    arch-chroot /mnt
    

(Sources: AW: Installation Guide, AW: Security#Kernel hardening)

Essential setup

  • Now that we're chrooted into the new system, follow the configuration part of the Installation Guide and set up the timezone, clock, locale(s), hostname, hosts, etc...

  • Edit the /etc/crypttab file using a text editor, e.g. nano, to contain the following lines:

    • An entry to mount the home partition (replacing <dev-uuid> with the UUID of the actual device, not the LUKS volume, and crypthome with whichever name you gave your encrypted home volume):
      crypthome    UUID=<dev-uuid>    /etc/keyfiles/home-keyfile
      
      if you set up a keyfile for the home partition
      --- OR ---
      crypthome    UUID=<dev-uuid>
      
      if you didn't set up a keyfile and want to be prompted for the password
    • If you set up an encrypted swap, an entry to mount that (we are using /dev/disk/by-id because of persistent swap naming issues; relplace cryptswap with whichever name you gave your encrypted swap volume):
      cryptswap    /dev/disk/by-id/<dev-id>    /dev/urandom    swap,cipher=aes-cbc-essiv:sha256,size=256
      
      This will re-encrypt the swap partition with a random password each time, rendering it unrecoverable once powered off. Since swap is not meant to be persistent, this is fine and/or actually desirable. The default is to use aes-cbc-essiv as the cipher, and a key size of 256 bytes. You can of course customise these to fit your needs.
      (A side note: If you are using a GPT-formatted drive, you can assign the partition a persistent label at the GPT level using parted. I believe you can exit the chroot, assign this, and chroot back, but you may have to unmount and close the volume first. Start parted on the disk, then type name <part-number> <name>, replacing <part-number> and <name> as appropriate. You can then use the respective /dev/disk/by-partlabel/ entry instead of the /dev/disk/by-id/ entry).
  • Edit the /etc/fstab file using a text editor, e.g. nano.

    • Change the line concerning /dev/mapper/cryptswap to use that path instead of the UUID (which will be changing on each reboot), i.e. the entry should look something like:
      # /dev/mapper/cryptswap
      /dev/mapper/cryptswap    none    swap    defaults    0 0
      
  • (note: I don't know if this is specific to the VM I was testing this on or if something has changed with the Arch ISO, but double-check dhcpcd is installed using pacman -Qs dhcpcd. If it returns nothing, install it with pacman -S dhcpcd (it is required for internet access). Aditionally, if you need Wi-Fi access, installing iw and wpa_supplicant is probably a good idea.)

  • Install GRUB

    grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
    

(Sources: AW: Installation guide#Configure the system, AW: System configuration#crypttab, AW: fstab, AW: GRUB#Installation)

Boot manager setup

  • Edit /etc/mkinitcpio.conf using a text editor, e.g. nano
    • Change the line beginning with HOOKS= in accordance with this Arch Wiki page, i.e. it should read
      HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt filesystems fsck)
      
  • Generate initramfs images by running
    mkinitcpio -p linux-hardened
    
  • Configure GRUB
    • Generate the default config file by running grub-mkconfig -o /boot/grub/grub.cfg
    • Change the kernel parameters by editing /etc/default/grub
      • Edit the line with GRUB_CMDLINE_LINUX to end with
        rd.luks.name=<root-device-uuid>=cryptroot root=/dev/mapper/cryptroot
        
        replacing cryptroot with whichever name you gave your root volume
      • Uncomment the line with GRUB_ENABLE_CRYPTODISK
  • Then re-generate the GRUB config using grub-mkconfig -o /boot/grub/grub.cfg

(Sources: AW: Encrypting an entire system#Configuring mkinitcpio, AW: mkinitcpio#Common hooks, AW: GRUB#Generate the main configuration file, AW: GRUB#Additional arguments)

Reboot

  • Leave the chroot by typing exit
  • Unmount everything
    # umount -R /mnt
    # swapoff /dev/mapper/cryptswap
    
  • Close the encrypted volumes
    cryptsetup close <volume-name>
    
    (repeat for each of the volumes)
  • Restart by typing reboot and remove the Arch ISO USB when the machine starts restarting.
  • You should be able to boot into Arch using GRUB.
    • If systemd gets stuck on mounting the swap partition, try restarting. It should fix itself.
    • If you cannot boot at all, plug the Arch ISO USB back in and re-open and mount everything; grab the outputs from lsblk -f, ls -l /dev/disk/by-id, and ls -l /dev/disk/by-partlabel/; chroot; sanity-check your /etc/fstab and your /etc/crypttab; sanity-check your /etc/mkinitcpio and if you make changes to it, remember to re-run mkinitcpio -p linux-hardened; and potentially also sanity-check /etc/default/grub and re-generate the GRUB config using grub-mkconfig -o /boot/grub/grub.cfg.

Install rEFInd

  • (note: if you do not want to install rEFInd but instead use GRUB, see this section of the GRUB Arch Wiki page for details on how to detect the Windows OS)
  • Once you are booted back into Arch (the install, not the ISO/live environment)
  • Install rEFInd by typing pacman -S refind-efi
  • Run the refind-install script, it should correctly find the /boot partition.
  • You should now have rEFInd installed at /boot and it should have created a refind_linux.conf
  • When you reboot, you should now be greeted with the rEFInd boot manager and able to boot both Windows and Linux.
  • At this point, I believe it's safe to uninstall GRUB, remove it from the /boot/EFI directory, and delete the /boot/grub directory (all of which I would do to save space on the ESP). However, if you want to keep GRUB there, that is also a possibility (it may be a security risk, I'm not sure though).

(Sources: AW: rEFInd)

Accessing the shared partition from Linux

  • To access the shared partition from Arch, we will need VeraCrypt. It can be installed through
    pacman -S veracrypt
    
  • Then, the volume can be mounted to a mount point using
    veracrypt /dev/<crypt-device> /mnt/<mountpoint>
    
    replacing <crypt-device> with the device containing the shared partition (if you are uncertain which one it is, find it with lsblk) and replacing <mountpoint> with wherever you wish to mount the volume.

Done.

Congratulations on making it to the end, I know this was long and complicated, especially if you've never done anything like this before. I hope it was helpful and that you learned a thing or two :-)

Sources

  1. https://www.reddit.com/r/linux/comments/9galhz/creating_a_hardened_arch_linux_installation_with/
  2. https://wiki.archlinux.org
  3. https://wiki.archlinux.org/index.php/Installation_guide
  4. https://gist.github.com/CodingCellist/05556e0cb6cde146fc3f70b578b73da3
  5. https://veracrypt.fr
  6. https://www.howtogeek.com/fyi/you-cant-trust-bitlocker-to-encrypt-your-ssd-on-windows-10/
  7. https://www.youtube.com/watch?v=eRuca6eAdFM
  8. https://www.microsoft.com/en-us/windows/compare-windows-10-home-vs-pro
  9. https://github.com/th-wilde/veracrypt-w10-patcher
  10. https://wiki.archlinux.org/index.php/Partitioning#Discrete_partitions
  11. systemd/systemd#12383
  12. systemd/systemd#10179
  13. https://wiki.archlinux.org/index.php/Kernel_module#Manual_module_handling
  14. https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LUKS_on_a_partition
  15. https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption
  16. https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Backup_and_restore
  17. https://wiki.archlinux.org/index.php/Installation_guide#Format_the_partitions
  18. https://wiki.archlinux.org/index.php/Installation_guide#Mount_the_file_systems
  19. https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Mounting_the_devices
  20. https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Keyfiles
  21. https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Removing_LUKS_keys
  22. https://wiki.archlinux.org/index.php/Security#Kernel_hardening
  23. https://wiki.archlinux.org/index.php/Installation_guide#Configure_the_system
  24. https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption
  25. https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#crypttab
  26. https://wiki.archlinux.org/index.php/Fstab
  27. https://wiki.archlinux.org/index.php/GRUB#Installation_2
  28. https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_mkinitcpio
  29. https://wiki.archlinux.org/index.php/Mkinitcpio#Common_hooks
  30. https://wiki.archlinux.org/index.php/GRUB#Generate_the_main_configuration_file
  31. https://wiki.archlinux.org/index.php/GRUB#Additional_arguments
  32. https://wiki.archlinux.org/index.php/GRUB#Detecting_other_operating_systems
  33. https://wiki.archlinux.org/index.php/REFInd
@cmonty14
Copy link

cmonty14 commented Jan 1, 2022

Hi,
thx for sharing this instruction.

Question:
Will this setup also work for a dual-boot configuration with

  • MBR (and not GPT)
  • Windows 10 using 2 partitions: SYSTEM_DRV, DATA_PARTITION (see screenshot)?
    disk-management

THX

@CodingCellist
Copy link
Author

CodingCellist commented Jan 12, 2022

Hi @cmonty14, sorry for taking a while to get back.

A couple of things first: The disclaimer applies to this as well; please make sure you have working backups of your data. I'd also recommend trying this (a dual-boot system using an MBR-partitioned disk) in a VM (e.g. VirtualBox) first, just to make sure it works and you are somewhat comfortable with the commands needed to set things up : )

In terms of decrypting the Linux partition, I don't think MBRs provide a unique disk identifier in a similar way to GPT, so setting up the /etc/crypttab file will probably be different.

The SYSTEM_DRV partition appears to be a Lenovo-specific thing containing some recovery tools (see: NotebookReview, Lenovo Forums). If you encrypt your Windows partition (C:), I'd be surprised if the tools still work/are useful; they'd be unable to access the data on the disk and you've replaced the Windows bootloader with the VeraCrypt one. I don't think the bootloader is stored on SYSTEM_DRV, I think it's purely a backup/recovery option, but if it is then I don't know if VC will be happy. (As a side note: on my device, I think I accidentally deleted SYSTEM_DRV when reinstalling Windows, so it might be fine to remove it, but I don't know. Again, always make sure you have working backups of your data in case something goes wrong!)

With all that said, as far as I can tell, it should work with an MBR-partitioned disk since both VC and LUKS2 supports MBR (to my knowledge). I found a recent blogpost comparing full-disk encryption using MBR and GPT with both (Legacy) BIOS and UEFI systems: https://www.rohlix.eu/post/linux-disk-encryption-with-bios-uefi-using-mbr-gpt-luks-lvm-and-grub/. This might be insightful, but note that the setup is different (no dual-boot, parted for partitioning instead of fdisk, and they also use configure LVM on top of everything).

Again, I'd start by downloading a Windows ISO and an Arch ISO, and then setting up a small VM to test things out. I don't think there should be problems with the setup in theory, but you never know. If the VM config seems to work, and you've got recent backups of your data, then I think it should be fine and I would then try it on your machine. If you want to, please me know how it goes/any insights you gain : )

@cmonty14
Copy link

Hello @CodingCellist, thanks for your reply.

I have encrypted the Windows partition (C:/) in the meantime with VeryCrypt.
There are no issues during and after encryption.

In my understanding VeraCrypt installs its bootloader in MBR.

Therefore I cannot install Grub in MBR, too.
If I would install Grub in MBR, the VeraCrypt bootloader would be overwritten.

To my understanding VeraCrypt's bootloader can display other partitions with a different bootloader, means if I hit in VeraCrypt's bootloader and don't enter the password, the bootloader will load Grub.

My plan is now this partition layout:
sda1
SYSTEM_DRV
sda2
Windows Data partition
sda3
Grub partition
sda4
Linux partition

Partition sda3 will be some MB of size and not encrypted; partition sda4 is the root partition incl. /boot and encrypted.
In fact this would be a layout comparable to EFI (with a dedicated ESP).

Will this plan work?

@d4op
Copy link

d4op commented Mar 8, 2024

Hello @CodingCellist, thanks for your reply.

I have encrypted the Windows partition (C:/) in the meantime with VeryCrypt. There are no issues during and after encryption.

In my understanding VeraCrypt installs its bootloader in MBR.

Therefore I cannot install Grub in MBR, too. If I would install Grub in MBR, the VeraCrypt bootloader would be overwritten.

To my understanding VeraCrypt's bootloader can display other partitions with a different bootloader, means if I hit in VeraCrypt's bootloader and don't enter the password, the bootloader will load Grub.

My plan is now this partition layout: sda1 SYSTEM_DRV sda2 Windows Data partition sda3 Grub partition sda4 Linux partition

Partition sda3 will be some MB of size and not encrypted; partition sda4 is the root partition incl. /boot and encrypted. In fact this would be a layout comparable to EFI (with a dedicated ESP).

Will this plan work?

question is worked this ? :-P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment