RAK3172 RUI3 P2P Encryption/Decryption

mykebates · November 6, 2022, 8:21pm

Attempting to wade my way through getting a simple P2P setup in place while utilizing the encryption features in RUI3. Here is my setup.

3x RAK3172 modules. Two of them acting as senders and the third acting as a receiver.

The two senders are running firmware version 3.4.2 and are configured via WisToolBox with the following parameters - all default aside from the encryption key and mode being set to P2P.

The receiver module is programmed with the LoraP2P example Arduino sketch. The only thing I have altered here is the addition of the encry.set() and enckey.set() functions as the docs outlined LoRaWAN | RAKwireless Documentation Center

  Serial.printf(“Set P2P mode encryption status %s\r\n”, api.lorawan.encry.set(1) ? “Success” : “Fail”);
  Serial.printf(“Set P2P mode encryption Key %s\r\n\r\n”, api.lorawan.enckey.set(node_encrypt_key, 8) ? “Success” : “Fail”);
  Serial.printf(“P2P encryption status = %s\r\n”, api.lorawan.encry.get() ? “Enable” : “Disable”);

  api.lorawan.enckey.get(encrypt_buff, 8);
  Serial.printf(“P2P encryption Key = 0x”);
  for (int I = 0 ; I < 8 ; I++) {
      Serial.printf(“%02X”, encrypt_buff[I]);
  }
  Serial.println(“”);

The result is that with the encryption turned off on the sending modules, the receiving module prints out the payload as expected. But when the sending modules have the encryption option enabled, the receiving module does not seem to decrypt the payload.

RAKwireless LoRaWan P2P Example
------------------------------------------------------
P2P Start
Hardware ID: stm32wle5xx
Model ID: rak3172
RUI API Version: 3.2.0
Firmware Version: 3.4.2-rui3_22q1_update.112
AT Command Version: 1.5.4
Set Node device work mode Success
Set P2P mode frequency 868.000: Success
Set P2P mode spreading factor 12: Success
Set P2P mode bandwidth 125: Success
Set P2P mode code rate 4/5: Success
Set P2P mode preamble length 8: Success
Set P2P mode tx power 22: Success
Set P2P mode encryption status Success
Set P2P mode encryption Key Success

P2P encryption status = Enable
P2P encryption Key = 0x4142444533434442
P2P set Rx mode Success
Current Work Mode: LoRa P2P.
+EVT:RXP2P RECEIVE TIMEOUT
Empty buffer.
P2P send Success
P2P set Rx mode Success
+EVT:RXP2P:-21:12:FFA4ABD50A627F9A09BAD44F2287AB06
Incoming message, length: 16, RSSI: -21, SNR: 12
   +------------------------------------------------+ +----------------+
   |.0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .a .b .c .d .e .f | |      ASCII     |
   +------------------------------------------------+ +----------------+
 0.|48 65 6c 6c 6f 20 57 6f 72 6c 64 00 00 00 00 00 | |Hello World.....|
   +------------------------------------------------+ +----------------+
P2P send Fail
+EVT:RXP2P:-22:22:48656C6C6F20576F726C64
Incoming message, length: 11, RSSI: -22, SNR: 22
   +------------------------------------------------+ +----------------+
   |.0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .a .b .c .d .e .f | |      ASCII     |
   +------------------------------------------------+ +----------------+
 0.|6e d3 68 da 71 bb c1 70 46 d8 a1                | |n.h.q..pF..     |
   +------------------------------------------------+ +----------------+
P2P send Fail

I am unsure if there are other steps needed to decrypt the payload on the receiving end, or if setting the encryption options as shown above should result in that happening automatically.

Anyone else know the details for how to achieve this? Appreciate it!

carlrowan · November 7, 2022, 8:14pm

Welcome to RAK forum @mykebates ,

The encryption works fine and you’ll see it on the +EVT:RXP2P: notifications. Assuming you are sending the same payload and encryption key is enabled and correct (which I am not sure if that is the case on what you shared above).

However, the LoRa RX callback value seems to have discrepancy on our RUI3 callback function. We are still looking further on what could be wrong. Probably for now, you can proceed with no encryption then we can update once we got more info.

Btw, I suggestion you update your firmware to RUI3.5.x. It seems you are still at 3.4.2.

