SecureBlackbox 16: Certificate Basics

Content

• Definition
• Features and possible uses
• Certificate management
• Supplementary services
• Certificate structure
• X.509 certificate
• X.509.2 extensions
• X.509.3 extensions
• Conclusions

Definition

Two types of encryption algorithms are used with digital certificates - symmetric and asymmetric. Symmetric encryption algorithms deal with one secret key used to both encrypt and decrypt information. Asymmetric algorithms usually deal with a pair of keys, one that is private (secret) and another one that is public (known to everybody).

Certificates are a block of information in a standard format that contains a public key and supplementary information about this key. In a broader meaning, certificates can also include an associated private key. The private key is not a part of the certificate binary data, but logically they create one entity.

There exist different certificate formats that are designed for different applications. The most well-known formats are PGP and X.509 certificates. X.509 certificates are used in the SSL/TLS protocol, which is the basis for secure internet communications. The format of X.509 certificates is defined in RFC 2459.

The X.509 certificate structure is defined using Abstract Syntax Notation 1 (ASN.1). This notation allows uniform identification of binary data structures on any system, not dependent on byte size and byte order. The details of the structure can be found below.

Features and possible uses

The certificate contains the following information:

• Information about the person or organization the certificate was issued to
• Information about the organization that issued the certificate
• Date range when the certificate is valid
• (Optional) information that lets the application automatically verify the validity of the certificate and find out whether the certificate was revoked

Also, the certificate can contain predefined or user-defined information about the intended use of the certificate. This means that the application can find out the user's credentials and the scope of operations that the user is permitted to perform. Each application can define its own flags for the certificates it uses or manages.

Due to its nature, certificates are currently the best choice for authenticating the person and information that is distributed by this person and also for defining the scope of operations allowed for the person.

Certificates are indispensable for providing an easy-to-manage access control system for client-server and n-tier applications. In this scenario the server issues certificates in which it places information about the allowed uses of the certificate. Certificates together with their private keys are a good alternative to regular username/password pairs. When the user connects to the server, it uses the certificate in the process of establishing a connection with the server. The server is able not only to validate the user's authenticity, but also determine what actions this user is allowed to take or to which user group it belongs.

Utilizing the SSL/TLS protocol is the best way to involve the certificates into the "conversation", but if your middleware doesn't provide an easy way to add SSL to the data exchange, you will need to manage the certificates by hand. In both cases the SecureBlackbox package will assist you in certificate management. And if you need SSL, SecureBlackbox is a complete SSL/TLS solution.

Certificate management

The creation of the certificate is called issuing. The organizations that issue certificates are called Certificate Authorities (CA). The person or organization the certificate is given (issued) to is called the Subject.

The certificate is valid during some time period. If the certificate is used outside of this time period, it is either "not yet valid" or "expired".

When the certificate is issued, the certificate authority signs it and the signature of this certificate authority is put to the certificate.

The certificate authority can claim the certificate to be not valid anymore in some cases, for example, when the Subject claims that the certificate's private key was stolen. Another case is when the Certificate Authority's private key has become known to third parties and the signature doesn't identify authenticity anymore. Such a certificate is called revoked. The certificate authority keeps the list of revoked certificates and each certificate can contain the address (URI) of the certificate revocation list.

There can be several types of CAs. If you utilize certificates for some n-tier software solution (for authentication/security purposes), the certificates will most likely be generated by the server part of the software solution. In this case the user of the server part will act as a CA. If the certificate is issued by some organization to itself (i.e., the CA is the Subject), the certificate is called self-signed.

If the data exchange in which the certificates are involved is public (i.e., more than one organization participates in the process), self-signed certificates are a security compromise. The side that receives the certificate during the data exchange session can't reliably verify the identity of the other side unless there is some repository that can confirm the identity of that other side. The certificate authority itself is a good repository. There are several commercial organizations that issue and manage certificates (most of them are affiliates of the VeriSign company). They act as certificate repositories and their authenticity is well known to the public.

