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!

[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)

[FotoFieber]

@alexsh1
@Anticimex

Just tried

#define MY_RADIO_NRF24
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_RF24_ENABLE_ENCRYPTION

This was working in the old dev branch but doesn't work for me anymore. Did you have luck with the combination of signing and encryption?

n׌�Ox>�XܚMZ������t��ֵ���<��
�=�a�WY=��VP����E�P�pStarting repeater (RNNRAS, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=15)
TSM:FPAR
TSP:MSG:SEND 15-15-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-15 s=255,c=3,t=8,pt=1,l=1,sg=0:0
Skipping security for command 3 type 8
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=15)
TSM:UPL
TSP:PING:SEND (dest=0)
Skipping security for command 3 type 24
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-15 s=255,c=3,t=25,pt=1,l=1,sg=0:1
Skipping security for command 3 type 25
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
Signing required
Skipping security for command 3 type 15
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=1,st=fail:0101
Failed to transmit signing presentation!Waiting for GW to send signing preferences...
TSP:MSG:READ 0-0-15 s=255,c=3,t=15,pt=6,l=2,sg=0:0101
Skipping security for command 3 type 15
Mark node 0 as one that require signed messages
Mark node 0 as one that do not require whitelisting
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,ft=2,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,ft=4,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=0:972DE10483D0864680CE821987E5823ABAEF8435F971670F04
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F00060310FF
Current nonce: 972DE10483D0864680CE821987E5823ABAEF8435F971670F04AAAAAAAAAAAAAA
HMAC: 7922F4E571510EC46BD3CAAF37A1C1627BAE2562BA0ADC210173076854649826
Signature in message: 0122F4E571510EC46BD3CAAF37A1C1627BAE2562BA0ADC2101
Message signed
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=0:59321F17D680FFDC461270BD2C22F77FBC6FF6DE90DD9A34E6
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F00060310FF
Current nonce: 59321F17D680FFDC461270BD2C22F77FBC6FF6DE90DD9A34E6AAAAAAAAAAAAAA
HMAC: 09031876715AD7ADBC81671982D07A46122D564110C59880AB733AACB111289E
Signature in message: 01031876715AD7ADBC81671982D07A46122D564110C59880AB
Message signed
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=16,pt=0,l=0,sg=1,ft=6,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=16,pt=0,l=0,sg=1,ft=8,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:24AB30408F0D10A7DB4CE357B22C908ED2438638C567DF52AE
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F00060310FF
Current nonce: 24AB30408F0D10A7DB4CE357B22C908ED2438638C567DF52AEAAAAAAAAAAAAAA
HMAC: C2B0487B88AD8AE2FD7FB63C21E841324ED48975681EB881A7EC556D74637B33
Signature in message: 01B0487B88AD8AE2FD7FB63C21E841324ED48975681EB881A7
Message signed
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:4CDF80D7AAF5358B4DA616FBB1556569F68818F331C6C681F3
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F00060310FF
Current nonce: 4CDF80D7AAF5358B4DA616FBB1556569F68818F331C6C681F3AAAAAAAAAAAAAA
HMAC: C12B5B8BD5EA6DD142908FBB02A06933E3FFBC399876B8B52E30BA9A1A66B4FC
Signature in message: 012B5B8BD5EA6DD142908FBB02A06933E3FFBC399876B8B52E
Message signed
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=1,c=3,t=16,pt=0,l=0,sg=1,ft=10,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 15-15-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:0EEFA88D4FB45539A0B20C586D989BF510FC83F270ABEC3E2A
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F0006031001
Current nonce: 0EEFA88D4FB45539A0B20C586D989BF510FC83F270ABEC3E2AAAAAAAAAAAAAAA
HMAC: 2AEEC1974BF5ED7DE100A555DD98E420E5CA0C33918F8BEFF3524B1FED047C52
Signature in message: 01EEC1974BF5ED7DE100A555DD98E420E5CA0C33918F8BEFF3
Message signed
TSP:MSG:READ 0-0-15 s=255,c=3,t=8,pt=1,l=1,sg=0:0
Skipping security for command 3 type 8
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=15)
TSM:UPL
TSP:PING:SEND (dest=0)
Skipping security for command 3 type 24
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-15 s=255,c=3,t=25,pt=1,l=1,sg=0:1
Skipping security for command 3 type 25
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
Request registration...
Skipping security for command 3 type 26
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=1,st=fail:2
TSP:MSG:READ 0-0-15 s=255,c=3,t=16,pt=0,l=0,sg=0:
Skipping security for command 3 type 16
Signing backend: ATSHA204Soft
SHA256: 23DD90319EEA644480F44B15B3A95D6B20AD8380A953D40C7600000000000000
Skipping security for command 3 type 17
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=17,pt=6,l=25,sg=0,ft=2,st=fail:23DD90319EEA644480F44B15B3A95D6B20AD8380A953D40C76
Failed to transmit nonce!
TSP:MSG:READ 0-0-15 s=255,c=3,t=27,pt=1,l=1,sg=1:1
Signature in message: 011EA3852B9E54EF00F415B0A6121E25B32B9C5F976A090B
Message to process: 000F0E231BFF01
Current nonce: 23DD90319EEA644480F44B15B3A95D6B20AD8380A953D40C76AAAAAAAAAAAAAA
HMAC: 611EA3852B9E54EF00F415B0A6121E25B32B9C5F976A090BF2C96E0C02F28D72
Signature OK
Node registration=1
Init complete, id=15, parent=0, distance=1, registration=1
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=2,c=3,t=16,pt=0,l=0,sg=1,ft=3,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:AA800D53018F5EAFCD48C21D3F702501539BFE5DF7E008B204
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F0006031002
Current nonce: AA800D53018F5EAFCD48C21D3F702501539BFE5DF7E008B204AAAAAAAAAAAAAA
HMAC: 2E1247A4A77CA0767BFD16B9A1FCE401EF39B4D76FA6A96EF0978CE322271A6F
Signature in message: 011247A4A77CA0767BFD16B9A1FCE401EF39B4D76FA6A96EF0
Message signed
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=3,c=3,t=16,pt=0,l=0,sg=1,ft=5,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:358C0D190097ABD8AB64BF680AF252EAC6036B73222A854502
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F0006031003
Current nonce: 358C0D190097ABD8AB64BF680AF252EAC6036B73222A854502AAAAAAAAAAAAAA
HMAC: 4A209EA1B12FB01659122DD26F2F3FB7EC15439DDEFEA90813AA0E8F87321683
Signature in message: 01209EA1B12FB01659122DD26F2F3FB7EC15439DDEFEA90813
Message signed
Ping: 60 cm
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=1,c=3,t=16,pt=0,l=0,sg=1,ft=7,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:0677F380706F11E12CFC0C43FE9559F36D8FDAEB6854836E06
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F0006031001
Current nonce: 0677F380706F11E12CFC0C43FE9559F36D8FDAEB6854836E06AAAAAAAAAAAAAA
HMAC: 5E895658E4C08BCE1D6B5FC560D1AA608AB2AEDF9385EA80ABA1EDD8EE003EE5
Signature in message: 01895658E4C08BCE1D6B5FC560D1AA608AB2AEDF9385EA80AB
Message signed
Send button 1 pressed
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=4,c=3,t=16,pt=0,l=0,sg=1,ft=9,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 15-15-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:EE3BFA6BFDD922BB892AC9A1BF2079803D8C3C258B18DFA29B
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F0006031004
Current nonce: EE3BFA6BFDD922BB892AC9A1BF2079803D8C3C258B18DFA29BAAAAAAAAAAAAAA
HMAC: 7BEF3C478AD984729ED9A2717575A5325E66EF4C0CC9D3D761A1886A4BF4C4FD
Signature in message: 01EF3C478AD984729ED9A2717575A5325E66EF4C0CC9D3D761
Message signed
TSP:MSG:READ 0-0-15 s=255,c=3,t=8,pt=1,l=1,sg=1:0
Skipping security for command 3 type 8
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=15)
TSM:UPL
TSP:PING:SEND (dest=0)
Skipping security for command 3 type 24
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-15 s=255,c=3,t=25,pt=1,l=1,sg=1:1
Skipping security for command 3 type 25
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
Send button 1 pressed
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=4,c=3,t=16,pt=0,l=0,sg=1,ft=1,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:9069C5ABD4E3E13F19A92D0B708ABB41C809B6D67654357C61
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F0006031004
Current nonce: 9069C5ABD4E3E13F19A92D0B708ABB41C809B6D67654357C61AAAAAAAAAAAAAA
HMAC: 01CCD77E9CC961B65E896180243DAB5E9174C0B88032D38261ED78BB619A00EF
Signature in message: 01CCD77E9CC961B65E896180243DAB5E9174C0B88032D38261
Message signed
Skipping security for command 3 type 16
!TSP:MSG:SEND 15-15-0-0 s=2,c=3,t=16,pt=0,l=0,sg=1,ft=3,st=fail:
Failed to transmit nonce request!
!TSP:MSG:SIGN fail
TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:1B94EC3D5354C0431C3D49CEC8903433984E2DE5D04F2D00DD
Skipping security for command 3 type 17
Nonce received from 0. Proceeding with signing...
Signing backend: ATSHA204Soft
Message to process: 0F0006031002
Current nonce: 1B94EC3D5354C0431C3D49CEC8903433984E2DE5D04F2D00DDAAAAAAAAAAAAAA
HMAC: D46DFC8ACCEE0FA7E6D282E8556F9EC7659804AD3D33163E9522F7769449F809
Signature in message: 016DFC8ACCEE0FA7E6D282E8556F9EC7659804AD3D33163E95
Message signed
Ping: 61 cm
Ping: 60 cm
Ping: 60 cm
TSP:MSG:READ 12-12-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
TSP:MSG:BC
TSP:MSG:FPAR REQ (sender=12)
TSP:PING:SEND (dest=0)
Skipping security for command 3 type 24
!TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=5,st=fail:1
TSP:MSG:READ 0-0-15 s=255,c=3,t=25,pt=1,l=1,sg=0:1
Skipping security for command 3 type 25
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSP:MSG:GWL OK
TSP:MSG:SEND 15-15-12-12 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=6,st=ok:1
Ping: 60 cm

