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?
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.
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.
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 mean, unless there's a deliberate backdoor, any half-competent drive encryption implementation will require a passphrase or key to decrypt.
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.