Kongduino · November 8, 2022, 11:47am

This is very problematic – AES keys can’t be 64 bits (8 bytes), and RUI3 should not even accept a 64-bit key. Can you please try by supplying the API a proper 128-bit key, and see whether that helps?

EDIT
I did it myself and the API refuses to accept anything else than 64 bits – which doesn’t make sense. We will discuss this internally.

Kongduino · November 9, 2022, 2:41am

Also, as a more general piece of advice, in your loop you are sending a packet every 3 seconds, and use delay(), which is sub-optimal, for 2 reasons:

3 seconds is way too short a delay between packets. Not only does it go against fair use of the band, but it might even prevent your device(s) to receive packets properly.
delay() is blocking. What you want to do, especially in more complex applications, is leave time to other threads to run. Instead, use something last this:

void loop() {
  if(millis() - lastTime > SEND_DELAY) {
    // #define SEND_DELAY 30000 for example
    // ---> send packet
    lastTime = millis(); // reset
  }
}

mykebates · November 9, 2022, 9:26pm

Oh wow, I totally did not catch that log in there. I guess that line is being output from somewhere lower in the libraries? Because I don’t see anywhere in the LoRa_P2P_Receiver example sketch where that line is being printed.

I can confirm that those “+EVT:RXP2P” logs do adhere properly to the encryption settings. I tested this by mismatching the encryption keys between devices and the hex message does indeed come back garbled when the keys are mismatched. So that is great.

However, I still do not know how to access the decrypted value. It seems the payload buffer of the rui_lora_p2p_recv_t passed to the PRecvCallback is not properly dealt with.

Any ideas how to get at the properly handled payload as seen in the printed line you pointed out?

Or perhaps this is in relation to what @Kongduino pointed out with the AES keys 64bit/128bit?

carlrowan · November 9, 2022, 10:42pm

@mykebates , there is an issue ticket already created on the data of the callback. I do not think the fix will be really difficult to do because as you see the encryption is actually performed correct, just with invalid key length (but that is a different issue). You can probably proceed in developing your application less the encryption (for now) then we can add it later once we got the fix

mykebates · November 9, 2022, 11:29pm

Fantastic! I’ve got two remaining questions related to this

1 - Will this thread be updated when the fix is available, or is there an external-facing bug tracker/changelog where the status could be followed?

2 - In reference to the firmware 3.5.x - I did try updating to that version(prior to creating this post) simply out of curiosity if that might fix this issue. I experienced some weird results in that the receiving module would not ever receive anything. My code was exactly the same. I double checked to ensure the sf, bw, power, etc were all the same. I was able to compile and flash just fine. The firmware version printed out the proper version(3.5.1), everything was seemingly in working order, only there was no PRECV happening.

I can dig around in the forums and GitHub further to see if anyone else might have the same/related issue, but thought I’d bring it up here in the off chance you might be familiar with exactly what I am saying.

Kongduino · November 14, 2022, 4:02am

Turns out AES is borked in RUI3 – but from what I can see in the source code not with any influence on the result.

In the mean time, should you need encryption, I have produced a working example with AES128 ECB and CBC (CTR should also work too, I just haven’t implemented the buffer functions), using the reference implementation of AES, Rijndael. You can select in aes.h whether to use AES 128, 192 or 256.

I’ll do a couple more tests, and upload it on Github.

Kongduino · November 14, 2022, 6:52am

Two things.
• I uploaded the sample code, and tested it. ECB and CBC work great.
• We have worked out the AES issues in RUI3 this morning with the team. They will percolate through the feedback system and appear in a future firmware update. Once this is done, you’ll have AES128 CBC at no extra cost in RUI3!

This will let us know whether the issue you are having was caused because of this (I am not so sure now), or whether we need to poke elsewhere. Considering the size of the code base, I wish my AES fix also fixes your issue…

mykebates · November 14, 2022, 8:03pm

Incredible! Got this working in my setup. Appreciate it SO much!!
Will keep an eye out for the firmware updates as well

Kongduino · November 15, 2022, 12:11am

You are very welcome. The fixes in the firmware will be something like the sample code, and should produce an identical result. When the fixes make it to the beta, I’ll get in touch with you again, and maybe we can try code from your setup to confirm.

Cheers

system · November 17, 2022, 12:11am

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.