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

[Ivaylo Petrov <[e-mail]>]

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) <[e-mail]>
wrote:

> 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]> on behalf of Dominique Barthel <
> [e-mail]>
> *Date : *Thursday 9 January 2020 16:22
> *À : *Olivier Gimenez <[e-mail]>, lp-wan <[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]> on behalf of Olivier Gimenez <
> [e-mail]>
> *Date : *Wednesday 8 January 2020 19:03
> *À : *lp-wan <[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.
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan
>