How to enable message encryption in Contiki / Cooja simulator?

Question

I want to encrypt the messages that are exchanged between sensor nodes.

Can I do it without having access to real hardware sensor nodes, such as Tmote Sky?

Can software encryption/block ciphers only be simulated on Tmote Sky nodes? If I need to use hardware encryption algorithms, then should I have a real sensor node?

Also, I read that for symmetric encryption one must have real sensor nodes, but asymmetric encryption can work with emulated nodes as well?

Any documentation or description would be helpful.

Answer 1

Contiki has LLSEC (link-layer security) layer. This layer is hardware independent, as it uses generic AES driver API instead of directly accessing the hardware. There are multiple AES drivers implemented in Contiki - a software-only version and a couple of hardware accelerated ones, including for CC2420 (the radio chip on Tmote Sky).

The problem with Cooja is that the HW acceleration feature of CC2420 is not implemented in the mspsim emulator. So HW acceleration is not going to work in Cooja as opposed to real Tmote Sky nodes; you must explicitly select the software-based AES driver in configuration:

#define AES_128_CONF aes_128_driver

The bottom line is that AES encryption will work in Cooja, but will be slow.

Now the example configuration of LLSEC - there is little LLSEC documentation around, but the basic setup is described in this README file:

Add these lines to your project_conf.h to enable noncoresec:

#undef LLSEC802154_CONF_ENABLED
#define LLSEC802154_CONF_ENABLED          1
#undef NETSTACK_CONF_FRAMER
#define NETSTACK_CONF_FRAMER              noncoresec_framer
#undef NETSTACK_CONF_LLSEC
#define NETSTACK_CONF_LLSEC               noncoresec_driver
#undef NONCORESEC_CONF_SEC_LVL
#define NONCORESEC_CONF_SEC_LVL           1

NONCORESEC_CONF_SEC_LVL defines the length of MICs and whether encryption is enabled or not.

The important paramter here is NONCORESEC_CONF_SEC_LVL, which corresponds to the IEEE 802.15.4 framer security levels, with numerical values from 0x0 to 0x07.

To enable encryption, set it to 0x4:

#define NONCORESEC_CONF_SEC_LVL 0x4

The other values are:

• 0x00 No security Data is not encrypted. Data authenticity is not validated.
• 0x01 AES-CBC-MAC-32 MIC-32 Data is not encrypted. Data authenticity is validated.
• 0x02 AES-CBC-MAC-64 MIC-64 Data is not encrypted. Data authenticity is validated.
• 0x03 AES-CBC-MAC-128 MIC-128 Data is not encrypted. Data authenticity is validated.
• 0x04 AES-CTR ENC Data is encrypted. Data authenticity is not validated.
• 0x05 AES-CCM-32 AES-CCM-32 Data is encrypted. Data authenticity is validated.
• 0x06 AES-CCM-64 AES-CCM-64 Data is encrypted. Data authenticity is validated.
• 0x07 AES-CCM-128 AES-CCM-128 Data is encrypted. Data authenticity is validated.

To enable both encryption and authentication, set the level to 0x5, 0x6 or 0x7.

Another useful configuration parameter is NONCORESEC_CONF_KEY, the network-wide shared key.

As for the other questions, there is no support for hardware-accelerated asymmetric encryption on sensor nodes. Also, there are no software based implementations for that in mainline Contiki; there is no support (yet) for end-to-end security in general in this OS, as opposed to link-layer security. There are some projects that have developed DTLS and IPSEC for Contiki, but describing that goes beyond this answer.