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