Subject: Re: [core] RawPublicKeys

From: Alper Yegin <[email-masked]>
Date: Wed, 21 Mar 2012 11:22:34 +0200

Hi Johannes,

Sorry for late response. Please see below.

> 
> On 17/11/11 17:22, Alper Yegin wrote:
>> The above text explains how the network node authenticates/authorizes
>> the device.  But, how does the device authenticate/authorize the
>> network node? For that, the "identity" of the network node's public
>> key needs to be known to the device. But how?
> 
> In my understanding of the functionality of an interface-constrained IoT
> device, there is no need for the node to identify the network.

I can understand "it's not possible", or "it's difficult". But I don't understand how "there is no need."
Device needs to know it's connected to the right "server" 
(being right involves being authenticated and authorized, two really separate things).

> In fact,
> there is no meaning behind any identity as far as the node is concerned.
> 
> The only thing that matters is that the network can identify the node
> (as has been discussed) and that the network can ensure that it is the
> only one able to command the node.

So, a rogue network can do that. "Identify" the victim device, and read from it and write into it.
This is obviously not acceptable.

> This goes beyond what has been
> discussed here, and I may be outside the topic, but it all boils down to
> the Resurrecting Duckling model [1].
> 
> 
> 
> On 21/12/11 11:29, Alper Yegin wrote:
>> The issue I'm raising is that, there story has two sides. We gotta be
>> talking about not only how the network authorizes the device, but also
>> how the device authorizes the network. What you describe above is the
>> former, latter one is missing.
>> 
>> It's not like the device will/shall be OK to talk to anyone who wants
>> to talk to itself. Device needs to authenticate and authorize the
>> other end as well, using ACLs etc. 
> 
> Why not? Looking at the Resurrecting Duckling again, the device will
> talk to anyone when its in the "imprintable" state. After it has been
> imprinted by an authority (hopefully the right one, or you'll have to
> reset the device and try again),

So, knowing the "right one" is the issue.
Who's going to detect this is the wrong one and reset the device? The user.
We cannot assume user will detect and act upon it, if you consider the wide range of IoT use cases.
Users are rarely involved, especially in that capacity.

Cheers,

Alper

> it will identify the network as the
> party which holds the newly agreed symmetric key.
> 
>> How do we introduce the ACL into such devices? There's gotta be an
>> interface for that.
> 
> The ACL is this:
> - The symmetric key agreed with the first party to start imprinting has
>   all the authority.
> - The authority can add and modify the ACL (using in-band messages).
> 
>> Note that this is an issue for asymmetric-crypto. With the symmetric
>> crypto, device can assume whoever holds the same PSK is already
>> authorized hence I don't also need to maintain an ACL. Symmetric
>> crypto has other issues though (e.g., how did you get the PSK here and
>> there?)
> 
> See above. After asymmetric crypto was used to establish a symmetric key
> (using DTLS with ECDHE_ECDSA), the symmetric key will be used and the
> asymmetric key will only be needed again if the device is reset.
> 
> On 22/12/11 10:02, Alper Yegin wrote:
>> Alper> I thought we were trying to solve the problem of "dealing with interface-less devices". 
>> Alper> Maybe we shall re-state the problem statement, if that's not it.
> 
> I think this is what we should be talking about, in this or another
> thread.
> 
> These are my thoughts,
> would like to hear what you guys think,
> Jojo
> 
> 
> [1] - http://www.cl.cam.ac.uk/~fms27/duckling/
> 
> 
> -- 
> Dipl.-Inform. Johannes Gilger
> Research Group IT-Security
> UMIC Research Centre
> RWTH Aachen University
> Mies-van-der-Rohe-Straße 15
> 52074 Aachen
> 
> Office: 211
> Phone: +49 241 80 20781
> Fax:   +49 241 80 22731
> 
> http://itsec.rwth-aachen.de
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Johannes Gilger <[email-masked]>
Date: Wed, 21 Mar 2012 11:09:01 +0100

Hello Alper,

thanks for your comments. I'll try to explain the point I was making
with the last mail. I do suspect my approaches to be naive, and would
like to learn about scenarios where they fail.

> (being right involves being authenticated and authorized, two really separate things).

Yes, for some devices that is true. Lets take for example a plain
lightbulb (with Smart Object capabilities) and a Smart Meter which is
installed by a utility.

The lightbulb has no owner until it is bought and taken from the shelf.
The owner then wants to make sure that the lightbulb listens to him, and
not to his neighbor. The lightbulb does not (and can not) care about
"who" is switching it off and on, so long as it is the same person which
first associated with it.

For a Smart Meter, the relationship might look different on the surface.
After all, a Smart Meter installed at at customers home should only talk
to the correct utility. But then again, when the utility acquires the
Smart Meter from the manufacturer, it could imprint and use it like a
lightbulb, before installing it at the customer.

> This is obviously not acceptable.

The assumption here is that the Smart Object is in one of two global
states: Imprintable or Imprinted. The rogue network can simply imprint
itself in the Smart Object it if is able to reset the device or if it is
"faster" than the legitimate operator for the first imprinting process.

Both attack vectors can be controlled. If you buy a new lightbulb and it
does not listen to you, you will reset it and try imprinting again. At
some point you'll hopefully succeed (because your neighbor gave up).

If you have imprinted a device and don't want it to be reset, you have
to take measures to prevent just that, like mounting the device so its
inaccesible or simply omitting a reset button.

> Users are rarely involved, especially in that capacity.

I am not sure. What is probably clouding my judgement is that I know so
few actual end-to-end real-world applications for Smart Objects, which I
hope will change with the Smart Object Security workshop.

Regards,
Jojo

Office: 211
Phone: +49 241 80 20781
Fax:   +49 241 80 22731

---

From: Rene Struik <[email-masked]>
Date: Wed, 21 Mar 2012 11:00:53 -0400

Hi Johannes:

Provisioning usually involves both authentication and authorization. Cryptography takes care of the authentication aspects and would result in evidence to each of the devices involved (imprinter, imprinted) of each other's identity {in case authentication would involve an authenticated public-key key agreement scheme). Authorization can be dealt with via cryptographic tools only if the authentication protocol would include exchange of credentials from which authorization privileges can be inferred (e.g., via incoding hereof in policy attributes of a certificate). For large scale networks, this is inflexible, since this requires coordination beforehand. The more likely scenario would be to have some human decision element here, who influences authorization decisions, e.g., via 
(1) location-limited channel {Diana Smetters et al}: here, only devices in close proximity would successfully complete the protocol, the idea being that the user can control devices lingering around close to devices in play;
(2) mechanism for communicating by device of true id of the other device it communicated with, e.g., via display, beep pattern, light flashes {by bulb in question}, etc., followed by ack/nak by human (the infamous button-push scenario);
(3) etc.

Reset of a device to initial state is a transition in the trust lifecycle of device and should be managed accordingly. As an example, pressing a tiny reset button (similar to the one on my Wifi router at home) may not provoke this reset, if my state machine transition is triggered by more than just physical access to the device and would require, e.g., receipt of a properly formatted command to reset from an authorized device (i.e., one with the proper device role privileges) as well (or by the latter only).

We can discuss more Friday.

Best regards, Rene

==

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

---

From: Alper Yegin <[email-masked]>
Date: Wed, 21 Mar 2012 17:20:41 +0200

Hi Johannes,

> inaccesible or simply omitting a reset button.

See, these all have implications to provide "complete security", such as:
- A test is needed. The later the test, bigger the vulnerability as rogue operation cannot be detected until that. And test takes time. User jiggles few things, and possibly gives up and leaves the bulb in place for hours, days… There won't be a warning that says "if the bulb is not responding, remove it immediately, it may be compromised!".
- Lack of a reset button means someone can decommission the device by simply imprinting it before the victimized owner. No reset button, so the device is a brick now.
- Physical security (unreachable device).

My point is, having certs in place does not provide a complete solution for security.  

Alper

---

From: Johannes Gilger <[email-masked]>
Date: Thu, 22 Mar 2012 10:17:29 +0100

Hi Alper,

> See, these all have implications to provide "complete security", such as:
Yes, I've been making a few assumptions for this specific class of
devices.

> - A test is needed. The later the test, bigger the vulnerability as
> rogue operation cannot be detected until that. And test takes time.
> User jiggles few things, and possibly gives up and leaves the bulb in
> place for hours, days… There won't be a warning that says "if the bulb
> is not responding, remove it immediately, it may be compromised!".
OK, that could be a problem. But then again, one has to look at the kind
of devices and the combinations of the techniques I described here. For
example, some lightbulbs come with a big warning to not touch the glass
with your bare hands, which seems to work out fine. Likely, a Smart
Object lightbulb could say "If not responding within 30 seconds, unscrew
lightbulb within 5 minutes to avoid permanent damage".

A lightbulb is probably even a bad example if we assume that it is
installed in a private room. If it is, then it can have a small physical
reset button, and we can simply use the Resurrecting Duckling model to
reset and re-imprint it until we are successfull.

> - Lack of a reset button means someone can decommission the device by
> simply imprinting it before the victimized owner. No reset button, so
> the device is a brick now.
Yes, as I described for this case, one would need a grace period during
which the device can simply be rebooted without any imprinting becoming
permanent.

Obviously this kind of imprinting scheme can be dangerous if used by
inexperienced users. But it seems to work fine today. If you forget your
BIOS supervisor password, your mainboard and hard-drive have to be
replaced. Likely, there are features to disable password recovery for
network switches (the story of this SF network operator who hard-locked
everyone out of the city's Cisco hardware), yet nobody is complaining
about this feature.

So, looking at the Smart Meter application, we can safely assume that
the people imprinting the credentials at the utility company know how
the process works, and won't leave a device plugged in if for some
reason someone else was able to implement himself first.

> My point is, having certs in place does not provide a complete solution for security.  
No, certainly not, and I don't want to come across as making that claim.
I have just been thinking a lot about imprinting schemes for (very)
interface-constrained devices and wanted a reality check.

Regards,
Jojo

Office: 211
Phone: +49 241 80 20781
Fax:   +49 241 80 22731

---

From: Robert Cragie <[email-masked]>
Date: Fri, 23 Mar 2012 11:44:20 +0000

Hi Rene,

I agree with what you say and to Alper's point that certs. cannot be the 
only mechanism for authentication and thus implicit authorization. There 
invariably has to be some additional factor (human, OOB) and the 
practicality of that factor depends on the scenario.

Apologies I couldn't make the workshop - it was announced quite late and 
I had already made plans. Hope to catch up with some of you in Paris to 
discuss the findings.

Robert