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

[Phillip Hallam-Baker <[e-mail]>]

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

>
> Phillip Hallam-Baker <[e-mail]> wrote:
>     > 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
>

There is a key provisioning protocol in the spec.





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




>     > 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
>
> I would like to include this in my list, but we have a chicken and egg
> situation on it.
>

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