Lock, stock and barrel

By Pete LoshinSpecial to GCNThe next frontier for many government agencies is electronic commerce, the'theoretically'unfettered exchange of information and services via the Internet.Perhaps the biggest fetter holding it back is concern over security. That's where public-key encryption comes in, and with it administrators' hopes for unshackling agencies' efforts to expand online interactions.How does it work?Let's say you're using public-key encryption in your agency or department. Everyone, and maybe even every device, gets a public key. Everyone posts their public keys on a Web server somewhere and incorporates them on business cards and in e-mail.If you want to encrypt a message to your director, you use her public key; she decrypts it by using her private key. Public-key encryption is sometimes called asymmetric encrpytion because a message encrypted with a public key can only be decrypted with a related private key. With symmetric algorithms, the same key is used to encrypt and decrypt.But how do you know that the public key you use to encrypt mail to your director is actually the public key associated with the director?You don't, unless you've got some mechanism in place to keep track of who's who, and which public key belongs to whom. That means building a public-key infrastructure for distributing public keys and using a certificate authority, or CA, to sign all your users' public keys to create public-key certificates.Certificates are little more than simple statements digitally signed by some trusted third-party entity. These statements usually, but are not required to, contain data outlined in the International Telecommunications Union's X.509 standard: the name and other identifying information of the subject of the certificate, the subject's public key, and the digital signature of the certifying authority issuing the certificate. The CA's signature says, in effect, that the CA is vouching for the certificate holder: This person or entity is associated with this public key.Why use certificates instead of just public keys? You wouldn't really need a certificate if you distributed public keys by hand, with each entity holding a public key giving it to you in person. To avoid problems, however, you could never distribute keys any way but in person'hardly a practical method.Once you start e-mailing naked public keys, you risk a man-in-the-middle attack. If Bob sends a public key to Alice by e-mail, that key could be intercepted by Carol, who replaces her own key for Bob's key. Then, when Alice encrypts a message with what she thinks is Bob's key but is actually Carol's key, Carol can read it but Bob cannot.This is where certificates come in. With a certificate system, Bob gets his public key signed by a CA and sends the certificate to Alice. Alice can verify the CA's signature on the certificate, and, to the extent that Alice trusts the CA to have been conscientious about verifying Bob's information she can trust that the public key in the certificate belongs to Bob.Much of the attention certificates and CAs are getting arises from the importance of public-key cryptography in Internet commerce. Commerce servers need certificates so customers' browsers can encrypt sensitive consumer data. But government agencies can put certificates'and CAs'to good use for many other purposes. Most important, certificates are vital for any public-key encryption application, whether you are encrypting Internet e-mail or encrypting IP datagrams through a virtual private network.Sounds pretty good, you might say to yourself; we should use a CA for our public keys. But there are still some questions to worry over. Whom can you trust as the trusted third party? Should you try to do it in-house, to maintain control over the entire process, or should you contract it out to a vendor that specializes in such things? And what exact functions must a CA perform?The CA must issue certificates, respond to requests for users' certificates, and maintain a current list of revoked or invalid certificates. The products and services included in this Buyer's Guide all provide these certifying authority services.The bottom line is that you must also be able to trust that the CA cannot be subverted, whether the CA is controlled by a third-party service provider or internally within your agency. If someone gains control of the CA's private key, she can generate her own bogus certificates that would be indistinguishable from authentic certificates.Revocation provides a mechanism by which a compromised key can be taken out of circulation. When a certificate is revoked, the CA lists the invalid certificate as well as the date from which it was revoked, so illegitimate signatures can be flagged.If you opt for a CA service provider, you should carefully evaluate its security arrangements. You'll also want to review its policies for issuing and managing certificates, as well as what kind of documentation or identification they require to issue a certificate. Will the CA build policies specifically for your agency? What documentation is required to revoke a certificate? What liabilities and obligations will CA take on?If you opt to buy CA software and do it all yourself, you should have a qualified expert help. Expect to spend a lot of time working out the details of building your own CA. The Quebec-based PKI consulting firm Labcal Technologies Inc. offers '25 Steps to the Successful Implementation of a Corporate Public-Key Infrastructure' as a free download from its site, at www.labcal.com.Beyond certificate policymaking, certificate management and revocation are crucial day-to-day CA functions. X.509 certificates include validity dates, specifying when certificates are valid. But certificate revocation provides a mechanism by which a certificate can be revoked early'for example, if the certificate holder is compromised or leaves the organization.Vendors who offer CA services, such as Verisign Inc., Thawte Consulting and Alphatrust.com, would have you believe that a trusted third party means exactly that: an entity external to any of the entities using encryption to communicate.Others, such as Baltimore Technologies Plc., sell the software necessary to establish your own CA in-house. Still others, such as Entrust Technologies Inc., will tailor their service, whether it is for an in-house CA or a third-party CA service provider. Yet another option is just to use the Microsoft Certificate Server included in the Windows NT 4.0 Options Pack to generate your organizational certificates.Whether you go in-house or not, managing certificates and keys is far more complicated than simply signing public keys for the people, devices and systems under your control. Be sure to do your homework.XXXSPLITXXX-