Subject: [Secdispatch] IDevID considerations document to secdispatch

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2020 11:51:46 -0400

Dear Secdispatch chairs and WG, (and various people in the BCC who are
encouraged to forward)

EXEC SUM:  https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/

While working on ANIMA's BRSKI enrollment system, and the associated
mechanisms that create the ACP, it became clear that there was possibly a
wealth of useful advice on operating the Manufacturer and Owner components
(the MASA and Registrar).  As these thoughts grew, it became clear that there
were many non-normative, non-wire-protocol level design considerations.
Two documents were originally created:
    a) draft-richardson-anima-masa-considerations
    b) draft-richardson-anima-registrar-considerations

Both situations involve operation of a certificate authority.
On the manufacturer side, this involves the Manufacturer Installed
Certificate, the IDevID.  There are multiple users of the IDevID and there
are many entities building a variety of trust models based upon having
that trust model.  For instance, the Kumari/Doyle Secure Device
Install/draft-ietf-opsawg-sdi-12 leverages built-in certificates as much as
BRSKI does.

Much of the RATS work requires some kind of known signing key to
be built-in, secured deep into a hardware or firmware TPM/enclave.
If you want to (asymmetrically) encrypt firmware for SUIT, you may need
keys built in too.  Many other protocols also depend upon keys to be deployed,
but can deal with having them deployed as part of configuration, but as we
all experienced, actually getting them deployed can be difficult.

As discussed at the RATS/SUIT/TEEP Hackathon, and later in a few WGs, there
seems to be three ways to deploy matching private-key/certificates. a)
generate key onboard, sign with EST/SCEP/CMP/magic<%>, b) generate keypair in
CA, deploy with EST/SCEP/JTAG/magic, c) simultaneously/deterministically
generate keypair from shared secret, deploy certificate via magic.
I don't have good names for these three methods, nor sufficient proof that
there isn't a reasonable fourth method.    One reason (among many) to have
names for these three methods is so that it is possible in Supply Chain
Security discussions to be able to easily state the inherent security vested
in the device, and to thus #include the risk/threat landscape of devices
(particularly MCUs) that are included in designs.

I believe that EST (RFC7030), SCEP (draft-gutmann-scep) and some lightweight
profile of CMP (such as is in LAMPS) are reasonable protocols for factory
time onboarding, but require very strict profiling to get right.  This makes
it IETF business.
I would want to have a champion for (a)/(b)/(c) X {EST,SCEP,CMP}., ideally
said champion would be describing active experience from a real factory.

As publically anchored enterprise (intermediate) CAs seem to be a thing of
the past, many have discussed how appropriate it might be for manufacturers
to use ACME to provision IDevIDs directly. {In fact, I have running code}

There are however many aspects of this effort which might reasonably be
considered outside of the IETF perview.  Fundamentally, these are PKIX
objects that are being provisioned, and it is at the IETF that potential
successors to PKIX (CoID, JWTs, etc.) are being developed.

One of the major difficulties I have experienced in trying to assemble this
document is that current methods are often buried in a Silicon
vendor/OEM-board vendor interaction fearing many NDAs. This is particularly
acute for method (c).  This makes it difficult to ascertain what level of
care has been taken with the sensitive symmetric keys, which results in a
difficulty to compare audit results across the industry.

In order to get better and wider review, as well as detailing the required
magic, I've split the MASA considerations document into two pieces.
One is BRSKI MASA RFC8366 voucher generation specific, which I intend to
leave in the ANIMA WG (should the chairs agree), and the other part which is
IDevID generation specific, which I am looking for advice from secdispatch to
determine what to do with it.

The second document is:
  https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/

and it is still rather drafty.

I will note that draft-richardson-anima-registrar-considerations also
discusses an Operator/Enterprise/Home-router having/operating a CA,
(among many other things), and I am undecided whether or not to extract
that advice and merge it into idevid-considerations.  At this point, I think
that it is not of general interest and it is better kept isolated.

