PCR event vs PCR extend

[rossphilipson]

This issue is to track the proposed work to switch from using PCR extend commands to PCR event commands per the request from the LKML community. One goal here is to get feedback on the idea in general and the proposed implementation.

For background, the on-list conversation has evolved from talking about SHA-1 to proposing a rather large change of how we handle the TPM events/PCRs in our Secure Launch feature. This came about with the submission of patch set v11 and v12 is dependent on this. We currently use the TPM in the manner that TXT calls performance mode where digests are calculated by software then sent to the TPM with extend calls (as the ACM does in this mode). The PCR_Event approach is like the TXT agile mode, where the raw data is send to the TPM and it internally computes the hash for all open banks. This latter approach is what is being proposed as a better approach than our current one.

The PCR_Event approach would require a number of changes. This is one idea of how this could be implemented:

• Have the early SL stub code in the setup kernel use a hash algorithm (e.g, SHA 512) to hash all the items in the policy specified (command line, boot params, initramfs, etc).
• Modify the SLRT policy to have an updatable field for storing this hash. The SL early stub code would no longer update the DRTM log as it does.
• Modify the slmodule event processing code to send all the hashes from the policy to the TPM using TPM_Event which in turn will return all the digests that it produced.
• After the updates, the slmodule would append the DRTM log with each event and its digest ID.
• Add TPM_Event support to the existing TPM Linux driver.

There are a couple of downsides to doing this in general:

• The PCR events will be based off of hashes of the data not the original data. Taking hashes of hashes increases the likelihood of collisions.
• There are significant code changes to achieve this. In addition, the SLRT interface would need to change to accommodate this.
• It is not clear how to handle TPM 1.2 platforms since they don't have a PCR_Event command. The same method could be used (i.e. take an early SHA 512 hash) or the data can be hashed/extended directly using SHA-1. In either case, the SHA-1 patch would still be needed it seems.
• Adding support for doing PCR_Event to the Linux TPM driver is not trivial and this will mean more TPM patches that the TPM maintainers have to sign off on.
• Hashing anything using hardware support in the TPM is a slow process.
• It is not clear if there are any issues with AMD/SKINIT and this approach.

The final thing (and perhaps the most important one) is whether the TrenchBoot project members think this is a worthwhile undertaking. The current method we use is viable per the TXT specification though we could add SHA-384 and SM3 to bring the Secure Launch feature up to parity with the algorithms that recent ACMs support. The big issue here is can we make a convincing argument that the existing approach is reasonable, not insecure and works as we intended it to.

[dpsmith]

Summary

After reviewing the TPM Carte Blanche¹ write-up shared by Luto and investigating what risks and concerns there might be with using TPM2_PCR_EVENT, I have come to the conclusion that it would be safe with one caveat.

TPM Carte Blanche

First, to address the TPM Carte Blanche attack, such an attack is not feasible against DRTM. The crux of the attack was two-fold:

1. That it ensured all components in the boot chain did not record measurements into the SHA256 bank.
2. That an acceptable attestation allowed single bank attestations that did not include the spec default bank.

Both of those conditions must be met to achieved, and most certainly the first will not occur for a DRTM launch, and guidance is given in the TXT spec as to which algorithms will be used in the launch. The reason the first will never happen is that when the DL Event occurs, the CPU will use the _TPM_Hash_Start/_TPM_Hash_Data/_TPM_Hash_End
sequence to send the hash of the DCE, the SINIT ACM for Intel, to the TPM, which will result in all PCR banks to be extended with the hash. On Intel, the TXT spec specifically outlines which algorithms are supported by the ACM, when not running in Agile mode. A well-designed attestation service would request quotes for all supported algorithms along with the complete DRTM log. All supported PCR banks will contain measurements for everything up and including the DLME that was started. This attack immediately fails because the purpose of requirement (1.) is to ensure the bogus Linux environment does not get measured, but the ACM will measure the bogus Linux environment and this cannot be turned off or blocked.

TPM2_PCR_EVENT

The approach of using TPM2_PCR_EVENT in mathematical form would be:
PCR = Hf'_Extend(Hf'(Hf(Data)))
With this approach, an important factor to consider is the block size of the Hf' in comparison to the output size of Hf. The optimal selection is that Hf output size is equal to or greater than the block size of Hf'. For the algorithms currently supported by TXT, SHA1, SHA2-224, SHA2-256, and SM2/3 all have a block size of 512 bits and an output size 256 bits or fewer. The supported algorithms of SHA2-384 and SHA2-512 both have a block size of 1025 bits and output sizes of 384 bits and 512 bits respectively. Thus, using any algorithm from the first set as Hf would have to zero pad at least 256 bits when Hf' is also from the first set and at least 768 bits when Hf' is from the second set. It is easily seen that, following this analysis to its conclusion, that SHA2-512 is the minimum acceptably sized algorithm for this scheme.

From a meta-analysis standpoint, if one accepts the scenario is that the attackers only has the ability to manipulate the input data, the question becomes what must they do to create a dubious measurement result. The answer is that they must in fact find a pair of co-incidental collisions in both Hf and Hf'. Let us consider the situation where Hf is SHA2-512 and Hf' is SHA1, an algorithm with known collision. Then the attacker must find either:

1. A collision in SHA2-512 itself.
2. A collision in SHA1 from two distinct 512 bit values, for which one is the legitimate value and the second is a value that can be coerced by modifying the original data.

With this understanding, it would hold that SHA2-512 would be the most resilient to either conditions.

Conclusion

The TPM Carte Blanche attack is not a relevant factor that must be considered in regard to the issue raised around algorithm agility concerns. While it is not a valid concern with respect to algorithm agility, agility itself is worth a consideration, especially if the solution might reduce code size/complexity for the implementation. Based on the analysis provided above, only having to support SHA2-512 in the setup kernel and relying on TPM2_PCR_EVENT in the mainline kernel to ensure all PCR banks are extended is an acceptable approach. There does not appear to be any perceivable risks, and reduces the number of hash implementations required in the setup kernel.

Footnotes

1. https://google.github.io/security-research/pocs/bios/tpm-carte-blanche/writeup.html ↩

[krystian-hebel]

libstb, used by OpenPOWER firmware, uses yet another approach: they calculate SHA2-512 and use first bytes (20 for SHA1, 32 for SHA2-256) of the result to extend SHA1 and SHA2-256 PCRs: https://github.com/open-power/skiboot/blob/bc7b85db1e7ef55c8fd0ec3d90c093572b02a153/libstb/trustedboot.c#L250-L257. This has the same advantage of requiring only one function for calculating the digest, but I'm unable to say if this is mathematically sound.