Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Electronic Cash and User Authentication using the Dallas Semiconductor / Maxim DS1963S Monetary iButton.

Similar presentations


Presentation on theme: "1 Electronic Cash and User Authentication using the Dallas Semiconductor / Maxim DS1963S Monetary iButton."— Presentation transcript:

1 1 Electronic Cash and User Authentication using the Dallas Semiconductor / Maxim DS1963S Monetary iButton

2 2 e-Cash - Electronic Money The DS1963S eCash iButton

3 3 An Apology This presentation was intended for interested lay-persons. Apologies in advance for its extreme simplicity. It was also intended to make sense without the accompanying lecturer, to please excuse the detail (and length) of the presentation.

4 4 What We Will Discuss How money and credit are handled now Why e-Cash is better The Evolution of a Secure eCash iButton The DS1963S Monetary iButton (MiB) Why Security is Important How the DS1963S features provide security

5 5 Well Also Touch On... iButtons in General iButton Physical Security Issues Various kinds of Cryptography Attacks against e-Cash Schemes Various e-Cash Applications

6 6 Be Sure You Understand! These slides indicate places where you should make sure that you are keeping up If you missed something, SPEAK UP! These slides will remind you

7 7 What is Cash Money ? A representation of value Recognized and validated by look, feel, familiarity Value is represented physically (ink on paper) Can be stolen by anyone with a physical advantage

8 8 Whats Good About Cash? Anonymous - The seller doesnt care who you are Difficult to counterfeit (paper, printing methods, lots of new tricks) Backed by the government Trusted by everyone (Were all used to it…) A visible representation of funds (you can see what youve got)

9 9 Whats New About Your Cash Color Shifting Ink Watermark Fine Line Printing Micro-printing Security Thread Portrait Serial Numbers

10 10 Whats Bad About Cash? Must be handled/observed by human eyesight or costly photo-scanner Fixed denominations - requires making change Not suitable for use on the Internet Bills consume space, must be physically secured No audit trail

11 11 Whats REALLY Bad About Cash? Carrier is in physical danger of being robbed of cash Stolen cash may be freely used Paper bills spread germs and disease

12 12 A Warning! It is highly likely that an epidemic of global proportions - a serious threat to all human life - will be spread around the world quickly and efficiently on paper currency. - From a joint statement by the World Health Organization and the United States Centers for Disease Control in 1994.

13 13 What is a Credit Card? A representation of your responsibility Really just an ID card Backed by you - the individual Recognized and validated by look, feel, familiarity

14 14 Whats Good About Credit Cards? Somewhat difficult to duplicate (embossed plastic, magnetic stripe data, holograms) No denomination - No need to make change Audit trail is owned by the card issuer and the user Slightly more easily used over the Internet (only because number can be used w/o plastic card)

15 15 Whats Bad About Credit Cards? Not anonymous. Depends on knowing exactly who you are Data stored magnetically, costly mechanical reader Audit trail owned by the card issuer and who else? No easy visual representation of funds

16 16 Whats REALLY Bad about Credit Cards Account number alone can be used if it is stolen or discovered (card is not required) No PIN or Password required in most cases, allows anyone with the number to use it Every vendor must be connected to the central server (via phone or network) Vendor-end equipment is costly

17 17 Why eCash is Like Cash? A representation of value Anonymous - The seller doesnt care who you are i

18 18 Why is eCash like a Credit Card? No denomination - No need to make change Information is electronic, access is simple and fast Audit trail is optional and personal i

19 19 Why is eCash Better than Cash or Credit Cards? Perfectly suited for computers, the Internet Validated using advanced cryptography (much more secure) Almost impossible to counterfeit Carrier is not in physical danger of robbery Its easier to obtain a visual, private representation of your funds

20 20 Why Not e-Credit Cards? Credit Cards require database lookups –Database lookups take time –Database currency is a problem All vendors must have a telephone or network connection to access database Not all recipients are connected or even connectable to the bank Vending equipment is too expensive

21 21 The Dallas Semiconductor iButton as an Electronic Token for e-Cash Applications

22 22 What is an iButton? Portable memory that doesnt forget Electronic circuits that can control or limit data access It can keep secrets Physically secure circuit assembly Physically secure steel container RAM ROM ID CONTROLCONTROL Battery

23 23 Non-Volatile Memory Random Access Memory (RAM) Data is sustained by internal battery Special mechanisms to assure good data despite intermittent connections Memory organization using TMEX allows easy, efficient sharing of the memory area between users

24 24 Very Simple Connection Communicates 2-ways using one signal line Much simpler than radio, magnetic, or infra-red communications Very simple and inexpensive connection to electronic systems A variety of ways to get into computers (serial ports, parallel ports, USB ports, etc..)

25 25 Just a Touch... Communicating with an iButton requires a simple touch of the iButton to a reader Positive action by the user is required There is no doubt about the intent, no accidental communications take place

26 26 The Most Important Feature A unique Serial Number, sometimes called a ROM ID A permanent identifier that cannot be re- programmed No two iButtons EVER have the same serial number RAM ROM ID CONTROLCONTROL Battery

27 27 An iButton Serial Number D6 0C Family Code Unique Serial Number Error Check Code Shown in Hexadecimal notation

28 28 Facts about iButton Serial Numbers Written by a laser when iButton is manufactured Every iButton is unique. No two iButtons will ever have the same serial number The biggest iButton serial number possible is 281,474,977,000,000 iButtons in each family There can be 256 families, for a total of 18,010,000,000,000,000 iButtons in all! We will NEVER run out of numbers

