1

When using a TPM to provide integrity measurements for a system via SRTM, the trusted computing base is reduced to only the TPM and CRTM. The CRTM is a component of the BIOS (specifically the bootblock) which executes first and allows the TPM to hash the remaining contents of the BIOS, in effect making it so that even compromised firmware cannot break the chain of trust. It is intended to be read-only and is stored alongside the BIOS. If it is not read-only, then it cannot provide integrity.

Typically, the chain of trust goes like so (where the CRTM and TPM are trusted):

  1. The CRTM sends the hash of the BIOS itself to the TPM.

  2. The BIOS sends the hash of the option ROMs, MBR, and bootloader to the TPM.

  3. The bootloader sends a hash of the kernel and boot parameters to the TPM.

  4. The kernel is executed, and it verifies the integrity of userspace executables.

Each earlier stage verifies subsequent stages, all the way to userspace. When the kernel is up, the TPM will only "unseal" itself and reveal a secret value if all of the hashes it has gotten thus far are correct. A compromised system will not be able to successfully unseal the TPM and the secret value not be revealed. The end result is that, if the CRTM is trusted, everything will have been verified and need not be trusted, from the BIOS to the kernel to userspace. All of this relies on the assumption that the CRTM and TPM cannot be modified. However, the potential for implementation issues was highlighted in the section Implementation Specific Attacks on the ITL blog.

How can one verify that a specific vendor's CRTM is read-only in hardware?

  • In a discussion I had over in the Electrical Engineering chat, it seems very likely that the only way to test this would be to verify that the actual chip has loaded the CRTM into a read-only storage region. Most chips either have OTP fuses that can lock this region, or a jumper that sets it to read-only. – forest Dec 15 '18 at 4:27
2

As the name implies, a CRTM is the Core Root of Trust for Measurement. By definition, a Root of Trust of a given system is trusted because its correct operation cannot be verified by that system. In general, for a CRTM to operate correctly it must be immutable for the system that relies on it.

So, by principle, it doesn't make sense to try to verify the immutability of a Root of Trust from within the given system ("in-band"), especially if the trustworthiness of the verification relies on the very assumption you try to verify.

Nevertheless, verifying the immutability of a CRTM would depend on the particular CRTM implementation and on the level of assurance that you are trying to obtain, with approaches ranging from attempting to write to the given CRTM code location to hardware design review and physically invasive methods.

  • My question is more about verifying the implementation on an already trusted system. Naturally you could not verify (from software) whether or not it is read-only on a compromised system. – forest Apr 25 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.