I upgraded the firmware RAK3172 from RUI3_5_3 to RUI4_0_6. I now get an error when using AT+ENCKEY=1122334455667788 AT+PARAM_ERROR
The latest AT COMMAND indicates 8 HEX characters (16 characters).
Has this command changed? Why is this generating an in error RUI4_0_6?
Does it requires 16 HEX characters (32 characters) ?
Actually this is a bug fix. In older RUI3 versions the encryption key was only 8 bytes long, but the encryption algorithm requires 16 bytes. The bug inside RUI3 was that the 8 bytes were just used twice to get the 16 bytes.
Since RUI3 V4.0.6 this is fixed and now you have to give a full 16 byte encryption key.
Documentation needs still to be updated, but it is already mentioned in the changelog
This is worth a reminder – and a congrats to the RUI3 team. The bugs I had identified last year in the AES implementation have been finally fixed, and it has TWO implications:
• The key length is 16 bytes – the implementation was using 8, repeated… – so you need to pass 16 bytes in code or 32 hex bytes in the AT firmware.
• The AES implementation is AES-CBC. Which means it requires a new IV every time. The fixed IV has been removed and you have to supply it yourself with service_lora_p2p_set_crypto_IV or AT+PIV. Do NOT reuse the same IV. Set a new one every time you want to encrypt something. The reason to remove the fixed IV was exactly that: it is an egregious breach to reuse an IV, as it defeats the very purpose of an IV.
I am producing a patch for the service_lora_p2p.* files to help with that and add a layer of protection. And a good practices tutorial.
That’s what I thought.
Its funny that this bug permeated for so long, since the beginning.
I’m really glad for this bug fix.
Yes that’s I thought that it needed 16 bytes for the full encryption key.
I am using two RAK3172 (both with fw: RUI4_0_5) in AT command via UART, to communicate in P2P mode between them. I am using P2P encryption. So far everything ok.
I’m trying now to communicatte from my RAK3172 with RUI4_0_5 to an other one that has the RUI4_0_6 version and since has the ENCKEY on passed on16 bytes.
I provided the ENCKEY 1122334455667788 to the first one and assumed the ENCKEY combination for the second one was just 11223344556677881122334455667788 (repeated) according to this post. Unfortunately I am unable do decrypt correctly with this byteorder.
Could you please inform me what was the bytorder of the 16bytes key that was built from the 8 bytes provided key in RUI4_0_5 ? Or should I play with AT+PIV on the RUI4_0_6 side ? Thanks!
You should be using Firmware RUI4.0.6 on both ends.
You’ll need to download the programming tools.
Whatever is connected to RAK3172 UART pins will need to be disconnected.
A USB to UART interface will be needed.
The UART Rx/TX then connected to the RAK3172.