Charles H. Rothauser

EE578 / CS578 - Cryptography and Data Security

Worcester Polytechnic Institute Section

Until recently, the Internet was used primarily for research by a small segment of society made up of universities and research labs who were comfortable with computers and networks. Indeed, these are the people who invented the Internet and they thrived in the unmanaged free spirit of the net. Now, as business forces integrate web technology into society, secure on-line commerce emerges as a critical technology that will utilize the Internet’s global reach.

Secure Internet commerce will require high-performance cryptographic services especially as transaction rates increase. Quite a number of cryptographic protocols for securing on-line commerce have been proposed. Published proposals include CyberCash [1], NetChex [2], STT [3], SEPP [4], and SET[5]. Among these proposals, STT (Visa and Microsoft) and SEPP (MasterCard and Netscape) are two specifications published by Visa and MasterCard respectively. STT and SEPP were analyzed [6] in the context of an open network and some subtle vulnerabilities emerge. These missing and misused services include: authentication, integrity, and non-repudiation. On June 1, 1997, MasterCard and Visa agreed on a common protocol known as SET (Secure Electronic Transaction) protocol that addresses these concerns and to provide a single royalty free standard.

The new SET (Visa, MasterCard, Microsoft, Netscape, IBM, GTE, VeriSign) protocol [5] uses public key cryptography [11] (RSA Inc.) along with symmetric key algorithms [11] (DES) to provide confidentiality of payment information, ensure payment integrity, and authenticate both merchant and cardholder. The digital signature [11, 12] (SHA) is a main component of SET. It looks like a random series of characters appended to the end of a document, but a one-way algorithm [11,12] calculates it using both the contents of the document and the signer’s cryptographic key [11]. Others can inspect the document to validate the signature, and the signer cannot later deny having signed it.

The author will discuss the vulnerabilities of STT and SEPP in section II. In section III, the author will discuss the key features of SET [7,8] and examine the performance of a software implementation. In section IV, the author will present arguments for specialized hardware solutions [9] which include the use of biometric smartcards [10]. In section V, the author presents conclusions on the role of SET and biometric smartcards in bringing about secure electronic commerce on the Internet.

Visa and MasterCard have been successful in operating private on-line payment networks, both STT and SEPP use some security services that are well understood to be inadequate [6] in open networks. Both STT and SEPP incorporate the working style [6] of a financial institution (acquiring bank or acquirer) who makes on-line payment transactions. This working style can be defined as the acquirer will process at most one on-line payment request per payment transaction. Figure 1 graphically depicts the on-line payment schemes used it STT and SEPP. To clarify the presentation, some message names [6] have been combined that have the same meaning. For example, "Invoice" and "Confirmation": In STT, "Invoice" is called "Merchant Credential" and "Confirmation" is called "Order Acknowledgement". In both protocols, the buyer will first get "Invoice" from the seller.

Figure 1: On-line bankcard schemes [6] used in STT and SEPP.

Both protocols use public-key cryptography, but SEPP [4] also allows the use of conventional cryptography based on the personal identification number (PIN). The analysis [6] will focus on the use of public-key / private-key pairs, since the discovered vulnerabilities apply to other versions as well. The discussion of figure 1 will be in terms of the cryptographic protocols used. The message "Invoice" contains the seller’s and the acquirer’s public-key information (keys and certificates). When the buyer conducts a purchase, a combined message is sent "Order" and "PI" (Payment Instruction) to the seller along with the buyer’s public key information. The "Order" portion is meant for the seller and the "PI" portion is meant for the acquirer.

The bankcard number is treated as confidential data and encrypted in the "PI" with the acquirer’s public key. The seller then makes a payment request by sending the "Auth-Request" message to the acquirer for payment authorization. After the acquirer authorizes payment, the acquirer sends an "Auth-Response" message to the seller. The seller then sends a protocol message "Confirmation" to the buyer and then ships the purchased goods. The "Confirmation" message includes the seller’s signature and thus acts as a receipt of sale. In SEPP, during the on-line authorization, the buyer can make any number of purchase order inquires ("PO.Inquiry") and the seller will respond to every inquiry with the purchase order status and detailed information ("P.O.Response"). In the two protocols, the seller obtains all the needed information to conduct a real transfer of money well before the protocol completes. The following vulnerabilities [6] emerge from such a process.

