SmartCert: Redesigning Digital Certificates with Smart Contracts

by   Pawel Szalachowski, et al.

The Transport Layer Security (TLS) protocol and its public-key infrastructure (PKI) are widely used in the Internet to achieve secure communication. Validating domain ownership by trusted certification authorities (CAs) is a critical step in issuing digital certificates, but unfortunately, this process provides a poor security level. In this work, we present SmartCert, a novel approach based on smart contracts to improve digital certificates. A certificate in SmartCert conveys detailed information about its validation state which is constantly changing but only with respect to the specified smart contract code and individual domain policies. CAs issuing and updating certificates are kept accountable and their actions are transparent and monitored by the code. We present the implementation and evaluation of SmartCert, and discuss its deployability.



There are no comments yet.


page 1

page 2

page 3

page 4


Securify: Practical Security Analysis of Smart Contracts

Permissionless blockchains allow the execution of arbitrary programs (ca...

VeriSolid: Correct-by-Design Smart Contracts for Ethereum

The adoption of blockchain based distributed ledgers is growing fast due...

BlockPKI: An Automated, Resilient, and Transparent Public-Key Infrastructure

This paper describes BlockPKI, a blockchain-based public-key infrastruct...

AuthSC: Mind the Gap between Web and Smart Contracts

Although almost all information about Smart Contract addresses is shared...

Blockchain-based TLS Notary Service

The Transport Layer Security (TLS) protocol is a de facto standard of se...

Compositional Security for Reentrant Applications

The disastrous vulnerabilities in smart contracts sharply remind us of o...

Standing Forest Coin (SFC)

This article describes a proposal to create a digital currency that allo...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Secure Internet communication often relies on digital certificates that contain bindings between subjects (usually domain names) and their public keys. It is security-critical that these bindings are correct; otherwise, an adversary able to obtain a certificate with an incorrect binding could impersonate the attacked subject. In the TLS PKI [22], CAs are obligated to validate the correctness of these bindings and subsequently are allowed to issue certificates stating it. Unfortunately, the validation process provides a poor security level since it is conducted only once for the certificate lifetime [12]. Moreover, the TLS PKI provides the weakest-link security and an adversary compromising a single CA (out of hundreds [58]) can issue a certificate for any domain. A certificate also has to be accompanied with its revocation status (as it can be prematurely invalidated) but designing a sustainable and effective revocation system turned out to be a huge challenge [46].

There were many approaches proposed to solve or mitigate these issues. Extended Validation (EV) certificates [29] try to introduce more secure public-key validation by requiring a requesting entity to prove that it has a legal control over the domain. Unfortunately, EV certificates are unpopular [56], their security benefits are questionable [38, 19], and their support in main browsers may be deprecated in a near future [65]. Another approach is notary servers [81, 48], which contact TLS servers and report observed public keys to a TLS client that can compare its own view with the views of notary server(s) prior to accepting the TLS connection. Although properties provided by notary systems are desired in an environment like the Internet, their deployment issues thwarted their adoption. Certificate Transparency (CT) [45] is a prominent log-based system which does not improve the public-key validation process but rather aims to make actions of CAs visible by logging all issued certificates. There have been many proposals for a secure and efficient revocation system [22, 44, 62]; however, despite them, the current TLS PKI still cannot offer this basic functionality [46]. The domain expressiveness in the TLS PKI is also unsatisfactory. Domains can use CAA [36] or DANE [34] to specify simple policies, like their trusted CAs; however, these systems rely upon the DNS/DNSSEC infrastructure causing inefficiencies, and low security and deployability [68].

One important observation is that in the current TLS PKI certificates are static; thus are: a) inflexible in terms of adding and handling new features, and b) decoupled from the information about their validity (like policies or a revocation status). Such a design causes serious issues, as the security and availability of the certificate validation process are underpinned by multiple separate infrastructures (e.g., for revocation or logging). In this paper, we present SmartCert, a framework where certificates are empowered by smart contracts. This design choice gives us an opportunity to rethink and redesign how digital certificates can be maintained and expressed in order to improve their security and flexibility. In SmartCert, certificates are dynamic objects carrying their validation states, which are able to evolve according to pre-defined rules and individual domain policies. These rules and policies are self-enforced by a code; therefore, the trust placed in CAs can be significantly minimized. We present SmartCert in the context of improving dominant domain-validated certificates but the framework can be extended to other validation policies easily. SmartCert combines advantages of previous systems and with “history-rich” certificates provides new interesting properties beneficial for clients and domains. SmartCert is deployable with the legacy TLS infrastructure, requires small changes on involved parties and does not require any new infrastructure to be deployed. We implemented and evaluated SmartCert, and our results indicate its efficiency and practicality.

2 Background

2.1 Notation

We use the following notation. is a cryptographic hash function; is the string concatenation; is a set of all -bit long strings; denotes that is an element randomly selected from the set ; for a private key and a message to sign , creates the corresponding signature ; returns True if the message matches the signature under the public key , False otherwise; returns the current timestamp.

2.2 Transport Layer Security

The TLS protocol [23] provides security for the client-server model and can be used to secure any application-layer protocol; however, its main use case on the Internet is HTTPS, i.e., running the HTTP protocol on the top of TLS. (We focus on TLS 1.2 as it is currently recommended and widely deployed, but SmartCert can be easily combined with TLS 1.3 as we discuss in § 7.4.) TLS consists of multiple subprotocols, one of which is the TLS handshake protocol. TLS handshake initiates a TLS connection and is designed to negotiate a shared symmetric key between a client and a server. During an execution of this protocol, the communicating parties decide to accept or reject the connection. There are many ways this shared key can be negotiated; however, methods based on the elliptic curve ephemeral Diffie-Hellman (DH) protocol [14] are recommended and used by default by modern TLS implementations [70, 69].

Client Server
if :
  … CKE
Fig. 1: A TLS handshake with an ephemeral DH key exchange.

The TLS handshake with an ephemeral DH key exchange is presented in Fig. 1. It is initiated by the client that sends a ClientHello message (CH) containing a random value CH.r selected by the client (this value is prepended with the client’s timestamp), a list of the cryptographic methods that the client supports, and other parameters and extensions (optionally). After receiving the ClientHello message, the server prepares multiple messages to send them back to the client. In particular, the ServerHello message (SH) contains a random field created analogically, while the ServerKeyExchange message (SKE) contains authenticated information about the key exchange. This information consists of the client’s random value (CH.r), the server’s random value (SH.r), parameters of the DH protocol, and the signature () that protects all these values. The SKE message is sent to the client together with the server’s certificate (that allows the client to verify the server’s signature and identity) and with the ServerHelloDone message (SHD). Upon receiving these messages the client performs multiple verification checks including ensuring that the signature of the SKE message was signed indeed by the entity from the certificate (it is not presented in the figure but the certificate is also validated at this stage of the protocol). The client computes a shared key and establishes it with the server via the ClientKeyExchange message (CKE). Then the parties exchange ChangeCipherSpec and Finish messages indicating that the following communication can be encrypted.

2.3 TLS PKI and Certificates

TLS employs the X.509 PKI [22], where CAs are trusted parties contacted by entities wishing to obtain X.509v3 certificates [22]. In such a case, a CA is obligated to validate the binding between an entity’s name and a presented public key. If the CA successfully validates such a binding, a certificate stating so can be issued. In the TLS PKI, the public-key validation is conducted once per certificate and is usually automated by following the trust-on-first-use model over an insecure protocol like DNS, HTTP, or e-mail [12]

. It is called a domain validation and this approach provides poor security as an adversary able to launch a man-in-the-middle (MitM) attack even for a moment 

[31, 13] can obtain a certificate (for the attacked entity) which will be valid for several months. (A sophisticated off-path attack was presented recently [16].)

In most TLS applications (like HTTPS), only servers have certificates and usually, they are identified by their associated DNS domain names. Clients verify certificates by checking whether they are issued by CAs from the list of trusted CAs (this list is provided by software vendors — operating systems, browsers, or TLS implementations).

2.4 Blockchain and Smart Contracts

Blockchain platforms started emerging with the advent of Bitcoin [53]. Bitcoin is a cryptocurrency which for the first time introduced the concept of decentralized and permissionless consensus combined with an immutable data structure. This concept was quickly extended to more powerful systems that besides monetary transfers offer other features and functionalities. In particular, smart contract platforms received a lot of attention, as aside from simple monetary transfers they allow users to specify arbitrary agreements that can be encoded in high-level programming languages which these platforms offer. As of writing this paper, Ethereum [17] is the most popular and developed smart contract platform.

Ethereum is an open platform where anyone can make a monetary transfer, submit its smart contract, interact with other contracts, or become a miner (i.e., a node that is running the underlying consensus protocol). It provides its native cryptocurrency — ether. Ethereum users have unique addresses (identifiers) that are encoded as hashes of their public keys. Similarly, every smart contract instance also has a unique address that is derived as a hash of concatenated its creator’s address with a nonce. To interact with the platform a user signs and sends a transaction which transfers ether to another account or/and calls a contract’s method (specifying the targeted contract, the method to be called, and its arguments). Transactions are collected by miners who execute them and run the consensus protocol to append new transaction blocks to the blockchain (it is required to keep a consistent version of its global state). Callers have to supplement their transactions by an execution cost called gas purchased in ether from the miner who has appended the transaction to the blockchain. Gas consumption depends on the operations that the call executes.

