Decryption through LUKS2 reencryption crash recovery | Hacker News Reader

Decryption through LUKS2 reencryption crash recovery

seclists.org

143 pointsbeermonster38 comments

Generally speaking hard drive encryption protects against theft and not tampering. I.e. the idea is that if your laptop or NAS is "lost and found", then you wipe the drive and restore from backup, not continue to use the drive.

Since the protocol used here is broken the fix is to change the protocol - so keep in mind that...

> The former reencryption operation (without the additional digest) is no longer supported (reencryption with the digest is not backward compatible). You need to finish in-progress reencryption before updating to new packages. The alternative approach is to perform a repair command from the updated package to recalculate reencryption digest and fix metadata.

Just in case you were thinking about upgrading the software during re-encryption - don't.

cryptsetup supports using AEAD modes for encryption, primarily using AEGIS-128 as algorithm.

Some background information https://arxiv.org/abs/1807.00309

There is also old presentation, which explicitly refers to protecting against "returned disk" scenario: https://archive.fosdem.org/2018/schedule/event/cryptsetup/at...

> Just in case you were thinking about upgrading the software during re-encryption - don't.

You'd expect such a critical software had necessary failsafe mechanisms around that.

What's still unclear to me: can you just grab an encrypted device (cold) and decrypt it? Or does the attack require a "live" device i.e one where the passphrase already have been given and the device is online?

Here a more clear explanation step-by-step of such attack:

https://bugzilla.redhat.com/show_bug.cgi?id=2032401

From reading the links, you can modify a cold volume, so that next time it's loaded and written, cryptsetup will write out the data decrypted to the disk, so that you can access it cold a second time and the data will be decrypted.

So a legitimate user does have to decrypt it in the middle, but you don't need to control what they do or access it the same time they do.

Great explanation, thanks. Now I assume that, having an encrypted external LUKS2 device, if someone may have had access to it I should never decrypt it in a system with a vulnerable cryptsetup version.

To be fair, once you have the device in your hands you can do other nastiness as well such as loading a modified initramfs (such contains cryptsetup) that intercepts the entered key and writes it somewhere. This part of the boot system is normally not encrypted as it's the very step that asks for the passphrase.

Good 'evil maid' mitigations should be sufficient here too, like encrypting at the SSD level with a boot password.

However I do wonder if this bypasses secure boot checks as I doubt the Luks header is signed. That's normally an evil maid mitigation but I don't think it'll suffice here.

Your second guess is the correct one. This is a bug in the LUKS2 header metadata that can trick the kernel to "recover and resume" an unsolicited decryption/reencryption process. Very hard to do because you need access to the drive and later someone to unlock the modified drive.

It as fixed bug, and a plausible scenario is if someone wants to decrypt a LUKS2 (in and old linux kernel system) which is auto unlocked by a TPM like device.

>It as fixed bug, and a plausible scenario is if someone wants to decrypt a LUKS2 (in and old linux kernel system) which is auto unlocked by a TPM like device.

how's the TPM ecosystem on linux like? On windows bitlocker, it mostly just works, but IIRC on linux you had to jump through a bunch of hoops to get everything configured.

It's not auto setup like bitlocker, but once setup it is reliable (if your TPM itself is, unlike the Zen 2 fTPM...) and working.

It would be a pretty wild design failure if you could just take an encrypted drive and quickly crack it.

I mean, unless there's a deliberate backdoor, any half-competent drive encryption implementation will require a passphrase or key to decrypt.

neither

it requires you to:

1. mess with a device

2. and then the device to be used (with the proper password)

3. and then you having access to it again

At lest that, for certain attacks maybe multiple iterations of this, not sure.

So it's not braking the main security model: Device Theft = Data Theft protection.

What does this let an attacker do exactly that they couldn't already do with a regular evil maid attack?

I think this doesn't care about secure boot? As it works on the unauthenticated data, rather than the bootloader + kernel which in a properly configured secure boot system will not boot if modified.

secureboot can be trivially disabled in firmware.

But your computer will complain loudly because it’s 2022 and you use tpm2-totp because that’s the normal thing to do.