[Anticimex]

Not sure if it is a typo or now but you list
#define MY_SIGNING_ASOFT but it should be #define MY_SIGNING_SOFT

In any case, you get st=fail which mean your radio setup is basically not working.
For any security to work, messages has to get through, and from your log, they don't:
"Failed to transmit signing presentation!"
"Failed to transmit nonce request!"
So I think from the log that signing and encryption is working, but occasionally you get messages dropped due to a poor radio link which manifests itself as failed transmissions.

[lyndaeldo]

If implemented correctly, AES is AES; the output between two different implementations is identical, and therefore no distinction is possible in after-the-fact comparison -- if done correctly, the one is exactly the same as the other.

But there are a few points where differences can crop in:

Operation Mode
Truecrypt implements a modified counter mode called XTS. It's pretty well vetted and has withstood some serious abuse from some powerful attackers (such as the US Government).

From examining the p7zip source code, it appears that AES encoding for the 7-zip format operates in CBC mode. This is certainly not necessarily insecure; it's the mode most popularly used in protocols such as TLS, but it is potentially vulnerable to padding oracle attacks. See this discussion on operation modes for more information.

Key Derivation
Truecrypt uses PBKDF2 to turn your password into an encryption key. It's difficult to come up with a better alternative than that. p7zip uses a salted SHA256 hash repeated over a configurable number of iterations. PBKDF2 is a bit more configurable, but 7-zip's alternative is functionally similar and arguably reaches the same goals.

