LoRa/LoRaWAN tutorial 21: OTAA, ABP and LoRaWAN Security

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

This is part 21 of the LoRa/LoRaWAN tutorial.

In this video series different topics will be explained which will help you to understand LoRa/LoRaWAN.
It is recommended to watch each video sequentially as I may refer to certain LoRa/LoRaWAN topics explained earlier.

In this video I will explain how Over-The-Air-Activation (OTAA) and Activation-By-Personalisation (ABP) works.

Before I start with this tutorial please be aware of the following:
The information provided in this tutorial is based on the LoRaWAN 1.0.2 specification.

More information about the LoRaWAN 1.0.2 specification, see:
https://lora-alliance.org/resource-hu...

All LoRaWAN specifications, see:
https://lora-alliance.org/resource-hub

The MCCI Arduino LMIC library has only been tested with LoRaWAN 1.0.2 networks and has not implemented the LoRaWAN 1.1 new security features.

There are two methods to activate an end device in a LoRaWAN network:
- Over-The-Air-Activation (OTAA)
- Activation-By-Personalisation (ABP)

OTAA
OTAA is the preferred activation method because it provides the most secure way to connect end devices to a network server.
Before activation:
- End devices must know and store its DevEUI, AppEUI and AppKey.
- The network server must know and store the same AppKey.

The DevEUI uniquely identifies the end device and is similar to a MAC address.
The AppEUI uniquely identifies the Application Server and is similar to a port number.
The AppKey is an AES 128 bit symmetric key and is used to generate the Message Integrity Code (MIC) to ensure the integrity of the message.
Both end device and network server must store the same AppKey.

The end device generates the DevNonce which is a randomly generated number to prevent rogue devices re-playing the Join-Request.
The end device constructs a message containing the DevNonce, AppEUI and DevEUI.
Over this message, the Message Integrity Code (MIC) is generated by the AppKey.
DevNonce, AppEUI and DevEUI and are not encrypted by the AppKey.
The end device can now activate itself, by sending a Join-Request message to the network server containing the DevNonce, AppEUI, DevEUI and MIC.

After the network server receives the Join-Request message it will check if the DevNonce has not been used previously.
The network server authenticates the end device with the MIC value. If accepted, the following values are generated by the network server:
- DevAddr (Device Address)
- AppNonce
- NetID

The network server constructs a message containing the DevAddr, AppNonce, NetID and some network settings.

Over this message, the Message Integrity Code (MIC) is generated by the AppKey.
The message itself is encrypted with the AppKey.
The network server sends a Join-Accept response back to the end device containing the encrypted message and the MIC.
Now both the end device and network server share the same AppNonce and DevNonce.

The end device and network server uses the AppNonce and DevNonce to generate two session keys: the Network Session Key (NwkSKey) and the Application Session Key (AppSKey).
The network server sends the AppSKey and DevAddr to the application server.
The NwkSKey is used by the end device and network server to calculate and verify the Message Integrity Code (MIC) of all data messages to ensure data integrity.
The NwkSKey is also used to encrypt and decrypt the payload.
The AppSKey is used to secure end-to-end communications between the end device and the application server.
The shared symmetric key is used by the application server and end device to encrypt and decrypt the payload.

The payloads are end-to-end encrypted between the end device and the application server, but they are not integrity protected.
That means, a network server may be able to alter the content of the data messages in transit.
Network servers are considered as trusted.

ABP
Instead the end device is preloaded with the DevAddr, AppSKey and NwkSKey.
The network server is preloaded with the DevAddr and NwkSKey.
The application server is preloaded with the DevAddr and AppSKey.
When an end device is trying to communicate with the network server, it will send messages directly.
These messages are encrypted and signed.

In Oct 2017, the LoRaWAN 1.1 specification is out with improved security.
More information about LoRaWAN 1.1, see these webinars from The Things Network:
   • The missing puzzle pieces of LoRaWAN ...  
   • What is new in LoRaWAN 1.1?  

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