|
When the Web exploded into acceptance as a new medium for
marketing and commerce, it was initially used primarily as
a forum for electronic marketing, with early adopters beginning
to accept credit cards as payment. Many of the early adopters
ignored security concerns about credit card information being
intercepted, and gained useful experience and market leadership
over their competitors. A number of highly publicized security
incidents raised public awareness of the potential for credit
card fraud, and many vendors began examining options for providing
security. Netscape Communications, Inc.'s SSL (Secure Socket
Layer) is the most widely deployed Internet transaction protection
technology. SSL is supported by Netscape's browser, which
has hastened its market penetration. A competing protocol
is Enterprise Integration Technologies, Inc.'s SHTTP (Secure
HTTP) protocol. The SSL protocol recently received bad press
relative to a security flaws that have been widely published.
One flaw was a basic mistake in how public keys were generated
for session encryption. This flaw has been fixed in subsequent
releases, but many security experts have been concerned that
such an elementary error was made in such an important part
of the system. Another flaw in SSL that received a great deal
of attention was the cracking of an encrypted transaction
by a French student who used a number of high performance
workstations to crack a key for the encryption algorithm used
to protect transactions.
SSL and SHTTP both provide basic encryption of session contents,
to prevent an eavesdropper from being able to intercept credit
card or other personal information. SSL and SHTTP use a digital
signature scheme to authenticate both parties.
|
|
|
Security Relationships and Communications Channels
When considering electronic commerce applications, it's
important to identify what parts of the transaction
need to be protected, and how they are protected. Undue
attention paid to one part of the complete system will
not result in improved overall security, but rather
a false sense of security. Consider as an example the
manner in which large amounts of cash are transferred:
every step of the process of moving money between vault,
street-curb, armored car, street-curb at destination,
and vault at destination has appropriate security. The
security practices employed in transferring large amounts
of cash are a direct result of years of refinement spurred
by innovative criminal action. When we look at electronic
commerce systems we must assume that a similar process
of refinement will take place. During the early 18th
century, explosives lacked the shattering power and
compact size required permitting small safes to be blown
open without destroying the contents. As a result, great
emphasis was placed on multiple complex locks with carefully
guarded keys. Not surprisingly, criminal activity centered
on theft of keys.
Criminal activity will usually be directed against the
most effort/cost effective target. One implication is
that "insider jobs" will continue to be a
significant threat to electronic commerce. Eventually,
the most cost-effective form of attack will be getting
a job with the victim. We need to maintain our perspective
and build computer security into electronic commerce
processes systematically, not simply into the obvious
and attractive points of
attack.
|
Data Pipes
|
 For