29 29 iButtons with Special Functions Temperature Sensors Time/Temperature Histograms Time clocks (DS1994) Password-protected memories (DS1991) Analog-to-Digital Converters

30 30 Be Sure You Understand! Do you know all about iButtons and their basic features? Do you know how iButtons are carried and used in day to day applications? Understand the Unique Serial Number?

31 31 Evolving eCash... We will walk through the evolution of an eCash iButton, starting at the simplest form, examining ways that it could be attacked, and then adding methods to protect against attacks, until we achieve a sound eCash solution.

32 32 How We Can Put Money Into an iButton Money is just a number (call it your balance) The bank takes cash, writes money amount into your iButton memory Seller reads the balance, subtracts the amount of the sale, writes the new balance back into the iButton $ i

33 33 Think of it as Money The iButton contains a balance stored in the RAM by a monetary authority (like a bank) The balance represents your money remaining; the funds that are left in your iButton account

34 34 Is Money Stored in RAM Safe? NO!

35 35 Lets Make Ourselves Rich! Its EASY to change the numbers in RAM Well just raise the balance amount to whatever we want Instant money! Who will know?

36 36 Why is it So Easy to Cheat? Access to the iButton data is very easy (our own data books tell you how) The Bad Guy just writes in a bigger balance Theres no protection against anyone altering the memory contents Theres no easy way to detect that the fraud has been perpetrated

37 37 A Memory iButton Alone is Not Enough for Secure eCash The Evolution of a Better e-Cash iButton

38 38 To Make a Better eCash Token, Well Need Some Help... Special Hardware Features and Functions Special Secure Assembly Methods Strong Cryptographic Techniques Careful Analysis of All Possible Attacks

39 39 Introducing Cryptography From simple substitution ciphers to highly advanced mathematical algorithms Cryptography is a science all its own! It has its own language, symbols, and lingo Message CIPHER Cryptogram PlaintextCiphertext

40 40 Cryptography Lingo Message Plaintext Ciphertext Cryptogram Cipher Algorithm Key Secret Encode, Encrypt Decode, Decrypt Attacker, or Bad Guy

41 41 Message Simple enough: Your message is whatever you have that you wish to protect or hide from all but the intended recipient.

42 42 Plaintext, Ciphertext Plaintext is the message that you wish to send It is clearly read and understood by anyone It is insecure Ciphertext is the encrypted message It makes no sense to anyone when they attempt to read it It is secure because the real contents cannot be read or understood

43 43 Cryptogram A Cryptogram is a Message that has been encrypted, or converted to a form that a person who does not have the secret key cannot understand. An entire Message, converted to Ciphertext, is a Cryptogram.

44 44 Cipher or Algorithm A Cipher is the process by which PlainText is converted into CipherText An Algoriothm is a series of operations that, when performed on the PlainText data, will turn it into Ciphertext. Cipher is a catch-all term for a variety of encryption algorithms

45 45 Key, Secret The ingredient of the Cipher that is known only to the legitimate parties to the message is the Secret or Key. Just as a mechanical key opens a lock, the cipher Key makes the data readable again. The words Key and Secret are sometimes interchangeable, but not always (well see why later on…)

46 46 Encrypt Decrypt Encrypt means to make Plaintext into Ciphertext Decrypt is to make Ciphertext back into Plaintext once again Sometimes Encode and Decode are used to mean the same thing.

47 47 Attacker, Bad Guy The person or organization who wants to break your crypto-system and find out what the secret message contains Perhaps wants to alter the secret message before it gets to its rightful destination Sometimes, its your own courier, or your own customer!

48 48 A Little Bit About Ciphers...

49 49 Single Key Ciphers The old Decoder Ring Both ends of the conversation must know the same secret key Only one or a limited number of recipients Recipient can also encrypt messages using the same secret key Hello Cipher pjighqr Hello Cipher Cipher- text Original message Restored message Key Same Key

50 50 What Does It Tell You? Only that whoever sent the message knows the secret key, because, If they didnt know the secret, they could not have made a valid encrypted message. If more than one other person knows the secret, you can never be sure who sent you any given message.

51 51 Whole-Message Authentication The entire message is encrypted No outsider can alter the message Could be a legal problem because the content is hidden from the authorities Can be very slow if the message is large

52 52 Another kind of Cryptographic Function - Hashing A way to reduce information to a smaller digested representation Much faster than encryption/decryption Does not need to be reversible Any amount of input data makes the same size Digest (output) Now is the time for all good men to come to the aid of their party. 187B6EF54B079A5C DIGEST MESSAGE HASH FUNCTION

53 53 Hashing is Used to Make Sure that Data is Un-Changed Run all the data through the hash function Send the resulting Hash along with the data The recipient can regenerate the Hash and compare it to the one that was sent to check the data for accuracy This makes transfer of data ultra-reliable

54 54 An Example of a Simple Hash - A Check Digit System Some companies include Check Digits in their numbering systems Heres how Check Digits work: –Take a part number or account number –Generate a simple hash of it (well use SUM) –Take all or some portion of the result –Embed it in the number - Make it a part of the number –Alteration is detected using the hash (check digit)

55 55 A Simple Hash - Check Digits A typical Part or Account Number: Sum of the Digits = = 45 Take just the right-most digit = 5 Embed the check digit in the part number: Make an error in entering the part number: System re-computes check digit: = 46 The error is obvious: 6 = 5 ??? The Check Digit has caught a keying error before it could become a serious problem.

56 56 Be Sure You Understand! Do you understand the concepts of Hashing? Do you understand WHY a Hash can tell us if the data in a message has been changed? This is an important concept - ASK NOW!

