Decrypt AES encoded payload?

chbla · January 8, 2018, 6:50am

Hi there,

Probably a very basic question, I’ve successfully created an Arduino Pro Mini + RFM95 node that sends data.
I used the sample here:

github.com

things4u/LoRa-Thing/blob/master/LoRaWAN_V31-htu-lowpower/LoRaWAN_V31-htu-lowpower.ino

/****************************************************************************************
* File:     LoRaWAN_V31-htu.ino
* Author:   Maarten Westenberg
* Company:  Things4U
* 
* E-mail:   mw12554@hotmail.com
*
* Publishing temperature and humidity to thethingsnetwork
* This is the low-power version, for use on battery power.
* So receiving functions are disabled...
* 
* Based on the example program made by Gerben of Ideetron http://www.ideetron.nl/LoRa
* Changed and extended to support HTU21d temperature/humidity sensors
* running on an Arduino Pro-Mini
****************************************************************************************/

/****************************************************************************************
* Created on:         20-01-2015
* Supported Hardware: Arduino Pro-Mini board with RFM95 and HTU21d sensor
*

This file has been truncated. show original

The payload is encrypted, but is there any way to have it decrypted on TTN directly so I can actually view the values in the data tab while testing?

E.g. a decoder function for the payload formats tab?

Thanks a lot!
Christoph

arjanvanb · January 8, 2018, 6:58am

Unless you’re not giving us all details, you’re wrong when thinking the data is still encrypted when using TTN Console. See Decrypting messages for dummies.

chbla · January 8, 2018, 7:07am

Thank you for the reply.

I’m sending a simple string “TTT” to the gateway, and what I receive in the payload is: 8E EF 60

It’s sent here:

github.com

things4u/LoRa-Thing/blob/master/LoRaWAN_V31-htu-lowpower/LoRaWAN_V31-htu-lowpower.ino#L175


//Initialize RFM module
RFM_Init();


//Construct data
memcpy(Data_Tx, msg, strlen(msg));
Data_Length_Tx = strlen(msg);


Serial.print("loop: sending message: "); Serial.println(msg);


//Data_Length_Rx = LORA_Cycle(Data_Tx, Data_Rx, Data_Length_Tx);	// Send and receive
LORA_Send_Data(Data_Tx, Data_Length_Tx, Frame_Counter);			// Send only! (for battery sensors)


Frame_Counter++;


Serial.println("Sleep 90 seconds"); Serial.println();
delay(200);										// Delay if Sleep to succeed if all comms is done
RFM_Write(0x01,0x00);								// Put RFM95 in Sleep mode


LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);	// Put Arduino in Sleep mode 12 times 8 seconds
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);   // Either this or a for-loop (whatever takes less memory)
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);

The only change that I did in my sketch is adjusting the keys and change

sprintf(msg,"{“t”:"%d.%d",“h”:"%d.%d"}",it,ft,ih,fh);
to
sprintf(msg,“TTT”);

Is there anything I missed on the TTN side?
The sample uses AES encryption.

Thank you,
Christoph

arjanvanb · January 8, 2018, 7:33am

The answer is in the topic I linked too, so you’ll need to read that first before asking for more help.

If you still think so after reading the other topic: where’s the code for that?

chbla · January 8, 2018, 7:37am

I read the topic, what exactly are you referring to?
If it would be HEX only when arriving on TTN it would be 3 times the same if I send TTT, or not?

The encryption is done here:

github.com

things4u/LoRa-Thing/blob/master/libraries/LoRaWAN_V30/LoRaMAC_V10.cpp#L109




	unsigned char MIC[4];


	//Unconfirmed data up
	unsigned char Mac_Header = 0x40;


	unsigned char Frame_Control = 0x00;
	unsigned char Frame_Port = 0x01;


	//Encrypt the data
	Encrypt_Payload(Data, Data_Length, Frame_Counter_Up, Direction);


	//Build the Radio Package
	RFM_Data[0] = Mac_Header;


	RFM_Data[1] = DevAddr[3];
	RFM_Data[2] = DevAddr[2];
	RFM_Data[3] = DevAddr[1];
	RFM_Data[4] = DevAddr[0];


	RFM_Data[5] = Frame_Control;

The sample is from:
https://things4u.github.io/HardwareGuide/Arduino/Mini-Sensor-HTU21/mini-lowpower.html

arjanvanb · January 8, 2018, 7:40am

That’s in the gateway. When looking at your device’s data in TTN Console, TTN will have decrypted for you, like explained in the other topic.

And true, the LoRaWAN libraries will encrypt (but your own sketch won’t), but TTN will decrypt for you when using TTN Console.

chbla · January 8, 2018, 7:45am

I’m not sure if I follow. 8E EF 60 is in the TTN console, under the data tab.
The sketch I use uses LORA_Send_Data() as shown above, and LORA_Send_Data() as in my last message contains Encrypt_Payload().

So I assume it is encrypted (hence I do get 3 distinct values in TTN if I send “TTT”) I guess?

arjanvanb · January 8, 2018, 8:09am

That’s weird. Unless the specific sketch is doing additional encryption, that should not happen when using TTN Console to administer applications and devices. I think sprintf(msg,"TTT"); should not cause that either.

Sorry, I’d use a different example then. Examples that send text are not a good start anyway, as to save bandwidth a LoRaWAN node should not send text.

arjanvanb · January 8, 2018, 11:36am

~~When using ABP, then~~ I guess TTN Console cannot know if the correct Application Session Key (AppSKey) was used.

For uplinks, the Message Integrity Code (MIC) is calculated using the secret Network Session Key (NwkSKey), not the AppSKey. But even when TTN determines the packet’s MIC is valid, decryption of the application payload (using the secret AppSKey) ~~might~~ will still silently fail when using different secrets for encryption and decryption. (So: will show different results when the AppSKey in TTN Console and the node do not match.)

You can see for yourself with your own data or an example in the “FRMPayload decrypted” part of the online decoder: just play with the AppSKey to see you’ll get different decrypted data, without any clue if the right key was used. Changing the NwkSKey will get you an error though, as for the MIC we know the expected value from the LoRaWAN packet.

So: are you sure you used the correct AppSKey in your node? See also Hex, lsb or msb?

chbla · January 8, 2018, 12:09pm

Thanks for the pointers. I forgot to mention that I use msb - the reason being that with lsb I did not see any data at all . With msb I actually received.
However, I now saw in your link that lmic requires lsb, which is confusing as I don’t receive anything then.

Do all of the values need to be in either msb or lsb? If so I’m not sure why msb gives me data…
I’m not sure if:
SPI.beginTransaction(SPISettings(4000000,MSBFIRST,SPI_MODE0));
is related.

arjanvanb · January 8, 2018, 12:41pm

I think:

If you see packets in a gateway’s Traffic page then you only know it’s connected; you don’t know if the keys are okay. (Though maybe peeking into the “trace” part might give you some hints about TTN knowing the recipient.)
If you see data in a device’s Data page, then the DevAddr and NwkSKey in the node are okay. And:
- For OTAA you can then assume all keys in the device are okay.
- For ABP, if you see the correct data, then the AppSKey is okay too. (So, all keys are okay.)
- For ABP, if you see the wrong data then check the value for AppSKey in the node, or maybe try to revert it in the node.

chbla · January 8, 2018, 1:38pm

I’ve now switched to this tutorial:
https://www.thethingsnetwork.org/labs/story/build-the-cheapest-possible-node-yourself
Here it works without problems, after re-wiring the module as outlined - must be the other lib.

Just a quick question: I read that OTAA sometimes takes longer for the initial connection. Is it better to use ABP for battery (low)powered nodes?

Thanks a lot for your help!

arjanvanb · January 8, 2018, 1:42pm

See:

chbla · January 8, 2018, 8:50pm

Thanks a lot!

Javastraat · January 10, 2018, 9:18pm

Hi Christoph,
The tutorial that you were using originally probably has a bug in the Encrypt_Payload function. The function in Encrypt_V30.cpp encrypts the payload with:
AES_Encrypt(Block_A,NwkSkey);
This should be:
AES_Encrypt(Block_A,AppSkey);

arjanvanb · January 10, 2018, 10:18pm

Nice find, @Javastraat. Care to comment at https://github.com/things4u/LoRa-Thing/issues/2 ? (Otherwise I’ll copy your post there.)

Javastraat · January 10, 2018, 10:52pm

Thanks for the suggestion. I just left my comment there.

chbla · January 11, 2018, 9:10am

Thanks a lot! I did not see that. I will check out the code and give it another try.

I’m not sure about the different libraries, some are trying to reduce power consumption, others reduce sketch size, might be outdated though as well.