Boot network for remote unlock of fde
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. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
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. Or get a server that supports some sort of kvm/console over IP.
Re: Boot network for remote unlock of fde
Em 05-03-2014 17:30, Ted Unangst escreveu: 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. Or get a server that supports some sort of kvm/console over IP. Ted, Thank you for your reply. I am tending for the generic solution for unlocking it via network. Not using console nor any hardware assist. On linux, using initramfs + busybox + dropbear + some other hacks, it works quite well and secure, since you unlock it through ssh. I took a look at pxeboot, but I don't think it will work. I know it is a chicken-egg problem, but I want to take a shot at it. Just would like some guidance, where to start. I know that maybe it would need some approach in the lines of initramfs, but I would avoid it as much as I can, if possible. I think a unencrypted partition/disklabel with boot.conf and the kernel, plus some hack with boot itself to initialize the network device, and configure it's ip address would be more interesting. Or even just boot.conf on the partition. This would require that boot(8) would do most of the work, even a small sshd implementation. Any ideas? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
On 2014/03/05 17:48, Giancarlo Razzolini wrote: Em 05-03-2014 17:30, Ted Unangst escreveu: 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. Or get a server that supports some sort of kvm/console over IP. Ted, Thank you for your reply. I am tending for the generic solution for unlocking it via network. Not using console nor any hardware assist. On linux, using initramfs + busybox + dropbear + some other hacks, it works quite well and secure, since you unlock it through ssh. I took a look at pxeboot, but I don't think it will work. I know it is a chicken-egg problem, but I want to take a shot at it. Just would like some guidance, where to start. I know that maybe it would need some approach in the lines of initramfs, but I would avoid it as much as I can, if possible. I think a unencrypted partition/disklabel with boot.conf and the kernel, plus some hack with boot itself to initialize the network device, and configure it's ip address would be more interesting. Or even just boot.conf on the partition. This would require that boot(8) would do most of the work, even a small sshd implementation. Any ideas? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC What are you trying to protect against? If somebody has physical access, they can presumably replace the kernel/initramfs with a trojanned version ...
Re: Boot network for remote unlock of fde
Em 05-03-2014 18:05, Stuart Henderson escreveu: On 2014/03/05 17:48, Giancarlo Razzolini wrote: Em 05-03-2014 17:30, Ted Unangst escreveu: 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. Or get a server that supports some sort of kvm/console over IP. Ted, Thank you for your reply. I am tending for the generic solution for unlocking it via network. Not using console nor any hardware assist. On linux, using initramfs + busybox + dropbear + some other hacks, it works quite well and secure, since you unlock it through ssh. I took a look at pxeboot, but I don't think it will work. I know it is a chicken-egg problem, but I want to take a shot at it. Just would like some guidance, where to start. I know that maybe it would need some approach in the lines of initramfs, but I would avoid it as much as I can, if possible. I think a unencrypted partition/disklabel with boot.conf and the kernel, plus some hack with boot itself to initialize the network device, and configure it's ip address would be more interesting. Or even just boot.conf on the partition. This would require that boot(8) would do most of the work, even a small sshd implementation. Any ideas? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC What are you trying to protect against? If somebody has physical access, they can presumably replace the kernel/initramfs with a trojanned version ... I'm not trying to protect anything. Physical access almost always means game over. There could be some work on the area of trusted booting, using TPM chips, but this is another beast entirely. I'm trying to be able to remote unlock my full disk encrypted OpenBSD installation in a way that the keystrokes can't be intercepted in the wire. There is already a protocol for this, which is ssh. The trick is to have it working in the boot process. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
On Wed, Mar 05, 2014 at 06:11:35PM -0300, Giancarlo Razzolini wrote: I'm not trying to protect anything. Physical access almost always means game over. There could be some work on the area of trusted booting, using TPM chips, but this is another beast entirely. I'm trying to be able to remote unlock my full disk encrypted OpenBSD installation in a way that the keystrokes can't be intercepted in the wire. There is already a protocol for this, which is ssh. The trick is to have it working in the boot process. you could try to reproduce the Linux initramfs configuration with a bsd.rd (the installer) like setup to launch an ssh server unlock you real root. But OpenBSD is missing the pivot_root system call, so you'll need to implement it. Other tricks (like just chrooting into the real root fs) will produce more or less frankenstein systems that wont reboot cleanly or may exhibit other unexpected behaviours. -- Matthieu Herrb
Re: Boot network for remote unlock of fde
On Wed, Mar 05, 2014 at 06:36:55PM -0300, Giancarlo Razzolini wrote: | One byproduct of such design would be the possibility of redirecting the | console to the ssh connection. I know this is deranging from the initial | idea, but make perfect sense. Anyway, I noted your concerns on this. | Now, anyone have any design idea for implementing this? Your SSH key will always be readable. Either you have a readable SSH host key in the initramfs or the one on disk is readable. With your ssh host key compromised, your disk encryption means nothing. I have one machine in a datacenter with FDE. Well, almost Full: I added a very small sd0a partition with an /etc/boot.conf that sets console output to the serial port. Then I have secure access to the console via another machine where I have ssh access. Of course, if that other machine ever gets compromised, my FDE password is equally compromised. There's one other downside to the small sd0a as of somewhere between 5.4 and 5.5: I now have an /etc/random.seed there too that I need to remember to update after a reboot (I've got an @reboot cron to remind me though). Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: Boot network for remote unlock of fde
Giancarlo Razzolini [grazzol...@gmail.com] wrote: One byproduct of such design would be the possibility of redirecting the console to the ssh connection. I know this is deranging from the initial idea, but make perfect sense. Anyway, I noted your concerns on this. Now, anyone have any design idea for implementing this? Personally I think this sort-of soft-IPMI is a pretty cool idea and I found Matthieu's reply enlightening as well. Apparently Linux has made some progress beyond pivot_root and there are some interesting ideas there. (Note that we have a functioning tmpfs.) http://www.spinics.net/lists/util-linux-ng/msg08794.html https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt Evolving the kernel ramdisk to extract archive to a tmpfs might be the right thing to do if the BSD tmpfs has the same advantages (doesn't run the backing store back through the buffer cache etc.)
Re: Boot network for remote unlock of fde
On Wed, 5 Mar 2014, Stuart Henderson wrote: What are you trying to protect against? If somebody has physical access, they can presumably replace the kernel/initramfs with a trojanned version ... It protects against stolen machines, but not active attacks. Our cryptoraid doesn't protect against active attacks either - the attacker can replace the bootloader with something that phishes your password. The closest we could get to fixing that would be to use the TPM on some x86 systems, but there are ways around that too... -d
Re: Boot network for remote unlock of fde
On 2014/03/06 09:15, Damien Miller wrote: On Wed, 5 Mar 2014, Stuart Henderson wrote: What are you trying to protect against? If somebody has physical access, they can presumably replace the kernel/initramfs with a trojanned version ... It protects against stolen machines, but not active attacks. Our cryptoraid doesn't protect against active attacks either - the attacker can replace the bootloader with something that phishes your password. The closest we could get to fixing that would be to use the TPM on some x86 systems, but there are ways around that too... -d If that's the use case, then a custom rc script or ramdisk kernel that lets you ssh in, unlock most of the disk, and start other daemons might be enough.. If it's desirable to protect /etc, the majority of files in there could be copied over to ramdisk after mounting (or a partition on the protected disk could be mounted over the minimal /etc)..
Re: Boot network for remote unlock of fde
previously on this list Giancarlo Razzolini contributed: I prefer to have /etc and everything else encrypted. If not, I would have to move lots of configuration files to the encrypted partition, not to mention that it would very error prone. You can always use symlinks or mount encrypted partitions into say /etc/ssl. I believe the absolute OpenBSD original book mentioned you couldn't have /etc on it's own partition and I guess it must be on root for boot of /etc/rc but I would also guess you could mount over the top before starting sensitive data handling services. You would just need to keep them in sync when upgrading the system and thankfully OpenBSD's startup is rather neat and can be handled with comparatively little trouble Though I can understand the FDE approach for Linux due to it's rather and pointlessly (IMO) complex boot. It seems to me you are going to a lot of effort to achieve little but a slower system with less entropy and aiding crypt-analysis a little due to predictable data when all you really need is a bit of scripting or consideration of how you can most conveniently and best protect what you need to. Encrypting logs is no chicken and egg problem and very straight forward. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: Boot network for remote unlock of fde
previously on this list Kevin Chadwick contributed: Though I can understand the FDE approach for Linux due to it's rather and pointlessly (IMO) complex boot. Obviously not all using the linux kernel like buildroot for embedded which can be literally six lines of shell but probably every desktop distro. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: Boot network for remote unlock of fde
Em 05-03-2014 19:03, Chris Cappuccio escreveu: Personally I think this sort-of soft-IPMI is a pretty cool idea and I found Matthieu's reply enlightening as well. Apparently Linux has made some progress beyond pivot_root and there are some interesting ideas there. (Note that we have a functioning tmpfs.) http://www.spinics.net/lists/util-linux-ng/msg08794.html https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt Evolving the kernel ramdisk to extract archive to a tmpfs might be the right thing to do if the BSD tmpfs has the same advantages (doesn't run the backing store back through the buffer cache etc.) Chris, The first answer that is trying to give some ideas, rather than just criticizing security. I'm aware of all the shortcomings of this solution. I had to hack some time with linux's initramfs to get some sense of security. I even managed to have pppd embedded on it so I can unlock my server over the internet, not just lan. I have it even to run some script that set's it's ip address on my dns server that has it's SSHFP record, so I won't be victim to impersonating attacks. It's working quite well, I must say. Physical access means game over, even more with the solution pointed by you guys, of moving things and creating symlinks. It opens up more attack vectors. Telling me to have another machine to redirect the console to, booting with a pendrive, and every other ideas that rely on external things, is not necessary. I'm aware of those possibilities. Rather than that, what about contribute with ideas for this. I believe that it's not only FDE unlocking that would benefit of early network. As I mentioned before, the possibility of redirecting the console to the ssh session is one of them. I believe that there are others. Come on guys, I'm not asking for implementation, just want some pointers and ideas. I know it would be a very hard task, but I would like the challenge. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
On Wed, Mar 05, 2014 at 22:28, Giancarlo Razzolini wrote: Rather than that, what about contribute with ideas for this. I believe that it's not only FDE unlocking that would benefit of early network. As I mentioned before, the possibility of redirecting the console to the ssh session is one of them. I believe that there are others. Come on guys, I'm not asking for implementation, just want some pointers and ideas. I know it would be a very hard task, but I would like the challenge. If we're going to discuss things that would be useful, I have for quite some time wanted a kexec() syscall that loads a new kernel and reboots into it. I think that would be helpful for a variety of tasks, not least of which is avoiding the four minute BIOS countdown sequence on overengineered servers. As for FDE, you'd initially boot to a small, normal OpenBSD installation. Like an initramfs, but not all scrunched up. You login via ssh and run kexec /bsd sr0a:password or something, which tells the system to reboot with that kernel, except using softraid as the root partition.
Re: Boot network for remote unlock of fde
Em 05-03-2014 23:01, Ted Unangst escreveu: If we're going to discuss things that would be useful, I have for quite some time wanted a kexec() syscall that loads a new kernel and reboots into it. I think that would be helpful for a variety of tasks, not least of which is avoiding the four minute BIOS countdown sequence on overengineered servers. As for FDE, you'd initially boot to a small, normal OpenBSD installation. Like an initramfs, but not all scrunched up. You login via ssh and run kexec /bsd sr0a:password or something, which tells the system to reboot with that kernel, except using softraid as the root partition. Now we're talking. I thought of this also, didn't looked at the complexity of it yet. Another task where it would be useful, is in overwriting the RAM with /dev/zero or /dev/random. This approach is used on TAILS live cd to wipe the RAM after use. But I believe, not have looked much at the code yet, that the kexec() approach would be simpler than implementing the pivot_root(). Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Boot network for remote unlock of fde
But I believe, not have looked much at the code yet, that the kexec() approach would be simpler than implementing the pivot_root(). Well, certainly less issues to deal with in C code. Instead you'll be running up against debugging things relating to that file called locore.S ...
Re: Boot network for remote unlock of fde
Em 05-03-2014 23:17, Theo de Raadt escreveu: But I believe, not have looked much at the code yet, that the kexec() approach would be simpler than implementing the pivot_root(). Well, certainly less issues to deal with in C code. Instead you'll be running up against debugging things relating to that file called locore.S ... Yes, I was looking at this file a few moments before you e-mail arrived. Seems some pretty scary asm stuff. Nevertheless, I'm still willing to take a look at it. So everybody agrees that the kexec() approach is the best one? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