[FotoFieber]

@Anticimex
Sorry for the typo.

Interestingly, the sketch is working perfect without signing.

I will try to add another power source and try again.

Do you have a working setup with encryption and signing?

[Anticimex]

@FotoFieber When you use signing, the max message size is used, and this strains the rf link the most. Signing is still not your problem. It is clear from the log that messages fail to transmit, and that is a radio problem.

[alexsh1]

@Anticimex @FotoFieber

We have been through this a few times. Just a suggestion - shall we do an FAQ link explaining what you have just said (st=fail is a problem of radio and not singing). Ingerestingly enough I did not manage to resolve this issue with the Sensebender. I still get several fail to transmit nonce before it starts working fine. Only the Sensebender. All other nodes work flawlessly

[Anticimex]

@alexsh1 It is already documented where all signing is documented:
https://ci.mysensors.org/job/Verifiers/job/MySensorsArduino/branch/master/Doxygen_HTML/group__MySigninggrp.html

Check the troubleshooting section for details. Link to all documentation is on the github frontpage and on the "head" post of the signing topic on this forum.

[alexsh1]

@Anticimex OK, that's super. I think we all became victims of nrf24l01+ terrible fake copies. Some of these work OK until....
Then a woodoo dance has to be performed (highly recommended) in order to make them work again.

