How do signers work?

[laurencelundblade]

There is a signer field and a section on signers mentioning UEFI, X.509 and such, but there is no mention of any signing scheme or format. If there is to be a non-EAT signature on some measured components there has to be a signing data structure.

You can put signed CoSWIDs in EAT, so there is one way to have independently signed measurements, but the point of measured components is to not use CoSWID, right?

[thomas-fossati]

There is a signer field and a section on signers mentioning UEFI, X.509 and such, but there is no mention of any signing scheme or format. If there is to be a non-EAT signature on some measured components there has to be a signing data structure.

There are two separate signatures:

1. On the installed component. This is made by a vetted supply chain entity and verified during secure boot by the relevant cryptographic RoT - e.g., the key hierarchy rooted in the ROTPK (Arm's TBBR), or PK (UEFI).
2. On the measured component. This is made by the RTR that signs the (EAT) evidence - e.g., the IAK (Arm PSA), or CPAK (Arm CCA).

From the point of view of the latter, the specific signing scheme and format used by the former are irrelevant. The only important thing is to be able to somehow track the identity of the (installed component's) "signer" and report it to the verifier.

[laurencelundblade]

OK. It's making some sense again, but it is probably impossible to understand from the current text and/or without a large amount of context about UEFI or such. If this is to be interpreted in the UEFI context, then the text should probably say that in a strong way and provide the necessary references and such.

Let me ask this way. When Qualcomm designed the Brew app download system, we required each app be signed by the vendor/developer of the app. For example, we would require that Byte Dance sign the TikTok app. But then, Qualcomm who ran the App Store, would sign it again to indicate the developer and app had been vetted and was OK to run on commercial phones. The phone only checked for the second signature. The first signature was for protection and authentication while the app was being developed and approved. I think the "signer" here is like the Qualcomm signature. It's the entity that approves running on the device. It's not the vendor of the component. Is that right?

(Also, my knowledge of UEFI is limited...)

[thomas-fossati]

OK. It's making some sense again, but it is probably impossible to understand from the current text and/or without a large amount of context about UEFI or such. If this is to be interpreted in the UEFI context, then the text should probably say that in a strong way and provide the necessary references and such.

UEFI's secure boot is certainly a motivating use case (and so is Arm's TBBR), but the concept is more generic than those specific instances. In fact, your Brew example is yet another possibility, like any other "code signing" scheme.

Let me ask this way. When Qualcomm designed the Brew app download system, we required each app be signed by the vendor/developer of the app. For example, we would require that Byte Dance sign the TikTok app. But then, Qualcomm who ran the App Store, would sign it again to indicate the developer and app had been vetted and was OK to run on commercial phones. The phone only checked for the second signature. The first signature was for protection and authentication while the app was being developed and approved. I think the "signer" here is like the Qualcomm signature. It's the entity that approves running on the device. It's not the vendor of the component. Is that right?

It is right. However, if the original developer's signature was not removed (and could also be measured during boot), it could, in principle, be added to the signers array alongside Qualcomm's.

(Also, my knowledge of UEFI is limited...)

Whoever claims complete knowledge of UEFI is a liar :-)

[thomas-fossati]

What kind of explanatory text would you like to see in the "Signer" section?

[laurencelundblade]

I'll never tell a lie about UEFI. Other things...

Something like this for the text?

The signer field identifies the entity that gave permission to install and/or run the component. An example of this is the signer of secure boot components in UEFI or other secured boot schemes. It may also be the controlling entity in an app store. Typically the permission mechanism is by a signature that is evaluated by the boot ROM, OS or app launcher so the field is named "signer".

It is never the identity of the manufacturer of the component such as you would find in a manifest like a payload CoSWID.

This begs the question about what name space the signer comes from and how the recipient of a measured component knows what to do with the signer field. Maybe you just say that this is out of scope.