Attack-Resilient TLS Certificate Transparency

The security of Public-Key Infrastructure (PKI) for Internet-based communications has lately attracted researchers’ attention because of Certification Authorities (CAs) crashes and consequent attacks. Google Certificate Transparency and subsequent log-based PKI proposals (e.g., AKI and ARPKI) have succeeded in making certificate-management processes more transparent, accountable, and verifiable. However, those proposals failed to solve the root CA generous delegation of trust to intermediate CAs, non-conformant certificate-issuance by them, and lack of rigorous authentication of domain ownership during certificate-issuance problems. This study presents Attack-Resilient TLS Certificate Transparency (ARCT) based on log servers to address these problems. ARCT enables root CA to enforce intermediate CAs to follow community standards through leveraging a log server at each root level. It also introduces a collaborative domain ownership verification method that deters false certificate-issuance and ensures that a set of CAs validates every certificate before any client will accept it. A certificate collectively approved by a set of CAs assures users that the certificate has been seen, and not instantly detected malicious, by a group of CAs. Finally, formal security and performance evaluations prove the reliability and effectiveness of ARCT.


I. INTRODUCTION
Transport Layer Security (TLS) is the backbone and tremendous success in securing Internet-based communications. Virtually all online purchase transactions are secured and protected by TLS. Although TLS was primarily designed to secure web traffic, today, most financial and non-financial communications depend on TLS for their security. TLS is highly reliant on the PKI for the secure connection establishment, in which CA-signed certificates are employed for authentication. CAs play the most critical role in the PKI, and PKI's security and defense depend solely on the trustworthiness, honesty, and security of CAs. Stealing secret-keys of CAs are enough to impersonate domain servers; this makes CAs' secret-keys the prime targets for hackers.
The associate editor coordinating the review of this manuscript and approving it for publication was Muhammad Khalil Afzal .
Unfortunately, we have observed notable crashes and exploits in the CA regime. Although the CA regime purports to shield and guard clients against Man-in-the-Middle (MitM) attacks, the current CA trust model is worryingly brittle. Recent CAs collapses have revealed its vulnerability in practice [1], [2]. The web browsers/operating systems blind trust in a substantial number of CAs' certificates is a big problem of the current TLS ecosystem. In the current CA model, CAs can issue TLS certificates for domains outside their scope, representing the idea of weakest-link security [3].
In response, several solutions [3]- [6] have been proposed. Certificate Transparency (CT) [4], [5] is a scheme proposed by Google to make the problem of false TLS certificates detection easier by registering all TLS certificates on a public log maintained in the form of a Merkle Hash Tree (MHT). However, it cannot guard clients against attacks when a corrupted CA issues false TLS certificates. References [3] and [6] are another line of proposals that attempts to sign the TLS certificates from multiple CAs and frame certificate-management transparent by maintaining public Log Servers (LSes) of all TLS certificates. They also acquaint checks-and-balances to reduce the need to trust any single party and prevent MitM attacks.
However, the generous-delegation-of-trust by the root CA still lacks attention from the research community. Root CA generously delegates their signing authority to intermediate CAs, 1 and these unknown entities are blind as trusted as the root trust servers. This trust delegation results in a mass blind chain of trust. Further, intermediate CAs have abused the delegated power for false certificate-issuance [7]. Both before and after DigiNotar and Comodo incidents, a series of lucrative attacks on intermediate CAs came to light [7]. Most small intermediate CAs failed to follow root CAs and community standards and miss-issued certificates [8]. For example, in 2011, a Malaysian sub-CA was reported to have issued domain certificates with a key size smaller than required by the parent CA, and a Swiss intermediate CA shorter key was used to sign malware [7]. Most sub-CAs' miss-issuances have gone unmentioned in public forums like the Mozilla Developer Security Policy (MDSP), but deserve special attention [8].
Apart from trust delegation, CAs do not conduct strict validation of the domain identity before certificateissuance [9], [10]. For example, in 2018, Birge-Lee et al. [9] and Brandt et al. [10] showed real-world attacks against top CAs such as Let's Encrypt, Comodo, GoDaddy, Symantec, InstantSSL, CertCom, NetworkSolutions, SSL.com, Net-Lock, and GlobalSign. They unveiled that the certificateissuance process 2 is itself defenseless to MitM attacks. Again, Let's Encrypt was taken down by Borgolte et al. [11], and as a result, fake certificates were issued. Fake and maliciously acquired TLS certificates have been used to conduct cyber-attacks against users of various famous websites such as Google, Yahoo, and Facebook [12], [13]. A survey showed that 0.2% of all Facebook users' connections were attempted to tamper with malicious TLS certificates [14], and 3 million forged TLS certificates were identified for the top 10k Alexa sites [15].
To address these problems, we propose a new log-based PKI for managing domain certificates, called Attack-Resilient TLS Certificate Transparency. This new PKI scheme has verifiable distributed parties and makes four primary contributions.
• Root CA's generous-delegation-of-trust is an important problem for certificate-issuance in the current CA model, and this area has yet not received research attention. ARCT is the first architecture to resolve the problem by giving root CA active control over their delegated power and enabling root CA to restrict intermediate CAs from abusing and misusing the delegated authority.
• We explore attacks on CAs and certificate transparency. ARCT mitigates the attacks by introducing a collaborative certificate-issuance mechanism that enforces the rigorous identity verification of the domain to counter malicious certificate-issuance (see V). It introduces an improved revocation mechanism that keeps a record of all revoked certificates as well as efficient in terms of communication cost (see VII).
• A thorough security analysis of ARCT is conducted, which shows that ARCT can prevent impersonation attacks, even in the face of a strong adversary who is capable of compromising CA and LS simultaneously (see VI).
• A prototype of ARCT is built to evaluate the feasibility of the collaborative identity verification process. Lastly, ARCT is compared with some leading log-based PKI schemes using various performance metrics (see VII).

II. RELATED WORK
Prior works can be broadly classified into traditional PKI schemes, blockchain-based PKI schemes, and log-based PKI schemes. Traditional PKI Schemes: The X.509 standard PKI deployment includes CRL [16] that is periodically disseminated by CAs to prevent revoked certificates being used in TLS connections. This approach can only mitigate attacks if clients possess an updated CLR copy. Otherwise, attackers have an opportunity to launch cyber-attacks against clients using already revoked certificates [6]. On the other side, CLR is quite expensive in terms of communication costs. OCSP [17] servers are deployed to reduce CRL costs and enable real-time certificate revocation status. Short-lived Certificates [18] eliminates the need for checking the revocation of a certificate. However, the main issue of CRL, OCSP, and SLC is their heavy dependency on web browsers to identify and blacklist spurious certificates endorsed by dishonest CAs [3].
To empower clients, some proposals delegate the power of accepting or rejecting certificates to clients based on either their defined local policies [19] or comparison with the information stored in the repository [20]- [22]. Likewise, other proposals [23]- [25] empower domains to shield their keys despite CAs crashes by allowing them to announce their public-keys such that users can pin their keys. However, these approaches are vulnerable to MitM attacks on ''first connection to a domain.'' DNS-based Authentication of Named Entities (DANE) [26] sanctions domains to assert their key-related information in their DNS security extension (DNSSEC). CA Authentication (CAA) [27] lets domains to explicitly define a list of qualified CAs that can endorse certificates for them. Reference [28] analyzed that a small set of CAs issue certificates of top-level domains (TLDs). Using the TLDs analysis of [28], CAge [29] restricts the set of TLDs, for which a specific CA is trusted to issue TLS certificates. While CA-TMS [30] and [31] collects information about CAs reputation from users, and they restrict CAs' scope using the reputation data gathered from their clients. References [9], [10] successfully attacked several eminent domain validation-based commercially used CAs and showed that their certificate-issuance process itself is exposed to MitM attacks. References [9], [10] suggested several recommendations to mitigate attacks against the domain validation-based certificate-issuance process. The proposals are defenseless against attackers capable of compromising CAs' private-key.
Blockchain-based PKI Schemes: This class of schemes [32]- [36] tried to propose decentralized solutions based on blockchain for public-key management. SCPKI [33] integrated the web of trust with smart contracts to identify false certificates in the communication. Reference [34] managed .bit addresses (DNS) on a public ledger, which is forked of Bitcoin. In [34], self-signed certificates are inserted into DNS addresses as auxiliary data. Certcoin [37] extended [34] and further eliminated the need for using third-parties (CAs). Certcoin includes identity registration, verification, search, and revocation phases. PB-PKI [38] resolved the identity linking and privacy concerns of Certcoin [37]. However, the authors in Blockstack [39] identified that a single miner in [34] holds over 51% of computation power and clients are exposed to 51% attacks. Wang et al. [40] presented a PKI framework to manage TLS certificates and their revocation on a blockchain medium. In this blockchain-based PKI, each domain server has two key-pairs, namely, publishing key-pair and TLS key-pair. The publishing is endorsed by a group of web servers, which is used to publish transactions to the blockchain. While the TLS key-pair, which is approved by a CA and published on blockchain medium, is used in TLS communications. It is vulnerable to cyber-attacks where an attacker can communicate with a client through a revoked certificate whose transaction is still valid [41].
Yakubov et al. [42] proposed a decentralized PKI scheme to handle TLS certificates on a blockchain platform. In this scheme, a smart contract is created for each CA, which comprises the CA certificate, hash values of the CA-signed end-entities certificates, and certificate revocation information. Blockchain-related metadata are inserted into X.509 extension fields of each TLS certificate. In this framework, the hash values of domains' certificates are only stored, which makes it impracticable for domain owners to watch their certificates [41]. CertChain [43] proposed a novel data structure called CertOper for TLS certificates auditing. The proposed data structure comprises certificate-related data and related procedures such as registration, renewal, and revocation. CertChain adopted the Ouroboros [44] as a consensus algorithm, which relies on CA and bookkeeper's reputation for a leader selection. PBCert [45] identified shortcomings in CertChain and proposed enhancement to mitigate the issues. CertLegder [41] presented a PKI framework where all certificate-related operations and data are handled on a blockchain medium. It eliminates the key store maintained by clients and makes key revocation transparent. The major problem with blockchain-based PKI frameworks is scalability issues, and they substantially alter the underlying infrastructure of TLS PKI [46]. Second, synchronizing full-node takes considerable time (e.g., synchronizing full-node of Bitcoin with 145 GB ledger size takes three days [47]).
Log-based PKI Schemes: Unlike blockchain-based PKI approaches, log-based PKI proposals do not substantially alter the underlying architecture of certificate management. They enable anyone to monitor and audit CAs operations and detect their misconduct. Google Certificate Transparency (CT) gained widespread adoption, which will be reviewed in the next section. Peter Eckersley presented a new public-key framework called Sovereign Key (SK) [48] that is designed to securely verify the domains TLS certificates more robustly than the existing CAs model. In SK, a domain generates a sovereign key-pair to endorse a TLS certificate and register the public part of the key-pair on an append-only log called timeline servers. SK can guard against an impersonation attack even when CA gets compromised. However, in SK, domains and clients have to blindly trust mirrors of timeline servers, as mirrors are unable to generate a verifiable proof for the certificate included in the append-only log. Unfortunately, in SK, a client also requires querying to a timeline server, increasing latency, and sacrificing client privacy.
AKI [3] is a log-based proposal for transparent certificate management that distributes trust over multiple anchors. AKI has built-in support for revocation and enables domain owners to specify a list of trusted CAs and LSes. It uses the checks-and-balances mechanism to reduce trust in any party, resulting in the mitigation of MitM. ARPKI [6] is a refinement of AKI. In ARPKI, certificate registration requires a domain owner to designate a certain number of service providers (n) and contact one of them to monitor multi-signature certificate (ARCert) registration in LSes. It offers robust security against powerful adversaries and can protect clients from attacks, even when an adversary subverts n-1 service providers. However, ARPKI has no support for multi-domain certificates, and it has an extra delay because of the involvement of all designated parties in all processes [49]. TriPKI [50] utilized a threshold-signature scheme among a list of trusted CAs, trusted DNSes, and trusted LSes to distribute trust and assure secure communication. Reference [50] substitutes third-party validators with DNSes and adopts checks-and-balances among the trusted set of CAs, DNSes, and LSes to watch each other behavior.
DTKI [49] is another PKI framework that combines CT, AKI, and SK, where the sovereign key-pair (renamed as a master-key in DTKI) is used to restrict the CA's role while LS is maintained using a pair of chronological and lexical MHTs to have benefits of CT with revocation support. Unfortunately, in DTKI, everyone must trust a single log maintainer called Mapping Log Maintainer (MLM). DTKI has extra latency as clients must visit MLM before every connection, putting their privacy in danger. Policert [13] tries to give more control to domain owners over their TLS certificate and TLS connection by specifying detailed policy.
In Policert, a domain needs to register the Subject Certificate Policy (SCP) and multi-signature certificate (MSC) on LS. The domains present SCP, MSC, and their presence proof in LS to clients during the TLS connection. This scheme also supports TLS certificate revocation. However, in this proposal, the mechanism for disseminating and detecting LS misconduct is not specified [6]. ATCM [12] explores MitM attacks on Policert and mitigates the attacks by leveraging checks-and-balances and making the life cycle of TLS certificate transparent. ATCM provides stout security and can defend clients against an active adversary compromising most of the trusted servers. They also validated the security features that their scheme supports using the automated verification tool Tamarin prover [51].