Internet communications are usually good, but there is no guarantee that a computer on the network will be accessible or reachable at any given time. The Internet uses packet routing and in conditions of heavy network congestion packets will be delayed or lost. If a message is delayed or lost after "Auth-Response", this situation will be frustrating for the buyer. The buyer will experience long delay and will in the case of SEPP send inquires ("P.O.Inquiry") to the seller, get frustrated and end up purchasing the product from a different seller [6]. This not good for the buyer since now the purchase has been done twice! A refund transaction will have to be processed at a later date which adds to the cost per transaction to use the system.

A malicious user, either the buyer or the seller, can achieve a gain by claiming a problem with the network. For example, the seller can advertise goods even when the goods are out of stock. By delaying sending out "Confirmations" to the buyers, the seller can replenish the stock while claiming (when asked) problems with the network. Many buyers will be deceived by this approach [6].

Consider electronic commerce that does not involve the delivery of goods, such as on-line gambling, airline-ticket reservations, and information document selling. With STT or SEPP protocols, the buyer could claim problems with the network and avoid the cancellation fee while getting a cheaper airline fare from another seller. The seller can use the same problem with the network to require a cancellation fee by falsely claiming that the "Confirmation" message was sent. Both protocols (STT, SEPP) have not supplied the service of non-repudiation [6] on proof of receipt. Conceptually the difference between authentication and non-repudiation is authentication involves convincing yourself of the validity of a message while non-repudiation involves proving the validity of the message to a third party [6].

A direct result of malicious behavior or of network problems is a greater expense in system operations. In this view both STT and SEPP do not provide integrity protection. Integrity protection detects message loss, alteration, or corruption over a secure channel running on an open network. An integrity service should be inexpensive to implement but present an attacker with a severe penalty. Both STT and SEPP allow inexpensive attacks [6] to compromise the integrity of the system and they cost the system in fallback (refund) measures.

The two protocols have also overlooked the following fact [6]: the acquirer and the seller have a long time business relationship. Instead of using this relationship in the encryption protocol, they require the acquirer to process session messages from the seller using public-key cryptography. Whereas, a symmetric scheme using shared cryptographic keys will provide the same level of security with much better performance [6]. For example, authentication using RSA signatures is about 100 times slower than using shared keys, and decrypting can be 1,000 to 10,000 slower than using a symmetric key. The acquirer also has to on-line verify the buyer’s signature and validate the buyer’s certificate with a third party (Certificate Revocation List - database). The communication to the remote database will be more time consuming that using the shared keys approach and the RSA modulus exponentiation cycles are very costly when implemented in software [12].

The heavy on-line workload and the exposed position of the acquirer invites the denial of service attack [6]. The attacker sends a large quantity of data to the server and thus jams legitimate communication with that host. In Figure 1, the message "PI" is encrypted with the acquirer’s public key and is not valid at the seller. The attack involves sending a large number of PI’s to the seller along with valid "Orders". When the seller receives the valid "Orders" it just resends them along with the PI’s (replayed data) to the acquirer. In SEPP, the attacker just uses the "Initiate" message which is sent in cleartext and follows it with the recorded PI’s. It is even easier in STT, since there is no "Initiate" message to construct and the seller allows duplicate "Order" messages for ease of ordering. The result is a large number of "Orders" with duplicated PI’s going to the acquirer for authentication.

On June 1, 1997, Visa and MasterCard deployed a more secure solution for open network credit card transactions. Their Secure Electronic Transaction (SET) protocol [7] uses public-key cryptography to provide authentication, privacy, and integrity. Several companies [Netscape, Microsoft, IBM, VeriSign] are building software systems that will incorporate this protocol, which uses digital certificates for authentication and for creating signed digital transactions. The certificates are issued - by consumer banks to their customers (buyers) and by credit card processing centers to their customers (sellers) [7].

All the certificates are linked back to a global root public key shared by Visa, MasterCard and other payment-card issuers. That is, built into browsers, electronic wallets, seller servers, and other commercial software. The problem of always looking up SET certificates is solved [8] by requiring SET messages to contain all the certificates needed for their authentication unless the sender already knows the recipient has the appropriate certificates.

