Digital cash doesn’t have to involve the Internet. But a number of Internet payment schemes are digital cash. Some of the confusion about digital cash is a confusion about Internet payment schemes. So let’s look at these in context.

Most Internet payment schemes address some issues of security, but make little effort to address personal privacy. However, our time will not be wasted by looking at them. For almost all practical issues surrounding Internet payments are practical issues in any digital cash system. Our goal is to make privacy practical--and not to leave it at the mercy of those hot-air libertarians who can discourse endlessly on politics, but who cannot in fact write a check.

Cypherpunk founder Eric Hughes formulated the motto: “Cypherpunks write code.” Which was intended to emphasize that the use of cryptology to preserve freedom is a practical agenda. As it turned out, some cypherpunks write code and some don’t. Government agencies like the NSA and the FBI have dedicated themselves to making tyranny practical. The least that sovereign individuals can do is to work to make privacy practical. Or else they must concede that the Masters of Tyranny represent a superior force, deserving--de facto and de jure--of every obeisance the masses can give them. Kneel, slave.

Internet payment schemes generally fall into one of three broad categories.

First, are secure credit card transactions. Here the focus is on securely interfacing with the existing credit card network. Security is provided by encrypting the credit card number. This type of system raises important issues. An encrypted credit card number is not itself a digitally signed medium of exchange, and hence does not qualify as bona fide digital cash. But it does highlight a principal concern of all digital cash systems. A customer must be identified or authenticated in some sense before the encryption on the card number becomes a signature. True, the encrypted number cannot be read en route by an eavesdropper. But just as anyone can place a fraudulent order over the telephone, so can anyone who knows a card number send it encrypted over a network.

Next are credit-debit systems. In these systems, customers open an account in one of a specialized network of payment servers. They then authorize charges against their account. For example, in NetCheque, customers can digitally sign a payment check against their account. It is digitally countersigned by another account holder receiving the check. By definition, this represents a digital payment message bearing a digital signature which functions as a medium of exchange or store of value, so these checks are bona fide digital cash. The accounting servers handle the formalized payment protocols which allow for Internet payments in a simple and efficient manner. The payment server itself maintains a line to the ordinary banking system. There is no reason the payment server cannot handle anonymous accounts--in which case the payment server becomes the interface between the anonymous and non-anonymous banking system. If a customer must always maintain a positive balance with the payment server, it is called a “debit” system, while if a customer is allowed negative balances which are billed later, it is called a “credit” system.

Third are digital token systems. Here customers purchase electronic certificates from a bank or a currency server. These certificates are digitally signed and function as digital tokens which can be transferred off-line to others in payment. This contrasts with the credit-debit model, where one customer account must be reduced while a second customer’s account is simultaneously increased. Instead, the digitally signed tokens which are digital cash circulate as a general liability of the bank or currency server. A withdrawal of digital cash by one customer does not result in an imediate credit to the account of another customer. In fact, in anonymous digital cash, any connection between one customer’s withdrawal and another customer’s deposit is automatically severed.

The remainder of this article focuses on the first category: secure credit card transactions. We will look at some general protocols such as iKP, SET, and EMV, as well as some actual and proposed commercial implementations, including CyberCash, First Virtual, Security First, First Bank of Internet, BankNet, and Open Financial Exchange.

iKP is a family (i = 1, 2, 3, . . .) of on-line payment (Internet Keyed Payments) protocols built on existing authorization and clearing systems for credit cards. These protocols are only for payment, and not order, information. The latter is assumed to be protected by some other security mechanism, such as S-HTTP or SSL (which we will not discuss in this article). This separation between payment and order information is intentional, in order to allow iKP compatibility with different web browsers, and to separate iKP from issues related to the restrictions that U.S. ITAR regulations may impose on bulk encryption. The iKP protocols were developed by IBM, and can be implemented in hardware or in software.

The iKP protocols are intended to take advantage of the already existing credit card network, and proceed from there by evolution. In its simplest conception, iKP allows someone to transmit his credit card number securely over the Internet. To do this, it uses public key cryptography, which involves public key/private key pairs (referred to simply as "key pairs," below). iKP uses RSA as its public key signature and encryption algorithm.

