Decentralized Public Key Infrastructure with Identity Management

using Hyperledger Fabric

Amisha Sinha and Debanjan Sadhya

ABV-Indian Institute of Information Technology and Management Gwalior, India

Keywords:

Public Key Infrastructure, Certiﬁcate Authority, Hyperledger Fabric, Decentralized Identiﬁer.

Abstract:

Public key infrastructure (PKI) is one of the most effective ways to protect conﬁdential electronic data on

the internet. In centralized PKIs, the identity is deﬁned by trusted third parties, speciﬁcally the Certiﬁcate

Authority (CA). However, the security of the end-users becomes jeopardized if the CA gets compromised.

To tackle this problem, the decentralized nature of the system can be used to eliminate a single point of

failure. However, the lack of real-time support, the block complexity, and strict implementation are drawbacks

that burden the practicality of these approaches. This study tries to evaluate the Decentralized Public Key

Infrastructure (DPKI) framework based on a permission-less model. The model itself is constructed over the

decentralized identiﬁer to manage the identity of users. We use the Hyperledger Fabric based blockchain

network to create a hierarchy Certiﬁcate Authority, where each CA is a peer in a decentralized distributed

network. Hence, each peer owns a separate database validated by the blockchain. We have evaluated the

model efﬁcacy in terms of the network latency and throughput, which were all found to be acceptable.

1 INTRODUCTION

Public Key Infrastructures (PKI) rely on digital sig-

nature technology to establish trust and security asso-

ciation parameters between entities. It allows entities

to interoperate with authentication proofs using stan-

dardized digital certiﬁcates. Even though many ap-

plications use PKI technology for their security foun-

dations, there are several concerns about their inher-

ent design assumptions based on its centralized trust

model. There have been instances where CAs have is-

sued rogue certiﬁcates, or the CAs have been hacked

to issue malicious certiﬁcates. Traditional PKIs also

encounter several versions of the Man-in-the-Middle

Attacks (Dacosta et al., 2012). Due to such issues,

there remains a requirement for forgery-proof identity

veriﬁcation techniques (Salman et al., 2019).

Unlike the traditional approach, Decentralized

Public Key Infrastructure (DPKI) ensures no single

third party can compromise the integrity and secu-

rity of the system as a whole. In blockchain-powered

DPKIs, the new third parties become miners or val-

idators (Isirova and Potii, 2018). The trust is estab-

lished and maintained based on the consensus pro-

tocols. The miners or validators follow the protocol

rules that would ﬁnancially reward and punish these

third parties, thereby preventing misbehavior in the

blockchain and limiting their roles effectively.

1.1 Contributions

This study aims to build a secure DPKI that im-

proves the existing infrastructures for user privacy

and identity management. Speciﬁcally, our frame-

work attempts to solve usability issues like identify-

ing malicious certiﬁcates. These certiﬁcates can be

consequently used to perform MITM attacks by re-

voking and blacklisting CAs so that no other domain

owner can request certiﬁcates from it. We utilize the

blockchain technology over the Hyperledger fabric to

build a web of trust model. This model allows any en-

tity on the network to verify attributes about any other

entity through a trusted network.

The proposed model guarantees security by con-

stantly validating intermediate signing CAs through

other peers. This process enables the certiﬁcates to be

produced in a legitimate and unaltered manner. Fur-

thermore, this framework provides a hierarchy Cer-

tiﬁcate Authority, in which each CA owns a sepa-

rate database validated by a decentralized-distributed

blockchain. The entities will have unique DIDs, at-

tach their public keys, and write them to the public

ledger. Any person or organization that can discover

these DIDs will be able to access the associated pub-

554

Sinha, A. and Sadhya, D.

Decentralized Public Key Infrastructure with Identity Management using Hyperledger Fabric.

DOI: 10.5220/0011273000003283

In Proceedings of the 19th International Conference on Security and Cryptography (SECRYPT 2022), pages 554-559

ISBN: 978-989-758-590-6; ISSN: 2184-7711

lic keys for veriﬁcation purposes. Hence, this work

provides an alternative to the conventional CA-based

identity veriﬁcation model. The efﬁciency of the so-

lution is measured by the variation in the latency of

requests due to the blockchain transaction ﬂow.

2 RELATED WORK

This section brieﬂy discusses solutions based on

DPKI for identity management. Noticeably, the need

for DPKIs and how it can address the usability and

security challenges that plague traditional PKIs has

been extensively reported.

The study by (Salman et al., 2019) compares the

existing DPKI approaches from different perspec-

