Re: [lamps] Side meeting on PKIX key attestation format

[Michael StJohns <[e-mail]>]

On 4/8/2023 5:28 PM, Michael Richardson wrote:
> Michael StJohns <[e-mail]> wrote:
> ...
>      > I'm going to answer that two different ways - indulge me please.
>
> :-)
> What an amazing way with words.
> You put your name in for 2024 presidential race yet?
Never going to happen.  Or "The physics of pigs flying is sufficiently 
deterministic in a negative sense to suggest the answer to that question."
>
>      > 2) In this particular set of questions, the CA/BF has explicitly
>      > disclaimed the use of a TPM attestation statement as proof of a Code
>      > signing keys residence on a secure module, and has put in some
>      > interesting requirements for issuing a code signing certificate.
>
> is this fundamentally why we have to do this side meeting?

My personal take is that we've got an elephant and at least three blind 
men trying to describe it.   Mike O has an immediate (Real Soon Now) 
need for a way to carry an HSM attestation statement in a PKCS10 (or 
similar) ASN.1 based request - 
https://datatracker.ietf.org/doc/draft-ounsworth-pkix-key-attestation/. 
Since neither the HSM attestation format nor the general scheme for 
carrying attestation statements in PKCS10 has yet been defined, that 
showed up as a single document.  That document in turn collides a bit 
with 
https://datatracker.ietf.org/doc/draft-ietf-lamps-key-attestation-ext/ 
which appears to me to be targeted at carrying attestation statements 
wrapped in a semi-opaque Webauthn format for the Webauthn community.  
Neither of these approaches currently appears to me to provide a good 
answer to Task A.  Russ suggested we discuss.

I think that last sentence is probably the "have to" part of the above!


>
> My interest stems from
> https://datatracker.ietf.org/doc/draft-irtf-t2trg-taxonomy-manufacturer-anchors/

I didn't have time to look at this very long, but I did a quick scan 
over Section 3.  Mostly what you have here is how to prove things to a 
device (software, other devices, the back office, etc - onboarding 
mostly).  One of the things you appear to be missing is a 
uni-directional device proving to the word "Hi, I'm an MCU of type X 
from manufacturer Y, and here's a public key that you can use to verify 
cryptographic statements I make about my capabilities".  TPMs call that 
an Endorsement Key/Endorsement certificate for the built in key, and 
that can be used to bootstrap into an Attestation Key/Certificate that 
may be more local in nature and shorter in time scope.  The trust anchor 
for that is a manufacturer public key and/or certificate, chaining to 
the device EK certificate.  The root of trust for the Attestation 
Certificate need not chain back to the device manufacturer's EK root.

That model may not exactly equal the IDevID you mention in section 4.

Think of it this way:   During board manufacturing, I want to know that 
the secure part/MCU/etc is the part I ordered and will behave as I want, 
and I want to be able to link later credentials to the original hardware 
attestation.  During board manufacturing, I'll ask the MCU to generate a 
key pair, and then prove that the public key of that key pair is 
internal to the MCU using MCU credentials.  I'll bind that key pair into 
a IDevID based on my OEM manufacturing credentials.  When it gets to the 
field, the owner will look at my OEM IDevID, and use the MCU attestation 
functions to generate an LDevID key pair, use MCU to attest that key 
pair perhaps using the contents of the IDevID as the attestation key - 
using a combination of the various previous roots of trust.

Finally, in a device that has a multi-tenant model, I may need to 
bootstrap a tenant's key pair attestation as part of the administration 
of the device.  That brings us up to the possibility of 4 roots of trust 
for attested keys.

Enjoy - Mike

>
> I think that there will be a lot more HSM in the field.
> (That's a good thing)
ps - actually I'm hoping for less big-iron HSMs and more SEs (Secure 
Elements), smart card based HSMs, or MCU/MPUs with embedded SE IP cells.