Why do we need the public key infrastructure?

Why do we need the public key infrastructure?

To encrypt anything, we need the encryption key (and we need the signature key to sign anything). The same is needed to decrypt anything (verify the signature) as well. If the desired person does not have the key, he or she will not be able to decrypt the message (or verify the signature). If the intruder has got the key: This is easy to understand.

Perhaps, everyone can recall the moment and the person to whom he or she gave the key from his or her apartment for the first time. Saying nothing of what this means from the point of view of relations between a man and a woman, we do understand we must confide in the housemaid or in the neighbor when we ask her to feed the cat when we are away.

We try to give the key from our apartment only to the people we are well familiar with. Fortunately, you do not have to give the key from your apartment to a great amount of people.

You can do the same to share encrypted information or data signed with electronic signature within a close circle of friends and partners: you can interchange the necessary keys when you meet them in person or by confirming the authenticity of transmitted data (e.g., the key sent by email) by phone.

The situation with the keys to your office can be different. When going on a vacation, we warn the guards: "you can give the key only to Julia and director's secretary as well as to those they will ask to give the key to when they are away. If those people ask to give the key to someone else, you can give the key to them but only during business hours, and they must not enter the office alone but only accompanied by a guard." This way, we form a kind of a guarantor system, which is characterized by its own hierarchy: the confidence level is reduced at each step.

This is the "civil society" level. What about the state level? It is difficult to imagine the situation when foreigners are permitted to cross the border by guarantee or just because the border guard trusts them personally. The president cannot know all citizens in person even provided he is going to let people go through the border personally instead of charging border guards with this.

Passports are used for this. A valid passport, which is not on the black list as false, with the photo representing the passport holder and all details complying with the officially recognized standards, is the document confirming that the passport holder can enter the country, i.e. he or she "has got the key."

We know there is a special authorized body that issues passports. The passport does not prove you are a decent person. It just confirms you are the one you claim to be.

Since cryptography is the same social phenomenon as the above-mentioned ones, the same applies to it.

Using cryptography for secure information interchange on a broad scale inevitably requires solving the problem of reliable key distribution. That is why asymmetric cryptography - public key systems - was suggested. Asymmetry means there are two different keys: one of them is private and the other one is public. You can give the latter to everyone without running any risk. Thus, public key systems enable us not to transmit secret key information but enable us to transmit only public data.

To use asymmetric cryptography in practice, it is necessary to solve one more problem: how can we make sure the public key belongs to a particular user?

The Public Key Infrastructure was developed for this purpose.

This issue can be obviously approached from two different directions: there may be either a system of guarantors (when the user with the public key you rely on signs the other user's public key, "guaranteeing" its authenticity this way) or a system of "passports" when an authorized organization all users must trust in is in charge of certifying that the public key matches the user.

In the former case, a "web of trust" is formed (the OpenPGP philosophy), and in the latter case the system of Certification Authorities is established.

Digital certificates

The digital certificate or public key certificate associating the certificate holder with the value of his public key is the basic element of the latter. A digital certificate comprises only public data which are accessible to everyone. They include the user's information, his or her public key, certificate validity term and additional attributes related to the certificate issue.

In other words, a digital certificate is a passport where the end user's personal data are linked to his or her public key using the electronic signature (ES) of the Certification Authority (CA). The CA's signature verifies as follows:

·  Relation between data from the certificate and the user

·  Integrity of the digital certificate ("the photo in the passport is authentic" - any attempt to intervene with the structure or certificate data will damage it; thus, if the integrity is verified, the certificate underwent no changes, and the public key was not amended).

It is quite easy and understandable how to organize certificate management in operation systems (OS) belonging to the Microsoft Windows family. In the elementary case, the certification acquisition process requires applying to the CA using the browser and filling in standard forms.

The certificate acquired this way is stored in the personal system certificate repository ("MY" repository) in the computer used to apply for the certificate. The certificate and private key from the key pair related to this certificate are stored in the computer registry. The user can easily use the obtained certificate in any software requiring this. By the way, not only the user who obtained the certificate but also any user of this computer.

At the same time, to use the certificate on some other computer, the user needs to export it to a file, copy the resulting file to some data carrier and then import the certificate from the file into the personal system certificate repository in the other computer. This is inconvenient, in particular if you do not wish to use two or three computers but feel like being independent of permanent workplaces.

Moreover, when the user plans to use the certificate on another computer not only for verification but also for generating signatures, he or she needs to transfer the certificate together with the key pair (this can be accomplished by exporting the certificate in a special format, .pfx) but this is insecure because the file can be snatched by intruders, and then they will be able to use your signature.

To solve this problem for Windows operating systems, Microsoft developed regulations on embedding physical repositories into the system logic certificate repository. This means the certificates and key pair related to them are stored not in the system registry but on any portable carrier. In this case, if the carrier is not plugged in the computer, the certificates are unavailable.

The physical repository must be registered in the system using special system functions. Then it will be accessible via the system logic repository specified during registration. Thus, when we have registered the "A" physical repository related to the "MY" logic repository, we will get access to certificates stored in the "A" physical repository when calling the MY" repository.

The security level for keys and certificates on the portable carrier may vary depending on the type of the carrier. If this is a floppy disk, it is clear that the security level is low. Therefore, it is preferable to use such really secure devices such as SHIPKA PCDST for this.

Special software supplied together with the SHIPKA PCDST comprises a library supporting physical certificate repositories. Physical certificate repositories are registered with the SHIPKA PCDST during installation of the SHIPKA software and the user does not have to do anything else.

To obtain a certificate using the SHIPKA PCDST, the user follows the standard procedure of applying to the Certification Authority.

When the certificate is installed, it is saved not in the "MY" logic certificate repository but in the SHIPKA device, and this certificate can be managed via the physical certificate repository for the SHIPKA PCDST.

Then the user can use the certificates stored in the SHIPKA PCDST in all applications requiring them in the same manner as if the certificates were stored in the system locally. As soon as the SHIPKA device is unplugged from the USB port, the certificates are no longer accessible to the user.

If the SHIPKA device is plugged in the USB port of another computer where the SHIPKA PCDST software is installed, the user automatically gains access to the certificates stored in the SHIPKA device (to be sure, if this is the owner knowing the PIN code but not just anyone who has seen the SHIPKA device that was left unattended near the PC). It is impossible to get the keys or certificates from SHIPKA in any other way.

Corporate users will appreciate the possibility to work with certificates signed by the certification authority. However, you may also need to share data with your friends - for personal needs - in a safe way. Then it is not very convenient to obtain and use certificates signed by the CA. First of all, certification authorities render their services on a paid basis. Second, you may be embarrassed by the fact that you will have to involve official authorized organizations in the process of private communication. Third, in case of any disruption in the CA's software or its erroneous functioning, data interchange between the users can be impaired.

If such interchange needs to be based on the certificate system but not on the "web of trust," it is much more convenient to use self-signed certificates. It is the user who issues the certificate, i.e. he or she generates it and signs using his or her own private key from the key pair. This enables the user to solve all of the above-mentioned problems: creation of such certificates does not entail any financial expenses and rules out participation of the certification authorities in the user's activities.

No matter which of the above-mentioned ways was used to obtain the certificate for the public key using SHIPKA PCDST, it can be used for any applications providing for the use of digital certificates.

Web of Trust

Let us return to the alternative to the Certification Authorities mentioned above - the "web of trust". A very simple idea underlies this system: you do not have to trust any organization to interchange data in a protected way with the people you trust.

To make sure my girlfriend's public key is authentic, it is sufficient for me to get the key directly from her, from hand to hand.

However, it is not always convenient to meet in person with all those people we would like to share data with in a safe way, and sometimes this might be impossible. However, there is a saying that all people of the world "know each other" through six people maximum. At the same time, we do not need all people of the world.

Let us say, you cannot meet a friend of you from the city of Mogilev in person but you need his public key now. If a mutual friend of yours has got his public key at his disposal (for example, he has just came back from Mogilev and got the key), he can provide you with the key both in person or by email having signed it by his own key you can rely on because you got it from hand to hand. The idea is clear: you verify the signature of the mutual friend of yours using the key you rely on, and if the signature is valid, the Mogilev friend's key signed by the signature has been delivered uncorrupted, and you can consider it to be authentic without having to go to Belarus.

Of course, it is not always convenient to turn to third parties (even if they are your friends) every time you need someone's public key. Therefore, when forming your own "web of trust" it might be expedient to have your public key signed by several users at once: their signatures can come in handy for some new subscriber to verify your key. For example, if five friends of mine have signed my key at once, I stand a fair chance that when I have to email my key to a sixth friend (if I cannot provide him with my key in person), this sixth friend will have the authentic public key of at least one of the five friends at his disposal.

If we delve into this system, which has already been said to underlie the OpenPGP standard PGP (Pretty Good Privacy) cryptographic software is based on, we need to distinguish between the trust in people and trust in keys. This seems to be obvious - how can we confuse a person and a key? However, we should keep in mind that when signing someone's key, we certify that this key is truly his but not that this guy is trustworthy. Similarly, the passport does not prove that its holder is a very moral person.

At the same time, this will be relevant if you are going to deploy quite an extensive "web of trust" involving a lot of people. Take it easy when you are going to interchange data in private, among your friends.

For example, you can protect your email communication in The Bat! email client using the PGP software. You can do this using SHIPKA PCDST as well. At the same time, this will improve the data interchange security level because key data are neither stored nor processed where intruders could get access to it. At first you will need to set up PGP for working with SHIPKA (this can be accomplished due to the fact that PKCS#11 library is built in the SHIPKA software, and PGP can be run using the library). Then you need to generate the keys and set up The BAT! for working with PGP. All of these procedures are easy to follow and are detailed in the SHIPKA PCDST User Manual. However, we must admit that setting PGP takes quite a lot of steps (though simple ones). That is why mainly advanced users apply this software.

At the same time, the concept of "web of trust" seems to be very appropriate to be used in private life but not only by gurus. Therefore, a landmark solution seems to be of current interest for users -a program running under SHIPKA according to the PGP logic but without any long-term settings or need to possess any special skills. This program is known as Privacy (ссылка!). It does not make a part of standard SHIPKA PCDST software: it is a stand-alone product. By using this application, you can manage keys, encrypt files and folders, create protected virtual disks and secure email or ICQ communication by means of electronic signatures or encryption. At the same time, you will not need to set up your email or ICQ clients in any way. It takes a minimum for the users to organize secure data interchange. In fact, this minimum adds up to the installation of the Privacy program by all users taking part in the interchange, and using it is a very simple thing due to its well-thought-out interface.

The public key infrastructure is developed just to enable everyone to use it. This makes sense for any infrastructure. This means there must be tools enabling the usage of such infrastructures not only by individual experts or in individual corporate systems. You must agree this would be totally absurd if employees were handed umbrellas in the company's gatehouse only having to use only very intricate devices to protect themselves against the rain outside of its territory. It is unlikely that the people would agree to get wet. You do not have to get wet. Developers are capable of offering easy to use solutions for cryptographic protection of private data.