Building a chain of trust in PKI, is it so simple

Public Key Infrastructure (PKI) is a fairly popular technology to ensure the integrity and proof of authorship of various IT systems. Sometimes a person sitting at a computer does not even suspect its use, as in the case of checking the integrity of a program when installing on a computer.


PKI technology is not new. If we count from the moment of the occurrence of the Merkle algorithm for the distribution of the key - then the technology is already 42 years old, if you count from the moment of the occurrence of RSA - then 39 years. Age is impressive in any case. During this time, the technology has evolved significantly and allows you to create a solid list of services for other applications and users.


The services themselves are regulated in a number of standards, in the X.500 series it is a series of ITU-T standards (1993) for the distributed network directory service and the RFC series (Request for Comments) - a document from a series of numbered Internet information documents covering technical specifications and standards widely used on the World Wide Web. Moreover, the RFC series is primary. The bulk of the RFI about PKI was released by RSA, one of the fathers (s) of the founders of PKI technology.


PKI and its standards


Separately, all kinds of national standards and regulatory requirements should be mentioned, for example, in the Russian Federation it is FZ-63, orders of the FSB of Russia No. 795 and 796 and other derivatives from them. It should be noted that the variety of RFC standards and PKI functions described in them gave rise to several organizational and regulatory approaches to building PKI infrastructure in a single country. To illustrate, here is a list of PKI services that are described in the X.842 standard:


  • Key management services
  • 1 Key Generation Service
  • 2 Key Registration Service
  • 3 Key Certification Service
  • 4 Key Distribution Service
  • 5 Key Installation Service
  • 6 Key Storage Service
  • 7 Key Derivation Service
  • 8 Key Archiving Service
  • 9 Key Revocation Service
  • 10 Key Destruction Service
  • Certificate Management Services
  • 1 Public Key Certificate Service
  • 2 Privilege Attribute Service
  • 3 On-line Authentication Service Based on Certificates
  • 4 Revocation of Certificates Service
  • Electronic Notary Public Services
  • 1 Evidence Generation Service
  • 2 Evidence Storage Service
  • 3 Arbitration Service
  • 4 Notary Authority
  • 5 Electronic Digital Archiving Service
  • Other services
  • 1 Directory Service
  • Identification and Authentication Service
  • 1 On-line Authentication Service
  • 2 Off-line Authentication Service
  • 3 In-line Authentication Service
  • 4 In-line Translation Service
  • Recovery Services
  • 1 Key Recovery Services
  • 2 Data Recovery Services
  • 5 Personalization Service
  • 6 Access Control Service
  • 7 Incident Reporting and Alert Management Service

The result of this diversity was the outrage in the national standards of individual countries. As a result, a set of problems on compatibility between different solutions in individual countries and, very often, the inability to build a chain of trust between two users of PKI technology in different countries.


Certification Chain and Trust Chain


Before considering the question of how to build cross-border trust, I would like to analyze the question of building a chain of trust within the country, taking the example of the Russian Federation.


To do this, I will briefly describe how the basic PKI infrastructure is built and what are the methods for building trust in PKI.
Trust in PKI is built on the principle of guarantee - for example, if two people do not know each other, but want to enter into a relationship that requires mutual trust, they are looking for a third person whom they both can trust and who would vouch for each of them before the other. An analogue of such a person in PKI is called a third trusted party.


One of PKI's applications is to ensure the legal value of electronic document management. That is, providing the ability to trust an electronic signature on an electronic document. But, it should be clarified that ensuring legal significance requires the fulfillment of a number of conditions, one of which is the construction of a certification chain. In the framework of this article, I would like to examine in detail only the procedure for building a certification chain and its relationship with the trust chain.


A chain of trust between people is built by building a certification chain. This is done as follows: the role of the third trusted party is an accredited certification center. This is a legal entity that has one or more sets of equipment that implements the functions of a certification center. Accreditation means that this legal entity meets a number of legislative requirements, it has the appropriate licenses of the FSB, the Ministry of Communications and sometimes the FSTEC of Russia, properly equipped premises, trained personnel with the right diplomas and certified software and equipment in the role of a certification center (CA). So, this certification center is authorized by the state to confirm your electronic signature to other persons. The process of confirming your electronic signature by a certification authority is the process of creating a certification chain, as the CA certificate is also signed by the Main Certification Authority (GSC), which is a single point of trust. What is an electronic signature and how does it work - the question is beyond the scope of this article, you can read about it in other sources.


In order for this CA to be able to say exactly what your signature is under the document, you need to go to the registration center of this CA and provide your public key, certificate request, passport and a number of other documents. As a result, you will receive a public key certificate signed on the key of this CA. An analogue of this is the 2nd and 3rd pages of the internal passport of a citizen of the Russian Federation, there is also your unique signature, full name and which authority indicated these data. But there is a slight difference - in the case of a passport, trust in its carrier is built through confirmation of the authenticity of the passport itself, and then through the data that is indicated in it. In the electronic world of CAs, it is customary to trust only if both users who are trying to communicate with each other are served in this CA. If each user has a CA, the problem of trust between the CAs arises. There are several ways to solve it; the way from below implies cross-certification between CAs of different users. This way is good when there is not a lot of CAs, but if each department develops its own CA, a situation will arise that arose in the Russian Federation by 2002-2005: there are many CAs in the country, but there is no single trust space, since cross-certification is among 800 CAs - the thing is technically unrealistic.


And here the question arises - how to build a single space of trust in a single country so that it works. The approach that is used in the Russian Federation and not only - the creation of the Main Certification Authority (state) (GSC), its signing with a certificate of all CA certificates in the country, as a result - building a chain of trust through verifying the validity of all certificates in the signature through the GCC. This approach implies that the user's signature, the validity of the user’s certificate, the validity of all certificates in the chain (CA – HUZ) are verified. Validation of certificates in different countries is done differently. In Estonia and Ukraine it is necessary to apply to the OCSP / TSP-service of the SEC, which will answer - a valid certificate or has expired or the certificate has been revoked. In Russia, for verification, it is necessary to request from each CA in the chain a list of revoked certificates (SOS) and verify that the certificate is not specified in it. Perhaps the most developed option for constructing a PKI system should be considered a scheme using a bridge-forming CA, in the form in which it is used in the United States. The US federal bridge-forming CA (bridge) contains several basic services whose functions should be discussed in a separate article.


Difficulties

At this point, difficulties begin. The first difficulty. It happens that the user certificate is filled out incorrectly, does not meet the requirements of the law, in which case it must be re-issued. As a rule, a similar problem is caused by a CA employee who filled it incorrectly, and the user gets problems when he cannot use it normally.


The complexity of the second. The legislation says that the CA is a legal entity, and the GEC must sign a certificate of this CA. The situation when one legal entity has several complexes of CAs and several certificates of these CAs is not clearly spelled out in laws. CAs take advantage of this, some certificates are not signed using the GSC certificate and make them self-issued at best - when the chain to the GCC can be built only by the name of the CA in the certificate - or generally self-signed - when there is no technical connection between the certificates of one CA, it is only on paper.


The complexity of the third. If the certificate has been revoked, the CA is obliged to add it to the list of revoked certificates (SOS), this obligation is prescribed in the RFC, if they are accepted as a standard in the country, or in the rules of the GSC, to which all accredited CAs must join. In the case when the COS (CRL) is large, the CA for the convenience of users issues a delta COS (deltaCRL) with changes in a short period. In the regulations of the SEC the frequency of renewal is 12 hours or upon the revocation of certificates. In reality, various CAs publish their SOS as they want, there are some CAs that update them once every few months. Or SOS is signed with a key that is not related to the CA certificate, which also reduces the chance to build a chain of trust to zero. Slowly there is a problem with processing the SOS itself,


The fourth difficulty is connected. Building a chain of trust in PKI in one way or another requires a connection with the CA and the GUT and working online. Work offline is not provided. There are a number of places and applications where working with signatures and certificates offline would be very useful. Not all of the territory of the Russian Federation is covered by high-quality Internet and every extra byte transferred is perceived painfully, as it hits the wallet.


Difficulty fifth, technical. Sometimes in the hardware and software complexes of the CA there are still errors in the logic and implementation, this can also affect the construction of a chain of trust.


And only if these problems did not occur in the user's path, the chain of trust should be built. If you use OCSP / TSP services, problems also exist, but this is a topic for another article.


Also popular now: