Re: [Rats] [CoRIM] The use case for TDX- and SEV-SNP-measured virtual firmware

[Tom Jones <[e-mail]>]

This is the part that sounds like a hand wave

its job right, such that you can take the chip's signature of a
virtual instance's boot state at face value, so long as the key
certificate roots back to the manufacturer's published root of trust.

I am the guy that gets this attestation and needs to make the trust
decisions. How do I know what that means when I make the trust decision. I
hope that you are not going tell me to read some policy statement

At least in tls we have the CA!B for a min set of policies.

BTW I was the guy at Intel trying to build the very first of these back in
1996 so I understand the problem.

thx ..Tom (mobile)

On Tue, Jan 9, 2024, 1:06 PM Henk Birkholz <[e-mail]>
wrote:

> Hi Dionna,
>
> thank you for bringing the CVM goals here! I think they are a great
> addition to the mix. Let's try to figure out some answers to your
> questions step by step.
>
> You are touching on a lot of topics, so I am focusing on adding context
> to the RATS side of things first and in the interest of the list's
> subscribers only point quickly to one recent SCITT activity up front:
>
> > https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/156
>
> Pending the approval of that PR, the initial attempt to facilitate DIDs
> as a first citizen identifier is a thing of the past.
>
>
> So, RATS: please let me try to add some additional context about in-toto
> attestations in the context of RATS & CoRIM to start with, in the way
> how I currently understand it.
>
> The attestations you refer to are described here, I think:
>
> > https://github.com/in-toto/attestation/tree/main/spec/v1
>
> In remote attestation land, the concept that can be found at that
> pointer is potentially best compared with a RATS Endorsement or NIST's
> 3rd-Party Attestation and maybe also NIST's 1st-Party Attestation (a
> "self-attestation"), I think. It seems not to be RATS Evidence, I think,
> which is the input to a RATS Verifier, and I am happy to exchange more
> thoughts about that.
>
> in-toto attestations' outer layer are in-toto Envelopes with a JSON
> encoding, which are signed using DSSE:
>
> > https://github.com/secure-systems-lab/dsse/blob/v1.0.0/envelope.md
>
> DSSE - Dead Simple Signing Envelope - is an alternative approach to
> JOSE's JWS. Some reasoning about why it is defined as it is can be found
> here:
>
> > https://github.com/secure-systems-lab/dsse/#why-not
>
> In CoRIM work, we are also defining semantics that could be viewed as a
> type of pre-defined set of predicates as defined by in-toto:
>
> > https://github.com/in-toto/attestation/tree/main/spec/predicates
>
> I am an under the impression (maybe wrongfully so!) that the
> similarities seem to end there.
>
> Two of CoRIM's goals - in a simplified nutshell - are compactness
> combined with standardized signing. The JSON encoding prescribed by
> in-toto seems to be going down a different path, but hypothetically it
> might be possible to transfer all semantics covered in CoRIM into
> in-toto predicates. The DSSE uses a signing scheme that seems to make
> some unique choices on flexibility and extensibility, of which I would
> be careful to assume that they can be simply adopted as is. I am happy
> to exchange more thoughts on these topics, too.
>
> We definitely agree on the goal to not overly burden Verifiers with
> respect to their duty of appraisal of Evidence. There is a lot more in
> your email, but I am stopping here for now so that we can work through
> your illustrated goals and corresponding questions iteratively, if that
> is okay for you.
>
>
> Viele Grüße,
>
> Henk
>
> p.s. I started the email off with your reply to Tom instead of your
> initial email. Sorry!
>
>
> On 09.01.24 20:34, Dionna Amalie Glaze wrote:
> > On Mon, Jan 8, 2024 at 5:15 PM Tom Jones <[e-mail]>
> wrote:
> >>
> >> I don't understand the process that would allow a 3rd party attestor to
> make any assertion about what happened in the Google cloud (or any other
> cloud for that matter.)  Does anyone else understand the basis for virtual
> instances being attested as secure?
> >
> > The process is by transferring trust to a third party attester that
> > you do trust, and ensuring that the attested environment is heavily
> > protected from host tampering. This is the idea behind Trusted
> > Execution Environments, and is a very different threat model than
> > folks typically work with.
> > For AMD SEV-SNP or Intel TDX, you have to trust that the chip is doing
> > its job right, such that you can take the chip's signature of a
> > virtual instance's boot state at face value, so long as the key
> > certificate roots back to the manufacturer's published root of trust.
> > What Google then certifies is what the measurement of the boot means,
> > since we're providing the firmware. At first this will just be "we
> > signed the measurement", but then we'll add claims like, "this
> > measurement is producible through documented means on a binary that
> > was built from sources X and toolchain container Y"
> >   and then you can go further down the rabbit hole of if you trust the
> > builder, or if X + Y have the difficult-to-attain property that a
> > clean rebuild yields exactly the same bits. You can audit the sources
> > to establish trust in the firmware, and you can continue the "who
> > built the toolchain container and do I trust them?" unfathomably long
> > chain of builders building builders.
> >
> >> ..tom
> >>
> >>
> >> On Mon, Jan 8, 2024 at 4:33 PM Dionna Amalie Glaze <dionnaglaze=
> [e-mail]> wrote:
> >>>
> >>> Hi y'all, I've touched on the issue of confidential VMs (CVMs) a few
> times in my issues and emails to this list, but I'd like to lay out exactly
> what we'd like to be able to enable with RATS.
> >>>
> >>> # Goals
> >>>
> >>> Our goal is for CVM hardware attestations of Google-provided TCB to be
> linked to
> >>> 1. verifiable authenticity: signed corim measurements
> >>> 2. auditable measurements: the signed measurement also points to a
> supply chain transparency report for the measured binary. A document or
> software package we publish shows how to calculate the measurement from the
> binary, and the transparency report binds the binary to an auditable source
> tree at commit X built with toolchain container Y, signed by an
> organizationally endorsed builder key that the build follows SLSA L3
> operational security requirements.
> >>>
> >>> and ephemeral claims, e.g.,
> >>> 3. vulnerability reporting: short-lived certificates of firmware
> status, like "has the most up to date security version number" or "is
> subject to CVE xyz. Restart your instance to get on the latest version".
> This could be modeled as a CoRIM endorsement of a claim like "uptodate as
> of TIMESTAMP".
> >>> 4. Platform security reporting: short-lived certificates of platform
> firmware status, like "you can be sure that an attestation's TCB is >= x
> anywhere in the fleet"
> >>>
> >>> # Supply chain standards
> >>>
> >>> There are further things you can do with the transparency report like
> non-repudiation through hosting the build attestation with a transparency
> service that has append-only logs after identity-proofing, but there seems
> to be a fundamental disagreement between the IETF SCITT workstream and the
> sigstore.dev project on how to achieve that, since SCITT wants W3C DID
> identities, and sigstore.dev is already built to use OIDC. I don't know
> how that all is supposed to be consonant with RATS, since there's nothing
> in the corim or eat documents about using DID for identities. There is EAT
> binding to OIDC tokens though. Is there anyone in the RATS group that is
> participating in the SCITT effort that can explain this to me?
> >>>
> >>> The SLSA provenance schema itself is defined in terms of a completely
> different attestation format called in-toto (https://in-toto.io), and
> communication I've had with them is that in-toto should be considered an
> alternative carrier format to CoRIM to fit into the RATS framework. If we
> want to link the reference measurement to an in-toto attestation, that
> seems like something verifier-specific that we'd need to say, "hey if you
> want to ensure the firmware measurement is not only signed, but built
> transparently, then download the SLSA attestation in dependent-rims. By the
> way if there's more than one thing in dependent-rims, you can understand
> any url with prefix X to be a firmware build attestation from Google" which
> is an unfortunate complexity.
> >>>
> >>> # Modeling CVM attestation
> >>>
> >>> I'm trying to understand how to fit all these goals into the RATS
> framework such that we can propose extensions to open source verifiers that
> aren't overly burdensome or highly specific to each particular package we
> want to provide reference values (and provenances) for.
> >>>
> >>> In terms of the firmware measurement, we can deliver a CoRIM through a
> UEFI variable pointed to by the NIST SP 800-155 unmeasured event, and we
> can give the AMD SEV-SNP VCEK certificate through extended guest request,
> but everything else seems to be up to the verifier to collect independently
> of the VM.
> >>>
> >>> ## Evidence collection
> >>>
> >>> The way we're collecting attestations at the moment is through a
> recommended software package https://github.com/google/go-tpms-tools that
> wraps up a vTPM quote with a TEE quote and supporting certificates as a
> protocol buffer. I'm not clear if this unsigned bundling process should be
> modeled as any particular thing in the RATS framework. I think we're
> working with the "passport model" of attestation.
> >>>
> >>> I don't have a sense of how the WG foresees how evidence should be
> bundled to give to a verifier. I'm working from a vendor-specific
> understanding at the moment that whatever verifier service you use, you
> need to use their format and API, but of course ideally I'd like this to be
> more of a federated arena where you can have n-of-k verifiers say some
> evidence matches policy, and the evidence is not too vendor-specific for
> that to be out of the question.
> >>>
> >>> ## CVM Profiles
> >>>
> >>> Whereas Google has an attestation verifier service that generates an
> EAT with its own claims bound to an OIDC token (for the Confidential Space
> product), we'd like to use more standard claims, like AMD SEV-SNP
> measurement, Intel TDX MRTD, etc. Azure's attestation service has their own
> x-ms-* extensions for this that will hopefully help AMD and Intel align on
> how claims should be proposed for the CoRIM format.
> >>>
> >>> Supposing we do get profiles from Intel and AMD for their CVM
> attesting environments (more below), those environments sign quotes /
> attestation reports that serve as evidence for the claims defined in those
> profiles.
> >>>
> >>> I as a Reference Value Provider want to be able to provide a document
> that says something that covers 1 and 2 up front like, "if your AMD
> measurement is contained in {x, ...} or your TDX measurement is contained
> in {y, ...}, then you're running Google-authentic virtual firmware with
> security version n. The firmware this measures can be found at z".
> >>>
> >>> My understanding of how to do this is for the firmware CoRIM to have a
> single CoMID tag and the SLSA provenance linked from dependent RIMs.
> >>> The CoMID tag will have lang: en-us, tag-identity: some-uuid we
> generate before signing, and triples-map containing some reference triples.
> >>> We have reference triples for both AMD and TDX by using different
> environment-maps with different class fields.
> >>> AMD SEV-SNP's class is up to AMD to profile, but let's just say it's a
> class-id for the VCEK extension oid prefix 1.3.6.1.4.1.3704.1.1. The
> measurement-map for this can have an mkey or not. If we had one, I'm unsure
> if it's something that Google would define or if it's still up to AMD. If
> Google, we could use a uuid that stands for Google Compute Engine?
> >>> The mval as a measurement-values-map would then contain our AMD
> firmware svn, and AMD profile-specific claims, but I think we'd just give
> the measurements and some form of acceptable policy specification. We just
> have one guest policy we apply everywhere, but if that changes we probably
> need the AMD profile to have expressions like ranges, lower- and
> upper-bounds for policy components.
> >>> For Intel, they'd need a similar profile for the TDREPORT components
> as claims.
> >>>
> >>> I say measurements and not measurement even though we're talkabout
> about a single firmware binary because both AMD and TDX can have multiple
> measurements based on the VM construction, such as how many vCPUs it
> launched with (AMD has VMSAs and Intel has TDVPS).
> >>> For now our security version number matches what we measure as
> EV_S_CRTM_VERSION in PCR0, but that may change if there are
> technology-specific changes.
> >>>
> >>> As far as I understand, the Intel profile for CoRIM only supports the
> boot chain up to the quoting enclave (QE) in terms of its TCB version, but
> the profile does not describe the QE as its own attesting environment for
> SGX enclave or TDX VM. The attesting key is generated in the QE and is
> signed by the PCE's hold on the PCK, which is per-machine-per-TCB (ppid +
> pceid). The quote wraps around the attesting key's signature for
> verification against their non-x.509 format.
> >>>
> >>> AMD similarly does not have a profile for the SNP firmware as an
> attesting environment for an SEV-SNP VM.
> >>>
> >>> # Evidence Appraisal
> >>>
> >>> Setting aside evidence formats, I want to really understand how we go
> from a signed CoRIM and a CVM attestation to an attestation result (which
> I'll handwave is some JWT representation of the accepted claims).
> >>>
> >>> We somehow get the VCEK or PCK certificate and attestation report /
> quote, and the Google firmware CoRIM to the verifier. The verifier can
> verify the evidence back to the manufacturer with this forwarded (or
> cached) collateral and introduce every quote/report field as claims of the
> target environment.
> >>> Let's say Google's code signing root key is in the trust anchor, so
> any CoRIM we sign is trusted.
> >>>
> >>> If I read the CoRIM document about matching reference values against
> evidence, the document starts talking about conditional endorsements
> instead, which are a different triple from reference-value-triples. We
> discussed a little in the Github issues that reference values are a special
> kind of endorsement, but it's still jarring. It goes on to say that
> reference-value-triples is essentially redundant with the
> conditional-endorsement-triples, but you can use either. Then there's "In
> the reference-triple-record these are encoded together. In other triples
> multiple Reference Values are represented more compactly by letting one
> environment-map apply to multiple measurement-maps."
> >>>
> >>> It seems "Conditional Endorsement" is philosophical, and
> "conditional-endorsement-triples" is one implementation of the idea, and
> "Reference Value" is philosophical, but "reference-value-triples" is one
> implementation of the idea. Another implementation of "Reference Value" as
> an mkey of a "conditional-endorsement-triples", and the mval is more
> explicit about what claims are introduced. For "reference-value-triples", I
> don't see any explicit representation of a claim, rather,
> reference-value-triples lead to "authorized-by" getting added to fields of
> an Accepted Claim Set entry which itself is only a conceptual type to help
> understand appraisal, but not an actual claim itself–is this where a
> profile-defined claim needs to clarify meaning? I see this authorized-by as
> conceptually different from the optional field of a measurement-map, since
> that is from the CoRIM that I've signed and isn't part of an attestation
> result representation.
> >>>
> >>> If I'm looking at a JWT with an AMD profile claim about the
> measurement value, I'd like another claim that the measurement value is
> signed by Google, or a stronger claim that the measurement value was signed
> by a trusted source, and the build provenance is [some google URL to the
> SLSA provenance].
> >>> Again though, if at all possible these claims should appeal more
> broadly than just Google.
> >>>
> >>> --
> >>> -Dionna Glaze, PhD (she/her)
> >>> _______________________________________________
> >>> RATS mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rats
> >
> >
> >
>