Threat Modeling

Decentralized_Public_Key_Infrastructures_atop_Blockchain.pdf

Home >Information Systems homework help >Threat Modeling

AbstrAct The public key infrastructure (PKI) has been

widely adopted to create, manage, distribute, store and revoke digital certificates, which plays an important role in bootstrapping secure com- munications. A PKI system authenticates entities with the corresponding public keys and it lays the security foundation for public-key crypto- systems in public-key encryption and digital sig- natures. However, traditional PKI systems suffer from security breaches, such as single-point-of- failure and man-in-the-middle attacks due to the existence of a centralized certificate authority. In this article, we review the traditional central- ized PKI system as well as the subjected security concerns, and then we propose possible solu- tions to address these issues with the emerging blockchain technology. Two frameworks are pre- sented where blockchain is utilized as a public bulletin board or trusted majority. We implement the functions to evaluate the off-chain time costs and on-chain gas costs of the proposal, which demonstrate the feasibility and practicality of the proposal.

IntroductIon Secure key generation and key distribution are the fundamentals of a cryptographic system. For example, communications over the Internet are built on the top of the secure distribution of public keys and the confidentiality of the corre- sponding private keys. A common approach to securely generating and claiming key pairs is to employ a public key infrastructure (PKI). A PKI system is a collection of hardware, software, people, policies and procedures that achieves the generation, management, storage, distri- bution, and revocation of keys and certificates based on public-key cryptography. PKI systems can be applied to ascertain the identities of differ- ent authorities and authenticate an entity to the corresponding public key. It provides underlying security services for e-commerce, e-government, office automation, and so on, so that users who are unknown to one another or physically apart can communicate securely through the chain of trust. A PKI system provides fundamental secu- rity guarantees to many applications. However, the typical traditional PKI system relies on a cen- tral authority (CA) to create, store and revocate digital certificates. In this case, it might trigger a number of security issues. First, CA can easily

