LoRa/LoRaWAN tutorial 21: OTAA, ABP and LoRaWAN Security
HTML-код
- Опубликовано: 19 окт 2018
- 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:
lora-alliance.org/resource-hu...
All LoRaWAN specifications, see:
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 pie...
• What is new in LoRaWAN...
Check out all my other LoRa/LoRaWAN tutorial videos:
• LoRa/LoRaWAN tutorials
Subscribe to my RUclips channel:
/ @mobilefish
The presentation used in this video tutorial can be found at:
www.mobilefish.com/developer/...
#mobilefish #lora #lorawan 
Наука
In the near future, Your video series will surely become the starting point for anyone who wants to work on lorawan... :)
Though I've extensively worked on lorawan, many of my doubts have been cleared by watching your videos.. thanks!
Already has one person entering the field watching!
since u have worked lot on lorawan
pls clarify my doubt
does enddevice can communicate directly with network server,if so wht is the use of using gateway
Nice video, thank you!
Thank you for my exam !
Very well described and simply explained procedure for LoRaWAN beginners.
Hi The video tutorials are very well explained, I am new to LoRa, I am exploring if a text file around 200kb can be transferred? Even if in pieces? how much time it will take at 2 km distance at EU bands
Hi, thank you for the video. I'm not sure to understand. During the video you say that network server can decrypt payload and at the end you write "it's possible to have end-to-end encryption" Does the network server have an access to the LoRa data ?
Read: www.thethingsnetwork.org/forum/t/separation-and-distribution-of-otaa-keys/17225 and www.thethingsnetwork.org/forum/t/where-is-appskey-stored-and-handled/29819/2
pls clarify my doubt
does enddevice can communicate directly with network server,if so wht is the use of using gateway
An end device does NOT communicate directly with network server.
An end device communicates with a gateway (thru LoRa radio) and the gateway sends the received data to the network server using an internet connection.
Note: It is possible to install a network server onto a gateway.
If you find this confusing. Think of the following:
Your (4G) mobile phone (= end device) sends data to your mobile operator mast (= gateway) and your mobile operator sends the transmitted data to a server for example (google) (= network server)
If I may ask, Do you know of any publicly available pen testing tools made specifically for LoRaWAN?
Sorry I do not know but if you do please let me know. I am also curious.
How many lora node can communicate with single channel gate way.
I got a simple questions. Is this code valid for another host/server apart from TTN? Can you use the IDs and Keys from another provider???? Thanks
To be honest I do not know. But if I were you I would ONLY use the IDs and keys generated by the other provider.
If I buy some end device which needs a connection the a specific network server, how does the gateway know which network server to send the message?
You specify it yourself. See www.mobilefish.com/download/lora/lora_part28.pdf page 54,55 and 56
@@Mobilefish Ok, at the gateway... I was a little confused about this. So the network server and gateway are paired. That's fine. I was actually curious how the message ends up in the right application server. Does the network server keep a map of the AppKeys and addresses of all application servers in the world or how does it work? Is the mapping updated between network servers? Or can the message travel between network servers until the right application server is found (if it's not found in the first one)? Are there other components in addition/between network servers that handle finding the right application server (sort of routers or name servers)?
What does "EUI" mean? I know the meaning, but don't know how it's written. Please help :)
Great Vid btw. Keep up the work.
EUI = Extended Unique Identifier. A globally unique number.
What is MIC? and How it is generated?
Correct me if I'm wrong. I'm still learning myself. But I think it goes like this: MIC stands for Message Integrity Code. It tells if the message has been forged or not by some other party. It is calculated from the message with a help of a secret key (AppKey) which only end device and network server know. If you don't know the secret code, you can't end up in the same MIC that end device or network server can calculate. Calculating and verifying MIC prevents e.g. forging the source, destination or the payload of the message.