Subject: [lp-wan] [lpwan] Interface Identifier computation on draft-ietf-lpwan-schc-over-lorawan-14

From: Felipe Canales <[email-masked]>
Date: Mon, 25 Jan 2021 19:13:04 -0300

Dear Author,

In section 5.3 of draft-ietf-lpwan-schc-over-lorawan-14, the example given for the computation of an Interface IDentifier (IID) has 0x1122334455667788 as the DevEUI, and therefore as the message to be encoded using AES128_CMAC. The presence of the ‘0x’ prefix suggests that the value should be taken as a series of 8 bytes, each one represented by 2 hexadecimal digits. For example, the first byte would be 0x11. However, when applying the AES128_CMAC algorithm, the CMAC computed is not the one presented in the document but the following:

0x4e822d9775b2649928f82066af804fec

The CMAC presented can be achieved if the DevEUI is evaluated as a string, or in other words, as 16 bytes each one having the value of the ASCII representation of a digit. In this case, the first byte is 0x31 (the character ‘1’).

Which of these two scenarios is the intended one?

I’ve confirmed the CMACs I obtained using my code, with the following implementations of the algorithm specified in RFC 4493:

https://artjomb.github.io/cryptojs-extension/

https://github.com/SecureAuthCorp/impacket/blob/master/impacket/crypto.py

Regards.

Felipe Canales

---

From: Olivier Gimenez <[email-masked]>
Date: Tue, 26 Jan 2021 10:37:15 +0000

Hello Felipe,

Thank you for your comment. You are right I made a mistake, I wanted to input the data as a series of 8 bytes but did it as their ASCII representation.
I do not know how it happened, as it has also been verified by someone else with another tool (Python vs Matlab)
With the fixed script using the DevEUI as integer, I get the same result than you:

devEUI 0x1122334455667788 - Type: <class 'bytes'>
appSKey 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB - Type: <class 'str'>
key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB - Type: <class 'bytes'>
CMAC: 0x4E822D9775B2649928F82066AF804FEC
IID: 0x4E822D9775B26499

If someone else want to check, I used:
#!/usr/bin/env python
# -*- coding: utf-8 -*-

# Dependencies:
# pip install git+https://github.com/dlitz/pycrypto

import binascii
from Crypto.Hash import CMAC
from Crypto.Cipher import AES

# Input
devEUI = 0x1122334455667788
appSKey = "00AABBCCDDEEFF00AABBCCDDEEFFAABB"

# Conversion to bytes
devEUI = (devEUI).to_bytes(8, "big")
key = binascii.unhexlify(appSKey)

# CMAC computation
cmac = CMAC.new(key, ciphermod=AES)
cmac.update(devEUI)

print(f"devEUI 0x{devEUI.hex().upper()} - Type: {type(devEUI)}")
print(f"appSKey 0x{appSKey} - Type: {type(appSKey)}")
print(f"key: 0x{key.hex().upper()} - Type: {type(key)}")
print(f"CMAC: 0x{cmac.hexdigest().upper()}")
print(f"IID: 0x{cmac.hexdigest()[0:16].upper()}")

Is this OK for you?

Best regards
OIivier

From: lp-wan <[email-masked]> On Behalf Of Felipe Canales
Sent: 25 January 2021 23:13
To: [email-masked]
Cc: [email-masked]; Sandra Céspedes <[email-masked]>
Subject: [lp-wan] [lpwan] Interface Identifier computation on draft-ietf-lpwan-schc-over-lorawan-14

Dear Author,

I’ve confirmed the CMACs I obtained using my code, with the following implementations of the algorithm specified in RFC 4493:
-          https://artjomb.github.io/cryptojs-extension/
-          https://github.com/SecureAuthCorp/impacket/blob/master/impacket/crypto.py

Regards.

Felipe Canales

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.

---

From: Julien CATALANO <[email-masked]>
Date: Tue, 26 Jan 2021 12:59:40 +0100

Dear Olivier, all,

I created a minimal Python script to compute SCHC-over-LoRaWAN IID:
https://github.com/jca-klk/schc-lorawan-iid

It might be helpful in the future. I confirm that IID you computed below
is good (and that the one in draft 14 is not).