57 57 Larger Scale Hashing Algorithms Can handle very large amounts of input data Characteristics that make it more secure –Large output size –Lots of diffusion –Lots of reduction Now is the time for all good men to come to the aid of their party. 187B6EF54B079A5C DIGEST MESSAGE HASH FUNCTION

58 58 What Makes a Good Hashing Algorithm? Impossible to figure out any part of the input from the output digest Very unlikely to create a collision - the same digest made from different input data Time-tested, peer-reviewed, and very well scrutinized around the world Approved and specd by the government

59 59 Secure Hash Algorithm (SHA-1) What is it? How does it work? Why do we use it? It uses several methods to be secure: –Diffusing - Each change in an input bit affects many bits of the output –Reducing - Much about the input is lost in the course of the computation, keeping the process irreversible –Obscuring - More than one input bit can cause changes in the same output bit

60 60 Secure Hash Algorithm Repeat this process 80 times! 160 bits

61 61 A Good Example of Peer Review in Action SHA-1 has MANY predecessors The Evolution of SHA-1: –MD-2 One method, but a little slow, so... –MD-4 Weakness was discovered, so... –MD-5 Never broken, but suspect, so... –SHA Better than any before, but…. –SHA-1 The most trusted of them all!

62 62 Hashing Secures A Monetary Balance against Changes A balance is just a very short message Include the balance and the Hash of the balance in the iButton memory If the balance changes, the Hash wont match the balance when checked If the Hash changes, the balance wont match the Hash when checked Any change is detected by the Hash

63 63 Does a Hash Secure Our Balance Against A Bad Guy? A bad guy could just change the balance, and then compute a new hash for it We would never know that money was added The Hash algorithm is only a part of the scheme

64 64 How to Make It Really Secure? Make it impossible for the Bad Guy to be able to compute a new Hash If he changes the balance, it is detectable because the Hash is no longer correct

65 65 How to Prevent the Bad Guy from Making a New Hash Keep the Hash algorithm secret? –Its hard to protect an algorithm that is committed to hardware from getting out –There are only a limited number of good algorithms to use –Cant get good peer-review and global acceptance on an algorithm if it is kept secret Oh No! Security by Obscurity !

66 66 Keeping A Part of the Message a Secret An unlimited number of different secret parts are possible The secret part can be provided by service providers - They dont have to trust the iButton manufacturer to keep their secrets, or even know what the secrets are Algorithm can be made public to allow normal, healthy peer-review

67 67 Now is the time for all good men to come to the aid of their party. 361B73F60A925C DIGEST HASH FUNCTION Mary had a little lamb. Hash A Message Plus a Secret MessageSecret

68 68 Store Message + Hash in iButton, But NOT the secret Now is the time for all good men to come to the aid of their party. 361B73F60A925C Message + Hash stored in iButton Attacker is missing critical information needed to alter the data

69 69 Vendor Checks the Message Now is the time for all good men to come to the aid of their party. 361B73F60A925C Re-Created Hash Function Mary had a little lamb. Vendor knows the Secret Part If Hash in iButton matches, the the data is OK

70 70 A New Crypto-Term: MAC A MAC is a Message Authentication Code It is simply a Hash when a portion of the input is kept secret No one can compute a valid MAC for an altered balance unless they know the secret

71 71 Understand MACs and How They Work Call it a Secret (Its not really a Key) The input data and secret cannot be figured out from the resulting MAC A changed message cannot be augmented to find one that will generate the same MAC A MAC is not encrypted data, it is a digest of the message and the secret

72 72 A Note About Cryptography Most failures of cryptographic systems are failures in their IMPLEMENTATION, and not in the cryptography itself There are many short-cuts that can be made that may greatly weaken the security There are time-tested rules for crypto- systems and their application

73 73 Crypto-System Rules Never depend on Security By Obscurity. Only full disclosure and peer-review can hope to guarantee a secure crypto-system Be sure that random numbers REALLY ARE random. Bad random numbers have been the downfall of many crypto systems. Never short-cut or circumvent the time- tested and approved algorithms.

74 74 Recap - Hashing: What is a Hash? What does a Hash allow us to detect? How would you send a letter so that any changes could be detected? Does all the data involved in the hash have to be sent along?

75 75 How can we prevent a Bad Guy from being able to change the message and then generate a new Hash for it? When a Hash is computed and part of the input data is kept secret, what is the Hash result or digest called?

76 76 Be Sure You Understand! How can a MAC protect data from unauthorized changes? This is an important concept, so ASK NOW!

77 77 Back to the eCash iButton Put money balance in the iButton memory Compute a MAC of the balance and a secret No one can change the balance and also keep the MAC correct without the secret!

78 78 Is Our e-Cash Really Secure? Not Yet!

79 79 Duplicating Money Even if the Bad Guy doesnt know the secret, he can read the balance and valid MAC He could get more iButtons and simply copy the balance and valid MAC into them He can now spend each of them freely - They all have valid e-Cash!

80 80 Its Just Like Copying Currency Make photo-copies of a Dollar bill Spend em! Electronic data is even easier to copy, and the copies are impossible to tell from the original

81 81 How can we Prevent Duplication? What if all copier paper had unchangeable serial numbers embedded in it? Each iButton is unique, because it has a permanent lasered serial number inside We can include the unique iButton serial number in the input to our MAC Now the Bad Guys copies are worthless!

82 82 Be Sure You Understand WHY! Why does including the serial number in the MAC make duplication impossible? This is an important point! ASK NOW!

