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

["Panwei (William)" <[e-mail]>]

Hi Toerless,

It's an interesting topic, I'd like to join in and contribute.
I think the use of such ECDH methodology is to get rid of certificates or PKI mechanism. And if that works, it will benefit the IoT devices very much.
By the way, I think we may also need to have a "lightweighted BRSKI" draft to accommodate the use of "enrolling voucher". For example, by using this "enrolling voucher", the certificate enrollment part of using EST in BRSKI can be omitted. Also, BRSKI replies on the devices shipping with an IDevID/IDevID certificate, if we consider to completely throwing away certificates and ship the device with an key pair, then we also need to address this change .

Regards & Thanks!
Wei Pan

-----Original Message-----
From: Iot-onboarding [mailto:[e-mail]] On Behalf Of Toerless Eckert
Sent: Wednesday, November 18, 2020 4:33 PM
To: Phillip Hallam-Baker <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: [Iot-onboarding] Phil*: "self-enrolling voucher" - (was: Re: Using Threshold techniques in onboarding.)

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

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