authorized-by: change type to [ + $authorized-by-type-choice ]

[deeglaze]

Hey y'all, I discussed this in the Veraison meeting, but I'll make it an issue here.

First off, let's not change anything yet, just add a code point.

$authorized-by-type-choice /= $crypto-key-type-choice

The reason I'm asking for this change is for the Qemu OVMF profile for SEV-SNP to model composite authorizers. The SEV_HASH_TABLE in OVMF allows for different initial measurements of the boot chain to get locked into the initial launch measurement. The firmware itself that allocates space for this table can be created by a different entity. This effectively squashes multiple events with individual authorizers into a single event that is captured by the hardware attestation report's launch measurement.

If the profile has the ability to represent a composite authorized-by representation, then we can compose disparate claims about the components of the initial measurement into a profile-defined X+Y+Z = Reference-value operation that means the reference value is authorized by all of X, Y, and Z's endorsers.

[nedmsmith]

What are the X, Y, and Z objects?

[deeglaze]

X, Y, and Z are all CoRIMs with different signers, but all for the OVMF-for-SEV-SNP profile. They each have reference values for different components of the OVMF measurement and SEV hashes. Say X has the ovmf.fd measurement and GUID table data that's needed to interpret the other components of the measurement, Y has the SEV_KERNEL_HASH, SEV_CMDLINE_HASH and Z has the BSP and AP VMSAs.

The combination of all of them reconstructs the MEASUREMENT field of the attestation because the different memory sections described by the OvmfSevMetadata section and SEV-ES Reset Block all change how the measurement is constructed.

[nedmsmith]

just add a code point. $authorized-by-type-choice /= $crypto-key-type-choice

I'm confused by this as AFIK there isn't an $authorized-by-type-choice in the schema that can be extended. The current authorized-by measurement is already a $crypto-key-type-choice.

[deeglaze]

Crypto key type choice is used other places that a composite authorization wouldn’t make sense, which is why I suggested a new code point

[nedmsmith]

If the X entity wants to recognize Y and Z as peer (equivalent) authorities for the X claims, it can include an authorized-by statement in measurement-values-map that includes $crypto-key-type-choice for Y and Z. Each of X and Y entities do the same for (X, Z) and (X, Y) respectively.

Verifier will produce ACS entries for each RIM's triples resulting in three ACS entries:
X claims with authority (X, Y, Z) - since X signed the rim and added authorized-by of (Y, Z).
Y claims with authority (X, Y, Z) - since Y signed the rim and added authorized-by of (X, Z).
Z claims with authority (X, Y, Z) - since Z signed the rim and added authorized-by of (X, Y).

This use case seems solvable using the current schema.
I don't see why the transitivity of $authorizied-by-type-choice /= $crypto-key-type-choice /= tagged-... (pick the best representation) is different from $crypto-key-type-choice /= tagged-... except that $authorizied-by-type-choice can be extended to some other form for authority.

But it seems the use case can be implemented with current schema, so I'm not seeing why the extensibility variation using $authorized-by-type-choice is needed aside from stylistic preference (which I kind of like personally).

[deeglaze]

The beginning assumption

If the X entity wants to recognize Y and Z as peer (equivalent) authorities for the X claims

We (Google) don't.

There is a single piece of evidence that can be authorized, and that evidence is a collection of parties' reference values for inputs to a specified reference value computation function. That function is defined by a profile that specifies a complex image construction operation. We're effectively squashing multiple EventLog entries into one before the initial measurement.

Google provides a firmware image and only wants to claim authority for that artifact. Canonical provides a kernel binary and only wants to claim authority for that artifact. Service operator Z provides the kernel commandline and only wants to claim authority for that artifact. The relying party includes Google, Canonical, and Z in their trust anchor to approve attestation results that include this profile's composite measurement authorization.

[nedmsmith]

Let me try to model the use case to see if I understand it. Evidence is a combination of 3 artifacts G.a1, C.a2, and Z.a3 which is asserted by the Attester: [G.a1, C.a2, Z.a3] : Attester_key