There are three actors in the protocols. The customer is the one who makes the payment. The merchant is the one who receives the payment. And the gateway or acquirer is the one who authorizes the payment (Visa, MasterCard, or Europay, for example). The acquirer-gateway serves as a front end that connects to the already existing credit card clearing and authorization network.

In 1KP, only the acquirer-gateway has key pairs. It might, for example, be Visa. Alice encrypts her credit card number with Visa's public key. She sends this to the merchant. The merchant never sees her card number. The merchant forwards her order containing the encrypted number to Visa, who decrypts the card number with its private key. Visa then authorizes the transaction, placing its signature on the transaction data to guarantee payment to the merchant. Thus neither the merchant, nor other observers who intercept the encrypted message, will be able to fraudulently take advantage of the card number without having possession of Visa's private key also. In 1KP the identity of a customer is authenticated on the basis of her credit card number and (possibly) her secret PIN. 1KP does not, however, offer non-repudiation for either customers or merchants.

2KP adds to this another key pair for the merchant. This allows for non-repudiation of messages originated by merchants, and allows customers to verify they are dealing with bona fide merchants. 3KP additionally adds a key pair for the customer. This allows for non-repudiation by customers, and allows payment orders to be authenticated by the customer's digital signature (in addition to the credit card number and PIN).

iKP assumes a central certification authority (CA) to authenticate the public keys of customers, merchants, and the acquirer-gateway. The CA certifies Alice’s public key by signing her public key, along with information about Alice's identity, with the CA’s own secret key. Then anyone who trusts the CA can verify the authenticity of Alice's public key by using the CA's public key to verify the CA’s signature.

iKP is intended to protect payments from several potential adversaries or security risks. These include the eavesdropper (who listens to messages, and may attempt to get credit card numbers and PINs), the active attacker (who sends forged messages), and the insider (e.g. a dishonest merchant getting unauthorized payments, or a Visa employee stealing PINs). The levels of security provided for each of the three iKP actors by the different protocols are listed in the following Table.

Table: iKP Security Levels

Actor Requirements	Type of Proof	1KP	2KP	3KP
Acquirer-Gateway Requirements	A1: Proof Customer has authorized transaction	X	X	XX
	A2: Proof Merchant has authorized transaction		XX	XX
Merchant Requirements	M1: Proof Acquirer has authorized transaction	XX	XX	XX
	M2: Proof Customer has authorized transaction			XX
Customer Requirements	C1: Impossibility of unauthorized payment	X	X	XX
	C2: Proof Acquirer has authorized transaction	XX	XX	XX
	C3: Proof of Merchant accreditation		XX	XX
	C4: Receipt from Merchant for goods		XX	XX

X: Requirement is satisfied. XX: Requirement is satisfied based on an undeniable proof.

A signature on a message M in iKP does not include the message M itself. That is, it is not a simple matter of encrypting the message with one's private key. Instead, first a message digest (one-way hash) of M is produced using the hash function H, yielding H(M). This hash value can then be signed (encrypted) with the secret key sx of actor X, yielding E_sx[H(M)].

There are basically five steps ("flows") in iKP. The exact content of each step depends on whether we are talking of 1KP, 2KP, or 3KP. The essential difference in content between the three is the increasing use of signatures from 1KP to 3KP.

The protocol starts with the assumption that the Customer and Merchant have already agreed to the description (DESC) and price (PRICE) of the items being purchased. Then events proceed as follows:

1. The Customer Initiates the payment process.
2. The Merchant responds by providing an Invoice.
3. The Customer makes Payment.
4. The Merchant sends an Authorization Request to the Acquirer-Gateway;
the Acquirer-Gateway sends an Authorization Response to the Merchant.
5. The Merchant provides the Customer a Confirmation.

1. The Customer creates a pseudo-ID (CID) which will identify the Customer for the purposes of this transaction. To do this he generates a random number (RC), concatenates this with his credit card or Customer Account Number (CAN), and computes a hash value: CID = H(RC,CAN). The customer creates a second random number (SALT), to be used in connection with the merchandise description (DESC). The Customer sends CID and SALT to the Merchant as an Initiate message:

Initiate = {SALT, CID}.

