DPKI: Fixing the Disadvantages of a Centralized PKI with Blockchain

It's no secret that one of the widely used auxiliary tools, without which data protection in open networks is impossible, is the technology of digital certificates. However, it is no secret that the main drawback of this technology is unconditional trust in the centers that issue digital certificates. Andrey Chmora, Director of Technology and Innovation at ENCRY, proposed a new approach to organizing public key infrastructures (Public Key Infrastructure, PKI), which will help eliminate the current shortcomings and which uses distributed ledger (blockchain) technology. But first things first.

If you are familiar with how the existing Public Key Infrastructure works and know its key weaknesses, then you can skip ahead to a description of what we propose to change below.

What are digital signatures and certificates?Interaction on the Internet always involves the transfer of data. We all have an interest in ensuring that data is transmitted securely. But what is security? The most requested security services are confidentiality, integrity, and authenticity. For this, methods of asymmetric cryptography, or cryptography with a public key, are currently used.

Let's start with the fact that in order to use these methods, the subjects of interaction must have two individual paired keys - public and secret. With their help, the security services that we mentioned above are provided.

How is the confidentiality of information transfer achieved? Before sending the data, the sender-subscriber encrypts (cryptographically converts) the public data using the recipient's public key, and the latter decrypts the received ciphertext using the paired secret key.

How is the integrity and authenticity of the transmitted information achieved? To solve this problem, another mechanism was created. The open data is not encrypted, but the result of applying the cryptographic hash function is transmitted along with it - a "compressed" image of the input data sequence - in encrypted form. The result of such hashing is called a “digest”, and it is encrypted using the secret key of the sender (“signer”). Digest encryption results in a digital signature. It, together with the clear text, is transmitted to the recipient subscriber (“verifier”). He decrypts the digital signature on the public key of the witness and compares it with the result of applying the cryptographic hash function, which the verifier calculates on the basis of the received public data. If they match, then this indicates that the data was transmitted in an authentic and complete form by the sender subscriber, and not modified by an attacker.

Most resources that work with personal data and payment information (banks, insurance companies, air carriers, payment systems, as well as government portals such as the tax service) actively use asymmetric cryptography methods.

What is a digital certificate? Everything is simple. Both the first and second processes involve public keys, and since they play a central role, it is very important to make sure that the keys really belong to the sender (signer, in the case of signature verification) or the recipient, and not spoofed with malicious keys. That's what digital certificates are for, to ensure the authenticity and integrity of the public key.

Note: the authenticity and integrity of the public key is confirmed in exactly the same way as the authenticity and integrity of open data, that is, using an electronic digital signature (EDS).
Where do digital certificates come from?Trusted Certificate Authorities, or Certification Authorities (CAs), are responsible for issuing and maintaining digital certificates. The applicant requests the issuance of a certificate at the CA, is identified at the Registration Center (CR), and receives a certificate from the CA. The CA guarantees that the public key from the certificate belongs to the entity for which it was issued.

If you do not authenticate the public key, then an attacker during the transfer / storage of this key can replace it with his own. If the substitution has taken place, then the attacker will be able to decrypt everything that the sender-subscriber transmits to the recipient-subscriber, or change the open data at his discretion.

Digital certificates are used wherever there is asymmetric cryptography. One of the most common digital certificates is SSL-certificates for a secure mode of communication over the HTTPS protocol. Hundreds of companies registered in various jurisdictions are engaged in issuing SSL certificates. The main share falls on five to ten large trusted centers: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA and CR are components of PKI, which also includes:

• Open Directory - a public database that provides secure storage of digital certificates.
• List of revoked certificates – a public database that provides secure storage of digital certificates of revoked public keys (for example, due to a compromise of a paired secret key). Infrastructure actors can independently access this database, or they can use the specialized Online Certificate Status Protocol (OCSP), which simplifies the verification process.
• Certificate Users – serviced PKI entities that have entered into a user agreement with the CA and verify the digital signature and/or encrypt data based on the public key from the certificate.
• Subscribers – Served PKI entities that own the private key paired with the public key from the certificate and have entered into a subscriber agreement with the CA. The subscriber can also be the user of the certificate.

