About keys and certificates

About keys and certificates

Non-experts know about cryptography just as much as they need to use it in practice. It is clear that we need to encrypt files to prevent them from being read by outsiders, and we should use electronic signatures for our mail to verify its authenticity and integrity. As for cryptographic keys, they do not seem to be directly related to practice. Therefore, they are difficult to understand.

In fact, they are quite simple.

Basic concepts

A cryptographic key is a set of unique data controlling the cryptographic transformation process (encryption, decryption, electronic signature generation and verification, etc.). To decrypt the message "dcoe" encrypted based on the permutation method, you need the key used to encrypt it ("3124"). Having the key at your disposal, you can arrange the letters in the appropriate order and get the original word "code." The nature of the data being the key can vary. For example, in case of encryption by the permutation method the key is the order of permutated elements, and in case of signature based on the RSA algorithm the key is the exponent.

Cryptography can be symmetric and asymmetric depending on the keys and process organization.

To encrypt a message or provide it with electronic signature, you need to select the key. To decrypt an encrypted message or verify its electronic signature, you must know the key. Equal keys result in symmetric transformation while different keys lead to asymmetric transformation.

One key is less than two. This seams to simplify the process but all people taking part in such correspondence must keep the key secret. This represents a problem: if many people have access to the key, it is very difficult to locate the leak.

According to Russian regulatory documents, encryption can be both symmetric and asymmetric while electronic signatures can be only asymmetric.

Public key systems

To enable two people to exchange confidential information in a safe way, one of them needs to generate a key and provide it to the other person. At the same time, the key is confidential information that needs to be provided in a secure way! The circle is closed now.

To solve the problem of key distribution, public key systems were suggested.

The idea is that each addressee generates two keys interconnected according to a certain (mathematic) rule. One key is public, and the other one is private. The public key is published and is available to everyone who is going to share information with the given addressee. The private key is kept secret.

The source text is encrypted using the addressee's public key and transferred to him or her. The text encrypted this way cannot be decrypted using the public key. To do so, a private key is needed, and only the addressee has access to it.

As for electronic signatures for messages, the situation is quite opposite: the message is signed using the private key, and everyone having the proper public key can verify the electronic signature (and make sure the message is authentic).

Public and private keys are interrelated based on irreversible or one-sided functions characterized by the following: given the value of x is known, it is easy to calculate the value of y=f(x) but if the value of y is known, there are no easy ways to calculate the x value from y=f(x).

It is clear that to ensure large-scale prevalence of public key cryptography, a legitimate and functioning system of rules for using and maintaining such keys is needed. Such infrastructure is known as PKI (public key infrastructure).

Public key infrastructure. Digital certificates.

Thus, public keys are communicated in unprotected channels, so reasonable doubts may arise as to their authenticity. There are no intrinsic properties in public keys to establish their relevance to the user, and it is impossible to make sure in any empirical way that this is the very key that was sent by the given user and not anyone else. This implies that if there is anyone wishing to interfere with the communication, he can attempt to replace public keys. If he succeeds in doing so, electronic signatures belonging to the parties to the communication will always be incorrect. On the contrary, signatures forming a part of the intruder's messages sent in the name of some bona fide communication parties will be recognized as correct.

You can pass the key from hand to hand but this is not always convenient and not always absolutely secure. Moreover, an unfair user can always say this key is not his if he does not feel like recognizing his authorship confirmed by the electronic signature.

There may also be a situation when the public key is authentic but the private one is corrupted (for example, the carrier with the electronic signature is lost, missing or stolen).

This means we need a mechanism for a reliable association between the public key and the user and legalization of this key.

That is, there needs to be someone to authorize the "user + his public key" pair. Certification Authorities (CAs) do this by issuing digital certificates. A digital certificate is the "username + public key" pair signed by the electronic signature of the Certification Authority.

Needless to say, CAs must have good reputation as well as appropriate technical and organizational facilities at their disposal to promptly issue and recall certificates without the need in any particular user skills or knowledge.

Flow of electronic documents

When we analyze different electronic signature patterns, the question arises: "Can we promptly pick up two different (meaningful) messages with the same electronic signatures?" The answer is usually negative: this is difficult to achieve. At the same time, it turns out that having two messages, it is possible to pick up private keys so that the signatures were identical. The consequences of this can be very serious.

Here is an example of the intruder's actions:

1. Prepare two payment obligations (m1 and m2):

         for the amount of 10,000,000 rubles (m1);

         for the amount of 3 rubles (m2).

