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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023/8/19 7:17, Mimi Zohar wrote:
> On Fri, 2023-08-18 at 09:25 +0800, Guozihua (Scott) wrote:
>> On 2023/8/17 22:19, Mimi Zohar wrote:
>>> On Thu, 2023-08-17 at 14:13 +0800, GUO Zihua wrote:
> [...]
>  
>>> Other proposals have changed the hard coded hash algorithm and PCR
>>> value from SHA1 to SHA256.  Both that proposal and this will break
>>> existing userspace applications.
>>
>> This is the part I would like to "RFC" on, and thanks for the comment!
> 
> Another proposal included all of the enabled TPM bank digests.
Will this introduce some performance issue? I don't think we should be
calculating various hashes on the same thing again and again.

If we are feeding digests for all slots of the same PCR bank, we could
do a cut-down or padding on the banks we don't care, avoid unnecessary
hash operations.
> 
>> In deed this change should break userspace as well as all the existing
>> remote attestation implementation. It should be better to have a brand
>> new file for this.
> 
> True SHA1 is being phased out due to hash collisions.  Verifying the
> template data hash against the template data isn't necessary for the
> attestation server to verify a TPM quote against any of the enabled TPM
> banks.  The attestation server walks the measurement list calculating
> the bank specific template data hash.  Breaking existing applications
> is unreasonable.
> 
>>>
>>> Before we can introduce this sort of change, we would need to introduce
>>> an IMA measurement list version.  Perhaps its time to define an IMA
>>> security critical-dbata record, which would include this and other
>>> information.  The measurement list itself would need to include a
>>> version number.
>>>
>> I guess one of the easy way to do it is to make a
>> ascii_runtime_measurements_ng and binary_runtime_measurements_ng, which
>> contains a changed template supporting configurable template hash. What
>> do you think?
> 
> Defining additional pseudo filesystems would allow both the old and new
> measurement list formats to be enabled at the same time.
> 

-- 
Best
GUO Zihua




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux