On Wed, Aug 30, 2023 at 03:12:39PM -0400, Ken Goldman wrote: Good morning, I hope the day is going well for everyone. > 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. Yes, unbiased observation calls into question the relevancy of the 2000-2002/Palladium model for TPM based integrity attestation, both from a hardware and software perspective. In addition to interference by standard scheduling artifacts, the notion of everything being SMP makes PCR invariancy a hopeless issue. In fact, our trust orchestrators demonstrate that the very act of modeling, ie computing file digests, causes an event ordering that will be different from subsequent invocations when the digest value is cached. A concept that should be of no surprise to anyone fluent in the writings of Heisenberg... :-) We discuss this at some length, along with our proposed solution, in the documentation that we provide with our TSEM LSM: https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@xxxxxxxxxxxx/T/#t TSEM is a superset of IMA, given that file checksums are just one of the components in the security state coefficients that our security modeling is based on, but the issue is the same. Having an invariant 'security state' value also simplifies the attestation processw, since the relying party only needs to evaluate a single signed value in order to verify that the workload has been consistent with its desired security model. It is also becoming increasingly apparent that advancing the art of integrity and trusted systems will become problematic without the ability to 'namespace' or partition integrity on a workload by workload basis. We also introduce support for that with our security modeling namespaces. I missed copying the LSM list on my reply, but I discussed some of the challenges that TDX, and COCO in general, raises to current integrity infrastructures in the following thread, which should be easily locatable on the LKML or COCO lists: tsm: Introduce a shared ABI for attestation reports Given our experiences, it is difficult to understand how the notion of 'legitimate' confidential computing is going to grow from 7 billion dollars to 55 billion dollars over the next five years without the concept of better 'trust orchestration'. Have a good remainder of the week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity
