- Contact: tech-kern
- Duration estimate: 2 months
While currently we have the cgd(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 init(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 init(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.
I think you should do something that no one wants to do. Take as much as you can from a long term existing system. There's a program that started on win98(name change)(scramdisk) and moved to Win 2000(ECM) then on Win XP,...etc(Truecrpyt). It now is rewritten and called (Veracrypt) for Windows, Linux, Mac OS and Raspberry Pi ARMv7. The only thing stopping me from moving to one of the BSD's is reading truecrypt files. DragonflyBSD reads Truecrypt through tcplay a rewrite of truecrypt but DF is a little more experimental than I want for a desktop.
https://www.dragonflybsd.org/features/#index5h2
So there's two versions from the same Truecrypt source. Tcplay and Veracrypt. Veracrypt is a newer version that is audited and has corrected some small deficiencies of TC so is better but bigger, more complete and complex. The MacOS works through FUSE specifically OSXFUSE 2.5. Linux I think through DMcrypt. Here's what so good about Veracrypt/Truecrypt. It has encryption on the fly for not only regular drives but the OS system drive also, after it's running. This means not setting up encryption but encrypting the drive as the OS runs, then writing the boot with password enabled. It's very, very nice. I'm not saying that all these things need to be in place at once but using the code they have already written shows a pathway. Too start just use the code for equivalent encryption to Veracrypt(which has a compatibility function for Truecrypt). The important thing is Truecrypt has been around a long, long time and lots of people have this format and it works. For some reason people keep reinventing the wheel and will not use that which a lot of work has gone into already. Now I KNOW that porting this will not be easy but maybe NetBSD's FUSE can be used the same way that Veracrypt uses MacFUSE. Strip out the GUI stuff but know that it can be added and most of it is already set up for GTK in the MAC so the possibility remains to have it on a desktop with GUI using the lower level already done. Sorry so long but it complicated.
I forgot to add that Truecrypt had a version for Linux and at one time had a BSD version which I believe no longer is around or operative. Truecrypt was anonymously written and he closed up shop and just disappeared one day. Truecrypt has also had extensive code verification leading to additions in Veracrypt.
Here's a link for tcplay(derivative or Truecrypt).
https://github.com/bwalex/tc-play
Veracrypt
https://veracrypt.codeplex.com/
and the Dragonfly BSD I linked above where it's use of tcplay is described.
I hope this is helpful All the questions that you asked in the summary have been answered on other systems with TC and VC. I know they're not Net but it could be a good start on how they've managed it.
Now veracrypt is supporting FreeBSD. The reason I'm pushing this is it the biggest standard across platforms. Veracrypt supports Truecrypt. Truecrypt had a method of encrypting a whole systen drive while it was running live drive and the source code is available. Does that mean it could be done for NetBSD, well no but it's a start. It has been done on Windows.
https://www.veracrypt.fr/en/Downloads.html
I see a lot stuff that's BSD or open source and it seems they frequently are always reinventing the wheel. It's depressing sometimes.