Question: when remotely unlock the boot disk via ssh, how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys?
At some point I wanted to do something with utrablue [1], to work over network rather than Bluetooth, but then it was in go and I got lazy suddenly :)
> how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys?
In my case, I can't. This is a NAS in my house and this is mostly to prevent me from having to go to another room and plug in a monitor and keyboard. (Also, I've done this from across the country after a power outage.)
The threat vectors I'm protecting against are I guess mostly theft of the entire machine, or forgetting to wipe the drives when I eventually toss them out. Mostly, it's just fun practice because I'm a nerd and every drive should be encrypted.
For my use-case, the auto-unlock-by-polling-a-specific-LAN-IP linked in this thread would probably be fine, for example.
Well you can always drill holes in the platter, or hit them with a strong magnet, or just separate them and toss them in the trash. Unless you're fighting the NSA, you can probably get away with enough physical destruction to make recovery challenging.
In theory this should be a perfect match for TPM-powered secure booting: your machine starts every time with a clean TPM, which validates the BIOS into it, which validates the bootloader into it, which validates the kernel into it, which derives an RSA private key from the resulting TPM state. If an attacker compromises it, it'll present the wrong host key and you get a big fat error message.
Mandos tries to mitigate this problem by periodically checking that the rebooting server is still up. Exactly how this is done is configurable, but by default it uses ssh-keyscan to check if the server is up and using the SSH server key from its normal encrypted root file system. If a server is ever down too long (configurable, default 5 minutes), the Mandos server will “disable” that server in its server list, and not provide the password to that server anymore.
The idea is that you should configure the timeout to be long enough to allow for a normal kernel panic and reboot, but hopefully short enough that it would be hard for anyone to compromise the server in that time. It’s not a perfect solution, but it’s the best anyone has come up with as far as I know.
The server itself may have been physically breached, and if so you can’t trust anything. But, if your host key matches, you should be confident that at least you’re logging into the correct machine (there was no IP takeover).
True, but in that case, I think it would still be difficult to swap in a completely new system into the network (with your IP) with your old private host key.
(Without a physical breach... if that happens, all bets are off).
What are the best options to solve this problem? It’s a hard problem imho for most threat models.
If the booting machine has been compromised and i use my usb connected keyboard to enter the full disk encryption key I would run into the exact same issues, no?
The ultrablue project I linked to solve exactly this problem, with TPM and a smartphone, but it's targeted at unlocking your laptop and uses Bluetooth to communicate with the smartphone for unlocking - and I don't want to have Bluetooth on my NAS ^^
Theoretically you could use secure boot with custom keys to ensure that your boot chain is not modified and you could use TPM for SSH host keys storage to ensure that it's not possible to copy them.
I have disk encryption on a remote server on cheap low-asssurance hosting, and I do it so I don't have to worry about what happens when the disks are recycled. If I could (easily) automate entering the key on boot, I would (but I'm running FreeBSD, so Linux solutions don't help). But I don't need to reboot often and the hardware is fairly reliable, so eh.
This is for my personal hosting which if someone wants to take over, I guess I'd be more curious than upset.
At some point I wanted to do something with utrablue [1], to work over network rather than Bluetooth, but then it was in go and I got lazy suddenly :)
[1] https://github.com/ANSSI-FR/ultrablue