Thus, the trusted entities of the public key infrastructure, which include CAs, CAs and public directories, are responsible for:

1. Verification of the identity of the applicant.
2. Profiling the public key certificate.
3. Issuance of a public key certificate to the applicant, whose identity has been reliably verified.
4. Change the status of the public key certificate.
5. Providing information about the current status of the public key certificate.

Disadvantages of PKI, what are they?The fundamental disadvantage of PKI is the presence of trusted entities.
Users must unconditionally trust CAs and CRs. But, as practice shows, unconditional trust is fraught with serious consequences.

Over the past ten years, there have been several major scandals in this area related to infrastructure vulnerabilities.

- in 2010, the Stuxnet malware began to spread on the network, which was signed using stolen digital certificates from RealTek and JMicron.

In 2017, Google accused Symantec of issuing a large number of falsified certificates. At that time, Symantec was one of the largest CAs in terms of release volumes. In the Google Chrome 70 browser, support for certificates issued by this company and its affiliated GeoTrust and Thawte centers was discontinued until December 1, 2017.

The CAs were compromised, as a result, everyone suffered - both the CAs themselves, as well as users and subscribers. Confidence in the infrastructure has been undermined. In addition, digital certificates can be blocked in the face of political conflicts, which will also affect the work of many resources. This is what was feared several years ago in the administration of the Russian president, where in 2016 they discussed the possibility of creating a state certification center that would issue SSL certificates to sites in Runet. The current state of affairs is such that even state portals in Russia use digital certificates issued by American companies Comodo or Thawte (Symantec's subsidiary).

There is another problem - the question primary authentication (authentication) of users. How to identify a user who has applied to a CA with a request to issue a digital certificate without direct personal contact? Now this is being decided situationally, depending on the capabilities of the infrastructure. Something is taken from open registries (for example, information about legal entities requesting certificates), in cases where applicants are individuals, bank offices or post offices can be used, where their identity is confirmed by identification documents, such as a passport.

The problem of falsifying credentials for the purpose of impersonation belongs to the category of fundamental ones. Note that a full-fledged solution to this problem does not exist due to information-theoretical reasons: without having reliable information a priori, it is impossible to confirm or disprove the authenticity of a particular subject. As a rule, for verification it is necessary to present a set of documents proving the identity of the applicant. There are many different verification methods, but none of them provides a full guarantee of the authenticity of documents. Accordingly, the authenticity of the applicant's identity cannot be guaranteed either.

How can these shortcomings be eliminated?If the problems of PKI in its current state can be explained by centralization, then it is logical to assume that decentralization would help to partially eliminate the identified shortcomings.

Decentralization does not imply the presence of trusted entities - if you create decentralized public key infrastructure (Decentralized Public Key Infrastructure, DPKI), then neither CA nor CR are needed. We will abandon the concept of a digital certificate and use a distributed ledger to store information about public keys. In our case, we call a registry a linear database consisting of individual records (blocks) linked using blockchain technology. Instead of a digital certificate, we introduce the concept of “notification”.

How the process of receiving, checking and canceling notifications will look like in the proposed DPKI:

1. Each applicant sends an application for a notification independently by filling out a form during registration, after which it forms a transaction that is stored in a specialized pool.

2. Information about the public key, along with the details of the owner and other metadata, is stored in a distributed registry, and not in a digital certificate, for which the CA is responsible for issuing in the centralized PKI.

3. Verification of the identity of the applicant is done ex post by the collaborative efforts of the DPKI user community and not by the RA.

4. Only the owner of such a notification can change the status of a public key.

5. Everyone can access the distributed ledger and check the current status of the public key.

Note: At first glance, community verification of the applicant's identity may seem too unreliable. But we must remember that at present, all users of digital services are bound to leave a digital footprint, and this process will only continue to gain momentum. Open electronic registers of legal entities, maps, digitization of terrain images, social networks - all these are public tools. They are already successfully used in the course of investigations by both journalists and law enforcement agencies. For example, suffice it to recall the investigations of Bellingcat or the joint investigation team of the JIT, which is studying the circumstances of the crash of the Malaysian Boeing.

So, how will a decentralized public key infrastructure work in practice? Let us dwell on the description of the technology itself, which we patented in 2018 and rightfully consider it our know-how.

Imagine there is some owner who owns a set of public keys, where each key is a kind of transaction that is stored in the registry. How, in the absence of a CA, to understand that all the keys belong to this particular owner? To solve this problem, a null transaction is created, which contains information about the owner and his wallet (from which the commission for placing the transaction in the registry is debited). A null transaction is a kind of “anchor” to which the next transactions with public key data will be attached. Each such transaction contains a specialized data structure, or in other words, a notification.

Notificat is a structured data set consisting of functional fields and including information about the public key of the owner, the persistence of which is guaranteed by being placed in one of the related records of the distributed registry.

The next logical question is how is a null transaction formed? The zero transaction - like the subsequent ones - is an aggregation of six data fields. During the formation of a null transaction, the key pair of the wallet (public and paired secret keys) is involved. This key pair appears at the moment when the user registers his wallet, from which the commission will be charged for placing a zero transaction in the registry and - subsequently - operations with notifications.

As shown in the figure, the wallet public key digest is generated by successively applying the SHA256 and RIPEMD160 hash functions. Here RIPEMD160 is responsible for the compact representation of data, the bit length of which does not exceed 160 bits. This is important - after all, the registry is not a cheap database. The public key itself is entered in the fifth field. The first field contains data that establishes a connection with the previous transaction. For transaction zero, this field contains nothing, which distinguishes it from subsequent transactions. The second field is data for checking the connectivity of transactions. For brevity, we will call the data of the first and second fields “link” and “check”, respectively. The content of these fields is formed by iterative hashing, as shown in the example of linking the second and third transactions in the figure below.

The data from the first five fields are certified with an EDS, which is generated using the secret key of the wallet.

Everything, a zero transaction is sent to the pool and, after a successful check, is entered into the registry. Now you can “tie” the following transactions to it. Let's consider how the formation of transactions other than zero occurs.

The first thing that probably caught your eye is the abundance of key pairs. In addition to the already familiar wallet key pair, ordinary and service key pairs are used.

An ordinary public key is what everything, in fact, was started for. This key is involved in various procedures and processes unfolding in the outside world (banking and other transactions, document flow, etc.). For example, a secret key from an ordinary pair can be used to generate the EDS of various documents - payment orders, etc., and a public key can be used to verify this EDS with the subsequent execution of these instructions, provided that it is valid.

The service pair is issued to the registered subject of the DPKI. The name of this pair corresponds to its purpose. Note that no service keys are used when generating/verifying a null transaction.

Once again, let's clarify the purpose of the keys:

1. Wallet keys are used to generate/verify both zero and any other non-zero transactions. The secret key of the wallet is known only to the owner of the wallet, who is also the owner of multiple ordinary public keys.
2. A single public key is similar in purpose to a public key for which a certificate is issued in a centralized PKI.
3. The service key pair belongs to the DPKI. The secret key is issued to registered entities and is used in the formation of the digital signature of transactions (except for the zero one). Public is used to verify the digital signature of a transaction before it is placed in the registry.

Thus, there are two groups of keys. The first includes service keys and wallet keys - they only make sense in the context of DPKI. The second group includes ordinary keys - their scope may vary and is determined by the applications in which they are used. At the same time, DPKI ensures the integrity and authenticity of ordinary public keys.

Note: The service key pair may be known to different DPKI entities. For example, it can be the same for everyone. It is for this reason that when forming the signature of each non-zero transaction, two secret keys are used, one of which is the wallet key - it is known only to the wallet owner, who is also the owner of a set of ordinary public keys. All keys have their own meaning. For example, it is always possible to prove that the transaction was entered into the registry by a registered DPKI subject, since the signature was also generated on the secret service key. And here there can be no abuses, such as DOS attacks, because the owner pays for each transaction.

All transactions that follow the zero one are formed in a similar way: the public key (but not of the wallet, as in the case of the zero transaction, but from an ordinary key pair) is run through two hash functions SHA256 and RIPEMD160. This is how the data of the third field is formed. The fourth field contains accompanying information (for example, information about the current status, expiration dates, timestamp, identifiers of cryptographic algorithms used, etc.). The fifth field contains the public key from the service key pair. With its help, the EDS will then be checked, so it is replicated. Let us justify the need for such an approach.

Recall that the transaction is entered into the pool and stored there until it is processed. Storage in the pool is associated with a certain risk - transaction data can be falsified. The owner certifies the transaction data with an EDS. The public key for verifying this digital signature is indicated in one of the fields of the transaction in an explicit form and subsequently entered into the register. The features of transaction processing are such that an attacker is able to change the data at his discretion and then certify them using his secret key, and indicate the paired public key for verifying the EDS in the transaction. If the authenticity and integrity is ensured solely through the digital signature, then such a forgery will go unnoticed. However, if in addition to the EDS there is an additional mechanism that provides both archiving and persistence of the stored information, then forgery can be detected. To do this, it is enough to enter the original public key of the owner into the registry. Let's explain how it works.

Let the attacker perform the forgery of the transaction data. From the point of view of keys and EDS, the following options are possible:

1. The attacker places his public key in the transaction with the owner's EDS unchanged.
2. An attacker generates an EDS on his private key, but leaves the owner's public key unchanged.
3. An attacker generates an EDS on his secret key and places a paired public key in the transaction.

Obviously, options 1 and 2 are meaningless, since they will always be detected during the verification of the EDS. Only option 3 makes sense, and if an attacker generates an EDS using his own secret key, then he is forced to save a paired public key in the transaction that is different from the owner's public key. For an attacker, this is the only way to impose falsified data.

Let's assume that the owner has a fixed pair of keys - secret and public. Let the data be certified with an EDS using the secret key from this pair, and the public key is indicated in the transaction. Let's also assume that this public key has already been previously entered into the registry and its authenticity has been reliably verified. Then the forgery will be indicated by the fact that the public key from the transaction does not match the public key from the registry.

To sum up. When processing data from the very first transaction of the owner, it is necessary to verify the authenticity of the public key entered in the register. To do this, read the key from the registry and compare it with the owner's true public key within the security perimeter (a region of relative invulnerability). If the authenticity of the key is confirmed and its persistence is guaranteed upon placement, then the authenticity of the key from the subsequent transaction can be easily confirmed/denied by comparing it with the key from the registry. In other words, the key from the registry is used as a reference sample. All other transactions of the owner are processed similarly.

The transaction is certified by an EDS - this is where secret keys will be needed, and not one, but two at once - a service one and a wallet. The use of two secret keys provides the necessary level of security - after all, the service secret key can be known to other users, while the wallet secret key is known only to the owner of the ordinary key pair. We called such a two-key signature a “consolidated” EDS.

Verification of transactions other than zero is performed using two public keys: wallet and service. The verification process can be divided into two main stages: the first is verification of the digest of the public key of the wallet, and the second is verification of the digital signature of the transaction, the same consolidated one that was generated using two secret keys (wallet and service). If the validity of the EDS is confirmed, then after additional verification, the transaction is entered into the register.

A logical question may arise: how to check if a transaction belongs to a particular chain with a "root" in the form of a null transaction? To do this, the verification process is supplemented with one more stage - a connectivity check. This is where we need the data from the first two fields, which so far we have ignored.

Imagine that we need to check if transaction #3 really comes after transaction #2. To do this, the combined hashing method calculates the value of the hash function for data from the third, fourth and fifth fields of transaction No. 2. Then the data from the first field of transaction #3 is concatenated and the previously obtained value of the combined hash function for the data from the third, fourth and fifth fields of transaction #2. All this is also run through two hash functions SHA256 and RIPEMD160. If the received value matches the data of the second field of transaction No. 2, then the check is passed and the connectivity is confirmed. This is shown more clearly in the figures below.

In general terms, the technology for generating and entering a notification in the register looks like this. A visual illustration of the process of forming a chain of notifications is shown in the following figure:

In this text, we will not dwell on the details, which undoubtedly exist, and return to a discussion of the very idea of ​​a decentralized public key infrastructure.

So, since the applicant himself sends an application for registration of notifications that are not stored in the CA database, but in the registry, the main architectural components of the DPKI should be considered:

1. Register of valid notifications (RDN).
2. Register of revoked notifications (RON).
3. Register of suspended notifications (RPN).

Information about public keys is stored in RDN/RON/RPN as hash values. It is also worth noting that these can be both different registries and different chains, or even one chain as part of a single registry, when information about the status of an ordinary public key (revocation, suspension, etc.) is entered in the fourth field of the data structure in the form of the corresponding code value. There are many different options for the architectural implementation of DPKI, and the choice of one or the other depends on a number of factors, for example, such an optimization criterion as the cost of long-term memory for storing public keys, etc.

Thus, DPKI may turn out to be, if not simpler, then at least comparable to a centralized solution in terms of architecture complexity.

The main question remains Which register is suitable for implementing the technology?

The main requirement for the registry is the ability to form transactions of an arbitrary type. The most famous example of a ledger application is the Bitcoin network. But in it, when implementing the technology described above, certain difficulties arise: the limitations of the existing scripting language, the lack of the necessary mechanisms for processing arbitrary data sets, the methods for generating transactions of an arbitrary type, and much more.

We at ENCRY have tried to solve the above problems and have developed a registry that we believe has a number of advantages, namely:

• supports several types of transactions: it can both exchange assets (that is, perform financial transactions) and form transactions with an arbitrary structure,
• developers have access to the proprietary programming language PrismLang, which provides the necessary flexibility in solving various technological problems,
• a mechanism for processing arbitrary data sets is provided.

In a simplistic way, the following sequence of actions takes place:

1. The applicant registers with the DPKI and receives a digital wallet. The wallet address is the hash value of the wallet's public key. The secret key of the wallet is known only to the applicant.
2. The registered subject is granted access to the service secret key.
3. The subject forms a null transaction and certifies it with an EDS using the secret key of the wallet.
4. If a transaction other than zero is formed, then it is certified by an EDS using two secret keys: a wallet and a service one.
5. The subject submits a transaction to the pool.
6. The ENCRY network node reads the transaction from the pool and checks the digital signature, as well as the connectivity of the transaction.
7. If the EDS is valid and the connection is confirmed, then it prepares the transaction for entry into the register.

Here, the registry acts as a distributed database that stores information about valid, canceled and suspended notifications.

Of course, decentralization is not a panacea. The fundamental problem of primary user authentication does not disappear anywhere: if CRs are currently checking the applicant, then in DPKI it is proposed to delegate verification to community members, and use financial motivation to stimulate activity. Open source verification technology is well known. The effectiveness of such a check has been confirmed in practice. Again, let us recall a number of high-profile investigations by the Internet publication Bellingcat.

But in general, the following picture emerges: DPKI is an opportunity to correct, if not all, then many of the shortcomings of a centralized PKI.

Subscribe to our Habrablog, we plan to continue to actively cover our research and development, and follow twitterif you don't want to miss out on other news about ENCRY projects.

Source: habr.com