83 83 Could the Bad Guy Re-Use the Same iButton? The Bad Guy copies the money amount and the valid MAC to a diskette The Bad Guy then spends most or all of the money value in the iButton The Bad Guy writes the original amount and MAC back into the iButton from the diskette Bad Guy spends the SAME money all over again! This is called a Replay Attack

84 84 Make each copy of the monetary value unique, too... To do this, we need some hardware help - Enter the DS1963L Monetary iButton The DS1963L has a counter that counts up once each time a balance is written into the iButton Well include the counter in the MAC input When the attacker writes the valid balance and hash back into the device the counter increments, and so the MAC is no longer valid.

85 85 Counter has Special Properties Counter cannot be reset, backed-up, or re-loaded Counter is BIG, and cannot be wrapped-around –It can count to 4,294,967,296! Special precautions detect any attempt to set the counter back or affect it (Tamper Bits) The counter makes each write to the memory a unique event and gives each instance of the balance a unique ID

86 86 Be Sure You Understand! Why does including the counter in the MAC make replay attacks impossible? ASK NOW!

87 87 Secure iButton e-Cash with the DS1963L!

88 88 Wait Just a Minute! Its Not Really That Easy! A More Advanced Attack

89 89 Faking-Out the Vendor The clever Bad Guy could make special hardware that can pretend to be an iButton Many micro-controllers and other programmable circuitry can be programmed to pretend to be an iButton This is called Emulating an iButton The Bad Guy copies the valid balance and MAC from a real iButton to his emulation of the iButton The Bad Guy uses the emulation iButton as money, sets the counter back each time he restores the original balance (he can do Re-Play attack because he controls the counter)

90 90 How can we make sure that an iButton is a REAL one? A clever person can figure out how to pretend to be an iButton device We need a way to Authenticate the iButton - To make sure its not a fake. ?

91 91 Methods for Authentication How to tell a REAL iButton from an Emulation (a fake iButton)

92 92 Spy-Vs-Spy: Whats the Secret? How do you make sure someone is not an impostor? Ask for something only the real person should know. If they can answer correctly, then they have authenticated themselves Whats the secret?

93 93 What if Someone Overhears the Secret? If someone overheard the secret, they could use it later to make us think they were authentic, too Its not hard to tap into an electronic data conversation and record it for use later on You wouldnt even know that they have discovered the secret

94 94 A Better Way to Authenticate Choose a number at random Ask them to multiply their secret by the random number The secret itself was not ever revealed to be compromised If a Bad Guy overhears the answer, it will be of no use next time because the random number is always different Whats the secret times 452?

95 95 Challenge-and-Response The random number is called a Challenge, and the answer is the Response. No one in between the two can fool us, even if we passed the challenge-and-response down a line of intermediaries. Recording the response is of no use in any subsequent transaction

96 96 Can we Make an iButton that can Prove it is Authentic? We need a special iButton with some new features - Enter the DS1963S It can keep secrets securely hidden inside It can compute SHA-1 MACs inside It can take a Challenge and generate a Response (the MAC of the challenge and a secret) We can test the result to see if the iButton really does know the secret

97 97 Be Sure You Understand! Why does being able to keep a secret and perform Challenge & Response make it possible for an iButton to be authenticated? Why does the Challenge need to be a random number? This is important, so ASK NOW!

98 98 Security Depends on Keeping a Secret from a Bad Guy The Bad Guy can get his hands on as many of these iButtons as he needs, and he can take them where ever he wants to work on them in privacy.

99 99 Protecting the Secret Secret is stored in static RAM It is maintained by a very small Lithium power cell inside the iButton steel container Battery connection would have to be maintained during dis-assembly and probe without any interruption, or the secret would be scrambled and lost.

100 100 A Secure Assembly Method Silicon Chip (Face Down) Printed Circuit Board Solder Bumps Epoxy Underfill Flip-Chip Technique Makes a Circuit Sandwich that would be very difficult to take apart Secrets

101 101 Secure Assembly Silicon hides secrets under metal layers Silicon is flipped and soldered face-down to a circuit board Ultraviolet-light-hardened epoxy is flowed between the silicon chip and the board by capillary action Almost impossible to dismantle or probe

102 102 A Stainless Steel Vault Sealing the entire device in Stainless Steel makes a very durable package thats very difficult to open Lithium Battery Circuit Board Circuit Sandwich Sealed, Stainless Steel Enclosure Integral Power Source

103 103 Is all this data REALLY from the iButton? A Bad Guy could bring a valid iButton to authenticate himself He could then substitute a fake iButton with illegal money value in it for the transaction Can we be sure the monetary data we read from the iButton really came from the same iButton that we have authenticated?

104 104 Can We Trust the iButton Data Communications Path? The data connection is vulnerable, exposed to the Bad Guy to manipulate how ever he wishes Its not too difficult to switch signals around at the right times using smart electronic devices Cola

105 105 Be Sure You Understand! How can a simple Challenge & Response exchange guarantee that the data we read really came from the iButton, and not a Bad Guy injecting false information? ASK NOW!

106 106 Requirements to Perform Secure e-Cash Authenticate the iButton device to make sure its not an Emulation Verify that all of the data has not been in any way corrupted or altered in the communications path Validate the monetary balance and make sure it has not been altered

107 107 Accomplishing iButton Challenge and Response A MAC of all the data and a secret would protect the data from being manipulated, and would prove that the device knows the secret, and is therefore authentic The entire exchange of data to and from the device can be protected from intervention The device must be able to perform world- class hashing functions - and fast!

108 108 A Secure Hashing Algorithm We need a secure, trusted, well-tested hashing algorithm implemented in silicon. SHA-1 has all the features we need, and is one of the easier hashes to implement in hardware logic and registers.

