Kali Pi 2018, Secure

Although we have already covered the creation of secure “throwaway hack boxes” with the Raspberry Pi , it seemed like it was high time that we revisited the entire process. We found that the process needed to be updated with all of the changes in Kali and the Raspberry Pi models.

We are trying to make a “leave behind” standalone device which, once discovered, makes it difficult to find what you did. This is why we combine the LUKS nuke and full disk encryption with the LUKS Nuke to create this device. You can use these instructions to create your secure Raspberry Pi 3 Model B+ system. The updated procedure is based upon our prior documentation and includes some community .

A description of the entire process

Let’s first take a look at the goals for setting up Raspberry Pi 3 Model B+, also known as “RPi”:

1. Create a normal Kali Linux RPi installation
2. Preparation for remote boot encryption and system lock
3. To allow unlocking to take place, create an initramfs with Dropbear keys and SSH keys.
4. Backup existing data
5. Setup the encrypted partitions
6. Restore our data
7. Configure LUKS Nuke
8. Get cracking!

Although it may seem daunting, this is actually quite simple. Once completed, the RPi will start, receive an IP from DHCP and Dropbear allows us to connect via SSH so that we can provide the LUKS keys. This allows us to use the RPi without a host, while still protecting our data. We can then retrieve the data or remotely delete it with LUKS NUKE.

Prepare the Base System

First, you need to save the RPi image on a SD Card. This is not the place to go, but we have information.

Once that is done, insert your SD card in the RPi. After the initial boot, the SD card will be resized and then rebooted. We connect via SSH and update Kali. Finally, we install the packages that we need.

Apt update apt Dist-Upgrade apt Install cryptsetup LVM2 Busybox Dropbear

The Magic-Fu Method

Now that the RPi has been set up, let’s dive in. We will be making changes to a few files in our RPi install once this is completed. You should not restart the device, or shut it down altogether until you’re ready. Otherwise you might end up with a system that will not boot.

We must first append a line to /boot/config.txt.

echo Initramfs.gz Followkernel >> Boot/config.txt

The next step is to verify the location of our root filesystem device:

:~# cat /etc/fstab # proc /proc proc defaults 0 0 /dev/mmcblk0p1 /boot vfat defaults 0 2 /dev/mmcblk0p2 / ext4 defaults,noatime 0 1 

Our root filesystem is located at and /dev/mmcblk0p2. These are the files we’ll use in our future examples. Be sure to change your instructions accordingly.

Once we have the root location of our filesystem, we can edit the . It contains these default settings:

:~# cat /boot/cmdline.txt dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0 

Note the entry root=/dev/mmcblk0p2. It will be updated with a cryptodevice value.

root=/dev/mapper/crypt cryptdevice=/dev/mmcblk0p2:crypt 

After the file was modified, it looks as follows:

:~# cat /boot/cmdline.txt dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mapper/crypt cryptdevice=/dev/mmcblk0p2:crypt rootfstype=ext4 rootwait rootflags=noload net.ifnames=0 

Also, we need to modify /etc/fstab as well as replace the device whose root filesystem is currently /dev/mapper/crypt.

:~# cat /etc/fstab # proc /proc proc defaults 0 0 /dev/mmcblk0p1 /boot vfat defaults 0 2 /dev/mapper/crypt / ext4 defaults,noatime 0 1 #/dev/mmcblk0p2 / ext4 defaults,noatime 0 1 

The next step is to create an /etc/crypttab document that contains the following:

crypt /dev/mmcblk0p2 none luks 

Be careful here. The separators between entries must be tabs and not spaces. Before we can create our initramsfs we will need to perform a clever hack to make cryptsetup include us. We will make a fake LUKS system to do this. We create a fake LUKS filesystem by creating an empty file.

dd if=/dev/zero of=/tmp/fakeroot.img bs=1M count=20 cryptsetup luksFormat /tmp/fakeroot.img cryptsetup luksOpen /tmp/fakeroot.img crypt mkfs.ext4 /dev/mapper/crypt 

Do not worry about creating a strong password to this fakeroot, as this is the only use of it.

Initramfs and SSH setup

We are now on the final stretch. This is a really exciting part. Normally, when LUKS boots up, it pauses for you to access the HDD using your LUKS keys. This is not ideal if you’re running a headless computer system.

Dropbear will be configured to launch, authenticate using SSH and connect to you for your LUKS password.

