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

171–180 of 247 posts

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

#171

Post by comex »

Guvante wrote: post #166
IngoBlechschmid wrote: post #45

Earlier quoted context omitted.

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.

I don’t know about “almost all”.

If the key has been purged but you can read RAM, then you can do two things:

1. You can extract whatever user data happens to be in RAM.

2. If you can either write RAM or reboot into your own OS, and then return the device to the unsuspecting user who will put in their password, then you can run a fake password dialog and get everything.

1 is bad, since there may be quite a lot of user data in RAM. But it’s not quite as bad as having the disk key, which gives the attacker all the data plus the future ability to decrypt or modify user data given only the physical disk. (Still, a better solution would be encrypting the hibernation image, preventing this attack entirely.)

2 is fully bad, but in many plausible scenarios (e.g. seized device) the attacker cannot just return the device to the user without them knowing something happened. Or even if they can, the method of RAM access may be one where reads are much more practical than writes, such as cold boot attacks involving physically swapping out the RAM.

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

#172

Post by adrianmonk »

bluebarbet wrote: post #148
tombert wrote: post #103

I don't think this bothers me. The only reason that I do the disk encryption is so that I don't have to worry about people going through my laptop to steal tax documents and/or credit card stuff when I sell the laptop. I of course also wipe the laptop too, but I figure that if the data is encrypted at the drive level then there's very little risk of anyone being able to use some kind of forensics tool and recover dat…

Assuming the encryption key is strong, the wiping is theoretically redundant.

And assuming the crypto algorithm has no fundamental flaws, it's applied correctly, and the software implementation has no bugs.

All of which are things people have on occasion believed to be true and found out later they were wrong about.

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

#173

Post by solenoid0937 »

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…

> the TPM effectively rate limits

I had a friend working at trusted compute at Microsoft, and he had so many stories.

These TPM firmwares are often written by shitty companies that have no fxcking clue what they are doing.

Most TPM implementations are a clown show, companies just want to check a box on paper so they say "look! We have a TPM!" and move on.

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

#174

Post by procaryote »

aniceperson wrote: post #163
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.

The whole point of luksSuspend is to not have the encryption keys in memory, as that actually does mean they could be extracted by an attacker who has taken the hardware.

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

#175

Post by charcircuit »

dlcarrier wrote: post #162
jjmarr wrote: post #152

Earlier quoted context omitted.

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.

The time limit is enforced by the TPM itself which defends against tampering.

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

#176

Post by chazeon »

polotics wrote: post #121
chazeon wrote: post #120

But if you do this, don't you have to enter two passwords each time you wake? One for LUKS, one for the system login?

Well yes and I don't see how this can be avoided.

I have always been thinking LUKS was supposed to be enrolled in TPM, so you should not have to enter this key manually; this is just to prevent someone from unplugging the hard drive and reading on another machine. Of course, this depends on one's threat model.

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

#177

Post by shevy-java »

To me the bigger problem is that the linux kernel does not seem to have a thorough test suite. Such things should be easily testable and verifiable. Apparently since 2024 nobody had that; humans are only so good for some tasks. Automatism should be done programmatically by machines serving humans.

Edit: Wait, so this was a debian patch? Now, this does not nullify my prior statements, but they should have said so clearly that debian screwed up here rather than the linux kernel devs.

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

#178

Post by acdha »

bluebarbet wrote: post #153
acdha wrote: post #53

Earlier quoted context omitted.

Anyone with physical access, significant tools, and experience. The FBI has people who can pull data out of memory after freezing the RAM but the average laptop thief doesn’t so how serious this is depends significantly on your threat model. If you’re not a major criminal, bitcoin whale, or intelligence target this is almost certainly academic.

While that is true, the fact is that encryption is technically useless for anyone who is not constantly powering off and on, which is surely a bunch of people. That this is not widely understood is IMO a problem. And excellent reason for Debian's feature. PS: Downvoting is not a rebuttal. Disk encryption is not effective security on a suspended (sleeping) system. That is a fact.

You’re being downvoted because you’re taking a narrow edge case and saying it invalidates all usage. Disk encryption is not “technically useless” when it works for 99.999+% of the people using it who aren’t targeted by professional attackers. Most people expect it to protect them against an unskilled thief or when they resell the device, and it works for that.

People in those high risk categories already need more than disk encryption anyway, so this isn’t even the critical piece for them! (Consider how likely it is that I would have the resources and access to freeze and extract your RAM but not, say, the ability to record you entering your password using the same access. Yes, you can come up with scenarios where that makes a difference but it really underscores that you have many additional things to worry about if this is your threat model.)

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

#179

Post by ltbarcly3 »

fsckboy wrote: post #117
quotemstr wrote: post #104

It's because of vulnerabilities like this that I enable Intel's "total memory encryption" feature. No plaintext leaves the CPU package. DIMM swap attacks become useless. Moreover, it's basically free: the cryptography happens directly in the memory controller, in hardware, inline with the bus transactions the CPU is doing anyway .

I don't see how that solves this problem. there is a string in memory that gets saved on suspend. that string when read by the CPU has the same properties it had before. if the CPU is using rot-13, the string is still rot-13 and the attacker doesn't need to spend the compute needed to crack rot-13, the CPU will simply do that as normal.

This is correct, the memory encryption stuff is to prevent side channel attacks, not secure data.

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

#180

Post by dwattttt »

dlcarrier wrote: post #162
jjmarr wrote: post #152

Earlier quoted context omitted.

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.

You're also not restricted to 4 digits. A full passphrase is an option.
Post reply on HN