Discuss the overlap and comparison with IETF's RATS framework

[deeglaze]

Hi folks, I work on confidential VMs and am trying to get an internally built binary that we run in production to have a fully transparent verifiable remote attestation that matches binary digest all the way back to a public source repository at some commit hash. That's what I really like about in-toto and SLSA.

What I'm trying to understand is how to integrate the software attestation of in-toto with a whole target environment the way that the Internet Engineering Task Force (IETF) Remote ATtestation procedureS (RATS) framework is seeking to do. Where RATS refers to integrity manifests with Reference Values and Endorsements, I see a lot of connections to in-toto and opportunities for in-toto's richness to improve the attestation framework as a bit of combination of all that. Furthermore claims in an entity attestation token (EAT) appear to be synonymous with in-toto's notion of a predicate. The difference is really the IANA number assignment to claims, whereas in-toto has claims defined by URI to the schema.

RATS synthesizes multiple software integrity manifests and hardware integrity manifests with a trusted policy evaluator that issues attestation tokens (EATs). working group for "reference integrity manifests" called CoRIM https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-03 is seeking to do.

It seems that where CoRIM has tags for software identity that go so far as file digests and version number claims, in-toto's SLSA predicate has more fine-grained evidence that links Reference Values to software identities where software identity isn't a name and version but the culmination of all of the code, how the code is produced and securely stored and built.

Do you see this standard merging with RATS's favored formats of EAT (JWT or CWT) and CoRIM, or existing separately as an alternative carrier format within the RATS framework?

[JustinCappos]

This is just my two cents, but I would see this as fitting better as an alternative carrier format. We'd love for in-toto attestations to be used everywhere (RATS included!), but at least in my mind there are some security concerns with parsing those more complex formats which we'd like to avoid.

I'm curious to hear what others who are closer to the problem have to say about this question though...

[deeglaze]

Is it the parsing of CBOR or the interpretation of profiles that you're more concerned about? The notion of profile and predicate are indeed underspecified and I'm poking the WG about their meaning.

[deeglaze]

Coming back to this question, since I'm starting to see a bigger picture emerge. The CoRIM format can be seen as a few things that relate to in-toto in that it has some pre-defined predicates, but RATS also has the notion of an attestation result that can carry along "claims", commonly in a JWT. The in-toto verifier's output is Optional instead of Either<Set, Error>, so I think that there is a disconnect.

In some sense a hardware attestation verifier that cross-checks against an incoming (say, firmware provenance) attestation can produce its own "attestation result" (In RATS parlance) as its own in-toto predicate, but that wraps a signed result in another signed envelope, which is a bit strange. There is also the matter of this many-to-one interpretation process that would need to be specified in a manner as CoRIM is trying to do with its "Accepted Claims Set" modeling, though I'm currently skeptical of the semantics.

I don't see in goals vs non-goals any statement about comparing attestations with evidence, i.e., the current in-toto attestations are all in some sense signed reference measurements, but there is no double-checking with a boot/workload attestation to compare for remote attestation purposes.

I guess what I'm getting at is I see in-toto only as partially able to be a carrier format for reference values in that there is no specification for extracting claims from a verified predicate. I suppose you can extend the meaning of the predicate name to the transformation process to claims, but that is a big change in expectations for implementors.

[JustinCappos]

I don't see in goals vs non-goals any statement about comparing attestations with evidence

I think this is largely an artifact of how we scoped the original in-toto academic paper. At that time, all of this was new and unknown to people, so to scope this we focused on instead providing some measure to do things like link steps of a supply chain together.

We have been (and always were) quite aware of this problem, which is why we mention it in a lot of the documentation, and in the paper (if I recall correctly). If you look for the phrase "byproduct", we used this early in the project's lifetime, but later moved on to just say these are types of attestations. However, since we took the security analysis from the paper to make our threat model, it's not prominent because our academic paper wasn't scoped to solve that problem.

This whole issue is a reminder that we probably need to refresh the threat model especially after all of the ITE work we've done to address topics not in the original paper.

(I'm leaving the rest of your comment to others to answer. I didn't really understand your last few statements on the issue.)

[marcelamelara]

I don't see in goals vs non-goals any statement about comparing attestations with evidence, i.e., the current in-toto attestations are all in some sense signed reference measurements, but there is no double-checking with a boot/workload attestation to compare for remote attestation purposes.

Have you looked at the SCAI predicate? This predicate, in particular is specifically designed to begin addressing some of these gaps by binding evidence to claims about software or hardware.

We have an example in the SCAI demos repo that covers a secure boot use case. And we have a verification flow demo that also checks evidence in one attestation/claim against other attestations. The demo doesn't show how evidence for hardware attestations is checked, but I'd imagine the flow would be quite similar.

[deeglaze]

@marcelamelara The evidence is not particularly scrutable to me is it's base64-encoded bytes, and the link to SCAI attribute report is broken https://github.com/in-toto/attestation/v1.0.1/main/spec/predicates/scai.md

I'm not sure how the attribute for hardware attestation can stand on its own when an important aspect is a nonce challenge. There's a runtime aspect to the running task. Let's say a container is running on TDX. You can request a quote for the instance and provide a 64 byte nonce challenge. That will return a signed (rooted to Intel) report about the measured state of the instance. That means the firmware in a field called MRTD (measurement register of the trust domain) and the rest of the boot chain with TPM PCRs translated to one of four runtime measurement registers TDX supports called RTMRs. Each measurement into the RTMRs are collected into a CC Event log that can be replayed to compare against the RTMR state in the quote.

With the combination of the TDX quote, CC event log, and potentially files the CC event log references that can be forwarded from the instance (e.g., the firmware build attestation in a UEFI variable referenced by the SP 800-155 unmeasured event, and possibly signed build attestations for individually measured pieces of the CC event log), you can end up with many things to check about the container against this quote. Again the quote is protected from replay attacks through the challenge nonce.

I could see for example a daemon in the container image that can respond to requests for attestation challenges and provides all this to an attestation verifier in the form of an SCAI predicate that includes the nonce as an attribute.. is that what you envision, too?