SecureBlackbox 16: Introduction to Certificates

Content

• Introduction
• Types of Certificates and Certificate Authority Functions
• Certificate Fields
• Certificate Revocation List (CRL)
• How Do I Get a Certificate?
• Certificate Storage
• Storing Private Keys
• Uses of Certificates
• Signature
• Encryption
• Sign and Encrypt
• Secure File Storing

Introduction

Sometimes you need to be sure about the identity of the person you communicate with. This proposition holds for individual meetings as well as for data exchange. If someone you don't know comes to you and says that he is a reliable bank agent and wants to offer you a deal on beneficial terms, you will not take his word for it. You will require him to show his credentials; furthermore, you will try to ascertain as much about this bank as possible and you will use your own trustworthy sources of information.

Digital certificates allow the identification of persons or firms, so you don't need to take your communications with someone over the network at face value. Moreover, digital certificates permit transmitting encrypted data with the certainty that it can be read only by the person to whom it is addressed.

Two encryption methods are used today:

• Symmetric cryptography: One secret key is used for data encryption and then the same key is used for decryption. Some problems arise in this case, such as secure key transfer: many keys must be stored in a safe place and need to be easily accessible by the owner at any time.

• Public-key cryptography: A key pair is used, a private key and public key. These two keys are related with a mathematical expression so that data encrypted with one key from the pair can be decrypted only with the second one. There is no need to transfer keys in this case. Moreover, you need to care about the security of only one key.

Public-key cryptography brings its own set of problems. Suppose you get a message signed with a sender's private key. Can you really trust this information? Not entirely: in this situation, you can guarantee that the message and public key came from one place, but you cannot know where exactly.

Let us assume that your friend Alice sent you her public key, but Bob substituted it with his own. Then Bob sends you a message as if he were Alice. In that case, you cannot find out that the message was really written by Bob, as you think his public key to be Alice's one.

It is necessary to have the possibility of verifying the identity of the sender. How can you do this if you cannot get the public key from its owner directly? Certificates provide the solution: the main purpose of a certificate is to confirm that the public key belongs to its owner.

A certificate contains information about the person or organization to whom it belongs: the public key, information about the certificate issuer, time limits for when this certificate can be used, and the operations for which it can be used.

The private key is not a part of the certificate. Unlike certificates, the private key is not public. It is an element you must store securely.

There are several different certificate formats used. One of the most common is X.509. This type allows the use of a certificate for various purposes due to its wide distribution and numerous extensions. Such certificates can be used for encrypting messages, signing messages, verifying signatures, as an additional authentication system, or as a replacement for passwords. Furthermore, such certificates are used in the SSL protocol.

Each certificate contains some mandatory and some optional fields. To understand the functions of some of these fields you need to acquaint yourself with the Certificate Authority concept and certificate issuing technology.

Types of Certificates and Certificate Authority Functions

Certificates are made in two types in general: self-signed certificates you create yourself and those issued by a CA (certificate authority). Most systems, with the rare exception, distrust self-signed certificates. At the same time, self-signed certificates can be useful for creating an internal certificate structure in your company. But, this is beyond the scope of this article.

A CA is an organization whose functions include issuing and providing access to certificates, as well as certificate revocation. If you request a certificate, the CA will require confirming your identity by an appropriate method determined by the required level of security. For example, if you need the certificate only for personal use it can be enough to indicate your passport or another document number. But, a more serious purpose calls for stronger measures. Sometimes you can be required to provide a notarized paper document, for example.

After issuing the certificate, the CA must provide easy access and at the same time must guarantee that the certificate cannot be changed or revoked by an unauthorized person. Managing the whole information flow has gotten beyond the individual certificate authorities as certificates have gained more popularity and become more widespread. So, they have delegate authority to lower level CAs. That is, when you get the certificate, it is signed by a CA of the lowest level and it in turn has its own certificate issued by a CA of a higher level and confirming its right to issue certificates -- and so on, up to the root CA. But who identifies this root CA then? In that case, self-signed certificates are used; the root CA issues the certificate for itself. If you use a popular browser or mail client most likely it will contain a list of some certificates checked for trustworthiness, including ones for root CAs.

A corollary function of the CA is the capability to revoke the certificate. The need to revoke the certificate can arise out of the suspicion that someone else has got access to the private key or out of losing the certificate. Outside of the circumstances that call for certificate revocation, sometimes it can be useful to lock the certificate for a certain period of time.

Certificate Fields

Each certificate consists of the certificate body, the signature algorithm, and the CA signature itself. The certificate body includes several obligatory fields and there can be one or more additional fields depending on the certificate version.

You can find the following fields in most certificates:

• Version (1, 2, or 3): Certificates of the first version can contain only obligatory fields without any extensions or additional information. Unique subject and object identifiers were added in the second version. These fields enable reusing the same names several times. But it is not recommended to use these fields. Extensions were added in the third version. They allow you to concretize the area in which the certificate will be applied, and specify other parameters related to the certificate owner or the digital signature that the certificate must confirm. The number in this field is one less than the real certificate version as the numeration begins from zero.
• Serial number: Uniquely defines the certificate issued by the certificate authority.
• Signature : Identifies the algorithm used by the CA to sign the certificate.
• Issuer: Identifies the CA that issued the certificate.
• Subject: Information about the certificate owner. If one subject needs several different certificates signed by one CA, the certificates can have the same value in this field. Sometimes this field can be empty (i.e., when the key is associated only with an email address). In that case the subjectAltName extension must be used.
• Validity: The beginning and ending dates of the certificate's period of validity.
• Subject Public Key Info : The subject public key for the sake of which the certificate was created. Besides the key itself this field contains an algorithm identifier and the parameters within which this key must be used.
• Issuer Unique ID and Subject Unique ID: These fields uniquely identify the issuer and the subject. They are used when the Issuer and Subject fields contain the same values; however, the certificate is not self-signed.


• Extensions: A sequence of one or more certificate extensions. Each extension can be critical or not, standard or custom.


• Signature Algorithm: Contains the identifier for the cryptographic algorithm used by the CA to sign this certificate.


• Signature Value: The CA signature to confirm the certificate's validity and authenticity.

Certificate Revocation List (CRL)

The CRL is usually used to indicate revoked certificates. This list contains certificates that are not valid anymore for some reason but the certificate's period of validity has not finished yet. At the end of this period, the certificate is deleted from the CRL. Using CRLs is nonobligatory in general, if the CA can process revoked certificates in a different way. This article focuses on CRLs as this is the most commonly used.

Besides containing revoked certificates as stated above, each CRL must include the date of the next update. CRLs are usually updated with some frequency, e.g., once a day, once an hour, or once a week. The update rate depends on the certificate authority, but if the updates are too rare the security level decreases; this raises the possibility of accepting a certificate that was revoked but has not been added to the CRL yet.

Besides the certificates, CRLs include the following: An indication of the organization that issued and signed the list -- so, each CRL must the contain the issuer's signature and signature algorithm -- and the dates of the current and next updates. These dates are necessary for the CRL to be an actuality. CRLs also can have different extensions that allow flexibility and adaptability in the control system.

How Do I Get a Certificate?

You can get a certificate in one of several ways: You can issue a self-signed certificate yourself, you can get one from your company if it issues certificates for its workers, or you can request one from a certificate authority. The choice of method depends on your needs and purposes. If you are planning to use the certificate only for personal needs it can be quite enough to use a self-signed certificate, especially if you have the possibility to hand it over to your friends and partners. But, in this case you will need some knowledge of issuing certificates and some understanding of certificate fields and extensions. Otherwise, you risk creating a certificate that can't be used for your purposes. Outside of personal use, note that systems can deny authentication when a self-signed certificate is used.

Utilization of a certificate issued by your company has a number of advantages and disadvantages. As such a certificate will most likely be used for internal company needs -- for example, for limiting access to resources -- it can have some nonstandard extensions unsupported by other systems. Or, the range of its application can be limited.

It should be mentioned that there is a case in which some companies require a certificate issued by themselves for user authentication. You can most often find this practice among banks or software developers.

If you decide to use a universally recognized certificate authority, the actions you will have to take will depend on the rules of the authority and the security level you need. In the most simple case, (i.e., at www.thawte.com) you can get a certificate confirming your email address for free. You just have to pass a simple registration procedure during which you will need to enter your name, country, and, depending on the country, an identification code (a passport, a driver's license number, etc.) -- and the email address and password. The only thing you will have to do other than this is to get your certificate from the same computer and with the help of the same browser that you used to send the request. If you desire, you can set the extensions yourself but it's strongly recommended to do this only with a clear understanding of the process. On other systems using, for example, VeriSign, the registration procedure can be stricter and more time-consuming, as well as expensive. You can be required to provide a notarized document, for example.

Certificate Storage

The most easy and common place for storing certificates is System Windows Storage. But, it can occur that this storage does not provide you with the necessary security level. Even when you set the highest possible security level for your private key, such protection can be broken if someone can gain access to your computer. This gives an attacker the ability to change not only your own certificates but other certificates.

A better decision is to store your certificates and private keys outside of your computer. You can use a smart card or USB dongle for these purposes. This has some advantages:

• All your certificates are stored in one place. You don't need to search through different storages to find the certificate. Note that some applications can use their own storages; when you add a certificate to its storage, it is still unavailable for other applications and the system. When you use a USB dongle or smart card, you can access the certificates you need at any time. If some application cannot use external storages, you just have to export the certificate from one storage and then import it into another one.
• You are the only person who has access to the certificates. You carry your smart card or USB dongle with you, just like your home or car keys. You give it to no one. It is always protected by password. Even if your smart card or USB dongle is stolen, the criminal will have to find out the password before they can use it. For such devices, the password should be long and unusual.
• You need only one copy of each certificate. You do not need to install it on your home computer, computer in the office, notebook, or any other place. At the same time, you have access to it from any computer. Accessing your computer and discovering the private key password is of no use to an attacker as there is no installed certificate. You also do not need to install a certificate when you want to sign data.

Smart cards have their own disadvantages:

• If you use a smart card you will not be able to read information from without a smart card reader. A USB dongle in this respect is better as it can be used at any computer with a USB port. But, if you keep in external storage only certificates you use at the office, it can be more secure to use a smart card.
• If you are used to storing all kinds of data in one place, external storages can be disconcerting as they allow you to store only digital certificates. You could see this as a plus: you will keep only certificates there and will not access this device for other information. Or, you could subscribe to a different theory and store your password manager in the same secure place as your certificates.
• There is no possibility to export your private key from a smart card. So, if you by some reason need to install a certificate with its private key to another storage you will need to copy it in a different way.

Storing Private Keys

As stated above, the certificate itself, without a private key, has not much use. Several techniques for restoring a private key hinge on entrusting the private key's storage to an authorized delegate: This method can in no way be called ideal, as it is undesirable to give access to your private key to anyone, even to a trusted person. An improvement on this method is to divide the key into several parts and allot these parts to several trusted people so that it is possible to restore information only by bringing all the parts together. No one can restore your key alone. In this case, you must be able to approach all people involved at any moment. This can decrease the number of people needed to restore the key.

Another variation is to put your private key into a digital envelope and sign it with a trusted person's public key. If you lose the key, you can just ask this person to open the envelope with his private key. The common theme is that your trusted people must remain trusted and accessible.

The easiest and most comfortable way is to save your private key into a file, save this file on a disk, and store it in a secure place, for example, in a bank safe. If you lose the key, you can import it again from the drive.

But, losing your private key -- and your ability to access confidential information -- causes only a fraction of the trouble of an attacker knowing your private key.

The only thing you can do in that case is to revoke your certificate as soon as you have any suspicion that someone else can use it. You then create a new certificate and start over, providing top-level security for the corresponding private key.

To protect the private key, it must be private and secret. You must be the only one who can access it. But at the same time you need to have access to it at any moment.

Uses of Certificates

How do you profit from using certificates? When is it useful to sign or encrypt data? What problems can you avoid by using certificates? Learn how to use certificates to secure your digital communications in the following sections.

Signature

A digital signature enables you to send confidential messages to recipients, who can verify that only you could have sent the message. As the recipient confirming the authorship of the message, you protect yourself from the sender deserting the message. With a digital signature, you encrypt a message with your private key; you send encrypted and nonencrypted variants to the recipient. The recipient decrypts the encrypted message with your public key. If the result is equal to the original message, the recipient has proven that you sent the message.

It should be mentioned that when the whole message is used as a digital signature the information in transit doubles. Public key cryptography also adds time to the process of sending a message. Therefore, usually only a digest of a message is encrypted. The digest can be created from the initial message and has a small fixed length. The digest creation algorithm must meet several requirements. If one symbol changes in the initial message, the digest will vary considerably. It is practically impossible to find a message with a predetermined digest. These demands are necessary to make it impossible to touch up the signed message.

When a digest is used, the recipient needs software that will manage the following process:

1. Apply to the initial message the same algorithm that the sender did.
2. Use the sender's public key to decrypt the digest received.
3. Compare the two digests, which must be equal.

Encryption

Encryption ensures that the information transferred remains for the recipient's eyes only. The encryption process works around the fact that asymmetric algorithms are much slower than symmetric ones:

1. The message is encrypted with a symmetric algorithm using some secret key.
2. The secret key is encrypted with the recipient's public key and attached to the message.
3. The recipient needs to decrypts the secret key. The recipient does so with the corresponding private key and then decrypts the initial message.

Sign and Encrypt

Combining signing and encrypting operations guarantees both the privacy of the message and the identity of the sender. The order of operations can vary depending on the specific situation: You can sign a message and then encrypt it together with the signature, or, vice-versa, you can encrypt the message first and then sign the encrypted data. The second variant can be more preferable when a large amount of information comes in the form of encrypted messages, as signature verification does not require the whole message to be decoded and can be automated to a certain extent.

Storing Files Securely

Not only used in data transmission, certificates also provide a basis for storing files securely: Instead of protecting a file with a password, which can be lost to memory, you can extend the application of a private key you use elsewhere as well to protecting your files.