Ethereum enables smart contracts to store a persistent storage. The storage is maintained by miners and it is part of the global blockchain state. Each contract has its state associated, and this state can be accessed through the state tree, which is an instance of the Merkle Patricia Tree (MPT) data structure [27]. The state tree is authenticated by including its root in each block header, as depicted in Fig. 2. Using the tree, it is possible to efficiently access a contract’s state that includes its nonce, its balance, the hash of its code, and the root of another MPT storage tree, including the contract’s storage. Besides accessing state nodes, an MPT (as a Merkle tree variant) allows to prove that a given leaf is part of the tree. It is realized with an MPT proof, a set of nodes that allows to rebuild the tree’s root. The size of this set is logarithmic in the number of MPT leaves.

Fig. 2: An Ethereum’s block header with the associated trees.

Thanks to this design, it is possible to prove to light clients [26] what is the current state (code, balance, and nonce) or storage of a given smart contract instance. Light clients are blockchain clients that store only block headers without storing the entire blockchain. For instance, to prove that a given storage is part of a contract’s state, one provides a light client with a) an MPT proof (of that storage) that roots in the contract’s state node (i.e., StorageRoot, see Fig. 2), and b) an MPT proof (of the state node) that roots in the state root encoded in a block header (i.e., StateRoot, see Fig. 2). With only block headers, a light client can easily validate these proofs by rebuilding the corresponding MPT roots [26].

3 SmartCert Overview

3.1 System Model

SmartCert introduces the same parties as in the TLS PKI. Domain provides a service via the TLS protocol (e.g., HTTPS). We assume that services, and servers that host these services, are identified by DNS domain names. (For simple description, we use the terms “domain” and “server” interchangeably.) We assume that domain’s servers can interact with the blockchain network, obtaining MTP proofs. CA is a trusted party that certifies bindings between identities and their public keys. We assume that CAs have key pairs that can be used over the blockchain platform, and CAs are able to send transactions to the blockchain platform. CAs in SmartCert are similar to TLS PKI CAs, except they are not completely trusted and their actions are self-monitored and self-enforced by a smart contract code and domain policies. Client wishes to contact a service (served by a domain) in a secure way. Clients trust CAs and they are also blockchain light client able to obtain the blockchain block headers.

We assume that these parties can interact with a blockchain platform that supports smart contracts. In particular, we focus on Ethereum; however, SmartCert can be adjusted to most smart contract platforms available. For demonstration, we assume various adversary models and first, an MitM adversary is assumed. We assume that MitM attacks are short-lived; otherwise, a permanent attack would make every domain-validation scheme ineffective [81]. The goal of the adversary is to conduct an impersonation attack undetected. We assume that the used cryptographic tools are secure and that the adversary cannot undermine the security properties of the underlying blockchain platform. Moreover, we assume that CAs can misbehave by not undertaking their duties (or conducting them incorrectly), but every such misbehavior should be detectable. We also consider a stronger adversary who in order to impersonate a domain can collude with malicious CAs; however, we assume that the domain can always prove its identity to honest CAs, for .

3.2 Design Space

TLS PKI Issues  Certificates in the current TLS PKI do not provide a high level of security. We discuss some of their design inherent issues that contribute to this state.

A public-key validation is conducted only once per the certificate lifetime (i.e., prior its issuance) and certificates are “static”, i.e., cannot be updated even if the claims they contain are outdated or incorrect. For instance, a MitM adversary able to impersonate a domain even for a moment can obtain a certificate valid for several months. Moreover, a certificate is asserted only by a single (any trusted) CA what inherently limits its security. In particular, an adversary compromising one CA can impersonate any domain on the Internet, as we have seen in the past [63, 1]. Next, certificates are decoupled from the information about their validity, i.e., their content is insufficient to provide high guarantees to relying clients who validate them. For instance, revocation information regarding a certificate is not part of the certificate and is stored and managed by a separate infrastructure. Thus, to fully validate a certificate, a client has to obtain information from an external infrastructure. As a result, the certificate validation depends on availability and security of multiple not well-connected infrastructures. To illustrate this complexity Fig. 3 depicts the currently deployed PKI infrastructures and their interactions. Certificates are inflexible in terms of introducing new functionalities and features, and their abilities are bound by their format which contains signed statements, assertions, and metadata produced at the time of their issuance. For instance, current certificates cannot be authenticated by multiple CAs, effectively providing the same security level for all domains. Another issue is a lack of domain expressiveness. Domains cannot specify and enforce their security policies. In practice, it would be beneficial if domains could specify secure and flexible policies, like CAs authorized to issue their certificates or a number of CAs that certificates have to be asserted with.

Fig. 3: PKI infrastructures involved in the certificate validation.

Design Rationale  We argue that in order to significantly improve the security of TLS PKI, a major redesign of digital certificates and their ecosystem is necessary. First, certificates should be self-contained, carrying all information needed to validate them, such that when a client receives a certificate, she should be able to validate it immediately without contacting any other parties or infrastructures. A framework should improve the security of TLS connections. It should integrate the state-of-the-art security solutions and properties (like transparency) and certificates should offer stronger authentication of public keys (e.g., multiple validating CA) and it should be possible for domains to express and enforce their security policies (e.g., a list of trusted CAs). The framework should also be able to provide desired features impossible or difficult to provide now. One such example is key continuity [33] indicating how long a public key is being used by a domain. Implementing such functionalities would imply that certificates are becoming rather “dynamic” as their internal state change over time. The framework should be efficient. For instance, many previous proposals for a revocation system has failed due to their inefficiencies [46]. Lessons learned from these and other attempts are that: a) clients should not incur excessive storage overheads, and b) during TLS handshakes clients should not conduct any blocking connections to third parties. The framework should provide a viable and incremental deployment path. In particular, it should be feasible to deploy the scheme without major changes to the ecosystem and existing protocols, or requiring new infrastructures.

The main observation behind SmartCert is that the blockchain and smart contract technology allows us to rethink and redesign the concept of a digital certificate, and to propose a system that meets the stated requirements. As depicted in Fig. 3, today’s certificate management and validation is underpinned by multiple distinct infrastructures with different goals and operators; however, with similar requirements (like availability and authentication). We observe that functions of these infrastructures can be easily implemented and potentially automated with the blockchain technology and smart contracts. First, blockchain platforms provide a good point of anchoring trust as they are transparent, immutable, highly available, and censorship resistant. Second, smart contracts enable us to create objects that can carry states updatable by a predefined code. In our case, we can represent a certificate and its current validation state as such an object. Consequently, the state can evolve, but only according to the domain’s policy and the rules encoded in the corresponding smart contract. For example, these rules may require multiple authorized CAs to periodically conduct public-key validations which then would be reported and checked by the code itself. That would result in self-contained and updatable certificates, where trust placed in CAs is minimized as compliance of their actions is enforced and audited by the code. Lastly, the data models of blockchain platforms enable light clients that do not have to store nor process the entire blockchain but still can benefit from it.

3.3 High-level Overview

In SmartCert, we propose to leverage smart contracts to create dynamic, self-contained, extensible, and policy self-enforcing certificates. The central point of our design is to compose a digital certificate from its validation and presentation logic. The validation logic maintains the current validation state of the certificate and its compliance with the domain’s policy, while the presentation logic presents this information to clients. Following this design, the following elements are central to SmartCert:

Policy contract

is a smart contract that manages domains’ security policies. Policies describe when domain’s certificates are considered as valid. We assume that there is one global instance of this contract with a publicly known address. Every domain can have a single policy at the time and if there is no policy for a domain the default policy is used.

SmartCert contract

is a smart contract that implements, encodes, and enforces the public-key validation logic and policy compliance. The validation logic is expressed as a code (in the blockchain platform’s programming language) with an associated storage. By executing the logic, the contract modifies its internal storage that reflects the validation state and its compliance with the domain policy (accessed from the policy contract). SmartCert contracts can implement arbitrary logic, although we expect that only some, standardized, validation logic will be used in practice.

SmartCert certificate

is an information that, in a secure and efficient way, presents TLS clients the current validation state of the contract. Clients accept or reject TLS connections basing on SmartCert certificates presented.

Throughout the paper, we present SmartCert in a setting where SmartCert certificates carry information about historical public-key validations of a given domain conducted by multiple CAs. However, SmartCert can be implemented with almost arbitrary validation logic as it is only limited by the smart contract language deployed. We discuss other validation logic in § 7.5.

A high-level overview of SmartCert is presented in Fig. 4 and its steps are outlined below.