2. The Merchants gets SALT and CID from the Initiate message. The Merchant generates DATE, which is a time stamp to prevent replay of messages. In addition, the Merchant generates a random number (NONCE). The Merchant next chooses a transaction identification (TID) which identifies the context of the current transaction. Then the Merchant computes H(DESC, SALT). Next the Merchant adds its ID (which identifies itself to the Acquirer- Gateway) and the price (PRICE) of the merchandise to this list, forming the composite array COMMON:

COMMON = {PRICE, ID, TID, DATE, NONCE, CID, H(DESC, SALT)}.

Finally, the Merchant computes a hash value for COMMON, H(COMMON), and sends an Invoice to the Customer. The Invoice consists of these:

Invoice = {ID, TID, DATE, NONCE, H(COMMON)}.

3. The Customer obtains ID, TID, DATE, and NONCE from the Invoice. The Customer adds to these his already existing knowledge of PRICE and CID to recreate COMMON. The customers computes the hash of COMMON, and verifies it matches the value H(COMMON) in the invoice. The Customer then forms the composite SLIP:

SLIP = {PRICE, H(COMMON), CAN, RC, PIN}.

Finally, the Customer encrypts SLIP with the public key of the Acquirer-Gateway, forming E_A(SLIP). This forms the Payment message returned to the Merchant:

Payment = {E_A(SLIP)}.

4. The Merchant sends an Authorization-Request to the Acquirer-Gateway, made up of three elements:

Authorization-Request = {Invoice, H(DESC, SALT), Payment}.

The Acquirer-Gateway (A-G) receives the Authorization-Request, and takes the following steps:

a. The A-G extracts the Invoice and checks for replays. There should be no previously processed request with the same ID, TID, DATE, and NONCE.

b. The A-G decrypts Payment using its private key. It checks that H(COMMON) in Payment (computed by the Customer) is the same as H(COMMON) in Invoice (computed by the Merchant). This shows that the Customer and the Merchant agree on the order information.

c. Next the A-G recreates COMMON. From the Invoice it has ID, TID, DATE, and NONCE. From the Payment it has PRICE, CAN, and RC. It computes CID = H(RC, CAN). It also has H(DESC, SALT) from the Authorization-Request. The A-G puts these together to make COMMON, computes H(COMMON), and verifies the value corresponds to the value computed by the Customer and the Merchant.

d. The A-G uses the existing clearing and authorization system to authorize the payment on-line. It gets a yes or no response (Y/N). The A-G computes a signature for Y/N and H(COMMON): S_A[H(Y/N,H(COMMON))]. Then it returns an Authorization-Response to the Merchant, consisting of Y/N and the signature:

Authorization-Response = {Y/N, S_A[H(Y/N,H(COMMON))]}.

5. The Merchant receives the Authorization-Response. Since the Merchant already has H(COMMON), he can verify that the signature on {Y/N,H(COMMON)} is valid. The Merchant then sends a Confirm to the Customer, consisting of Y/N and the signature (so the Customer may check it also):

Confirm = {Y/N, S_A[H(Y/N,H(COMMON))]}.

There are some small aspects of privacy. The Acquirer-Gateway is not given DESC, but rather H(DESC, SALT). Thus there is no possibility that either the Acquirer-Gateway or an eavesdropper on the Merchant to Acquirer-Gateway link will produce a Customer "list of purchases". (To do so would require that one obtain the value of SALT, which could only be obtained by monitoring both the communication between the Customer and the Merchant, and the Merchant and the Acquirer-Gateway, and correlating the two streams). At best the Acquirer-Gateway could compile a list of Merchants the Customer has dealt with.

In addition, the protocols do not reveal the identity of the Customer to the Merchant, because the Merchant only has the CID, which is pseudo-ID created by the Customer for the transaction.

However, the Customer is not anonymous to the Acquirer-Gateway. The Acquirer-gateway gets credit card numbers (or CANs) and PINs, and must be trusted to keep these confidential.

In particular if the Merchants colluded with the Acquirer-Gateway (or better stated, if FinCEN put together information from Merchant files with information with the Acquirer-Gateway file), it would be possible to create a dossier containing both the Customer's true identity and a complete description of his purchases. Thus iKP gives needed security from tranmission errors, misunderstandings, and frauds, but would require extentions to become a secure and anonymous system of digital cash. It remains, however, as the mother of all secure credit card payment schemes.