SET has highly specific privacy goals [7]. SET has been designed carefully to prevent the seller from finding out the buyer’s credit card number. Today, sellers always learn the buyer’s credit card number, and this is a major source of fraud. Buyers who use SET put their credit card numbers in a SET message signed for the acquirer [7] not the seller. The seller trusts the acquirer to verify the buyer’s validity [7].

SET was designed to conform to U.S. export control laws, so SET-compliant software can be developed in the U.S. and sold worldwide [9]. RSA Inc. has been granted the right to sell its S/PAY software globally. However, the SET protocol’s business model does not meet the needs of all countries [7]. For example, in Japan most electronic payments involve direct transfers between bank accounts, not credit cards. Buyers tell their banks to transfer their payments directly into the sellers’ bank accounts, avoiding the service charge required by credit card associations. In Japan, consumer bank accounts are often tied to an automated system [7] of loans linked to the quarterly and yearly bonuses that make up the majority of the income of Japanese consumers.

The operation of the SET protocol relies on a sequence of messages [7] (Figure 2). In the first two, the buyer and seller exchange initialization messages which include certificates and establish a transaction ID number. In the third step, the buyer’s purchase request contains a signed hash (NSA specified SHA) of the goods and services ordered. This request is accompanied by the buyer’s credit card information, encrypted so that only the seller’s acquiring bank can decrypt it. At this point, the seller can acknowledge the order to the buyer, seeking authorization later (steps five and six) or perform steps five and six first and confirm authorization in step four. Steps seven and eight give the consumer a query capability, while the seller uses step nine and ten to submit authorizations for remuneration.

In the CyberCash protocol, only CyberCash knows everyone’s public key [8]. SET assumes the existence of a hierarchy of certificate authorities that provide a secure link between a user and a public key. Buyers, sellers, and acquirers must exchange certificates before a party can know what public key to use to encrypt a message for a particular partner in a SET transaction [7].

Although the software industry is moving rapidly to implement SET, the protocol poses significant problems [7] for the banks. Credit card issuers must invest a lot of money to have public key pairs and certificates issued to their credit card holders. Yet the benefits to the SET credit card issuers are not clear [7]. A standard protocol may reduce software costs to sellers and buyers, as well as reduce seller fraud, but the cost of such fraud is born by the banks not the credit card issuers [7]. Also, it is not clear that SET will generate significant new credit card use, as opposed to just moving the current mail and telephone orders [7] to SET. There are many difficult political problems between the sellers, credit card issuers, and the banks to resolve.

Figure 2: Steps in a SET Transaction [7].

At first, software-based cryptography may appear to be economical when implemented at the seller or acquirer [8]. However, software implementations of public key technology are so computationally intensive that an implementation on a general purpose application server spends most of its processor cycles doing cryptography [8]. In fact, as transaction rates increase, software becomes more expensive than hardware. It’s important to look at the cryptographic functions that are required of each party in the SET transaction [8].

Within the SET transaction, the acquirer is required to do six large RSA exponentiation cycles [5] in supporting RSA decryption and digital signature generation. The decryption cycles are required to decrypt digital messages from the buyer and the seller. Digital signatures are required on instructions from the acquirer to the seller indicating that the seller has been paid and that the seller can go ahead and ship the product to the buyer [5]. Other signatures are used to sign an acknowledgement to the buyer that the purchase has been authorized, the account has been debited, and the delivery date of the product has been confirmed [5].

In this analysis of a SET transaction, the focus is on the RSA decryption and signature generation because these cryptographic functions are the most computationally intensive of the whole RSA functions [5]. There are also many DES cycles per transaction with several key exchanges. However, in the software solution, these DES cycles do not steal many processor cycles from the application server processor. Thus they will be ignored in the following calculation.

Suppose today, that the electronic commerce rate on the Internet is 1 transaction per second. It is estimated that this transaction rate will grow to 200 transactions per second [7]in some Internet servers over the next 18 months. We know from above that each transaction has 6 large RSA exponentiation cycles. This means that there will be 1200 RSA exponentiations per second when this rate reaches 200 transactions per second.

We can estimate the impact on the application server’s processing system. We can assume that one RSA cycle takes 60 msec on the application server (60 msec is very fast for the server and represents a best case analysis). We also assume a 1024 bit key size.

