Subject: Re: [core] RawPublicKeys

From: Johannes Gilger <[email-masked]>
Date: Tue, 14 Feb 2012 12:49:04 +0100

Hi everyone,

I'm fairly new to this list, so bear with me if I miss the more subtle
points of IoT security provisioning or topics you might have discussed
outside the mailinglist.

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. 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. 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 20/12/11 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> One possible design that some of you had mentioned to me is to print
> the fingerprint of the public key on the device(sensor) and to then,
> when you introduce the device into your network, to verify the
> fingerprint on the device with the value shown on the server for
> inclusion in the access control list. This works nicely in a smaller
> environment, such as a home network. 
[...] 
> Having public-key derived identities printed on a device presumes that
> a device's public key will never change over its lifecycle. Moreover,
> it assumes that the public key is available prior to printing the bar
> code. 
[...] 
> These devices are assumed to have no trusted platform on board. What
> if someone else clones a device, produces a million copies, and
> pollutes the market place this way (one of the scenarios described in
> draft-garcia-core-security-03 (Section 3.1)). It seems that one is
> just out of luck then.

That is one large problem, if we assume to have no trusted platform on
board. A lot of the things I came up with when looking at IoT security
bootstrapping rely on having a secure chip, at least when
interface-constrained (no display) publicly accessible devices are
concerned.

If we have *no* trusted platform, we can not really generate the key in
advance and print/etch it on the box, as anyone could clone our keypair.
Keep in mind that the printing / reading is an out-of-band channel. 

So now we have to generate our own keypair, which has to happen on the
node itself, since we do not have any interfaces. After the key has been
generated, the node has to transfer the public key to us, using the
wireless link. If we consider devices completely void of any other
interface, there simply is no secure channel to communicate the device's
public key to us.

I think that if we want to be on the safe side, there are two options:

 - A trusted platform with an ECC-keypair which is used as a CGA and
   printed on the case of the device or etched on the chip.
 - Some kind of tamper-evident out-of-band channel, even if its just an
   LED. It just needs integrity, not confidentiality.

Of course, with the first option, the manufacturer has to get the
freshly generated ECC pubkey from the device as well, just like the
user. This is where I trust that it's easier for a large company to
build an actual Faraday cage to ensure no interference than it is for
people employing the technology.

I could go on and talk about how one might need the printed CGA to be
tamper-evident as well, but its obvious that there are many attack
scenarios and possible mitigations.

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), 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Feb 2012 17:49:13 +0200

Hi Johannes, 

thanks for you thoughtful comments; a few remarks inline. 

> In my understanding of the functionality of an interface-constrained IoT

What do you mean by "interface-constrained"? 

> there is no meaning behind any identity as far as the node is concerned.

It depends on your threat model. 

Think about an application where you want to make sure that your video surveillance recording goes to the right server. 

> (as has been discussed)

It again depends what your threat scenario is. 
If your network is access controlled (like many enterprise networks) or the operator of the network charges you for using the network then they definitely want to authenticate someone (typically the subscriber of the service). 

In some other cases this may not be a concern at all. There may be no need for network access authentication. We don't authenticate to many WiFi networks because they are wide open. 

> and that the network can ensure that it is the

There are certainly different threat scenarios that get raised here. In the previous discussion there seems to be a worry that devices get cloned (including their key). As a result, you may end up with two temperature sensors in your home who both use the same public/private key pair, which may be confusing. 

Then, there is the possibility that sensors get tampered with (after they have been put in service).
 
In both cases you typically need physical access to the device. 

So, depending on your assumptions and your usage scenario some of the solutions work or do not work. 

> - The authority can add and modify the ACL (using in-band messages).

For many devices this may be a perfectly fine approach and it is used in today's appliances. 

> asymmetric key will only be needed again if the device is reset.

I also see no problem with using symmetric keys in some scenarios. 

> would like to hear what you guys think,
Ciao
Hannes

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core