DPKI: Addressing the Disadvantages of Centralized PKI by Means of Blockchain

Digital certificates are one of the most commonly known auxiliary tools that help protect data across public networks. However, the key disadvantage of this technology is also commonly known: users are forced to implicitly trust certification authorities which issue digital certificates. Andrey Chmora, Technology and Innovations Director at ENCRY, suggested a new approach for building a Public Key Infrastructure (PKI) to eliminate the existing disadvantages using the distributed ledger (blockchain) technology.
Let's begin with the basics.

If you already know the basics of the existing public key infrastructure and its key disadvantages, feel free to scroll down to the description of what we suggest to change.

What are digital signatures and digital certificates?

Interactions over the Internet always include data exchange. And thus we all are interested to keep data safe during such exchange. But what is safety? The most popular safety services are confidentiality, integrity, and authenticity. Today, they are based on asymmetric cryptography, which is also called public key cryptography.

First of all, these methods require that the entities of interaction must have two dedicated key pairs: public and private. These key pairs provide the above mentioned safety features.

But how to achieve private exchange of information?

Figure 1. Encrypted data transmission using a public key cryptography

Before sending any data, the sender encrypts (converts cryptographically) the public data using the recipient’s public key, and then the recipient decrypts the encrypted data using the private key pair.

How to achieve integrity and authenticity of the information being sent? This problem can be solved using another mechanism.

Figure 2. Digital signing/verifying

Though public data is not encrypted, it contains a cryptographic hash function value, i.e. encrypted «compressed» image of the input data sequence. The result of such hashing is called a «digest» and is encrypted using the private key of the sender («authenticator»). The result of digest encryption is a digital signature, which is sent to the recipient («verifier») along with the unencrypted text. The recipient decrypts the digital signature using the authenticator's public key and then compares it with cryptographic hash function value which is calculated by the verifier based on the obtained public data. If they match, then the received data is fully authentic, integral and free from any modifications that could possibly be made by attackers.

Most resources which process personal data and payment information (such as banks, insurance companies, air carriers, and payment systems along with the tax service and other government portals) widely use asymmetric cryptography.

How digital certificates can help here? It's quite simple. Both processes include public keys which play a very important role and thus we must always check that they belong to the sender (or to the authenticator when we need to verify a signature) or the recipient rather than to attackers. And this is where digital certificates can help ensure authenticity and integrity of the public key.

Note: Authenticity and integrity of the public key is verified in exactly the same way as for public data, i.e. using the digital signature (DS).

Who issues digital certificates?

Digital certificates are issued and maintained by trusted Certification Authorities (CAs). The entity making the request asks a CA to issue a certificate, registers in the Registration Center (RC) and then receives their certificate in the CA. The CA guarantees that the public key from the certificate belongs to the entity for which it was issued.

If you don't verify the public key authenticity, then attackers will be able to replace the transferred/stored key with their own. Once the key has been replaced, attackers will be able to decrypt everything that the sender transfers to the receiver, or even modify the public data at their discretion.

Digital certificates are always used together with asymmetric cryptography. One of the most popular digital certificates are SSL certificates for secure communications via HTTPS. SSL certificates are issued by hundreds of companies across various jurisdictions. The core market share is distributed among five to ten largest trusted certification authorities: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, and Trustwave.

CAs and RCs are the PKI components which also include:

• Public Dictionary: A public database that provides reliable storage for digital certificates
• List of Revoked Certificates: A public database that provides reliable storage for digital certificates of revoked public keys (e.g. due to compromised private keys)
  Infrastructure entities may access this database on their own or use the specialized Online Certification Status Protocol (OCSP) which simplifies the verification proces.
• Certificate Users: PKI entities that are serviced in accordance with the user agreement with the CA and verify digital signatures and/or encrypt data based on the public key from the certificate
• Subscribers: PKI entities that are serviced by a CA, hold the private key and paired public key from the certificate, and have concluded a subscriber agreement with the CA. A subscriber may also be a user of the certificate.

Thus, trusted entities of the public key infrastructure, including CAs, RCs, and Public Dictionaries, are responsible for:

1. Verification of the entity making the request
2. Profiling of the public key certificate
3. Issue of a public key certificate for an authenticated entity making the request
4. Change of the status of a public key certificate
5. Provision of the information about the current status of a public key certificate.

What are disadvantages of PKI?

The fundamental disadvantage of PKI is reliance on trusted entities. Users are forced to trust CAs and RCs blindly. However, such blind trust is dangerous.

Over the past ten years, infrastructure vulnerability caused several major scandals.

In 2010, the malware Stuxnet signed using stolen digital certificates from RealTek and JMicron began to spread on the Internet.

