Lenovo ThinkCentre M50 IDC white paper titled "The Coming of Age of Clien - Page 11

In the public version of security, a world of ecommerce, where people can freely trust the Net and all the clients and services that they run into, there would be no inelegance. But in the real world, people of a certain disposition and skill can game the system and filch unprotected private keys, forcing the owners to go back to the authority and ask it to disallow that pair. The authority has to maintain a list of revoked "certificates," records that contain details about senders' identities, details about the authority, senders' public keys, expiration dates, and digests of the certificates themselves. Certificates, obtained from and validated through the authority, are used to vouch for the sender's public key and irrefutably connect the sender to a set of public-private key pairs. A valid certificate provides the recipient with a guarantee that the sender cannot repudiate the transaction contained in the message, a critical feature for doing ebusiness. Another complication with PKI is the existence of more than one certificate authority, and participants must have a public key for each. Common certificate issuers include VeriSign, Baltimore, Entrust, and Xcert. Finally, certificate authorities need clear procedures to verify that participants are who they say they are. However, the good news on the procedural side is that the only keys each participant has to worry about are his or her private key, his or her public key, and the public key of the certificate authority. With symmetric keys, participants have to keep a copy of the keys of everybody they ever correspond with. So, that's great. We have an unbeatable algorithm and a theoretically robust infrastructure to operate it in (if we can find a third party to trust). But what about implementation? In what medium do we utilize this powerful math? CLIENT SECURITY IMPLEMENTATIONS Because of the unresolved procedural issues involved with implementing a fully secure infrastructure, some of the grander visions of secure computing have been scaled back, at least in the short term. Companies need not wait until all parties agree on all aspects in order to shore up their security perimeters. Even if it is not yet feasible to send and receive data from all customers and all suppliers over secure, verified links, it is possible and even easy to set up basic security at the client node. User authentication at the client end can be performed adequately with smart cards, strong passwords, or biometric identification systems. The ideal client-protection procedure involves some combination of two or more of what you have, what you are, and what you know, which are defined as follows: ! What you have. Can be a smart card or proximity badge, with which the client system must interact in order to operate ! What you are. Can be a biometric measure of your iris, voice, or fingerprint ! What you know. Can be a password or your mother's maiden name Smart cards are credit card-size cards that carry their own microchip. Smart cards can carry keys and, in conjunction with authentication software, can be used to identify a user trying to log on to a particular client. One of the benefits of this type of user verification system is that, as a hardware implementation, it can be outfitted with a counter to prevent hammering. Any user attempting to log on too many times can trigger a lockout of the smart card. However, smart cards have certain drawbacks. For one thing, the number of keys a smart card can hold is limited, which is a problem from the perspective of likely developments in ebusiness, for which users will likely require a large number of secure keys to conduct transactions with a variety of entities. Also, a smart card and smart-card reader, which are necessary add-ons, are relatively expensive. ©2003 IDC #3577 11