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

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

    > 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-