Enable RF24 Encryption with mysensors V2.x

[Rafifi]

Hello,

I have just update my network to mysensors 2.0 and my network is growing up. I think its time to secure it. First, I've changed the channel of RF24, then I've uncommented the line "//#define MY_RF24_ENABLE_ENCRYPTION" in MyConfig.h file.

It's also noticed "and all must be personalized with the same AES key". But where can I setup this AES key and which format for it ?

Thanks

[Marik]

I am also interested in taking this next step, thanks for bringing it up.

[Anticimex]

This is done using the security personalizer sketch. The doxygen documentation describes the steps under the signing chapter.

[Anticimex]

@Rafifi please be advised that encryption for that radio is purely sw based and is not using initialization vectors so it is technically possible to derive the key and the encryption is quite weak. And in a mysensors context, encryption provide very little security anyway as the data being sent is quite predictable. It only provide obscurity. Signing provide authenticity which is more important. I'd suggest you start with that. Adding encryption on top of the signing would at least theoretically provide somewhat better obfuscation as the messages will be more random if you insist on using encryption. But encryption by itself provide more the illusion of security than actual security. Especially for nrf24 radios.

[Rafifi]

Thanks ! I finally successed to use signing but it was quite difficult because I speak just a little bit english and The only step by step guide that I've found is for mySensor V1.5 and not for 2.0.

My difficulty comes that I didn't understand that I had to flash EEPROM with Keys(with SecurityPersonnalizer.ino) and then flash my sketch. Finally, I added in Gateway and Sketches these lines

#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES

And now it works !!

I've just noticed some communication errors sometimes... Perhaps it's because signing protocole needs more messages exchanges
between nodes and gateway.

[Anticimex]

@Rafifi you can find step by step guide in doxygen as mentioned in this thread and on the github repo Readme and on the forum topic about signing. In those guides you will also find a troubleshooting section which informs you that enabling signing will cause messages to be sent with maximum payload size and this puts the maximum strain on the rf link which can manifest itself in transmission errors. Those errors are not signing related but indicate a less than ideal rf connection.

[Nicklas Starkel]

Hello,

Before I do anything stupid
I followed the documents but want to clarify so...
I used SecurityPersonalizer.ino and uploaded it to a node.
The results were just a bunch of "FFFFFFFFFFFFFFFFFFFFFFFFF".
I defined my own MY_HMAC_KEY, MY_SOFT_HMAC_KEY, MY_SOFT_SERIAL and MY_AES_KEY with different values.
Uploaded it to a node and it saved it in EEPROM (I ran the original sketch to find out what was saved)

1: Do I use the same SecurityPersonalizer.ino to my gateway and all nodes so they all have same keys?
Or do I have to change any key?

Thanks!

[Anticimex]

@Nicklas-Starkel All nodes that are supposed to communicate with each other have to use the same keys.

[Nicklas Starkel]

@Anticimex great!

So flashed my gateway and 1 node.
How do you know it "works"?
In my gateway and node sketch I have included:
#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES

Reading the document I would expect that all other nodes that isn't "signing" the information would be disregarded by the gateway.
But in my case they can send info to the gateway and it will forward it via MQTT (as I have the ethernet w5100 gateway with MQTTclient).

Using serial monitor on the gateway this is what is seen when a signed node is reporting:
0;255;3;0;9;TSF:MSG:READ,4-4-0,s=0,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:5D7FA0C430E8A0363FEBA8E73BDBBD2755DFC7A53E8D1B394F
0;255;3;0;9;TSF:MSG:READ,4-4-0,s=0,c=1,t=16,pt=2,l=2,sg=1:0
0;255;3;0;9;Sending message on topic: Broker/1/0/1/0/16
0;255;3;0;9;TSF:SANCHK:OK

A node that isn't signed:
0;255;3;0;9;TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=2
0;255;3;0;9;TSF:CHKUPL:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;!TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
0;255;3;0;9;TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=1
0;255;3;0;9;TSF:CHKUPL:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:SANCHK:OK

