Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

mathstodon.xyz

Post reply on HN
Print view View original

161–170 of 247 posts

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#161

Post by J_Shelby_J »

estebank wrote: post #112
fsddfsdfssdf wrote: post #102

Earlier quoted context omitted.

While I can see the shortcomings of C and generally don't recommend it for new projects I don't see this particular bug as a good example of something Rust's borrow checker or some other language's type system will catch. I don't think even static analyzers can catch this. It's basically something like this: original: DoTheThing() new: DoTheThingSlightlyDifferentButKeepMyCredentialsAlive() fix: DoTheThingSlightlyDiff…

This is in effect a state machine, and when you have a type system more complex than C's you can encode state transitions in the type system (either by having state transitions explicitly return a new return type or by using sum types). You still need to architect the system to encode the invariants in types. No language will fix all logic bugs for free. But you can leverage language features to reduce their number.

Like set an generic marker struct IsEncrypted where T is yes or now and only allow its state to change when proven and then write the shutdown function to only take the yes variant?

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#162

Post by dlcarrier »

jjmarr wrote: post #152
dlcarrier wrote: post #145

Earlier quoted context omitted.

Just a PIN? For most people that's a 4-digit number, which has a worst-case scenario of 10,000 attempts and a median of only a few hundred. Why not use a full 8-digit password?

Because the TPM effectively rate limits brute forcing of the key. https://learn.microsoft.com/en-us/windows/security/hardware-... > For example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess every two hours. This totals a maximum of about 4,415 g…

In that case, the median would still be just over a month, if the PINs were entered in order of how commonly they are used. Even the worst case of two years is still soon enough for a lot of data still be useful.

Also, how is the time limit enforced? With hardware access, it would be easy to change time or increase the clock rate, as well as many other side-channel attacks that could eliminate the wait altogether.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#163

Post by aniceperson »

moktonar wrote: post #157

Did the Feds desperately need a way of getting the key? is this a bugdoor? Has the commits been traced? Recently I’ve been seeing this pattern a lot and I’m starting to be a little bit suspicious. Maybe it’s because people are more sensible to this and post more on it?

it is a regression. the user space application also would silently fail, it is a chain of oversights. also having the encryption keys in memory does not mean you can extract them, it is more of unnecessarily letting it there indefinitely, not having it where it shouldn't be.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#164

Post by naikrovek »

dlcarrier wrote: post #145
noinsight wrote: post #86

Earlier quoted context omitted.

If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.

Just a PIN? For most people that's a 4-digit number, which has a worst-case scenario of 10,000 attempts and a median of only a few hundred. Why not use a full 8-digit password?

No one uses a 4-digit pin for BitLocker. No one who knows what they are doing, anyway.

My employer requires at least an 18-digit PIN, and not just numbers, either.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#165

Post by dathinab »

IngoBlechschmid wrote: post #14
bitbasher wrote: post #9

I don't see any other way? When you sleep (suspend to RAM), everything is stored in RAM and is encrypted but the master key is present in kernel memory (if I recall correctly). However, if you hibernate (suspend to disk) the entire contents of RAM (including the master key) is written/encrypted to disk and the RAM is cleared. When you wake the machine up you have to re-enter the passphrase to decrypt the master key t…

Yes, if you simply suspend your laptop on most stock Linux distributions, then everything including the master key is still kept in memory. But Debian pioneered the (optional) cryptsetup-suspend addon. This issues a luksSuspend command which is supposed to wipe the key from memory, and on resume asks you to resupply your passphrase. Up to kernel 6.8, this worked as described; starting with kernel 6.9, it silently did…

makes me wonder if there is potential for a more "main stream"/by default friendly version of this, where the key during suspend is encrypted using the TPM even if the TPM isn't a possible unlock from cold boot (i.e. no TMP encrypted volume key in the LECS headers/meta only temporary in memory during suspend)

or the alternative (for more convenient usage) for single user systems auto login on boot + use disc password for doas/sudo?

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#166

