ABOUT THE PROJECT
MFSSIA: Multi-Factor Self-Sovereign Identity Authentication
Central authorities are the prominent choice when two parties want to establish trust between each other. For example, web servers are using central authorities to establish a secure socket layer (SSL) connection with the browser. A significant flaw of central authorities is that, if the primary node is compromised, all of the nodes are rendered untrustworthy, because of the hierarchical structure.
Another alternative to central authorities is the Pretty Good Privacy (PGP) web of trust (WOT), where each user acts as an authority. Still, a lack of incentives for correctly identifying another user as trustworthy and missing punishments for malicious actions are the main reasons why the WOT is not considered reliable. Additionally, sybil nodes represent a threat to the WOT since there is no defence mechanism for identifying a group of users who maliciously identify each other as trustworthy.
Multi-factor authentication (MFA) is the concept that emerged in the 1980s. However, most of the customers did not consent to physically carrying another factor for authentication and thus, the market did not adopt it. After introducing smartphones that provide the possibility to send evidence of possession, inherence, knowledge, or context to another user, MFA is accessible for billions of people.
MFA is used as a safer way to establish trust relations in a network. Security-critical organizations similar to banks, authenticate customers using their knowledge, inherence, and possessions. Furthermore, contextual information such as the time, location, and device model can be considered as an additional factor of authentication. The more factors are used during authentication, the safer the process becomes.
In this project, another alternative to public key infrastructures called Authcoin, is further developed using customizable challenges and MFA. Blockchain technology is utilized for storing authentication-related data, and hence, transparency, trustworthiness, and immutability of data are achieved.
Motivation for the project:
The rise of the machine-to-everything (M2X) economy creates a very complex system landscape that can best be described as socio-technical. Thus, a single-factor, or not configurable multi-factor identity authentication is not suitable for connecting the humans, organizations and systems (e.g., IoT, self-aware machines, and so on) in a secured way to allow collaborations that are trusted.
Another aspect is that self-sovereign identification is important in a society where personal liberties and freedoms are ever more infringed upon and efforts are visible to assign social-credit score systems. Thus, Authcoin for self-sovereign multi-factor identity authentication on blockchains matches with the stated needs of the ONTOCHAIN documented objectives for such a service, i.e., Objective 2 about the ONTOCHAIN technological framework design.
More concretely, we are aware of the existing applications that lacks a self-sovereign and configurable identity-authentication system for humans and applications to enable a trusted market ecosystem. For example, Knowledge X is an ONTOCHAIN stack application that creates a marketplace for trusted data sharing that Authcoin can secure. Likewise, Authcoin can also be employed for securing the Reputable application for securing the trustworthy interaction between buyers and sellers on the ONTOCHAIN marketplace. The Authcoin identity authentication for the Reputable application may incorporate flexible challenge sets to support the reputation evaluation of marketplace counterparties. A similar trust-establishing integration of Authcoin is possible with the POC4Commerce app that goes further in that it employs a semantic search engine to enable commerce. Authcoin will be a complementary as a more flexible and research-publications based addition to the existing ONTOCHAIN stack applications of ID systems being ONTOSSIVAULT and HIBI.
The addressed need is one for flexibly adjustable multi-factor identity authentications of humans and machines for the emerging M2X economy. Currently existing identity authentication systems such as the Estonian ID card are not contextually configurable with respect to challenge sets and are not suitable for an M2X economy. Note also that it is clear for this proposal that we intend to implement the existing Authcoin protocol using Ethereum smart-contract blockchain technology and furthermore, we will specifically consider the iExec stack for ONTOCHAIN that is complementary to Ethereum for Cloud-based off-chain marketplace.
Generic use case description:
A possible running case (that should still be discussed and confirmed with the ONTOCHAIN team) could be about the health monitoring of elderly persons at home with smart devices, e.g., their blood pressure. We are aware that the M-Sec Santander running case in Santander focuses on this. Context is a smart home where sensors are in the bed, movement sensors are in the rooms. The elderly person possesses a smartphone. Another option is that a smart television with a camera may be used to monitor the elderly person who is also equipped with wearable devices that monitor various health data such as blood pressure. All the sensors from IoT devices, including the wearables, create personal health data (PHD) that can be combined with more static electronic health records (EHR) from hospital databases. The idea is to combine the more real-time PHD with the rather static and long-term EHR for high-quality health diagnosis that can either be useful for very diagnostic lifestyle-change recommendations, or also for emergency care use.
First, the base version of the Authcoin system as per these 2 publications:
- Leiding, Benjamin, and Alex Norta. "Mapping requirements specifications into a formalized blockchain-enabled authentication protocol for secured personal identity assurance." International Conference on Future Data and Security Engineering. Springer, Cham, 2017.
- Norta, Alex, Raimundas Matulevičius, and Benjamin Leiding. "Safeguarding a formalized blockchain-enabled identity-authentication protocol by applying security risk-oriented patterns." Computers & Security 86 (2019): 253-269.
Note that the system based on these publications will be implemented as a backend using primarily Ethereum smart-contract blockchain technology.
Second, a library of challenge sets that is dynamically configurable to serve the self-sovereign identity authentication of humans, organisations and machines.
Third, an app needs to be created that allows humans (also as representatives of organizations) to step with a smartphone through a multi challenge-set identity authentication process.
Fourth, to a limited extent, we also aim to lay the foundation for machine-oriented identity authentication. Still, we consider this fourth item mostly as future work.
How these functionalities can be integrated within the software ecosystem:
The evaluation feedback recommended that we should focus on ONTOSSIVAULT. However, our own preliminary paper-based preliminary investigations yielded several potential other integration options the must be further evaluated. For further details about the preliminary findings of the paper-based study, we refer interested readers back to the section above about the motivation for the project.
Gap being addressed:
The state of the art shows for a rising M2X economy the can informally be best characterised as a socio-technical collection of humans, organisations, machines and other software systems that are ever more also smart-contract blockchain realised. Thus, conventional identity authentication systems that are government dominated, they do not cater for such complex collaboration scenarios.
For example, the very accomplished Estonian identity-authentication card that has been instrumental for enabling the well known e-governance systems of the country, supports only 2 challenges. One simple 4 digit challenge is offered to allow humans to sign into e-governance systems. Second, a 5 digit number is on offer for digitally signing transactions, e.g., for signing documents, confirming payments, etc. While this Estonian system has been very essential for establishing the world renowned e-governance infrastructure, this is not sufficient for the next level of moving into a smart-city context that coincides essentially with the principles of the M2X economy.
Expected benefits achieved with the novel technology building blocks:
The use of smart-contract blockchain technology being part of the ONTOCHAIN stack as a target technology assures immutability and traceability of events that are captured with the Authcoin system. That way the benefit of the Authcoin system is to support the establishment of trust and security for cross-organizationally connecting humans, organizations and diverse sets of collaboration systems.
Second, since the cross-organizational collaboration scenarios change, configuration flexibility of the challenge sets for identity authentication are important. I.e., besides collaborations between humans and organisations can be set up and dissolved eventually, existing collaborations move through life cycles of modifications where new automation systems and devices are introduced, modified and eventually removed from cross-organizational collaborations. Thus, at each stage, the need may arise to change the challenge sets for such a flexible authentication of challenge sets for identity authentication.
Third, the aspect of self-sovereign identity authentication is important for identity authentication to avoid Orwellian scenarios that emerge easily when governments and other powerful actors such as oligopolistic corporations enforce identity authentication under their control as gatekeepers that also have the power to cancel other humans, organizations and systems. Thus, with the use of smart-contract blockchain technology that comprises public/private key capabilities, individuals have the ability to not be dependent on a dominant power gatekeeper entity such as a state government, or an oligopolistic corporation.
Potential demonstration scenario:
In case we can continue with the suggested elderly health monitoring with wearable devices, this would be the demonstration scenario. Note that such a running case has been developed as a deliverable for the project funded for 3 months by the NGI explorers project.
In several application contexts, it is possible to flexibly arrange a set of challenges that must be correctly answered to authenticate the identity of devices, systems, organisations, or individual persons. These challenges are available in a store to choose from, allegorically comparable to apps in an app-store. This way, many factors determine in a tailored way if humans, organisations, or systems/devices can be trusted for establishing a collaboration connection.
Possible future use case scenarios can be implemented on top of this project solution. What are these scenarios and how they work are explained in further details:
Scenario 1 - How it works for challenge creators. The following steps take place when a user uses the service:
An organisation and individual register to the challenge-set marketplace.
The challenge is created, and the application description added for search.
A crypto price is set for integrating a respective challenge into a set for use in challenge/response-lifecycles.
Notifications are sent to the creator for the use of respective challenges for identity authentication.
Cryptos enter the wallet of the challenge creator per challenge used for identity authentication.
Scenario 2 - How it works for challenge users. The following steps take place when a user uses the service:
An organisation and individual register to the challenge-set marketplace.
Challenges are chosen that serve the identity-authentication needs of the user.
If a challenge is missing, a request may be issued for the creation of a token of compensation.
The challenge set is brought to the blockchain to commence the identity authentication process.
A crypto budget is deposited for financing challenge/response-lifecycles.
Scenario 3 - How it works for response evaluators. The following steps take place when a user uses the service:
An organisation and individual member register to the oracle component of MFSSIA.
Specific oracles of the response evaluator are registered with MFSSIA.
The evaluation rate is defined in crypto tokens.
The oracles engage in the challenge/response-lifecycle evaluations.
The crypto wallet of the evaluator collects token compensation for the evaluation service.
Scenario 4 - How it works for security consultants. The following steps take place when a user uses the service:
The security consultant signs up with MFSSIA and submits the credentials stating to be able to offer security services.
The profiles of specific security-consulting offers are submitted to MFSSIA together with the rate for consulting.
Requests for security consulting are serviced.
Feedback is collected on the quality of security consulting to establish a reputation indicator.
The token payment for the security consulting is collected to the wallet of the security consultant.
Scenario 5 - How it works for MFSSIA users. The following steps take place when a user uses the service:
The user signs up with MFSSIA.
The challenges are chosen from the corresponding marketplace and arranged into a set for deployment.
The oracle services are decided for response evaluations.
A token budget is deposited into MFSSIA for funding challenge/response-lifecycle evaluations.
Gimly ID: MFSSIA DApp provides API interfaces where Gimly ID is able to connect to gain MFSSIA capabilities. The added value for ONTOCHAIN is that Gimly ID can then also run MFSSIA functions.
ORIGINTRAIL DKG: The synergy is that MFSSIA aims to use DKG instance files for fully automated challenge/response-lifecycle processing. The benefit for MFSSIA is that diverse semantic facts of the application context are captured and as such give essential flexibility to very diverse application scenarios to establish identity authentication.
iExec: it uses iiExec as a deployment infrastructure for our MFSSIA project, since that way we have a cloud environment available for the entire development process. The synergy for MFSS is in addition that also iExec is an oracle factory, which is essential for the evaluation of passing challenge/response-lifecycle processes.
PERUN-X: The synergy with MFSSIA exists in that gateways are relevant to create cross-blockchain connections.
ADOS: The very Interesting ADOS application case should be coverage for the IoT case with MFSSIA with the same approach of challenge/response-lifecycle management the same way as in this ongoing project for cross-blockchain connection green/red-lighting.
At the current stage of the project, they utilise the OriginTrail Decentralised Knowledge Graph (DKG) for capturing context semantics that the MFSSIA solution automatically analyses. The challenges are created as DKG instances and the responses too. With this consistent DKG use, there is a uniform format in use for the evaluation of responses to challenge sets pertaining to the MFSSIA application context.
Alex Norta is currently an associate professor at the Department of Software Science of TalTech.
Researcher, Blockchain Engineer, Data analyst.