AuthLedger: A Novel Blockchain-based Domain Name Authentication

Scheme

Zhi Guan

1,3 a

, Abba Garba

2,3 b

, Anran Li

1,3 c

, Zhong Chen

1,3 d

and Nesrine Kaaniche

2,3 e

Institute of Software, EECS, Peking University, National Engineering Research Center for Software Engineering,

Peking University, Beijing, China

MoE Key Lab of High Conﬁdence Software Technologies, Peking University, Beijing, China

SAMOVAR, Telecom SudParis, CNRS, University of Paris-Saclay, France

Keywords: PKI, Blockchain, Authentication, Cryptography.

Abstract:

Nowadays public key infrastructure authentication mainly rely on certiﬁcate authorities and have to be trusted

by both domain operators and domain owners. Domain Name System Security Extensions (DNSSEC) using

DNS-based Authentication Name Entities (DANE) DNS records types, offer additional security for authen-

ticating data and integrity to domain name system (DNS). This method allow client via signed statements to

specify which CAs are authorized to represent certiﬁcate of a domain. Another method is Certiﬁcate Author-

ity Authorizations (CAA) developed by Internet Engineering Task Force (IETF) to provide security guarantee

against rogue certiﬁcate authorities that offer fake certiﬁcate for the domain. However, all of these approaches

are prone to single point of failure due to their trust attached to infrastructure like Internet Corporation for

Assigned Names and Numbers (ICANN). In order to weaken the level of trust to the CAs over certiﬁcates, it is

necessary to balance the distribution rights among the entities and improve the control of certiﬁcate issuance

for the certiﬁcate owners. Recently with the emergence of Blockchain, a public and distributed ledger, several

applications appeared taking advantage of this powerful technology. In this paper, we present an AuthLedger

a domain authentication scheme based on blockchain technology. The proposed scheme is multi-fold. First,

we proposed a domain authentication scheme to reduce the level of trust in CAs. second, we implement our

system using Ethereum smart contract. Third, we evaluate security and performance of the proposed system.

1 INTRODUCTION

In current Public Key Infrastructure (PKI) systems,

there is a disparity of rights between the different in-

volved entities such as users and certiﬁcate authori-

ties (Scheitle et al., 2018). Indeed, users may initi-

ate a certiﬁcate signing request, but are not allowed

to judge whether the issuing authority has the right

to issue certiﬁcate for the domain. In fact several

breaches of reporting certiﬁcates mis-issue have been

revealed (Kamat and Gautam, 2018). For instance

in September 2015, Google announced to stop us-

ing Symantec’s Extended Validation certiﬁcates due

to Symantec issued a certiﬁcates without authoriza-

https://orcid.org/0000-1111-2222-3333

https://orcid.org/1111-2222-3333-4444

https://orcid.org/2222-3333-4444-5555

https://orcid.org/3333-4444-5555-6666

https://orcid.org/4444-5555-6666-7777

tions for google domains (Rashid, 2015). Meanwhile,

in 2015 Lenovo Superﬁsh installed a local CA in its

products. This CA is used to inject ads into the trans-

port layer security (TLS) protected web sites to steal

conﬁdential data (Kamat and Gautam, 2018). Since

the CA private keys are in the computer RAM, they

may be easily used to self-examine the trafﬁc. In may,

2016 Symantec bought Blue coat to become part of its

subCA with intention to enhances security in the cy-

ber environment. Blue coat has a devices to pry an

encrypted internet trafﬁc (Kamat and Gautam, 2018).

These lethal phenomena lead to many researches

to disseminate the absolute trust on CAs to various

authorities (Khan et al., 2018). Nowadays, certiﬁcate

miss-issuance is hard to detect due to lack of standard

mechanisms to check which certiﬁcate authorities are

allowed to issue certiﬁcates for the domains (Kubilay

et al., 2018).

Recently Domain Name System Security Exten-

sions (DNSSEC) offer additional security for au-

Guan, Z., Garba, A., Li, A., Chen, Z. and Kaaniche, N.

AuthLedger: A Novel Blockchain-based Domain Name Authentication Scheme.

DOI: 10.5220/0007366803450352

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 345-352

ISBN: 978-989-758-359-9

345

thenticating data for domain name system (DNS).

DNSSEC records allowed client via signed statements

to specify which CAs are authorized to represent cer-

tiﬁcate of the domain (Gourley and Tewari, 2018).

Certiﬁcate authority authorizations (CAA) is devel-

oped by Internet Engineering Task Force (IETF) as

explained in [RFC 6844]

to provides security guar-

antee against rogue CAs. In CAA, domain owners

decides which CAs can issue a certiﬁcate for their

domain via CAA resource records (Karaarslan and

Adiguzel, 2018). Baldi et al., (2017) describe the

DNSSEC system require a lots of complex security

requirements for deployment. From one hand, Certiﬁ-

cate authority authorization (CAA) has not been de-

ployed by vast majority of the CAs (Hari and Laksh-

man, 2016). Consequently, latter approaches are more

prone to central of failure due to their trust attached

to infrastructure like Internet Corporation for As-

signed Names and Numbers (ICANN)

(Berkowsky

and Hayajneh, 2017).

Blockchain is a decentralized global ledger that

contain a series of transactions in the form of blocks

(Ali et al., 2016). Each block is secured by hash

function to link to another Block in an orderly man-

ner to form a Blockchain network (Yakubov et al.,

2018). Ethereum is the second largest blockchain sys-

tem in terms of value. The objective of such system

is to store an arbitrary state in a distributed temper-

proof manner (Matsumoto and Reischuk, 2016). Un-

like Bitcoin, Ethereum used Turing-complete lan-

guage and EthereumVirtualMachine(EV M) to repre-

sent language and computations.

In this paper, we propose AuthLedger a novel

domain authentication scheme based on blockchain

technology. The proposed mechanism records a set

of trusted CA associated with each speciﬁc domain

on the blockchain. That is, each CA has to ﬁrst verify

if is considered to be trusted in order to perform is-

suance process. On the other hand, each domain can

update its trusted CA’s on the blockchain and check

the issued certiﬁcate related to it.

Thus, our contributions are summarized as fol-

lows:

– We propose a new solution based on the

blockchain technology for identity authentication

without a trusted third party.

– Provides an efﬁcient and trustworthy certiﬁcate

authentication process.

– We implement and conduct an experimental per-

formances’ analysis to validate the proposed sys-

https://tools.ietf.org/html/rfc6844

https://www.icann.org/

tem using Ethereum solidity smart contract envi-

ronment.

– Analyze security implication of the proposed

scheme by discussing different security threats

and countermeasures.

The remainder of this paper is organized as fol-

lows. Section 2 reviews PKI systems, highlights re-

lated security challenges and gives a general overview

of the blockchain technology. We present proposed

system in 3; 4 we give a detail evaluation of the

proposed system, security and performance including

the browser extensions; Finally conclusion and future

