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

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

On Tue, Nov 17, 2020 at 1:20 AM Toerless Eckert <[e-mail]> wrote:

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

In the Mesh, these happen simultaneously... I was not really thinking of
this as an ordered sequence though.

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


IoT is really a set of constraints and limitations that were not
encountered in the workstation era of computing that the Internet emerged
out of. IoT means not being able to count on the device having a keyboard
or a display. It means possibly having limited performance. It often means
having multiple users but not having accounts.

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


Yes, UDRP.

And I am going to have to think of similar for Mesh callsigns
since @cocacola can only be used by one party...



> 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 ;-)
>

I have an alternative architecture that makes use of an notarized append
only log to issue permanent names for $0.10. The user only needs one of
those for a lifetime and only needs to interact with the registry when
changing their service provider. The registry does not support queries,
that is the job of service providers which simply take a complete copy of
the registry.

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

I use UDFs as the fingerprint format. That allows the work factor to be set
to any degree of difficulty desired. For most purposes, a work factor of
2^128 is sufficiently prohibitive. UDFs are always calculated using
SHA-2-512 or SHA-3-512 but can be expressed at variable precision. So I can
specify 120 bits (30 chars) to save space or give 260 bits (52 chars) if I
want to have quantum cryptanalysis resistant work factor.


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

I looked into that at one point. But I found a way to design around the
need to go there. It not really necessary as these domains don't require
DNSSEC, they are roots of authority in their own right. So its just a query
function and a resolver can only respond for the domains it knows about. So
if we used SINs, the local DNS resolver might know a few hundred of them at
most.

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

Key generation is pretty quick for ECDH, its the same as a key use. But
from the security point of view, there is really no difference between keys
generated on the device and keys installed during manufacture that is
visible to the end user. So they can't trust the key that much regardless.


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

Actually not. If x is leaked during manufacture, the key is still as secure
as the value y. That is the whole beauty of this approach. The
manufacturer can mess up completely and the only damage is a very small
window of vulnerability during the device connection operation.

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

Same as any other Ed448 or X448 operation - a few ms.



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

That sounds like a way forward. I am happy to align with Anima nomenclature
if it helps.



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

There are different types of backdoor. What my technology does is to allow
the manufacturer to prove that they do not have a backdoor to the keys
users make use of in applications as a result of information available at
the time of manufacture.

What I cannot do is to provide a complete set of controls that prevent a
manufacturer leaking information through a side channel after the device is
provisioned. You can apply threshold as many times as you like so that the
number of parties that have to collude is as large as you like but no
protocol can ever be secure if EVERY trusted party defects.

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

Alice is generating y on her administration device. What if the
administration tool has a backdoor and sends a copy of y to Mallet? Well
Alice is still protected provided that the device manufacturer is honest.
It takes disclosure of x AND disclosure of y for there to be a breach.




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


Zero effort security.

The only user experience that is acceptable to me is no user experience at
all. Once devices are connected, they just work and Alice is not even aware
of the fact she is using end to end encryption. The drafts describe this in
more detail. But basically, Mesh email works just like regular email. Mesh
messaging works just like regular chat, etc. etc.

The only time the user experience changes at all is during the
connection/onboarding process and that is simply the scanning of a QR code
or the exchange of an IR, Bluetooth or other affordance and saying 'yes I
want to connect this device and here is what I want to allow it to do'. If
the coffee pot wants access to the passwords catalog... its a bad coffee
pot.