Keywords

1 Introduction

Within a typical PKI (Public Key Infrastructure) deployment, digital certificates were used to prove the identity of clients and servers by using a tertiary entity known as a Certification Authority (CA).

An entity X that wanted to have a certificate issued for its identity would generate a PKI cryptographic key pair (private key and public key) and a Certificate Signing Request (CSR) using its own identification data bonded to the public-key. In order to obtain a valid signed certificate, this entity would contact a CA and request certification (usually for a fee). The CA would analyze this request, perform a validation on the requesting entity’s data, and after the fee is paid, a certificate would be issued. This certificate contains the binding of the CA’s digital signature with the CSR resulting in a final certificate. The entity would use the certificate throughout the certificate’s validity period. After the certificate expires, entity X can apply for recertification by applying for a certificate renewal. If there are no validation or identity proofing problems, the issuing CA reissues a new certificate for the same entity. At any given time, if the entity requests a certificate revocation or the CA finds out that the entity is not eligible for certification (in case of major problems or frauds), the CA can revoke the entity’s certificate.

The procedure described above is known as the Standard or Traditional PKI. This form of traditional PKI gives a certain amount of control to the Certification Authorities and assumes that these CAs are honest and do not cheat. However, history shows us that there have been successful attacks on CAs and certificates were issued by fraud.

Another type of issue which we consider a problem is the multiple level trust. We believe that trust exists fully, not partially. Currently, there are multiple main levels of trust: DV (domain validation), OV (organization validation) and EV (extended validation). We believe that having a single type of trust eliminates the need for multiple-level trust mechanisms and helps to avoid confusion regarding trust.

This paper presents a theoretical proof-of-concept and is organized as follows:

In Sect. 2 we briefly discuss about the main components of the PKI ecosystem. Section 3 summarizes the current problems of trust regarding Certificate Authorities. Section 4 argues the problem of multiple-type validations. Section 5 proposes a novel concept called BlockCACert for automatic deployment of X.509 digital certificates and Sect. 6 analyzes a challenging and disruptive approach by which the CA uses ring signatures mechanism in the signing process of the request before publishing the certificate to the blockchain. We conclude the paper with our view regarding the positive impact of our concept on the world of digital certificates.

2 PKI Ecosystem

2.1 Digital Signatures and Digital Certificates

Digital Signatures are small pieces of data that contain authentication information which can be verified using a public key. Digital signatures are used to prove that a message or content belongs to a person or an entity. A digital signature, if implemented properly, is much more secure than a standard hand-written signature and harder to falsify. Of course, the private key used to generate the signature must not be compromised.

Digital Certificates are also known as Public-key certificates, or standard X.509 type documents (the standard which denotes the family of certificates). A digital certificate associates a digital signature to a public key with an identity. The certificate is used to verify if a public key belongs to an entity.

In a general PKI platform, the digital signature from within the digital certificate belongs to the Certification Authority (CA). Regardless of the nature of the digital signature used, the signature proves that the signer trusts the fact that the public key belongs to the certificate owner (information extracted from within the certificate).

2.2 Public PKI Systems

When we talk about the management of digital certificates or about public or private PKI systems, basically we talk about the processes that take place at the Certification Authority. The CA acts like a third party, which is trusted by all the other communicating parties. The CA certifies that at least one of the communicating parties is genuine and is authorized to execute secure communications in its name.

A typical illustration of a traditional public PKI systems along with the respective workflow are detailed in Fig. 1:

Fig. 1.
figure 1

A typical PKI CA workflow

Full size image

  • Step 1: Entity X generates it’s keypairs (private and public keys).

  • Step 2: Entity X creates a CSR binding its public key with its own information.

  • Step 3: Entity X contacts CA A and proves its identity to the CA. (After paying the certification fee,) The CA signs the CSR with its own private key producing a Certificate (CRT) which is given to Entity X.

  • Step 4: Entity X gives the certificate to any communicating partner. When entity Y wishes to authenticate Entity X, it validates the certificate against its CA stored public keys. Using the public keys, entity Y can verify the signature of the CA “A” applied to Entity X’s certificate.

  • Step 5: After authentication is performed, secure communication may now commence.

This scenario, however, introduces some security risks which are described later in this paper.

3 Current Problems of Certificate Authorities

CA-based PKI contains numerous single points-of-failure. The centralized trust model of CA-based PKI means that the security of the system is based on single points-of-failure: CAs. Also, the structure of an X509 certificate may rely on a single root certificate for validation. If the Root CA in the chain is compromised, it can compromise the entire chain of trust [4].

There are online services, like Google’s Certificate Transparency Project [8] which tries to detect rogue or forged CAs and their certificates. While Certificate Transparency (CT) acts similar to a blockchain, by providing a public logging of digital certificates information, using the blockchain for PKI offers an alternative solution to storing certificates securely and detecting any possible fraudulent activity.

Opsmate Inc. aggregates a list of Certificate Authority failures, in which false CAs or certificates were involved and other attacks which were performed against the PKI system, because of negligence or distrustful practices of CAs [9]. As the list points out, a CA can suffer from both technical and practice habits problems. While we believe that the technical problems can arise like any other computer software bug, they can also be fixed and a CA cannot be held liable for this if it implemented software guidelines correctly. We can only hope that improved technology, best practices and further regulations in this industry are developed, to try to secure and align CAs to the best practices, highest security and high-quality service grid.

4 Current Shortcomings of Different Validation Types

All X.509 certificates, while having a similar structure and purpose, they differ in the type of validation used to issue them. Any certificate that is issued to a requesting entity is issued by a Certification Authority (CA) after the CA performs some form of validation to ensure that the requesting party proves its identity and its authorization to use the certificate.

In the PKI Digital Certification industry there are multiple types of validations:

  • DV – Domain Validation

  • OV – Organization Validation

  • EV – Extended Validation

Below we present a summary of these validation types:

4.1 Domain Validation (DV)

DV certificates are the most common type of SSL certificates. They are verified using only the domain name as element of verification. Informally the workflow is as follows: the entity that requests a DV certificate sends the request to the CA. The CA then passes on a Challenge of HTTP or DNS type which the client must resolve. After the challenge is resolved and proof of domain control is validated, the certificate can be issued [10].

4.2 Organization Validation (OV)

OV certificates require more validation than DV ones but provide more trust. For this type of certificates, the CA verifies the actual entity or organization that wants to get a certificate. OVs are used by corporations, governments and other entities that want to provide the extra layer of identity information, alongside the technical domain element. OV is also used for code signing, document signing, or client authentication [10].

4.3 Extended Validation (EV)

It is said that EV certificates provide the maximum amount of trust because of the extra verifications being performed, even more than in the case of OV certificates.

The guidelines for issuing EV-type certificates were laid down by the CA/Browser Forum [10] and extra documentation must be provided to issue an EV certificate. As with OV, the EV lists the company/organization name in the certificate itself. EV certificates are the only type of certificates which cannot be locally issued (by creating a local-owend home CA), because it is said that modern browsers hardcode the IDs of the CAs which are authorized to issue EV certificates. While these types of validations offer different grades of trust, obviously for different fees, we believe that real trust must be expressed by a single type of validation, similar to an OV-type validation.

We believe that OV-type validation has enough fields to assure anyone of who the domain/CN is and who operates this certificate (O & OU fields). But, in our opinion, that EV-type validation is nothing more than an extension to OV-type validation, which used to turn the web-browser bar to green color or offer a special marker indicating an EV-type validation – the “O” (Organization) filed is sufficient to denote who is the owner of the certificate in question. A single type of validation is sufficient to ensure trust in a resource (Certificate – “CN” field) ownerd by a Person or an Orgzanization (Certificate - “O” field) [10].

5 BlockCACert Concept

We can use blockchain, as a public ledger, to register any kind of PKI operations, like issuing new certificates, renewing existing certificates or revoking certificates. Our new concept combines the blockchain public ledgering technology with the traditional PKI concept, adding the ring signatures component.

The BlockCACert concept only uses Blockchain technology for securely storing the digital certificates. It does not operate like a cryptocoin’s blockchain, hence there is no proof of work involved. There are no miners involved and the transaction is processed automatically without anyone receiving a reward or a monetary value (as opposed to Bitcoin or other cryptocoins).