Fig. 4: A high-level overview of the SmartCert architecture. Dotted lines are for one-time operations, dashed lines for periodic actions, and solid lines for the TLS client-server communication.
  1. In the first step, a domain creates its policy describing a set of conditions that its certificates will have to meet (e.g., what are authorized CAs or the maximum certificate lifetime). To bootstrap the policy, the domain contacts a number of CAs (at least one) with a request to sign the domain’s policy. The CAs verify the domain’s identity, sign the policy, and publish it at the policy contract. Policies can be updated subsequently; however, every domain can have only one “active” policy at the given time. The domain can skip this step and rely on the default policy.

  2. Then, the domain deploys a SmartCert contract on the blockchain, created from a predefined (trusted) code template. It is initialized with the data like the domain name, the domain’s public key, and the CAs that will be validating it. (We assume that the CAs are informed about the contract either by looking at the blockchain or out-of-band, e.g., via CA websites. In fact, the contract can be deployed by a CA instead of the domain.)

  3. Within every

    validation epoch

    (or just epoch), every CA listed in the SmartCert contract is obligated to validate the domain’s public key and update the contract:

    1. a CA contacts the domain with a validation request,

    2. the domain returns a validation proof which proves that at the time the domain possesses the private key corresponding to its public key from the contract,

    3. the CA updates the contract with the validation proof. The contract verifies it and updates its storage accordingly, reporting all occurred errors if any.

    4. Finally, the SmartCert contract checks if its validation state is compliant with the domain’s policy and saves the outcome of this check as a validity status.

  4. Periodically, the domain obtains from the blockchain network fresh MPT proofs proving on the SmartCert contract instance and its internal validation state.

  5. For every TLS connection, the domain sends to the client the SmartCert certificate that consists of the MPT proofs accompanied with required metadata. The client validates if a) the corresponding SmartCert contract was created correctly (i.e., has the correct code), b) its validity status is correct, c) and the MPT proofs are authentic and fresh. Then, the client either accepts or rejects the TLS connection.

    SmartCert certificates carry historical information about public-key validations conducted, like the number of errors occurred or the last successful validation; thus, they can be combined with sophisticated policies or they can be used by domain operators to monitor validations.

4 SmartCert Details

4.1 Policy Creation and Update

To facilitate domain expressiveness SmartCert introduces a global policy contract that contains a list of all trusted CAs (identified by their public-key hashes) and that allows domains to publish their certificate validation policies. By registering a policy, a domain specifies a set of rules that domain SmartCert certificates will have to be compliant with. Whenever a domain wishes to register its policy it contacts CAs (at least one) that check the domain’s identity, sign its policy, and publish it with the global policy contract mapping domain names to their policies (see newPolicy() in Alg. 1). From that moment, everyone can easily look up the domain’s policy by calling getPolicy() of the policy contract. If a domain does not register its policy, the default policy, with a relaxed security level (similar to today browser policies), is used.

dfltPolicy: the default policy; trustedCAs: the list of trusted CAs. function init()
function newPolicy(name, policy, sig[])
        /* policy update via policy key */
        if  then
               assert ; ;
       /* policy registration or replacement */
        else if  then
               assert ; /* make sure at least one CA signs*/
               for  do
                      assert ;
                      assert ;
              ; ;
function getPolicy(name)
        if  then
               return ; /* return policy if registered */
       return ; /* return default */
Alg. 1 Policy Contract.

The main fields of a policy are: KEYID is a policy management public key identifier (unset in the default policy) that allows a domain to: update the policy, revoke any certificate claiming the domain name, and is mandatory for creation of any certificate claiming the domain name. As these actions are infrequent, the corresponding private key can be stored offline. CAs is a subset of trusted CAs authorized to keep validating domain certificates (every trusted CA is authorized by default); MAX_LIFETIME is the maximum lifetime a domain’s SmartCert certificate can have (two years by default, as today); MAX_ERR is the maximum number of validation errors per authorized CA to count this CA’s validation as successful (unset by default); MIN_CAs is the minimum positive number of authorized CAs that validated a domain’s SmartCert certificate successfully (set to 1 by default).

Each policy has other metadata associated, like its version, type (e.g., new or updated), and the number of distinct CAs which have signed it. Security policies should be long-term and stable; however, domains from time to time would need to modify them. Each policy includes its management key that can be used for the policy update. In the case of the key loss or compromise, the policy can be replaced by a new policy signed by at least the same number of CAs as the previous policy (see newPolicy()). At any given time, every domain can have only a single “active” policy. We discuss the policy contract management and other possible policies in § 7.5.

4.2 SmartCert Contract Creation

To create a SmartCert certificate, a domain has to create a SmartCert contract instance first. Domains follow the same code template to instantiate SmartCert contracts, and we assume that clients are pre-loaded with the corresponding code hash of that template (thanks to that, clients will be able to verify that the received SmartCert certificates were created using the authentic SmartCert contract code). After the contract is appended to the blockchain it is initialized (see init() in Alg. 2). First, the initialization procedure ensures that if the domain has its policy, the SmartCert contract is created with the private key corresponding to the policy key (creating a binding between the policy and the contract). Afterwards, the following contract fields are set: is the domain name for which the certificate is being issued; is the public key of the certificate; denotes when the SmartCert contract was created; is the revocation flag; is the validity flag; is the set of CAs that revoked the certificate; denotes the time of the last SmartCert contract update; is a map of CAs authorized by the domain to keep updating the contract and their validation states with three following fields: denotes the time of the last update of the given state; stands for the time of the last validation error (it can be either invalid validation proof sent to validate or no data sent, i.e., a skipped validation); is the number of validation errors occurred so far. After the initialization is completed, the SmartCert contract instance is ready for deployment.

is the global policy contract; lastBHash() returns the -th last block hash; lastBTime() returns the -th last block timestamp; now() returns the timestamp of the current block; cliRnd, srvRnd, params, : elements of the signed message SKE sent by the domain to the CA (see § 2.2, Eq. 2, and Fig. 5 for details); is a map of CAs and their validation states. function init(name, key, CAs)
        if  then
               assert ;
       ; ; ;
        ; ; ; ;
        for  do
               assert ; ;
               ; ;
function update(cliRnd, srvRnd, params, )
        ; assert ;
        /* check for skipped validations of CAs*/
        for  do
               if  then
       /* ensure that cliRnd is fresh */
        ; ;
        for  do
               /* check if the -th last block is in the epoch */
               if  then
              /* check if the -th last block hash matches */
               if  then
                      ; break;
       /* check the freshnes and verify the signature */
        if !fresh or ! then
               ; ++;
       ; ;
function revoke()
        ; ;
        if  then
               ; ;
       if  then
               ; ; ;
function isCompliant()
        ; ;
        for  do
                   and  then
       return ;
Alg. 2 SmartCert contract.

4.3 Public-Key Validation and Contract Update

In our scenario, SmartCert certificates carry information about historical validations of their public keys associated. To realize it, every epoch (a system parameter discussed in § 7.3), each authorized CA conducts the public-key validation with the domain and submits the obtained validation proof to the corresponding SmartCert contract to update it. The goal of this procedure is to “convince” the SmartCert contract that the domain still possesses the key pair, such that the contract can verify it and update its storage to reflect the validation state accordingly. Such a proof should be: a) short, so a smart contract can process it efficiently b) authentic, proving that the private key, corresponding to the public key specified in the SmartCert contract, is being used, c) fresh, proving that the information was produced recently.

The authenticity is necessary as it should be infeasible to produce fake validation proofs that a given key in being used. Moreover, a SmartCert contract must be able to verify that proofs are authenticated by the private key associated with the public key that the contract was initialized with. On the other hand, the freshness is critical, as otherwise a malicious CA could just produce multiple validation proofs at once and keep submitting them later to the SmartCert contract over some extended time period. Therefore, a SmartCert contract must be able to verify that the validation proof is recent. However, these two requirements are challenging to meet in the TLS setting.

Authenticity  The TLS protocol was not designed to provide non-repudiation for application-level data. Therefore, it is impossible to prove to third parties that a server produced given data. However, such proof is necessary for our setting, as SmartCert contracts have to be able to verify that a given private key is being used. One possible approach to tackle this problem is to design and deploy a new protocol or an extension that would allow servers to sign date [9, 61]. However, that may be undesired as introducing a new dedicated protocol have side effects, like larger trusted computing base and a long standardization and adoption process. Instead of introducing a new protocol, we make an observation that although TLS does not provide non-repudiation for application data, the TLS handshake messages can be used to achieve this goal. More specifically, as described in § 2.2, during the TLS handshake with a negotiated ephemeral DH key exchange method, the server signs client’s and server’s random values (CH.r and SH.r, respectively) together with the DH parameters. The signature is placed in the ServerKeyExchange message (SKE) sent to the client; therefore, it can be used as a proof that the server’s private key is being used. CAs can obtain such proofs by simply running TLS handshakes with targeted domains.

Freshness  The message authenticity is insufficient for a complete validation proof. A CA could conduct multiple handshakes at once and keep using them later on as “current” validation proofs. Thus, the second challenge is to provide freshness for that information. Interestingly, the client’s and server’s random values as specified in the TLS specification [23], should contain a GMT timestamp encoded in the first four bytes of these fields (see Fig. 1). Therefore, the ServerKeyExchange message containing the server’s random value contains also the server’s timestamp. Unfortunately, we cannot rely on this field, as only 37% of TLS servers put accurate timestamps in their TLS handshakes [72]. Moreover, the TLS protocol does not require protocol parties’ clocks to be synchronized [23] and some implementations randomize timestamp fields as a prevention from fingerprinting [49].