work in section 5.

2 BACKGROUND AND RELATED

STUDY

2.1 Certiﬁcate Authorities (CAs)

Certiﬁcate Authorities involve several hardware and

software entities to manage the PKI system (Aish-

warya et al., 2015). Certiﬁcate based authentication

used X.509 PKI standard to provide a strong level

of clients authentication. Authentication occur us-

ing a third party certiﬁcation authorities (CA)(Kiayias

et al., 2017). Below describe the entities involve in the

Certiﬁcate of authorities: A client will provide infor-

mation to a CA that verify user identity. Registration

authority (RA) managed CA task such as authenticat-

ing users. Validation authority (VA) verify and con-

ﬁrm whether digital certiﬁcate is used by adequate

trustworthy CA. Different entities involved in the CA

as shown in ﬁgure 1:

Registration

Authority

Certiﬁcation

Authority

Validation

Authority

Get veriﬁcation

Identity veriﬁcation

Get!

certiﬁcate

Certiﬁcate request

Authenticate with

certiﬁcate

User

2 3

Figure 1: Entities involves in CA.

2.2 DNS Security Extensions (DNSSEC)

DNS security extensions (DNSSEC) using DNS

based authentication of named entities (DANE)

was designed based on Internet Engineering Task

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

346

Force (IETF) [RFC6394-RFC6698] standard to pro-

tect cache poisoning attacks (Shulman and Waidner,

2017). The main purpose of DNS security extensions

(DNSSEC) is to address some security challenges of

the existing PKI certiﬁcates authentication (Gourley

and Tewari, 2018). However, Security of DNSSEC

inherently lies on PKI root at ICANN

which is vul-

nerable to central failure. Consequently, vulnerabil-

ity is much easier to exploit with current DNSSEC

system (Sehgal and Dixit, 2019). The Key corrective

measure is to ensure domain holders and domain op-

erators behave honestly (Matsumoto et al., 2017). De-

spite the current proposed solutions there is no stan-

dard method to incentivitize an entities that behave

honestly (Matsumoto and Reischuk, 2016).

Furthermore, DNSSEC using DANE allows do-

main operators to make judgment about CA based

on the statement related to each PKI certiﬁcate (Qin

et al., 2017). it includes the following information:

• CA Restrictions: the client should determine

which CA should issue certiﬁcates.

• Service Certiﬁcate Restrictions: the client

should accept only certain certiﬁcates.

• Trust Anchor: the client should validate certiﬁ-

cates for a particular domain based on the set of

available domains provided chain of trust.

2.3 Certiﬁcation Authority

Authorization(CAA)

Certiﬁcate authority authorization provides an addi-

tional measures to protect issuing accidental certiﬁ-

cates (Scheitle et al., 2018). The success of the Cer-

tiﬁcation Authority Authorization (CAA) as a largest

DNS security mechanism relies on smooth coopera-

tion between CAs, DNS operators and domain own-

ers. Generally, DNS based extension Aishwarya et

al.,(2015); Certiﬁcate authority authorization Scheitle

et al., (2018); are DNS resource record types built to

assist in certiﬁcate issuance and veriﬁcation.

2.4 Blockchain based PKI

Blockchain technology allow an execution of arbi-

trary logic known as programmable contract. Smart

contract is a program that executes on the blockchain

by network of mutually distrustful nodes without re-

quiring a trusted authority (Wang et al., 2018). Sev-

eral solutions are proposed based on the blockchain

technology to address the current PKI challenges

namely: Namecoin (Kalodner et al., 2015) proposed

https://www.icann.org/

a namespace blockchain based system that provide a

noble solution to the current challenges of decentral-

ized namespaces. Ali et al. (2016) BlockStack is an

implementation of a new type of decentralized inter-

net infrastructure focusing on decentralized applica-

tion layer of traditional internet architecture.

3 NOVEL BLOCKCHAIN

BASED DOMAIN NAME

AUTHENTICATION SCHEME

3.1 Threat Model

First we introduce the threat model. In particular

we describe several adversaries capabilities: From

Blockchain, to malicious client entities that may

launch a colluding attacks (between several compro-

mised CAs).

3.1.1 Adversary Capabilities

First scenario we assume there are M full nodes in the

blockchain network, in which the entire nodes with p

proportion is controlled by malicious attackers, and

the other nodes of 1 − p are honest full nodes;the

number of veriﬁcation nodes is N, among which q

accounts for the veriﬁcation node is controlled by a

malicious attacker, and the other 1 −q proportion of

the veriﬁcation nodes are honest nodes.

Additionally we assume malicious entity replicate

public keys as the authenticating node to launch (Sybil

attack).

Second scenario, from client server side we as-

sume CAs and validating authorities are malicious

which act arbitrarily such as binding fake certiﬁcate.

Moreover, Domain name server (DNS) is assume to

be corrupted. We assume that malicious entities can-

not collude the hash function of the standard crypto-

graphic protocols.

We also assume when Browser is performing

checking relevant to a CA may ﬁlter erroneous cer-

tiﬁcates.

3.2 Entities and Its Functionalities

Our proposed system consist of ﬁve entities namely:

• Certiﬁcate Authority (CA). It represents each

authorized entity to be able to issue digital certiﬁ-

cates in this case, to join AuthLedger to register

the information on the Blockchain.

AuthLedger: A Novel Blockchain-based Domain Name Authentication Scheme

347

• Domain Name Server (DNS). Maintains the di-

rectory of the certiﬁcate owner and identity bind-

ing.

• Browser Extension. Complete domain name

Transport layer security (TLS) set up.

• Validating Authority. Put vigilance during CA

operations for suspicious certiﬁcates and report

any misbehaviour for an entity.

• Blockchain. Which contain full nodes verify

binding request and conﬁrm request from validat-

ing authorities.

Certiﬁcate

Authorities

(CAs)

Domain

Validators

Client

Browser

{Domain : exmaple1.com, T rustedCAs : CA

,CA

..}

...

{Domain : exmaple2.com, T rustedCAs : CA

,CA

..}

<latexit sha1_base64="jB/df6oeayh8A/byyn0T/ir04nY=">AAACXHichVHLSgMxFM2Mr7a+qoIbN8EiuJAwUwSlK0UXLiu0ttApJZPeajCPIcmIZehPunPjr2hau9BW8EIuh3Pu4SYnaSa4dVH0HoQrq2vrG6VyZXNre2e3urf/YHVuGLSZFtp0U2pBcAVtx52AbmaAylRAJ32+meqdFzCWa9Vy4wz6kj4qPuKMOk8NqjYp8K2WlKsGvEqaCYgJ0/IMt0xuHQzxzbVt+DaIz3yrE4KTSZJUCkLIBHuwZK//a68MqrWIRLPCyyCegxqaV3NQfUuGmuUSlGOCWtuLo8z1C2ocZwImlSS3kFH2TB+h56GiEmy/mIUzwSeeGeKRNv4oh2fsT0dBpbVjmfpJSd2TXdSm5F9aL3ejy37BVZY7UOx70SgX2Gk8TRoPuQHmxNgDygz3d8XsiRrKnP+PaQjx4pOXwUOdxBGJ789rV2QeRwkdoWN0imJ0ga7QHWqiNmLoHX0GpaAcfISr4Wa4/T0aBnPPAfpV4eEXbiyvFg==</latexit>

Full nodes

Blockchain network

Transactions

1. Identity binding !

request

2. Conﬁrm !

request

3. Modify trusted!

CA list

4. Certiﬁcate!

request

5. Issued !

certiﬁcate!

6. Visit!

request

7. Certiﬁcate

8. Get domain’s !

trusted CA list

9. Trusted CA list

10. Compare the issuer !

of the certiﬁcate !

with trusted CA list

Figure 2: Entities and its Functionalities in AuthLedger.

As depicted in Figure 2 [1] Domain initiates an

identity binding request in the blockchain.[2] Validat-

ing authority via full nodes verify the requests. [3] A

domain updated a trusted CAs in the Blockchain. [4-

5] The domain name sends a CA list that is trusted by

blockchain network to complete certiﬁcate issuance

process. [6-7] Client initiates a secure connection

through the browser-plug-in to obtain the certiﬁcate

own by the domain name. [8-10] Browser then re-

quests trusted CAs list from blockchain and compare

the validity of the information obtained.

3.3 Domain Authentication

In order to achieve the entity authentication in this pa-

per we provide an authentication procedures based on

time [T] and count [C], detail process describe be-

low:

The identity of the binding process is broadly di-

vided into 3 steps:

1. The domain name send an authentication request

to the blockchain.

2. After transaction conﬁrmation, the transaction

and block are placed on the server side for veri-

ﬁcation.

3. Node is verify the transaction after the veriﬁcation

period or number of times takes to complete the

identity binding.

3.3.1 Authentication Veriﬁcation based on Time

In time-based authentication process when the veri-

ﬁcation reaches a speciﬁed time it owns the domain

name server and completes the binding procedures.

As depicted in ﬁgure 3.



req

(Pk

, exmaple.com)

<latexit sha1_base64="v2RvuGznC1eMZEZc1LmyhA2ELlA=">AAACBHicbVA9SwNBEJ3zM8avREubxSAoyHFno2XExjJCokISjr3NJFmye3fu7mnCkcLGv2JjoYit+Bvs/DduPgo1Phh4vDfDzLwwEVwbz/ty5uYXFpeWcyv51bX1jc1CcetSx6liWGOxiNV1SDUKHmHNcCPwOlFIZSjwKuydjfyrW1Sax1HVDBJsStqJeJszaqwUFHaq/SBTeDPcr/SC00OCfUkTgS6L5UFQKHmuNwaZJf6UlMrFO/kBAJWg8NloxSyVGBkmqNZ130tMM6PKcCZwmG+kGhPKerSDdUsjKlE3s/ETQ7JnlRZpx8pWZMhY/TmRUan1QIa2U1LT1X+9kfifV09N+6SZ8ShJDUZssqidCmJiMkqEtLhCZsTAEsoUt7cS1qWKMmNzy9sQ/L8vz5LLI9f3XP/CpuHCBDnYgV3YBx+OoQznUIEaMLiHR3iGF+fBeXJenbdJ65wzndmGX3DevwFMoZlS</latexit>

<latexit sha1_base64="/RK0XcrRlgeGQG9dYuUIJpN9I58=">AAACBHicbVC7SgNBFJ2N7/hI1NJmMAgRZNm10TJiYxnBPCBZltnJ3WTIzO46M6sJSwobf8XGQhFbP8HCTj/Cb3DyKHwduHA4517uvSdIOFPacd6t3Nz8wuLS8kp+dW19o1Dc3KqrOJUUajTmsWwGRAFnEdQ00xyaiQQiAg6NoH869htXIBWLows9TMATpBuxkFGijeQXdy4GfibhclSu9v2TAwwDQRIONo3Fvl8sObYzAf5L3BkpVTavxcfrZ6HqF9/anZimAiJNOVGq5TqJ9jIiNaMcRvl2qiAhtE+60DI0IgKUl02eGOE9o3RwGEtTkcYT9ftERoRSQxGYTkF0T/32xuJ/XivV4bGXsShJNUR0uihMOdYxHieCO0wC1XxoCKGSmVsx7RFJqDa55U0I7u+X/5L6oe06tntu0rDRFMtoB+2iMnLREaqgM1RFNUTRDbpDD+jRurXurSfredqas2Yz2+gHrJcv1aCbNw==</latexit>

<latexit sha1_base64="oSoZPewt3V9J8cGB2YL+hy/DNfQ=">AAACBHicbVDLSsNAFJ3UV62vqstuBotQQULiRpcVNy4r9AVtCJPpTTt0JokzE2kJXbjxV9y4UMStH+HOv3H6WGjrgQuHc+7l3nuChDOlHefbyq2tb2xu5bcLO7t7+wfFw6OmilNJoUFjHst2QBRwFkFDM82hnUggIuDQCoY3U7/1AFKxOKrrcQKeIP2IhYwSbSS/WKqP/EzC/aRSG/rX5xhGgiQcbBqLM79YdmxnBrxK3AUpowVqfvGr24tpKiDSlBOlOq6TaC8jUjPKYVLopgoSQoekDx1DIyJAednsiQk+NUoPh7E0FWk8U39PZEQoNRaB6RRED9SyNxX/8zqpDq+8jEVJqiGi80VhyrGO8TQR3GMSqOZjQwiVzNyK6YBIQrXJrWBCcJdfXiXNC9t1bPfOKVftRRx5VEInqIJcdImq6BbVUANR9Iie0St6s56sF+vd+pi35qzFzDH6A+vzB6iul10=</latexit>



<  > example.com

<latexit sha1_base64="kAAwL60dN96Drn/sN71bk6Y6+U0=">AAAB/XicbVDJSgNBEK1xS4xbXG5eGoPgxWHGix5EIl48RjALJCH0dCpJk+6ZobtHjCHop3jxoIhX/8Ob3yD4DXaWgyY+KHi8V0VVvSAWXBvP+3Tm5hcWl1Lp5czK6tr6RnZzq6SjRDEsskhEqhJQjYKHWDTcCKzECqkMBJaD7sXQL9+g0jwKr00vxrqk7ZC3OKPGSo3sTqHbOCenh2cEb6mMBbosko1sznO9Ecgs8Sckl099fz0AQKGR/ag1I5ZIDA0TVOuq78Wm3qfKcCZwkKklGmPKurSNVUtDKlHX+6PrB2TfKk3SipSt0JCR+nuiT6XWPRnYTklNR097Q/E/r5qY1km9z8M4MRiy8aJWIoiJyDAK0uQKmRE9SyhT3N5KWIcqyowNLGND8KdfniWlI9f3XP/KpuHCGGnYhT04AB+OIQ+XUIAiMLiDR3iGF+feeXJenbdx65wzmdmGP3DefwAoOJaW</latexit>

