Application Session Key in Application Server doesn't match device generated

ChirpStack Application Server
1

Hi!

I am working with the lorhammer project and specifically working on getting OTAA join requests to work to allow creating and provisioning devices in the same flow that our actual devices behave.

I am running into an issue where it appears the join is successful, logs note that, and devaddr and app/net session keys are set in the UI, but the application session key is all zeros 00000000000000000000000000000000. In lorhammer, I generate the session keys using the encyrption spec in 1.0.2 and I can confirm the network session key I generate matches what shows up in the application server.

The part that has me stuck, is that the application session key I generate, does not match the all zeros in the application server.

Any thoughts on what would cause the application session key to get stored in this way? I would expect it would generate the same app session key I generate and store that.

image

From lorhammer logs:

current keys appSKey=40285b8abbc3e56c341c6e6c090d1161 netSKey=8667333b40f36e48b25608fde2b18adc
2

Interesting - it doesn’t set / store the app key until the first uplink payload comes in. TIL

3

Correct, the first uplink is the confirmation that the device switched its security context. This is important as with the LoRaWAN 1.1 rejoin-request, there is a possibility that the device continues to use the old context. (On rejoin-request and sending back a JoinAccept, the NS will store both the “old” and “new” context. It then verifies the next uplink / MIC against both contexts).

2 Likes