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

Public Key Infrastructure (PKI) is a popular enough technology to ensure integrity and proof of authorship in 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 installed on a computer.

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

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

PKI and its standards

We should separately mention all kinds of national standards and regulatory requirements, for example, in the Russian Federation these are FZ-63, orders of the Federal Security Service of Russia No. 795 and 796, and other derivatives of them. It should be noted that the diversity of the RFC standards and the PKI functions described in them has generated several organizational and regulatory approaches to building the PKI infrastructure in a single country. For illustration, here is a list of PKI services, which 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 Offline 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 a disgrace 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 impossibility of building a chain of trust between two users of the PKI technology in different countries.

Chain of Certification and Chain of Trust

Before considering the issue of the methodology for building cross-border trust, I would like to examine the issue 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 in general and what are the methods to ensure trust in the PKI.

Confidence in a PKI is built on the principle of guarantee - for example, if two people do not know each other, but want to enter into relationships that require mutual trust, they are looking for a third, who both of them can trust and who will vouch for each of them to the other. An analogue of such a person in PKI is the third trusted party.

One of the applications of PKI is to ensure the legal value of electronic document management. That is, providing the ability to trust an electronic signature under 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 this article, I would like to consider in detail only the procedure for building a chain of certification and its relationship with the chain of trust.

The chain of trust between people is built by building a certification chain. This is done as follows: an accredited certifying center acts as a third trusted party. This is a legal entity having one or several sets of equipment that implements the functions of a certification center. Accreditation means that this legal entity meets a number of legal 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 correct diplomas and certified software and equipment as a certification center (CA). So, this certification center is authorized by the state to confirm your electronic signature to other persons. The procedure for confirming your electronic signature by the certifying authority is the process of creating a certification chain, since the CA certificate is also signed by the Main Certification Authority (GTC), which is a single point of trust. What is an electronic signature and how it works - the question is beyond the scope of this article, you can read about it in other sources.

In order for this CA to say for sure that it is your signature under the document, you need to come 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 the CA. The 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, your full name, and it is indicated which authority assured these data. But there is a small difference - in the case of a passport, the credibility of its carrier is built through confirming the authenticity of the passport itself, and then through the data that is indicated in it. In the electronic world, CAs are usually trusted only if both users who are trying to communicate with each other are serviced in this CA. If each user has their own CA, there is a problem of trust between the CAs. There are several ways to solve it, the way from below implies cross-certification between TC of different users. Such a path is good when there is not much CA, but if each agency develops its own CA, the situation will arise in the Russian Federation by 2002–2005: there are many CAs in the country, but there is no common space of trust, since the cross-certification among 800 CAs - a piece technically unreal.

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 is the creation of the Main Certifying Center (state) (GTC), its signature with a certificate of all CA certificates in the country, and as a result, building a chain of trust by checking the validity of all certificates in the signature through the CTC. Such an approach implies that the user's signature, validity of the user's certificate, validity of all certificates in the chain (CA – GHC) are verified. Validation of certificates in different countries is done in different ways. In Estonia and Ukraine, this requires you to contact the OCSP / TSP service of the GTC, which will respond with 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 check that the certificate is not specified in it. Perhaps, the most developed variant of building a PKI system should be considered a scheme using a bridge-forming TC, as used in the USA. The Federal Bridge Forming Center (Bridge) of the USA contains several basic services whose functions should be analyzed in a separate article.

Difficulties

At this point, the difficulties begin. The complexity of the first. It happens that the user certificate is filled out incorrectly, does not comply with the requirements of the legislation, in this case it must be reissued. As a rule, a similar problem is caused by a CA worker who has filled it in the wrong way, and the user gets problems when he cannot use it properly.

The complexity of the second. The legislation says that the CA is a legal entity, and the ACC must sign the certificate of this CA. The situation when a single legal entity has several CA complexes and several certificates of these CAs is not clearly spelled out in the laws. CAs use this, some of the certificates are not signed with the help of the GTC certificate and are at best self-issued - when the chain to the GTC can be built only by the name of the CA in the certificate - or self-signed in general - when there is no connection between the certificates of the CA only on paper.

The complexity of the third. If the certificate is revoked, the CA must add it to the list of revoked certificates (CRL), this duty is prescribed in the RFC, if they are accepted as a standard in the country, or in the GTC regulation, to which all accredited CAs must join. In the case when the COC (CRL) is large, the CA for the convenience of users releases the delta COC (deltaCRL) with changes in a short period. The regulation of the GTC prescribes the update frequency of 12 hours or after the revocation of certificates. In reality, various CAs publish their SOS as they want, there are some CAs that update them once in several months. Or the SOS is signed by 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 the processing of the SOS themselves, during the existence of the CA they have become quite large, but almost no one releases the SOS delta.

The complexity of the fourth, connected. Building a chain of trust in PKI in one way or another requires communication with TC and GCB 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. Far from 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.

The complexity of the fifth, technical. Sometimes, software and hardware complexes of the TC still contain errors in logic and implementation, this can also affect the construction of the chain of trust.

And only if there are no such problems on the user's path, should the chain of trust be built. In case of using OCSP / TSP services, problems also exist, but this is a topic for a separate article.