[Iot-onboarding] Phil*: "self-enrolling voucher" - (was: Re: Using Threshold techniques in onboarding.)

[Toerless Eckert <[e-mail]>]

Phil:

Let me open a new thread on that sub-topic and add ANIMA WG:

I vry much like your ECDH idea and i think one way to proliferate it,
would be to specify in an RFC an "enrolling voucher". I'd be happy
to help co-author that, but if i look at all the other voucher RFC/drafts
we have, there is a lot of knucklehead encoding work i am not the expert
on - so maybe other would like to jump in.

To restarte for ANIMA your idea/mechanism:

 device ships with an ECDH {public, private} keypair {x.P, x}
 When device is onboarded/owned, the owner 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.

An enrolling voucher would have to have:

 a) The required subset of the existing voucher components:
 identifier of device (such as x.P), and voucher signed by some TA
 that the device trusts before onboarding.

 b) New Stuff:
 b.1) y encrypted with some fitting ECDH derived scheme with x.P, so that
      only the device itself can decrypt y.
 b.2) (optional) A certificate for z.P signed by whatever TA the owner has selected
      (not needed when the node itself does not need to run protocols
       relying on certs, but maybe only needs the z key pair) (*1)

The cool novelty of this scheme is that we eliminate the need for a lot of
communications otherwise needed, so these vouchers would make all those
"disconnected" use-cases easier. Normally the device would need to have
an active secure connection to enroll a certificate or to indicate a new
key-pair it locally creates. In this mechanism, the voucher could be, quite
similar to ACME cert renewal certificates (without re-keying!) distributed
across public caches and downloaded through arbitrary chain of sneakernet
(USB-stick-net).

(*1) There is an interesting limitation/change of the scheme in so far as that
usually a CA may want to have some form of "proof of ownership" of in this
case z before it would sign a certificate for z.P. Because the device is
decidedly not involved here, the CA would need to be willing to sign 
the cert without such proof of posession. This might require according
extensions to the certificate that would indicate this new type of certificate.
Obvioulsly, when we use non-public TA, such as typically assumed in ANIMA/ACP,
this is not an issue at all.

So, would be interesting to hear what others think.

Cheers
    Toerless


On Tue, Nov 17, 2020 at 05:09:45PM -0500, Phillip Hallam-Baker wrote:
> 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.