A. CERTIFICATE TRANSPARENCY OVERVIEW
We review CT [4], [5] in detail for two main reasons: (1) ARCT is motivated by CT's architecture and utilizes some of its concepts; (2) ARCT resolves several problems that remain despite the CT model deployment. The main aim of CT is to mitigate the problem of fake and fraudulent TLS certificates by introducing an auditable public log of all issued certificates. Eventually, browsers would accept a certificate only if it had an inclusion proof in a public log. In CT, when a CA wants to issue a TLS certificate for a domain, it selects an LS and delivers the TLS certificate data to the LS. The LS generates signed-certificate-timestamp (SCT) for the certificate, which guarantees that the LS will insert the TLS certificate to its database within the maximum merge delay (MMD). The CA embeds the SCT as an X.509 extension in the signed TLS certificate or sends it with the certificate in OCSP extension after receiving SCT from the LS. The CT operates with the following main entities.
• Log Server (LS). Log servers are maintained using MHT in chronological form. All issued TLS certificates are stored in one of many LSes.
• Monitor. Monitors check the LSes for suspicious TLS certificates by examining all log entries.
• Auditor. Auditors verify that the LSes are behaving correctly, detect miss-issued TLS certificates based on partial information from the LSes, and check that SCTs they encounter are in the logs.
LSes are maintained in the form of MHT, where each leaf node of MHT is a hash of the TLS certificate, and internal nodes of MHT are a hash of two child nodes, enabling the LS to generate inclusion and extension proofs efficiently. The root of the MHT, which is signed and broadcasted by LS, is called a signed-tree-head (STH).

