From LoRaWAN 1.0 to 1.1: Security Enhancements
summary
A private LoRa test framework reproduces replay, keystream reuse and RNG flaws and finds backend exposures, memory dumps and side channels that extract keys after 40–50 join requests. LoRaWAN 1.1 splits network and application sessions, adds rejoin, multicast and more keys (nine vs a few), encrypts counters and prevents counter resets, which materially reduces replay risk. Remaining practical risks include gateway-server UDP plaintext, message‑length leakage without padding, and complex MAC flows that cause implementation deadlocks. Recommendations: prefer OTAA, rotate keys, use secure elements or HSMs, monitor gateways and pad or constant‑length payloads.
AI-written summary · about
chapters (5)
related talks
44mLoRaPWNing - how to attack and secure the LoRaWAN protocol
15mHow to design LoRaWAN® products for scale
24mMass Deployment of LoRaWAN Sensors
15mmanaged PKI solution offers additional security for LoRaWAN
14mEnabling Secure and Scalable Firmware Updates Over LoRaWAN
25mFirmware Updates Over The Air
36mLoRaWAN Network Server
27mDo's and don'ts: Electronics manufacturing and LoRaWAN devices
