# Encrypted root with unencrypted preboot and reboot -r



## WhiteCoyote (Mar 6, 2020)

Hi there!
Been working with linux for many years and recently started to learn FreeBSD and really loved it.
I'm trying to create a fully encrypted setup with the possibility to unlock the drive remotely (e.g. using SSH).

I know about the possibility to leave the base system and encrypt user data, however, I would like my specific system configs (like the list of users, etc.) to stay encrypted as well. Unfortunately I couldn't find a definitive answer to what is the absolute bare minimum of a base system which can boot and start sshd. The common case is that it can't connect to the network due to the encrypted `/etc`, but otherwise you leave out some of the data (like users).

Then I learned about `reboot -r` and thought about a different solution. I can install FreeBSD using the standard way (e.g. Encrypted ZFS root) such that it's fully encrypted and can be unlocked with physical keyboard. Then I can boot from a custom LiveCD (which connects to the network and starts sshd), unlock the primary disk and simply change the root filesystem with `kenv vfs.root.mountfrom` and then `reboot -r`.
This way I can view the setup as just two separate systems which I can upgrade and maintain separately. I only need to keep the versions (kernel) in sync. While LiveCD has the bare minimum of extra information (basically only an extra ssh host key) and everything else is encrypted. And I can boot the main system on it's own if needed. It seems much simpler than to customly separate a single system into `/boot` and `/` or always making sure no data is leaked to the unencrypted part.

I understand that this way the actual working kerned will be the unencrypted one, but the evil maid attack is outside of scope. The goal is to conceal as much data as possible if the hardware is stolen or accessed physically, and mitigate data leaks into unencrypted parts of the disk.

But due to the limited experience with FreeBSD I don't know what I miss with that approach.
I'm more concerned about what could be the difference between loading into the root fs with `reboot -r` vs the regular boot, i.e. if some kernel parameters might be out of sync or so?
And how feasible this approach is overall?


----------



## T-Daemon (Mar 6, 2020)

Have a look at this github repository, it looks like exactly what you want, except no LiveCD is used, but a small UFS partition, and it's designed for a mirrored ZFS system, but can easily be modified to a single disk (stripe) system, or taken as template to tailor your own script. Summary from the README.md:

*FreeBSD disk encryption with zfs, mirroring and remote-boot functionality*

This repository contains some scripts to help you set up a nearly full-disk-encrypted FreeBSD where you can enter the password via ssh.

This is accompished by having a small ufs partition consisting of the kernel, modules and a statically linked dropbear. It enables networking, and starts dropbear to allow you to log on. Once you entered the password, the boot switches the root filesystem and boot resumes from the zfs same as a normal unencrypted boot.

If you are at the console, you can hit ^c to kill the dropbear and you will be dropped into a shell where you can enter the password at the console and resume booting.
-------------​If you inspect the PREBOOT script you will find familiar concepts, like `kenv vfs.root.mountfrom=` and `reboot -r`.


----------

