Data in LoRaWAN networks are transferred in similar way as in WiFi and LTE networks – via the air. These types of network are therefore more exposed and vulnerable to cyber attacks than physically wired networks.
How exactly is it protected then? How does a device authentication and data encrypting in LoRaWAN networks work?
Mutual authentication runs already during the process of connecting an endpoint into LoRaWAN network. Thanks to that, no unauthorized / unknown devices will be connected.
LoRaWAN MAC commands and payloads are secured by origin protection, integrity and encrypting. Combined with mutual authenticetion, we achieve that network communication:
- will not be altered,
- comes from trusted device,
- is incomprehensible for eventual eavesdropping.
LoRaWAN, as one of the few IoT networks, implements end-to-end encryption for payloads, exchanged between endpoints and application servers. Although network traffic is encrypted via aerial interface in some traditional, cellular networks, it is transfered as a plain text within the basic network. Therefore, end users are forced to select, deploy and manage another security layer (usually implemented using some type of VPN encryption or application layer, such as TLS). This approach is not suitable for LoRaWAN networks, as additional secure layers increase energy consumption, complexity of infrastructure and costs as well.
Security mechanisms stated above rely on standardized, proved cryptographic algorithms AES, approved by NIST (National Institute of Standards and Technology). These are generally accepted as one of the best security approaches for network communication encryption. LoRaWAN security uses AES combined with several operation modes:
- CMAC (Cipher-based Message Authentication Code) for integrity protection,
- CTR for encryption.
Each endpoint is personalized with 128-bit AES key (called AppKey) and the globally unique identifier (DevEUI, based on EUI-64). These keys are used during the device authentication. In order to receive EUI-64 identifiers, an applicant (device producer) must be assigned with the unique identifier OUI (Organizationally Unique Identifier) from registration authority IEEE (Institute of Electrical and Electronics Engineers).
LoRaWAN networks are identified by the unique identifier, assigned by LoRa Alliance.
LoRaWan application payloads are always end-to-end encrypted between the device and the application server. The integrity protection is provided by so-called hop-by-hop method:
- one air hop (jump) via integrity protection LoRaWAN protocol,
- another air hop between the network and the application server using secure connection technologies, such as HTTPS or VPN.
IoT device authentication
LoRaWAN supports two methods of the device connection:
- OTAA (Over The Air Activation)
- ABP (Activation By Personalization)
If OTAA is used, the request for endpoint connection is sent. The network verify device’s identifier (AppEUI) and AppKey, provided by endpoint, after accepting the request. If these keys are valid, the connection acceptance message is sent back to the endpoint.
OTAA (or joining sequence) verifies that both the endpoint and the network have the same AppKey. This validation is performed by AES CMAC calculation, using the endpoint AppKey in order to secure integrity and authenticity of transferred data.
Subsequently, two keys are deduced for:
- securing integrity protection and encryption of LoRaWAN MAC commands and payload (Network Session Key – NwkSKey),
- end-to-end payload encryption (Application Session Key - AppSKey).
The NwkSKey is distributed into LoRaWAN network to ensure data packets authenticity and integrity. Similarly, the AppSKey is distributed into application server for payload decryption.
When the ABP is used, there is no initial communication between the endpoint and the network. The device can send data immediately after the connection is successful. Both encryption keys (AppSKey and NwkSKey) are set once and must be same at both sides.
The recommended and safer way of connecting the endpoint to LoRaWAN network is the OTAA method, as encryption keys are generated during every connection session.
Data integrity and credibility protection
LoRaWAN communication is protected by two relation keys. Each payload is encrypted by AES CTR, carries a frames counter (prevents the packet replay) and a message integrity code (MIC), which is calculated with AES CMAC (prevents unauthorized packet manipulation).
Physical LoRaWAN devices security
The AppKey, NwkSKey and ApPSKey are permanently stored inside the endpoint. Therefore, the protection of these keys depends on quality of the physical device security. If the endpoint is exposed to physical threats, keys can be stored in a durable storage (Secure Element), where the keys‘ extraction is extraordinary hard.