In 2017, Google accused Symantec of issuing a large number of falsified certificates. At that moment, Symantec was one of the largest CAs by number of issued certificates. Since version 70 of Google Chrome, Google has ceased support for all certificates issued by this company and its affiliates GeoTrust and Thawte before December 1, 2017.

These CAs were compromised and, as a result, the CAs themselves along with users and subscribers were impacted. Moreover, confidence in the infrastructure was impacted. In addition, digital certificates may be banned due to political conflicts and thus impact many resources. This why in 2016 the Russian authorities considered creation of the national certification center to issue SSL certificates for Runet websites. In the current situation, Russian governmental portals use digital certificates issued by the US companies Comodo or Thawte (Symantec's subsidiary).

There is yet another problem: how to authenticate users initially? How to identify an anonymous user who has requested a digital certificate from a CA? Today, it is often made arbitrarily depending on the infrastructure capabilities. Some information is taken from public databases (e.g. about legal entities requesting certificates) or from banks and post offices where individuals can identified by their ID cards and other documents.

Impersonation based on false credentials is one of the fundamental problems. And, unfortunately, no complete solution of this problem may even exist due to informational and theoretical aspects: without reliable information, it's impossible to verify authenticity of an entity. As a rule, the verification process requires a set of documents proving the identity of the entity making the request. Though there are lots of verification methods, none of them can guarantee authenticity of the documents. Thus, authenticity of the entity making the request also cannot be identified for sure.

How to eliminate these disadvantages?

Since current PKI problems are mainly caused by centralization, it's obvious that decentralization may help eliminate at least some of them.

Decentralization doesn't rely upon any trusted entities, since creation of the Decentralized Public Key Infrastructure (DPKI) will make both CAs and RCs needless. Let's reject the digital certificate concept and instead use a distributed ledger to store information about public keys. In our case, a ledger is a linear database consisting of individual records (blocks) and connected using the blockchain technology. Let's replace the term «digital certificate» with the term «notification».

This is how the receipt, verification, and revoking of notifications will look like in the proposed DPKI:

1. Each entity making the request applies for a notification on their own by filling out a registration form, and then composes a transaction which will be stored in a specialized pool.
2. Information about the public key along with the owner’s details and other metadata are stored in a distributed ledger rather than in a digital certificate which is issued by the CA in the centralized PKI.
3. The entity making the request is then authenticated by the joint efforts of the DPKI user community rather than by RC.
4. Only the owner of such notification may change the status of a public key.
5. Everyone may access the distributed ledger and check the current status of the public key.

Note: At first glance, authentication of the entity making the request may seem unreliable. However, it's important to keep in mind that nowadays all users of digital services leave an ever-growing digital footprint. The publicly available tools include digital databases of legal entities, maps, digitalized terrain images, social media, and more. They are already successfully used in investigations by journalists and law enforcement agencies. One of the typical examples include Bellingcat investigations and joint group JIT, which investigates the Malaysian Boeing plane crash.

So, how will a decentralized public key infrastructure work in practice? Let's deep dive into the technology that we've patented in 2018 and consider our best know-how.

Suppose there's an individual who owns a set of public keys, where each key is a sort of transaction stored in a ledger. How to verify that all these keys really belong to a given owner without a CA? To solve this task, we can create a null transaction to store the information about the owner and their e-wallet (from which a commission fee for adding a transaction to the ledger is debited). A null transaction is a sort of «anchor» for hooking up the next transactions along with the data about public keys. Each transaction of this type contains a specialized data structure which is called «notification».

Notification is a structured data set of functional fields that stores information about the owner's public key and guarantees persistence of this key by adding it to one of the related records in the distributed ledger.

The next obvious question is how to form a null transaction? A null transaction, just like all subsequent transactions, is an aggregation of six data fields. To form a null transaction, we use the public/private key pair for the e-wallet. This public/private key pair is created when the user creates their wallet from which the commission fee for adding a null transaction to the ledger and for subsequent operations with notifications will be debited.

Figure 3. Сreating a null transaction

Figure 3 shows how a digest of the e-wallet's public key is formed using the SHA256 hash function and then the RIPEMD160 hash function. Here, RIPEMD160 is responsible for representing data with the digest size up to 160 bits. It's very important, since ledgers are expensive databases. The public key itself is included in the fifth field. The first field contains data that links a given transaction to the previous one. In the null transaction, unlike all other transactions, this field is empty. The second field contains data for verification of the transaction connectivity. For the sake of brevity, we will be referring to data in the first and second fields as «bind» and «verification» respectively.

Figure 4. Transactions binding and verification

Data in these fields can be formed using iterative hashing as shown in the Figure 4 above for binding the second and third transactions.
Data in the first five fields is authenticated with the DS generated using the e-wallet's private key. And that's all — the transaction can now be added to the pool and then, upon successful verification (as shown in Figure 5), to the ledger.

Figure 5. Verification of the null transaction

Now this transaction can be used for «hooking up» the next transactions. Let's take a look at Figure 6 to see how all non-null transactions are formed.

Figure 6. Сreating a non-null transaction

The first thing you may notice is a multitude of public/private key pairs. In addition to the already familiar e-wallet public/private key pair, we also use ordinary and service key pairs.

An ordinary public key is the most important part here. This key is used in various procedures and processes of the surrounding world (such as banking and other transactions, document flow, etc.). For example, a private key from an ordinary public/private key pair can be used for the creation of a DS for various documents, such as payment orders, while the public key can be used for the verification of the DS with subsequent execution of these orders.

A service public/private key pair is issued to a registered DPKI entity. The name of this public/private key pair clearly reflects its purpose. Note that service keys are not used for generation/verification of a null transaction.

Just to be clear, let's refine purposes of these keys:

1. E-wallet keys are used for the generation and/or verification of both null and any non-null transactions. The e-wallet's private key is known only to the e-wallet's owner who also possesses the set of ordinary public keys.
2. The purpose of an ordinary public key is the same as that of the public key for which a certificate in the centralized PKI is issued.
3. The service public/private key pair belongs to the DPKI. A private key is issued for the registered entities and is used for creating a DS of all non-null transactions. A public key is used for the verification of a DS for transactions before adding them to the ledger.

Thus, we have two group of keys. The first group includes service keys and e-wallet keys that are eligible only within the DPKI. The second group includes ordinary keys that can be used for various purposes depending on a given field of application. At the same time, the DPKI ensures integrity and authenticity of ordinary public keys.

Note: The service public/private key pair may be disclosed to various DPKI entities. In certain cases, the pair may be the same for all entities. This is why forming a signature for each non-null transaction requires two private keys, one of which is the e-wallet key: this key is known only to the e-wallet's owner who also possesses the set of ordinary public keys. All these keys have certain purposes. For example, we can always prove that a given transaction was included in the ledger by a registered DPKI entity, since the signature was formed using a service private key as well. In addition, this prevents any DOS attacks and other fraudulent activities, because the owner pays for each transaction.

All transactions that follow a null transaction are formed similarly: a public key (from an ordinary key pair, not the e-wallet's key as for null transactions) is processed using two hash functions: SHA256 and RIPEMD160. This is how data in the third field is formed. The fourth field contains additional information (e.g. information on the current status, validity period, time stamp, IDs of the cryptographic algorithms, etc.). The fifth field contains a public key from the service public/private key pair. This key is replicated, since it will be used for the verification of a DS. Let's prove that such approach is necessary.

Each transaction is included in the pool and stored there until processed. However, keeping transactions in the pool is risky, since transaction data can be falsified. The owner authenticates transaction data using a DS. The public key for the verification of this DS is explicitly specified in one of the transaction fields and then included in the ledger. Transactions are processed in a way that possibly allows an attacker to modify the data at their own discretion, verify it with own private key and then specify the corresponding public key for the verification of DS directly in the transaction. If authenticity and integrity are ensured only using a DS, such forgery may remain unnoticed. However, extending a DS with an additional mechanism that provides both archiving and persistence of the stored information will help detect such forgery. All we need to do is to include the authentic public key of the owner in the ledger. Let's see how it works.

Suppose that an attacker is trying to falsify the transaction data. In terms of the keys and DS, the following options are possible:

1. The attacker places their own public key in the transaction while keeping the owner's DS unchanged.
2. The attacker forms a new DS using their own private key while keeping the owner's public key unchanged.
3. The attacker forms a new DS using their own private key and place the corresponding public key in the transaction.

It's obvious that options 1 and 2 are useless, since the verification of the DS will always detect such forgery. The only option that makes sense is option 3: if the attacker creates a DS using their own private key, then they are forced to save the corresponding public key in the transaction, and this key will be different from the owner's public key. It's the only way for the attacker to enforce their falsified data.

Suppose that the owner has a fixed public/private key pair. Suppose that the data is authenticated with a DS using a private key from this pair while the public key is specified in the transaction. Suppose also that this public key has been included previously in the ledger and has been fully authenticated. Then the forgery can be revealed by the fact that the public key in the transaction does not match the public key in the ledger.

Let's sum it up. When processing data from the owner's very first transaction, we must authenticate the public key included in the ledger. To do this, we can read the key from the ledger and then match this key with the owner's authentic public key within the security perimeter (relatively invulnerable area). If the placed key is authenticated and fully persistent, then the key from the next transaction can also be easily authenticated by matching it with the key from the ledger. In other words, the key from the ledger is used as a reference. All other transactions of the owner will be processed similarly.

Each transaction is authenticated with a DS, and here we need both private keys: the service private key and the e-wallet's private key. Based on the two private keys, we can ensure the target security level, since the service private key can be known to other users, while the e-wallet's private key is known only to the owner of the ordinary key pair. We've called such a two-key signature a «consolidated» DS.

Non-null transactions are verified using the two public keys: the e-wallet's key and the service key. (Figure 7)

Figure 7. Verification of a non-null transaction

The verification process consists of the two basic steps: the first step includes verification of the digest of the e-wallet's public key while the second step implements the verification of the transaction's «consolidated» DS formed using the two private keys (i.e. the e-wallet's key and the service key). When the DS is authenticated, then the corresponding transaction, upon the additional verification, is included in the ledger.

However, the following question arises: how to verify whether a given transaction belongs to a particular transaction chain which begins from a null transaction? To do this, we've updated the verification process with yet another step — the connectivity verification. This step will require data from the first two fields that we haven't used up to this point.

Suppose that we need to verify whether transaction #2 is really followed by transaction #3. To do this, we can use the combined hashing method for calculating the hash function values for the data in the third, fourth, and fifth fields. The we can concatenate the data from the first field of transaction #3 and the previously calculated combined hash function value for the data in the third, fourth, and fifth fields of transaction #2. All these values are then processed using the two hash functions: SHA256 and RIPEMD160. If the resulting value matches the data in the second field of transaction #2, then the verification is passed successfully and the connectivity is proved. This is shown in more detail in the figures below.

Figure 8, Figure 9. Binding verification, second and third transactions example

In general, forming and including a notification in the ledger look like this. The workflow of forming a chain of notifications is clearly shown in the following figure:

Figure 10. Transaction structure and processing

In this article, we will not dive deep into the details and get back to the discussion of the concept of the decentralized infrastructure for public keys.

So, since the entity making the request sends a request for registration of notifications that are stored in the ledger rather than in a CA database, the core architectural components of the DPKI are as follows:

1. Ledger of Valid Notifications (LVN)
2. Ledger of Withdrawn Notifications (LWN)
3. Ledger of Suspended Notifications (LSN).

The information about public keys is stored in the LVN/LWN/LSN as hash function values. Note also that it can be either different ledgers or different chains or even a single chain as part of a single ledger, when information about the status of an ordinary public key (withdrawal, suspension, etc.) is added to the fourth field of the data structure as the corresponding code value. There are lots of options for the architectural implementation of the DPKI depending on various optimization criteria, such as costs for for long-term storing of public keys in memory, etc.

Thus, the DPKI can turn to be of the same or even lower architectural complexity compared to a centralized solution.

So, the main question here is which ledger is more suitable for implementing this technology?

The core requirement for the ledger is to be able to form transactions of any type. The most well-known example of a real ledger is Bitcoin. However, implementing the above technology for Bitcoin may face certain difficulties: limitations of the existing scripting language, the lack of necessary mechanisms for processing arbitrary datasets and methods for generating transactions of arbitrary types, and so on.

We at ENCRY tried to solve the above problems and developed a ledger, which, in our opinion, features several important advantages:

• Support of several types of transactions: in this ledger, you can both exchange assets (i.e. carry out financial transactions) and form transactions of an arbitrary structure
• Developers are welcome to use the proprietary programming language PrismLang which is very flexible in solving various technological problems
• The implemented mechanism for processing arbitrary datasets.

Simply put, the following steps should be completed:

1. An entity making the request registers in the DPKI and obtains an e-wallet. The e-wallet's address is a value of the hash function applied to the e-wallet's public key. The e-wallet's private key is known only to the entity making the request
2. Upon registration, the entity obtains access to the service private key
3. The entity forms a null transaction and then authenticates its DS using the e-wallet's private key
4. When forming a non-null transaction, the entity must authenticate its DS using two private keys: the e-wallet's key and the service key
5. The entity sends the transaction to the pool
6. The ENCRY network node reads the transaction from the pool and then verifies the transaction's DS and connectivity
7. If the DS is valid and the connectivity is proved, then the node will prepare the transaction for adding to the ledger.

Here, the ledger serves as a distributed database that stores information about valid, withdrawn, and suspended notifications.

Certainly, decentralization is not a one-size-fits-all solution. The core issue with the primary user authentication still persists: while the entity making the request is currently verified by the CA, the DPKI proposes to delegate this verification to the community members and motivate them financially. The verification technology based on public sources is commonly known. Efficiency of such verification has also been proved in practice: several high-profile investigations conducted by Bellingcat are good examples of this.

But in general, we are quite sure that the DPKI is capable to eliminate many, if not all, disadvantages of a centralized PKI.

Feel free to subscribe to our blog on Habr, where we are going to discuss our further researches and developments, and follow our Twitter to stay tuned for more news about ENCRY projects.