[lp-wan] IID computation for SCHC over LoRaWAN

[Olivier Gimenez <[e-mail]>]

Dear,

As discussed at the end of today's interim meeting the preferred solution for the IID computation algorithm is the one currently proposed in the draft:

5.3.  IID computation

   In order to mitigate risks described in [RFC8064] and [RFC8065] IID
   MUST be created regarding the following algorithm:

   1.  key = LoRaWAN AppSKey
   2.  cmac = aes128_cmac(key, devEui)
   3.  IID = cmac[0..7]

   aes128_cmac algorithm is described in [RFC4493].  It has been chosen
   as it is already used by devices for LoRaWAN protocol.

   As AppSKey is renewed each time a device joins or rejoins a network,
   the IID will change over time; this mitigates privacy, location
   tracking and correlation over time risks.  Rejoin periodicity is
   defined at the application level.

   Address scan risk is mitigated thanks to AES-128, which provides
   enough entropy bits of the IID.

   Using this algorithm will also ensure that there is no correlation
   between the hardware identifier (IEEE-64 devEUI) and the IID, so an
   attacker cannot use manufacturer OUI to target devices.

   Example with:
   o  devEui: 0x1122334455667788
   o  appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB

   1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
   2. cmac: 0x4E822D9775B2649928F82066AF804FEC
   3. IID: 0x28F82066AF804FEC

I asked security working group of the LoRa Alliance for their agreement to use the AppSKey for this purpose. If not the other option is to use the algorithm proposed in RFC7217:

RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key), where Net_Iface can be DevEUI and Network_ID the LoRaWAN netid.

Unless one of you have another algorithm to propose, which respect recommendations of RFC8065

Best regards
Olivier




To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.