Re: [lp-wan] IID computation for SCHC over LoRaWAN

["Pascal Thubert (pthubert)" <[e-mail]>]

We need to rekey the second guy. I hope it’s not too much effort for something that never happens!

From: lp-wan <[e-mail]> On Behalf Of [e-mail]
Sent: jeudi 9 janvier 2020 16:26
To: Olivier Gimenez <[e-mail]>; lp-wan <[e-mail]>
Subject: Re: [lp-wan] IID computation for SCHC over LoRaWAN

Oops, I forgot one point.
How high is the risk of IID collision? Different AppSKey, different devEUI, yet same IID.
What do we do if this unlikely event happens?

Dominique

De : lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Date : Thursday 9 January 2020 16:22
À : Olivier Gimenez <[e-mail]<mailto:[e-mail]>>, lp-wan <[e-mail]<mailto:[e-mail]>>
Objet : Re: [lp-wan] IID computation for SCHC over LoRaWAN

Hello all,

I like the approach Olivier proposes.
It uses a shared secret that is readily available at both ends of the LoRaWAN link and seems to meet all required properties of 8064 and 8065.
Snooping on the LoRa Alliance mailing list, it looks there's no opposition and one approval, so far. Let's give them a fews days and make a decision.
Best regards

Dominique

De : lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Olivier Gimenez <[e-mail]<mailto:[e-mail]>>
Date : Wednesday 8 January 2020 19:03
À : lp-wan <[e-mail]<mailto:[e-mail]>>
Objet : [lp-wan] IID computation for SCHC over LoRaWAN

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<http://www.semtech.com/legal>.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.