<latexit sha1_base64="lNLLybCJYf8UWPkklXMWwkEEZyQ=">AAAB/XicbVC7SgNBFJ2Nj8T4Wh+dzWBQbFx2bbQQidhYRjAPSJYwO7mbDJnZXWZmxRiCv2JjoYit32Br5zcIfoOTR6GJBy4czrmXe+8JEs6Udt1PKzM3v7CYzS3ll1dW19btjc2KilNJoUxjHstaQBRwFkFZM82hlkggIuBQDboXQ796A1KxOLrWvQR8QdoRCxkl2khNe7vUbZ7j08MzDLdEJBwcGoumXXAddwQ8S7wJKRSz31/Jfua91LQ/Gq2YpgIiTTlRqu65ifb7RGpGOQzyjVRBQmiXtKFuaEQEKL8/un6A94zSwmEsTUUaj9TfE30ilOqJwHQKojtq2huK/3n1VIcnfp9FSaohouNFYcqxjvEwCtxiEqjmPUMIlczcimmHSEK1CSxvQvCmX54llSPHcx3vyqThoDFyaAftogPkoWNURJeohMqIojv0gJ7Qs3VvPVov1uu4NWNNZrbQH1hvP1Qal3c=</latexit>

<latexit sha1_base64="kz9xtRBnG5AmhgZz6Rq8M4MnC00=">AAAB/XicbVDLSsNAFJ34rPUVHzs3g0VwY0jc6EKk4sZlBfuANoTJ9KYdOpOEmYlYQ/FX3LhQxK3/4c6/cdpmoa0HLhzOuZd77wlTzpR23W9rYXFpeWW1tFZe39jc2rZ3dhsqySSFOk14IlshUcBZDHXNNIdWKoGIkEMzHFyP/eY9SMWS+E4PU/AF6cUsYpRoIwX2fm0QXOGLk0sMD0SkHByaiMCuuI47AZ4nXkEqqEAtsL863YRmAmJNOVGq7bmp9nMiNaMcRuVOpiAldEB60DY0JgKUn0+uH+Ejo3RxlEhTscYT9fdEToRSQxGaTkF0X816Y/E/r53p6NzPWZxmGmI6XRRlHOsEj6PAXSaBaj40hFDJzK2Y9okkVJvAyiYEb/bledI4dTzX8W7dStUp4iihA3SIjpGHzlAV3aAaqiOKHtEzekVv1pP1Yr1bH9PWBauY2UN/YH3+AJ0gk/Y=</latexit>

Get blockchain info

of binding request

(Pk

, exmaple.com, BlockInfo)

<latexit sha1_base64="633ZiNeFxpQz7Ox3vJmBYMg30Xc=">AAACB3icbVC7SgNBFL0b3/EVtRRkUAQFWXZttPTRaBfBmEAMYXZyNw6ZxzIzK4ZgZ+Mn2FnbWChi6y/Y+TdOEgtfBy4czrmXe+9JMsGti6KPoDAyOjY+MTlVnJ6ZnZsvLSyeWZ0bhhWmhTa1hFoUXGHFcSewlhmkMhFYTTqHfb96icZyrU5dN8OGpG3FU86o81KztLJR7jT3twheSZoJDJmWW+RAaNY5VqnebJbWojAagPwl8RdZ25u7u7sHgHKz9H7e0iyXqBwT1Np6HGWu0aPGcSbwunieW8wo69A21j1VVKJt9AZ/XJN1r7RIqo0v5chA/T7Ro9Larkx8p6Tuwv72+uJ/Xj136W6jx1WWO1RsuCjNBXGa9EMhLW6QOdH1hDLD/a2EXVBDmfPRFX0I8e+X/5Kz7TCOwvjEpxHCEJOwDKuwATHswB4cQRkqwOAGHuAJnoPb4DF4CV6HrYXga2YJfiB4+wSHLpnz</latexit>

<latexit sha1_base64="/spPsOHSZ6C8HEPqdk+Zky88azQ=">AAACB3icbVDLSgNBEJyNrxg1Rj0KMiiCgiy7XvQY9aK3COYBMYTZSa8ZMo9lZlYMITcvfoJ+ghcPinj1F7z5N04eB00saCiquunuihLOjA2Cby8zMzs3v5BdzC0tr+RXC2vrFaNSTaFMFVe6FhEDnEkoW2Y51BINREQcqlHnbOBXb0EbpuSV7SbQEORGsphRYp3ULGztlTrNkwMMd4IkHHyqxAE+5Yp2LmSs9puFncAPhsDTJByTnWL+cYCnUrPwdd1SNBUgLeXEmHoYJLbRI9oyyqGfu04NJIR2yA3UHZVEgGn0hn/08a5TWjhW2pW0eKj+nugRYUxXRK5TENs2k95A/M+rpzY+bvSYTFILko4WxSnHVuFBKLjFNFDLu44Qqpm7FdM20YRaF13OhRBOvjxNKod+GPjhpUvDRyNk0SbaRnsoREeoiM5RCZURRffoGb2iN+/Be/HevY9Ra8Ybz2ygP/A+fwDka5u4</latexit>

<latexit sha1_base64="RN/mO3zWkWcRRDmhXzupxD3dzC8=">AAACB3icbVDLSgNBEJz1bXytehRkMAgRwrLrRY9RL3qLYDSQLGF20huHzGOZmRVD8ObFX/HiQRGv/oI3/8bJ46CJBQ1FVTfdXUnGmbFh+O3NzM7NLywuLRdWVtfWN/zNrWujck2hRhVXup4QA5xJqFlmOdQzDUQkHG6S7tnAv7kDbZiSV7aXQSxIR7KUUWKd1PJ3S9Vu66SM4V6QjENAlSjjU65o90Km6qDlF8MgHAJPk2hMimiMasv/arYVzQVISzkxphGFmY37RFtGOTwUmrmBjNAu6UDDUUkEmLg//OMB7zuljVOlXUmLh+rviT4RxvRE4joFsbdm0huI/3mN3KbHcZ/JLLcg6WhRmnNsFR6EgttMA7W85wihmrlbMb0lmlDroiu4EKLJl6fJ9WEQhUF0GRYrwTiOJbSD9lAJRegIVdA5qqIaougRPaNX9OY9eS/eu/cxap3xxjPb6A+8zx+pDJfT</latexit>

Get blockchain info

of binding request

(Pk

, exmaple.com, BlockInfo)

2.Put Vcode

exmaple.com/

path

Visit exmaple.com/path

vcode





















[Pass]

[Not Pass]

Duration

The binding

lasts T

duration, if

there is no

report, then

the binding

completes.

rep

(Pk

,Pk

, example.com)

