Abstract

I want to build Identity Management System to facilitate the management of digital identities and operations such as authentication and authorization of a user’s identity. Recently, there have been initiatives introducing blockchain-based identity management tools that allow the taking back control of one's own identity by the user (i.e. self-sovereign identity). In this article I purpose a blockchain-based identity management system that uses attribute-based access control policies and privacy-preserving algorithms to authenticate and authorize individuals before handing back control of their identities. It includes mechanism to securely digitize documents issued by any governmental or other body, like passports, drivers licences, utility bills, etc.

My purposed system consist of a private blockchain, which would store re-certification events, data access requests, and user identity authorization requests in a safe, verifiable manner, protecting the data's integrity.

Introduction

Traditional systems are neither secure nor dependable, so identity providers or service providers take on the role of third-party operators that authenticate and authorise the user's identity in an identity management system. Password manager and single-sign-on provider, OneLogin was hacked, and all customers served by its US data center were affected. Equifax, one of the most significant credit bureaus in the USA, was the victim of a data breach. These digital identities are portable, but they lack security. The issues with current identity management systems affect many different businesses. Excessive bureaucracy is a cost of the lack of cooperation between government agencies and sectors. This, in turn, increases processes times and costs.

In the course of registration, user identifying data is kept in a central database (CD). User identifying information may leak if CD is hacked. Additionally, user identities and passwords are kept on CDs for authentication purposes, which makes them vulnerable. We seek to employ decentralized blockchain technology to verify and authorize users using privacy-preserving features and give ownership of a user's identity back to the user in order to address the problem in such situations.

The system architecture proposed in this article has four main components(Identity Management Architecture):

1. Authorities on a private blockchain working together could include credit reporting agencies, for example. An identity provider will be able to query and confirm the identity attributes via a querying API server (Communication Server) that is very strongly tied to the consortium. In addition to being a blockchain node, the communication server has several extra responsibilities, such as interacting with the outside world.

2. Identity provider (IDP): User authentication and permission are the topics of this module. Single-Sign-On feature would be implemented using the OpenID Connect Protocol (OIDC). In essence, it will serve as an OIDC provider.

3. Service provider (SP): A user might use virtually any third-party service under this heading. As OIDC reliant parties, they function.

4. User: Users can engage with IDPs using a variety of privacy-preserving personas, and in our proposed system, users are free to choose which persona they wish to use. This gives users more discretion over the aspect they want to employ.

Tools and Protocols

In contrast to permission-less blockchain systems like Bitcoin or Ethereum, which do not need an access control layer, a permissioned blockchain is not accessible to the general public and can only be accessed by those who have permissions. Next, we discuss OpenID Connect, an open and reliable authentication system that gives OAuth 2.0 an identity layer. OIDC clients can employ authorization server authentication to confirm an end user's identity.

Hyperledger Fabric

A distributed ledger platform that is open, tried, and business-ready is called Hyperledger Fabric. It is a permissioned ledger with sophisticated privacy controls, so only the information you choose to share is distributed to the "permitted" (known) network users. Instead of an open network of anonymous members, Fabric enables the establishment of decentralized trust. The parties with authority to read the transactions are the only ones who have access to the confidential transactions. Only those parties who have been given permission to read them are given access to the transactions, which are kept private. A ledger is a piece of information that exists within the purview of a channel and can be shared across all users of that channel. It can be also privatized to only include a limited number of participants. As a result, Fabric is an ideal option for a decentralized but trusted ledger that protects user privacy.

The transaction processing workflow is divided into three parts by the modular design of Hyperledger Fabric: smart contracts, also known as chaincode, which consist of the systems' distributed logic processing and agreement, transaction sequencing, and transaction validation and commitment.

This division has numerous benefits:

• Fewer verification and trust levels, which keeps the network and processing uncluttered.
• Increased network scaling capacity.
• Improved performance all around.

OpenID Connect Protocol

By extending and analyzing OAuth 2.0, OpenID Connect (OIDC), an open authentication protocol, adds an identity layer to it. Clients can utilize OIDC to employ authorization server authentication to confirm an end user's identity. A single framework that guarantees to safeguard APIs, mobile native apps, and browser apps in a single, unified architecture is produced by overlaying OIDC on top of OAuth 2.0.

For user authentication and identity attribute permission, our system would use OpenID Connect. OIDC enables service providers to get basic profile information about the end-user in an accessible and REST-like manner and to confirm the end-identification user's based on the authentication carried out by an identity provider. The data owners give the identity provider with the user's basic profile information. This data is then used to determine the trust ratings for the desired identity traits, and those results are returned along with the identity claims.

Hierarchical Deterministic Keys

The "Data Access Key" and "Data Authorization Key" are generated by the user using the broad concept described in BIP-32. The Data Authorization Key is linked to the identity provider, whereas the Data Access Key is linked to the data owners. We are able to keep the details of the data owners and the identity providers apart by using two distinct master keys, the Data Access Key and the Data Authorization Key. These two keys are generated by the user and kept secret and secure; if a private key were to be revealed, privacy would be compromised. Given a parent key and an index i a "Child Key Derivation Function" computes a child key. We can create new child keys by changing i.

