CNS2009lecture 14 :: e-commerce protocols1 ELEC5616 computer and network security matt barrie [email protected].

CNS2009 lecture 14 :: e-commerce protocols

1

ELEC5616computer and network

securitymatt barrie

[email protected]


2

e-cash is king

• Cash hasn’t really changed in the last thousand years – still mainly used as a substitute for chickens, goats, bread, …– bulky to carry (try bribing a politician with Colombian pesos)– giving change can be a problem (change for $100 anyone?)– cash spreads germs– you can’t easily spend cash on the Internet

• Cash continues to battle advances in counterfeiting– The US $100 “superbill” produced in Lebanon’s Bekaa valley– Iran has produced over US $1B of 1980s-era $100 notes

• Each year the US issues ~$300M worth of $100 notes

• Cash is pseudo-anonymous (governments don’t like it)– Serial numbers, bar codes, “marked bills” (East German secret

police used radioactive isotopes) help traceability


3

credit cards, cheques

• Credit cards and cheques allow a massive invasion of privacy– The government (and your bank, and the ATO, … ) knows all about

your credit card purchases at Kings Cross or in the seedy side of the Internet

• Credit cards are having problems retrofitting to the net– Fraud accounts for ~18% of issuers revenue (all insured)– Note: all liability rests with the merchant– In 2000, 37 million credit card number stolen from Egghead.com

• Credit cards and cheques are easy to counterfeit– Cheques can be replicated on a laser printer– Credit cards are trivial to copy (punching the plastic card is the

hardest bit)


4

the ground is shifting

• Banks are closing branches and turning into websites.

• Mobile phone companies think they can do it better and cheaper than the banks (mPay).

• A variety of different loyalty / payment schemes have appeared which are evolving into a form of money.– PayPal– Flooz / Beenz– McDonald’s trialled a radio proximity paycard (any risks?)

• A variety of other players want to get into the game:– The post office– The utilities companies– The supermarket

• A desire for processing of micropayments (e.g. μcents)


5

problems with e-cash

• The government wants anonymous digital cash even less than they want anonymous communications or strong crypto

• True e-Cash is much more than simply buying goods and services over the the Internet– Doug the Drug Dealer will be able to buy houses and cars with his

narcoprofits

• Many crimes get solved by “following the money” – track their assets and you track their structure– freeze their assets and you freeze their power

• Anonymous e-Cash removes the “stigma” of dealing in dirty money (“hey, you can’t get caught!”)

• It gets worse...


6

the power of anonymous e-cash

Posted to the alt.crypto.fanatical newsgroup in the near future:

We decree that the government’s policy on strong cryptography is a farce and a totalitarian sham. We, the united netrunners hereby decree our fatwa: the president must die. We will pay 1 million CryptoCredits (anonymously) to the person that fulfils this decree.

Since our organisation consists of only a few poor engineering students, we need YOUR donation to help the cause! Please post anonymously your money to this newsgroup (encrypted with the following key…).

Click here to see the status of our fund:

The assassination fund currently has: 1,237 Credits.


7

the power of identifiable e-cash

• No need to file a tax return! – The tax office knows precisely what you’ve spent your money on and can automatically calculate it for you.– Enables a wonderful new world of pay-as-you-go tax (PAYG-tax)?

• Keep shonky politicians in line– Know where that campaign money really came from

• Enables fun new games for all to play– six degrees of separation from “Iran”, “cocaine”, “hookers”?


8

desirable properties of digital cash

• Independence– The security of the digital cash is not dependent on a physical

location. Cash cannot be transferred through computer networks (i.e. be stolen without being spent).

• Privacy (or untraceability)– If lobbyist Alice bribes Congressman Bob, Eve the pesky reporter

doesn’t know anything about Alice’s identity.– Furthermore, Bob can use that money to buy cocaine, and nobody

can trace that money back to Alice. – If Alice tries to pull a swifty and tries to spend the same money

down Kings Cross, she’ll be detected. – If Bob tries to deposit the money in two accounts, he will get

detected.


9

desirable properties of digital cash

• Off-line payment– Vince the vendor can accept payment from Alice without having to

talk to the Bank each time.

• Transferability– The digital cash can be transferred to other users (without an

intermediary)

• Divisibility– The digital cash can be subdivided into smaller, arbitrary pieces

(e.g. change).

• Security– Digital cash cannot be copied or reused.


10

digital cash

