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

61–70 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#61

Post by theandrewbailey »

BiteCode_dev wrote: post #14

Are other people experiencing too many corruption problems on encrypted disks? I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc. Also, it's slow. I put my firefox conf folder in it, but it slows the browser down. Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.

No. I run a server in my basement, and for the past 5+ years, every one of its drives have been LUKS encrypted, including external backup drives. I've had no issues with encryption (corruption, speed, or otherwise), only disk hardware failing outright.

Re: Authenticated Boot and Disk Encryption on Linux

#62

Post by amarshall »

hsbauauvhabzb wrote: post #11

I kinda think the claims about not encrypting /use are fairly dubious. What’s to stop an attacker replacing a lib with a signed+known vulnerable lib? As far as I know there’s no mechanism for revocation. What’s to stop this occurring to the kernel and/or boot loader? Maybe the TPM but idk

From the article:

> The OS binary resources (i.e. /usr/) must be authenticated before being booted into. (But don't need to be encrypted, since everyone has the same anyway, there's nothing to hide here.)

Authentication prevents manipulation. Encryption is not necessary to do so (encryption often also authenticates).

Re: Authenticated Boot and Disk Encryption on Linux

#63

Post by vbezhenar »

So basically an issue is that initramfs is not validated. Is it even possible to resolve that issue? If new grub version adds forced initramfs validation when run under secure boot mode, attacker can just install old grub which is still signed, but allows for unsigned initramfs.

Of course everything but /boot must just be encrypted, there's no reason not to.

Re: Authenticated Boot and Disk Encryption on Linux

#64

Post by nsajko »

phh wrote: post #47
nsajko wrote: post #35

Earlier quoted context omitted.

Replicating the chassis (including the scratches, etc.) and other laptop parts is the hardest part of your attack. I assume you don't know about the nail-polish with glitter based protection? Even "copying the login screen" is not necessarily easy.

You know the scratches on the chassis of your laptop? I definitely don't. If someone replaces my laptop with a brand new one, I'll notice something is off, but I wouldn't be surprised I'd notice /after/ typing my password. If rather than brand new, it's replaced another laptop with approximately same age/usage, I would most definitely not notice. > I assume you don't know about the nail-polish with glitter based prot…

This is what I meant: https://www.wired.com/2013/12/better-data-security-nail-poli...

Re: Authenticated Boot and Disk Encryption on Linux

#65

Post by amarshall »

egberts1 wrote: post #51
amarshall wrote: post #42

Earlier quoted context omitted.

The problem is: where is the line drawn? Everything (and I mean everything) in many Linux distros (including Fedora) is just a package. There’s no base system, unlike in most BSDs. Further, each of those packages can (and often are) updated independently of each other, confounding somewhat attempts at signing the root of that hierarchy. macOS signs the whole base system, but that also means that updating a single bit…

Yes, initd is essentially a clone of /bin, et al. Initd’s /bin probably is going to be needing to be signed differently from main root mount point.

initrd is a (very) small subset, far from a clone.

Re: Authenticated Boot and Disk Encryption on Linux

#66

Post by vbezhenar »

phh wrote: post #32

Every time I read stuff about secure boot, "evil maid" attack scenarios come up. And every time, they fail to mention the easiest one. The attack described here involves dismantling the victim's hard drive. I have an attack that isn't defeated by secure boot, and doesn't even require dismantling anything. Steal the original laptop. Take another physically identical unit. Replace it. Copy the login screen of original…

I think that this attack is not possible to prevent without hardware tokens. At least user will be immediately aware that something's not quite right.

Re: Authenticated Boot and Disk Encryption on Linux

#67

Post by rcthompson »

uuidgen wrote: post #55
phh wrote: post #32

Every time I read stuff about secure boot, "evil maid" attack scenarios come up. And every time, they fail to mention the easiest one. The attack described here involves dismantling the victim's hard drive. I have an attack that isn't defeated by secure boot, and doesn't even require dismantling anything. Steal the original laptop. Take another physically identical unit. Replace it. Copy the login screen of original…

> Copy the login screen of original laptop on a brand new laptop, and have it log the password when the victim types it to you over wifi. This is why you need mutual authentication. The easiest is with 2 passwords. You enter a password, this authenticates you to the system. Now system presents you some secret. It may be a passphrase, something not obvious like a password prompt with a typo, or a splash screen with so…

If someone is considering an "evil maid" style attack, the objective is to compromise your security without you knowing (so that you will continue using the device believing it is still secure). "Asking nicely" isn't going to accomplish that.

Re: Authenticated Boot and Disk Encryption on Linux

#68

Post by SkyMarshal »

nsajko wrote: post #22

An option that wasn't at all considered in the article is to have the initrd and (optionally) the secret key used for decrypting the disk on a separate device (or devices), for example on an 1 GB USB drive. This way the big disk can have full, real FDE (not LUKS). To an attacker not in possesion of the USB drive the big disk just looks like random data. And the USB drive can be kept on one's own person and easily des…

> 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.

Re: Authenticated Boot and Disk Encryption on Linux

#69

Post by vbezhenar »

BiteCode_dev wrote: post #14

Are other people experiencing too many corruption problems on encrypted disks? I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc. Also, it's slow. I put my firefox conf folder in it, but it slows the browser down. Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.

I started using full disk encryption (except /boot) this year, so far no problems at all. I'm using ordinary luks on Fedora.

Re: Authenticated Boot and Disk Encryption on Linux

#70

Post by nsajko »

SkyMarshal wrote: post #68
nsajko wrote: post #22

An option that wasn't at all considered in the article is to have the initrd and (optionally) the secret key used for decrypting the disk on a separate device (or devices), for example on an 1 GB USB drive. This way the big disk can have full, real FDE (not LUKS). To an attacker not in possesion of the USB drive the big disk just looks like random data. And the USB drive can be kept on one's own person and easily des…

> 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.

Post reply on HN