<latexit sha1_base64="oiK/v2m/KJchv80icjbttjQFEY0=">AAACCXicbVC7SgNBFL3rM8bXqqXNoAgRZNm10TJqYxkhL4hhmZ3c6JCZ3WVmVg1LWht/xcZCESvBP7Dzb5w8Co0euJfDOfcyc0+UCq6N7385M7Nz8wuLhaXi8srq2rq7sVnXSaYY1lgiEtWMqEbBY6wZbgQ2U4VURgIbUe9s6DduUGmexFXTT7Et6VXMu5xRY6XQJdW7MFeYDkqVXnh6QGw/OcA7KlOBHkvkfuju+p4/AvlLggnZLW/cyncAqITu52UnYZnE2DBBtW4FfmraOVWGM4GD4mWmMaWsR6+wZWlMJep2PrpkQPas0iHdRNmKDRmpPzdyKrXuy8hOSmqu9bQ3FP/zWpnpHrdzHqeZwZiNH+pmgpiEDGMhHa6QGdG3hDLF7V8Ju6aKMmPDK9oQgumT/5L6oRf4XnBh0/BgjAJsww6UIIAjKMM5VKAGDO7hEZ7hxXlwnpxX5208OuNMdrbgF5yPb4d1mws=</latexit>

<latexit sha1_base64="mW/wYPPTW0LdEhYI8QfngaEAMqI=">AAACCXicbVC7TgMxEPTxJjxyQEljgZBAik53NFDyaCiDRAApiU4+ZxOs2D7L9gHRKS0Nv0JDAUK09BR08BF8A86jgISRdjWa2ZW9kyjOjA3DT29icmp6ZnZuvrCwuLRc9FdWz02aaQoVmvJUXybEAGcSKpZZDpdKAxEJh4ukfdzzL65BG5bKM9tRUBekJVmTUWKdFPv47DbONajudrkdH5Ww64cluCVCcQhoKnZifzMMwj7wOImGZPNg5UZ8vX8Xy7H/UWukNBMgLeXEmGoUKlvPibaMcugWapkBRWibtKDqqCQCTD3vX9LFW05p4GaqXUmL++rvjZwIYzoicZOC2Csz6vXE/7xqZpv79ZxJlVmQdPBQM+PYprgXC24wDdTyjiOEaub+iukV0YRaF17BhRCNnjxOzneDKAyiU5dGgAaYQ+toA22jCO2hA3SCyqiCKLpDD+gJPXv33qP34r0ORie84c4a+gPv7QcQg5zw</latexit>

<latexit sha1_base64="vP13iUkaZCRFUnpKFcQJwf3Hj3Y=">AAACCXicbVC7TsMwFHXKq5RXgZHFokIqUhUlLDAWWBiL1JfURpHj3rRW7SSyHdQq6srCr7AwgBArf8DG3+A+Bmg50r06Oude2fcECWdKO863lVtb39jcym8Xdnb39g+Kh0dNFaeSQoPGPJbtgCjgLIKGZppDO5FARMChFQxvp37rAaRicVTX4wQ8QfoRCxkl2kh+EddHfiYhmZRrQ/+mgk2/rsCIiISDTWNx7hdLju3MgFeJuyAltEDNL351ezFNBUSacqJUx3US7WVEakY5TArdVEFC6JD0oWNoRAQoL5tdMsFnRunhMJamIo1n6u+NjAilxiIwk4LogVr2puJ/XifV4ZWXsShJNUR0/lCYcqxjPI0F95gEqvnYEEIlM3/FdEAkodqEVzAhuMsnr5Lmhe06tnvvlKr2Io48OkGnqIxcdImq6A7VUANR9Iie0St6s56sF+vd+piP5qzFzjH6A+vzB+OCmRY=</latexit>

Domain

Valid ator

1.Pk and

Domain

Name

Figure 3: Time Based Domain Authentication.

Time based Domain Process: Hypothesis

Suppose A owns key fairs and domain name e.g

example.com such that: (Pk

kSk

kDm

example.com

);

veriﬁer B with the following parameters of key fairs:

(Pk

kSk

)

Transaction Type

In this scenario, the following three types of transac-

tions are:

– Binding Transaction Request: T x

rep

(Pk

kDm

example.com

) binder issues a binding

request containing its own public key Pk

and

domain name example.com.

– Report Transaction: Tx

rep

while processing the

binding, the veriﬁcation node ﬁnds that the

binder’s authentication information is incorrect.

Transaction can be reported and rejected.

– Verify Transaction: T x

rep

reporting transaction

can be veriﬁed by the validator.

Binding Procedures. The speciﬁc process of binding

is shown in Figure 3, which includes the following

steps:

• A Publishes the binding transaction T x

req

(Pk

,example.com) to the blockchain.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

348

• Validator B accesses the domain name to verify

that A operates correctly. If not, sends a report

transaction T x

rep

,Pk

,example.com) to the

blockchain.

• After A maintains the veriﬁcation time T, the veri-

ﬁcation service can be stopped and the binding is

completed.

3.3.2 Authentication Veriﬁcation based on

Count

In count based authentication system veriﬁcation pro-

cess reaches the speciﬁed number of counts to com-

plete the identity binding as shown in ﬁgure 4.



req

(Pk

, exmaple.com)



<  > example.com





1.Pk and

Domain Name

(Pk

, exmaple.com, BlockInfo)





(Pk

, exmaple.com, BlockInfo)

2.Put Vcode

exmaple.com/

path



vcode

3.According

to the info of

Binding

request,

generate path

and Chal,

then compare

the Vcode

with Chal.

4.Verify

correctness of

Vcode

[Pass] 



[Not Pass]

rep

(Pk

,Pk

, example.com)

vf y

(Pk

,Pk

,Vcode)

<latexit sha1_base64="IjYSslm8KxWZdg3YQoCxZC/YShc=">AAACBHicbVC7SgNBFL0bXzG+Ei3TDAYhQlh2bbSM2lhGyAuSsMzOziZDZh/MzEbDksLGX7GxUMRW/AY7/8bJo9DEA/dyOOdeZu5xY86ksqxvI7O2vrG5ld3O7ezu7R/kC4dNGSWC0AaJeCTaLpaUs5A2FFOctmNBceBy2nKH11O/NaJCsiisq3FMewHuh8xnBCstOfli/d5JR/54Uq4NnasK0v2ygpok8uipky9ZpjUDWiX2gpSqhbvgEwBqTv6r60UkCWioCMdSdmwrVr0UC8UIp5NcN5E0xmSI+7SjaYgDKnvp7IgJOtGKh/xI6AoVmqm/N1IcSDkOXD0ZYDWQy95U/M/rJMq/6KUsjBNFQzJ/yE84UhGaJoI8JihRfKwJJoLpvyIywAITpXPL6RDs5ZNXSfPMtC3TvtVpmDBHFopwDGWw4RyqcAM1aACBB3iCF3g1Ho1n4814n49mjMXOEfyB8fEDOGWYnw==</latexit>

