Full Disk Encryption with the Trixie image

With the arrival of the Hackergadget NVME board I finally found the need to encrypt my uConsole’s storage. Searching for how to accomplish this I found many howtos - most of them overly complicated and hard to follow.

The best thing I found and what I based my setup on is the following reddit post: Raspberry Pi 5 running Trixie with LUKS encrypted root. I will refer to this down in the text - keep the tab open.

This is an attempt to create a clearer description by not going into every detail but by providing the priniples and only some important details.

Step 1 - Install a current system.

Get the Trixie image that @Rex provides, install it to a SD card and configure it to your liking. Also install the “cryptsetup-initramfs” package - you’ll need it later.

This is your unencrypted source disk!

Step 2 - Create encrypted target disk.

This is the disk you will use after encryption. In my case it is the NVME SSD, but it could also be another SD-Card. I took the easy route and did all this on another Linux system not on the uConsole itself. I would recommend you do too.

  • Create a 512 MB FAT32 partition on the card - this will be the unencrypted boot partition.
  • Create a LUKS encrypted second partition. You can do this graphically with gparted, the KDE Partition Editor or on the Commandline using fdisk and cryptsetup (see linked article) - this will be the root partition that stores your encrypted system with all files.

There has been a question regarding encryption cyphers. For the CM5 you can use the standard AES encryption since the CPU has hardware acceleration for that from what I read. The CM4 does not so you’ll need another, less CPU demanding cypher. I found a Page where someone did benchmark ciphers for Raspi 4 - have a look there.

Step 3 - Copy installed system to new disk.

Use rsync with the following options:

rsync -aAXHv source destination

Mount both boot partitions and transfer their files. Be carefull to get source and destination right. rsync is a bit tricky with trailing slashes too - but you can always redo the transfer if something goes wrong.

Now mount both root partitions and do the same. The encrypted target will aready require you to input your password.

Easy until here.

You now have a SD-Card that contains your encrypted Trixie installation but it does not yet know how to boot itself. For that you have to create an initramfs on your unencrypted boot partition that will ask for your password on system startup. Some configuration options are also necessary.

I will provide my working setup although I believe some options might be superfluous. This is because I had to try a lot of stuff before I got it to work and only removed the settings I really know to be unnecessary.

Step 4 - Boot uConsole from your old installation.

Yes that’s right. Take the original SD-Card, put it in the uConsole and boot from it a last time. You also need a card reader to connect your newly encrypted system so that both cards with all 4 partitions are available at the same time. If you’re using a NVME target, this is the time to install the SSD into the uConsole.

use the blkid command to get the UUIDs of all connected partitions and take note of them.

Step 5 - Mount and chroot into your encrypted filesystem.

Mount the encrypted root as well as the unencrypted new boot partition. Following the guide linked above I recommend following mountpoints

encrypted new root to      /mnt/
unencrypted new boot to    /mnt/boot/firmware/

Before chrooting into the new system you also need the sys, dev, and proc filesystems - mount them using following command:

for dir in sys dev proc ; do mount --rbind /$dir /mnt/$dir && mount --make-rslave /mnt/$dir ; done

Change into the new system using chroot

chroot /mnt/

You are now inside the encrypted system and can make all necessary configuration changes.

Step 6 - Configuration files

Working examples below - change according to your UUIDs and names accordingly. Create files that do not exist.

/etc/crypttab

# <target name> <source device>         <key file>      <options>
cryptroot UUID=$uuid_of_your_encrypted_root_partition none luks,discard

/etc/fstab

proc            /proc           proc    defaults          0       0
UUID=$uuid_of_your_unencrypted_boot_partition  /boot/firmware  vfat    defaults          0       2
/dev/mapper/cryptroot  /               ext4    defaults,noatime  0       1

/etc/cryptsetup-initramfs/conf-hook

CRYPTSETUP=y

(Not sure if above is necessary, but it still works)

/boot/firmware/cmdline.txt

console=serial0,115200 console=tty1 root=/dev/mapper/cryptroot cryptdevice=UUID=$uuid_of_your_encrypted_root_partition:cryptroot rootfstype=ext4 fsck.repair=yes rootwait fbcon=rotate:1 psi=1 cfg80211.ieee80211_regdom=AT