Obvious Attacks:• User double spends a coin (replay)• Vendor tries to frame the user by spending a coin

twice

useruservendoruser

bankvendorbankuser

withdrawal protocolspending protocoldeposit protocoltransfer protocol

bank


11

simple digital cash

Cast: Alice, Bob the Bank, Vince the Vendor

Withdrawal:Alice → Bob: Authentication ProtocolAlice → Bob: “give me $1”Bob → Alice: coin = sigB{value | “Alice” | seq-num}

• Bob deducts $1 from Alice’s account. • The sequence number is a unique ID for the coin.

Spending:Alice → Vince: “I want to buy X for $1”Vince → Alice: random nonce r є {0,1}128

Alice → Vince: v-coin = sigA{r, coin}

• Vince verifies the coin and then sends X


12

simple digital cash

Deposit:Vince → Bob: “deposit $1”, v-coin

• Bob stores all v-coins• Bob checks the coin is new (seq-num not in the db)• If the coin is new, it is valid.• If the coin is old, compare the nonce of the coin with

the nonce in the database– if the nonces are the same then Vince is double spending

• Only Alice can sign the v-coin

– if the nonces are different then Alice is double spending• Only Alice can sign the v-coin and hence attach the nonce


13

simple digital cash

Problems:• If Alice double spends, she gets caught after the fact

– Problem with most offline schemes

• The cash is not anonymous since Alice’s ID is the coin.

• Not transferable: Vince can only deposit the coin, not spend it.


14

anonymous cash protocol #1

Protocol:• Alice prepares 100 anonymous money orders for $X• Alice puts one each, and a piece of carbon paper, into

100 different envelopes• Alice sends all the envelopes to the bank• The bank opens 99 envelopes and confirms each money

order is for exactly $X• The bank signs the remaining unopened envelope

– the carbon paper copies the signature to the money order

• The bank sends the unopened money order to Alice• Alice opens the envelope and spends the money order• The merchant checks for the bank’s signature• The merchant takes the money order to the bank which

verifies the money order and gives the merchant $X


15


Discussion:• The bank never sees the money order (it’s anonymous)

• The bank is convinced the money order is valid (the bank verifies its signature)

• The 99 of 100 envelope procedure is known as a cut-and-choose protocol

• The bank is relatively sure that the money order is for $X

• 1% probability in this case Alice can cheat the system– We can increase the security by increasing the number of

envelopes sent (e.g. one million envelopes => 0.0001%)

• The bank makes the penalty for cheating a jail term, so it’s not worth it for Alice to try (resource game)


16


Problems:• Alice can copy the money order and send it twice

– Replay!

• Eve can steal the money order and spend it herself

• The system doesn’t detect cheaters– Alice can get away with relative impunity


17


Protocol:• Alice prepares 100 anonymous money orders for $X

(with each she attaches a unique nonce)• Alice puts one each, and a piece of carbon paper, into

100 different envelopes• Alice sends all the envelopes to the bank• The bank opens 99 envelopes and confirms each money

order is for exactly $X• The bank signs the remaining unopened envelope

– The carbon paper copies the signature to the money order• The bank sends the unopened money order to Alice• Alice opens the envelope and spends the money order• The merchant checks for the banks signature, and

takes the money order to the bank• The bank verifies the signature and that it hasn’t seen

the nonce, before handing over the $X


18

blind signatures

• Remember that blind signatures allow Bob to sign a message from Alice without Bob knowing what the message contains.

Protocol:• Alice turns message m into a “blinded message” m*

• Alice sends m* to Bob• Bob signs it and returns the signature s* to Alice• From s*, Alice can compute Bob’s signature s for m• At the end of the protocol, Bob does not know the

message m or the signature s

• This is the main primitive used for anonymity.


19

blind signatures with RSA

Setup:• Alice wants Bob to sign a hash of a message e.g. h(m) • Bob generates a RSA key: public=(n, e), private=d

Signatures:• Alice picks random r є Z*

n

• Alice computes m* = re h(m) (mod n) [blinding]– this is unconditionally blinding since m’ is randomly distributed over Zn

• Alice → Bob: m*

• Bob → Alice: s* = (m*)d (mod n) [signing]• Alice computes signature s = r-1s* (mod n) [unblinding]

Note: se = (r-1s*)e = (r-1)e ((m*)d)e = r-e((m* ) ed) = r-e(re h(m)) = h(m)


20

simple anonymous offline digital cash

• Chaum, Fiat, Naor (1989)

• The main idea is that Alice’s identity is exposed only if she double spends a coin

• Thus the sequence number must be hidden from the bank during withdrawal

• We use secret splitting to guarantee anonymity but detect cheaters


21


Withdrawal Protocol:• Let I be Alice’s identity and (e, n) be the bank’s public

key

• Alice chooses IL(j), IR

(j) such that I = IL(j) IR

(j) where j=1..100. Let us call the two arrays IL,1 and IR,1

• Alice sets

m1 = [“$X”, seq-num1, h(IL,1), h(IR,1)]

• Alice sets

blind1 = r1e h(m1) (mod n) where r1 is random

• Alice similarly generates blind2 .. blind100 with new sequence numbers, identity arrays and blinding factors

• Alice sends all the blindj’s to the Bank


22


Withdrawal Protocol (cont):• The Bank does a cut and choose on 99/100 of the blinded

messages at random and gets Alice to reveal mi, ri as well as IL[100]i and IR[100]i for all i ≠ k, for some k є [1,100]

• The Bank verifies these 99 messages are formed correctly(hash and re-blind them all to check)

• The Bank signs the remaining blinded message and sends Alice

b-coin = [blindk, sigB(blindk)]

• Alice unblinds the signature and sets coin = [mk, sigB (mk)]

• Alice also keeps track ofIL=IL,k and IR=IR,k


23


Spending Protocol:• Alice → Vince: “buy Y for $X”, coin• Vince verifies Bob’s signature• Vince → Alice: random r є {0,1}100

• Alice → Vince: R = [I1, …. I100] where

Ik = IL(k) if r[k] = 0

Ik = IR(k) if r[k] = 1

• Vince hashes these revealed identity halves and verifies they are correct – without knowing I.

• The purchase is then complete.


24


Deposit Protocol:• Vince → Bob: “deposit”, coin, r, R• Bob verifies the signature on the coin and the hashes

of the identity halves due to R (proves it all came from Alice)

• Bob checks to see if the sequence number is in the database

• If not, the coin is valid and Bob adds it to the database• If it is, let [coin’, r’, R’] be the coin the database

– if r = r’ then the vendor is cheating– if r ≠ r’ then the user has double-spent the coin

• If the user has double spent the coin, then there exists k such that r[k] ≠ r’[k] R[k] R’[k] = I

• Thus the user is identified


25


Discussion:• The protocol doesn’t prevent Alice from cheating, but if

Alice spends the coin twice, she is identified

• Alice could try to sneak a money order past the bank where the identity strings identify someone else, with probability of success = 1 in 100 (1%).

• The penalty for being caught is set to make the risk not worth it.

• The security can be increased by increasing the number of blinded messages.

• The merchant can’t cheat because he can’t deposit the money order twice and he can’t open the identity arrays.

• Alice and Vince can’t collude as they can’t sign the coins.

• Alice’s identity is protected by the blinding protocol.


26


Problem:• Eve can cheat the system.

• Eve can eavesdrop the communications, steal the coin and deposit it quickly before Vince does.

• Bob will accept the coin and (even worse) blame Vince for cheating when he tries to deposit it.

• If Eve steals and spends Alice’s cash before she does, Alice will be identified as the cheater.

• There is no way to prevent these problems; they are an artifact of anonymous digital money.


27

ssl / tls

• The Secure Socket Layer (SSL) was developed to support web based authentication and session encryption (Netscape)– Heavily used in e-Commerce and other web based applications (e.g.

medical records)

• Version 3.1 was developed by the IETF and is called Transport Layer Security (TLS)

• Variable encryption key sizes: – 40-bit (exportable - otherwise known as extremely weak)– Up to 256-bit AES

• The design goals are: – Minimal load on the browser– Minimal load on the server– Algorithm negotiation: new algorithms can automatically be used if

both sides support it


28

ssl

• SSL is a transport layer protocol– layered on TCP

• SSL Session– Association between a client / server– Created by SSL Handshake– May have multiple SSL Connections

• SSL Connection– A transport for a particular service

• SSL Record Protocol Goals– Confidentiality– Integrity

IP

TCP

SSL Record

Handshake Cypher Spec Alert HTTPSSL SSL SSL


29

ssl protocol

SSL Message Encapsulation:

• Fragmentation– 16384 (214) byte blocks

• Compression– Optional, but not often used