B. REMAINING CHALLENGES
We briefly highlight several issues that motivated this work and remained despite the prior works. Root CA's generous-delegation-of-trust is a significant problem of the current CA model, where the parent CA delegates certificate-issuance authority to several sub-CAs that can issue TLS certificates to any domain without any restriction. After delegation, the root CA loses control over the delegated authority and cannot prevent sub-CAs from abusing and misusing the delegated power. Further, the root CA fails to enforce sub-CAs to comply with the community standards, whereas most erroneous certificates are issued by the intermediate CAs [8]. For example, Comodo CA has 29 sub-CAs, and most unsound and non-conformant certificates are signed by just one sub-CA (COMODO RSA DV Secure Server), which totals for 85% of the erroneous certificates [8].
CT and previous solutions (e.g., AKI, DTKI, and ARPKI) assume that CAs' certificate-issuance process is secure, and they perform rigorous verification of domain ownership. However, CAs use a vulnerable certificate-issuance process, and the process itself is exposed to MitM attacks [9].
Besides these issues, CT left revocation as an open problem and still relies on existing methods for revocation. Proposals like revocation transparency [52], CIRT [53], CT with Enhancements and Short Proofs [54], and PKI safety net (PKISN) [55] have been suggested to solve CT's revocation problem, but none has been incorporated in CT yet. While existing certificate revocation schemes CRL [16] and OCSP [17] are still unsatisfactory. Table 1 shows the important symbols and notations used in ARCT.

III. PRELIMINARIES A. MERKLE HASH TREE
We formally define MHT. L and yields a tree head (root hash) TH that is a commitment to the list.
• AuthenPath(elmnt, L) → AP: A deterministic algorithm that takes a list L and an element elmnt as inputs and outputs an authentication path AP representing the membership.
• ExtenProof (m, n, L) → EP: It takes as inputs an L, and two indices 0 ≤ m ≤ n ≤ |L|, and generates an extension proof consisting of a sequence of hashes. The proof provides evidence that the current tree consisting of entries (0 : n) is extending the previous one, consisting of entries (0 : m).
• VerifyExtenProof (TH i , TH j , EP) → 0/1: It takes as inputs proof of extension EP, two root hashes TH i , and TH j and verifies that the tree corresponding to TH j is an extension of the MHT corresponding to TH i . VerifyEx-tenProof(.) either returns true or false. Proof: This follows from the work by [56], [57]. Lemma 2: (Collision-resistance of Authentication path of MHT). If H is a collision-resistant, then an authentication path in MHT is collision-resistant.
B. AUTOMATIC CERTIFICATE MANAGEMENT ENVIRONMENT (ACME) ACME [59] protocol is proposed by the Internet Security Research Group (ISRG) to automate interactions between CAs and domain servers, allowing automated certificate-issuance and deployment at a low cost. The ACME protocol supports domain validated (DV) certificateissuance, where the ownership of a domain is validated through a challenge/response process. The ACME protocol supports a DNS-and HTTPS-based challenge/response process to verify control over a domain. The validation mechanism of the ACME protocol comprises three main steps: (1) When a CA receives a certificate signing request from a domain owner, the CA sends a set of challenges to the domain owner.
(2) The domain owner replies with a set of responses to complete the set of challenges. (3) The CA validates the set of responses, and once the challenges are correctly completed, the CA issues a DV TLS certificate for the domain.

IV. SYSTEM AND THREAD MODEL
To build a PKI that is immune to the compromise of several parties and can recover from catastrophic casualties, we base ARCT on verifiable LSes. In the proposed PKI, we achieve strong security by introducing one more layer of transparency  [53]. To address the revocation problem, we additionally manage the revocation information as another MHT, maintained as in [60], which we call a revocation tree. The revocation tree is a hash tree with leaf nodes corresponding to a set of statements about the certificate's serial numbers. The set of statements is generated from revoked certificates and provides information about the certificate revocation status. The root of the revocation tree is inserted as the last node in the ELS ChronTree.
• Shared Log Server (SLS): This LS is a public log of all issued TLS certificates, as in CT. However, the database of SLS is extended and is maintained as a pair of MHTs. Both MHTs are kept in chronological form. The first tree maintains a database of certificates that we call certificate tree (CertTree), while the other tree maintains a database of ELSes' STHs, which is referred to as a witness tree (WitTree). Here the SLS acts as a witness for ELS and prevents ELS from split-world attacks.
• Monitor: Monitors regularly watch and scan the LSes (ELS and SLS) for malicious certificates by examining all their records as in CT.
• Auditor: Auditors verify that LSes (ELS and SLS) are behaving correctly as in CT, detect malicious certificates based on partial information from the LS, and check that the SCTs they encounter are in the logs. They are lightweight software and an integral part of client software.
• Domain: Each domain 3 has an ICA-signed certificate that is presented to its client during connection establishment. • Client: A user agent (e.g., a web browser) that uses services offered by domain servers securely.

A. ADVERSARY MODEL
We consider an adversary whose primary aim is to impersonate domain servers using HTTPS. To accomplish this aim, the adversary can steal CA (e.g., intermediate CA) private-key to acquire the malicious certificates and LS (e.g., ELS) private-key to log malicious certificates. We assume that the cryptographic building blocks that we use, such as the hash function and signature schemes, are secure. The hash function H is resistant to collision and pre-image attacks, and the signature scheme cannot be forged (EUF-CMA secure).

