Re: [Iot-onboarding] Using Threshold techniques in onboarding.

[Toerless Eckert <[e-mail]>]

Inline

On Mon, Nov 16, 2020 at 07:44:20PM -0500, Phillip Hallam-Baker wrote:
> I have running code and a spec for one way to skin this particular cat. The
> draft is not quite ready but its close:
> https://tools.ietf.org/id/draft-hallambaker-mesh-architecture-15.html
> 
> Let's consider what we want to do when we onboard a device:
> 
> 1) Establish initial communication with the device.
> 
> 2) Configure the device to operate under control of the owner. Including
> the ability to connect to the owner's network and authenticate commands
> from the owner.
> 
> 3) Establish a trust context that is verifiably independent of the
> manufacturer and supply chain.

In ANIMA/BRSKI and friends we typically swap your 2) and 3), so that
3) itself can happen under the owner trust context and therefore minimizes
what happens with the device under "ownership" of manufacturer/seller.

> 4) Reconfigure the device as necessary including the ability to switch wifi
> networks, reset device config without needing to repeat onboarding, etc.
> etc. without the need to climb a ladder at 3am in the morning because the
> smoke alarm decided to throw away its configuration data on a whim.

In ANIMA/ACP we embed in devices minimal, automated & trusted connectivity
that is intended to be "undestroyable" by operator/SDN-controller mistakes.
(effectively an automaticac out-of-band management network).

> Onboarding must become a one time operation. No excuses.

Once per board ;-)

Aka: for most devices you probably do not need to repeat onboarding unless
ownership changes. Not sure yet what this means for cases such as leased equipment
in multi-tentn office environments (leased) for example.

> Onboarding configuration requires user effort which is precious.

Its primarily error prone even for remote automation, which is one aspect that
ANIMA/ACP attempts to eliminate.

> Configurations MUST survive a hard reset of the device.
> The only time the configuration should be forgotten is when the owner requires it.

Yes. Unfortunately, i have not seen a lot of IETF documentation about this
device level operational models. I had a hard time to push a bunch of ACP
related operational aspects in this space through IETF/IESG review because
they are "internal" to the node and not "protocol on the wire". 

But i think we should have a lot more of these aspects standardized. Even
though it will be hard to agree on models for it.

> TLS configuration was raised in SECDispatch. I believe DANE is the wrong
> tool for the same reason CAs are the wrong tool: PKIX PKI is really not
> designed for IoT.

I don't even know what IoT vs. non-IoT is. Problems such as different
levels of "reset" already apply for decades to routers. Even simple
operational aspects such as "boot once with new firmware, and automatically
reboot old firmware within 10 minutes unless remote operations has cancelled
this fallback-reboot" - have not been standardized as operational device
requirements. And have not really been implement well in many routers (haven't
looked recently..).

> In particular, PKIX certificates are bound to DNS names
> which requires that they expire within a short timeframe. Moving from the
> WebPKI to DNSSEC doesn't help because DNS names are rented, not owned.

Haha. Indeed. Are there actually cases where DNS names where forcefully
removed from owners ? Otherwise one could make the argument that any
buyer of DNS names should pay upfront for the following 30 years for the domain
name as soon as one discovers that the domain name is hardcoded into
equipment. I am sure RIR would love those upfront payments ;-)

> The expiry issue aside, enterprises and IETF participants have DNS domains
> of their own. Consumers do not. And so binding to DNS names...

Yes. Way too little overall automation for DNS name allocation. And the
problem of long enough ownership...

> So one approach I have proposed in the past is to use Strong Internet
> Names. These are simply a fingerprint of a public key that is mapped to a
> reserved portion of DNS namespace.

Hmm.. reminds me of all those informal web-pages where you could "register"
a ULA you picked. I actually had i think two of them mentioned in ACP draft
until they vanished on me.

Aka: there are hash collisions, so i would first have to wrap my head
around the potential of hash collision attacks. Need to not make the public
key/hash known to anyone non-trusted until its locked into DNS.

> So lets say that Alice's coffee-pot has a TLS key with the fingerprint
> MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4. We can use that to establish a domain
> name that allows us to authenticate the TLS cert without reference to any
> external trust provider:
> 
> coffee.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
>
> That is not the sort of identifier I want to ever throw in a user's face.
> But it is perfectly OK for an internal buried in the guts identifier. That
> is what I started with four years ago... I have moved on a bit since.

You probably want to come up with a DHT way to hierachically split up such
a space so that individual DNS servers would not be overloaded once this
domain grows globally.

