Enable RF24 Encryption with mysensors V2.x
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 ?
I am also interested in taking this next step, thanks for bringing it up.
This is done using the security personalizer sketch. The doxygen documentation describes the steps under the signing chapter.
@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.
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_RANDOMSEED_PIN 7
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.
@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.
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?
@Nicklas-Starkel All nodes that are supposed to communicate with each other have to use the same keys.
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_RANDOMSEED_PIN 7
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;Sending message on topic: Broker/1/0/1/0/16
A node that isn't signed:
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?
@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.
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 !
@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