Google creates a manifest containing the G.a1 as a reference value: [G.a1] : Google_key.
Canonical creates a manifest containing the C.a2 as a reference value: [C.a2] : Canonical_key.
Z creates a manifest containing the Z.a3 as a reference value: [Z.a3] : Z_key.

These result in entries in an ACS as:

EV : [combined.a0] : A_key
RV : [G.a1] : G_key
RV : [C.a2] : C_key
RV : [Z.a3] : Z_key

The Relying Party has a policy that says the a1 artifact should be asserted by Google, the a2 artifact asserted by Canonical and the a3 artifact asserted by Z.

Since the three RV entries in ACS are present, the policy can be met.

[deeglaze]

Apart from [G.a1, C.a2, Z.a3] appearing split out, yes. All the values of those three components are combined through an OVMF and SEV-SNP-specific computation that results in a single digest that is present as evidence in the AMD-signed attestation report. It's the AMD measurement that is evidence, so it's the only element that would get an authorized-by entry for the combined RVs.

[nedmsmith]

All the values of those three components are combined

I updated my example to better represent the use case. Instead of evidence being three digests (a1, a2, a3) it is a combined digest a0.

The interesting condition may be that neither G, C, or Z are the providers of the RV for a0. Instead, the Verifier needs to know to compute the combined digest - i.e. f-hash(a1, a2, a3) = a0 - is this a more accurate representation of the use case?

[deeglaze]

Yes

[nedmsmith]

There's two options for collecting a0 as a reference value. Either the vendor that implements the algorithm that produces a0 needs to validate that given inputs a1, a2, and a3; a0 is indeed the output. Or the vendor that combined a1, a2, and a3 into a product can generate a0 using the algorithm implemented by the attester vendor.

Is there a reason either of these two options are unworkable?

The alternative is a standard has to define an algorithm for combining a1 - a3. This seems like a slippery slope.

[deeglaze]

Neither of those are workable. The a0 here is AMD SEV-SNP's measurement, and the VM operator that can populate a2 and a3 cannot get a1 ahead of time from us to sign the combination.

AMD's design for SEV-SNP pushed the problem of runtime measurements down the road too far and we've ended up with a feature that might not die for a while that mixes multiple artifacts into one measurement. I don't think many would follow down this slippery slope given the difficulty to even determine a1, a2, and a3 ahead of time to even derive a0.

[andrew-draper]

This seems similar to a case I've been thinking about, which is how to handle evidence which comes into the verifier as a PCR value plus an event log in a generalized way.

My thoughts were that the Evidence Collection phase should use the PCR value to verify that the event log is correct, and then add the event log measurements to the Accepted Claims Set as individual measurements. The environment-map for each measurement would be set to something which represents what is being measured.

The CoRIM can then use the standard matching rules to match against the individual measurements it cares about.

I think the Evidence Collection phase would also need to include a measurement which describes the order of measurements in the log, without this it might be possible for an attacker to add fake measurements to the PCR after the real measurements.

Dionne, could something like this help with your use case?

[deeglaze]

What is to be done with the hardware attestation report, then? It doesn't seem appropriate for a virtual firmware profile to override the profile for the measuring technology. When you interpret the evidence of a hardware attestation report, you get the measurement as an accepted claim, which that needs to be (collectively) authorized. Now every use of SEV-SNP that has multiple entities represented in the measurement need to specify that their profile should be used instead of AMD's for interpreting the hardware attestation report. Admittedly they could say, "we use AMD's profile for everything except we don't admit the sevsnpvm-measurement as an accepted claim.

The SEV-SNP attestation report measurement must be computed from "ovmf-sevsnp-base-measurement, ovmf-seves-rip, ovmf-seves-csbase" as the baseline from the OVMF binary provider, then "ovmf-sevhash-kernel, ovmf-sevhash-cmdline, ovmf-sevhash-initrd" from the VM operator, then "ovmf-seves-bspvmsa, ovmf-seves-apvmsa" (with the seves-rip and seves-csbase plugged in appropriately) from the VMM operator.

I suppose for this use case I could live with this awkward this, though I wonder how to collect all these values as evidence in the first place. Maybe /sys/firmware/qemu_fw_cfg, but that would need additional changes to qemu.