Encrypting your HDD with plausible deniability
Certain government agencies feel they're within their right to seize and copy your data as you pass through their checkpoint if you fall into suspicion for some reason. With the presence of an encrypted partition known, they could also compel you to reveal the password. The idiocy is spreading due to the naive belief that security and privacy are a zero-sum game.
I was searching for a way for someone to pass through such a checkpoint with no indication that the drive contains anything other than random data. While there are plausible ways to deny that you know the password, I couldn't find any to deny the existence of encrypted data in the first place.
A stock Ubuntu Linux load installs onto your hard drive without encryption. With a little extra fiddling (using the alternate installer CD), you can encrypt the root partition. However, someone forensically examining the drive will see an MBR and GRUB bootloader, the /boot partition in all its glory, an extended partition record, and a LUKS header on the encrypted LVM physical volume containing your root and swap volumes.
Here I present a method of encrypting the entire physical hard drive. There is no MBR, no /boot partition, and no LUKS header. It requires only a small USB thumb drive or SD card to boot from (I used a MicroSD).
The example commands below use the Ubuntu 9.04 LiveCD, and assume the laptop's HDD is at /dev/sda and the USB stick at /dev/sdb. Adjust these assumptions as appropriate for your system or distro of choice. It does not seem to work with Ubuntu 9.10; I'm still investigating why. You can always update after the install.
Boot into the LiveCD in evaluate mode (no changes to your computer). Open a terminal window, switch to the root user, and run the following commands. When formatting the USB stick, allocate at least 100MB (or the entire stick) for your boot partition, and set the partition's bootable flag.
When the install completes, continue testing your LiveCD environment, and return to your shell to complete a few manual steps. First, the same utilities we installed above need to be installed on your new OS and its initramfs on the /boot partition.
Don't panic yet, that prompt is part of your plausible deniability. That is where you run your cryptsetup command as follows (remember, this is in the initial ram disk's busybox prompt, so there is no shell history retained).
If you're not updating anything on the /boot partition (such as the kernel), you can open a shell prompt, umount /boot and pull your USB drive once you're up and running. By itself, it looks like a rescue disk for some undefined Linux install.
Remember that in many countries, lying to a government agent is a crime in itself. I am not a lawyer, this is not legal advice, and you should obey the law. But, with this setup, if you keep your mouth shut and don't indicate elsewhere that there is encrypted data on the drive, there is nothing on the drive itself to indicate to the courts that there is. As far as any forensic examiner is concerned, the drive could just as well have been freshly wiped with random data.
I was searching for a way for someone to pass through such a checkpoint with no indication that the drive contains anything other than random data. While there are plausible ways to deny that you know the password, I couldn't find any to deny the existence of encrypted data in the first place.
A stock Ubuntu Linux load installs onto your hard drive without encryption. With a little extra fiddling (using the alternate installer CD), you can encrypt the root partition. However, someone forensically examining the drive will see an MBR and GRUB bootloader, the /boot partition in all its glory, an extended partition record, and a LUKS header on the encrypted LVM physical volume containing your root and swap volumes.
Here I present a method of encrypting the entire physical hard drive. There is no MBR, no /boot partition, and no LUKS header. It requires only a small USB thumb drive or SD card to boot from (I used a MicroSD).
The example commands below use the Ubuntu 9.04 LiveCD, and assume the laptop's HDD is at /dev/sda and the USB stick at /dev/sdb. Adjust these assumptions as appropriate for your system or distro of choice. It does not seem to work with Ubuntu 9.10; I'm still investigating why. You can always update after the install.
Boot into the LiveCD in evaluate mode (no changes to your computer). Open a terminal window, switch to the root user, and run the following commands. When formatting the USB stick, allocate at least 100MB (or the entire stick) for your boot partition, and set the partition's bootable flag.
- fdisk /dev/sdb
- apt-get update
- apt-get install watershed lvm2 cryptsetup
- cryptsetup -y -c aes-cbc-essiv:sha256 create crypt /dev/sda
- dd bs=16384 if=/dev/zero of=/dev/mapper/crypt
- pvcreate /dev/mapper/crypt
- vgcreate usb /dev/mapper/crypt
- lvcreate -n swap -L 2G usb
- lvcreate -n root -l 100%FREE usb
- mkswap /dev/mapper/usb-swap
- mke2fs /dev/mapper/usb-root
- /boot is installed on the /dev/sdb1 partition created using fdisk above
- / is installed on /dev/mapper/usb-root
- swap space is on /dev/mapper/usb-swap
When the install completes, continue testing your LiveCD environment, and return to your shell to complete a few manual steps. First, the same utilities we installed above need to be installed on your new OS and its initramfs on the /boot partition.
- mount /dev/mapper/usb-root /mnt
- mount /dev/sdb1 /mnt/boot
- for p in proc dev sys; do mount -o bind /$p ./mnt/$p; done
- chroot /mnt
- apt-get install watershed lvm2 cryptsetup
- exit
- ln -s /mnt/boot/grub /boot/grub
- grub-install --root-directory=/mnt /dev/sdb
- dd if=/dev/zero bs=512 count=1 of=/dev/mapper/crypt
Don't panic yet, that prompt is part of your plausible deniability. That is where you run your cryptsetup command as follows (remember, this is in the initial ram disk's busybox prompt, so there is no shell history retained).
- cryptsetup -c aes-cbc-essiv:sha256 create crypt /dev/sda
- exit
If you're not updating anything on the /boot partition (such as the kernel), you can open a shell prompt, umount /boot and pull your USB drive once you're up and running. By itself, it looks like a rescue disk for some undefined Linux install.
Remember that in many countries, lying to a government agent is a crime in itself. I am not a lawyer, this is not legal advice, and you should obey the law. But, with this setup, if you keep your mouth shut and don't indicate elsewhere that there is encrypted data on the drive, there is nothing on the drive itself to indicate to the courts that there is. As far as any forensic examiner is concerned, the drive could just as well have been freshly wiped with random data.
Labels: aes, deniability, dm-crypt, fde, linux, random data, ubuntu