If you listen to the vendors, public key infrastructure (PKI) is a security panacea, worth every penny of your security budget and more.
Ask the critics and they'll mutter about chocolate teapots, sledgehammers to crack nuts and other derogatory figures of speech.
For the majority of security practitioners PKI sits somewhere between these two extremes, often filed away under the heading of 'potentially useful, but do I really need one?'
So, what is PKI?
Basically a PKI is a collection of technologies, processes, and organisational policies that support the use of public key cryptography (see box) and in particular the means to verify the authenticity of public keys.
Digital certificates provide a link between a particular individual or system and their public key, and this certificate is signed by a certificate authority, so that anyone who trusts that authority will also trust that the corresponding key pair is genuine.
OK, so what does it do?
If you've ever bought something on the internet the chances are that PKI was used to protect your credit card details from the miscreants and mischief-makers who prowl the World Wide Web.
The padlock in the corner of your browser window signifies that PKI has been used to authenticate the web server, and to set up a shared symmetric key to protect your communications with that server.
Another increasingly important application of PKI is the provision of secure email. A quick browse through your daily helping of spam might suggest that 'secure email' is an oxymoron as it is clearly trivial for one user to masquerade as another (unless Bill Gates and President Bush are really trying to get in touch...).
Although a little more difficult, there is a chance that unprotected email can be intercepted, read and modified.
Many organisations are coming to realise that if they want to continue to rely on email as their primary communications mechanism, they had better protect their emails in some way. This is especially true where emails may be audited, used as evidence in court and so on.
One possible solution is to use PKI to enable users to sign and encrypt email. A digital signature prevents masquerade by authenticating the sender, and alerts the recipient to any modifications made to the email en route (thereby ensuring message integrity).
It also makes it difficult for a user to deny having sent the email (a service usually referred to as non-repudiation). Encrypting the email prevents it being read by anyone other than the intended recipient (preserving its confidentiality).
And there are many other applications of PKI, from authentication (in virtual private networks, wireless LANs and system logon) to controlling the distribution of information with digital rights management.
A wide range of organisations are choosing to deploy PKI solutions, including defence organisations, UK public sector bodies and large private sector companies (like the Volvo Group who recently deployed a PKI to deliver email authentication, integrity and encryption capabilities to 80,000 employees worldwide).
So what's the 'infrastructure' bit all about?
The big problem with public key cryptography is how to verify the authenticity of public keys. A mechanism is needed to guarantee that a public key really belongs to a particular individual; that they know the corresponding private key; and that their key is 'valid' (that is, it hasn't expired, been revoked and so on). This is where the infrastructure - the 'I' in PKI - is so important.
As illustrated in Figure 1 the infrastructure consists of several different components, interacting to provide the necessary assurance in public keys.
A key component (if you’ll excuse the pun) of any PKI is the digital certificate, which links the name of an individual - known in PKI-land as a subscriber - to their public key.
The certificate authority (CA) that issues the digital certificate signs it using its own private key: this signature not only proves that the CA created the certificate but also ensures that any modifications - for instance replacing the public key in the certificate with another one - will be apparent to anyone who relies on it (a so-called relying party).
Of course to verify the signature on a digital certificate, the relying party uses the CA's public key, and so needs to trust the authenticity of that public key. This might involve validating the signature of a higher CA, which issued a certificate to the subordinate CA.
Clearly there must be a CA at the top of the hierarchy and the relying party needs to implicitly trust the public key of this 'root' CA.
Are there any problems with PKI?
As with all technologies PKI introduces some challenges. For instance, every time a relying party uses a public key, they need to check that it hasn't been revoked: ensuring that all users have access to an up-to-date revocation list (without using up all available bandwidth) can be a real headache. Key pairs have only limited lifetimes and the process of certificate 'rollover' needs careful thought to ensure it is both efficient and secure.
Smart cards or tokens might be required to protect subscribers' private keys, and keys belonging to a CA might require more substantial protection (using a hardware security module for example) ' all this will add to the overall cost.
That sounds like a lot of bother. Do I really need a PKI?
It is incredibly difficult to draw any general conclusions about PKI because it can be used in so many different ways. Implementing an organisation-wide PKI for multiple applications can be a serious undertaking, requiring significant investment and commitment, while deploying a dedicated PKI for, say, secure VPN access for a small number of home-workers can be achieved in an afternoon (with practice).
So before asking whether you need one, a first step is to identify the problem(s) that you need to solve. For many individual requirements it will be possible to identify a suitable technology that does not rely on PKI. The exception is the provision of digital signatures - PKI is the only technology capable of supporting them in a secure and scalable way.
Applications are increasingly designed to exploit the benefits of PKI, making the technology more desirable from an interoperability point of view, and the ability to control a user’s credentials from within a common, standardised framework can be extremely valuable.
This is particularly true if that user misbehaves or leaves the organisation as there is just a single place from which to withdraw their privileges.
Right, I'm off to buy one right away
Just before you go, you might be interested to know that, in addition to some very capable COTS solutions, a number of open source PKI offerings are available providing everything you need for a DIY PKI.
Also it is worth investigating whether any of the software that you currently own has inbuilt PKI functionality (Microsoft Windows 2003 Server, for example, has inbuilt CA, RA and directory services).
Even if these products don't meet your requirements they offer an opportunity to test the capabilities of PKI and decide whether a solution offering greater functionality would be worth the investment.