Certificate authorities that publicly issue certificates usually require that the person who requests the certificate prove his or her identity by passing regular (paper) documents (passport, driver's license, etc.).

Another type of public activity that involves certificates is electronic document signature or encryption. In this case there is one party that signs/encrypts the data, and any number of parties that get the information must check it for validity.

When one side of the data exchange session receives the certificate from other side, it is supposed to validate the certificate, i.e., check the following:

• The certificate integrity must not be corrupted. Each certificate contains the data that can be used to check certificate integrity. Information in a corrupted certificate can't be used at all.
• If the certificate is not self-signed, the CA's authenticity should be verified. This is done by looking for this CA's certificate in the repository. The repository can be local to the application that validates the certificate (for example, the Windows 32 API provides an API for accessing built-in Windows certificate storage). Custom storage can be used (it can be located on other systems including public certificate repositories. If the certificate is found, we use the CA certificate to validate the certificate in question. If the certificate is not found, we can't confirm the authenticity of the certificate in question.
• The certificate validity time period must correspond to the data signing/encryption time. One should not use expired or not-yet-valid certificates to sign/encrypt the data.
• The certificate should not be present in the certificate revocation list. As mentioned, each certificate can contain a reference to the certificate revocation list. The validating side should check the list if the reference is present. If the certificate is not self-signed and there is no reference to the certificate revocation list inside, it is possible to check the CA's certificate for such a reference and use it instead.
• (Optional). The certificate purpose must correspond to the action being certified. Each certificate can have a list of purposes for which it is applicable.

Usually, certificates are only valid if all of the above conditions are true. If any of the conditions are false, the data source can't be fully trusted. SecureBlackbox offers methods to validate the certificate (except revocation list lookup).

Supplementary services

One of the most important actions in certificate management is key recovery.

When the key is lost (because of data storage corruption or some accident or because it is just erased by mistake), it's probably lost forever. This means that if the key pair was used to encrypt the data, the data is also unrecoverable. One of the ways to prevent this is to put the key (or key pair) to the digital envelope and store this envelope somewhere. The envelope, however, must be secure too. This is achieved by involving a third party (trusted person) to the process. The trusted person gives his or her public key for envelope creation. The trusted person doesn't necessarily have access to the envelope. If the original key is lost, the owner of the envelope can contact the trusted person, who will apply its secret key to the envelope and open the envelope.

The disadvantage is that the trusted person must remain trusted and available. If its security is compromised or the person becomes unavailable, all users of the trusted person's services must recreate their envelopes. To overcome the security risk of involving a trusted person it is possible to involve several trusted persons. Each person's public key is used to encrypt only a part of the information being secured (either the secret key or symmetric key). Then a single person can't discover the secret information as he or she doesn't have access to the secured data (secret key or symmetric key).

When it is necessary to recover the key, each of those persons should be contacted to decrypt part of the envelope. Unfortunately in this case if any of those persons becomes unavailable, the whole envelope is useless.

In business it makes sense to use key recovery services, which are provided by public companies. These companies can be related to certificate authorities somehow or can be independent organizations. As with the trusted person mentioned above, the recovery service can have access to the keys used for signing documents or to decrypt data. The benefit of the recovery service is that it usually has a secure infrastructure for key keeping and transfer.

If the certificate authority (CA) issues or plans to issue lots of certificates, it makes sense to delegate some of its functions to registration authorities. Those authorities receive certificate requests from the organizations or individuals, check their identity, and issue certificates. They also manage certificate revocation lists and reissue expired certificates.

Certificate management is quite a complicated thing, which can involve other types of services and actions. We don't review them here because the topic is enough for a book, not just an article.

Certificate structure

X.509 defines the following blocks of data in the certificate:

• Version. This is the version of the certificate format. Currently this can be 1, 2, and 3.
• Certificate serial number.
• Signature algorithm identifier, which identifies the algorithm used to sign the certificate and parameters for the algorithm.
• Issuer name. This is the name of the company that has issued (generated and signed) the certificate.
• Validity period. This field defines the lifetime of the certificate.
• Subject name. This field contains the name of the person/company the certificate is issued to.
• Public key information. This field contains the body of the public key, information about its algorithm, and parameters.
• Extensions (see below).
• Signature algorithm identifier (the same as described above).
• Signature value (body of the signature).

There were several revisions of the certificate standard. The latest is X.509.3. Revisions 2 and 3 define extensions to the original format.

Extensions can be critical or noncritical. If they are critical, an application that doesn't handle such an extension should not process such a certificate further. Noncritical extensions can be ignored.

The certificate itself contains a flag that defines whether the certificate extension is critical or noncritical.

X.509.2 defines the following extensions:

• Issuer Unique Identifier
• Subject Unique Identifier

X.509.2 extensions are not currently recommended for use by RFC 2459.

X.509.3 defines the following extensions:

• Authority Key Identifier. Critical for certificates that are not self-signed.
• Subject Key Identifier. Critical for certificates that are not self-signed and recommended for self-signed certificates.
• Key Usage. This field is used to restrict the set of operations for which the certificate is eligible. The standard recommends flagging this extension as critical.
• Extended Key usage. This field is similar to the Key Usage field, but RFC 2459 doesn't constrain the possible values of this field and any application can define its own flags.
• CRL Distribution Points. This is the URL of the certificate revocation list, which can be used to check the validity of the certificate. This extension is noncritical, but it is recommended that applications support it.
• Private Key usage period. This field defines the lifetime of the private key associated with the certificate. If the field is not present, the lifetime is the same as the lifetime of the certificate itself. RFC 2459 doesn't recommend using this field.
• Other, more specific extensions. A full list can be found in RFC 2459.

Conclusions

Certificates are a very powerful and advanced technology, which, when used properly, can provide the highest level of security in many areas of electronic activity. Basic certificate management, though, needn't be too complicated. The SecureBlackbox components provide straightforward certificate management and a complete TLS/SSL solution for applications on any platform.