The Data Access Key could be used to create child private keys for certain data sources "Data Owner Keys"). Then, either at the time the identity is created or afterwards, these data owner keys are registered with each data owner. Data owners have access to both the keys they currently possess and any future keys they may generate. The owners of the data can create additional keys, which can be used to link transactions concerning a person on the blockchain. Thus, some degree of privacy on the blockchain is guaranteed. The user would have access to all future keys that the data owner further derives because these data owner keys are derived from the Data Access Key. The "Identity Owner Keys" that we can create from the Data Authorization Key are numerous. These identity owner keys can be used to register with identity providers and then be used for the identity provider's authentication in the future.

This proposed system can handle the leakage of up to m private keys with a master public key size of O(m). The key derivation procedure of ECDSA was modified somewhat by "Das P" to increase the security of BIP-32. They proposed changing BIP-32's additive to multiplicative re-randomization in order to increase security without incurring additional costs. Based on their theorems and a conservative choice of parameters, they noticed that BIP-32 offers around 92 bits of security. The multiplicative version of ECDSA, on the other hand, offers 114 bits of security with an equally effective method. Therefore, for my proposed system, I advise adopting the multiplicative version rather than the additive version.

Key Generation Process for Data Access Key

Key Generation Process for Data Authorization Key

User interaction with identity provider(s)

User registration with identity provider We propose a multi-factor authentication system for our system design. Below figure details the user signup process with an identity provider. In order to sign up with the identity provider, the user selects a username, password, and the most recent identity provider key. In order to increase security, the user also registers with a TOTP-based [32] 2FA (Two-factor authentication) authenticator app.

User login with identity provider This section describes the user login process with the identity provider(s). Below figure can be used as a reference to understand this process. There are multiple steps in this phase:

1. User enters password and username. It advances to the TOTP-based 2FA screen after verification. The user is prompted to enter the information again if this fails.
2. The user confirms the 2FA code after confirming the login and password. The user is directed to the unsuccessful login state if the request is rejected; otherwise, we proceed to the next stage.
3. After the 2FA code has been validated, the user generates a login key using the identity provider key associated with their current identity provider key. By changing the index i in the hierarchical deterministic key creation procedure, the user creates a login key. The user gives the identity provider the login key together with the index i.
4. The user's identity provider key is in the possession of the identity provider. The user-provided input index i is used to retrieve it. The user authentication was successful if the generated key matches the login key that the identity provider received from the user as input.

User login with service provider The system uses OpenID Connect for federated authentication and authorization. All communication between the identity provider and the consortium of data owners is through the communication server of the consortium. Below figure can be used as a reference.

1. When attempting to log in to a service provider, a user can choose the identity provider. Every time a user tries to log in to a service utilising an IDP, they are forwarded to that IDP with the necessary claims.
2. The user logs into the IDP. The user has the option to choose which data owners they want to utilise to verify particular aspects of their identification. Based on the service they are attempting to access and the necessary attribute claims, the user can select pertinent data owners. A user can utilize their passport as the identification source if, for instance, they need their date of birth to obtain their social security number because it is a more reliable source of information. However, users can utilize their social media identities to obtain those attribute claims if a service, such as an email provider, requires a user's name. The user's choice of data owners will depend on the services they hope to use.
3. The user encrypts the data owner key and the data identity using their private IBCPRE key. They then provide the identity provider these encrypted papers. We must keep in mind that because these documents are encrypted, not even the identity provider will be able to access them at this time.
4. The user creates a re-encryption key by using the data owner's public key in order to re-encrypt the data owner key and identity. The data owners receive these encrypted objects, which they then decode using their IBCPRE secret keys and the list of necessary properties.
5. The data owner decrypts the objects, retrieves the identities kept on their systems using the data owner key they have been provided, and verifies the information on their system using the user-provided identity document. If these documents are identical, the data owner informs the identity provider that the attributes are true.
6. The data owner updates the blockchain with a new transaction containing the data access request. The requested attribute details, identity provider details, service provider details, and time information for the data access request are all contained in the blockchain transaction. Using the user's data owner key from the aforementioned transaction, the data owner creates a new blockchain transaction key for the user.
7. The user creates a re-encryption key for the identity provider after it has received the go-ahead from the data owners. The identity provider has the ability to decode previously saved documents. The documents delivered to the data owner are identical to those used by the identity provider because we are only creating re-encryption keys (IBCPRE) for the data owner and the identity provider.
8. The identity provider can determine a trust score for the necessary attributes using the decrypted documents. The claimed attribute values and the trust score for the corresponding attribute are returned to the service provider by the identity provider.
9. The user is given access to the service if the trust score is higher than the standard set by the service provider for a threshold. Else, they will have to choose a different data owner.

Conclusion and Future Work

Therefore, there is room for development. One of the first steps toward the development of a fully operational privacy-first federated identity management system is this study. The interface must abstract away the majority of interactions between the blockchain and identity providers in order for users to comprehend and make use of the system. There will therefore be a greater need for usability testing in the field. To determine whether this system architecture is practicable in the actual world, we also need to conduct some performance testing. Although there are cryptographic guarantees for the transaction's privacy when it is stored, there is always a chance of some data leakage (due to usage, frequent updates, etc.) that can worry policymakers. Further security testing would be necessary as a result.