Now one SET transaction will take 6 X 60 msec = 360 msec to do the RSA processing. This means that one transaction per second would require 360 msec of the server’s processing system every second just doing RSA cryptographic functions. Therefore, at about 2 ¾ transactions the server would be doing nothing but RSA functions. We can conclude that a software only implementation would require a replacement of the RSA exponentiation, faster server or more processors - not an inexpensive proposition.

In 1985, Neil Koblitz and Victor Miller independently proposed the Elliptic Curve Cryptosystem [11] (ECC), whose security rests on the discrete logarithm problem over the points on an elliptic curve. The elliptic curve discrete logarithm problem [11] can be stated in the following manner. Fix a prime P and an elliptic curve. If Q is a multiple of P, so that Q = xP for some x. Then the elliptic curve discrete logarithm problem is to determine x given P and Q.

The security of the ECC rests on the difficulty of the elliptic curve discrete logarithm problem [12]. As is the case with the integer factorization problem [11] and discrete logarithm problem modulo p [11], no efficient algorithm is known to solve the elliptic curve discrete logarithm problem. Also, the elliptic curve discrete logarithm problem is believed to be harder than both the integer factorization problem and the discrete logarithm problem modulo p [12]. This extra difficulty makes ECC the strongest public-key cryptographic system known today [11].

An implemented ECC system includes the following advantages over RSA and DSA. It is generally accepted that 10**12 MIPS years [13] represents reasonable security at this time, since this would require most of the computing power on the planet to work for a long time. For RSA or DSA to achieve reasonable security, they should employ a 1024-bit modulus, while a 160-bit modulus should be sufficient for ECC [13]. The security gap continues to grow as the key sizes increase. For example, a 300-bit ECC is a great deal more secure than 2000-bit RSA or DSA[13]. State-of-the-art implementations of these systems show that ECC is roughly an order of magnitude [13] (10 times) faster than RSA or DSA.

Consider the results of the analytical SET model introduced above. We found that a single SET transaction took 360 msec. If we use ECC instead of RSA, we can expect a 10 times reduction in the computational time required or 36 msec. The applications server would be able to process 27.5 transactions using SET with ECC, not nearly enough of a speedup to satisfy the 200 transactions per second projection for the applications server!

In addition, there are significant security concerns using a software only implementation. The criteria of an end-to-end security model such as the one employed by SET require that the cryptographic keys and certain data be protected throughout their entire lifecycle. This is true whether the information must be protected for seconds or decades. A credit card or PIN number are data that must never be revealed to the seller in the SET model.

Specialized hardware solutions [10] provide the key to secure, high-performance processing on the Internet. Stored-value "smartcards" offer this type of approach. The idea is to trust a computer about the size of a credit card to store and track your money. Funds can be added to the smartcard (electronic wallet) by the buyer and removed by the seller [7]. The security of the smartcards is based on keys stored in the hardware and used to convince sellers that the smartcard is legitimate and backed by enough money. The smartcard must also recognize legitimate banks so that it cannot be tricked into adding funds that are truly unavailable [7].

The primary benefit of stored-value smartcards is that they eliminate the need for on-line communications with acquirers [7]. In developing countries where there is not an installed wired infrastructure, they can convert the basis of their economies from cash to stored-value smartcards quickly. The EMV [9] (Europay/MasterCard/Visa) standard addresses the use of smartcards in financial payment systems, defining the basic protocols for communication between cards and readers. In 1996, Microsoft Corp.,

announced a joint program with Hewlett-Packard, Bull CP8, Schlumberger Electronic Transactions, and Siemens-Nixdorf Informationssysteme [9]. Their aim is to promote the acceptance of smartcards in the PC environment to deliver network access and electronic commerce [9].

Smartcards by themselves can not solve the problem of the remote nature [10] of the electronic commerce transaction. That is, the same technologies (cryptographic systems, open networks) that has aided in the promotion of electronic commerce has made it more difficult to know who is initiating the transaction. Currently, the individual is at the end of a communication channel and identifiable only by something that they posses, such as a card or something that they know, such as a password, Personal Identification Number (PIN) or encryption key.

