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

71–80 of 247 posts

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

#71

Post by killerstorm »

fpoling wrote: post #64

On my laptop with Fedora I just configured Linux to hibernate to disk after 15 minutes of suspend. Powering memory off ensures that bugs like this Debian-specific would not matter. Plus what Debian extension to Linux tooling does although nice in theory, but in practice if one really worries about cold-boot attacks, then all keys and important documents has to be wiped out from memory, not only LUKS keys. So hibernat…

Hmm, where does it get a key to decrypt memory on resume?

AFAIK it's practical only if you make use of TPM. And if you do, you're basically at mercy of TPM.

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

#72

Post by teravor »

killerstorm wrote: post #71
fpoling wrote: post #64

On my laptop with Fedora I just configured Linux to hibernate to disk after 15 minutes of suspend. Powering memory off ensures that bugs like this Debian-specific would not matter. Plus what Debian extension to Linux tooling does although nice in theory, but in practice if one really worries about cold-boot attacks, then all keys and important documents has to be wiped out from memory, not only LUKS keys. So hibernat…

Hmm, where does it get a key to decrypt memory on resume? AFAIK it's practical only if you make use of TPM. And if you do, you're basically at mercy of TPM.

    > where does it get a key to decrypt memory on resume?
you enter it...

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

#73

Post by gruez »

andrewpiroli wrote: post #38
nacs wrote: post #32

Earlier quoted context omitted.

Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request. https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

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.

Not to mention that unless the bitlocker activation flow changed recently, it specifically asks you how to store your backup keys, with a choice given been local options (eg. usb drive, printing it off, etc.) and saving it to your microsoft account.

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

#74

Post by dijit »

john_strinlai wrote: post #55
dijit wrote: post #50

Earlier quoted context omitted.

if by "great" you really mean "fine". It's still brittle, awkward and puzzlingly awful UX despite being the literal standard for the platform. Compare it to any of the actively maintained alternatives, Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else) or LUKS on Linux.. heck, even Veracrypt is actually easier to understand and more robust.

> if by "great" you really mean "fine". no, i mean great. managing a fleet of 100+ laptops with bitlocker is a breeze. its so seemless that the users don't even realize its enabled (i.e. no UX issues, at all). on the other hand, i am not managing 100+ laptops that use veracrypt. sounds absolutely awful. i've never managed an apple fleet, so i can't speak to that, and will take your word on it. for personal use, i do…

Flicking a button to turn something on is not what I'm talking about, that's normally the easy part of any setup, and I judge people harshly who only take that aspect of something into consideration when discussing systems.

Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid you service the laptop and now you have to enter recovery mode.

Then you're in a nightmare, trying to give someone a super long passphrase over the phone is a not-too-uncommon occurance.

That's assuming you have a good policy for storing the recovery keys. Too loose and they're handed out to everyone, sort of defeating the purpose: too strict and you need the IT department (or specific members), and its still predicated on the notion that you have a policy for it... Given that Admins are a dying breed... I don't think this is workable.

If you compare with Filevault on MacOS: which tracks the credentials of the logged in user; there's no "issue" if the device loses trust because ultimately you always use the real unlock key: not something cached in a "secure storage".

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

#75

Post by bbminner »

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 FP with invariants encoded in types is a practically feasible scalable solution either. Model checking? [LLM] fuzzing? Fewer primitives with clear boundaries? Is that how seLinux was "checked"?

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

#76

Post by pedrocr »

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?").

It was still more secure than the default if I understand this correctly. On resume from suspend the laptop would still be locked by the encryption key and without access to the disk even if you can somehow circumvent the lock. The only insecurity was that somewhere in the kernel memory the key still exists so if you can somehow extract that from the live system you can unlock it.

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

#77

Post by snailmailman »

saidnooneever wrote: post #66
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

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

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

#78

Post by killerstorm »

unethical_ban wrote: post #48
wrs wrote: post #16

Earlier quoted context omitted.

Obviously your distro isn’t using cryptsetup-luksSuspend.

Correct. The point being made is: If one isn't re-entering their passphrase after suspend, how are they surprised that the encryption keys are somewhere in memory during suspend? edit: I see now that the prompt was being given and the keys still resided in memory.

Well, potentially a key might be stored in TPM. But I don't think that's better

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

#79

Post by j16sdiz »

dijit wrote: post #50
john_strinlai wrote: post #36

Earlier quoted context omitted.

for enterprises, where this doesn't really matter, bitlocker is great.

if by "great" you really mean "fine". It's still brittle, awkward and puzzlingly awful UX despite being the literal standard for the platform. Compare it to any of the actively maintained alternatives, Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else) or LUKS on Linux.. heck, even Veracrypt is actually easier to understand and more robust.

> Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else)

Did you read the documentation?

https://support.apple.com/guide/mac-help/protect-data-on-you...

"iCloud account: Click “Allow my iCloud account to unlock my disk” if you already use iCloud. Click “Set up my iCloud account to reset my password” if you don’t already use iCloud."

https://developer.apple.com/documentation/devicemanagement/f...

"FileVault Full Disk Encryption (FDE) recovery keys are, by default, sent to Apple if the user requests them. Only one payload of this type is allowed per system."

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

#80

Post by IngoBlechschmid »

fpoling wrote: post #64

On my laptop with Fedora I just configured Linux to hibernate to disk after 15 minutes of suspend. Powering memory off ensures that bugs like this Debian-specific would not matter. Plus what Debian extension to Linux tooling does although nice in theory, but in practice if one really worries about cold-boot attacks, then all keys and important documents has to be wiped out from memory, not only LUKS keys. So hibernat…

> So hibernating is really the only proper way to protect against cold boot.

I agree; or resurrecting FridgeLock: https://www.sec.in.tum.de/i20/publications/fridgelock-preven...

Post reply on HN