Blockchain-Based Certificate Transparency and Revocation Transparency

Abstract

Traditional X.509 public key infrastructures (PKIs) depend on certification authorities (CAs) to sign certificates, used in SSL/TLS to authenticate web servers and establish secure channels. However, recent security incidents indicate that CAs may (be compromised to) sign fraudulent certificates. In this paper, we propose blockchain-based certificate transparency and revocation transparency. Our scheme is compatible with X.509 PKIs but significantly reinforces the security guarantees of a certificate. The CA-signed certificates and their revocation status information of an SSL/TLS web server are published by the subject (i.e., the web server) as a transaction, and miners of the community append it to the global certificate blockchain after verifying the transaction and mining a block. The certificate blockchain acts as append-only public logs to monitor CAs’ certificate signing and revocation operations, and an SSL/TLS web server is granted with the cooperative control on its certificates to balance the absolute authority of CAs in traditional PKIs. We implement the prototype system with Firefox and Nginx, and the experimental results show that it introduces reasonable overheads.

This work was partially supported by National Basic Research 973 Program of China (Award No. 2014CB340603), National Natural Science Foundation of China (Award No. 61772518), and Cyber Security Program (Award No. 2017YFB0802100) of National Key RD Plan of China.

A Parameters Selection

The time interval between two adjacent blocks (denoted as $T_B$) determines how soon a certificate will be accepted by browsers after it has been included in the blockchain. It is reasonable for a web server to require its published certificates to be accepted within 24 h, i.e., $N \times T_B < 1,440$ min. On the other hand, a smaller $T_{B}$ enforces the web server to watch for fraudulent certificates in the blockchain more frequently, and take countermeasures more quickly. Accordingly, we set $T_B = 120$ min as a typical value and let $N=6$ (the same as the requirement in Bitcoin). In order to keep the block mining stable, the community adjusts the PoW target of the blockchain periodically.

The validity period of Type-I transactions (denote as $T_{I}$) is chosen to provide moderate revocation transparency. First, only when a transaction has been included in a fully-confirmed block (not in the latest N ones of the blockchain), the contained certificates are considered as valid by browsers. So, $T_{I} \gg (N+1) \times T_B$; otherwise, it is never accepted by browsers before it expires. Meanwhile, $T_I$ shall be not significantly greater than the general revocation status update period, to enforce the web servers to update their transactions in a timely manner. So we require that $T_{I} \le 10 \times T_{Revoke}$, where $T_{Revoke}$ is the revocation status update period. For more than 95% of CRL files, $T_{Revoke}$ is not larger than 1 day. OCSP provides timely revocation status services, but the validity period of OCSP responses is typically 4 or 7 days.¹ Thus, we set $T_I = 14,400$ min (or 10 days) in the prototype.

$T_{II}$ determines the frequency of shadow Type-II transactions. We set $T_{II} = 10\times T_{I}$ (i.e., 100 days).