Subject: [saag] IoT device authentication is overrated

From: Stefan Winter <[email-masked]>
Date: Thu, 7 Apr 2016 22:24:37 -0300

Hi,

not sure if this is really a good idea or if it's just too much wine at
Bits'n'Bites. :-)

As I read through EAP-NOOB I noticed that they declare completely
I/O-less devices out of scope. This made me start thinking about these
devices, and how to do onboarding for those. My favourite IoT device is
a thermometer. I'm all involved in EAP-based networks, so my scenario is
also just applicable in EAP (stop reading if you don't like that).

So, imagine you want to deploy a thousand thermometers to measure the
temperature of some glacier.

I don't think you want to run an EAP-NOOB OOB authentication and
individual key derivation for all of these. Let alone that I can't
imagine how the OOB message would look like ("heat the thermometer
sensor to 50°C. Let it cool down to 25°C. Warm it up to 35°C.
Authenticated."). You want to authorise the *class* of device, not an
individual device.

I believe there are just some devices that don't need or deserve
individual authentication, but they do have a place on your network.

I imagine a very simplistic EAP method which makes sure devices only get
exactly the network resources they claim, that this can be supervisioned
by the admin, and it's flexible if the device changes over time (new
firmware etc.).

The story goes like this:

Device ships out of the box with a simple description file of which
network services it needs (ports open to which destinations, etc.). This
can be a MUD file for example. It has no "personal" identifiers; serial
numbers are not needed for the method I describe below. Let's assume the
MUD file contains the equivalent of "I'm a thermometer from
FridgeControl Inc., and occasionally need firmware upgrade checks from
www.fridgecontrol.example; you may find updated MUD files for me at
...URL... ."

On first network connection, the device does an EAP login with a
strawman method "EAP-NOID" which merely carries the MUD file to the EAP
server. The EAP server checks if the MUD file has already been
authorised by the network admin (byte-by-byte comparison; any change in
MUD leads to new authorisation requirement).
If yes, send Access-Accept to the device and open access-lists according
to the MUD description on the IP hop whom it concerns.
If no, flag MUD file content as "to be decided" to the network admin;
send Access-Reject in the meanwhile. The device can try as often as it
likes.

All thermometers send the same MUD file: once the admin has cleared the
first thermometer, all subsequent thermometers get online automatically.

If an "attacker" buys the same make and model of thermometer and deploys
it: thank you; one more thermometer for the measurements.
If an attacker forges the thermometer so that it sends the same MUD file
but tries to spam on TCP/25 instead: won't work, because the MUD file
has been translated into an access-list and the malicious traffic is
blocked.
If an attacker sends a different MUD file with the TCP/25 request in it
- it's a new MUD file and the network admin would need to clear it
manually on first sight (which he hopefully doesn't do; otherwise "this
is not the admin you are looking for").

I imagine this to be very IoT friendly, also suited for extremely
constrained devices. The MUD file transmission in the EAP-NOID method
does not even need TLS protection: there is absolutely nothing secret in
it. You could find the documentation of the thermometer's communication
needs also in the thermometer manual; and the device has neither a
username nor a password -> no need for encryption. There is also not a
need for integrity protection: the admin sees what's coming in; and
exactly the settings he sees are going to applied on the access-list -
all authorisation requests reach human eyes and get applied as seen. (<-
that previous sentence is even less thought out than the rest :-) ) This
reduces the computing power needs to a copy&paste of a few bytes of text
from local storage to a clear-text EAP method. Computationally, it
doesn't get much cheaper than that.

You don't want an approve-once accept-always policy for all kinds of IoT
devices of course: for the thermometers which don't do anything more
than thermometering all day this is fine; if the device is a camera
instead then at some point you do want individual device authentication
- just because there are 10 cameras in the reception area doesn't mean
there should be an 11th in the showers. So this is not a cure-all and
doesn't directly compete with EAP-NOOB. But it may be a very simple and
lightweight solution for *some* deployments and classes of devices. For
some per-device authentications a simple way of continued use of
EAP-NOID would be: authorise the device per MAC address and only during
the current network session.

I believe we are obsessed with individual authentication because in a
human networking world this is important: you want to be able to find
out who did something bad, and want to control who is allowed to come in
in the first place - but when the end devices are just things which can
only do exactly one task, it's sufficient to let the things do exactly
their task, and forbid them anything else.

Greetings,

Stefan Winter

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 7 Apr 2016 22:45:42 -0400

> also just applicable in EAP (stop reading if you don't like that).

What happens when the attacker penetrates your cheap, Verizon/Aciontec
router and then starts commandeering the thermostat because its
hanging off the network?

https://www.youtube.com/watch?v=fdG_BDWjLmg

Jeff

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Apr 2016 10:20:58 -0400

> temperature of some glacier.

Yes.  We have imagined that.

Please see:
   https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
and:
   https://datatracker.ietf.org/doc/draft-richardson-6tisch--security-6top/

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

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 8 Apr 2016 11:25:37 -0300

>     https://datatracker.ietf.org/doc/draft-richardson-6tisch--security-6top/

A couple years ago, I was challenged for a situation where sensors were 
being dropped from a helicopter.  I pointed out SOMETHING would be 
loading those sensors.  All the sensors were know.  Building up an ACL 
before deployment is really acheivable.  They went back and did that.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Apr 2016 16:08:25 -0400

Robert Moskowitz <[email-masked]> wrote:
    > A couple years ago, I was challenged for a situation where sensors were being
    > dropped from a helicopter.  I pointed out SOMETHING would be loading those
    > sensors.  All the sensors were know.  Building up an ACL before deployment is
    > really acheivable.  They went back and did that.

reference?
That's not zero-touch exactly...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 25 Apr 2016 14:02:20 -0700 (PDT)

>    https://datatracker.ietf.org/doc/draft-richardson-6tisch--security-6top/

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

  regards,

  Dan.

[1] the attached QR code is the base64-encoded subjectPublicKeyInfo for
a EC public key; scan it, base64-decode it, and voila.

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 26 Apr 2016 19:55:25 +0000

> On Apr 25, 2016, at 3:02 PM, Dan Harkins <[email-masked]> wrote:
> 
> 

Sure. If all the devices can be scanned. Or perhaps the original public key “directory” concept could be resurrected; scalable central cloud databases have come a long way. :/ 

> key through a variant of the Resurrecting Ducking [2]

FYI - resurrecting duckings result in what I call the “zombie duckling”. Namely a device that has been fully compromised by an attacker and is now joining your network and pretending to be a cute little baby duck. 

Unless we build a full network endpoint attestation infrastructure (for IoT) to detect zombies.
Or enforce other mitigations, like mandatory device verification of central logging or ownership validation. 

- max

> -- when it is
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 26 Apr 2016 15:24:07 -0700 (PDT)

On Tue, April 26, 2016 12:55 pm, Max Pritikin (pritikin) wrote:
> Sure. If all the devices can be scanned. Or perhaps the original public
> key “directory” concept could be resurrected; scalable central cloud
> databases have come a long way. :/

  Nobody said anything about "all" but I guess a response could be
sure, not necessary if all devices get manufactured with a manufacturing
CA whose certificate is obtainable and trusted somehow.... That global
PKI is still a ways off :/

  Generating a public key at manufacturing time is one thing. Having
an auditable and secure manufacturing CA to enroll a device that
generated the public key into this common CA is a bit more. For an
enterprise-grade access point that'll fly, for a $89.99 doorbell/camera
probably not-so-much.

> FYI - resurrecting duckings result in what I call the “zombie
> duckling”. Namely a device that has been fully compromised by an
> attacker and is now joining your network and pretending to be a cute
> little baby duck.

  And the metaphor completely falls apart when you try to bend and
expand the terms to suit your agenda. Fully compromised devices are
a threat without ducklings and their cuteness isn't really part of
the model.

> central logging or ownership validation.

  And if you don't have mandatory device verification of central
logging and full network attestation infrastructure (which I think it
is safe to say is probably not going to exist in Joe Random's house
where a bunch of things Joe bought are going to sit around trying to
get on his network) the idea is you can get a decentralized semblance
of trust without relying on trusted 3rd parties through the imprinting
step described in the "Resurrecting Duckling"-- my public key is known
by someone who has possession of me and/or bought me so I'll trust that
if someone proves she has my public key then I'll accept that she's
legitimate and will accept imprinting from her (also known as "hi mom!").

  Reverse metempsychosis (the whole resurrection stuff) is sort of like
a "reset to factory defaults" step followed by a whole 'nuther run
of the provisioning protocol. Not necessary, and if done right doesn't
create cute looking walking dead ducklings that will try and eat the
soft goo in the center of network (major metaphor breakdown).

  Dan.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 26 Apr 2016 22:54:24 +0000

inline, 

> On Apr 26, 2016, at 4:24 PM, Dan Harkins <[email-masked]> wrote:
> 
> 
> 
>> key â?odirectoryâ? concept could be resurrected; scalable central cloud
>> FYI - resurrecting duckings result in what I call the â?ozombie
>> ducklingâ?. Namely a device that has been fully compromised by an

Agreed. This is the threat we need to mitigate. Call it a ‘trojan duckling’ if you like that metaphor better, but I’m partial to ‘zombie’ due to the use of ‘resurrecting’ in the original paper. 

> legitimate and will accept imprinting from her (also known as "hi mom!”).

I think you’re suggesting using the device’s public key as a 'secret key’, and that the network needs to “prove she has” it and that this is a mitigation for the zombie duckling problem? I’d tend to reject using a public key/cert that are normally exposed during a TLS handshake and thus make poor secrets but agree that using an actual secret key that must be scanned does provide a mitigation. 

I don’t like the scanning and distribution of secret keys so I reject that approach as well.

> a "reset to factory defaults”

This is a good point. If devices can be reset to factory defaults but their symmetric key has already been used and exposed then it is even harder to justify using them for an ongoing lifecycle protection. 

- max

> step followed by a whole 'nuther run

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 26 Apr 2016 17:32:39 -0700 (PDT)

>>>> On Apr 25, 2016, at 3:02 PM, Dan Harkins <[email-masked]> wrote:
[snip]
> Agreed. This is the threat we need to mitigate. Call it a ‘trojan
> duckling’ if you like that metaphor better, but I’m partial to
> ‘zombie’ due to the use of ‘resurrecting’ in the original paper.

  It falls apart because you are assuming that "resurrection" (per
the paper) entails compromise. Nothing wrong with calling them zombies,
but there's something wrong with assuming that the walking dead are
unique to some model or that they are the inevitable result of following
that model.

>>> Unless we build a full network endpoint attestation infrastructure
>>> (for
>>> IoT) to detect zombies.
> I think you’re suggesting using the device’s public key as a 'secret
> key’, and that the network needs to “prove she has” it and that this
> is a mitigation for the zombie duckling problem? I’d tend to reject
> using a public key/cert that are normally exposed during a TLS handshake
> and thus make poor secrets but agree that using an actual secret key that
> must be scanned does provide a mitigation.

  As I stated before, I do not agree with your "zombie duckling problem".
The public key is not secret since it can be scanned but one can infer
something from knowledge of the public key. And the entity that scanned
it can know that there's only one device in the world that knows the
corresponding private key.

  If I scan a QR code on some packing material that came with my new
802.11-enabled doorbell/camera and there is now some device "out there"
that knows the corresponding private key I can infer that that device
is my new doorbell/camera. The doorbell/camera can infer that if
someone proves knowledge of its public key then it must have the
packing materials which means, pretty much, that that someone owns the
doorbell/camera. No need to securely access some secured cloud, no
need for a slew of trusted certificates that I somehow obtained in some
secure manner a priori, and the manufacturer can keep the cost down to
just $89.99 because he doesn't need a secure and auditable manufacturing
CA (or probably CAs since manufacturing is done in several distinct
locations).

  And who said anything about TLS? TLS would happen _after_ the
provisioning protocol. This scanned key is used to authenticate the
device and then it is provisioned with, perhaps, a certificate for
use with TLS at some later point if it has a need to access a server.

> I don’t like the scanning and distribution of secret keys so I reject

  I don't like the scanning and distribution of _symmetric keys_. There
is a critical difference between a symmetric key and an asymmetric key.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Apr 2016 09:23:46 -0400

> corresponding private key.

  In one company I worked at, a technician on the manufacturing line who discovered he could be more efficient by skipping the step which created a new MAC address for every device.

  This was discovered after about 1000 devices had been incorrectly flashed and shipped.  They all had to be recalled.

  We've also recently seen low-cost Wifi routers ship with the same default SSH keys.

  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.

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

  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'm just throwing ideas out here... but I just think that unless it's forbidden by design, we will see many devices with the same public / private keys.

  Alan DeKok.

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Wed, 27 Apr 2016 15:34:48 +0000

I think what you're proposing is a required duplicate detection mechanism. While I don't know it to be possible to make such a system perfect, I could envision steps on could take such as license renewals. Not sure that would be appropriate all or even most of the time. 

Eliot

> On Apr 27, 2016, at 9:24 AM, Alan DeKok <[email-masked]> wrote:
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Apr 2016 13:56:04 -0400

On Apr 27, 2016, at 11:34 AM, Eliot Lear (elear) <[email-masked]> wrote:
> 
> I think what you're proposing is a required duplicate detection mechanism.

  Sure.  I think it's important to either make duplicates impossible, or detectable.

> While I don't know it to be possible to make such a system perfect, I could envision steps on could take such as license renewals. Not sure that would be appropriate all or even most of the time. 

  It's mainly the initial deployment, when coming from the manufacturer.  Once it's in the customers hands, it's up to them to keep the system secure.

  Alan DeKok.

---

From: Василий Долматов <[email-masked]>
Date: Thu, 28 Apr 2016 15:25:40 +0300

>> 
> 
> .  Once it's in the customers hands, it's up to them to keep the system secure.

sounds like a bad idea. customer can have no slightest understanding of device and/or network security, and it will be the most probable case for IoT devices.

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Thu, 28 Apr 2016 12:39:39 +0000

I think the goal should be defense in depth. That's why I proposed Manufacturer Usage Descriptions in Buenos Aires. In as much as manufacturers can provide additional clue about how the device should behave that information could be used either to limit or audit device behavior.

Eliot

> On Apr 28, 2016, at 8:25 AM, Василий Долматов <[email-masked]> wrote:
> 
> 
>>