> In principle, we could just issue strong name certificates when a device is
> manufactured.

That is is a broad expectation. Would be nice.. Not sure if its feasible for
all IoT devices. Even for IT equipment, the process of staging certs
in a trusted way into TPM or the like is quite advanced.

> And that would be perfectly adequate for most user's actual
> needs. Right up until some manufacturer is found to have kept track of all
> the keys ever issued and has suffered a breach.

Right. Main issue in manufacturing is the time it would take low-end device
'TPM' hardware to calculate a key pair, so the manufacutring process is
highly security critical.

> This approach is not
> acceptable for most enterprises and particularly not for HIPPA / SCI type
> applications.

No idea about these type of apps. You mind to prive (pointers to) some insight ?

> The solution is to take advantage of the fact that all Diffie Hellman Keys,
> including Elliptic Curve keys support threshold key generation.
> 
> The device ships with an ECDH {public, private} keypair {x.P, x} When the
> device is onboarded, the administrator issues a second set of keys {y.P, y}
> and passes the private value y to the device by means of a secure channel
> and a certificate for the key {z.P, z} where z=x+y.
>
> Only the device has the means to calculate x+y. But the administrator can
> calculate z.P because z.P = x.P + y.P.

Nice option. 

Does of course expect that x was never leaked from the manufacturer.

Not sure too if during deployment the time taken to locally calculate a
standalone {z.P, z} would be too significant. Couple minutes..

In ANIMA we developed the concept of vouchers (rfc8366), which authenticates
the owner to the device by mean of a manufacturer signed object (the voucher)
(device trusts manufacturer signed object).

We could have an extended voucher object which includes encrypt(x.P, y).
This could replace the secure channelt to the device to enroll the new
keypair.

> Using this approach means that the user is completely insulated from any
> malice or incompetence on the part of the manufacturer (or subsequent
> supply chain compromise) provided only that the administration device
> chooses a strong value of y.

And that the manufacturer has no backdoors. Which obviously politicians
are claiming these days for every device from another political empire.
And then the same politicians will go back and force their own political
realm backdoor into their realm equipment.

*sigh*

I guess for low-end-enough IoT devices one could still verify open source
chip designs and verify samples of chips under actual electroni microscopes
to validate the chip manufacturer.

> Contrawise, the user is protected if the
> administrative device is faulty unless the device manufacturer defects.

Didn't parse that.

> Threshold is really, really powerful. You can have exactly as much fault
> tolerance as you like, all you have to do is to introduce another party to
> share the key with.
> 
> 
> So what is the user experience like in practice? Well I have not yet fully
> considered the enterprise case where we have to consider the distinction
> between the owner and the user and consider insider threats. But I do have
> three onboarding scenarios for the user case:
> 
> 1) Witness value comparison (with optional PIN code)
> 
> If the device to be onboarded has a keyboard, Alice enters her Mesh
> callsign ([e-mail]) on the device to be connected. The device
> spits out a witness value which should appear on the administration device.
> If the witness values match exactly, everything is correct and the
> connection request can be accepted. Alternatively, an out of band PIN code
> may be used as an authentication mechanism.

Not quite complete dscription i think. Whats the condition for alice's
ownership ? Just physcial posession ? If not, then what ?

> 2) QR code presented on administration device.
> 
> If the device to be connected has either a camera or some means of
> accepting a short range communication and a means of placing the device
> into an onboarding mode, the Mesh callsign and PIC code can be presented in
> this form allowing the device to connect without the need to enter data.

bearer token on QR. 

> 3) Static QR code printed on the connecting device.
> 
> The connection can also be made by means of a static QR code printed on the
> device itself. This must provide some means of bootstrapping a local
> communication channel between the devices to complete the connection
> process and provision the initial network configuration.

Yeah. physical posession. All type of problems with those on-box
ownership authenticators depending on distribution channels.

> One of the principles of the Mesh is autonomy. Users should be in control
> of their digital environment. So what I am currently working on is a
> mechanism to allow users to switch Mesh Service Providers without switching
> costs.This will allow the mesh callsign to simply become @alice which will
> be a lifelong name assigned to Alice that never needs to change unless she
> wants to change it. She can switch her provider (e.g. moves from a Comcast
> served area to Verizon) but she doesn't need to change her callsign. All
> her existing devices will adjust automatically.

Good luck

Cheers
    Toerless

> -- 
> Iot-onboarding mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iot-onboarding