<latexit sha1_base64="GfbKdyHQRd/xXKxenTPWwZfW4Bc=">AAACBHicbVC7TsMwFHV4lvJoCmMXiwqpSFWUsMBYYGEsUl9SG0WO47RWnYdspxBFHVj4FRYGEGLlExjY4CP4BtzHAC1HuldH59wr+x43ZlRI0/zUVlbX1jc2c1v57Z3dvYJe3G+JKOGYNHHEIt5xkSCMhqQpqWSkE3OCApeRtju8nPjtEeGCRmFDpjGxA9QPqU8xkkpy9FLj1slGfjqu1IfORRWqfl6FLRx55NjRy6ZhTgGXiTUn5VrxJvh6/y7UHf2j50U4CUgoMUNCdC0zlnaGuKSYkXG+lwgSIzxEfdJVNEQBEXY2PWIMj5TiQT/iqkIJp+rvjQwFQqSBqyYDJAdi0ZuI/3ndRPpndkbDOJEkxLOH/IRBGcFJItCjnGDJUkUQ5lT9FeIB4ghLlVtehWAtnrxMWieGZRrWtUrDADPkQAkcggqwwCmogStQB02AwR14AE/gWbvXHrUX7XU2uqLNdw7AH2hvP8FkmoQ=</latexit>

<latexit sha1_base64="AlT67TtNe56+UQN7xMgjTXY63pY=">AAACBHicbVC7TsMwFHV4lvIKMHaxqJCKVEUJC4wFFsYi9SW1UeQ4TmvVcSLbqYiiDiz8CgsDCLHyEWz8DW6bAVqOdK+OzrlX9j1+wqhUtv1trK1vbG5tl3bKu3v7B4fm0XFHxqnApI1jFouejyRhlJO2ooqRXiIIinxGuv74duZ3J0RIGvOWyhLiRmjIaUgxUlryzErrwcsnYTatNcfeTR3qfl2HHRwH5Nwzq7ZlzwFXiVOQKijQ9MyvQRDjNCJcYYak7Dt2otwcCUUxI9PyIJUkQXiMhqSvKUcRkW4+P2IKz7QSwDAWuriCc/X3Ro4iKbPI15MRUiO57M3E/7x+qsIrN6c8SRXhePFQmDKoYjhLBAZUEKxYpgnCguq/QjxCAmGlcyvrEJzlk1dJ58JybMu5t6sNq4ijBCrgFNSAAy5BA9yBJmgDDB7BM3gFb8aT8WK8Gx+L0TWj2DkBf2B8/gCUcpaq</latexit>

VerifyCount:0

<latexit sha1_base64="KcXGJ/eGiivwE7azqnvJe3ecod8=">AAAB9HicbVDLSgNBEOz1lRhfUY9eBoPgadn1ongK5OIxgnlAsoTZyWwyZHZmnZkNLEvAv/DiQRGvfow3v0HwG5w8DppY0FBUddPdFSacaeN5n87a+sbmVqG4XdrZ3ds/KB8eNbVMFaENIrlU7RBrypmgDcMMp+1EURyHnLbCUW3qt8ZUaSbFnckSGsR4IFjECDZWCppUsSiryVSYa69XrniuNwNaJf6CVKqF768HAKj3yh/dviRpTIUhHGvd8b3EBDlWhhFOJ6VuqmmCyQgPaMdSgWOqg3x29ASdWaWPIqlsCYNm6u+JHMdaZ3FoO2NshnrZm4r/eZ3URFdBzkSSGirIfFGUcmQkmiaA+kxRYnhmCSaK2VsRGWKFibE5lWwI/vLLq6R54fqe69/aNFyYowgncArn4MMlVOEG6tAAAvfwCM/w4oydJ+fVeZu3rjmLmWP4A+f9B/55lGw=</latexit>

<latexit sha1_base64="XupeiMK/ORWONMo4A1UtaBGQWtY=">AAAB9HicbVC7SgNBFL0bH4nxFbW0GQyKVdi1UawCaSwjmAckS5idzCZDZmfWmdnAsuQ7bCwUsfU/bO38BsFvcPIoNPHAhcM593LvPUHMmTau++nk1tY3NvOFreL2zu7efungsKlloghtEMmlagdYU84EbRhmOG3HiuIo4LQVjGpTvzWmSjMp7kwaUz/CA8FCRrCxkt+kioVpTSbCXLu9UtmtuDOgVeItSLma//6Kz3Lv9V7po9uXJImoMIRjrTueGxs/w8owwumk2E00jTEZ4QHtWCpwRLWfzY6eoFOr9FEolS1h0Ez9PZHhSOs0CmxnhM1QL3tT8T+vk5jwys+YiBNDBZkvChOOjETTBFCfKUoMTy3BRDF7KyJDrDAxNqeiDcFbfnmVNC8qnlvxbm0aFZijAMdwAufgwSVU4Qbq0AAC9/AAT/DsjJ1H58V5nbfmnMXMEfyB8/YDKmqVTQ==</latexit>

<latexit sha1_base64="V3gSUy5lgYf9IUZ+A1dUtwll2no=">AAAB9HicbVBNSwMxEM36WetX1aOXYBE8LVkviqdCLx4r2A9ol5JNZ9vQbLIm2cJS+ju8eFDEqz/Gm//GtN2Dtj4YeLw3w8y8KBXcWEK+vY3Nre2d3dJeef/g8Oi4cnLaMirTDJpMCaU7ETUguISm5VZAJ9VAk0hAOxrX5357AtpwJR9tnkKY0KHkMWfUOilsgeZxXleZtHekX6kSnyyA10lQkCoq0OhXvnoDxbIEpGWCGtMNSGrDKdWWMwGzci8zkFI2pkPoOippAiacLo6e4UunDHCstCtp8UL9PTGliTF5ErnOhNqRWfXm4n9eN7PxbTjlMs0sSLZcFGcCW4XnCeAB18CsyB2hTHN3K2YjqimzLqeyCyFYfXmdtK79gPjBA6nW/CKOEjpHF+gKBegG1dA9aqAmYugJPaNX9OZNvBfv3ftYtm54xcwZ+gPv8wdzcJHM</latexit>





<  > example.com

VerifyCount:0

When n

validators

confirm the

binding

request,

domain

completes the

binding of Pk

and Domain

name

 

Figure 4: Count Based Domain Authentication Framework.

Count-based Domain Process: Hypothesis. Sup-

pose A owns key fairs and domain name example.com

such that: (Pk

kSk

kDm

example.com

); veriﬁer B owns

