LRWAN - Which activation use OTAA or ABP

[JAN R]

Posted on February 07, 2018 at 11:27

Dear,

I am working on end-devices which will not be configurable (no LCD, no buttons..). You can imagine it like simple thermometer which periodically send the new measured data to Gateway.

I read many topics about ABP/ OTAA activation, but it is still not clear to me which activation for this my device is possible.

My existing knowledge:

1) When I use the OTAA - I will have to set in my end-device AppKey, AppEUI and maybe DevEUI which I get from TTN - So it looks like inapplicable for me, is not it? Because In first I will program my device (with HEX file), but the AppKey, App EUI, DevEUI I (user) will know much much later.

2) Whe I use the ABP - I will have to set in my end-device Device Adress which I get also from TTN and Network Session Key with App Session Key I can probably know in advance but also I have to guarentee that these 2 keys will be unique - but how?

I hope my question is clear.

Thank you very much for advice 

Jan.

#otaa-abp #lrwan #lorawan

[After Forever]

Posted on February 07, 2018 at 12:07

Quote from the SPEC.

6.3 Activation by Personalization

Under certain circumstances, end-devices can be activated by personalization. Activation by

personalization directly ties an end-device to a specific network by-passing the join request-join accept procedure.

Activating an end-device by personalization means that the DevAddr and the two session

keys NwkSKey and AppSKey are directly stored into the end-device instead of the DevEUI,AppEUI and the AppKey. The end-device is equipped with the required information forparticipating in a specific LoRa network when started.

Each device should have a unique set of NwkSKey and AppSKey. Compromising the keys of

one device shouldn’t compromise the security of the communications of other devices. Theprocess to build those keys should be such that the keys cannot be derived in any way frompublicly available information (like the node address for example).

If you don't know in advance your AppEUI and you don't have a way of remotely setting it in your devices it seems ABP is the way to go.

Just randomly generate the NwkSKey and AppSKey keys and save them in some kind of database or CSV file. Have a placeholder in your firmware for the keys, for example. ZZZZZZZZZZZNwkSKeyZZZZZZZZZZZZZZ and ZZZZZZZZZZZAppSKeyZZZZZZZZZZZZZZ, then write a PC software which will get the compiled binary and find & replace the placeholders with the real keys and save/flash the unique binary to a specific device, keeping the track of which keys went to which devices.

[ab val]

Posted on February 07, 2018 at 12:07

I would go with OTAA. As it requires less configuration in the device. Can you save data in flash (or eeprom) ? Because with OTAA it is better to save the keys so that you don't have to join every time you want to send something. 

Do you have a uart exposed? In this case, you could program all your end-device with the same .hex but then change the Dev EUI simply by sending uart command. 

If you go with ABP, you can create the keys in TTN first, then hardcode them in your end-device. But that means more config, so potentially more mistakes. 

[JAN R]

Posted on February 07, 2018 at 13:42

Thank you.

Yes, I do not have any way of remotely configure my device after flashing. 

But when I will generate randomly the NwkSkey and AppSKey - so how can I guarantee the unique keys? Or it is not necessary?

[JAN R]

Posted on February 07, 2018 at 13:51

Thanks,

Ye I have eeprom for save keys.

It means that OTAA is possible only when the device will be configurable (example via UART)?

[After Forever]

Posted on February 07, 2018 at 14:07

It is necessary for good security.

When you generate a bunch 16 bytes of random values (keys in this case) it is virtually guaranteed that they will be unique for your application (of course you should use a good random number generator for that).

For example here's a simple code in PHP for generating a random key (both binary and hex variants):

<?php
$key_bin = openssl_random_pseudo_bytes(16);
$key_hex = bin2hex($key_bin);�?�?
�?�?�?�?�?�?�?�?�?

[ab val]

Posted on February 07, 2018 at 15:04

TTN gives you the NwkSkey and AppSKey, why do you want to generate them yourself? 

[JAN R]

Posted on February 08, 2018 at 11:09

OK it looks fine.

About the DevAddr: I have to hardcode this number to the end device too. But I have to generate it in advance too as well. In the LoRaWAN specification is written that DevAddr is assigned fromdatabase by network manager.

 The DevAddr consists of 32 bits identifies the end-device within the current network.

The most significant 7 bits are used as network identifier (NwkID) to separate addresses of territorially overlapping networks of different network operators and to remedy roaming issues. The least significant 25 bits, the network address (NwkAddr) of the end-device, canbe arbitrarily assigned by the network manager 
 

It means that firstly I have to get the DevAddr from for example TTN, and after that I can hardcode to it to the device?

But in this case I do not understand how could I use this

https://webshop.ideetron.nl/LORA_KEYF

with fixed DevAddr with TTN or another operator.

Or if I will make my own private network server - then I could probably Use this fixed DevAddr?

Thanks, Jan.

[ab val]

Posted on February 08, 2018 at 15:52

If you use OTAA, DevAddr will be given by TTN during the joining request/reply process.

[ab val]

Posted on February 08, 2018 at 15:53

No, it means it is easier to setup with UART. You can build for each end-device a hex file with the same AppEUI, AppKey but different DevEUI (that can be a 64bits serial number).