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

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 19:18:25 -0400

Brockhaus, Hendrik <[email-masked]> wrote:
    >> 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.

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

I hear this complaint as heresay, and I have yet to hear it directly from
someone who would know.  They always seem two or three layers of indirection
away.  I would be very happy to kill this issue as a non-issue.
I'm aware of a major VoIP phone supplier whose CA is on a different
continent, and it's not an issue.

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

yes, that's certainly true, but it also take some interactions among
different layers.

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

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

The -02 version of the document cites:
              "Factoring RSA keys from certified smart cards:
              Coppersmith in the wild", September 2013,
              <https://core.ac.uk/download/pdf/204886987.pdf>.

for a story of not-quite-random-enough issues!

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 19:31:40 -0400

Tomas Gustavsson <[email-masked]> wrote:
    > 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 do like the birth concept, and I am thinking if changing the document name to
include it would make sense.
Perhaps someone with expertise in attachment parenting can provide some
interesting words about how trust anchors are installed.

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

I have named this:
  a) _device-generated_ / _mechanically-transfered_
  b) _device-generated_ / _network-transfered_

I know that you are blown away by my imagination here.
Perhaps someone can feed this through a mechanical translator, run it
English->German->Mandarin->Swahili->English, and see what comes back.

I think that it's useful for the entity that needs to examine the risk for
the process to distinguish the two transfer methods.

    > 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

I have named this:
   a) _factory-generated_ / _mechanically-transfered_
      Like a serial console connection, or a JTAG flash writer.

for b) _factory-generated_/ _network-transfered_

yes, but what key would you use? :-)
The device has nothing....
So I think that it really has to always be used in the factory with a
physically secure network connection.

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

I have named this: device/factory-co-generated

I had not seen this either.
Laurence Lundblade, formerly of Qualcomm says that it's a thing.
While the interface to the CA could still be via CSR, the CSR is generated
by the OEM, possibly not in the factory at all.

The private key can be generated, used to sign a CSR and create a
certificate, and then destroyed.

This can occur completely asynchronously to the manufacturing process.

It can occur in advance, in which case the certificate can be loaded via a
(pipelined) write operation to the device, which will generate the same
private key.

It can also occur after the device has been built and provisioned.
The device might never actually have it's certificate internally: the
onboarding infrastructure could retrieve it from the OEM when the device
first shows up.  Or the device could retrieve it when it first boots up as
part of the QA process.

But, ultimately, what's happening is that

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

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 22 Jul 2020 07:22:43 +0200

> The device has nothing....

Very good question, I thought the same.
In the case I see, the device don't talk directly with the PKI.
There can be a secure HW device in the factory interacting with
production line on one side, and the CA on the other. It can talk
something device specific, direct connect, with the device on the
production line, and make the CMP calls to the PKI. The private key
generated (by the CA) is then encrypted with the gateways public key
(where the private key is kept in an HSM/TPM/SmartCard).
Yes, the "gateway" becomes a point where the private key is decrypted
and vulnerable for a short time, so it's not for every scenario.

The CA can be off-site, not in the factory, i.e. central organization
PKI. The the term _factory_generated_ can be a bit misleading. The CA
can of course be in the factory as well, I just don't want to trigger a
specific architecture image in the readers mind.

> physically secure network connection.

Physically secure on the production line itself, but can be internet
between the gateway on the production line and the CA.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 22 Jul 2020 08:14:20 +0000

> Von: Michael Richardson <[email-masked]>
> 
> someone who would know.  They always seem two or three layers of
> indirection away.  I would be very happy to kill this issue as a non-issue.
> I'm aware of a major VoIP phone supplier whose CA is on a different continent,
> and it's not an issue.

We make used of a CA across continents for some years now and it works fine.

> yes, that's certainly true, but it also take some interactions among different
> layers.
> 

For smart card production the pre-generation of keys is often used. Especially if RSA keys are required.
Key generation for RSA keys is much slower and duration is unpredictable, compared to generating ECC keys.
Actually I mainly see ECC keys on embedded devices today. Today the required key length for long term used RSA keys gets inacceptable, as ECC keys key length is still acceptable. See section 4.6 in www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf

- Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 22 Jul 2020 08:45:26 +0000

> Von: Spasm <[email-masked]> Im Auftrag von Michael Richardson
> 

I use the image of the "birth certificate" to better explain the attributes of an IDevID certificate.
- Issued at manufacturing time (in Germany the birth certificate is a simple sheet stamped and signed by the local register office)
- The enrollment process requires some organizational/physical security, as there is nothing to derive trust from at that point in time (in Germany the father or mother have to request the birth certificate personally. They need to define the name of the child in front of the register officer and need present a conformation letter from the hospital or midwife about the date of birth)
- It lasts as long as the device is used (in Germany a birth certificate has no validity and it is difficult to get a new one, if you lost yours)
- It is required for initial authentication to request an operational certificate (in Germany the birth certificate is required if you request a national ID card or a passport)
- It should not be used for day-to-day operational tasks (you would not use the birth certificate to identify yourself other than to the register office. Only rarely it is requested, e.g., when becoming a governmental or public official)