One approach to solving this issue is to use external time sources to timestamp TLS handshakes but that would require the introduction of new trusted parties and reliance on their availability. To overcome that problem, we make an observation that the blockchain platform itself acts as a source of time. Blockchain blocks are ordered (linked by a hash function) and contain their creation timestamps (see Fig. 2). Therefore, a CA could set its ClientHello’s random field (CH.r) to the current block hash and conduct a TLS handshake. Then when this value is signed by the server (within the SKE message), it implies that the handshake happened after the block was mined. Therefore, the SmartCert contract will be able to verify that the validation proof is fresh, checking whether the signed block hash is recent (smart contract platforms, like Ethereum, natively support accessing previous block hashes). In that way, the validation will be automated and without introducing any additional trusted parties or protocol changes.

Fig. 5: Details of the SmartCert contract update process.

Public-Key Validation and Contract Update  The public-key validation is initiated by a CA once per epoch. The entire process is depicted in Fig. 5 and Alg. 2 (see the update() method), and we discuss it in detail below.

  1. The CA and domain execute a TLS handshake:

    1. The CA gets the latest block () hash, creates a hello message CH, prepends the hash with its blockchain identifier () and sets it as the random field of the message:


      The CA identifier is added to ensure that any other CA cannot replay the validation proof. The message CH is sent to the domain.

    2. The domain sends back the messages SH,Cert,SKE, and SHD. The ServerKeyExchange message SKE contains the signature over the random fields and the key exchange parameters (see Fig. 1 and § 2.2). This signature together with the fields it protects constitute a validation proof.

  2. After receiving the proof, the CA prepares and disseminates a transaction to trigger the update() method of the SmartCert contract (see Alg. 2), that will be executed with the elements of the validation proof as arguments:


    where CH.r is set to the block hash set by the CA.

  3. Network participants (i.e., miners) constantly collect new transactions and try to mine a new block.

    1. Miners validate the transaction by executing update(). The method checks if the submitter is an authorized CA, if the certificate is still valid, and executes the following verification logic.

      1. Check if any authorized CA skipped a validation and every missed validation count as an error.

      2. Check whether the message is fresh by comparing CH.r with the previous block hash(es). Due to the network propagation time [80], multiple older block hashes can be checked (see § 7.3 for more details); however, all these blocks must belong to the current epoch (to avoid replayed validation proofs). If the matching block hash is found, it implies that the TLS handshake was conducted after the block was mined (as the hash is within the CH.r field); thus the validation proof is fresh.

      3. Verify the authenticity of the handshake’s SKE message, i.e., ensure that it was signed by the domain’s private key corresponding to the public key with which the contract was initialized.

      4. Update the contract’s internal storage indicating that it just got updated (i.e., the last validation timestamp is updated). If any of the above checks fails, the counter of errors is increased and the last error time is updated.

      5. Determine the validity status by checking if the validation state is compliant with the domain’s policy (see isCompliant()). In this check, the contract gets the domain’s policy via the policy contract and checks if a) the CAs updating the contract are authorized, b) their validation states are correct, c) the certificate lifetime is not exceeded, d) and the number of correct validations is at least as specified in the policy. If the policy compliance check fails the certificate will be marked and treated as invalid (i.e., valid=False).

      At the end of this process, the SmartCert contract has validated the authenticity and freshness of the handshake message and updated its internal storage accordingly to the domain’s current policy.

    2. Miners mine block with validated transactions.

    3. When the new block is mined and propagated it becomes part of the blockchain. The block contains the updated state of the SmartCert contract.

The update procedure requires an interaction with a smart-contract platform. As we show in § 6.2 even with the existing platforms the execution cost is acceptable.

Revocation  Like in the TLS PKI, certificates can be revoked when they are issued by a mistake, their associated keys are lost/stolen or not used anymore, or their owners just wish to revoke them. A SmartCert certificate can be revoked by a quorum of its authorized CAs or the domain owner. In order to do so, the revoke() method is triggered, which verifies whether the calling entity is authorized and upon a successful revocation sets the revoked flag to True and the valid flag to False. With that change, the SmartCert certificate is revoked and immutable, as the update() method checks the validity status prior to executing the rest of its body.

4.4 SmartCert Certificate and its Validation

SmartCert does not change the TLS protocol and it follows the standard TLS connection establishment as described in § 2.2. The only change is that instead of sending an X.509v3 certificate, the server sends a SmartCert certificate, which consists of the following elements:

is the blockchain address of the SmartCert contract,

is the storage of the SmartCert contract that encodes the domain name, its public key, and its current validity status (i.e., whether the certificate is valid or not),

is an MPT storage proof proving that the given contract instance’s storage is part of the blockchain.

is an MPT code proof proving on the code of the SmartCert contract (without this proof a malicious CA could deploy a contract with a different code).

To prevent replay attacks, the storage and the proofs have to be fresh, so the domain periodically, e.g., every several hours, fetches new proofs from the blockchain and serves them in every subsequent TLS handshake. We emphasize that this setup is privacy preserving as clients do not contact the network for fresh proofs (revealing domains they connect to). The SmartCert certificate validation is described in Alg. 3. In the first step, the client verifies if: a) the MPT proofs provided are consistent and authentic, i.e., they correspond to the same smart contract address and they belong to the blockchain whose block headers the client stores (TLS clients are also blockchain light client), b) the code proof proves on the correct smart contract code (CAs have to follow the same code template and the clients are pre-loaded with the hash of this template codeHash), c) the storage proof proves that the passed storage belongs to the contract.

codeHash is the hash of the trusted SmartCert contract code stored by clients; maxStale denotes the maximum tolerable difference between the current time and the time of the last update of the presented certificate (see § 7.3), . function verify(name, addr, st, )
        /* check proofs authenticity and consistency */
        if ! or
            ! or
            !  then
               return FAIL;
       /* check the name, validity, and freshness */
        if  or ! or
               return FAIL;
       return OK; /* continue the handshake with */
Alg. 3 SmartCert certificate validation.

When the client knows that the storage corresponds to an authentic SmartCert contract instance, the client verifies whether a) the SmartCert contract is issued for the contacted domain, b) the certificate is valid (i.e., compliant with the policy and non-revoked), c) the storage is fresh enough i.e., was updated no longer than seconds ago. The validity of the SmartCert certificate implies its compliance with the domain’s policy (note, that the correct code template guarantees that the contract keeps checking its compliance with the correct policy). In our example, the SmartCert contract self-enforces the policy by checking if the number of public-key validation errors does not exceed the maximum number allowed and if validations were successfully conducted by the minimum number of authorized CAs as specified by the domain. Interestingly, with changing policies and SmartCert contracts, TLS clients stay almost unchanged, as they only check the validity of the certificates while the compliance checks and validations are conducted by SmartCert contracts themselves. After the certificate is successfully validated, the client continues the TLS handshake with the domain’s public key specified in the SmartCert contract storage (i.e., ).

5 Security Analysis

SmartCert provides multiple security benefits over standard certificates. First of all, SmartCert provides a reliable and easy, yet powerful, policy framework supporting domain expressiveness. Domains can publish their policies specifying conditions under which SmartCert certificates are considered valid. Policies can be authenticated by multiple CAs (at least one); thus, SmartCert is not a weakest-link system anymore. Furthermore, if a domain’s policy is published it guarantees that a) no SmartCert contract (and no SmartCert certificate, consequently) can be created without the domain’s consent, and b) all SmartCert contracts claiming the domain’s name will self-enforce the policy. For the former, if there exists a policy for a domain name, a SmartCert contract with that name specified can be created only when it is authenticated by the domain’s policy key (see init() in Alg. 2). For the latter, SmartCert contracts with every update check their compliance with the policy; thus, any non-compliant contract will invalidate itself with the first update and consequently will be rejected by clients (note, that clients check if the SmartCert contract code is correct to ensure that the validation rules are respected). An adversary can present such an invalidated SmartCert certificate to clients, but only for maxStale seconds from its latest update (then clients will reject it – see § 4.4).

Beside authenticating policies by multiple authorities, valid SmartCert contracts have to be successfully authenticated by a minimum MIN_CAs CAs from the CAs set, as specified by the domain. Therefore, it increases the security as certificates are being validated by multiple authorized CAs and it limits adversary’s capabilities as an adversary compromising a CA can only update certificates that have authorized this particular CA. An adversary able to compromise multiple () CAs can try to impersonate a domain by updating its policy. Such an attack will be successful if is at least equal the number of CAs that signed the current legitimate policy. However, as assumed the domain can obtain a new policy signed by CAs, and submit it to invalidate the malicious policy. As policy keys are used infrequently (only for policy updates, SmartCert contract creations, and revocations) they can be stored offline increasing the security. However, in the case of key loss or compromise, the same policy update procedure is executed. Besides, all policy changes are publicly visible so the domain should be able to quickly mitigate these threats.

If a domain deploys SmartCert certificates without a policy specified, the default policy is used. It authorizes any trusted CAs to validate domain certificates, so an adversary able to compromise a single CA can impersonate the domain without a policy. Such an attack would be detectable easily, as the malicious contract would be published on the blockchain. In such a case, the domain can quickly bootstrap its policy and revoke a certificate claiming its domain name via the policy key. The adversary would not get a successful validity status for the revoked certificate (the SmartCert contract would self-invalidate with the successful revocation), but she would be able to use the old proofs for at most seconds.

