To ensure that a LoRaWAN®-based device can be uniquely and securely identified on a network, it needs a unique ID and other security key material. Using a device’s unique, built-in identifier and deriving the appropriate key material is called provisioning the device. In this article, we’ll take a look at the best practices for provisioning your devices.
At the point of manufacture, unique identifiers are built into the devices. These include both a unique device identifier (DevEUI) and a join server unique identifier (JoinEUI). While the DevEUI uniquely identifies the device, the JoinEUI indicates the person or entity that manages the network security and authorizes the device to join the network.
Both the join server and the end device share a secret key, referred to as the AppKey in the LoRaWAN 1.0.x specification, and as the NwkKey in 1.1.x. When a device is activated, the device (identified by its DevEUI) and its join server (identified by the JoinEUI) will exchange as series of join request (in clear text), followed by a join accept frame (encrypted with either the NwkKey or the AppKey). This allows them to exchange nonces and symmetrically derive session keys, encrypting and authenticating the ensuing traffic.
So, how does a DevEUI get created? Where does it come from?
A DevEUI is a 64-bit globally-unique Extended Unique Identifier (EUI-64), obtained by the manufacturer from the IEEE Registration Authority. The header of the EUI-64 it the Organizationally Unique Identifier (OUI) of that company, and the manufacturer must ensure that all DevEUIs picked in the range are unique.
Note: Some of Semtech’s LoRa® transceivers are serialized, and their serial numbers, derived with Semtech’s OUI, can be used in the LoRaWAN context, and are unique.
When working with a collection of DevEUIs, it is a good idea for manufacturers to segment blocks of DevEUIs, designating different attributes on a per-block basis. For example, a manufacturer might use one block for testing and experimentation, and another for production devices. Or they might assign different blocks to different frequency bands.
Part of the purpose of using JoinEUIs is to consolidate devices. So, while multiple JoinEUIs can point to the same join server, avoid creating unique JoinEUIs for individual devices.
Creating a Device Address
Over-the-Air Activation (OTAA) is the preferred method for joining a device to a network. During this process, devices are assigned a device address (DevAddr). There are edge cases, however, that require a device to be activated by personalization (ABP). With this approach, it is necessary to create the DevAddr manually. This requires concatenating the address prefix (AddrPrefix) with the network address. The address prefix is an identifier unique to each network that has been granted a NetID. These prefixes are allocated by the LoRa Alliance®.
If you don’t know the NetID to which your devices will be allocated, use the experimental network reserved for this purpose. The address prefix for this network can be either AddrPrefix = 0b0000000 or AddrPrefix = 0b0000001.
DevNonce and FCNT
To ensure the effectiveness of the LoRaWAN security measures, the DevNonce and frame counters (FCNT) should be implemented as persistent counters.
With each join attempt for a given JoinEUI, the DevNonce counter SHALL be incremented.
Frame counters SHALL persist over the course of an entire network session. While an end device using OTAA may reset the FCNT, frame counter values SHALL not be reused with the same session keys. In practice, this means that devices which use Activation by Personalization (ABP) MUST use non-volatile memory to persist the frame counter, since ABP device have only one session key by definition.
For additional information about provisioning best practices and other aspects of developing LoRaWAN-based devices, see Developing LoRaWAN-based Devices: Things to Know.
Semtech, the Semtech logo and LoRa® are registered trademarks or service marks of Semtech Corporation or its affiliates.