If you’re creating an Internet of Things device or application, your team has likely already taken both security and testing frameworks into account. But there are a lot of things you need to consider as you move through this process. To help out, we’ve outlined the top five things to keep in mind during security testing and the top three things to remember for your IoT testing framework.
There are two different approaches to keep in mind when thinking about encryption: where the data lives online and how the data gets to the internet. The standard practice online is to use SSL, which you should use everywhere your data exists.
On the wireless protocol side, you need to be sure the protocol you’re using has built-in encryption.Take asset tracking, for example. If your device isn’t encrypted and you’re relaying the location of your assets, anyone could read that information. If you created a device for your customers to keep track of their valuable belongings, those customers want to be the only ones who know where they are—not any random person online.
Even though your data is encrypted, you want to be sure your device is talking only to you and that only you can talk to your device. A consequence of neglecting authentication is that anyone can make up information and send it to you, and you’d have no way to verify that it isn’t real.
Let’s say you have agricultural sensors on your farm. This seems pretty innocuous—you might not think you need to encrypt that data. But what if someone decides to fake a drought and feeds data saying your plants need more water? As a result, you may end up flooding your system and effectively ruining your crops. You can see how the lack of authentication can have drastic consequences, even if they aren’t obvious upfront.
Even with encryption and authentication, there are still other ways to gain illicit access to your system. Side channel attacks have less to do with the information itself and more with how the information is presented.
For example, if you have an IoT device that detects when something arrives at a location and you send notifications only when the asset has reached its destination, someone could detect that. The location itself may be encrypted, but the fact that you’re sending a notification can tip someone off and allow for them to gain access. This may apply more for sensitive applications like government or military, but is worth keeping in mind nonetheless.
First, you have to keep in mind if the network you’re thinking about will fit your application’s range needs. Let’s consider Symphony Link as an example. A potential customer can purchase our development kit, setup a gateway, and take our network tester out for a spin. (The network tester is a handheld device that tells the user how strong the signal is from the gateway as they walk around.) People talk about the great range of the LoRa radio—which is what our Symphony Link system is built on—but even still, you can’t violate physics. No matter what, you’ll always need to test to ensure you have the coverage you require.
Or, take ZigBee. If you want to deploy a ZigBee application, you have to determine how many repeaters you’d need in the building and where to put them in order for the installation to work. And because it’s a mesh network, adding more repeaters lessens the capacity you have in your system—and eventually you’ll get to a breaking point. So you will want to figure out what that sweet spot is before going forward with your deployment.
Most people want to push the limits of capacity (the number of bytes per second that the network can handle) and latency (the total time it takes for a message to get from an endpoint to the cloud-based application, or vice versa). Those two factors are always in competition with each other. To increase the capacity of a network, by definition, you’re increasing the latency. On the other hand, if you want to bring your latency down, you’re going to affect the capacity of the network negatively. With this in mind, if you’re building a data-intensive IoT device, you’ll need to test whether or not the network can support those demands.
For example, there are some IoT companies who are interested in monitoring and controlling an electric plant. They want to be able to measure current from a node in a circuit and throw a breaker or move a switch in response to that measurement. Often, they are looking for extremely short latency for that control application, on the order of milliseconds. Unfortunately, that’s not practical for any wireless system, unless you can live with not all of your messages getting through the first time due to collisions.
When a wireless module rolls off the assembly line, each one goes into a fixture that tests the power output, receiver sensitivity, and frequency accuracy. Even if you’re purchasing a pre-built module and integrating it into your host application, you’ll still want that kind of assembly line testing on your end-device.
Let’s say you’ve created a parking sensor, which will sit under a car and use magnetic field detection to know if there is a car there. If the appropriate magnetic field is detected, it will send a message up to a gateway. To manufacture this product, there are a few components you’d have to keep in mind.
On the assembly line, you must make sure that there are no issues when you put the modules down on the carrier board. For example, did anything happen during the soldering process? You’ll need to test the module by both visual and X-ray inspection around all of the soldered connections.
You’ll also want to do a functional test when the product is off the assembly line so you can exercise the ability of the radio module and test all of the possible states your microcontroller could go through.This process ensures your application acts as intended on every single device.
If you are going to build a military-specific application, you’ll want to understand all of the specs beforehand and verify that the components you’re adding to your device meet those specs. For example, can a particular sensor survive in 150-degree temperatures for a certain amount of time? You’ll need to keep these considerations in mind.
Once your end device is complete, you’ll have to go through FCC (in the U.S.) or ETSI/CE (in Europe) certification. In the U.S., you could buy a module with a pre-approved certification and put it into your end device, which allows it operate in the 900-928 MHz ISM band. This is nice, and it gives you an indication that you’ll pass the final testing you need to go through—but as the manufacturer, you also need need to be able to pass the FCC’s unintentional emissions verification test when you’re finished with the design.
The most important thing to remember about IoT security is that your data doesn’t go from A to B directly; it takes a route over the wireless interface and through the Internet. To protect your data along that path, you absolutely need to follow the steps outlined above.
Also, remember that the IoT testing framework is complex! All of the validation and testing for a particular application can take 12-18 months—and sometimes longer. You can give yourself a good head start by purchasing pre-certified modules, but be prepared to do a fair amount of the testing yourself.
Do you have questions about security or testing processes? Tweet us @LinkLabsInc or drop us a line; we’re happy to help.