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

61–70 of 247 posts

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

#61

Post by weaksauce »

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.

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

If that was the case for the people using the debian extra secure extension that should have wiped the memory clean then someone would have found this bug much earlier than two years. Their password was required to be re-entered even though the key was still in memory somewhere.

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

#62

Post by akerl_ »

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.

The reason this bug is unexpected is that the user is expecting to have to enter their password (because they expect the key to be wiped on suspend), and then _they are_ asked for their password. But there was a copy of the key elsewhere in kernel memory that was never cleared.

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

#63

Post by deng »

acdha wrote: post #53
nicce wrote: post #40

Earlier quoted context omitted.

Anyone with physical access. I think it is understandable from the phrase. There is a common misconception about how lock-screens in general work - they usually just prevents using the current hardware and software as it is to access the current OS. But the disk encryption is the main thing that prevents modification and other kind of access to actual data. And if the disk encryption key is lying in the memory, then…

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.

> If you’re not a major criminal, bitcoin whale, or intelligence target this is almost certainly academic.

Thanks, that's what I thought.

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

#64

Post by fpoling »

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 hibernating is really the only proper way to protect against cold boot.

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

#65

Post by Arainach »

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.

Veracrypt is more difficult to set up - whether on one machine or a fleet. Bitlocker is a few buttons in the UI, configurable via Group Policy, and so much more.

What is brittle or awkward?

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

#66

Post by saidnooneever »

IngoBlechschmid wrote: post #34
naturalmovement wrote: post #24

Earlier quoted context omitted.

It absolutely is and they have most the enterprise market.

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

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

#67

Post by IngoBlechschmid »

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…

Sorry, aimed for a technically precise title and didn't want to bait clicks.

Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway.

Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports.

The thread-keyring(7) manpage promises: "A thread keyring is destroyed when the thread that refers to it terminates." For their key upload (from userspace to kernelspace) mechanism, the cryptsetup project relied on this property; but kernel 6.9 introduced a regression invalidating this property.

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

#68

Post by dijit »

Arainach wrote: post #65
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.

Veracrypt is more difficult to set up - whether on one machine or a fleet. Bitlocker is a few buttons in the UI, configurable via Group Policy, and so much more. What is brittle or awkward?

"PLEASE ENTER YOUR BITLOCKER RECOVERY KEY"

Where is it?

A) Uploaded to microsoft

B) Somewhere in EntraID?

C) Somewhere in our onprem AD?

D) Written down on a scrap of paper when I set up the laptop

the fact that they never ask for the passphrase is a weakness of the system. Because now you have an extremely difficult situation as soon as you're off the happy path.

It's also like 64 characters alphanumeric with no capability to copy/paste.

Compare it to Vera/Filevault where the access key is the users passphrase. In MacOS it's literally your account password, which follows along with your in-OS account credentials.

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

#69

Post by saidnooneever »

deng wrote: post #30

> Except that, for more than two years, the encryption key remained resident in memory across suspend, leaving it there for the taking by anyone who seized the still-powered laptop. I don't get it. Obviously, the laptop is locked when it resumes, how is that key "for the taking by anyone"? I'm not saying it is impossible to read out RAM from a locked laptop, but surely not by "anyone".

you dump the physical memory, then decrypt the disk offline

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

#70

Post by teravor »

on the subject of encryption keys and memory there is something you can do:

- if your CPU supports it, enable memory encryption.

- if your TPM module supports this look for MemoryOverwriteRequestControl & MemoryOverwriteRequestControlLock (/sys/firmware/efi/efivars/) and toggle them. make sure that your computer always reboots and never powers off. memory will always be wiped on boot.

Post reply on HN