Internet-based electronic commerce, the data pipe-the
TCP/IP connection between the client's computer and the
commercial server-is currently the main focus of our attention.
A variety of encryption and authentication schemes are
being used to protect the data in transit from being altered
or monitored. This is important, yet it is only a small
part of the complete security spectrum we need to address
in order to build robust electronic commerce systems.
For all intents and purposes, a data stream that is protected
with reasonably high-quality encryption (56 bits of key
size or better) is safe against attack. There is a potential
for cryptographic attacks on the data stream but an attacker
who is not a cryptographer will be effectively barred
from playing. If the financial benefit to attacking the
cryptography used is sufficient, it may justify mounting
an attack. European pay-perview satellite systems have
had their cryptography compromised several times, at a
cost
of millions of dollars in lost revenues. The attackers
who compromised the cryptography have more than recouped
their investment in effort by selling falsified access
cards.
Internet-based electronic commerce systems presently are
placing a great deal of emphasis on cryptographic protections
that are being applied to the data pipes. This emphasis
is a direct result of the attack cost-effectiveness of
TCP/IP sniffing. TCP/IP sniffing, in which an attacker
passively monitors traffic on a network, is a known problem,
and a relatively easy attack to defeat. We need to be
concerned that in our rush to protect against sniffing
that we don't ignore the other points of attack and potentially
more serious threats. |
| |
End Points
|
When
a commerce application uses an encrypted data pipe to
communicate with the server on the other end, what do
we know about the security of the end point systems?
In this case, there are two end point systems: one is
the server at the merchant's electronic place of business,
the other is on the user's desktop. Both end points are
vulnerable to attack if not secured adequately. In some
cases the merchant's server is behind a firewall or some
form of network protection. In others it is sitting directly
on the
Internet on a (hopefully) "hardened" UNIX system.
What happens to the data once it gets across the secure
pipe to the server? Often it is simply stored in a file
or database, which may contain customer credit card information,
telephone numbers, home addresses, etc.
Usually, the data gathered is stored unencrypted, "in
the clear" and is a very attractive target for an
attacker. We have already seen many cases where Web servers
have been attacked and broken into. Usually, this has
been a harmless nuisance, but eventually a Web server
with customer credit card information will be compromised.
Most likely, this has already happened several times but
nobody has noticed or notified their customers.
The second end point in electronic commerce is the user's
desktop system. Users on multi-user systems have a particularly
serious problem since it is not difficult to exploit security
holes in most commercial operating systems, to access
other users' data. This may include information such as
users' keystrokes as they type them, passwords, credit
card information, etc. If an attacker can read the data
out of a user's running program before it is placed into
an encrypted data pipe, there is no need to attack the
encryption at all. Which is easier: breaking DES and RSA
encryption, or breaking into UNIX? PCs or other computers
are no more secure than UNIX systems; Trojan horses or
attack programs are potentially capable of accessing users'
information from their hard disks without anyone being
the wiser. As Web browser meta-language technologies such
as Java, and Visual Basic grow more powerful and prevalent,
the likelihood of someone developing a credit-card number
stealing browser applet increases.
To protect the end points of electronic commerce we will
need tools that protect not only the data pipes but the
data at the ends of the pipes. This means that security
will have to be taken into account at every step of the
design process, rather than added as an afterthought once
the application is in beta-test. Applications will have
to be "smarter" about their default operations,
and will need to be designed to prompt users when dangerous
operations are attempted. Smart card technologies, which
are capable of protecting data even from untrustworthy
applications, will become more important, as they allow
users to "unplug" private information from the
system and carry it away with them.
|
Applications
|
Electronic
commerce promises to herald the dawn of desktop banking.
What will happen when everyone's PC is a personal automatic
teller machine? Clearly, some kind of authorization needs
to be applied so that the PC software "knows"
that the correct person is using it. The danger is that
early versions of desktop banking might rely only on a
password (or worse: no password at all) to authorize access
to an individual's account.
Presumably, the situation will improve once a few highly
publicized incidents serve to illustrate the risks. Imagine
what would happen if an annoyed spouse or child decided
to sell someone's stock portfolio short, or to stop payment
on a mortgage check. To build electronic commerce systems,
we will need to walk a fine line between making the system
easy to use and making the system easy to fool. Accomplishing
this goal will require careful and consistent thinking
about security and privacy issues.
|
Cryptosystems
|
One
of the principal protections available for electronic
commerce is encryption.
Presently, a great deal of attention is being paid to
various algorithms, key exchange mechanisms, and certification
technologies. Cryptography is an important tool but is
not, by itself, a solution. Simply adding encryption is
not sufficient to make an application "secure".
The use of encryption in commercial systems has to be
correct and relevant to what needs protection.
|
| Algorithms |
Encryption
algorithms are hard to design; the history of cryptography
is filled with "unbreakable" systems that turned
out to have fatal flaws. For electronic commerce, most
systems rely on the U.S. Data Encryption Standard (DES),
International Data Encryption Algorithm (IDEA), or RSA
Data Security Inc.'s RC4 algorithm.
DES typically uses 56 bits of key space, IDEA 128 bits,
and RC4 40 bits. The number of bits used for keys is important
since it indicates the level of effort required performing
a brute-force search for the correct key. Recently, a
college student with a large number of workstations cracked
a 40-bit key used by Netscape to encrypt data with RC4.
Within two years, it is safe to assume that about $10,000
worth of hardware will provide adequate
processing power to crack 40 bits worth of keys. Keys
with a length of 56 bits will, for some time to come,
be outside of the reach of all but national government
agencies and is, for practical purposes, immune to brute-force
search. The time required to brute-force search a cryptosystem
does not necessarily mean that the cryptosystem is unbreakable:
security flaws in cryptosystems might permit an attacker
to reverse-engineer a key in significantly
less time than a brute-force search. Most of the cryptanalysts
skilled enough to crack codes are currently employed by
national government agencies and probably do not represent
a threat to electronic commerce applications. Because
of the risk of flaws in cryptography, most commercial
applications use one of the well-known cryptosystems,
rather than "home brew" systems. |
|
|
|
|
|
