Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 10 of 28 The authors reserve the right to change documents without notice. network backend, an HSM is a dedicated piece of hardware specifically designed to manage 286 the cryptographic key lifecycle. 287 3.5 ABP Devices 288 Due to the vastly superior provisioning simplicity, dynamic address and session key 289 generation, and more robust security, OTAA SHOULD be used instead of ABP. 290 ABP devices are provisioned with the information required for network connectivity without 291 going through the OTAA Join Procedure. As such, they are provisioned with a DevAddr and 292 session keys. In addition, the LoRaWAN specifications require the end-device be provisioned 293 with a DevEUI to disambiguate its identity to the network. It is RECOMMENDED that the end- 294 device be provisioned with all OTAA elements (DevEUI, JoinEUI, and root keys). This allows 295 the ABP device to operate as an OTAA device, if required, and provides a robust, internal 296 mechanism for generating session keys from statically provisioned DevNonce and 297 JoinNonce values. 298 3.5.1 Device Address (DevAddr) 299 End-devices are assigned a 32-bit ephemeral device address (DevAddr) by the network 300 operator when they join a network. ABP devices SHALL use a DevAddr assigned to them by 301 the network operator to which they will connect or SHALL use a DevAddr allocated from one 302 of the private NetID ranges. 303 The DevAddr SHALL be allocated according to the rules defined in Section 3.2. 304 3.5.2 Session Keys 305 ABP devices are provisioned with the session keys that would typically be generated through 306 the Join Process. A full set of these keys needs to be provisioned both in the end-device and 307 in the network to allow end-device operation. ABP devices are provisioned with the session 308 keys whereas OTAA devices generate them through the Join Process. Session keys SHOULD 309 be generated and handled using recommendations detailed for root keys in Section 3.4.3. 310 3.6 Physical Provisioning 311 It is RECOMMENDED that the end-device DevEUI be marked on the outside cover and easily 312 legible. The LoRa Alliance has published technical recommendations, [TR005], that define a 313 method of universal machine reading of the provisioning details, which can be used to enable 314 automated on-boarding. It is RECOMMENDED that some type of machine-readable marking 315 of the basic provisioning information (DevEUI and JoinEUI), exist on the device exterior to 316 facilitate rapid and reliable device deployment. Security keys SHALL NOT be printed or 317 displayed in any way on the end-device. 318