Re: [RFC PATCH -next] ima: Make tpm hash configurable

[Ken Goldman <kgold@linux.ibm.com>]

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.