Document

FOpts Encryption, Usage of FCntDwn Errata on the LoRaWAN L2 1.1 Specification

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

Contents of this Issue

Navigation

Page 1 of 2

the case because the rightmost byte in A is always 0x00 (see figure 15) while in Ai the rightmost byte is never 0x00 (see figure 17); so the key streams of FOpts encryption and FRMPayload encryption are isolated. When FPort is absent in a downlink frame that carries FOpts; NFCntDwn must be used (see section 4.3.1.5 line 645). Reason for change #2: FOpts encryption uses the IEEE 802.15.4 Annexe B scheme; it defines the encryption transformation in B.4.1.3 - A i = Flags (1-byte) || Nonce N (15-bytes) || Counter i, for i = 0,1,2,… (2-bytes) - C i = E(Key, A i ) xor M i for i = 1,2,…,t > please note that i starts at 1 (not 0); so A 1 must be used for FOpts encryption (max. 15 bytes, so only 1 block) - As a result, the last byte of the A-field must be 0x01 (not 0x00) On notation; we should use "A 1 " (instead of "A") Please note that A 0 (i = 0) is used in IEEE in the encryption of the authentication tag U. But LoRaWAN doesn't use U, it uses CMAC instead. This is also the reason why the last byte in the A i fields of the FRMPayload encryption starts with 1. Summary of change: Introduce 2 constants to assure that A-frames are always distinct (even when NFCntDwn and AFCntDwn have the same value) Introduce AFCntDwn as the counter to use when FPort > 0 Set the last byte of the A-frame to 0x01 (instead of 0x00) to comply to IEEE802.15.4 Use notation "A 1 "rather than "A" Clauses affected: 4.3.1.6 Other deliverables affected: Other comment: Proposed changes (normative/informative)

Articles in this issue

view archives of Document - FOpts Encryption, Usage of FCntDwn Errata on the LoRaWAN L2 1.1 Specification