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:

Electronic Banking

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:

  1. 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.)

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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 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.

Initial Electronic Check Processing

Referring to the figure above, the following steps occur when an electronic check is processed:

  1. The client requests some service from the server.

  2. The server checks the client's server account and discovers that there are insufficient funds. to service the request.

  3. 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.

  4. 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.

  5. The server receives the electronic check and immediately forwards the check to the server's bank for verification.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. The server receives a message saying that the check is good and credits the client's server account.

  11. 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.