We are going to talk about electronic commerce, in particular electronic payment protocols and their properties.
There is a great deal of interest in the security community now about electronic commerce. Security has not always been an exciting topic; up through the early 90s, security was a topic of secondary priority. The science community was going to get to the security problems as soon as they had solved these other problems.
The reason it was not a problem was because, by and large, most applications that were out there could live with fairly reduced levels of security. The result has been that until the advent of the WWW and the explosion in the Internet, most people were only worried about virus protection. When the WWW and Internet spread, interest grew in computer security for ordinary commercial uses and also in electronic commerce.
It has been predicted that by the year 2005, one-fifth of all retail commerce will be in electronic form. As a result of this and other similar predictions, lots of efforts have been started up in electronic commerce and electronic payment methods.
These efforts include
Why are we so interested in electronic commerce. What are the values electronic commerce offers? Let us divide these questions into two parts: What does electronic commerce do for the world and what does electronic commerce do for us as computer scientist?
Electronic commerce will enable people to put material on the Net that currently is not there. There are a lot of things on the web, but by no means has it replaced libraries (for example) as a source of information. In part this is because current information on the net is often worth what you pay for it.
It is cheaper because you can eliminate the cost of human involvement. You can, e.g., put electronic catalogue information and order handling on the Net, and you can dynamically update the information so you know instantly if something is in stock or out of stock, both for your and your customers' benefit.
There is a strong trend towards this model of ordering. For example, in the US today half of all long-distance calls made are 800-numbers and a tremendous fraction of those are people calling merchants requesting information, making orders or checking the status of their orders.
Electronic commerce is important to us as computer scientists, since it gives us the opportunity to take research that has been rather theoretical and apply it in real life. For example, let us talk about the analysis of security protocols. There has been work done in this area for a long time, but because people did not use security protocols this work was primarily academic. For example, when a flaw was discovered in the Needham-Schroeder public-key cryptosystem, it did not cause much excitement although banks across the country had to shut down to repair their protocols. From a practical point of view it was a interesting discovery but did not draw much attention from the commercial world. If we actually use electronic commerce protocols these sorts of issues will become more important.
Authentication is somewhat of a dead duck in these matters. People are probably going to use a limited number of authentication protocols in the future. These protocols will have been beaten to death and there will not be much concern for authentication. There is, however, reason to have great concern for electronic commerce protocols which are much more immature and where there is much more opportunity for problems.
There are some issues that are important for electronic commerce protocols and electronic payment protocols.
One is the issue of atomicity:
There is also an issue of privacy: Basically, you do not have much privacy in electronic transactions in the US. You are required to do extensive recording on transactions, in particular electronic transactions. For example, any transaction over $100 must be recorded and made available to government agencies on demand. Transactions over $10,000 must be reported.
In addition there are security issues separate from the issue of electronic transfers. We may want to keep the content private, and we would want all operations to be non-repudiable.
There is an important engineering question on the size of a transaction. An average VISA transaction is $70. VISA makes money by charging the merchant a fee for processing the transaction, normally $0.50 plus 2% of the purchase. VISA breaks down this fee in a certain way to pay a tremendous amount of their overhead cost. The only things that are per transactions costs are incoming interchange and perhaps fraud.
So, there is a fairly heavy fee charged. If a great amount of electronic commerce in the future will take place in the form of microtransactions, clearly something is broken here in terms of supporting these transactions if the fees are going to stay that high.
It is an open question what the appropriate level of microtransaction should be. Some people believe we should be able to support extremely low valued transactions. A point in case is the Millicent (Mark Manasse et. al. at DEC SRC) protocol. Other people claim that these small-valued transactions do not matter anyway and you should be looking at subscriptions instead. The actual truth might be somewhere in the middle. There is obviously some level of transaction that is best supported by advertising revenue, by paying fraction of a cent for webpages. Clearly high level transactions will be handled in a different manner, but there is a range of microtransactions perhaps between $0.05 and $10.
First attempt at an electronic protocol:
By taking advantage of what
people have today, credit cards, we can design the following protocol:
The consumer sends the credit card number to the merchant, and the
merchant sends the credit card number to his bank for processing.
credit card #
Merchant <----------------- Consumer
\
\
\
\
\
\
\-> Bank
The first problem with this approach is that we are sending our credit card numbers in the clear over the network. Credit card numbers are all of a similar format and can be easily detected in a bitstream.
The next step would be to use SHTTP/SSL and establish a secure encrypted channel between the consumer and the merchant.
_________________
| credit card # |
Merchant <--+-----------------+-- Consumer
\ |_________________|
\ shttp
\
\
\
\
\-> Bank
That is not sufficient either, because the result of this protocol is that the merchant gets your credit card number, and the merchant can be dishonest too. Actually, merchant fraud is estimated to be larger than consumer fraud.
So people have come up with mechanisms like SET, a result of two completely different protocols by VISA and MasterCard.
Merchant ---\
|| <-\ \
------------------------------
|| \ \ |
|| \ \ Internet
|| \ \ |
--------------------------------
|| \ \-> Credit Card
Consumer \--- Acquirer
note: encrypted tunnel through the Internet
The consumer sends the merchant a order information, but the credit card portion of this order is encrypted so only the bank that processes the transaction can read the credit card number. While the bank might also commit fraud, there are a lot fewer banks than there are merchants, and banks tend to be more heavily regulated.
However, the SET specifications are hundred of pages long and extremely complicated. The chances of the SET protocol not having serious flaws in it are virtually zero.
There are also some problems with its design. We have just mentioned how giving the merchant your credit card number is a potential problem. It turns out that a lot of merchants organise their databases sorting on the key of the credit card number and they have complained that they need this credit card number. As a result SET provides a mode whereby the merchant gets the credit card number back from the acquiring bank!
Another flaw in SET is that it uses the expensive credit card transactions and cannot currently support microtransactions adequately.
Using credit cards is like notational money, an account balance that is kept at the bank server, like a checking account. We also have a notion of token money, e.g. postage stamps or dollar bills. The question is whether we can realise electronic payment using this type of money. One such idea is DigiCash.
/-> Merchant
/ /- ^
5 / / |
/ /4 |
/ / |
/ / |
Bank<-/ |3
\ <-\ |
2\ \1 |
\ \ |
\ \ |
\ \--Consumer
\------>
There are a number of problems with this protocol: There is no atomicity, anonymity is restricted in the US, and detecting double spending is expensive.
Also, if the transaction is interrupted, you have an ambiguous state. If the merchant really got the message you can not go on and spend that same money again. But if the consumer wants to spend the money and the merchant did not get the message, the consumer should be able to do so. He could try to turn the money back into the bank directly, but then he also risks being accused of double spending.