SECURITY BUYER'S GUIDE
PKI complexities, cost hold promising technology back
Robert Scheier
09.18.2001
Rating: -3.56- (out of 5)
If you're even considering implementing public key infrastructure (PKI) to guard your networks, you know about the sad state of this technology. The cost and complexity has turned off so many customers that once high-flying vendors such as Baltimore Technologies plc are struggling for survival, and others, such as Xcert International Inc., are being gobbled up by larger players.
You know a technology is in trouble when you ask analysts for a list of the latest and greatest tools only to hear that there really aren't any great tools or that the problems with the technology go far beyond what any specific tool can solve.
PKI uses a combination of public and private "keys" to encrypt messages and to authenticate the identity of the person sending the messages. PKI implementations include digital certificates, which hold the public keys; a CA (certificate authority), which issues and validates the certificates; an RA (registration authority), which tells the CA whether to issue the certificate and one or more directories to hold the certificates. By accessing a public directory of certificates, the sender can use the recipient's public key to encrypt a message, but only the recipient can use their private key to decrypt it.
Sound complicated? It is. That's why you need to ask some basic questions before you even start looking at specific PKI tools. They include:
Is PKI right for my business?
Because PKI is so expensive and complex, "you don't want to build a PKI system until you have at least two applications" that can use it, says William Hugh Murray, an independent security consultant in New Canaan, Conn. He also recommends making very clear the authorization and access policies you'll be embedding in your PKI system. Traditional paper-based authorization systems contain a lot of assumptions about who has what access and who can vouch for a user's identity, he says. A PKI system will fail if it doesn't reflect the way such access policies are really administered, he says.
Do I have a global naming convention for my users?
Before you can start issuing digital certificates and keys, you need to know to whom you'll be issuing them. That's no simple feat in many organizations, where the same employee might have five or six aliases to access different systems. Before moving into PKI, says Murray, you need to agree on standard naming formats across your organization and then implement them so each user has only one, unique, uniformly accessible name by which the PKI system can identify them.
Do I have an LDAP-enabled directory?
Many large enterprises have, or are creating, enterprisewide directories using platforms such as Novell Inc.'s Novell Directory Services or Microsoft Corp.'s Active Directory. Creating such a directory is difficult and time-consuming, but is vital to a PKI implementation because it holds the central list of users whose access will be managed through PKI. It's vital, says Murray, to make sure your directory is LDAP (Lightweight Directory Access Protocol) enabled because LDAP is the prime method by which applications will communicate with the directory. The directory must also, he says, "be PKI-aware. It needs to know about certificates and keys and revocations (of certificates) and all those kinds of things."
How will my applications link to my PKI system?
PKI isn't much good if it can't talk to your applications. Having an LDAP and PKI-enabled directory is an essential foundation but doesn't solve the entire problem. Customers should ask their application vendors specific questions about how their applications will link to PKI systems, says Peter Lindstrom, senior security analyst at Hurwitz Group Inc.
For example, does the PKI vendor write directly to the APIs (application programming interfaces) of your most important applications? Or does the PKI system talk to the application through another layer, such as the operating system or an application server, which adds to the complexity and makes debugging more difficult? Does your application favor one vendor's CA over another, possibly changing your choice of PKI vendor? "The real critical piece," says Lindstrom, "is can I use a certificate within my application to authenticate or sign data or encrypt the data?"
The bottom line
There's no one "silver bullet" tool for creating and managing PKI. It's all about what PKI can do for your core application(s). You need to create a solid infrastructure which includes a single naming convention and LDAP-capable directory, make sure your PKI infrastructure corresponds to your business processes, and then ask your application and PKI vendors very specific questions about how they work together.
About the author
Robert L. Scheier is a former technology editor at Computerworld, now a freelance writer and editorial consultant in Boylston, Mass. He can be reached at rscheier@charter.net.
----------------------------------------------
Talk back! Do you have any comments on this column? If so, share them in our Encryption Discussion Forum.
SearchSecurity's encryption experts have answered your most frequently asked questions. See if your question has already been answered, or submit it to our experts.
Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption, Second Edition
By Warwick Ford & Michael S. Baum
Publisher Name: Prentice Hall
Date published: Dec. 2000
Pages: 620
Cover Type: Soft Cover
Summary:
This book offers a complete blueprint showing companies how to implement state-of-the-art e-commerce, while minimizing all the security risks involved. This new edition has been completely updated to reflect today's latest developments in digital signatures, public-key infrastructure, EDI technical standards, certification and authentication.
|
|
Rate this Tip
|
To rate tips, you must be a member of SearchSecurity.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
|
|
|
|
