CIS 551 / TCOM 401

Computer and Network Security
April 18th, 2006 - Class Notes
E-commerce & Protocols
How to carry out electronic transaction?
*Buy a book at amazon, use credit card number
There are some advanced related protocols, different models of safe payment such as
--Digital cash
Digital cash proposals rely on fundamental building block protocols which are:
--Oblivious Transfer
--Class of protocols called Zero-Knowledge proofs
Zero-Knowledge proof is that "A proves to B that A knows some secret without revealing any information about that secret to B"
Electronic commerce example:
Amazon uses some secure protocol to get your credit card information from you. Then carries out some secure protocol with the company that provides your credit card and charge your account.
However, in physical world, physical signature is required (still in many restaurants, no more in gas stations) Restaurants accept VISA, they pay some fixed cost to VISA annually and also pay a charge per merchant transaction.
E-commerce uses some standardized protocols for validating card transaction. You give your card number, contact information, they make use of cryptography.
Disadvantages of  e-commerce:
1. Earlier the idea was people would be paying for very small interactions on web, per click, per file download, etc. However, the transaction charge exceeded the cost of these actions. For example the customer can pay only 10cents for downloading a file whereas the cost of this transaction for the service provider (merchant)  is 25 cents. Because of this overhead, this micropayment approach didn't catch up.
2. Digital cash is not anonymous whereas paper money can be exchanged with anyone. Physical cash is much more flexible.
Can electronic cash be implemented with the properties of physical cash? Are there any problems?
1. It is difficult to replicate physical cash. The anti-forgery technology in physical cash prevents it from being copied. However, electronic cash which is in bits, is very easy to copy.
2. Physical cash is anonymous, untraceable. However, when carrying out a protocol, you cannot lie about your IP since you have to be a legitimate participant.
Third Parties:
PayPal is a wrapper for credit card transaction. It is not anoymous but traceable since it has a history
You have to be paypal merchant to get the money.
Nowadays, subscription model is dominant over micropayment (charge people 10$ a month, etc)
SET Protocol
Secure electronic transaction protocol but is not used very often.
Standardization did not happen since each company like Amazon, keeps their own database of credit card information.
Credit card providers stopped requiring physical signatures to make profit.
What is a "micropayment"?
It is a payment small enough that processing it is relatively costly.
(processing one credit-card payment costs about 25cents)
Processing cost is the key issue for micropayment schemes.
The need for small payments
--"Pay-per-click" purchases on Web: Streaming music and video, Information services
-- Mobile commerce ($20B by 2005): Geographically based info services, Gaming, Small "real world" purchases
-- Infrastructure accounting: Paying for bandwidth
Generic Payment Framework
Consumer = Alice
Merchant = Bob
Consumer PSP = PNC
Merchant PSP = VISA
Alice wants to buy a CD and has an account in PNC. First, PNC verifies Alice didn't exceed limit/ has money in her account. Then Alice pays to Bob when she purchases CD. Bob's PSP (VISA) deposits money after the reconciliation between PNC nad VISA
Aggregation : To reduce cost, micropayments must be aggregated into fewer macropayments.
Micropayments have to be aggregated somewhere
Possible levels of aggregation:
-- None: Every payment deposited with PSP
-- Merchant-level: A consumer's payments are aggregated by merchant
Merchant can have per consumer aggregation. Merchant keeps a tab on how much consumer bought and whenever consumer exceeds some threshold, merchant will carry out the protocol.
Alice puts down 20$ and can go and do transaction while she has debit.
-- MicroPSP: Monopoly service that disintermediates existing payment services; doesn't scale well
Trusted 3rd Party aggregates transaction (Such as Paypal), it requires some minimum transaction cost.
Alice pays small amount of money to Bob's Tunes
Bob interacts with PayPal and says "debit Alice's account for this amount"
-- Universal: Payments aggregated across all users and merchants, even those supported by different
cooperating PSPs
It dramatically reduces processing cost, independent of spending patterns and aggregates payments from many consumers, many merchants, many PSP's in any combination. There is no need to aggregate sales per consumer.
Universal Aggregation Idea
When the merchant is offered to pay twenty 50 cent payments or $0 for 19 payments and $10 for one, there is no difference to merchant, on average. However if the processing costs are taken into consideration and suppose one payment involves 20 cents processing cost, then merchant can make 30 cents profit per payment or 49 cents profit per payment. In this case, a merchant would prefer the latter.
Ron Rivest's idea: Electonic lottery tickets as micropayments (Peppercoin)
Payments are probabilistic.
Aim is to provide global aggregation across all user/merchant pairs.
Everyone exchanges lottery tickets and they don't have to come from the same customer. Merchant doesn't have to keep tab for the customer. One customer can give lt to another customer so there can be agrregation across customers.
How lottery tickets work?
Merchant gives user hash value y = h(x). User writes Merchant check: This check is worth $10 if three low-order digits of h-1(y) are "some digits that user picked." (Signed by user, with certificate from PSP.)
Merchant "wins" $10 with probability 1/1000. Expected value of payment is 1 cent.
Merchant's proof to the bank that they won the lottery:
Here is the X, the cryptographic hash function, digitially signed certificate the customer gave me.
Bank (PSP) sees only 1 out of every 1000 payments, because of aggregation across thousands of tickets before finding the ticket.
Suppose Alice already spent $8.50 among lots of different merchants paying with Peppercoin scheme and now she wants to make 50cents purchase. They play this lottery game. She signs the ticket "This is worth $10 if the last three digits are OK". Chance is 19/ 20 that they won the lottery. Bob logs all the transactions. Later Alice comes again after spending $11 somewhere and at this point the lottery ticket she gave to Bob wins. Bob proves the bank that he won the $10 lottery and they know because of the digital signature that Alice used who Alice's PSP is so they can ask that PSP for payment.
If we have been logging everything in the right way and also assuming that the signatures also keep around the current amount that one spent then the bank can send the current exact total that one has spent across all merchants visited. Likewise, the bill Alice will get will be the current total amount.
So there is no risk at customer side but there is some amount of risk on merchant's side.
This is scalable because you basically made 20 transactions for the present one and can scale it as long as you do it probabilistically.
More standard digital Cash Protocol
Sub protocol: Zero-Knowledge proof
Zero-Knowledge proof is that "A proves to B that A knows some secret without revealing any information about that secret to B"
Is is not useful directly in pratice but can be used to build up complicated protocols.
Trick: change the statement
"A can prove to B with high probability that A knows some secret without revealing B what the secret is"
Imagine the secret A was trying to keep is some key. And that key unlocks the door.
(Physical analogy, there is a door at the bottom of the tunnel and it is locked, A has the key to this door)
_____________________      ______________
|                                   ___|     |                           |
|                                   |     ___|                           |
|                       ______| B |__________              |
|                       |                       ------>   |             |
|                       |           _________        |             |
|                       |     |     |                 |        |             |      
|                       |     |     |                 |        |             |
|                       |    V    |                 |        |             |
|                       |           |________ |        |             |
|                       |              A  | | |              |             |
|                       |_________ | | |_______|             |
|                                                                           |
|_____________________________________ |
A asks B which way  should I go?
B is at the entrance of the tunnel.
B chooses left. Awill come out the other way (after a cycle, goes to left and comes up from right)
B doesn't see how A opens the door.
A is on one side of the door (right or left) and B is again at the etrance of tunnel and it doesn't know on which side A is initially. B says left or right. A may use the key to the door if it is on the same side of the door as B said or it may not use the key since it is already on the other side. (1/2 chance)
Repeat this protocol n times with the same key, then B is convinced. (0.5 to the power n probability that A cheats)
Solving hard problems:
  1. A uses some secret S to transform a hard problem P into another hard problem Q (isomorphic problems in the sense that they are the same problem but you can't tell, for example graph isomorphism, not known to be in polynomial time) A solves Q
  2. A commits to the solution to Q
  3. A reveals Q to B
  4. B asks A to either show that P is isomorphic to Q (can only do if A has the secret S) or open the commitment to Q (show that she is able to solve Q)
  5. A does what B asks
Repeat this n times