B. DESIRED PROPERTIES
• Complete audit: All entities taking part in certificateissuance should be liable. They (e.g., sub-CAs) should be audited and compliant with standards at the same level as a root CA, none of their violation should go unnoticed.
• Low cost: The scheme should not tectonically expand the TLS handshake message size and should have an insignificant effect on processing time. Moreover, no extra delay should be added to the TLS connection establishment in particular round-trip time to external servers.
• Resilience against attacks: Building a complete secure infrastructure that can eliminate attacks in catastrophic failure is impossible. However, the system must have a brief system attack window.
• Privacy: Public-key infrastructure (PKI) must not reveal the clients' connection information.
• Checks and Balances: Root CAs should limit blind trust in sub-CAs, and limited trust should be given to participating parties (e.g., LSes) to mitigate the weakest-link security. Furthermore, participating parties should be able watch each other to detect misconduct.

V. ATTACK-RESILIENT TLS CERTIFICATE TRANSPARENCY
First, we discuss in detail the algorithms executed by ELS, SLS, monitors, and auditors to generate and verify proofs.
The following are the main algorithms run by ELS and SLS. VOLUME 8, 2020 GenSCT (cert, t, sk ELS ) → SCT : It takes as inputs a certificate cert, current time t, and private-key to generate SCT. GenSTH (TH , t, sk) → STH : A randomized algorithm that takes TH , time t, its private-key sk as inputs and return sign-tree-head (STH CheckSCT (SCT , pk) → 0/1: It validates that the SCT is issued for the corresponding certificate and endorsed by a trusted LS. CheckSTH (STH , pk) → 0/1: It takes SHT and public-key pk of a concerned LS and returns either 1 or 0. CheckPoP(cert, STH , PoP, pk) → 0/1: A deterministic algorithm which executes CheckSTH (STH , pk) and VerifyAuthenPath(cert, TH , PoP)) to validate that the certificate cert is logged or not in the LS .  CheckPoN (cert, s(i, j), STH , PoN , pk) → 0/1: It first checks that cert serial number is greater than i but less than j. After verifying the serial, it then computes root hash from the authentication path.
If the computed hash is equal to the published root hash, then it is accepted, otherwise rejected. CheckPoE(STH i , STH j , PoE, pk) → 0/1: To validate that the current version is extended from the previous one, the verifier executes CheckPoE (STH i , STH j , PoE, pk) by giving two signed tree head, proof of extension, and public-key of the LS as input, then CheckPoE(.) returns either 1 or 0. In the rest of the section, we describe the proposed scheme in detail based on four main phases, namely certificate-issuance, certificate registration, certificate revocation, and connection establishment.

A. CERTIFICATE-ISSUANCE
To start using ARCT, a domain must possess a valid certificate. To acquire a certificate, the domain owner of a domain (e.g., D.com) generates a key-pair and forwards Certificate Signing Request (CSR) to intermediate CA. Upon receiving a CSR, the intermediate CA must validate that the submitter is the actual owner of the D.com. To enforce rigorous control verification, we introduce a new collaborative domain identity verification method that complements the traditional certificate-issuance process and ensures verification by multiple parties (CAs). As shown in Figure 2, the collaborative process works as follows. The ICA1 issues a challenge to the owner of the domain, through which ICA(1) requires to accomplish to verify ownership of the domain. 3 Once the domain owner receives the challenge, she hosts the challenge1 signed by its private-key at the URL, e.g., ''https://D.com'' to serve as the domain validation resource. 4 The ICA1 validates the domain by accessing the challenge1 placed at the URL as well as verify the signed challenge using the public-key of the domain. 5 After initial verification of a domain's identity, the ICA, e.g., ''ICA(1),'' forwards approval request to its parent CA. 6 The root CA selects m numbers of sub-CAs and multi-casts collaborative identity verification requests to them, where m is a system parameter set by the root CA. 7 Each m number of identity validation includes carrying out step 7 to step 9, which are the repetition of step 2 to step 4 but with different challenge types and from different vantage points. After collaborative verification, the root CA prepares a list of certificates that passed the scrutiny and sends the final approved list to the ELS. Note, each sub-CA can implement different challenge types (e.g., DNS challenge, see Sec. VII-C for different challenge types).

B. CERTIFICATE REGISTRATION
Before a certificate can be used in secure communications, it must be registered at the ELS and at least at one or more than one SLS(es). First, we discuss registration at ELS and then describe the logging process at SLS.

1) EXCLUSIVE LOG SERVER
After the domain identity validation, each intermediate CA sends the certificate(s) to the ELS for registration. The certificate(s) must be present in the final approved list, say L app sent by the root CA to the ELS. The ELS generates an SCT for each certificate after checking the soundness and correctness of each TLS certificate (see Algorithm 1), where the SCT acts as an insurance that the ELS will attach the TLS certificate to its database in the next update. All erroneous certificates are filtered out at this stage by the ELS.

2) SHARED LOG SERVER
After receiving an SCT from the ELS, the submitter (e.g., intermediate CA or domain owner) forwards the certificate to SLSes for logging the certificate in SLSes. Each SLS validates the SCT of the ELS, generates an SCT after performing the necessary checks as given in Algorithm 2, and sends the SCT back to the submitter.

C. CERTIFICATE REVOCATION
When a domain's private-key leaks, it generates a signed Certificate Revocation Request (SCR) and forwards the SCR to an ELS. The ELS verifies the SCR and checks whether the certificate is included in its database. If it exists in its database, then the ELS generates a signedrevocation-timestamp (SRT) given in Algorithm 3, which acts as a promise that the ELS will revoke the certificate in the next update. If   Every domain periodically fetches proof of non-revocation from the corresponding ELS after each update. The client opens an SSL/TLS connection with the D.com server using Algorithm 4, and the D.com server sends the certificate along with evidence during the TLS handshake. The certificate is authenticated using the pre-installed CA's certificate in browsers, and SCTs and proof are validated using LSes' public-keys that are delivered to the browser. The leaf node of revocation tree s(i,j) represents the range that brackets the certificate Cert ICA D serial number sn such that i < sn < j whereas pk RCA represents root CA's public-key.

E. CROSS LOGGING ELS SIGNED TREE HEAD (STH)
Periodically, at a well-known interval, each ELS updates its database by inserting all new certificates and publishes a fresh root for the current version of its database, which is signed by ELS as well as the root CA. The fresh STH is

Algorithm 4 TLS Secure Connection Establishment
forwarded to SLSes for witnessing, where each SLS generates signed receipt after performing necessary checks given in Algorithm 5, which is a cryptographic assurance of inserting to WitTree. This witnessing strengthens security against forking attack, in which ELS shows different signed versions of its log (one version for one set of users and another version another set of users). t now ), pk SLS ) add STH j to pending witness list L wit end else ''Invalid STH '' end

VI. SECURITY ANALYSIS
In this section, we conduct an informal and formal security analysis and verify the main security feature that ARCT guarantees. Further, the proposed scheme security relies on the two lemmas for security. First, Table 2 compares security of ARCT with the following six log-based proposals: SK [48], CT [4], [5], AKI [3], ARPKI [6], DTKI [49], and Policert [13]. Second, in Theorem 1, we prove that ARCT thwarts impersonation when at most, one party is honest.
For the ''MitM attack mitigation'' metric, CT cannot guard clients against impersonation when a subverted CA issues a bogus TLS certificate for a domain. In SK and DTKI, each TLS certificate is cross-signed with a key-pair owned by the domain, whereas, in AKI, ARPKI, and Policert, a subject needs to get certified from more than one CA. The proposed scheme can prevent such attacks as a set of CAs verifies each domain identity (see Sec. V-A). Root CAs do not endorse end-entity certificates directly but cryptographically transfer that power to intermediate CAs. The intermediate CA can issue certificates (maybe a fake certificate) even for domains that are outside its scope, and most successful attacks are also launched against sub-CAs [61]. Compared with the log-based PKI frameworks, ARCT counters such failures of intermediate CAs by giving root CA the ability to prevent the exploitation of signing authority by them.
Log-based PKI proposals are still in infancy, and they failed to address the problem of non-conformant certificateissuance by intermediate CAs. Reference [8] showed that the majority of small intermediate CAs have a high miss-issuance rate. However, the proposed scheme refrain intermediate CAs from issuing an erroneous certificate, since every certificate passes through a filtering process where ELS checks each certificate for soundness and correctness. (A) given in Figure 3, then ELS A() , which runs A, finds a collision in MHT.
We demonstrate that a successful adversary A outputs two lists under the same root of the MHT used in ELS in the proposed scheme, which, by lemma 1, results in a hash collision.   s(i,j), STH, PoN , pk ELS ) = 1, but s(i, j) / ∈ L. As the proof PoN contains hash values of nodes on the authentication path from range s(i,j) at some position say, m to the root, given a valid proof PoN and certificate serial number range s(i,j), we can also calculate the hash values for the nodes on the authentication path. Generate an MHT for a list of series of ranges L, starting from the root node, and consider the first node at which node hash value in the authentication path varies from the node in the MHT for the list of series of ranges L. This breaks collision resistance of authentication path. By Lemma 2, a break of collision-resistance of authentication path of MHT results in a collision in H. VOLUME 8, 2020 Case 3: In this case, an ELS acts as an adversary A, and spawns a new MHT to launch a forking (split-view) attack, as the clients accept STH if it is signed by the root CA (see Algorithm 4). If A wins Exp Fake−STH ELS (A) given in Figure 5 by outputting (L , STH , PoN , pk RCA ), then ELS A() , which runs A() and outputs (L , STH , PoN , pk RCA ) can forge signature scheme (EUF-CMA secure). For this, we create another signature forger adversary B, and the attack game. First, we create a signature forgery attacker B given in Figure 6 against the signature algorithm, which works as follows. First, B creates a state with an empty set of certificate ranges. It then simulates the Exp Fake−STH ELS for A, providing the root CA public key as input in the game. It furthermore forms the signatures using its signing oracle when needed in the simulation of the game and stores all the values in a list queried to the signing oracle. If B wins by outputting (L , STH , PoN , pk RCA ), at least tree head TH was not outputted through the B simulation as we excluded the MHT collision case. Since TH was not contained in the list, B outputs this as a valid signature forgery.

VII. EVALUATION
To assess the effectiveness of ARCT, we first compare the revocation method of the proposed approach with state-ofthe-art standardized schemes like CRL, OCSP, and log-based techniques. We then examine the storage cost of each LS (ELS and SLS) and also evaluate the performance of ARCT by building a prototype. At last, we compare the proposed framework with existing log-based proposals using various performance metrics.

