In part 1, we described the process of providing end-to-end security and some of the challenges in achieving network security. In this installment, we will go over how authentication work to achieve end-to-end network security between the end devices and the application servers.
Device authentication and key management
Each LoRaWAN device is given a unique 128-bit AES key (called AppKey) and a globally unique identifier (EUI-64-based DevEUI) for authentication purposes. For LoRaWAN, there are two ways for an end device to initiate a connection request to the application server: over-the-air activation (OTAA) and activation by personalization (ABP). Successful connection involves authentication using multiple keys after acceptance of the activation request. Only after the activation process is completed can encryption be applied. Otherwise, either the end devices or the application server will not have the key to decrypt a message.
It’s as if two countries engage in a battle, and the commander-in-chief delivers a secret message to the field operator. Not wanting the enemies to know the content, the message is encrypted. But the field operator must first have access to the method of deciphering (the key) the secret message. Otherwise, the message can never be deciphered. But if the method of deciphering (the key) is stolen by the enemy, the secret message is not a secret anymore.
What is a key? It is a series of long codes. When it used properly, both the application server and the end devices can decipher the encrypted messages both ways. Note that LoRaWAN specification 1.0x specifies one root key is issued while specification 1.1 specifies two root keys are issued. But the concept of key management remains the same.
How do OTAA and ABP work?
In OTAA, multiple keys are involved. Here is how it works.
Step 1: The end device sends an unencrypted activation request known as the Join Request to the application server. Usually, it will go through a gateway device and the network server before reaching the application server. It is similar to sending an email. The email will go through your router, then the modem and through the servers of your network provider such as ATT, Spectrum Cable or others. The join request is a long code that contains the device information, DevNonce (a unique random number) and a message integrity code (MIC). DevNonce, the unique 16-bit random number generated by the end device, can be used only once to ensure that the hacker cannot use it again to prepare for the next attack. The MIC is created using an algorithm to create a checksum. This algorithm uses the 128-bit CMAC-AES encryption with the AppKey (issued to the end device). Note that at this point, no encrypted data has been generated.
Step 2: The gateway device, upon receipt of the Join Request, will send back a Join Accept to the end device. This Join Accept message consists of an AppNonce, information generated by the application server, an ID and other relevant information. Note that that the Join Accept message is encrypted with the AppKey as described in Step 1 above.
Step 3: Upon receipt of the Join Accept, the end device can now derive a new key called a “session key.” This key is created with random Nonces (the DevNonce and the AppNonce) information received back from the Join Accept. Note that the “session key” is actually a set of keys called NwkSKey and AppSKey. Because the “session key” is good only for one session or one-time data transfer, hackers cannot copy and reuse. At this point, the encrypted data communication can be initiated.
Compared with OTAA, ABP is static and much simpler. Each device and server (network and application) is issued a set of keys one time. So long as the data messages are encrypted and decrypted using the same keys, the data transfer will be successful. The potential problem of ABP is that those keys are static. If they are stolen, copied or rekeyed, the network is compromised.
Summary
The open, standards-based, long-range wide area network commonly known as LoRaWAN provides low-power connections for many applications including smart homes, smart grids, infrastructure, smart farming, industrial IoT, smart cities and smart manufacturing. Each end device or edge device will need to go through a connection and authentication process to establish trust, so the application servers will know “You are who you say you are.” There are two different methods: OTAA and ABP. OTAA is more complicated but more secure. ABP is static and simpler, but the downside is that once the keys are stolen, the network is compromised. By comparison, OTAA uses “session keys” in which each communication session will make randomly generated keys, and hackers cannot reuse the stolen keys.
Questions remain, however. What is preventing hackers from stealing information or pretending to be the real device during the authentication process? How secure is the action and authentication process? In upcoming articles, we will explain the pitfalls of the network security and explore the hardware and partition approach to enhance network cybersecurity.
What is the key