ELEC5616 computer and network security

ELEC5616computer and network security matt barrie mattb@ee.usyd.edu.au lecture 14 :: e-commerce protocols

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 lecture 14 :: e-commerce protocols

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) lecture 14 :: e-commerce protocols

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) lecture 14 :: e-commerce protocols

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... lecture 14 :: e-commerce protocols

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. lecture 14 :: e-commerce protocols

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”? lecture 14 :: e-commerce protocols

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. lecture 14 :: e-commerce protocols

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. lecture 14 :: e-commerce protocols

digital cash Obvious Attacks: • User double spends a coin (replay) • Vendor tries to frame the user by spending a coin twice user user vendor user withdrawal protocol spending protocol deposit protocol transfer protocol bank vendor bank user bank lecture 14 :: e-commerce protocols

simple digital cash Cast: Alice, Bob the Bank, Vince the Vendor Withdrawal: Alice → Bob: Authentication Protocol Alice → 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 lecture 14 :: e-commerce protocols

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 lecture 14 :: e-commerce protocols

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. lecture 14 :: e-commerce protocols

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 lecture 14 :: e-commerce protocols

anonymous cash protocol #1 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) lecture 14 :: e-commerce protocols

anonymous cash protocol #1 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 lecture 14 :: e-commerce protocols

anonymous cash protocol #2 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 lecture 14 :: e-commerce protocols

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. lecture 14 :: e-commerce protocols

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) lecture 14 :: e-commerce protocols

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 lecture 14 :: e-commerce protocols

simple anonymous offline digital cash 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 lecture 14 :: e-commerce protocols

simple anonymous offline digital cash 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 of IL=IL,k and IR=IR,k lecture 14 :: e-commerce protocols

simple anonymous offline digital cash 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. lecture 14 :: e-commerce protocols

simple anonymous offline digital cash 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 lecture 14 :: e-commerce protocols

simple anonymous offline digital cash 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. lecture 14 :: e-commerce protocols

simple anonymous offline digital cash 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. lecture 14 :: e-commerce protocols

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 lecture 14 :: e-commerce protocols

ssl SSL SSL 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 Handshake Cypher Spec Alert HTTP SSL Record TCP IP lecture 14 :: e-commerce protocols

ssl protocol SSL Handshake Protocol: • Facilitates mutual authentication and negotiation of cyphers, MACs and keys to use Protocol: • Establish Capabilities • Server sends Certificate • Client sends Certificate (*) • Setup Connection 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 lecture 14 :: e-commerce protocols

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) lecture 14 :: e-commerce protocols

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 lecture 14 :: e-commerce protocols

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”} lecture 14 :: e-commerce protocols

set complexity lecture 14 :: e-commerce protocols

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 lecture 14 :: e-commerce protocols

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. lecture 14 :: e-commerce protocols

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) lecture 14 :: e-commerce protocols

public key infrastructures (pki) • 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. lecture 14 :: e-commerce protocols

public key infrastructures (pki) • 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 lecture 14 :: e-commerce protocols

moral of the story “Given the choice between dancing pigs and security,users will pick dancing pigs every time” -- Ed Felten (Princeton) lecture 14 :: e-commerce protocols

references • Handbook of Applied Cryptography • Read §11.8.1 • Stallings • Read §14 lecture 14 :: e-commerce protocols

ELEC5616 computer and network security