This is the first part of a 3 part series of blog posts surrounding Kali usage on Raspberry Pi devices. This first post will cover enabling Full Disk Encryption (FDE) on a Raspberry Pi, part two will cover remotely connecting to it, and finally, part three will cover debugging issues we ran into while making these posts, so others can learn how to do so as well.
With everything that has been going on in the world in the last few years, more people are working remotely. We are no exception to this, and today, we are going to be revisiting our “drop box” machine, which has been encrypted thus making it harder to identify if discovered.
The goal is to create a stand-alone “leave behind” headless device that, that if/when discovered, does not make it easy to figure out what we were doing as our data is secure at all times. To accomplish this, we will use Full Disk Encryption (FDE), and allow for it to be remotely unlocked (should the device get restarted for any reason). There will be the option as well to use , but it also has been tested on a part of this before. This time we include additional developments, with some community contributions thrown in. We would like to give a shout-out to Richard Nelson (. We will touch on this after going through the manual method, as we always recommend you understand what is going on under the hood.
Higher-level overview
Before we dive into the lower-levels of technical details of what we are going to accomplish, let’s take a quick look at our goals that we want to achieve, and break it down:
(henceforth called “RPi”)
to allow the remote unlock to occur (using initramfs and Dropbear)
the encrypted partitions
the .
We have also chosen the 64-bit image, as we have more than 4GB of RAM, and are not using any
As a reminder, we are using the RPi4, 64-bit image. So we would need Re4son-v8l+. Please make sure you adjust to your device.
So now we know what kernel name to use, we now need to find what kernel version. This will alter from device to device, and it will also change as and when Kali gets updates At the time of writing, it is 5.15.44 for our RPi:
Keep in mind the kernel versions may change, however the name will not:
Before we can backup, we have to ensure that rpi-resizerootfs is disabled. This is a service we typically run on all of our ARM devices that resizes the root filesystem partition to increase the size of the partition to the full size of the storage device it is on. Since we are doing this step manually, we want to disable it, so it doesn’t potentially delete our root filesystem and re-make it.
The final steps that we have to make are to fix up the /etc/fstab file for the new LUKS UUID, or you can leave it as /dev/mapper/crypt and replace the UUID in our unlock script and remake the initramfs file, this step is important as it will not properly boot if not done, because it won’t have the information to use the encrypted filesystem! Remember to put the information in from YOUR system, as the UUID will be different for every system:
CONSOLE
$ sudo mount /dev/sdX1 /mnt/encrypted/boot/
$ sudo mount -t proc none /mnt/encrypted/proc
$ sudo mount -t sysfs none /mnt/encrypted/sys
$ sudo mount -o bind /dev /mnt/encrypted/dev
$ sudo mount -o bind /dev/pts /mnt/encrypted/dev/pts
$ sudo env LANG=C chroot /mnt/encrypted
┌──(root㉿kali)-[/]
└─# blkid /dev/sdX2
/dev/sdX2: UUID="173e2de4-0501-4d8e-9039-a4923bfa5ee7" TYPE="crypto_LUKS" PARTUUID="e1750e08-02"
┌──(root㉿kali)-[/]
└─# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
UUID=173e2de4-0501-4d8e-9039-a4923bfa5ee7 / ext4 errors=remount-ro 0 1
LABEL=BOOT /boot vfat defaults 0 2
┌──(root㉿kali)-[/]
└─# vim /etc/initramfs-tools/unlock.sh
┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/unlock.sh
#!/bin/sh
export PATH='/sbin:/bin:/usr/sbin:/usr/bin'
while true; do
test -e /dev/mapper/crypt && break || cryptsetup luksOpen /dev/disk/by-uuid/173e2de4-0501-4d8e-9039-a4923bfa5ee7 crypt
done
/scripts/local-top/cryptroot
for i in $(ps aux | grep 'cryptroot' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'askpass' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'ask-for-password' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep '\\-sh' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
exit 0
┌──(root㉿kali)-[/]
└─# vim /etc/crypttab
┌──(root㉿kali)-[/]
└─# cat /etc/crypttab
crypt PARTUUID=e1750e08-02 none luks
┌──(root㉿kali)-[/]
└─# mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+
If you get a cryptsetup error here, similar to cryptsetup: ERROR: Couldn't resolve device PARTUUID=ed889dad-02 that means that you did not edit the /etc/crypttab file and put the correct PARTUUID in. The warning about no fsck.luks existing can be ignored, as there is no such thing.
Earlier, we mentioned the LUKS Nuke capability. If you plan to use it, while booted on your freshly encrypted RPi rootfs, simply run the following command to add the Nuke password and follow the prompt:
What we changed here is the block device, LUKS encryption password, and the root password. The image URL can be changed if you would like to use a different image file, so be sure to do that now if need be.
Now the only thing left to do is run both stages’ scripts and follow the instructions. By the end of it, you’ll have a fully encrypted file-system with Dropbear SSH access!
Vollständiger Original-Bericht
Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf kali.org.
SOCIAL SHARE CARD GENERATOR