> I think that it's useful for the entity that needs to examine the risk for the
> process to distinguish the two transfer methods.
> 
> 
> So I think that it really has to always be used in the factory with a physically
> secure network connection.

I personally would prefer to say '_infrastructure-generated_' than '_factory-generated_', because the generation on the device will most likely also take place in the factory.

> I have named this: device/factory-co-generated

Same here: 'device/infrastructure-co-generated'.

- Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 22 Jul 2020 08:56:13 +0000

> Von: Spasm <[email-masked]> Im Auftrag von Tomas Gustavsson
> 
> There can be a secure HW device in the factory interacting with production line
> on one side, and the CA on the other. It can talk something device specific,
> direct connect, with the device on the production line, and make the CMP calls
> to the PKI. The private key generated (by the CA) is then encrypted with the
> gateways public key (where the private key is kept in an HSM/TPM/SmartCard).
> Yes, the "gateway" becomes a point where the private key is decrypted and
> vulnerable for a short time, so it's not for every scenario.

I wrote down some thoughts on central key generation in tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02#section-4.1.6.

   There are some cases where an EE is not able or not willing to
   locally generate the new key pair.  Reasons for this may be the
   following:

   o  Lack of sufficient initial entropy.

   Note: Good random numbers are not only needed for key generation, but
   also for session keys and nonces in any security protocol.
   Therefore, we believe that a decent security architecture should
   anyways support good random number generation on the EE side or
   provide enough entropy for the RNG seed during manufacturing to
   guarantee good initial pseudo-random number generation.

   o  Due to lack of computational resources, e.g., in case of RSA keys.

   Note: As key generation can be performed in advance to the
   certificate enrollment communication, it is typical not time
   critical.

   Note: Besides the initial enrollment right after the very first
   bootup of the device, where entropy available on the device may be
   insufficient, we do not see any good reason for central key
   generation.

   Note: As mentioned in Section 2.1 central key generation may be
   required in a push model, where the certificate response message is
   transferred by the PKI management entity to the EE without receiving
   a previous request message.

- Hendrik

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jul 2020 11:39:51 -0400

> specific architecture image in the readers mind.

Should I say _ca-generated_ then?

    > between the gateway on the production line and the CA.

Agreed.

--
]               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: Tomas Gustavsson <[email-masked]>
Date: Thu, 23 Jul 2020 07:19:18 +0200

On 2020-07-22 17:39, Michael Richardson wrote:
>>>> 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
>>>
>>> I have named this: a) _factory-generated_ /
>>> _mechanically-transfered_ Like a serial console connection, or
>>> a JTAG flash writer.
>>>
>>> yes, but what key would you use? :-) The device has
>>> nothing....
>
>> Very good question, I thought the same. In the case I see, the
>> device don't talk directly with the PKI. There can be a secure HW
>> device in the factory interacting with production line on one
>> side, and the CA on the other. It can talk something device
>> specific, direct connect, with the device on the production line,
>> and make the CMP calls to the PKI. The private key generated (by
>> the CA) is then encrypted with the gateways public key (where the
>> private key is kept in an HSM/TPM/SmartCard). Yes, the "gateway"
>> becomes a point where the private key is decrypted and vulnerable
>> for a short time, so it's not for every scenario.
>
>> The CA can be off-site, not in the factory, i.e. central
>> organization PKI. The the term _factory_generated_ can be a bit
>> misleading. The CA can of course be in the factory as well, I
>> just don't want to trigger a specific architecture image in the
>> readers mind.
>

I kind of liked Hendriks suggestion: '_infrastructure-generated_'

>
>>> So I think that it really has to always be used in the factory
>>> with a physically secure network connection.
>
>> Physically secure on the production line itself, but can be
>> internet between the gateway on the production line and the CA.
>
> Agreed.
>
> -- ]               Never tell me the odds!                 | ipv6
> mesh networks [ ]   Michael Richardson, Sandelman Software Works
> |    IoT architect   [ ]     [email-masked]
> http://www.sandelman.ca/        |   ruby on rails    [
>
>
> -- Michael Richardson <[email-masked]>, Sandelman Software
> Works -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________ Spasm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2020 11:33:08 -0400

> I kind of liked Hendriks suggestion: '_infrastructure-generated_'

I'm going with that.
BTW: There is exactly the same set of considerations with initial(default)
     passwords.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Jul 2020 11:53:51 -0400

Just thought I would weigh in with some points.