SET (Visa and MasterCard)

The SET (Secure Electronic Transaction) specification is a technical standard for making credit card purchases over open networks announced by Visa International and MasterCard on February 1, 1996. SET incorporates public key cryptography from RSA Data Security (whose upgraded BSAFE 3.0 encryption engine contains all the cryptographic modules required to implement the SET specifications). This includes 56-bit DES, and RSA public/private key pairs using a 1024-bit modulus.

The overall framwork is similar to--indeed derived from--iKP: SET requires software by the Customer and the Merchant, decryption technology in the hands of the Acquirer-Gateway, and Certification Authorities to issue digital certificates. SET can be implemented on many different platforms, including PowerPC, MS-DOS, Windows, Macintosh, OS/2, Intel, Sparc, and UNIX.

The business requirements addressed by SET, according to its proponents are these:

As would be expected, the confidentiality of transmitted information in SET is ensured by message encryption, and the integrity of payment information is ensured by digital signatures. SET uses DES symmetric key encryption, along with RSA digital signatures for authentication and key transfer. A cardholder (customer) is authenticated through a digital signature along with a cardholder certificate issued by the cardholder's bank. A merchant is authenticated through a digital signature along with a merchant certificate issued by the acquiring bank. Interoperability is enabled through the use of specific protocols and message formats. SET messages are transferred as MIME messages, and SET cryptographic encapsulation follows PKCS-7 (Public Key Cryptography Standard, Number 7).

SET uses 160-bit message digests produced by the SHA-1 hash algorithm, and two public/private keys pairs. One pair is used in symmetric key exchange. A message will be encrypted using a randomly-generated DES symmetric session key, and the first public key pair is used to encrypt and decrypt the DES session key. The second key pair is used to create and verify digital signatures. A message will be hashed by SHA-1 and then signed with the private key of the second key pair, and afterward verified with the corresponding public key.

Each public key needs a digital certificate. A certification authority creates and signs digital certificates that bind identifying information of the customer to the customer's public keys. The CA certificates follow the X.509, version 3 format.

We will not go through the same level of detail for SET as we did for iKP. But, as a simple summary, the steps in the SET commercial transaction protocol are these:

1. The customer requests a transaction from a merchant.
2. The merchant acknowledges the request.
3. The customer sends a purchase order to the merchant.
4. The merchant sends the customer a purchase order verification.
5. The merchant sends to the acquiring bank the customer payment data.
6. The acquiring bank verifies the customer data.
7. The customer, meanwhile, may send a status query to the merchant.
8. If so, the merchant responds with purchase status information.
9. The merchant requests payment from the acquiring bank.
10. The acquiring bank sends payment to the merchant.

In the first two steps, the customer and merchant agree to do business, exchange certificates, and create a transaction ID number. In step 3, the DES- encrypted customer purchase request contains a SHA-1 hash of the goods and services order signed by the customer's private RSA key (which is done by customer software outside the communication protocol). This purchase request also contains the consumer's credit card information, which is first encrypted using the RSA public key of the acquiring bank, so that only the acquiring bank (and not the merchant) can read it. At this point, the merchant can acknowledge the order to the customer, and seek verification (steps 5 and 6) later; or the merchant can perform steps 5 and 6 first, then confirm authorization to the customer (step 4). Steps 7 and 8 are optional: they give the customer a query capability. The merchant uses steps 9 and 10 to submit authorizations in order to receive payment.

Notice, however, that "confidentiality" here means messages cannot be read in transit, such as at Internet gateway routers or local access providers. The customer's credit card number is likewise concealed from merchants (eliminating a frequent source of fraud). But the SET acquiring bank is privy to all transaction information. It can both link together transactions made by a customer, and it can link purchases to credit withdrawals on the credit card. The credit-card issuing banks can do this also. Hence SET is designed to facilitate electronic commerce over the Internet, but it does not provide any important aspects of personal privacy or anonymity.

In the very similar CyberCash system, considered below, CyberCash is assumed to know everyone's public key. SET, however, uses certification authorities, which bind identities to public keys. This makes the SET application potentially more secure, but puts a burden on credit-card issuing banks to have certificates issued to their cardholders. (SET, however, makes this requirement optional.) It also requires the acquiring bank to issue certificates to merchants.

