Re: Full disk encryption including /boot, excluding bootloader?
On Tue, Feb 18, 2020 at 08:05:29AM +0100, Paul de Weerd wrote: On Tue, Feb 18, 2020 at 05:12:25AM +, Frank Beuth wrote: | Yes, it's a cool way to combine things to get unexpected functionality. | I haven't dug into the bootloader much... is there a reasonably easy way | to get the USB-stick-bootloader to boot the hard drive partition by | default? Best way to dig into the bootloader is by starting at its fine manpage which you can read online at http://man.openbsd.org/man8/amd64/boot.8 The quick answer is `echo 'boot sr0a:/bsd' > /etc/boot.conf` (on the USB-stick's root filesystem). Thanks!
Re: Full disk encryption including /boot, excluding bootloader?
> Are there any downsides though? For example, would resume from > hibernation still work for such a setup? It should work with hibernation without any problems, but i did not test this extensively. > > More so, for the less knowledgeable of us, how does this relate to > UEFI's "Secure Boot"? I can only hope OpenBSD will support it some > day, at least for amd64. Debian has implemented it for the last major > release, Debian 10. Secure Boot as defined by the UEFI specification works with cryptographic signatures instead of just measuring. Meaning there is also a Chain in which every component has to verify the Signature of the next one. The downside of this approach is, that in order to verify any signature, you need some keys that you trust. If your name is Microsoft, than you can get every vendor to include your keys inside the firmware and your bootloader can be verified. This is obviously very convenient for the user. If you are not Microsoft and your signature key is not included in the firmware, than users have to sign the boot components manually and add their keys to the firmware. To sum it up. I think that SecureBoot was the right choice for Microsoft but for FOSS the TPM approach is less hassle for the user. Also measuring can not only be done for the executable itself, but also for the data it uses. That way buffer overflow attacks can also be detected. The signature based approach can not do that. In the next few days i will write a email to misc containing a small manual and all the source code. Best Regards Julius
Re: Full disk encryption including /boot, excluding bootloader?
Make sure no one has physical access to you machine! EVER. Lock it away. That way no 'Evil Maid' or any one else can access it! This is not hard. Why is this a thing? If someone has physical access to you box then it is Game Over! All of these fantasy efforts are BS. Physically secure your hardware people! You are deluding yourselves.
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 04:09:57PM +0100, Julius Zint wrote: I'm not really in a position to reflash my machine but I would still be curious for details. There is no need to reflash your firmware if the system has a integrated and supported TPM 1.2 chip. The prototype uses a Static Root of Trust for Measurment (SRTM) approach where the Chain of Trust is extended from a small immutable firmware part up to boot(8). Every component in the boot chain is responsible for measuring the components, that it hands control over the system. Measuring just means calculating the hash and sending it to the TPM. The following example is the Chain of Trust from my test system Lenovo Thinkpad X240 with OpenBSD. 1: Core Static Root of Trust for Measurment (C-SRTM) (immutable part of the Firmware) 2: Firmware (including OptionROMS) 3: MBR (mbr(8)) 4: PBR (biosboot(8)) 5: boot(8) (residing in the softraid(4) metadata when FDE is enabled) I changed the mbr(8) and biosboot(8) to support measuring their next component. Because there is very little available space left in the 440 byte of the mbr(8) startprogram, you have to choose between CHS and measurement support at compile time. boot(8) got support via a machine specific command to seal and unseal a secret of your choosing to any drive. Sealing and unsealing means encrypting/decrypting data depending on the state of the Platform Control Registers (PCR). PCRs are in the TPM NVRAM and store the measurements. With the laptop being in a trusted state, you can seal a secret and store it on a usb drive. When you want to verify, that the software components are unchanged, you plug in the usb drive and unseal the secret. If the output shows the correct secret and you were the only person knowing it, than there is a very high chance that the early boot components are unchanged. Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? That sounds awesome! Hope you are working on upstreaming your changes. Are there any downsides though? For example, would resume from hibernation still work for such a setup? More so, for the less knowledgeable of us, how does this relate to UEFI's "Secure Boot"? I can only hope OpenBSD will support it some day, at least for amd64. Debian has implemented it for the last major release, Debian 10. Thanks!
Re: Full disk encryption including /boot, excluding bootloader?
On Tue, Feb 18, 2020 at 05:12:25AM +, Frank Beuth wrote: | Yes, it's a cool way to combine things to get unexpected functionality. | I haven't dug into the bootloader much... is there a reasonably easy way | to get the USB-stick-bootloader to boot the hard drive partition by | default? Best way to dig into the bootloader is by starting at its fine manpage which you can read online at http://man.openbsd.org/man8/amd64/boot.8 The quick answer is `echo 'boot sr0a:/bsd' > /etc/boot.conf` (on the USB-stick's root filesystem). Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 06:44:25PM +0100, Paul de Weerd wrote: On Mon, Feb 17, 2020 at 01:35:38PM +, Frank Beuth wrote: | > | This way the evil maid would have nothing to tamper with. | > | > Note that with this approach, a default OpenBSD install to your | > machine will still install a bootloader on the physical disk inside | > your machine. It's then on you to NOT use that. | | That's a heck of a hack! Not sure how you mean that - I don't think it's that much of a hack, mostly an interesting side-effect of how the bootloader works in general. Taken in combination with a "normal" install to removable media, you get basically exactly what you want at no additional cost. Note that you don't have to do a full (or even minimal) install, if all you really want is use the bootloader on the removable media. It's just the easiest way to prepare it that I know of. Besides, if you do a 'normal' install, you have a convenient 'live' or 'rescue' system to carry around with you whenever you go: I've got one of these on my keychain :) Yes, it's a cool way to combine things to get unexpected functionality. I haven't dug into the bootloader much... is there a reasonably easy way to get the USB-stick-bootloader to boot the hard drive partition by default?
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 04:09:57PM +0100, Julius Zint wrote: I'm not really in a position to reflash my machine but I would still be curious for details. There is no need to reflash your firmware if the system has a integrated and supported TPM 1.2 chip. The prototype uses a Static Root of Trust for Measurment (SRTM) approach where the Chain of Trust is extended from a small immutable firmware part up to boot(8). Every component in the boot chain is responsible for measuring the components, that it hands control over the system. Measuring just means calculating the hash and sending it to the TPM. The following example is the Chain of Trust from my test system Lenovo Thinkpad X240 with OpenBSD. 1: Core Static Root of Trust for Measurment (C-SRTM) (immutable part of the Firmware) 2: Firmware (including OptionROMS) 3: MBR (mbr(8)) 4: PBR (biosboot(8)) 5: boot(8) (residing in the softraid(4) metadata when FDE is enabled) I changed the mbr(8) and biosboot(8) to support measuring their next component. Because there is very little available space left in the 440 byte of the mbr(8) startprogram, you have to choose between CHS and measurement support at compile time. boot(8) got support via a machine specific command to seal and unseal a secret of your choosing to any drive. Sealing and unsealing means encrypting/decrypting data depending on the state of the Platform Control Registers (PCR). PCRs are in the TPM NVRAM and store the measurements. With the laptop being in a trusted state, you can seal a secret and store it on a usb drive. When you want to verify, that the software components are unchanged, you plug in the usb drive and unseal the secret. If the output shows the correct secret and you were the only person knowing it, than there is a very high chance that the early boot components are unchanged. Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? That's amazing if you can get it to work without reflashing. Are you then sealing the disk encryption key? Unfortunately I have to be a bit conservative with my laptop, but I would be quite interested in testing this once it's near-production-ready.
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 01:35:38PM +, Frank Beuth wrote: | > | This way the evil maid would have nothing to tamper with. | > | > Note that with this approach, a default OpenBSD install to your | > machine will still install a bootloader on the physical disk inside | > your machine. It's then on you to NOT use that. | | That's a heck of a hack! Not sure how you mean that - I don't think it's that much of a hack, mostly an interesting side-effect of how the bootloader works in general. Taken in combination with a "normal" install to removable media, you get basically exactly what you want at no additional cost. Note that you don't have to do a full (or even minimal) install, if all you really want is use the bootloader on the removable media. It's just the easiest way to prepare it that I know of. Besides, if you do a 'normal' install, you have a convenient 'live' or 'rescue' system to carry around with you whenever you go: I've got one of these on my keychain :) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Full disk encryption including /boot, excluding bootloader?
I’m interested as well. Jan On 17 Feb 2020, at 17:10, Kevin Chadwick wrote: On 2020-02-17 15:09, Julius Zint wrote: Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? I'm interested
Re: Full disk encryption including /boot, excluding bootloader?
On 2020-02-17 15:09, Julius Zint wrote: > Some feedback from the OpenBSD community on this would also be appreciated. > Are there > enought people interessted in a Trusted Boot with OpenBSD? I'm interested
Re: Full disk encryption including /boot, excluding bootloader?
> I'm not really in a position to reflash my machine but I would still be > curious for details. There is no need to reflash your firmware if the system has a integrated and supported TPM 1.2 chip. The prototype uses a Static Root of Trust for Measurment (SRTM) approach where the Chain of Trust is extended from a small immutable firmware part up to boot(8). Every component in the boot chain is responsible for measuring the components, that it hands control over the system. Measuring just means calculating the hash and sending it to the TPM. The following example is the Chain of Trust from my test system Lenovo Thinkpad X240 with OpenBSD. 1: Core Static Root of Trust for Measurment (C-SRTM) (immutable part of the Firmware) 2: Firmware (including OptionROMS) 3: MBR (mbr(8)) 4: PBR (biosboot(8)) 5: boot(8) (residing in the softraid(4) metadata when FDE is enabled) I changed the mbr(8) and biosboot(8) to support measuring their next component. Because there is very little available space left in the 440 byte of the mbr(8) startprogram, you have to choose between CHS and measurement support at compile time. boot(8) got support via a machine specific command to seal and unseal a secret of your choosing to any drive. Sealing and unsealing means encrypting/decrypting data depending on the state of the Platform Control Registers (PCR). PCRs are in the TPM NVRAM and store the measurements. With the laptop being in a trusted state, you can seal a secret and store it on a usb drive. When you want to verify, that the software components are unchanged, you plug in the usb drive and unseal the secret. If the output shows the correct secret and you were the only person knowing it, than there is a very high chance that the early boot components are unchanged. Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? Best Regards Julius
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 11:56:24AM +0100, Paul de Weerd wrote: But you can already do this. If your machine supports booting from USB, you can do a minimal install to a USB stick (using FDE, if you want). Now you have a portable OpenBSD environment you can boot on any system capable of booting from USB (and supporting the same kernel architecture). What you can also do with this USB stick is use its bootloader to boot the OS stored on the disk inside your machine (FDE encrypted or not). I've used this to fix up installs gone sour on my machines in the past. Works a treat. I don't use it to prevent the evil maid case you describe though, but I think it would work just fine. | This way the evil maid would have nothing to tamper with. Note that with this approach, a default OpenBSD install to your machine will still install a bootloader on the physical disk inside your machine. It's then on you to NOT use that. That's a heck of a hack!
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 11:13:27AM +0100, Julius Zint wrote: I recently finished my masterthesis that solves this problem by including the Trusted Platform Module (TPM) in the bootprocess of OpenBSD. It extends the Chain of Trust up to boot(8) and allows you to seal a secret of your choice to the platform state. To check wether the unencrypted bootcomponents got tampered with, you can unseal and verify the secret to ensure that the contents of the MBR, PBR and boot(8) are unchanged. it is not exactly the solution you were looking for but it should solves the problem that you describe. Does this sound like something you were willing to try and does your machine have a TPM 1.2 Chip? That sounds absolutely fascinating. Are you familiar with the Heads firmware? How is your approach different? I'm not really in a position to reflash my machine but I would still be curious for details.
Re: Full disk encryption including /boot, excluding bootloader?
>>> How do you do this on OpenBSD? >>@frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk > > That's telling me how to use a keydisk -- how to put the softraid FDE > encryption key material on a USB disk. > > If an evil made came by and got access to my machine, they would still > be able to tamper with the bootloader code to harvest the FDE password > when I returned. > > I want to put the whole bootloader (including the code used to decrypt > the softraid-FDE-encrypted root-partition-containing media) on a USB > disk. > > This way the evil maid would have nothing to tamper with. They still would have plenty of firmware to target/infect, usually under 3 minutes with a screwdriver and dedicated hardware. If going this path, buy a safe and lock the computer while away from it. -Fabio Martins
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 08:50:14AM +, Frank Beuth wrote: | > > How do you do this on OpenBSD? | > @frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk | | That's telling me how to use a keydisk -- how to put the softraid FDE | encryption key material on a USB disk. | | If an evil made came by and got access to my machine, they would still | be able to tamper with the bootloader code to harvest the FDE password | when I returned. | | I want to put the whole bootloader (including the code used to decrypt | the softraid-FDE-encrypted root-partition-containing media) on a USB | disk. But you can already do this. If your machine supports booting from USB, you can do a minimal install to a USB stick (using FDE, if you want). Now you have a portable OpenBSD environment you can boot on any system capable of booting from USB (and supporting the same kernel architecture). What you can also do with this USB stick is use its bootloader to boot the OS stored on the disk inside your machine (FDE encrypted or not). I've used this to fix up installs gone sour on my machines in the past. Works a treat. I don't use it to prevent the evil maid case you describe though, but I think it would work just fine. | This way the evil maid would have nothing to tamper with. Note that with this approach, a default OpenBSD install to your machine will still install a bootloader on the physical disk inside your machine. It's then on you to NOT use that. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Full disk encryption including /boot, excluding bootloader?
> > If an evil made came by and got access to my machine, they would still > be able to tamper with the bootloader code to harvest the FDE password > when I returned. > > I want to put the whole bootloader (including the code used to decrypt > the softraid-FDE-encrypted root-partition-containing media) on a USB > disk. > > This way the evil maid would have nothing to tamper with. I recently finished my masterthesis that solves this problem by including the Trusted Platform Module (TPM) in the bootprocess of OpenBSD. It extends the Chain of Trust up to boot(8) and allows you to seal a secret of your choice to the platform state. To check wether the unencrypted bootcomponents got tampered with, you can unseal and verify the secret to ensure that the contents of the MBR, PBR and boot(8) are unchanged. it is not exactly the solution you were looking for but it should solves the problem that you describe. Does this sound like something you were willing to try and does your machine have a TPM 1.2 Chip? Best regards Julius
Re: Full disk encryption including /boot, excluding bootloader?
On Sat, Feb 15, 2020 at 12:22:02PM +0100, no@s...@mgedv.net wrote: >depends what you want to achieve, but my recommendation is booting from USB >and mount encrypted root from the HDD. >you can safely remove the usb key after root mount and all your configs/etc >files are used from the encrypted storage. >this ensures 2 things: bootloader + kernel on USB boot media cannot be >attacked during system uptime and all bytes on disk are encrypted. >another advantage is, you don't need (to type, write down or remember) any >passphrases but can use strong random data for crypto payload/keys. > How do you do this on OpenBSD? @frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk That's telling me how to use a keydisk -- how to put the softraid FDE encryption key material on a USB disk. If an evil made came by and got access to my machine, they would still be able to tamper with the bootloader code to harvest the FDE password when I returned. I want to put the whole bootloader (including the code used to decrypt the softraid-FDE-encrypted root-partition-containing media) on a USB disk. This way the evil maid would have nothing to tamper with.
Re: Full disk encryption including /boot, excluding bootloader?
> >depends what you want to achieve, but my recommendation is booting from > USB > >and mount encrypted root from the HDD. > >you can safely remove the usb key after root mount and all your configs/etc > >files are used from the encrypted storage. > >this ensures 2 things: bootloader + kernel on USB boot media cannot be > >attacked during system uptime and all bytes on disk are encrypted. > >another advantage is, you don't need (to type, write down or remember) any > >passphrases but can use strong random data for crypto payload/keys. > > > > How do you do this on OpenBSD? @frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk
Re: Full disk encryption including /boot, excluding bootloader?
On Thu, Feb 13, 2020 at 01:31:43PM +0100, no@s...@mgedv.net wrote: depends what you want to achieve, but my recommendation is booting from USB and mount encrypted root from the HDD. you can safely remove the usb key after root mount and all your configs/etc files are used from the encrypted storage. this ensures 2 things: bootloader + kernel on USB boot media cannot be attacked during system uptime and all bytes on disk are encrypted. another advantage is, you don't need (to type, write down or remember) any passphrases but can use strong random data for crypto payload/keys. How do you do this on OpenBSD?
Re: Full disk encryption including /boot, excluding bootloader?
no@s...@mgedv.net(nos...@mgedv.net) on 2020.02.13 13:31:43 +0100:
> > > On Linux you can do the following:
> > > { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive
> entirely encrypted] }
> ... which i would consider to be as insecure, as unencrypted root at all.
... which totaly depends on what you are trying to protect your laptop/data
from.
The lost/stolen laptop szenario is covered nicely by what OpenBSD offers.
Re: Full disk encryption including /boot, excluding bootloader?
> > On Linux you can do the following:
> > { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive
entirely encrypted] }
... which i would consider to be as insecure, as unencrypted root at all.
maybe check out https://wiki.osdev.org, they have nice articles on this.
IMHO a secure boot chain is only possible using a secured, open source bios,
removing all firmware like IME and such.
in such a BIOS you'd save a checksum of the bootloader to NVRAM and refuse
booting if the checksum is incorrect.
altering fw/kernel/boot loader is a common attack vector and if the hardware
is not in a secured room, it's anyways attackable.
depends what you want to achieve, but my recommendation is booting from USB
and mount encrypted root from the HDD.
you can safely remove the usb key after root mount and all your configs/etc
files are used from the encrypted storage.
this ensures 2 things: bootloader + kernel on USB boot media cannot be
attacked during system uptime and all bytes on disk are encrypted.
another advantage is, you don't need (to type, write down or remember) any
passphrases but can use strong random data for crypto payload/keys.
Re: Full disk encryption including /boot, excluding bootloader?
cipher-hea...@riseup.net writes:
>
> On Linux you can do the following:
>
> Hard drive:
> { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive entirely
> encrypted] }
>
> Then the only parts of the (x64) computer that are unencrypted are the BIOS
> and GRUB.
This is how it already does it with the exception that the unencrypted
data are not in a regular partition. Instead the unencrypted
bootloader exists within the space allocated for the disklabel (and
the MBR on x86) which then locates and decrypts the partition
containing the kernel.
> You can then move the GRUB offline if you wish, execute it externally.
>
>
> Is something like this possible on OpenBSD?
I have briefly looked into locating the unencrypted parts of OpenBSD's
bootloader on a seperate detachable disc, as I had managed to cobble
together previously, but the kernel is told where its root partition
is in quite a different way from Linux and I decided I didn't want
to trawl through x86 real mode assembly any more.
It can be done of course but you may have to hack at the bootloader
to make it work. I only did it with Linux to prove that I could not
because it was useful.
Matthew
Re: Full disk encryption including /boot, excluding bootloader?
On Thu, Feb 13, 2020 at 10:31:30AM +, cipher-hea...@riseup.net wrote:
>
> On Linux you can do the following:
>
> Hard drive:
> { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive entirely
> encrypted] }
>
> Then the only parts of the (x64) computer that are unencrypted are the BIOS
> and GRUB.
>
> You can then move the GRUB offline if you wish, execute it externally.
>
>
> Is something like this possible on OpenBSD?
>
Yes, see FAQ: http://www.openbsd.org/faq/faq14.html#softraidFDE
-Otto
