The previous chapter discusses
caches.
Electronic Banking
A electronic bank is used to mediate the exchange
of money between various portions of the electronic
publishing system. In order to be usable, the
electronic banking system must be secure from a
great number of security attacks. This section
first describes how the electronic banking system
works and then goes into the security aspects of
the entire system.
Electronic Banking Overview
Before going into the security aspects of the
banking system, it is worthwhile to go through
a fairly complete example of how money through
the system. This is shown diagrammatically below:
There are a four individual/organizations shown
in the diagram, and they are the:
-
Reader.
-
The reader is the person that wishes
to read published information.
-
Cache Provider.
-
The cache provider is an individual
or organization that supplies a
cache service.
-
Repository Provider.
-
The repository provider is an individual
or organization that supplies a repository
service.
-
Author.
-
The author stores information in the
repository in exchange for a monthly fee
and the opportunity to collect royalties
from readers who read the information.
In general, money flows from the reader to author with
the cache and repository extracting fees along the way.
In addition, there is a "reverse" flow from the author
to the repository for monthly storage fees.
The overall system uses the existing world wide banking
system for the actual storage and transfer of real money.
These banks are called real banks to distinguish them
from the electronic banks and electronic money of the
electronic publishing system. It is hoped that eventually
real banks will get into the electronic brokerage of money
in the electronic publishing system, thereby blurring the
distinction between real banks and electronic banks;
however, for the rest of this design it is assumed that
electronic banks and real banks are completely separate.
In this example, there are a plethora of both real and
electronic bank accounts. Each individual/organization
has their own real bank account and a corresponding
electronic bank account. For full generality, it is
assumed that each individual/organization has selected
a different electronic bank. Each electronic bank as a
single real bank account that is uses for of its
electronic bank accounts. Thus, since there are four
individuals/organizations and four different electronic
banks, there are a total of eight real bank accounts four
electronic bank accounts that must be kept track of
Finally, both the cache and repository maintain local
accounts called cache accounts and repository accounts,
respectively. These accounts are used to keep track of
the current usage down to the fractional penny.
Money will flow into and out of cache and repository
accounts the most quickly. At appropriate intervals,
money will flow between electronic banks via electronic
checks to reconcile accounts. Finally, a appropriate
intervals, electronic banks will reconcile their real
accounts by sending paper checks drawn on real bank
accounts via the postal system. While eventually the
paper checks will be abandoned in favor of electronic
funds transfer, it is not germaine to the example.
The following steps take place:
-
Everybody must select their own electronic bank
and open an electronic bank account. Among other
information, a postal mail address to which to
send correspondence and/or payment checks must
be provided. In addition, each person will have
to sign a release form that states that the
electronic bank may transact funds upon receipt
of an electronic check with a valid electronic
signature. (Electronic signatures are discussed
much further below.)
-
The author starts the entire process by deciding
to publish some information. A repository is
selected and an author repository account is
set up at the repository. (An author repository
account is kept by the repository and is distinct
from the author's electronic bank account.) Monthly
storage fees will be debited to and royalties will
be credited to the author repository account.
Whenever the author repository account balance
reaches a zero balance, the repository is entitled
to delete the published information. At regular
intervals, such as at midnight, the repository
transfers funds from the repository's electronic
bank account to the author's electronic bank
account for any royalties collected in the
author's repository account.
-
The reader decides that they wish to read
electronically published information. At an
earlier step, the reader already opened an
electronic bank account which has a balance
of zero. The reader writes a paper check and
sends it to electronic bank's postal address
for deposit into the electronic bank account.
The electronic bank receives the paper check
and deposits the check into the electronic
bank's real bank account. The world wide banking
system processes the paper check and transfers
funds from the reader's real bank account to
the electronic bank's real bank account. Once
the paper check has cleared, the electronic
bank places the corresponding electronic funds
into the reader's electronic bank account. Once
the balance in the reader's electronic bank
account is non-zero, the reader is ready to
start read electronically published information.
-
The reader starts their viewer software and calls
up a cache. The viewer software automatically sets
up a reader cache account at the cache. The reader
cache account will exist for the duration of the
connection between the viewer software and the
cache. The viewer software will transfer a modest
amount of funds from the reader's electronic bank
account to the cache's electronic bank account.
The amount of funds transferred show up in the
reader cache account. As the reader accesses
information, royalties and other fees (such as
communication fees with the repository) will be
deducted from the reader's cache account. As the
account balance approaches zero, the viewer software
will automatically transfer additional funds from
the reader's bank account to the cache's electronic
bank account, thereby increasing the amount of
funds available in the reader cache account. When
the reader is done viewing information, the
connection to the cache is shut-down and any
remaining funds in the reader cache account are
transferred back to reader's electronic bank
account from the cache's electronic bank account.
At this point in time the reader cache account is
no longer needed and it can be deleted.
-
At regular intervals, the electronic banks will
balance their books via paper checks. For the
transaction above, the reader's electronic bank
will cut a single paper check that covers the
entire amount of money owed to the cache's
electronic bank. If a multitude of different
readers are using the same electronic bank and
cache, all of these readers transactions are
covered by a single paper check. The electronic
banks will both send out paper checks and receive
paper checks to deposit into their corresponding
real bank accounts.
-
When the reader accessed information from the
cache, the cache at some point in time had to
establish a connection with a repository to
fetch the information. Upon connecting to a
repository, a cache repository account is set
up at the repository, in a fashion that is quite
similar to how the viewer software sets up a
reader cache account at a cache. Funds are
transferred from the cache's electronic bank
account to the repository's electronic bank
account to fund the cache repository account.
As the cache accesses information, royalty fees
are transferred from cache repository account
into the appropriate author repository account.
Whenever the cache repository account approaches
a balance of zero, additional funds are
transferred from the cache's electronic bank
account to the repository's electronic bank
account. When the cache/repository connection
is disconnected, the funds remaining in the
cache repository account are transferred back
from the repository's electronic bank account
to the cache's electronic bank account and the
repository account can be deleted. Whenever the
electronic banks balance their books, a paper
check drawn on the real bank account associated
with the cache's electronic bank and is sent to
deposit into the real bank account associated
with the repository's electronic bank.
-
As was mentioned earlier, at regular intervals
the repository will balance its books and cause
transactions between the repository's electronic
bank and author's electronic bank. When these
banks balance their books a paper check drawn
on the real account associated with the cache's
electronic bank is cut and sent to author's postal
address; this check constitutes a royalty check
and is deposited in the author's real checking
account for spending however the author sees fit.
This series of transactions marks the end transferring
money from the reader's checking account through a
series of intermediate accounts and ultimately into
the author's checking account. Along the way both the
cache, repository and electronic banks are collecting
additional fees that eventually wind up as profits
deposited into the bank accounts associated with the
cache provider, repository provider, and electronic
bank provider respectively. They are free to either
reinvest these profits into their business or to
distribute the profits however they see fit.
The Security Aspects of Electronic Banking
The entire electronic publishing system is based on
the ability of people and organizations to exchange
money electronically via electronic checks with
electronic signatures. Since there are dishonest
people who will attempt to forge electronic checks,
the only effective way to ensure the validity of
electronic checks is via cryptographic technology.
The dishonest people who attempt to compromise the
electronic banking system are simply referred to
as criminals.
In an ideal system, money for accessing a bit of
information is exchanged exactly as each bit of
information is received by the viewer. Such a
system would be difficult, if not impossible,
to engineer with sufficient performance to be
usable. Instead, there will be periods of time
when either the viewer has the information and
the repository has not received any money or
vice versa. As long as accounts are eventually
resolved such that the repository has received
the correct amount of money for the information
transmitted, the overall system will be quite
workable.
Engineering the banking portion of electronic
publishing would be remarkably easy if it could
be assumed that everybody is completely trustworthy;
conversely, if everybody is assumed to be completely
untrustworthy, it is essentially impossible to
engineer such a system. Thus, it is necessary to
decide what security attacks there are and how
defend against them.
-
Wire tapping
-
It should be assumed that dishonest people
will have no scruples about listening in
and/or attempting to forge network
transactions. The purpose of breaching
network security can be to either attempt
to abscond with funds or deny service to
segments of the user community or the
community as a whole.
-
Dishonest Readers
-
While most readers will be completely honest,
there is a certain class of person that feels
almost obligated to take advantage of an
loophole in a system. For these people, if
the system permits them to read information
before payment is collected, they will
cheerfully read the information and then
fail to pay for the information read when
payment becomes due. Thus, the overall
system will be essentially required to insist
that all users pay for information before
reading it.
-
Dishonest Bank
-
A bank could be honest for years and then
suddenly decide to abscond with whatever
funds it has on deposit. It is almost
impossible defend against a dishonest bank.
The only defense is to limit exposure by
not storing an inordinate amount of funds
in any one bank. The only real requirement
for the electronic publishing system is to
be able to detect when a bank has become
dishonest and announce it to the system as
a whole so that no further dealings with
the bank will occur.
-
Dishonest Cache/Repository
-
A dishonest cache or repository can charge
readers more than the agreed amount and
pocket the difference. Technically, the
cache or repository could also pass incorrect
information to the reader; while, in general,
there is no reason to do so, there is some
information, such as an index of public keys
for a public key cryptographic system,
for which it might be tempting to pass
along forged information. The only real
way to protect against dishonest caches
and/or repositories is to build in enough
policing to detect when one is being dishonest
and announce it to the whole system so that
future dealings will them will cease.
Thus, the overall system will trust banks the most and
caches and repositories almost as much. There will be
enough consistency checking to detect dishonest banks,
caches, and repositories. The readers will be trusted,
but in general they will have to pay money up front
before receiving any information. When it comes to
network transactions involving money, it will be assumed
that dishonest people (i.e. criminals) will expend a
serious amount of energy attempting to breach network
security. When it comes to the day-to-day transmission
of published information, it will be transmitted in the
clear with only modest attempts to ensure data integrity.
The United States Congress has empowered the National
Security Agency, NSA, to manage United States'
cryptographic technology base and foreign policy.
For legitimate reasons of national security, the NSA
appears to be discouraging the world-wide proliferation
cryptographic technology. One of the techniques used
for discouraging the proliferation cryptographic
technology is that both cryptographic hardware and
software are under the same export control as firearms
and require an export license for sale outside of the
United States. Since commercial software undergoes
extremely short product cycles, requiring an export
license has very effectively put a damper on
incorporating much cryptographic technology in most
of the United States commercial software base.
Strangely enough, there does not appear to be any
law to prevent or discourage people and/or
organizations from promoting cryptographic
technology both within the United States and
orld-wide. For example, RSA Data Technology in
Redwood City California, that has licensed public
key cryptography patents from the Massachusetts
Institute of Technology, MIT and is actively
promotes this advanced cryptographic technology
world-wide. Before any electronic check technology
based on cryptography becomes widely adopted, the
NSA will almost certainly become either directly
or indirectly involved in the protocol definition
process.
Cryptography allows someone to transmit a message to
somebody else without eavesdroppers being able to
determine its contents. All forms of cryptography
require that a message sender have a key which is
used to encrypt the message prior to transmission;
upon message receipt, the receiver uses a key to
decrypt it. The three forms of cryptographic technology
discussed in this section are:
-
One-Time Key (OTK)
-
One-time key cryptography uses key of random
bits whose length in bits is equal message
length. To encrypt a message, it is XOR'ed
with the one-time key, transmitted; it is
decrypted by XOR'ing it again with the
one-time key. Proper use of one-time key
cryptography requires that the one-time key
never be used again. Properly used, the only
way to compromise one-time key cryptography
is to compromise the key. The entire focus
with one-time cryptography is to securely
share the one-time key between the message
transmitter and receiver and nobody else
(e.g. the proverbial trusted couriers with
handcuffed attache cases.)
-
Public Key Cryptography (PKC)
-
Public key cryptography uses two interrelated
keys, called the public key and private keys.
Any message encrypted using the public key can
only be decrypted by someone who has the private
key. Thus, compromising a public key, does not
compromise any messages encrypted with it; indeed,
public keys can be widely published and
distributed. There are basically two ways to
compromise a public key cryptography system -
compromise the private key or trick a sender
into using an incorrect public key (i.e. the
public key distribution issue.) While some people
like to dwell on the public key distribution issue,
in practice, it is difficult to trick someone into
using an incorrect public key for very long, when
the public keys are widely published and
cross-checked. The keys in public key cryptography
are approximately 100-200 bits in length.
-
Data Encryption Standard (DES)
-
The data encryption standard was started by IBM
in the 1970's. Eventually, the NSA stepped in
to help complete the standard, which was
eventually adopted by the United States
National Bureau of Standards. The data
encryption standard utilizes a 54-bit key
to encrypt 64-bits of information at a time.
Many people believe that since the NSA
designed the a critical component of DES
(the P-box), that NSA has some trick that
enables them to read messages encrypted under
DES with less effort than the brute force
method of trying all 254 possible keys;
furthermore, there is skepticism that 54
bits is not really a long enough key. While
the skepticism and controversy lingers,
in practice, many very bright people have
attempted to comprise DES and none have
publicly announced success. Thus, despite
the lingering doubts that some people have
about DES, it is almost certainly a strong
enough cipher to support an electronic banking
system.
While there are many other forms of cryptography,
in general, they have not scrutinized as extensively
as OTK, PKC, and DES have.
While there are differences between OTK, PKC, and
DES, the important issues that they share in common are:
-
Key Generation.
-
The best keys are truly random bit streams,
where the probability of any bit in the bit
stream being a 1 is exactly 50% with a 0%
correlation with any of the other bit in
the bit stream. In general, people make
lousy random number generators. While there
are good pseudo random number generation
algorithms, it seems a little more comforting
to base random number generation on physical
processes that are currently thought to be
truly random, such as radioactive decay and
shot noise in a properly biased diode.
(Diodes are significantly cheaper than
radioactive sources and their associated
detectors.)
Once a sequence of bits has been recorded
from a truly random source, it is necessary
to perform an additional step of balancing
the bits so that the probability of a 1 is
exactly 50%. If the probability of getting
a 1 is p, the probability of getting a 0 is
1-p. If the bits in a random bit stream are
taken pair-wise, the probability of getting
11 is p2, 00 is (1-p)2, 10 is p(1-p), and 01
is (1-p)p. Thus, the probability of getting a
10 is exactly the same as getting a 01 (i.e.
p(1-p) = (1-p)p.) Hence, a random stream of
bits can be balanced by taking pairs of bits,
throwing away all 11's and 00's, and taking
the first bit of each remaining pair. On
average, each balanced random bit will require
at least 4 bits from the unbalanced random bit
stream. (The technique of using diode shot
noise and balancing the resultant bit stream
was relayed to me at an MIT lecture given by
Professor David Gifford in the early 1980's.)
Electronic banks will use random bit string
generation equipment to generate random keys
for themselves and their customers.
-
Key Distribution.
-
All cryptographic schemes require that the
message transmitter and message receiver have
the correct keys for message encryption and
decryption. The proposed banking system has
centralized random bit string generation at
the electronic banks to share the random bit
string equipment cost among all of the bank's
customers. Thus, even if banking system is
based on public key cryptography, electronic
banks need to generate public/private key pairs
and securely distribute the private keys to
their customers.
For the purposes of the electronic banking
system, it is assumed that truly random bits
are written on some sort of portable media.
Since most personal computers currently have
the ability to read 3.5 inch floppy disks,
the initial portable media will probably be
a 3.5 inch floppy disk with a storage capacity
of 1.44MB of random bits. The fact that most
computers can read 3.5 inch disks is a security
weakness, since a criminal can potentially
intercept the disk, copy its contents, and
at a later date generate forged electronic
checks. If this security risk becomes too
great, a much more tamper resistant alternative
media for distributing random bits can be
developed. The tamper resistant media probably
be deployed as something the size of a credit
card with a calculator style keypad and an
embedded processor. The tamper resistant media
has the advantage that it will be very resistant
to tampering without extremely specialized and
expensive equipment (i.e. only government agencies
will be able to afford the specialized equipment.)
Since both of these portable media have many of
the characteristics of a checkbook, they are both
referred to as an electronic checkbooks. Electronic
banks will have the equipment for generating
random bits and storing them into electronic
checkbooks.
The two most likely distribution strategies for
electronic checkbooks are to pick them in person
or to have the bank mail them to their customers
via the postal system. Clearly, picking an
electronic checkbook in person is an extremely
secure key distribution strategy. While real
banks regularly use the postal system for the
distribution of blank checks to their customers,
electronic banks may discover that it is a little
too easy for a criminal to intercept and copy an
electronic checkbook distributed on a 3.5 inch
floppy disk and subsequently issue forged
electronic checks. Thus, electronic banks may
have to either rely solely on distribution in
person or on the development of the tamper
resistant electronic checkbooks; conversely,
they may discover that sending electronic
checkbooks on 3.5 inch floppy disks through
the postal system is quite workable.
-
Key Security.
-
Key security is a distressingly complex subject.
One brute force security attack is for a criminal
breach physical security by simply breaking and
entering to gain access to someone's electronic
checkbook. Since electronic banks centralize the
storage of electronic checkbook information,
they will be particularly susceptible to break
and enter style attacks and will have to protect
their storage accordingly; banks that do not
provide enough security will soon be out of
business. A more ingenious attack takes the form
of a computer virus, whereby a computer virus will
attempt to infect the code in the user's viewer
software that access the information on the 3.5
inch floppy disk electronic checkbook and cause
it to issue forged electronic checks. The user's
electronic checkbooks stored on 3.5 inch floppy
disks must be educated to exercise above average
security measures to protect the integrity of their
electronic checkbooks; such measures include locking
the checkbook up when it is not in use, only
inserting the checkbook into the disk drive when
an electronic check needs to issued, regularly
scanning their computers for viruses, and limiting
financial exposure by only keeping a modest balance
in an electronic bank account.
People whose machines are connected to an open
computer network are susceptible to truly mind
boggling number of devious and dastardly security
attacks. For network accessible computers,
transferring the contents of the electronic
checkbook to an on-line disk is particularly
risky, since most operating systems lack
sufficiently robust security to protect the
electronic checkbook from being accessed via
the network. For example, for Unix based software,
information can be stolen via the judicious use
of either the /proc or /dev/kmem interfaces.
Equivalent security attacks exist for both
the System 7, DOS, OS/2 and NT operating systems.
Ultimately, it will be necessary to develop the
tamper resistant electronic checkbook. For this
media, the user will key in a personal identification
number (PIN), the amount of the check and the
destination account number. Upon insertion into
a receptacle in the user's computer, the embedded
processor in the electronic credit card will
generate the appropriate electronic check for
subsequent transmission by the user's computer.
Successful deployment of an electronic banking system will
require compromises between security and usability. The
closer electronic banking is to the current real banking
system, the more comfortable people will be with electronic
banking.
People familiar with public key cryptography, PKC, will
see immediate ways to apply the technology to the
electronic banking scheme proposed in this paper.
However, the PKC technology is exclusively licensed to
RSA Data Technology and any software containing the
technology is certainly under export control. Thus,
there may be difficulty getting an export license to
the rest of the world. Since the patents are exclusively
licensed to RSA Data Technology, people can not legally
thwart the export license issue by writing the software
outside of the United States, without being in violation
of the MIT patents. Thus, while the PKC technology is
quite attractive technologically, it is between RSA Data
Technology and the NSA whether a world-wide electronic
banking system can be based on the technology.
It is the contention of this paper that a perfectly
workable electronic banking system can be constructed
using either PKC or DES. One based on DES appears to
have less political risk and is presented next.
An electronic check basically consists of a message
that contains:
-
the bank number, bank phone number, and
account number being debited.
-
the amount of money being transferred.
-
a unique check number.
-
an electronic signature.
The electronic signature involves taking the check
number, looking up the corresponding 54-bit key on
the electronic checkbook disk and encrypting the
amount, bank number, bank phone numbers, and account
numbers in cipher chaining mode.
Referring to the figure above, the following steps occur
when an electronic check is processed:
-
The client requests some service from the
server.
-
The server checks the client's server account
and discovers that there are insufficient funds.
to service the request.
-
A message is sent back to the client requesting
that additional funds be transferred to the
server before the service request can be
completed; the message contains the bank number
and account number of the server's electronic bank
account. The most secure way to transfer the bank
< account number from the server to the client is to
use cryptography to ensure that no criminal
compromises the server's electronic bank account.
In order to use cryptography to secure this message,
the client and server will need to have exchanged
some secure keys.
-
The client receives the funds transfer request
message from the server; if it is encrypted,
the client will look up the appropriate key
and decrypt it. A message shows up on the
client's screen requesting a fund transfer.
The client decides how much money to transfer
and types in the amount. The electronic check
writing software asks the client to insert
their 3.5 inch floppy disk electronic checkbook
into the computer. After insertion, the current
check number is read from the disk and the
appropriate 54-bit random key is read from
the disk. An electronic signature is generated
by encrypting both bank numbers, both bank
phone numbers, both account numbers, the
amount, and the check number using the 54-bit
random key in DES cipher chaining mode. The
contents of the electronic check are recorded
back on the 3.5 inch floppy disk for future
reference (just like a check register for real
checkbooks.) The client software ejects the
electronic checkbook from the drive. Finally,
the client software sends the electronic check
to the server.
It is interesting to note that the contents of
the electronic signature are completely available
in the clear portion of the electronic check.
Thus, a brute force attack of checking all 254
possible key combinations is particularly easy.
However, since each electronic check uses a one
time keyand is redeemed almost immediately, the
benefit of discovering the an electronic check's
key is pretty minimal.
-
The server receives the electronic check and
immediately forwards the check to the server's
bank for verification.
-
The server's bank receives the electronic check.
The server's bank immediately calls up the
client's electronic bank to verify the
authenticity of the electronic check. The phone
number to call is stored in the clear in the
electronic check. The electronic check is
immediately forwarded to the client's electronic
check.
-
Upon receiving the electronic check, the client's
electronic bank looks up the account number and
check number, reads the corresponding 54-bit
random key it has on-line, decrypts the electronic
signature and verifies that it exactly matches
the rest of the check. If the signature is an
exact match, the electronic check is good and the
client's bank now owes the server's bank the
designated amount of funds.
-
If the client's bank and servers' bank do not
trust one another, the server's bank can insist
upon an immediate electronic funds transfer
between the client's real bank and the server's
real bank. If the server's bank decides to trust
the client's bank that the electronic check will
be honored, the server's bank is effectively
extending credit to the client until the client's
bank gets around to transferring the funds. It
is between the server's bank and the server to
negotiate who will incur the loss if the client's
bank never actually transfers the funds.
To secure the verification step against criminals
falsely saying that the check is good, the
verification message must be protected by
cryptography. Thus, for full security, the client
and server electronic banks must have exchanged
random keys.
-
Up receiving verification that the check is
good (or that the funds are now on deposit in
the server's bank), the server's bank sends a
message to the server saying that the electronic
check is good; to secure this message against a
criminal, this message should be encrypted using
the server's electronic checkbook.
-
The server receives a message saying that the
check is good and credits the client's server
account.
-
The service that the client originally asked
for is provided.
While there are a fair number of steps outlined here,
each step is pretty straight forward.
If the client's bank and server's bank are separated
by a geographic distance, the phone call from the
server's bank to the client's bank will incur a
significant expense. If the client is located
geographically closer the client's bank, it is
possible to avoid this expense by having the client
temporarily disconnect from the server, call the bank
for verification, get the verification message,
reconnect to the server and forward the verification
message to the server; this expense reduction strategy
will only work if both banks have already exchanged
secure keys or if the server insists upon an electronic
funds transfer prior to honoring the electronic check.
While there is a great deal of hard work required to
do a detailed design of the electronic checking
protocols and convince the user community that the
protocols are secure from criminals, hopefully, the
overall electronic banking scheme has been presented
in enough detail to convince you as to its overall
ability to be implemented.
The Electronic Marketplace
Once electronic banking is in place the technology
is in place to do more than exchange money for
information. Other goods and service can be purchased
via electronic banking.
For example, a manufacturer of goods can publish a
catalog of goods via electronic publishing. Users
can browse the catalog, choose some goods, mail a
request to the manufacturer, and the manufacturer
can directly ship the product to the customer. Indeed,
it is possible to conceive of manufacturers who will
not manufacture the product until the order is received.
This transaction is quite interesting in that there is
no need to have any manufacturer to wholesaler to
retailer to customer mark-up. Thus, the customer has
the potential of reaping a substantial savings over
both the standard retail and mail-order channels.
You can go to the next chapter that contains
summary information or back to the
table of contents.
Copyright 1992-1995
Wayne C. Gramlich All rights reserved.