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

181–190 of 247 posts

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

#181

Post by quotemstr »

ltbarcly3 wrote: post #179
fsckboy wrote: post #117

Earlier quoted context omitted.

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.

Memory encryption is secure under a certain threat model. It makes cold boot attacks, DIMM transfer attacks, and rowhammer much harder to pull off. It doesn't protect against everything and doesn't pretend to do so, but IMHO it's valuable anyway.

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

#182

Post by qlte »

Groxx wrote: post #136
andrewpiroli wrote: post #38

Earlier quoted context omitted.

Only if you store your key with Microsoft, which is not required or the default if you're using a local account which I assume most privacy sensitive people are.

Agreed it's optional (I've seen and used that option), but are local accounts even a thing any more? Or are you just referring to "not MDM controlled" accounts?

  > are local accounts even a thing any more?
Yes, most certainly. You can easily convert to a local account in Settings, and there is still a workaround to avoid using a Microsoft account during install. Or the far more stable and reliable method of using Rufus to create the installer ISO which has an option to use a local account without the hassle.

Rufus for install + Win11Debloat post-install is a nearly effortless way to get an ad-free, local only Win 11 install that persists through updates which removes pretty much all notorious Win 11 pain points (plus additional customization if desired).

I've been doing it for years and so reading Windows 11 complaints on HN always feels like they're coming from a strange parallel universe since I never have to deal with any of it.

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

#183

Post by shakna »

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.

Most enterprises require a 12 digit code, to meet a specific security standard. Bruteforcing that, with hardware access restricted by TPM, would take a very, very long time.

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

#184

Post by tombert »

adrianmonk wrote: post #172
bluebarbet wrote: post #148

Earlier quoted context omitted.

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.

I mean I don't think it's unfair to say that most of the battle-tested encryption is "uncrackable enough" for the consumer.

If you're working for the NSA you need to worry about these things being cracked, obviously, but for the "I don't want a scammer to buy my laptop and get my social security number" situation, I think that you really can just assume that LUKS is uncrackable.

That said, it takes like five minutes to boot a live Linux flash drive and run fdisk to delete the partitions and/or install Mint or something over the existing data, so I don't really see any reason not to do it, even if it's not strictly necessary.

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

#185

Post by dwattttt »

pjdesno wrote: post #111
bbminner wrote: post #75

I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if…

To translate to Rust, it would have been "we missed a single line Rust check"... This is a bug involving intersecting concerns and a deficit of cross-domain knowledge. It probably would have been the same in Lisp or assembly language.

I think https://news.ycombinator.com/item?id=48766436 is a practical answer. A marker that can't be forged (without explicitly malicious code being written), which is needed by the "yield to suspend/shutdown" function.

Missing the "wipe key from memory" means you don't have the marker, and trying to continue the suspend/shutdown will fail to compile, because you don't have the marker.

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

#186

Post by nicce »

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…

Hmm, the subcommand is in the official cryptsetup repository and the description matches? https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/man/cry...

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

#187

Post by bluebarbet »

acdha wrote: post #178
bluebarbet wrote: post #153

Earlier quoted context omitted.

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 th…

Yes I understand all that. I don't have secure boot, so I'm not protected against the evil-maid attack either. I know that too.

It's why I used the word "technically", by which I meant "in the absolute". What word do you propose instead? Encryption that can be worked around by anyone with skills and commonly available equipment is technically useless. It offers some protection (the thief will probably reboot or unplug) but ultimately it's null and void.

>Most people expect

This would need to be sourced. I say most people expect "encryption" to be as secure as the encryption password. In the case of an unattended sleeping computer using Linux with FDE enabled and the screen locked, it's not. I'm not sure most people know that. I believe things are different on, say, iOS. All of this was the rationale for Debian's (buggy) feature.

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

#188

Post by XorNot »

comex wrote: post #171
Guvante wrote: post #166

Earlier quoted context omitted.

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 use…

The seized device scenario is starting to get very specific though: in the actual cases it's relevant like the Silk Road take down the device was intercepted while open.

It's of some frustration to me that more security devices don't have a "pull pin to destroy" function available in them for this reason if you have any type of threat model where this applies: e.g. when I thought about using a Yubikey to secure remote access, a core problem is you can't quickly wipe a Yubikey in your possession - and while they're fragile in daily use, they're also surprisingly hard to intentionally destroy quickly.

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

#189

Post by XorNot »

dwattttt wrote: post #180
dlcarrier wrote: post #162

Earlier quoted context omitted.

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.

Which I wish was more heavily advertised because a passphrase is a lot easier to remember.

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

#190

Post by chlorion »

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…

You can just wipe the luks header as a nice middle ground.

Luks uses an anti-forensics algorithm that requires the entire volume key being available to unlock the disk at all (it combines the blocks of the key with some diffuse algorithm and xors stuff together to form the actual master key), so in theory you can just clear one sector of the volume key and the whole thing should be unrecoverable.

What I mean is that if even one block of the key is missing you can't guess the rest easily.

Post reply on HN