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

[Olivier Gimenez <[e-mail]>]

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 <[e-mail]> On Behalf Of Felipe Canales
Sent: 25 January 2021 23:13
To: [e-mail]
Cc: [e-mail]; Sandra Céspedes <[e-mail]>
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:
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

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.