[RFC] IMA Log Snapshotting Design Proposal - unseal

[Tushar Sugandhi]

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.

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

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.

~Tushar