tives. Even though these systems exist and are open-

source, the authors noted that only a few are utilized

in real-world applications. This study also gives in-

sights into the use of security services for current

applications and highlights the state-of-the-art mech-

anisms that currently provide these services. This

study is concluded by describing the associated chal-

lenges and discussing how the blockchain technology

can resolve them. A public and decentralized PKI

system termed SS-DPKI was proposed by (Chu et al.,

2020). This solution enables a user to utilize public

keys of multiple devices in a single ID.

A ChainPKI system was proposed by (Chiu et al.,

2021), which still had some issues. For instance, the

system uses an IP address as the ID for the relay nodes

(intermediates). Though a user can change their IP

address, it might still reveal some information relat-

ing to the user, like the geographic location. The sys-

tem developed by (Garba et al., 2021) records a set of

trusted CAs, each associated with a speciﬁc domain

in the blockchain. A limitation of blockchain-based

PKIs is storing a vast amount of data in the form of

certiﬁcates, as well as large handshake message sizes.

The listed works have played an important role

in developing meaningful solutions for replacing cen-

tralized PKIs. However, they do not claim satisfac-

tory results for identity maintenance. Although few

studies have reported promising results (Salman et al.,

2019), they are quite complex and costly to be in-

tegrated into industrial domains. In this regard, our

framework provides an efﬁcient DPKI solution based

on the Hyperledger fabric.

3 BACKGROUND

Now we detail some of the technological concepts re-

lated to our study. These preliminaries would facili-

tate in better understanding of our work.

3.1 Public Key Infrastructure

Centralized PKI relies on a trusted third party

called Certiﬁcate Authority in the current standard

X.509 (Burr et al., 1996). PKI uses a public and

private key combination to encrypt and decrypt data.

The X.509 certiﬁcate has a tree-like structure; it has

a root node and is connected with various branches.

The standard ﬁelds in X.509 certiﬁcates include the

version number, algorithmic information, validity pe-

riod, name of the CA and name of the subject to

whom the certiﬁcate is issued to.

3.2 Decentralized Public Key

Infrastructure

A decentralized Public-key Infrastructure is an ap-

proach that removes and separates the power of the

CA. DPKI is a protocol for securely accessing decen-

tralized consensus systems. DPKI changes the web’s

security model from single points of failure to de-

centralized consensus groups that create namespaces.

DPKIs can provide a way to manage attributes for the

web of trust. However, it does not specify what kind

of identiﬁers should be used. Alternatively, it accepts

different approaches that vary in terms of ease-of-use,

permanence, uniqueness, security, and other proper-

ties. There are four types of identiﬁers:

• Centralized: Controlled by single entity

• Federated: Controlled by multiple entity

• User-centric: Individual/administrative control

• Self-sovereign: Individual control

The Self Sovereign Identity (SSI)

movement uses

a blockchain to address several solution requirements.

The most basic one is for the secure and authentic ex-

change of keys, which was not possible using PKIs.

3.3 Decentralized Identiﬁers

Decentralized identiﬁers (DID) are used to globally

identify people and things over the internet. Previous

global unique identiﬁers mostly include UUIDs and

URNs. However, UUIDs are not globally resolvable

and URNs require a centralized registration authority.

Furthermore, none of these schemes is able to ver-

ify the ownership of the identiﬁer in a cryptographic

manner. In this regard, DIDs are the core component

https://decentralized-id.com/literature/

self-sovereign-identity/

Decentralized Public Key Infrastructure with Identity Management using Hyperledger Fabric

555

of an entirely new layer of decentralized digital iden-

tity. The format of DID is presented in Figure 1

Figure 1: The format of DID.

In Figure 1, DID Method is the namespace com-

ponent identiﬁer, and DID Method-Speciﬁc Identiﬁer

is the format of the method-speciﬁc identiﬁer. In

essence, DID is like a key-value database, where DID

is the key and DID-document is the value. Inter-

estingly, the DID document is a JSON-LD Data (a

JSON-based serialization for Linked Data). The ar-

chitecture of the DID is presented in Figure 2.

Figure 2: An overview of the DID architecture.

3.4 Blockchain

Blockchain is an emerging technology that demon-

strates increased safety and conﬁdentiality through

decentralized, distributed and immutable characteris-

tics. The blockchain is analogous to a digital ledger

that stores transaction data in a distributed and peer-

to-peer model. The data entered into the blockchain

network is arranged in the form of blocks (Yaga et al.,

2018). These blocks are immutable and hold the

timestamp and the cryptographic hash of the previous

block. This mechanism ensures a backward linkage

between successive blocks. The hash generated by

the cryptographic algorithm is foreordained. A slight

modiﬁcation in the data will change the hash values,

which helps to resist any changes in the blockchain.

Hence, this property allows having data in an open,

public and immutable storage.

https://www.w3.org/TR/did-core

4 PROPOSED MODEL

The design of the proposed system can be divided into

two parts. Initially, a DPKI framework based on a per-

mission oriented collaborative consortium model us-

ing the Hyperledger Fabric (Androulaki et al., 2018)

is developed. In this framework, all different DPKI

entities and chaincode functions are created. Once a

basic DPKI framework is setup, we integrate it with

DID. We have decided to use the Hyperledger Fabric

since it has a concept of channels and is open-source.

4.1 Chaincode Creation

The Hyperledger Fabric has a smart contract named

chaincode, in which we can deﬁne our rules and func-

tions for revocation and management of certiﬁcates.

The chaincode can be used to create custom permis-

sioned public or private blockchain. Chaincode ex-

tended attributes are constructed on the basis of the

current PKI system. Interestingly, different features

can be incorporated into different chaincodes as per

the requirement. The most signiﬁcant property re-

quired is the signature mechanism that is used for

signing certiﬁcates. Noticeably, it can be different

from the one used in transaction signing, nodes in the

cooperative CA and others.

It is possible to insert consensus protocols in the

Hyperledger Fabric (Vukolic, 2017). It also has a

novel architecture for transactions, executing order,

and validating. These functions are further explained

as follows:

• Execute: The endorser executes the transaction

and veriﬁes its correctness.

• Order: Ordering of transactions through the

pluggable consensus protocols.

• Validate: Validate transactions through endorse-

ment policies before committing them into the

ledger.

4.2 Identity Veriﬁcation Model

DIDs are only the base layer of the decentralized iden-

tity infrastructure. Veriﬁable Credentials is the next

higher layer where most of the value is unlocked.

DIDs can identify various entities in the Veriﬁable

Credentials ecosystem, such as issuers, holders, sub-

jects and veriﬁers. Figure 3 is a visual representation

of the identity credentials veriﬁcation ecosystem. The

functions of the various sub-modules are:

• Issuer: Issues veriﬁable credentials about a spe-

ciﬁc subject.

SECRYPT 2022 - 19th International Conference on Security and Cryptography

556

• Holder: Stores credentials on the behalf of a sub-

ject.

• Veriﬁer: Requests a proﬁle of the subject.

• Identiﬁer Registry: Issues identiﬁers for sub-

jects.

Figure 3: Flowchart of the identity veriﬁcation model.

For the implementation of the DPKI, the main

changes were made for the signing of DPKI content

in the Endorsement System Chaincode component.

Proxies act as the gateway between external clients

and the DPKI network. A REST API gets exposed

by the Proxy, which enables the clients in issuing and

managing the certiﬁcates. The function Cert() that

is used for creating the self signed Root certiﬁcate is

presented as follows.

