Subject: [6tisch-security] 6TiSCH security: start and end states

From: Thomas Watteyne <[email-masked]>
Date: Fri, 13 May 2016 14:37:24 +0200

All,

At the 6TiSCH-sec call yesterday, I was asked to describe what I thought
the start and end states of a "6TiSCH minimal security" solution would
contain. Here it is.

TL;DR:
- start: pairwise PSKs
- end: K2

start state:
- each mote is pre-configured with a key, the same key is written in the
JCE together with its MAC address

end state:
- the JCE has authenticated the mote; the mote has authenticated the JCE
- the JCE has installed (through secure session with the JN) key K2. This
key is then used for link-layer AUTH+ENV CCM*
- the PSK enables a session between the node and the JCE. The JCE uses that
session to send commands to the mote to (1) rotate K2, (2) change PSK

Thomas

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 May 2016 11:56:33 +0300

Thomas Watteyne writes:
> All,
> 
> At the 6TiSCH-sec call yesterday, I was asked to describe what I thought the
> start and end states of a "6TiSCH minimal security" solution would contain.
> Here it is.
> 
> TL;DR:
> - start: pairwise PSKs
> - end: K2

The issue with PSK is that it must be kept secret, meaning it cannot
be printed on the mote, it cannot be shared over the network, when it
is stored in the system that system must be properly secured, meaning
JCE for example requires some kind trusted store which protects all
the keys.

If anybody manages to find security issue in JCE, this might leak out
all the PSK keys used in the network, thus making it very expensive to
clean up the network after the security break.

Also this kind of setup makes it very easy for the manufacturers,
adminstrators or users to misconfigure the system, i.e., configure it
so that it uses just one PSK for the whole network (there are already
several existing examples of that kind of setups in the IoT market).

I described this in the call: Using PSK is like giving them a rope
with nice loop in one end that loop fits nicely for their neck, so
users can very easily use that loop and hang themselves, even when the
instructions of the rope say do not do that. When using raw public
keys we are giving them a stick with small hook, and whatever they do
they cannot use that to hang themselves. Both offer about same
features for normal case, but when misused they have very different
properties.

> start state:
> - each mote is pre-configured with a key, the same key is written in the JCE
> together with its MAC address

If using raw public keys, each mote has a private and public key pair
stored in the device. The hash of the public key and the MAC address
can printed on the side of the device (or distributed over internet).
That information needs to be protected from modifications, but there
is no need for confidentiality for them.

Each mote is pre-configured with the hash of the JCE (or it can
imprint itself to the first JCE it sees after first boot, making the
system completely zero-configuration for the mote).

If someone hacks in to the one mote he can fake to be that device
(just like with PSKs). On the other hand if someone hacks in to the
JCE he will not get credentials for all the motes. During the cleanup
phase after such hack, each mote is given a new hash of the public key
of the JCE, and for all devices which move to new JCE we know there
cannot be attacker between, as the private key of the mote was never
leaked. This cleanup can be done over the air as we can still
authenticate the mote, and know there cannot be attackers in between.
For PSKs we need to go and securely reinstall new PSK for each mote,
and we cannot do that over the air as we do not have anything we can
use to authenticate the mote.

Most of the complains about using raw public keys comes from the cost
of doing public key operations, but if we are planning on doing
Diffie-Hellman anyways, then we are already doing public key
operations, thus there is no reason for using raw public keys for
authentication. Also the public key is only needed in the bootstrap,
and after that we can use K2 to protecte things on the network. 

> - the JCE has installed (through secure session with the JN) key K2. This key
> is then used for link-layer AUTH+ENV CCM*

For raw public keys, the 2nd case there would be to give the mote a
new hash of the JCE public key when the device needs to move to the
new JCE after hacking incident.
-- 
[email-masked]