[6lowapp] 6LOWAPP Commissioning Method

["Oflynn, Colin" <[e-mail]>]

Hello All,

I only just joined 6lowapp, so I caught up by reading the archives a bit. I didn't see any previous discussion of commissioning, besides a very quick security discussion. I apologize if this is thus already discussed somewhere I missed! I was working on the commissioning problem on the IPSO side, and was just directed to 6lowapp. 

I had some questions on the fundamental assumptions of commissioning:

> 1) Duckling mode. One Device is put in a "mother duck" mode where it
>      listens for broadcasts of Devices trying to imprint.

I'm assuming this is based on http://www.cl.cam.ac.uk/~fms27/duckling/ (The Resurrecting Duckling). 

As described, the method isn’t highly secure. The main problems are:

1)	If you just add whoever is in ‘imprint’ mode, it is easy for an attacker to add themselves to your network.

2)	How to put nodes in duckling mode? The paper mentions maybe having a ‘master key’ who can do this.

Wi-Fi Protected Setup (WPS) helps get around some of these problems by having a push-button and LED. The button puts the node into either mother or duckling mode (depending on node type), and an LED lets the user see which two nodes are going to connect. 

>2) Out of Band Key mode. Each Device in manufactured with an initial
> symmetric key physically printed on the side in numeric and barcode
>  form...

This is similar to WPS’s PIN-based entry. The issue with that was many nodes which could run 6LoWPAN will physically be too small to have labels legibly printed on them. Further having labels which must agree with a preprogrammed key would increase manufacturing cost, and there is a problem with labels being knocked off. WPS gets around this by having nodes being able to generate their own PIN and displaying it on an LCD, but most 6LOWPAN nodes would be too cheap  for this.

There is a security threat too: let’s say you have a ‘secure’ network. An attacker has physical access to your end nodes, but not to the central station which authorizes new nodes to come online. For many application this would be a reasonable assumption I would think. They could just put a label with a different key on your end node, then drain the batteries from the node or do something else that would force a maintenance operation. When the node is being ‘fixed’ it will be put back on the network, but really you’ve just opened up your network to an attacker.

> 3) Certificate mode. Each Device is manufactured with a certificate
 >  with an asymmetric key. The fingerprint of the certificate is printed

Similar issues to labels above, but since it’s optional it could be deployed where manufactures specifically see it as an advantage. The issue with the first two is they are mandatory.

> no public key cryptography to support
> modes 1 and 2 and additional crypto profile with public key
> cryptography for support of mode 3

I also see that only mode 3 will use Public-Private exchange. Should method 1 not require a public-private exchange, as I know of no other way to secure a hostile channel? You can use ECC encryption which is pretty light-weight (less than 3K ROM, 300 bytes SRAM).

If a node is too small to run ECC it has no business doing an In-Band key exchange. Passive listening on RF networks is far too easy and impossible to detect. Man In The Middle and other attacks at least need the attacker to do something detectable mostly. It’s not just an issue of someone by chance listening when you do the setup. The problem is they could easily purposely force one node off the network by selective jamming, and waiting until maintenance personal reset or replace the node and do a new key exchange. 

Was any consideration given to an Out Of Band (OOB) exchange method? Something like using IR (either IrDA or discrete IR), or even a very simple physical connection. It would almost guarantee a secure key exchange, have little code overhead, and physical connection can be used to power parasitically-powered nodes which might not be able to go through lengthy configuration processes. As well it would lend itself to a small ‘widget’ being used to authorize nodes, such as a cheap pen-sized tool with some smarts in it. 

Regards,

  -Colin O’Flynn

PS: I have some information I wrote down for IPSO about Security problems & Commissioning problems I could try to post somewhere 6LOWAPP would have access to them as well.