MIC Calculate?

1

Hi,
Iam working on mic calculate for create tx frame. Is there anybody can explain mic?
I created mic values from lorawan protocol datasheet but i miss something.
I have to see how to manuelly calculate

Thanks & Regards

2

Section 4.4 of the LoRaWAN specification is quite clear about MIC calculation. Here’s a simplified version of some code I wrote a couple of months ago:

// msg = MHDR | FHDR | FPORT | FRMPayload
var msgbuf bytes.Buffer
msgbuf.WriteByte(mhdr)
msgbuf.Write(fhdr)
msgbuf.WriteByte(fport)
msgbuf.Write(payload)
msg := msgbuf.Bytes()

// B0 =  0x49 | 4x 0x00 | Dir (uplink=0x00/downlink=0x01) | DevAddr | FCnt (4 bytes!) | 0x00 | len(msg)
var blocksbuf bytes.Buffer
blocksbuf.Write([]byte{0x49, 0x0, 0x0, 0x0, 0x0})
switch mType {
case UnconfirmedDataUp, ConfirmedDataUp:
	blocksbuf.WriteByte(0x00)
case UnconfirmedDataDown, ConfirmedDataDown:
	blocksbuf.WriteByte(0x01)
default:
    // nonononono
}
binary.Write(blocksbuf, binary.LittleEndian, dataPayload.FHDR.DevAddr)
binary.Write(blocksbuf, binary.LittleEndian, uint32(dataPayload.FHDR.FCnt))
blocksbuf.WriteByte(0x00)
blocksbuf.WriteByte(byte(len(msg)))

// Append msg to B0
blocksbuf.Write(msg)

blocks := blocksbuf.Bytes()

hash, _ := cmac.New(nwkSKey)
hash.Write(blocks)

return hash.Sum([]byte{})[0:4]

You could also have a look at how it’s done in the github.com/brocaar/lorawan package.

3

Thanks a lot. I solved

4

I understand that the MIC consists of the first 4 bytes of a AES-128 cmac. What mode of operation does the cipher use? Options seem to be: CBC, CCM, CTR, ECB, GCM, OFB, XTS

5

Have you checked RFC4493 which the standard refers to? It provides the algorithm used.

6

I must confess I had not. Having read through it once only, I will admit, converting said specification into a working program in c is a tad daunting. I am hoping to leverage the existing cmac library from mbedtls, and have made some limited progress in this regard. The resulting cmac output I am able to generate however does not contain the 4 byte MIC sequence given by this online calculator. My suspicion is that I am using the wrong mode of operation, as there are a few available in the mbedtls definition. Unfortunately I am none the wiser after reading the RFC4493 standard.

7

Glancing at the RFC I don’t see a direct match with the algorithms you mentioned. It seems they created yet another algorithm, very like an existing one but not necessarily compatible.

Are you working on the node or back-end side? For nodes there are plenty of existing code bases in C that contain the logic. For back-end most of the code is in other languages (go seems to be a favorite).

8

Given a pull request on a JavaScript library I use in an example explaining deciphering Join Accepts, I’d say it’s CBC:

Changed from cipher algorithm alias to real names (aes128, aes192, and aes256 to aes-128-cbc, aes-192-cbc, and aes-256-cbc) to improve compatibility with Electron, see electron/electron#16195 for more details

1 Like
9

The RFC explains that it’s based on the XCBC improvements to CBC, but the implementation described there seems to use ordinary CBC as the core operation and do additional manipulations around it.

There’s very little reason to try to implement this from scratch apart from pure curiousity. What language and licensing context are you working in?

10

Thanks for the tips. I will definitely try again using CBC. Maybe I had the MSB / LSB wrong when I tried it the first time. Will take a closer look at what the mbedtls/cmac.c library requires.
Its the node I am developing, in C, on an ESP32 using the arduino framework. It’s more or less an amateur licensing context. I’m not averse to C++ but I prefer to steer clear of dynamic memory operations and String functions as much as possible to avoid memory fragmentation.

11

With the law, it’s black and white, not really more or less - and it’s not clear if you are doing LoRaWAN from scratch or something else. If the former, please can you setup a private server to test it on.

Alternatively the licensing context may be for the software.

If you don’t use them, they don’t bite. But some of the object facilities, function overloading and parameter defaults can be very handy

Whilst I used some String like functions for an SDI-12 decoder, I’ve rarely had any need for such a thing for writing firmware.

12

Thanks for your input @descartes . How would you categorize a person running their own business in electrical automation (mainly using PLCs etc) but who has an interest in electronics design and LoraWAN, to see if it is something that could be used commercially, but with no concrete plans to do so at this time?

13

If you are potentially looking at a commercial product why would you start from scratch in stead of using a BSD licensed reference implementation that is actively being tested for LoRaWAN compliance? (LoRaMac-node)

1 Like
14

That is a good question @kersing. I am often torn between using something off the shelf, and starting from scratch to develop a better understanding of the underlying mechanisms. I tried a few off the shelf libraries, but was not able to make it work properly or understand what was going on, so I embarked on a learning excercise. It’s possibly a fool’s errand.

15

That’s a whole heap of information extra to process, so I’ll get back to you.

But as there’s so many interpretations available, I went with the likelihood that you were referring to amateur radio licensing with a backup on the software front.

For commercial work there isn’t a license per se, just the legal issues of compliance for various uses from retail / home use through to industrial.

That’s pretty normal around these parts - the LoRaWAN spec is like an onion and almost every level will make you cry. It may be worth getting one setup working so you’ve got something to observe as you write your own. Anything in the LMIC-node device list is a good start and plenty of support on here for it.

16

Trying to implement LoRaWAN from scratch without previously having some experience using already sound end device (node) and server implementations is a recipe for disaster.

Spend some time watching proper code work, dig through the details of the packets being exchanged.

Once you see the scope of actually achieving LoRaWAN compliance (and if you are going to use TTN, you really must implement what the spec requires, since cutting corners leads to squandering airtime when you fail to respond as dictated) you’ll change your mind.

2 Likes