[Feature Request] LUKS encrypted partitions

[Dimensional]

I have some experience making FDE systems, and am currently migrating from BerryBoot to Pinn, and I'm wondering if it's possible to allow for certain partitions to be encrypted, with an option to create encryption keys for each partition as well as edit the corresponding cryptab file. Given how the system is set up, I can only see this being done when creating the partition table.

I'm not overly technical in making something work or describing it as such, but the way I can visualize it being done with the current setup is asking for an passphrase when creating the partition, LUKS creates the partition and then opens it, followed by the LUKS mounted partition, which can be assumed located in /dev/mapper/luks_, getting mounted to the normal installation path for the files to be copied over.

Of course following that the normal editing of fstab would be done, but instead of directing the root of the file system to the mmcblk block device, it would redirect to the luks device, and crypttab would get the blockid of the partition that is luks encrypted, and use that.

Currently I only know of Raspbian and Kali being capable of using this feature to the fullest, but there might be others. Maybe a line can be included in the os.json files like "encryptable=true" or something for the systems that can use luks without issue.

[procount]

Interesting. I have never used LUKS, so I would have a learning curve before I can even start to consider this, and as I'm quite busy at the moment, this may be a while. It certainly looks feasible from my quick reading around the subject. I'm just a little confused about cryptab at the moment and where that is located. Is it to allow PINN to access the encrypted partitions, or stored in /etc of the installed OS? If the latter, how can the OS kernel access cryptab to load the rootfs if cryptab is on the encrypted rootfs? Or does that mean you need additional partitions? Like I said, I have some learning to do first, but I'll put it on the list for consideration.

[Dimensional]

Crypttab is located in the OS's /etc folder. It's to LUKS and Cryptsetup what fstab is to mount, telling the encryption software what partition is encrypted and how to mount it at boot. mount and fstab usually are run after crypttab is read.

The idea is for the bootloader and kernel to be in their own separate partition, which for raspberry pi is already done, and the root storage for the OS is in it's own encrypted partition. I'm not sure how different things are handled between PC and RPi systems, so it definitely will require research, but I think it's possible.

Here's some old tutorials for Raspbian and Kali, both which I'm also reading.

https://carlo-hamalainen.net/2017/03/12/raspbian-with-full-disk-encryption/

https://docs.kali.org/kali-dojo/04-raspberry-pi-with-luks-disk-encryption

As for accessing the encrypted partitions through PINN, all one would need is the proper software to be included, like cryptsetup, and a keyboard or some automated script. If you want to read a partition from inside PINN, if that is a feature, then selecting the partition and mounting it could ask for a passphrase to decrypt it with.

[Dimensional]

To give a better understanding on how FDE works on PC, you have a boot partition that holds your kernel files, configs, maybe grub, as well as a ramdisk. That ramdisk is something that is loaded into memory at boot, containing almost everything for the very basic linux environment, similar to what PINN's recovery menu has.

What would happen is the ramdisk would be created for the kernel to include the necessary programs and libraries, in this case cryptsetup, to be able to decrypt and mount the root partition using the kernel's mount libraries. On the unlikely chance you don't use linux, the mount command requires admin access because it accesses a series of calls and functions that are compiled into a standard linux kernel, especially if it's a linux native file system like extfs.

So cryptsetup mounts the encrypted partition under /dev/mapper, and then normal mount operations during boot take over where it mounts the mapped partition as root, followed by boot being mounted as a folder inside.

For a good example, here's a tutorial on how to manually do it with Ubuntu, which should be easily translated to other distributions. Skip the lvms part of the preinstall. In this case you just want 2 partitions: The Boot Partition and The Root Partition.

https://askubuntu.com/questions/918021/encrypted-custom-install

[lurch]

This is also something I know nothing about (I had to google to learn that FDE = Full Disk Encryption), but presumably it requires the user to enter a passphrase (using a keyboard) and so this wouldn't work with the "headless" features of PINN?

It's an interesting suggestion, but I wonder if it might be too specialised a feature to be within the remit of PINN? :man_shrugging:

[Dimensional]

crypttab does include the option for key files so you can boot without a password, but in that case Full Disk Encryption would be pointless. The entire SD card doesn't have to be encrypted. Just the data partitions of select OSs installed on there. I don't think every OS has to be encrypted all together.

So you can have some encrypted for local access, or encrypted storage to access after logging in remotely on headless, and some kept unencrypted for headless.

[Dimensional]

Thinking this over, I realize this may only be useful for individual systems installed onto the Pi. The only reason I can see this being implemented in PINN is to allow it to create encrypted data partitions for each OS and modifying the boot partition for said OS to include the encryption records. This would be preferable to either having a blanket encryption of every partition, as well as speed things up since users won't have to create a second partition to store all their files in before formatting the original to encrypted and editing afterwards.

Other than that, solely for mounting the encrypted partitions in for emergency purposes, such as refreshing or reinstalling the OS without having to format and rebuild the encryption.

As for headless systems, like I mentioned cryptsetup supports keyfiles for quick automounting.

Cryptsetup Manpage Crypttab Manpage - The manual for crypttab, Cryptsetup's equivalent to fstab/mtab Examples for mounting LUKS with keyfiles