LoRaWAN networks power critical infrastructure, but their security requires multiple layers of protection. Sensor access policies are the first defense, ensuring only verified devices connect. These policies use unique device identifiers and cryptographic keys to authenticate sensors, with Over-the-Air Activation (OTAA) offering dynamic rekeying for long-term deployments. LoRaWAN 1.1 improves security by introducing a Join Server and separating session keys, reducing risks tied to earlier versions.

Key Points:

• Sensor Access Policies: Authenticate devices using unique IDs and keys.
• OTAA: Generates new session keys for better security.
• Device Keys: Encrypt data and authenticate commands.
• Role-Based Access Control (RBAC): Manages user permissions and data access.
• Physical Security: Protects hardware with Secure Elements and tamper-resistant designs.

Each layer strengthens the network, addressing specific vulnerabilities. Combining these measures creates a solid framework for safeguarding LoRaWAN deployments.

LoRaWAN® Security – the Foundation for a Secure System

sbb-itb-0e600ab

1. Sensor Access Policies

Sensor access policies determine which devices can connect and communicate within a LoRaWAN network. By utilizing unique device identifiers and cryptographic keys, these policies ensure that every sensor on the network is verified. Essentially, they act as the first line of defense against unauthorized devices, laying the groundwork for more advanced security measures.

Each sensor is equipped with a globally unique 64-bit DevEUI and 128-bit root keys (AppKey and NwkKey in LoRaWAN 1.1). These keys are used to derive session keys during activation, ensuring that only authorized sensors can join the network.

The most secure method for enforcing these policies is Over-the-Air Activation (OTAA). This approach generates new session keys every time a device connects, offering a higher level of security compared to ABP (Activation by Personalization). ABP uses fixed keys, which can pose risks for unattended devices. OTAA, on the other hand, supports secure rekeying remotely, making it ideal for long-term deployments where physical access to devices is limited. If a key is compromised, OTAA allows for rekeying without needing to retrieve the device.

Once a device is authenticated, session keys enforce access policies by separating network-level traffic from application data. Specifically:

• The AppSKey encrypts the sensor’s payload, ensuring data remains private.
• Network session keys handle integrity and routing tasks.

This separation is a key feature of LoRaWAN 1.1, as it allows network operators to manage traffic without gaining access to the raw application data.

“Specifying effective policies prevents over privilege and data leakage, thereby ensuring the security of a system.” – Kaushik Ragothaman, Yong Wang, Bhaskar Rimal, and Mark Lawrence

These policies are designed to tackle several security threats. For instance:

• Nonces and frame counters block replay attacks.
• AES-128 encryption protects against eavesdropping.
• A Message Integrity Code (MIC) prevents tampering with transmitted data.

However, there is a challenge: legacy hardware. Many older sensors running LoRaWAN 1.0.x lack the capability to receive over-the-air updates, meaning they may never transition to newer, more secure versions of the protocol. This limitation highlights the importance of ongoing hardware updates for maintaining network security.

2. Device Keys

Device keys play a crucial role in LoRaWAN security by defining what devices can do once they’re connected to the network. While sensor access policies determine which devices can join, the device keys handle their operational permissions.

LoRaWAN employs two session keys to maintain security. The Application Session Key (AppSKey) ensures end-to-end encryption of sensor data, keeping it private – even from network operators. Meanwhile, the Network Session Key (NwkSKey) secures control messages between devices and the network server, ensuring operational integrity.

“LoRaWAN also boasts end-to-end security between the device and the application server using an application session key, which protects in confidentiality the applicative payload, shielding it away from the prying eyes of the operator.” – ACM Symposium on Applied Computing

This dual-key system tackles two major IoT threats: eavesdropping, prevented by AppSKey encryption, and command spoofing or injection, blocked by NwkSKey authentication. Operationally, it also separates responsibilities – allowing network operators to handle traffic and routing without accessing sensitive application data.

