[[!template id=project

title="Transparent full-disk encryption"

contact="""
[tech-kern](mailto:tech-kern@NetBSD.org)
"""

category="filesystems"
difficulty="medium"
duration="2 months"

description="""
While currently we have the [[!template id=man name="cgd" section="4"]]
driver for encrypting disks, setting it up is fairly involved.
Furthermore, while it's fairly easy to use it just for /home, in an
ideal world the entire disk should be encrypted; this leads to some
nontrivial bootstrapping problems.

Develop a scheme for mounting root on cgd that does not require
explicit manual setup, that passes cryptographic muster, and that
protects everything on the root volume except for what absolutely must
be exposed.
Implement it.

The following is a non-exhaustive list of issues to consider:

 * How should we tell when root should be on cgd (perhaps in boot.cfg?)
 * When (and how) do we enter the passphrase needed to mount root (at mount-root time? in the bootloader? after mounting a fake root?)
 * Key management for the encryption passphrase
 * Where to keep the bootloader and/or kernels
 * Should the bootloader be able to read the cgd to get the boot kernel from it?
 * If the kernel is not on cgd, should it be signed to allow the bootloader to verify it?
 * Integration with sysinst so all you need to do to get FDE is to hit a checkbox
 * Perhaps, making it easy or at least reasonably possible to migrate an unencrypted root volume to cgd

Note that while [[!template id=man name="init" section="8"]] currently has a scheme for mounting a
temporary root and then chrooting to the real root afterwards, it
doesn't work all that well.
Improving it is somewhat difficult; also, ideally
[[!template id=man name="init" section="8"]]
would be on the encrypted root volume.
It would probably be better to support mounting the real root directly
on cgd.

Another option is a pivot_root type of operation like Linux has, which
allows mounting a fake root first and then shuffling the mount points
to move something else into the / position.
This has its drawbacks as well, and again ideally there would be no
unencrypted fake root volume.

"""
]]