Kali Linux on a Raspberry Pi (A/B+/2) with Disk Encryption

With the advent of smaller, faster ARM hardware such as the new Raspberry Pi 2 (which now has a Kali image built for it), we’ve been seeing more and more use of these small devices as “throw-away hackboxes“. While this might be a new and novel technology, there’s one major drawback to this concept – and that is the confidentiality of the data stored on the device itself. Most of the setups we’ve seen do little to protect the sensitive information saved on the SD cards of these little computers. This fact, together with a nudge from friends is what prompted us to create a LUKS encrypted, NUKE capable Kali Linux image for our Raspberry Pi devices. The following blog post describes the process, so you can repeat it and make your own shiny shiny.

Birds Eye View of the Disk Encryption Process

The process described in this blog post was tried and tested successfully on a Raspberry Pi B+ and a Raspberry Pi 2 (henceforth collectively called “RPi”). but it should be trivial to port these instructions to any ARM device running Kali. Before we begin, let’s take a minute to quickly describe what we’ll be doing – as while this process is not complicated, it is involved. This is basically our spiel:

1. We download the required Kali Raspberry Pi RPi image and dd it to an SD card.
2. We chroot to the RPi image and install/update several files in preparation for our crypted boot.
3. We create an initramfs file which includes Dropbear and freshly generated SSH keys.
4. We rsync the modified rootfs to a temporary backup location and then delete the rootfs partition from the SD.
5. We then recreate an encrypted partition to which we restore the root partition data. That’s it!

If all goes well, the RPi will boot and then LUKS will kick in and ask for a password to decrypt the root drive, while simultaneously opening a Dropbear SSH session through which you can SSH in and provide the boot decryption password. Oh yeah, did we mention this image also has LUKS NUKE capabilities?

Getting Your Hands Dirty

As always, all our ARM dev is done on a Kali amd64 machine and we’ve made sure that we have all the dependencies we need. We download the latest Kali RPi image (1.1.0), extract it, and dd it to our SD card, which in our case showed up as sdb2 – adapt as necessary!

[cc lang=”text”]
dd if=/root/kali-1.1.0-rpi.img of=/dev/sdb bs=4M
[/cc]

Once dd‘d, we mount the various partitions and chroot into the Kali RPi image:

[cc lang=”text”]
mkdir -p /mnt/chroot/boot

mount /dev/sdb2 /mnt/chroot/
mount /dev/sdb1 /mnt/chroot/boot/

mount -t proc none /mnt/chroot/proc
mount -t sysfs none /mnt/chroot/sys
mount -o bind /dev /mnt/chroot/dev
mount -o bind /dev/pts /mnt/chroot/dev/pts

cp /usr/bin/qemu-arm-static /mnt/chroot/usr/bin/
LANG=C chroot /mnt/chroot/
[/cc]

We then update our image and install some essential packages we will need for this process:

[cc lang=”text”]
apt-get update
apt-get install busybox cryptsetup dropbear
[/cc]

We create an initial initramfs file, which will trigger the dropbear SSH key generation. We first find out the modules directory version number as follows (this will change between different image versions):

[cc lang=”text”]
root@kali:/# ls -l /lib/modules/ |awk -F” ” ‘{print $9}’
3.12.36
[/cc]

We then use that version info to generate an initial initramfs file.

[cc lang=”text”]
mkinitramfs -o /boot/initramfs.gz 3.12.36
[/cc]

We configure the OpenSSH service to start at boot, while remembering to change the default password.

[cc lang=”text”]
update-rc.d ssh enable
passwd
[/cc]

Next, we verify that the /boot directory is mounted, and if so, we modify the boot parameters in cmdline.txt and config.txt.

[cc lang=”text”]
nano /boot/cmdline.txt
[/cc]

…and add / change the following parameters:

[cc lang=”text”]
root=/dev/mapper/crypt_sdcard cryptdevice=/dev/mmcblk0p2:crypt_sdcard rootfstype=ext4
[/cc]

Next comes config.txt:

[cc lang=”text”]
echo initramfs initramfs.gz 0x00f00000 & /boot/config.txt
[/cc]

Now we deal with the Dropbear SSH access. We copy over the SSH private key to our laptop:

[cc lang=”text”]
cat /etc/initramfs-tools/root/.ssh/id_rsa
[/cc]

And limit the SSH connection to allow interaction with the cryptroot application only.

[cc lang=”text”]
nano /etc/initramfs-tools/root/.ssh/authorized_keys
[/cc]

We paste the following before the ssh public key begins.

[cc lang=”text”]command=”/scripts/local-top/cryptroot && kill -9 `ps | grep -m 1 ‘cryptroot’ | cut -d ‘ ‘ -f 3`”[/cc]

We then create a fstab and crypttab with our configured boot device and exit the chroot:

