Recently, news about the huge risk associated with IoT devices has started to appear like mushrooms after the rain. That they are typically left to communicate by themselves over the internet is a fundamental cause for concern.

Is it necessary to worry? Is it possible to defend yourself? Is safety a matter for the manufacturer or does it also depend on customers' decisions? Are LowPower devices the same as other IoT devices from a security perspective? 

I definitely do not want to trivialize this topic and I am aware of how relatively easy it is to abuse ‘large’ devices that offer a considerable degree of autonomy in the field of communication. Recently, however, reports of vulnerabilities and dangers have also appeared for simpler devices optimized for low power consumption—LowPower IoT devices. The reality of the danger of these devices is completely different, but unfortunately it is not often perceived even by IT experts, and some proposals of the newly formed EU legislation—the Cyber ​​Resilience Act—contain requirements that completely neglect the basic functionality of LowPower IoT devices. 

It is of course appropriate to use the general security manual published by the EU Cybersecurity Agency (ENISA) in 2017 under the title "Baseline Security Recommendations for IoT". This document goes just over one hundred pages and is definitely worth a read. It contains principles that every serious device manufacturer should implement. 

Therefore, in order for LowPower IoT devices to really function for 5 years or more, it is necessary to optimize their communication and the way they acquire and process data. If we were to apply requirements for encryption or the use of robust certificates, for example, it would be very difficult for the necessary ‘computing power’ to enable low energy consumption and the required device lifetime. It is therefore necessary to choose other solutions from a wide range of options that ensure safety and do not affect the performance of the device. 

As an example, let's take the use of the Internet. 

For many IoT devices, the use of the Internet is not necessary at all. It would only be able to receive and send data via private lines. Of course, it is not the majority of them, but even the majority can only use the Internet in private tunnel mode, i.e. a connection that is very difficult to compromise by potential attackers. 

Probably the most durable part of the communication will be the connection between the device and the base station of the mobile operator. Due to the use of robust 5G network protocols—NB-IoT and LTE-M—breaking their secure communications is costly and inaccessible to most attackers. Other parts of the communication chain (data transfer to the mobile operator's backend and possible integration platform) are also secure thanks to the use of private tunnels. As experience from the past shows us, the servers themselves, which are in charge of data presentation, are a much easier target, even for primitive DDoS attacks. 

But what about the end devices themselves? 

If the device can communicate freely and send data via the Internet to the target server, then it is a relatively easy target for an attack. This situation occurs quite often if the services of so-called virtual operators are used. They usually offer universal M2M or IoT SIM cards with the possibility of using 2G/3G/4G as well as NB-IoT and LTE-M. At first glance it looks like a great advantage, but on closer inspection it is clear that such an approach brings many risks. 

Two of them are worth mentioning in particular. First of all, it is precisely enabling communication to any server. In devices that used, and use, older 2G/3G/4G standards, this form of communication is common. Thanks to the fact that it was not necessary to monitor energy consumption, it was possible to apply tools that ensured communication at the cost of higher consumption. But for LowPower applications, these tools are not effective. 

But how to solve such a situation? It is very simple if you use the private APN service for device communication. The devices then do not have the possibility to communicate to public servers, but only to the secure server. Large customers of mobile operators have such an option, or it is possible to use, for example, the Miotiq.com integration platform. 

The second risk is a breach of integrity of the transmitted messages. So let's look at the necessity of using cryptography in the IoT devices themselves. In most cases, data is sent in binary form. To decipher them, you need to know the key, which is known to the device manufacturer and its customers. However, the vast majority of attackers do not have such a key, and the data itself has no meaning for them. If we ignore the fact that most IoT devices send very simple data such as temperature, humidity, meter status, contact closure and the misuse of such data is minimal, even such minimalist data can be effectively encoded with a simple function directly in the firmware of the device. 

However, if the officials succumbed to the pressure of some lobbyists and introduced the need to use complex cryptography across the board even for LowPower devices, it would only mean an increase in their price and a reduction in battery life. This is completely against their original meaning. Send simple data as long as possible.

As in many other areas, it is good to use common sense in the field of ICT security. As a best practice, we recommend starting from ENISA's recommendations and implementing all the procedures and tools that make sense given the architecture of the entire solution, from devices to communication to data processing and presentation. Many risks can be mitigated by choosing an architecture that inherently makes it difficult for attackers to work, such as limiting the ability of devices to communicate only within a private APN.

Integration platforms, such as Miotiq.com, also allow you to choose a special communication channel for the purpose of changing device settings or updating firmware outside of your own sensor data. Again, it is thus possible to place serious obstacles in the way of attackers by regular changes in the encoding of transmitted messages.

Both of these measures significantly increase the security of data transmission and at the same time have no effect on limiting the time for which the device can send data.