LoRA WAN device activation (OTAA and ABP)

19 Aug 2020 - tsp
Last update 19 Aug 2020
Reading time 9 mins

TL;DR: OTAA assigns network and application session keys as well as 4 byte device address dynamically and allows for roaming and identifies the device using it’s device EUI as well as the application using the application EUI and the application key; ABP assigns both session keys and the device address statically and doesn’t allow for roaming and requires centralized administration.

Since device activation seems to be somewhat like black magic to many people playing around with LoRA-WAN devices these days I decided to write a short introduction on the role of activation from the networks point of view. It’s a rather high level introduction - in case on wants to implement activation the LoRA WAN specification is the source to rely on.

Just before talking about activation let’s recall the packet format used by LoRA-WAN on the PHY and MAC layer:

As one can see the only way a device can be identified is the DevAddr. This field contains a short 7 bit network identifier that selects a network which allows up to 128 networks to operate overlapping in the same area. The remaining bits identify the device inside of the specific network - one can think of the DevAddr being something similar to an IP address except that there is no other subnetting than the network ID. Note that this of course would mean that only 33.554.432 devices could be present inside a single network. That might sound much but as one has seen from IPv4 address space exhaustion this is a really small key space. Fortunately one can use different encryption keys during message integrity code calculation to further differentiate. This is possible since two devices using the same DevAddr but different session keys will produce invalid integrity codes from the point of view of the other device and other application.

Persistent state on the device

What’s activation all about? Basically it’s about the determination of four parameters on the end device:

Depending on the used activation method different initial state is required on the devices. But what are these three stateful variables used for?

The device address DevAddr consists of a 32 bit identifier that identifies the device uniquely within it’s current network. The most significant 7 bits are used as an network identifier, sometimes called NwkID. These network IDs are usually centrally assigned to separate different network providers in a given geographic location. Note that this of course limits the number of networks to 128. The least 25 bits sometimes called NwkAddr of an end device have to be assigned arbitrarily by the network management and have to be unique inside the network. Depending on the used activation procedure one has to centrally assign the NwkAddr (ABP) or is able to do this dynamically (OTAA).

There are two other unique known addresses from the EUI64 namespace:

The other two stateful variables NwkSKey and AppSKey are AES-128 encryption keys. Since they’re session keys they should be unique for each device. Depending on the activation method they’re pre-programmed or derived during the join procedure. The network session key NwkSKey is used to verify the message integrity of data messages on the network server and device end - and it’s used to encrypt MAC-only messages. The AppSKey is an application session key that’s used - on the other hand - to encrypt but not integrity protect application payload. This encryption happens between the end device and the application server - although the specification clearly states that this encryption layer does not guarantee confidentiality or integrity. One should use an application layer cryptosystem if this level of integrity or confidentiality is required.

OTAA (Over-the-air activation)

OTAA is the preferred activation mechanism to determine the DevAddr as well as the two session keys. It initially requires:

The device also has to create a 2 byte random value that should never be reused. This DevNonce is used to prevent replay attacks. The network server at least keeps track of the previous DevNonce and discards it at the earliest at the next successful join operation of a device.

The device joins the network by transmitting a join message. This message contains:

This join message is not encrypted but message integrity protected using

cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce)
MIC = cmac[0..3]

As one can see the AppKey is used for the calculation of the message integrity code. Note there is no limitation on the data rate and channels to be used so devices might try a variety of them starting with high bandwidth short range messages or multiple data rates at once.

The next step is the response of the network server - which is a standard downlink message inside the receive window with some different timing constraints than usual. The join accept message contains:

The nonce again is a random unique value that is provided by the network server. It’s used to derive the session keys:

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad_16)
AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pat_16)

cmac = aes128_cmac(AppKey, MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList)
MIC = cmac[0...3]

The join accept message is encrypted with the AppKey:

aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList | MIC)

As one can see the message integrity code is contained inside the encrypted payload - one can compare this with an sign then encrypt schema. The usage of the decrypt operation for encryption allows to reduce the number of operations required on the device - since encrypt and decrypt are inverse functions applying decrypt and then encrypt provides the same result as encrypt and then applying decrypt.

ABP (Activation by personalization)

This is the older and discouraged alternative to more complex OTAA. Basically OTAA is used to derive two session keys and a device address. With ABP these values

are stored during device firmware flashing. Of course the DevEUI is already known since it’s known as soon as a LoRA MAC is present.

The main difference is that the session keys as well as the network unique device address have been preprogrammed which requires central coordination inside the network. This is not required for OTAA which allows roaming of devices between different networks when using OTAA as long as the networks support roaming. When using ABP the device is already assigned to a given network.

This article is tagged:

Data protection policy

Dipl.-Ing. Thomas Spielauer, Wien (webcomplains389t48957@tspi.at)

This webpage is also available via TOR at http://rh6v563nt2dnxd5h2vhhqkudmyvjaevgiv77c62xflas52d5omtkxuid.onion/

Valid HTML 4.01 Strict Powered by FreeBSD IPv6 support