6.2 Over-the-Air Activation

  1. For over-the-air activation, end-devices must follow a join procedure prior to participating in

3 data exchanges with the network server. An end-device has to go through a new join

  1. procedure every time it has lost the session context information.
  2. The join procedure requires the end-device to be personalized with the following information
  3. before its starts the join procedure: a globally unique end-device identifier (DevEUI), the
  4. application identifier (AppEUI), and an AES-128 key (AppKey).
  5. The AppEUI is described above in 6.1.2.
9 Note: For over-the-air-activation, end-devices are not personalized
10 with any kind of network key. Instead, whenever an end-device joins a
11 network, a network session key specific for that end-device is derived
12 to encrypt and verify transmissions at the network level. This way,
13 roaming of end-devices between networks of different providers is
14 facilitated. Using both a network session key and an application
15 session key further allows federated network servers in which
16 application data cannot be read or tampered with by the network
17 provider.

6.2.1 End-device identifier (DevEUI)

  1. The DevEUI is a global end-device ID in IEEE EUI64 address space that uniquely identifies
  2. the end-device.

6.2.2 Application key (AppKey)

  1. The AppKey is an AES-128 root key specific to the end-device.1 Whenever an end-device
  2. joins a network via over-the-air activation, the AppKey is used to derive the session keys

24 NwkSKey and AppSKey specific for that end-device to encrypt and verify network

  1. communication and application data.

6.2.3 Join procedure

  1. From an end-device‘s point of view, the join procedure consists of two MAC messages
  2. exchanged with the server, namely a join request and a join accept.

6.2.4 Join-request message

30 The join procedure is always initiated from the end-device by sending a join-request
31 message.
32
Size (bytes) 8 8 2
Join Request AppEUI DevEUI DevNonce
  1. The join-request message contains the AppEUI and DevEUI of the end-device followed by a
  2. nonce of 2 octets (DevNonce).

1. Since all end-devices end up with unrelated application keys specific for each end-device, extracting the AppKey from an end-device only compromises this one end-device.

©2016 LoRa™ Alliance Page 33 of 70

The authors reserve the right to change specifications without notice.

LoRaWAN Specification

  1. DevNonce is a random value.1For each end-device, the network server keeps track of a
  2. certain number of DevNonce values used by the end-device in the past, and ignores join
  3. requests with any of these DevNonce values from that end-device.
4 Note: This mechanism prevents replay attacks by sending previously
5 recorded join-request messages with the intention of disconnecting the
6 respective end-device from the network. Any time the network server
7 processes a Join-Request and generates a Join-accept frame, it shall
8 maintain both the old security context (keys and counters, if any) and
9 the new one until it receives the first successful uplink frame using the
10 new context, after which the old context can be safely removed. This
11 provides defense against an adversary replaying an earlier Join-
12 request using a DevNonce that falls outside the finite list of values
13 tracked by the network server.
  1. The message integrity code (MIC) value (see Chapter 4 for MAC message description) for a
  2. join-request message is calculated as follows:2

16

  1. cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce)
  2. MIC = cmac[0..3]
  3. The join-request message is not encrypted.
  4. The join-request message can be transmitted using any data rate and following a random
  5. frequency hopping sequence across the specified join channels. It is recommended to use a
  6. plurality of data rates. The intervals between transmissions of Join-Requests shall respect
  7. the condition described in chapter 7.

6.2.5 Join-accept message

  1. The network server will respond to the join-request message with a join-accept message if
  2. the end-device is permitted to join a network. The join-accept message is sent like a normal
  3. downlink but uses delays JOIN_ACCEPT_DELAY1 or JOIN_ACCEPT_DELAY2 (instead of
  4. RECEIVE_DELAY1 and RECEIVE_DELAY2, respectively). The channel frequency and data
  5. rate used for these two receive windows are identical to the one used for the RX1 and RX2
  6. receive windows described in the ―receive windows‖ section of the LoRaWAN Regional
  7. Parameters document [PARAMS].
  8. No response is given to the end-device if the join request is not accepted.
  9. The join-accept message contains an application nonce (AppNonce) of 3 octets, a network

34 identifier (NetID), an end-device address (DevAddr), a delay between TX and RX

  1. (RxDelay) and an optional list of channel frequencies (CFList) for the network the end-
  2. device is joining. The CFList option is region specific and is defined in the LoRaWAN
  3. Regional Parameters document [PARAMS].

38

Size (bytes) 3 3 4 1 1 (16) Optional
Join Accept AppNonce NetID DevAddr DLSettings RxDelay CFList
  1. The DevNonce can be extracted by issuing a sequence of RSSI measurements under the assumption that the quality of randomness fulfills the criteria of true randomness
  2. [RFC4493]

©2016 LoRa™ Alliance Page 34 of 70

The authors reserve the right to change specifications without notice.

LoRaWAN Specification

  1. The AppNonce is a random value or some form of unique ID provided by the network server
  2. and used by the end-device to derive the two session keys NwkSKey and AppSKey as
  3. follows:1
  4. NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)
  5. AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)
  6. The MIC value for a join-accept message is calculated as follows:2
  7. cmac = aes128_cmac(AppKey,
  8. MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList)
  9. MIC = cmac[0..3]
  10. The join-accept message itself is encrypted with the AppKey as follows:
  11. aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList |
  12. MIC)
13 Note: The network server uses an AES decrypt operation in ECB
14 mode to encrypt the join-accept message so that the end-device can
15 use an AES encrypt operation to decrypt the message. This way an
16 end-device only has to implement AES encrypt but not AES decrypt.
17
18 Note: Establishing these two session keys allows for a federated
19 network server infrastructure in which network operators are not able
20 to eavesdrop on application data. In such a setting, the application
21 provider must support the network operator in the process of an end-
22 device actually joining the network and establishing the NwkSKey for
23 the end-device. At the same time the application provider commits to
24 the network operator that it will take the charges for any traffic incurred
25 by the end-device and retains full control over the AppSKey used for
26 protecting its application data.

27 The format of the NetID is as follows: The seven LSB of the NetID are called NwkID and 28 match the seven MSB of the short address of an end-device as described before.

  1. Neighboring or overlapping networks must have different NwkIDs. The remaining 17 MSB
  2. can be freely chosen by the network operator.
  3. The DLsettings field contains the downlink configuration:

32

Bits 7 6:4 3:0
DLsettings RFU RX1DRoffset RX2 Data rate

33

  1. The RX1DRoffset field sets the offset between the uplink data rate and the downlink data
  2. rate used to communicate with the end-device on the first reception slot (RX1). By default
  3. this offset is 0.. The offset is used to take into account maximum power density constraints
  4. for base stations in some regions and to balance the uplink and downlink radio link margins.
  5. The actual relationship between the uplink and downlink data rate is region specific and
  6. detailed in the LoRaWAN Regional Parameters document [PARAMS].
40 The delay RxDelay follows the same convention as the Delay field in the
41 RXTimingSetupReq command.
  1. The pad16 function appends zero octets so that the length of the data is a multiple of 16.
  2. [RFC4493]

©2016 LoRa™ Alliance Page 35 of 70

The authors reserve the right to change specifications without notice.

LoRaWAN Specification

results matching ""

    No results matching ""