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

181–190 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#181

Post by orthecreedence »

BiteCode_dev wrote: post #19
withinboredom wrote: post #17

Earlier quoted context omitted.

You probably have some fun disk caching turned on in the OS or your disk has a built in cache that it’s not properly flushing. I’ve seen this before with cheap SSDs.

Maybe, I don't know enough about this, but I've been using this veracrypt disk on 6 machines, now, and I have the problem with each of them. Also, I don't have any problem with non encrypted data.

Maybe a dumb question, but are you on windows? Check that Defender isn't scanning every single time data is written to your veracrypt drive. When I was on windows, the most painful slowdowns were almost invariably caused by Windows Defender.

Re: Authenticated Boot and Disk Encryption on Linux

#182

Post by mjg59 »

cmurf wrote: post #159

Can a TPM be shared by two operating systems? As in, dual boot configurations? Is any sort of deconfliction required and does the relevant spec account for this?

> Can a TPM be shared by two operating systems?

Yes.

> Is any sort of deconfliction required

No.

Re: Authenticated Boot and Disk Encryption on Linux

#183

Post by deckard1 »

SkyMarshal wrote: post #177
deckard1 wrote: post #174

Earlier quoted context omitted.

you're only going to write to the USB drive when you upgrade your kernel. all these worries are completely overblown. I've been using USB boot method for close to 10 years now. It's just another folder/mountpoint to backup along with your normal backup.

Anecdote != data. And unlike the other folders, if you lose this one you lose the whole system. And it's not just writes we care about, but bit flips for any reason.

> Anecdote != data

Thank you Captain Obvious.

> And unlike the other folders, if you lose this one you lose the whole system

Yeah, that's how encryption works.

> but bit flips for any reason

Way to move the goalposts. Your typical laptop/desktop does not have ECC RAM. You're also not using mirrored ZFS anyway. So not only will you never detect corruption, but you have no way to correct it either. Which, again, is totally overkill for the average user.

Re: Authenticated Boot and Disk Encryption on Linux

#184

Post by r-w »

SV_BubbleTime wrote: post #160
teddyh wrote: post #109

Earlier quoted context omitted.

> LUKS leaves encryption metadata unencrypted. Except for ruling out plausible deniability, what problem does this pose?

Which is kinda funny on a laptop. If some authority told you to unlock a device and it did have a plausible deniability encryption system - no one is going to believe that anyway. For a USB drive or a file, sure, feature. For a laptop, “duh, it’s encrypted” is going to be the first thing anyone considers. Not “well, I guess the laptop has no data on it at all!”

Hence, “plausible”.

Re: Authenticated Boot and Disk Encryption on Linux

#185

Post by teddyh »

adgjlsfhk1 wrote: post #158
teddyh wrote: post #109

Earlier quoted context omitted.

> LUKS leaves encryption metadata unencrypted. Except for ruling out plausible deniability, what problem does this pose?

Metadata includes file names. If you have a file on your computer called proof_nsa_is_doing_illegal_stuff.pdf, that would significantly help a prosecutor trying to convict a wistleblower even if they can't get the file.

No, the LUKS header includes only encryption metadata, not file system metadata.

Re: Authenticated Boot and Disk Encryption on Linux

#186

Post by BrightGlow »

selfhoster11 wrote: post #101
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.

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?

Which operating system doesn't have this attack vector? Is there one that somehow doesn't have a supply chain?

Re: Authenticated Boot and Disk Encryption on Linux

#187

Post by belorn »

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

There are two main vector of attacks to get access to the data. The simpler version are those that attempt to get they key by recording it when the user type it in, like hooking into the keyboard. No real need to try make it a fake system since no keyboard that I know of has security built in to prevent MITM attacks. If we are asking what spy agencies do, I would also suspect that the camera on a laptop could be replaced with a look-alike with a transmitter.

The other main attack vector is to target the hardware while it is running and without waiting for the owner to type in the password. Get access to the main bus would be the primary target if the ram is not vulnerable (usb vulnerabilities, debug pins on the mother board, and so on). Vulnerabilities of the software is also an alternative, and if time is not a problem one could in theory wait until a vulnerability is found. I would assume that all internal connections are to a degree vulnerable to malicious designed hardware in mass consumer laptops, sever and desktops, but the main question is how to do it hot without crashing the machine.

Re: Authenticated Boot and Disk Encryption on Linux

#188

Post by tkfu »

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?

Re: Authenticated Boot and Disk Encryption on Linux

#189

Post by aaronmdjones »

predakanga wrote: post #157
michaelt wrote: post #96

Earlier quoted context omitted.

Also, once you've got per-user encryption on ~/.ssh/authorized_keys you'll need some other mechanism for users to log in. And don't think of having the users do their own backups - locking users' home directories mean they won't be able to run their own cron jobs.

> Also, once you've got per-user encryption on ~/.ssh/authorized_keys you'll need some other mechanism for users to log in. OpenSSH supports this through the AuthorizedKeysFile directive - it'd be quite simple for the homedir mounting tool to sync that file from the user's authorized_keys file on unmount. You could also use SSH certificates, but that requires a CA - not ideal for the home user.

You can also store the file anywhere else, a la

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u
(For example, /etc/ssh/authorized_keys/bob)

Re: Authenticated Boot and Disk Encryption on Linux

#190

Post by privacyxpert »

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…

There are basically zero scenarios where using raw dm-crypt is recommendable over using LUKS(2) with a detached header.

Some (good) distros even have built-in support for detached headers, even. I actually use detached headers on a number of my system and it just basically works out-of-box, compared to what I'd imagine you had to do to make raw dm-crypt work.

Also, what is it with people that are determined to be smarter than LUKS? I've met another person online that was quite insistent that dm-crypt must be safer. Strangely, they stopped replying when I asked how they were securely storing a properly long AES key that they were then entering at boot, remotely or otherwise.

Post reply on HN