Securing the LPWA environment – a step into the unknown?
The arrival of any new communications technology on the scene always poses a conundrum: while it might bring promise improvements in any number of areas, it might also introduce our industry – and our users and customers – to an entirely new set of security vulnerabilities. Recent history shows that, in many cases, appropriate security levels have had to be added retrospectively, adding time and cost to deployments and eroding trust in each particular solution.
The current ferment around the LPWA (Low Power Wide Area) networks area and, in particular, the emergence of solutions from outside the already well-policed 3GPP and ETSI standards communities, means that questions now have to be asked about the security techniques and policies used by these new technologies. At the risk of mixing some metaphors, while we don’t want to cry wolf unnecessarily, we also don’t want to have to close the stable door after the proverbial horse has bolted…
Against this backdrop, IoT Now’s Alun Lewis thought he should sit down for a chat with Loic Bonvarlet, product marketing director for M2M solutions and services at Gemalto, one of the world’s leading secure communications companies, to discuss the security aspects and challenges of the LPWA domain and, more specifically, LoRa.
IoT Now: Loic, historically the great majority of M2M solutions have relied upon cellular networks for connectivity. Security issues in this domain are not only well-understood and based upon many years of practical experience, but they’re also based on the use of SIMs. The LPWA solutions not based on 3GPP technologies – such as LoRa – that are now appearing don’t use SIMs. What security management issues does this raise for service providers?
LB: There are probably two main areas that are currently rather problematic with LPWA – as opposed to the cellular world that we’ve grown used to over the last couple of decades. Firstly, in the absence of a SIM, how can you provide appropriate credentials to each device to identify it in unique and secure ways? A complementary issue to this involves the challenge of spotting cloned devices, where a device or sensor’s identity can be effectively hijacked for nefarious purposes, or making sure right from the start that devices cannot be cloned.
The second area of potential concern involves the now fast expanding LoRa ecosystem, bringing a wide range of companies, both old and new, into the space. Expertise and experience in IoT security are not evenly distributed across all the participating vendors and service providers now entering the sector, particularly given the extremely broad attack surfaces that this environment presents to opportunists. As a result, for the time being at least until more formal processes are established, both users and network providers must proceed very carefully when it comes to joining together the different elements, data and applications that collectively make up an LPWA service. Some system, device and application functionalities might need to be disabled or limited to impose some level of isolation and ensure that any attacker can’t get the keys to all of the kingdom in one fell swoop.
IoT Now: The success – and revenue potential – of the IoT depends on there being a pretty open ecosystem that’s able to share data across devices, communications links, gateways, databases and applications. How will the deployment of LoRa affect the security environment that all the other players in the ecosystem, such as application developers and device manufacturers, have to understand and apply consistently?
LB: Security has to be imposed by design right from the start of any project – or, indeed, right from the very first discussions with device and sensor manufacturers and application developers. Companies have to make sure the risk exposures associated with the eventual end-to-end solution and its specific operational environment are well understood. Understanding the contexts in which the system will eventually be used is essential in applying appropriate levels of security. Security by Design principles are both well understood and well established and involve taking into account both software and hardware factors. Skilled and well-equipped hackers, for example, can even use probes on individual chips, extracting information and commands before they are encrypted.
It’s also essential to have plans in place to be able to manage your devices and solutions across the whole of their life cycle, because tomorrow’s threats will be different from today. This issue is particularly acute in the LPWA environment where the long battery life means that many devices will be intended to remain in situ and unattended and unvisited for many years, especially if they are in settings hazardous to human health.
IoT Now: There are always going to be some ‘civilisation-critical’ IoT applications – such as the utilities – where extra security will be needed. What solutions would Gemalto advise here?
LB: For critical infrastructures such as the utilities, or specific use cases such as the monitoring of high value assets and items, the security inherent in an LPWAN transport network today might be deemed insufficient to cope with the risks currently at hand. In such a case, by applying a thorough risk analysis, it becomes possible to complement the network’s security with application security principles. These, at a minimum, involve using both encryption and applying signatures to the end-to-end data flows from end device sensors to the backend servers actually processing the data.
LPWA networks hold a huge potential when it comes to realising the next wave of the IoT vision and the deployment of smart ‘things’ across an increasingly interconnected planet. We just have to make sure that our next steps are made on solid ground – and that only comes through a deep understanding of the accompanying vulnerabilities and tools and processes that must be used to protect ourselves, our business and our communities.