Security by Design

IOTICSpace is a digital twin ecosystem infrastructure that enables data interactions, leading to 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 transmitting data from the producing endpoint to the consuming endpoint.

Reduce attack surface

Everything is virtualized

Everything 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 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 behaviour of another, but they must be able to verify the things they do and break the connection if they are not happy

Increase resilience and scalability

Everything is Decentralised

IOTICSpaces are a connected mesh of nodes forming a network. These networks are resilient to attack as enough redundant data is stored so 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 permission to join (Mitigating against stolen credentials).

All traffic in a network is encrypted by a symmetric key running on 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 the network

Make provenance verifiable

Identity is self-sovereign

IOTICSpace uses the W3C standard recommendation for the Decentralised Identities. This means that everything in IOTICSpace (a person, a twin, an application - or more correctly their agent) is identified in the same way and can be linked to decentralised, 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