Implementation details about how BlockCACert is built, how the agents join/leave the system or the protocols involved are not part of the BlockCACert concept.

5.1 Blockchain Technology Basics

Blockchain [2, 3] is an innovative technology which aims to provide a secure, anonymous, based on consensus and decentralized public-ledger solution for transactions between users, without a central authority overseeing any of the transactions and without the possibility of linking the users to their actual identities. Blockchain was created with the concept of security and anonimity in mind [1, 4].

The non-financial aspect of blockchain technology relies in the mechanism used to operate the blockchain. On the blockchain, an easy verification can be made to verify the chain of ownership (Fig. 2).

Fig. 2.
figure 2

Original blockchain verification scheme (Bitcoin) [2]

Full size image

5.2 Indexes Used by BlockCACert in the Concept Demonstration

C – Client (person, company, institution, etc.);

B – Multilayer Blockchain;

Be – Blockchain → Entities’ Layer;

Bc – Blockchain → Certificates’ Layer;

CAx – Certificate Authorities;

Kpriv – Private Key;

Kpub – Public Key;

CSR – Certificate Signing Request;

CSRm – Modified Certificate Signing Request (modified standard CSR header);

CRT – Final (signed) Digital Certificate;

ACode – Secret Authorization Code;

EACode – Encrypted Secret Authorization Code;

KprivCAx – CAx’s Private Key.

KpubCAx – CAx’s Public Key.

5.3 PKI Component

BlockCACert concept uses the traditional PKI and X.509 standards for issuing, administering and revoking certificates. The only modification of BlockCACert in the PKI area is the introduction of a new type of CSR: CSRm.

The CSRm is the same as a regular CSR, except it contains one field that does the linking between the PKI and the blockchain: The Client Secret Authorization Code (ACode).

5.4 Blockchain Structure Component

Starting from the observation made by Axon in [5] and Axon and Goldsmith in [6], who consider the suitability of a blockchain-based PKI for contexts in which PKI is required, but in which linking of identity with public key is undesirable, our novel concept uses the blockchain technology only for its properties as an unmodifiable public ledger, where no financial elements are present in this implementation. Moreover, according to [7] privacy is very often neglected in most state-of-the-art blockchain-based PKI implementations, topic that we also followed in the process of designing our solution.

Our blockchain architecture does not use proof-of-* concepts and neither does reward users for transactions with some cryptocoins, like the traditional application of blockchain technologies. Our version of blockchain has an abstract multi-layer concept. Technically, there are no multiple layers, as every block comes one after the other. But, semantically, there are 2 layers of blocks: the Entity layer (Be) and the Certificate Layer (Bc).

The Entity Layer stores the blocks regarding to new and retired entities (persons, companies, institutions, and so on.). The Certificate Layer stores the blocks regarding to certificate operations: issuance, revocation, renewals, etc.

The following figure summarizes our blockchain structure (Fig. 3):

Fig. 3.
figure 3

BlockCACert – the multi-layer blockchain structure

Full size image

Legend:

  1. 1.

    – Genesis

  2. 2.

    – P.Hash; ID1; Type1

  3. 3.

    – P.Hash; ID2; Type1

  4. 4.

    – P.Hash; ID3; Type2

  5. 5.

    – P.Hash; ID4; Type2

  6. 6.

    – P.Hash; ID5; Type1

  7. 7.

    – P.Hash; ID6; Type2

The contents of the Entity Layer: (Be) (Table 1):

Table 1. Entity layer fields
Full size table

The contents of the Certificates Layer (Bc) (Table 2):

Table 2. Certificate layer fields
Full size table

The number of bytes per each field is subject to open discussion, remaining to be established by each implementing entity. There are no fix limits on how much space should the blockchain header occupy. This is a theoretical concept and implementation data may vary based on specific implementation.

5.5 Workflow of PKI-Blockchain Transactions

Let’s assume we have a client C which registers on the blockchain as an entity. This entity can be a real person, a company, an institution, and so on. The method by which the client C registers on the blockchain is beyond of this paper’s scope. Ideally, it can register on the blockchain via an official authority, via a registering company, etc.

