Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch

[Michael Richardson <[e-mail]>]

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 <[e-mail]> wrote:
    > On 2020-06-11 19:52, Michael Richardson wrote:
    >>
    >> Tomas Gustavsson <[e-mail]> 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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [