1. Introduction
Since its inception [
1], the public key infrastructure (PKI) model has struggled with several challenges derived from the difficulties of managing private keys. Certificate revocation mechanisms are used to handle cases where a private key has been deemed unfit to sign any further messages. However, before a certificate can be revoked, it is imperative that the compromise is detected. Typically, due to the increased security of root and intermediate certification authorities (CAs), they are assumed to be secure enough such that this monitoring is unnecessary. Final CAs, those that issue end-user certificates, are known to be more easily compromised [
2]. Hence, there exists a need to monitor certificate issuance by final CAs.
Systems that deal with the monitoring of issued certificates are usually named after the well-known Certificate Transparency (CT) protocol [
3]. In this protocol, CAs submit “pre-certificates” to CT loggers, which respond with signed CT timestamps, acting as a promise that these certificates will be logged. Typically, logs are built as a Merkle tree and reconstructed with new certificates after some specified period; CAs typically embed these timestamps in the issued certificates as X.509 extensions. Systems that require CT timestamps only verify their respective signatures, while monitors and auditors check log integrity. Still, the addition of extra signatures can lead to certificate bloat, harming the efficiency of TLS protocols, depending on the signature algorithms chosen by loggers.
While CT manages to monitor the issuance of TLS certificates with some degree of success, adapting it to track end-user documents would require extensive changes in document signature generation processes, requiring end users to log every created signature by themselves. A widespread PKI environment is expected to have laypeople as the largest portion of its user base and cannot rely on the assumption that non-technical certificate holders would follow the required steps to register signed documents. Imposing extra steps in the creation of digitally signed documents ultimately hurts usability and restrains adoption. Therefore, we argue that any proposal based on the CT framework must be transparent to the end user.
Furthermore, the addition of multiple extra signatures on the certificate must be addressed when future proofing any CT-like protocol. For instance, with the advent of quantum computing, classic signature algorithms such as RSA and ECDSA are fated to be replaced. Active research is being conducted on quantum-resistant cryptographic algorithms. However, the consequences of quantum resistance are an increase in the public key and signature sizes [
4], which greatly affect CT artifacts. Hash-based signatures are an example of quantum-resistant schemes with small public keys and signature sizes [
5], which are desirable properties when considering storage requirements.
Hash-based signatures rely exclusively on the pre-image resistance of its component cryptographic hash function and provide a framework to construct one-time signature schemes (OTSs) [
6]. It is strongly recommended that key pairs from OTS schemes are used to generate a single signature since it is derived directly from a private key. In the context of a PKI framework, this implies that a private key need not be stored after being used once. Thus, we argue that OTS schemes are an important asset in solving private key management issues, relieving the end user from holding sensitive information and consequently improving usability. This security restriction is monitored via a CT-like framework to assert that documents are not signed with the same private key.
Contributions. We propose an augmentation to the traditional PKI model, which consists of logging end-user certificates and hashes associated with digitally signed documents in a blockchain. Any logging must be made by CAs to relieve laypeople of such responsibilities, increasing the usability of end-user certificate holders. As a consequence, our model requires a binding between certificate issuance and documents, i.e., a digital certificate unique to each digitally signed file. This is performed via the creation of new key pairs for each signed document or simply through the use of OTS schemes. Such bindings are then registered as transactions in the blockchain.
We achieve the effective monitoring of digital certificate issuance and creation of digitally signed documents, detecting possible malfeasance from CAs and/or the compromise of user credentials, and preventing the backdating of digital signatures. Additionally, our strategy is quantum-resistant, considering a suitable choice of signature schemes throughout the CAs, end users and blockchain networks. The distributed ledger technique prevents effective private key reuse, solving the largest practical restriction of an OTS scheme. We discuss the privacy and security implications of our proposal, present public and private blockchain models as alternative implementations, and analyze the storage and performance requirements considering a realistic PKI scenario.
Related work. Blockchain implementations of the CT protocol have been proposed with some improvements. Madala et al. [
7] introduce an implementation of CT, where CAs must receive consent from the domain owner before a certificate can be issued. Their implementation is able to revoke certificates in the blockchain. In a similar manner, BB-PKI [
8] requires that registration authorities (RAs) reach a consensus on the issuance of a certificate, which is then signed by multiple CAs through an out-of-band channel to lower the chances of successful impersonation attacks against RAs.
Blockchain-based PKIs have been proposed as an alternative to the traditional model. In these proposals, CT is assumed, as most PKI artifacts are committed to the blockchain as part of the process of issuing certificates. However, most proposals simply replicate the same procedures of a traditional PKI, opting to simply log its operations without much disruption to the usual procedures. However, some proposals create conditions for the issuance of digital certificates. Kubilay et al. [
9] require that a consensus be reached through a dynamic threshold signature scheme before a certificate is issued. Another PKI implementation that aims to block certificate misissuance before it happens through the blockchain is the Pistis [
10] framework. In this framework, certificate issuance is performed through the blockchain only when domain ownership is verified.
Some proposals include misissuance prevention as a feature of signature verification applications. In other words, verifiers can set conditions for when a signature can be deemed valid. For instance, Han and Hwang [
11] introduced a trust model dubbed “conditional trust”. Certificates with many trusted signatures are seen as more trustworthy than those with fewer signatures. This proposal utilizes the blockchain to communicate among many CAs and RAs. However, an important observation of models that embed many signatures in a certificate is that it may grow indefinitely with time.
The intersection of blockchain and OTS limits itself to using such schemes to improve aspects of blockchain as a replacement for classical digital signature algorithms. Most works set hash-based algorithms as the de facto OTS scheme. Vives [
12] improves efficiency by replacing ECDSA signatures with a single hash-based signature to enable post-quantum authentication in the blockchain. Hyla and Pejaś [
13] show how blockchains can create a beneficial environment to the archiving of digital documents by acting as a timestamp. They propose the usage of XMSS to increase blockchain longevity in the post-quantum scenario.
The Key Compromise Resilient Signature [
14] (KCRS) system includes the end-user signature in the list of PKI artifacts that it logs in the blockchain. In this scheme, users have multiple key pairs, a master key pair certified by a digital certificate, and multiple “signing key pairs”. The user derives the signing key pairs from the master key to sign symmetric key-encrypted messages sent through an out-of-band secure channel by the verifier and log the resulting signature in the blockchain. Thus, only the verifier and the signer know that the end user has generated a signature. This scheme loses the monitoring qualities of CT by weakening the link between the user and the asymmetric key pair.
To the best of our knowledge, there are no published works that deal with the private key reuse of OTS schemes by limiting the number of signed documents that can be validated. We note that most proposals draw heavily from the CT protocol and consequently focus on the perspective of TLS certificates. Research on the impact of post-quantum algorithms, certificate logging and monitoring, and usability for the signing of digital documents by laypeople is severely lacking.
3. The OTSchain Framework
To solve the issue of effectively monitoring digitally signed electronic documents and, consequently, key pair usage, we propose a blockchain-based strategy where final CAs share a distributed ledger of issued digital certificates and message hashes. In our strategy, multiple compliant PKI infrastructures contribute to the same blockchain network since users may have one or more digital certificates issued by unrelated CAs. To improve the authenticity and non-repudiation of transactions, we propose to identify CAs in the network with the same key pair they use to issue digital certificates. As a result, CAs can read and write data on the blockchain. When reading data, CAs and other interested parties, such as end users and signature validation applications (SVAs), act as monitors. To properly validate a signed document, our strategy requires a connection to the blockchain in addition to the usual access to certificate chains and revocation data by the SVA.
We require the use of one-time signature schemes in our framework to improve usability for end users such that private keys need not be stored after the first document is signed. Additionally, we are able to prevent effective repeated OTS private key usage via blockchain semantic validation, addressing the main constraint of such schemes. A direct consequence of our restriction is the higher load for PKIs, particularly in the certificate issuance and the key generation step. We argue that hash-based OTS schemes have efficient key generation when considering sufficient and available entropy, compared to classic methods and even other quantum-resistant alternatives; only random bits are needed, with no additional constraints imposed [
24].
Certificates used in the context of the CT protocol may include a certificate extension of the signed timestamp response from the CT logs. Analogously, the usage of OTSchain may also be identified by the presence of an extension embedded into the certificate. While generates unwanted certificate bloat, as it contains one or more digital signatures, may hold a short list of ledger URIs, or it can be empty when such information is already known via out-of-band mechanisms. Therefore, we are able to minimize the overhead caused by CT-like proposals while maintaining the desired properties.
Any legislation that recognizes advanced signatures similarly to the European standard ETSI EN 319 102-1 [
18] is able to use this proposal without any changes to their regulations. That is, advanced and qualified signatures and derived requirements are agreed upon by all parties involved in processing digitally signed documents. Notably, the Brazilian civil registry PKI allows the use of any certificate extension, and is currently using a proof-of-concept version of
OTSchain within their existing legal frameworks.
We define the entities and data that belong to the protocol for any
. The actors are a certification authority
, an end-user
, and a CT-like monitor
. Data inserted in the blockchain are denoted as follows: a message hash
to be signed by
, a digital certificate
carrying a set of attributes
, owned by
and issued by
, and a tuple
linking certificate and message hash. Finally, we define the blockchain elements: an asset
carrying a tuple
, a transaction payload
encoding
, the signed payload
, a transaction request
, a transaction output
(or
), a transaction
, and a block
containing
. The flowchart in
Figure 1 depicts the interactions among these entities.
In the context of the blockchain network roles, we propose a network, where every PKI can maintain a copy of the blockchain. Furthermore, root and intermediate CAs are not required to be part of the network or publish data since our proposal focuses on end-user certificates. However, every final CA is encouraged to maintain a copy of the blockchain and engage in the consensus protocol. SVAs should be nodes in the network as well, as they act as monitors, querying the existence of assets to validate the document corresponding to . Additionally, having a local copy of the blockchain speeds up document validation, which brings further usability to end users.
The left side of
Figure 1 illustrates the general steps toward registering digital certificates in the blockchain. We recall that
is the final CA that issues
. Step
in the flowchart represents the certificate issuance, which does not depend on the active blockchain network. The message hash
is obtained via an out-of-band mechanism, for instance, via the signature creation application. We remark that there are no interventions in the traditional certificate issuance procedures; it is merely depicted for completeness.
The first step of the registry process consists of the generation of an asset representation of the end-user digital certificate and message hash by the CA. Then, is ready to generate a transaction payload in step , encoding the asset, using any format required by the blockchain network. Subsequently, in step of the protocol, signs the transaction payload using its private key, which enables the generation of the transaction request in step . Previous steps execute outside of the blockchain network and culminate in step , which consists of storing the data as a transaction to be consumed in the monitoring process at a later time.
We note that between steps
and
, the transaction proposal must be broadcast by
, so it reaches the other nodes in the network, making the copies cohesive. The consensus protocol by which nodes will agree on the new state of the blockchain depends on the arrangements between nodes. For instance, they may agree on a majority policy, meaning that the data are stored in the blockchain if more than
of the nodes agree on the transaction request. We present a detailed discussion about deployment recommendations and measurements in
Section 4.
Let ℓ be the set of all possible . Step contains the application of a function . Consequently, our framework may be customized to check certain semantic restrictions. Examples of such verifications are (i) how recently the certificate was issued to prevent backdating; (ii) the certificate issuance rules according to the content of , for instance, allowing only certain organizational units to participate in the network; and (iii) restricting node operations, for example, to impose upper bounds on attempts to register certificates by a faulty CA. The transaction fails if f returns a false response, which prevents the insertion of in any block. We opt to register the offending request to improve the detection of malpractice and possible attacks.
In our proposal, f is set to control additional registration of certificates containing a previously logged public key. As previously discussed, we move log information out of the certificate itself to the blockchain. We require compliant SVAs to check the blockchain for the existence of the correct tuple . In this manner, even if an OTS private key is used multiple times, only the registered hash associated with the submitted signed document will be valid under this policy.
After the registering process,
is available to be read by any node with permission, which enables the start of the monitoring process. The right side of
Figure 1 details such procedures. In step
, a monitor
defines a set of attributes
to search. Such attributes are encoded in a transaction payload in step
and digitally signed in step
to create a transaction request in step
, analogous to the register operations. Finally, in step
, the network consults the set
ℓ for a matching
, and returns the suitable asset list to
.
We emphasize that monitors are independent; further external validation by these entities, such as the processing of specific documents, is, by design, out of the scope of our framework. Such behavior is particular to how a monitor operates and which services they offer. Moreover, as we require the registration of every certificate in the blockchain to properly validate a document, monitors are able to detect and warn users of every certificate that has been issued in their name. In other words, whenever an attacker uses a compromised credential, it must inevitably reveal itself by having the resulting certificate registered in the blockchain. Thus, monitors and end users may take appropriate steps to deal with this security breach as soon as possible.
Our strategy is suitable for a wide range of use cases, especially when long-term registry of signed documents is a hard requirement. For instance, consider the issuance of degree certificates by educational institutions, which may be subject to fraud [
25]. In this case, as long as the blockchain network is online, students and other interested parties can validate a degree certificate by checking the registry of the signature on the
OTSchain. Moreover, since our framework ties any digital certificate to a single document, compromised private keys would not allow the issuance of valid degree certificates. Furthermore, through the use of quantum-proof OTS schemes, degrees can be protected from quantum attackers long before they become a real threat.
3.1. Privacy Impact
As our proposal requires the inclusion of entire end-user certificates in a blockchain, we must consider the ramifications of facilitating access to attributes contained in such certificates, considering data protection laws such as the EU GDPR [
26] and the Brazilian LGPD [
27]. We discuss the differences between registering TLS and end-user certificates, the intrinsic trade-offs between privacy and monitoring services, the differences between a public and private blockchain privacy-wise, and how to use
OTSchain when pseudo-anonymity is desired.
Bernabe et al. [
28] proposes eleven privacy-preserving challenges and four general solutions. We highlight “non-erasable data and on-chain data privacy” as the most relevant challenge to our proposal. Since blockchains tend to be immutable databases, the authors claim that even encrypted or hashed data are unsafe in the face of broken cryptographic primitives. That is even more complicated when referring to public blockchains, where data are publicly accessible by virtually anyone.
In this context, some blockchain-based implementations have proposed to store only public data in the blockchain and maintain private counterparts in an external database, such as the InterPlanetary File System (IPFS) [
29]. Moreover, some private blockchain networks present an integrated solution to the problem. For instance, Hyperledger Fabric offers “private collections”, where nodes maintain the public part of the data in the blockchain and the private portion on a local database, where they can control which other nodes in the network may have access.
We remark that there exists a natural trade-off between privacy and transparency in our proposal due to the generation of evidence that shows the intent behind the signing of a document. Thus, if a signed document is contested in court, a robust monitoring system may help to prove that the signature was indeed generated by the original certificate holder. This logging framework can be augmented to include further user data to increase the amount of evidence for the receiver, such as IP addresses and identity provider tokens. However, we note that privacy is decreased with the amount of evidence provided.
Conversely, techniques that are able to obfuscate the data contained in the certificate, such as zero-knowledge proofs [
30], or logging the hash of the certificate instead of itself, are able to improve privacy at the cost of monitoring capabilities. We note, however, that such techniques might damage monitoring to a degree where misissuance can no longer be detected and should be carefully considered before adoption in the context of our proposal.
Ultimately, digital certificates associate a key pair to an entity and thus are seen as public documents in the traditional PKI model. Logging certificates through our proposal facilitates document spread, a desirable property in many PKI implementations. We observe that the link between the entity and signature is made through the digital certificate itself; logging mechanisms only assist in spreading the public certificates. Thus, we argue that a PKI that requires pseudo-anonymity and wishes to incorporate logging and monitoring services should ensure anonymity directly in the certificates. While pseudo-anonymity may harm monitoring effectiveness, multiple uses of the same OTS private key are still prevented. Furthermore, if the pseudonym used in the certificate can be traced back to the user by a trusted party, monitoring is provided on a smaller scale.
PKI architects are free to choose the best way to implement the OTSchain framework according to the particular purposes of the models. Infrastructures that wish to keep end-user information private can opt for a mix of permissioned blockchain and digital certificates with pseudonyms. Alternatively, those that do not wish to or cannot create their private blockchain can utilize pre-established blockchains, such as Ethereum, to increase the spread and monitoring capabilities of their logs. Finally, as data protection regulations vary wildly among countries, there must be considerable care in logging implementation pursuant to local laws.
3.2. Security Benefits
In this section, we discuss how OTSchain facilitates the administration of several scenarios where participants misbehave, helping to detect or outright prevent situations in which the security of a PKI may be compromised. We remark that there are two main incentives for participants to behave in the traditional PKI model. Trustworthy participants have increased financial benefits, as opposed to those who have misbehaved, as the PKI is ultimately built on trust. Additionally, the threat of law action may be imposed by regulators if misbehavior is frequent or severe enough. We list below several situations addressed more effectively by our model compared to a traditional PKI.
CA misbehavior. OTSchain is built on top of the CT framework; consequently, it has the same intrinsic set of benefits as conventional implementations of CT, i.e., the detection of certificate misissuance by CAs. Those that are found to be misbehaving can be, in addition to any legal action, revoked in the traditional sense and, in the case of blockchains, have their write permissions removed from the blockchain network. A CA is deemed malicious if it does not follow the guidelines established by the protocol: (i) it does not register any binding when a signature is generated; or (ii) registers with incorrect information.
We recall that, for a document to be validated using our proposal, a SVA must obtain the tuple containing the link between the message hash and the matching digital certificate. Thus, refusing to register a certificate, logging the wrong certificate, or failing to produce the correct hash all lead to an invalid signed document. We argue that adapting existing SVAs to be pursuant to OTSchain can be done efficiently, as it amounts to querying a blockchain network and performing a small number of additional checks.
Our proposal may also be extended to broader threat models. We consider signature backdating attacks, in which rogue CAs publish signed claims allegedly made in the past but never before disclosed. To address this situation, only a small modification to the function f is necessary: certificates are required to have their issuance time attribute be “close enough” to the logging time. Indeed, this is crucial when protecting classical CAs from quantum attacks in the event that signed artifacts are held until a conventional signature algorithm becomes insecure.
Monitor misbehavior. A third-party rogue monitor may opt to respond to queries about certificates and documents wrongfully, to individually prevent the validation of a document, or to collude with a malicious CA to validate a document that has not been correctly logged in the blockchain. In OTSchain, SVAs are free to either (i) choose a trustworthy monitor, (ii) query multiple monitors to form a consensus, or (iii) become a monitor themselves to ensure the correct response to a query.
End-user private key compromise. A major benefit of our proposal, when compared against traditional CT implementations, is that it includes the tracking of end-user documents in addition to CA actions. Particularly, we are able to detect when end-user credentials are stolen without any input from the certificate holder whatsoever. In this manner, we are able to increase protection to the most exposed and broadest class of entities in a PKI while still preserving usability.