[cc lang=”text”]
cat < /etc/fstab
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mapper/crypt_sdcard / ext4 defaults,noatime 0 1
EOF

echo crypt_sdcard /dev/mmcblk0p2 none luks > /etc/crypttab[/cc]

During our tests, we noticed that in some instances, the USB ports take a while to wake up, which can kill the initrd Dropbear network initialization. To fix this, we can introduce a 5-second sleep before the configure_networking function located in the initrd itself:

[cc lang=”text”]
nano /usr/share/initramfs-tools/scripts/init-premount/dropbear
[/cc]

change:

[cc lang=”text”]
configure_networking &
[/cc]

to:

[cc lang=”text”]
echo “Waiting 5 seconds for USB to wake”
sleep 5
configure_networking &
[/cc]

Save and exit the file them regenerate the initramfs and exit the chroot. You can ignore the cryptsetup and device-mapper warnings.

[cc lang=”text”]
mkinitramfs -o /boot/initramfs.gz 3.12.36
exit
[/cc]

Now we proceed to tear down the chroot and backup our rootfs partition:

[cc lang=”text”]
umount /mnt/chroot/boot
umount /mnt/chroot/sys
umount /mnt/chroot/proc
mkdir -p /mnt/backup
rsync -avh /mnt/chroot/* /mnt/backup/
[/cc]

Once outside the chroot, we unmount everything:

[cc lang=”text”]
umount /mnt/chroot/dev/pts
umount /mnt/chroot/dev
umount /mnt/chroot
[/cc]

Once done, we delete the existing 2nd partition on the SD card and recreate an empty one, which we set up for LUKS encryption.

[cc lang=”text”]
echo -e “d\n2\nw” | fdisk /dev/sdb
echo -e “n\np\n2\n\n\nw” | fdisk /dev/sdb
[/cc]

Unplug your SD card and plug it back in to have the new partitions register, then start setting up your encrypted partition.

[cc lang=”text”]
cryptsetup -v -y –cipher aes-cbc-essiv:sha256 –key-size 256 luksFormat /dev/sdb2
cryptsetup -v luksOpen /dev/sdb2 crypt_sdcard
mkfs.ext4 /dev/mapper/crypt_sdcard
[/cc]

Once ready, we restore the rootfs backup to the now encrypted partition.

[cc lang=”text”]
mkdir -p /mnt/encrypted
mount /dev/mapper/crypt_sdcard /mnt/encrypted/
rsync -avh /mnt/backup/* /mnt/encrypted/
umount /mnt/encrypted/
rm -rf /mnt/backup
sync
[/cc]

Then we unmount and close the volume.

[cc lang=”text”]
cryptsetup luksClose /dev/mapper/crypt_sdcard
[/cc]

That’s it! Now all that remains is to boot up the RPi using the modified SD card. The initramfs will load Dropbear and get a DHCP address on your local LAN (you can also hardcode an IP), allowing you to SSH to the booting RPi and enter a decryption password. Once the password is accepted, Dropbear will exit and the RPi will continue to boot. You should see something like the following:

[cc lang=”text”]
root@kali:~# ssh -i key 192.168.0.52
The authenticity of host ‘192.168.0.52 (192.168.0.52)’ can’t be established.
RSA key fingerprint is a6:a2:ad:7d:cb:d8:70:58:d1:ed:81:e8:4a:d5:23:3a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.0.52’ (RSA) to the list of known hosts.
Unlocking the disk /dev/mmcblk0p2 (crypt_sdcard)
Enter passphrase: cryptsetup: crypt_sdcard set up successfully
Connection to 192.168.0.52 closed.
root@kali:~#
[/cc]

Can I Have Some LUKS NUKE With That Pi?

If you are not familiar with the Kali Linux LUKS NUKE feature then you’re missing out. Although this stage is optional, it allows you to configure and apply an emergency self-destruct password to your LUKS encrypted drive. To do this, we simply define a Nuke password on our encrypted partition:

[cc lang=”text”]
root@kali:~# cryptsetup luksAddNuke /dev/sdb2
Enter any existing passphrase: (existing passphrase)
Enter new passphrase for key slot: (new nuke passphrase)
root@kali:~#
[/cc]

With the Nuke password defined, you can now remotely wipe the LUKS decryption keyslots, making the data on the SD card inaccessible.

Raspberry Pi Disk Encryption Video

In order to give a bit more visual context to the process, we made a short video which shows the sequence of commands used to get LUKS disk encryption working on a Raspberry Pi B+. Enjoy!

Kali Dojo 04 – Kali on a Raspberry Pi with LUKS Disk Encryption from Offensive Security.

References

We came up with this procedure by cannibalising ideas and instructions from various sources on the net, most notably, the two below. Big thanks to the Raspberry Pi community!

1. https://www.ofthedeed.org/posts/Encrypted_Raspberry_Pi/
2. http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=7626