software AES encryption for NRF24

[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 :(

[ximinez]

@FotoFieber said:

@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... :(

Old thread, but... In the dev branch, there's a RF24 refactor that is much smaller. With that, and removing test-mode, there's plenty of space on the sensebender:

#define MY_RADIO_NRF24
#define MY_SIGNING_ATSHA204
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0xBO,0xGU,0xSK,0xEY,0xZZ,0xFC,0xAD,0x04,0xD1}}}
#define MY_OTA_FIRMWARE_FEATURE
#define MY_RF24_ENABLE_ENCRYPTION

Sketch uses 23,196 bytes (75%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,386 bytes (67%) of dynamic memory, leaving 662 bytes for local variables. Maximum is 2,048 bytes.

Even with debug it's only at 91%.

My W5100 gateway ends up at 107% with AES though, but it fits (with 592 bytes to spare) if I use a static address instead of DHCP.
Serial Gateway ends up at only 65%.

[alexsh1]

@ximinez RF24 refactor - do you mean RF24 inside the MySensors folder? I tried it but still out of luck:

Sketch uses 31,396 bytes (102%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,762 bytes (86%) of dynamic memory, leaving 286 bytes for local variables. 

[Anticimex]

@alexsh1 from development branch, not master. 2.0.0-beta. Rf24 driver on that branch has been significantly optimized (together with other parts of the library).

[alexsh1]

@Anticimex Thanks for heads up - I think I messed up different versions though I remember unpacking "Arduino-development". I deleted the whole folder and unzipped the files again and voila:

Sketch uses 28,228 bytes (91%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,462 bytes (71%) of dynamic memory, leaving 586 bytes for local variables. Maximum is 2,048 bytes.

UPDATE: It turned out DEBUG took a lot of memory (DEBUG AND SIGNING DEBUG)