CIS 551 / TCOM 401
Computer and Network Security
April 18th, 2006 - Class Notes
by
Mujde AKBULUT
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
--MicroPayments
--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.
MICROPAYMENT PROTOCOL
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
Analogy:
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.
Example:
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.
Trick:
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:
- 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
- A commits to
the solution to Q
- A reveals Q
to B
- 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)
- A does what B
asks
Repeat this n
times