ABP LoRaWAN Sensors in Remote Irrigation
Riverton Irrigation Cooperative runs 1,200 LoRaWAN soil-moisture sensors and 14 gateways across 60 km of farmland. Three hundred sensors installed in 2021 use ABP with static root and session keys; the rest use OTAA. Gateways sit in padlocked cabinets on wooden poles, some within reach of a public road. The network server is vendor-hosted, and downlinks command irrigation valves. A former contractor's laptop still holds gateway credentials. This week, twelve sensors' uplinks appeared at two gateways with identical payloads but different arrival times; one gateway EUI is not on the approved list. The network server deduplicates on frame counter and MIC, so operations saw no duplicate valve commands, but the security team is concerned about a rogue gateway. The cooperative has no spare gateways and depends on the vendor for network-server changes.
1. What can a rogue LoRaWAN gateway actually do in this deployment, and how would you validate the anomaly?
Read the worked answer
A LoRaWAN gateway is a packet forwarder; it does not hold application or network session keys, so a rogue gateway cannot decrypt uplinks by itself. But it can inject forged uplinks if it also has keys, replay captured frames within the frame-counter window, drop or delay traffic, and provide false coverage. In this deployment the former contractor's laptop with gateway credentials is the more serious finding than the duplicate payloads. Validate by checking the unapproved gateway EUI against the join server and network server allowlist; capture its backhaul IP, location, and first-seen time; compare frame counters and MICs for the twelve sensors; look for ABP devices whose counters were reset. If any ABP key is exposed, assume forgery is possible. Contain by disabling the unapproved gateway, rotating gateway credentials, and reviewing who can add EUIs. Do not rely on deduplication alone; it hides duplicate delivery but not malicious injection.
2. How should the cooperative migrate 300 ABP sensors without disrupting irrigation?
Read the worked answer
ABP migration is a rekeying project, not a firmware update. For each of the 300 sensors, provision a unique DevEUI, JoinEUI, and root key in the join server; schedule OTAA joins in batches by irrigation zone, outside peak watering windows. Expect join storms and downlink congestion: throttle joins, stagger them over days, and monitor join-accept and join-fail rates. Keep ABP fallback only for devices that cannot be moved and isolate them in a separate application with strict frame-counter monitoring. For devices that support remote reconfiguration, use a signed downlink to switch mode; for those that do not, use a technician visit during the dry season. The judgment is to avoid a big-bang cutover: a failed join during irrigation can cost a crop, so migration must be reversible and scheduled with operations.
3. How should physical gateway risk be prioritized across 14 sites?
Read the worked answer
Prioritize by accessibility and consequence, not by count. Score each of the 14 sites on public-road proximity, lock type, whether the gateway is the sole backhaul for a valve-control zone, and whether tamper detection exists. Sites that are both reachable and critical get locked metal cabinets, tamper switches, and cellular backhaul with a private APN; remote sites with redundant coverage can use the current cabinet plus a heartbeat. Add gateway configuration attestation: the network server should alert on a new gateway EUI, a changed packet-forwarder version, or a backhaul IP outside the approved range. Physically, replace padlocks with keyed locks and log key holders; a padlock is a delay, not a control. The residual risk is that a determined attacker can steal a gateway; the design should assume that and protect the keys, not just the box.