Cert() {

var cert = forge.pki.createCertificate();

cert.publicKey = this.keys.publicKey;

cert.serialNumber = ’01’;

cert.validity.notBefore = new Date();

cert.validity.notAfter = new Date();

cert.validity.notAfter.setFullYear(cert.

validity.notBefore.getFullYear() + 1);

cert.setSubject([{

value: ’CA’

}, {

value: "CertificateAuthority"

}, {

shortName: ’C’,

value: ’UK’

}]);

cert.setIssuer([{

value: ’CA’

}, {

value: "CertificateAuthority"

}, {

shortName: ’C’,

value: ’UK’

}]);

cert.sign(this.keys.privateKey);

this.CA = {

privateKey: forge.pki.

privateKeyToPem(

this.keys.

privateKey

certificate:

forge.pki.

certificateToPem(cert)

};

return this.CA;

}

4.3 Certiﬁcate Veriﬁcation Model

In the developed system, it is possible to request sig-

natures from the endorsing peers (seen as a coopera-

tive CA) through a chaincode. A Certiﬁcate Signing

Request (CSR) or X.509-v3 certiﬁcate is given as the

input for this purpose. Figure 4 is a visual representa-

tion of this model.

Figure 4: The certiﬁcate veriﬁcation signature model.

5 EXPERIMENTAL RESULTS

This section presents a set of experimental evaluations

performed to support the developed framework. We

speciﬁcally evaluate the framework performance over

the latency and throughput of the network over var-

ious tasks. Noticeably, latency is deﬁned as the re-

sponse time per transaction, whereas throughput rep-

resents the number of successful transactions per sec-

ond (Kuzlu et al., 2019).

5.1 Evaluation Environment

We used a local server to run the Hyperledger Fabric

based blockchain network and Proxy. Each peer of

this network is a docker container, and we have an-

other dedicated container for its local ledger. There-

fore, two docker containers are allotted to each peer.

Furthermore, we have used a single proxy in the eval-

uations. In all assessments, four orderers were used

Decentralized Public Key Infrastructure with Identity Management using Hyperledger Fabric

557

in the Byzantine Fault Tolerance (BFT) ordering ser-

vice of the blockchain network (Sousa et al., 2018).

The requests were made through the Proxy REST API

with HTTP.

5.2 Performance Results

The primary aspect in all types of requests to the

DPKI is the variation in the latency of request re-

sponses. The ﬁrst test analyzes the latency of the

certiﬁcate issuing process in the DPKI solution. As

presented in Table 1, we can observe that the latency

suffers the most when we increase the number of

endorsers. The signature reconstruction process in-

creases the latency of certiﬁcate signatures. Since we

are working with a blockchain network that contains

complex processes, the latency observed in the ex-

ecuted evaluations was expected. We can attribute

these values while validating and committing trans-

action blocks in the Hyperledger Fabric transaction

ﬂow, mainly during ordering.

Table 1: Latency of the certiﬁcate issuing process in the

DPKI solution.

No.of Endorsers Latency (ms)

1 2440

2 2768

4 3489

Our second simulation investigates the latency in

the certiﬁcate revocation process. Table 2 shows the

results obtained with different numbers of endorser’s

peers while using the revocation process with a key

size of 4096 bits. We can see that the number of en-

dorser does not signiﬁcantly increase the total latency

of the requests. The latency in this case is caused due

to the proxy running the chaincode algorithm that ob-

tains the new Certiﬁcate revocation List (CRL) and

signatures of the endorsers.

Table 2: Latency of the certiﬁcate revocation process the in

DPKI solution.

No. of Endorsers Latency (ms)

1 2220

2 3129

4 3564

For comparing the issuing process with the tradi-

tional issuing of X.509 certiﬁcates, we ran a docker

container on the same machine where the blockchain

network and Proxy were running. We did a simple

conﬁguration that enables requests for certiﬁcate re-

vocation. In this regard, it should be noted that the

time to enroll an entity is not added since it happens

only in a centralized PKI. Table 3 demonstrates the re-

sults obtained while comparing our DPKI model with

the traditional EJBCA PKI

. These results are ex-

pected since our model’s characteristics and improve-

ments have a performance trade-off. The resulting

latency increases due to the ordering process, com-

munication steps between peers in transactions, and

others factors.

Table 3: Comparison of the latency in certiﬁcate issuing

process with traditional PKIs.

Model Name No. of Endorsers Latency (ms)

EJBCA PKI 1 348

DPKI 1 2462

DPKI 4 3188

Next, we investigate the impact of the blockchain

network throughput on the Hyperledger Fabric per-

formance. We have utilized the Hyperledger Caliper

Benchmark tool

for this purpose. Figure 5 shows the

impact of the number of participants in the network

on the network throughput for both Open Transac-

tions (where one read and one write transactions were

performed) and Query Transactions (where only one

read transaction was performed). The results demon-

strate that the query transactions have higher through-

put than the open transactions since there is only one

read operation in the query transaction.

Figure 5: Impact of the number of participants on the net-

work throughput.

Our ﬁnal simulation analyzes the size of the issued

certiﬁcates for different key sizes. Figure 6 presents

the corresponding results for the RSA 2048 bit and

RSA 4096 bit certiﬁcate signatures. Since we are

working with multi-signatures, the issued X.509-v3

certiﬁcates contain all the signatures in extensions.

Their size considerably increases due to this addi-

tional information. This entire process facilitates the

validation of the certiﬁcate and its signatures by other

entities.

https://doc.primekey.com/ejbca/

https//hyperledger.github.io/caliper/

SECRYPT 2022 - 19th International Conference on Security and Cryptography

558

Figure 6: Variation of the size of issued certiﬁcates with the

number of endorsers for different key sizes.

When the requests were made through the Proxy

REST API with HTTP, a Round Trip Time of 32ms

was noted with the dedicated server. In this scenario,

the local-host client was used to call the DPKI func-

tions in a local computer. In both the evaluations (i.e.,

latency comparison of certiﬁcate issuing and certiﬁ-

cate revocation process), functions write data to the

ledger of the blockchain. The currently stored CRL is

obtained and returned so that the endorsers can sign it

and insert their signatures in the response.

6 CONCLUSIONS AND FUTURE

WORKS

The objective of this work is to provide an effective,

robust and reliable user identity management PKI

using a decentralized approach. This study merges

the concepts of blockchain and decentralized storage

structure with the ability of PKI to generate a certiﬁ-

cate. Each of the peers on the network uses a unique

intermediate certiﬁcate authority and validator. Any

peer who joins the network will become an intermedi-

ate signing CA. The guarantee that the produced cer-

tiﬁcates are legitimate and unaltered is constantly val-

idated by other peers in the network.

We can optimize the current implementation of

our model to enhance its functioning. Speciﬁcally,

we would emphasize on using a blockchain frame-

work that uses DID and DPKI internally. In our

current model, the certiﬁcates used in transactions

are still generated by a utility function of the Hyper-

ledger Fabric. Another possible improvement is to

use the same generated key-pairs and certiﬁcates for

both DPKI signatures and transaction signatures.

REFERENCES

Androulaki, E., Barger, A., Bortnikov, V., Cachin, C.,

Christidis, K., De Caro, A., Enyeart, D., Ferris,

C., Laventman, G., Manevich, Y., Muralidharan, S.,

Murthy, C., Nguyen, B., Sethi, M., Singh, G., Smith,

K., Sorniotti, A., Stathakopoulou, C., Vukolic, M.,

Cocco, S. W., and Yellick, J. (2018). Hyperledger fab-

ric: A distributed operating system for permissioned

blockchains. In Proceedings of the Thirteenth EuroSys

Conference, EuroSys ’18, New York, NY, USA. Asso-

ciation for Computing Machinery.

Burr, W. E., Nazario, N. A., and Polk, W. T. (1996). A

proposed federal pki using x. 509 v3 certiﬁcates. NIST

Gaithersburg.

Chiu, W.-Y., Meng, W., and Jensen, C. D. (2021). Chainpki-

towards ethash-based decentralized pki with privacy

enhancement. In 2021 IEEE Conference on Depend-

able and Secure Computing (DSC), pages 1–8. IEEE.

Chu, Y., Kim, J. M., Lee, Y., Shim, S., and Huh, J. (2020).

Ss-dpki: Self-signed certiﬁcate based decentralized

public key infrastructure for secure communication.

In 2020 IEEE International Conference on Consumer

Electronics (ICCE), pages 1–6.

Dacosta, I., Ahamad, M., and Traynor, P. (2012). Trust no

one else: Detecting mitm attacks against ssl/tls with-

out third-parties. In European symposium on research

in computer security, pages 199–216. Springer.

Garba, A., Chen, Z., Guan, Z., and Srivastava, G. (2021).

Lightledger: A novel blockchain-based domain cer-

tiﬁcate authentication and validation scheme. IEEE

Transactions on Network Science and Engineering.

Isirova, K. and Potii, O. (2018). Decentralized public key

infrastructure development principles. In 2018 IEEE

9th International Conference on Dependable Systems,

Services and Technologies (DESSERT), pages 305–

310.

Kuzlu, M., Pipattanasomporn, M., Gurses, L., and Rahman,

S. (2019). Performance analysis of a hyperledger fab-

ric blockchain framework: Throughput, latency and

scalability. In 2019 IEEE International Conference

on Blockchain (Blockchain), pages 536–540.

Salman, T., Zolanvari, M., Erbad, A., Jain, R., and Samaka,

M. (2019). Security services using blockchains: A

state of the art survey. IEEE Communications Surveys

Tutorials, 21(1):858–880.

Sousa, J., Bessani, A., and Vukolic, M. (2018). A byzan-

tine fault-tolerant ordering service for the hyperledger

fabric blockchain platform. In 2018 48th Annual

IEEE/IFIP International Conference on Dependable

Systems and Networks (DSN), pages 51–58.

Vukolic, M. (2017). Rethinking permissioned blockchains.

In Proceedings of the ACM Workshop on Blockchain,

Cryptocurrencies and Contracts, BCC ’17, page 3–7,

New York, NY, USA. Association for Computing Ma-

chinery.

Yaga, D., Mell, P., Roby, N., and Scarfone, K. (2018).

Blockchain technology overview.

Decentralized Public Key Infrastructure with Identity Management using Hyperledger Fabric

559