Issue link: https://read.uberflip.com/i/1464683
LoRaWAN ® Fragmented Data Block Transport Specification TS004-2.0.0 ©2022 LoRa Alliance ® Page 18 of 32 The authors reserve the right to change specifications without notice. 4 Data Block Integrity Check and Authentication 505 506 When using multicast, the payloads transported by this package are encrypted and 507 authenticated using the McAppSKey and McNwkSKey (described in the LoRaWAN 508 Remote Multicast Setup Specification [TS005]). However, those keys are identical in all the 509 end-devices of the multicast group. Because one of the group's end-devices might be 510 compromised (the end-device might have been physically compromised and the keys 511 extracted), those keys cannot be considered safe unless a tamper-proof secure element is 512 used to store them in every end-device member of the group. 513 514 This is the reason why the current specification provides a baseline integrity and authenticity 515 check through the MIC field of the FragSessionSetupReq command. The MIC computed is 516 different for every single end-device because it uses an end-device-specific key 517 (DataBlockIntKey). The MIC does not rely on the multicast keys and is therefore not 518 compromised even if the McAppSKey or McNwkSKey are compromised. 519 520 When the data block transported corresponds to a firmware upgrade file or firmware patch, it 521 is RECOMMENDED to use an additional authenticity and integrity check using a 522 public/private cryptography certificate. 523 524 This certificate MAY use a standard HASH + SIGNING mechanism based on Rivest– 525 Shamir–Adleman cryptosystem (RSA) or Elliptic-curve cryptography (ECC). The additional 526 authenticity and integrity check increases the size of the file transported 527 (cryptography/certificate overhead). For ECC, that overhead is typically around 100 octets. 528 However, that overhead is tolerable in the case of a firmware upgrade file, which usually 529 exceeds 1 kB. 530