One of the current research priorities for NCC Group is smart cities. We perceive that in the future substantial investment will be made into deploying intelligent sensor systems into our cities: initially the focus being on passive applications, gathering and collecting data, but potentially in future leading to more active applications, integrating systems to automatically take action in response to changes in sensor data.
Indeed, there are examples of these systems already being deployed including smart street lighting deployments in the UK, a smart irrigation management system in Australia and a programme to roll out over 3 million LoRaWAN smart meters in France, after a successful trial of the technology in Toulouse.
The introduction of these types of systems brings with it a variety of potential threats. In the case of smart street lighting they could range from opportunistic (someone working out how they can disable the streetlight outside their house) through criminal (organised crime disabling streetlights to provide cover for robbery or burglary) to nation state threats (plunging entire towns into blackout in an attempt to create panic). A more detailed analysis of the different types of smart city threat can be found in our whitepaper on Securing Smart Cities.
There is already plenty of existing vulnerability research detailing potential flaws in these technologies, and therefore it is the responsibility of system designers, local government and security practitioners to ensure that these systems are resilient to malicious actors wishing to interfere with or otherwise achieve significant influence over the operation of these systems.
Various technologies are competing in the Low-Power Wide-Area Network (LPWAN) space, including Sigfox, LTE-M and NB-IOT and LoRaWAN. Some key points and differentiators of these technologies are highlighted below:
| LoRaWAN | NB-IoT | Sigfox | |
| Spectrum Type | Regulated, but not licenced | Licenced spectrum | Regulated, but not licensed |
| Networks | A mixture of public, commercial and privately deployed networks | Multiple commercially operated networks | Privately owned service provider |
| Standard | Networking stack is open and managed by LoRa Alliance. Radio technology is proprietary (owned by Semtech) | 3GPP | Proprietary (but gradually more details being released) |
| Approximate Power Consumption | 32mA peak, 1µA | 120mA, 5µA | 27mA transmission, 1.6uA |
| Maximum Payload | 1600 byte payload | 243 byte payload | 12 byte payload, 14 packets per day Limited downlink capability (8 bytes) |
| Encryption Mechanism | AES128 symmetric key cryptography | Operator dependent, or independently implemented | AES128 with symmetric token |
There is a more detailed comparison of the various elements of these technologies in “A comparative study of LPWAN technologies for large-scale IoT deployment”.
This blog post focuses on LoRaWAN as it is gaining in popularity for reasons including:
- Interoperability and openness (although the Physical Layer (PHY) is proprietary, other layers of the stack are open)
- Excellent range (a record of 476 miles from 25mW of transmission power)
- Large community support (a large community of makers exist)
- Low cost (infrastructure can be deployed and managed for under $1,000 USD)
The strength of community within the ecosystem was evident when we visited The Things Conference at the end of January 2020. The conference was very well attended, and had a strong blend of technical and non-technical, equipment vendors and service offerings. Major cloud vendors were also in attendance. It was notable that at least one company is looking to provide global coverage for LoRaWAN via satellite.
It is a sign of the growing maturity of the ecosystem that security featured in several of the keynotes, and was an active topic of conversation.
Typical Deployments
The way that LoRaWAN is developing, is in some ways analogous to the development of Wi-Fi in the early 2000s; with a plethora of affordable hardware presenting a low barrier to adoption – and consumers and users of the technology can deploy their own, pay for access or jump on to ‘free’ open networks. For reasons that will be demonstrated in this blog post, that analogy also (just about) stretches to security.
There are typically three modes of deployment, each with their own unique security posture:
Private LoRaWAN
For this theoretical example, let us suppose an entity (academic institution or a business) wants to deploy a variety of sensors across a large campus.
In this instance, the entity will likely look to deploy multiple gateways across their estate to ensure good radio coverage and add layers of redundancy.
It may also be cheaper in the long term to buy the equipment, than to pay for a third party service. However, maintaining a private LoRaWAN network of gateways will come with its own overheads (managing, securing and updating the gateways).
From a security perspective, they might be looking to keep the data internally within their networks (and as such, segregated from the internet) and to maintain oversight of the whole system for risk management and compliance reasons.
Third Party Commercially Operated LoRaWAN
In this instance, a particular consumer, for example a small business owner may want to deploy a couple of sensors to monitor their property. They might deploy a LoRa-enabled passive infrared (PIR) sensor to augment their legacy security system. Additionally, temperature and humidity sensors might be used to monitor a stock room to detect and report conditions that could place perishable goods at risk of spoiling.
This user doesn’t want the overhead of installing and configuring a gateway. Other ancillary infrastructure may be cost prohibitive, not to mention the maintenance of a technology they don’t necessarily understand. On the supply side, developers of sensors and applications want to keep costs low and don’t want to have to provide support for gateways as well. This is where operators of LoRaWAN infrastructure come in (e.g. SK Telecom in South Korea, or Boston Networks in Scotland) and provide the gateways and network server layers to (for a small fee) take that pain away from end-users and application developers.
In this model of operation, one of the primary concerns from a security perspective is that, on quick inspection of three third-party LoRaWAN platforms all of them by default requested the provision of AppKeys to their servers. This enables the network provider to both validate the messages (at network server level) but also decrypt them (at application server level).
This may be an acceptable tradeoff for many, especially if using a trusted provider. However, the LoRaWAN specification’s original intent was to provide data confidentiality end-to-end, and if the network provider (or server) has access to the AppKey, then they can also decrypt the data.
This is a deficiency in the LoRaWAN 1.0.x specification, and is widely known, and has been rectified in LoRaWAN 1.1.x, with the provision of a separate network key. However, at the time of writing it is important to note that there are currently no sensors listed on the LoRa Alliance’s website that support LoRaWAN 1.1, and despite intensive research efforts, the author has been unable to find any LoRaWAN 1.1 devices commercially available. Even when these begin to emerge, some companies will already be tied into particular vendors (for example via ‘sole-source’ restrictions), and there is likely still to be a further lag in adoption as companies work out upgrade routes and migration strategies.
Public LoRaWAN
The Things Network is probably the most well-known example of these. Part of the reason for the rapid growth and take-up of LoRaWAN has been the ease of entry to community hobbyists, makers and developers.
Anyone can buy a LoRaWAN gateway, and join it to The Things Network, leveraging their backend to expand LoRaWAN coverage.
For many consumer and other non-critical applications where perhaps data is less sensitive (more on this later) or system availability is less of a concern, then a community based network such as The Things Network is likely more than suitable. In the future, it is looking likely that LoRaWAN will move towards a more distributed model, using an intermediary like Packet Broker, which was unveiled at The Things Conference in January 2020, or the built-in support in LoRaWAN 1.1 for handover roaming. It is early days for this technology – and we will monitor the progression of the technology. If it becomes widely used, then this will need to be added to the threat model.
Security Challenges
Key Management
Keys to the Kingdom
As indicated in the table above, LoRaWAN does indeed mandate AES-128 encryption. However it uses a shared-secret (symmetric key implementation), which both parties need to have visibility of. It is presumed this decision was made for simplicity and performance (both power and computational) reasons.
There is only really a semantic difference in the practical security of something encrypted by a symmetric implementation of AES as opposed to an asymmetric implementation, but there are different attack vectors to consider.
This is noticeable in the journey that the LoRa Alliance (who publish the LoRaWAN specifications) have been on. In the current widely implemented version (1.0.x), no mention is made of secure elements or hardware security modules. These are rightfully included in 1.1, but any guidance, or specific requirements are left outside the scope of the document.
It is also unfortunate that the specifications are not more prescriptive about the AppKey, and indeed, draw more attention to its importance in securing the system. For example, although both 1.0 and 1.1 specifications do reference the AppKey in both the main body:
The AppKey is an AES-128 rootkey specific tothe end-device. Whenever an end-device joins a network via over-the-air activation, the AppKey is used to derive the session keys NwkSKey and AppSKey specific for that end-device to encrypt and verify network communication and application data
LoRaWAN 1.0.3 Specification
and a related footnote:
Since all end-devices are equipped with unique application [and network] root keys specific for each end-device, extracting the AppKey[/NwkKey] from an end-device only compromises this one end-device.
LoRaWAN 1.0.3 Specification, LoRaWAN 1.1 additions in square brackets
no practical guidance is provided in how these should be best generated, highlighting the true importance of its uniqueness.
In the case of key generation there is some simple guidance that can be followed:
- Do not use an AppKey multiple times under any circumstances
- Do not make an AppKey predictable or related to a well-known value (like the App or DevEUI) (prior research suggests that some vendors have been using predictable keys)
- Do use a cryptographically secure random number generator (not math.random())
- Do carefully consider where you generate the keys, and store them (are they just generated on a developer’s laptop or a dedicated secure offline computer?)
A more extreme approach to the problem could be to utilise some portion of the LoRa stack – but implement a different encryption layer underneath. Researchers have already carried out some investigations into the practicalities of this. However, this is only really going to be of benefit in a particular bespoke solution that requires the additional benefits that an asymmetric implementation might bring.
Practically however, the author believes that the best approach will be for the LoRa Alliance to continue to enhance and develop the specification itself. Projects such as BearSSL, and protocols such as Datagram Transport Layer Security (DTLS) are lowering the barrier to entry for small embedded devices to use asymmetric cryptography.
Alice, Bob, meet Marty
Having discussed the key implementation and generation above, we now turn our attention to another aspect of the LoRaWAN design that it is important to consider from a security perspective.
To adopt ‘Alice and Bob’ terminology, both Alice (the sensor) and Bob (the application server) need to have visibility of the same application session key (AppSKey) so that they can both read, and write messages to each other.
To extend the analogy, in LoRaWAN a third party, Marty (the network server), is actually passing the messages between Alice and Bob. Marty is responsible for verifying the integrity of the messages, and for this it uses the network session key (NwkSKey).
Both AppSKey and NwkSKey are derived from the AppKey which is embedded into individual sensors.
The technical derivation of individual session keys from the AppKey (taken from the LoRaWAN 1.0.3 spec) is shown below:
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)
The problem is that in this implementation Marty can effectively view the traffic if they have access to the AppKey. This deficiency has been addressed in the LoRaWAN 1.1 specification (via the introduction of a separate NwkKey) and by some vendors by introducing a mutually trusted fourth party, Emmett (the join server) who handles the keys.
However, despite the improvement here: the integrity and confidentiality of the system still depends on Alice, Bob, Marty and Emmett all keeping those keys safe. (This is opposed to asymmetric key cryptography where the private key would likely only be installed on the server, Bob in this case). Sometimes, it also depends on Marty being trusted not to peek in (or indeed, modify) your data.
“Has anyone seen my keys?”
From Alice’s perspective, given that sensors are often made with cost, and time to market at the forefront of the vendor’s mind, the security in place around the keys in the sensors is often minimal. Indeed, in our investigations, one vendor supplied the key to us for a device via email, no questions asked, as the piece of paper that should have contained the key information was missing from the box in which our device had arrived.
With physical access to the device, recovery of said keys is normally even more trivial. This is covered in further detail in the Physical Security section below.
The impact of the loss of a single sensor will likely be deployment dependent. In many cases, it is likely to be noticed – and may only cause inconvenience. As such, the most likely security challenge for the average user today might be replacing broken, vandalised or stolen sensors.
However, as these become more prolific and the data more essential to our everyday lives, part of the security challenge will be the constant monitoring of these sensors, looking for unexpected behaviour or bad actors trying to manipulate data.
Bob (the application server) is a more attractive target for an attacker. Accessible remotely, the attacker does not have to risk being physically present at the target to attempt to compromise the sensor. Bob presents a more traditional IT security problem, with well-known mitigations and risk management strategies, but they may still not have significant protection for key storage.
Procurement of an HSM to secure the key material could be a large investment, potentially out of reach of the smaller scale innovators in this space, or could end being a can to be ‘kicked down the road’.
Marty, for the purposes of this analogy is a third party handling the secure messages between Alice and Bob. As demonstrated by the derivation of the NwkSKey above, given the AppKey, Marty has the potential to modify the messages and re-sign them with a correct Message Integrity Code (MIC). This would then lead to Bob trusting decrypting them, resulting in wrong data. (Again, this issue has been resolved to a large extent in LoRaWAN 1.1 – and can be mitigated by the use of a trusted Join Server).
Security of the network server, and application servers, and the keys they rely on to secure communications of the device probably represent the single biggest threat to a LoRaWAN deployment. Compromise could render an entire deployment of thousands of sensors useless.
Currently there exist multiple vulnerabilities in the way keys are provided for devices, for example, we have seen instances where the key is:
- provided within the device’s box/packaging
- emailed to a person requesting the key for a particular device
- a default value available online
There are of course mitigations and caveats to this, for example it is possible to reconfigure the keys on devices, but realistically how often is that done? And one person’s email may have a very different security posture to another.
Very often these systems are provided as a complete solution or service, and the end-user might not have visibility of how the system is secured. As a customer, what steps might you be taking to ensure due diligence? And as a startup or company in this space, what steps are you taking to ensure the integrity of your system? Increasingly during merger and acquisition work, questions are asked of the security of product design.
One final thought before we leave key management: scaling. On a small deployment, key management might be relatively straightforward (at least, in terms of keeping track). Given the potential for IoT to scale rapidly, some thought needs to be given to good key management handling. This is something NCC Group has recently covered in a detailed whitepaper on the secure provisioning of ECUs for trucks.
Session Management
Two join methods are provided in LoRaWAN, over the air activation (OTAA) and activation by personalisation (ABP).
Activation By Personalisation (ABP)
In ABP, the AppSKey and NwkSKey are stored in the sensor manually, and as such no join procedure is required.
Researchers have determined that replay attacks are plausible with ABP-joined devices. In this scenario the session keys (AppSKey and NwkSKey) are static – once the Frame Counter (FCnt) rolls over, previously sent messages are then candidates to be reused in a replay attack.
To evaluate the plausibility of these attacks, let us consider LoRaWAN 1.0.2 which allows for 16-bit, as well as 32-bit frame counters.
To work out how quickly a replay attack may become possible – let us assume an FCnt limited to 16-bits, equating to 0xFFFF or 65535 messages.
Let us also assume a LoRaWAN desk occupancy sensor that sends an update on average every 5 minutes:
# 5 minutes * 65535 = 327675 minutes to exhaust counter
# 327675 / 60 = 5461 hours to exhaust counter
# 5461 / 24 = 227 days to exhaust counterGiven that LoRaWAN sensor manufacturers are boasting battery life times of several years, counter exhaustion is a problem.
If the FCnt field is configured to 32-bit frame counters (which is mandatory in LoRaWAN 1.1) then the rollover point is pushed out to over 4 million messages (over 40,000 years worth of messages at 5 minute intervals). Clearly this implementation is much less vulnerable to replay attacks.
It is worth noting that at a radio protocol level, the FCnt field is still 16-bit and the specification states:
Note: Since the FCnt field carries only the least-significant 16 bits of the 32-bits frame counter, the server must infer the 16 most-significant bits of the frame counter from the observation of the traffic.
LoRaWAN™1.1 Specification (page 23)
It is concerning that there is there is no directive on what should happen at the point at which the counter overflows (or indeed the storage of these).
Both these problems are much less of an issue in OTAA authentication as we shall see in the following section.
Over The Air Authentication (OTAA)
In OTAA, the sensor sends a join request to the gateway, and uses fields provided in the join accept to derive an application session key (AppSKey) and a network session key (NwkSKey).
This to a large extent solves one of the key vulnerabilities of ABP which is that the session keys are static and never change during the lifetime of the device.
However, it is worth noting that potentially the same problem could occur with 16-bit keys if the device does not periodically initiate a new Join procedure.
The bigger risk in OTAA is a replay attack using the Join Request message.
LoRaWAN 1.1
Although LoRaWAN 1.1 addresses many of the deficiencies of LoRaWAN 1.0.x, the fundamentals of the OTAA and ABP methods have not changed. The main key management challenge added by 1.1 is the move to use a separate AppKey and NwkKey.
Efforts are ongoing to improve LoRaWAN security in this area – for example, research has shown that Ephemeral Diffie–Hellman Over COSE (EDHOC) could be used to provide secure, and regularly updated session keys.
In terms of cost to business, compromise of a set of keys to a sensor network of a medium to large-scale sensor network deployment of 1000 sensors could be extremely expensive to replace, or repair.
Embedded Device Security
Sensors
It is likely, and indeed probably accepted that in various LoRaWAN deployments, sensors will be in publicly accessible areas. For example, on lampposts, in dustbins, in fields or underneath office desks. Experience suggests that given enough time and money, a determined attacker will find a route to compromise. They will find a way to extract the keys from the secure element and/or find some other vulnerability in the sensor.
For example, the commonly used RN2483 transceiver for example, communicates with other devices (typically a low power microprocessor) using a UART interface. With commodity hardware it is very straightforward to ‘sniff’ those data lines to retrieve the AppKey when it is set using the “mac set appkey” command.
STMicroelectronics recently launched ‘the LoRa system-on-chip (SoC)’, while this removes the above problem (or at least, raises the bar substantially), compromise via microcontroller readback is still a problem.
As security in embedded devices can increase the cost per unit, compromises have to be made. Recognising that this is a potential barrier to uptake, The Things Industries has been working on a solution with Microchip, which may provide a cost effective solution to including a secure element in LoRaWAN products. Semtech in their LoRaMac-node reference implementation have also recently included support for a secure element.
For the reasons described above, it is reasonable to assume a very low bar currently to compromise a single sensor and obtain its keys. It is important therefore to ensure that a single compromised sensor can be detected, can be isolated, and not impact other sensors (or devices) in the network.
This could be done in different ways:
- Detection from the application server: LoRa devices typically have very predictable and long battery lives. It is likely that in many cases there will be regular patterns to their usage (e.g. a temperature sensor updating at a regular interval, or a desk occupancy sensor being very active at 9am). Anomalies should be flagged.
- Tamper proofing could be applied to the sensors such that when they are opened, key material is automatically erased and the device is rendered inoperable until being recommissioned.
Gateways
In the LoRa Alliance specifications the gateway is very much portrayed as a fairly passive component within the LoRaWAN network (merely providing an interface between the sensor nodes, and the network server). For example, the LoRa Alliance’s interpretation of a gateway is shown below:
While some of the gateways we have analysed do match this interpretation, others have many more features and power available to them.
These systems are very often custom embedded Linux platforms and again, with cost being one of the primary drivers for uptake of LoRaWAN, they may not always built to the highest standards (or maintained as such once released.
It is theoretically possible to run the entire system LoRaWAN stack, network and app server on a single device – with keys being stored on the gateway (indeed, we have tried this for our own testing purposes). However, in a real world system this would be non-typical and present a potential security risk (as keys would be stored on a physically accessible piece of embedded hardware). We note that some vendors however, are actively pushing applications out to gateways – attempting to add value to their offering by adding edge computing and reducing backhaul WAN costs.
That said, let us consider the function of the gateway: to collect encrypted messages from sensors and forward them onto the network server. In the third party and public LoRaWAN models, the burden of responsibility is assumed to move from the end party consumer to the third party. But if you deploy your own private LoRaWAN network, you are effectively taking on that risk (possibly for very good reason).
What does this risk look like? Well, consider an application where only one gateway is deployed; this as a single point of failure in the system. However, LoRAWAN is designed to allow multiple gateways to connect to a network server, so this can be mitigated.
Questions that arise here for those deploying and operating LoRaWAN solutions include:
- Have you carefully selected a vendor and bought the same device to get some economies of scale on your purchases?
- Are all your gateways connected via the same network or VLAN to the network server?
- If your network was compromised, would it be possible to compromise all the LoRaWAN gateways – rendering them inoperable, or part of a botnet?
If this rendered a hot-desking system that allows staff to quickly locate free desks inoperable, it is likely to cause inconvenience, and some reduction in employees’ effective time while they search out vacant desks – but this would not be a showstopper.
External Factors
A secondary area to consider here is attacks on the sensor that do not require the sensor itself to be compromised.
For example, consider the case of a thermostat controlled by a landlord or holiday home tenant who wanted to restrict energy usage. There are multiple examples on the internet of ways in which these can be manipulated.
Consider also, an office monitoring system: if the device measuring desk occupancy is reliant on a PIR sensor to detect movement, but some tape is placed over the external sensor…
Meta Data
DevEUI
Even if we assume a securely implemented system (with appropriate restrictions around keys in place), the payload data will be encrypted using AES128, yet there is still a large amount of metadata available to any attacker.
The presence of a device could in itself be useful information for an attacker. The DevEUI is a globally defined IEEE EUI64 address space and it is possible to identify the manufacturer or owner of an end device by looking up the first three bytes at the IEEE Registration authority.
When a device sends a Join Request, the DevEUI is transmitted unencrypted over the air. If the manufacturer only has a single product, or type of product, it will be possible to make an educated guess as to what might be being deployed in the area (and potentially locate the sensor physically).
Message Length
Prior research has identified that due to the type of encryption used (AES-CTR mode), the plaintext message length can be easily determined from the encrypted LoRaWAN message. This additional information may allow an attacker to narrow their field of products, or identify specific types of messages that are sent by sensors.
Behaviours
LoRa sensors also tend to be heavily optimised to reduce power consumption and to push the boundaries of battery life. A side effect of this, is that in some cases they may only transmit when ‘something’ is happening.
For example consider a sensor designed to detect the opening of doors. It is conceivable that a developer could consider the device should only communicate over LoRa to identify a change in state. Although this will be the most power efficient use case, it also means that the very fact the device is transmitting at all is giving away an indication that the door is being opened or closed. Depending on the profile of the person(s) who occupy a particular area, this could be valuable intelligence.
Access to any of this metadata, either by capturing the information via the front-end (LoRa radio interface), or by somehow compromising the backend (e.g. a man-in-the-middle attack between network server and application server), could prove valuable for anyone looking to perform a physical breach of a building or area.
Data Handling
By no means specific to LoRaWAN, but also important to consider, is the security and use cases of the data that is being collected (hopefully, securely from sensor to application server).
Research suggests simple temperature and humidity data can indicate whether a room is occupied or not and as such, there is a possibility that this could be considered personally identifiable information under GDPR.
Other data might be of great commercial value. For example, understanding footfall patterns in a busy train station or shopping centre could potentially provide an advantage. What happens to your data once it reaches the application server and is decrypted, is up to you.
Securing your deployment
Considering all of the above, and to leave readers with some food for thought we have come up with a quick list of practical things to be considered when deploying a LoRaWAN system (or indeed, any LPWAN system):
Understand your threat model
When considering the deployment of your sensor network it is vital to understand the nuts and bolts of your deployment (from sensors, all the way through to your end-user application) as well as any context-specific security requirements. For example, if the sensor network was reliant on the clock-sync functionality introduced in LoRAWAN 1.0.3 release, it is important to bear in mind this is relying on the time received from the network server, as opposed to the application server.
Particular thought needs to be given to sensor compromise for example, as in many applications (especially smart city or agritech applications) the sensors will be located in public spaces, and as such the potential for tampering is high.
One level up from the sensor, if reliability and resilience are import, it will be important to ensure that your gateway deployment (whether private or third party) is going to be robust to any attempted attacks.
Other concerns might be in terms of ownership of data, and networking infrastructure. Many IoT systems are sold ‘as a service’ and as such it will be important to ensure that appropriate due diligence is carried out on any third parties involved, and that clear delegation of responsibility for the handling of any sensitive data is made.
Think about your key management
We have already covered some of the challenges with key management earlier in this post.
In simple terms, think about your network and application server – they will more than likely contain the keys to the kingdom (almost literally).
In terms of more detailed practical help – especially for deployments that need to scale, NCC Group have produced an in-depth whitepaper on Secure Device Provisioning best practices[i], which although presented within the context of the trucking or transportation imagery, the concepts required here are very similar.
Monitoring
Consider how you will monitor your sensor network. As previously discussed, compromise of a single sensor given physical access is likely quite high. It is important not to blindly trust the data coming back from the sensors – especially if the data is being used to actively control a system in response to the data.
Unusual scenarios that might prompt further investigation could include:
- Unexpected join requests to the network from a device (at a minimum perhaps, suggesting a device has been tampered with or damaged – but at worst perhaps, the device has been powered down and tampered with).
- A device suddenly communicating ‘out-of-sequence’. If a sensor is configured to transmit, for example, every 15 minutes, but goes missing for an hour (with no previous record of being unreliable).
- Deviation between two co-located sensors in a system where only subtle deltas should occur within localised regions.
Consider the future
LoRaWAN sensors available at present (April 2020) typically do not have over-the-air firmware update mechanisms in our experience. This means that should any issue be found in the sensors, it may require replacement of the device.
While vendors are actively working on it, it would be prudent to engage with suppliers to understand whether they have a firmware update over the air (FUOTA) capability and what they plan to do should any vulnerability be discovered in their equipment.
Gateways do typically receive regular firmware updates, and should be kept up-to-date as per good security hygiene.
Finally, when it comes to decommissioning any devices, care should be taken at all aspects of the network (sensors, gateways and servers) to ensure that any sensitive data associated keys are removed from your network .
The Future
Predicting the future is hard: and history is littered with technologies that showed great promise and then fell by the wayside. As per the introduction, in the area of LPWAN there are currently various competing technologies, and it feels inevitable that some will fall by the wayside. That said, it is hard, at this point to envisage a world where LoRaWAN isn’t playing some key part in sensor networks.
It is fair to say that, the technology is rapidly maturing (with providers looking to expand coverage to hard to reach areas via satellite), and NCC Group is starting to see more interest from our clients in developing, deploying and utilising these sensor networks in secure ways within their businesses.
It was notable at The Things Conference (and more widely in the ecosystem) that awareness around security is growing. Although some of the sensors on the market do have weak physical security (i.e. where physical access would lead to very quick compromise of the device keys), the ecosystem is moving towards the inclusion and use of secure elements within products.
Anecdotally from the conference, it seems that certain elements from LoRaWAN 1.1 which improve the security posture of the protocol (for example, 32-bit frame counters) are being ‘backported’ to a new 1.0.4 release which will hopefully see more rapid uptake of these features, before work resumes on the new LoRaWAN 1.1.x series. Firmware updates over the air (FUOTA) seems to be one area that is still very much a work in progress.
Upcoming roaming features within both the LoRaWAN stack, and the ecosystem (such as Packet Broker) are interesting avenues which as well as undoubted benefits, will surely have as yet unrealised security implications.
Conclusion
Sensor networks are a rapidly advancing area of technology, and smart cities incorporating this technology are here today. However, what their impact will be on the world and society in general is not yet understood. There are several hypothetical scenarios where compromise of a sensor, or sensor networks could lead to real risk. This has to be offset by the appreciable gains that society will make from the deployment of this technology, and also what a reasonable bar for exploitation should be.
One thing that we noticed at The Things Network conference was that, effectively, we are in the main still very much at the data gathering stage of sensor networks. That is, collecting more and more information about the world around us (particularly the environment). Alongside the concerns mentioned earlier around privacy, currently these systems in the main do not lead to direct action being taken.
We continue to develop our LoRaWAN capabilities within NCC Group – in terms of methodology development and developing deep understanding of the technology, and also where applicable development of tools and testing capabilities to allow us to demonstrate and prove our theories. Currently we are building an internal lab of representative LoRaWAN devices to develop our own captive ‘smart city’, and developing our own ‘bad gateway’ which we can use to test other devices. More to follow in future blog posts on our Smart City and LPWAN security research…
Acknowledgements: I would like to extend a special thanks to the various NCC Group employees from around the world that took time to review and suggest improvements to this blogpost.
