6 ms·
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
by gameoverhumans 3y ago
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 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?
- magicalhippo 3y agoThere's also voltage glitching which has been used with great success as well[1][2]. [1]: https://web.archive.org/web/20190801014726/https://www.cl.cam.ac.uk/~sps32/mcu_lock.html https://web.archive.org/web/20190801014726/https://www.cl.ca... [2]: https://arxiv.org/abs/2108.04575 https://arxiv.org/abs/2108.04575
- gameoverhumans 3y agoIndeed! 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/ https://blog.scrt.ch/2021/11/15/tpm-sniffing/
- Kiuhrly1 3y agoFor 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.
- adrian_b 3y agoBecause 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.
- alexeldeib 3y agoAre you still using LUKS for these? How are you invoking decryption with the pass phrase protected key?
- adrian_b 3y agoI 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.
- gameoverhumans 3y agoLUKS supports detached headers, maybe this would be useful for your setup? https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encryp... 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=FRACCFBZ02 https://frame.work/de/en/products/storage-expansion-card?v=F...
- theLiminator 3y agoIs there a way to do 2FA yubikey style disk encryption? Ie. requires a passphrase + user's yubikey to login?
- o11c 3y agoYes, see https://askubuntu.com/questions/599825/yubikey-two-factor-authentication-full-disk-encryption-via-luks https://askubuntu.com/questions/599825/yubikey-two-factor-au... Note that this is via a second slot, the original passphrase-only key still works unless you take steps to remove it.