Technically, when registering on the blockchain, C registers on the Entities’ Layer, by creating a new block with the following elements:

  • (the checksum of the previous block)

  • New Block ID

  • Block Type: 1

  • Registration date (YYYY-MM-DD format)

  • Country

  • City

  • Organization (O)

  • Organization Unit (OU)

  • Common Name (CN)

  • Secret Authentication Code

  • Notes

After the registration, C gets a Secret Authentication Code which defined the respective C as being unique and authorizes C to perform blockchain-based PKI operations.

We define the code as follows:

$$ ACode\left( C \right){{ }} = {{ }}Hash\left( {CN + date\left( {^{{{\prime \prime }}} U^{{{\prime \prime }}} } \right)} \right); $$
(1)

where,

ACode(C) = The Secret Authorization Code of Client C;

Hash() = A cryptographic hash function like SHA*;

CN = X.509 Standard’s Common Name field.

date(“U”) = a pseudo-code representation of the current date and time, in standard Unix epoch format.

When C decides that it wants to begin cryptographic operations, C will generate its CSR via traditional PKI method:

  • It generates its Kpriv

  • It generates its CSR (which contains the Kpub) with the following fields, actually generating a CSRm:

  • Country

  • State

  • Cirty

  • (Organization)

  • OU (Organization Unit)

  • CN (Client Name or Server URL)

  • EACode – this is the new field in the CSRm format;

The following formula describes the EACode field:

$$ EACode\left( C \right) \, = \, ENCRYPT\left( {ACode\left( C \right), \, K_{pub} CA_{x} } \right); $$
(2)

As the formula describes, before inserting the ACode into the EACode field, this code must be encrypted with the Public Key of the Certificate Authority which is going to be contacted in order to perform the certification operation. This encryption assures that no one can steal the client’s secret authorization code and only the respective CA can decrypt it using its private key. Modifying the standard CSR to include an encrypted authorization code yields a new CSR fomat: CSRm (CSR modified). The following formula describes the new CSRm format:

$$ CSRm \, = \, CSR \, + \, ACode \, Field; $$
(3)

  • After generating the CSRm, C contacts an arbitrary CA (CAx) and applies for a new certificate by supplying some registration data and the CSRm.

  • CAx decrypts the EACode using its KprivCA:

    $$ ACode\left( C \right) \, = \, DECRYPT\left( {EACode\left( C \right), \, K_{priv} CA_{x} } \right); $$
    (4)

  • The CA contacts the blockchain (B) and begins validating the data against the Decrypted Authorization Code found in the Entity’s Layer of the blockchain (Be) and supplied in the CSRm (Table 3);

    Table 3. Registered vs. supplied fields comparison table
    Full size table

  • The condition for data matching is an AND-ing operation which verifies the matching of the values:

    $$ \begin{aligned} & Field1\left( {B_{e} } \right) \, AND \, Field1\left( {CSR_{m} } \right) \, = \, 1; \\ & Field2\left( {B_{e} } \right)ANDField2\left( {CSR_{m} } \right) \, = \, 1; \\ & Field3\left( {B_{e} } \right)ANDField3\left( {CSR_{m} } \right) \, = \, 1; \\ & Field4\left( {B_{e} } \right)ANDField4\left( {CSR_{m} } \right); \, = \, 1; \\ & Field5\left( {B_{e} } \right)ANDField5\left( {CSR_{m} } \right) \, = \, 1; \\ & Field6\left( {B_{e} } \right)ANDField6\left( {CSR_{m} } \right) \, = \, 1; \\ & Field7\left( {B_{e} } \right)ANDField7\left( {CSR_{m} } \right) \, = \, 1; \\ \end{aligned} $$
    (5)

  • If all the fields match, then the client is validated.

  • If, at least one of the fields do not match, the client is invalidated and the transaction is rejected.

  • When CAx validates C on Be, it proceeds to sign the CSRm with the KprivCAx, using the ring signatures scheme described below resulting a final signed digital certificate belonging to the C:

    $$ CRT \, \left( C \right) \, = \, CASIGN\left[ {RINGS} \right]\left( {CSRm\left( C \right), \, K_{priv} CA_{x} } \right);) $$
    (6)

  • This certificate is issued to the client and is registered on the blockchain (B) as a new transaction on the Bc Layer, by creating a new block with the following elements:

    • (the checksum of the previous block)

    • New Block ID

    • Block Type: 2 (certificate block)

    • Registration date (YYYY-MM-DD format)

    • Common Name (CN)

    • Validity

    • Encoded X.509 Certificate (DER/PEM Format)

    • Notes

