Make No Assumptions When it Comes to Cellular System Security
Security in cellular IoT systems is often misunderstood and occasionally neglected. Those new to IoT may assume their device will have a public IP address on the Internet, or that a VPN is automatically in place. Other common assumptions include the presence or absence of things like firewalls, network address translation (NAT), stateful packet inspection, port IP forwarding, SIM locking, and a wide array of other “features” that may or may not actually exist. Indeed “features” that may or may not be a good idea.
When designing IP based IoT systems, it’s important to anticipate the worst case situation and make no assumptions. IoT is fundamentally different from other IP based communication systems. Do not assume that because you’ve always seen something done a specific way when dealing with data centers or cloud services, that the same methods are correct for IoT.
A common example is assuming that “somewhere at the carrier” NAT and a firewall are present between cellular devices and the public Internet, so the device can initiate outgoing IP connections, but from the public internet, there is no way to open an IP connection directly to your device. That might sound reasonable, however we have to anticipate that hackers can gain access inside that firewall and get to the NAT address segment.
Never Trust the Channel
Channel security can change over time with the deployment of new equipment or technologies. All network types from cellular to Sigfox have their own flaws and are prone to attack. Product creators cannot control the channel and should never trust any system outside their control. Over cellular, devices can be taken offline or be tracked by cell tower location if the provider does not offer proper signaling protections.
The best solution for IoT data security is end-to-end authentication and/or encryption. There are a number of ways to handle this. The more expensive way is to simply rely on an end to end SSL/TLS connection over TCP. This adds quite a lot of overhead during negotiation, in message headers, and with connection keep-alive messages, however this is proven and well known. The downside is that since cellular is a metered connection, each byte represents a real expense. When employing 10k units to be in service 24/7/365, even a few extra bytes per message add up to big money.
Some data doesn’t need to be encrypted, only verified as coming from the identified source. Message signing and authentication is often sufficient in many applications. Be aware, however, that just because the data being sent doesn’t appear to have value to the hackers today, this could change in time with new technological development that makes this data newly relevant. Message signing of each packet and using UDP can make a big difference in your data plan bill vs. encryption and TCP.
If data needs to be encrypted, doing so on a message-by-message basis is more secure and allows you to avoid extra overhead due to channel encryption negotiation. It also still allows for using UDP for lower packet overhead vs. TCP. The fewer messages your device sends per day, the more value you’ll get out of end-to-end message encryption. On the other hand, if you’re sending large amounts of data fairly often, then the overhead of TCP/TLS may not matter much.
Check Hardware Security
Having followed all the advice you can find, tested and fixed your system – you may decide your data is secure. In reality, you’ve only just begun. Now you need to ensure your hardware itself isn’t at risk. You can bet on a hacker having physical access to your IoT device. Bad actors are ubiquitous, and often in isolated places where it’s easy to manipulate the device for extended periods of time. To make matters worse, since radio system connectivity is not guaranteed, watching for missed reports does not serve as a notification if a device has been compromised.
The first step to device security is as simple as ensuring the programming interface is secured on shipped units. Your production test system should be tripping the JTAG (or other programming interface) fuse on every device it processes once it verifies the bootloader was programmed correctly. From there on, the device can only be programmed using the bootloader. That bootloader needs to work in a failsafe way, so that a loss of power never causes the device to fail in a way that it can’t recover from by itself. That bootloader also needs to enforce use of encrypted/signed firmware images to ensure it only accepts new firmware from a trusted source.
With these steps, you have protected the hardware from inspection by a debugger and reading out of the programmed firmware image, and also secured it from accepting and running an unauthorized firmware image. Next, consider the sources of data your device is gathering. Could someone disable or spoof a sensor in the system? If so, how important is that and what can you do about it? Finally, how does your remote hardware handle power interruption? Does your application need to ensure the device wasn’t relocated? As you think through your application, likely other factors to consider will come up. Take your time, write it all down, and consider having a third party review your security plan.
Secure Anything of Value
Data over the channel is secure and hardware is secure. Is this everything?? Not quite. Here’s where things get a bit more subtle. Anything in the IoT system that somebody is paying for, by definition, has value. While it may not seem to have a lot of value to a wide audience, it is valuable to someone.
In a cellular system, there are significant costs in those bytes of connectivity. What’s to keep someone from breaking open a device and stealing the SIM card to put in their own connectivity device? Remember that hackers are just as qualified as any industry expert. If the industry has come to understand something, we can be sure those bad actors have as well.. What about the case of a private APN? It is easy enough for a hacker to simply sniff the serial line to the cell radio and gain access. SIM theft may have various repercussions. In the best case, a SIM may be put in a common cell router, and used for common video streaming – resulting in a $20K cellular bill. In more serious examples, an enterprise may find themselves in hot water with governmental authorities over questionable uses of data and suspicious activity.
To prevent the use of a SIM in an unauthorized device, make sure it is locked to the cellular radio IMEI. Ensure your cellular radio is locked to your SIM either at the radio level or in your application software. This will prevent someone using another network provider to spoof the system and reverse engineer it. This cannot be accomplished on units used for certification testing, however the production tester should apply this to every shipped device. Another way to prevent SIM theft fraud is by using an APN lock, which only allows a SIM to work in a device with the correct credentials. Even with a soldered MFF2 format embedded SIM, this is a crucial step to ensure security. Although embedded SIMS are inherently less likely to be removed, it is far from impossible, and the effort required to solder such a SIM into a new device may be worth it in the eyes of a thief.
Simplify Your System
Of course, all of this is focused on the IoT device and it’s connection. If the control interface for managing devices is compromised, then all bets are off. Any system’s security is limited by its weakest link. Keep your system as simple as possible. Compartmentalize individual pieces so intrusion in one part doesn’t compromise the entire system. The best way to start securing any IoT system is to follow general IT security best practices wherever practical. Beyond that, diving into the details will help minimize risk of a security failure.
This blog was written in partnership with ZARIOT, who offers secure connectivity globally for IoT and M2M devices, with signaling and IP security solutions for enterprises. ZARIOT brings the knowledge and expertise of over 15 years of experience and innovation in telecom security to IoT. For more information go to https://www.zariot.com/security