<%> leveraging Clarke's third law, but possibly also 1st and 2nd law as well.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Jun 2020 13:52:55 -0400

Tomas Gustavsson <[email-masked]> wrote:
    > The notion of serialNumber in the document, for me, reads as it's not
    > clear what is the certificate serial number (9-19 bytes in your
    > document) and the device serial number. There don't have to be the
    > same. What I have seen commonly used is that the subjectDN field is
    > used to carry the device serial number, while the certificate serial
    > number is random, and only used to uniquely identify the certificate
    > in the PKI (issuer/serial).

Your assumption is entirely correct.  I wish that certificates hadn't used
"serial Number" in it's terminology, as it's really "certificate Identifier",
and we have learnt the hard way that it should not be sequential.

    > In such a case I would assume that the manufacturing execution system
    > (MES) and it's database controls the device serial number, while the
    > PKI controls the certificate serial number, and there does not have to
    > be any synchronization between these two.

Agreed.
Do I say something different here?  I would love to clarify things.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Jun 2020 16:51:27 -0400

Thank you again for reviewing the document!

I know that primekey is involved in creating Birth Certificates for many
product lines. (Your website's term, not mine, but a good one)

I wonder if you can comment on which of the three methods you support?
Do you have any suggestions on names for the three methods?
To me, just getting three good names is 90% of the value of this document.

Thinking about "birth" concept, I am trying to think if this helps with terms.
Invivo  <- self-generated private key, with enrollment.
Invitro <- private key generated in test-tub, deployed to device.

I also feel that I want to leverage the "digital twin" terminology a bit for
the third case.

I suspect that there might also be some hybrid/fourth case that uses
Threshold Modes in Elliptic Curves, draft-hallambaker-threshold-02
and while I think this would be an improvement on the security side of
things, I also am concerned that it may make the manufacturing process worse.

In particular, the self-generated (_invivo_) key suffers because the device
needs to do a write/read operation from the infrastructure.  That involves
the highest possible latency for interaction with the CA and therefore would
slow the assembly line the most.

The invitro and shared-secret methods allows the infrastructure to generate a
few keys in advance (and get them signed, assigning DN-serialNumber at the
same time), and then injecting that key via JTAG at the same time as the
firmware.  This overlaps the CA interaction with other steps.

Tomas Gustavsson <[email-masked]> wrote:
    > On 2020-06-11 19:52, Michael Richardson wrote:
    >>
    >>> The notion of serialNumber in the document, for me, reads as it's
    >>> not clear what is the certificate serial number (9-19 bytes in
    >>> your document) and the device serial number. There don't have to
    >>> be the same. What I have seen commonly used is that the subjectDN
    >>> field is used to carry the device serial number, while the
    >>> certificate serial number is random, and only used to uniquely
    >>> identify the certificate in the PKI (issuer/serial).
    >>
    >> Your assumption is entirely correct.  I wish that certificates
    >> hadn't used "serial Number" in it's terminology, as it's really
    >> "certificate Identifier", and we have learnt the hard way that it
    >> should not be sequential.
    >>
    >>> In such a case I would assume that the manufacturing execution
    >>> system (MES) and it's database controls the device serial number,
    >>> while the PKI controls the certificate serial number, and there
    >>> does not have to be any synchronization between these two.
    >>
    >> Agreed. Do I say something different here?  I would love to clarify
    >> things.

    > This section confused me at first read:
    > -----
    > In all cases the serialNumber embedded in the certificate must be
    > unique across all products produced by the manufacturer. This suggests
    > some amount of structure to the serialNumber, such that different
    > intermediate CAs do not need to coordinate when issuing certificates
    > -----

    > At first read I thought about certificate serial number, but now
    > realize it's the device serial number that is meant. I think that
    > section can be clarified somewhat.

okay, I will do that. I wish I had a good way to distinguish things.

"serialNumber" (in that case), is a used in RFC5280 as the field name of the
               "CertificateSerialNumber",
               I sure wish we could go back and change the name of the field
               to be "certificateIdentity"

The same document mentions "id-at-serialNumber" and X520SerialNumber!
And in section 4.1.2.4 (Issuer) and 4.1.2.6 (Subject), it uses the term
"serial number"... and the usual rendering in a DN is that it is "serialNumber"
(OID 2.5.4.5, I think it is)!

I will call it the "product DN-serialNumber". How does this strike you?

    > Some additional nitpicking...
    > I think this section is missing an 's'?

Do you mean the title? that it should be:
   ## Public Key infrastructure for IDevID
-> ## Public Key infrastructure for IDevIDs

    > -----
    > The intermediate CA will have a private key, likely kept online, which
    > is used to sign each generated IDevID. Once the IDevID are created,
    > the private key is no longer needed and can either be destroyed, or
    > taken offline.
    > -----

    > In the line preceding this section it talks about "some number of
    > IDevIDs". Then that the CAs private key can be destroyed after
    > generating that number if IDevIDs. Hence, just ad an s:

    > "Once the IDevID are created, the private key is no longer needed and
    > can either be destroyed, or taken offline."
    ->
    > "Once the IDevIDs are created, the private key is no longer needed and
    > can either be destroyed, or taken offline."

I think I found all the missing s, and one case where it should be CAs'
rather than CA's.

see commit/diff:
https://github.com/mcr/idevid-security-considerations/commit/84fa9fad74d9b2d950b061a4fa5bf3fe99443472?short_path=77f5cdf#diff-77f5cdfefb38aca78416645deaa3310e

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 29 Jun 2020 06:54:36 +0000

Richard

> needs to do a write/read operation from the infrastructure.  That involves the
> highest possible latency for interaction with the CA and therefore would slow
> the assembly line the most.

We make use of the key-pair generated on the fly on the device and do not see major delay on the manufacturing line due to CA communication.
Finally it is a question of how you arrange your manufacturing procedures. If you experience delay due to waiting for the certificate delivery, you can do other meaningful things in the meantime.

> firmware.  This overlaps the CA interaction with other steps.

Finally this method puts higher security burden on the manufacturing infrastructure to securely handle the pre-generated key pairs. This is why I do not like it, but sometimes it is needed.

-- Hendrik

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 29 Jun 2020 10:05:17 +0200

Hi,

On 2020-06-28 22:51, Michael Richardson wrote:
> I know that primekey is involved in creating Birth Certificates for
> many product lines. (Your website's term, not mine, but a good
> one)

It wasn't my (ours) terminology unfortunately :-). We found it
elsewhere. I don't remember where "birth" came from. 3GPP 33.310 have
the same concept, but calling Vendor certificate. I think birth
certificate is a little better, as it's more generic than specifying a
vendor relationship.

> I wonder if you can comment on which of the three methods you
> support? Do you have any suggestions on names for the three
> methods? To me, just getting three good names is 90% of the value
> of this document.

We support:
2.1.1.  On-device private key generation
Standard CSR-submitted-to-CA  process
2.1.2.  Off-device private key generation
Typically CA-generates-keystore process. Some protocols, i.e.
CMP/RFC4210 have standard support for encrypting the private key sent
back to the client

2.1.3.  Key setup based on 256-bit secret seed
We haven't seen this. Albeit, it's not so much related to the PKI
part, so it can still be supported/used if the certificate issuance is
done using a CSR process to the CA.

> Thinking about "birth" concept, I am trying to think if this helps
> with terms. Invivo  <- self-generated private key, with
> enrollment. Invitro <- private key generated in test-tub, deployed
> to device.

Good idea to have naming for these. I like the idea. I don't have any
immediate ideas. Are there any naming from TMP/SE vendors/standards
that can be re-used? (I'm not very familiar with those specs myself).

> I also feel that I want to leverage the "digital twin" terminology
> a bit for the third case.
> 
> I suspect that there might also be some hybrid/fourth case that
> uses Threshold Modes in Elliptic Curves,
> draft-hallambaker-threshold-02 and while I think this would be an
> improvement on the security side of things, I also am concerned
> that it may make the manufacturing process worse.
> 
> In particular, the self-generated (_invivo_) key suffers because
> the device needs to do a write/read operation from the
> infrastructure.  That involves the highest possible latency for
> interaction with the CA and therefore would slow the assembly line
> the most.
> 
> The invitro and shared-secret methods allows the infrastructure to
> generate a few keys in advance (and get them signed, assigning
> DN-serialNumber at the same time), and then injecting that key via
> JTAG at the same time as the firmware.  This overlaps the CA
> interaction with other steps.
> 
> 
>>>> The notion of serialNumber in the document, for me, reads as
>>>> it's not clear what is the certificate serial number (9-19
>>>> bytes in your document) and the device serial number. There
>>>> don't have to be the same. What I have seen commonly used is
>>>> that the subjectDN field is used to carry the device serial
>>>> number, while the certificate serial number is random, and
>>>> only used to uniquely identify the certificate in the PKI
>>>> (issuer/serial).
>>> 
>>> hadn't used "serial Number" in it's terminology, as it's
>>> really "certificate Identifier", and we have learnt the hard
>>> way that it should not be sequential.
>>> 
>>>> In such a case I would assume that the manufacturing
>>>> execution system (MES) and it's database controls the device
>>>> serial number, while the PKI controls the certificate serial
>>>> number, and there does not have to be any synchronization
>>>> between these two.
>>> 
>>> Agreed. Do I say something different here?  I would love to
>>> clarify things.
> 
>> This section confused me at first read: ----- In all cases the
>> serialNumber embedded in the certificate must be unique across
>> all products produced by the manufacturer. This suggests some
>> amount of structure to the serialNumber, such that different 
>> intermediate CAs do not need to coordinate when issuing
>> certificates -----
> 
>> realize it's the device serial number that is meant. I think
>> that section can be clarified somewhat.
> 
> "serialNumber" (in that case), is a used in RFC5280 as the field
> name of the "CertificateSerialNumber", I sure wish we could go back
> and change the name of the field to be "certificateIdentity"
> 
> The same document mentions "id-at-serialNumber" and
> X520SerialNumber! And in section 4.1.2.4 (Issuer) and 4.1.2.6
> (Subject), it uses the term "serial number"... and the usual
> rendering in a DN is that it is "serialNumber" (OID 2.5.4.5, I
> think it is)!
> 

For me that is crystal clear. Nice.

> 
>> Some additional nitpicking... I think this section is missing an
>> 's'?
> 
> Do you mean the title? that it should be: ## Public Key
> infrastructure for IDevID -> ## Public Key infrastructure for
> IDevIDs
> 
>> ----- The intermediate CA will have a private key, likely kept
>> online, which is used to sign each generated IDevID. Once the
>> IDevID are created, the private key is no longer needed and can
>> either be destroyed, or taken offline. -----
> 
>> In the line preceding this section it talks about "some number
>> of IDevIDs". Then that the CAs private key can be destroyed
>> after generating that number if IDevIDs. Hence, just ad an s:
> 
> 
> 
>> "Once the IDevID are created, the private key is no longer needed
>> and can either be destroyed, or taken offline."
> ->
>> "Once the IDevIDs are created, the private key is no longer
>> needed and can either be destroyed, or taken offline."
> 
> I think I found all the missing s, and one case where it should be
> CAs' rather than CA's.
> 
> see commit/diff: 
> -- ]               Never tell me the odds!                 | ipv6
> mesh networks [ ]   Michael Richardson, Sandelman Software Works
> |    IoT architect   [ ]     [email-masked]
> http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
>