Tuning the encryption!

Prologue

I have achieved my goal! However I am not still pretty sure about the goodness of the encryption. From my point of view it creates more problems respect the ones it should be solve. If you have a disk failure you may not be able to decrypt that disk, even having a LVM partition spread on several disks may lead to the same problem and if those are also encrypted the risk is even higher.

Today, as a matter of fact, the Solid State Disk (SSD) are lesser prone to get broken as the old spin Hard Drive (HD) and probably this kind of risk is really low respect before; I don't store sensible information on my computers and the risk to get my hardware stolen is presumably lower than get a damaging disk. I believe that my personal data are more on risk while my computer is on internet, if for some reason there is a 0 Day Attack on Linux my data will be grasped whether I have or not my disks encrypted.

I am still convinced that all this question about encryption it is just a marketing stuff and nothing more. In twenty years of informatics I haven't had any complaining about the lacking of encryption on my computers. Instead of having just all your drive encrypted it would be more pragmatic just having a partition encrypted where store sensible information, I'll see...

On the track

Said that now I am the two disks encrypted but now every time I boot my computer I have to insert two very long password and I am too lazy for making this twice, I have to automatize at least the second password.

The idea is to use a key that is stored on the first disk that will be available when it is decrypted and that will automatically unlock the second disk transparently for me. It seems reasonable I have just to understand how...

Fortunately I am still working on my Virtual Machine so I can mess up everything and revert all the changes until I don't understand the right procedure:

After several attempts and after read all the documentation available I was able to achieve it. It was not easy and it was not also the best solution but is enough to make your data protect. The fact is, so far I saw, that only Arch Linux has developed the tools to make the decryption through multiple device working using the key because with SYSTEMD that handles even the encryption all the former Debian Scripts won't work anymore. As a matter of fact there were a lot of helpful scripts to make it pretty easy but the only solution I found is stored the key inside the INITRD in order to make it available while the LVM is partially mounted.

References

Check the instructions:

1. Create a random key

sudo dd if=/dev/urandom of=/root/crypt.key bs=512 count=4  iflag=fullblock
4+0 records in
4+0 records out
2048 bytes (2.0 kB, 2.0 KiB) copied, 0.000214817 s, 9.5 MB/s

2. Hardening the key with the permits

 sudo chmod 600 /root/crypt.key

3. Adding the key to LUKS

sudo cryptsetup -v luksAddKey /dev/sdb1 /root/crypt.key

output

Enter any existing passphrase: 
Key slot 0 unlocked.
Key slot 1 created.
Command successful.

4. Modifying the crypttab file to use the key

sudo nano /etc/crypttab 
cat /etc/crypttab

output

cryptdata UUID=4f9334bd-c029-4e7b-8a80-4ae053685257 none luks
cryptextra UUID=3cdd9690-a7b1-40a4-ab12-c16cee0c99da /root/crypt.key luks

The combination of systemd and systemd-boot present on POP! make almost impossible unlocking multiple devices with keys. From one side you would need of the Debian scripts that won't work on systemd and from the other side you would need the feature of GRUB while POP! uses systemd-boot (former gummy-boot) at this point with a small sacrifice it is possible put the keys on the INITRD and storing them on an unencrypted partition like describes in here:

zless /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz

12. Storing keyfiles directly in the initrd
-------------------------------------------

Normally devices using a keyfile are ignored (with a loud warning), and
the key file itself is not included in the initrd, because the initramfs
image typically lives on an unencrypted `/boot` partition. However in
some cases it is desirable to include the key file in the initrd; for
instance recent versions of GRUB support booting from encrypted block
devices, allowing an encrypted `/boot` partition.

Among the key files listed in the crypttab(5), those matching the value
of the environment variable KEYFILE_PATTERN (interpreted as a shell
pattern) will be included in the initramfs image. For instance if
`/etc/crypttab` lists two key files `/etc/keys/{root,swap}.key`, you can
add the following to `/etc/cryptsetup-initramfs/conf-hook` to add them to
the initrd.

KEYFILE_PATTERN="/etc/keys/*.key"

Furthermore if the initramfs image is to include private key material,
you'll want to create it with a restrictive umask in order to keep
non-privileged users at bay. This can be achieved by adding the
following to `/etc/initramfs-tools/initramfs.conf`.

UMASK=0077

And is exactly what I did.

5. Adding the key on the initrd

sudo nano /etc/cryptsetup-initramfs/conf-hook 

and modified the line like this:

KEYFILE_PATTERN=/root/*.key

I could also using KEYFILE_PATTERN=/root/crypt.key.

Then you can hardening the INITRAMFS adding UMASK=0077 to the file /etc/initramfs-tools/initramfs.conf

sudo nano /etc/initramfs-tools/initramfs.conf

6. Regenerating the INITRAMFS and reboot!

sudo update-initramfs -u -k all

output

update-initramfs: Generating /boot/initrd.img-5.0.0-21-generic
kernelstub.Config    : INFO     Looking for configuration...
kernelstub           : INFO     System information: 

    OS:..................Pop!_OS 19.04
    Root partition:....../dev/dm-2
    Root FS UUID:........2fe679e2-6b68-44eb-9fb2-ae9c24b64fa6
    ESP Path:............/boot/efi
    ESP Partition:......./dev/sda1
    ESP Partition #:.....1
    NVRAM entry #:.......-1
    Boot Variable #:.....0000
    Kernel Boot Options:.quiet loglevel=0 systemd.show_status=false splash
    Kernel Image Path:.../vmlinuz
    Initrd Image Path:.../initrd.img
    Force-overwrite:.....False

kernelstub.Installer : INFO     Copying Kernel into ESP
kernelstub.Installer : INFO     Copying initrd.img into ESP
kernelstub.Installer : INFO     Setting up loader.conf configuration
kernelstub.Installer : INFO     Making entry file for Pop!_OS
kernelstub.Installer : INFO     Backing up old kernel
kernelstub.Installer : INFO     Making entry file for Pop!_OS
update-initramfs: Generating /boot/initrd.img-5.0.0-15-generic
kernelstub.Config    : INFO     Looking for configuration...
kernelstub           : INFO     System information: 

    OS:..................Pop!_OS 19.04
    Root partition:....../dev/dm-2
    Root FS UUID:........2fe679e2-6b68-44eb-9fb2-ae9c24b64fa6
    ESP Path:............/boot/efi
    ESP Partition:......./dev/sda1
    ESP Partition #:.....1
    NVRAM entry #:.......-1
    Boot Variable #:.....0000
    Kernel Boot Options:.quiet loglevel=0 systemd.show_status=false splash
    Kernel Image Path:.../vmlinuz
    Initrd Image Path:.../initrd.img
    Force-overwrite:.....False

kernelstub.Installer : INFO     Copying Kernel into ESP
kernelstub.Installer : INFO     Copying initrd.img into ESP
kernelstub.Installer : INFO     Setting up loader.conf configuration
kernelstub.Installer : INFO     Making entry file for Pop!_OS
kernelstub.Installer : INFO     Backing up old kernel
kernelstub.Installer : INFO     Making entry file for Pop!_OS

I rebooted and everything got fine:

Put the first passwordPut the first password

Unlocked!Unlocked!

Unlocked Automagically!Unlocked Automagically!

#Linux #System76 #PopOs #LVM #PostInstallation #LinuxDesktop #Foss #Floss #OpenSource #Encryption #Debian #Ubuntu

if you want comment this article add me on Diaspora, Friendica or Mastodon: gnuserland@social.isurf.ca