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

From: <[email-masked]>
Date: Thu, 9 Jan 2020 15:22:24 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Olivier Gimenez <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 8 January 2020 19:03
À : lp-wan <[email-masked]<mailto:[email-masked]>>
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.

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 9 Jan 2020 15:26:04 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Date : Thursday 9 January 2020 16:22
À : Olivier Gimenez <[email-masked]<mailto:[email-masked]>>, lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] IID computation for SCHC over LoRaWAN

Hello all,

Dominique

Dear,

5.3.  IID computation

   1.  key = LoRaWAN AppSKey

   Example with:

Best regards
Olivier

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Jan 2020 15:29:08 +0000

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

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

Dominique

Hello all,

Dominique

Dear,

5.3.  IID computation

   1.  key = LoRaWAN AppSKey

   Example with:

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>.

Thank you.

Thank you.

---

From: Ivaylo Petrov <[email-masked]>
Date: Fri, 10 Jan 2020 09:14:59 +0100

Hello,

For me rekeying sounds as the simplest solution, even though I am wondering
how it would work. The straightforward way that I can think of might not
work - the SCHC gateway detects the IID conflict and then it needs to tell
the NGW - hey, could you ask this device to rekey. The problem for me is
that the rekeying operation is not supported by lorawan versions below 1.1
if I am not mistaken and we are considering lorawan 1.0.3. Furthermore I am
not sure there is an API that the SCHC gateway could use to request the
rekeying from the NGW.

Best regards,
Ivaylo

On Thu, Jan 9, 2020 at 4:30 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> *From:* lp-wan <[email-masked]> *On Behalf Of *
> [email-masked]
> *Sent:* jeudi 9 janvier 2020 16:26
> *To:* Olivier Gimenez <[email-masked]>; lp-wan <[email-masked]>
> *Subject:* Re: [lp-wan] IID computation for SCHC over LoRaWAN
>
>
>
> *De : *lp-wan <[email-masked]> on behalf of Dominique Barthel <
> [email-masked]>
> *Date : *Thursday 9 January 2020 16:22
> *À : *Olivier Gimenez <[email-masked]>, lp-wan <[email-masked]>
> *Objet : *Re: [lp-wan] IID computation for SCHC over LoRaWAN
>
>
>
> Hello all,
>
>
>
> 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 <[email-masked]> on behalf of Olivier Gimenez <
> [email-masked]>
> *Date : *Wednesday 8 January 2020 19:03
> *À : *lp-wan <[email-masked]>
> *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
>
>
>
> 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.
>
>
>
> 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.
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Olivier Gimenez <[email-masked]>
Date: Tue, 21 Jan 2020 08:24:39 +0000

From: Pascal Thubert (pthubert) <[email-masked]>

I hope it’s not too much effort for something that never happens!

Dear,

I think that this comment says everything. Collision risk is 1/(2^64) = 5.42e-20
In comparison with Aerospace industry: in software (DO178<https://en.wikipedia.org/wiki/DO-178B>) and hardware (DO254<https://en.wikipedia.org/wiki/DO-254>), a DAL A event (Catastrophic - Failure may cause a crash) should be lower than 1e-9 per hour.

Best regards
Olivier

---

From: Ivaylo Petrov <[email-masked]>
Date: Tue, 21 Jan 2020 13:01:33 +0100

Hello Olivier,

Could you explain what are your assumptions that lead to collision risk of
1/(2^64)? I don't think that this applies for any network prefix size and
any number of devices.

Cheers,
Ivo

On Tue, Jan 21, 2020 at 9:24 AM Olivier Gimenez <[email-masked]>
wrote:

>
>
>
>
> *From:* Pascal Thubert (pthubert) <[email-masked]>
>
> In comparison with Aerospace industry: in software (DO178
> <https://en.wikipedia.org/wiki/DO-178B>) and hardware (DO254
> <https://en.wikipedia.org/wiki/DO-254>), a DAL A event (Catastrophic -
> Failure may cause a crash) should be lower than 1e-9 per hour.
>
>
>
> Best regards
>
> Olivier
>

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 27 Jan 2020 09:38:22 +0000

Hi,

According to Wikipedia<https://en.wikipedia.org/wiki/Birthday_problem#Probability_table> for 64 bits IID:

  *   when 190 000 devices are in the network, collision probability is one out of a billion
  *   when 6 100 000 devices are in the network, collision probability is one out of a million

I am still convinced that we should not add any specification/code complexity with such low numbers, anyway we wonder if another approach can be used:

Please see attached picture, the gateway can be seen as a NAT router: the device is able to compute its IP address based on devEUI or whatever we find relevant, which will be unique inside an IPv6 network (but will not change over time or be obfuscated), then IP used outside LoRaWAN network is computed in the SCHC gateway, this way an address collision is detected in the gateway and a new IP can be generated.
Another pro is there is no more need to provision the network prefix into the device

Any thoughts ?

Thank you
Olivier