109 109 SHA-1 is No Easy Task SHA-1 done the usual way would take a lot of room, and so the new iButtons be expensive to manufacture (fewer parts can be made from each wafer processed) Instead, we have designed a unique SHA-1 engine that uses a very efficient method to keep the hardware small, and therefore keep the cost down

110 110 A Special SHA-1 Engine Performs the SHA-1 hash in about 500 microseconds ( seconds) Uses very little battery power Occupies very little silicon space Implements an un-compromised FIPS compliant SHA-1 algorithm

111 111 Authenticate not just the iButton, but the Data from it as well Include the challenge, the balance, the serial number and the secret in the MAC input Now the MAC, if it checks, proves that the device knows the secret, and That all the data we got from the device is authentic and accurate, too. Once we know that the data from the iButton is authentic, we can check the MAC on the balance and know that it is valid as well

112 112 Validate Everything! Serial Number Secret Balance MAC Balance Challenge SHA-1 Match? Random Un-trusted Connection between iButton & Reader Secret

113 113 Two MACs for Double Security Two MACs: –One authenticates the iButton and the data, and secures the communications link to the device –One protects the monetary balance against being changed or faked by a Bad Guy The entire transaction can be validated All of the data is checked

114 114 Be Sure You Understand! How can a SHA-1 algorithm provide e-Cash security from attackers? Why is it a benefit to have the SHA-1 engine inside the iButton? ASK NOW!

115 115 Lets Look at a Real-Life Transaction. Buy a Cola! Touch your Monetary iButton at the Cola Vending Machine reader The machine generates a random challenge and sends it to the iButton The machine reads the balance, the unique iButton serial number, and the counter from the iButton The iButton generates a MAC of the balance, serial number, counter and secret

116 116 The machine reads the MAC from the iButton The machine performs the same MAC computation on the same data, and the secret (that it knows) The machine verifies the match between the two MACs to see if the iButton is authentic The machine now knows that the iButton is real (the iButton has proved that it knows the secret) The machine also knows that the data has not been tampered with in the communications path.

117 117 The machine takes the monetary balance, the serial number, and the counter and generates a MAC using the monetary secret (that it knows) If the MAC matches the one from the iButton, the money has been proven to be valid and unaltered The machine subtracts the cost of the cola from the balance and generates a new monetary MAC using the secret that it knows The machine writes the debited amount, with the new valid MAC, back into the iButton

118 118 Think the Machine gives up a Cola now? Not so fast! What if the iButton left the reader before the new debited balance could be written into it? The money has been validated, but hasnt been taken from the customer iButton yet! What if a Bad Guy fooled the machine to make it think that the debit was successful, when in fact the iButton was never really debited - because it left just in time? The Bad Guy could buy Colas forever and never spend a single e-penny !

119 119 We have to do more... The machine generates a new random challenge and reads the device data back again The machine checks the MAC from the device with the one that it generated to be sure that the iButton and the data is authentic and not just a playback of what the machine wrote out before A playback would be the same, but the challenge is new each time and so the response is different Only an iButton that knows the secret can make a proper response

120 120 IF and ONLY IF the balance, serial number, counter and monetary MAC that we read back from the iButton all match what we wrote to it, THEN we know that the entire transaction completed properly, so Give up the cola! (Its about time!) Ya-Hoo!

121 121 They call it Tear? Another crypto-term: Tear - When the media (in this case, the iButton) is taken away before the transaction can be completed and checked At most stages in the transaction, we can abort if the iButton device departs too soon, and no harm is done (no money or product has changed hands) What if all is well right up until we try to check and see if the debit was successful, and we find that the iButton has gone away?

122 122 Accidental, or Intentional? A Good Guy might simply remove the iButton too early by accident We need to handle innocent tear very well to keep customer confidence and comfort Bad Guy could cause precise loss-of-contact Be sure that the result of intentional tear does not produce a profit for a Bad Guy

123 123 The Prisoner Exchange Problem You have something of value Someone who you dont trust has something of value as well Both of you wish to exchange these items... How do you do it? –He might grab them both and run! –He thinks you might do the same!

124 124 Even a Child Knows... Eye your opponent carefully Try your best to look intimidating Get into a position where your opponent does not have an advantage Make the exchange suddenly, and quickly Grab the item you want and dont let go!

125 125 We Handle it the Same Way Make sure the iButton is real and the money contained in it is valid Make the transaction as quickly as possible (to reduce the odds that tear will occur) Dont give up the product until they prove that they gave up the money (by staying long enough to read the iButton back)

126 126 Tolerate the incompetent humans, they know not what they do The philosophy for dealing with tear is very important in e-Cash vending system design What if we simply refuse to give up product? –Let the transaction finish, or NO COLA! The thirsty and frustrated human is very likely to present the iButton again Our machine will just wait for the iButton to return and finish the job when (and if) it does

127 127 Alternative Philosophies Money could be lost if the human walks away and indeed WAS debited, but thats a loss we will have to live with. The alternative would be to vend the product, but that would open the system up to attacks and greater losses (because tear would now become profitable for the Bad Guy)

128 128 Be Sure You Understand! Do you understand what Tear is and why it could be a problem? ASK NOW!

129 129 Thats a LOT of Work It took four hashing operations in the machine: –One to check the data and iButton authenticity –One to check the monetary balance for validity –One to generate a new MAC for the newly debited monetary balance –One to check the data read back when we verified that the debit completed properly

130 130 And it took two hashing operations in the iButton: –One to generate a MAC for the data that the machine read when the iButton arrived, and –One to generate a MAC for the data that the machine read back to check that the debit completed.

131 131 What Else can they Throw at Us? As we have seen, it is very important that the vending machine read the iButton back after the debit to be sure that it took. But, if the iButton appears to have been properly debited, how do we know that the debit was our own?

132 132 This next one is a bit Complicated... The A-B-A Cheat

133 133 A scenario for yet another way of cheating: –Bad Guy attempts to buy a cola from Machine A –Bad Guy removes the iButton before the debit can be read back and checked by the machine –Bad Guy goes to Machine B using the same iButton (which has not been debited) –Bad Guy allows the full transaction to complete at Machine B, and gets a cola. His iButton is debited for the cost of one cola. –So far, so good. B

134 134 –Bad Guy now returns to machine A and touches the same iButton again –Machine A reads the iButton, observes the correctly debited amount, the correct serial number, and the correct counter value and assumes that it (A) had completed the prior transaction after all. It thereby assumes that it owes this customer a cola! –Machine A vends a Cola. A

135 135 –Customer got two Colas for the price of one! –And the cost of one Cola has been added to two different coin boxes! We have duplicated money! –(Banker-types consider it very bad if cola machines create new money on their own)

136 136 Preventing the A-B-A Cheat Each vending machine includes a random number with the balance (well call it a Transaction Code) This Transaction Code number is included in the iButton with the balance, and is a part of the input to the monetary MAC computation as well. When an iButton departs and then returns, the random value is not at all likely to be the same if the iButton was in fact debited by a different machine, or at a different time. The debit in Machine A is found to have not completed, no duplicate product is vended, and no new money is created. The customer got one Cola for one Cola-price.

137 137 But, thats not all. There are MORE problems to think about... What if someone DID get into an iButton and get that precious secret out of it? The same secret is used by all the iButtons in the Service Providers entire system, so All the iButtons that use the same secret would be compromised!

138 138 New Crypto-Term: Class Break When all the devices in a system are broken by breaking a single device. The consequences of a Class Break would be very serious indeed! Making a system-wide key change across millions of deployed iButtons would be almost impossible - and very costly

139 139 How to Prevent a Class Break Reduce the odds or increase the difficulty –Better physical security (expensive and ultimately limited) Catch em in the act of trying to break the device –Booby-traps that wipe the secret when you try to break in and get it (expensive, sometimes they might false alarm and erase legitimate money, also ultimately limited)

140 140 A Different Secret for each iButton? Legitimate vendors would have to know every secret for every iButton that might arrive –There could be millions of secrets! –Requires huge memories, or network connections at each and every vending machine –A database nightmare!

141 141 A Better Way to put a Unique Secret in Each iButton Give each device a secret that is computed from a master secret and the unique device serial number The method should make it impossible to figure out the master secret given the unique device secret We will need a fast way to re-create each devices unique secret when it arrives Sound familiar?

142 142 Use our SHA-1 Hashing Algorithm to Make Unique Secrets Each iButton is given a secret that is the MAC of the master secret combined with its unique serial number. The cola machine reads the device serial number when it arrives and, knowing the master secret, figures out the unique secret for the device. Now were up to seven hash operations per transaction! Serial NumberMaster Secret SHA-1 Unique Device Secret Used to Authenticate Data from iButton Device Secret

143 143 Be Sure You Understand! Do you understand what a Class Break is? Why does having a different key in each iButton prevent a Class break? ASK NOW!

144 144 All those MACs! Wont it take forever just to buy a Cola? Now were doing seven complex MAC operations in each transaction A MAC operation involves thousands of steps and lots of computation

145 145 Time to Perform a MAC? In a typical micro- controller, could be as slow as 1/2 second or more for each MAC That would be 3.5 seconds or more just to do this simple Cola transaction!

146 146 The DS1963S as a Co-Processor Another DS1963S can also be used inside the vending machine as a co-processor iButton SHA in.0005 seconds! It can also keep the critical secrets, and store the collected money safely i i Inside, doing the crypto work at very high speed Outside, serving as personal e-cash Cola

147 147 The Ultimate Co-Processor The Monetary iButton can perform MACs very quickly It has functions that allow it to check MACs from other iButtons without revealing the sensitive secrets It can keep the secrets better than any micro controller It has its own unique serial number It has its own stainless-steel vault It has its own backup power cell It is a safe place to store accumulated funds It has room for configuration and price data It can be easily installed, retrieved or exchanged It is inexpensive

148 148 Be Sure You Understand! Do you understand how the same DS1963S iButton can be both an eCash carrier and a co-processor? ASK NOW!

149 149 What about other Points of Risk? The biggest risk is often the people or systems at the service providers own facilities Employees could profit by stealing the master secrets that they may have access to at work Master secrets must be kept under lock-and-key, and security of that type is expensive and doesnt always work reliably. Cryptography comes to the rescue again with Secret Sharing methods...

150 150 Protecting the Master Secrets Another crypto-term: Secret Sharing Breaks the master secret into several partial secrets Partial secrets may be distributed among VIPs or kept in different vaults (physical or electronic, like CiBs). No single employee needs to ever have access to all the partial secrets. No partial secret is of any use without all of the others. Partial secrets must be brought together only when the master secret is to be re-created

151 151 Shared/Split Secrets Partial Secret Master Secret Partial Secret

152 152 Still at Risk? Even secret sharing schemes cant fully protect the master secret The Master Secret still exists, if even for a moment in a computer, when the partial secrets come together and the master is injected into the iButtons. Unless…..

