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.
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. 
Especially given the title & link name used as ‘potential bait’ 
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.
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 GitHub - IOActive/laf: This project intends to provide a series of tools to craft, parse, send, analyze and crack a set of LoRaWAN packets in order to audit or pentest the security of a LoraWAN infrastructure..
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.
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
euregion start with0x2601). 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 with0x26011) 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.
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.
Unfortunately media like to pick up on and amplify FUD + add sprinkling of sensationalising… already being picked up 
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.
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:
Hi, I’m just wondering how does the things network prevent a DDOS attack on the gateway? Is it using an IDS tailored to LoRAWAN or just a generic one like snort?
Most gateway have limited exposure on the IP side. Just a few listening ports.
Gateways are deployed by gateway owners, not by a central party. All gateways are deployed within different networks. Some networks might include IDS, some (most?) will be connected to a (home) ADSL or equivalent so will be in a NATted and firewalled network which limits access from outside the LAN and with a limited set of devices within the LAN.
I don’t think DDOS against a gateway is likely and not very useful anyway.
Hi @jariyawansa, is your question really about how does the TTN network core deal with a DDoS attack?
If so then TTN should never answer a question like that as it might give away important information to anyone thinking about mounting a DDoS attack against TTN.
Hi @jariyawansa,
First of all, this tool doesn’t prevent attacks. It only detects them for the moment, although it’s our goal to build a more active system. Also, we don’t have any alerts yet about packets flooding on gateways.
All the alerts were crafted with LoRaWAN in mind from scratch, we didn’t use a generic tool.
I hope having answered your doubts!