Machine identity for IoT communications

An overview of machine-to-machine communication: traffic, identity, challenges, solutions.

Machine to machine (M2M) communications is all about direct inter-device communications, through which a robot/machine controls the other machines. M2M communications can be used to more efficiently monitor the condition of critical public infrastructure such as water treatment facilities or bridges, with less human intervention.

The technology itself includes wired and wireless connections, but I’m interested especially in the latter on account of its greater capacity for scalability. Wireless M2M communication also is called the Internet of Things (IoT).

Machines/Things are physical entities whose identity and state are being relayed to an Internet-connected IT infrastructure. We attach a sensor to the container, car or animal and it becomes part of the network that collects and analyzes data. These devices contain many or all of the same elements as computers: processor, memory, storage, inputs and outputs, OS, software. The key point is that they are increasingly cheap, plentiful and can communicate, either directly with the internet or with internet-connected devices.

M2M communication: architecture and types

Unlike human-type communications (HTC) where approval, validation, and authorization from humans are needed, machine-to-machine (М2M) communications refer to automated data communications among devices and the underlying data transport infrastructure. On the diagram below we see the general scheme of communication in the IoT network for a smart house use case.

The architecture of a smart home environment

With IoT networks spreading to more and more industries, it becomes critical that these systems work fast, exchange data in a secure and confidential way and are reliable. The basic principles of secure communication that should be followed for that are: authentication (I always need to know who I‘m talking to), availability (I must be able to communicate when I need to), confidentiality (nobody else shall get the message), integrity (the message must not be manipulated).

Here are the most common types of M2M communications that are used at the moment:

• Backend-to-Backend. This is about sending device logs over the internet to the cloud provider. It also works for schedulers, daemons, and continuous processes.
• IoT devices. This is about uniting data from small, autonomous, specialized devices at the server.
• CLI clients. This concerns the creation of CLI apps that have the necessary rights to perform the actions, but that is only available on certain computers such as their own, or in mainframes.

Cybersecurity measures for IoT devices

Traffic analysis is important for detection of DDoS attacks exploiting M2M vulnerabilities in case devices are broken into. There are clear differences between M2M and HTC traffic that helps to find the source of the attack and to solve the problem. There are important differences between machine-generated traffic and human-generated traffic, as discovered by researchers:

• The number of packages being transmitted is less than HTC traffic;
• An extended period of time between data transfer (long duty-cycle traffic patterns);
• Traffic patterns of a device with similar statistical characteristics;
• Domination of outgoing traffic;
• Periodic traffic and traffic dependent on events;
• Aggregated traffic (combined traffic from multiple sources specific to network nodes such as a gateway).

Current communication networks are not designed for M2M applications, especially since the behavior of M2M devices can be different from human users. The introduction of an M2M application to an existing system will cause significant overload as well as competition for the network resources with one another and with other users. To overcome this challenge the M2M traffic should be optimized, which will essentially take place within standardization.

But the principal threat from M2M communications isn’t its power to generate significant automated traffic, but the high probability of critical data losses. First of all, it is important to have the right security settings on the device. For security reasons, the device’s OS space should be divided for the kernel and applications and have separated privileges in the kernel, user mode and virtual machines to protect the rights of different apps.

Identity in IoT communications

To ensure secure communication, it is necessary that on the one hand, the sensors can be easily recognized by network gateways, and on the other hand, the gateway itself must be checked for authenticity. You can set the identity of the gateway device using an X.509 Digital Certificate. Any external entities connecting to the gateway will be able to verify the identity of the gateway which is now enabling HTTPs or NTLS protocols. It is important that with certificates, commands being issued to devices or sensors in the field are now coming from a trusted device.

Device identities also can be protected with device X.509 Digital Certificates. They can refer to the Initial Device Identifier (IDevID) if it was issued by an IoT manufacturer or to Locally Significant Device Identifiers (LDevIDs) by a network administrator. Each LDevID is bound to the device in a way that makes it infeasible for it to be forged or transferred to a device with a different IDevID without knowledge of the private key used to affect the cryptographic binding.

Alternatively, distributed PKI technology that provides a TLS/SSL security service can be used. Instead of a CA, it offers a blockchain network (or a network of trust as an alternative to the chain of trust). Using such an approach, a network administrator has the possibility to control all managed machine identities instead of confirming them through outdated hierarchical and sophisticated Public Key Infrastructure. Being dependent on centralized servers that store machine identities is inadequate for responding to modern communication speed requests.

A truly industry-accepted innovation in machine identity security is still on its way, and there is a need for the open source tech community to unite efforts around existing distributed technologies. There are numerous possibilities how to start, for example, check out our bounty challenge for integrating distributed PKI protocol for ensuring secure IoT communication in smart home systems.

Challenges with machine identities to resolve

IoT protection still isn’t secure enough to prevent attacks like the Mirai botnet. Companies are solving their M2M needs on their own in isolation from one other despite sharing similar architectures. In addition, the field of IoT is constantly changing and evolving when unknown devices, applications, and use cases are added every day. The need to interconnect heterogeneous M2M devices and applications that have never been connected before and extend that to the internet has introduced new levels of complexity.

The main limit to attaining best security practice implementation, however, is that IoT devices are small, inexpensive and use standard operating systems and protocols, which introduces similar, well-known weaknesses of centralized network solutions.