software AES encryption for NRF24

[fleinze]

Hey there!

I really wanted my over-the-air data to be encrypted. As I have a powermeter sensor, I basically broadcast detailed energy usage-statistics, which is a bit more privat than temperatures.
The encryption is done with a copy of the MyTransportNRF24.h library. This copy is named MyTransportNRF24ENC.h All the data that is sent and received is encrypted respectively decrypted.
Check it out:
https://github.com/fleinze/MySensors/tree/Encryption/libraries/MySensors
To use it you need to replace the MyTransportNRF24.h with MyTransportNRF24ENC.h and the MyTransportNRF24-constructor with MyTransportNRF24ENC.
If you want to try it yourself please download all files, because it is based on a fork I use.
For encryption the AES-library of spaniakos is used:
https://github.com/spaniakos/AES

The encryption uses an additional 3400 bytes of flash, so it could get a bit tight for an ethernet-gateway.

This encryption is a all-or-nothing thing. You can't mix encrypted and unencrypted nodes. OTA-update is not possible with this, because the bootloader expects unencrypted messages.

Identical messages create identical encrypted messages. To prevent a replay attack you need to use message signing.

[Anticimex]

Interesting stuff! But I suppose the routing would be sketchy if one of the nodes listens in and can't do decryption, right? In any case, it should be possible to take this into the library as a #define:able feature for those who use rf24 and can live with the drawbacks in memory and strict uniformity.

[Anticimex]

In any case it is great work! And @hek is getting impressive results with library refactoring so it might be possible to squeeze this in an ethernet gw as well. Possibly with signing added for better entropy. 👍

[hek]

Thanks @fleinze .

I'll add it (but enabling it using defines).

[Anticimex]

Since we now have the potential to do AES encryption in SW, will consider adding support for atmels AES crypto chip as well so we get an hw option similar to the atsha204 so we get symmetry. SW AES is vulnerable to memory dumps since the key would be stored in flash (similar to SW signing and also the AES support in rf69). Bugger, I who thought I finally could begin focusing on my own sensor network :)
@fleinze, perhaps you would consider looking into that? I would imagine a lot of similarities in design with atsha204 but since it is symmetrical crypto, personalization and SW would be much less complicated than the signing. I don't know if nonce would be meaningful to bother with since one could just add signature to the messages to get that like you said.

[hek]

Ok, added here: https://github.com/mysensors/Arduino/commit/5c39f022c0db5e0280be1c1412f51be7d435cd60

Let's look at the worst-case gateway

ENC28J60 gateway without encryption enabled

