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

[Tomas Gustavsson <[e-mail]>]

Hi,

On 2020-06-28 22:51, Michael Richardson wrote:
> 
> 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)

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.
> 
> 
> 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?

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: 
> 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    [
> 
> 
> 
>