EMV Global Chip Card Payment Infrastructure

EMV has created a set of joint specifications for Integrated Circuit (IC) cards for payment systems. An updated version of the specifications for data structure, security, and communication protocols was announced in July 1996. EMV is Europay International (Waterloo, Belgium), MasterCard International (New York), and Visa International (San Francisco). Each organization represented, respectively, about 114 million, 420 million, and 402 million cardholders.

The goal of the EMV joint venture was to 1) establish authentication methods for off-line payments, and 2) to decide on global specifications for electronic purses/wallets/stored-value cards. The EMV infrastructure was based on ISO specifications for microprocessor cards and card-reading terminals.

Some of the subjects addressed include these:

In December 1996, the three EMV partners announced they would begin work to link the EMV chip card standards to the Visa and MasterCard SET specifications. Chip card holders could in that event make Internet transactions using a chip card reader attached to a PC.

EMV will be covered in more detail in an article devoted to smart cards.

CyberCash

CyberCash operates as a gateway between the Internet and traditional credit card authorization networks. It essentially provides a communication interface. The CyberCash Wallet software may be freely downloaded from the Internet at http://www.cybercash.com/.

The customer software allows the customer to register several credit cards which will be used to make payments over the Internet. A customer's software generates an RSA public-private key pair for the customer, and also stores CyberCash's public key. Customers' public keys are sent to CyberCash and stored in a database. Internet payment messages are then encrypted using a randomly generated 56-bit symmetric DES encryption key. This symmetric key is attached to the message and is itself encrypted using the recipient's 768 or 1024- bit public key.

Customers, merchants, and CyberCash all have public-private key pairs. However, customers and merchants communicate order instructions to each other in the clear. The customer (who must have a Web browser and a copy of the CyberCash Wallet) selects an item from a WWW catalog page. The merchant responds with a payment request that describes the item being purchased, and a list of credit card types the merchant accepts. The customer selects one of his pre- registered credit cards and sends an encrypted message, which includes the payment information and the item description, to the merchant. The symmetric key used in the message is encrypted with CyberCash's public key; hence the merchant cannot read it. The merchant forwards the customer's message to CyberCash along with its own encrypted version of the transaction. CyberCash decrypts the two messages and compares them for compatibility. It then submits an authorization request to the credit card network. Once the charge is authorized, CyberCash sends a confirmation response to the merchant. The merchant notifies the customer that the purchase is approved.

Note several things about this process. CyberCash operates as an agent of the merchant's bank. The customer's credit card number is encrypted, so it can't be read en route. Neither does the merchant see the credit card number, unless CyberCash releases this information to the merchant at the request of the merchant's bank. (Such a release is not unlikely given that many merchant records are organized by credit card number.)

Moreover, there is no anonymity in this process. CyberCash can both link and trace customer transactions, since it sees and identifies each customer transaction. Moreover, because CyberCash uses the ordinary credit card authorization network, the credit card company can also link and trace customer transactions in the ordinary fashion--as seen in a customer's credit card statement.

Thus the service CyberCash provides is security in transmission of credit card numbers, as well as verification that customer and merchant are looking at the same transaction. CyberCash itself collects a fee from the processing bank for each such payment made. CyberCash has said it will make its system compliant with Secure Transaction Technology (SET). CyberCash security features are incorporated into CheckFree's Wallet (discussed below).

The CyberCash system uses strong encryption, but only for small sections of a transaction message. In particular CyberCash received permission from the US government to use 768-bit RSA public keys in export products. Export approval for 768-bit keys is not surprising, given the fact there are no aspects of ultimate secrecy with respect to the transactions themselves.

In addition to its credit card interface, CyberCash also runs a digital cash system called CyberCoin, which is discussed in Part II of this article.

First Virtual

First Virtual is not included here as an example of a secure messaging implementation, but almost as a counterexample. San Diego-based First Virtual uses ordinary email and no encryption. Security in the First Virtual system relies firstly on the cost and effort required to monitor multiple communication channels, and secondly on the buyer's right to revoke a payment within a certain time.

The system was principally designed to handle the purchase and sale of information over the Internet. To open a server account, a customer contacts First Virtual and establishes an account ID. The customer then phones or faxes a list of credit card numbers to First Virtual, which keeps them in a database.

