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

91–100 of 247 posts

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

#91

Post by john_strinlai »

dijit wrote: post #90
john_strinlai wrote: post #87

Earlier quoted context omitted.

maybe i am missing something, but how did veracrypt solve all of the admin and policy issues you’re bringing up? (specifically for large enterprise fleets)

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?

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

#92

Post by dcrazy »

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 absolutely has an optional iCloud Keychain escrow. That’s how the “unlock with Apple Account” feature works. Apple doesn’t have the keys for iCloud Keychain, but it is still stored in iCloud.

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

#93

Post by dcrazy »

dijit wrote: post #83
j16sdiz wrote: post #79

Earlier quoted context omitted.

> 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/device…

Can . If you click "Allow my iCloud account to unlock my disk", your recovery key is escrowed to Apple, tied to your Apple Account. If you don't select that option it never does. I should have said "without your explicit permission", but I assumed we were all adults and understood that. The main point is that it's using your account password to unlock, the recovery key is for if you forget your account password.

No, you were just plain wrong. You said “never”, when in reality BitLocker and FileVault both have optional escrow.

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

#94

Post by Twirrim »

lazide wrote: post #85
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…

In open source, someone (many, many) someone’s can at least check. Closed source…..

Not sure why you're getting downvoted, this is the entire point of open source.

Does such a bug exist in Windows? OSX? Who checks? If someone finds the key in memory, can they tell what conditions might be causing it and where?

Their only recourse under those situations is to hand it off to the OS Vendor and trust that what they implement does solve the problem, and trust that it wasn't a deliberate back-door that is now being replaced by another back-door.

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

#95

Post by dcrazy »

dijit wrote: post #90
john_strinlai wrote: post #87

Earlier quoted context omitted.

maybe i am missing something, but how did veracrypt solve all of the admin and policy issues you’re bringing up? (specifically for large enterprise fleets)

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.

Have you never gone on vacation and forgotten your daily-use password upon return?

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

#96

Post by IngoBlechschmid »

pedrocr wrote: post #76
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?").

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.

Yes, you are right: LUKS encryption protests your data at rest. An attacker which steals your disk can only gain little, like the information that you have used LUKS (unless you put your LUKS headers elsewhere, separated from the disk) and perhaps disk and disk sector usage statistics.

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

#97

Post by someothherguyy »

teravor wrote: post #70

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.

https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-...

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

#98

Post by charcircuit »

Twirrim wrote: post #94
lazide wrote: post #85

Earlier quoted context omitted.

In open source, someone (many, many) someone’s can at least check. Closed source…..

Not sure why you're getting downvoted, this is the entire point of open source. Does such a bug exist in Windows? OSX? Who checks? If someone finds the key in memory, can they tell what conditions might be causing it and where? Their only recourse under those situations is to hand it off to the OS Vendor and trust that what they implement does solve the problem, and trust that it wasn't a deliberate back-door that is…

Security researchers find security bugs in closed source operating systems all of the time.

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

#99

Post by WhitneyLand »

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…

The premise of a secure open codebase is fine.

The problem is being more auditable does not automatically make it more audited.

There have to be enough people with skill taking enough time to work on it.

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

#100

Post by russdill »

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…

The lesson here is that if a feature (at a minimum) does not have a associated test case, it is not actually a feature.
Post reply on HN