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

211–220 of 247 posts

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

#211

Post by Groxx »

qlte wrote: post #182
Groxx wrote: post #136

Earlier quoted context omitted.

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…

"modify the windows installer via a binary patch to work around the continued bloat and feature crippling" really isn't "local accounts are supported" in my book. that's like saying "the 1965 ford mustang was an electric car" because someone did a conversion on it a few years ago.

and the actually supported workarounds have disappeared, last I saw - bypassnro and disabling internet both failed completely for me, the last time I tried. maybe they have come back (it has intermittently failed in the past and come back), but they're very clearly doing more to remove it than they did a year+ ago when bypassnro worked easily and consistently.

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

#212

Post by miki123211 »

Imagine how this HN thread would have looked like if this vulnerability existed in a proprietary OS.

The top-level comment would surely have been about how Applosoft doesn't care about software quality any more and "that's what you get if you allow vibe-coded slop into your OS". The one below it would have been a crazy (everywhere else, not crazy for HN) conspiracy theory about the surveillance industrial complex and the NSA.

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

#213

Post by [deleted] »

tredre3 wrote: post #122
dist-epoch wrote: post #58

Earlier quoted context omitted.

Both Intel/AMD CPUs produced in the last 5 years or so support full transparent (to the OS) memory encryption. So cold boot attacks are a thing of the past if you enable this feature (it's typically disabled because it reduces RAM speed by about 0.5%).

The impact on performance is more along the lines of 1-2% on AMD (though it likely varies by generation (I did extensive benchmarking on Renoir wrt throughput/latency/gpu). But yes small enough to be insignificant unless you run LLMs or game on the iGPU. I imagine that it also uses marginally more power. AMD also has a second encryption mode where the OS decides what gets transparently encrypted, it doesn't have to b…

[deleted]

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

#215

Post by saidnooneever »

snailmailman wrote: post #77
saidnooneever wrote: post #66

Earlier quoted context omitted.

veracrypt lost their drivers license so afaik you should avoid it since it cannot update its drivers any longer. didnt see any news about them reacquiring that license

Assuming this is what you are referring to, it was resolved within a few days. The incident being resolved just didn't make headlines. https://sourceforge.net/p/veracrypt/discussion/general/threa...

aah cool, thank you..100% missed the update :). thanks! thats good to read honestly lol. not that i use windows much but i felt it was MS trying to undermine it. happy it got restored and there remains an alternative to butlocker.

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

#217

Post by dlcarrier »

charcircuit wrote: post #175
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.

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

I found some pictures of TPM modules with crystal oscillators, so those could keep time while powered on, but wouldn't be able to keep time while off. It would be possible to only count time while on, but that would be really annoying to a legitimate user that kept turning off the computer, waiting for the time limit to expire, especially if it doesn't tell the user how much time is left.

Anyway, crystal oscillators connect to one input pin and one output pin, with an internal feedback circuit that causes the crystal to resonate. It's possible to change out the crystal for a higher frequency, or even directly drive the input pin for a much higher frequency. Semiconductor manufacturers often only characterize the limit of the feedback circuit, but not the limit of the internal clock circuitry when directly driven. Considering that the logic design supports an SPI bus running up to tens of megahertz, it's totally possible that the crystal input could be driven at a similar speed, possible a thousand times faster than a normal real-time clock oscillator.

There would be several ways to mitigate such an attack, but a quick search for TPM side-channel attacks brings up multiple much simpler vulnerabilities, so it's not likely that TPM manufacturers are putting any real effort into mitigation.

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

#218

Post by dlcarrier »

solenoid0937 wrote: post #173
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…

> 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.

A quick search for "TPM side-channel attack" substantiates that claim.

Looking at the manufacturers of TPM ICs, it makes sense. Most of them make microcontrollers that have code-protect bits in them that are notorious for being susceptible to simple side channel attacks, but also for not being a target simply because no one cares about the object code on any random product's microcontroller.

I worked at a company that sold a microcontroller that executed from external memory, so there was no possible way to have built-in code protect bits, and some potential customers complained until we included a library to encrypt the external memory, run a small unencrypted bootloader which included the a plain-text decryption key, then run the encrypted program. That checked their box, despite doing nothing useful.

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

#219

Post by dijit »

john_strinlai wrote: post #91
dijit wrote: post #90

Earlier quoted context omitted.

If you use your key every day you tend not to forget it. If I as an admin give you your key: it is “leaked” effectively.

> If you use your key every day you tend not to forget it. hoping users don’t forget their password is a very weak policy. specifically, the policy and admin points you brought up above, how does veracrypt solve them?

We're sort of talking about two things and conflating them.

I'm sort of talking about my user experience of the system, and I'm getting it in the neck from helpdesk.

Enterprise rollouts are different from anything I actually deliver, despite pushing out thousands of windows servers: I have complete control over those.

Same as my local PC.

But as a user on a PC I'd buy from a store, I'm not going to forget my password without expecting to lose access to my system.

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

#220

Post by mrob »

foltik wrote: post #201
whimsicalism wrote: post #200

Earlier quoted context omitted.

AI reply, triggered my spidey senses

Yup look at the rest of their comments

We should just automatically ban every new account with "AI" in the about field. I don't think we'd lose much.
Post reply on HN