2. Pick up the X1 private key and calculate the X2 key when electronic signatures (с1 and с2) of messages m1 and m2 would be identical (с1 = с2).

3. Register public keys complying with the private one.

4. Submit order m1 with signature X1 (m1c1) to the bank.

5. Wait until the bank fulfills the order.

6. Lodge a claim with the bank saying that he allegedly submitted the order to transfer 3 rubles (m2c2) instead of 10,000,000 rubles (m1c1), and it is no concern of his that someone had corrupted the message without changing the electronic signature. The bank, certification authority or insurance company has to pay just to repay the money. In fact, they will have to pay!

Why can such an attack be successful? The point is that the Federal Law about Electronic Digital Signatures allows one person to have numerous electronic signatures (Article 4, Clause 2). Therefore, the intruder can pick up and register the key, and do this legally, instead of picking up the message, which is very difficult. In addition, it is not improbable that two persons can form a confederacy. The electronic signature becomes vulnerable if the private key becomes known to anyone! What if two certification authorities form a confederacy?

However, the situation is not that awful. In fact, all this does not discredit the cryptographic security of electronic signatures. This proves they can be vulnerable in case electronic signature mechanisms are misused. In this connection, special attention must be paid to ways of organizing secure flow of documents based on electronic signatures.

There is a radical way to control such attacks. You just need a device, which:

1. Generates a private key.

2. Calculates the public key.

3. Exports the public key including for certification by the certification authority.

4. Uses the private key only to generate the electronic signature only inside the device, and it becomes impossible to export it!

If this is the case, you cannot know in advance what keys you will get as a result. Since the device does not export private keys, it is impossible to calculate the private key, the public key for which is identical to the available one.

SHIPKA PCDST is the device you need.

Key life cycle

The life cycle of a cryptographic key comprises the following stages: generation, storage, usage and deletion. Abuses may be possible at each of these stages, and we must avoid them.

The intruder can get access to a key, which is generated in an insecure medium or using an insecure mechanism, or he can even provide the key to you.

It is not only insecure but also inconvenient to store cryptographic keys on the PC because you can need them not only on the specific computer, and anyone who has logged in as the legal owner can use the keys on his behalf. If keys are stored on portable carriers, you must be sure no one can use the key if the carrier is lost or stolen. For this purpose, the carrier must have a high security level, and it must also provide for the possibility to recall the public key certificate for the corrupted or deleted key pair in a prompt and secure manner.

When it is the question of carrier safety, it is usually understood as impossibility for the intruder to get access to someone else's key. At the same time, in addition to getting access to the key, the intruder can destroy or corrupt it, which will have unpleasant consequences as well.

The intruder can snatch the key that is stored safely (for example, in an encrypted form) if cryptographic transformation is carried out in an insecure medium, for example, in the computer processor because the key is stored in the random access memory in an accessible form during the transformation.

SHIPKA PCDST enables you to avoid such bottlenecks.

Generation

A new and uninitialized device has no keys or random sequences to be saved in advance. SHIPKA generates keys intrinsically using a physical random number generator.

Key generation using SHIPKA PCDST is a simple procedure taking minimum time and efforts. At the same time, you will not have to remember what keys you have used for any transformations or what public key matches some certificate: the device will never confuse keys or certificates.

We would like to remind you that you can assign descriptions in any language you like to your keys in SHIPKA PCDST for convenient usage (first of all, for sharing the keys with the people you are going to exchange information with). For example: "for Alexander" or "email."

The Key Management utility in SHIPKA PCDST is designed for working with keys without using the PKI space, i.e. when you need to share public keys directly, without any digital certificates, or when you want to share session encryption keys for sharing encrypted messages, again without using certificates, as well as if you are going to encrypt and decrypt files (and/or sign them with electronic signature and verify it) using the same SHIPKA device.

If you plan to use PKI (having obtained a digital certificate), you need to generate a key pair in SHIPKA PCDST in some other way.

To obtain a certificate from the Certification Authority for the public key of the key pair generated by SHIPKA, you need to generate the key pair using the CA's software by selecting the Shipka Base Cryptographic Provider option in the CSP dropdown list.

The cryptographic provider of SHIPKA PCDST is signed with the Microsoft electronic signature, which confirms its full operational capability within the family of operating systems including WinCE.

The key pair will be generated directly in SHIPKA, and the public key certificate will be saved to it as well. The certificate can be saved to special repositories on the computer in the course of obtaining it (using the CA's software) or to some other computer later, so you will always have it at hand in your SHIPKA. At the first glance, this option may seem trifle but everyone who has ever had to think on the eve of his or her business trip or vacations whether he or she would need the certificates and whether he or she has to copy them to some carrier will appreciate this.

In addition to obtaining certificates from a CA, SHIPKA PCDST provides for the possibility to obtain self-signed certificates.

 

Self-signed certificates are quite good for organizing secure exchange of confidential information for private purposes. However, if it is the question of organizing the flow of electronic legal documents, certificates must be issued by CAs.

Application

To organize secure data interchange between two users directly (without using the PKI interface), they need to interchange the keys. The SHIPKA PCDST features a simple procedure, which is detailed in the manual, to interchange public keys and symmetric encryption keys between two SHIPKAs.

Select the key to be transmitted in the Key Management window of the sender's SHIPKA and click the Export button (the key with the green minus). A window where you can define where exactly you are going to save the exported key will be displayed. It is reasonable to save it in the default folder. This is convenient because another SHIPKA device will be searching for the file for key import in this folder. When keys are interchanged by means of connecting different SHIPKAs to the same computer, this is quite useful. Public keys are saved by default as publickey.bin. You can rename them whenever necessary (for example, if you need to export several keys). Having plugged in the recipient's SHIPKA, click the Import button (the key with the red plus) in the same window. At first the window for selecting a key from the keys found in the folder will be displayed (if you have saved the key in a folder which is different from the default one, please specify the necessary folder). Then the window where you can enter a description for the key, which will match the key in the recipient's SHIPKA, will be displayed (to be sure, the description entered in the sender's SHIPKA when the key was generated will not be displayed in the recipient's SHIPKA).

The symmetric key is exported in an encrypted form. It is encrypted based on the recipient's public key and decrypted using the appropriate private key. This means that the sender of the symmetric key must have the recipient's public key in advance.

Select the symmetric key to be transmitted in the Key Management window of the sender's SHIPKA and click the Export button (the key with the green minus). Select the public key received from the SHIPKA of the symmetric key recipient in the Symmetric Key Export window in the field "Select a public key to export the symmetric key" (otherwise the recipient will not be able to decrypt it, and SHIPKA will display an error message). Click the Import button (the key with the red plus) in the Key Management window of the recipient's SHIPKA. The window for selecting a key from the keys found in the folder will be displayed (if you have saved the key in a folder which is different from the default one, please specify the necessary folder). Encrypted symmetric keys are saved to sessionkey.bin file by default. This filename (session key) is related to the fact that it is recommended to encrypt only one communication session. It is advisable to generate a new key to be used the next time for safety purposes. The recipient's SHIPKA automatically finds the public key required for decryption in the respective field of the Symmetric Key Import window. There is a field to describe the key in the bottom right-hand part of the window. It is expedient to provide the key with a clear description in order not to confuse it with other symmetric keys and not to jeopardize communication.

To enable the key transfer to another device, mark the key as exportable during its generation. Exportable keys are transferred outside only in a protected form, and keys that are marked as non-exportable will never leave the device.

The key the user plans to operate with is selected with the light pen. It can be seen in the pictures that when you have selected an exportable key the Export button (the key with the green minus) is active while when you have selected a key which is marked as non-exportable, the button is inactive (the icon becomes dim and the mouse cursor does not respond). If you have selected a private key (even if it is marked as exportable), the button is inactive because SHIPKA will never export private keys.

Keys never leave the device in the course of cryptographic calculations as well: the SHIPKA processor that is active and independent of the computer handles the process in full, and keys will never get in the computer random access memory.

Storage and deletion

There are two individual memory units in the SHIPKA PCDST: inside the processor and outside the processor (but also within the device).

The user's keys are stored in the file system of the SHIPKA external memory in an encrypted form. It is impossible to get access to the keys as file system objects, which means you can neither read the key file as a data file (see the code in the file) nor save any data to it as in a file (i.e. corrupt the key) or delete it as a file. Keys stored in the SHIPKA PCDST can be used only in strict compliance with the documented functions and using special SHIPKA software.

Of course, this does not mean that all keys that are not needed any more will remain in memory forever occupying its free space. The SHIPKA owner can delete keys, key pairs and certificates using the Key Management (in "File encryption and signature") and Certificate Viewer utilities, respectively.

Keys used to encrypt the user's keys are stored in the memory of the SHIPKA processor. In theory, it is possible to get access to data stored in the memory. However, this is a very complicated and expensive task, which nearly always results in complete destruction of the memory and data loss. Therefore, this key storage system can be considered to be quite reliable.