Re: [RFC] IMA Log Snapshotting Design Proposal - unseal

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

 





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

_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux