SLIX: A P2P Certificate Exchange Protocol
Protocol description
In this article, we will discuss the technical aspect of SLIX Protocol. If you are interested to find out about which use-cases SLIX can apply to, please have a look at our previous article here.
The Edge Computing Network (ECN) as discussed here, introduces more security threats since it increases the real-world attack surface. Devices are out in the physical world with a very limited guard. At the Edge, it is crucial to be prepared for the situations in which a malicious actor is motivated to get physical access to your device. If so, they will not only compromise the information on the device but also access the device identity (private key). This enables the attacker to communicate with other devices on behalf of the compromised device and eventually gain access to a larger set of devices and information. This way, the overall security of the network is compromised.
On the other hand, sharing information is a crucial factor for the success of various IoT use-cases. It is not enough to only keep the data and devices safe in locked silos. There have to be ways to propagate data and to share resources with the right parties. However, currently, there are hardly any measures used to ensure that the information always stays in the right hands and the resources are not exchanged without the consent of the owner. This is an even bigger concern in multi-party scenarios since not all devices are owned by one party. Read more on this topic here: Wikipedia Botnet.
The access control models designed for web applications and cloud
computing mainly consists of different permissions to Read and Write. Such a model would never be satisfying in ECNs due to the higher complexity of the system and the applications they enable. This calls for fine-grained access control that addresses the questions such as who can access which devices for what reason at what time and how.
The Core Protocol
To exchange attributes related to a certain peer of the network, we demonstrate a P2P network with three main actors involved: Subject, Requester, and Prover.
In a common scenario, Requester asks for information from a Subject but requires to have a confirmation from the corresponding Prover. For example, an institute (Requester) wants to verify that a person or a device (Subject) works for or belongs to the claimed organization (Prover).
Based on the described interactions between three actors, the Requester receives an answer that is signed twice, therefore, it is ensured that both, Subject and Prover, have agreed to it. Worth mentioning, this protocol is built on trust in the Provers as the only source of truth.
Benefits of the Protocol
Considering all communications are signed and encrypted which stops any illegal listener to alter the exchanged data, or even screen it, peers of the network can benefit from this protocol, as summarized here:
- Queries will be answered with as little information revealed as possible.
- Subject and Prover have full control of whether a query should be answered or not – both have to agree.
- Subject and Prover keep control over information that is shared through the time.
- Requester can get answers that are verified by both Subject and Prover.
If you are interested to know more, you can take a look at the SLIX paper. In addition to that, we open-sourced the reference implementation of the protocols: https://github.com/slix-network/. We’re happy to assist you to become a contributor or support you to build your applications based on SLIX protocol.
DISCLAIMER: This post only reflects the author’s personal opinion, not any other organization’s. This is not official advice. The author is not responsible for any decisions that readers choose to make.
