Encryption with RFM69 and PI serial GW

[Jerby]

How does encryption with RFM69 work?
The RFM69 has build in hardware encryption with a AES key of 16 bytes. But when builing the rPI GW a 32bytes AES key is required else it report "warning wrong AES key". For building the nodes it is also required to define a 32bytes MY_RFM69_ENCRYPTKEY to be able to communicate with the rPI GW.
It seems that for encryption with the RFM69 only the first 16bytes are used and the personalised encryptkey in EEPROM of a node is not used. Is this correct?

[Anticimex]

@jerby I am afraid I don't understand. All encryption variants uses 16 byte AES key. Signing (which is not encryption) uses a 32 byte MHAC key but that is something completely different.

[Jerby]

Hi Anticimex, I'm puzzled, in the node I used the 16byte aes key from the personaliser. That value is a hex code of 32 characters and in the examples found on the forum there are 16 characters. Where is the translation made from bytes to characters? And is hardware encryption automatically used in case of RFM69 radio's?

[Anticimex]

@jerby one hex character can encode 16 values. So a single hex character represent 4 bit. So one byte is 2 hex characters. Therefore, in order to represent 128 bits (the AES key length), you need 32 hex characters which is 16 bytes of data.

[Jerby]

@Anticimex I fully agree, but the examples give a 16bytes ascii encrypt key and 1 ascii character is 2 bytes. I did not specify that my entered key is in bytes so I would expect that the compiler converts it to 32hex characters but it dpoesn't do that else my communication wouldn't work!?

[Anticimex]

@jerby one ascii character when used to represent a hex value represent a hex value which means that it can only express 0-9 and a-f which is 4 bits. The storage used to store the representation is larger yes, as one character takes 8 bits but that is irrelevant as the compiler will interpret 0x<value> as hex so when assigning something that value only 4 bits data is moved. You could try use 0x2G or similar as key but unless the compiler is fundamentally broken that will not compile.

[Anticimex]

@jerby and in the rPi case I believe the key is stored in a file in a somewhat compressed manner so python or whatever interpreter used knows that the string is a hex string, so if the example list a key in something like
'3f7ba35290dc327b28a4f7b2c6a910db' it should also fail if you then try '3f7ba35290dc327b28a4f7b2c6a910gb'.

[Jerby]

@Anticimex, clear therefore I don't understand that my configuration as given below is working.

rPI mysensors.conf
aes_key=D35AB40FDE3DBF9EAB4DC9CDA48EDB55

promini node:
#define MY_RFM69_ENABLE_ENCRYPTION
#define MY_RFM69_ENCRYPTKEY "D35AB40FDE3DBF9EAB4DC9CDA48EDB55"

Thanxs for your quick replies.

[Anticimex]

@jerby well, as far as I know, there is no such define available: MY_RFM69_ENCRYPTKEY
Arduinos are personalized with their keys using a personalizer sketch. If you don't want to do that there is the "simple" security flags.
Are you sure encryption is really activated at both ends?

[Anticimex]

@jerby if you run the personalizer sketch with proper flags, it will show you the data in eeprom. The radio uses the AES key in eeprom if you enable encryption on the node. And afaik, it is not supported to define any security keys as strings in the sketches, the only exception being the "simple" flags. The personalizer uses 0x hex byte syntax for its definition and I believe the personalizer also provide the keys in that form in the personalization flow for simple deployment purposes (copy+paste).

[Jerby]

@Anticimex, great that could be the answer. I'll build the node without #define MY_RFM69_ENCRYPTKEY and see if they still communicate. Thxs.

[Jerby]

@Anticimex, test failed. So #define MY_RFM69_ENCRYPTKEY is required for encryption with the RFM69 and encryption key from EEPROM is not used!
My question how does the compiler know that the entered MY_RFM69_ENCRYPTKEY is in hex and not acsii is still a mistory to me.
Regards, and thanks for your help.

[Anticimex]

@jerby I need more details on your setup to be able to help you.
Your flag is unknown to me and non-existant in the MySensors repository as you can see here: https://github.com/mysensors/MySensors/search?utf8=✓&q=MY_RFM69_ENCRYPTKEY&type=

So you must be running some other code base for your things that I am unfamiliar with.

[Jerby]

@Anticimex, this is the references that I found:

https://github.com/Oitzu/mysensors-Arduino-attiny/pull/2/commits/74a54267d2b76c1cd509ae4245d4d3837270670b?diff=unified

row 418.

[Anticimex]

@jerby from the readme of that fork, the library version is 1.4. That is practically ancient and probably before I even started on the security framework.
It is certainly not compatible with anything current in the MySensors environment. And with current I am talking about something from the last 3 years.

[Jerby]

@jerby said in Encryption with RFM69 and PI serial GW:

@Anticimex,

My configuration is as follows:
I started with a rPI with Domoticz and NRF24 nano GW and nodes with soft signing and encryption. I've added a RFM69 nano GW with soft signing and encryption and converted one node from NRF24 to RFM69. That configuration worked but the serial GW's got mixed up. The RFM69 sensors showed up under NRF24 GW and working so I even could disable the RFM69 under Hardware while the RFM69 sensors still worked via the NRF24 GW. The sketch name of the RFM69 also showed up at the NRF24 GW. Therefore I removed the RFM69 nano GW and connected the RFM69 on the I/O pins of the rPI and configured the rPI as follows:

*git clone https://github.com/mysensors/MySensors.git --branch master

configured the keys from the personaliser in the file etc/mysensors.conf

sudo ./configure --my-transport=rfm69 --my-rfm69-frequency=433 --my-is-rfm69hw --my-gateway=serial --my-serial-is-pty --my-serial-port=/dev/ttyUSB020 --my-rfm69-irq-pin=22 --my-rfm69-cs-pin=24 --my-rfm69-encryption-enabled*

sudo make install
etc.

And the promini node with:
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY (RFM69_433MHZ)
#define MY_RFM69_NETWORKID 100 // Default network id. Use the same for all nodes that will talk to each other
#define MY_RFM69_ENABLE_ENCRYPTION
#define MY_RFM69_ENCRYPTKEY "D35AB40FDE3DBF9EAB4DC9CDA48EDB55"
#define MY_RFM69_NEW_DRIVER

When I remove the #define MY_RFM69_ENCRYPTKEY communication doesn't work any more.

I use platformio as development platform.
Hope this is sufficient info of my setup.

[Anticimex]

@jerby can you confirm that you run with the same library version in both gateway and node?
And that the encryptkey flag is not present in any code you use. Because it shouldn't if you run with a library from the ladt 4 years. And therefore the presence of that flag or not in your code should have no effect. So I suspect you run an outdated version of the library or a fork.

[Jerby]

@Anticimex, I confirm that I'm have build pro mini and rPI on MySensors version 2.3.1 and didn't specify the encryptkey other than in given define and in EEPROM.

So now I removed the define again and ... communication is still working , you where absolutely right. Don't know what I did yesterday

Tomorrow I'll start again with adding software signing and see if that will work too.

Thanks again for your patience and help, great support .

[Anticimex]

@jerby glad that things worked out for you always happy to give a helping hand with security