Cyronclad Service
Goal: IoT infrastructure security
Cyronclad was created with the aim of making IoT infrastructures more secure. Currently, there are only two options for managing a fleet of connected devices: relying on a cloud-based platform managed by a service provider or activating a platform with similar functionality by yourself. The first option is inherently insecure. Although measures are taken to protect critical information that would allow data and device security breaches, the platform operator has complete visibility and control. For instance, he can suspend the service at any time. The second option therefore seems better suited to support mission critical applications or, in general, should provide greater visibility of the operational status of all components, thus ensuring greater security. Unfortunately, this is not true, because a greater possibility of control requires a greater operational effort, which inevitably introduces risks of errors, higher costs, and therefore it is impossible to obtain a guarantee that all system components are in a perfect state of operation, and therefore inviolable. Cyronclad introduces to the market, for the first time, a third option that raises the overall reliability level of the IoT infrastructure with marginal economic and organisational impact.
From decentralization, solutions to increase the security of the IoT Infrastructure
Decentralized systems are immune to attacks aimed at modifying data and blocking the devices (nodes) that support them.
Cyronclad uses the same approach and makes use of the following technology components:
- In Cyronclad, communication between entities is direct (peer-to-peer), i.e. without the need for any kind of explicit intermediation by third parties.
- In Cyronclad there are three categories of subjects: o Devices o Users (both human and logical) o Systems (both physical and logical).
- Each subject has a cryptographic identity (i.e. based on asymmetric keys).
- Each subject can receive and send messages that may contain data, service information or commands.
- Each message always has a sender, a signature that can be verified by the identity of the sender and a recipient.
- If necessary, messages can be encrypted so that only the recipient can decrypt them.
Reliable and persistent transport layer
The Internet is based on the TCP/IP protocol, which, similarly to what has just been described, allows direct messages to be sent between two network addresses. However, the nodes of the Internet network do not store the data they receive and transmit, so if a message is lost along the way, the recipient must ask for re-transmission. This implies that communication between the end points of the Internet network can only take place if they are simultaneously connected and able to handle the overall traffic.
This condition is rather complex to achieve and guarantee, which is why higher-level protocols, such as Message Queue Telemetry Transport (MQTT), have been designed that implement an intermediate communication system.
MQTT allows the receiver of messages from multiple sources to limit incoming traffic by deciding to receive messages from only a few transmitters at a time. This system is very efficient, but is obviously based on an intermediate communication model not present at the lower level (TCP/IP).
Therefore, while simplifying the role and reducing the operating costs of the message receiver, a critical point is introduced. To achieve the same result as MQTT and similar protocols, Cyronclad uses the IOTA distributed network as a ‘Secure Transport Layer’. A Secure Transport Layer performs the same functions as TCP/IP, but with some additional properties:
– messages are replicated on all nodes in the network
– messages are persistent (at least for a certain period of time) on all nodes in the network
– Messages are immutable because they are protected by the cryptographic structure of the register.
These additional properties mean that the sender does not have to synchronise with either the receiver or an intermediary-broker. Any node in the network is an alternative and equivalent entry point.
The same applies to the receiver, who can receive messages intended for him at any time by connecting to any of the nodes in the network.
The positive effects of this approach are many
– Total asynchronicity of the communication process between transmitter and receiver
– Absolute guarantee that the receiver will be able to receive the messages addressed to him
– Absolute guarantee that the messages are completely intact.
These results are achieved thanks to the unique characteristics of the IOTA network, which guarantees the almost instantaneous sending of data due to the absence of ‘mining’. Just as with TCP/IP, there is no charge for traffic and therefore the use of the IOTA network to send data is completely free.
Security beyond VPN
The use of IOTA as a transport layer provides even greater security for those who publish data or control remote systems via Cyronclad. Indeed, it is not possible to trace an individual message back to the IP address of the transmitter.
This feature makes a Cyronclad infrastructure virtually immune to attacks via the Intenet, so there is absolutely no need to isolate transmitters and receivers via VPNs, MPLS networks or similar tencological solutions. If desired, the devices can be connected directly to the Internet via a mobile 3/4/5 G connection.
Furthermore, the security of the system is extended to the protection of the receivers: in a cloud-based system, access to data is inevitably mediated by a direct connection between the platform itself and the system that is to receive the data. Although the connection is certainly protected by encryption protocols (TLS), the cloud platform inevitably obtains information about the receiver, information that can be used for malicious purposes.
Using Cyronclad’s IOTA network functions, the receiver can be totally isolated and ‘invisible’. In fact, to send or receive a message, it is sufficient to activate an IOTA node on a DMZ of the receiver’s network. This node, completely indistinguishable from thousands of others, will receive all IOTA network traffic and allow the receiver to obtain the data of its interest with a secure connection on its own DMZ network, i.e. without having to access the Internet.
Distributed storage
Using IOTA solves any security problems and simplifies the overall architecture of any IoT infrastructure. However, IOTA cannot contain infinite data. This means that any message sent to the network will sooner or later be deleted by all nodes. Clearly, the recipient can store the received data on any storage medium, but will it be safe? Indeed, it does not make much sense to make the receiving system super resilient and then store the data without worrying about its fate. For some use cases, this aspect is very critical. For example, the data collected could be used for forensic purposes, or it has an intrinsic value that requires absolute protection from the risk of loss, the risk of copying, or the risk of tampering. Cyronclad offers a secure storage service because it is based on a replicated storage architecture, based on a committee of dOra nodes. For data to be stored reliably, there are two options:
– the sender sends an identical copy of the message to both the recipient and the committee
– the recipient tells the committee the address of a message on the IOTA network that is to be stored.
In both cases, the committee nodes independently acquire the message and store it in their object store. The number of replicas coincides with the number of committee nodes. When a party with the correct credentials wants its data back, it will send a command from the committee. The nodes will co-ordinate to publish the data on the IOTA network (or other destinations) with the addition of two additional properties:
- Proof of inclusion of the original message in the IOTA DLT.
- Proof of preservation by the dOra committee.
Proof of inclusion is a signature produced by an IOTA node, based on the structure of the DLT at the time the original message was included. Any IOTA node can confirm the validity of the signature and thus confirm that the message is identical to the one entered into the IOTA network Proof of Preservation is a signature produced by dOra nodes at the time of message republication. Only if at least the majority of nodes have preserved the same data can a valid signature be produced. The validity of the signature can be verified with the identity of the committee.
Root of trust
What has been described so far highlights the extraordinary progress of the Cyronclad infrastructure in terms of security and resilience to Internet attacks on platforms and data receivers. However, the risk of individual devices being compromised still exists. To create a total security umbrella, Cyronclad provides two additional components:
- A development device with which a physical barrier between IoT devices and the Internet can be designed (or eventually replaced).
- A distributed supervision system for IoT devices
The device is based on an STM32 U5 SoC, a special version of the well-known microcontroller that has the ability to manage data and processes in a protected area of its internal architecture. Equipped with high levels of security certification, this chip allows the device to create and manage its own cryptographic identity, which is inviolable. This allows it to create the ‘root of trust’ for data produced by the device or received from others and sent by it over the IOTA network. It is essentially impossible to breach the device and force it to publish incorrect data. The second component is a service provided by a dOra committee. This service consists of validating certain information published by devices, such as the hash of their configuration. By comparing the information received with the information provided by the owner of the device, a committee of dOra nodes verifies that the device functions as expected. If the verification is successful, the committee publishes a message containing a datum that lets any recipient know that the datum is valid. The service is provided for both STM32 U5-based devices and generic devices, whose physical inviolability is, however, not guaranteed.
