|
|
 |
|
Key Management: Public and Secret Key
|
|
|
|
|
 The
actual encryption algorithm used is only part of the picture
when using encryption systems. Key exchange, the process of
safely getting a shared encryption key to both parties, is one
of the weaknesses all encryption systems share. Secret key exchange
relies on some secure means of pre-exchanging a key for future
use. The preexchange of the key has to be done securely, and
is usually done out-of-band or face-toface.
A good example of a simple secret key exchange is the way in
which a bank issue personal identification numbers (PINs) for
automatic teller cards. The customer appears in person at the
bank and is issued the card and PIN, or the card and PIN is
sent via the (presumably secure) U.S. mail.
Another way in which secret key can be used effectively is by
encapsulating the secret key in a smart card or similar device,
where the issuing authority never gives the customer access
to the key information at all. The main disadvantage of secret
key technology is that each key must be managed securely, and
each user has a unique key-pair that is used to authenticate
and encrypt traffic to the central authority. As a result of
the unique key-pair requirement, it is impossible to engage
in commerce with someone to whom you have not already been "introduced"
to. Neither of you has a shared secret key and there's no secure
channel over which to exchange one. Secret key works best when
a single issuing authority is maintaining a service for a customer
base where there is some kind of registration process that takes
place prior to becoming a customer. Possibly the biggest advantage
of secret key approaches is that the registration and unique
per-user key means a merchant can be fairly certain as to the
identity of the customer.
The primary tool of public key encryption is the RSA encryption
algorithm. RSA takes advantage of some clever mathematics to
allow users to split a key into two parts, one of which is kept
secret, the other of which is safely published. Anyone, using
the published part of a user's key, may send encrypted messages
to them without having to have access to a pre-arranged shared
secret. This is important since it means that parties that have
not been "introduced" or pre-registered can carry
on a transaction without a third party being able to eavesdrop.
For performance reasons, RSA is usually used only to exchange
keys, and conventional (DES or whatever) encryption is used
for the bulk of the message. There is still an open issue of
reliably knowing who is on the other end of the transaction.
For most of the electronic commerce systems in operation today,
the user's credit card and the credit card verification process
is used to authenticate them as an authorized consumer. In a
sense, with current electronic commerce systems, the basis of
trust is still in the validity of the credit card. The main
disadvantages of public key technology are the lack of standards
for exchanging public keys, the lack of means for verifying
the identities of key holders, and the performance of the algorithms:
public key encryption is many times more compute intensive than
traditional encryption. At present, the main role that public
key encryption plays in electronic commerce is as a technique
for setting up encrypted data pipes between parties which have
never been introduced. In an environment like the Internet,
where the population is growing constantly, this is an extremely
important capability.
|
|
|
Certification
and Registration
|
In
public key encryption, one party can "introduce" another
by using their public key to "sign" the new public
key. A key, with other public key signatures attached, is often
referred to as a public key certificate. Usually a certification
authority, such as a merchant, ISP, bank, or other trusted source
countersigns a certificate. The role of a public key certificate
is not unlike a credit card: it is a portable object with some
minimal information about the user, which is issued by some
organization that can be called upon to verify its authenticity.
Credit card authorization systems are a means of verifying the
validity of a given card when a merchant wants to perform a
purchase. Just as credit cards can be stolen, public key certificates
need to be protected, since someone who gains illicit access
to the secret part of the key can subsequently impersonate the
user. Public key certification systems share many common antecedents
with credit card systems. Just as credit card authorization
databases may be able to mark a stolen card as "bad: seize
on sight" a public key certificate system must address
certificate revocation and must permit the issuer to assign
a limited lifetime to a certificate, if desired.
Microsoft, Inc.'s recent announcement of an electronic commerce
initiative with Visa includes a public key certification hierarchy
as part of its architecture. The details have not yet been sorted
out, but presumably issuing banks will create what amount to
electronic credit cards. When this happens, we need to remember
that just as with real credit cards, there will be a danger
of having them stolen. The secret part of an RSA public key
is usually 1024 bits or larger: 128 characters-more than most
people can remember or care to type. Therefore, it must be stored
someplace safe where nobody can access it. Current systems such
as Pretty Good Privacy (PGP), an Email encryption program, and
store the secret data encrypted on a user's hard disk. If it
is not carefully guarded, it makes a good target for attack.
Smart card technologies, some of which incorporate the ability
to do RSA
signatures and storage for keys, are an attractive technology
for protecting this important information in a portable manner.
|
| Relevant
Technologies |
| Integrating
secure electronic commerce solutions requires a consistent and
unified view of the problem domain. Web servers, clients, firewalls,
and encryption/authentication systems must all work together
to ensure that there are no weak links. Security must address
the complete path between the user and the end point processing
system, protecting private data as it is transmitted and stored. |
| Web
Servers |
Many
sites have difficulty deciding where to put their Web server.
For organizations with a security perimeter protected by a firewall,
there's usually a strong desire to put it behind the firewall
to shield it from attack. Many firewalls, however, do not support
"outside" access to the Web server behind the firewall,
without significantly weakening the firewall. There is also
often a concern that attackers, which would effectively put
the attackers behind the firewall, where they could easily attack
the rest of the network, may compromise the Web server. Putting
the Web server in front of the firewall leaves the server on
its own to defend against attack, and increases the difficulty
of managing the pages on it by isolating it from the protected
network. For commerce activities, the position of the Web server
vis-a-vis the firewall is especially crucial if the Web server
stores customer information such as credit card numbers. If
at all possible, sensitive information should be quickly handed
off the Web server and through the firewall to a safe place.
If a Web server cannot resist attack, can the contents of the
transactions it passes through the firewall be trusted?
Many
commercial sites are running their Web servers on UNIX systems,
using public domain or off-the-shelf HTTP servers. There are
several common points of attack against Web servers: HTTP servers,
CGI scripts, and host platforms. Several security flaws have
been identified in various versions of HTTP servers. Some of
these flaws would permit an attacker to execute arbitrary commands
on the Web server itself, in some cases permitting the attacker
to log in directly with system administrator privileges. As
CGI scripts become more powerful, they also represent a potential
avenue for attack. In one well-known incident, a flaw in a perl-based
CGI script permitted an attacker to execute commands on the
Web server from across the Internet. The entire Web site was
quickly compromised through a single weakness.
|
| Firewalls |
One
technique for protecting Web servers and customers accessing
the Web is to place them behind firewalls. For the sake of this
discussion, we will not worry about the details of a particular
firewall technology: a firewall is a generalized access control
system between two networks. With a firewall in place, the Web
server may be protected, but often at a cost in performance
or complexity. Access from the user's perspective is often
more complicated as well. New services are always appearing
on the Internet and making them work through a firewall are
a time-consuming headache. It is an unfortunate fact that most
electronic commerce protocols are designed with the implicit
assumption of direct point-to-point connectivity between end
points. As more sites are connecting to the Internet behind
firewalls, electronic commerce applications will have to become
firewallaware,
and firewalls, in turn, will have to support newer and different
services. |
| Web
Clients |
Web
clients are becoming increasingly powerful and are beginning
to incorporate powerful multimedia display systems and programming
languages. The danger of someone developing attack code hidden
in HTML documents increases as HTML extension languages give
the author more control over the client system. The Microsoft
Word "concept" virus is an example of the ease with
which macro languages can be used
to launch powerful and invisible attacks. Many security experts
are justifiably concerned that unknown persons or agents might
be able to execute electronic commerce transactions on behalf
of the user, by reprogramming their Web clients. It makes sense
to eventually separate the user-interface and display aspects
of the browser from the
payment system. We are facing a period of market and customer
confusion as multiple competing electronic payment systems are
introduced. Compatibility and interoperation will be a problem
if users have to swap browsers in order to make purchases.
Current browsers have been fairly free of security flaws. An
early version of one UNIXbased Web client permitted commands
to be executed on behalf of the user when certain URLs were
selected. Later versions of the Netscape browser had a memory
overrun that potentially could have been used to create a Web
page that would be able to run commands on the user's system,
if they were using the right (or in this case, wrong)
version of the browser. Software flaws are to be expected, as
browsers continue to become more complex and powerful. |
| The
Future |
| It
is inevitable that electronic commerce will play a role in our
futures. Pay-per-view television, Internet commerce, and digital
cash/credit card convergence are already being developed. Will
there be security problems? Inevitably. Applications must incorporate
security as a basic part of their design, rather than an afterthought. |
The
current trend seems to be toward massive integration of functionality
into monolithic programs that do everything imaginable. If the
trend in browsers continues, in a few years users will expect
to be able to perform bank transactions, edit files, send Email,
and collaborate on writing using a common interface. The competition
to provide those interfaces will be intense, and with such a
large market it is likely that vendors will attempt
to fragment the market along functionality lines, in order to
dominate specific segments.
Strategic
alliances and partnerships will continue to be extremely important
factors in determining what is available to the customer. For
a long time to come, we will be faced with a lot of systems
that provide electronic commerce capabilities, but which do
not overlap; much as today's automatic teller machines and credit
card systems took years to converge. Key management and certification/registration
will become increasingly
important and may push the market towards wider-scale deployment
of smartcards, as it already has in Europe. |
| Future
Problems |
The
security problems of the future will be the same as those of
the present: management of complexity. Software systems suffer
security problems because they are complex, large, and difficult
to program; a single flaw can give an attacker a foothold into
an otherwise very strong system. Good design and a solid security
foundation can provide multiple levels of protection, and reduce
the risk of a system being completely compromised. Future electronic
commerce systems will require correct interoperation among end
points, browsers, servers, firewalls, and other network devices
that haven't been invented yet. As the number of cooperating
agents increases, the chances that everything will perform correctly
decreases.
Today,
many of the security holes in software result from the race
to bring software to market with new, more desirable features.
There is no reason to expect or hope that the feature-race will
ever end, and every reason to expect new features will bring
new security holes. Probably the most fruitful area for attackers
will be in meta-languages and embedded interpreters. It is scary
to ponder that we have not even come close to solving
the problem of computer viruses, yet we are rapidly deploying
increasing numbers of meta-programmed applications, each with
their own interpreters and protection models.
|
| Future
Technologies |
| What security technologies
will we be able to deploy to secure the electronic commerce
applications of the future? The most important problem that
will be solved will be key management and registration. Smart
cards, which can contain multiple public keys safely and portably
will provide a tamper-proof platform for authenticating purchases.
Many visionaries believe that eventually everyone will carry
personal electronic agents or digital assistants. These agents
will become the "portable automatic teller machines"
of the future, and, eventually, we may see some form of "convergence"
in which credit cards, smart cards, cellular telephones, and
Internet terminals are rolled into a single portable, tamper-proof
unit. Until such a time as the market unifies, competitive pressures
will effectively act to prevent convergence. The ancient Chinese
curse, "may you live in interesting times", will always
be true for the cutting edge of electronic commerce. |
|
|
|
|
|
