Issue link: https://read.uberflip.com/i/1428338
CHANGE REQUEST LoRaWAN Version 1.1 CR rev CR Title: FOpts encryption, usage of FCntDwn Compliance to IEEE 802.15.4 Submitter: Name: Joris Delclef Contact Email: joris.delclef@st.com Contact Other: Affiliation: STMicroelectronics Work Item Ref: Technical workgroup/main Date: 1026 January 2018 Category: F (correction) Reason for change #1: The text states in section 4.3.1.6 figure 15 that NFCntDwn must be used in the FOpts encryption process of downlinks. I think that this is not correct. I consider 2 cases; FPort is present and FPort is absent When FPort is present in a downlink frame that carries FOpts it means that FPort is different from 0 and that FRMPayload (containing applicative data) is present (it is forbidden to have MAC commands both in FOpts and in FRMPayload (see section 4.3.1.6 line 695)) - When FPort is different from 0, AFCntDwn must be used (see section 4.3.1.5 line 646). This is in contradiction with 4.3.1.6 figure 15 that states that NFCntDwn must be used. - FHDR can only contain one FCnt, which is the AFCntDwn in this case - As a consequence, FOpts must be encrypted with NwkSEncKey using AFCntDwn in the formatting of A (see figure 15). - Remember that FRMPayload will be encrypted with AppSEncKey and with AFCntDwn in the formatting of Ai (see figure 17) - NwkSEncKey is now linked to 2 different counters; AFCntDwn and NFCntDwn so there is a risk that A-frames collide when counters have the same value. To mitigate the risk we introduce a constant in the A-frame that is different for both counters - The constants are chosen to be coded in the 4-bytes field as 0x00000001 and 0x00000002. We deliberately didn't choose for 0x00000000 because this one is used in the A-frames of FRMPayload encryption so that both domains (FOpts encryption and FRMPayload encryption) are isolated. - . One could think that this could induce security risks because both counters could have the same value and thus reveal the same keystream but this is not