[RFC] IMA Log Snapshotting Design Proposal - unseal
Ken Goldman
kgold at linux.ibm.com
Wed Sep 6 20:13:04 UTC 2023
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.
More information about the Linux-security-module-archive
mailing list