Different key pair for PCR signing vs FMC Alias

[varuns-nvidia]

HW PCR signing (key slot 7) currently uses the same private key as FMC Alias. This poses problems:

• The FMC Alias Certificate indicates the key is a Certificate Authority, so it cannot be used for signing anything other than certificates per X.509
• Best practices: the keys are used for two different commands (Quote() vs Runtime FW update) so the attack surface on the key in terms of side channel exposure is the union of the two commands
• The signed payloads are different so there is exposure to substitution attacks

To mitigate, recommending that either ROM or FMC generate a new key pair for HW PCR signing. The public key could be exposed as a certificate or as TCI evidence for the Caliptra Runtime.

@Bryankel @vsonims @bluegate010 @JohnTraverAmd @jhand2 for comment.

[FerralCoder]

If you want to make sure that PCR signing is truly a hardware function and cannot be affected by rogue/buggy/hacked FW, then the key should be created and locked by ROM.

[JohnTraverAmd]

Question about the requirements:

1. Would it be required that this public key be static from boot to boot or could this be generated each boot? I'd prefer that this is fully random each boot if the infrastructure could handle that.
2. How would the Verifiers know they could trust this Public Key? How is it tied back to the cert chain?

[jhand2]

For 2, I would recommend endorsing with LDevID

If we do that, I don't think there's benefit in making the signing key random on each boot. I don't have any specific objections, just don't think any security value is gained.