1 / 38

David Evans cs.virginia/~evans

Lecture 12: Randomness and Cash.

Télécharger la présentation

David Evans cs.virginia/~evans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lecture 12: Randomness and Cash Cash is a problem. It’s annoying to carry, it spreads germs, and people can steal it from you. Checks and credit cards have reduced the amount of physical cash flowing through society, but the complete elimination of cash is virtually impossible. It’ll never happen; drug dealers and politicians would never stand for it. Checks and credit cards have an audit trail; you can’t hide to whom you gave money. Bruce Schneier, Applied Cryptography David Evans http://www.cs.virginia.edu/~evans CS551: Security and Privacy University of Virginia Computer Science

  2. Menu • Randomness • Money University of Virginia CS 551

  3. Random Numbers • For numbers in range 0...2n-1, an observer with the first m - 1 numbers, cannot guess the mth with probability better than 1/2n. University of Virginia CS 551

  4. Good Random Numbers • Lava Lamps (http://lavarand.sgi.com) • Gieger Counter and Radioactive stuff University of Virginia CS 551

  5. Pseudo-Random Number Generators • Start in a hard-to-guess state • Run an algorithm that generates an unpredictable sequence from that state University of Virginia CS 551

  6. Bad Random Numbers • srandom (time (NULL)); • for (...) random (); Doesn’t satisfy either property! • random () • Doesn’t give cryptographic random numbers • Using system clock in milliseconds to seed (even a good PRNG) • There are only 24*60*60*1000 = 86.4M • Fine for video games, not fine for protecting nuclear secrets. University of Virginia CS 551

  7. Jefferson Wheel Challenge Key Generator long key[NUMWHEELS]; int i, j; srandom ((unsigned)time (NULL)); for (i = 0; i < NUMWHEELS; i++) key[i] = random (); for (i = 0; i < NUMWHEELS; i++) { long highest = -1; int highindex = -1; for (j = 0; j < NUMWHEELS; j++) { if (key[j] > highest) { highindex = j; highest = key[j]; } } fprintf (stdout, "%d\n", highindex); key[highindex] = -1; } Reduces key space from 36! (3.7 * 1041) to 86M! Challenge is now 2.3 * 1034 easier! University of Virginia CS 551

  8. Yarrow-160 • Accumulate Entropy • Unspecified how: implemented decides • User keystrokes, disk seek times, network activity (be careful!), etc. • Use entropy to and SHA1 hash function produce unpredictable K. • Calculate random numbers: C = (C + 1) mod 2n R = EK (C) • EK is 3DES University of Virginia CS 551

  9. Digital Cash University of Virginia CS 551

  10. Real Cash • Why does it have value? • Nice pictures of Mr. Jefferson (< 1¢) • Because it is hard to print (< 5¢) • Because other people think it does • We trust our government not to print too much • People who forge it get sent to jail University of Virginia CS 551

  11. Counterfeiting • Secret Service siezed $209M in 1994 (of $380B circulated) • Nearly 2/3 of US cash is in foreign countries • Why did US bills change? • Iran and Syria probably print counterfeit US bills • They have a De la rue Giori (Switzerland) printing press, same as used for old US bills • 1992 report, led to currency redesign • Most foreign countries are smarter • Use of color • Obvious, well-known security features • Bigger bills for bigger denominations University of Virginia CS 551

  12. Properties of Physical Cash • Universally recognized as valuable • Easy to transfer • Anonymous • Heavy • Moderately difficult to counterfeit in small quantities • Extremely difficult to get away with counterfeiting large quantities (unless you are Iran or Syria) University of Virginia CS 551

  13. IOU Protocol (Lecture 9) M = “I, Alice, owe Bob $1000.” M EKRA[H(M)] Bob Alice knows KUA {KUA, KRA} M EKRA[H(M)] Bob can verify H(M) by decrypting, but cannot forge M, EKRA[H(M)] pair without knowing KRA. Judge knows KUA University of Virginia CS 551

  14. IOU Protocol • Universally recognized as valuable • Easy to transfer • Anonymous • Heavy • Moderately difficult to counterfeit in small quantities • Extremely difficult to get away with counterfeiting large quantities (unless you are Iran or Syria) University of Virginia CS 551

  15. What is cash really? • IOU from a bank • Instead of generating, “I, Alice, owe Bob $1000”, let’s generate, “I, the Trustworthy Trust Bank, owe the bearer of this note $1000.” • Alice asks the bank for an IOU, and the bank deducts $1000 from her account. University of Virginia CS 551

  16. Bank IOU Protocol • Universally recognized as valuable • Easy to transfer • Anonymous • Heavy • Moderately difficult to counterfeit in small quantities • Extremely difficult to get away with counterfeiting large quantities (unless you are Iran or Syria) University of Virginia CS 551

  17. Counterfeiting Bank IOUs • Assuming the hash and signature are secure • Alice gives Bob bank IOU for $1000 • Bob sends bank 100 copies of bank IOU • The bank has lost $99 000. • Bits are easy to copy! Hard to make something rare... University of Virginia CS 551

  18. Bank Identifiers • Bank adds a unique tag to each IOU it generates • When someone cashes an IOU, bank checks that that IOU has not already been cashed • Can’t tell if it was Alice or Bob who cheated • Alice loses her anonymity – the bank can tell where she spends her money University of Virginia CS 551

  19. Digital Cash, Protocol #1 • Alice prepares 100 money orders for $1000 each. • Puts each one in a different sealed envelope, with a piece of carbon paper. • Gives envelopes to bank. • Bank opens 99 envelopes and checks they contain money order for $1000. • Bank signs the remaining envelope without opening it (signature goes through carbon paper). University of Virginia CS 551

  20. Digital Cash, Protocol #1 cont. • Bank returns envelope to Alice and deducts $1000 from her account. • Alice opens envelope, and spends the money order. • Merchant checks the Bank’s signature. • Merchant deposits money order. • Bank verifies its signature and credits Merchant’s account. University of Virginia CS 551

  21. Digital Cash, Protocol #1 • Is it anonymous? • Can Alice cheat? • Make one of the money orders for $100000, 1% chance of picking right bill, 99% chance bank detects attempted fraud. • Better make the penalty for this high (e.g., jail) • Copy the signed money order and re-spend it. • Can Merchant cheat? • Copy the signed money order and re-deposit it. University of Virginia CS 551

  22. Digital Cash, Protocol #2 • Idea: prevent double-spending by giving each money order a unique ID. • Problem: how do we provide unique IDs without losing anonymity? • Solution: let Alice generate the unique IDs, and keep them secret from bank. University of Virginia CS 551

  23. Digital Cash, Protocol #2 • Alice prepares 100 money orders for $1000 each, adds a long, unique random ID to each note. • Puts each one in a different sealed envelope, with a piece of carbon paper. • Gives envelopes to bank. • Bank opens 99 envelopes and checks they contain money order for $1000. • Bank signs the remaining envelope without opening it. University of Virginia CS 551

  24. Digital Cash, Protocol #2 cont. • Bank returns envelope to Alice and deducts $1000 from her account. • Alice opens envelope, and spends the money order. • Merchant checks the Bank’s signature. • Merchant deposits money order. • Bank verifies its signature, checks that the unique random ID has not already been spent, credits Merchant’s account, and records the unique random ID. University of Virginia CS 551

  25. Digital Cash, Protocol #2 • Is it anonymous? • Can Alice cheat? • Can Merchant cheat? • Can bank catch cheaters? University of Virginia CS 551

  26. Mimicking Carbon Paper • How does bank sign the envelope without knowing what it contains? • Normal signatures Alice sends bank M Bank sends Alice, SM = EKRBank (M) Alice shows SM to Bob who decrypts with banks public key. University of Virginia CS 551

  27. Blind Signatures • Alice picks random k between 1 and n. • Sends bank t = mke mod n. (e from Bank’s public key). • Bank signs t using private key d. Sends Alice: td = (mkemod n)d mod n = (mke)dmod n  mdkedmod n = (mke)dmod n  mdkedmod n What do we know about kedmod n? University of Virginia CS 551

  28. Blind Signatures • Alice gets td mdkmod n • Alice divides by k to get sm mdk/ k  md mod n. • Hence: bank can sign money orders without opening them! University of Virginia CS 551

  29. Digital Cash Protocol #2 • Instead of envelopes, Alice blinds each money order using a different randomly selected ki. • The bank asks for any 99 of the ki’s. The bank unblinds the messages (by dividing) and checks they are valid. • The bank signs the other money order. • Still haven’t solved the catching cheaters problem! University of Virginia CS 551

  30. Anonymity for Non-Cheaters • Spend a bill once – maintain anonymity • Spend a bill twice – lose anonymity • Have we seen anything like this? University of Virginia CS 551

  31. Digital Cash • Alice prepares n money orders each containing: Amount Uniqueness String: X Identity Strings: I1 = (h(I1L), h(I1R)) ... In = (h(InL), h(InR)) Each In pair reveals Alice’s identity (name, address, etc.). I = IiL IiR. h is a secure, one-way hash function. University of Virginia CS 551

  32. Digital Cash, cont. • Alice blinds (multiplies by random k) all n money orders and sends them to bank. • Bank asks for any n-1 of the random kis and all its corresponding identity strings. • Bank checks money orders. If okay, signs the remaining blinded money order, and deducts amount from Alice’s account. University of Virginia CS 551

  33. Digital Cash, cont. • Alice unblinds the signed note, and spends it with a Merchant. • Merchant asks Alice to randomly reveal either IiL or IiR for each i. (Merchant chooses n-bit selector string.) • Alice sends Merchant corresponding IiL’s or IiR’s. • Merchant uses h to confirm Alice didn’t cheat. University of Virginia CS 551

  34. Digital Cash, cont. • Merchant takes money order and identity string halves to bank. • Bank verifies its signature, and checks uniqueness string. If it has not been previously deposited, bank credits Merchant and records uniqueness string and identity string halves. University of Virginia CS 551

  35. Digital Cash, cont. • If it has been previously deposited, bank looks up previous identity string halves. Finds one where both L and R halves are known, and calculates I. Arrests Alice. • If there are no i’s, where different halves are known, arrest Merchant. University of Virginia CS 551

  36. Digital Cash Protocol • Universally recognized as valuable • Easy to transfer • Anonymous • Heavy • Moderately difficult to counterfeit in small quantities • Extremely difficult to get away with counterfeiting large quantities (unless you are Iran or Syria) University of Virginia CS 551

  37. Digital Cash Summary • Preserves anonymity of non-cheating spenders (assuming large bank and standard denominations) • Doesn’t preserve anonymity of Merchants • Requires a trusted off-line bank • Expensive – lots of computation for one transaction • Other schemes (Millicent, CyberCoin, NetBill, etc.) proposed for smaller transactions University of Virginia CS 551

  38. Charge • PS3 due Wednesday • Project proposal feedback in office hours tomorrow (3-5) • Next class: • Factoring breakthrough • Attacking biometrics • Trust models University of Virginia CS 551

More Related