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

[Henk Birkholz <[e-mail]>]

Hi Dionna,

before starting to phrase more detailed replies (and I will come back to 
that!), I'd like to start with a few clarifying question about your 
goals, if you allow me, in-line below.


Viele Grüße,

Henk

On 12.01.24 00:31, Dionna Amalie Glaze wrote:
> On Tue, Jan 9, 2024 at 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.
>>
> 
> They are certainly more on the software side of things, but I wouldn't
> suggest that an in-toto attestation couldn't be a carrier of evidence.
> * We could define a predicate that both reflects a TEE attestation
> report's fields and includes the TEE attestation report from the
> device for verification, and its verifier extension would not accept
> the predicate if it's not properly signed by the manufacturer.
> * We can define a "fully-double-check SLSA" predicate that will both
> test that the provenance is properly signed but also test that the
> input sources and toolchain container build binaries with the same
> digest. This is evidence for build transparency of measured artifacts
> in an attested environment, which can then be translated to accepted
> claims about provenance that are stronger than unchecked endorsements.
> As a middle ground, you might require that a signed build attestation
> has a non-repudiation proof with a code transparency service that the
> verifier must query to accept the build attestation. I'm not sure we
> have agreement on what counts as evidence for a claim.

1.) When you write TEE attestation report, are you referring to Evidence 
consumed by Verifiers or to Attestation Results consumed by Relying Parties?

2.) What I now think you are saying is that you would like to increase 
the assurances ("trustworthiness") of toolchain activities, including 
authenticity and accountability of toolchain components. SLSA today 
provides a way to document toolchain behavior. You would like to enrich 
that assertion set with RATS Attestation Results, so you can show that 
the assertions about the toolchain are trustworthy because the toolchain 
was composed exactly as it was intended to be and did what it was 
intended to do and nothing else?

3.) You would like to explore the possibility, if the assertion formats 
used by SLSA (in-toto attestations) can not only convey the assertions 
about the toolchain and its activities, but also not only convey (as, 
e.g., by including an EAT) but natively express (and I am uncertain 
here!) remote attestation Evidence if the toolchain environment can also 
takes on the role of an Attester?

4.) As toolchains are potentially running in CVMs, corresponding 
Verifiers must also assess the confidentiality capabilities of the 
Attester and express them in the Attestation Result (see, for exmaple, 
https://www.ietf.org/archive/id/draft-ietf-rats-ar4si-05.html#name-specific-claims)

> 
>> 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.
> 
> A predefined set of predicates does indeed sound to me like what CoRIM
> is, and it's why I think the extensibility model is clunky. If you
> were to make it cleanly extensible such that a profile has full
> control over its evidence schema, then your differences from in-toto
> would be JSON vs CBOR.
> 
> I like the idea of different platform providers coming together than
> trying to fit into a similar representation to simplify verification,
> but I don't like the resulting abstraction to be what every platform
> provider henceforth needs to find a way to model themselves on top of.
> I think we'd be telling a different story about reference values and
> measurement-values-map if there were a standard evidence format that
> RVPs and manufacturers alike would target. Right now though, there is
> an implicit "turn the blob of evidence into a form that fits all these
> triple record types".
> What is really abstractable into the same type such that the
> underlying technology doesn't actually matter?
> 
> I think we have the document's validity time range (which could be
> modeled in the signing key's certificate expiration) and security
> version numbers, but the rest is extra that I don't really get.
> Why is there a SWID used in the document when it's meant to be
> describing evidence and endorsements as claims, when SWID is purely
> metadata? Isn't this kind of thing more related to supply chain
> integrity in the SCITT workstream?
> 
> For another example of overgeneralization, an environment-map has the
> class, instance, and group fields. Class limits to some amount of
> detail, but no it could be a class-id that's arbitrary bytes. Instance
> can also be arbitrary bytes. Group also arbitrary bytes. They have
> been expanded so much to fit a few use cases that they no longer carry
> meaning.
> I think there's value in understanding how to translate a concise
> binary object into something more human-readable, which the initial
> fields attempted to do. There's value in not needing a pretty printer
> for every profile, but I think that maybe schemas should be more
> shareable and reusable without creating a fragile base class [1].
> Indeed you can have URLs to cddls that name some type(s) that you then
> include in the cddl of your profile for the names to get printed
> nicely.
> 
> There are multiple types nested inside a corim that have extension
> points that are subject to interpretation by a profile, and some types
> are closed with some number of alternates while others are open with
> some initial alternates.
> A profile could extend or restrict those alternates, so I don't really
> see why every profile would need to paste itself on top of the
> existing identity types and triples.
> 
> Profiles can then be schemas (again like in-toto) that have their own
> interpretation for translating evidence into claims. The "own
> interpretation" how CoRIM is currently defines profiles anyway: "A
> profile allows the base CoRIM schema to be customised to fit a
> specific Attester."
> 
> I think that a lot of the definitions described so far have been
> abstractions to fit a small number of use cases (DICE, ARM CCA's PSA,
> TPM), and I think that the types defined in CoRIM can perhaps be
> reusable in their profiles, but I don't think that the heft of the
> CoRIM document is serving itself.
> 
> The description of conditional triples and conditional series triples
> and multiple environment conditional triples... it feels very much
> like an awkward virtual machine to program with a verification policy.
> There's a whole expression language that Intel defined in their
> profile for CoRIM draft. I don't know where reference value ends and
> policy description (allegedly out of scope for CoRIM) begins.
> 
> [1] https://en.wikipedia.org/wiki/Fragile_base_class
> 
>>
>> 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
>>>
>>>
>>>
> 
> 
>