©2003 IDC
#3577
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?
C L I E N T S E C U R I T Y I M P L E M E N T A T I O N S
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.