Post by Guvante »

IngoBlechschmid wrote: post #45
herywort wrote: post #39

Earlier quoted context omitted.

So you would still be asked for a passphrase, even though it's already available?

Exactly. Cryptsetup wouldn't know about the extra copy of the volume key in kernel memory. Which is why, dramatically, it appeared secure ("surely I wouldn't be asked to resupply the passphrase if the volume key is still in memory, right?").

You need to get quite specific on actual attacks to call this insecure to be clear.

Having access to the raw RAM of a machine suspended but demanding the key to resume is certainly possible but the number of attacks where you don't need this bug is "almost all of them" given at that point if the machine ever unlocks you won in this hypothetical attack even with a bug fix.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#167

Post by bri3d »

naikrovek wrote: post #158
IngoBlechschmid wrote: post #34

Earlier quoted context omitted.

Okay, yes, sure. It definitely is the most-used encryption software for Windows. But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others: 38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM

If you think for one single second that businesses and governments who rely on a lost disk being secure don’t trust bitlocker, I have oceanfront property in Missouri to sell you. Bitlocker + PIN is as secure as anything. A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.

> A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.

First off: I agree with your thesis, BitLocker with PIN is Just Fine, equivalent in all practical senses to most disk encryption strategies, and an enterprise standard.

I post this to reinforce what you're saying, because there are a ton of weird theories about how this works that make people think it's weaker than it is.

BitLocker with PIN works like this:

* BitLocker seals an encrypted key IK into the TPM using a policy on the TPM which requires the SHA-256 of the PIN to be sent to the TPM to unlock the record (and has anti-hammering at the TPM level).

* Encryption using another key called the SK. Once the OS acquires the e(IK) from the TPM, it needs to derive SK to decrypt the IK. The SK is generated by applying a salt and 0x100000 rounds SHA256 to the PIN.

* The IK can then decrypt the VMK, which can decrypt the FVEK which is the actual data encryption key used on the on-disk data.

Fully offline (no TPM access) decryption is hopeless; the IK is random and not attached to the PIN at all.

Fully online decryption relies on TPM anti-hammering; if you can manage to hammer the TPM and find a PIN where h(PIN) matches, you can then use the PIN to generate both h(PIN) (unseal TPM) and reverse e(IK).

Partially offline decryption (imagining TPM content is somehow dumped, for example by bus sniff while a user uses their PIN) relies on bruteforcing the key for e(IK), which is possible but difficult (IMO Microsoft should ratchet this up or use a more expensive algorithm than SHA-256 in order to deal with modern hardware capabilities, but they have issues like FIPS to deal with that make new algorithm selection difficult).

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#168

Post by AlienRobot »

pixl97 wrote: post #105
WhitneyLand wrote: post #99

Earlier quoted context omitted.

The premise of a secure open codebase is fine. The problem is being more auditable does not automatically make it more audited. There have to be enough people with skill taking enough time to work on it.

If you think open source is bad, wait till you see enterprise code. I'm talking full auth bypass due to the stupidest crap. You can do that in any language if you have fools working on the code base.

"It is better to keep your mouth closed and let people think you are a fool than to open it and remove all doubt" is a reason why people don't open-source more often.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#169

Post by [deleted] »

kokada wrote: post #44

While it is certainly an interesting bug, I kinda feel that the title is click bait? Because this `cryptsetup luksSuspend` from what I understood is not really officially supported but an extension done in Debian, so if anything this regression only affected Debian? I am not sure if you can blame the kernel for something that is not supported or even widely tested. I still find this impressive, and it is nice that we…

[deleted]

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#170

Post by [deleted] »

Terr_ wrote: post #140
solenoid0937 wrote: post #128

Earlier quoted context omitted.

It's probably all security theater. There's only so much trust you can put into some shitty vendor's TPM implementation

"Disk must be in expected hardware environment" versus "Same environment plus PIN" makes a huge difference if a thief simply steals a whole computer.

[deleted]
Post reply on HN