Building Secure Connected Devices - I

(Originally published here, please excuse misalignments, if any)

Recently I was researching for articles on Security and IoT, and I happened to notice that most of these focus more on fear-mongering, explaining in detail how a certain device, if hacked, could cause devastating problems. And then many articles advertise the use of certain security solution on the cloud or likewise. But very few attempt to explain the security context, at the IoT device level. So here is an attempt to break-down the problem and understand the most common security issues that could surface and the typical solutions for the same. Hopefully this helps you to develop more secure IoT products by design.

Why is IoT security a concern?

Connected devices are here to stay and they are entering our lives in ways like never before. These are no longer limited to the smart home electronic appliances. Today we have smart door locks and smart vacuum cleaners and even the US president wearing a fitness tracker. Security is a concern primarily because of the following:

• Connecting more physical things potentially increases the surface area of the attack vector. While previously the attack could be limited to your email account, or social network account, the attack could now come to your house.
• Newer interactions with these connected devices opens up completely new attack vectors.
• Strong constraints on cost and power of connected devices required a newer breed of hardware to address a lot of the IoT use cases. While embedded devices have been around for a long time, connecting them to the Internet opens them up to a range of attacks that weren’t possible on these devices before. It took a while for the hardware to catch up with the latest security standards for already identified attack vectors.
• As with the rapid increase in cloud/web-service developers, it takes time for newer set of enthusiasts, hobbyists and developers to get acquainted with the attack vectors and their solutions.

Device Interactions

Let us first try to look at the typical interactions that any such smart device will have with the outside world. Once all the interactions are known, we can identify potential attack vectors associated with each of these interactions and then come up with meaningful solutions to address these.

There are a wide variety of smart devices that are being built out there. Let’s look at Wi-Fi enabled devices that are typically deployed in smart homes. Consider this smart device (one the left) part of a smart home.

Most interactions with this device can be categorized into three types:

• Physical Access: The first is the physical interactions that the device owner has with her devices. For this interaction you have to be present in the house for operating the device.
• Local Network Access: The second is the access over the local Wi-Fi network. For this interaction you can be anywhere in the vicinity of the house in the Wi-Fi Access Points range.
• Remote Access: Finally, most Wi-Fi devices talk to some cloud services. It may be to facilitate remote access to the owner of the device, or to query other services (weather, electrical pricing etc.).

Most attackers would prefer to exploit the remote access model. This allows them to exploit millions of devices across the world without leaving your chair. So let’s look at that interaction first.

Remote Access

As a common pattern of remote access, most connected devices are currently assuming a network client persona, and communicating with a remote server over HTTP, MQTT or other such protocol. By not being a server themselves, for the remote access scenario, these devices avoid having to re-configure firewalls on home gateways to open up holes for the incoming accesses.

From the device to the cloud

Let’s look at the first part of the device interaction from the AP onward to the cloud (see figure below). There are multiple attacks possible targeting this communication, like,

• man-in-the-middle: snoop your thermostat data from your device to the cloud (Nest), or modify settings from the cloud to the device
• replay attacks: if the data is encrypted, replay the same encrypted packet of data that unlocks the door lock of the house
• DNS spoofing: divert the traffic of your connected toy to a malicious server
• device spoofing: create a malicious/fake camera, and make the cloud believe that the camera belongs to you, the owner, and that the video feed is genuine

But if you notice, most of these attacks are also applicable to an online banking transaction. The communication pattern is no different. Obviously, the right thing to do is to rely on the tried and tested standards that are used to protect our online banking transactions. This mechanism is Transport Layer Security (TLS). TLS works at the transport layer, so you can run any higher level protocol, HTTP, MQTT or others, on top of it.

Until recently, running a TLS stack on micro-controllers wasn’t a possibility, because of their low compute power and constrained memory.

The latest IoT micro-controller platforms, however, are powerful enough to run the TLS stack. Many low footprint TLS software implementations are also available that can run on these hardware platforms. The hardware and software capability being now available, there is no reason not to use TLS for this communication over any other home-grown security mechanism.

From the cloud to the app

Now let’s look at the communication from the cloud to the user’s app. This isn’t directly related IoT per-se, but mostly about following standard practices for secure web API design. These are the APIs that allow your smartphones or other devices, to interact with the cloud for querying or controlling the connected devices in your home.

The entire web API should be exposed over TLS. Additionally, you have to ensure that the user apps are appropriately authenticated with the cloud service, and then they have the proper authorization to access the thing that they are supposed to talk to. Thankfully, there are many IoT cloud platforms available that provide a higher-level abstraction that already takes care of most of these things.

Through the secure communication channel

The most common manner in which we get malware installed on our computers is by accessing sites/files that we aren’t supposed to access.

Connected devices must communicate with a limited set of known servers. And these servers should be under the control of trusted parties.

The other protection that helps is to have a read-only partition that runs the firmware image. Even if you have to make any changes, it should be first switch to a read-write mode, and then written to.

---

While the above is a short list of the most common attack vectors, there could be use case specific attack vectors based on interactions with other elements. These should be also considered and tackled. For example, say a door lock is unlocked if the phone reaches a certain location, can the phone be tricked using GPS spoofing?

Those are some of the common attack vectors and their solutions for the remote access scenario. In the next part, we will look at possible attack vectors for local network access and physical access.

Note: Thanks to Pixabay for the shield image in the title