Sketch uses 25,648 bytes (79%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,169 bytes (57%) of dynamic memory, leaving 879 bytes for local variables. Maximum is 2,048 bytes.

ENC28J60 gateway with encryption enabled

Sketch uses 29,078 bytes (90%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,502 bytes (73%) of dynamic memory, leaving 546 bytes for local variables. Maximum is 2,048 bytes.

To use it in sketch, do something like this (note gateway-refactoring-branch):

// Enable and select radio type attached
#define MY_RADIO_NRF24
#define MY_RF24_ENABLE_ENCRYPTION
#define MY_RF24_ENCRYPTKEY 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x10,0x11,0x12,0x13,0x14,0x15,0x16

#include <MySensor.h>  

#define CHILD_ID 1  
MyMessage msg(CHILD_ID, V_TRIPPED);

void setup()  
{ 
  sendSketchInfo("Motion Sensor", "1.0");
  pinMode(DIGITAL_INPUT_SENSOR, INPUT);     
  present(CHILD_ID, S_MOTION);
}

void loop()  
{ 
  boolean tripped = digitalRead(DIGITAL_INPUT_SENSOR) == HIGH; 
  send(msg.set(tripped?"1":"0"));  // Send tripped value to gw 
  sleep(INTERRUPT,CHANGE, SLEEP_TIME);
}

[Anticimex]

Cool. What happens if you also add SW signing. To make it a really "bad" case?

[hek]

ENC + encrytion + soft-signing fails :(

Sketch uses 34,244 bytes (106%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,912 bytes (93%) of dynamic memory, leaving 136 bytes for local variables. Maximum is 2,048 bytes.

[Anticimex]

Well, it is the worst possible case. Perhaps hw signing fits.

[scalz]

actually, I prefer usb but it could fit easily in mysensors wifi gateway..
nice work!

[fleinze]

Wow, thank you all for your overwhelming feedback!
@Anticimex: in your first reply you asked about routing. This is not a problem, as all nodes share the same encryption key and the whole packet is decrypted by any relay node, handled and re-encrypted. As the relay node changes the first byte of data, some extra entropy is added as well.
I decided to encrypt the whole packets because AES has 16byte block size which works good with the 32byte size limit of the NRF-packets. Just encrypting the payload on the other hand would limit the payload-size to 16bytes.

I also took a look at the ATAES132-chip. The chip offers AES-CCM for encryption and authentification. Using the DECRYPT command on the chip we would need to provide a valid 16-byte MAC-key (which is calculated using the encrypted data and other authenticate-only data bytes). If we don't want to change the protocol to add encrypted MAC-exchange for each packet this is not an option.
The chip also offers a LEGACY-command which is supposed to be used for encryption and decryption. Normally encryption and decryption are different operations, so I still need to find out what the LEGACY-command does.

[Anticimex]

@fleinze yes, exactly. My point was that (like you said) ALL nodes in the network have to support encryption/decryption if it is to work beyond strict ad-hoc communication.
Regarding the Atmel chip, yes that is something to think about. I don't have the bandwidth to fix that myself within reasonable time right now but as long as the keys are properly protected, I do think legacy support is adequate. But like you I have not looked into that further. The way I see it, the signing system takes care of that part, and encryption can be added to add obfuscation to the process.
Also, to me it is important that SW and HW alternatives are interchangeable and that mean the encryption MAC stuff has to be ported in SW as well and the things start spiralling out of hand. And ideally, it should be compatible with the rf69 encryption scheme as well which I believe is the same as "Atmel legacy" and your SW approach here.

[tbowmo]

Interesting thing that atmel chip. It seems that it's a direct replacement for the onboard flash chip used on the sensebender, pin wise that is. As it's an eeprom, commands might be different than the ones we use for the flash now.

[Anticimex]

@tbowmo Yes, I also noticed that. Made me space out thinking about the possibilities to replace the SPI flash we currently use for one of the bootloaders OTA solution. And legacy encryption might be so cheap it will fit the bootloader as well as I believe all IO commands to the chip uses the same basic read/write operations so adding a decryption call of a message would not cost may bytes if the IO functions are there anyway.
It would also mean it is a drop-in replacement for the memory in your upcoming gw as well as my upcoming sensorboard :) And although I don't have the time to indulge myself too much in implementation for the moment, just knowing that it won't require a new PCB is encouraging. And it might also perhaps encourage someone with the time to spare who happened to have a sensebender to do a little rework and test it out :) And if nothing else, I might do it myself eventually. But don't expect it for 2015, and perhaps not even 2016 :( I am then leaving the country and will set up shop in your hood :) and after the dust settles I can start MySensoring more seriously hopefully.

[FotoFieber]

Compiling AES with an ESP8266 fails. I had to change AES_config.h (in drivers/AES):

#include <pgmspace.h>

instead of

#include <avr/pgmspace.h>

[hek]

@FotoFieber said:

Compiling AES with an ESP8266 fails. I had to change AES_config.h (in drivers/AES):

#include <pgmspace.h>

instead of

#include <avr/pgmspace.h>

Thanks, I'll fix.

[FotoFieber]

@hek

@hek said:

ENC + encrytion + soft-signing fails :(

Sketch uses 34,244 bytes (106%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,912 bytes (93%) of dynamic memory, leaving 136 bytes for local variables. Maximum is 2,048 bytes.

Yesterday I made a setup with a ESP8266 gateway and a mega2560 as a secure relay actuator with encryption and signing. There are quite small mega2560 but a sensbender mega2560 would be desireable. :)

ENC + encryption + soft signing is working! :relaxed:

[Anticimex]

@FotoFieber with a SenseBender, there is no reason for soft signing. It should have a ATSHA204A chip. But nice that you have working setup :)

[FotoFieber]

@Anticimex said:

@FotoFieber with a SenseBender, there is no reason for soft signing. It should have a ATSHA204A chip. But nice that you have working setup :)

Yes, but encryption and ATSHA204A is to big for the SenseBender... :(

[Anticimex]

@FotoFieber ah. Bummer :(