PKI (Public Key Infrastructure) - an explanation

Public key cryptography is the perfect solution for ensuring the privacy of data employed in distributed systems of all kinds. This is especially true in the kinds of systems implemented as part of e-commerce solutions, where organisations are engaging in transactions with individuals who are hitherto unknown to them, and with whom they may never have any further contact.When choosing a PKI system, there are a number of features to watch out for. It is easy to pass a certificate server off as a PKI solution, and the terminology is not entirely inaccurate.

Most certificate products, however, are focused primarily on the creation, publication, and management of certificates. Products such as Netscape Certificate Server and Microsoft Certificate Server, for example, enable managers to generate “root” keys used to sign the certificates they generate. Both allow details of the certificates generated to be published in a directory and support the use of Certificate Revocation Lists (CRL).

All these are important functions, but stop short of full key management facilities – such as backup, recovery and update – that are necessary to support a full-blown PKI. The astute buyer therefore needs to be aware that certificate generation and distribution is only one small part of a complete PKI solution.

If you are looking for that complete solution, you should expect the products on your short list to contain most, if not all, of the following components:

Certificate Server – this is the platform that generates, serves and manages the certificates and binds them to the appropriate public keys – both for signing and encryption. It will also renew these on demand or at regular intervals as defined by security policies. Note that private signing keys are not held at the server in order to provide non-repudiation
Directory – a repository of all the public information that is pertinent to a PKI, including the public key certificates, CRL, ARL, CA certificates, and so on. It is critical that this element of the PKI has high availability, and it is often distributed throughout an organisation. LDAP compatibility is a must.
Revocation system – the ability to revoke a key to prevent further access to encryption and/or signing functions by the user using a particular key pair (perhaps because the user has left the company or because his or her keys have been compromised in some way). Certificate Revocation Lists (CRL) must be maintained automatically and distributed regularly throughout the system to ensure that access is always restricted only to those with valid certificates. In addition to CRLs, other methods can be used to provide more timely and efficient notification of certificate status, such as the Online Certificate Status Protocol (OCSP). Whichever method is used, it is vitally important that end-user applications actually use them to verify certificate status, of course.
Automatic key update – The only reason for a certificate to have an expiry date is to ensure that new key pairs are generated at regular intervals. However, the end user should be unaware of this process if possible, unless the security policy dictates that a positive action is required by the user. If a positive action is not required, the key update should be completely automatic and transparent, ensuring that the user is always using keys that conform to the corporate security policy.
Key histories – As keys are updated at regular intervals, it will become necessary to access data encrypted under a previous generation of keys for a particular user (or to verify a signature created with an earlier key pair). The user should not have to keep copies of every version of every certificate and associated key pair they have ever used – matching key pairs to documents would be a time-consuming and error-prone task. Instead, the PKI should provide the means to maintain a complete key history against a user, and should access the appropriate version each time a decryption or signature validation operation is performed.
Key backup and recovery – Not to be confused with key escrow, key recovery ensures that copies of decryption keys are maintained at the certificate server for all users, and can subsequently be recovered should the need arise (such as when the user forgets a password, leaves the company, or if a court order is produced by a law enforcement agency to recover encrypted data).
Support for non-repudiation – the idea of key backup and recovery opens a loophole in the system. Now a user could claim that because someone else potentially has access to their signing key, that they were not actually responsible for particular transactions that had apparently been signed by them. It is thus necessary to maintain dual key pairs for every user. The encryption key pair can be backed up and recovered, whereas the signing key pair should never leave the user’s possession.
Cross certification – If Bob and Alice work for Acme Inc, they trust it as their Certification Authority. If Fred works for Bloggs Inc., he trusts it as his CA. But how does Bob know whether or not he can trust Fred? In order to remove the need for multiple trusts to be created between individual users, a PKI should be able to create high-level mutual or one-way trusts between CA’s. Thus, if Acme trusts Bloggs, then by implication, Bob and Alice can both trust Fred. Of course, Acme and Bloggs must exercise due diligence to ensure that they both have similar risk models and procedures. In addition to peer cross-certification, today’s PKI should also support a multi-level hierarchical model of CA’s and sub-CA’s.

Without the means to manage complete key histories locally, users may be forced to keep copies of all keys ever used on their system to ensure they can decrypt an older document after the original encryption keys have expired. The older keys will inevitably go missing, forcing the user to approach the security officer to perform key recovery operations before data can be accessed.Finally, there is no way to force regular and rigorous checking of CRL’s, thus opening a potential loophole in the PKI.

The products referenced in this site are provided by parties other than SnmpTools.net. SnmpTools.net makes no representations regarding either the products or any information about the products. Any questions, complaints, or claims regarding the products must be directed to the appropriate manufacturer or vendor.

Let us know how we're doing - send us your comments by E-mail. Copyright ©1995-2007 SnmpTools.net. All rights reserved.