Are keys the key to the LoRaWAN kingdom when it comes to security? Dave Kjendal, CTO of Senet, say encryption keys are one important part of securing Low Power Radio Access networks, but when those networks connecting things are connecting critical infrastructure (for example a power plant, a chemical plant, public transportation hubs and security systems) – organizations and enterprises need to prepare for the cyber barbarians at the gate with multiple layers of protection.
While LoRa has long been considered the low cost, lower battery consumption protocol and approach to networking (vs. broadband, cellular and satellite solutions) more and more mission critical deployments are going live every day. Just because the hundreds or thousands or tens of thousands of battery operated endpoints are less sophisticated and compute-heavy than other industrial grade alternatives, doesn’t mean those endpoints shouldn’t be shielded from botnets, exfiltration attacks, and more.
“We’re all over ensuring our LoRa network infrastructure and services are fully secure,” Kjendal said, pointing to a recent announcement with G&D Security, covered by Carl Ford a few weeks ago. “We’re working with global leaders in encryption, like G&D, while also ensuring our own network operations are as locked down as possible.”
The layer cake of LoRaWAN security includes orchestration from the device to the gateway to the cloud and into the applications layer and back again. Securing increasingly large local LoRa deployments (as well as distributed systems where multiple LoRa networks transmit information into a centralized view and control platform) is driving innovation in network operations and policy – enterprise grade vs. simple POCs.
According to this outstanding analysis by Robert Miller, a security consultant and researcher for MWR InfoSecurity, “The LoRaWAN protocol like many of its rivals offers encryption and secure methods of provisioning end devices (Nodes). However, these features should not be blindly trusted by developers and users as they do not defend every possible attack against their solution, and their effectiveness will be governed by the developer’s implementation.”
Miller’s white paper goes on to define the application of security of the Long Rang (LoRa) solution and its Long Range Wide Area Network (LoRaWAN) protocol, proving “clear guidance about how LoRa secures data as well as its limitations that must be considered by developers and users.”
It’s a comprehensive read, that delves into session management (including signing and encryption for parts of LoRaWAN packets using symmetric keys known to both the node and network server, and onto application servers depending on the system). The discussion includes OTA updates, AppKeys, AppEUIs and DevEUIs, and explores many variations on the security theme depending on each use case.
Like Kjendal, Miller’s guidance for companies deploying LoRa networks, or using them, is to take security into consideration as a forethought, not an afterthought.
For example, multicast message, which allow the Network Server to send a single downlink message to multiple class B Nodes simultaneously, is inherently less secure than unicast, but of course far more efficient especially for large LoRaWAN-based systems. Security professionals are still working on ensuring that shared keys are made secure, with Nodes updating transceivers with new NwkSkey and AppSkey keys. For example, Miller says, “as the keys are normally based on nonces, and the keys themselves are never transferred, it is unclear how this would work in practice.”
Kjendal explained that, as with any data network, “good hygiene” across the board is called for. Even with blockchain-based security systems, which claim to be more secure than previous interconnection and data-sharing technologies, if the network itself is exposed when multiple administrators are allowed into the network and can change policies or otherwise update the network, significant risks are present.
“Having an Identity Access Management policy and software in place, especially Privileged Access Management, is an important part of scaling LoRa and any other type of IoT network as the world of connected things continues its growth,” Kjendal said.
Given the nature of IoT networks, and the requirement to also deliver infrastructure and services cost efficiently, Kjendal foresees tremendous innovation in automation of all the layers of security in LoRa-based networks. “We are working with the smartest security teams in the world,” Kjendal said, “to integrate security that provides the appropriate layers of defense, without sacrificing performance or quality of service. We’re seeing advances in labs that will be quite meaningful to the entire LoRa community, not just Senet. We’re probably one of the most active partners given that we are growing so fast, and working with so many big enterprise and systems integration partners.”
Senet announced earlier this month a new Global Low Power Wide Area Virtual Network (LVN™). The LVN is a demand-based and incentive-based solution for not just connecting LoRaWAN networks, but enabling the build out and broader availability of new services on those networks.
Senet is well known for having built the largest low-power wide-area network (LoRaWAN) in North America, in 225 markets, covering 100,000 square miles, able to serve a population of 50 million people. They are on the move in other regions as well, from Australia to India, so the stakes are getting higher.
Like its Managed Network Services for IoT (MNSi) and public network, Senet’s LVN is built on the cloud-based services architecture of its proprietary Network Operating System. It’s the virtualized brother of their physical network builds, and it’s more software than hardware. It’s open and flexible, and purpose built to allow for a lot of creative business models, including those with rev shares (and that is not an easy thing to do).
We have a hunch Senet is now going to more openly court all the participants in the ever-evolving world of connectivity, including large network operators with substantial customers, their own infrastructure investments, and a desire to move into the attractive LoRaWAN market with a lot less risk.
Given the move to NFV and SDN by all the Tier Ones and many lower tier operators and service providers, “tapping in” is getting easier, but it can also expose more risk as the interconnected networks and services grow and more money is being made and shared on those networks.
Senet, one of the most successful LoRaWAN companies with substantial capital invested and growing talent pool, made its mark by creating their own “POCs” and building Points-of-Presence (PoPs) in the real world, the old-fashioned telecom footprint way. But that’s clearly not their end-game.
With Senet going even more aggressively and creatively in the space, it’s going to be fun to watch.
Following are a few questions we posed on the new LVN:
What happens when gateways and end points are registered to the network?
Gateways: The RAN provider will use the Senet Network Server’s Customer Portal to register a new gateway on the Senet LVN network. The registration process will provide the necessary Senet software agent to be installed on the gateway, prompt for the gateway type, location, antenna gain and deployment height. Once registered, deployed and connected to the internet, the device will become active an active participant in the Senet LVN.
Devices: For devices under contract with Senet directly or with one of Senet’ MNSi customers, once authorized they are authorized to connect using any Senet LVN Radio Access Network.
How are those categorized and priced?
RAN Providers that participate in the Senet LVN are categorized into classes, which is factored into a weighted RAN Provider revenue share model.
Application Providers that participate in the Senet LVN are entitled to a rebate based on the devices connecting to their network.
What are the SLAs? Do those SLAs include – security?
Revenue sharing by RAN provider class encourages high quality network builds. Senet LVN participant gateways are classified based on the grade of service e.g. Carrier/Operator/Service Provider, Enterprise, Consumer. The better the SLA on the gateway, the higher the revenue share opportunity for the RAN provider.
How will rev shares really work?
Participants are paid for third-party usage of their RAN based upon their role/investment in network.
RAN Providers are categorized into classes, which are factored into a weighted RAN Provider revenue share model. Revenue share allocation is established based on number of qualified messages using the provider’s RAN.
Application Providers are entitled to a rebate based on the devices connecting to their network. A rebate pool is established based on number of qualified messages using the providers RAN.
What value add is Senet really bringing?
- The Senet LVN is available today, providing an IoT-centric network model needed to deploy, securely connect and manage millions, and ultimately billions, of low-power, low-cost sensors.
- Senet’s OSS/BSS functionality is being used to enable the delivery LoRaWAN services globally. It is optimized for LoRaWAN IoT and built with an advanced micro-services architecture deployed as cloud based resources to provide ease of deployment, high availability, on demand scale and redundancy (not adapted from a legacy connectivity technology and business models).
- LVN enables geographic expansion of LoRaWAN network services without any one party incurring the brunt of the capital equipment expense.
- Costs, contracts and complexities are minimized by centralizing application onboarding.
- The LVN business model provides participants with opportunities for new revenue streams.
With multi-faceted ecosystems and more and more APIs – whose responsibility is security? It’s everybody’s responsibility, but what is the framework that will actually work – protecting the core, the edge, the endpoints in the “fog,” and the applications in the cloud?
Senet is not just targeting the traditional connectivity providers; they’ll continue to disrupt, it seems, by bringing revenue opportunities to power companies, for example – by placing their gateways on power company’s poles. This could be a boon for municipalities, utilities, but also any organization who owns something up in the air where a gateway can be installed.
One can see, with all of this activity, breadth, creativity, disruption, and money at stake – securing LoRaWAN networks is no longer “just POC.” It’s becoming very big, very real, very fast.
In his conclusion on securing LoRa and the LoRaWAN protocol networks, Miller writes “Secure solutions must be developed that protect the company and the end user from cyberattacks. It should be clear to all developers of LoRa solutions however, that using LoRa does not guarantee security. Instead they should build LoRa solutions with the potential attacks in mind. Given that LoRa will form part of a complex IT solution means that security vulnerabilities are a likely occurrence during development. Similarly given that LoRa solutions are being used in systems ranging in use from home security through to monitoring and controller infrastructure, attacks and development of exploits against these systems are also likely.”
It's encouraging to see many leaders in the LoRa space working together with leaders in the network operations and security space, as security can no longer be an “afterthought” – nor can the network itself be an “afterthought.”
Connected things with long lifespans generate untold value for businesses and governments, but without ensuring comprehensive security, on all layers, it will take much longer for that value to be unlocked.
Edited by
Ken Briodagh
