I’ve not read the analysis (but did see some summaries in media coverage, which did not alarm me too much), but I did run into https://github.com/IOActive/laf.
Its README states for LAF-002:
Two different devices might have been assigned the same DevAddr. This isn’t a security threat, but it shouldn’t happen since the lorawan server wouldn’t be able to distinguish in which device a message is generated.
This is not true. The number of truly available DevAddr’s is much too low to allow them to be unique; TTN only uses as few as 12 bits within a region and class to generate a DevAddr, yielding only 4,096 unique values within such region and class.
Click for more details
First, it contains a prefix:
6.1.1 End-device address (DevAddr)
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.
Next, a network may use specific logic in the remaining 25 bits, like for The Things Network (TTN):
Within TTN, we assign device address prefixes to “regions” (for example, device addresses in the
eu region start with
0x2601). Within a region, the NetworkServer is responsible for assigning device addresses. We are using prefixes here too for different device classes (for example, ABP devices in the eu region start with
0x26011) or to shard devices over different servers
When a device joins the network, it receives a dynamic (non-unique) 32-bit address (
DevAddr). It’s good to keep in mind that device addresses are not unique. We can (and probably will) give hundreds of devices the same address. Finding the actual device that belongs to that address is done by matching the cryptographic signature (MIC) of the message to a device in the database.
So, TTN only uses as few as 12 bits within a region and class to generate a DevAddr, yielding only 4,096 unique values within such region and class.
(Also, of course, devices might be assigned a DevAddr that was used by other devices in the past.)
Also, LAF-004 states:
A duplicated uplink packet was detected, which may imply that the lorawan server is under a replay attack. This is, an attacker that may have captured an uplink packet (sent from the device) and is sending it again to the lorawan server.
It would be nice to explain that this might very well be a retry for a confirmed uplink, which did not get its confirmation downlink.