19 Aug 2020 - tsp
Last update 19 Aug 2020
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:
FCtrlwhich allows to transmit control flags to modify data rates, transmit acknowledge packets, frame pending and retransmission attributes, etc.
FOptsthat can contain MAC commands on top of data packets.
FPort) that can be used to differentiate between different services. Port 0 is reserved for MAC commands, 224 is dedicated to the MAC layer test protocol. Values 1-223 can be used in an implementation specific way by the respective application.
AppSKey(see below) before the message integrity code is calculated. The used key is dependent on the port - in case of port 0 the
NwkSKeyis used instead of the application key.
As one can see the only way a device can be identified is the
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
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
DevAddr but different session keys will produce invalid integrity
codes from the point of view of the other device and other application.
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
NwkAddr (ABP) or is able to do this dynamically (OTAA).
There are two other unique known addresses from the
AppEUIis a global application ID. Since it’s an EUI64 it’s required to be globally unique like a Ethernet MAC address. It’s not required when using ABP activation method. The
AppEUIhas to be pre-programmed on a device when using OTAA.
DevEUIis an unique EUI64 device address. This is also unique like an Ethernet MAC address and is always known on all devices during initial programming.
The other two stateful variables
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
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
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 is the preferred activation mechanism to determine the
as well as the two session keys. It initially requires:
AppEUIthat identifies the application.
DevEUI, the globally unique 8 byte device address that’s also preprogrammed.
AppKey. This is not a session key but a pre-shared application key.
The device also has to create a 2 byte random value that should never be reused.
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:
NetID. The 7 least significant bits are the network ID that match the 7 most significant bits from the addresses of end devices. Overlapping networks always have to differ in their network ID. The remaining 17 most significant bits can be freely chosen by the network operator.
DevAddr. Note that this is not the
DevEUI, this is a dynamically assigned local device address inside the current network.
RX1DRoffset, Bits 3 to 0 the
RX2data rate. This
RX1DRoffsetdescribes the difference between the data rate used by uplink and downlink channels to allow unlicensed operation of gateways. This information is needed for timing on the devices.
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
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.
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:
Dipl.-Ing. Thomas Spielauer, Wien (firstname.lastname@example.org)
This webpage is also available via TOR at http://coihcmhmb6cg6bvtelykwlte45yqhxkl6ffdoco5kc3a4qn3uno53oqd.onion/