• Add MAC– Uses HMAC

• Encrypt– Symmetric Cypher

• Prepend SSL Record Header

SSL Handshake Protocol:• Facilitates mutual

authentication and negotiation of cyphers, MACs and keys to use

Protocol:1. Establish Capabilities2. Server sends Certificate3. Client sends Certificate

(*)4. Setup Connection


30

ssl features

• SSL Supports– Diffie-Hellman key exchanges

• for session keys to allow forward and backward secrecy

– Mutual authentication• Both the client and the server can produce a certificate (RSA/DSS)


31

set

• It is well known that the trouble with using credit cards on the Internet doesn’t come from sniffed traffic, but from hacking merchant web servers and stealing the whole database.

• Microsoft, Netscape, VISA and MasterCard came up with the Secure Electronic Transaction (SET) protocol (1996):– Both customers and merchants have public key certificates, so

customers can sign transactions– Customers sign two messages (with linked signatures)

• Order Information: Contains a description of the goods and the price, sent to the merchant (OI)

• Payment Information: Another which is sent to the bank with the price and the card number but not the description of the goods (PI)

– The back-end systems processing the transaction use legacy systems


32

set

• Alice → Vince: “Alice”, rA, certificate(kA)

• Vince → Alice: “Vince”, seq-num, certificate(kV), certificate(kB)

• Alice → Vince: {OI}kV, {PI}kB, sigA{h(OI), h(PI)}

• Vince performs an authorisation step (may be offline):

• Vince → Bob: {“summary”}kB, {PI}kB

• Bob → Vince: sigB{“authorisation response”}


33

set complexity

0

200

400

600

800

1000

Pages # 63 80 971

SSLv3 TLS SET


34

problems with set

• SET has failed in the marketplace

• The benefits turn out to be less than expected– Merchants were holding onto credit card numbers to use as

indexes in marketing databases and unwilling to delete them.– A “feature” was added to allow a merchant to query a card

number from the bank (thus removing all the added security!). Banks could have issued special “SET” credit card numbers but didn’t.

• Costs were too high (like setting up all the PKIs!)

• Usability issues– Speed / performance– Download multi-megabyte “SET” wallet over dial-up a hassle


35

problems with set

• There is no benefit for consumers– Actually worse off; previously users could refute transactions for

any reason, now they were bound to honour transactions as many countries tried to remove this protection.

• Moral of the story:– Deal with issues as they are in practice, not in theory.

• End Result:– SET is being allowed to die off quietly.


36

public key infrastructures (pki)

• Many eCommerce systems rely on the existence of a PKI which allows certificates to be issued and verified.

• However, there are significant problems with PKIs that are often overlooked:

• Costly and complex to design and set up

• Extremely difficult to manage

• Political problems– Do we trust the CA organisation? How much?– How do we license these organisations?– Are there backdoors for law enforcement?

• Competitive issues– New CAs have stumbling blocks in that they need to get their root

certificate into the browser (that is to say : Microsoft Internet Explorer)


37


• Administrative problems– CAs issue certificates binding company names to domain names

(though they have no authority over either!).– Certificate revocation is a problem as one wants certificates to be

usable offline:• Expiration Dates• “Bad certificate” lists (called CRLs)

• Implementation Problems– The DNS name of the shop you wanted to use might differ from

that on the certificate because they outsource their web hosting or credit card clearing facility

– Most sites are configured to use 40-bit crypto because “it’s easier to configure”, meaning it’s the default selection.


38


• Consumer rights issues– In paper systems, the liability in the event of fraud is with those

that accept the signature (i.e. the merchant)– In removing this risk the consumer is still protected whether they

bother to look at the certificates or not– No convenient way for consumers to record their transactions to

show they exercised due diligence

• User problems– They disable certificate checking in their browser.– Extremely costly for a business to additionally run “tech support”

to get them not to.– Browser failures usually allow user (single-click) override


39

moral of the story

“Given the choice between dancing pigs and security,users will pick dancing pigs every time” -- Ed Felten (Princeton)


40

references

• Handbook of Applied Cryptography– Read §11.8.1

• Stallings– Read §14

CNS2009lecture 14 :: e-commerce protocols1 ELEC5616 computer and network security matt barrie [email protected].

Documents

internet cash

notes cash

king cash

ecommerce protocols2

power anonymous ecash

power of anonymous ecash

anonymous digital cash

cheques credit cards