Hi :) I've made a first attempt to add requirements for LoRaWAN, to resolve #81 . I couldn't find a single authoritative source (ex. NIST or ENISA guidelines), so I've based them on the sources below.
4.5.1: Version 1.0 has a number of known vulnerabilities that have been addressed in v1.1 ([1]).
4.5.2: The backend servers are considered as trusted by the LoraWAN spec. Compromise of those servers can lead to a widespread compromise in the LoraWAN ecosystem ([5]).
4.5.3: The integrity of LoRaWAN messages is not end-to-end verified (not between network server & backend), therefore MITM attacks are possible if the channel does not guarantee message integrity. The LoRaWAN payloads are end-to-end encrypted. See discussion in [2], "A lack of end-to-end integrity protection"
4.5.4: The LoRaWAN spec imposes that to reduce the impact in case of device compromise ([4]).
4.5.5: Since OTA firmware udpates are not possible, compromised devices can only be recovered with physical access (see [2], point "The key update is not specified").
4.5.6: This is a concern explored in [3], handling of off-sequence frame counters is left to the app and the developer.
4.5.7: As noted in [1], jamming LoRaWAN networks is easy and practical, therefore for L2 and L3 applications the gateway should be able to detect and alert when that happens.
Hi :) I've made a first attempt to add requirements for LoRaWAN, to resolve #81 . I couldn't find a single authoritative source (ex. NIST or ENISA guidelines), so I've based them on the sources below.
Sources:
Rationale: