Revisiting Privacy-aware Blockchain Public Key Infrastructure

Paul Plessing

and Olamide Omolola

Institute of Applied Information Processing and Communication, Technische Universitaet Graz, Austria

Keywords:

Blockchain, Public Key Infrastructure, Privacy, RSA.

Abstract:

Privacy-aware Blockchain Public Key Infrastructure (PB-PKI) is a recent proposal by Louise Axon (2017)

to create a privacy-preserving Public Key Infrastructure on the Blockchain. However, PB-PKI suffers from

operational problems. We found that the most important change, i.e., the key update process proposed in PB-

PKI for privacy is broken. Other issues include authenticating a user during key update and ensuring proper key

revocation. In this paper, we provide solutions to the problems of PB-PKI. We suggest generating fresh keys

during key update. Furthermore, we use ring signatures for authenticating the user requesting key updates and

use Asynchronous accumulators to handle the deletion of revoked keys. We show that the approach is feasible

and implement a proof of concept.

1 INTRODUCTION

Nowadays, Public Key Infrastructure (PKI) plays a

major role in ensuring secure communication. PKI

works on the principle that a trusted third-party or-

ganization called Certiﬁcate Authority (CA) can sign

certiﬁcates and vouch for the authenticity of the link

between the public key and the subject name con-

tained within the certiﬁcate. The trusted third-party

veriﬁes a client’s identity and conﬁrms the client’s

identity before signing. This third-party signs a cer-

tiﬁcate with its private key

. The certiﬁcate of the

trusted third-party is assumed to be widely known,

and another entity can verify the signed client certiﬁ-

cate by verifying the signature of the trusted third-

party organization afﬁxed to it.

However, PKI is a centralized infrastructure and

attacks like those carried out on Comodo

or DigiNo-

tar

compromises the CAs, and that can compromise

the integrity of the certiﬁcates issued thereby compro-

mising the whole infrastructure.

Phil Zimmerman proposed the Web of Trust

(WoT) in 1992 (Zimmermann, 1994) as a decentral-

https://orcid.org/0000-0002-2679-1862

https://orcid.org/0000-0002-4655-4274

The public key is included in the certiﬁcate.

https://www.comodo.com/Comodo-Fraud-Incident-

2011-03-23.html(last accessed on 20/03/2019)

https://security.googleblog.com/2011/08/update-

on-attempted-man-in-middle.html(last accessed on

20/03/2019)

ized alternative to PKIs. The initial processes lead-

ing to trust in WoT is different from that in PKI. For

example, if Alice knows the public key of Bob and

trusts him, and Bob knows the public key of Claire,

then Alice can ask Bob for Claire’s key and trust that

it is indeed Claire’s key. Alice and Bob exchange their

keys initially in person. This exchange event is called

a “Key Signing Party”, where people exchange their

keys with each other in person. However, this per-

sonal exchange poses two problems. The ﬁrst prob-

lem is an efﬁciency problem as only a few keys can

be exchanged initially in a particular time frame. The

second problem is a trust chain problem as it is possi-

ble that Alice is unable to ﬁnd a trust chain that con-

nects with Claire, thereby giving rise to isolated trust

communities.

Researchers are continually trying to improve the

two mechanisms above in different ways. Blockchain

has recently come to the center stage of the research

community (Nakamoto, 2009), and many researchers

have proposed using the Blockchain to solve some of

the PKI and WoT problems. One of such propos-

als is the Privacy-aware Blockchain-based PKI (PB-

PKI) (Axon and Goldsmith, 2017). PB-PKI

aims to

use the Blockchain to solve the problems of WoT and

also ensure privacy.

However, some of the goals were not achieved,

and we discovered some problems with the key up-

date process and the key revocation in the proposal.

PB-PKI is actually an implementation of WoT on the

Blockchain.

Plessing, P. and Omolola, O.

Revisiting Privacy-aware Blockchain Public Key Infrastructure.

DOI: 10.5220/0008947104150423

In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 415-423

ISBN: 978-989-758-399-5; ISSN: 2184-4356

415

Our contributions in this paper include the follow-

ing:

1. We show that the key update process in PB-

PKI (Axon and Goldsmith, 2017) does not en-

sure privacy.

2. We propose the use of ring signatures to solve

the problem of authenticating registered mem-

bers of the blockchain during key update to en-

sure that only registered members can perform

key updates.

3. We propose a revocation mechanism that in-

volves key deletion from the blockchain for PB-

PKI.

4. We implement a PoC and show that it is feasi-

ble in practice.

The rest of the paper is structured as follows: Sec-

tion 2 gives a short overview of previous research;

Section 3 gives a short introduction into Asyn-

chronous accumulators and Ring Signatures; Sec-

tion 4 describes the privacy notions in PB-PKI; Sec-

tion 5 describes PB-PKI; Section 6 discusses the

problems of PB-PKI and provides our solutions to

them; we evaluate our ideas in Section 7; Section 8

discusses the implications of our changes to PB-PKI

and we conclude in Section 9.

2 RELATED WORK

Blockchain became popular in 2009 with the intro-

duction of Bitcoin (Nakamoto, 2009). Blockchains

are decentralized and store transactions between par-

ties. All the transactions are publicly auditable by all

participants, and once a transaction is recorded and

conﬁrmed, it is practically immutable. These charac-

teristics have led researchers to propose implement-

ing PKIs and WoT on the Blockchain (Karaarslan

and Adiguzel, 2018; Singla and Bertino, 2018;

Yakubov et al., 2018; Matsumoto and Reischuk,

2016; Garay et al., 2018; Conner Fromknecht, 2014).

One example of such a proposal is Certcoin (Con-

ner Fromknecht, 2014). Certcoin is a blockchain vari-

ant built upon Namecoin

that also functions as a

WoT.

The simplest version of Certcoin uses Name-

coin as a bulletin board where blockchain posts

and blockchain traversals support its functionalities.

Data structures such as Asynchronous Accumula-

tors (Reyzin and Yakoubov, 2015) and Kademlia

Distributed Hash Table (DHT) (Maymounkov and

Namecoin is a fork of Bitcoin.

Mazi

eres, 2002) were introduced in successive ver-

sions so that Certcoin is time- and space-efﬁcient.

However, Certcoin was not built with privacy taken

into consideration.

Certcoin transactions store information about pub-

lic key events. The public key events are registration,

update, revocation, and veriﬁcation. Certcoin man-

dates every entity to register two key pairs. The entity

uses the ﬁrst key pair called online key pair for com-

munication and uses the second key pair called ofﬂine

key pair for security purposes such as key revocation

and update. The ofﬂine key pair is stored ofﬂine to

protect it.

The authors of Certcoin provide an incomplete

implementation of Certcoin in the language Go. The

implementation uses RSA keys and the Asynchronous

Accumulator for key veriﬁcation. PB-PKI builds on

the foundation of Certcoin.

3 PRELIMINARIES

This section brieﬂy describes the algorithms that are

used in the rest of the paper

3.1 Asynchronous Accumulator

Reyzin and Yakoubov proposed the Asynchronous ac-

cumulator(AA) (Reyzin and Yakoubov, 2015). AA is

the dynamic form of the accumulator called Merkle

tree (Derler et al., 2015), and it provides algorithms

for adding or deleting elements from the original set.

AA (see ﬁgure 1) is a container of several Merkle

roots, i.e., an array of Merkle roots. Every index of

the AA can contain only the root of one Merkle tree

at a particular time.

AA preserves efﬁciency in an environment, where

modiﬁcations of a Merkle tree happen often due to

frequent addition of leaves. Recalculating the whole

tree after a modiﬁcation requires log

time, therefore,

it is desirable to optimize this process. AA works sim-

ilar to a Merkle tree regarding veriﬁcation.

1. Initially, the AA is empty

2. To add a message m

, m

is hashed to H

and put

into the ﬁrst slot of the AA at index 0.

3. Suppose a second message m

needs to be added.

Since index 0 is occupied by H

, H

and H

are

concatenated and hashed to H

. The hash H

put at index 1 of the AA. Simultaneously, H

gets

The ofﬂine key pair can revoke the online key by sign-

ing a revoke-event.

is the hash of message m

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

416

Figure 1: Illustration of an Asynchronous Accumulator

with its empty (”-”) and ﬁlled (”H****”) Merkle roots and

their corresponding Merkle trees.

removed from index 0. To verify that message m

is part of the AA, the prover has to remember m

and H

. With this knowledge, he can reconstruct

the Merkle root at index 1.

4. When a third message m

arrives, it is hashed to

and placed at index 0 since index 0 is empty.

5. The next message m

is also hashed to H

. How-

ever, index 0 contains H

. Therefore, H

and H

are concatenated and hashed into H

. H

should

be placed at index 1, but it is occupied by H

Thus, H

and H

are concatenated and hashed

into H

1234

. H

1234

is then placed at index 2. To

verify the existence of message m

, only message

, H

and H

need to be remembered. Simul-

taneously, H

and H

are removed from index 0

and index 1.

The worst case scenario for an addition to AA is log

operations (concatenating and hashing), with n leaves

of the biggest tree. In the best case, the addition can

be done after one hash if index 0 is free. The trade-

off of faster additions is that more space is needed

for storing an AA compared to one Merkle root. The

storage requirement of AA for n leaves is log

3.2 Ring Signatures

Ring signatures allow a user to sign a message and

specify a set of possible signers without revealing

which member actually signed the message (Rivest

et al., 2001). The user can choose any set of possi-

ble signers that includes himself and sign by using his

secret key and the other’s public keys without getting

their approval or assistance. A ring signature does not

need any set-up, and the ring signature scheme is de-

ﬁned by two procedures:

1. Sign(m, P

, . . . , P

, S

) which produces a ring sig-

nature σ for the message m, given the public keys

, P

, . . . , P

of the r ring members, together with

the secret key S

of the s-th member (who is the

actual signer).

2. Verify(m, σ) which accepts a message m and a

signature σ (the signature includes the public keys

of all the possible signers), and outputs either true

or false

4 PRIVACY CONCERNS

Users sometimes assume that public blockchains are

anonymous. This assumption is true to the extent that

personal information is not connected to the accounts

of the blockchain user. An account is the hash of the

public key of a user’s key pair on the blockchain. Two

possibilities for tracking users exist. For example, it

is possible to ﬁnd out the IP-address of a blockchain

address by observing the blockchain network. A user

can prevent this possibility by masking his IP-address

using anonymizing technologies like Tor. The sec-

ond violation of privacy happens by design because

Revisiting Privacy-aware Blockchain Public Key Infrastructure

417

the public can audit Blockchains. Therefore, the pub-

lic knows what data is in a blockchain address’ wal-

let, the meta information of the data such as its origin

and more. A naive solution would be to use a new

public key for each transaction. However, this has no

real privacy gain since the mapping between the pub-

lic key and the account is available for the public.

In terms of blockchain based PKIs, this violation

of privacy would translate to linking any public key

and its transactions even when the public key has been

updated. At the moment a public key is used in any

service, an adversary could track its activities across

services. PB-PKI provides unlinkability between an

updated public key and its identity without compro-

mising the ability to verify that a speciﬁc public key

is authorized to take an action.

5 PB-PKI

In this section, we give a short introduction into the

original PB-PKI (Axon and Goldsmith, 2017).

PB-PKI modiﬁes part of Certcoin to achieve pri-

vacy. Registering, revoking and verifying a key in

PB-PKI is the same as that of Certcoin. An entity

registers its identity by posting its public key on the

blockchain. The main difference between Certcoin

and PB-PKI is the key update process. The unique key

update procedure in PB-PKI aims to provide untrack-

ability and provide a way to disclose the link between

an identity and its key by the entity at a later point.

This user-controlled disclosure enables the entity to

prove that a message is signed with its unlinkable key

which is connected to the certiﬁed key. PB-PKI hides

the link between an identity represented by its current

public key and its previous actions as well as keys,

while still retaining the authenticity of the key.

Since the PB-PKI Key update process is the main

improvement over Certcoin, we will focus on it in the

rest of this paper. The PB-PKI Key update process

(RSA keys) involves two steps:

1. Generate a new ofﬂine key pair, pkf

and skf

(of-

ﬂine public key at time n and ofﬂine secret key at

time n), where:

2. Compute the new online key pair pkn

and skn

(online public key at time n, and online secret key

at time n) in the following manner:

With this formula, the new keys are a valid RSA

key pair, where:

pkn

· skn

= 1 (mod N

) (1)

The two steps form a chain of keys as shown in

