Document

LoRaWAN® Specification v1.0.3

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

Contents of this Issue

Navigation

Page 35 of 71

LoRaWAN 1.0.3 Specification ©2018 LoRa™ Alliance Page 36 of 72 The authors reserve the right to change specifications without notice. The AppNonce is a random value or some form of unique ID provided by the network server 1012 and used by the end-device to derive the two session keys NwkSKey and AppSKey as 1013 follows: 1 1014 NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad 16 ) 1015 AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad 16 ) 1016 The MIC value for a join-accept message is calculated as follows: 2 1017 cmac = aes128_cmac(AppKey, 1018 MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList) 1019 MIC = cmac[0..3] 1020 The join-accept message itself is encrypted with the AppKey as follows: 1021 aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList | 1022 MIC) 1023 Note: The network server uses an AES decrypt operation in ECB mode 1024 to encrypt the join-accept message so that the end-device can use an 1025 AES encrypt operation to decrypt the message. This way an end-device 1026 only has to implement AES encrypt but not AES decrypt. 1027 1028 Note: Establishing these two session keys allows for a federated 1029 network server infrastructure in which network operators are not able to 1030 eavesdrop on application data. In such a setting, the application 1031 provider must support the network operator in the process of an end- 1032 device actually joining the network and establishing the NwkSKey for 1033 the end-device. At the same time the application provider commits to 1034 the network operator that it will take the charges for any traffic incurred 1035 by the end-device and retains full control over the AppSKey used for 1036 protecting its application data. 1037 The format of the NetID is as follows: The seven LSB of the NetID are called NwkID and 1038 match the seven MSB of the short address of an end-device as described before. Neighboring 1039 or overlapping networks must have different NwkIDs. The remaining 17 MSB can be freely 1040 chosen by the network operator. 1041 The DLsettings field contains the downlink configuration: 1042 1043 Bits 7 6:4 3:0 DLsettings RFU RX1DRoffset RX2 Data rate 1044 The RX1DRoffset field sets the offset between the uplink data rate and the downlink data 1045 rate used to communicate with the end-device on the first reception slot (RX1). By default 1046 this offset is 0.. The offset is used to take into account maximum power density constraints 1047 for base stations in some regions and to balance the uplink and downlink radio link margins. 1048 The actual relationship between the uplink and downlink data rate is region specific and 1049 detailed in the "Physical Layer" section 1050 The delay RxDelay follows the same convention as the Delay field in the RXTimingSetupReq 1051 command. 1052 1 The pad 16 function appends zero octets so that the length of the data is a multiple of 16. 2 [RFC4493]

Articles in this issue

view archives of Document - LoRaWAN® Specification v1.0.3