Anyone wishing to verity the certificate, can do it by the following means:

  • Traditionally, via PKI tools: checking the Signature of the CA within the CRT against a Certificate Root Store;

  • Interogating the blockchain (BC of B) by querying the validity of the certificate or the act of certification from CAx who digitally signed the CSRm with its KprivCAx.

6 Ring Signatures in BlockCACert

A ring signature is a type of digital signature that allows any member of a group of users (ring) to sign a message with its own key in an anonymous way. Within the process, no one, but except actual signer, knows which member signed the message - this means it is computationally infeasible to determine which of the group members’ keys was used to produce the digital signature. Ring signatures must satisfy two independent notions of security: anonymity and unforgeability.

The notion of ring signature was formalized by Rivest, Shamir and Tauman in [11]. In contrast to group signatures, the authors designed a signature scheme with no managers involved, and which do not require any central coordinator, setup and revocation procedures. Moreover, according to authors, there is no way to distribute specialized keys and to revoke the anonymity of the actual signer, and there are no prearranged groups of users.

A ring signature scheme is defined by two procedures [11]:

  • ring-sign(m, P1, P2,…,Pn, s, Ss) – produces a ring signature σ for the message m, where P1, P2,…,Pn are the public keys of the n ring members, Ss is the secret key of the s-th member, who is the actual signer.

  • ring-verify(m, σ) – takes a message m and a signature σ (which includes the public keys of all the possible signers), and outputs either true or false.

Ring Signatures is fundamental concept used in the CryptoNote/Monero cryptocurrency [13, 14].

In order to preserve the privacy between BlockCACert layer’s communication, we propose a formal ring signature mechanism starting from the functional definition of a ring signature presented by Bender, Katz, Morselli in [12]:

  • key generation: Gen(1k), where k is a security parameter, outputs a public key PK and secret key SK. Entity layer (Be) is responsible for key generation. The keys are not included into the block structure, but each block has an associated pair of keys, which can be changed/regenerated at any given time (due to length restrictions, we are unable to detail the way the keys are regenerated and relinked to the blocks).

  • message signature: Signs,SK(M, R) outputs a signature σ on the message M with respect to the ring R = (PK1,..., PKs), where (R[s], SK) is a valid key-pair output by Gen. Here it is important to note that in the signing process we have the secret keys associated with the blocks chained to the current block s at which the signature is applied.

  • signature verification: VrfyR(M, σ) verifies a signature σ on a message M with respect to the ring of public keys R. The verification process takes place only at the Certificate Layer (Bc). If the signature verification fails, that block at the Certificate Layer does not perform any additional analysis to check if a new public key has appeared in the blockchain – the method, although it seems quite rigid, solves quickly two issues: double spending prevention and no more computational resources.

Regarding the implementation details of our proposed ring signature mechanism, one of the viable options would be to define a third layer for BlockCACert architecture, where the entire key management mechanism is modularized and integrated.

7 Conclusions

BlockCACert tries to improve the management of digital certificates by using blockchain technology as a proven security mechanism for CAs trustworthiness. This ensures that no fraudulent certificates can be issued, or even if, somehow, these certificates are issued, the fraud is immediately detectable on the blockchain.

This scheme eliminates the need for multiple types of validation. By using non-modifiable blockchain records, we can ensure that every entity who requests a certificate has a name, and some identification information, thus eliminating the need for multi-level trust. Our solution also introduces a degree of automatic deployment, to ease the task of authentication. As a future direction of research, we will investigate integration of BlockCACert with the privacy data storage protocol proposed in [15], that is based on the ring signature on the elliptic curve.

This concept was implemented in one of our labs, on 10 computers, and the results we got confirmed the desired workings of our concept. There are no numerical results, as this theoretical concept only proves that the workflow of storing digital certificates on blockchains works efficiently when implemented properly.