Cryptreboot

This is the homepage of cryptreboot, a secure and convenient reboot for Linux systems with encrypted root partition.

Just type cryptreboot instead of reboot.

It asks for a passphrase and reboots the system afterward, automatically unlocking the drive on startup using in-memory initramfs patching and kexec. Without explicit consent, no secrets are stored on disk, even temporarily.

Use case

This tool is useful for unlocking the drive after the reboot, especially in challenging situations like on headless or remote systems.

It prompts the user for the passphrase before the reboot, while the system is still fully functional and remotely accessible.

In contrast, with a standard reboot, the passphrase must be entered after the reboot, but before the system becomes fully functional and remotely accessible, requiring the user to enter the passphrase locally.

Demo

This 30-second video demonstrates how the cryptreboot (on the left) compares to a standard reboot (on the right).

Example scenarios

• A headless mini PC configured as a file server for a home network. If the disk is encrypted, you need to connect a keyboard after every reboot because it won't start without entering the passphrase locally.

• A blockchain node hosted at a friend's house due to low internet quality at your location. If the disk is encrypted and you remotely reboot the machine, you would have to ask your friend to enter the passphrase to unlock the disk.

With cryptreboot, you can remotely connect to your machine, perform the reboot, and be confident that it will restart without requiring local intervention.

Not every system start is a reboot

Cryptreboot won’t help you unlock the disk of a powered-off machine that has just been turned on. As the name suggests, cryptreboot is for reboots, not for starting a cold machine. In this case, unless another solution is implemented by the system administrator, unlocking the disk locally will still be required.

If your machine with an encrypted drive is constantly on (e.g., a server or blockchain node) and is protected by a UPS, powering it on should be rare. You will find cryptreboot useful each time a reboot is needed, such as when doing a kernel upgrade.

Quick installation instructions

On Ubuntu type:

sudo apt install ruby kexec-tools
sudo gem install crypt_reboot

When asked if kexec should handle reboots, answer: Yes.

You will find more comprehensive instructions in the README.

Usage

To perform a reboot type:

sudo cryptreboot

To see the usage, run:

cryptreboot --help

In case of issues check the Troubleshooting section in the README.

Security

Boot integrity

Unless a secure and/or measured boot is implemented, every time the system starts, there is a non-zero chance the unencrypted part of the startup code has been altered maliciously to extract the encryption key or compromise the system in another way.

Cryptreboot avoids full system restart and uses kexec instead. This way, each reboot maintains the security level of the initial system startup without introducing an opportunity window for an attacker.

Handling of secrets

In normal operation, key material is handled in memory only. If a given external tool used by cryptreboot requires passing a file containing secrets, cryptreboot puts it on a temporarily mounted ramdisk. This way sensitive material never touches the disk.

Some command line options may cause the keys to be saved to a file or printed on the console. This fact is always mentioned in a given option description, therefore be sure to read it.

Cryptreboot uses memory locking to avoid leaking secrets to swap. However, it uses external tools that may not offer the same level of protection. Therefore, it is advised to use an encrypted swap. The good news is the swap is probably encrypted by default when you use disk encryption.

Interoperability

Cryptreboot has been successfully tested by the author with a standard configuration of Dropbear-enabled initramfs in Ubuntu 24.04. Cryptreboot works the same way as it would normally, while on standard reboot or powering the system on, the disk can be unlocked remotely via ssh.

Other automated and/or remote disk unlocking solutions have not been tested.

How does it work?

The following description has been simplified to convey the main idea without obscuring it with details.

Let’s examine what happens when a user reboots a machine with an encrypted disk. The OS shuts down and the machine is reset. The rest of the boot process is the same as when powering the machine on.

Standard reboot flow.

Then, take a look at how kexec improves it. It skips the machine reset, hardware initialization, firmware, and bootloader. This results in a faster boot. However, the user is still asked for a passphrase after reboot.

Kexec reboot flow.

Combining kexec with initramfs in-memory patching explains how does cryptreboot work. It asks for a passphrase, derives the master key, and saves it in an in-memory copy of initramfs. Then it passes kernel and patched initramfs to kexec. When run, initramfs doesn’t need to ask for a passphrase, because the master key is already there.

Reboot flow using cryptreboot.

For more details and context, see my post introducing cryptreboot.

Planned improvements

• An option for passphrase-less reboots. Ask for the passphrase only once and securely store the disk encryption key. The key will be reused on following reboots without a need for a passphrase.

• More consistency with standard reboot and better compatibility on systems without /boot/vmlinuz symlink (Debian) by boot loader configuration parsing. Currently, cryptreboot relies on symlinks or the user to pick the kernel and initramfs manually.

• Easier installation and configuration for Debian-based distributions by providing a .deb package and PPA repository.

• An option to make cryptreboot the default reboot handler for systems with a passphrase-less reboot configured. Cryptreboot would be invoked when pressing CTRL-ALT-DELETE, a power button, performing a reboot from within the graphical environment, etc.

• Improved reboot time. Currently, initramfs extraction is performed each time, but with proper use of cache, it won’t be needed.

• Support for non-Debian Linux distributions by integrating other methods of initramfs generation such as Dracut.

Enjoying cryptreboot?

Here are a few ways you can show your support:

• Star the project on GitHub.

• Share it on social media, on your blog, or tell your friends in person.

• Subscribe to my blog and follow me on Farcaster.

• Reach out and say hello!

License and author

The software is available as open source under the terms of the MIT License.

My name is Paweł Pokrywka and I’m the author of cryptreboot. If you want to contact me visit this page.