SmartCert contracts encode their current validation states; therefore, it is easy to get a better view of public keys of contacted domains. More specifically, in the presented setting, a SmartCert contract encodes the key continuity measure and checks its compliance with the domain’s policy, and then reflected the compliance in the SmartCert certificate. CAs are obligated to conduct public-key validations periodically, and this procedure is enforced and monitored by the smart contract’s code. Such a design allows to provide the functionality of notary systems detecting and preventing various MitM attacks where e.g., an adversary impersonates the website presenting a different certificate. If a CA is presented with the malicious key, it will be visible as it will be reflected in the SmartCert contract. Moreover, a CAs without breaking the blockchain platform cannot prefetch validation proofs as they require recent pseudorandom block hashes.

SmartCert contracts are designed such that only authorized CAs can update them and such updates are validated by the code and individual domain policies. Therefore, SmartCert minimizes trust placed in CAs. If a malicious or unavailable CA does not submit a validation proof within an epoch or submits an invalid validation proof, the SmartCert contract will detect it and report that fact in its internal storage. Similarly, a replayed or outdated validation proofs will not be accepted by the SmartCert contract as valid and an error will be recorded as well. Consequently, SmartCert provides an important property that if a domain is under a MitM attack during an epoch, it will be reflected in the corresponding SmartCert contract and issuing CA cannot refuse or hide this fact. This design is beneficial not only for TLS clients but also for domains who can detect attacks much easier just by looking at their SmartCert contracts (see § 7.5).

SmartCert benefits from the underlying blockchain platform in other ways. An immediate benefit is a high availability, which turned out to be an Achilles heel of almost all security infrastructures. SmartCert certificates are created and distributed via the blockchain platform, and they contain all information required to validate them (like a validation state and a revocation status). Domains obtain fresh MPT proofs just by interacting with the blockchain network, which is distributed, available, and censorship resilient. CAs need to be able to only send transactions to the blockchain network, but they do not need to invest in any highly-available front-end servers to serve TLS clients. It increases the security of the system significantly, as an adversary trying to launch a Denial-of-Service attack on a CA or wanting to censor CA transactions needs to undermine the properties of the blockchain platform what requires a (significant) control over the blockchain network. Another important benefit of basing SmartCert upon the blockchain platform is transparency. All policies, certificates, and other CA actions are publicly visible. Therefore, SmartCert allows to detect CA mistakes or tailored attacks where a fraudulent certificate is created by a malicious or colluding CA for a one-time targeted attack. In § 7.5 we discuss how smart-contract platforms facilitate such a monitoring. In addition, parties in SmartCert cannot equivocate, e.g., by registered two policies for the same domain, as long as they cannot undermine the properties of the blockchain platform. Finally, SmartCert is privacy-friendly, since SmartCert certificates are self-contained and sent to clients by servers during TLS handshakes. Thus, clients do not need to contact any other parties (like CAs) or services to fully validate SmartCert certificates.

6 Implementation and Evaluation

6.1 Implementation

We implemented all SmartCert elements, namely a SmartCert-supported client, server, CA, and smart contracts. Although SmartCert can be implemented with more performant permissioned blockchains (see § 7.1), we present it in a more challenging open setting; thus we selected Ethereum as the blockchain platform and implemented the contracts in Solidity. For in-contract signature verification, we used and extended the SolRsaVerify package, which provides a verification code for RSA signatures used in ServerKeyExchange messages (i.e., RSA-PKCSv1.5-SHA256 [39]). We implemented RSA signatures since they are most common as a TLS authentication method [37]. The CA is implemented in Python and it consists of a) a blockchain-communication module to interact with the Ethereum platform and contracts, and b) a modified TLS stack that obtains validation proofs from TLS handshakes. The former module is realized with the Web3py package that allows CAs to get a recent block hash (used in public-key validations — see § 4.3 and Alg. 2) and send transactions to policy and SmartCert contracts. For modifying the TLS stack we used the tlslite-ng library. With our changes, prior a TLS handshake, a TLS client can pass an arbitrary string as its hello’s random value (CH.r), and then get it signed together with the fields of the ServerKeyExchange message (i.e., SH.r, SKE.p, and ). We implemented a SmartCert server with NGINX 1.15.2. Our server differs from a standard TLS server by two following elements: a) it periodically obtains fresh MPT proofs, and b) it transfers its SmartCert certificate to the TLS client. The first functionality is implemented with a help of the eth-proof package, while the second one is realized by employing the OCSP stapling extension [59] allowing a server to piggyback a SmartCert certificate during a TLS handshake. Moreover, such an implementation is backward-compatible as SmartCert-unsupported clients can ignore the extension (see § 7.2). SmartCert client, realized mainly in Python, implements the TLS connection establishment, parsing of the OCSP stapling extension, and the SmartCert certificate validation logic (see Alg. 3), including the verification of MTP proofs (via the eth-proof package).

6.2 Evaluation

Smart Contracts

  Deploying and interacting with smart contracts over Ethereum is associated with a gas cost. Each operation costs a pre-defined amount of gas, and operations can differ significantly in their gas consumption. To estimate the cost in US dollars we used the following data from obtained on 20 Mar 2020: we used the standard gas price equal 1.8 Gwei/gas (1 Gwei = ether) with the ether price equal $150/ether. We deployed our smart contracts on an Ethereum testnet. First, we measured the cost incurred by registering a policy with the policy contract (see newPolicy() in Alg. 1). The overall cost is around $0.23 and it is mainly due to the transaction size and the storage required for the policy fields. Next, we investigated how expensive it is to deploy SmartCert certificates. In our experiment, the contract was deployed for, with which a CA kept conducting TLS handshakes periodically (as presented in § 4.3) and kept submitting obtained validation proofs to update the SmartCert contract. signs ServerKeyExchange messages with RSA-2048 and the results of this experiment are presented in Tab. I. As shown in the table, creating and initializing the contract is more expensive than updating it, and according to our estimation, it costs around $0.36 (it is a one-time cost per SmartCert contract). To update a SmartCert contract by a validation proof, a CA has to pay about $0.045 in that scenario. As depicted, the RSA verification is the update()’s dominant operation, consuming almost 56% of all gas required.

create update()
+ init() Total SigVrfy() Misc.
Gas 1343799 165885 92623 73261
ETH 0.00289 0.00036 0.0002 0.00016
USD $0.361 $0.045 $0.025 $0.020
% 100% 100% 55.8% 44.2%
Tab. I: Cost analysis of the SmartCert contract operations.

The cost of maintaining a SmartCert certificate is mainly determined by the epoch parameter (see discussion in § 7.3). In Tab. II we present a monthly cost depending on epoch values assuming a single CA (the cost is linear to the number of CAs). As shown, the cost is inversely proportional to epoch, e.g., the monthly cost for a SmartCert certificate validated every day is $1.26.

Epoch 6h 12h 24h 48h 72h
Cost $5.05 $2.53 $1.26 $0.63 $0.42
Tab. II: A monthly deployment cost depending on epoch values.

Ethereum, like other blockchain platforms, is under heavy development. Therefore, we envision that with scaling solutions and more mature implementations (e.g., natively-supported RSA operations), the gas consumption presented may be much lower in future, consequently lowering the overall cost of SmartCert deployment.

CAs  The main overhead on the CA’s side is to conduct periodic validations which is equivalent to running TLS handshakes (see § 4.3). To estimate the throughput, we selected 10000 random hosts supporting TLS and we conducted periodic TLS handshakes with them. We used a machine equipped with Intel Core i7 (3.5GHz), 16GB RAM, and 100Mbps wired Internet connection. This single machine running connections in parallel could perform around 175 TLS handshakes per second on average, i.e., 0.63M handshakes per hour (the time is dominated by the network latency). Thus, assuming six hours epoch, only three machines could keep validating over ten million public keys, which is similar to the number of active TLS certificates currently issued by even large CAs [76, 78].

Transmission Overhead  SmartCert certificate size is the only transmission overhead introduced to a TLS connection. To estimate it we used a SmartCert certificate derived from the SmartCert contract deployed previously. The main contributors to the SmartCert certificate size are MPT storage and code proofs ( and , respectively). MPT proofs in Ethereum are generated for 32B-long words; therefore, a domain’s public key (usually, 256B long) requires multiple MPT proofs. However, these proofs are highly redundant, and in our scenario, the SmartCert certificate needs 4.11KB to be encoded. As reported [77], an average size of today’s X.509v3 certificate chain is around 4.75KB; thus, the size of SmartCert certificates is comparable with today TLS certificates.

TLS Clients  In SmartCert, TLS clients are also blockchain light clients obtaining and verifying new block headers (without actual blocks and transactions) from the blockchain network. In Ethereum, block headers are about 508B long; thus, at the time of writing, the Ethereum main network with 6.75M blocks requires from fully light clients [26] the storage overhead of about 3.43GB. However, storing all previous header is not necessary for validating SmartCert certificates. TLS clients do not accept SmartCert certificates older than the maxStale parameter. So, if a client rejects stale certificates with storage proofs older than three days, then the client needs to keep headers only for three last days (and keep dropping outdated ones), becoming a partially light client [26]. In this example, the storage required would be around 10MB.

Min Max Avg. Med.
[ms] 6.427 11.142 7.446 7.217
Tab. III: The performance of SmartCert certificate validation.