python3 schc-lorawan-iid.py 1122334455667788 00AABBCCDDEEFF00AABBCCDDEEFFAABB
4E822D9775B26499

Note that I have used another python's cryptography module,  and that
all inputs are converted to bytes, as they should.

Julien

Le 26/01/2021 à 11:37, Olivier Gimenez a écrit :
>
> Hello Felipe,
>
>  
>
> Thank you for your comment. You are right I made a mistake, I wanted
> to input the data as a series of 8 bytes but did it as their ASCII
> representation.
>
> I do not know how it happened, as it has also been verified by someone
> else with another tool (Python vs Matlab)
>
> *From:*lp-wan <[email-masked]> *On Behalf Of *Felipe Canales
> *Sent:* 25 January 2021 23:13
> *To:* [email-masked]
> *Cc:* [email-masked]; Sandra Céspedes <[email-masked]>
> *Subject:* [lp-wan] [lpwan] Interface Identifier computation on
> draft-ietf-lpwan-schc-over-lorawan-14
>
>  
>
> Dear Author,
>
>  
>
> In section 5.3 of draft-ietf-lpwan-schc-over-lorawan-14, the example
> given for the computation of an Interface IDentifier (IID) has
> 0x1122334455667788 as the DevEUI, and therefore as the message to be
> encoded using AES128_CMAC. The presence of the ‘0x’ prefix suggests
> that the value should be taken as a series of 8 bytes, each one
> represented by 2 hexadecimal digits. For example, the first byte would
> be 0x11. However, when applying the AES128_CMAC algorithm, the CMAC
> computed is not the one presented in the document but the following:
>
> The CMAC presented can be achieved if the DevEUI is evaluated as a
> string, or in other words, as 16 bytes each one having the value of
> the ASCII representation of a digit. In this case, the first byte is
> 0x31 (the character ‘1’).
>
>  
>
> I’ve confirmed the CMACs I obtained using my code, with the following
> implementations of the algorithm specified in RFC 4493:
>
> <https://artjomb.github.io/cryptojs-extension/>
>
> -         
> <https://github.com/SecureAuthCorp/impacket/blob/master/impacket/crypto.py>
>
>  
>
> Regards.
>
>  
>
> Felipe Canales
>
>
> 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: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 26 Jan 2021 12:08:18 +0000

This I-D has been approved by the IESG and sits in the RFC Editor queue, such a minor but important change can be incorporated at the AUTH48 stage in a couple of weeks.

Thank you Felipe for spotting the error

-éric

From: lp-wan <[email-masked]> on behalf of Julien CATALANO <[email-masked]>
Date: Tuesday, 26 January 2021 at 12:59
To: Olivier Gimenez <[email-masked]>, Felipe Canales <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Sandra Céspedes <[email-masked]>
Subject: Re: [lp-wan] [lpwan] Interface Identifier computation on draft-ietf-lpwan-schc-over-lorawan-14

Dear Olivier, all,

I created a minimal Python script to compute SCHC-over-LoRaWAN IID: https://github.com/jca-klk/schc-lorawan-iid

It might be helpful in the future. I confirm that IID you computed below is good (and that the one in draft 14 is not).

4E822D9775B26499
Note that I have used another python's cryptography module,  and that all inputs are converted to bytes, as they should.

Julien

# Dependencies:

import binascii

# Input

# Conversion to bytes

# CMAC computation

Is this OK for you?

Best regards
OIivier

From: lp-wan <[email-masked]><mailto:[email-masked]> On Behalf Of Felipe Canales
Sent: 25 January 2021 23:13
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Sandra Céspedes <[email-masked]><mailto:[email-masked]>
Subject: [lp-wan] [lpwan] Interface Identifier computation on draft-ietf-lpwan-schc-over-lorawan-14

Dear Author,

I’ve confirmed the CMACs I obtained using my code, with the following implementations of the algorithm specified in RFC 4493:
1.       https://artjomb.github.io/cryptojs-extension/
2.       https://github.com/SecureAuthCorp/impacket/blob/master/impacket/crypto.py

Regards.

Felipe Canales

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

lp-wan mailing list

[email-masked]<mailto:[email-masked]>