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

[Dionna Amalie Glaze <[e-mail]>]

On Tue, Jan 9, 2024 at 3:31 PM Tom Jones <[e-mail]> wrote:
>
> 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.
>

CA/B and certificate transparency are certainly the kind of efforts
that build transparency efforts are trying to emulate. The SLSA
framework for securing build environments and certifying builds is a
step towards the "Baseline Requirements" for how, say, firmware
binaries are produced. If you trust that the builder has met these
requirements, you can make the logical jump that the binary artifacts
are a product of the sources that are pointed to by the signed SLSA
provenance document. You can make the trust decision based on your
personal trust in the sources and toolchain that produced the binary
whose measurement is in the hardware-rooted attestation report. If you
trust Google's SLSA attestations, you can add the SLSA root key to
your trust anchor. If you only trust the attestation if you have some
personal endorsement of the measurement, then that sounds like an
appraisal policy to require

What kind of extra controls do you want for specifying your trust decisions?

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

Thanks for fighting the good fight.

The Open Compute Project appears to be very similar to RATS in their
goals, but is starting simpler. They have hardware manufacturers
coming together to decide on a common evidence format, and they want
to avoid the need for offloading trust decisions to a verifier.
Instead of minting trust decisions behind an EAT, they essentially
would always pass around the whole CMW of the attestations of the
target environment. If that's more appealing to you, you can just
collapse the roles of relying party and verifier.

> 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
>> >
>> >
>> >



-- 
-Dionna Glaze, PhD (she/her)