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

["Brockhaus, Hendrik" <[e-mail]>]

> Von: Spasm <[e-mail]> Im Auftrag von Tomas Gustavsson
> 
> On 2020-07-22 01:31, Michael Richardson wrote:
> >
> > Tomas Gustavsson <[e-mail]> wrote:
> >
> >     > On 2020-06-28 22:51, 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.
> >
> > for b) _factory-generated_/ _network-transfered_
> >
> > 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.

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