Biometrics [10] is the measurement of some physical characteristic of the human body that is unique to that individual. A sensing device reads the physical information from the individual and converts it into a digital record, or "template". The template is compared to a new, real time measurement of the individual’s physical characteristic to verify their identity. The most widely accepted biometric, and the one used by most companies producing biometric devices is the fingerprint.

The fingerprint is very stable over time [10] and a proven unique identifier of an individual. The chance is less than one in one billion that two people, including twins, will have the same print [10]. The fingerprint is also one of the few physical measurements available that can provide enough data to develop a highly accurate verification of an individual. Uncompressed template sizes typically range in 500 to 1000 bytes [10]. It is the only biometric technology, besides voice, capable of being reduced and stored in a computer chip.

This template may be stored at a host site, whether it be a commercially provided shopping network, on-line service, bank, or on a transportable medium such as a smartcard [10]. The biometric verification function can be incorporated with transaction equipment, such as an ATM, a point of sale terminal, PC, or a television. An encryption technology can be used to secure communication between the two sites [10]. The user places their finger on the verification device and an identity verification is performed against the stored template [10]. The transaction is carried out upon positive verification of the user’s identity.

In September 1992, the UK Plastic Fraud Prevention Forum surveyed the consumer’s reaction to biometrics [10]. When 2,000 people were asked if they preferred PINs, dynamic signature verification, or fingerprint verification at the point of sale, they selected fingerprint verification as the preferred method. It was seen as fast, reliable, easy to use, and highly secure [10].

In a distributed architecture the individual’s fingerprint template is stored in the smartcard. This is the more appropriate architecture with a large number of users. When the user uses the smartcard, they place their finger on a scanning device that takes the image of the fingerprint and applies it against the previously stored template on the card. If the user is the true owner of the smartcard, authorization is granted.

In the short term, SET is likely to have a significant impact in that it will raise the level of consumer confidence in making on-line payments over the Internet [9]. Once SET is widely supported in Web browsers and other applications, it is likely to have a big impact on the amount of business transacted over the open Internet [7]. For electronic commerce to be successful on the Internet, there must be readily available methods for all people and businesses to participate in a secure manner.

The author feels that a distributed architecture of biometric smartcards and smartcard readers would bring electronic commerce to everybody. Abuse by governments must be controlled and the rights of the individual protected. However, the world banking system must fix the fraud which is rampant in the current credit card systems. Biometric smartcards can provide an electronic commerce future where everybody has the capability to send digitally signed documents and securely make payments to anybody.

[1] The CyberCash ™ System – How it works. http://www.cybercash.com/cybercash/cyber2.html.

[2] B.C. Neuman and G. Medvinsky. Requirements for Network Payment: TheNetChecque ™ Perspective. Proceedings of IEEE Compcon ’95, San Francisco, March 1995.

[3] Secure Transaction Technology Specifications (STT), version 1.0, September 26, 1995. http://www.visa.com/visa-stt/index.html.

[4] Secure Electronic Payment Protocol (SEPP), draft version 1.2, November 3, 1995. http://www.mastercard.com/Sepp/sepptoc.htm.

[5] MasterCard & Visa ( http://www.visa.com http://www.mastercard.com ): Secure Electronic Transaction (SET); Specification, Business Description (Book 1), Programmer’s Guide (Book 2), Formal Protocol Definition (Book 3), June 1, 1997.

[6] W. Mao, On Two Proposals for On-Line Bankcard Payments using Open Networks: Problems and Solutions, 1996 IEEE.

[7] M. Sirbu, Credits and Debits on the Internet, IEEE Spectrum Feb. 1997, pp. 23-29.

[8] R. Baldwin, C.V. Chang, Locking the e-safe, IEEE Spectrum Feb. 1997, pp. 40-46.

[9] I. Christofis, New Standards Set Stage for Electronic Commerce. EDI Forum Feb. 1997, pp. 81-86.

[10] A. Stockel, Securing Data and Financial Transactions, 1995 Proceedings of Security Technology, pp. 397-401.

[11] D. Stinson, Cryptography, Theory and Practice, copyright 1995 by CRC Press, Inc.

[12] B. Schneier, Applied Cryptography, copyright 1996, publisher John Wiley & Sons Inc.

[13] Certicom Whitepaper, Current Public-Key Cryptographic Systems, April 1997.