Making sense of PKI

The Public Key Infrastructure solves many security problems, but also introduces risks that require careful management. Nick Barron reports.

A basic knowledge of cryptology is important to understanding the Public Key Infrastructure (PKI). Cryptology is, in essence, the science of keeping secrets. The standard assumption of the designers of encryption systems is rather pessimistic. Not only is it assumed that the message has been intercepted, it is also assumed that the attacker knows exactly how the encryption works, and can even experiment with their own messages.

In fact, the only challenge facing the attacker is discovering the encryption key, and that is why the safe handling of keys is one of the hardest problems in cryptology (and business).

There are two fundamental types of encryption, and keys are handled differently in each. The first, most familiar type is called ‘secret key' or ‘symmetrical' encryption. In this type, the same key is used to encrypt and decrypt the data. The downside of this sort of encryption is the need to exchange keys in advance in a secure fashion. Ideally they should be changed often to limit the impact if an attacker discovers a key.

In ‘public key' encryption, there are two distinct but mathematically-related keys. A message encrypted with one key can only be decrypted using the other (hence they are usually referred to as ‘key pairs'). This neatly sidesteps the problem of distributing secret keys.

One part of the key pair, known as the ‘public key', is published to the world. There is no need to keep the public key secret, as it is only useful with the corresponding private key (which, as the name suggests, is kept secret).

Anyone wanting to send a secret message can encrypt it using the public key, safe in the knowledge that only the holder of the other half of the key pair, the ‘private key', can decrypt it.

You might wonder why, given the invention of public key systems, secret key encryption is used at all. The main reason is performance; in general terms, secret key algorithms are much faster than public key alternatives for a given level of protection. As a result, most systems make use of both public and secret key systems, typically using public key methods to exchange the keys for a much larger secret key message.

Public key encryption can be used for ensuring the authenticity of messages, as well as their privacy. By generating a fixed-length ‘digest' of the message, then encrypting it with the private key, any holder of the public key can retrieve the digest and verify the message. This provides no privacy, but it does prove that the message originated from the owner of the private key.

Because the digest is small, the normal performance issues associated with public key encryption are avoided, as only the digest is encrypted. This is referred to as a ‘digital signature', as it authenticates the message in a similar way to handwritten signatures on printed documents.

Messages protected by digital signatures do not have to be encrypted; indeed a common use for digital signatures is to authenticate security warnings from software vendors to prevent forgery.

Helpful as it is, public key encryption does not solve the entire key distribution problem. Key secrecy is not an issue, as the public key can be published freely. However, the authenticity of keys is still a major concern.

There's nothing to stop an imposter publishing a key purporting to be from someone else, and then silently intercepting messages and re-sending them to the target with the ‘real' public key.

So a key-distribution problem exists with public key systems, namely that two parties wanting to communicate still need first to exchange keys (of course with public key systems this is a one-off affair, which is an improvement). It is very important to know that the public key you have really does belong to who you think it does.

This is the problem that digital certificates attempt to solve. Like their paper-based counterparts, digital certificates bind a set of information with an identity. Digital signatures accomplish the same via public key encryption.

The information to be authenticated, typically the identity of a person or website and a related public key, is digitally signed to create a tamper-proof digital certificate. There is still one remaining problem though, namely who signs the certificate, and how can their keys be validated?

Signing certificates is performed by a ‘certification authority', or CA for short. At least one CA's public key must be ‘preinstalled' in order for certificates to be of practical use. For internet applications, a small number of high-level CAs have their public keys included with major web browser and operating system distributions.

For security reasons, the entry requirements to get your CA key included in this fashion are considerable. For Microsoft Windows, for example, an investment of around US$500,000. is required, making fraud unlikely. By including a range of ‘preloaded' CA certificates, the key-distribution problem is greatly reduced and, generally speaking, invisible to the end user.

Such ‘hierarchical' CAs are not the only way to distribute keys. PGP, the earliest widely-used email encryption package, adopts a less hierarchical and more ‘grass roots' approach (relatives of PGP such as the open source GPG also use a similar model).

Rather than using a small number of universally trusted CAs, PGP keys can be signed by other PGP users, establishing a ‘web of trust' for each key. Depending on the number of signatures attached to a public key and the level of trust in the ‘signers', PGP keys are given a sliding scale of trust.

PGP still uses a CA of sorts; there are a number of PGP ‘keyservers' that provide a central repository of keys. A key's presence in a keyserver does not give any guarantee of authenticity, so for proper trust a signature by a known associate is essential. For this reason, a private, carefully controlled keyserver is the preferred corporate solution.

In simple terms, a ‘public key infrastructure' (PKI) is the set of facilities that supports the creation, distribution and revocation of public keys and certificates. The majority of PKI solutions are certificate-based, and the predominant standard is ITU X.509, which is rather complex. Fortunately a detailed knowledge of X.509 is not necessary, as the complexities are managed by the PKI software.

The trickiest issue, how you prove that someone is who they claim to be, is sidestepped by the X.509 standard.

It is up to the individual CA to establish a certificate holder's identity, and of course different CAs may use different standards.

X.509 works relatively well for websites, which have a unique identity in the form of a fully qualified domain name such as www.scmagazine.com/uk, the uniqueness of which is already assured by the domain name system.

For human beings the situation is less straightforward, although in most cases an email address gives a reasonable assurance of uniqueness. There is still no universally accepted way to define the identity of a human being – or even a company – in X.509 terms.

X.509 does a passable job of providing a standard method to ask for a certificate, and a standard way of encoding it for delivery. Implementations are often less than perfect, and the standard is more open to interpretation than many, so interoperability of PKI applications is a frequent concern.
X.509 also allows some constraints on the usage of certificates.

For example, some certificates might be valid only for website use, whereas others will allow code signing, secure email and so on. These same controls apply to CA certificates, so if a CA is only approved for website certificates, any certificates signed by it will be limited to that role.

Revocation of certificates is a more troublesome issue. Although certificates are issued with an expiry date, the length of a certificate's validity is typically a year or more. If during that time the private key associated with the certificate is compromised, or the ‘owner' of the certificate leaves the company, it is necessary to revoke the certificate.

X.509's main method for handling revocation is using a regularly-published ‘blacklist' of certificates called a Certificate Revocation List or CRL. Before using a certificate, applications are supposed to check it against the CRL, which is regularly updated by the CA (and signed by it to prevent imposters from revoking certificates arbitrarily).

CRLs are far from perfect, as there is always a window of vulnerability between the revocation of a key and the updated CRL arriving at the client.

Downloading the CRL also uses valuable bandwidth, and for large organisations CRL distribution can be a major issue (for example, in 2004 a rush on VeriSign's CRL download site caused peak traffic of 1.5Gbps). To make matters worse, some more paranoid applications will refuse to accept any certificates if their CRL is out of date, resulting in an unintentional denial-of-service attack if CRL distribution fails.

Using CRLs in most browsers requires manual configuration, so their effectiveness is rather limited.

An alternative to CRLs is the Online Certificate Status Protocol or OCSP. OCSP uses an online check of a specific certificate to see if it has been revoked. OCSP is more efficient than the CRL process, as only one certificate at a time is checked, rather than a list of all revoked certificates from each CA.

Although far from universally supported, OCSP is growing in popularity and gradually replacing CRLs, providing a more workable and scalable revocation process.

Perhaps the biggest problem with PKI is the issue of trust. Certificates are often assumed to verify that the holder of the certificate is trustworthy. All that a certificate really does is bind some cryptographic key material with some identification information.

How much trust you place in it depends very much on the verification process used by the certificate issuer, often unknown without some non-trivial investigation. At the end of the certification chain you still have to trust the CA to have done its job properly. Trust in certificates still boils down to trust between people.

In the open source community, code signing of source and binary packages by GPG or PGP is relatively common. In most cases, users are encouraged to download the verification key from the same website distributing the source code.

In the event of a server compromise, both source code and signing key could be modified, leading to a false sense of security. Code signing is a valuable security precaution only if the authenticity of the key can be guaranteed; at a minimum, the keys should be retrieved from a keyserver, ideally signed by a trustworthy third party.

The presence of a CA-signed certificate implies that the site can be trusted. In fact, once the certificate is issued, the CA is not involved in the trust process. But when you connect to a ‘secure' site, your trust is really placed in how well the site administrator protects the certificate's private key and the site content.

It's not unheard of for a website with a CA-signed certificate to be attacked and used to host malicious content. The certificate should be seen as authenticating the site, not the safety of the site's content.

Similar problems affect code signing. Mobile code such as ActiveX in Windows and Java modules can be ‘signed' by the issuer. This is commonly thought to be a security feature, but in fact all it provides is a degree of accountability.

The CA who issues the signing certificate will never see the code that the certificate is used to sign. At best, all that using signed code means is that you know whose code has crashed your system; it often provides a false sense of security.

A common problem with certificate handling on the desktop is that many applications will handle certificates in their own unique way. Windows has its own certificate store, which is used by Internet Explorer, Outlook and other applications using the standard Windows crypto toolkit, but third-party browsers such as Firefox handle certificates internally, quite independently of Windows' store.

Fortunately, in the corporate world, many of these PKI problems are already covered. Existing human resources processes will have a company-approved method of establishing a person's identity and providing them with a unique ‘name' within the company (for example, their employee payroll number).
Providing a company-wide PKI can also avoid many of the interoperability problems that plague multi-vendor implementations.

Most modern businesses can benefit from some form of PKI. For email applications, a PGP-style keyserver approach with a trusted ‘corporate' key-signing authority is often adequate. For more complex requirements, where multiple types of public key are required, a more sophisticated X.509 system may be more suited.

Whatever solution is required, a more detailed understanding of the technical and non-technical issues will allow you to make a more educated choice.

See original article on scmagazineus.com

Copyright © SC Magazine, US edition

briefingmakingofpkisecuritysense