153 153 Assemble the Partial Secrets inside the iButton Use the Hash mechanism inside the Monetary iButton as a secret sharing tool Re-build the master secret entirely inside the confines and security of the iButton The master secret NEVER exists outside the iButton, and is NEVER exposed to employees or anyone else Partial secrets can be injected at various points along the process, even in different cities or factories The final partial might not be injected until the iButton is given value and handed to the customer. Any iButton taken from the system before that step is useless to an attacker.

154 154 Assemble Partials in the iButton Partial Secret Master Secret SHA-1 We send each partial in to the iButton and build the new master secret one-by-one. The results are never exposed outside the iButton.

155 155 Be Sure You Understand! Do you understand how Secret Sharing is done? Understand WHY? ASK NOW!

156 156 Recap: A Scheme and iButton for Secure e-Cash Provides a secure steel container for eCash Secures a monetary value using a Hash Uses the unique iButton ID to protect monetary value against duplication Uses non-resetable counters to protect monetary value against Re-Play Attacks

157 157 Secure e-Cash, contd... Provides a fast, efficient crypto engine Generates a unique secret for each and every iButton - No Class Break problem Authenticates the iButton using Challenge & Response, and the secret in the iButton Checks all the data from the iButton using a Hash and the secret in the iButton

158 158 Secure e-Cash, contd... iButton can also be a co-processor to keep secrets and to speed up transactions Provides user authentication by challenging the human carrier to prove he knows a secret PIN or password Provides secret-sharing to protect the secrets at the service providers facilities

159 159 Theres One Attack Left... What about the Bad Guy who simply wants to BREAK the system?

160 160 The Sneakiest Attack of Them All The Competitor Attack Most attackers wish to profit from their efforts Competitors may profit by simply breaking the system, causing customers to distrust it The simplest attack is to destroy the device, but that leaves obvious evidence behind Another method is to corrupt the monetary data in the device, but that would also be somewhat obvious The sneakiest attack would be to corrupt the secrets. Since they cannot be read out, no one could be sure if a non-working part had been scrambled or had simply failed.

161 161 A Counter on the Secrets An attempt to make competitor attacks more easily detectable and obvious Like the data pages, each secret also has a counter that goes up one count when the secret is changed This can be used to detect over-written secrets as opposed to hardware or memory failures. The secret counter can be included in the monetary MAC to lock the monetary value even more tightly to the state of the iButton and secret.

162 162 Be Sure You Understand! Do you understand why someone would want to disrupt the system even if they did not profit directly from their attack? ASK NOW!

163 163 The DS1963S eCash iButton Securely stores monetary balances Can be reliably authenticated Can reliably authenticate a user Detects alteration of the monetary balance Detects alteration of the I/O data exchanged Detects alteration of the secrets Physically secure, durable steel container Fast, efficient internal cryptographic engine

164 164 Can the DS1963S iButton only Represent Money? Other data may also be secured –Secure employee information –Secure access rights, door lists, security levels –Secure credit card information –Secure photograph –Secure biometric Data Tamper-Proof Employee/Student ID Bob Jones Employee ID Card

165 165 True User Authentication PINs and Passwords

166 166 User Authentication The Internet needs a way to authenticate users - to make sure they are really who they say they are - before allowing them access to sensitive information Software systems need a secure way to authenticate users Access Control and Door Lock systems need more reliable and secure keys

167 167 Problems Handling PINs and Passwords For an Internet server, handling thousands (or millions) of user PINs or passwords is a huge task The time to authenticate a user includes looking up their PIN or password in the huge database Having many copies of a database of user secrets makes them more easily compromised Sending PINs or passwords over the network raises the risk of their interception

168 168 PIN/Password –vs- Tokens PINs & Passwords are easily compromised You will not always know if your PIN or password has been compromised Tokens (like keys, cards or iButtons) can be stolen and used by someone else You know when the physical token is missing (its not there when you need it)

169 169 A Better Way… Combine the best of Tokens and Passwords Something You Bring (the Token) Something You Know (your Password)

170 170 Something You Bring, Something You Know… The authentic user must bring a unique, physical token and present it, The authentic user must know something that is secret, and prove that he knows it, Only when both the secret and the token are present is the user truly authenticated.

171 171 Bind the User to the Token Include the users PIN or Password as if it is the last partial secret Binds the User to the iButton Token The user must provide the correct PIN or Password before the device can be authenticated

172 172 Other DS1963S Applications

173 173 The Monetary iButton as a Key Access Control, Safes, Lockers, Stand-alone Door Locks all need versatile electronic keys that cannot be duplicated. Because data can also be protected from alteration, access levels, door lists, and employee ID can be stored securely in the iButton as well.

174 174 Accessory Authentication Manufacturers want to be sure that customers use only genuine accessories Secret-keeping and Hashing can allow an appliance to authenticate the accessories that are connected to it, and refuse to work with third-party knock-offs

175 175 DS1963S iButton Capacity Sixteen data pages Eight secrets Eight data page write counters Eight Secret write counters Total 5.12K Bits of battery-backed RAM Data Secret Counter

176 176 Multiple Service Providers As many as seven service providers can share the device Each providers space is independent from the others CitiCorp NationsBank Eat At Joes Etc... DS1963S

177 177 1-Wire File Compatible 1-Wire File directory and file structures may be used throughout 1-Wire File directory pages can be protected, too Allows dynamic RAM memory allocation as providers are added File Directory File Page 0 File Page 1 File Page 2 Other Page...

178 178 DS1963S Cryptographic Security

