Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Authenticated Boot and Disk Encryption on Linux

0pointer.net

Post reply on HN
Print view View original

101–110 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#101

Post by selfhoster11 »

dbrgn wrote: post #73
sam_lowry_ wrote: post #8

After taking over the process #1, Lennart Poettering decided to go deeper and take over kernel, initrd and bootloader. I sometimes wonder whether he is on the NSA payroll. Lennart Poettering and Moxie Marlinspike are two people NSA should really strive to buy and/or intimidate.

Instead of attacking the person (ad-hominem), how about discussing the technical merits and deficiencies of the proposed solution to a real problem that no Linux distro has tackled so far? I'm sure the NSA is happy about unauthenticated initrds. I'd be very surprised if such manipulation was never used in practice.

I don't think it's an ad hominem, because this is a viable attack vector. What better way to get access to countless systems than by compromising the supply chain?

Re: Authenticated Boot and Disk Encryption on Linux

#102

Post by selfhoster11 »

fmajid wrote: post #27
sam_lowry_ wrote: post #8

After taking over the process #1, Lennart Poettering decided to go deeper and take over kernel, initrd and bootloader. I sometimes wonder whether he is on the NSA payroll. Lennart Poettering and Moxie Marlinspike are two people NSA should really strive to buy and/or intimidate.

Signal is partly funded by the US government: https://www.opentech.fund/results/supported-projects/open-wh...

So is Tor. Is there any other reason to suspect foul play?

Re: Authenticated Boot and Disk Encryption on Linux

#103

Post by lugged »

cmurf wrote: post #95
nsajko wrote: post #89

Earlier quoted context omitted.

Let's put it this way: say you want to prevent somebody from getting the data on a disk. Wouldn't writing random data over the entire disk be a good idea?

blkdiscard /dev/nvme0n1 No need to write anything. Better would be to use nvme tools to securely erase it ("format" is the terminology used)

The idea is to give you the plausible deniability, you can tell the cops you wiped it with random data, there is no password.

Your flash drive can't then be used as evidence that you haven't wiped it yet.

The initrd on the drive would be evidence you haven't wiped the drive.

Whether that gets you out of a jam and not in trouble for destroying evidence is another question.

Re: Authenticated Boot and Disk Encryption on Linux

#104

Post by selfhoster11 »

Foxboron wrote: post #4
jimsi wrote: post #3

https://github.com/xmikos/cryptboot/blob/master/README.md

I don't think a 5 year old project linked without context is appropriate when talking about modern boot chain security. It doesn't even support stubs so it fails at the first threat scenario described in this post.

I disagree. UEFI boot security is not that recent, and it hasn't changed so much as to render earliest approaches less secure.

Re: Authenticated Boot and Disk Encryption on Linux

#105

Post by 0xdeadb00f »

dbrgn wrote: post #73
sam_lowry_ wrote: post #8

After taking over the process #1, Lennart Poettering decided to go deeper and take over kernel, initrd and bootloader. I sometimes wonder whether he is on the NSA payroll. Lennart Poettering and Moxie Marlinspike are two people NSA should really strive to buy and/or intimidate.

Instead of attacking the person (ad-hominem), how about discussing the technical merits and deficiencies of the proposed solution to a real problem that no Linux distro has tackled so far? I'm sure the NSA is happy about unauthenticated initrds. I'd be very surprised if such manipulation was never used in practice.

Their accusations are bold and brash, but this is not an ad-hominem.

Re: Authenticated Boot and Disk Encryption on Linux

#106

Post by Foxboron »

selfhoster11 wrote: post #104
Foxboron wrote: post #4

Earlier quoted context omitted.

I don't think a 5 year old project linked without context is appropriate when talking about modern boot chain security. It doesn't even support stubs so it fails at the first threat scenario described in this post.

I disagree. UEFI boot security is not that recent, and it hasn't changed so much as to render earliest approaches less secure.

It is less secure. The initramfs is not signed, along with the microcode.

Re: Authenticated Boot and Disk Encryption on Linux

#107

Post by dbrgn »

0xdeadb00f wrote: post #105
dbrgn wrote: post #73

Earlier quoted context omitted.

Instead of attacking the person (ad-hominem), how about discussing the technical merits and deficiencies of the proposed solution to a real problem that no Linux distro has tackled so far? I'm sure the NSA is happy about unauthenticated initrds. I'd be very surprised if such manipulation was never used in practice.

Their accusations are bold and brash, but this is not an ad-hominem.

Instead of discussing the ideas presented, the _person_ behind the ideas is discussed. In my book, that's pretty close to an ad-hominem, even if the accusations are only implied.

Re: Authenticated Boot and Disk Encryption on Linux

#108

Post by selfhoster11 »

stragies wrote: post #100
selfhoster11 wrote: post #97

Earlier quoted context omitted.

Strip the signature and sign with your own key? It's possible as a part of the Secure Boot model.

That ^^ feels like an important part of the HowTo. Is there one, that includes this step already?

I imagine that this is a documented generic process that works for all UEFI boot binaries. I can't point to any specific guide because I don't use UEFI in Secure Boot mode.

Re: Authenticated Boot and Disk Encryption on Linux

#109

Post by teddyh »

nsajko wrote: post #70
SkyMarshal wrote: post #68

Earlier quoted context omitted.

> This way the big disk can have full, real FDE (not LUKS). I thought LUKS was the only way to do FDE in Linux. What other options for FDE are there? But yes, putting /boot on an external USB drive is the only way I know of get FDE on your hard drives. Possible with UEFI, not BIOS/MBR.

LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.

> LUKS leaves encryption metadata unencrypted.

Except for ruling out plausible deniability, what problem does this pose?

Re: Authenticated Boot and Disk Encryption on Linux

#110

Post by noahbliss »

A significant issue is being able to protect your initramfs and your cmdline options during boot while still keeping the convenience of auto-unlock. By using the TPM to handle validation, you also cut yourself out of the mix by not knowing the password. Of course this comes with the risk of hardware attacks, but there is always a risk. Current distribution implementations DO NOT, EVEN WITH SECUREBOOT ON, verify the integrity of the initramfs, which can be repacked to include malicious code that will execute during boot, potentially intercepting your LUKS key. There have been a number of attempts to solve this problem, but the most complete appear to be Mortar (a project I head) and safeboot.dev

I highly recommend taking a look at either of these projects if you want be able to improve both your convenience through auto unlocking, and security through broadened scope of audit.

https://github.com/noahbliss/mortar

https://safeboot.dev

Post reply on HN