This post is a try to order my thoughts about the mysensors implementation possibilities for signing and encryption.
I thought that it could be of some help for other people, who are new, like me, to mysensors and want to start using it.
This is written with in mind the current version 2.3.1 of the mysensors libary and 2 Arduinos Uno's R3 as hardware. Be aware that this can change in the future as the library will continue to evolve!
Please, if you find any mistakes, don't hesitate to point them out to me so I can correct this post.
First some (condensed) theory found in the docs and on this forum.
Two different things:
-
Signing messages : this makes that the receiver is sure that the received message is really from the transmitter. The message can't be changed by somebody during the transmission of the message. This is done by the MySensors message protocol.
More detailed explication can be found on: https://www.mysensors.org/apidocs/group__MySigninggrpPub.html#MySigninggrpencryption -
Encryption of the messages: is done on the level of the used radio itself. For RFM69HW for example, it is done by the hardware itself of the radio. It is independent from the MySensors message protocol implementation.
A. Signing of the messages
Three possibilities: 2 based on software and one based on extra external hardware. The latest I can't test because I have no Atmel ATSHA204 chips lying around...
-
First option, software backed by using only a password : weaker security, but simple to activate.
MY_SIGNING_SIMPLE_PASSWORD: this keyword enables security only on the level signing
If the provided password is shorter than the size of the HMAC key, it will be null-padded to accommodate the key size in question. A 32 character password is the maximum length. Any password longer than that will be truncated. -
Second option, sofware backed
MY_SIGNING_SOFT: this keyword enables security only on the level signing
If MY_SIGNING_SIMPLE_PASSWD is used a personalisation must not be done.
If not used, a personalization must be done, the values are stored in EEPROM.(see: https://www.mysensors.org/apidocs-beta/group__MySigninggrpPub.html#personalization). See also further on. -
Third option, hardware backed via the Atmel ATSHA204 chip
MY_SIGNING_ATSHA204: this keyword enables security only on the level signing
If MY_SIGNING_SIMPLE_PASSWD is used a personalisation must not be done.
If not used, a personalization must be done, the values are written to the Atmel ATSHA204 ship. It is irreversible!! (see https://www.mysensors.org/apidocs-beta/group__MySigninggrpPub.html#personalization)
B. Encryption of the radio transport level
Only possible for the supported radios (RF24, RFM69, NRF5, RFM95 at current library version 2.3.1)(https://www.mysensors.org/apidocs-beta/group__EncryptionSettingGrpPub.html)
The RFM69 radio does support hardware encryption of the communication using AES (Advanced Encryption Standard).
- MY_ENCRYPTION_SIMPLE_PASSWORD: this keyword enables encryption on all radio communications of the radio types that supports it and uses provided password as key.
If the provided password is shorter than the size of the AES key, it will be null-padded to accommodate the key size in question. A 16 character password is the maximum length. Any password longer than that will be truncated.
example : #define MY_ENCRYPTION_SIMPLE_PASSWD "MyInsecurePassword"
If you are already using the first option of signing messages (MY_SIGNING_SIMPLE_PASSWORD), you can replace it by following keyword:
- MY_SECURITY_SIMPLE_PASSWORD: this keyword enables security on the level signing and encryption (only usable on Arduino. On the Raspberry PI use the other two simple options)
My practical tests
- a sensor based on an Arduino Uno with the sketch UltraSonic_sensor from the website adapted for the RFM69HW radio
- a gateway based on an Arduino, a W5100 ethernet shield for the Uno and a radio RFM69HW (see https://forum.mysensors.org/topic/10358/solved-mqtt-gateway-based-on-arduino-uno-uno-compatible-w5100-ethernet-shield-rfm69hw-radio)
- Added in the two sketches: only encryption
#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"
Result : it works
- Added in the two sketches: encryption and simple signing
#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWORD "my32characterpassword"
Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!
- Added in the two sketches: encryption and simple signing
#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWORD "my16characterpassword"
Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!
- Added in the two sketches: the shortcut define for the Arduino platform
#define MY_SECURITY_SIMPLE_PASSWORD "my16characterpassword"
Result : it works
- Added in the two sketches: the shortcut define for the Arduino platform
#define MY_SECURITY_SIMPLE_PASSWORD "my32characterpassword"
Result : it works
Is this shortcut define specially done for the Arduino platform to avoid the low memory condition?
- Added in the two sketches : encryption and soft signing with simple password personalization
//enable radio communication encryption
#define MY_ENCRYPTION_SIMPLE_PASSWD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWD "my32characterpassword"
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A0
Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work. The signing is failing.
- Added in the two sketches : encryption and soft signing with personalization
First we will personalize each arduino (the sensor and the gateway)
- open the SecurityPersonalizer.ino file via the Arduino IDE menu File, Examples, Mysensors, SecurityPersonalizer
- uncomment the define GENERATE_KEYS_SOFT
- upload the sketch to your Arduino
- open the serial monitor
- here you will find your generated keys HMAC and AES keys
- copy the entries under the 'Key copy section' into the SecurityPersonalizer.ino file
- comment again the define GENERATE_KEYS_SOFT
The following 3 steps must be done on each node where you want to use soft signing
- uncomment the define PERSONALIZE_SOFT
- upload the sketch again to your Arduino
- in the serial monitor output you will find now that the keys are written to the EEPROM (see EEPROM section)
The following 5 steps must also be done on each node where you want to use whitelisting
-
if you want to use whitelisting and your device does not provide a unique device ID, you have to generate a unique serial and store it in EEPROM (my arduino uno does not provide a unique device ID, so I must run the sketch)
-
comment the define PERSONALIZE_SOFT
-
uncomment the define PERSONALIZE_SOFT_RANDOM_SERIAL
-
upload the sketch to your Arduino
-
in the serial monitor output you will find now a generated serial unique device ID. This unique serial ID must be copied somewhere on a safe place. You must later on copy this key in the whitelisting define of your gateway and nodes sketches.
-
Take now your sketches and add the following defines
//enable radio communication encryption
#define MY_ENCRYPTION_SIMPLE_PASSWD "my16characterpassword"
//enable soft signing
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A0
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = 0,.serial = {0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99}},{.nodeId = 1,.serial = {0x99,0x88,0x77,0x66,0x55,0x44,0x33,0x22,0x11}}}
The MQTT gateway has always nodeid = 0 and my sensor has nodeid = 1 (the sensors must have a fixed set nodeid because in MQTT mode, the controller (like HomeAssistant) can't assign node ids).
The serials given above are fake numbers, use the ones from your sketch!
Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!
So I think that in my case, with an Arduino Uno as MQTT gateway, only the simple signing and encryption is possible.
Maybe the hardware backed signing, but I can't test this at this moment. (see my other question : https://forum.mysensors.org/topic/10370/is-there-still-a-breakout-board-for-the-atmel-atsha204a-chip)
:
.