179 179 The Brute Force Attack Any and every cryptosystem is susceptible to a Brute Force attack The attacker simply tries each and every possible key until one works Time depends on maximum rate that keys can be tried and number of possible keys

180 180 Is a 64-bit Secret Big Enough? On average, finding out the secret would require (2^64)/2 SHA operations, or about 9,223,000,000,000,000,000 computations. A very fast computer can perform a SHA-1 computation in about 1 microsecond. It would take about 2,900 years using 1000 ultra-fast computers to break the secret!

181 181 2,900 years !

182 182 Other Crypto-Attacks? There are no known cryptographic attacks against SHA. - Applied Cryptography, Second Edition, by Bruce Schneier 1996

183 183 iButton Data Security-Vs-Cost More Security Higher Cost DS1991 Password- Protected Memory DS1963L Monetary iButton DS1955/DS1957 DS199X Memory iButtons DS1963S Next-Generation Monetary iButton Java-powered Cryptographic iButton $$$$ Very Secure, Low Cost Ultra Secure, High Cost

184 184 The DS1955/DS1957 Cryptographic iButton The Java-powered Cryptographic iButton has even better physical and electronic security: –More metal layers covering secrets –Freeze and other tamper detectors –Instant Zeroization wipes secrets quickly Performs Dual-Key Encryption very fast Can help limit the scope of some attacks through its programming capabilities

185 185 DS1955/DS1957 also has Drawbacks... More expensive (very large die size) Illegal to export or sell to some customers Much more versatile, but not as fast in performing some operations, like SHA-1 Difficult to justify for small cash use

186 186 The Competition for Authentication Whats the secret word?

187 187 Dedicated Hardware Lock-and-Key Chipsets They use much weaker algorithms and small key sizes - subject to simple attacks Most of them use Security By Obscurity and try to keep their algorithms a secret They have no built-in provisions to authenticate the user –Steal a key and you can use it any time

188 188 e-Cash iButton Applications Bus/Train Fares Parking Meters Telephone Card Gasoline Card Multi-Credit Card Student Union Card Utility Use Metering Locker/Post Box Access

189 189 Conclusions The Monetary iButton DS1963S can be a secure, effective and versatile e-Cash token. Levels of physical and cryptographic security are suitable for dollar amounts similar to what a person might carry in a purse or wallet. A world-class algorithm in its pure form attains higher levels of monetary and data security for the cost than ever before.

190 190 The Monetary iButton does not perform encryption, and so is free of export and national security restrictions. The Monetary iButton makes an excellent user authentication token for Internet, Intranet or other electronic user authentication applications.

191 191 More Uses for the DS1963S It just keeps getting better!

192 192 Small Message Encryption One Time Pad is a fundamental concept of cryptographic theory SHA-1 (being irreversible) make a great One-Time-Pad generator

193 193 Theory of the One-Time-Pad Given a message byte, called the PAD XOR the byte with a secret random byte The result is a random number! No information about the original byte remains so long as the PAD byte is unknown. This is the most SECURE cipher possible!

194 194 Pads are the most basic cipher Both parties to the conversation share the same pad The pad is created entirely using random numbers It is unbreakable! (So long as the PAD is never be used again! Each pad is good for ONE message.)

195 195 Use SHA to Generate Pads MAC is essentially random if you dont know the secret used to make it Irreversible - Pad cannot reveal secret MAC data serves as One-Time-Pad Secrets never leave the safety of the iButton Work is done in the iButton Host does only simple byte-wide XOR

196 196 Randomize to Prevent Replay Inject a random challenge (called a salt in this case) to make each message random Include the challenge in the message

197 197 Small Message Encryption Now is the time for all good men to come to the aid of their party. Random Number Cipher- Text MAC Secret SHA-1 Ciphertext

198 198 Small Message Decryption Now is the time for all good men to come to the aid of their party. Cipher- Text MAC Secret SHA-1 Random Number Ciphertext

199 199 The DS1963S for Small Message Encryption/Decryption Every message appears entirely random (even the same message repeated) 20 bytes of One-Time-Pad in about 1ms World class security at very low cost Micro needs only perform XOR function Secrets are stored safely in DS1963S Built-in Secret rotation facility

200 200 Anonymous Authentication We dont know WHO he is, but we know hes REAL!

201 201 Voting Systems Voting systems need to securely authenticate each and every voter Voter identity must be kept secret – each persons vote is private. The DS1963S authentication schemes that we have described all require the server to know the token serial number

202 202 Anonymous Authentication Do not bind the secret to the ROM ID (serial number) of the device Agent (local computer or iButton reader) does not send the ROM ID to the server Server can authenticate the iButton, but does not get an identity from the iButton

203 203 The DS1961S and DS2432 New SHA devices with EEPROM

204 204 Features One secret, four data pages 8-byte scratchpad (versus 32 bytes) Write to memory cannot be performed without proper MAC (you must know the secret to write to the device) Slightly slower SHA computation Battery-less!

205 205 Drawbacks One secret (one service provider) Not equipped to serve as a co-processor (designed to work with the DS1963S as a co-processor) EEPROM has some special problems in intermittent contact environments Limited EEPROM write cycles Does not have anonymous capability

206 206 Benefits Battery-less Smaller Cheaper

207 207 Future DS1963S co-processor in IC package DS1961S token with anonymous mode A Debit-Only Co-Processor SHA-1 security in other devices

208 208 FIN (Thats French for THE END)

209 209 e-Cash - Electronic Money The DS1963S eCash iButton


Download ppt "1 Electronic Cash and User Authentication using the Dallas Semiconductor / Maxim DS1963S Monetary iButton."

Similar presentations


Ads by Google