IOTICS | Documentation

Welcome to the IOTICS Developer Hub

Security by Design

IOTICSpace is a digital twin ecosystem infrastructure that enables data interactions, leading into powerful event analytics. The secure flow of data has been a guiding principle since we first put pen to paper and key to code. We are proud of our “Security by Design” principles and this paper sets them out in detail.

Our platform forms an overlay network over an estate of established systems, allowing secure sharing of data inside and outside of an enterprise. We mainly deal with data in motion/in transit and static metadata. We enable adaptors to external persistent data stores as required, allowing the control and responsibility for security to remain n the hands of the owner of the sources, not IOTICS.

Connectors connect to any data source in or out of an enterprise, with the IOTICS platform securely transmiting data from the producing end point to the consuming end point.

Reduce attack surface

Everything is virtualized

Anything in IOTICSpace is virtual. Twins that produce data are virtual, Twins that consume data are virtual. Connectors that get data from external sources have a virtual counterpart. Applications that consume data and event analytics have a virtual counterpart. Intelligent twins that perform analytics on the event data also have a virtual counterpart.

Security implication
  1. Limits the attack surfaces to only virtual things, nothing real is exposed

Reduce attack vectors on the Twins

The twin is in control of of its own destiny

The Twin is in control of what data it shares and when it shares it. Twins have three kinds of interactions they can broker:

  1. Exchange metadata to describe a twin and its capabilities
  2. Follow feeds to receive data from a twin
  3. Attach to controls to send data to a twin

The owner of the twin can always set policies governing which other twins can see their metadata and are allowed to follow feeds or attach controls. These policies are evaluated before any connection is made between twins.

Security implication
  1. Limits the attack vectors to the brokered interactions, so interactions can be removed by the data owner if they wish
  2. Mitigates against denial of service attacks as the twin shares data, so is not subject to the GET of death
  3. One party cannot control the behavior of another, but they must be able to verify the things they do and to break the connection if they are not happy

Increase resilience and scalability

Everything is Decentralized

IOTICSpaces are a connected mesh of nodes forming a network. These networks are resilient to attack as enough redundant data is stored that other nodes can continue if one gets comprised.

Routing of messages between nodes is supported by a Distributed Hash Table(we use Kademlia). Networks can be interconnected using a gateway that enables requests for metadata or data to flow only in allowed directions.

The system traffic in each network is encrypted using that network’s shared key. Any node wanting to join the network must have the shared key to decrypt and understand this traffic and must also have the permission to join(Mitigating against stolen credentials).

All traffic in a network is encrypted by symmetric key running on a pluggable transport protocols (ipv4 / ipv6, tcp/udp/websocket, tls/quic).

Security implication
  1. Increases resilience as parts of the network can be removed without compromising the entire network
  2. Mitigates against denial of service attacks as DHTs are only attackable from the inside
  3. You need the shared key and permission to join to join the network

Make provenance verifiable

Identity is self-sovereign

IOTICSpace uses the W3C standard for Decentralized Identity Documents. This means that anything in IOTICSpace (a person, a twin, an application - or more correctly their agent) is identified in the same way and can be linked to decentralized, independent Identity Management Systems (IDMS). The DID carries the list of Public/Private keypairs for that identity. Identity can also be delegated, for example: from the owner of a twin to the twin to act on the owner’s behalf.

Security implication
  1. All data can be encrypted or signed (with Elliptic Curve Encryption) based on the keys in the DID document and can therefore be linked to the DID
  2. Authentication - JWT tokens are signed with the DID document’s keys to allow access to the APIs
  3. Accounting - any action taken in the system can be linked to the identity that performed it

Mitigate against stolen credentials

All interactions are temporary

All brokered interactions have a lifetime. When the lifetime expires, the connection has to be reformed, requiring new JWT tokens and reverification of identity, authentication and authorization.

Security implication
  1. Stolen tokens or intercepted messages would have a limited lifetime

Updated 4 months ago


Security by Design


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.