LoRaWAN Security Research Paper is now published!

Hi all!

We have published the paper “LoRaWAN Networks Susceptible to Hacking: Common Cyber Security Problems, How to Detect and Prevent Them”. You can take a look to it and find us in the TTN conference if you have any question.

We will also be talking about this research on Thursday at 2.00pm in The Things Stage!

Looking forward to meet you there.

1 Like

The link you have posted is a shorturl. Being a security concious person I tend not to click on shorturls because they could lead to somewhere bad. Perhaps you could paste a summary in plain text for us in your post. :slight_smile:

2 Likes

Especially given the title & link name used as ‘potential bait’ :slight_smile: :scream:

Hi @matiassequeira, I take cyber-security very seriously so I read your paper looking to learn if I’m missing anything.

I’m not impressed. This looks to me like normal Fear, Uncertainty & Doubt (FUD) marketing, see https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt

The content is shallow and much of it is just generic cyber-security 101 and is nothing to do with LoRaWAN. The risk of key databases being exfiltrated by targeted spear-fishing type attacks is not new or specific to LoRaWAN. LoRaWAN does not have a monopoly on human stupidity and negligence.

Please read the LoRa Alliance Backend Interfaces Specification, https://lora-alliance.org/resource-hub/lorawanr-back-end-interfaces-v10.

The integration between the LoRaWAN Application Server and the end-user system is usually by HTTPS POST or MQTT publish/subscribe but this gets no mention at all in the paper. In my experience this is the most vulnerable and error-prone part of the end-to-end IoT system.

I’m guessing that the IOActive LoRaWAN Auditing Framework is a generic cyber-security checklist with a veneer of LoRaWAN stuff.

3 Likes

I too also check on links before I click on them …

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.)

(GitHub issue.)

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.

1 Like

I agree with the FUD/marketing stunt. With that said, a few of the tools in the github repo actually look useful. I hope I’ll be able to prioritize trying them out.

1 Like

Unfortunately media like to pick up on and amplify FUD + add sprinkling of sensationalising… already being picked up :frowning:

For the HTTP Integration one needs to add one’s own security, which people might forget or do wrong indeed. But to subscribe to the MQTT data, one needs to use an access key as provided by TTN (hopefully a dedicated key for each usage). What’s the risk there? Maybe that the same access key might be used for a very long time?

Hi @arjanvanb, you are correct that using MQTT via a username and password is secure when used over TLS.

My experience is that the keys are often copied out of TTN then sent to the MQTT subscriber in an unencrypted email. This means they get stored in searchable email systems. This is a very common reason for cyber-security audit failures after the simple question “How do you manage and transmit keys?” The problem is not the technology but the lazy/ignorant human handling of security information by sysadmins. There is nothing special about LoRaWAN here, just general cyber-security stupidity.

When hackers gain access to systems they search email archives for email being used to transfer sensitive information.

2 Likes

All system need a regular patch.

It’s an interesting report, I saw their talk at TTC last week too.

I’ve written some of my own thoughts here: