Certificate basics

Problem/Question/Abstract:

Key management can be an issue in security-related tasks. Certificates define a standard way of managing keys and associated information. They are also used in SSL/TLS protocol and S/MIME.

Answer:

Definition

Two types of encryption algorithms are used - symmetric and asymmetric. Symmetric encryption algorithms deal with one secret key, which is used to both encrypt and decrypt information. Asymmetric algorithms usually deal with a pair of keys, one of which is private (secret) and another one is public (known to everybody). Certificate is a block of information in standard format that contains a public key and supplementary information about this key. In broader meaning certificate can also include an associated private key. The private key is not the part of certificate binary data, but logically they create one entity.

There exist different certificate formats, designed for different applications. Most known formats are PGP and X.509. X.509 certificates are used in SSL/TLS protocol, which is the base for secure Internet communications. Format of X.509 certificates is defined in RFC 2459.

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 from 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, to which it was issued,

Information about the organization that issued the certificate

Date range when the certificate is valid.

(Optional) information, which lets the application automatically verify validity of the certificate and find out whether the certificate was revoked.

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

Due to its nature, certificate is 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 to the person.

Certificates are indispensable for providing 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 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 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 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 data exchange, you will need to manage certificates by hand. In both cases SecureBlackbox package will assist you in certificate management. And if you need SSL, SecureBlackbox is a complete SSL/TLS solution.

Certificate management

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

The certificate is valid during some time period. If the certificate is used out 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.

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

There can be several type 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, which receives the certificate during data exchange session, can't reliably verify the identity of the other side unless there is some repository, which can confirm the identity of that other side. Certificate Authority itself is a good repository. There are several commercial organizations that issue and manage certificates (most of them are affiliates of VeriSign company). They act as certificate repositories and their authenticity is well known to public.

Certificate authorities, that publicly issue certificates, usually require that the person, who requests the certificate, prove his 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 and must check it for validity.

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

Certificate integrity must not be corrupted. Each certificate contains the data that can be used to check certificate integrity. Information in corrupted certificate can't be used at all;

If the certificate is not self-signed, CA's authenticity should be verified either. This is done by looking for this CA's certificate in the repository. Repository can be local to the application that validates the certificate (for example Windows 32 API provides API for accessing built-in Windows certificate storage). Custom storage can be used (it can be located on other system including public certificate repositories. If the certificate is found, we use CA certificate to validate the certificate in question. If the certificate is not found, we can't confirm authenticity of the certificate in question;

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;

Certificate should not be present in certificate revocation list. As mentioned, each certificate can contain the 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 certificate revocation list inside, it is possible to check the CA's certificate for such a reference and use it instead.

(optional). Certificate purpose must correspond to the action being certified. Each certificate can have a list of purposes, for which it is applicable.

Usually, certificate is only valid if all of the above conditions are true. If any of conditions is 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 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. Trusted person gives it's public key for envelope creation. Trusted person itself 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 it's secret key to the envelope and open the envelope.

The disadvantage is that the trusted person must remain trusted and it must remain available. If its security is compromised or the person becomes unavailable, all users of 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 (it's either secret key or symmetric key). Then single person can't discover the secret information even when it has the

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 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 re-issue 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 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 lifetime of the certificate.

Subject name. This field contains the name of the person/company, to which the certificate is issued.

Public key information. 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 certificate standard. The latest is X.509.3. Revisions 2 and 3 define extensions to the original format.

Extensions can be critical or non-critical. If they are critical, the application, which doesn't handle such extension, should not process such certificate further. Non-critical extensions can be ignored.

The certificate itself contains a flag, which defines whether certificate extension is critical or non- critical.

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 not self-signed certificates.

Subject Key Identifier. Critical for not self-signed certificates 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 Key Usage field, but RFC 2459 doesn't constrain possible values of this field and any application can define it's own flags.

CRL Distribution Points. This is the URL of the certificate revocation list, which can be used to check validity of the certificate. This extension is non-critical, but it is recommended that the 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. Full list can be found in RFC 2459


Conclusions

Certificates are 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, is not too complicated thing and can be done by any application, especially with the help of SecureBlackbox package.


Component Download: http://www.secureblackbox.com/files/blackboxeval.zip