You need to be able to modify the contents of the disc, which implies that either you have managed to boot your own OS or you have been able to temporarily plug the storage into something else. This is as you say a much lower bar to clear than modifying the OS of the device as in a classical evil maid. Effectively, the maid is already built in to the OS in the form of the bug.

Technically you can have access to an encrypted device (e.g. USB stick) but not the machine the owner uses to enter the passphrase.

> LUKS2 online reencryption is an optional extension to allow a user to change the data reencryption key while the data device is available for use during the whole reencryption process.

Since it's optional, is it possible to see if this is enabled or disabled, and how to disable it?

Some people keep the LUKS2 volume header in a separate file that's encrypted (e.g., with gpg). Would someone still be able to attack a cold volume using this vulnerability in that case?

I still don't get how the fix works. If I just mount an external LUKS2 device in an updated system, It's good to go?

The way I understand it the reencryption process now requires additional digest of reencryption metadata. This digest cannot be calculated without knowledge of the passphrase. This means that the attacker can still modify the metadata but cryptsetup will scream loudly when you try to open the device because the digest will be incorrect/missing. So yes, updating the package should be all that's required.

> The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step.

First time I'm glad grub cannot boot LUKS2.

Grub doesn't support LUKS2 encrypting the boot partition with Grub config files inside, but it can decrypt a LUKS2 root partition

I thought grub2 does support this now?

LUKS2 is supported with some know limitations [0]

Argon2id (cryptsetup default) and Argon2i PBKDFs are not supported, only PBKDF2 is.

grub-install does not support creating a core image that could be used for unlocking LUKS2.

[0] https://wiki.archlinux.org/title/GRUB#LUKS2

Could then NSA crack any LUKS encrypted container held on cloud storage such as Dropbox or GDrive (opened with a key on client side, never entered on server)?

LUKS should not be used on top of an rclone mount or something like that.

The container could be held in a local drive that syncs to a remote, such as Dropbox. The sync will be incremental. Still it’s not a good approach.

Also I sometimes use LUKS on top of a LAN network share such as Samba, but I don’t recommend this either.

XTS mode and lack of authentication used in disk encryption are drawbacks.

Does this affect LUKS1?

From the article:

> The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step.

I'm sorry for being thick, but this sentence sounds like LUKS1 can be update to LUKS2 in-place, so it is affected.

It is a fixed bug. Your target needs to be an outdated Linux distro.

In a current one or patched one, is more likely to have a non-vulnerable LUKS2 volume that you can not downgrade to a vulnerable one, or a kernel and userspace tools non-vulnerable to the metadata manipulation even for a LUKS1 volume.

I concede the plausible scenario of replacing the kernel to a vulnerable one, if you ha access to the drive (by external OS boot or get the hardware) and replacing the kernel on the usually unencrypted boot partition along modifying the LUKS2 metadata of the encrypted volume. Not a quick local or remote feat to do. Not doable on an encrypted boot volume or signed boot files (secure boot thingy). Sincerely, if you have that kind of access, it is easier to modify the initramfs file to grab the LUKS key.

Not so outdated. No Ubuntu version has the fix up to now. They think 18.04 is not affected [1]

  Ubuntu 21.10   Needed
  Ubuntu 21.04   Ignored (reached end-of-life)
  Ubuntu 20.04   Needed
  Ubuntu 18.04   Not vulnerable (code not present)

[1] https://ubuntu.com/security/CVE-2021-4122

Yup, Ubuntu is ongoing in this. Debian is in a better shape.

Is that even possible in a cold device?

According to [0] attacks from a cold device require two steps of physical access. That would bypass signed contents of a boot partition, since you're messing with unprotected LUKS header contents.

If the contents of the boot partition are unsigned there are probably easier attacks available. You could, for instance, deploy a kernel with crafted reencryption logic baked in over the default boot kernel. That wouldn't require this vulnerability, because the victim will be typing the passphrase into the attacker's (unprotected) kernel from /boot.

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=2032401

Reply on news.ycombinator.com