On 8/30/2023 5:32 AM, Guozihua (Scott) wrote:
On 2023/8/29 5:05, Ken Goldman wrote:
I'd like to present three possible cases, expanding on Mimi's
observation that the template hash is currently the hash of the
template data.
My vote is #2, but all have merits.
----------
1. Leave the SHA-1 template hash.
A. This does not break existing applications.
B. The template data is protected by the TPM quote, which does not
have to be SHA-1.
C. The SHA-1 digest provides some debug usefulness against a
non-malicious alteration of the template data. The application can
report which event record is incorrect.
What the verifier can't do as of now is to tell which file has been
corrupted, given the attacker managed to achieve a SHA-1 collision while
keeping the measurement items reasonable.
That's why I said "non-malicious". A collision in that case is unlikely.
It's just a debug aid. The quote failed. Including a SHA-1 hash
can help in software debug.
Even worse, as the TPM quote contains only an accumulated digest, there
leaves a chance for the attacker to "fix" the TPM digest by generating
additional measurement items. Without the ability to verify each and
every individual measurement item verifier could produce a false
negative result.
The quote uses SHA-256 or better, which the attacker cannot fix. In #1,
the SHA-1 hash is for debug, not for security.
----------
2. Include template hashes for all PCR banks.
A. This breaks existing applications on the attestor side, but could
be made backward compatible / deprecated at the verifier side.
B. The redundant data is an attack surface, in that the verifier must
remember to check the hashes against the quote AND against the
template data.
C. The digest provides debug usefulness against malicious attacks on
the template data.
D. This permits the use case where the template hash is NOT a hash of
the template data. In the UEFI event log (using IMA terms), the
template hash can be a digest of some other data and the template data
is a hint as to where and what that data is.
E.g., the UEFI event EV_CPU_MICROCODE template data field has a patch
descriptor, while the template hash is a digest of the patch itself.
As of now, IMA stores template hash with it's measurement item in the
memory, and storing digest value from all banks would make the digest
list N times bigger, where N would be an increasing number of supported
algorithms by TPM.
N is not the number of supported algorithms. It's the number of
allocated PCR banks.
E.g., a typical TPM might support SHA-1, 256, 384, but only allocate
SHA-256 and SHA-384. The IMA log would hold those two.
In addition, while the digest list may be N times bigger, the record is
not, because most of the record is the template name, template data, ...
----------
3. Include a template hash for the strongest hash algorithm.
A. It's not always clear what the strongest algorithm is.
Otherwise, this is the same as #2.
"strongest" algorithm does not exist. I think it would be better to find
a extensible solution allowing for future upgrade.
Sometimes yes (SHA-256 vs. SHA-384). I agree that A. is the drawback of
#3. I voted for #2.
