4 ms·
Very interesting work, but I see 2 major weakness: (hinted at the bottom of the introduction) > So. During hibernation we freeze userland. We then reset PCR 23
by 1996 6y ago
Very interesting work, but I see 2 major weakness: (hinted at the bottom of the introduction)
> So. During hibernation we freeze userland. We then reset PCR 23 and
> extend it to a known value. We generate a key, use it and then encrypt
> it with the TPM. When we encrypt it, we define a policy which states
> that the TPM must have the same PCR 23 value as it presently does. We
> also store the current PCR 23 value in the key metadata. On resume, we
> again freeze userland, reset PCR 23 and extend it to the same value. We
> decrypt the key, and verify from the metadata that it was created when
> PCR 23 had the expected value.
First weakness: kexec. It's not clear how the extension of PCR23 will be compatible with different kernel versions. What if you want to upgrade in place and kexec your new kernel, to avoid too much time spend in the bios (as is often the case on systems with multiple disks and specific peripherals)? What if an attacker use kexec for more evil purposes?
Second weakness: kernel image attack. This work is interesting in that in provide a nice way to prevent a specific kind of evil maid attack (replacing the content of your swap by something evil), but the job of protecting the swap falls in the kernel.
If the extension of PCR23 is done with a common key (to help with the kexec - for example the UUID) or anything that can easily be guessed/recovered, it will be possible to cook an "evil" kernel that 1) extend PCR23 with it to get access 2) inject content into the swap before resume. It just moves the problems.
As most systems use a shimx64 followed by grub, it won't be detectable by the user.
The best solution I see:
1) secureboot with your own keys, using a fat EFI (kernel + initrd + cmdline in one EFI file) that you sign (cf https://wiki.archlinux.org/index.php/EFISTUB https://wiki.archlinux.org/index.php/EFISTUB ; and to automatically deploy new kernel on apt upgrade, use a systemd monitor: https://wiki.archlinux.org/index.php/EFI_system_partition#Using_systemd https://wiki.archlinux.org/index.php/EFI_system_partition#Us... ) : the computer won't boot if this is altered
2) place what's used to extend the PCR23 in a luks partitions with 2 keys: a plain text one for recovery or transfer of the disk to another computer (or rescue operations etc), one stored in the TPM
You could also store in that protected partition the keys for other boot related task - just let the kernel key manager expire the key and have the final step of the boot unmount this partition. Even if it's 0700 and the file inside are readable only by root, you don't want a zero day to expose your keys