Issue link: https://read.uberflip.com/i/1428356
LoRaWAN Fragmented Data Block Transport v1.0.0 Specification ©2018 LoRa Alliance™ Page 13 of 30 The authors reserve the right to change specifications without notice. 4 File integrity check and authentication 343 344 The payloads transported by the fragmentation/defragmentation package are encrypted and 345 authenticated using the McAppSKey and McNwkSKey. However, those keys are identical in 346 all the end-devices of the multicast group. Because one of the group's end-devices might be 347 compromised (the end-device might have been physically destroyed and the keys 348 extracted), those keys cannot be considered safe except if a tamper-proof secure element is 349 used to store them in ALL the end-devices of the group. 350 If that is not the case (no secure element is used), then an additional file integrity and 351 authentication step SHOULD take place. The integrity/authentication check corresponds to 352 making sure that the block reconstructed is exactly what the fragmentation server wanted to 353 send to the end-device and that this block has not been modified in any way through the 354 transport process. This goal may be achieved by different means: 355 1. Public/private cryptography certificate 356 2. Unicast exchange protected by Symmetric key 357 Solution 1 does not require any additional exchange and MAY use a standard HASH + 358 certificate mechanism based on RSA or ECC cryptography. This solution is 359 RECOMMENDED when the fragmentation layer is used to transport a firmware upgrade file. 360 That solution increases the size of the file transported (cryptography/certificate overhead). 361 For ECC that overhead is typically around 100bytes. 362 Solution 2 relies on a unicast exchange between the end-device and the fragmentation 363 server. The messages exchanged contain a HASH of the reconstructed file and MUST be 364 protected by an end-device specific key. In that way even if the multicast keys are 365 considered unsafe, the final authentication is made on an end-device per end-device basis 366 and cannot be compromised. That solution has no file size overhead but requires an 367 additional unicast exchange between each end-device and the AS. 368 The choice between the two solutions is application specific and this is currently considered 369 out-of-scope of this specification. Following versions of this specification will provide a 370 recommended file integrity/authentication verification process. 371