ﬁgure 2 after every update. When a user wishes to

pkn

Posted online:

Online keys:

(pkn

, skn

)

skf

Stored ofﬂine:

Ofﬂine keys:

(pkf

, skf

)

pkn

(pkn

, skn

)

skf

(pkf

, skf

)

pkn

(pkn

, skn

)

skf

(pkf

, skf

)

Figure 2: Key update procedure to facilitate user-controlled

disclosure.

disclose the public keys, the user has to publish all

ofﬂine public keys. With that knowledge, anyone can

recompute the chain of public keys and verify that a

speciﬁc key leads back to a particular identity.

Regarding the key update transaction, it must be

guaranteed that this new unlinkable public key is from

a registered member. Louise Axon (Axon and Gold-

smith, 2017) proposed that the identity that wants to

update must provide a signature signed with the cur-

rent key. However, this would mean a public link-

age of all keys. Therefore, the author proposed that

the link is disguised by encrypting the signature with

the public keys of a randomly chosen subset of the

network members. These network members are then

included in the veriﬁcation process because they can

decrypt the signature and verify that it is indeed from

a key that was already on the network. This of course

still enables the veriﬁers to track that two keys belong

to the same person. However, since the subset is cho-

sen randomly for every key update, a veriﬁer can only

track the identity link between two keys.

Furthermore, the changed usage of the ofﬂine key

pair means that it cannot be used the same way as

in Certcoin. In Certcoin, the ofﬂine key provided a

way to revoke compromised keys. In case of online

key theft, a user can still prevent the malicious usage

of the stolen online key by revoking it with the of-

ﬂine key. However, the user stores the ofﬂine keys

securely after its generation in PB-PKI and only pub-

lishes them to disclose its identity. To obtain the same

revocation abilities as Certcoin, PB-PKI introduces

the so-called “Master Key”. The Master key func-

tions the same way as ofﬂine keys in Certcoin, i.e., it

can revoke a current compromised online key.

6 ENHANCEMENTS TO PB-PKI

This section describes the problems encountered in

the implementation of PB-PKI and the solutions to

these problems

. Some of the problems required a to-

We refer to our improved version of PB-PKI as En-

hanced PB-PKI.

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

418

Table 1: Comparison of PB-PKI with NOOB-PKI regarding key operations.

PB-PKI Enhanced PB-PKI

Setup Phase User U generates an online, ofﬂine and master RSA key pair.

Setup Phase User U generates an online and ofﬂine RSA key pair.

Key Registration: U posts a registration transaction with

• his identity

• a timestamp

• the public part of the generated online key

• a signature of the generated online public key

• a signature of the master key

It has to be veriﬁed that the identity and the online key have not been

registered previously and that the signature of the online key is valid.

Key Registration: U posts a registration transaction with

• his identity

• a timestamp

• the public part of the generated online key (registration key)

• a signature of the online public key

• the witness of the online public key

• the public part of the generated ofﬂine key

• a signature of the ofﬂine public key

It has to be veriﬁed that the identity and the public online key have not been

registered previously. The signatures of the online and ofﬂine keys and the

witness are also validated.

Key Update: User U generates a new ofﬂine RSA key pair with public part

pkf and private part skf. To generate the new online key with public part

pkn and private part skn, U calculates:

pkn

= pkn

n−1

· skf

(ModNn) (2)

skn

= skn

n−1

÷ skf

(ModNn) (3)

U then posts an update transaction with

• a timestamp

• the public part of the newly calculated online key

• a signature of the online public key

• a signature of the previous online public key to ensure that U is

already part of the network. This signature is encrypted with the

public keys of a subset of network members. The subset is chosen

randomly at each update and has to verify the signature of U’s

previous online key.

U secret shares the new ofﬂine public key between a majority of the

network members.

It has to be veriﬁed that the online public key has not been registered

previously, that the ﬁrst signature is valid, and that the second signature is

valid and done with a currently valid public key on the network.

Key Update: User U generates a new online and ofﬂine RSA key pair and

posts an update transaction with:

• a timestamp

• the public part of the new online key

• a signature of the new online public key

• the witness of the new online public key

• the public part of the new ofﬂine key

• a signature of the new ofﬂine public key

• a ring signature by use of a randomly selected subset of registration

keys and U’s registration key

• all registration keys used for the ring signature

The network members verify that the online public key has not been

registered previously, the signatures of the online and ofﬂine keys are valid,

and the witness is valid. Additionally, the network veriﬁes that the ring

signature is valid and that all used registration keys exist.

Key Revocation: User U posts a revocation transaction with

• a timestamp

• the public part of the to be revoked public key

• a signature of the public key

Key revocation can be executed either by the key holder.

Key Revocation: User U posts a revocation transaction with

• a timestamp

• the public part of the to be revoked key

• a signature of the public key

• the witness of the public key

• the new ancestors of the revoked public key

The network members verify that the revoked key is indeed part of the

network and that the signature, the witness, the ancestors are valid. The

ancestors of a given message are all its parent nodes in a Merkle tree. The

revoked key is replaced with ”⊥” in the Merkle tree, and the ancestors of

”⊥” have to be posted so that other users can update their witnesses

accordingly.

tal change of procedure while the others needed some

RSA is used because it is based on a computationally

hard problem.

modiﬁcations to the existing procedures. The issues

and their solutions are given below:

Revisiting Privacy-aware Blockchain Public Key Infrastructure

419

6.1 Creation of New Keys

In PB-PKI (Axon and Goldsmith, 2017) new keys are

generated with the novel update procedure described

in section 5. This update procedure should ensure

unlinkable keys while allowing user-controlled dis-

closure at the same time. However, this novel pro-

cedure has a side effect - it uses the same modu-

lus for every updated key pair. An attack where en-

crypted messages can be decrypted when two public

keys have the same modulus was documented by Dan

Boneh (Boneh, 1998). We present equations below

that involves two different public keys e

, e

, and two

cipher texts of the same message encrypted by the two

public keys A, B. The equations show that the mes-

sage can be decrypted even without the private keys.

Given:

A = M

(mod n)

B = M

(mod n)

(4)

If gcd(e

, e

) = 1 ,there exists some x, y such that

+ ye

= 1

Therefore:

· B

= M

· M

= M

· M

= M

+ye

(5)

= M

The attacker could also trick the user to sign sensitive

information twice with a past and current key. The at-

tacker can then decrypt the message using the process

we described. Furthermore, an adversary can scan the

blockchain for public keys with equal modulus, and

be sure that these keys belong to the same user. In-

stead of user-controlled disclosure, the novel update

process actually ensures linkability by design.

6.1.1 Solution

As the proposed update procedure could not disguise

links between keys, we sought another mechanism.

We found that the key update mechanism in PB-PKI is

not critical to ensuring privacy. The mechanism helps

in disclosure since a user can provide the link between

his keys to a veriﬁer. However, there are other ways

that one can use to prove the ownership of a key with-

out linking one’s keys by design.

We propose generating a new random key pair at

each update event. A user can still disclose that a spe-

ciﬁc key belongs to him. He does it by providing a

signature with the key to be disclosed and his regis-

tration key. Thus, a veriﬁer can be sure of the owner-

ship of the disclosed key. In addition, the disclosure

of a key does not disclose any other keys of the same

identity.

6.2 Key Deletion

In previous papers about Certcoin (Con-

ner Fromknecht, 2014) and PB-PKI (Axon and

Goldsmith, 2017), fast key veriﬁcation is achieved

with the Merkle root of a Merkle tree containing all

valid public keys. Speciﬁcally, many Merkle roots

are involved because Certcoin and PB-PKI use the

AA as explained in Subsection 3.1. To quickly verify

whether a key is valid, a veriﬁer takes the key as well

as its witness and computes its Merkle root. Then the

veriﬁer takes the Merkle roots of the latest block and

checks whether one of them matches the computed

one. This process is quick because it needs at most

log

operations (for n number of keys in the Merkle

tree) to calculate the Merkle root. In addition, it is

space-efﬁcient, because the veriﬁer only needs to

store the latest blockheader plus the public key and

the witness

Adding keys is very efﬁcient as well because of

the Asynchronous Accumulator. The maximum of

operations needed per addition of a key is log

(for n

number of all keys in the Merkle tree). Consequently,

the Merkle tree does not need to be fully recalculated

but it is merged with other trees of the same size, i.e.,

concatenating the roots and hashing them.

This works very well when one adds keys only.

However, the event of a key deletion in the case of

key revocation was not discussed intensively by the

authors of Certcoin and PB-PKI. Even though in both

papers it is mentioned that deletion is possible, only

Certcoin gives a short explanation of how deletions

can be implemented using a Merkle tree. To make the

term clear: deleting a key from a Merkle tree means

to modify an entry of a Merkle tree. The entry to be

deleted gets replaced with an entry that indicates that

the former public key is deleted.

6.2.1 Solution

In the Enhanced version of PB-PKI, we use the sign

”⊥” for deleted entries. With such a modiﬁcation, we

have to recalculate log

parents of the Merkle tree.

Therefore, while adding keys takes at worst case log

operations, deletion of keys always takes log

opera-

tions.

Witnesses are the missing hashes needed by a veriﬁer

to construct a Merkle root.

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

420

Furthermore, the time required for key holders to

update their witness needs to be considered as well.

Every witness in this Merkle tree has to be updated.

The number of operations for witness update is in the

worst case in direct correlation to the number of op-

erations needed to update the AA. In the best case, a

key holder only has to do one operation to bring his

witness up to date. Therefore for both addition and

deletion, a key holder needs to do at most log

opera-

tions.

6.3 Space Efﬁciency

The second issue regarding entry deletion from

Merkle trees is space efﬁciency. If there are additions

to the AA only, the only information that is needed

to update any witness are the resulting Merkle roots

after every addition. However, in the case of deletion,

one needs to know the former witness of the deleted

element in order to update the other witnesses of a

Merkle tree. This means that the witness of every re-

voked and deleted key has to be stored and published.

The result of this is more storage is used.

6.3.1 Solution

The AA changes with every transaction, but only the

ﬁnal accumulator after all transactions in a block are

taken into account gets shown. This means that for

key additions, it is mandatory to publish the witness of

each added key as well. The result is the publication

of every change of the AA.

As a result of the changes made in the preced-

ing paragraphs, a prover with an old witness has to

go back to the last block where his public key plus

witness was valid. Then he traverses all transactions

of all blocks leading to the most current block, and

he adjusts his witness according to the occurred key

events. Finally, he has a witness that provides proof

when using the latest accumulator.

6.4 User Authentication

The third challenge was the authentication of a pend-

ing key update. At key update, it should be ensured

that the user requesting the key update already owns a

key on the network while securing his identity. In the

proposed PB-PKI this is done through a signature of

the current key. However, this would enable a linking

of the keys. Therefore, the signature is encrypted. It is

encrypted with a subset of total public keys available

on the network. These members then have to decrypt

the signature and verify that it is indeed done with a

registered key.

This practice sounds nice in theory but is hard to

implement. The ﬁrst set of challenges arises: how can

the subset of network members announce their veriﬁ-

cation of the signature? Post it on the blockchain?

How can one trust that they are telling the truth?

Moreover, how can one guarantee that they actually

verify the signature and have not been ofﬂine for two

years?

This set of questions remains unanswered, but

even if there were answers to them, another ques-

tion arises: How to ﬁnd out a subset of current public

keys? This would either require global storage of n

public keys (for n network members), like the AA,

but instead of a few Merkle roots we needed to record

all valid keys, millions of it in every block. This

would be fast but space-intensive (totally unusable).

Alternatively, we traverse the blockchain looking for

valid keys, which would be space-friendly but time-

intensive. Additionally, we cannot ﬁnd out which

public keys that were posted onto the blockchain are

still valid and which are not, because no keys are

linked to each other.

6.4.1 Solution

We decided to ﬁnd another way of solving the authen-

tication problem. We chose to use ring signatures.

Ring signatures are explained in Subsection 3.2. In

the Enhanced PB-PKI, a ring signature is crafted and

posted in the update transaction. The public keys are

randomly selected out of the public keys published at

registration event. The user’s public key that was cre-

ated during registration is added to the set of keys.

With these selected keys, he performs the ring signa-

ture and puts it onto the transaction. That way, anyone

can verify that this transaction must be from one of

the already registered holders of the used public keys.

However, nobody knows who it was from this group

of keys. Moreover, distinct ring signatures have no re-

lation to each other, and no information can be gained

by intersecting them. We used a ring size of 6 possi-

ble signers for the proof of concept because having a

larger ring size is space inefﬁcient.

7 EVALUATION

For the proof of concept, we used an Asus Laptop

with 4GB RAM and an Intel Core processor i5 of the

5th generation. The installed operating system was

Ubuntu 16.04. The PoC was written in the program-

ming language Go, and the database we used to store

the blocks was LevelDB.

Revisiting Privacy-aware Blockchain Public Key Infrastructure

421

With this setup, we measured how long it takes to

execute the different operations:

• Register a Key:

∼

80 milliseconds

• Update a Key:

∼

120 milliseconds

• Revoke a Key:

∼

10 milliseconds

• Verify a Key:

∼

15 microseconds

• Update a Witness:

∼

90 milliseconds

Verifying a key is the most critical activity because

users often have to verify whether a key is valid. In

Enhanced PB-PKI, verifying a key is the fastest oper-

ation, because it only involves hashing and concate-

nation without any write operation. The bottleneck of

posting transactions is the need to mine new blocks

and verify them. Setting the mining time or process

is beyond the scope of this paper. The Enhanced PB-

PKI is a full blockchain and it was deployed locally

on the laptop for the experiments.

8 DISCUSSION

In this section, we consider the possible cases of key

compromise and the options that the Enhanced PB-

PKI provides to the victim. Key compromise happens

when an adversary gets access to or steals the private

part of the online or the ofﬂine key. Getting access to a

key means an adversary knows a key while the victim

still has access to the key too. Stealing a key means an

adversary takes the key away from the victim so that

the adversary knows the key while the victim does

not.

8.1 Security Model

We consider a model where PB-PKI is accessible to

the public. In this model, we assume that an adversary

has access to the blockchain. The adversary is also

part of every operation involving registration, key up-

date and key revocation and able to tamper with any

of these operations.

The security goals of the system are as follows:

1. The adversary cannot link a key to the owner.

2. Only the owner of a public online key can prove

the ownership.

Depending on which private keys were stolen or ac-

cessed, we consider six different cases:

1. Online secret key accessed only: The adversary

can take part in the network by using the accessed

online key. The victim can revoke his online key

and update it. The update creates a new online key

he can safely use again.

2. Online and ofﬂine secret keys accessed: The ad-

versary can take part in the network by using the

accessed online key. The adversary can also per-

form key update, but this is not useful because

when the user revokes the online key and performs

key update, then the adversary can no longer im-

personate the victim. After key update, the ad-

versary does not have any knowledge of either the

new online or ofﬂine key.

3. Online secret key stolen only: The adversary can

take part in the network by using the stolen online

key. To recover from this case, it requires that the

victim stored the previous online key. With this

previous online key and the current ofﬂine key, he

can recalculate the stolen online key. Then he re-

vokes and updates the stolen key.

4. Online and ofﬂine secret keys stolen: The ad-

versary can take part in the network by using the

stolen online key. In this case, the victim can do

nothing against the adversary. However, the vic-

tim can update the previous online key, and stay

part of the network. The possibilities for the ad-

versary are limited to the use of the stolen online

key only. To mitigate this scenario, the introduc-

tion of an expiration date of public keys would

limit the key abuse of the adversary to a certain

time frame.

As long as keys are not stolen and key compromise is

detected early, an adversary can be kept under control.

To avoid key theft, keys should always be copied to a

safe location.

9 CONCLUSION

In this paper, we have shown that the initial proposal

of PB-PKI is fraught with challenges. Some of the

problems include authentication during key update,

how revoked keys can be deleted successfully and

the key update mechanism is not as secure as ear-

lier expected. Enhanced PB-PKI simpliﬁes the update

process by requiring the user to generate fresh keys

without using the key updates mechanism by Louise

Axon et al. (Axon and Goldsmith, 2017). The new

key update mechanism removed the privacy problem

that was introduced by PB-PKI. The Enhanced PB-

PKI solved the problem of user authentication by in-

troducing ring signatures to PB-PKI. We also adapt

the use of AA in order to aid key deletion and ensure

that storage space is maximized after deletion of a re-

voked key. The Certcoin usage of ofﬂine keys for key

revocation was retained instead of using it for key up-

dates as in the initial PB-PKI construction. We devel-

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

422

oped the proof of concept using the Go programming

