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

191–200 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#191

Post by privacyxpert »

contingencies wrote: post #171

Set up a new laptop for Ubuntu recently and opted for ZFS encryption, impressed it was now a mainstream install option. Sadly amused after setup that it suspends indefinitely without requiring the passphrase, ie. keeps unlocked volumes in memory. This makes the encryption basically pointless. (NB. This category of issue was highlighted in the recent interview by the resurfaced Alpha Bay operator, specifically after h…

Just a heads up, you should be aware that ZFS encryption leaks considerably more metadata than full LUKS block encryption.

Re: Authenticated Boot and Disk Encryption on Linux

#192

Post by privacyxpert »

BiteCode_dev wrote: post #129
theandrewbailey wrote: post #61

Earlier quoted context omitted.

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.

Servers and consumer laptop are very different beast though, so not sure the comparison hold. You don't shut them off often, they don't go to sleep, rarely undergo shock, plane travel or forced shut down...

Friend, LUKS is reliable. LUKS doesn't just eat data in those edgecases you talk about, there would be tons of reports if that were the case. LUKS is used all over the place for non-server uses too.

I can count at least 3 devices that are all LUKS-encrypted that are used as consumer devices daily. I trip over the power cord, I let the battery die, I drop it, I fly regularly, etc, etc. Never once had a single issue.

In fact, the single time that I've had FS issues under Linux was running under Hyper-V but that's because of the slowly-being-uncovered serious issues w/ Hyper-V.

Re: Authenticated Boot and Disk Encryption on Linux

#193

Post by fidesomnes »

mjg59 wrote: post #178
teddyh wrote: post #111

If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote . Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either l…

> nothing we can do can currently avoid this. Unless you scope "sophisticated" as "can compromise hardware we currently believe is secure", we can get to the point where the only mechanism is a hardware keylogger (which is something made far more complicated by, eg, using a Bluetooth keyboard). This has a few problems: 1) It's relatively easy to detect - you're adding a new physical object 2) You're only seeing a sma…

apparently nobody has introduced you to Intel vPro.

Re: Authenticated Boot and Disk Encryption on Linux

#194

Post by mjevans »

SkyMarshal wrote: post #90
nsajko wrote: post #70

Earlier quoted context omitted.

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.

Huh, I thought BIOS/MBR required /boot to be on a partition at the beginning of the MBR and nowhere else, whereas UEFI allows it to be anywhere on the disk as long as its labeled with ESP. So with UEFI, you just label /boot on USB as ESP. How does it work with BIOS/MBR?

That was an issue with older BIOS versions which also often didn't fully support LBA indexed sectors.

Any system with a UEFI BIOS that has 'CSM' (compatibility support mode IIRC) should support arbitrary placement of the /boot partition.

Today the main reason to put /boot early is for migrating to larger drives later, the start sector of many filesystems (including windows) can be left in place, and the size of the last partition, the data/system partition can then just be expanded.

Re: Authenticated Boot and Disk Encryption on Linux

#195

Post by supperburg »

amarshall wrote: post #60
supperburg wrote: post #50

“With LUKS, the encryption is as good as your password is strong.” Well that was anticlimactic. I thought my entire setup would have to be overhauled.

Did you read the whole thing? LUKS (or FDE in general) is not enough for the attacks presented. Partly because FDE is rarely ever the “full” disk.

I did read it. The “attacks presented” are of concern to basically nobody.

Re: Authenticated Boot and Disk Encryption on Linux

#196

Post by temac »

kobalsky wrote: post #136
teddyh wrote: post #111

If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote . Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either l…

> If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. I think with blanket statements like this it's important to define sophisticated. For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ? I'm of course not talking about social engine…

> break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor*

On Windows (even modern versions IIRC) you can sniff the traffic (or maybe forge requests? I think it was simply sniffing though) to the TPM and get the keys to decrypt the HD, if there is no additional protection (like a PIN or password). Don't know if this is also applicable to Linux stacks. Kind of weird the interface has not been designed and/or programmed to resist to such attack, although of course password-less full disk decryption is often going to be less secure than with one, at least Macs are not subject to the same attack, I think?

Re: Authenticated Boot and Disk Encryption on Linux

#197

Post by thayne »

tkfu wrote: post #188
thayne wrote: post #152

On most linux distros the initrd is dynamically generated, and depends on the specific hardware. So it isn't possible for the initrd to be signed by the vendor. Is it possible for the TPM to verify such a dynamically created file during boot? Also, requiring a TPM for decrypting the hard drive has a security/usability tradeof. If the TPM dies, or possibly other components of the computer (like the motherboard), then…

The article already mentions both of those challenges, and outlines practical solutions/mitigations to both--can you be more specific about what you didn't like?

To be honest I hadn't read the whole article when I posted that, I'd only made it about halfway through. Now having read the whole thing, regarding a failing TPM, having a recovery key seems like a fine solution, I just didn't know if that was possible.

Regarding initrd, the idea of a base image plus extension images might work. Although I still have questions. Are these extension image signed by the vendor or the host? If the former, how do DKMS modules work? That isn't an edge case, the nvidia propriatary drivers, some wireless drivers, virtualbox, and sysdig for example all rely on DKMS (at least on ubuntu). And how does that system handle competing drivers? Should the base initrd use the nouveau drivers or the proprietary nvidia drivers, or does the user need to load an extension image to choose? And for that matter the base initrd you want for a server will probably be pretty different from what you want for a laptop.

Re: Authenticated Boot and Disk Encryption on Linux

#198

Post by er4hn »

rwmj wrote: post #82
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…

Clevis/Tang ("network-bound disk encryption") is likely better: https://www.redhat.com/en/blog/easier-way-manage-disk-decryp...

Clevis/Tang are really cool technologies that enable a new way of doing FDE. I'm surprised they aren't talked about more.

With Clevis you can use Shamir Secret Sharing to divide the FDE key into multiple parts. The parts can them be put in multiple places: the devices TPM, a server that will only reply to devices on the local network (Tang), a hardware token, etc.

If you put one part of the key on the TPM and the other on the Tang server, you now have a device that can be automatically rebooted in a data center without needing to enter an unlock password at boot. But if the device is removed from the data center its contents will be encrypted.

Pretty neat!

Re: Authenticated Boot and Disk Encryption on Linux

#199

Post by a1369209993 »

kobalsky wrote: post #136
teddyh wrote: post #111

If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote . Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either l…

> If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. I think with blanket statements like this it's important to define sophisticated. For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ? I'm of course not talking about social engine…

> For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ?

a: 1 copy of all the computer hardware present in the target system.

b: 1 secure radio link of sufficient bandwidth.

c: 1 apartment or van near the target system.

d: Sufficient equipment to interface with the target system (now in said apartment/van[c]) well enough to replicate its login UI (via radio link[b]) on the fake copy of it[a] you left in its place when you stole it.

Re: Authenticated Boot and Disk Encryption on Linux

#200

Post by eightails »

imwillofficial wrote: post #172
hulitu wrote: post #140

Earlier quoted context omitted.

> For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ? Intel ME and the equivalent AMD PSP. > I'm of course not talking about social engineering or fooling the user into typing their password on a fake system, since this is preventable. As other pointed out when the atacker has physical access it is game over. Also network a…

Again, Blanket statements. What ME flaws?

There are dozens of known CSME vulns -- there's a list on cvedetails [0] which itself seems to be missing some (e.g. 2019-0090/2019-0091). Plenty of these could be used by a sophisticated attacker with physical access, and some can even be executed remotely.

Here's an Intel Whitepaper detailing one such vulnerability of moderate severity (CVE-2019-0090, CVSS 4.4) [1]. From the 'Potential Consequences' table:

> Unauthorized BIOS compromises OS loader and OS integrity... All use cases / user secrets protected by Intel TPM are compromised.

Other bits and pieces of firmware including AMT have been similarly plagued with vulns [2], such as CVE-2017-5689, with a CVSS score of 10!

These are often difficult to patch, and even more difficult to convince manufacturers to spend the effort testing and distributing updates for their products. My own laptop is still running a version of CSME vulnerable to many of these attacks.

[0] https://www.cvedetails.com/vulnerability-list/vendor_id-238/...

[1] https://www.intel.com/content/dam/www/public/us/en/security-...

[2] https://www.cvedetails.com/vulnerability-list/vendor_id-238/...

Post reply on HN