The Things Network
Bob continues his article series on LoRa. In Part 2, he looks at The Things Network—the Long Range (LoRa) Community based and open source middleware network for LoRa. He discusses what it is, what kind of security it provides, its advantages and disadvantages and how you can get started using it.
The first computer network I was exposed to was DECnet running on a Digital Equipment Corporation (DEC) PDP-11 (Figure 1) [1]. While taking a course on DECnet in Maynard Massachusetts in 1976, some of us were talking about a commercial we’d seen the night before on TV. This was back in the days when there were only three channels and these kinds of conversations regularly happened. The commercial showed two trains rushing at each other on the same track. At the last minute, a control computer talking over a network to the two trains switched one train to a different track and they whizzed by—just missing each other. At the end of the commercial, the narrator said something to the effect of “The power of computers.”
Most of us agreed that we wouldn’t want to be on either one of those trains. During the course of that class, we struggled just to get two PDP-11’s to say “Hello” to each other. I remember the exhilaration when I was able to get my DEC computers talking together back home in the lab. But we all wondered: How in the world would digital networks ever be able to do what was portrayed in the commercial? Fast forward to the present, and today’s networks—both wired and wireless—do far more than we ever imagined back in those early days.
One such amazing network is The Things Network (TTN) (Figure 2). This month we will explore what it is and what kind of security it provides. We’ll explore its advantages and disadvantages and how you can get started using it. Because TTN is based on the LoRa technology, it would be good for you to review the first article in this series [2] if you are not familiar with LoRa.
WHAT IS THE THINGS NETWORK?
Let’s introduce the topic by looking at a particular need. And by seeing how TTN meets that need, we will define the network. Let’s imagine that you have a large number of wireless sensors that you want to deploy in municipalities around the world. Each city would need between 100 and 1,000 of these devices. You have designed a really cool battery-operated sensor. It mounts on or in a product you sell that gets placed all around the city. You have chosen to use LoRa technology for communicating to the first leg on the way to your back end. But how do you get the data to your back end?
One approach would be for you to mount gateways all around the city. Each gateway would talk to about 100 of your devices. You cannot mount the gateway where the device is mounted because it needs more power than an appropriate and acceptably sized battery could provide. It is impractical for you to go to up to 10 businesses in every community and see if they would allow you to power and mount your gateway in their building. Here is where TTN comes in.
— ADVERTISMENT—
—Advertise Here—
Because it is a community based and open network, TTN may have gateways already there. So, let’s imagine that you are going to deploy in Zurich. If you go to the TTN website you find that there are 155 gateways already running there. Viola! You can configure devices to connect to one or more of these gateways and you are in business. The devices will talk via LoRa to the gateway. The gateway will send your data to the TTN backend. You write a simple app that forwards your data to your back end and you are in business.
If there is no existing TTN in all of the cities where your devices are installed, then TTN still helps you. However, as we previously stated, you will have to provide the gateway yourself and find locations around the city to power and mount them. But apart from the logistical problems of finding homes and power for the gateways, the devices and software are off-the-shelf and open source. In summary, TTN enables LoRa devices to connect to gateways which in turn connect to an open-source decentralized network on which you can put your own applications to send the data to your back end.
SECURITY FOR TTN
If you read the literature about LoRa and TTN, you—as a busy designer—may be tempted to deal with it like we do the myriad of licenses and terms and conditions we are asked to accept. Often, we just scroll down and say “I accept” without really knowing what is going on. You may be tempted to say: “These folks are smarter than me. They have thought this through. They write a lot about security. It must be secure.” This has the potential of proving fatal to your project and possibly even your company.
TTN is designed based on the LoRaWAN specification. For example, the specification makes the assumption that you store the keys in tamper-proof / tamper-resistant memory. When the writers of the specification say that network traffic is secure, they are assuming you have done everything they have told you to do. We need to understand how security works in TTN before we blindly adopt it. Knowing how it works, what vulnerabilities it is susceptible to and what measures you need to take to secure your data is critical. You need to know the attacks your device will be vulnerable to and how that fits in the security provided by LoRaWAN.
All IoT devices need two basic forms of security: Confidentiality of the data (preventing others from reading your data) and Authentication of the devices (knowing that you are who I think you are). The LoRaWAN specification was created with a business model where the people who own and operate the network are different from those who own and operate the end device (Figure 3). Confidentiality is created by encrypting all of the data that is sent across the network. For this reason, there are two distinct AES 128- bit private keys (called the root keys) used for encrypting and decrypting: a network session key and an application session key.
ACTIVATION METHODS
Having the network session key alone (necessary for the network operator) does not provide access to the payload of the device. This is a foundational idea in TTN security. Only your application has access to the application key for encrypting and decrypting your data. A third key (application key) is used during one of the two activation methods (Over-The-Air-Activation (OTAA)) to generate the other two keys. Authentication of your end device is primarily provided by utilization of a bearer token which is signed by a secret key and kept on the account server.
The challenge with any private key encryption model is: how to get the root keys onto the devices initially and how to update them. TTN provides two ways for activating your device: Dynamic or OTAA and Static or Activation-By-Personalization (ABP). OTAA is the preferred and most secure method. With OTAA, the devices join the network and network session keys and application session keys are generated from the secret application key.
This method doesn’t solve the chicken and egg problem, however, since the application key must be somehow provided to the network. Various methods are proposed including: Public Key Infrastructure and utilizing the authenticated Diffie-Hellman key Exchange (ADHE) algorithm. But none of this is provided in the TTN open-source code available to date. In addition, TTN allows for all of your devices to have the same application key, which simplifies your process but decreases security.
There are many more in depth discussions of security on TTN’s web site [3] and a number of good articles about the threats that even a well-secured TTN presents [4]. For now, we can just scan down the page and say: “I Accept” that they have some well thought out security methods. It is up to you the designer to find the level of security you require and the lengths you will need to go to get that level of security. As we will show in future articles in this series, the open-source gateway packet forwarders I have found do not implement even the basic security requirements. So, keep in mind that you will be responsible for implementing much of these security requirements, if you deem them necessary.
— ADVERTISMENT—
—Advertise Here—
ADVANTAGES AND DISADVANTAGES
The advantages of TTN are many: a broad community support, a vast array of open-source code from which to build your infrastructure, and the potential of not having to deploy gateways. These are significant advantages.
We have already mentioned one of the disadvantages of TTN and that is that most likely there are not public gateways available where your device is marketed (Figure 4). Even with all of the gateways they have up, that number is a drop in the bucket compared to a full worldwide network provided by the cellular market. This means that you will have to deploy your own gateways. When I think of two devices we designed and developed that were candidates for TTN, there were TTN gateways in less than 1% of the locations. The question we have to ask ourselves: Is TTN going to propagate as widely as cell networks?
Once you deploy your own gateways, you are not the only one on the network. In last month’s article I talked about rules like the amount of time you are allowed to light up the cloud and the number of packets per day. Other poorly designed devices may be on your network that don’t follow those rules, and they could bring your product down.
The activation process for TTN does not lend itself to a quick on-ramp for deploying a large number of devices. As discussed in our last article series, Bluetooth mesh is much further along in this respect with many more built-in automated provisioning steps. And of course, cell technology is way ahead of both LoRa and Bluetooth Mesh along those lines. We have designed and installed hundreds of thousands of cell-based devices using the very automated activation processes that were provided by the cell carriers.
GETTING STARTED WITH TTN
We will talk more about this later in this article series. I’ll describe the setup I used to test out LoRa and TTN. As a little preview of that, here is what I did. You need a LoRa device and a gateway. For my LoRa device, I purchased an ExpLoRer board designed by Sodaq for Microchip.[5] It has everything you need for a stand-alone LoRa device (including a rechargeable battery).
For my TTN gateway, I purchased a Raspberry Pi 3 B+SBC [6] and RAKwireless 831 LoRa gateway [7]. In less than two hours you can have everything put together—although you must wait overnight to get your gateway registered on TTN. After they accept your gateway, you can start sending and receiving packets on the LoRa network. I will provide many more details in the final article in the series—but all of you are smart enough to get these going yourself by using this article’s references.
The Things Network has many significant advantages for deploying low power sensors over long range. The examples given on the TTN’s website show that this is doable quickly and economically. Activation for large numbers and security remain concerns but this is still relatively new technology. Even the LoRaWAN 1.0 specification has already been updated to 1.1 to address security concerns found in the specification used for TTN. Not all end devices are 1.1 compatible. Therefore, known vulnerabilities exist in most of the devices.
As always, we have hit this in thin slices. Next time we will look at a commercial LoRaWAN network that has other potential solutions and possible problems.
RESOURCES
References:
[1] A good history [1957-1977] of Digital Equipment Corporation including DECnet is found here: http://archive.computerhistory.org/resources/text/dec/dec.digital_1957_to_the_present_(1978).1957-1978.102630349.pdf
And of course Wikipedia provides a pretty good summary of DECnet https://en.wikipedia.org/wiki/DECnet
[2] See Embedded in Thin Slices in Circuit Cellar October 2019.[3] https://thethingsnetwork.org
[4] For a more detailed look at the security risks, the threats and the solutions when using LoRaWAN and TTN see “Security Risk Analysis of LoRaWAN and Future Directions” at https://www.mdpi.com/1999-5903/11/1/3/pdf
[5] ExpLoRer board support https://support.sodaq.com/Boards/ExpLoRer/
[6] Raspberry Pi 3 B+ https://static.raspberrypi.org/files/product-briefs/Raspberry-Pi-Model-Bplus-Product-Brief.pdf
[7] RAKWireless 831 LoRa Gateway https://store.rakwireless.com/products/rak831-gateway-module
Microchip Technology | www.microchip.com
Raspberry Pi Foundation | www.raspberrypi.org
Shenzhen RAKwireless Technology | www.rakwireless.com
Sodaq | www.sodaq.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2019 #353 – Get a PDF of the issue
Sponsor this Article
Bob Japenga has been designing embedded systems since 1973. From 1988 - 2020, Bob led a small engineering firm specializing in creating a variety of real-time embedded systems. Bob has been awarded 11 patents in many areas of embedded systems and motion control. Now retired, he enjoys building electronic projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org