[Anticimex]

@alexsh1 Don't forget the goat sacrifice

[FotoFieber]

I have tried a different setups now

• Arduino Mega2560, Arduino Uno
• different NRF modules from different vendors, with and withoud amplifier, with different capacitors
• different power supplies

I always end up getting st-fail, even with encryption only. But it is working even with these fails...

@Anticimex
You have a working setup with encrpytion and the actual libraries from github without st-fail?

Next tests:

• change NRF and power supply on the gateway
• and if all that doesn't help: make a setup without encryption

[Anticimex]

@FotoFieber No, I have no set up at all for the moment. But I have been using both encryption and signing yes. And I can tell you again (and again and again) that st=fails has nothing to do with signing or encryption. Unless you don't use the same AES key for your nodes because if the message is encrypted, it is jibberish to the receiver and NRF does not natively support encryption so I don't thinnk it will be able to ack properly. I trust you are sure you have your keys properly configured per the instructions for version 2.0.0?

[FotoFieber]

@Anticimex
I have a very reduced sketch now (sending millis() every second) and yes, I have configured the keys as it should be.

As long, as nobody can prove with a concrete setup, that with the actual git-version (with encryption and NRF24L01) it is working without st-fail, the possibility exists, that it there is a bug.

[Anticimex]

@FotoFieber No. At least not for signing. As st=fail is something set by the transport/radio layer and signing has nothing to do with that. Encryption I discourage from using (detailed in the documentation) since it provides little benefit in the form used here.

[FotoFieber]

@Anticimex
As the bug is there even with encryption only, it can't be in the signing code.

For privacy concerns, signing is no solution.

[Anticimex]

@FotoFieber Neither is encryption for NRF24 as it does not use IV:s. And the data you encrypt is predicable so the key can be derived quite easily, effectively eliminating the "protection" the encryption is supposed to give.

[FotoFieber]

@Anticimex
No IV? Then the AES Transport implementation is not secure, more ore less an obfuscation...

Is this a known bug, that will be fixed?

[Anticimex]

@FotoFieber it is a known limitation and is currently not in scope for improvement for nrf24 because it require reliable sync which nrf radios are notoriously bad at providing. If you have an idea on how to fix it, a pr is always welcome

[FotoFieber]

Hm, I am not an encryption expert. What about a Diffie-Hellmann key exchange and then use the key as IV?

[Anticimex]

Me neither. I care about security, not obscurity. I see no reason to encrypt a '1' or a '0' and digital streams like audio and video is not supported anyway. But exchange of constant (but random) data is already used and supported since signing is based on nonce exchange. But I believe IV:s "evolve" with the messages encrypted which implies the messages need to be exchanged trustworthy and sender and receiver need to be om sync. But I know to little about that to be sure.
In any case, I welcome any development that adds to security, and will happily review such code, but I don't have the bandwidth nor motivation to "drive" the development of encryption in the core library as I don't feel it adds enough value to be worth the effort.