Network-first IoT security
Requirements for a secure Internet of Things system.
With the Internet of Things (IoT) there is something new to learn every day, be it security, scaling, or communications between devices. And there are some pressing questions related to IoT to be answered: How are we going to secure communication for billions of connected devices? How can we ensure that attackers can’t take control of our devices, steal information, disrupt services, or take down entire networks of expensive, imperative devices?
A secure system is one that can protect itself from being attacked, but if for some reason that does happen, notify others about the compromise. Being both preventative and reactive to the hack is key. Every day we read reports on how connected devices are so easily hacked and data compromised. IoT needs to bring together the broader ecosystem of software, hardware, security, and network experts, to name a few. Take a smart lock manufacturer, for example. They might know how to communicate between a phone and the lock but they may know less about making that secure, or providing remote firmware upgrades. Partnering with leading security providers and network experts can help them scale their product and provide an all-around viable solution. This kind of integration becomes more necessary with the increasing amount of complexity associated with IoT applications.
Network-first IoT security
An IoT solution provides Internet connectivity to everyday objects, and makes them smarter. A secure IoT solution will have to do the same thing in a reliable manner, starting from securing the “things” and the messages going between them. This kind of end-to-end security solution seems like a daunting task initially, but when you break it up into device security and network security, you see the light at the end of the tunnel.
As more devices connect to the Internet, they are going to be opening ports, connecting to servers, and talking to other devices all over the world. What if we could provide security from within the network that these devices are connected to? What if the network could handle remote firmware updates, grant/revoke permissions for the devices, and can encrypt the messages going through it between devices? This seems like a solution that can scale irrespective of the number of devices connected to the network or the communication protocol used. With this network-first security strategy in mind, let’s figure out the best-practice design patterns for implementing a secure data stream network to enable bi-directional communication for the Internet of Things.
Going through the journey of a message from the time it is created in one device to reaching the end device through the network will give us a better idea of the security aspects to consider at each step.
The first step in sending a message is to open a port and send the message. Basic socket-level communication requires two devices to communicate by opening sockets. One device sends the data and another opens an inbound port, waiting for that data to arrive. The open port can prove harmful since the device can easily be sniffed out by hackers, information can be mishandled, or malware can be injected. What is required is an outbound port open to the network and the other device. This calls for bi-directional communication between the devices in a network. Using MQTT, HTTP 2.0, CoAP, and WebSockets allow for outbound connection from devices in order to facilitate real-time communication.
Now that the data has left the device, let’s talk about securing it. Information between devices can be anything from chat messages to sensor readings to sensitive medical information. Irrespective of what it is, we don’t want our messages to be easily readable by anyone.
In order to provide a fully secure system, it is necessary to secure the communication channel over the network and encrypt the data. Transport Layer Security (TLS) alone does not cut it, since it is a point-to-point (P2P) solution (1 hop). Data from devices will have to pass through several hops before it reaches the end point. AES – the Advanced Encryption Standard – is a specification for the encryption of electronic data. AES, in combination with TLS on the other hand, will secure the data right from when it is created until it reaches the destination device.
Sometimes there might be the need to do some analysis on data midstream, before it reaches the end device. In such a scenario, it makes sense to follow the example of the postal system. The contents of the letter (data to be sent) is inside the envelope (encrypted), and hence no one can see it. The address alone is visible to everyone (information to be analyzed midstream), so that we know where that mail has to go. Using this strategy, IoT manufacturers can easily ensure full end-to-end encryption for sensitive data while simultaneously allowing for clever design patterns that leverage “envelope” data for mid-stream processing and analysis.
Our phones, laptops and servers have enough computing power and memory to take full advantage of the security options from cryptography to encryption. This is definitely not the case for the microprocessors and chips being used for IoT. Given these power and memory constraints, manufacturers aren’t compelled to add security along with the firmware. But they are learning fast, and providing alternatives to the dilemma.
Chip manufacturers have begun including a crypto chip that implements various cryptographic functions like SHA (Secure Hash Algorithm), ECC (Elliptic Curve Cryptography), or AES. These chips provide security capabilities that offload key storage and algorithm execution from the microcontroller, significantly reducing system cost and complexity. The Hardware Crypto Engine on some devices accelerates applications that need cryptographic functions. By executing these functions in the hardware module, software overhead is reduced and actions such as encryption, decryption, and authentication can execute much more quickly. This also removes the need to develop an appropriate cryptographic code library for new applications.
Now that our message has left the device and is making its way to its destination, let’s talk about the network it is going through. Earlier I touched on the network doing all the heavy lifting of handling the security for the entire system. This network has to be smart enough to handle malicious nodes, keeping track of devices that are connected to it and managing their read/write permissions.
Say you have several devices in a field monitoring different parameters. One of the devices gets compromised and starts tampering with the data that’s being collected. The minute you detect this you can easily revoke read and write permissions for that device. This level of isolation and control can help prevent the entire system from getting hacked. In doing so, the network effectively serves as a traffic cop, both authorizing device access and controlling which devices can speak and listen on the network based on the tokens the network distributes.
When you have several devices connected to the Internet and talking to each other there is sometimes the need to monitor these devices from a remote location. Say you have multiple solar panels at various locations, or oil field sensors out in the field. These devices can send information at regular intervals, and the sudden absence of it can mean one of two things: Either someone tampered with it to route the information elsewhere, or it could be a broader problem like a power/network outage.
Whatever it is, the ability to constantly monitor your devices – whether it is millions of them and irrespective of where they are in real time – is of key importance. The end goal of most hackers is not to tamper with the device to get data from it, but to connect to the network that the device is part of. When malicious devices on-board into a network, using “presence” can help you detect any devices that join your network, as well as isolate it so it can’t send or receive messages. Having a network that will monitor all of this for you by sending that information on separate channels makes it even easier when scaling. Network outages can be easily identified and solved, and in the event of tampering, you can also isolate devices easily.
Plug and play
On-boarding the devices in a home/office environment is a big concern for consumers. Say you buy a security camera monitor that connects to the home Wi-Fi and lets you monitor your house remotely. The ideal situation is to open the device, have it connect to the home network, and start streaming content easily. But not everyone provides this: The user is expected to ensure that the firewall doesn’t block the connection, open ports to communicate with the rest of the world, and upgrade the firmware every few months manually. All this frustrates the end user who might not go through the trouble of upgrading, which makes him prone to attacks. There is not too much incentive nor the ability to upgrade the chip’s firmware remotely once they are shipped, and maintaining older products is not a priority for manufacturers.
In a nutshell
Back in the day, PC/device vendors did not provide software patches periodically, nor did the average user make the effort to upgrade the software. As people got more comfortable working with and using PCs, routers, and servers, security upgrades were prioritized and pushed out often. The same thing is happening with IoT and embedded devices, where security is still in its nascent stages. We needn’t have to reinvent the security wheel every time we add a new toaster or refrigerator to our IoT deployment. What we need is a flexible system that is powerful enough to shield the broad range of devices and communication gateways out there.
There needs to be a radical way of thinking about security, as adding it to existing systems the way you bandage up wounds won’t help. We need a solution well integrated with the rest of the system to be as foolproof as possible. By building smart security into your networks and devices from the beginning, you can simplify this process in a secure and highly scalable method by uniquely identifying each approved device.