According to the LoRaWAN 1.1 specification, the end device generates the DevNonce which is a 2-byte counter, starting at 0 when the device is initially powered up and incremented with every join-request.
The DevNonce value is used to prevent replay attacks.
This means a DevNonce value will never be reused and therefore an end-device must store the DevNonce in a non-volatile memory.
Question: Must an end device supporting LoRaWAN 1.1 have a non-volatile memory to store the DevNonce?
Note: Unfortunately the mcci-catena/arduino-lmic supports only LoRaWAN 1.0.2 and 1.0.3 so I could not test this myself.
Havenāt looked at the detail of it yet, but as an example, LoRaMAC-node will no longer support SAMR34 as it doesnāt have self-contained NVM - a bit childish as who the heck turns their nodes off and the leading secure element is the Microchip one which can store settings ā¦
But I suspect we are some time away from 1.1 being prevalent, not sure they have even modified the spec since 2017 ā¦
For 1.0.4 version of the specification, it is also mandatory to store the DevNonce in a NVM alongside with some other parameters.
The reason why the DevNonce must be stored in a NVM is due to the fact that the specification now mandates the use of a counter based DevNonce instead of random DevNonce.
Concerning LoRaMac-node support of the SAMR34 the issue is that we donāt have enough resources at the moment to implement the NVM storage support.
I have started to implement the support for the NVM as well as to update all the SAMR34 libraries. However, I did not had the time and donāt know when I will in order to finalize this work.
If someone is willing to help finalize the job I can provide a branch containing the work I have already done.
Also note that for the next release the 1.1.x and 1.0.x code bases are merged which means a single firmware will be able to support 1.0.x and 1.1.x network servers. The current master branch already reflects this.
Iāve not found any requirement to store the DevNonce in NVM - it just requires that the DevNonce increment and makes the suggestion that IF the power were to be restarted, that it may be useful to store it in NVM for retrieval at startup.
For deployment of a device, it joins, it runs, itās batteries die, it gets left to form part of the sedimentary level causing a strange shape in the rock when the aliens arrive to find out what happened to us after the seas rise and we go though another ice age. IF the device happens to be restarted due to a battery change or other reason, its first, possibly second join will fail but as the NS wonāt exactly be holding a value in the low teens, after a few futile tries it will join. Personally Iām likely to have something I can save settings in on the board, so having a stub for the developer to add saving settings, if the use case deems appropriate, is OK.
We already have had this issue come up with SAMR34 devices here where developers were testing using OTAA, hadnāt read the MLS release notes and get road blocked. Clearing the DevNonce at the command line is easy enough and switching to ABP for radio testing (and not using the radio when not testing the blindly obvious bit about sending) should solve most issues.
@mluis1, can you point me at your work in progress and I can see if itās feasible for me to pick it up.
Thank you, but Iāve read it before, several times, hence my original commentary - and for readability Iāve adjusted the image - please do not post images when you can copy & paste text.
The security of the node is up to the creator, it would only need to save the DevNonce if it was going to be certified, but then some storage may well be on board the device.
Not supporting SAMR34 because it doesnāt have internal NVM is taking a suggestion in the spec about how something should be done and extending outside of the reality zone of real life.
Thank you for adapting the image size. I used an image because it was easier to highlight the text.
The specification mandates the use of some sort of persistent memory.
āIf the end-device can be power-cycled, then DevNonce SHALL be persistent (e.g., stored in a non-volatile memory)ā
The important word here is SHALL.
The aim of the LoRaMac-node project is to provide examples that work out of the box using the supported platforms.
In SAMR34 example we try to use the internal MCU FLASH memory because the SAMR34 development kit does not provide any other possibility to persist data out of the box.
Nothing prevents the user to connect an external I2C/SPI NVM and adapt src/board/eeprom.c to use an external memory instead of the MCU FLASH memory.
All the provided examples require to have an NVM because all of them should pass the LoRa-Alliance pre-certification tests as well as to provide recommended good practices examples.
As a side note I think that security must be taken into account since the beginning of the end-device development. If we say we will do it later it will almost certainly not happen (will forget to do it at the end of the project development, time constraints to deliver the final product, etcā¦).
It would still be useful though if LoRaMac-node and the examples can use a modular mechanism for storing state, one which is not NVM type (or MCU family) bound.
E.g. by registering a callback(s) that does the actual reading and writing of the state data to and from NVM (whether builtin to the MCU or some type of external I2C or SPI NV storage).
This will make it easier to port to other architectures and other hardware.
@bluejedi At some point we still need to have access to the hardware that is able to store the data.
The purpose of src/board/<platform>/eeprom-board.c is to provide such interface implementation.
In case a user wants to use a different way to store his data it just needs to adapt the contents of eeprom-board.c to the used hardware.
When porting the LoRaMac-node project to another platform one is just required to implement the drivers under board directory. The minimum set of required files are listed in following document LoRaMAC: Porting Guide
I havenāt checked that code and the interface but that does not sound like modular design (to start with just the filenameā¦ eeprom). E.g. my FRAM would feel very disrespected with such a name.
I expect better from an essential library as LoRaMac-node.
Iāve fully acknowledged the specifications requirements, Iām referring to the non-mandatory eg that has ended up with a āNo NVM on SAMR34 therefore no further supportā in the release notes. Nothing in the specification means you can only service MCUās with internal flash/fram/dot-matrix-printer-with-OCR.
Providing sane & sensible links to allow the device designer to link any storage mechanism they like is much more flexible, as @bluejedi says, than just dropping the core line from one of the major silicon providers.
So why not create an example for the SAMR34 that has a secure element in the mix. Although it is quite bizarre that Microchip didnāt put one on their SAMR34 or WLR089U boards.
Good to know. Iām in full agreement, itās something Iāve been doing for a while now.
If you re-read what I typed, you see I never said anything about retro-fitting. But what I did imply is that shipping a device without a way of storing the DevNonce is up to the designer & the end user. Particularly if the unit is sealed with itās batteries (Iāve made a few, Iāve got a third-party moisture probe like that), then it canāt have itās power cycled so the SHALL becomes irrelevant.
And from where I sit, people pulling the little bit of plastic out the battery hole and sticking the device somewhere to never be looked at ever again is definitely a thing. So the power canāt be cycled, so no NVM required ā¦
A very wise man, @kersing, once said, as long as it is not detrimental to the network, then some flexibility should be expected. A device having an upset and taking two or three goes to advance through the DevNonces isnāt going to be the end of the world.
But, and hereās the kicker, you can tell why a device has restarted from itās power manager - as seen in the Microchip offerings so we have the option of incrementing the DevNonce by a chunk & a bit, say from 1 to 11 (I like prime numbers). So it can have two goes at joining without disrupting the specificationās karma.
There are plenty of things that could be improved.
Also I have plenty of ideas for improvements. The problem is the lack of resources and time to do such improvements.
As the name eeprom-board.c does not look to fit your requirement you could just rename it as well as the APIs in order to fit your requirement.
@descartes
Now I understand the confusion.
I guess that I did not choose the right words for the changelog file.
Known limitations
SAMR34 platform does not support NVM storage. This is a requirement for LoRaWAN versions greater or equal to 1.0.4. No work on this subject is forseen by the maintainers. Implementation proposals are welcome.
What I meant is that: āCurrently the SAMR34 platform does not support NVM storage by lack of drivers implementation.ā
The sentence This is a requirement for LoRaWAN versions greater or equal to 1.0.4 was to inform that currently we cannot run the pre-certification tests due to the missing NVM storage support.
The sentence No work on this subject is forseen by the maintainers goal was to indicate that adding this support is not supposed to happen in the near future.
In the mentioned text we also ask for help on implementing this support in order to speed up the process.
In addition I have already started to implement such support (few posts above). The problem is the lack of time to finalize it.
I will update the changelog in order to be more clear.
For the sake of completeness:
According to the LoRaWAN 1.1 specification
the devNonce and the JoinNonce should be stored at the device.
The device keeps track of the JoinNonce value used in the last successfully processed Join-accept (corresponding to the last successful key derivation). The device SHALL accept the Join-accept only if the MIC field is correct and the JoinNonce is strictly greater than the recorded one. In that case the new JoinNonce value replaces the previously stored one. If the device is susceptible of being power cycled the JoinNonce SHALL be persistent (stored in a non-volatile memory).
But if it canāt be power cycled, it SHALL form the basis of a battle of wills between corporate business and a small entrepreneurial electronics business based in the North of England ā¦
It is interesting wording to have SHALL but to undermine it so completely with āsusceptibleā. I think @descartes is completely correct with his implementation; his devices are not susceptible and so the SHALL doesnāt apply. Even a unit with replaceable batteries in O(years) wouldnāt be considered susceptible, my threshold would be āmains poweredā but ymmv.
The title of this topic is therefore incorrect too; they should be stored and compared, but lack of persistence is not a violation of the spec. Is that the position you arrived at too @robertlie ?
In theory (and practice) every device, appliance is susceptible to being power cycled (if not intentional then accidental).
To keep things simple, i.m.o. for new LoRaWAN developments it will be best to allways include and use some form of NV storage. (Yes, to make things āsimpleā, reliable and keep them working usually requires more work.)
@bwooce my interpretation is: both DevNonce and JoinNonce shall be stored in a Non-Volatile Memory (NMV). End-devices maybe solar powered, maybe maintained (eg plastic box damaged, send to repair), maybe moved from one location to another (eg beehives) but for the last 2 cases it maybe useful to power down the device for accurate data recording. If the DevNonce and JoinNonce are not persistent stored it will be difficult to make these devices work correctly again.
