On 3/5/14 3:30 PM, Ted Unangst wrote: > On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote: >> Hi, >> >> I have one linux server that has full disk encryption, and I use >> it's initramfs with dropbear to be able to remote unlock the encrypted >> root partition. >> >> From what I read from the OpenBSD documentation, this is not >> possible now. I want some guidance for what areas of code I would need >> to modify, to accomplish the same. I know it would involve lots of >> hacking with boot(8), with the kernel itself, and perhaps more. Also, I >> want to know how hard you guys think it would be. > > I'm aware of some issues in this area. > > You probably need to modify boot to default to serial console. The > normal approach, taken by the installer, is to use boot.conf, but of > course that's not readable before the disk is decrypted. This is > assuming you will use serial console to provide the password instead > of regular keyboard. > > If you want to provide the password over the network, I think that's > going to be way more work. pxeboot may be a place to start, but I > don't think you'll like where that leads and it won't be very secure > either.
I think that's silly, then once your box is compromised it could pretend to be pxebooting and just grab your password, or some passive attacker on your network could sniff it, or the pxeboot server being compromised would lead to all your passwords being compromised. > Or get a server that supports some sort of kvm/console over IP. Which likely isn't going to be super secure either. The best remote access thing I've seen was a sun server which supported ssh, but it was limited at best. The best solution for you really depends on your threat model. If you're worried about protecting your data, then you don't really need full disk encryption, you just need your data partition encrypted. If you're worried about protecting your entire system from malicious people with physical access to your drive, I'd argue that if you need to defend against that, you're already screwed anyway (they could just overwrite your bootloader with a malicious one that records your pw, among a plethora of other potential attacks). If by "full disk encryption" you're willing to accept more than your bootloader being unencrypted, then I'd suggest the old (pre-bootloader-support) way. You could have your system boot, start ssh, and notify you (email or whatever) that it needs you to ssh in and run bioctl(8) yourself, and then go start whatever services you wanted to actually start at boot. Of course, this could all be nicely automated with a bit of work. This has the advantage of being able to run a good, open, updated sshd as opposed to whatever "was probably hopefully maybe secure at some point" embedded sshd shoved into your lights out management micro-controller with its firmware-limited-to-1024-bit RSA key generated from very little entropy by a system you can not audit. There is certainly something to be said for being able to send your key out of band, but when "out of band" means a stupid impi controller hacked into the same network interface anyway, I don't really see the added security.
