Conference PaperPDF Available

BlockVoke -Fast, Blockchain-Based Certificate Revocation for PKIs and the Web of Trust

Authors:

Abstract and Figures

A reliable certificate revocation mechanism is crucial, as illustrated by the recent revocation of 1.7 million certificates issued by the Let's Encrypt certificate authority. It is just as essential to get revocation information to users in an efficient and timely manner without impacting their privacy. Existing approaches such as Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP) fail with respect to either of those metrics, while approaches that try to mitigate both, such as OCSP-Staple and Must-Staple suffer from soft-failure modes and meager adoption rates. To address these issues, we propose the BlockVoke scheme, which decentralizes revocations, allowing certificate owners as well as CAs to revoke certificates, and distribute revocation information rapidly. Our approach furthermore allows the revocation of CA root certificates, which is not possible with traditional approaches. The use of a blockchain as an underlying layer ensures the continued availability and immutability of revocation information. Block-Voke interacts favorably with approaches such as CRLite and Certificate Revocation Vectors (CRV), allowing organizations to update revocation filters with as little delay as required by their security policies. We also demonstrate the cost-efficiency of our approach in comparison to other approaches such as CRLs, showing its high feasibility.
Content may be subject to copyright.
BlockVoke – Fast, Blockchain-Based
Certificate Revocation for PKIs
and the Web of Trust
Abba Garba1,ArneBochem
2(B
),andBenjaminLeiding
2
1School of Electronics Engineering and Computer Science,
Peking University, Beijing, China
abbaggumel@pku.edu.cn
2Institute of Computer Science,
University of Goettingen, Goettingen, Germany
arne.bochem@cs.uni-goettingen.de, benjamin.leiding@tu-clausthal.de
Abstract. Areliablecerticaterevocationmechanismiscrucial,as
illustrated by the recent revocation of 1.7 million certificates issued by
the Let’s Encrypt certificate authority. It is just as essential to get revo-
cation information to users in an ecient and timely manner without
impacting their privacy. Existing approaches such as Certificate Revo-
cation Lists (CRLs) or the Online Certificate Status Protocol (OCSP)
fail with respect to either of those metrics, while approaches that try to
mitigate both, such as OCSP-Staple and Must-Staple suer from soft-
failure modes and meager adoption rates. To address these issues, we
propose the BlockVoke scheme, which decentralizes revocations, allow-
ing certificate owners as well as CAs to revoke certificates, and distribute
revocation information rapidly. Our approach furthermore allows the
revocation of CA root certificates, which is not possible with traditional
approaches. The use of a blockchain as an underlying layer ensures the
continued availability and immutability of revocation information. Block-
Voke interacts favorably with approaches such as CRLite and Certificate
Revocation Vectors (CRV), allowing organizations to update revocation
filters with as little delay as required by their security policies. We also
demonstrate the cost-eciency of our approach in comparison to other
approaches such as CRLs, showing its high feasibility.
Keywords: PKI ·Blockchain ·Certificate ·Revocation ·Web of Trust
1Introduction
Nowadays, Internet services and applications, such as e-commerce websites and
e-mail communication or messaging services, are not only essential to our daily
life, but also become more common and popular due to the progressing digitiza-
tion of society, e.g., [21] and [46]. X.509 certificates are used to secure those web
applications and ensure their authenticity, integrity, and confidentiality. Public
c
Springer Nature Switzerland AG 2020
W. Susilo et al. (Eds.): ISC 2020, LNCS 12472, pp. 315–333, 2020.
https://doi.org/10.1007/978-3-030-62974-8_18
316 A. Garba et al.
key infrastructures (PKIs) ensure the correct association between a certificate
and its owner. The trust model of PKIs relies on hierarchically structured central
authorities [39], whereas the PGP Web of Trust (WoT) builds on a decentralized
structure [27]. The vulnerability induced by the centralized and intransparent
structure of CAs regularly results in security incidents [4,9]. Meanwhile, the
PGP WoT is decentralized and does not suer from these vulnerabilities. Yet,
the PGP WoT does neither provide sucient certainty that the information
stated in a public key (certificate) is correct, since users do not carefully verify
them due to missing incentives or lack of punishments, nor is it resilient to Sybil
node attacks [33].
Certificates expire after a pre-determined lifetime. However, security inci-
dents or other events require a certificate revocation before its expiry date. A
certificate may be revoked after its corresponding private key is compromised,
the identification of a flaw in the underlying cryptographic system, or due to
issues related to internal PKI processes.
Recently, the non-profit CA Let’s Encrypt (LE) announced the revocation of
3,048,289 certificates due to a bug in their Certification Authority Authorization
(CAA) software – the so-called LE CAA rechecking bug [10,24,25]. Ultimately,
only 1,706,950 certificates were revoked, and the remaining certificates were left
to expire within the subsequent 90 days.
Even though WoT revocations do not depend on a CA, any revocation has to
be propagated within the network. This is done by a set of distributed peer-to-
peer (P2P) keyservers which synchronize with each other. However, due to their
limited number and reoccurring reliability issues, they potentially pose risks to
organizations relying on them [20,28].
Several mechanisms for certificate revocation exist such as Certificate Revo-
cation Lists (CRLs) [14], the Online Certificate Status Protocol (OCSP) [43],
or OCSP extensions such as OCSP stapling [15] and OCSP Must-Staple [19].
Nonetheless, due to their centralized nature, these revocation mechanisms inherit
the same security concerns as the general PKI concept itself, e.g., single point
of failure (SPOF).
Alternative decentralized and more transparent alternatives – for both, PKIs
in general as well as the WoT – exist and are being tested, e.g., [12,18,30,45], but
are not widely used yet and suer from dierent disadvantages such as scalability
issues, privacy leaks, eciency deficits or low security guarantees.
Relying on CAs or WoT keyservers as gatekeepers to crucial information
such as certificate revocation data poses a risk not only to the everyday user,
but especially to big organizations with large IT-systems and thousands of users.
For them, a secure and timely revocation notification channel for X.509 certifi-
cates that does not impact user privacy is important. Therefore, a research gap
exists with respect to the design of such a system. This work fills the detected
gap and investigates the research question of how to enable secure, timely and
privacy preserving certificate revocation. Our proposed scheme is, in addition,
also decentralized, transparent, scalable and ecient. The proposed BlockVoke
scheme addresses these issues by rapidly distributing revocation information and
BlockVoke – Blockchain-Based Certificate Revocation 317
decentralizing revocations, allowing certificate owners as well as CAs to revoke
certificates.
An instantiation of our scheme is explained using the Bitcoin blockchain and
1-of-2 threshold multi-signature addresses [1], which, once created using certifi-
cate specific public keys from both the certificate owner and the CA, will allow
either party to create a transaction on the blockchain revoking the certificate.
The remainder of this paper is structured as follows: Sect. 2introduces supple-
mentary literature and related work. Section3focuses on the functional details
of BlockVoke as a transparent and accountable certificate revocation mechanism,
while Sect. 4details specific properties as well as engagement processes. After-
wards, Sect. 5evaluates BlockVoke and discusses the findings. Finally, Sect. 6
concludes this work and provides an outlook on future work.
2SupplementaryLiteratureandRelatedWork
This section provides background information, supplementary literature, and
also introduces related work with previous approaches to solving the issue of
certificate revocation.
2.1 Certificate Revocation Mechanisms
Certificates expire after a pre-determined lifetime. However, security incidents
or other events may require a certificate revocation before its expiry date, e.g.,
after its corresponding private key is compromised, the identification of a flaw
in the underlying cryptographic system, due to an insecure key length, or due to
issues related to internal PKI processes [24]. Compromised PGP keys or X.509
certificates enable an attacker to access initially secured data or perform MITM
attacks [45]. CAs revoke certificates by issuing a signed revocation statement – as
a cryptographic proof – using their private key. Additionally, the CA ensures the
distribution of the revocation statement. In the context of the WoT, revocations
do not depend on a CA. Instead, the certificate owner revokes the certificate and
posts a corresponding revocation message to the PGP keyservers.
The most common X.509 certificate revocation mechanisms are illustrated in
Fig. 1and described in subsequent sections.
Certificate Revocation Lists (CRLs) are signed records of all revoked – but
not expired – certificates of a specific CA based on the certificates’ serial number
[14]. Certificates listed in a CRL are not trusted by any browser. However, CRLs
are criticized as not being ecient at dispersing the revocation information for
several reasons: First, clients are only interested in the validity of a single cer-
tificate – yet, they have to download the complete CRL. Second, each CA main-
tains its own CRL instead of a single global CRL for all CAs. Third, delays occur
between certificate revocation and adding the certificate to the CRL, resulting in
browsers trusting the certificate despite its revocation. Fourth, large numbers of
revocations, as illustrated by our initial Let’s Encrypt incident example, result
318 A. Garba et al.
CRL OCSP
OCSP
OCSP OCSP
OCSP
OCSP
1213
2
1
2
12
CA
Web Server CA
Web Server CA
Web Server CA
Web Server
Client Client Client Client
a) CRL c) OCSP-Staple d) OCSP Must-Staple
b) OCSP
Fig. 1. Certificate Revocation Mechanisms: [a] CRLs: The browser retrieves a signed
list of revoked certificates from the CA during the SSL/TLS negotiation; [b] OCSP:
The client requests the revocation status of a single certificate from the CA; [c] OSCP
stapling: The web server communicates with the CA to periodically receive signed
statements which prove that the corresponding certificate has not been revoked yet.
Alternatively, [b] serves as a fallback; [d] OCSP must-staple enforces [c] by removing
the fallback option [b]. If no valid OCSP response is available, the browser discards the
certificate; – Based on [13] and [45]
in large CRLs, which lead to additional latency and communication overhead
while loading websites [36].
Online Certificate Status Protocol (OCSP) addresses the CRL overhead
issue by allowing clients to query the CA directly and requesting the status
of a particular certificate instead of downloading the whole CRL [43]. The CA
responds by sending a signed response along with the current certificate’s sta-
tus (revoked, not-revoked, or unknown) along with the validity period of the
certificate. Even though OCSP reduces the amount of transferred data, it still
results in additional overhead since the CA has to be queried before trusting the
certificate [13]. Moreover, delays between revoking a certificate and listing the
certificate as revoked still occur [3].
In addition to the previously known issues, OCSP introduces a privacy issue.
The CA can profile clients by correlating their browser activities based on the
IP address with the requested certificates.
OCSP Stapling –alsoknownasTLS Certificate Status Request –addresses
OCSP’s communication overhead with the CA as well as the privacy issue men-
tioned above [15]. Instead of the client sending an OCSP request to the CA, the
web server serving a certificate periodically requests the most-recent certificate
revocation status updates from the CA. The CA responds with a signed state-
ment for the certificates of the requesting web server, additionally stapling a
cryptographic proof to the certificate, which is then presented to a client during
the TLS/SSL negotiations. The CA’s signed statement is only valid for a pre-
defined period and thus cannot be used indefinitely by a malicious web server.
As a result, OCSP stapling reduces communication overhead and addresses the
BlockVoke – Blockchain-Based Certificate Revocation 319
Fig. 2. General Blockchain Structure – Based on [37]
issue of CAs profiling clients based on their browsing activities. In case a web
server cannot provide an OCSP staple proof, the client can still fallback to nor-
mal OCSP.
Nevertheless, OCSP stapling still does not solve all issues of certificate revo-
cation. For example, CAs operate using a hierarchical trust model where a root
CA signs the certificate of a sub-ordinate CA, and so on. Neither OCSP nor
OCSP stapling incorporates the revocation status for the end-entity certificate.
An extension proposal exists to address this limitation by allowing the server
to incorporate multiple certificate statuses in a single response, although this
approach is not widely adopted [40].
Finally, the OCSP stapling Must Staple Extension enforces the existence of
a valid OCSP response to be presented by the web server – otherwise, TLS/SSL
negotiations are aborted. Furthermore, the OCSP protocol also enforces the
Must Staple Extension and addresses attack scenarios where an attacker is able
to block clients’ OCSP requests or web server OCSP requests forcing them to
fallback to less secure certificate validation mechanisms. However, according to
[13], out of 500,000,000 certificates tested in 2018 only 0.02% supported the
OCSP Must Staple Extension.
2.2 Blockchain Technology
Figure 2presents the general structure of a blockchain and subsequently blocks
as used by, e.g., the Bitcoin [37], or Ethereum blockchains [47]. A blockchain con-
sists of a sequentially ordered number of blocks that record transaction events,
e.g., transfer of a cryptocurrency from one person to another. Transactions are
cryptographically signed and represent an incremental list of records, consistent
over the network, time-stamped, and verifiable [37]. Blocks are linked by hashes
of their previous ancestor block, thereby chaining all blocks together. As a result,
changing information in one block, results in a hash mismatch of the succeeding
block. Thus, tampering with one block requires the recalculation of all succeeding
blocks. Blocks are publicly available and synchronized via a global, distributed,
and decentralized P2P storage system.
The technological foundations of blockchains result in properties relevant for
secure, transparent, ecient, and decentralized certificate revocation. i) Decen-
tralization: Data is stored and processed in a decentralized and distributed man-
ner. Consensus is determined by the majority of network participants based on
320 A. Garba et al.
the conformity of the network rules. ii)Immutability:Conrmedtransactions
are appended to the blockchain. Once recorded, transactions cannot be changed
later on. Furthermore, they are tamper-resistant and prevent unnoticed manip-
ulation of data. iii)Transparency:Informationstoredonapublicblockchainis
globally available and provides transparency to all users. iv) Openness: The P2P
network is open; anyone can join or leave the network at any time. v)Security:
Security of blockchains is achieved based on cryptographically signed statements
and information in conjunction with the distributed and decentralized consensus
mechanism as well as redundant and transparent P2P data storage.
2.3 Related Work
Besides the general revocation mechanisms presented in the previous section,
many more exist and have been proposed in earlier research. In the context of
traditional PKI-related revocation, systems such as Certificate Revocation Trees
[29]andCerticateRevocationSystems[38] exist, while non-research organiza-
tions and entities proposed solutions such as CRLset [23]. Especially the latter
two suer from bandwidth and latency problems and require the client to fetch
revocation details from pre-defined servers [22].
Larisch et al. [31] propose CRLite, a revocation mechanism that “aggregates
revocation information for all known, valid TLS certificates on the web, and
stores them in a space-ecient filter cascade data structure” [31] based on Bloom
Filters. The system is implemented in Firefox nightly and is distributed to all
browsers with small (580KB) daily updates. However, the system is prone to
single point of failure attacks since it relies on a centralized system design. Due
to being updated daily, there is also a certain amount of latency between the
revocation of certificates and users receiving these revocations.
Besides the classical centralized approaches, various decentralized solutions
using blockchain technology emerged in recent times. CertLedger [30]isa
blockchain-based PKI which records the complete SSL/TLS certificate lifecycle
on the blockchain, including issuance, validation, and revocation of certificates,
thereby circumventing SPOF issues as well as transparency-related drawbacks
of previous systems. However, CertLedger operates its specialized blockchain,
which incurs significant growth in storage (ca. 512GB per year), resulting in
storage and network communication overhead. Moreover, clients do not store
the complete blockchain and only access block headers. Thus, they cannot con-
firm whether they receive a proof referring to the most recent revocation state
of a certificate without making a request to a full node, which might lie. Finally,
operating their special-purpose blockchain implies that CertLedger cannot lever-
age security guarantees of established public blockchain platforms.
Yakubov et al., [48]andFromknechtetal.[18], propose further blockchain-
based models for issuing, revoking, and validating X.509 digital certificates. The
proposed models manage the entire certificate lifecycle via a blockchain. While
Yakubov et al. rely on Ethereum-based smart contracts, Fromknecht et al. use
Namecoin, which is based on Bitcoin. Similarly, CertChain [12]implementsa
X.509 digital certificate self-audit and operation service on a blockchain. It stores
BlockVoke – Blockchain-Based Certificate Revocation 321
the entire certificate history from registration to revocation. The proposed sys-
tem makes entire revoked certificates publicly visible, while CertChain leverages
the advantages of blockchain to provide decentralized tamper-evident public cer-
tificates.
Despite their decentralized nature, these systems require users/clients to
either download the complete blockchain or rely on full nodes to provide the
relevant information to clients, which results in network structures that are still
prone to manipulation. Also, the proposed methods do not provide ecient meth-
ods for clients with storage constraints to query certificate revocation statuses.
3BlockVokeBlockchain-BasedCerticateRevocation
Traditional PKI systems are based on trusted CAs that sign certificates, main-
tain CRLs, and provide OSCP proofs for certificates they issued. As previously
mentioned, the current mechanisms of certificate revocation are subject to SPOF
[2] risk as well as other security and privacy issues, while the WoT suers from
disadvantages of its own. In this section, we describe the lifecycle of a certificate
using the blockchain-based BlockVoke certificate revocation system. The lifecy-
cle consists of three main parts. First, a certificate signing request is made by
the future certificate owner, which is subsequently used by the CA to create the
certificate. Finally, the certificate either expires or is revoked prematurely.
Throughout this section, we assume an instantiation of our scheme on the
Bitcoin blockchain, using 1-of-2 multi-signature addresses, which allow spending
with either of two dierent public keys. The general structure remains the same
even when instantiated on other blockchain platforms or through smart con-
tracts. First, we describe the BlockVoke scheme as it applies to the revocation
of SSL/TLS certificates. After that, we describe its applicability to WoT-based
systems, such as PGP. An overview of the whole process is given in Fig. 3.
3.1 Certificate Signing Request
Creating a CSR generally follows the procedure of creating any regular SSL/TLS
CSR. Our approach, however, requires the addition of a new attribute, which
contains the public key corresponding to a Bitcoin address owned by the certifi-
cate owner – illustrated as step 1 in Fig. 3.
3.2 Certificate Creation
Again, the creation and signing procedure of the certificate follows that of any
regular SSL/TLS certificate. In addition, using the public key corresponding to
a Bitcoin address, the CA uses its own Bitcoin public key and the certificate
owner’s key to create a 1-of-2 multi-signature address, which can be spent from
with either of the two public keys. The resulting address is added to the certificate
as an extension field. If the CA publishes Certificate Revocation Vectors (CRV)
322 A. Garba et al.
Fig. 3. Overview of the certificate lifecycle, from creation to blockchain based revoca-
tion.
as described in [45], it also adds its own public key to the field. These are steps
2 and 3 in Fig. 3.
Once the certificate owner receives the certificate, it is used as any other
certificate, as indicated by step 4 in Fig. 3.
3.3 Revocation
The extension field allows users attempting to validate the certificate to look up
past transactions originating from this multi-signature address. If any such trans-
action exists, the certificate is considered revoked. The creation and the process
of adding this transaction to the blockchain (the so-called mining process) are
indicated by step 5 in Fig. 3.
The actual revocation is performed either by the certificate owner or the
CA. To revoke a certificate, the party performing the revocation creates a Bitcoin
transaction, sending a small amount into the multi-signature address specified in
the extension field of the certificate. After transmitting this transaction, they cre-
ate a second transaction, spending the funds they just sent to the multi-signature
address back to their wallet. This transaction also contains an OP RETURN script
opcode containing necessary information concerning the revocation. During this
step, it is not necessary to wait for the first transaction to be confirmed since
Bitcoin allows the spending of unconfirmed change. For both transactions, a suf-
ficient miners’ fee should be added to ensure the timely confirmation of both
transactions.
The OP RETURN script opcode allows embedding arbitrary information in Bit-
coin transactions, with a limited size of up to 40 Bytes. The first ten of these
bytes are specified to be BlockVoke followed by a zero byte. As a result, it easy
BlockVoke – Blockchain-Based Certificate Revocation 323
to scan the blockchain for revocation transactions even for unknown certificates.
This is followed by the first 16 Bytes of the certificate’s fingerprint, allowing
users to confirm that this transaction actually pertains to the certificate they
are trying to validate. It is then followed by a four-byte integer indicating the cer-
tificate’s date of issuance in days since 2020-02-02. One additional byte encodes
the reason for the revocation, following the RFC 5280 [14] revocation codes as
given in Table 1.
If the CA that issued the certificate is publishing CRVs, the last nine bytes
contain first a three-byte unsigned integer for the revocation number (RN) and
finally six bytes containing a unique identifier for the CA. This information is
added only in case the CA revokes the certificate, as can be confirmed through
the public key that was added to the certificate’s extension field.
As revocation information is instantly broadcast over the Bitcoin P2P net-
work, users and entities building their own revocation lists or filters can instantly
update their filters to include the newly revoked certificate. Examples of such
entities may include companies, universities, or other organizations, which have
stringent security requirements that demand a higher update rate than, e.g.,
the daily updates provided by the CRLite [31] implementation currently being
tested by Mozilla in Firefox Nightly builds [26].
We estimate that a revocation transaction on Bitcoin using a single input and
output, plus an OP RETURN operation has a size of up to 283 Bytes, depending
on the OP RETURN payload’s size.
3.4 CA Root Certificates
Usually, the revocation of CA root certificates poses diculties as they are self-
signed, and there exists no key that is eligible to revoke them. With our scheme,
a separate key tied to a blockchain address is used for revocation. Therefore, the
BlockVoke revocation mechanism applies as well to CA root certificates, making
it possible to revoke them in case of compromise or other reasons.
3.5 Web of Trust Keys
In the WoT, no central authorities exist to provide trust in cryptographic keys.
Instead, users mutually sign their keys after, ideally, carefully confirming each
others’ identities. Users then determine how much they trust other users’ keys
by checking whether there is a path of transitively trusted signatures leading up
to it [33].
The BlockVoke scheme for certificate revocation is also applicable to keys in
the WoT with minor modifications. Since there is no certificate authority, only
the key owner can publish a revocation. Due to this, a regular Bitcoin address can
be used instead of a multi-signature address. The key owner directly generates
a Bitcoin address and stores it in a User Attribute Packet [11] that is part of an
OpenPGP key. From there on, a revocation is performed as specified above for
SSL/TLS certificates.
324 A. Garba et al.
Tabl e 1 . Certificate revocation codes according to RFC 5280 [14].
Code Reason Code Reason
0Unspecified 6Cessation of operation
1Key compromise 7Certificate hold
2CA compromise 8Remove from CRL
3Aliation changed 9Privilege withdrawn
4Key compromise 10 AA compromise
5Superseded
4Analysis
In this section, we give an analysis of various properties of the BlockVoke scheme.
First, we detail the security properties of our scheme.
4.1 Basic Security Properties
The primary security properties of certificates using our scheme remain unaf-
fected as BlockVoke is only concerned with the revocation process. It does this
by announcing and preserving revocations through a blockchain platform. Thus,
it is possible to also employ traditional revocation publication methods such as
OSCP or CRLs in parallel, where required.
The fingerprint provided in revocation transactions allows users to confirm
that the transaction is intended to revoke the specific certificate, while the fact
that the transaction originates from the address specified within the certificate
guarantees that the revocation is legitimate. Allowing for fingerprint verification
mitigates the possible scenario that an attacker gains access to the wallet keys of
a certificate owner and attempts to randomly revoke their certificates as a form
of Denial-of-Service attack, without actually knowing which certificates belong
to a particular certificate owner.
4.2 Timeliness of Revocations
In contrast to many other blockchain-based schemes, BlockVoke does not require
its users to wait until revocation transactions are confirmed before acting on
them. The transactions themselves are sucient to allow the corresponding cer-
tificate to be added to revocation lists or CRLite-based filters without delay. The
purpose of adding them to the blockchain is to ensure the global and continued
availability of these revocations, as the lifetime of transactions that exist merely
in the transaction pool of the Bitcoin P2P network is limited.
Because revocations can be processed as soon as they are broadcast through
the network, attacks on the underlying blockchain also have only a limited impact
on BlockVoke. If the transactions do not get mined before falling out of the
transaction pool, revocations may be lost at some point in the future, unless the
CA or another party rebroadcasts them.
BlockVoke – Blockchain-Based Certificate Revocation 325
4.3 Comparison with CertLedger
CertLedger moves the entire certificate lifecycle onto a new, special-purpose
blockchain [30]. While presenting a comprehensive solution to certificate issuance
and revocation, the approach has certain drawbacks.
First, the use of a custom blockchain means that is not possible for the scheme
to inherit the security properties of existing public blockchains. In the case of
BlockVoke, the computational eort spent on securing the Bitcoin blockchain by
miners also guarantees the future persistence of revocations on this blockchain.
Another issue concerns the privacy-preserving aspect of CertLedger. The
state of a certificate changes to revoked by triggering a state update operation in
a smart contract. Only full nodes are able to see these updates directly as most
clients only download block headers, which are then used to verify certificate
state proofs generated by full nodes. CertLedger claims to preserve client privacy
as a state proof can be sent to the client together with the certificate when
establishing a connection. This way, no request regarding this certificate has to
be made to any third party. However, if an attacker takes control of a domain
and compromises the key, a situation which certificate revocation should remedy,
the attacker can bundle an outdated certificate state proof as long as clients do
not check with a third party full node to ensure that the received state proof is
up to date.
4.4 Fees
When storing data on a blockchain, the size of transactions and the fees they
incur are important factors to consider. Table 2shows the costs of BlockVoke
revocation transactions on the Bitcoin as well as the Ethereum platform.
As described in Sect. 3.3 and presented in Table2, we estimate an optimal
revocation transaction in the Bitcoin network to have a size below 283 bytes
with a payload size of 40 bytes. As our approach does not depend on fast trans-
action processing, it is not necessary to gain a very high mining priority for our
revocation transactions by paying high fees. Based on data for March 2020, the
cost for a transaction average around $0.001751 per byte. Thus, a BlockVoke
revocation transaction of 283 bytes on the Bitcoin platform costs $0.496.
The costs for an Ethereum transaction are calculated as illustrated in Eq. 1,
where 21000 gas are the fees paid for any transaction, and each byte of payload
costs 68 gas. Based on the 40-byte payload of a BlockVoke revocation, the overall
transaction results in an Ethereum gas demand of 23720. As shown in Table 2
and based on the average Ether price for March 2020, this results in a price of ca.
$0.07 per BlockVoke revocation transaction on the Ethereum platform. Thus, it
is seven times cheaper than the Bitcoin platform.
Fee = 21000 gas + 68 gas size of txdata in bytes (1)
The size of a minimal Ethereum transaction is 107 bytes, in addition to the up
to 40-byte payload of BlockVoke data [35,47].
326 A. Garba et al.
In addition to the costs for the revocation transaction, there has to be a
transaction funding the BlockVoke address. This transaction is usually smaller
and therefore costs less. However, Ethereum multi-signature transactions are
implemented using smart contracts and therefore require two transactions to be
made – first, the transaction triggering the smart contract; second, the trans-
action of the smart contract that transfers the funds. Therefore, we need two
107-byte funding transactions.
We further analyze the impact of transaction size and fees in Sect. 5.
Tabl e 2 . Transaction fee comparison between Bitcoin and Ethereum based on the aver-
age transaction fee prices per byte for Bitcoin and the average gas price for Ethereum
in March 2020 – Sources: [57] and [16,17,35,47]
Platform Min. TX Size Avg. TX Cost
Bitcoin 283 bytes $0.496
Bitcoin (Funding) 193 bytes $0.338
Ethereum 147 bytes $0.070
Ethereum (Funding) 2 ×107 bytes $0.124
4.5 Privacy
Privacy can be considered from two perspectives: The privacy of the certificate
owner who might be revoking their certificate and the privacy of users who
attempt to verify whether a certificate is still valid.
Certificate Owner. The privacy impact on certificate owners is not commonly
considered, but we will shortly explore the topic in the following. In the context
of BlockVoke,theonlytimeatransactionismadeontheblockchainiswhena
certificate is revoked. Therefore, unless the certificate is revoked, our scheme has
no impact on certificate owner privacy. If a certificate is revoked, we can again
consider two separate aspects. The first aspect is the data contained within the
revocation transaction’s payload. It contains the fingerprint of the certificate,
the date of issuance, and the certificate authority. This information should have
little impact on the privacy of the certificate owner. It can only be matched to
a certificate when the certificate and thus its fingerprint is already known. The
only additional information gained from it is the revocation reason, which is
intended to be known by users attempting to use the certificate.
Another aspect is the issue of general blockchain privacy. Revoking a cer-
tificate using our scheme requires the creation of a transaction on a blockchain.
Therefore the usual considerations about transaction traceability apply [42].
BlockVoke – Blockchain-Based Certificate Revocation 327
User. Our scheme has no impact on user privacy. Users running a full node
receive all revocations without leaking information about which certificates they
might be interested in. Users downstream of organizations building, e.g., CRLite
filters based on revocations from our scheme, will experience no privacy impact
from the use of BlockVoke.
4.6 Auditability
Auditability is given as all revocations are publicly stored on the blockchain.
5EvaluationandDiscussion
The following sections focus on evaluating the BlockVoke protocol. In Sect. 5.1
and Sect. 5.2, we analyze storage size and costs for dierent certificate revocation
scenarios in the context of PKIs and the WoT on the Ethereum and Bitcoin
blockchain.
Bit first, we discuss how fast a BlockVoke revocation statement propagates
through the system. After revoking a certificate – for both cases, PKI and WoT –
the revocation statement is posted to the blockchain in the form of a transac-
tion. The revocation transaction is pushed to the pool of pending transactions
before being mined into the next block of the Bitcoin or Ethereum blockchain.
Technically, a revocation transaction does not have to be mined to be valid in
the context of BlockVoke. Therefore, the lower boundary of time that it takes to
publish a revocation transaction is almost instantly. However, an upper bound
depends on the confirmation time of transactions in both networks.
The Bitcoin network aims to publish a new block every ten minutes (the
so-called block time). The larger the transaction fee attached to a revocation
transaction, the higher the probability that a miner will pick up the transaction
as soon as possible to include it into the next block to receive the transaction fee
for doing so. A Bitcoin transaction is usually considered confirmed after six con-
secutive blocks, i.e., after 60 min. However, the median transaction confirmation
time for transactions that include sucient fees varies between five and thirty
minutes for the first block [8].
The Ethereum network aims to publish a new block every 12–15 s and is
therefore much faster than the Bitcoin network. A 2018 study suggests that less
than 1% of all transactions take more than ten minutes to be confirmed, while
72% are confirmed within 30 s, or less [44].
Next, we present three case study examples to evaluate cost, eciency, and
storage requirements of BlockVoke in dierent real-life scenarios. The calcula-
tions are based on the transaction cost and storage size estimates presented
earlier in Sect. 4.4.
5.1 Case-Study I – Let’s Encrypt CAA Bug March 2020
In Sect. 1, we presented the Let’s Encrypt CAA bug, which forced LE to revoke
3,048,289 of its certificates. 1,706,950 were actually revoked while the remainder
328 A. Garba et al.
was left to expire within the next 90 days. Table3presents the costs and storage
size requirements of revoking the 1,706,950 LE certificates via BlockVoke. Assum-
ing a Bitcoin-based implementation, BlockVoke needs ca. 812.5 MB of storage
for the revocation and funding transactions as well as roughly $1,423,596 in
transaction fees. Given a block time of ten minutes and a block size limit of
one megabyte, all 1.7 million certificates could have been revoked in less than
136 h – ignoring any further regular transactions which are processed in paral-
lel. An Ethereum-based implementation requires only 616 MB and costs around
$331,148 in fees. Due to the shorter block time (12–15) and a transaction limit
which is imposed by a gas limit (10,000,000 gas at the time of writing this work),
Ethereum could handle the complete set of revocations in less than 47 h – again,
ignoring any further regular transactions.
Tabl e 3. BlockVoke revocation and funding fees as well as storage size requirements
for revoking 1,706,950 certificates involved in the Let’s Encrypt CAA Bug of March
2020.
Platform Min.
BlockVoke TX
Size
Avg.
BlockVoke TX
Cost
Storage Size TX Cost
Bitcoin (Revocation) 283 bytes $0.496 483.07 MB $846,647.20
Bitcoin (Funding) 193 bytes $0.338 329.44 MB $576,949.10
Ethereum (Revocation) 147 bytes $0.070 250.92 MB $119,486.50
Ethereum (Funding) 2×107 bytes $0.124 365.29 MB $211,661.80
Table 4goes even one step further and assumes the compromise of the LE
root certificate which requires to revoke all existing LE certificates. On March 31,
2020 LE listed around 124.533 million active and valid certificates [34]. Revoking
all of them at once results in ca. 59.28 GB of storage and $103.8 million in fees on
the Bitcoin, and 44.96 GB of storage and $24.159 million in fees on the Ethereum
platform.
Tabl e 4 . Transaction fees and storage size requirements for the hypothetical scenario
of revoking all 124.533 million valid LE certificates as of March 31, 2020.
Platform Min.
BlockVoke TX
Size
Avg.
BlockVoke TX
Cost
Storage Size TX Cost
Bitcoin (Revocation) 283 bytes $0.496 35.24 GB $61,768,386
Bitcoin (Funding) 193 bytes $0.338 24.03 GB $42,092,154
Ethereum (Revocation) 147 bytes $0.070 18.31 GB $8,717,310
Ethereum (Funding) 2×107 bytes $0.124 26.65 GB $15,442,092
BlockVoke – Blockchain-Based Certificate Revocation 329
It is necessary to put the calculations above into context. Even though the
time, storage, and transaction costs seem to disqualify blockchains as foundations
for PKIs, it is important to keep in mind that the two scenarios presented above
are extreme cases. Revoking 1.7 million – yet alone 124.5 million certificates –
never happened before and is thus not comparable with day-to-day operating
costs. Moreover, the cost of $24.159 million to safely revoke all compromised
certificates of a complete CA is cost-ecient, given the size and potential security
implications. As a point of comparison, the US-company Cloudflare estimated
that they spend $400,000 per month to distribute their growing CRL [41,45].
This also leaves aside the fact that BlockVoke allows the direct revocation of the
root certificate, making it even less likely that such a high number of certificates
ever needs to be revoked.
Moreover, despite the timespan to add all transactions to the blockchain,
the approach is also very time-ecient. As mentioned at the beginning of this
section – a revocation is already valid once a revocation transaction is posted to
the transaction pool. Adding it to a valid blockchain block is only required
for subsequent actions. Nevertheless, adding several gigabytes of data to a
blockchain with a public consensus mechanism and slow block times is a tedious
process. Finally, due to a limited maximum lifetime of certificates, full nodes do
not have to process all past transactions anymore since their content becomes
irrelevant after some time (e.g., at the latest after two years) and only remains
relevant in the context of maintaining the underlying blockchain’s security guar-
antees.
5.2 Case-Study II – Revoking the Web of Trust
Our second case study scenario concerns key revocation in the context of the
WoT. Unfortunately, no statistics exist with regards to the daily, weekly, or
monthly amount of revoked certificates. However, [32]performedananalysisof
the WoT based on a snapshot from October 2014 and found 2,966,965 keys, which
were neither expired nor revoked. Similar to the root certificate compromise of
LE, we calculated the storage requirements and transaction fees for the scenario
of revoking the complete WoT. The results are presented in Table 5.Again,
Tabl e 5 . Transaction fees and storage size requirements for the hypothetical scenario
of revoking all 2,966,965 valid WoT keys existing in October, 2014.
Platform Min.
BlockVoke TX
Size
Avg.
BlockVoke TX
Cost
Storage
Size
TX Cost
Bitcoin (Revocation) 283 bytes $0.496 839.65 MB $1,471,614.64
Bitcoin (Funding) 193 bytes $0.338 572.62 MB $1,002,834.17
Ethereum (Revocation) 147 bytes $0.070 436.14 MB $207,687.55
Ethereum (Funding) 2×107 bytes $0.124 634.93 MB $367,903.66
330 A. Garba et al.
the same considerations regarding time, storage size, and overall costs for this
operation apply as presented in the previous section.
6ConclusionandFutureWork
Relying on CAs or WoT keyservers as gatekeepers to crucial information such
as certificate revocations poses a risk not only to the everyday user but espe-
cially to organizations with large IT-systems and thousands of users. Existing
revocation mechanisms such as Certificate Revocation Lists (CRLs), the Online
Certificate Status Protocol (OCSP), and further OCSP extensions are subject
to various security and privacy challenges. CRLs are being criticized as being
an inecient method of disseminating revocation information; OCSP faces crit-
ical privacy concerns, and its extensions such as OCSP-staple and Must-staple
have minimal adoption rates. On the other hand, the WoT is subject to various
security challenges of its own.
BlockVoke addresses these issues by utilizing blockchain technology to enable
secure, transparent, ecient, and decentralized certificate revocation using the
Bitcoin or the Ethereum blockchain. The scheme relies on a three-stage lifecycle.
First, a certificate signing request is made by the future certificate owner, which
is subsequently used by the CA to create the certificate in the second step.
Finally, the certificate either expires or is revoked prematurely. The BlockVoke
scheme is applicable to the revocation of X.509 certificates as well as OpenPGP
keys used in the context of the WoT.
Usually, the revocation of CA root certificates poses diculties as they are
self-signed and there exists no key that is eligible to revoke them. BlockVoke
ties a separate key to a blockchain address, which enables the revocation of such
certificates. Revocation information is stored as part of revocation transactions
on the Bitcoin or Ethereum network by embedding payload data into the trans-
action. Our payload is limited to the size of up to 40 bytes and thus very storage
ecient. As revocation information is instantly broadcast over the correspond-
ing P2P networks, users and entities building their own revocation lists or filters
instantly receive updates for their filters to include the newly revoked certificate.
Furthermore, we detail the protocol parameters and various properties of our
scheme related to security, timeliness, cost, eciency, and auditability. Likewise,
we discuss upper- and lower-bounds of revocation times. Finally, we evaluate
BlockVoke in dierent real-life case-studies and provide estimates on storage
size and revocation costs for these scenarios as well as a proof-of-concept imple-
mentation of the protocol for the Bitcoin and Ethereum platform.
For future work, we plan to implement and deploy the BlockVoke protocol
on the Bitcoin as well as Ethereum blockchain and evaluate real-world use-cases.
Moreover, we will further analyze the option to invoke smart contracts instead
of plain blockchain transactions. Finally, we will research implementations on
alternative blockchain platforms with faster transaction processing times as well
as lower transaction fees.
BlockVoke – Blockchain-Based Certificate Revocation 331
References
1. Bitcoin Wiki - Multisignature (2019). https://en.bitcoin.it/w/index.php?title=
Multisignature&oldid=67043.Accessed1Sept2020
2. Baldi, M., Chiaraluce, F., Frontoni, E., Gottardi, G., Sciarroni, D., Spalazzi, L.:
Certificate validation through public ledgers and blockchains. In: Proceedings of
the First Italian Conference on Cybersecurity, ITASEC 2017, pp. 156–165 (2017)
3. Basin, D.A., Cremers, C., Kim, T.H., Perrig, A., Sasse, R., Szalachowski, P.:
Design, analysis, and implementation of ARPKI: an attack-resilient public-key
infrastructure. IEEE Trans. Depend. Secure Comput. 15(3), 393–408 (2018)
4. Berkowsky, J.A., Hayajneh, T.: Security issues with certificate authorities. In: 2017
IEEE 8th Annual Ubiquitous Computing, Electronics and Mobile Communication
Conference (UEMCON), pp. 449–455. IEEE (2017)
5. Blockchain Explorer - Blockchain.com: Bitcoin - Average Block Size (MB) (2020).
https://www.blockchain.com/charts/avg-block- size.Accessed1Apr2020
6. Blockchain Explorer - Blockchain.com: Bitcoin - Average Transactions per Block
(2020). https://www.blockchain.com/charts/n-transactions-per-block.Accessed1
Apr 2020
7. Blockchain Explorer - Blockchain.com: Bitcoin - Fees per Transaction (USD)
(2020). https://www.blockchain.com/charts/fees-usd-per-transaction. Accessed 1
Apr 2020
8. Blockchain Explorer - Blockchain.com: Bitcoin - Median Confirmation Time
(2020). https://www.blockchain.com/charts/median-confirmation-time. Accessed
1 Apr 2020
9. Bugzilla: Bugzilla #1311713 - Comodo: CA Comodo used broken OCR and issued
certificates to the wrong people (2016). https://bugzilla.mozilla.org/show bug.cgi?
id=1311713. Accessed 19 Mar 2020
10. Bugzilla: Bugzilla #1619179 - Let’s Encrypt: Incomplete revocation for CAA
rechecking bug (2020). https://bugzilla.mozilla.org/show bug.cgi?id=1619179#c7.
Accessed 18 Mar 2020
11. Callas, J. and PGP Corporation and Donnerhacke, L. and IKS GmbH and Finney,
H. and PGP Corporation and Shaw, D. and Thayer, R.: OpenPGP Message For-
mat. IETF RFC4880, November 2007. Accessed 24 Mar 2020
12. Chen, J., Yao, S., Yuan, Q., He, K., Ji, S., Du, R.: CertChain: public and ecient
certificate audit based on blockchain for TLS connections. In: IEEE INFOCOM -
IEEE Conference on Computer Communications, pp. 2060–2068. IEEE (2018)
13. Chung, T., et al.: Is the web ready for OCSP must-staple? In: Proceedings of the
Internet Measurement Conference 2018, pp. 105–118 (2018)
14. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., Polk, W.: Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile. IETF RFC5280, May 2008. Accessed 18 Mar 2020
15. Eastlake, D.: Transport Layer Security (TLS) Extensions: Extension Definitions.
IETF RFC6066, January 2011. Accessed 18 March 2020
16. Etherscan.io: Ether Daily Price (USD) Chart (2020). https://etherscan.io/chart/
etherprice. Accessed 31 Mar 2020
17. Etherscan.io: Ethereum Average Gas Price Chart (2020). https://etherscan.io/
chart/gasprice. Accessed 31 Mar 2020
18. Fromknecht, C., Velicanu, D., Yakoubov, S.: A Decentralized Public Key Infras-
tructure with Identity Retention. IACR Cryptology ePrint Archive, p. 803 (2014)
332 A. Garba et al.
19. Hallam-Baker, P.: X.509v3 Extension: OCSP Stapling Required - Draft-
hallambaker-muststaple-00 (2012). https://tools.ietf.org/html/draft-hallambaker-
muststaple-00. Accessed 18 Mar 2020
20. Hansen, R.J.: SKS Keyserver Network Under Attack (2019). https://gist.github.
com/rjhansen/67ab921b4084c865b3618d6955275f. Accessed 25 Mar 2020
21. Horst, H.A., Miller, D.: Digital Anthropology. A&C Black, London (2013)
22. Hu, Q., Asghar, M.R., Brownlee, N.: Checking certificate revocation eciently
using certificate revocation guard. J. Inf. Secur. Appl. 48, 102356 (2019)
23. ImperialViolet: Revocation Checking and Chrome’s CRL (2012). https://www.
imperialviolet.org/2012/02/05/crlsets.html. Accessed 26 Mar 2020
24. Homan-Andrews, J.: Let’s Encrypt - 2020.02.29 CAA Rechecking Bug (2020).
https://community.letsencrypt.org/t/2020- 02-29-caa-rechecking-bug/114591.
Accessed 18 Mar 2020
25. JamesLE: Let’s Encrypt - Revoking Certain Certificates on March 4 (2020).
https://community.letsencrypt.org/t/revoking-certain-certificates-on-march-4/
114864. Accessed 18 Mar 2020
26. J.C. Jones: CRLite: Speeding Up Secure Browsing (2020). https://blog.mozilla.
org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/. Accessed 19
Mar 2020
27. Khare, R., Rifkin, A.: Weaving a web of trust. World Wide Web J. 2(3), 77–112
(1997)
28. Klafter, R., Swanson, E.: Evil 32: Check Your GPG Fingerprints (2014). https://
evil32.com/. Accessed 25 Mar 2020
29. Kocher, P.C.: On certificate revocation and validation. In: Hirchfeld, R. (ed.) FC
1998. LNCS, vol. 1465, pp. 172–177. Springer, Heidelberg (1998). https://doi.org/
10.1007/BFb0055481
30. Kubilay, M.Y., Kiraz, M.S., Mantar, H.A.: CertLedger: a new PKI model with
certificate transparency based on blockchain. Comput. Secur. 85, 333–352 (2019)
31. Larisch, J., Chones, D., Levin, D., Maggs, B.M., Mislove, A., Wilson, C.: CRLite:
a scalable system for pushing all TLS revocations to all browsers. In: 2017 IEEE
Symposium on Security and Privacy (SP), pp. 539–556. IEEE (2017)
32. Leiding, B.: Link topological analysis of the PGP web of trust. Bachelor’s Thesis,
University of Rostock, Rostock, Germany (2015)
33. Leiding, B., Cap, C.H., Mundt, T., Rashidibajgan, S.: Authcoin: validation and
authentication in decentralized networks. In: The 10th Mediterranean Conference
on Information Systems - MCIS 2016, Paphos, Cyprus, September 2016
34. Let’s Encrypt: Let’s Encrypt - Statistics (2020). https://letsencrypt.org/de/stats/.
Accessed 06 Apr 2020
35. Song, L.: Signing an Ethereum Transaction the Hard Way (2018). https://
lsongnotes.wordpress.com/2018/01/14/signing-an-ethereum-transaction-the-
hard-way/. Accessed 06 Apr 2020
36. Liu, Y., et al.: An end-to-end measurement of certificate revocation in the web’s
PKI. In: Proceedings of the 2015 Internet Measurement Conference, pp. 183–196.
ACM (2015)
37. Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System (2008). https://
bitcoin.org/bitcoin.pdf. Accessed 15 Mar 2020
38. Naor, M., Nissim, K.: Certificate revocation and certificate update. IEEE J. Sel.
Areas Commun. 18(4), 561–570 (2000)
39. Perlman, R.: An overview of PKI trust models. IEEE Network 13(6), 38–43 (1999)
40. Pettersen, Y.: The Transport Layer Security (TLS) Multiple Certificate Status
Request Extension. IETF RFC6961, June 2013. Accessed 22 March 2020
BlockVoke – Blockchain-Based Certificate Revocation 333
41. Prince, M.: The Hidden Costs of Heartbleed (2014). https://blog.cloudflare.com/
the-hard-costs-of-heartbleed/.Accessed1Sept2020
42. Ron, D., Shamir, A.: Quantitative analysis of the full bitcoin transaction graph.
In: Sadeghi, A.R. (ed.) FC 2013. LNCS, vol. 7859, pp. 6–24. Springer, Heidelberg
(2013). https://doi.org/10.1007/978-3-642-39884-1 2
43. Santesson, S., Myers, M., Malpani, A., Galperin, S., Adams, C.: X. 509 Inter-
net Public Key Infrastructure Online Certificate Status Protocol - OCSP. IETF
RFC6960, June 2013. Accessed 18 Mar 2020
44. Singh, H.J., Hafid, A.S.: Prediction of transaction confirmation time in Ethereum
blockchain using machine learning. In: Prieto, J., Das, A., Ferretti, S., Pinto, A.,
Corchado, J. (eds.) BLOCKCHAIN 2019. AISC, vol. 1010, pp. 126–133. Springer,
Cham (2020). https://doi.org/10.1007/978-3-030-23813-1 16
45. Smith, T., Dickinson, L., Seamons, K.: Let’s revoke: scalable global certificate
revocation. In: 27th Annual Network and Distributed System Security Symposium,
NDSS 2020. The Internet Society (2020)
46. Su, K., Li, J., Fu, H.: Smart city and the applications. In: International Confer-
ence on Electronics, Communications and Control (ICECC), pp. 1028–1031. IEEE
(2011)
47. Wood, G.: Ethereum Yellow Paper: A Secure Decentralized Generalised Trans-
action Ledger - BYZANTIUM VERSION 7e819ec - 2019–10-20 (2019). https://
ethereum.github.io/yellowpaper/paper.pdf . Accessed 06 Apr 2020
48. Yakubov, A., Shbair, W., Wallbom, A., Sanda, D., et al.: A blockchain-based
PKI management framework. In: The First IEEE/IFIP International Workshop on
Managing and Managed by Blockchain (Man2Block) Colocated with IEEE/IFIP
NOMS 2018, Tapei, Tawain 23–27 April 2018 (2018)
... We follow the basic approach of BlockVoke [35] to make it possible to revoke this identity at a later point in time, which will be explained in more detail in Section 3.3. ...
... However, the drawback is that identities need to be recreated periodically, incurring unnecessary costs for users who have no reason to revoke their identities. Therefore, we propose the following mechanism to revoke identities, basically following the approach of [35]. Each identity proof contains an additional Bitcoin address, as specified in Section 3.1. ...
... Storing data on a PoW-base chain, such as the Bitcoin blockchain, incurs costs that correlate with the transaction size. A revocation transaction in the Bitcoin network with a payload of 40 bytes has a size of fewer than 283 bytes, as suggested in [35]. Because Rechained does not depend on fast transaction processing, it is unnecessary to aim for a high mining priority by paying high fees. ...
Article
Full-text available
Today, increasing Internet of Things devices are deployed, and the field of applications for decentralized, self-organizing networks keeps growing. The growth also makes these systems more attractive to attackers. Sybil attacks are a common issue, especially in decentralized networks and networks that are deployed in scenarios with irregular or unreliable Internet connectivity. The lack of a central authority that can be contacted at any time allows attackers to introduce arbitrary amounts of nodes into the network and manipulate its behavior according to the attacker’s goals, by posing as a majority participant. Depending on the structure of the network, employing Sybil node detection schemes may be difficult, and low powered Internet of Things devices are usually unable to perform impactful amounts of work for proof-of-work based schemes. In this paper, we present Rechained, a scheme that monetarily disincentivizes the creation of Sybil identities for networks that can operate with intermittent or no Internet connectivity. We introduce a new revocation mechanism for identities, tie them into the concepts of self-sovereign identities, and decentralized identifiers. Case-studies are used to discuss upper- and lower-bounds for the costs of Sybil identities and, therefore, the provided security level. Furthermore, we formalize the protocol using Colored Petri Nets to analyze its correctness and suitability. Proof-of-concept implementations are used to evaluate the performance of our scheme on low powered hardware as it might be found in Internet of Things applications.
... While BlockVoke is described in depth in [26], a gap exists with respect to the creation process of the corresponding formal CPN model as well as analyzing and verifying the formal model. This work fills the detected gap and investigates the research question of how to formalize the BlockVoke protocol using Colored Petri Nets. ...
... In such a case, the certificate authority (CA) that signed the certificate issues a revocation statement signed by its private key. Figure 1 shows the most common revocation mechanisms, which are briefly introduced in this section. [26][27][28]). ...
... While a general description of BlockVoke is presented in [26], a formal model that could be analyzed and verified was missing. Formal methods, such as CPNs, facilitate the design, development, analysis and verification of new protocols; the detection of flaws; and the mitigation of identified security risks. ...
Article
Full-text available
Protocol flaws such as the well-known Heartbleed bug, security and privacy issues or incomplete specifications, in general, pose risks to the direct users of a protocol and further stakeholders. Formal methods, such as Colored Petri Nets (CPNs), facilitate the design, development, analysis and verification of new protocols; the detection of flaws; and the mitigation of identified security risks. BlockVoke is a blockchain-based scheme that decentralizes certificate revocations, allows certificate owners and certificate authorities to revoke certificates and rapidly distributes revocation information. CPNs in particular are well-suited to formalize blockchain-based protocols—thus, in this work, we formalize the BlockVoke protocol using CPNs, resulting in a verifiable CPN model and a formal specification of the protocol. We utilize an agent-oriented modeling (AOM) methodology to create goal models and corresponding behavior interface models of BlockVoke. Subsequently, protocols semantics are defined, and the CPN models are derived and implemented using CPN Tools. Moreover, a full state-space analysis of the resulting CPN model is performed to derive relevant model properties of the protocol. The result is a complete and correct formal BlockVoke specification used to guide future implementations and security assessments.
... Several alternative revocation status protocols have been developed [5], [6], [39], [45], as well as novel PKIs [3], [24], [47], [48], [52]; however, all of these protocols and PKIs require large changes to the infrastructure. Similarly, many other semi-centralized and decentralized PKIs, revocation protocols and logs have been proposed [7], [16], [17], [25], [28], [32], [44], [46], [50]. Matsumoto et al. [36] propose a decentralized framework that incentivizes CAs to monitor for certificate misissuance through financial penalties. ...
Preprint
Full-text available
The modern Internet is highly dependent on trust communicated via certificates. However, in some cases, certificates become untrusted, and it is necessary to revoke them. In practice, the problem of secure revocation is still open. Furthermore, the existing procedures do not leave a transparent and immutable revocation history. We propose and evaluate a new revocation transparency protocol that introduces postcertificates and utilizes the existing Certificate Transparency (CT) logs. The protocol is practical, has a low deployment cost, provides an immutable history of revocations, enables delegation, and helps to detect revocation-related misbehavior by certificate authorities (CAs). With this protocol, a holder of a postcertificate can bypass the issuing CA and autonomously initiate the revocation process via submission of the postcertificate to a CT log. The CAs are required to monitor CT logs and proceed with the revocation upon detection of a postcertificate. Revocation status delivery is performed independently and with an arbitrary status protocol. Postcertificates can increase the accountability of the CAs and empower the certificate owners by giving them additional control over the status of the certificates. We evaluate the protocol, measure log and monitor performance, and conclude that it is possible to provide revocation transparency using existing CT logs.
Article
Full-text available
In conventional PKI, CAs are assumed to be fully trusted. However, in practice, CAs’ absolute responsibility for providing trustworthiness caused major security and privacy issues. To prevent such issues, Google introduced the concept of Certificate Transparency (CT) in 2013. Later, several new PKI models are proposed to reduce the level of trust to the CAs. However, all of these proposals are still vulnerable to split-world attacks if the adversary is capable of showing different views of the log to the targeted victims. In this paper, we propose a new PKI architecture with certificate transparency based on blockchain, what we called CertLedger, to eliminate the split-world attacks and to provide certificate/revocation transparency. All TLS certificates’ validation, storage, and entire revocation process is conducted in CertLedger as well as Trusted CA certificate management. During a TLS connection, TLS clients get an efficient proof of existence of the certificate directly from its domain owners. Hence, privacy is now perfectly preserved by eliminating the traceability issue via OCSP servers. It also provides a unique, efficient, and trustworthy certificate validation process eliminating the conventional inadequate and incompatible certificate validation processes implemented by different software vendors. TLS clients in CertLedger also do not require to make certificate validation and store the trusted CA certificates anymore. We analyze the security and performance of CertLedger and provide a comparison with the previous proposals. Finally, we implement its protoype on Ethereum to demonstrate experimental results. The results show that the performance of the TLS handshake and certificate validation through CertLedger is significantly improved compared to the current TLS protocol.
Conference Paper
Full-text available
Traditional Public-Key Infrastructure (PKI) is Certificate Authority based (CA-based). Thus, the security of PKI is completely relying on the security of CAs' infrastructure. However, many recent breaches show that the CA's infrastructure can be compromised as well as exposed to operational errors, while the Log-based PKIs and Web of Trust (WoT) approaches have many issues related to the potential points-of-failure and other difficulties. In this paper, we propose a novel blockchain-based PKI management framework which can issue, validate and revoke X.509 standard certificates using Blockchain technology. Our framework resolves the problems with traditional PKI systems - in particular, certificate revocation, elimination of single points-of-failure and rapid reaction to CAs misbehavior. We designed and developed a prototype for issuing, validating and revoking PKI certificates through Ethereum blockchain. Evaluation and experimental results confirm that the proposed framework can be used to construct reliable and robust PKI systems.
Article
In the Public Key Infrastructure (PKI) model, digital certificates play a vital role in securing online communication. Communicating parties exchange and validate these certificates and the validation should fail if the certificate has been revoked. However, some existing studies [1,2] raise an alarm as the certificate revocation check is skipped in the existing PKI model for a number of reasons including network latency overheads, bandwidth costs, storage costs and privacy issues. In this article, we propose a Certificate Revocation Guard (CRG) to efficiently check certificate revocation while minimising bandwidth, latency and storage overheads. CRG is based on OCSP, which caches the revocation status of certificates locally, thus strengthening user privacy for subsequent requests. CRG is a plug and play component that could be installed on the user’s machine, at the organisational proxy or even in the ISP network. Compared to a naive approach (where a client checks the revocation status of all certificates in the chain on every request), CRG decreases the bandwidth overheads and network latencies by 95%. Using CRG incurs 69% lower storage overheads compared to the CRL method. Our results demonstrate the effectiveness of our approach to improve the certificate revocation process.
Conference Paper
TLS, the de facto standard protocol for securing communications over the Internet, relies on a hierarchy of certificates that bind names to public keys. Naturally, ensuring that the communicating parties are using only valid certificates is a necessary first step in order to benefit from the security of TLS. To this end, most certificates and clients support OCSP, a protocol for querying a certificate's revocation status and confirming that it is still valid. Unfortunately, however, OCSP has been criticized for its slow performance, unreliability, soft-failures, and privacy issues. To address these issues, the OCSP Must-Staple certificate extension was introduced, which requires web servers to provide OCSP responses to clients during the TLS handshake, making revocation checks low-cost for clients. Whether all of the players in the web's PKI are ready to support OCSP Must-Staple, however, remains still an open question. In this paper, we take a broad look at the web's PKI and determine if all components involved---namely, certificate authorities, web server administrators, and web browsers---are ready to support OCSP Must-Staple. We find that each component does not yet fully support OCSP Must-Staple: OCSP responders are still not fully reliable, and most major web browsers and web server implementations do not fully support OCSP Must-Staple. On the bright side, only a few players need to take action to make it possible for web server administrators to begin relying on certificates with OCSP Must-Staple. Thus, we believe a much wider deployment of OCSP Must-Staple is an realistic and achievable goal.
Chapter
An Ethereum transaction is defined as the method by which the external world interacts with Ethereum. More and more users are getting involved in cryptocurrencies like Ethereum and Bitcoin. With a sudden increase in the number of transactions happening every second and the capital involved in those transactions, there is a need for the users to able to predict whether a transaction would be confirmed and if yes, then how much time would it take for it to be confirmed. This paper aims to use modern machine learning techniques to propose a model that would be able to predict the time frame within which a miner node will accept and include a transaction to a block. The paper also explores the impact of imbalanced data on our chosen classifiers-Bayes, Random Forest and Multi-Layer Perceptron (MLP) with SoftMax output and the alternative performance measures to optimally handle the imbalanced nature of the dataset.
Conference Paper
An Ethereum transaction is defined as the method by which the external world interacts with Ethereum. More and more users are getting involved in cryptocurrencies like Ethereum and Bitcoin. With a sudden increase in the number of transactions happening every second and the capital involved in those transactions, there is a need for the users to able to predict whether a transaction would be confirmed and if yes, then how much time would it take for it to be confirmed. This paper aims to use modern machine learning techniques to propose a model that would be able to predict the time frame within which a miner node will accept and include a transaction to a block. The paper also explores the impact of imbalanced data on our chosen classifiers-Bayes, Random Forest and Multi-Layer Perceptron (MLP) with SoftMax output and the alternative performance measures to optimally handle the imbalanced nature of the dataset.