Another small setback on this topic: I got notice about potentially very easy hacks (cheap and doable in 30 minutes) if the overall hardware and software design of the TPM2 integration is crap. I read an article about someone cracking disk encryption coupled to a TPM2 chip by reading the !unencrypted! SPI bus communication by jacking in on the CMOS battery controller which apparently was using the same SPI bus as the TPM chip (this was a business lenovo notebook). The disk encryption was done using bitlocker btw., which used the unencrypted TPM2 API.

I guess a small - but intense - notice about the security implications of shitty platform design are in order. I also want to investigate, if the Linux Kernel uses the encrypted TPM2 API, which would avoid this kind of easy exploit.

Yeah, I've heard of some pretty trivial bypasses too. I thought this one was pretty good.

Excerpted from Life after Trim: Using Factory Access Mode for Imaging SSD Drives:

For encrypted SSD drives: look up for the module containing the media encryption key (MEK). While SSD encryption is beyond the scope of this article, it is important to note that certain encryption methods (such as the Windows 10 version of BitLocker) makes use of SSD built-in encryption features as opposed to encrypting data using the CPU. As a result, an expert may be able to locate the BitLocker encryption key and decrypt the data without running a lengthy attack.

Earlier in the article it is explained that some SSDs have a debug/factory-access-mode that allows one to access the encryption key that is being used if the encryption work is being offloaded to the drive itself.

Just came across another one.

https://www.theregister.com/2023/01/17/msi_motherboards_secure_boot/

Seems like there is no end to these.

I think a warning at the top after the introduction that this method is a convenient alternative to passphrase authentication, but depending on the overall system design might be less-secure than passphrase-only authentication and probably should be enhanced with a second factor (e.g. a YubiKey) - if device theft + data theft is a concern. We could then launch another article (or handle this in the Security Key article).

I revised theory and content for this article which is already available on my blog. I'll move the base to the fedora magazine wordpress soon, do some FM specific changes before it's ready for review.

https://git.221b.uk/w4tsn/blog/-/blob/main/_posts/en/2023-01-23-safe-automatic-decryption-luks-partition-tpm2.md

I did some more testing what changes which PCR etc. and found out that binding 1, 4, 5 and 7 already protects against simple things such as access from live images, disabling secure boot, etc. If one wants to also detect changes to grub2 and initramfs PCR 9 is suited (although 8 and 10 also track this, but also track simple additional USB devices). However when binding PCR 9 you'll have to enter the passphrase on every kernel update or grub change and enter a command to rebind after boot. If you omit PCR 9 one could alter the unsigned initramfs on the unencrypted boot partition

There you go: https://fedoramagazine.org/?p=37747&preview=1&_ppp=3a873898c1

@w4tsn: I've edited this and scheduled it for publication on February 1 at 08:00 UTC. You should be able to view the preview using the below link.

https://fedoramagazine.org/automatically-decrypt-your-disk-using-tpm2/

WP won't let you edit the document further while it is "scheduled". But if you want to make further changes pre-publication, just let someone know with a comment here and we can easily move it back to "draft" status so you can make further changes.

Thanks for the contribution!

FYI: I might bump this to February 3 if the #164 is ready for publication before the 1st.