LoRa/LoRaWAN tutorial 54: LoRaWAN 1.1 OTAA
Mobilefish.com Mobilefish.com
28.3K subscribers
3,428 views
0

 Published On Jun 29, 2021

If you like this video and want to support me, go this page for my donation Paypal or crypto addresses:
   / mobilefish  

This is part 54 of the LoRa/LoRaWAN tutorial.

In this tutorial I will explain the Over-The-Air-Activation (OTAA) in LoRaWAN 1.1.

This presentation can be found at:
https://www.mobilefish.com/download/l...

The information presented in this video were taken from these two sources:
The LoRaWAN 1.1 Specification:
https://lora-alliance.org/wp-content/...
The LoRaWAN Backend Interfaces 1.0 Specification:
https://lora-alliance.org/wp-content/...


The end device generates the DevNonce which is a 2-byte counter, starting at 0 when the device is initially powered up and incremented with every join-request.
The DevNonce value is used to prevent replay attacks.
If the end device can be power-cycled then DevNonce shall be persistent, meaning stored in a non-volatile memory.
For each end device, the network server keeps track of the last DevNonce value used by the end device, and ignores join-requests if DevNonce is not incremented.

The end device constructs a message containing the JoinEUI, DevEUI and DevNonce.
To protect the message's integrity, the Message Integrity Code (MIC) is computed using the NwkKey.
The end device can now activate itself, by sending a join-request message as plain text to the network server.

The network server receives the join-request message and checks if the DevNonce has not been used previously.
The network server authenticates the end device with the MIC value.
If accepted, the network server constructs a JoinReq message.

The network server uses the Domain Name System (DNS) to look up the IP address of the join server based on the JoinEUI in the received join-request message.
If the DNS lookup succeeds, the network server sends the JoinReq message to the join server.

The join server provides the JoinNonce value which is a device specific counter value, that never repeats itself, and is incremented each time a Join-Accept message is created.
The join server processes the JoinReq message and derives the network session keys.

The network session keys are derived with the NwkKey and the AppSKey is derived with the AppKey.
The network session keys and AppSKey are stored at the join server and are not send to the network server.

The join server creates a join-accept message.
To protect the join-accept message integrity, the Message Integrity Code (MIC) is computed using the JSIntKey.
The join-accept message is encrypted with the NwkKey.

The join server constructs a JoinAns.
The join server sends the JoinAns to the network server.
The network server receives the JoinAns message and if Result==Success the network server forward the encrypted join-accept message to the end device.

The end device decrypt the join-accept message with the NwkKey and verifies the MIC of the join-accept message.
The JoinNonce should be greater than the recorded one stored in the device.
In that case the new JoinNonce value replaces the previously stored one.
If the device is susceptible of being power cycled the JoinNonce shall be persistent (stored in a non-volatile memory).
If the join-accept message is accepted the end device generates the network session keys FNwkSIntKey, SNwkSIntKey, and NwkSEncKey using the NwkKey, and generates the AppSKey using the AppKey.

The end device has a payload containing sensor data.
The end device encrypts the payload with the AppSKey and sends the encrypted payload to the network server.
The network server receives an uplink packet from the end device.
The network server forwards the encrypted packet to the application server.
The application server sends an AppSKeyReq message to the join server.
The message requests the AppSKey identified by the DevEUI from the join server.

The AppSKey is encrypted using a shared key between the join server and the application server.
The join server sends the encrypted AppSKey to the application server in an AppSKeyAns message.
The application server decrypts the encrypted AppSKey with the shared key.
The application server uses the AppSKey to decrypt the encrypted payload.

Check out all my other LoRa/LoRaWAN tutorial videos:
   • LoRa/LoRaWAN tutorials  

Subscribe to my YouTube channel:
   / @mobilefish  

The presentation used in this video tutorial can be found at:
https://www.mobilefish.com/developer/...

#mobilefish #lora #lorawan

show more

Share/Embed