3 ms·
A simple fix might be to bind the encrypted value to a PCR (hopefully one that isnt too fragile, but prefs one that measures the initrd) and then to invalidate
by twitchyliquid64 3y ago
A simple fix might be to bind the encrypted value to a PCR (hopefully one that isnt too fragile, but prefs one that measures the initrd) and then to invalidate that PCR when you drop to the recovery shell (by extending some junk bytes to it).
But if you can't find a PCR thats both not too fragile and measures the initrd, then youll have to settle for sealing the encryption key to a fairly static PCR, in which case the attacker could just boot into another OS and then do the right PCR extend dance to get the disk unlock key.
Its the combo of secure boot + disk unlock sealed to a PCR that is meant to get you most of the way there. Agree with other comments that evil-maid style hardware mod attacks are basically impossible to defend against, and practically most ppl attack model this as whether you can pull the disk key in X minutes rather than at all.
- patrakov 3y agoOn my laptop I have custom Secure Boot keys. I know I did not sign any other OS (well, I did - but with a different key), so this attack won't work, unless the attacker can somehow trick the unmodified previous version of the kernel + initrd combo into asking my passphrase and saving it somewhere, which is highly unrealistic.
- privacyking 3y agoIf they have physical access as per this scenario, they can just install a hardware keylogger and get access with your login credentials.
- jcelerier 3y agoOr even just hit OP repeatedly until they tell the password which is likely how many of the cases end
- arianvanp 3y agoThere's a WIP PR in the systemd repo that does exactly that. it's called pcrlock. Will come to your local distro soon :)