What is the difference between OTAA and ABP Devices

Could someone point me in the right direction on where i can find the difference between OTAA and ABP Devices and where they are used for? I cant seem to find any info on the wiki unless iam looking at the wrong pages.

2 Likes

Over-the-Air Activation (OTAA)

Over-the-Air Activation (OTAA) is the preferred and most secure way to connect with The Things Network. Devices perform a join-procedure with the network, during which a dynamic DevAddr is assigned and security keys are negotiated with the device.

Activation by Personalization (ABP)

In some cases you might need to hardcode the DevAddr as well as the security keys in the device. This means activating a device by personalization (ABP). This strategy might seem simpler, because you skip the join procedure, but it has some downsides related to security.

See the wiki for more information.

6 Likes

I’ve read that wiki doc but couldn’t see much about this - could anyone expand on what these security downsides with ABP are?

1 Like

Key extraction from Node devices is probable given that they will likely be physically outside of controlled environments. It is important therefore that the theft of keys from one Node does not compromise other Nodes in the system. One potential vulnerability is where Nodes use Activation-By-Personalisation (ABP) for joining, but use keys derived by the Node based on features such as the device address. If this could be worked out through reverse engineering of one Node, then all other communications to any Node would then be compromised. (From page 12 of https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-LoRa-security-guide-1.2-2016-03-22.pdf)

So as far as I can tell otaa isn’t necesarily more secure than abp as long as the way of procuring keys for abp is random enough. Otaa is imo more favorable though because the activatation process makes it directly visible whether you actually connected to the network or not.

Mostly the fact that you hard-code session keys into your device (then they’re not session keys anymore). I’m sure a quick forum search for “Security” will give you some reading material :wink:

For me the main reason to want OTAA is the option to switch networks.

Network-specific settings (such as TTN using SF9 in RX2) are nicely communicated in the OTAA Join Accept message, but need to be hardcoded in ABP devices.

1 Like

Can you tell me please if in the OTTA , every time the end-device reset or overflow , Network Session keys change or no ?

Yes, every OTAA operation resets the sessions keys. Both Network Session Key and Application Session Key are generated newly for at OTAA join.

Thanks but I’am asking if every reset or overflow the OTAA (join request - accept ) are repeated again ?

yes, if you power cycle (on/off) an OTAA programmed node it will try to join …, again, like Kersing said, the counters are also reset to zero.

see

https://www.thethingsnetwork.org/docs/lorawan/security.html

That depends on the software on the node. Some nodes save the information and restore and reuse it after a reset (LoPy has this feature) most will rejoin after a reset. However too many rejoins will result in issues because of nonce reuse.
I suggest you check the lorawan spec for expected behavior on overflow.

thnx , i have an other question , i want to know if every time the frame counters reches its maximum value the end device change its session keys (does mean repeat OTAA procedure) ?

I suggest too you check the lorawan spec for expected behavior on overflow and start using search and read some more background info.

1 Like

2 posts were split to a new topic: Node on two lorawan networks