🍰 sflc-boot

A custom initramfs to boot into a hidden OS on a Shufflecake-formatted partition.

• 💻 Usage
  • Initramfs
  • Hidden OS
• 💭 Prerequisites
  • Wait, what is Shufflecake?
  • Okay, what is plausible deniability in encryption?
  • But why should the OS itself be run from a hidden volume?

💻 Usage

The setup scripts are designed to be run from an official live image of Arch Linux [ISO] while connected to the internet.

Initramfs

Run esp-setup.sh with its first argument being the partition you want to setup as the EFI System Partition with the Unified Kernel Image containing the custom initramfs. The UKI will be located at the standard path 𝘦𝘴𝘱/efi/boot/bootx64.efi, so the ESP can be booted directly from the UEFI menu, otherwise from any bootloader of your choice.

Tip

For use with Secure Boot, you can mount and arch-chroot into your hidden OS once created, mount the ESP, and sign the UKI using sbctl (or use one of the other methods listed here).

pacman -S sbctl
# Make sure you booted with Secure Boot in Setup Mode
sbctl status
# Installed:	✘ Sbctl is not installed
# Setup Mode:	✘ Enabled
# Secure Boot:	✘ Disabled
sbctl create-keys
sbctl enroll-keys -m -f
sbctl sign -s 𝘦𝘴𝘱/efi/boot/bootx64.efi

For those wanting a different setup, run esp-setup.sh without any arguments to simply output the initramfs.cpio.gz and bootx64.efi files in the current directory for further use.

Note

For example, to use the initramfs image to build a UKI with custom kernel cmdline parameters and a(n uncompressed) CPU microcode CPIO archive included, run a command like

ukify build --linux=/lib/modules/$(uname -r)/vmlinuz \
            --initrd=cpu-ucode.img \
            --initrd=initramfs.cpio.gz \
            --cmdline="quiet rw"

Hidden OS

If you already ran esp-setup.sh, it will also have created in the working directory the shufflecake and dm-sflc.ko files that you need to create and open a Shufflecake partition.

Otherwise, build Shufflecake:

mount -o remount,size=2G /run/archiso/cowspace
pacman -Sy git make gcc device-mapper libgcrypt
pacman -U https://archive.archlinux.org/packages/l/linux-headers/linux-headers-$(uname -r | sed 's/-/\./')-x86_64.pkg.tar.zst
git clone --depth 1 https://codeberg.org/shufflecake/shufflecake-c
cd shufflecake-c
make

Stay in the same directory and load the kernel module dm-sflc.ko before using Shufflecake.

insmod dm-sflc.ko

Now the commands to initialize a partition /dev/sdXY for use with Shufflecake and to open volumes on it are simply

./shufflecake init /dev/sdXY
./shufflecake open /dev/sdXY

The volumes will be opened as some /dev/mapper/sflc_M_N.

Run root-setup.sh with its first argument being whichever of these volumes you wish to setup an installation of Arch Linux in. It will be relatively barebones, but you can install more programs later.

Close all the Shufflecake volumes on the partition with

./shufflecake close /dev/sdXY

Tip

If you later want to run esp-setup.sh, you can do so within the shufflecake-c/ directory containing the shufflecake and dm-sflc.ko files to avoid building them again.

💭 Prerequisites

Wait, what is Shufflecake?

Shufflecake (website, repo) is a disk encryption program for Linux — developed in 2022 as an EPFL master's thesis [PDF] project — that aims to provide plausible deniability.

Okay, what is plausible deniability in encryption?

Deniable encryption is similar to steganography — as long as the encrypted header and partition look like random bytes, you can claim that it's simply space that's been erased via overwriting with random 0s and 1s. Even given that there exists some encrypted data, you can deny your ability to decrypt it by claiming to have lost or forgotten the key.

But when the partition in question is large and can be shown to have been used recently, neither of these defenses may be very convincing and could get you accused of destroying/hiding data. In jurisdictions that mandate key disclosure, or in certain illegal cases of coercion (xkcd), not providing any key at all can result in being labelled uncooperative and facing the legal or illegal consequences of that label.

Shufflecake tries to make the denial plausible by hiding, in the unused space of other volumes, further volumes that are encrypted and look like discarded random bytes. This allows the user to surrender a password that decrypts some (decoy) volumes, but not all — thus avoiding being seen as uncooperative while weakening the prosecution's claim to the arbitrary-sounding "He provided a password that decrypted M volumes but maybe there are N volumes!!1!1!" 😠

But why should the OS itself be run from a hidden volume?

From the original paper:

[...] the OS itelf (or other applications installed therein) can unintentionally leak to an adversary the presence of hidden data when a hidden volume is unlocked. This can happen for example through the OS logging disk events, search agents indexing files within the hidden volume when this is unlocked, even applications such as image galleries or document readers caching previews of opened documents. Customizing the OS’ behavior in such a way to avoid these pitfalls is an almost hopeless task. A proposed solution to this problem is to have the OS itself inside a hidden volume.

To facilitate this, we create a custom initramfs image containing Shufflecake that can ask for a password and boot into such a hidden OS on start-up.

Important

For plausibility, the decoy OS(es) need to be kept up-to-date by regularly performing system updates, downloading emails, etc.