To me it looks like it's ignoring the node because no temperature is received and shown in serial monitor.
But it still reports everything via MQTT.

Am I doing something wrong?

[Anticimex]

@Nicklas-Starkel From the documentation:
If a node does require signing, any unsigned message sent to the node will be rejected.
This also applies to the gateway. However, the difference is that the gateway will only require signed messages from nodes it knows in turn require signed messages.

[Nicklas Starkel]

@Anticimex

ahh, so basically the gateway will always accept everything, but nodes will not if signing is enabled.

Maybe it's a longshot, but I was worried that if someone knows my MQTT pathways they would be able to
1: Use a node and send information (ex MQTT/MyActuator/TurnON)
2: The gateway picks it up and converts to MQTT information and publish to MQTT broker
3: My actuator subscribes to this special channel and gets the "TurnON"
And then for example turns on my lights or whatever.

While I was writing this I realize more and more that the above is pretty far fetched
Also, I have separated MySensors channel from other channels so they should be safe.

But to be on the safe side and there seems not to be any apparent drawbacks, I will use Whitelisting as well.
Thank you for the help @Anticimex !

[Anticimex]

@Nicklas-Starkel you're welcome. This behaviour is because we did not want to turn a gw that require signatures useless to nodes that for any reason cannot use signing. It could be that this is changed at some point on the future so that a gw that require signatures does it for all nodes. But for now it doesn't for backwards compatibility. And it is considered that signing first of all is used for data going out to a node. Typically an actuator. And yes, whitelisting can also be added to further strengthen security if you fear nodes could be hijacked.
I'm glad the features are being used

[Sharath B Krishna]

Have one query... by just enabling the RF24 Encryption with the MY ENCRYPTION SIMPLE PASSWORD, is it required that all nodes have it set along with the gateway?

can a non encryption enabled node communicate with the gateway(encryption enabled) ? like we have with the signing ?

[mfalkvidd]

Welcome to the MySensors community @sharath-b-krishna. Great to have you here.

from the documentation:

#define MY_RF24_ENABLE_ENCRYPTION
Define this to enable software based AES encryption.

All nodes and gateway must have this enabled, and all must be personalized with the same AES key.

[Sharath B Krishna]

@mfalkvidd thanks , I understand its necessary since nodes with encryption need to communicate... but what is not clear is .....is it possible for nodes without encryption enabled also to communicate to gateway ?

like how nodes without signing enabled can still communicate with the gateway ..

[Anticimex]

@sharath-b-krishna no, as encryption is done in the physical layer while signing is done in the routing layer.
Encryption applies to ALL messages at ALL times so a gw has now way of distinguishing a node that encrypts messages from a node that doesn't.
Signing is done conditionally depending on requirements exchanged between gw and node and also on certain types of messages.
Security is guaranteed by persistent storage on the GW side of nodes that communicate certain signing requirements so rogue nodes cannot just tell the GW to reset the requirements for a node if signing has been enabled at any point in history without physical access to the gw.
Encryption does not do any of this logic as it implies that certain messages has to be exchanged between gw and node which both need to "understand".

[alowhum]

@Sharath-B-Krishna In other words: it's all or nothing

[Anticimex]

@alowhum @Sharath-B-Krishna yes, at least if we are talking a single gw setup. It is possible to use two gw:s to have two separate networks. One can be encrypted and the other plain.

[Sharath B Krishna]

@anticimex said in Enable RF24 Encryption with mysensors V2.x:

could

thanks @Anticimex ... also is the Encryption simple password stored in the eeprom? would be easily readable with a eeprom read program ?

[Anticimex]

@sharath-b-krishna no, the simple options have all secrets stored in the sketch, so don't put your production code on github if you plan to use that

[Sharath B Krishna]

thanks @Anticimex