Abstract
Current Transport Layer Security (TLS) Public-Key Infrastructure (PKI) is a vast and complex system; it consists of processes, policies, and entities that are responsible for a secure certificate management process. Among them, Certificate Authority (CA) is the central and most trusted entity. However, recent compromises of CA result in the desire for some other secure and transparent alternative approaches. To distribute the trust and mitigate the threats and security issues of current PKI, publicly verifiable log-based approaches have been proposed. However, still, these schemes have vulnerabilities and inefficiency problems due to lack of specifying proper monitoring, data structure, and extra latency. We propose Accountable and Transparent TLS Certificate Management: an alternate Public-Key Infrastructure (PKI) with verifiable trusted parties (ATCM) that makes certificate management phases; certificate issuance, registration, revocation, and validation publicly verifiable. It also guarantees strong security by preventing man-in-middle-attack (MitM) when at least one entity is trusted out of all entities taking part in the protocol signing and verification. Accountable and Transparent TLS Certificate Management: an alternate Public-Key Infrastructure (PKI) with verifiable trusted parties (ATCM) can handle CA hierarchy and introduces an improved revocation system and revocation policy. We have compared our performance results with state-of-the-art log-based protocols. The performance results and evaluations show that it is feasible for practical use. Moreover, we have performed formal verification of our proposed protocol to verify its core security properties using Tamarin Prover.
1. Introduction
Transport Layer Security (TLS) is the backbone and grand success in securing network-based communication. Most of the financial and commercial applications as well as noncommercial applications depend on TLS for security. TLS provides defense against different kinds of attacks [1–3]. The current TLS Public-Key Infrastructure (PKI) is a huge and complex system consisting of processes, policies, and entities that are responsible for secure certificate management processes. It is essential to securely communicate and reliably link a public key with its owner [4–7]. All the processes, policies, and entities play their role in securing the TLS PKI, but CA is the primary trusted anchor and entity in the current PKI [8]. CA signs and issues certificates for the domain (Server). The certificate is considered trusted if trusted CA signs it. Therefore, CA is the primary anchor and party in PKI, where integrity and security of the current PKI depend on the security, trustworthiness, and reliability of CA. Unfortunately, in recent years many attacks have been launched against TLS PKI infrastructure, and several most tectonic attacks have revealed the vulnerability of CA in practice. In particular, if a CA gets compromised in the present trust model of PKI, it can issue a counterfeit certificate for any domain under its authority. Such maliciously issued inauthentic certificate can be used for an extended period without being noticed. These types of vulnerabilities are widely been recognized in the literature [9, 10].
CA has issued bogus certificates all over the world, including France [11], Turkey [12], USA [13, 14], the Netherlands [15], and China [16]. Even the Symantec CA (SCA) owning near about quarter of certificate market share [17] was found of issuing a spurious certificate for Google domain and almost 2500 fake certificates were issued for unregistered and real domains as part of a test [18, 19]. Due to the issuance of bogus certificates by CAs, man-in-middle-attack (MitM) has been launched against various famous sites such Google, Skype, Yahoo, and Microsoft Live [20, 21].
These fraudulent and bogus certificates were issued either due to misconfiguration, software error, operational error, and social engineering or due to government enforcement and compulsion [22–24]. For example, an unauthorized certificate for Google domain was issued [11, 25] due to human errors. Similarly, a government can also compel CAs to issue a rogue certificate for a domain to launch compelled certificate creation attack [22]. Likewise, the Comodo was hacked by an Iranian hacker and issued unauthorized certificates for various domains [13, 26].
Certificate revocation is another big problem that needs to be addressed. A study and survey showed CAs owned by three different companies had issued around 75% out of all certificate. Only, Symantec CA (SCA) owned near about quarter of certificate market share, and GoDaddy CA had signed nearly 26% of all certificate in 2013 [17, 27–30]. Revoking GoDaddy certificate if its private key gets compromised would invalidate 26% of all HTTPS server certificates. This revocation will result in the unavailability of 26% of HTTPS servers. So revoking certificates of these significant CAs would result in substantial and collateral damage. In 2011, DigiNotar and Comodo got compromised [15, 31], the certificate of the former victim was revoked from browser CAs list [32], but the later victim certificate is still present in browser CAs list [33].
To solve these problems, some techniques have been proposed in the literature. Certificate transparency [34] is one such project that was initiated by Google for detecting the misbehavior of CA and refraining CA from fake certificate issuance by making certificate management process transparent. In this technique, public log implemented as Merkle hash tree is used as evidence. Each domain enrolls the CA-issued certificate on this log server. The server then returns the signed certificate time (SCT) to the domain, and the domain provides this SCT to a client on TLS connection setup as testament. This technique is not immune to attacks when CA get compromised. Policert [35] is another proposal that tries to empower domain by giving supremacy to a domain to describe their policy, certificate, and TLS connection setup properties. This scheme also uses public log server for validation, management, and enforcement of its policies. However, in this approach, no mechanism is specified to detect log misbehavior.
In our proposed protocol we have tried to solve the above problems and have contributed the following improvements.(1)We explore two kinds of attacks for Policert and mitigate these attacks by introducing an improved revocation system and monitoring mechanism.(2)The proposed scheme can handle the certificates hierarchy, intermediate CAs discovery, and provide a method to revoke CAs certificates without causing collateral damage.(3)We have verified the core security properties of our proposed protocol using formal verification tool Tamarin Prover [36].
The rest of the paper is organized as follows. Section 2 describes related work. Section 3 gives an overview of preliminaries. Policert: Secure and Flexible TLS Certificate Management is summarized in Section 4. In Section 5, we overview in detail the proposed scheme. Section 6 highlights the security analysis. In Section 7, we present the performance and comparison and discuss some practical concerns in Section 8. Finally, Section 9 concludes the paper with remarks for future work.
2. Related Work
Numerous works have been done to address the security and trust issues of current TLS PKI [28, 37, 38]. Perspective [39], Convergence [40], and Observatory [41] are notary-based lightweight PKI, in which notary continuously monitors web server’s certificates and stores these certificates in public repository. This public repository enables clients to confirm the server public key with that stored in public repository. Other approaches attempt to empower domain owners and limit the role CA [42, 43]. We discuss the proposals that use publicly variable log.
In 2011 EFF has started the Sovereign Key (SK) [44] project which is a public log-based approach for accountability of CA transaction. In the Sovereign Key technique, long time key is generated to get rid of browser certificate warnings. If a browser does not succeed in establishing a secure connection with the domain, it may result in hard failure. For signing TLS public key in Sovereign Key technique, each web server needs to have sovereign key pair logged on a server called time-line server. However, the main limitation of SK is that the clients have to rely only on the mirror of the server which does not provide efficiently verifiable proof that certificate is actually on the server. Another problem is that client need to query servers before connecting to the domain, introducing extra latency and sacrificing client privacy.
Certificate Transparency [34] is a technique that is proposed by Google to detect bogus certificate issued by a compromised CA to make certificate issuance transparent. It is an improvement over the Sovereign Key (SK) by organizing append-only log through Merkle hash tree. The log maintainer in CT can serve clients with two types of cryptographically verifiable proof: (I) proof that a given certificate resides on the log server; (II) proof that the log is an extension to the previous log. Since it uses Merkle hash tree for the log, so the proof generation and verification time are logarithmic. This CT technique has several limitations. First, CT can not efficiently prove that a specific certificate is not present in the log since certificates are stored in chronological order. Second, as the goal of CT was to detect CA misbehavior, so CT is vulnerable to attack when CA gets compromised by an adversary to create and register fake certificates. However, CT does not guard against this attack by preventing clients from accepting these spurious credentials. Moreover, CT has no built-in revocation transparency, so revocation transparency called Revocation Transparency is proposed [45]. However, it is still not incorporated.
Accountable Key Infrastructure (AKI) [46] is public log-based technique that tries to enhance and improve certificate management transparency. AKI protects domain and client from a single point of failure such as when CA or log get compromised. Besides, the trust is divided among various parties and check and balance method is used for detecting the misbehavior of the trusted entities. Moreover, to solve certificate revocation problem in the log, they uses Merkle hash tree that stores data lexicographically rather than chronologically. The AKI uses the validator for ensuring log consistency and detecting log misbehavior for securing clients against attacks. Again the AKI depends heavily on third-party agent called validator for security. The second problem is that the public log server stores only currently active, valid certificates and keeps no record of revoked certificates (purged from the public log). Checking for revoked certificates in public log is inefficient (linear) in AKI. Moreover, AKI does not support multidomain certificates.
In Distributed Transparent Key Infrastructure (DTKI) [47], Certificate Transparency (CT), Sovereign Key, and Accountable Key Infrastructure (AKI) are combined for certificate management without having any trusted monitor. DTKI uses the Sovereign Key concept of signing with a master key and then registering the certificate on a public log just like in CT and AKI. After successfully enrolling the CA-issued certificate on the public log, a client will accept the certificate present in the public log and validated by the domain owner. In DTKI, the client is responsible for verifying the integrity of public log and trusted validator is no more required. However, DTKI uses gossiping methods for synchronization of log status and contacting log server before every connection results in high latency. Hence, client privacy is violated because the log server knows about the client connection with the domain. Furthermore, in DTKI every one has to trust on the mapping log maintainer. DTKI has no mechanism for recovery from domain master key comprises.
The Design, Analysis, and Implementation of ARPKI: an Attack Resilient Public-Key Infrastructure [48] is public log-based Public-Key Infrastructure providing certificate related services and is an improvement over Accountable Key Infrastructure. In ARPKI, registering certificate requires the domain to contact only one CA, but a domain designates n service providers. The entitled service providers perform cross-checking and monitoring of the each other in ARPKI. So ARPKI mitigates attacks when n-1 trusted parties start colluding with each other due to cross-checking and monitoring. The security parameters are also proved using Tamarin Prover. The first limitation is that protocol goes through cool-off period in case of key compromise or improper key update. The second drawback of ARPKI is extra latencies and client connection delay due to the involvement of the all trusted parties in all processes. Another problem is that the public log server stores only currently active, valid certificates and keeps no record of revoked certificates (purged from the public log). Checking for revoked certificates in public log is inefficient (linear) in ARPKI. Moreover, ARPKI does not support multidomain certificates.
In Policert: Secure and Flexible TLS Certificate Management [35], the domain owners are given more control over their certificate usage and verification by a specification of detailed subject certificate policy on the certificate usage. So a domain needs to describe and specify the properties of TLS connection. Policert is a public log-based scheme like Accountable Key Infrastructure AKI for management, publication, and enforcement of its policy. Multisignature certificate and subject certificate policy is inscribed on public log server. However, in this approach, the mechanisms for detecting and disseminating log misbehavior are unspecified. The second problem is that protocol goes through cool-off period in case of key compromise or improper key update. Another problem is that the public log server stores only currently active valid certificates and keeps no record of revoked certificates (purged from the public log). Checking for revoked certificates in public log is inefficient (linear) due to Lex-Tree in Policert. Moreover, Policert has no solution for certificate chain (intermediate CAs discovery).
To incorporate a revocation system and its monitoring mechanism into CT, an attempt was made in [45, 49, 50]. These proposals try to address the revocation system problem left open by CT. The certificate revocation checking process in Revocation Transparency [45] is linear and inefficient. Certificate Issuance and Revocation Transparency [50] improved the certificate revocation checking operation by using tree called Lex-Tree. However, CIRT cannot handle key loss, and a domain needs to create a fresh identity. Recently, another proposal called PKI Safety Net (PKISN): Addressing the Too-Big-to-Be-Revoked Problem of the current TLS ecosystem was proposed [49], to address the revocation problem of the CT, and provides guidelines for lightweight monitoring. This proposal has no support for a multiplicity of log servers that would be needed for certificates. However, none of the above techniques are incorporated into CT yet. Moreover, none of the above discussed log-based schemes (CT, AKI, APRKI, DTKI, and Policert) have a solution for certificate chain (intermediate CAs discovery). Table 1 highlights the pros and cons of the log-based PKI schemes that aim to address security and trust issues.
3. Preliminaries
3.1. Merkle Hash Tree
Merkle hash tree is maintained in the form of a binary tree where data is stored in leaf-node [51]. The remarkable characteristics of the Merkle hash tree are that it can prove set-membership and nonmembership in an efficient and publicly verifiable way. These proofs are mainly the proof of presence, proof of absence, proof of extension, and proof of currency. In literature, publicly verifiable log data structures are extensively studied [34, 44, 50, 52–54]. Merkle hash tree can be maintained either in the form of chronological or in ordered data structure. The possible implementation of the chronological data structure is Merkle-tree as proposed in [34, 50, 52, 55]. The order data structure can be stored as Merkle-tree organized as binary search tree as in [50, 53].
3.2. Bilinear-Map
Let G, be a multiplicative cyclic group of order q, and g is the generator. A function is bilinear pairing map if it has the following properties:(1)Bilinearity:∀ P and Q G, and b (2)Nongeneracy:∀ g G, (3)Computability: e must be efficiently computable
3.3. Accumulator
A cryptographic accumulator was first introduced by Benaloh and de Mare [56], who defined accumulator as a one-way hash function having the property of quasicommutative. A quasicommutative function can be defined as such that
Accumulators are further extended and improved by [57–61]. Our proposed scheme uses bilinear-map based accumulator for proving membership and nonmembership for a certificate in the log server. Suppose we have an instance of bilinear pairing and a set X = , such that . Let s be the trapdoor information from . Then the accumulation value of X isThe witness for element is , the value s is the secret key sk of accumulator, the set is the public key pk, and the verifier having the pk and accumulator value can authenticate the membership witness by testingSince g and are part of public key and are equivalent to mathematically, the nonmembership witness for element is a pair , where and for some polynomial of degree n-1, uniquely defined by set X. The nonmembership witness can be proved by verifier by checking the equation, having public key and accurate accumulated value.This accumulator is collision-free under the q-Strong Diffie-Hellman assumption.
Definition 1 (negligible function). A function is negligible if , there exists such that , we have .
Definition 2 (q-strong Diffie-Hellman assumption [12]). Let be the generator of cyclic group of prime order and . Any probabilistic polynomial time algorithm that is given set can find a pair with probability at most .
Hash function: finally, we will use a secure collision-resistant hash function.
Definition 3 (collision-resistant hash function). Hash function is a collision-resistant hash function if it is hard to find for two messages , such that and .
4. Overview of Policert: Secure and Flexible TLS Certificate Management
We overview the Policert: Secure and Flexible TLS Certificate Management [35] for two reasons: ATCM is inspired by Policert’s design and concepts and employs some of its ideas and concepts; ATCM addresses several shortcomings and limitations of it that we have identified. It was proposed to mitigate and protect domain and client from losses and vulnerabilities caused by CAs private key compromises [62, 63]. It works with the following five agents:(1)Certificate Authority (CA): a CA authenticates domains and issues policy and X.509 certificates.(2)Domain: a domain specifies the fine-grained policy and binds multisignature certificates from different CAs by signing with policy private key.(3)Clients: a client wants to communicate with a domain for using services securely.(4)Auditor: an auditor monitors log server operations and detects misbehavior.(5)Log Server: Log Server maintains a database in the form of Merkle hash tree that logs domain policies and certificates.
The last two agents are not present in traditional PKI but are most important in Policert. The auditor is responsible for monitoring the log server and detects log server misbehavior, while log server is used to make CAs accountable. In Policert, the domain owners are given more control over their certificate usage and validation by a specification of detailed subject certificate policy (SCP). So domains are able to specify the properties of the TLS connection. It separates policy and certificate from each other so each domain has policy and certificate key pair. Separating key pairs provides security and allow domains to have multiple certificates and one policy. All the messages and actions are mainly divided into three categories. In the first type, certificate and policy management is done. The domain registers a CAs signed SCP on log server (LS) and binds together certificates from different CAs by signing with a subject certificate policy private key to create a certificate named multisignature certificate (MSC). The MSC is then registered on LS for secure communication with clients. The second and last category is concerned with LS audit and MSC validation and verification, respectively.
4.1. Attacks on Policert
Unfortunately, Policert has several loopholes and vulnerabilities through which MitM can be launched. The MitM attack can be made on Policert protocol through improperly revoked MSC as there is no proper method for MSC revocation consistency and revoked MSC are merely purged from log server. The revoked MSC can be inscribed at log server that had not recorded the certificate previously. Once the revoked certificate is logged, it can be used till the validity of the certificate.
Impersonation attack can also be launched against the Policert by compromising the log server. In this case, the attacker can use a malicious certificate to launch the attack against clients. The log server can use the different version of the database for launching the attack against the targeted victims as Policert has no mechanism to guard and detect such type of attack; ignoring security alerts and warning by victims is common in practice [64–67].
4.2. Policert Weaknesses
It has several drawbacks and problems that need to be solved. First, in Policert, only currently active certificates are stored and keep no record of revoked certificates as revoked certificates are merely removed from log server. Checking for a revoked certificate is linear in time, i.e., inefficient.
Second, Subject Certificate Policy (SCP) is not well defined and need to determine some more parameters for the proper management of certificates revocation since SCP did not include parameters for certificates revocation. Moreover, in Policert, it is necessary to register the SCP on log server and provide the proof to a client for validation, which introduces extra communication overhead.
Third, Policert has supposed that all certificates are directly signed by root CAs, which is unusual in practice. So it ignores certificates chain and hierarchy and intermediate CAs. Policert has no method to revoke CA certificates.
Finally, it has several loopholes and vulnerabilities through which MitM attack can be launched as discussed in detail in section Attacks on Policert.
5. Accountable and Transparent TLS Certificate Management: An Alternate Public-Key Infrastructure (PKI) with Verifiable Trusted Parties (ATCM)
Accountable and Transparent TLS Certificate Management: an alternate Public-Key Infrastructure (PKI) with verifiable trusted parties (ATCM) is a Public-Key Infrastructure (PKI) for managing certificates, domain policies, and making trusted parties like CAs accountable to the public. ATCM provides a strong defense against attacks by introducing cross-check method to detect misbehaving entity. We base ATCM on a verifiable log and extends Policert described in preliminary. In ATCM, we provide an overview of the principal agents involved and its responsibilities:(1)Clients: client (user browser) is an actor that wants to connect with a domain (server) securely.(2)Domain: a domain or server is an entity whose services are used by a client, and the client wishes to have a secure connection with a domain. The domain has public-key certificates signed by CAs and one or more key pairs, and this signed certificate will be presented to the client (user browser) for identification during TLS handshakes.(3)Auditor: an auditor is an entity whose duty is to fetch records from a log server periodically and performs verification that all of the records and information are correct. It enables a client to ensure that proof provided by the server is correct and valid.(4)Certificate Authority (CA): CA is responsible for signing certificates for domain owners. Before signing the certificate for the domain, she verifies domain owner’s identity and signs subject certificate policy and certificates after the verification. However, unlike today’s CA, the capability of CA in our proposed protocol is limited since signing and issuance of a certificate from a CA are not enough to make certificate valid and convince client (user browsers) to accept the certificate. However, in contrast to Policert, the CA checks the log server for their misbehavior and signs the root of log server. It mitigates the MitM chances.(5)Log Server (LS): the ATCM scheme has log servers that record all certificates and efficiently generate proofs that can be efficiently validated and verified. These proofs are mainly the proof of presence, proof of absence, proof of extension, and proof of currency that are then used by clients, domain, and CAs. Log server can see all certificates globally; therefore, it can provide a global view and consistency checks. In ATCM, log server can also be compromised, and there is also check and balance on their actions and behavior.
The ATCM working is shown in Figure 1. In ATCM, three appointed entities are actively involved in supervising each other conduct and operation during an MMSC registration. Here CA1 validates the correctness and trustworthiness of the other two parties operations and perform the role of messenger among domain, log server1, and CA2, while CA2 acts as monitor ensuring that log server1, as well as other LSes, operates accordingly. The domain also designates log server1 to ensure that an MMSC is synchronized among all LS.
5.1. Architecture
5.1.1. Master-Key Signed Multisignature Certificates (MMSC)
Master-key signed multisignature certificate (MMSC) binds a domain name to public key using more than one CA signatures. The MMSC is encoded as a collection of multiple standard x.509 certificates for backward compatibility with current PKI. For domain D MMSC is defined as follows with CA signatures:where represents a normal X.509 v3 certificate and represents policy binding of MMSC. In the proposed protocol, we also take into account the intermediate CAs hierarchy. The format of the multisignature certificate, when signed by intermediate CAs will beThe certificate represents the certificate chain of CA1. The certificates , , and are the root CA certificates while and are intermediate CAs certificates.
5.1.2. Master-Key Certificate Policy (MCP)
The MCP binds information regarding usage, validation, and revocation of certificates to the domain name. The parameters are encoded in MCP as an extension in X.509 standard certificates [68], and MCP must be signed by a threshold number of CAs for its validity. Unlike SCP in Policert, MCP does not need to register on log server. MCP contains the following fields: (1) General parameters(i)POLICY_VERSION: it indicates current master-key certificate policy version number.(ii)CA_LIST: it indicates domain trusted CAs list for signing MMSC and MCP.(iii)MIN_CA: it indicates the minimum number of CAs signatures on MMSC for certificate registration on log.(iv)CA_TH: it indicates threshold number of CAs signatures on MMSC to valid and must be less than the number of CAs in CA_LIST.(v)COP_MK_UNLINKED: cool-off period is applied if new certificate is not signed by MCP private key.(vi)COP_CA_UNTRUSTED: cool-off period is applied if CA signs certificate not present in CA_LIST. (2) Additional parameters(i)ONLY_EV: this field specifies that only extended validation (EV) certificates can be combined in MMSC.(ii)MAX_CC_LENGTH: it refers to maximum length of a certificate chain.(iii)NO_WILD_CERT: wildcards certificates are not allowed in MMSC. (3) Security parameters(i)MIN_CERT_SEC: define an MMSC certificate min security level.(ii)MIN_TLS_SEC: TLS negotiated parameters min security level. (4) Revocation parameters(i)DOMAIN_KEY: this specifies the master key of a domain.(ii)ROOT_CA_List: root CAs can directly revoke their certificates and intermediate CA certificates from a given checkpoint in a log called revocation-time-stamp. For domain certificate revocation MIN_CA root CAs are needed.(iii)INTER_CA: intermediate CAs can directly revoke their own certificates from a given checkpoint in a log called revocation time-stamp. For MMSC revocation, MIN_CA CAs are needed. (5) Connection Failure parameters(i)CERT_TH_FAIL: when an MMSC is invalid due to CERT_TH.(ii)TLS_FAIL: if TLS connection security level is too low.(iii)POL_VER_NOT_REC_FAIL: if policy version is old.(iv)EXP_LOG_PROOF_FAIL: if log server proof is outdated.(v)LOG_PROOF_FAIL: if log server proof is invalid.(vi)OTHER_FAILURE: aLL other types of failures.
5.1.3. Log Server
The number of log server is small and operated by Internet Service Providers (ISPs), web browser vendors, famous domains, or any interested parties. In short, log server has enough memory and computing power to store certificates and generate proofs. These proofs are mainly the proof of presence, proof of absence, proof of extension, and proof of currency. These proofs make log server behavior transparent to the world, and no one will blindly trust log server. In literature, publicly verifiable data structure is extensively studied [34, 44, 50, 52–54]. According to our literature survey, no single data structure is sufficient to provide all proofs needed by our proposed scheme. In our construction, log server is organized by using the tree data structures: Cert-Tree (CerT), Chain-Tree (ChT), Lex-Tree (LT), and Bilinear-map Accumulator Tree (BAT). The first two trees are maintained in the form to reflect the hierarchical structure of CAs, Lex-Tree is stored in the form of binary search Merkle-tree, and Bilinear-map Accumulator Tree is maintained in the form of accumulation tree. Cert-Tree (CerT). In Cert-Tree(CerT) all certificates are logged in chronological order, where the log stores MMSC, revocation (REV), the root of the Chain-Tree (ChT), accumulation value A of BAT, and the digest of Lex-Tree and acts as time-stamping service. In this tree, all certificates are appended to the right of the tree. When CA request for MMSC logging, it is added to the right of the certificate tree in chronological order. Chain-Tree (ChT). The Chain-Tree (ChT) consists of various subtrees in the form of a forest of trees and is stored in lexicographical order that mirrors the hierarchical and chain structure of certificate chains. The ChT leaf represents a certificate and its associated registration time-stamp . It also saves the possible revocation messages of a key if revoked; otherwise it stores ø, when a certificate has no associated revocation message. The parent represents the root CA while associated children nodes represent certificates signed by the parent node. The subtree of the parent node may be ø, when it does not sign any certificate. Lex-Tree (LT). This tree is stored in the form of binary search Merkle-tree, where data items related to domain D are stored in such a way that left-right traversal results in lexicographic order of domain D. The size of the Lists is bounded by a constant X in Lex-Tree and is maintained in first-in-first-out (FIFO) fashion. Unlike, Lex-Tree in CIRT, we keep two lists: one for active MMSC and the other for revoked MMSC. Bilinear-map Accumulator Tree (BAT). This tree is organized as binary search tree storing only active MMSC of domain lexicographically. Let C be the set of active MMSC; the C is implemented as a BAT. Each node in BAT contains an and the membership witness of MMSC. The accumulation value Acc(C) is linked to a leaf-node of the Cert-Tree.
5.2. Protocol Description
5.2.1. Certificate Registration
A domain owner spawns an MMSC by binding multiple X.509 certificates from a list of trusted CAs by signing with MCP private key. The domain owner explicitly designates trusted entities for performing MMSC registration, namely, two or more CAs and one log server. The domain owner will send an MMSC to one of the CA, and other CAs will monitor the behavior of other entities involved in the certificate registration process. Upon receiving the registration request from the CA, the log server first validates the multisignature certificate. If so, the LS will send back the following message to the CA when a quorum of LS agrees; to ensure a consistent view of domain D .The above is a time-stamped registration receipt containing the newly registered certificate and guaranteed time of presence in the log. The will be online after time ; , and show the certificate chain presence time of corresponding CAs. During the update of log server, the will be added to the log server; the public parameters (PPs) are updated, the following operations are performed on log trees. (i)Adding to BAT: let C be the set of active certificates and compute the accumulation value according to the new set , where s is the trapdoor information, i.e., secret key. For each , the membership witness is updated as . The BAT root is updated correspondingly.(ii)Adding to Lex-Tree: search tree for the domain D, if it exists, then add the new to the active certificate list for D. Otherwise, spawn a new node for D with two lists for current and revoked certificate. Add the to active certificate list and initialize revoked certificate list with null value; insert the newly created node to Lex-Tree in lexicographic order. The Lex-Tree root is updated correspondingly.(iii)Adding to Chain-Tree: search for the root CAs certificates corresponding to the certificate chains in in the certificate tree and append to the last of the corresponding chains as the last node with revocation and subtree set to ø. Update the root of the tree.(iv)Adding to Cert-Tree: add a new node consisting (, , , and ) to the right of the append-only tree. The new root of the Cert-Tree is updated as . Additionally, all intermediate CAs certificates are appended as well (if the intermediate certificates are not already in the LS).
5.2.2. Proof Querying
Anyone can send a query to the log server for the evidence of an MMSC. However, auditors are special entities responsible for detecting LS misbehavior by querying proofs from LS. The possible proof depending on the query can be the proof of the presence of a certificate, the absence of a certificate, absence of a domain, currency, extension, and presence of certificate chain. Anyone can request these proof from the log server and check the log server misconduct. The auditors, as well as well CAs, are primarily responsible for detecting the transgression of the log server.
5.2.3. Proof Generation
Upon receiving a request for verification, the LS yields the corresponding query as follows:(i)Proof of presence of an MMSC: search for an MMSC in the Lex-Tree. If a node for the domain D is present in the Lex-Tree, send the sequence of hashes forming authentication path.(ii)Proof of absence of an MMSC: search for the MMSC in the BAT. If there is no MMSC in the BAT, then send the witness for nonmembership of an MMSC, where and .(iii)Proof of absence of a domain: for domain D, the log server first locates the two neighbor node and that bracket D, namely, (in Lex-Tree). Next, the log server sends a proof that is in position i in log server and that is in position i+1 in log server.(iv)Proof of extension: proving that the current certificate tree extends the previous Cert-Tree can be done logarithmical in time and space, by sending at most one digest (hash) per level. If is an extension of , then is a subtree of the tree.(v)Proof of currency: for an MMSC currency evidence, search it in BAT. If the search is successful, then send the membership witness .(vi)Proof of presence of certificate chain: search the Chain-Tree for the certificate chain and yield the presence proof, by providing all the necessary nodes. The size of proof is not quite logarithm but instead needs number of nodes, where m is Chain-Tree height and n is the maximum number of entries in the Cert-Tree. However, in almost all cases the Chain-Tree (ChT) will be very small.
5.2.4. MMSC and Log Proof Validation and Verification
After determining the policies parameters, the client validates and verifies the MMSC by checking that all certificates in MMSC sign the same public key, issued for a right domain, expiry date, having current policy version number, and validating certificate chain path. The verification is performed as follows.(i)Proof of presence of an MMSC: the authentication path consists of hashes, the verifier will calculate the root hash from the path, and if the root hash calculated is equal to Lex-Tree digLT, then it is accepted, otherwise rejected.(ii)Proof of absence of an MMSC: given the witness for nonmembership of an MMSC, calculate the and accept if the equation holds, otherwise failure.(iii)Proof of absence of a domain: a verifier receives a proof that is in position i in log server and that is in position i+1 in log server. The verifier can verify that these two nodes are neighbor on the same search path and that , and this proves that D does not exist in Lex-Tree.(iv)Proof of extension: the verifier computes that if is an extension of , then is a subtree of the tree from the hashes sent by log server per level.(v)Proof of currency: given the witness for membership of an MMSC, calculate the , and accepts if the equation holds, otherwise failure.(vi)Proof of presence of certificate chain: the proof consists of hashes, the verifier will compute the root hash from the path, and if the root hash calculated is equal to Chain-Tree digChT then it is accepted, otherwise rejected.
5.2.5. MMSC Revocation
The revocation power of MMSC is only with a threshold number of CA. For revocation of an MMSC, domain owner designates the trusted agents as in registration process to have consistency. The revocation request consisting of an MMSC (revoking certificate) and appropriate signature is sent to responsible CA.Let an MMSC be signed by two CAs; then the following message is sent to log server:As revoking CA certificate causes a substantial and collateral damage, so to avoid collateral damage caused by CA certificate revocation, it is performed from a specific checkpoint in the log server using time-stamp by the following message:The key k can be root CA key or intermediate CA key to revoke a certificate. The root CA can directly revoke its own, intermediate CA certificate from a certain point in the log server, while intermediate CA can revoke its certificate from a checkpoint in log server. The revocation message carries a revocation time-stamp that represents the specified time from which the specified CA certificate and revocation issuance must be invalidated. The log server processes the certificate revocation request upon receiving and returns a revocation receipt containing the certificate and guaranteed time of certificate revocation in the log server. The following operations are performed on the log server, and public parameters are also updated. (i)Removing an MMSC from BAT: calculate the new accumulation value for new set as . The BAT is updated.(ii)Revoking an MMSC in Lex-Tree: in the Lex-Tree, an MMSC is added to revoked certificate list for the corresponding domain.(iii)Revoking an MMSC in Chain-Tree: only revocation message is added to the revoked MMSC and tree new root digest is calculated.(iv)Revoking an MMSC in Cert-Tree: search an MMSC and append a revocation message to the corresponding certificate and the root digest is just updated by appending all trees new root digest to the rightmost node.(v)Revoking CA certificate: to invalidate CA certificate from a checkpoint, append a revocation message to the chain containing the certificate to be revoked which will invalidate all the subsequent domain MMSCs from that time and onward. Moreover, a revocation message is also appended to the CA certificate in the Cert-Tree. The BAT and Lex-Tree are updated by invalidating all MMSCs effected by revoked CA certificate.
5.2.6. Client Connection to Domain
After completing the MMSC initial registration process, the domain D has an MCP, an MMSC, and its registration receipt or proof from log server. When a client initiates a TLS connection to a domain, the domain will send latest master-key certificate policy version and policy, master-key signed multisignature certificate (MMSC), and logging proofs for MMSC showing that the certificate is valid and related to the policy. After getting all these, the user browser will perform all the necessary actions and validates the certificates and proofs. The user browser will accept the connection if all operations are successful.
6. Security Analysis
Proof Using Tamarin. We have analyzed the security of our proposed protocol using formal protocol verification tool Tamarin Prover [36]. The Tamarin Prover is a symbolic tool for verification of security protocol that supports both unbounded verification and falsification in the nominal model. In the implementation of our model, we have abstracted several ideas just as in [47, 48, 69]. The log server is abstracted in the form of a list, and we also have only verified the security-related parameters of MCP instead of all other irrelevant information. In Tamarin Prover the protocols are coded as multiset rewriting rules while properties are expressed in the form of first-order logic rules. The following shows the MMSC creation rule:
rule D_Create_MMSC:
let Policy = $ LSk + $ CA1 + $ CA2 TD = time(~t) pkD = pk(~ltkD) pkPol = pk(~ltkPol)
in
[ !Ltk($D, ~ltkD), !Ltk( $D, ~ltkPol), F_CERT($D,pkD),
PublicFrVal(~t) ]
- -[ Is_Kind(’Agent’,$D), Is_Kind(’LS’, $LSk),
Is_Kind(’CA’,$CA1), Is_Kind(’CA’,$CA2),
MMSC_Req($D, ~ltkD) ,Clock(TD) ] -
[ CombineMultipleCerts($D, sig(sig( ( ’Cert’, $D, pkD,
pkPol, Policy ), ~ltkD) , ~ltkPol)),
Out($D, $CA1, sig( ( ’ReqForSigning’, sig(sig( ( ’Cert’,
$D, pkD, pkPol, Policy ) , ~ltkD), ~ltkPol), TD ),
~ltkD))
, Out($D, $CA2, sig( ( ’ReqForSigning’, sig(sig( (
’Cert’, $D, pkD, pkPol, Policy ) , ~ltkD) , ~ltkPol), TD
), ~ltkD))]
The adversary interacts with the protocols in Tamarin Prover by updating and generating network messages. The default adversary model used in Tamarin is a Delov-Yao adversary model, in which the adversary has control over the whole network and can intercept, delete, inject, and modify the network data and messages. We state our security goals in the form of implication in Tamarin syntax marked as a lemma. The following is one such goal to check the proper working of the protocol communication.
lemma Protocol_Proper_Work_Check:
”
(
All connid D B VL m key #i1. ( Communication ( connid, D, B, VL, m, key) @ #i1 & not (Ex #i2 CA1 ltkCAx1. Compromise_CA1 ( CA1 , ltkCAx1 ) @ #i2) & not ( Ex #i3 CA2 ltkCAx2. Compromise_CA2 ( CA2, ltkCAx2 ) @ #i3) & not ( Ex #i4 K ltkK. Compromise_Ls (K, ltkK) @ #i4)
) ( not (Ex #i5. KU(m) @ #i5) )
”
In the lemma, a message is sent from domain D to user browser B when no party is compromised in the protocol to check the proper working of the protocol.
Analysis. Using the Tamarin, we have first checked the proper working of the protocol, then we have identified various expected attacks by compromising one, two, and all parties in the protocol. We find that our protocol can guard against attacks when at least one entity is not compromised by an adversary and verify the lemma but fail when the adversary controls all the entities involved.
We experimented the proof on a personal computer with an Intel (R) Core (TM) i7-4790 CPU (3.60GHz) and 8GB of RAM. We have run the proof on VMware Workstation 12Pro and Ubuntu 16.04 64 bits as an operating system.
7. Performance Evaluation
To assess the effectiveness and efficiency of Accountable and Transparent Public-key Infrastructure, we compare ATCM with existing log-based schemes CT [34], AKI [46], DTKI [47], Policert [35], and ARPKI [48].
7.1. Asymptotic Analysis
Let k, m, and n be the total number of the domain, active certificates, and certificates in log server, respectively, and X be the accumulation set of certificates in the log server. The asymptotic costs of the different schemes are shown in Table 2.
7.1.1. Numerical Analysis
Currently, there are domains [70], so we suppose the database is required to store certificates for domain, who enroll with the LS over five-year period. We also assume that, on average, of the certificates are revoked per year. This amounts to 180,000 certificates issuance per day and 95,000 certificates revocations per day during five years, a total of 275,000 operations per day. Insertion and revocation occur in the order of transactions on Lex-Tree, Cert-Tree, and Chain-Tree. This takes negligible time. However, the BAT takes O(m) operations as each element membership value is updated. But, we get constant proof and verification cost.
ATCM induces no extra network request (no extra round-trip latencies) to the TLS handshake. However, ATCM expands the TLS handshake message size by approximately a kilobytes due to LS proof stapling. To assess the log server proof size of various schemes, we set , , , , , and , as usually domain can have many certificates, where k is number of domains, n is number of certificates, and m is currently active certificates (though only a fraction of domains have certificates and some log-based schemes do not support multidomain certificate (AKI, ARPKI)). We have considered worst cases where a total number of active certificates and issued certificates are equal.
Certificate Presence Proof. The first graph in the Figure 2 illustrates the certificate presence proof size in bytes. The proof cost in proposed schemes, AKI, ARPKI, and DTKI is and is independent of the number of certificates, so they have constant proof size. In CT and Policert, the authentication path size grows with the increase in the number of certificates while in ATCM, AKI, ARPKI, and DTKI path size expands with an increase in the number of the domains. Among all schemes, Policert has the highest certificate presence cost due to sending extra data for policy presence on log server which costs dlogn, where d is the depth of policy tree. However, AKI and ARPKI do not support multiple domain certificate which is a major limitation (a domain can have many certificates).
Certificate Absence Proof. Figure 3 compares certificate absence proof of log-based schemes. Again our proposed scheme has a constant cost of 64 bytes, as the nonmembership witness size is 64 bytes. CT and DTKI send data for proving an absence of a certificate. AKI and ARPKI require hashes, while Policert needs nodes to prove an absence of a certificate. Anew, our framework takes advantage of accumulation tree constant cost and outstanding among all PKI schemes.
Log Tree Extension Proof. The proof that the current tree is an extension of the previous tree needs hash for all schemes except AKI, ARPKI, and Policert which cannot provide such proof due to the lexicographical structure of log tree. Figure 4 gives an overview of the cost of extension proof.
Currency Proof. Figure 5 depicts the currency cost of various schemes. The ATCM has a constant and smallest proof size that is equal to the size of membership witness in X , which is 32 bytes. The size of authentication path of a tree used in AKI, ARPKI, and DTKI is ; Policert has again cost and more expensive. However, CT log tree has no such utility to provide currency proof.
7.2. Theoretical Comparison
In Table 3 we have several parameters like certificates, audit log properties, security, deployability, and efficiency to compare the log-based public-key protocols. For the first parameter certificates, no approach accept the self-signed certificate, and all have built-in support for certificate revocation except CT.
In audit log properties, the proof of the presence of certificate in the log can be provided by all infrastructure. All schemes can give proof of the absence of certificate and proof of currency of log tree except CT, while AKI, ARPKI, and Policert are not capable of providing the proof of extension of log tree from the previous version.
In considering security as parameters for comparison, all infrastructure can prevent man-in-the-middle attack except CT. CT has no mechanism to handle such attacks as it was proposed to detect CA misbehavior. Similarly, the scale of compromising trusted entities for man-in-the-middle attack is low for CT and DTKI. Compromising only log server is enough to launch an attack against them, while AKI and Policet require compromising both. ATCM and ARPKI require all trusted entities to be compromised. Only ARPKI, DTKI, and ATCM protocol provide formal security proof for verification of their security properties. The CT and DTKI have no mechanism to handle when domain losses its private key, as DTKI supposes that domain key can never be compromised. Likewise, DTKI did not preserve client connection privacy, since client must contact log server before connecting to a domain. Hence, the log server has information about client connection so violating client privacy. Similarly, all schemes supposed that root CA signs their certificate directly and did not consider certificate hierarchy (intermediate CA) except ATCM, which can also handle intermediate CAs certificates. Only ATCM can revoke CA certificate without causing massive and collateral damage.
We also take into account deployability evaluate and compare the log-based public-key protocols. All protocols require client-side-changes as well as server-side-changes except CT and DTKI. At last, we also investigate efficiency. In TLS connection setup, all protocols require sending extra data in kilobytes except CT which has overhead in bytes. Similarly, end-user additional actions are needed in DTKI for connection setup. Moreover, DTKI also introduces extra latency in connection setup.
8. Discussion
CAs in ATCM. Certificate authorities in ATCM are different than the CAs in current CA model as the trust in an individual is gallantly reduced in ATCM and are made strongly accountable to the public. Moreover, the LS operations are publicly visible and verifiable and that compelled and spurious certificates can be fast and easily detected.
Detection and prevention of successful MitM. ATCM provides strong security by preventing impersonation attack when at least one party is not colluding. However, in case all the parties start conspiring, then ATCM cannot defend clients from impersonation attack. ATCM can be extended to support the prevention and detection of such a powerful attacker using the two techniques outlined below.
Reactive approach. To detect the devious LS version attack, Gossip protocol is proposed [71], where clients randomly share signed root information about the LS with servers. This protocol enables clients to exchange information in a lightweight way and guarantee that they are viewing the same version of LS. Gossip protocol does not need extra infrastructure nor a dedicated connection as the messages are piggybacked over the original requests and responses. The only condition is some amount of servers and clients gossip. This approach can be directly applied to ATCM, making the detection of devious LS more robust.
Proactive approach. As Gossip protocol can detect the devious LS for misconduct but cannot prevent the clients from sustained MitM attacks; even the attack will remain undetected if the adversary controls victim’s Internet access. To prevent clients from sustained MitM attacks, CoSi, a witness cosigning can used [72], which removes the need for Gossip protocol by guaranteeing that every certificate is witnessed and validated by a group of diverse witnesses before any client accepts it. This protocol protects clients against MitM attacks even if the adversary controls target’s Internet access. This approach can be directly applied to ATCM, defending clients against sustained MitM attacks. However, this protocol will introduce latency and communication overhead.
9. Conclusion and Future Work
In this work, we presented Accountable and Transparent TLS Certificate Management: an alternate Public-Key Infrastructure (PKI) with verifiable trusted parties (ATCM), a new PKI which improves the security of current TLS PKI. ATCM provides high security so that it can prevent a MitM attack when only one entity out of all entities is entrusted. Even if all trusted parties involved in ATCM got compromised, in which circumstances MitM attack cannot be prevented, the other CAs or auditor may still get proof that of the compromise and can perform some countermeasure, even though MitM attack cannot be averted when all trusted parties get compromised but are at least apparent and visible.
The current certificate revocation system of all the log-based protocols is inefficient and has many problems. In ATCM protocol, we introduce a new revocation system, which removes several drawbacks of the current log-based system. ATCM has an improved domain policy, which adds a new and enhanced revocation policy so that CAs certificate can be revoked without causing collateral damage. This improved revocation system makes certificate revocation transparent and narrows the window of fake certificates to limit the range of attacks. Moreover, ATCM has a solution for intermediate CAs discovery and certificates chain validation and verification. Additionally, ATCM can handle certificate registration, certificate validation and verification, and certificate revocation in an apparent and transparent way.
To evaluate the performance and feasibility of ATCM, we have computed computational cost and communication overhead. The performance results and evaluation show that ATCM is feasible for practical use. Moreover, we have performed formal verification of ATCM protocol to verify its core security properties using Tamarin Prover. The formal verification shows that ATCM provides strong security against attacks.
In future, we plan to perform some experiments on industry adoption and interoperability with current TLS ecosystem. We also plan to improve MCP by exploring other additional parameters and study the impact of the parameters on the security and performance of the proposed protocol.
Data Availability
The supporting data and results generated during the current study are available from the corresponding author on reasonable request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work is partially supported by China National Key Research and Development Program no. 2016YFB0800301 and National Natural Science Foundation of China “NSFC” no. 61300177.