6

I would like to use a TPM for providing tamper-evidence to my workstation, using SRTM (Static Root-of-Trust for Measurement). Currently, I plan to have the TPM seal a one-time value which only I know, similar to Qubes' Anti-Evil Maid implementation. The TPM verifies the BIOS, option ROMs, system configuration, and bootloader. A trusted bootloader (such as TrustedGRUB2) will verify the kernel and will use tboot (which uses the hardware ACM module) to boot the kernel. At this point, the system is considered secure (e.g. the kernel uses IMA to verify userland, or the disk is encrypted using a non-malleable encryption mode).

This is my understanding (where I may be confusing the roles of the CRTM with the ACM):

  • The CRTM, in sane firmware, cannot be modified as the CPU verifies it.

  • The CRTM is responsible for verifying the BIOS (or at least providing it to the TPM).

  • If the BIOS is modified, this will be evident as the CRTM will still give it to the TPM.

  • This is similar to BootGuard, except it provides tamper-evidence, not tamper-resistance.

My threat model:

  • My adversary is capable of modifying any writable storage on the system.

  • They cannot modify hardware itself (e.g. adding JTAG or a MITM on the LPC bus).

  • They do not know the secret which the TPM has sealed, and they cannot forge it.

  • They are not capable of exploiting the running system after it has been verified.

  • They want to monitor my input to the system after I have verified the sealed secret.

This means that I need to ensure that modifications to the BIOS can be detected (will the ACM/CRTM provide that guarantee?), and that other modifications to firmware such as option ROMs will be detected. My understanding of ACM and CRTM is rather limited. I understand the basics of how the TPM works (in regards to the PCR registers and its limitations), however.

Mistakes regarding my own OPSEC, hardware backdoors, attacks after measured boot has completed, or modification/replacement of physical hardware components are out of scope.

Is this solution sufficient for detecting firmware modification?

forest
  • 65,613
  • 20
  • 208
  • 262
guest
  • 219
  • 1
  • 5

0 Answers0