Image
The IoT device
An important aspect of an IoT device is that the device is controlled remotely via the network. So besides that, IoT devices collect and provide data over the Internet just as they are configured and controlled over the Internet. There are many examples of IoT devices. These include home thermostats, tracking devices for cars or pets, electronic door locks, remote-controlled lighting, home automation, etc. Let's not forget about the devices for industrial control systems, such as remote sensors, controllers, PLCs, and even robots. Are these IoT devices? Well, if they are directly or indirectly connected to the Internet, you could consider these devices as part of the IoT realm. To understand the threats to IoT and IoT devices, let's start with the device itself. An IoT device is commonly built upon a microcontroller and has dedicated software (firmware) that provides application logic. The firmware is very specific and customized for each of those devices, which is why we sometimes refer to those devices as embedded appliances. We all know that within normal IT, a PC/server might be vulnerable. If it is, an attacker could exploit it to navigate deeper into the enterprise network and potentially steal data from it. With the embedded devices that do not have an OS and or file system, the likelihood that the code will be compromised is lower than with common computers carrying an OS that can have many known vulnerabilities. But if someone has physical access to an embedded device, then there is a possibility to flash the device with altered code. Nevertheless, you could say that an embedded device is better-protected than a common PC or server.Communication
As we stated above, an IoT device is a device that can communicate directly or indirectly with the Internet. The fact that an IoT device maintains communication over a public network is indeed a concern. You see, the most common way for controlling an IoT device and collecting data is using the pub-sub protocol (i.e. MQTT, AMQP, STOMP) against a message broker. The great advantage of a pub/sub protocol is that the IoT device is communicating to the broker to send data (publish a message with a particular topic) and to receive selective data (receiving a message by subscribing to particular topic). The communication is unidirectional to the broker. This makes it possible to put IoT devices behind firewalls and has the benefit of not requiring a fixed IP address. To control an IoT device, an application or other device can publish a message to the broker intended for a single or group of devices. Let’s explain this with a real-world example of a remote home thermostat.The thermostat is connected to a broker on the Internet and will communicate with a broker. As the owner of the house, you can control your thermostat with your mobile phone. Your thermostat is paired with your mobile phone by the ID of your thermostat. Using the app on your phone, you can read and set the temperature in your home via the broker. To set the temperature, the app publishes a message with the requested temperature to the broker. Your thermostat will receive this message as it is published specifically for your thermostat. The thermostat is publishing the actual temperature to the broker, and the app on your mobile phone will receive the temperature as it is subscribed for messages published from your thermostat.Now, imagine that I can pretend with my phone or any PC that I’m the one your thermostat should listen for and that I’m able to publish false data to the broker in a way that it looks that it comes from your thermostat. This is a relatively harmless threat, but what about the thousands of cars that have a device that can control them? More and more car manufacturers produce cars that are connected as soon as they leave the factory. And what about all the elevators that are connected? And smart TV’s and devices that control critical infrastructures? I think you get the picture here. If we look at the security of IoT, the first thing we need to look at is how communications are secured. You would at least expect that the communication is encrypted and use certificates for mutual authentication, as it is obvious that with unencrypted communications the device is vulnerable to a man-in-the-middle (MitM) attack. However, the reality is that many IoT devices are still lacking encryption and are using a username and password to communicate to a broker. Especially with small, low-power, low-memory microcontrollers. SSL or TLS is commonly not used because of the overhead of encryption, which includes the size of the required additional library and the CPU power required. Nowadays with fast and small TLS libraries and the lower costs of more powerful microcontrollers, it is unthinkable to not use encryption and certificate authentication. But the problem remains with all the devices in the field that are still not up-to-date. They probably will never be, as there are no means to update them easily.