We start out by creating a file at /etc/dropbear-initramfs/authorized_keys that contains:

command="export PATH='/sbin:/bin/:/usr/sbin:/usr/bin'; /scripts/local-top/cryptroot && kill -9 `ps | grep -m 1 'cryptroot' | cut -d ' ' -f 3` && exit" 

This must be on one line. There should be no line breaks. This should be the result if you do it right.

:~# cat /etc/dropbear-initramfs/authorized_keys command="export PATH='/sbin:/bin/:/usr/sbin:/usr/bin'; /scripts/local-top/cryptroot && kill -9 `ps | grep -m 1 'cryptroot' | cut -d ' ' -f 3` && exit" ssh-rsa AAAAB3NzaC...  

Next, we make a small change to /usr/share/initramfs-tools/scripts/init-premount/dropbear. We need to slow Dropbear down to make sure that Dropbear can start up properly. It is located at the bottom of the file.

# Wait until your network has been configured before you mount NFS. Local mounts: # Configure the network in background using run_dropbear(). This allows someone with console access to enter the passphrase instantly. Configure_networking will hang for up to 5 minutes if the # network goes down.  >/run/dropbear.pid

This -sleep statement is what we want:

 >/run/dropbear.pid

Now we can finally create our Initramfs.

mkinitramfs -o /boot/initramfs.gz 

We ensure our custom changes are included in the final document before we proceed.

lsinitramfs /boot/initramfs.gz | grep cryptsetup lsinitramfs /boot/initramfs.gz | grep authorized 

Once that is done, all modifications are saved to the disk. Finally, shut down the RPi.

sync && sync init 0 

Backup and restore

Remov the SD card and then return to the original system that was used for writing the SD cards. Let’s get the environment ready.

ls -al /mnt/chroot,backup,encrypted # Please make sure there is nothing here first before you move on, otherwise you will have a bad day. rm -rf /mnt/chroot,backup,encrypted mkdir -p /mnt/chroot,backup,encrypted

Insert the SD card, and verify the device ID. The device in our example is /dev/sdc2. However, yours may be different. Adjust your system accordingly. Mount the device, and then make a backup.

mount /dev/sdc2 /mnt/chroot/ rsync -avh /mnt/chroot/* /mnt/backup/ umount /mnt/chroot 

After that, delete the SD card’s 2nd partition and create a new empty one. This is used for LUKS encryption.

 fdisk /dev/sdc echo -e "nnpn2nnnw" 

After the partitions have been updated, run partprobe to reload them. Next, configure LUKS for the new partition.

cryptsetup -v -y --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdc2 cryptsetup -v luksOpen /dev/sdc2 crypt mkfs.ext4 /dev/mapper/crypt 

We now restore the root backup from the encrypted partition.

mount /dev/mapper/crypt /mnt/encrypted/ rsync -avh /mnt/backup/* /mnt/encrypted/ sync umount /mnt/encrypted/ cryptsetup luksClose /dev/mapper/crypt 

It’s worth trying

Now you can insert the SD card into your RPi, and it will start. Dropbear should start to run if you are watching the boot. You should then be able SSH into Dropbear to unlock your drive.

[email prote ]:~# SSH -o UserKnownHostsFile [email] The authenticity host 10.42.42.94 (14.2.42.94) can't been established. ECDSA key fingerprint is SHA256:L+QVP+OmncGDleuEoj77OlRGuCji2gp0c1gMYjUupU0. Do you agree to allow us to connect (yes/no). Yes Warning: Permanently added 10.42.42.94 (ECDSA to the list) Please unlock disk/dev/mmcblk0p2: (crypt). Connection to 10.42.42.94 successfully established.

These little gadgets combined with Kali’s power never cease to amaze us. We now have a system that we can use with relative security, knowing that even if the device is discovered it will be easy to access.

We aren’t finished yet. We can add functionality.

cryptsetup luksDump /dev/mmcblk0p2 cryptsetup luksAddNuke /dev/mmcblk0p2 

When we enter SSH into the device, there are two passwords we can use to enable the SD card to unlock the system and to continue the boot process. The other password will destroy the LUKS header and make the data unaccessible. This option could prove very useful if you are unable to retrieve your device. You could combine this with . This allows you to remotely unlock/nuke the device using a wireless connection. If you don’t have access to the network that the RPi is attached to, this can be very helpful.