However, earlier versions like LoRaWAN 1.0 had a notable vulnerability. Both session keys were derived from a single master key and generated by the same network server, meaning a compromised master key could expose the entire system. The updated LoRaWAN 1.1 protocol addresses this by introducing a Join Server to independently manage root keys. It also expands the network session keys into three distinct keys (FNwkSIntKey, SNwkSIntKey, and NwkSEncKey), isolating security functions for better protection. All keys, regardless of version, are 128 bits long and use AES-128 encryption.

For large-scale deployments – like those in agriculture or manufacturing – managing keys can become complex. To simplify this, use OTAA (Over-the-Air Activation) for dynamic key generation. In LoRaWAN 1.1 networks, it’s recommended to manage root keys through a dedicated Join Server. This approach keeps the responsibilities clear: if a key is compromised, you can pinpoint the affected layer and address the issue without disrupting the entire network.

3. Role-Based Access Control (RBAC)

Alongside sensor access policies and device key management, RBAC strengthens network security by controlling user permissions. While device keys handle data encryption, RBAC decides which roles can access decrypted data. This distinction is crucial in LoRaWAN networks.

RBAC assigns permissions to roles rather than individuals. For instance, a “Network Operator” might handle traffic routing and manage MAC layer commands, while a “Data Analyst” would only access decrypted sensor readings. In LoRaWAN 1.1, roles are clearly divided: the Network Server (NS) ensures network operations, while the Application Server (AS) holds the AppSKey to decrypt data payloads.

“In LoRaWAN 1.0.x, only the application root key (AppKey) existed to derive the application session key (AppSKey) and NwkSKey, removing the independence of network and application keys and requiring the application provider’s full trust in the network operator.” – Frank Hessel, Lars Almon, and Matthias Hollick

This updated structure solves a major flaw in earlier versions. In LoRaWAN 1.1, the introduction of a Join Server (JS) as a neutral third party ensures that the NS cannot access the AppSKey. This separation means even if the NS is compromised, it cannot decrypt sensitive data like temperature or CO₂ readings. This enhanced key management creates a solid foundation for RBAC to manage user-level access.

4. Physical Security Controls

While software tools like RBAC and device keys help safeguard data, physical security measures are essential for protecting the hardware itself. This is especially critical for LoRaWAN, a wireless technology that lacks a fixed physical boundary, leaving devices vulnerable to risks like eavesdropping and unauthorized access. These physical defenses work hand-in-hand with the protocol-level protections already in place.

“Unlike wired infrastructure, there is no physical perimeter protecting communication. Any attacker within radio range can attempt eavesdropping, replay attacks, traffic modification, or unauthorized network access.” – Carlo Tinella, Semtech

One of the most effective hardware defenses for LoRaWAN end-devices is the use of Secure Elements. These are specialized chips designed to store cryptographic keys in a way that prevents them from being read, much like how a SIM card operates. Even if a device is compromised, Secure Elements ensure the cryptographic keys remain protected. On the backend, systems like the Join Server rely on Hardware Security Modules (HSMs) for similar protection. These modules are widely trusted in industries like banking and telecommunications.

A key aspect of physical security is keeping root keys strictly confidential. This means they should never be printed on the device casing or included in documentation. As Carlo Tinella from Semtech puts it, “Cloning or impersonating a device is prevented by keeping the root key strictly confidential: stored in dedicated memory or hardware that is not readable, not printed on the device, and is never exposed in documentation.” Any failure to follow this principle could compromise the entire security framework.

However, introducing physical security measures does come with its challenges. For example, integrating Secure Elements requires specialized hardware and additional supply chain controls. LoRaWAN sensors are often deployed in unattended environments, making tamper-resistant, durable hardware essential. Choosing LoRaWAN Certified devices ensures they meet strict security standards, offering peace of mind for procurement teams.

At CHOOVIO, we take physical security seriously. Our IoT sensor solutions incorporate trusted Secure Elements and adhere to rigorous certification standards, ensuring secure, long-term deployments for our customers.