SmartCert clients validate obtained SmartCert certificates (see § 4.4) by sanity and control checks, and the validation of storage and code proofs. To evaluate computation overhead, we executed one hundred SmartCert certificate validations and measured their execution time. The obtained performance results are presented in Tab. III. As shown, even with our unoptimized implementation, the average and median values are about 7ms. It is relatively small when compared to latencies of TLS handshakes (around 200ms on average [54]) and should not be noticed by users [32].

7 Discussion and Practical Considerations

7.1 Limitations

Although SmartCert provides multiple benefits it comes with some limitations. First, despite designing SmartCert with deployability in mind, we are aware that our system introduces changes to the current ecosystem that may be seen as radical. We demonstrate that the system is feasible and efficient even when built upon existing tools and platforms, but given deployment experiences with other TLS PKI enhancement we should not assume that SmartCert will be deployed right away as it is. We rather predict that SmartCert would have to be deployed incrementally, what we discuss in § 7.2.

Second, multiple aspects of SmartCert (like economics, trust assumptions, and throughput) are influenced by the underlying blockchain platform. We evaluated SmartCert in an open environment to show that the certificate cost is reasonable even in such a challenging deployment scenario. However, we do not see any reason why SmartCert could not be deployed with a more efficient permissioned blockchain [8] (e.g., run by a consortium of CAs, browser vendors, and non-profit organizations). Alternatively, SmartCert could be also implemented on the top of incoming permissioned networks, like Facebook’s Libra [7], which would eliminate the costs of launching and maintaining a new platform.

Lastly, projects offering free certificates rapidly increase the adoption of TLS [3]. We see it as a very positive trend, but we do not believe that SmartCert can compete in adoption with (free) DV certificates as costs of deploying SmartCert may hinder domains satisfied with the current protection level. Instead, we see our scheme as a more secure alternative addressed to security-savvy domains. We argue that in the face of abandoning EV certificates, such domains have no other choice than deploying domain-validated certificates.

7.2 Incremental Deployment

SmartCert certificates cannot be introduced just by replacing X.509v3 certificates, as legacy TLS clients would not be able to interpret them. One approach is to leverage an extension mechanism of X.509v3 certificates [22]. This mechanism allows to create a signed content that is part of a certificate. However, a SmartCert certificate cannot be efficiently implemented as an X.509v3 certificate extension, as SmartCert certificates are dynamic and their state changes frequently (the X.509v3 certificate would have needed to be re-issued for every such an update). One way to deploy SmartCert in a backward-compatible manner is to serve SmartCert certificates through the OCSP stapling extension [59], which was designed to piggyback revocation status messages on the TLS handshake. Then, supported clients would be able to process SmartCert certificates, while unsupported clients would process X.509v3 certificates ignoring the unsupported extension. Usually, incremental deployment and backward compatibility create downgrade attack opportunities [5]. We envision that the presented deployment models could be extended by mechanisms like strict modes [35] or pinning [28] to avoid downgrade attacks on SmartCert.

7.3 Parameters

SmartCert introduces epoch whose value constitutes trade-offs between efficiency, availability, and security. With a shorter epoch, the CA conducts public-key validations more frequently, minimizing the attack window. On the other hand, shorter epoch requires more frequent interactions between the CA and the SmartCert contract incurring higher cost and overhead. Epoch determines also how long CAs and domain servers can remain unavailable, and what are tolerable blockchain confirmation times to avoid forks (around 10 minutes in Ethereum). Taking it into account and following a similar discussion on the short-lived certificates, we envision that epoch values could be in practice set between several hours and a few days. Moreover, SmartCert could support an epoch value per policy or even per certificate what would allow domain owners to adjust their certificates to unusual use cases (like backup certificates or certificates for inaccessible subdomains). SmartCert contracts as presented use the blockchain’s notion of time by calling the now() function that returns the timestamp associated with the current block. Open blockchains are peer-to-peer networks but to guarantee only small clock desynchronizations it is part of the consensus rules that block timestamps are consistent with the previous timestamps and the time of the nodes. Moreover, Ethereum nodes are “advised” to synchronize their clocks with an NTP server, thus the time within the network is quite precise (up to a several dozen seconds) and does not constrain epoch values significantly.

CAs use current block hashes to prove that their validation proofs are fresh. However, the time between the public-key validation and the update() method execution (i.e., between the steps 1a and 3b from Fig. 5) can be greater than one block. To tolerate such delays, SmartCert contracts check multiple previous blocks (see update() in Alg. 2). The number of blocks checked, let us denote it as , is variable and can be platform- and situation-dependent. For instance, it is reported [80] that almost 95% of Ethereum transactions are added and propagated in about 300 seconds (the experiments were conducted in 2017), while of the time of writing the website reports 115 seconds as an average delay for 95% of transactions. Since the average time of a new block arriving is around 15 seconds, we can conservatively assume that in most cases . Epoch bounds , i.e., in this setting; however, it can be further bound since Ethereum contracts can access up to 256 previous blocks, giving , what in practice means that a CA has to execute a update call within around an hour (precisely, ) after a validation proof was obtained. Such a margin allows CAs to avoid and recover from blockchain forks, since Ethereum transactions usually require 30 confirmation blocks to be seen as “secure”. An important client-side parameter is maxStale (see Alg. 3), denoting the maximum tolerable age the last public-key validation. A value of this parameter should be greater than the epoch, and similar to epoch, it introduces a trade-off between security and efficiency. By following standardization of similar parameters in TLS PKI [20], we envision that it can be set between a day and several days.

7.4 Tls 1.3

TLS 1.3 [60] was recently approved as an Internet standard. Although a quick upgrade to TLS 1.3 is rather unlikely and should not be expected [66, 70], the protocol introduces a few important changes. As mentioned before, TLS 1.3 removes the timestamp values from ClientHello and ServerHello random fields. That change does not influence SmartCert design much as it does not rely on these fields. A more important change is the removal of the ServerKeyExchange message type and the introduction of a new CertificateVerify message type instead. Fortunately, the semantics of the CertificateVerify message type are similar. In particular, that message is signed and the signature is computed over random fields supplied by a client and a server in their hello messages, so SmartCert can be easily adjusted to be operational with TLS 1.3.

7.5 Enhancements

Multiple Public Keys  For easy description, we presented SmartCert in a setting where a domain has one public key. It is a common practice that for operational reasons large domains posses and use multiple key pairs. SmartCert can be easily extended to handle this case. Namely, the SmartCert contract, instead of a single key, is initialized with multiple public keys. Then, for a validation proof submitted, the contract verifies if it was signed by a private key corresponding to one of the preloaded public keys.

Validation Policies  We demonstrate SmartCert in a setting that improves the currently used and dominant Internet-based domain validation, as the key continuity is measured by periodic public-key validations conducted by multiple CAs. SmartCert with “history-reach” certificates enables to define and enforce almost arbitrary validation policies; thus, we believe that other interesting SmartCert contract code template(s) and validation logic could be proposed. For instance, policies could specify that the ratio of validation errors (errNo) is less than a certain threshold (e.g., 10%). Policies could be also extended by parameters regarding TLS connection properties like the desired security level of used cipher suites (e.g., forward secrecy) or HTTPS pinning [28]. The policy framework could be extended to support other applications and their features, like e-mail policies [82, 43].

Policy Contract Management  We envision that the policy contract would be managed by a standardization body like the CA/Browser Forum. Such a body, like in today’s PKI, could influence decisions on which CAs can be added or removed from the trusted set or specify and standardize available security policies. In particular, the policy contract could store CA lists per browser vendor, since vendors have different lists today. With such a modification, certificates would have validation state per vendor. We also see potential advantages of SmartCert in terms of the on-blockchain CA keys management. Blockchain platforms, as reliable time sources, by design allow to establish an order of events, that may be especially helpful in revocation of compromised CAs. Such revocations are risky for the ecosystem, as they invalidate all certificates issued by the revoked CA as a side effect. SmartCert could be extended to remove this collateral damage from the TLS PKI [73], by revoking CA with specifying the compromise time. In such a case, a SmartCert contract would ensure that it was created prior to the compromise time; thus, is still valid.

Notifications  Blockchain platforms provide features that facilitate smart-contract-empowered applications. For instance, Ethereum provides asynchronous event notifications, which can be particularly helpful when combined with SmartCert. With this mechanism, one could implement the contracts, such that every policy update, SmartCert contract creation, or public-key validation error, would trigger a notification accessible by blockchain (light) clients almost immediately. Then, domain owners would be able to listen for these notifications and in almost real-time detect all policy changes, certificates created for their domain names, or their validation errors. That could reduce the attack detection time radically.

8 Related work

