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

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

> Von: Michael Richardson <[e-mail]>
> 
> Brockhaus, Hendrik <[e-mail]> 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.

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

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

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