The trailing ieee80211 part is about WIFI regulatory countries and will be different in most cases. The root and cryptroot parts are the important stuff here.

Step 7 - The initramfs

Having configured all of the above, you can create a new initramfs with:

update-initramfs -u

Now comes the part that took me longest to find out! Rex’s image does not use a initramfs! The command above did indeed create one, but it is kept in the encrypted /boot directory that is not available when the uConsole starts up.

Change into the /boot directory and figure out which one is the newly created initramfs image - have a look at the file creation times with

cd /boot/
ls -l

Find the initramfs that has a timestamp of just a short time ago and copy it to /boot/firmware/. I used the following filename:

/boot/firmware/initrd_2712.img

Finally the uConsole needs to know where to find this initramfs during boot - that is done via the config.txt file - have a look at mine:

/boot/firmware/config.txt

[pi3]
#dtoverlay=clockworkpi-devterm-cm3
dtoverlay=clockworkpi-uconsole-cm3
dtoverlay=vc4-kms-v3d
dtparam=spi=on
dtoverlay=spi-gpio35-39
gpio=11=op,dh
enable_uart=1


[pi4]
#dtoverlay=clockworkpi-devterm
dtoverlay=clockworkpi-uconsole
dtoverlay=vc4-kms-v3d-pi4,cma-384
dtparam=spi=on
enable_uart=1
initramfs initrd_2712.img followkernel


[pi5]
#dtoverlay=clockworkpi-devterm-cm5
dtoverlay=clockworkpi-uconsole-cm5
dtoverlay=vc4-kms-v3d-pi5,cma-384
dtparam=uart0
dtparam=pciex1
dtparam=pciex1_gen=3
initramfs initrd_2712.img followkernel


[all]
ignore_lcd=1
max_framebuffers=2
disable_overscan=1
dtparam=audio=on
dtoverlay=audremap,pins_12_13
dtoverlay=dwc2,dr_mode=host
dtparam=ant2
dtparam=rtc_bbat_vchg=3000000


##only edit the section of the pi you have, other section will be ignored.
##if you have a devterm uncomment devterm and comment out entries with uconsole.

Step 8 - Reboot

Exit from the initramfs and reboot the system. It should now ask you for your encryption password on boot - finally

Closing Remarks

The initramfs will be recreated from time to time during some system updates. In that case you have to copy the new version to /boot/firmware/ again. It is possible to automate that and maybe I will take a look into how to do that. But until then, it has to be done manually.

Please tell if this guide has been helpful and also if there are problems or things missing. I’m open to suggestions and will try to improve this guide from feedback.

1 Like

Are you using a CM4 or a CM5? I’m asking because of the performance. And which encryption did you choose?

I’m using the CM5 and it feels quick enough. I have not tested HD speeds after encryption but before I got around 800 MB/s reads using PCIe 3x settings.

I expect it to be the same which would make the relatively slow interface the bottleneck and not the CPU encryption. I will test later though.

For the CM5 use standard AES encryption since the CPU has hardware acceleration for that from what I read. The CM4 does not so you’ll need another, less CPU demanding cypher. I found a Page where someone did benchmark ciphers for Raspi 4 - have a look there.

2 Likes

Hello, thanks for the guide!

I do have a problem, the new system is still not booting on the CM5 with SD card.

When you say “$uuid_of_your_encrypted_root_partition”, is it the UUID of the LUKS partition or the UUID of the ext4 inside the LUKS? (I assume the first one.)

When following the steps, I have warnings when creating the initramfs:

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.67-v8-16k+
cryptsetup: WARNING: target 'sda3_crypt' not found in /etc/crypttab
W: Couldn't identify type of root file system '/dev/mapper/cryptroot' for fsck hook

Edit: found the issue with initramfs, it was not looking for “cryptroot” but for “sda3_crypt”.
I updated my crypttab to use “sda3_crypt” and the fstab to use “/dev/mapper/sda3_crypt”.

Now update-initramfs generate the image without warning. However, my system still doesn’t boot…

Thanks if you can help!

There are of course many possibilities.

Have you manually copied the created initramfs to /boot/firmware ?

Have you also adapted the boot/firmware/mcdline.txt to find the encrypted root ? You have to rename cryptroot to sda3_crypt there too if it is named so in your case.

There might be other things, but these are what come into my mind