There are many systems that try to improve the security of digital certificates and PKIs. Short-lived certificates (SLCs) [62] aim to remove a revocation system [22, 67] by designing certificates to be valid for a few days. With SLCs domains have to conduct domain validation more frequently what mitigates short-lived MitM attacks, but as SLCs are irrevocable it also increases attack windows associated with compromised keys. Despite multiple tries to introduce them to the TLS PKI, SLCs were abandoned [18]. EV certificates [29] aim to improve the security of domain-validated certificates. To obtain an EV certificate, an entity has to prove that it a) controls the domain name, and b) is acting on behalf of the entity that is controlling the domain name. The latter check is manual and may require a face-to-face meeting; thus the value proposition of EV certificates is better security. Security benefits of EV certificates were questioned [38, 19] and their support in main browsers may be deprecated in a near future [65]. CAA [36] and DANE [34] are attempts to introduce domain expressiveness to the TLS PKI ecosystem, by allowing domains to publish at DNS(SEC) their simple security policies, like trusted CAs. Unfortunately, these schemes share issues of DNS(SEC), are difficult to enforce, and their adoption rates are low [75, 68] Notary systems such as Perspectives [81] and Convergence [48] use a multipath probing to give better guarantees to a client about the certificate she has obtained. They introduce trusted notary servers, that when requested by a client, check and return their views of the server’s public key. Then, the client can compare her view with the notary’s view and make a decision about the connection. Unfortunately, notary systems have privacy issues, increase the latency of TLS handshakes, introduce new highly available trusted parties [11, 52]. In SmartCert public-key validations are automatically validated by the smart contract code and recorded, providing reliable statistics.

Tab. IV: Comparison of the most related systems and SmartCert.

Sovereign Keys [25] is a system logging allowing domains to control (register or revoke) their certificates and making them visible. It is extended by CT [45] which aims to keep CA actions transparent. In CT, CAs submit all certificates (prior their actual issuance) to a publicly verifiable log which for every submission returns a signed promise that the certificate will be appended to the log’s database. A TLS client accepts a server’s certificate only if it is accompanied with the corresponding promise(s) from trusted log(s). As of the time of writing, CT is deployed with 32 public logs operated by 10 different organizations. Although CT is a significant improvement of the TLS PKI, it has some drawbacks. Logs do not run a consensus protocol so each log’s consistency has to be monitored separately that requires external gossip protocols [21, 55] run by clients. Logs have to be highly available and from the initial deployment, this seems to be challenging in practice [41, 40]. Moreover, CT provides limited security properties, aiming for certificate visible only, without asserting on its validation state.

Many systems improve CT’s security, efficiency, or add novel functionalities. For instance, ARPKI [10] (an improvement over AKI [42]) proposes a strongest-link PKI that remains secure even if an adversary is able to compromise all trusted entities but one. Properties of ARPKI are formally verified; however, the system introduces a static security parameter and requires significant changes to CAs. ECT [64] enhances CT by introducing revocation and supporting the e-mail communication, while DTKI [83] tries to relax trust assumptions of the previous system, but assuming a trusted initial setup with an honest log. The system is formalized; however, misses an implementation and practical considerations (e.g., ECT and DTKI increase the latency of TLS handshakes). Another approach with a similar goal is a distributed witness framework CoSi [71] where every seen certificate is asserted by a large group of authorities (instead of one or few, as in CT). The protocol scales due to a multi-signature scheme deployed and its hierarchical network structure; however, such a design requires coordination among authorities. CONIKS [51] is an attempt of providing key transparency to end users. The system relies on publicly-verifiable logs and provides interesting features like users privacy. PoliCert [74] is a log-based system that aims to better support domain expressiveness. Domains in PoliCert can use public logs to publish fine-grained policies describing their security preferences which then are enforced by clients. All systems in that class share the limitations of CT. They require either trusted validators or a gossip protocol run by clients (this aspect is usually unspecified) and assume highly available logs. Moreover, some of them increase the latency of TLS handshakes and violate privacy by enforcing clients to contact logs, require new infrastructures, or need significant changes to the TLS protocol and its PKI. Unlike these systems, SmartCert achieves the transparency, non-equivocation, availability, and censorship-resistance basing on the blockchain platform; thus, without introducing a new infrastructure. Moreover, in contrast to related work where CAs are monitored by some other (new) trusted entities, CAs actions in SmartCert are monitored and validated by smart contracts themselves.

Up to our best knowledge, there is no work proposing a similar to SmartCert concept, the blockchain technology has been investigated in the context of PKI recently. Namecoin [47] proposes a distributed namespace associated with public keys, what is improved by Certcoin [30] which adds new functionalities (i.e., key revocation and recovery). Blockstack [6] builds upon Namecoin, combining a distributed namespace and a storage system. Blockstack allows anyone to bind a name with a controlled public key and it leverages blockchain properties to make such bindings transparent, available, and equivocation resilient. The platform is fully implemented and deployed. Wang et al. [79] propose to implement CT over blockchain adding a revocation functionality. Their work requires an application-specific blockchain, what may limit applicability and deployment of the system. It also abstracts from the current TLS PKI and and the complexity of real-world deployment. SCPKI [4] proposes a blockchain-based identity system employing the web-of-trust model [2]. Interestingly, SCPKI targeting end-user identities uses an external storage for storing attribute data. Patsonakis et al. [57] propose a blockchain-based PKI, whose main novelty is a constant size cryptographic accumulator within a smart contract storing and managing certificates. The work provides a formal analysis but misses an implementation and evaluation. BlockPKI [24] provides an automated blockchain-based framework where multiple CA, synchronized via smart contracts, efficiently issue certificates. The system does not support any domain policies and relies on short-lived (irrevocable) certificates. Blockchain platforms are also employed to facilitate detection of misbehaving trusted parties. EthIKS [15] is a proposal for monitoring CONIKS logs using Ethereum, where a special smart monitors the consistency of a log, replacing a required gossip protocol. Another system is IKP [50], where dedicated smart contracts incentivize blockchain users for detecting fraudulent certificates.

In Tab. IV we compare the most related work with SmartCert. For every scheme we list its goal, trust assumptions, and important features like key authentication, validation logics, policies, revocation, key continuity, non-equivocation protection, and availability.

9 Conclusions

This paper proposes SmartCert, a novel digital certificates framework. By leveraging the blockchain and smart contract technology, SmartCert introduces “dynamic” certificates whose states can change but only according to the encoded validation logic and security policies specified individually by domains. Thanks to this design, SmartCert provides properties and features that the previous systems could not provide. Certificates in SmartCert self-enforce flexible security policies, carry historical statistics of the conducted public-key validations, the trust placed in CAs is minimized as their actions are transparent and monitored by the code, and the system provides high availability, robustness, and censorship resistance. SmartCert does not require major changes to the TLS PKI and is combined with the TLS protocol. The system is practical, does not introduce significant overheads, and can be deployed incrementally, co-existing with X.509v3 certificates.

