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

31–40 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#31

Post by MayeulC »

I haven't read the whole essay (stopped at "In detail"). So far, I agree with most of what Lennart said, it matches my analysis, except perhaps this:

> 3. The OS configuration and state (i.e. /etc/ and /var/) must be encrypted, and authenticated before they are used. The encryption key should be bound to the TPM device; i.e system data should be locked to a security concept belonging to the system, not the user.

Not sure you actually need a TPM for this, there are a few alternatives:

- Use a generic system configuration until you get to the user prompt. This doesn't require encrypting the partition, only authenticating it.

- After user authentication, either unlock the shared /etc configuration from a password stored in the encrypted user partition (could be protected by the TPM to avoid users leaking it).

- Or, the better (IMO) option is to get rid of that "shared" /etc, and allow each user to have a unique, system-wide set of parameters (with a "safe mode" in case they need to recover). Not allowing users to install arbitrary software while there are tools like overlayfs is a bit backwards IMO, unless there's a company policy, but in that case capabilities can be dropped before, or the user can be limited on a case-by-case basis.

Re: Authenticated Boot and Disk Encryption on Linux

#32

Post by phh »

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 laptop on a brand new laptop, and have it log the password when the victim types it to you over wifi.

There. I stole your data. Without any security flaw. In the exact same threat model described.

Re: Authenticated Boot and Disk Encryption on Linux

#33

Post by lathiat »

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’ve not used verycrypt, only normal Linux LUKS device mapper encryption, ZFS encryption and windows bitlocker full disk encryption with a paraphrase entered on boot (no tpm). But I haven’t had this problem with any of those.

I’d suggest either your SSD just loses data on power off which is a problem with some SSDs or it’s some veracrypt specific issue that I wouldn’t be familiar with.

Id encourage you to try out one of the above options.

Re: Authenticated Boot and Disk Encryption on Linux

#34

Post by BiteCode_dev »

snassar wrote: post #21
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.

The better solution to these kind of problems is having a backup concept with an implementation and regular testing of backups. The encryption exposed a problem with your disks or system in general. Depending on what the problem was, the problem is still there but you are not seeing it. Now you have a possible problem and unencrypted files.

I have a backup, but this is not a solution. Only a crutch. I had those problems on several machines, including brand new ones.

Re: Authenticated Boot and Disk Encryption on Linux

#35

Post by nsajko »

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…

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.

Re: Authenticated Boot and Disk Encryption on Linux

#36

Post by g_p »

Foxboron wrote: post #9
amarshall wrote: post #6

Earlier quoted context omitted.

Almost all UEFI firmware allows replacing the default public keys with your own, and then you can sign everything yourself with private keys only you possess.

In theory. But part of the UEFI boot chain is Optional ROM files stored on hardware. Most commonly found on dedicated graphics cards and other hardware. All of these files need to be authenticated, and currently signed by Microsoft or the OEM vendor. A modern Lenovo Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation fails for the GFX card you are essentially "soft bricking" the device since the GFX card won't…

An idea I just had around this, for if you run your own PK/KEK/DB chain - is it feasible to "dump" these Option ROMs?

If so, you should be able to whitelist their sha256 hashes in your DB database, since the DB can contain an allow-list of hashes, as well as an allow-list of public keys.

I'm not familiar with how to view relevant Option ROMs, but if you can "dump" them in the format they will be verified in, you should be able to put those into your DB database.

Perhaps there could even be an open/peer-vouched crowdsourced set of such DB entries maintained for popular systems?

Re: Authenticated Boot and Disk Encryption on Linux

#37

Post by wereHamster »

egberts1 wrote: post #29

I only wish that package maintainers (outside of OS distro) installed directly directly into /usr/local/bin but instead they wanted “in” on the /usr/bin placement. So, We lost there as this would have facilitated secondary signing of non-OS packages by OS distro. Doesn’t help when Fedora started muddling (merging) /bin and /usr/bin. So, secondary signing for non-OS vendors just went out the window. https://freedeskto…

Yeah, let's move to the complete opposite side: one /bin for each package. You can have that today, in NixOS.

Re: Authenticated Boot and Disk Encryption on Linux

#38

Post by remuskaos »

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…

That's what those countless convention stickers are for, they're basically a cryptographic hash of all the leet stuff you've attended.

Re: Authenticated Boot and Disk Encryption on Linux

#39

Post by aseipp »

mschuster91 wrote: post #20

> Some corners of the community tried (unfortunately successfully to some degree) to paint TPMs/Trusted Computing/SecureBoot as generally evil technologies that stop us from using our systems the way we want. That idea is rubbish though, I think. It's not as rubbish as the author wants to think. Just look at the current state of Android SafetyNet attestation - a myriad of apps refuse to run entirely (banking apps, ga…

The modern Windows ARM laptops all(?) use standard x86 Secure Boot/UEFI rules, as far as I know. You can install Linux on them pretty easily; I know at least Fedora/Anaconda supports ARM64 pretty well. The bigger problems come after that but are more of the same stuff, i.e. lack of drivers for peripherals, you're dealing with Qualcomm, etc.

Re: Authenticated Boot and Disk Encryption on Linux

#40

Post by sam_lowry_ »

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

This is all totally unsubstantiated, but...

Sinal's reliance on phone numbers and their point on encrypted e2e communication facilitates meta-information gathering for the governments of the world.

As for Pottering, he is an old-time RedHat employee, and RedHat is supplying virtually all governments of the world.

Post reply on HN