Pros and Cons of Each Security Measure

No single security measure can handle every aspect of security on its own. Instead, each layer – sensor access policies, device keys, RBAC, and physical controls – brings its own strengths and challenges. Understanding these trade-offs is essential when designing or expanding a LoRaWAN deployment.

Each measure plays a unique role in securing a LoRaWAN network. Sensor access policies are particularly useful in dynamic environments with multiple users, but they demand careful design to manage effectively at scale. RBAC, on the other hand, is easier to implement for large teams but struggles with flexibility in scenarios requiring fine-grained control.

Physical controls, while effective at preventing hardware tampering, are often expensive and impractical to retrofit after deployment. This makes it crucial to invest in tamper-resistant, certified hardware from the outset. As noted:

“Due to the variety of IoT applications, there is no one-size-fits-all solution for access control in the IoT.”

For the most robust security, LoRaWAN networks often combine all four measures. By layering cryptographic key management, context-aware access policies, role-based permissions, and physical protections, networks can create a more comprehensive and resilient security framework.

Conclusion

Securing a LoRaWAN network isn’t about relying on a single solution. While sensor access policies are crucial in dynamic environments, they need to be part of a broader, more integrated security strategy.

A resilient LoRaWAN setup combines several elements: context-aware policies, AES-128 encryption, hardware-based key protection, and OTAA for generating dynamic session keys. FUOTA plays a key role in enabling security updates over time, which is vital for long-term deployments.

Together, these measures create a robust defense system. As Carlo Tinella of Semtech aptly put it:

“The question isn’t just ‘does this technology work?’ but ‘can I trust it with my data, my devices, and my compliance obligations?'”

This layered strategy tackles security challenges by automating policy management, using a dedicated Join Server to keep network and application keys separate, and closely monitoring frame counters. These steps significantly reduce risks while avoiding the need for a complete infrastructure overhaul.

For organizations scaling LoRaWAN – whether in agriculture, smart cities, or industrial applications – the key is a defense-in-depth approach. Each layer of security works to offset potential vulnerabilities in others. CHOOVIO’s solutions embody this philosophy by integrating sensor access policies, strong encryption, and secure hardware, making it simpler to create networks that are both effective and secure. These combined measures establish a solid framework for safeguarding LoRaWAN deployments.

FAQs

When should I choose OTAA over ABP?

When deciding between OTAA (Over-the-Air Activation) and ABP (Activation by Personalization), consider your priorities like security, scalability, and device mobility. OTAA is ideal when you need stronger security and flexibility. It generates session keys dynamically during a secure join process, minimizing the risk of key compromise. Plus, it allows devices to rejoin the network seamlessly without requiring physical reprogramming.

On the other hand, ABP uses static keys, making it less secure and more susceptible to compromise. This option works best for quick testing or straightforward setups where security isn’t a top concern.

How does LoRaWAN 1.1 reduce key-compromise risk vs 1.0.x?

LoRaWAN 1.1 strengthens security by refining key management and enhancing protocol safeguards. One of the key updates is the introduction of two distinct master keys: NwkKey for network operations and AppKey for application data. This separation ensures that even if the network key is exposed, application payloads remain protected. Other improvements, such as nonce registration and fixes for counter overflow issues, tackle vulnerabilities found in earlier versions, reducing the risk of replay attacks and similar threats.

What do Secure Elements protect that encryption can’t?

Secure Elements protect cryptographic keys and sensitive information directly within hardware, making them resistant to physical attacks and tampering. Unlike relying solely on encryption, they add an extra layer of protection, ensuring these critical assets stay safe even if other security measures fail.

Related Blog Posts

• Ultimate Guide to Industrial IoT Sensor Selection
• Healthcare IoT: 6 Best Patient Monitoring Sensors
• How to Configure OTAA for LoRaWAN Devices
• LoRaWAN Network Server Standards: What to Know