We presented SmartCert in the context of public-key validation; however, in the future, we will investigate other validation policies. For instance, the SmartCert framework could be extended to support more sophisticated security policies allowing domains to instruct the client about other attributes of conducted connections (e.g., a domain’s desired cipher suites).


  • [1] “DigiNotar removal follow up,”, 2011, mozilla Security Blog.
  • [2] A. Abdul-Rahman, “The pgp trust model,” in EDI-Forum: the Journal of Electronic Commerce, 1997.
  • [3] M. Aertsen, M. Korczyński, G. Moura, S. Tajalizadehkhoob, and J. van den Berg, “No domain left behind: is let’s encrypt democratizing encryption?” in ACM ANRW, 2017.
  • [4] M. Al-Bassam, “Scpki: A smart contract-based pki and identity system,” in ACM BCC, 2017.
  • [5] E. Alashwali and K. Rasmussen, “What’s in a downgrade? a taxonomy of downgrade attacks in the tls protocol and application protocols using tls,” in ATCS, 2018.
  • [6] M. Ali, J. C. Nelson, R. Shea, and M. J. Freedman, “Blockstack: A global naming and storage system secured by blockchains.” in USENIX ATC, 2016.
  • [7] Z. Amsden et al., “The libra blockchain,” 2019.
  • [8] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich et al., “Hyperledger fabric: a distributed operating system for permissioned blockchains,” in ACM EuroSys, 2018.
  • [9] R. Barnes, J. Hoffman-Andrews, and J. Kasten, “Automatic certificate management environment (acme),” IETF Draft, 2017.
  • [10] D. Basin, C. Cremers, T. H.-J. Kim, A. Perrig, R. Sasse, and P. Szalachowski, “ARPKI: Attack Resilient Public-Key Infrastructure,” in ACM CCS, 2014.
  • [11] A. Bates, J. Pletcher, T. Nichols, B. Hollembaek, and K. R. Butler, “Forced perspectives: Evaluating an ssl trust enhancement at scale,” in ACM ICM, 2014.
  • [12] K. Bhargavan, A. Delignat-Lavaud, and N. Kobeissi, “Formal modeling and verification for domain validation and acme,” in Financial Crypto, 2017.
  • [13] H. Birge-Lee, Y. Sun, A. Edmundson, J. Rexford, and P. Mittal, “Bamboozling certificate authorities with bgp,” in USENIX Security, 2018.
  • [14] S. Blake-Wilson and A. Menezes, “Authenticated diffie-hellman key agreement protocols,” in Selected Areas in Cryptography, vol. 1556, 1998.
  • [15] J. Bonneau, “Ethiks: Using ethereum to audit a coniks key transparency log,” in Financial Crypto, 2016.
  • [16] M. Brandt, T. Dai, A. Klein, H. Shulman, and M. Waidner, “Domain validation++ for mitm-resilient pki,” in ACM CCS, 2018.
  • [17] V. Buterin, “Ethereum white paper,” 2013.
  • [18] CABForum, “Ballot 153 – short-lived certificates,” 2015.
  • [19] A. Caudill, “Looking for value in ev certificates,” 2017.
  • [20] Certificate Authority and Browser (CA/B) Forum, “Baseline requirements for the issuance and management of publicly-trusted certificates,” 2018.
  • [21] L. Chuat, P. Szalachowski, A. Perrig, B. Laurie, and E. Messeri, “Efficient gossip protocols for verifying the consistency of certificate logs,” in IEEE CNS, 2015.
  • [22] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, 2008. [Online]. Available:
  • [23] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, IETF, 2008. [Online]. Available:
  • [24] L. Dykcik, L. Chuat, P. Szalachowski, and A. Perrig, “Blockpki: An automated, resilient, and transparent public-key infrastructure,” in BlockSEA, 2018.
  • [25] P. Eckersley, “Sovereign key cryptography for internet domains,” 2012.
  • [26] Ethereum, “Light client protocol,” ””, 2018.
  • [27] ——, “Patricia tree,” ””, 2018.
  • [28] C. Evans, C. Palmer, and R. Sleevi, “Public Key Pinning Extension for HTTP,” RFC 7469, IETF, 2015. [Online]. Available:
  • [29] C. Forum, “Guidelines for the issuance and management of extended validation certificates,” 2017.
  • [30] C. Fromknecht, D. Velicanu, and S. Yakoubov, “Certcoin: A namecoin based decentralized authentication system,” Tech Report, vol. 6, 2014.
  • [31] A. Gavrichenkov, “Breaking https with bgp hijacking,” Black Hat. Briefings, 2015.
  • [32] S. D. Gribble and E. A. Brewer, “System design issues for internet middleware services: Deductions from a large client trace.” in USENIX USITS, 1997.
  • [33] P. Gutmann, “Key Management through Key Continuity (KCM),” IETF Draft, 2008.
  • [34] P. Hallam-Baker and R. Stradling, “DNS Certification Authority Authorization (CAA) Resource Record,” RFC 6844, IETF, 2013.
  • [35] J. Hodges, C. Jackson, and A. Barth, “HTTP Strict Transport Security (HSTS),” RFC 6797, IETF, 2012.
  • [36] P. Hoffman and J. Schlyter, “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA,” RFC 6698, IETF, 2012.
  • [37] L.-S. Huang, S. Adhikarla, D. Boneh, and C. Jackson, “An experimental study of tls forward secrecy deployments,” IEEE Internet Computing, 2014.
  • [38] C. Jackson and A. Barth, “Beware of finer-grained origins,” in W2SP, 2008.
  • [39] J. Jonsson and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” RFC 3447, IETF, 2003.
  • [40] K. Joyce, “ below 99% uptime,” ””, 2017.
  • [41] ——, “ below 99% uptime,” ””, 2017.
  • [42] T. H.-J. Kim, L.-S. Huang, A. Perrig, C. Jackson, and V. Gligor, “Accountable Key Infrastructure (AKI): A Proposal for a Public-key Validation Infrastructure,” in ACM WWW, 2013.
  • [43] M. Kucherawy and E. Zwicky, “Domain-based Message Authentication, Reporting, and Conformance (DMARC),” RFC 7489, IETF, 2015.
  • [44] A. Langley, “Revocation Checking and Chrome’s CRL,” ””, 2015.
  • [45] B. Laurie, A. Langley, and E. Kasper, “Certificate Transparency,” RFC 6962, IETF, 2013.
  • [46] Y. Liu, W. Tome, L. Zhang, D. Choffnes, D. Levin, B. Maggs, A. Mislove, A. Schulman, and C. Wilson, “An End-to-End Measurement of Certificate Revocation in the Web’s PKI,” in ACM IMC, 2015.
  • [47] A. Loibl, “Namecoin,”, 2014.
  • [48] M. Marlinspike, “Convergence,” 2011,
  • [49] N. Mathewson, “Let’s remove gmt_unix_time from TLS,” ””, 2013.
  • [50] S. Matsumoto and R. M. Reischuk, “Ikp: Turning a pki around with decentralized automated incentives,” IEEE S&P, 2017.
  • [51] M. S. Melara, A. Blankstein, J. Bonneau, E. W. Felten, and M. J. Freedman, “Coniks: Bringing key transparency to end users.” in Usenix Security, 2015.
  • [52]

    G. Merzdovnik, K. Falb, M. Schmiedecker, A. G. Voyiatzis, and E. Weippl, “Whom you gonna trust? a longitudinal study on tls notary services,” in

    IFIP DBsec, 2016.
  • [53] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
  • [54] D. Naylor, A. Finamore, I. Leontiadis, Y. Grunenberger, M. Mellia, M. Munafò, K. Papagiannaki, and P. Steenkiste, “The cost of the s in https,” in ACM CoNEXT, 2014.
  • [55] L. Nordberg, D. Gillmor, and T. Ritter, “Gossiping in CT,” Internet-Draft draft-linus-trans-gossip-ct-04, 2017.
  • [56] G. Ouvrier, M. Laterman, M. Arlitt, and N. Carlsson, “Characterizing the https trust landscape: a passive view from the edge,” IEEE Communications Magazine, 2017.
  • [57] C. Patsonakis, K. Samari, M. Roussopoulos, and A. Kiayias, “Towards a smart contract-based, decentralized, public-key infrastructure,” 2017.
  • [58] H. Perl, S. Fahl, and M. Smith, “You won’t be needing these any more: On removing unused certificates from trust stores,” in Financial Crypto, 2014.
  • [59] Y. Pettersen, “The Transport Layer Security (TLS) Multiple Certificate Status Request Extension,” RFC 6961, 2013.
  • [60] E. Rescorla, “The transport layer security (tls) protocol version 1.3,” 2017.
  • [61] H. Ritzdorf, K. Wüst, A. Gervais, G. Felley et al., “Tls-n: Non-repudiation over tls enabling ubiquitous content signing,” in NDSS, 2018.
  • [62] R. L. Rivest, “Can we eliminate certificate revocation lists?” in Financial Crypto, 1998.
  • [63] P. Roberts, “Phony SSL certificates issued for Google, Yahoo, Skype, others,”, 2011.
  • [64] M. D. Ryan, “Enhanced Certificate Transparency and End-to-End Encrypted Mail,” in NDSS, 2014.
  • [65] Ryan Sleevi et al., “On the value of ev,” 2017.
  • [66] R. Salz, “I can Haz TLS 1.3 ?” ””, 2017.
  • [67] S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP,” RFC 6960, 2013.
  • [68] Q. Scheitle, T. Chung, J. Hiller, O. Gasser, J. Naab, R. van Rijswijk-Deij, O. Hohlfeld, R. Holz, D. Choffnes, A. Mislove et al., “A first look at certification authority authorization (caa),” ACM SIGCOMM CCR, 2018.
  • [69] SSLLabs, “SSL Pulse,” 2018.
  • [70] N. Sullivan, “Why TLS 1.3 isn’t in browsers yet,” ””, 2017.
  • [71] E. Syta, I. Tamas, D. Visher, D. I. Wolinsky, P. Jovanovic, L. Gasser, N. Gailly, I. Khoffi, and B. Ford, “Keeping authorities “honest or bust” with decentralized witness cosigning,” in IEEE S&P, 2016.
  • [72] P. Szalachowski, “Padva: A blockchain-based tls notary service,” in IEEE ICPADS, 2019.
  • [73] P. Szalachowski, L. Chuat, and A. Perrig, “PKI safety net (PKISN): Addressing the too-big-to-be-revoked problem of the TLS ecosystem,” in IEEE EuroS&P, 2016.
  • [74] P. Szalachowski, S. Matsumoto, and A. Perrig, “PoliCert: Secure and Flexible TLS Certificate Management,” in ACM CCS, 2014.
  • [75] P. Szalachowski and A. Perrig, “Short paper: On deployment of dns-based security enhancements,” in Financial Crypto, 2017.
  • [76] B. VanderSloot, J. Amann, M. Bernhard, Z. Durumeric, M. Bailey, and J. A. Halderman, “Towards a complete view of the certificate ecosystem,” in ACM ICM, 2016.
  • [77] G. Varshney and P. Szalachowski, “A metapolicy framework for enhancing domain expressiveness on the internet,” in SecureComm, 2018.
  • [78] W3Techs, “Usage of SSL certificate authorities for websites,” ””, 2018.
  • [79] Z. Wang, J. Lin, Q. Cai, Q. Wang, J. Jing, and D. Zha, “Blockchain-based certificate transparency and revocation transparency,” 2018.
  • [80] I. Weber, V. Gramoli, A. Ponomarev, M. Staples, R. Holz, A. B. Tran, and P. Rimba, “On availability for blockchain-based systems,” in IEEE SRDS, 2017.
  • [81] D. Wendlandt, D. G. Andersen, and A. Perrig, “Perspectives: Improving ssh-style host authentication with multi-path probing.” in USENIX ATC, 2008.
  • [82] M. Wong and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” RFC 4408, IETF, 2006.
  • [83] J. Yu, V. Cheval, and M. Ryan, “Dtki: A new formalized pki with verifiable trusted parties,” The Computer Journal, 2016.