be the target of many attacks. For example, CA might suffer from network attacks, such as ARP spoofing, IP spoofing and DNS spoofing attacks, and moreover single-point-of-failure is another severe problem. Second, a malicious CA might cause unexpected disasters to the system since fraudulent certificate attacks happen frequently. In 2015, Google warned of fake digital certificate problems issued by intermediate CAs (https:// www.computerweekly.com/news/4500242932/ Google-warns-of-fake-digital-certificates). In 2017, hackers made use of fraudulent certificates to “rob” a major Brazilian bank. In 2019, Chronicle’s security researchers found that the Comodo CA issued the most digital certificates for malware on VirusTotal (https://www.securityweek.com/como- do-issued-most-certificates-signed-malware-virusto- tal). Thus, a decentralized PKI is urgently needed to helps solve these security issues.

reseArch chAllenges Blockchain is a revolutionary technology in decentralized systems, which is also supposed to solve the problems in traditional centralized PKI systems. However, the solutions of decentralized PKI systems based on blockchain are not straight- forward and the challenges are listed as follows.

Certificate Issue and Storage: Decentralized PKI systems require decentralized storage of the certificates. To store a huge number of certificates on a blockchain is unrealistic. Thus, to issue and store the certificates requires additional compo- nents in the system.

Efficient Certificate Search: Blockchain is a public database, where it can log every single operation in the system on the blockchain. It takes a long time to search certificates in the certificate lists or in the revocation lists. Thus, to realize an efficient search over the database based on the requirement is a challenge in a decentralized PKI.

Effective Certificate Revocation: Blockchain is an append-only public ledger, which does not inherently support deletion operations. However, certificate revocation is a basic requirement in PKI systems. Thus, how to build a blockchain-based PKI system with effective certificate revocation is a challenge.

In this article, we aim to address these security issues in traditional PKI systems. The contributions are three-fold: • We review the traditional PKI systems with

a centralized framework and point out its security issues.

Decentralized Public Key Infrastructures atop Blockchain Yannan Li, Yong Yu, Chunwei Lou, Nadra Guizani, and Lianhai Wang

ACCEPTED FROM OPEN CALL

Digital Object Identifier: 10.1109/MNET.011.2000085

Yannan Li is with the University of Wollongong; Yong Yu (corresponding author) is with Shaanxi Normal University; Chunwei Lou is with Southwestern University of Finance and Economics; Nadra Guizani is with Washington State University; Lianhai Wang is with Shandong Computer Science Center (National Supercomputer

Center in Jinan) and Qilu University of Technology (Shandong Academy of Science), China.

YU1_LAYOUT.indd 133YU1_LAYOUT.indd 133 11/19/20 3:56 PM11/19/20 3:56 PMAuthorized licensed use limited to: University of the Cumberlands. Downloaded on November 01,2022 at 15:51:28 UTC from IEEE Xplore. Restrictions apply.

IEEE Network • November/December 2020134

• We recap the existing solutions of block- chain-based PKI systems and propose poten- tial solutions to address the issues mentioned above based on blockchain.

• We implement the proposed solutions both on-chain and off -chain to show the feasibility and the practicality of the proposal. The rest of the article is organized as follows.

We review the related work in the following sec- tion and then provide some preliminaries. We describe several possible blockchain-based solu- tions. The implementation results are then pre- sented. Finally, we conclude the article.

relAted works Generally speaking, there are two types of PKI systems. The first one is a traditional CA-based PKI system, such as the X.509 system. The sec- ond category is decentralized systems without a CA, in which blockchain-based PKI is of great popularity.

trAdItIonAl PkI systems A traditional PKI system has the following mod- ules: a certificate authority (CA), a registration authority (RA), a central directory, a certificate revocation list (CRL), an online certificate status protocol (OCSP), and a lightweight directory access protocol (LDAP).

CA: CA is a trusted central party in the PKI system. It is responsible for distributing public keys and issuing certificates by digitally signing them with the CA’s secret key. The certificates are stored at the certifi cate repositories for future search and check. Normally, trust on CA is a chain-based/tree-based structure with multiple levels. From top to bottom, it includes Root CA, intermediate CA and signing CA. The Root CA is the dominant position, which can be self-certifi ed. The root CAs can also issue certifi cates for other sub-CAs. Intermediate CAs are the CAs that are neither on the top nor the leaf, and can issue only certifi cates for sub-CAs. Signing CAs are the CA at

the bottom of the tree hierarchy and are responsi- ble for issuing user certifi cates.

RA: RA is responsible for user registration. When a user requests a certificate, RA needs to validate the necessary information provided by the user. RA and CA can be the same entity in small PKI systems or an RA can be a sub-CA. CA can also delegate other trusted parties to be an RA in large PKI systems.

Central Directory: A central directory is a reli- able server where the issued certificates corre- sponding to the keys are stored.

OCSP: The OCSP is a protocol to get the latest status of a certifi cate. Users request the status of a certifi cate and the OCSP responds accordingly.

LDAP: LDAP is a protocol that creates fast access to the online storage repository of certifi - cates.

CRL: CRL is used to store all revoked certifi- cates signed by the CA. Besides checking the sig- nature of a certifi cate, a user also needs to search the OCSP and CRL to check the current status of a certifi cate for validation.

dIstrIbuted PkI wIthout A blockchAIn A centralized CA-based PKI system (Fig. 1) suf- fers drawbacks such as single-point-of-failure. Thus decentralized PKI systems were proposed, among which two well known examples are the log-based PKI and web of trust. The basic idea of a log-based PKI is to involve a public log server to record the certifi cate and detect CA’s misbehav- ior. The certifi cate transparency by Google [1] is the most famous implementation of a log-based PKI. Web of Trust (PGP) [2] is another decentral- ized approach, in which users can digitally sign others’ certifi cates to endorse the identity. These solutions can solve the aforementioned problems in a centralized PKI to some extent, but these sys- tems still have some flaws [3]. A log-based PKI ignores the data consistency in the log servers. Such equivocation is a critical problem, which may require central parties and therefore single- point-of-failure still exists. Web of Trust does not provide identity retention and is not friendly to new incoming members in the system because they must gain trust from the existing members.

blockchAIn-bAsed PkI Several PKI systems based on blockchain were proposed to eliminate the limitation of the central CA since blockchain can plant trust directly into a system and remove the trusted third party. Name- coin [4] provides the registration for domains with the cost of 0.01 Namecoin, which can include public keys as auxiliary information for authenti- cation [5]. Namecoin provides identity retention thanks to the consistency guarantees provided by blockchain-based cryptocurrencies, which means that a user cannot re-register a previously regis- tered identity. Certcoin [6, 7] was built on top of Namecoin, and took Namecoin blockchain as a public ledger. Certcoin is designed to allow users to register a public key pk for a correspond- ing identity id, which does not rely on any central parties. In the certcoin system, users claim id and pk in a register transaction and specify a signa- ture with the corresponding secret key, which can be verified by all miners. It also employs accu- mulators to enhance its efficiency in verification

FIGURE 1. Centralized PKI framework.

Users

Verifiers

Centralized storage

YU1_LAYOUT.indd 134YU1_LAYOUT.indd 134 11/19/20 3:56 PM11/19/20 3:56 PMAuthorized licensed use limited to: University of the Cumberlands. Downloaded on November 01,2022 at 15:51:28 UTC from IEEE Xplore. Restrictions apply.

IEEE Network • November/December 2020 135

and leverages distributed hash table to facilitate fast public key lookup, which supports update and revocation of a public key. Later, Axon [8, 9] modified Certcoin by proposing a block- chain-based PKI with privacy-awareness. It outper- forms in the situation where the PKI is required but linking between a public key and an identity is undesirable. In Axon’s proposal, they separat- ed identities with short-term public keys posted on the ledger. Once the identity is established, key updates are anonymous to protect users’ pri- vacy. In 2017, Chen et al. proposed Certchain [10], in which they put forward a decentralized public audit certificate management framework. At the data storage layer, they designed a new data structure called CertOper to express certif- icate operations to solve the mandatory travers- al problem, which is stored in the blockchain as a Merkle Hash Tree for traceability and efficient queries. The revoked certificates are stored in a dual counting bloom filter (DCBF) for future query. They also presented a new dependabili- ty-rank based consensus. For the components in the system, a bookkeeper is utilized to store the operations of a certificate and help clients validate certificates. When a user requests a certificate, CA checks the identity of the requested user and signs their certificate, then a transaction CertOper is generated and broadcasted to bookkeepers. Upon being posted on the blockchain, the hash of the certificate will be inserted into the CBF1. Similar operations are conducted for certificate updates. For certificate revocation, the hash of the certificate will be deleted from CBF1 and added to CBF2. Al-Bassam proposed SCPKI [11], an alternative PKI system based on a decentral- ized and transparent design using a web-of-trust model and a smart contract on the Ethereum blockchain, to make it easily possible for rogue certificates to be detected when they are pub- lished. In SCPKI, two components are involved, in which smart contracts are for the management of identities and attributes and clients are ale to search or filter attributes. An IPFS [12] is used to store attribute data off-chain. In 2018, Yakubov et al. [13] proposed a PKI management frame- work based on Ethereum, in which they extend X.509 [14] to be compatible with blockchain. In their proposal, each CA has a dedicated smart contract, which is generated by its parent CA by calling the create-contract function, to record the issue and revocation of users’ certificates.

PrelImInAry In this section, we review some basic knowledge of blockchain and give a brief description of smart contracts and Ethereum. Then we recall the back- ground of PKI systems and the existing block- chain-based PKI systems.

blockchAIn Blockchain [15, 16] is a chain of blocks that contain information s ecured by public-key cryptography. Users in the system are identi- fied with unique public keys and interact with blockchain using the corresponding private keys. Asymmetric cryptography supports the authen- tication, integrity and repudiation in the system. Each block contains a block header and a block body. A block body is composed of some data,

which depends on the type of blockchain. Bitcoin blockchain stores the details of each transaction, thus includes the pseudonyms of payers, payees, transaction amount and so on. A block header usually contains the hash of a previous block, the hash value of the transactions, a timestamp and a nonce. A hash function is a fingerprint of a block and is hard to find a collision. The hash of the previous block in the block header is the way to make them form a chain and more importantly, to resist modifications of the previous blocks. This makes it hard to tamper with blocks because the hash of this block will change, which means all subsequent hask blocks have to change as well. This is the reason why a blockchain is immutable. Once the block body is completed, it will be time- stamped to resist tampering or back-dating. Then a nonce is needed for a miner to make the hash of this block smaller than some specific value. This is the mechanism of mining in a blockchain sys- tem. The difficulty of mining is determined by a predefined value. The first miner who gets the proper nonce will benefit some reward as the incentive. They broadcast the block in the distrib- uted system, which can be publicly verified. In this article, the blockchain is leveraged as public logs and the trusted center to replace central parties in centralized protocols.

smArt contrActs The notion of smart contracts was proposed by Nick Szabo [17], who expected to use a distrib- uted ledger to store smart contracts. Smart con- tracts are the digital equivalent to contracts in real life. Specifically, smart contracts are actually a tiny computer program stored on blockchain that runs automatically when some specific con- ditions are met. Smart contracts can exchange money, property etc., in a direct and transparent way without trusted lawyers or notaries. Smart contracts have some inherent features such as being immutable and distributed. Immutability states that once a smart contract is created, it can never be changed, and it will execute automati- cally following the built-in codes. By distribution, it means that the output of a smart contract can be verified publicly in the system and achieve con- sensus. It is impossible for any single user to force a smart contract on-chain to release funds at their will before the requirements of this smart con- tract are met. Smart contracts have wide appli- cations, such as crowdfunding, processing claims in insurance, automatic payment for banks, and so on. Ethereum is the biggest platform designed to support smart contracts so far. Smart contracts can be programmed through specific languages; among the most applied is Solidity, which has a similar syntax to JavaScript.

ethereum Ethereum (https://github.com/ethereum/wiki/ wiki/White-Paper) is a public and permissionless blockchain with a built-in Turing-complete stack- based programming language to build decentral- ized applications. Smart contract codes are run on Ethereum Virtual Machine (EVM). In the Ethereum system, there are two types of accounts, external- ly owned accounts, controlled by public keys, and contract accounts, controlled by contract codes. Another difference between these two types of

YU1_LAYOUT.indd 135YU1_LAYOUT.indd 135 11/19/20 3:56 PM11/19/20 3:56 PMAuthorized licensed use limited to: University of the Cumberlands. Downloaded on November 01,2022 at 15:51:28 UTC from IEEE Xplore. Restrictions apply.

IEEE Network • November/December 2020136

accounts is that a contract account contains some codes. When the contract account acts as the recipient in a transaction, the codes within it are executed. To generate a smart contract, a peer can generate a transaction and pay to a special zero account, then a contract account will be generated with a new account address using the creator’s address together with some nonce. Ether is the digital currency of Ethereum to pay for the transaction fee and code running fee, which can exchange gas used for code execution to resist an infi nite loop. Ethereum has a smaller block size compared to the Bitcoin system, and the time for generating a block is shorter (about 14 seconds) than the Bitcoin block (about 10 minutes). Con- tracts can be encoded on any blockchain, but Ethereum is widely employed since it gives huge processing capability. While the Bitcoin block- chain is mainly used to track the ownership of dig- ital currency (bitcoins), the Ethereum blockchain focuses more on running programming code of any decentralized application.

PossIble solutIons In this section, we propose potential solutions for blockchain-based PKI to deal with the problems in traditional PKI systems. Blockchain can enhance traditional PKI systems in two aspects. First, block- chain acts as the public log to record certificate operations to support public and verifi able search. Second, blockchain can replace the trusted party CA to achieve a fully decentralized credential sys- tem. We claim that in both frameworks, a block- chain-based PKI enjoys merits over the traditional PKI at each stage of the PKI life cycle. We show possible solutions to each framework as follows.

blockchAIn-bAsed PkI wIth cA We first define the architecture for a block- chain-based PKI with CA and introduce the details of the main functions.

Framework: The details of the framework are shown in Fig. 2. The architecture is a three-lev-

el framework, including the decentralized stor- age layer, the blockchain layer and the layer with other entities. The decentralized storage is for stor- ing certificates for future integrity checking and searching. The nodes offering the storage space can receive the corresponding reward based on the space size provided and time period. The blockchain layer is a public ledger to record all the operations of the certificates. Various types of transactions are defi ned to distinguish diff erent kinds of operations. We need to note that in this layer, we only focus on the results published on blockchain and thus omit the mining pool, the incentive and consensus details, as these parts can be borrowed from the existing mainstream blockchain networks. The other entities include users (certifi cate requesters), verifi ers (observers) and a CA. The CA has the same responsibility as that in the centralized framework, which is to sign and issue certifi cates. All the entities interact with the blockchain rather than communicate with each other. Each request and response will be logged onto the blockchain for public audit and each entity in this system can access blockchain freely to validate all the transactions.

Functions: The aforementioned processes have fi ve main functions listed as follows.

Registration: As shown in Fig. 3, a CA in a blockchain network fi rst registers into the block- chain either with the signed certificates by its parent CA or is self-certified, in which it pub- lishes its public key in the network. The users who need digital certifi cates upload their identity information to the blockchain in a transaction txreg in a certifi cate request. The CA checks the registration information and issues certifi cates for legitimate users by signing the certificates with its private key. The first user to claim this iden- tity is issued with a valid certificate. Duplicate registration or registration with issued identities is regarded as an invalid request and would be discarded by the CA.

FIGURE 2. Decentralized PKI framework.

block Blockchain

block block block block block block

Decentralized storage Honest

Nodes Malicious

Nodes Rational

Nodes

IoT system P2P network

Data Outsoucing

Honest Nodes

Malicious Nodes

Rational Nodes

Tstore

Tchal

Tregist Tcancel

CCAA

Users

CA Verifiers

Users

Verifiers

Centralized storage

CCAA

P2P network

Blockchain

Cert Store

Honest Nodes

Malicious Nodes

Rational Nodes

block block block block block block block

Tstore

Tchal

h3 h4

blockblock block block block block block

Users Verifier

Self- certified

Prove

Authorized user set

Verify

Blacklist

FIGURE 3. Registration in two frameworks.

block 区区块块链链block block block block block block

分分布布式式

存存储储

Honest Nodes

Malicious Nodes

Rational Nodes

Tregist Tcancel

CCAA 用用

户户

证证书书

依依赖赖方方

用用

户户

证证书书

依依赖赖方方

中中心心化化

存存储储CCAA

Blockchain

block block block block block block block

Block Block Block Block

Blockchain

CCAA

Verify

Sign

Issue Register

Cert

info sign

WWhhiitteelliisstt BBllaacckklliisstt

UUsseerrss VVeerriiffiieerrss

Block Block Block Block

Blockchain

YU1_LAYOUT.indd 136YU1_LAYOUT.indd 136 11/19/20 3:56 PM11/19/20 3:56 PMAuthorized licensed use limited to: University of the Cumberlands. Downloaded on November 01,2022 at 15:51:28 UTC from IEEE Xplore. Restrictions apply.

IEEE Network • November/December 2020 137

Certificate Issue: The certificates can still inherit the X.509 framework, which is compatible with our system. All the basic information is the same, while the extension field needs to specify the network ID that the certifi cate is stored in and the corresponding link to easily locate the cer- tificate. After all the details are determined, the transaction is signed with the CA’s private key and posted on the blockchain.

Certifi cate Storage: The certifi cates are stored in a P2P network off-chain rather than a cen- tralized storage [18], which can be achieved by Swarm (https://swarm-guide.readthedocs.io/en/ latest/introduction.html) and decentralized stor- age, for example, IPFS (https://ipfs.io) and BitTor- rent (https://www.bittorrent.com). The framework can be the P2P storage with multiple replicas [19] to enhance the recovery probability. Each peer builds its index table for a fast response, as whoever responds first will get the reward once the data owner requests original data retrieval. The stored data can also be audited to check the integrity periodically or randomly by involving the decentralized provable data possession (DPDP) or decentralized proofs of retrievability (DPoR), which are the decentralized version of traditional PDP and PoR protocols. Regarding data privacy in data storage, the techniques in [20] can be bor- rowed.

Certifi cate Search: To search a certifi cate for a valid public key, a user submits a search request txser with some additional rewards embedded in the transaction and signs the transaction with the private key. A valid search request transaction will be validated by miners and broadcasted on the network. The users who store certifi cates synchro- nize the transaction and search the index table. If no results are returned, then abort. Otherwise, a transaction embedded with a link to the required certifi cate is returned. The reward is given to the fi rst user in the blockchain.

Certificate Revocation: Again, recall that blockchain does not support revocation or dele- tion operations in the system, as the append-only feature is an important trick to achieve the tam- per-proof property. Thus, to revoke a certifi cate, it is inevitable to take advantage of some new data structures. We introduce several useful tools here. The first one is a distributed hash table (DHT). A DHT is similar to a hash table with effi - cient lookup services. CA can maintain a global DHT, which supports effi cient update and search for the revoked certificates. Another effective solution is the bloom fi lter. A bloom fi lter (BF) is a type of data structure that stores the hash value of some elements and can easily find whether a specific element is in a given set or not with high probability. There are many new variants of the basic BF catering to diff erent demands, such as countable BF (CBF), spectrum BF (SBF) and dynamic BF (DBF), in which DBF is suitable for this scenario in the sense that it supports dynamic operations for the revocation list as well as the highly efficient search. We introduce a poten- tial approach to the revocation of a certificate as follows. The CA maintains an initially-empty revocation list with the DHT or DBF data struc- ture. Then, the user who would like to revoke the certificate needs to submit the request txrevok, which includes the identity, the public key, and

the user’s signature for authentication. CA then checks the validity of the transaction and revokes the corresponding certificate by updating the revocation list.

blockchAIn-bAsed PkI wIthout cA In this section, we go one step further to remove the central party and introduce a fully decentral- ized PKI system. We fi rst defi ne the architecture for blockchain-based PKI without a CA and intro- duce the details of the main functions.

Framework: The details of the framework are shown in Fig. 4. Compared to Fig. 2, there is no CA. A user is applying certifi cates from verifi ers. The user fi rst proves themselves with their identity information to register a credential. The verifi ers add the user into the legitimate user set (issue credential) after validating the proofs. The verifi - ers also maintain a blacklist to indicate all inval- id users. Then if a user wants to access services the verifi ers provide, the user needs to prove the membership of the legitimate credential set and the non-membership of the blacklist. The verifi ers check the proofs to determine whether the user is able to access the service.

Functions: We introduce the main functions listed below.

Registration: As shown in Fig. 3, a user uploads personal information to the blockchain and shows the attributes the user owns. Some advanced cryptographic techniques such as com- mitment and zero-knowledge proofs [21] are required when privacy needs to be presented. To be more specifi c, the user makes a commitment to the attributes and proves the attributes with zero-knowledge proofs. The proof shows that the commitments can be opened with correct attri- butes m and m satisfies the predicate y, that is, y(m) = 1, where y is the pre-defined policy. The user signs the transaction and puts the transaction on the blockchain.

Issue: The server checks the validity of the proofs embedded in the transactions. To gener- ate a certificate for a registered user, the server collects all the legitimate users from the block-

FIGURE 4. Decentralized PKI framework.

block Blockchainblock block block block block block

Decentralized storage

Honest Nodes

Malicious Nodes

Rational Nodes

IoT system P2P network

Data Outsoucing

Honest Nodes

Malicious Nodes

Rational Nodes

Tstore

Tchal

Tregist Tcancel

CCAAUsers

Verifiers

Users

Verifiers

Centralized storage

CCAA

P2P network

Blockchain

Cert Store

Honest Nodes

Malicious Nodes

Rational Nodes

block block block block block block block

Tstore

Tchal

h3 h4

blockblock block block block block block

Users Verifier

Self- certified

Prove

Authorized user set

Verify

Blacklist

YU1_LAYOUT.indd 137YU1_LAYOUT.indd 137 11/19/20 3:56 PM11/19/20 3:56 PMAuthorized licensed use limited to: University of the Cumberlands. Downloaded on November 01,2022 at 15:51:28 UTC from IEEE Xplore. Restrictions apply.

IEEE Network • November/December 2020138

chain in the system and generates a set of valid certificates. To enhance the efficiency, some techniques, such as accumulators or Merkle hash trees, are applied to accumulate the certifi cates to the valid certifi cates set.

Prove: The users can prove to the service pro- vider that they are legitimate users by showing valid certificates to the server directly. To pro- tect user privacy, the user can get the latest set of legitimate users from blockchain and gener- ate a membership proof of this set as well as a non-membership proof of this blacklist.

Verify: The service provider authenticates a user by validating the proofs they show. If the proofs are all valid, the user can access the corre- sponding service. Otherwise, the user is not eligi- ble for enjoying the service.

Revoke: If a user misbehaves with the resourc- es or services the server provided, the server is able to trace the user. The server maintains a blacklist to record the malicious users as per the previous activities. The revoked credential will be removed from the credential list and the corre- sponding users will be put into a blacklist.

ImPlementAtIon In this section, we evaluate the decentralized PKI based on blockchain by testing the time cost of off chain operations and the gas cost of the neces- sary on-chain operations for validation.

enVIronments The off-chain operations are written in the C++ programming language with the help of Miracl library in a VS 2010 compiler. The laptop con- ducting these programs uses the Windows 10 operating system (64-bit) and Intel® Core™i7- 8550U CPU @1.80 GHz. The RAM is 8 GB with 2 GB SSD. We leverage Raspberry Pi to simulate a thin client with restricted computational resources and storage. The Raspberry Pi is equipped with

Broadcom BCM2837B0, 1.4 GHz 64-bit quad- core ARM Cortex-A53 CPU and 1 GB LPDDR2 SDRAM. The operating system for the Raspber- ry Pi is Raspbian with kernel v4.14, which is the offi cial recommendation. The on-chain functions are implemented with smart contracts written in Solidity (v0.4.0) and debugged in Remix IDE (https://remix.ethereum.org/), which is an appli- cable online compiler. We evaluate the gas cost of the functions in a local private blockchain in a test network of Ethereum with a Geth console (https://github.com/ethereum/go-ethereum/ wiki/geth).

ImPlementAtIon results The implementation results are divided into two parts, the off-chain and on-chain part. For off- chain operations, we test three main functions including generating a pk, a zero-knowledge proof for a discrete logarithm [21] and a signa- ture [22] on a laptop and a raspberry Pi, respec- tively. To generate a pk, a random number is chosen as the private key and an exponentia- tion is conducted. To generate a zero-knowledge proof, some randomness, a hash operation and some exponentiations are required. The signa- ture is computed as indicated by the Sign algo- rithm. The implementation results are shown in Fig. 5. The time costs on a laptop are 1 ms, 2 ms, and 1.4 ms, respectively. It costs more time on a Raspberry Pi than that on a laptop, but it is still effi cient, since all the time consumptions are less than 15 ms.

As for on-chain operations, we test the gas costs for verifying a zero-knowledge proof [21] and verifying a signature [22]. This can be achieved in one smart contract with different functions. These two functions take the public parameters, the proof (resp. signature) generat- ed in the off chain phase as the input and output 0/1 to indicate the validity according to the ver- ification algorithm in the protocols. The results are shown in Table 1. The gas costs for these two functions are 156,005 and 2,199, respectively. The gas price is 0.02 Ether per million gas and the price of Ether is 176.50 USD (April 2020). Thus the USD costs are 0.55 and 0.0077 dollars for calling these two operations, respectively, which are acceptable.

conclusIons And future work PKI systems are the security foundation of pub- lic key cryptographic systems and at the same time defend the security of many online activ- ities, such as Internet communication, online shopping and so on. Decentralized PKI systems are helpful supplements to traditional cen- tralized PKI systems, which can eliminate the security issues of centralized PKI infrastructure and achieve all the properties of traditional PKI eff ectively. In this article, we reviewed tradition- al PKI frameworks and their security issues and proposed a decentralized infrastructure for a decentralized PKI. We also proposed several potential solutions for the certifi cate operations throughout the whole lifecycle of the digital certifi cates. The implementation shows the fea- sibility and practicality of the proposal by eval- uating the time cost and the gas cost for the dominant functions. Our future work is realizing

FIGURE 5. Time costs of the algorithms off chain.

1 2 1.5

generate pk generate ZPK generate signature

Laptop Raspberry Pi

TABLE 1. On-chain gas costs.

On-chain costs

Algorithms Gas cost USD costs

Verify ZPK 156,005 gas 0.55 USD

Verify signature 2,199 gas 0.0077 USD

YU1_LAYOUT.indd 138YU1_LAYOUT.indd 138 11/19/20 3:56 PM11/19/20 3:56 PMAuthorized licensed use limited to: University of the Cumberlands. Downloaded on November 01,2022 at 15:51:28 UTC from IEEE Xplore. Restrictions apply.

IEEE Network • November/December 2020 139

cross-domain authentication in decentralized PKI systems.

Acknowledgment This work was supported by the National Natu- ral Science Foundation of China (No. 61872229, No. U19B2021); the Key Research and Devel- opment Program of Shaanxi (Program No. 2020ZDLGY09-06); and the Basic Research Pro- gram of Qinghai Province (2020-ZJ-701).

references [1] B. Laurie, A. Langley, and E. Kasper, Certificate Transparency,

Tech. rep., 2013 [2] A. Abdul-Rahman, “The PGP Trust Model,” EDI-Forum: The J.

Electronic Commerce, vol. 10, 1997, pp. 27–31. [3] S. Matsumoto et al., “IKP: Turning a PKI Around with Block-

chains,” IACR Cryptology ePrint Archive, no. 1018, 2016. [4] A. Loibl and J. Naab, Namecoin, namecoin.info,2014. [5] Y. Yu et al., “Blockchain-Based Anonymous Authentication

with Selective Revocation for Smart Industrial Applications,” IEEE Trans. Industrial Informatics, vol. 16, no. 5, 2020, pp. 3290–3300.

[6] C. Fromknecht, D. Velicanu, and S. Yakoubov, “Certcoin: A Namecoin Based Decentralized Authentication System,” Massachusetts Inst. Technol. Tech. Rep, no. 6, 2014, pp. 46–56.

[7] C. Fromknecht, D. Velicanu, and S. Yakoubov, “A Decentral- ized Public Key Infrastructure with Identity Retention,” IACR Cryptology, ePrint Archive no. 803, 2014.

[8] L. Axon, “Privacy-Awareness in Blockchain-Based PKI,” 2015. [9] L. M. Axon and M. Goldsmith, “PB-PKI: A Privacy-Aware

Blockchain-Based PKI,” 2016. [10] J. Chen et al., “Certchain: Public and Efficient Certificate

Audit Based on Blockchain for TLS Connections,” Proc. IEEE INFOCOM 2018-IEEE Conf. Computer Commun., 2018, pp. 2060–68.

[11] M. Al-Bassam, “SCPKI: A Smart Contract-Based PKI and Identity System,” Proc. ACM Workshop on Blockchain, Cryp- tocurrencies and Contracts, 2017, pp. 35–40.

[12] J. Benet, “IPFS-Content Addressed, Versioned, P2P File Sys- tem,” arXiv preprint arXiv, 1407.3561, 2014.

[13] A. Yakubov et al., “A Blockchain-Based PKI Management Framework,” Proc. IEEE/IFIP Network Operations and Man- agement Symposium, Taipei, 2018, pp. 1–6.

[14] R. Housley et al., Internet x. 509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Tech. rep, 2002.

[15] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash Sys- tem,” 2008.

[16] Y. Yu et al., “Blockchain-Based Solutions to Security and Privacy Issues in the Internet of Things,” IEEE Wireless Com- mun., vol. 25, no. 6, 2018, pp. 12–18.

[17] N. Szabo, “Smart Contracts: Building Blocks for Digital Mar- kets,” EXTROPY: The J. Transhumanist Thought, 1996, pp. 16.

[18] Y. Li et al., “Fuzzy Identity-Based Data Integrity Auditing for Reliable Cloud Storage Systems,” IEEE Trans. Dependable and Secure Computing, vol. 16, no. 1, 2019, pp. 72–83.

[19] Y. Li et al., “IntegrityChain: Provable Data Possession for Decentralized Storage,” IEEE JSAC, vol. 38, no. 6, 2020, pp. 1205–17.

[20] M. S. Ali, K. Dolui and F. Antonelli “IoT Data Privacy via Blockchains and IPFS,” Proc. Seventh Int’l. Conf. Internet of Things, 2017, pp. 1–7.

[21] O. Goldreich et al., “Proofs that Yield Nothing but Their Validity and a Methodology of Cryptographic Protocol Design,” Proc. 27th Annual Symposium Foundations of Com- puter Science, 1986, pp. 174–87.

[22] D. Johnson, A. Menezes, and S. Vanstone. “The Elliptic Curve Digital Signature Algorithm (ECDSA),” Int’l. J. Informa- tion Security, vol. 1, no. 1, 2001, pp. 36–63.

bIogrAPhIes Yannan Li is currently a Ph.D. candidate at the University of Wollongong, Australia. Her research interests are blockchain and cloud security.

Yong Yu is currently a professor at Shaanxi Normal Universi- ty, China. His research interests are cryptography and cloud security.

Chunwei Lou received his Ph.D. degree from the University of Electronic Science and Technology of China. He is currently an associate researcher at Southwestern University of Finance and Economics. His main research interests are big data, data min- ing, multi-objective decision making and blockchain.

nadra guizani is currently a clinical assistant professor at Washington State University. She received her Ph.D. degree from Purdue University in 2020. Her research topic is block- chain security.

Lianhai wang is currently a research professor at Shandong Computer Science Center (National Supercomputer Center in Jinan) and School of Cyber Security, Qilu University of Tech- nology (Shandong Academy of Science), China. His current research interests are in the areas of information security, digital forensics and blockchain.

YU1_LAYOUT.indd 139YU1_LAYOUT.indd 139 11/19/20 3:56 PM11/19/20 3:56 PMAuthorized licensed use limited to: University of the Cumberlands. Downloaded on November 01,2022 at 15:51:28 UTC from IEEE Xplore. Restrictions apply.