Re: [Iot-onboarding] OPC and BRSKI

[Dan Harkins <[e-mail]>]

   Hi Toerless,

On 8/8/19 9:25 AM, Toerless Eckert wrote:
> On Wed, Aug 07, 2019 at 10:40:54PM -0700, Dan Harkins wrote:
>>    The problematic nature of voucher-less trust can be offset somewhat by
>> limiting knowledge of the device's credential. DPP attempts to do this. The DPP
>> device will only accept a provisioning agent that knows its public key.
> What is DPP ?

   The Device Provisioning Protocol. A quick google search discovers that
Michael has graciously placed the spec on his server. Thanks Michael!

    http://www.sandelman.ca/tmp/ieee/dev-prov.pdf

It's a way to provision 802.11 devices before they get on the 802.11 
network.
It doesn't require a backend like a MASA but such a thing could be used if
need be. Check it out.

> Interesting scheme. I wonder how problematic security experts would find
> this approach. But certainly novel to me to use a public key as a shared
> secret with one "owner".

   The public key isn't really a secret. It's the identity of the 
device. And
if you know it then you have the ability to provision it. You can talk to
the device if you know who it is, if you don't know who it is it will ignore
you. For small office or home/apartment situations this is 
trust-by-possession.
But, as I said, something like a MASA could be used to provide other forms
of trust (e.g. trust through legitimate purchase).

>> But that is not the only way of  bootstrapping a
>> device's public key. The device's public key could be bootstrapped from a
>> cloud service-- give the serial number of the device (and/or proof-of-ownership)
>> and get back the device's public key.
> How about resale of such a device. The second owner knows that the first
> owner always has a key left (because it can always remember the public key).
> Or else it should be possible to erase/recreate this key-pair.

   This identity key, called a bootstrapping key, does not change when the
thing is reset to to factory defaults. If the thing is not provisioned 
it will
listen for DPP messages addressed to it (via this identity key) and when 
it is
provisioned it will not listen to DPP messages anymore until it is reset to
factory defaults. If you want to resell the device you just need to provide
the new owner with the bootstrapping key (it may still be in the form of 
a QR
code on its backside or you may have it in packing materials). The owner can
then reset the thing to factory defaults and start sending it DPP messages.

>>    This allows the device to have a modicum of trust in "the network" based
>> on the steps the network had to go through in order to bootstrap the device's
>> public key.
>> This way printers (with a relatively low bar on trust of "the network") can
>> get provisioned for a network that also includes something like a centrifuge
>> (with a relatively higher bar on trust of "the network" that it will join).
> Not sure i understand that point.

   I'm trying to say that there are multiple ways to obtain a thing's 
identity
key and they all impart different degrees of trust. It is up to a 
manufacturer
to provide bootstrapping of identity keys of the things it produces in a 
manner
that is suitable for those kinds of things-- televisions placed on home 
networks
are different than light arrays placed in stadiums which are different than
EKGs put in hospitals which are different than....

>>    I'm not sure how relevant this is to OPC (I have not found the relevant
>> documents on the OPC website) but I just want to point out that voucher-less
>> provisioning does  not have to rely solely on blind trust or TOFU.
> A voucher is just a secure digital artefact to pass on authorization of
> ownership. If you want to give that authorization to some enterprises
> server/registrar in the shared-secret public-key scheme, you would also
> need to have some way to pass on that public key to that enterprise
> server. Just a different type of voucher.
>
> Aka: there is always a voucher, even if you haven't called it that way ;-))

   Indeed! One of the by-products of this effort by Eliot to enumerate 
all these
on-boarding techniques might be some common lingo so we can all talk to each
other :-)

   regards,

   Dan.