key fairs: (Pk

kSk

Transaction Type. In count based the transaction

veriﬁcation process includes the followings:

– Binding Transaction Request:

(Pk

kDm

example.com

) binder issues a binding

request containing its own public key and domain

name example.com.

– Reporting Transaction: T x

rep

if the veriﬁcation

node ﬁnds that the binding information is not ac-

curately placed then identity binding can be re-

jected.

– Veriﬁcation Transaction: T x

v f y

validator com-

pletes the comparison of the veriﬁcation informa-

tion, the validator sends the transaction that has

passed the veriﬁcation process.

Binding Process

Authentication process based on the number of

validations require more interaction between the val-

idators and the blockchain than time based.

• A Publishes binding transaction T

xreq

(Pk

,kexample.com) on the blockchain.

• A gets the block information In f o

block

of the lo-

cation where T x

rep

is located, and calculates its

value (Path,Chal) = F(In f o

rcv

Block) to put it un-

der domain control.

• B obtains the veriﬁcation content from exam-

ple.com/Path, submits the transaction Tx

v f y

(Pk

Pk A, Vcode) to complete the certiﬁcate veriﬁca-

tion. Once the K has been veriﬁed, the binding is

complete. The entire process same as time-based

requiring the binder to publish her public key Pk

domain name example.com onto the blockchain.

3.4 Misbehaviour Incentives

In order to encourage enough veriﬁcation nodes to

join the system, rewards should be given to the ver-

iﬁcation nodes. As shown in table 1:

First Rule In table 1, fee is deposited by the ini-

tiator, instead of unlimited arbitrary identity binding

operations; thus avoiding malicious adversary to

initiate unlimited invalid identity binding. Second

rule prevent the veriﬁcation node from randomly

initiating a reporter transaction to disrupt the com-

pleteness of the normal binding; The third rule node

that incentivises the veriﬁcation operation to attract

more nodes, but needs to deposit a fee to prevent

some nodes from misbehaving Fourth rule same as

third rule attract more nodes to join the system.

Property 3: Denial Binding Analysis. We assume

when binding authentication request is initiated, iden-

tity binding is completed after waiting for the valida-

tor to complete the veriﬁcation. However, in case ma-

licious attacker may disrupt the binding. The proba-

bility of successfully disrupting this request is shown

below:

Pr denial =

∏

i = 0

n/2

qN −i

N −i

(1)

Property 4: Sybil Attack. Blockchain is built based

on open P2P network any node can generate number

of identities to increase the probability as veriﬁcation

node. Therefore, additional information is required

including a veriﬁable workload certiﬁcate.

Security Comparison of the PKI Authentication

system as describe in table 2.

AuthLedger: A Novel Blockchain-based Domain Name Authentication Scheme

349

Table 1: Table describe incentive parameters.

Txt. Name Initiator PK Txt. Def. Txt. Fee Incentives Balance

T x

rep

Domain Name Pk

Binding

Identity

-P

0 Balance (Pk

) -P

T x

rep

Reporter Pk

Reporting -P

= P

Balance (Pk

T X

v f y1

Validator Pk

Validation -P

Balance (Pk

) +

T X

v f y2

Validator Pk

Conﬁrm -P

Balance (Pk

Table 2: Table describe security comparison of the proposed system.

DNSSEC-DANE CAA AuthLedger

Level of Trust Weak Weak Strong

50% attack protection N/A N/A Strong

Sybil attack protection N/A N/A Strong

Fake binding detection Weak Weak Strong

Domain compromise Strong Strong weak

Misbehaviour Incentives Weak Weak Strong

Browser validation Weak Weak Strong

Domain Server Perspective. includes the following

properties:

Property 1: We assume most of the Certiﬁcate author-

ities and validating authorities are malicious which

act arbitrarily such as binding fake certiﬁcate or cer-

tiﬁcate can be issued from invalid CA. We assume that

Domain name server (DNS) are corrupted.

Property 2: Browser client. Additional checks need

to be conducted from the client side to make sure any

certiﬁcate issued by adversary is detected. Therefore

browser need to interact with Blockchain to query

whether the received certiﬁcate is granted by a trusted

CA.

4 EVALUATION

4.1 Implementation Prototype

Entities involve in the implementation process in-

clude the followings: 1. User: domain sends identity

binding request and update trusted CA list to interact

interface in the Blockchain. 2. Relying Party: rely-

ing party obtains a certiﬁcate through a browser and

establishes secure communication, it needs to check

the validity of the certiﬁcate through Blockchain by

query trusted CA list. 3. Veriﬁcation Nodes: verify

any domain name initiated authentication requests on

the blockchain. Also veriﬁcation node needs to mon-

itor and report any misbehaviour during veriﬁcation

process. 4. Full node: Monitor all transactions in the

Blockchain network. Each time a block is created,

the initiator will get the reward corresponding to the

proportion of the computational power use. Figure 5

Relying

Party

Interface

Key management

Put the

veriﬁcation

Get veriﬁcation data

Conﬁrmation

Request

Domain name

Send binding request

Modify trusted CA list

Get certiﬁcate

Query trusted CA list

Browser extension plug-in

Users

Key Magmt.

Validator client

Veriﬁcation Nodes

Blockchain

Identity binding interface

Conﬁrm interface

Report interface

Modify trusted CA list

interface

Query trusted CA list

interface

Full

nodes.

Blocks

Modify

Read

Modify

Read

Figure 5: System Architecture.

describe the system architecture of the proposed sys-

tem.

4.2 Smart Contract Solidity

All entities in the proposed system need to be con-

nected through a blockchain. The functions in the

smart contract include the followings:

The domain name authentication function: When

the domain name calls this function, a series of veriﬁ-

cation nodes are selected to complete the veriﬁcation

through the veriﬁcation node.

Trusted list storage: Update the data stored in the

smart contract and complete the control of its own

trusted CA.

Trust list query: complete the query of the trusted

CA list of a speciﬁc domain name.

Implementation of these modules relies on

Ethereum smart contract to perform the functions of

the above interfaces using Solidity programming

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

350

Table 3: Trade execution cost.

Name of Trade Send Data Tx. Fee

(Gas)

Impl.

Cost

(Gas)

TTL Cost

(Gas)

Price ($)

Binding re-

quest

,example.com 189451 165555 355006 1.977

Veriﬁcation op-

eration

,example.com,

code

208475 197342 405 817 2.26

Modify trust

list operation

”CA List” 36906 14674 51580 0.287

language. Moreover, Solidity is used to complete

the mapping between the Ethereum contract address

and the domain name. Sample code for interactions

describe below.

struct Domain {

string name;

uint count;

string trustCAs;

uint stBlock;

address[] validator;

address addr;

bool isEntity;

}

mapping(address => Domain)reg\_domain;

mapping(string => Domain)auth\_domain;

uint constant auth\_times = 10;

uint constant limit\_blocks = 100;

Meanwhile based on the the underlying

blockchain platform, transactions that cause any

changes in the Ethereum blockchain need to con-

sume so-called Gas. In order to call transaction on

ethereum smart contract, the transaction needs to be

sent to the blockchain ﬁrst. The required cost is called

transaction costs, which is calculated according to

the large size of the data. While execution cost, it

needs to be based on the calculation of the transaction

to perform cost assessment. The current Gas station

estimate is : 1 gas = 3 Gwei

. The cost of the binding

and trust list modiﬁcation for example.com describe

below:

4.3 Browser Plug-in Validation

Browser Selection. The main operation of plug-in

is to obtain the trust CA list of the domain name in

the blockchain and and compares with the certiﬁcate

issuer.

4.4 Experiment

In order to test the performance of the proposed sys-

tem, we used Ali Cloud server conﬁguration is as fol-

https://ethgasstation.info/

Verifying nodes

Blockchain network

Relaying party

Domain server

Figure 6: System conﬁguration.

lows: CPU: 1 core, Operating System: Ubuntu 16.04

(64 bit), Memory: 2GB, Disk: 40GB, Golang: 1.8.

and Ethereum: Titanium (v1.8.7). Meanwhile ma-

chine conﬁguration we used, CPU: 8 cores, Operat-

ing System: macOs High Sierra (version 10.13.3) and

Chrome: Version 66.0.3359.139 (64-bit).

Blockchain network contain ﬁve Ali cloud

servers: full node; to complete the blockchain

maintenance network; the other ﬁve servers as the

authentication nodes, each server starts 10 au-

thentication clients, a total of 50 authentication nodes;

one Ali cloud deploys web services as a domain name

server and runs the domain name guest. The local

PC acts as a relying party, simulates the access to

the domain name and completes the acquisition of the

trusted CA list.

5 CONCLUSION AND FUTURE

WORK

In this paper, we proposed AuthLedger a novel

Blockchain-based domain name authentication

scheme using Ethereum smart contract to allows a

client to trust which CA can issue a certiﬁcate for

the domain using Blockchain technology. The paper

demonstrated an efﬁcient and trustworthy algorithm

for certiﬁcate authentication process. we also analyze

security implication of the proposed scheme by

discussing different security threats and countermea-

AuthLedger: A Novel Blockchain-based Domain Name Authentication Scheme

351

sures. Moreover, since this is a short paper, future

work will concentrate on detail implementation of the

AuthLedger to get more experimental results. Will

conduct a detailed performance and usability analysis

of the proposed system.

REFERENCES

Aishwarya, C., Raghuram, M., Hosmani, S., Sannidhan,

M., Rajendran, B., Chandrasekaran, K., and Bindhu-

madhava, B. (2015). Dane: An inbuilt security ex-

tension. In Green Computing and Internet of Things

(ICGCIoT), 2015 International Conference on, pages

1571–1576. IEEE.

Ali, M., Nelson, J. C., Shea, R., and Freedman, M. J.

(2016). Blockstack: A global naming and storage sys-

tem secured by blockchains. In USENIX Annual Tech-

nical Conference, pages 181–194.

Berkowsky, J. A. and Hayajneh, T. (2017). Security issues

with certiﬁcate authorities. In Ubiquitous Computing,

Electronics and Mobile Communication Conference

(UEMCON), 2017 IEEE 8th Annual, pages 449–455.

IEEE.

Gourley, S. and Tewari, H. (2018). Blockchain backed

dnssec. In 1st Workshop on Blockchain and Smart

Contract Technologies - 21st International Confer-

ence on Business Information Systems, Fraunhofer

FOKUS, Berlin, 18-20 July, 2018, pages 357–388.

Fraunhofer FOKUS, Berlin.

Hari, A. and Lakshman, T. (2016). The internet blockchain:

A distributed, tamper-resistant transaction framework

for the internet. In Proceedings of the 15th ACM

Workshop on Hot Topics in Networks, pages 204–210.

ACM.

Kalodner, H. A., Carlsten, M., Ellenbogen, P., Bonneau,

J., and Narayanan, A. (2015). An empirical study

of namecoin and lessons for decentralized namespace

design. In WEIS. Citeseer.

Kamat, P. and Gautam, A. S. (2018). Recent trends in the

era of cybercrime and the measures to control them.

In Handbook of e-Business Security, pages 243–258.

Auerbach Publications.

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

dns and pki solutions. IEEE Communications Stan-

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

Khan, S., Zhang, Z., Zhu, L., Li, M., Saﬁ, K., Gul, Q., and

Chen, X. (2018). Accountable and transparent tls cer-

tiﬁcate management: An alternate public-key infras-

tructure with veriﬁable trusted parties. Security and

Communication Networks, 2018.

Kiayias, A., Russell, A., David, B., and Oliynykov, R.

(2017). Ouroboros: A provably secure proof-of-stake

blockchain protocol. In Annual International Cryptol-

ogy Conference, pages 357–388. Springer.

Kubilay, M. Y., Kiraz, M. S., and Mantar, H. A.

(2018). Certledger: A new pki model with certiﬁ-

cate transparency based on blockchain. arXiv preprint

arXiv:1806.03914.

Matsumoto, S. and Reischuk, R. M. (2016). Ikp: Turning a

pki around with blockchains. IACR Cryptology ePrint

Archive, 2016:1018.

Matsumoto, S., Reischuk, R. M., Szalachowski, P., Kim,

T. H.-J., and Perrig, A. (2017). Authentication chal-

lenges in a global environment. ACM Transactions on

Privacy and Security (TOPS), 20(1):1.

Qin, B., Huang, J., Wang, Q., Luo, X., Liang, B., and Shi,

W. (2017). Cecoin: A decentralized pki mitigating

mitm attacks. Future Generation Computer Systems.

Rashid, F. Y. (2015). Google threatens action against

Symantec-issued certiﬁcates following botched inves-

tigation.

Scheitle, Q., Chung, T., Hiller, J., Gasser, O., Naab, J., van

Rijswijk-Deij, R., Hohlfeld, O., Holz, R., Choffnes,

D., Mislove, A., et al. (2018). A ﬁrst look at certiﬁ-

cation authority authorization (caa). ACM SIGCOMM

Computer Communication Review, 48(2):10–23.

Sehgal, A. and Dixit, A. (2019). Securing web access—dns

threats and remedies. In Emerging Trends in Expert

Applications and Security, pages 337–345. Springer.

Shulman, H. and Waidner, M. (2017). One key to sign them

all considered vulnerable: Evaluation of dnssec in the

internet. In NSDI, pages 131–144.

Wang, Z., Lin, J., Cai, Q., Wang, Q., Jing, J., and Zha, D.

(2018). Blockchain-based certiﬁcate transparency and

revocation transparency. Financial Cryptography and

Data Security. Springer International Publishing.

Yakubov, A., Shbair, W., Wallbom, A., Sanda, D., et al.

(2018). A blockchain-based pki management frame-

work. In The First IEEE/IFIP International Work-

shop on Managing and Managed by Blockchain

(Man2Block) colocated with IEEE/IFIP NOMS 2018,

Tapei, Tawain 23-27 April 2018.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

352