Persistent Counters

The effectiveness of LoRaWAN security measures require that certain numbers, transmitted as plain text information, are considered invalid if repeated. As a result, these values must be incremented, to simplify implementing the LoRaWAN specification. When these values are implemented as counters, the end-device must store only the last value that was used to make sure that the value is not duplicated. Therefore, these numbers (counters) must be stored in a persistent, non-volatile and tamper-proof memory in the end device. The network will reject packets that reuse numbers that must be unique for an end-device. The following numbers should be implemented as persistent counters:

• DevNonce – The DevNonce should be incremented with each Join attempt for a specific JoinEUI. If a device changes or varies its JoinEUI during the Join procedure, maintain a separate, persistent DevNonce counter for each JoinEUI.


• FCNT – The frame counters should be persistent per each network session. An end-device that uses OTAA may reset the frame counters at the start of each session but must not reuse any frame counter values with the same session keys. An end-device that uses ABP must not reuse any frame counters and therefore must maintain persistent values.