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

131–140 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#131

Post by sillystuff »

lugged wrote: post #74
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.

Does this matter? I once went through the waste of time of getting /boot encrypted. Would rather avoid needless pain.

For servers that you need to unlock remotely, you will need to leave /boot unencrypted. But, for things like a laptop, grub has supported encrypted /boot for a while now (and it works well). But, the release versions still only support luks v1 (it was good enough for all those years, probably still fine for most folks mostly just worried about their laptop getting misplaced / stolen).

add to /etc/default/grub to enable encrypted /boot support: GRUB_ENABLE_CRYPTODISK=y

After encrypting /boot, you don't need anything besides ensuring that the less than 2MB of unencrypted grub bootloader that is installed before the first partition on BIOS machines or into /boot/uefi on uefi machines is verified to ensure that 100% of the boot process is trusted (and all your data too since 100% of the disk is encrypted except for A simple way (if your threat model isn't mosad/nsa) is just checking a hash of this tiny bit of data whenever something sketchy has occurred with your laptop e.g., it is left unattended with airport security. Just boot from a thumb drive, and check the hash (it will only change if you e.g., change your filesystem type or grub gets patches). If OK, then boot is still trusted (at least what is on disk; if threat model makes you a possible target for hardware manipulation this nor Pottering's proposal will help you).

Nice if this simple check of less than 2MB could be automated, but not in a complex and fragile way that removes freedom from the nominal owner of the computer as Pottering is suggesting.

Re: Authenticated Boot and Disk Encryption on Linux

#132

Post by yyyk »

JonathonW wrote: post #123
yyyk wrote: post #99

This is a thoughtful post, yet it is useful to think again about the threat scenarios. Poettering mentions three: The obvious 'basic' one, and two advanced scenarios focused on a thief stealing the computer and then returning it. I recall exactly one case close to the these latter two scenarios: When Mossad stole a Syrian laptop allegedly containing nuclear weapon program information and returned it[0]. However, I do…

> In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). Is there anything akin to APFS containers [1] in the Linux space? APFS's ability to share space between multiple filesystems is, among other features, how Apple is able to get a…

I think btrfs subvolumes can do this? However btrfs doesn't (yet?) support encryption.

Re: Authenticated Boot and Disk Encryption on Linux

#135

Post by Matt3o12_ »

HanaShiratori wrote: post #124
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…

Wait, did I miss something or how does a sophisticated attacker break encryption with ~100+ bit password entropy?

I believe OP is referring to the fact that a sophisticated attack has access to the hardware and you continue using it afterwards. They could, for example, change the unencrypted /boot partition to log the password you use to decrypt your partition. Or, if you sign the boot partition, they could install a hardware key logger, or do any other kind of hardware modification that defeats the security. Preventing this kind of attack is incredible difficult. They are many means to prevent those kind of attacks but, for the most part, it just making it harder for the attacker so that the attacker needs to become even more sophisticated.

Full disk encryption only helps if you are worried that your hardware gets stolen

Re: Authenticated Boot and Disk Encryption on Linux

#136

Post by kobalsky »

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 engineering or fooling the user into typing their password on a fake system, since this is preventable.

* https://www.cs1.tf.fau.de/research/system-security-group/tre...

Re: Authenticated Boot and Disk Encryption on Linux

#137

Post by GekkePrutser »

Matt3o12_ wrote: post #135
HanaShiratori wrote: post #124

Earlier quoted context omitted.

Wait, did I miss something or how does a sophisticated attacker break encryption with ~100+ bit password entropy?

I believe OP is referring to the fact that a sophisticated attack has access to the hardware and you continue using it afterwards. They could, for example, change the unencrypted /boot partition to log the password you use to decrypt your partition. Or, if you sign the boot partition, they could install a hardware key logger, or do any other kind of hardware modification that defeats the security. Preventing this kin…

Just wanted to add that this is generally referred to as the "Evil Maid" scenario in case someone wants to Google it.

It can be mitigated somewhat with secure boot, tpm technologies etc but due to the breadth of possible attacks it's really hard to do against a serious attacker.

Even the sound of the keyboard is often enough to give your password away.

Re: Authenticated Boot and Disk Encryption on Linux

#138

Post by uzakov »

yyyk wrote: post #99

This is a thoughtful post, yet it is useful to think again about the threat scenarios. Poettering mentions three: The obvious 'basic' one, and two advanced scenarios focused on a thief stealing the computer and then returning it. I recall exactly one case close to the these latter two scenarios: When Mossad stole a Syrian laptop allegedly containing nuclear weapon program information and returned it[0]. However, I do…

> IMHO, the cost-benefit ratio for splitting the system isn't good enough.

A while ago I wrote a guide on a system that has good cost-benefit ratio in terms of security and amount of effort required. It is a bit outdated for 2021 but overall still good imho https://uzakov.io/2017/05/08/pretty-good-setup-pgs/

Re: Authenticated Boot and Disk Encryption on Linux

#139

Post by throwaway41597 »

lugged wrote: post #103
cmurf wrote: post #95

Earlier quoted context omitted.

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.

So have one drive with FDE and a USB drive with /boot but in no explicit way configured to boot the first drive?

Or maybe a better setup is an internal drive with /boot and a system stripped from sensitive files then somewhere in the drive an hidden partition (not sure how to avoid the vanilla OS overwriting the hidden partition), then you can either boot the vanilla OS or map the hidden partition and boot from it.

Re: Authenticated Boot and Disk Encryption on Linux

#140

Post by hulitu »

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* ?

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 access is insecure due to management engines.

Post reply on HN