4 ms·

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

by chopin 5y ago

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?

basemi 5y ago
Here a more clear explanation step-by-step of such attack: https://bugzilla.redhat.com/show_bug.cgi?id=2032401 https://bugzilla.redhat.com/show_bug.cgi?id=2032401
Macha 5y ago
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.
- lvass 5y ago
  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.
- GekkePrutser 5y ago
  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.
rjmalagon 5y ago
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.
- gruez 5y ago
  >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.
  - Macha 5y ago
    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.
TillE 5y ago
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.
dathinab 5y ago
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.

by chopin 5y ago

basemi 5y ago

Here a more clear explanation step-by-step of such attack: https://bugzilla.redhat.com/show_bug.cgi?id=2032401 https://bugzilla.redhat.com/show_bug.cgi?id=2032401

Macha 5y ago

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.

lvass 5y ago
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.
GekkePrutser 5y ago
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.

rjmalagon 5y ago

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.

gruez 5y ago
>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.
- Macha 5y ago
  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.

TillE 5y ago

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.

dathinab 5y ago

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.