There are some device vendors who made use of XKMS to provision private
keys to devices. As far as I am aware, that is the only standards based
effort that got anywhere in that space. The rest is not just proprietary,
it is a mess. The bane of enterprise software and services is that everyone
who is paying seven figures for a project can and does demand special
treatment.

There are no good choices for creating key pairs. All have drawbacks.

* Any key generated by the manufacturer can leak at multiple points in the
supply chain. But it can be welded to the device in such a way that it
cannot be extracted without extreme persuasion.

* Any key that is generated by the device can also be compromised through
an intentional side channel or by weak key generation. And once generated
can usually be extracted.

* Any key that is installed from an external source during onboarding can
be compromised during that process.

So none of the solutions are good. What should we do? The best answer is to
do all of them and combine the keys using threshold techniques. That allows
us to get a key that combines all the properties we want and is only
vulnerable if there are multiple failures.

The math is explained in this draft:
https://tools.ietf.org/id/draft-hallambaker-threshold-02.html

There are some caveats. While the private key is as strong as the strongest
of the input keys, the public key is only as good as the weakest public
key. Which means that the validation process has to be carefully designed.
There are approaches I took out of the drafts that are secure but only when
implemented exactly right so I have described a conservative approach.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2020 13:33:17 -0400

Brockhaus, Hendrik <[email-masked]> wrote:
    > - Issued at manufacturing time (in Germany the birth certificate is a
    > simple sheet stamped and signed by the local register office)

    > - The enrollment process requires some organizational/physical
    > security, as there is nothing to derive trust from at that point in
    > time (in Germany the father or mother have to request the birth
    > certificate personally. They need to define the name of the child in
    > front of the register officer and need present a conformation letter
    > from the hospital or midwife about the date of birth)

In Canada, I think the birth certificate is signed by doctor or midwife.

    > - It lasts as long as the device is used (in Germany a birth
    > certificate has no validity and it is difficult to get a new one, if
    > you lost yours)

Thus IDevID never expire.

    > - It is required for initial authentication to request an operational
    > certificate (in Germany the birth certificate is required if you
    > request a national ID card or a passport)

    > - It should not be used for day-to-day operational tasks (you would not
    > use the birth certificate to identify yourself other than to the
    > register office. Only rarely it is requested, e.g., when becoming a
    > governmental or public official)

But, you don't use your IDevID for day-to-day activities.
One needs an onboarding protocol to talk to an organizational CA to get the LDevID.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2020 15:34:56 -0400

> Just thought I would weigh in with some points.

Thank you.
I don't quite understand how XKMS can be used to provision private keys, but
I do agree that I do agree that the rest is a mess.

My goal is to just collect and describe the methods.

I originally started with the idea of being prescriptive about the shape of
of the PKI that is used to provision the certificates.  I am pulling back
from the prescriptive part, and instead I intend to just describe the
different considerations, giving them names.

    > can usually be extracted.

I am interested in why you say that the key can be welded into place
by the factory, but a key generated internally can't be welded in place in
the same way.
I think both strong and weak ways are possible in each case.

Agreed.

    > https://tools.ietf.org/id/draft-hallambaker-threshold-02.html

I would like to include this in my list, but we have a chicken and egg
situation on it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jul 2020 11:22:33 -0400

On Thu, Jul 23, 2020 at 3:35 PM Michael Richardson <[email-masked]>
wrote:

> I do agree that I do agree that the rest is a mess
>

There is a key provisioning protocol in the spec.

> by the factory, but a key generated internally can't be welded in place in

I have been through a bunch of designs where the manufacturer key can be
replaced by a user one. I don't think they actually add value.

What I am proposing for a threshold co-processor to address SPECTRE,
ROWHAMMER etc. attacks is the following:

Secret key key installed during manufacture are ka, ks

Operation Threshold Agree: P, a, c -> (a.ka+c).P

Operation Threshold Sign: Rin, a, c, m1, m2 -> r.P,  r + H(m1 ||  (r.P+Rin)
|| m2). (a.ks+c)

Such a co-processor should always offer operations on (a.k+c) rather than
just k. This allows the platform to make use of Lagrange/Shamir sharing
approaches and to construct as many virtual application keys as are needed .

Changing the manufacturer key just introduces a point of possible failure
without really achieving anything because the application should always be
adding in its own mix-in.

Unless one is prohibited from using the manufacturer key because of a
doctrine, I can't see why it would be a requirement. The manufacturer key
should never be used except in the process of application key provisioning.
And there the benefit of being able to print a QR Code on the device that
has real meaning probably outweighs that concern.
Doctrines can be a useful tool but we cannot develop specification
responsive to classified doctrines in an open process.

> I would like to include this in my list, but we have a chicken and egg

There is a NIST program looking at threshold. It is certainly an option
even if IETF isn't supporting it right now.