by supermatou on 12/30/24, 6:43 PM with 176 comments
by jansommer on 12/30/24, 8:42 PM
Now I've been trying for months to do the same for Linux. There's systemd-cryptsetup/cryptenroll, but it's only for LUKS and I'm trying to encrypt a few sensitive directories on a super slow internal eMMC with fscrypt (keys for secure boot and /home). The TPM is _EXTREMELY_ hard to code for when things go beyond the basics:
1. Bind to PCR 7
2. Bind to changing PCR 11 (changes whenever the kernel, init, cmdline etc. is updated)
3. Use a PIN - but not the AuthValue, because I want to use the same authorization policy for resetting the DA lockout counter on login, and also have a long password/AuthValue for resetting the counter manually.
4. Make it all work with PCR 11 signatures and public keys provided by systemd-stub.
Maybe this isn't the right place to ask, but there's almost nothing but basic TPM guides out there, so if you're an expert I could really use your help. It's just for a personal project, but I'll write about it once I'm done - if I ever figure it out!
by jandrese on 12/30/24, 8:07 PM
So if someone steals you machine with an encrypted hard drive they need to...just turn it on? That can't be right, but at the same time I have no idea how this particular attack is defeated. I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that, but it seems like the machine is going to give up the key pretty easily regardless.
With LUKS it at least has a password prompt to unlock the drive.
by mjg59 on 12/30/24, 7:44 PM
by NoInitRD on 12/30/24, 11:24 PM
by PhilippGille on 12/30/24, 8:55 PM
by layer8 on 12/30/24, 10:11 PM
[0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
by RachelF on 12/30/24, 10:35 PM
Both Intel and AMD are working on embedding this into their CPUs.
However, the target use appears to be servers with multiple VMs, not laptops.
by 0xml on 12/31/24, 3:18 AM
by ivraatiems on 12/31/24, 6:52 AM
I'm thinking of something like the old "Action Replay" devices for Gameboys, which modified memory from the game cartridge as it went into the system to be loaded (or executed in the case of code) in order to cheat in games. You slotted the cartridge into the Action Replay, then slotted the Action Replay into the Gameboy.
Could you do something similar between the RAM and the motherboard? Slot your ram into the device, slot the device into the motherboard, and capture the state of memory at any moment by simply watching how memory is read/written? That way, you'd save yourself the hassle of manually powering off the machine and hoping the data you need is available?
I'm not an electrical engineer so maybe what I am proposing is completely infeasible - physical space and bandwidth limitations certainly seem likely. But is it possible?
by dist-epoch on 12/31/24, 10:25 AM
It's typically disabled in BIOS, since it has a small memory performance penalty (0.1%->1%)
But it would completely prevent this attack.
by ibbtown on 12/31/24, 8:00 AM
by shortsunblack on 12/31/24, 1:07 AM
by medlazik on 12/30/24, 10:29 PM
Game over, any laptop with data worth stealing will have this disabled in bios
by jpalomaki on 12/31/24, 8:55 AM
Not sure how much this helps against a determined attacker, but it's easy and inconvenience is minimal in most cases.
by slicktux on 12/30/24, 8:46 PM
by 3eb7988a1663 on 12/30/24, 7:29 PM
by wh_123 on 12/31/24, 6:58 AM
by EVa5I7bHFq9mnYK on 12/31/24, 8:19 AM
by devops99 on 12/31/24, 9:05 PM
It's a shame that popularly used OEMs still allow "abrupt restart" to be so easy.
by maxo133 on 12/30/24, 8:13 PM
> In my experience I have had the most success restarting the system while Windows is loading but before the login screen has appeared, at least in the case of finding FVEK keys.
So what is this? It was supposed to be memory attack and he's dumping the keys after someone unlocked it and it's booting?
So this is just another theoretical attack where perfect conditions must be met.
by tnetenbaa on 12/30/24, 7:18 PM