A. NUMERICAL ANALYSIS
The communication cost of used data for revocation is optimal, and the proof supplied by the ELS is logarithmic in size, a domain can hold a short proof of non-revocation. The parameters we considered in evaluation are: • There are 3.31 * 10 8 domains [62], though only a fraction has TLS certificates. Estimated total number of domain TLS certificates (n = 10 8 ) • Estimated average number of domain certificates managed by a root CA (k = 10 6 ) • Estimated certificates revocation rate is 10% (p = 0.1) • The TLS certificate status querying rate is 10 8 times per day (q = 10 8 ) • Revocation update per day (T = 1) • The hash function is SHA-256 (l hash = 256 bits) • Length of certificate serial number (l sn = 20 bits) • Number of bits required to represent the certificate revocation status (l stat = 100 bits) • In our scheme signature length (l sign = 512 bits). Values for p, T, l sn , and l stat are taken from [63], l hash , and l sign , are specific to ARCT as SHA-256 and ECDSA (SECP256k1) are used as hash function and signature algorithm. While k and q are based on the value of n, which is taken from [62]. Table 3 summarizes the bandwidth, update, and query cost of the CRL, OCSP, log-based PKIs, and ARCT. Log-based PKIs include AKI, ARPKI, DTKI, and Policert, whereas SK and CT are excluded as they do not support certificate revocation. The above mentioned log-based PKIs use the identical kind of data structure to prove that the certificate is revoked (proof of the absence of a certificate is provided to prove that the certificate is revoked). Without loss of generality, we presume that all parties use machines with a Core i7-8550U CPU @ 1.8, 8GB RAM, Window 10, using which, we calculate and get the following computational costs: • Hash operation takes 4 µs. • ECDSA (SECP256k1) signature generation takes 0.02 s. • ECDSA (SECP256k1) verification takes 0.07 s. We apply these values to Table 3 and get numerical cost, which is given in Table 4.
Analysis. We can observe from Table 4 that OCSP has less cost as compared to the other schemes. However, OCSP has a higher system risk because of heavy reliance on an online trusted third party and extra additional connection, which induces significant time overhead and violates user connection privacy [3]. From Table 4, we can observe that ARCT has less cost as compared to CRL and log-based PKI, and is comparable to OCSP in terms of cost. Additionally, ARCT introduces no extra latency, preserves client connection privacy, and reduces the need for trust in any trusted third party. We can conclude that ARCT revocation has a reasonable cost among certificate revocation schemes.

B. STORAGE COST OF ARCT 1) ELS
Space. The approximate size of a TLS certificate that uses 256 bits public key and signed with ECDSA is 2 9 [41]. We consider Let's Encrypt CA that had signed around 70 million certificates till July 2018. 4 Let's Encrypt needs storing  all 70 × 10 6 TLS certificates which is approximately in the order of 70 × 10 6 × 2 9 ≈ 35.84 GB, while revocation information requires storing 70 × 10 5 serial numbers which is approximately in the order of 2 × 20 × 70 × 10 5 ≈ 35 MB. The price of a 1 GB storage space is around 0.054$, 5 the cost of storing an ELS is about 2$, which is a negligible amount. Again, the number of stored certificates in the log tree and the hash function used in computing the MHT determines the proof size. In ARCT SHA256 is used and the number of certificates is 70 × 10 6 , the proof contains approximately 27 hashes, together with signed root hash; while revocation tree compromises 70 × 10 5 leaves, the proof contains around 23 hashes, together with signed root hash and leaf node. This is less than 1 KB in both cases.

2) SLS
Space. We consider the cost of storing the witness tree (WitTree) as storing TLS certificates by SLS requires space depending on the number of certificates, as already examined in the above section. Currently, there are around 122 root CAs [10] supported by various web browsers/operating systems. Hence, WitTree requires storing 122 ELS STH, which is in the order of 122×160×365 ≈7 MB, per year, and when ELSes update their database once per day, where STH size is around 160 bytes. The cost is insignificant in terms of storage costs. Like in ELS, the number of stored certificates in the SLS and the hash function employed in yielding MHT determines the proof size as well as verification cost.

