Cyronclad vs. MQTT
MQTT
Message Queuing Telemetry Transport (MQTT) is the standard messaging protocol widely used for building IoT infrastructures.
IoT infrastructures generate data traffic in a very different way than web applications, which makes classical web servers unsuitable for creating IoT applications.
Since the Web application traffic flow is mainly going from server to client, clients can be directed to less-loaded servers (load balance).
In IoT platforms, the reverse happens and although each device may individually send little data, they may all send data all together, saturating the capacity of the network and server.
This is why the MQTT protocol was created. Basically, it handles communication with a publish-subscribe messaging model by inserting a component called a broker into the flow between client and server that coordinates transmissions.
MQTT has worked very well for more than 20 years, however, today’s demands and threats to IoT infrastructures require innovative solutions.
Among the main problems with MQTT (standard) are the weakness in identifying data sources and the reliability of the server, which obviously becomes an ideal point of attack.
Cyronclad vs. Serverless MQTT
The serverless MQTT broker emerges as a trend-setting architectural innovation for 2023. The main advantage of this approach is a significant reduction in MQTT service deployment time. The second advantage is the ability to scale.
Cyronclad’s operating model achieves and exceeds serverless MQTT: remote devices conitnue to use the MQTT protocol to interact with a server, but the server is local. The server consists of a sw component that acts as a bridge between the MQTT protocol and the Cyronclad infrastructure. This component can be hosted on customer on premis systems, in the cloud, or on a Cyronclad GW IoT.
Cyronclad vs. MQTT Multi-tenancy
Multi-tenancy architecture is a vital aspect of a serverless MQTT broker because inevitably IoT devices from different users or tenants can connect to the same MQTT cluster at large scale.
Therefore, it is necessary to isolate tenants by avoiding mixing data from different users.
To realize this, each tenant is given a separate instance of the application, running on a server or virtual machine. However, this is not enough: it is also essential to ensure data isolation at the database level. These requisites elevate the risks, derived essentially from the possibility of committing errors, unintentional or induced.
Cyronclad natively provides scalability, data isolation and operational processes separation. In fact, each “actor” in the Cyronclad system (users, devices, logical entities) has a digital identity. Not only is the data signed by the publishers (or the IoT GW), but encrypted so that only the recipient, with its own private key, can decrypt it.
Since this process is performed at the two ends of the communication channel between publisher and subscriber, there are no limits to scalability or risk of breach.
Unified Namespace MQTT
The Unified Namespace is a solution architecture built on the MQTT broker for Industrial IoT and Industry 4.0. It provides a unified namespace for MQTT topics and a centralized repository for messages and structured data.
In traditional IIoT systems, OT and IT systems are generally separate and operate independently with their own data, protocols and tools. By adopting Unified Namespace, you can enable OT and IT systems to exchange data more efficiently and finally unify OT and IT in the IoT era.
Cyronclad natively supports integration between IT and OT as data transmitted by IoT devices are collected in Object Storage by committees (clusters) of independent nodes.
The data can then be accessed with classical IT tools (S3 REST API) and are provided with additional properties provided by the Cyronclad infrastructure:
- proof of inclusion: is a cryptographic signature, verifiable by each IOTA node, that the message stored in object storage was really sent from the device to the network at a given instant
- proof of conservation: is a signature produced by the nodes in the cluster that proves that the data is present and compliant on the individual nodes’ object storage, i.e., it is replicated to ensure reliable preservation that is immune to manipulation.