Transactions are then effected via email. When a customer wishes to purchase information over the Internet, the customer provides his customer ID (or "vPIN") to the merchant. The merchant checks with the First Virtual server to see if this ID is valid. If it is, the merchant sends the information to the customer over the Internet. In the meantime, First Virtual sends an email message to the customer, asking if he is willing to pay for the information. The customer responds with "yes," "no," or "fraud".

If the answer is "yes", First Virtual submits the customer's credit card number through the usual credit network, charging the card for the information. First Virtual then holds the funds for 90 days. This allows the customer time to dispute his credit card bill, and allows First Virtual to earn interest on the funds. If everything is okay, First Virtual then transfers the funds to the merchant's bank account (which may be at another bank).

There is no encryption. Messages in these transactions are sent in the clear, although First Virtual account IDs can function as pseudonyms. (Eavesdroppers will, however, be thwarted if a secure messaging protocol such as S/MIME is used.) The essential security is provided by the customer, who is required to monitor his own credit card payments for fraud. Merchants have to rely on the assumption that most customers are honest, and will not deny receiving information for which they are satisfied.

And just as in previous examples, there is no privacy or anonymity provided to the customer. All transactions can be linked through First Virtual, or through the ordinary credit card channels. In fact, merchants may be concerned that a customer has a habit of frequently accepting information, then claiming it was not what he wanted--simply to avoid paying for it. This would require First Virtual to maintain a log of information about the customer, in addition to the transaction records already maintained by the credit card companies.

Security First

Security First Network Bank (SFNB) opened its virtual doors on Oct. 18, 1995, and became the first financial institution to receive the approval of the Office of Thrift Supervision (OTS) to offer banking services over the Internet. Its Virtual Financial Manager software, provided by its subsidiary Security First Technologies, allows customers to open accounts, check balances, and make payments by computer through any Internet connection supporting World Wide Web.

SFNB began as a unit of Cardinal Bancshares of Lexington, Kentucky, and was spun off to Cardinal's shareholders. Additional investment in SFNB came from Wachovia Corp. (Winston-Salem, NC), Huntington Bancshares (Columbus, OH), and Area Bancshares Corp. (Owensboro, KY).

As part of the Cardinal spin-off, SFNB acquired the stock of WebTech, Inc., which developed the SFNB Internet banking software. WebTech was in turn created by senior executives from the Atlanta computer security firm SecureWare, which supplied security software to the military and intelligence establishments. WebTech and SecureWare have been folded into Security First Technologies. More recently, SFNB abandoned its on-line banking business to devote itself exclusively to banking software.

The chief claim to fame of SFNB was in offering military-grade firewalls to protect the bank from unauthorized Internet intruders. As initially reported in one newspaper: "A small Kentucky bank, working with a high-tech company that builds computer systems for the Defense Department, is poised to offer Internet banking that it says will be safe from hackers" (Minneapolis Star-Tribune). (Many bank customers, of course, are interested in security not only from hackers, but also from the prying eyes of a virtual alphabet soup of government agencies.)