language and show that the solutions we proposed are

feasible.

In the future, we plan to implement optimiza-

tions to the ring signature scheme. New ring sig-

nature schemes such as forward-secure linkable ring

signatures (Boyen and Haines, 2018) will also be in-

vestigated as this supports forward security and the

blockchain user can prove ownership of a ring signa-

ture using this scheme.

ACKNOWLEDGMENTS

We acknowledge David Derler, Sebastian Ramacher,

Peter Lipp and Clemens Brunner for fruitful discus-

sions during the period of this work. We acknowledge

Sebastian Ramacher, Peter Lipp and Clemens Brun-

ner for their thorough reviews.

This research is part of the LIGHTest project

funded by the European Union’s Horizon 2020 re-

search and innovation programme under G.A. No

700321.

REFERENCES

Axon, L. and Goldsmith, M. (2017). Pb-pki: A privacy-

aware blockchain-based pki. In Proceedings of the

14th International Joint Conference on e-Business

and Telecommunications - Volume 6: SECRYPT,

(ICETE 2017), pages 311–318. INSTICC, SciTePress.

Boneh, D. (1998). Twenty years of attacks on the rsa cryp-

tosystem.

Boyen, X. and Haines, T. (2018). Forward-secure linkable

ring signatures from bilinear maps. Cryptography,

2(4):35.

Conner Fromknecht, Dragos Velicanu, S. Y. (2014). Cert-

coin: A namecoin based decentralized authentication

system.

Derler, D., Hanser, C., and Slamanig, D. (2015). Revisiting

cryptographic accumulators, additional properties and

relations to other primitives. In Topics in Cryptology -

CT-RSA 2015, The Cryptographer’s Track at the RSA

Conference 2015, San Francisco, CA, USA, April 20-

24, 2015. Proceedings, pages 127–144.

Garay, J. A., Kiayias, A., Leonardos, N., and Panagiotakos,

G. (2018). Bootstrapping the blockchain, with appli-

cations to consensus and fast PKI setup. In Public-

Key Cryptography - PKC 2018 - 21st IACR Interna-

tional Conference on Practice and Theory of Public-

Key Cryptography, Rio de Janeiro, Brazil, March 25-

29, 2018, Proceedings, Part II, pages 465–495.

Karaarslan, E. and Adiguzel, E. (2018). Blockchain based

DNS and PKI solutions. IEEE Communications Stan-

dards Magazine, 2(3):52–57.

Matsumoto, S. and Reischuk, R. M. (2016). IKP: turn-

ing a PKI around with blockchains. IACR Cryptology

ePrint Archive, 2016:1018.

Maymounkov, P. and Mazi

eres, D. (2002). Kademlia: A

peer-to-peer information system based on the xor met-

ric. In Revised Papers from the First International

Workshop on Peer-to-Peer Systems, IPTPS ’01, pages

53–65, London, UK, UK. Springer-Verlag.

Nakamoto, S. (2009). Bitcoin: A peer-to-peer electronic

cash system.

Reyzin, L. and Yakoubov, S. (2015). Efﬁcient asynchronous

accumulators for distributed pki. IACR Cryptology

ePrint Archive, 2015:718.

Rivest, R. L., Shamir, A., and Tauman, Y. (2001). How

to leak a secret. In Advances in Cryptology - ASI-

ACRYPT 2001, 7th International Conference on the

Theory and Application of Cryptology and Informa-

tion Security, Gold Coast, Australia, December 9-13,

2001, Proceedings, pages 552–565.

Singla, A. and Bertino, E. (2018). Blockchain-based PKI

solutions for iot. In 4th IEEE International Confer-

ence on Collaboration and Internet Computing, CIC

2018, Philadelphia, PA, USA, October 18-20, 2018,

pages 9–15.

Yakubov, A., Shbair, W. M., Wallbom, A., Sanda, D., and

State, R. (2018). A blockchain-based PKI manage-

ment framework. In 2018 IEEE/IFIP Network Op-

erations and Management Symposium, NOMS 2018,

Taipei, Taiwan, April 23-27, 2018, pages 1–6.

Zimmermann, P. (1994). Pgp user’s guide, volume i: Es-

sential topics.

Revisiting Privacy-aware Blockchain Public Key Infrastructure

423