What prevents the Intel TXT boot loader from being maliciously altered?

Question

From my understanding of Intel TXT, the technology can be used to put the processor in a trusted state where measurements can be performed. My understanding looks something like this, where I believe TBoot is typically used to launch SINIT. However such that SINIT is not called and the OS is brought up in a miscellaneous state? Is this a real security Threat?

Answer 1

Briefly, no.

There's a lot of problem with this diagram so I'll start by trying to clear things up before talking about your question.

SRTM ~ the left part of your diagram

The diagram propose the AC module would measure the processor which isn't right. The BIOS CRTM (Bios Boot Block) is executed by the CPU and used to measure the BIOS firmware. Then, it will return the result of the measurement (SHA1 hash) back to the TPM, not to the BIOS. Afterward, execution is passed to the BIOS firmware. The same is done for the next element in the boot process. See this for more info.

DRTM ~ the right part of your diagram

Again, the same comments applies. The SINIT AC Module does not measure the processor. Once a secure CPU contained environment is created, the module signature is validated and its identity is sent to the TPM (PCR 17), then it measure the Measured Launch Environment (MLE) and send the result to the TPM (PCR 18).

Both are providing the same thing: a means by which we can measures the running environment (i.e. Root of Trust for Measurements). Technically speaking this means sending measurements in the TPM's Platform Configuration Registers (PCRs) - mainly PCR0 for SRTM and PCR17 for DRTM. Still, we haven't done anything with those measurements.

Ok, now the question.

Briefly, a malicious user can always choose not to trigger a Late Launch/DRTM (TXT's senter operation) but the whole point is that the TPM's PCRs won't have the proper values hence some elements (e.g. keys) won't be accessible. Let me explain:

In the case of tboot boot loader, the Launch Control Policy (stored within the TPM NVRAM) defines which MLE and SINIT module can be loaded (and optionally BIOS, i.e. PCONF). A TXT Reset is triggered whenever the policy is not satisfied. The result of this reset is being unable to perform a Late Launch until the system is restarted. Not being able to perform a Late Launch doesn't prevent someone from using the system - it doesn't stop the boot process or the system by itself. However, it does prevent someone from accessing Locality 2 of the TPM. Locality 2 is necessary to extend PCR 19-22 (and any keys, TPM NVRAM and other resources tied to Locality 2).

What's important to understand here is that Late Launch is not enforcing anything, it's simply providing a means by which measurements are taken and stored in the TPM. Then and only then can we enforce different actions. E.g. if the goal is to build disk encryption, the Operating System could be encrypted with a key SEALed to specific PCRs (17-22) which match the desired/trusted operating system. Now here's the important part: if the proper environment has not been loaded (e.g. a malicious user changed the boot loader, did not triggered a Late Launch) the PCRs values won't match hence the key to decrypt the Operating System will be inaccessible (UNSEAL won't work).

In other words, PCRs values reflects the running environment. The SEAL operation uses those values as keys to encrypt data. If the proper environment is not loaded (PCRs are different) the TPM can't decrypt the data (UNSEAL).

You might want to look at ITL's Anti-Evil-Mail.

Hope this is clearer.