C. EXPERIMENTAL SETUP
To demonstrate the realization of ARCT in practice, we built a prototype with bare functionality. The prototype consists of 1) a web server (an ACME client) that requests a certificate from an intermediate CA, 2) a set of four CAs that perform collaborative verification. The CAs are implemented by modifying Pebble Challenge Test Server 6 to our requirements. On intermediate CA1, 7 [9]. This shows that the collaborative certificate-issuance process is feasible in practice, and even [9], [10] suggested inducing delay to Lets Encrypt CA issuance process to avoid path poisoning attacks against it.
ARCT increases certificate size roughly by 300 bytes because of sending two or more than two SCTs with each certificate (embedding in X.509 certificate extension or sending as OCSP extension). Fortunately, it does not induce extra delay to the TLS handshake. Nevertheless, ARCT requires about 1KB of additional bandwidth for the TLS connection set up due to non-revocation proof stapling with each certificate. We measured the MHT generation, proof generation, and proof verification in python on a machine with Core i7-8550U CPU @ 1.8, 8GB RAM, Window 10, experimented with a million of revoked certificates logged in ELS. The MHT generation time averaged 12 s, proof generation time averaged 15 µs, while verification time-averaged to 240 µs.
Deployability. SK, AKI, DTKI, and Policert do not change the CA business model, as the CA can sign TLS certificates only, while in ARPKI CAs monitor LSes and other CA's behavior on behalf of their clients. In CT and our proposed scheme, the preferred process for CAs is to embed SCTs (Other mechanism includes sending them via TLS extension) received from LSes in the TLS certificates. For the ''Domain side changes required'' metric, SK and DTKI require each domain to generate an SK pair and a master-key pair to countersign the TLS certificate. In AKI, ARPKI, and Policert a domain contact multiple trusted CAs and staple their certificates. In the proposed framework, a domain server needs to download PoN and staple it with its certificate after each update of ELSes.
Efficiency. For the ''Extra latency TLS connection setup/ End-user additional action required'' metrics, in SK and DTKI, each client must visit timeline and MLM servers, respectively, before every connection to a domain (webserver). This extra connection induces additional latency that is equal to round-trip-time (RTT) as well as violates user privacy and exposes users to blocking attacks.
Monopoly. The last point we test is the monopoly. DTKI has more flexibility to add LSes since browsers have to store only MLM public-key, which lets new LSes to be flexibly added. However, as mentioned earlier, connections with MLM risks users' privacy, induces extra latency, and opens clients to blocking attacks.

VIII. DISCUSSION
Proactive defense. The private keys of CAs are lucrative targets for adversaries (e.g., criminals, hackers, and spy agencies) to use their keys secretly to compromise domains and their clients. We envision that in an ARCT in which not just a single CA but many of them examine and collaboratively issue a certificate, stolen CA keys (e.g., Comodo and Dig-iNotar) would not by themselves be useable to sign a fake but valid certificate for domains that clients would accept.
Deployment aspects. Many CAs, websites, and browsers have widely adopted CT. Google has also recently begun mandating CT logging for all TLS certificates. ARCT ELS could be deployed at each root CA level, and SLS could be deployed directly on the CT's server with the least modifications, given their resemblance.
While CT's LSes are optimized for deployability, ARCT is optimized both for security and deployability. The ARCT framework is planned to be interoperable with the existing CT model. CAs also have incentives to deploy ARCT due to security and transparency reasons. Therefore, we believe that with the heightened interest in a secure network framework, CAs and Internet society can deploy ARCT on the top of the CT with minor changes to the current CT model.
Transitioning, and Tradeoff between security and delay. One of the most significant issues when introducing a new method is the transitioning stage. However, for the adoption of our model, this is not a problem. The collaborative certificate-issuance focuses on ACME protocol, but it can be generalized and can be applied to any certificate-issuance because it involves only repeating the identity verification from multiple vantage points. Nevertheless, the proposed method induces extra latency of a few minutes, as discussed in VII-C.
The delay can be decreased at the cost of security (proactive approach) tradeoff in two ways. First, root CA and ELS allow logging certificates with one or two authorities verification, which will strictly decrease security level to the current certificate-issuance that is vulnerable to MitM attacks. Another option is to generate two SCTs in parallel: the first SCT merely attests that CAs and ELS have seen the certificate, and the second SCT attests that CAs and ELS have validated the certificate. ELS then provides the former SCT but withholds the second SCT if the CAs cannot accomplish their domain's identity validation in the specified time interval.
Third-party validator. Root CA determines when to start a validation round, and multicasts to all CAs the certificate(s) to be validated. In our collaborative domain's identity validation process, root CAs can also take the help of third-party validators (e.g., Internet Service Providers (ISPs), famous domains, or any interested party) in a domain's identity verification. This type of validation with third-party validators can decrease the burden over CAs and assure high security. Similarly, CAs that either issue free certificates (e.g., Let's Encrypt) or have less number of intermediate CAs can benefit from third-party validators directly.
Economic incentive. Root CAs are running businesses and sell TLS certificates to their clients. Security breaches, erroneous certificates, and lack of control over their delegated trust have undermined their reputations, which were challenging to mitigate and control. ELS and collaborative verification help root CAs to counter these challenges. Therefore, root CAs understand the lucrative value of ELS that make controlling their delegated trust and observing their intermediate CAs operations more accessible and transparent. Further, ELS would make it easier for domain owners to decide to select which root CA as their root of trust based on its previous history. Thus, a root CA with high security, quality certificate-issuance, and internal transparency (making intermediate CAs and their operation open to public scrutiny) would gain a competitive advantage, which would cause an increase in its market share.

IX. CONCLUSION
This article presents a new log-based PKI framework that leverages a log server (ELS) per root CA to make intermediate CA management transparent. The ELS counters the lack of root CAs control over their delegated trust as well as prevents malformed certificate-issuance. The new collaborative identity verification of domain offers strong resilience against adversaries, who can compromise a CA's private-keys. The method ensures that adversaries cannot maliciously issue a fake certificate that clients would accept, without exposing that certificate to the set of CAs for public scrutiny. The validation of each certificate by a group of CAs causes a high probability of immediate detection of malicious certificates. Security analysis shows that ARCT can successfully defend against impersonation and forking attacks. Evaluation results and comparison with log-based PKI schemes prove that ARCT is cost-effective and practical.