Bob Walder, director of independent network security testing specialist the NSS Group explains what you need to set up public key infrastructure network security.
With the growth in use of the internet for business transactions, the need for confidentiality and positive identification is increasingly vital.
Encryption and digital signatures are important tools in the ongoing struggle to maintain privacy and confidentiality over insecure methods of transport. Confidentiality of data stored on a corporate network is also becoming increasingly important for many organisations.
Historically, operating system access control has been enough to keep all but the most determined employees from browsing through confidential company data. However, it has always been an accepted fact that IT personnel could access any data stored on the network. The only assurance we have against this is trust and personal integrity, which is not always enough.
Using encryption, any organisation can ensure that all data stored on the network remains secure from prying eyes - whether they work in the IT department or not.
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 engage in transactions with individuals unknown to them and with whom they may never have any further contact.
The cost of deploying secret keys for such transactions is high, both in pure financial terms and in the loss of customers who do not have the patience to wait for secure key distribution to take effect, such as in spur-of-the-moment internet shopping.
Public key systems, on the other hand, allow individuals and organisations to communicate securely using keys that can be freely distributed and published anywhere - much like a telephone number in a directory. This can be augmented further by the use of digital certificates which bind a public key to an individual or organisation and carry the signature of a trusted certification authority, thus verifying its authenticity.
Secure Sockets Layer, secure/multimedia internet mail extensions, secure electronic transactions and code-signing services for both Java and ActiveX, all make use of public key encryption and require some means of managing those keys.
To date, most public key use has been driven from the client end, with users obtaining class 1 certificates from organisations such as Verisign for their browsers or e-mail clients.
The application and renewal of such certificates and their associated keys is entirely under the control of the client, and renewal is more a commercial event than a strategic one. For example, Verisign forces a refresh of certificates every year purely to collect fees, rather than as a means to force key updates.
A properly implemented public key infrastructure supported by an effective security policy will force key updates at regular intervals driven entirely by security needs rather than any overriding commercial decision. The key update will also be completely under the control of the PKI administrator or security officer.
Key management imposes a significant burden on an organisation, as it requires far more than just a piece of certificate server software to create and distribute digital certificates. However, to date, many organisations have found the products confusing. Is certification authority software the same as PKI? Are there any standards in place? Do they need separate directory services?
It is true that standards have been thin on the ground, leaving companies to hang fire or settle for one of the widely available, yet essentially proprietary, PKI systems. The rapid adoption of the internet as a business communications medium has accelerated the requirement for robust and effective key management systems and PKI is suddenly under the spotlight.
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 are focused primarily on the creation, publication and management of certificates. Products such as Netscape Certificate Server and Microsoft Certificate Server enable managers to generate "root" keys, which are used to sign the certificates they generate. Both allow details of the certificates to be published in a directory and support the use of certificate revocation lists.
All these are important functions but stop short of the full key management facilities, such as back-up, recovery and update, necessary to support a full-blown PKI. The astute buyer needs to be aware that certificate generation and distribution is only one small part of a complete PKI solution.
If you are looking for a complete solution, you should expect the products on your shortlist to contain most, if not all, of the following components:
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, either 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 (see "Support for non-repudiation").
A repository of all the public information that is pertinent to a PKI. It is critical that this element of the PKI has high availability because it is often distributed throughout an organisation. Lightweight Directory Access Protocol compatibility is a must.
This is the ability to revoke a key to prevent further access to encryption and/or signing functions through 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 must be maintained automatically and distributed regularly throughout the system to ensure access is always restricted only to those with valid certificates.
In addition to certificate revocation lists, other methods can be used to provide more timely and efficient notification of certificate status, such as the Online Certificate Status Protocol. Whatever method is used, it is important that end-user applications actually use them to verify the certificate status.
Automatic key update
The only reason for a certificate to have an expiry date is to ensure new key pairs are generated at regular intervals. If possible, end-users should be unaware of this process unless the security policy dictates positive action is required by the user.
If positive action is not required, the key update should be completely automatic and transparent, ensuring users always use keys conforming to corporate security policy.
As keys are updated at regular intervals, it will become necessary to access data encrypted under a previous generation of keys (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, as matching key pairs to documents is a time-consuming and error-prone task. Instead, the PKI should provide the means to maintain a complete key history against a user, with the appropriate version accessed every time a decryption or signature validation operation is performed.
Key back-up and recovery
Not to be confused with key escrow, key recovery ensures copies of decryption keys are maintained at the certificate server for all users, and can subsequently be recovered when needed (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 data).
Support for non-repudiation
The idea of key back-up and recovery opens a loophole in the system. Suppose a user claims that because someone else potentially has access to their signing key, they cannot be responsible for particular transactions apparently signed by them. Therefore, it is 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.
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 certification authority. But how do Bob and Alice know if they 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 certification authorities. 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 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 certification authorities and sub-certification authorities.
If all these functions are to be fully supported, some form of PKI interface is required on the client's PC. Only then can the PKI ensure certificate revocation lists are rigorously checked, key lifecycles are correctly managed, and that key histories are maintained.
This client-side software can take the form of a proprietary PKI client for the PKI supplier, various PKI-aware applications such as browsers or e-mail clients, or applications that have been PKI-enabled using various tool kits from the PKI suppliers. Such applications will support PKI functionality in varying degrees.
This last point is often contentious, as PKI suppliers who do not require a client criticise those who do for being "proprietary". However, it is worth considering the implications of not having some form of client-side component in the PKI:
- Separate certificates and keys may be required for every application attempting secure communication, with a resulting management overhead for both user and administrator.
- 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 for key recovery operations before data can be accessed.
- Finally, there is no way to force regular and rigorous checking of certificate revocation lists, thus opening a potential loophole in the PKI.
Recent developments have seen suppliers moving towards providing lightweight or zero-footprint "clients" in the form of automatically downloaded web browser plug-ins or Java applets. This makes it possible to provide the advantages of client-side software without installing it on every machine likely to require it.
Of course, not all the above components are always from the PKI suppliers. The most obvious element which may be already installed in an organisation or which may be provided by a third party is the directory service. Those using an enterprise X.500 directory or one of the more recent offerings from Novell (NDS) or Microsoft (Active Directory) will require their chosen PKI solution to integrate fully.
Indeed, any PKI product not including all of the above components out-of-the-box should at least provide support for third party options via a standards-based interface.
Bob Walder and the NSS Group
Bob Walder, a leading authority on network security, is one of the founders of the NSS Group and author of the NSS report, Gigabit IDS Group Test (Edition 1), which is available from the NSS website.
The NSS Group is Europe's foremost independent security testing facility. Based in the UK with separate security and network infrastructure testing facilities in the South of France, the NSS Group offers a range of specialist IT, networking and security-related services to suppliers and end-user organisations throughout Europe and the US.
Output from the labs, including detailed research reports, articles and white papers on the latest network and security technologies, are made available on the NSS website.
A new report providing a detailed examination and extensive benchmarking of all the major players in the intrusion prevention systems market is currently in the testing phase, with publication due in the autumn of 2003. www.nss.co.uk/gigabitids