5 ms·
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 t
by forty 3y ago
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 :)
[1] https://github.com/ANSSI-FR/ultrablue https://github.com/ANSSI-FR/ultrablue
- bretthoerner 3y ago> 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.
- jethro_tell 3y agoThis is mostly me but the case that's the most common is that a disk can't be wiped because its dead. Gotta do that before hand.
- aftbit 3y agoWell 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.
- jethro_tell 3y agoThat doesn't work if you need to RMA the disk. So best to encrypt before you put anything on the disk
- jsmith99 3y agoThis is what a TPM is designed to prevent, but they’re not very popular in Linux community.
- rand846633 3y agoWhat 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?
- fbdab103 3y agoIf you have physical access, seems way easier to put a keylogger directly into the keyboard.
- vbezhenar 3y agoTheoretically 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.
- forty 3y agoThe 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 ^^
- pmorici 3y agoTPM and checking your physical security boundary hasn't been breached.
- mbreese 3y agoIsn’t there a host SSH key involved? 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).
- deleted 3y ago[deleted]
- akerl_ 3y agoIf the server was breached, what stops somebody from copying the host key to their new system.
- mbreese 3y agoTrue, 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).
- toast0 3y agoI 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.
- crote 3y agoIn 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.
- teddyh 3y agoMandos 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. (Disclosure: I am a co-author of Mandos.)