>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be.
Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?
If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot.
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.
> If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot.
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.
Linux's full disk encryption (FDE) is probably good at discouraging evil-maid attacks if used with a passphrase that the user enters every boot.
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.
In my view, a setup where you are forced to enter a decent-quality disk-unlock passphrase on every cold boot is a rather hardened setup. The problem is, this is awful UX. If something causes a lot of friction, folks tend to just avoid that thing. And that's why many people just bind the disk encryption key to their TPM and call it a day. Thus leading to the exploit detailed in the parent article.
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?
Because of things like those described by you, I have never trusted bootable encrypted SSDs/HDDs.
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.
While cool/interesting, i'm failing to understand the attack your protecting against here in the context of just prompting for an unlock PIN.
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.
The attacks "evil maid" described by a poster above are impossible.
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.
I use various Corsair or Kingston USB flash drives, with sturdy fully metallic cases, and which are just a little larger than a USB connector, i.e. they just have an ear that remains outside the connector when inserted, to allow for their extraction.
I am not using LUKS, I am using a custom kernel module that implements a block device that presents to the kernel the decrypted SSD. The kernel module receives the key when it is loaded, then it creates the block device that is eventually mounted as the new root device.
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.
Indeed! Voltage glitching was used to jailbreak Tesla recently! I believe it was also used to jailbreak the Nintendo Switch.
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/
For the Nintendo Switch, it was used to dump some firmware which was then analysed and found to have a buffer exploit (can't remember what sort), which let to the famous Fusee Gelee exploit on early switches. IIRC it was a security chip which is both ironic and incredibly useful because it couldn't be patched without a hardware revision and it ran before anything loaded from the onboard storage.
The thing that prompts for your password is necessarily unencrypted, the evil maid just needs to modify that to e.g. log the decryption key. On linux, this is usually just a shell script invoking cryptsetup somewhere in the initramfs image.
Maybe, it is possible to use both a firmware unlock against an OPAL encrypted drive, and validate the signature of the initrd/UKI as part of secure boot. Either or both protect against this to a certain extent depending on configuration.
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.
The code that displays the password prompt and unlocks the disk could be replaced by a modified copy as it isn't encrypted. TPM would protect against that though.
Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?