Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?
The evil maid attack on an encrypted disk with a passphrase is that the attacker installs a hardware keylogger, then comes back the next day and snatches your laptop, which the keylogger tells them the password for.
If you've got highly sensitive chassis intrusion detection that wipes your secrets at the drop of a hat, the evil maid triggers it in a way that looks like a false alarm, and uses a hidden camera in the ceiling to watch your recovery procedure.
And if you would never be so naive as to have a recovery procedure, the attack is to laugh their ass off because you needed that laptop to give the conference talk / client demo you came to this city for, and it also had your boarding pass on it, and now you're fired and you're stranded.
That's a weird dismissal.
This attack is a big deal because it provides a workaround to full desk encryption.
I have no idea why so many people in this thread are trying to pretend it's not a big deal. This is a big deal. Full disk encryption is supposed to make sure your data is safe if the laptop is stolen. This attack makes your data vulnerable if your laptop is stolen.
Regular password-protected FDE wouldn't be vulnerable this way.
But you know how Linux is: anyone can add any feature, no matter how bad of an idea it is. What is probably going on is that Linux's secure-boot support is not good enough to allow secure TPM-based FDE, but someone implemented it anyway. (Or it is good enough if you use a unified kernel image, but most Linux installs do not do that: https://wiki.archlinux.org/title/Unified_kernel_image)
Fedora's installer offers me the chance to turn on full disk encryption, but it does not offer me the option of TPM-based FDE.
>This attack is a big deal because it provides a workaround to full desk encryption.
Security is complicated, and this statement simplifies the situation too much.
Once you have physical access to a computer, the sky really is the limit on the kinds of exploits (both hardware and software) you can execute on an unsuspecting victim.
Disk password and no TPM binding? `dd` the entire contents of the victim's disk to an external disk. Then infect the bootloader so that the early initrd (which is responsible for that disk password prompt) will send the key to you as soon as network connectivity is established. Game over.
Secure boot? Pwn it with something like the technique I explained already.
Actually good secure boot (custom PK+MOK and a locked down BIOS config)? Pop the laptop lid, solder some wires (or in some cases, just a SOIC clip) to the BIOS flash chip (example: https://forum.phala.network/t/topic/2584), dump the BIOS, flash an insecure one, then do the same bootloader trick already described.
Of course depending on how hardened the computer being attacked it, the attacks get more sophisticated, but if someone is at the point where they're invading your physical boundaries and messing with your hardware in person, they're probably willing and capable to deploy fairly sophisticated attacks?
[1]: https://web.archive.org/web/20190801014726/https://www.cl.ca...
If a discrete TPM (separate chip on the mobo, rather than an fTPM which runs in the CPU/SoC) is in use, one can also use bus sniffing to pwn TPM protection: https://blog.scrt.ch/2021/11/15/tpm-sniffing/
In my computers, I have only non-bootable and non-partitioned SSDs/HDDs, which are completely encrypted with a random 256-bit key, so as long as an attacker has only access to the computer, for instance to a stolen laptop, there is absolutely nothing that can be done to gain access to the stored data.
To boot the computers, I use a small and inconspicuous USB memory containing the boot loader and the kernel, from which the encrypted SSD is mounted and then pivot_root is executed to replace the USB memory with the encrypted SSD as the root device, and then the USB memory is removed and it is not used during normal operation.
The USB key contains an encrypted form of the SSD encryption key, requiring the entering of a passphrase after the kernel has booted, but before mounting the encrypted SSD.
I do not know if LUKS could be used for this, I have not examined it. IIRC, LUKS stores the actual decryption key in the encrypted disk (protected by a passphrase) or in the TPM, like most commercial products for disk encryption, which are methods that I do not approve.
Your approach sounds pretty cool, by the way. I've thought about such an approach in the past, and I've used it for some auxiliary computers under my control, but not for my daily driver. I have a Framework laptop and I could indeed use this approach in quite a stylish way, though: https://frame.work/de/en/products/storage-expansion-card?v=F...
The last time when I have looked at LUKS was some years ago, when this feature did not exist yet.
In my opinion, this is the only right way to do SSD/HDD encryption. The detached header allows plausible deniability and it avoids downgrading the strength of the encryption key to the strength of the passphrase.
By using the detached header option, LUKS could be used exactly like in my custom setup.
Particularly if that unlock pin is for a FIDO key or whatever which can also be removed.
I mean, if someone steals your backpack, or stops you at the border, breaks into your house, whatever, they are getting the boot image too, right?
Furthermore, are all your machines AMD Pro or equivilant (with the encrypted RAM enabled)? Because the disk encryption key is probably just sitting unencrypted in system RAM otherwise, and is susceptible to people freezing the ram and removing it to another machine to extract the keys.
Even with physical access, the computer does not have any boot loader or kernel or any other executable that could be altered.
The attack described in the thread title also does not work, because the computer cannot boot. Even after booting from their own device, attackers cannot do anything useful. Reading the encrypted SSD will not provide any information and writing it will be detected later. The SSD does not have any non-encrypted sector.
Obviously I do not keep the USB key with the computer, especially when the computer is not with me. It is never put in the computer backpack.
Of course, if someone would watch me to discover how I start the computer and then they would capture me with all my belongings and then they would do a thorough search they might find the key and they might torture me to get the passphrase.
Nevertheless, against this kind of threats, there are no computer solutions. The only thing that would work would be the use of armed guards.
On the other hand, my method is not vulnerable to trivial attacks that could be done without my knowledge, like the one described in the thread title.
Ps I wonder what inconspicuous usb drive you use?
An example:
https://media.kingston.com/kingston/key-features/ktc-keyfeat...
I have also used MicroSD cards together with a very small USB adapter, which is also only a little greater than the USB connector.
Note that this is via a second slot, the original passphrase-only key still works unless you take steps to remove it.
As does of measuring all of the above into PCRs that are unlocked with by the utility prompting for a pin used alongside the PCRs to unlock the key.
With "cold boot attacks", after you cut power to a machine the system's memory will still be readable for a brief moment. If you chill the RAM with compressed air you can stave off the electrical self-discharge even longer. Boot to a specialized OS or move the memory to alternate hardware and you can dump its contents.
These attacks specifically target disk encryption and other keys that are kept in memory.