When an account is opened on-line with the SFNB software, the information (name, address, social security number) is checked with a credit service to see if it is consistent with information publicly on file. A physical copy of the application and a signature card must be mailed to the bank. An account creation package and an account password is then mailed to the customer to set up the account. Customers then communicate with the bank via World Wide Web, using any browser that supports SSL. (SSL uses encryption for the data passing between the customer's browser and the bank server: it encrypts the entire channel.)

The bank operates on a trusted operating system owned by Hewlett- Packard called VirtualVault. The trusted operating system replaces the Unix root account (which grants access to all areas of the operating system) with a mechanism of privileges which limit each user's actions to the commands they have been authorized to use. An additional system of firewalls and filtering routers separate the bank's internal network environment from the Internet.

In addition to the normal controls involving access controls and firewalls, the system uses RSA public key encryption technology for data integrity, identification, and authentication. All of this ensures that SFNB software does not deal with imposters. But it gives no special transactional privacy to the customer. It is simply on-line banking with access and communication protection. Accounts opened under the SFNB software are ordinary banking accounts and insured by the FDIC.

First Bank of Internet

The First Bank of Internet (FBOI) was an ad hoc proposal to operate an Internet-secure messaging system to match buy and sell orders between customers and vendors (merchants), and to transfer payments. As outlined in a press release, a FBOI customer first sets aside dedicated funds to be used for Internet purchases. Afterward, the customer uses PGP-encrypted email to place orders with merchants. FBOI (the proposal, anyway) compares the customer and merchant versions of each order for compatibility, withdraws funds from the customer's dedicated cash account, and credits the merchant's account (or sends a payment check to the merchant).

To open a FBOI account, a customer sends cash, check, or money order to FBOI, which purchases a pre-paid, PIN-protected Visa ATM card on the customer's behalf. This card gives the customer access to an FBOI ATM checking account of equal amount. That is, the customer agreement allows FBOI to possess a duplicate cash card, and FBOI withdraws cash from the customer's Visa ATM account in increments of $10 as Internet purchases are made.

FBIO charges the customer a hefty 5 percent commission to buy the Visa ATM card. The cash in the Visa ATM account is then good either for Internet purchases through FBOI, or alternatively it may be retrieved at one of the thousands of ATM machines that are part of the Visa/PLUS system.

The difference between this and an ordinary checking or credit account is that, because of the cash nature of the initial acquisition of the Visa ATM card, the FBOI does not collect any financial or employment information from the account holder. The account is essentially anonymous with respect to solicited credit and employment information. However, FBOI knows the customer's mailing address (in order to mail the ATM card to the customer) as well as the customer's email address (associated with the customer's PGP public key). In addition, the customer's FBOI account number is the "fingerprint" of the customer's PGP public key. (A PGP "fingerprint" is the 32-hexadecimal-digit MD5 hash value of the customer's public key.)

When a customer makes a purchase, the customer sends a PGP-encrypted message (called an "email check") to the merchant. The merchant sends a PGP- encrypted message (called an "email invoice") to FBOI. FBOI verifies the transaction, sends receipts to both customers and merchants, takes cash from the customer's ATM account, and credits it to the merchant. The FBOI charges the merchant 5 percent of each transaction for the service of matching customer checks with merchant invoices. (The customer is not charged fees for orders--but only for the initial purchase of the Visa ATM card.)

All purchases are traceable and linkable by FBOI via the customer's PGP public key and email address. Merchants have the ability to keep similar records for sales with respect to the same customer. Hence there is no anonymity or privacy in the system. Essentially the FBOI service (or proposed service, at least) allows a customer with nothing more than cash and an email account to make Internet purchases. ("Bad credit? We don't care.")

BankNet

MarketNet, BankNet (a Hungarian satellite data communication company), and Secure Trust Bank Plc (a British bank) have formed a joint venture to operate banking services over the World Wide Web. The accounts are ordinary Sterling-denominated bank checking accounts ("current accounts"), which may be opened at http://mkn.co.uk/bank. Statements can be viewed on-line with a Netscape web browser. Foreign transactions available to Secure Trust customers include international money orders in sterling or U.S. dollars, bankdrafts in any currency, and telegraphic transfers to any bank account abroad.

BankNet also offers an electronic payment system for Secure Trust customers. WorkHorse, the check-writing program, runs under Windows or Windows95. Aspects of the system include the following items.

Key Generation and Use: The account holder on a Windows PC (which may or may not be connected to the WWW) uses WorkHorse to generate an RSA public/private key pair of 512 to 1024 bits. The account holder must also provide an alphanumeric password. The private key is RC4 encrypted, base64 encoded, and stored on a disk (preferably floppy, but it could be the hard disk.) For the account holder to use the key, he must possess both the key file and the password, and must load the key file into the key-using program providing the password. (Alternatively, the customer can use PGP, in which case the details are those relavent for PGP, which is not covered here.)

Key authentication: The account holder generates a certificate request, base64 encodes it and sends it to the bank which generates a printed form for the account holder to sign. This will apply limits for payments and limits for aggregation of payments.

Signed Instructions: The account holder using the keyfile and password can then generate a number of instructions, for payment, buying securities, and selling securities. These instructions may not be repudiated, but each instruction will only be processed once.

The normal business advantages of the above scheme from the merchant's point of view would be low merchant commissions and certainty of payments. Purchasers of products, services and information would essentially bear transactions costs and any charges for repudiation.

Open Financial Exchange (CheckFree, Intuit, Microsoft)

On January 16, 1997, three companies--Microsoft, Intuit, and CheckFree-- announced they were creating a single, unified technical framework, called Open Financial Exchange (OFE). OFE would enable financial institutions to exchange financial data over the Internet with World Wide Web users, as well as users of popular financial software like Quicken or Microsoft Money. The Open Financial Exchange specification represented a convergence between Microsoft's "Open Financial Connectivity", Intuit's "OpenExchange", and CheckFree's electronic banking and payment protocols. First, some background on the companies involved.

CheckFree is an Atlanta, Georgia, based corporation founded in 1981. It provides electronic home banking and bill payment processing services to more than 200 financial institutions. The bank controls the customer relationship, while CheckFree provides back-office processing.

CheckFree Corporation also markets the CheckFree Wallet, which it describes as a "secure, cheap, and easy to use Internet transaction product for World Wide Web users." The security features of the Wallet were adopted from CyberCash (discussed previously). The Wallet generates 768-bit RSA public/private key pairs to enable secure Internet transmission of credit card numbers. An online shopper enters a password on her computer to open an on- screen wallet and selects a credit card payment option. After reviewing the order, the customer clicks a "pay" button to complete the transaction. The order, including the customer's shipping address and other information in encrypted form, is then transmitted to the merchant. Payment instructions are forwarded by the merchant to CheckFree for decryption, authorization, and processing. Once authorized, the payment is debited from the customer's credit card and credited to the merchant's account.

The Wallet integrates into Netscape and Microsoft web browsers, and existing retail order and fulfillment systems. The Wallet has been developed under an open system to accommodate standards adopted by the World Wide Web Consortium (W3C).

Intuit, Inc., of Menlo Park, California, is a financial software and Web- based services company. It develops and markets well-known personal finance products such as Quicken, the tax-preparation software TurboTax, and the small business accounting software QuickBooks. It also operates Quicken Financial Network (www.qfn.com), a mutual fund Web site (NETworth.galt.com), and a personal insurance site (InsureMarket.com). In October 1995, Intuit announced that the 1996 version of its Qucken software for Microsoft Windows would contain several integrative features: Internet access through Concentric Network Corp., a version of the Web browser Netscape Navigator, and free access to Quicken Financial Network.

This was followed by a joint agreement in November with Internet access provider America Online, Inc., to provide electronic banking services to AOL members. Under the agreement, AOL would sell Intuit's Quicken software to its customers, while Intuit would include AOL links to the Quicken Financial Network. The latter in turn has links to financial institutions through the Intuit Services Corporation (ISC) ISC was subsequently sold to CheckFree

An individual bank would make its services available to AOL and Quicken users through a single connection to ISC. The services provided by Intuit to AOL users would be included in their monthly subscription fee. Security procedures included a personal identification number and RSA Data Security encryption combined with triple DES.

Microsoft is a large personal computer software company founded by Bill Gates in 1975. It publishes personal financial products like Microsoft Investor and the Microsoft Money personal financial management program.

With this as background, let's look at Open Financial Exchange. OFE is a unified framework for the electronic exchange of financial data between financial institutions, businesses, and consumers. OFE which will enable the connectivity of many electronic banking products, and banks will find it a low- cost entree into on-line banking services. Microsoft, Intuit, and CheckFree, meanwhile, are implementing Open Financial Exchange across their entire lines of financial software products--which are sufficiently extensive to make it an Internet standard.

OFE uses standard Internet transport protocols, and is designed to be supported across Windows95, Windows 3.1, Macintosh, UNIX, and network computing devices. It uses HTTP for communications, and Secure Sockets Layer (SSL), version 3.0, for channel security. SSL uses public-key encryption to negotiate a session key between client and server, and this key is used to encrypt the data passing over the channel. However, many Web servers do not run behind a firewall, so there is an opportunity for someone to observe data after it has been decrypted, but before it has been passed to an internal secure network. To deal with this issue, OFE uses message-based security also: RSA public keys, DES symmetric encryption, and X.509 certificates for user authenication. (OFE also allows for authentication via a user-entered identification code and password, in place of a X.509 digital certificate signed by a CA.)

Web Page: http://www.aci.net/kalliste/