Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 9 of 28 The authors reserve the right to change documents without notice. 3.4.3 Root Key(s) 246 3.4.3.1 Root Key Generation 247 Root keys SHALL be generated in such a fashion that there is no derivable pattern between 248 the root keys of multiple devices, for example, not be reversibly based on the DevEUI or any 249 other easily guessed scheme, or be all 0s or all 1s or any other simple pattern. 250 Root keys of a set of devices SHALL exhibit a high degree of entropy (randomness) to ensure 251 that the compromise of a single device does not lead to the compromise of additional devices. 252 It is critical that keys conform to this model, as it makes the economics of cracking individual 253 devices infeasible for large-scale attacks. 254 Two techniques are often used to generate a set of root keys. The first technique is to create 255 a large set of unique root keys, each with its own input entropy. 256 The second technique is to create a single unique master root key for a set of devices and 257 then use a one-way, keyed, cryptographic hash function to derive the unique root keys for 258 each individual device. It is preferable that a Hardware Security Module (HSM) configured with 259 the master root key is used to securely generate derived root keys on demand. The master 260 root key SHALL be kept secure, as compromise of this key may compromise the entire set of 261 devices provisioned with root keys derived from it. The master root key SHALL NOT be kept 262 on an end-device, as this would raise the value of the attack to the point where it becomes 263 economically feasible. These techniques are fully described in the NIST SP 800-90 series of 264 documents (see [SP 800-90C]). 265 3.4.3.2 Root Key Delivery and Storage 266 The various parties (manufacturer, distributor, integrator, operator, etc.), SHALL strictly limit 267 access to root key material. 268 An attacker is likely to try to compromise the system at its weakest point. The LoRaWAN 269 protocol describes mechanisms that use security keys to secure traffic between the various 270 elements of the system (see [TS002]). This design has been subjected to extensive security 271 reviews and is robust. It is assumed that the keys are securely provisioned on the device, the 272 Join Server, and Application Server (and perhaps the Network Server). An attacker is likely to 273 try to compromise the system at its weakest point, which is often when the keys are 274 provisioned to the manufacturer, delivered to the operator, or stored in the operator's systems. 275 The keys SHALL be stored in a secure environment with a strictly limited access policy. The 276 delivery of keys to an authorized party (for instance, when providing new devices to a 277 customer), SHALL use secure methods and be sent to a very small distribution. It is particularly 278 important the customer/operator store keys in a secure manner and limit their distribution. 279 Many security breaches can be traced to allowing operations staff access to key material, so 280 access to keys SHALL be severely restricted. 281 For organizations and/or Internet of Things (IoT) applications that are particularly sensitive, it 282 should be mentioned there are a variety of solutions on the market that offer additional layers 283 of security for LoRaWAN systems. For example, if an end-device is subject to physical threats, 284 its keys can be protected in tamper-resistant storage via a so-called Secure Element. In the 285