[RFC] IMA Log Snapshotting Design Proposal - unseal

[Ken Goldman]

On 9/1/2023 5:22 PM, Tushar Sugandhi wrote:
> 
> 
> On 8/30/23 12:12, Ken Goldman wrote:
>> On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
>>
>>> For remote attestation to work, the service will need to know how to
>>>  validate the snapshot_aggregate entry in the IMA log.  It will have
>>> to read the PCR values present in the template data of
>>> snapshot_aggregate event in the latest IMA log, and ensure that the
>>> PCR quotes align with the contents of the past UM_snapshot_file(s).
>>> This will re-establish the chain of trust needed for the device to
>>> pass remote attestation.  This will also maintain the ability of the
>>> remote-attestation-service to seal the secrets, if the client-server
>>>  use TPM unseal mechanism to attest the state of the device.
>>
>> I think that seal/unseal to IMA PCRs is futile.  Since boot is
>> multi-threaded, the IMA PCR is unpredictable even when valid.
> 
> True. But here we are talking about seal/unseal post boot when the
> device is in a stable state, and there are relatively less number of
> events extending IMA PCR. The value of the actual IMA PCR doesn't matter
> in this context as long as it stays the same between seal-unseal window.

Does 'relatively less number of events' really matter?  Even if there 
are only two, if the order is unpredictable, unseal fails.

> 
> If it changes between that window, the clients typically retry by
> sending the request to the service with a new stable PCR.

Does a retry help? Once the PCR has been extended to the wrong value, it 
can never get back to the correct value without a reboot.

> 
> Seal-unseal is supported by TPM spec, and is used widely. So we had to
> ensure that our proposed design wouldn't regress this existing
> functionality.

It works in the pre-OS environment, where the firmware specification 
mandates that the PCR values are repeatable. Once you're post-OS, 
multi-threaded, an unseal that includes PCR 10 is infeasible.