Document

TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification

Issue link: https://read.uberflip.com/i/1428395

Contents of this Issue

Navigation

Page 45 of 89

LoRaWAN ® L2 1.0.4 Specification © 2020 LoRa Alliance ® Page 46 of 90 The authors reserve the right to change specifications without notice. The Join-Accept frame contains a Join-Server nonce (JoinNonce) of 3 octets, a network 1467 identifier (NetID), an end-device address (DevAddr), downlink configuration settings 1468 (DLSettings), a delay between TX and RX (RXDelay) and an OPTIONAL list of network 1469 parameters (CFList) for the Network the end-device is joining. The OPTIONAL CFList is 1470 region-specific and is defined in [RP002]. 1471 1472 Size (octets) 3 3 4 1 1 (16) optional Join-Accept payload JoinNonce NetID DevAddr DLSettings RXDelay CFList Table 54: Join-Accept payload format 1473 1474 JoinNonce is a non-repeating value provided by the Join Server and used by the end-device 1475 to derive the two session keys NwkSKey and AppSKey, which SHALL be calculated as 1476 follows: 10 1477 1478 NwkSKey = aes128_encrypt(AppKey, 0x01 | JoinNonce | NetID | DevNonce | pad 16 ) 1479 AppSKey = aes128_encrypt(AppKey, 0x02 | JoinNonce | NetID | DevNonce | pad 16 ) 1480 The MIC value for a Join-Accept frame SHALL be calculated as follows: 11 1481 1482 CMAC = aes128_cmac(AppKey, MHDR | JoinNonce | NetID | DevAddr | 1483 DLSettings | RXDelay | CFList) 1484 MIC = CMAC[0..3] 1485 The Join-Accept frame itself SHALL be encrypted with the AppKey as follows: 1486 1487 aes128_decrypt(AppKey, JoinNonce | NetID | DevAddr | DLSettings | RXDelay | 1488 CFList | MIC) 1489 1490 Note: [TR001] proposes additional behavior for the JoinNonce value 1491 in the Join Server to prevent synchronization issues related to the 1492 LoRaWAN 1.0.x Join Procedure. Some of the remedies include 1493 additional behavior both at the end-device and the Join Server, which 1494 are expected to be configured synchronously. See [TR001] for details. 1495 1496 Note: An AES decrypt operation in ECB mode encrypts the Join-Accept 1497 frame so that the end-device can use an AES encrypt operation to 1498 decrypt the frame. This way, an end-device has to implement only AES 1499 encrypt but not AES decrypt. 1500 1501 Note: Establishing these two session keys allows for a federated 1502 network infrastructure in which network operators are not able to 1503 eavesdrop on application data. The application provider commits to the 1504 network operator that it will take the charges for any traffic incurred by 1505 10 The pad 16 function appends all-zero octets so that the length of the data is a multiple of 16. 11 [RFC4493].

Articles in this issue

view archives of Document - TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification