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:
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, 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").
Directory
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.
Revocation system
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.
Key histories
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.
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 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.
Client-side software
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