Subject: Re: [saag] IoT device authentication is overrated

From: Michael Richardson <[email-masked]>
Date: Fri, 13 May 2016 14:46:53 -0400

Dan Harkins <[email-masked]> wrote:
    > An alternative to certificates or distribution of shared keys is
    > raw public keys in the form of something like a QR code [1] on the
    > backside or packing list of some headless device (like a thermometer).
    > The scanned public key is "trusted" because of where the QR code was
    > obtained and can therefore be used to authenticate the headless device.

So effectively, what you've done is just swapped the "public" and "private"
labels for the two halves of the public key.  Or if you prefer, swapped the
sign and encrypt operations.

    > [2] https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf

An interesting and prescient read!
It's nice to know that my suggestion of duck imprinting wasn't original, that
a smarter person thought of it first: it makes my use of it in much less
controversial :-)

    > The headless device can "trust" the entity that scanned its public
    > key through a variant of the Resurrecting Ducking [2]-- when it is
    > unprovisioned it accepts imprinting from the first device that knows
    > its public key similar to a duckling imprinting it's "mom" as the
    > first thing that moves and makes a sound.

I really enjoyed the introduction of the new terms:
         reverse metempsychosis.
         escrowed seppuku
         device to be endowed with two souls

I think that the mechanism that you've suggested is entirely a reasonable
mechanism for interchangeable (consumer/retail) grade devices that come by
the pallet load.

There are a number of issues, particularly in the industrial and commercial
building (lighting specifically) settings, which make this very simple and
direct approach problematic.  It amounts to that the people doing the
physical installation are not trusted --- conceptually, one could do the
imprinting in another location by a trusted entity, and then pass the devices
on to be installed.

The idea that we might do such a thing was discussed at length at the 2012
IAB (Paris) workshop in IoT security: the context that EKR introduced was that
someone had systematically collected the QR codes from the boxes of
thousands/millions of smart light bulbs (An employee at BIGBOXRETAILER.com).
The devices continued on to be installed and used by individuals.  The attack
is what happens to the grid if you simultaenously turn on/off that many
lightbulbs.  The group spent most of the day talking about this scenario.

So there are a whole bunch of problems that make this an unrealistic attack
in my opinion.

The first is that as observed by you and Andersen in Resurrecting Duck, that
the once used, the QR code can't be used again; access would get replaced
during that exchange.  So having reaped all these codes, one either uses them
immediately, causing the device to be unimprintable by the end user.  Or the
end uses the codes and imprints the bulb, and again replaces the identity.
Or, if they find the device already imprinted, they "resurrect" the device,
then the old access goes away.

One question that I have thought about this situation is why use public keys
at all.  A symmetric key printed in a QR code might also be useable and
simpler.  It's also unclear why it should be a key at all, as opposed to just
some opaque bearer token.  If we call the thing the device the IDevID, and
the thing that is printed on the outside and Ownership Token, then you wind
up with the mechanisms exactly as envisioned in ANIMA and NETCONF.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 May 2016 14:53:22 -0400

Alan DeKok <[email-masked]> wrote:
    >   So I am cynical about the comment that only one device knows the
    > corresponding private key.  It would be good to find a way to *ensure*
    > that the devices are properly provisioned.

    >   For me, that means *I* will provision a new public/private key to the
    > device.

It's critical that the only activity that the Ownership Token can provide for
is to provision a new key.  Whether a new private key is generated or not is
another consideration.

    >   Your scheme may work most of the time... but I pity the poor IT guy
    > who receives a shipment of IoT devices, scans the first QR code... and
    > has 1000 devices respond "That's me!"

Assuming that they don't also all have the same MAC address, then this is
actually okay: the process picks one, provisions the domain specific key, and
then goes on to pick another.

    >   Perhaps derive a symmetric key from a pre-provisioned public/private
    > key, and the MAC address of the device?  The shame of sending multiple
    > devices with the same MAC address is a *lot* higher than the shame of
    > shipping multiple devices with the same public/private key.

I advocate that the IDevID have the MAC address built-in to it, and the
device use that.  Many new devices don't have seperate MAC address PROMs,
it's all stored in the same device flash.