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

e-Cash - “Electronic Money” The DS1963S eCash iButton Who I Am: Hardware and Software Engineer A student of cryptography Wrote crypto iButton comm layers Warnings: WE WILL COVER MANY THINGS YOU MAY ALREADY KNOW VERY WELL. This session is intended to give a ageneral understanding of the DS1963S and the methods we use to secure money and data in it.

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

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

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

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 Explain how these will occur to spark people to speak up if they are not following.

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 Has no value in and of itself. Just paper and ink! Value is in the backing - the govornment backs it. As long as we all agree that money has value, it works!

What’s Good About Cash? Anonymous - The seller doesn’t care who you are Difficult to counterfeit (paper, printing methods, lots of new tricks) Backed by the government Trusted by everyone (We’re all used to it…) A visible representation of funds (you can see what you’ve got) Is it really difficult to counterfeit?

What’s New About Your Cash Serial Numbers Fine Line Printing Portrait Watermark Also: Ink is magnetic Rear includes oversized letters to be easier to read Security Thread Micro-printing Color Shifting Ink

What’s 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

What’s 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

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.

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

What’s 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)

What’s 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

What’s 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

i Why eCash is Like Cash? A representation of value Anonymous - The seller doesn’t care who you are i

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

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 It’s easier to obtain a visual, private representation of your funds

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

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

What is an iButton? Portable memory that doesn’t forget Electronic circuits that can control or limit data access It can keep secrets Physically secure circuit assembly Physically secure steel container ROM ID C O N T R L RAM Battery

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

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..)

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

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 ROM ID C O N T R L RAM Battery

An iButton Serial Number 15 00 00 00 01 40 D6 0C Error Check Code Unique Serial Number Family Code Shown in Hexadecimal notation

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

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

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?

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.

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 $123.45 i

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”

Is Money Stored in RAM Safe? NO!

Let’s Make Ourselves Rich! It’s EASY to change the numbers in RAM We’ll just raise the balance amount to whatever we want Instant money! Who will know?

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 There’s no protection against anyone altering the memory contents There’s no easy way to detect that the fraud has been perpetrated

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

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

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 Cryptogram CIPHER Plaintext Ciphertext

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

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

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

“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.

“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

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 (we’ll see why later on…)

“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.

“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!

A Little Bit About Ciphers...

Single Key Ciphers The old “Decoder Ring” Original message 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 Key Cipher- text pjighqr Same Key Cipher Key Restored message Hello

What Does It Tell You? Only that whoever sent the message knows the secret key, because, If they didn’t 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.

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

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. MESSAGE HASH FUNCTION DIGEST 187B6EF54B079A5C

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

An Example of a Simple Hash - A Check Digit System Some companies include Check Digits in their numbering systems Here’s how Check Digits work: Take a part number or account number Generate a simple hash of it (we’ll 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)

A Simple Hash - Check Digits A typical Part or Account Number: 12-3456-789 Sum of the Digits = 1+2+3+4+5+6+7+8+9 = 45 Take just the right-most digit = 5 Embed the check digit in the part number: 12-3456-7895 Make an error in entering the part number: 13-3456-7895 System re-computes check digit: 1+3+3+4+5+6+7+8+9 = 46 The error is obvious: 6 = 5 ??? The Check Digit has caught a keying error before it could become a serious problem.

Be Sure You Understand! This is an important concept - ASK NOW! 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!

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. MESSAGE HASH FUNCTION DIGEST 187B6EF54B079A5C

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 spec’d by the government

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

Secure Hash Algorithm 160 bits Repeat this process 80 times!

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!

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 won’t match the balance when checked If the Hash changes, the balance won’t match the Hash when checked Any change is detected by the Hash

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

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

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

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 don’t 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

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

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

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

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

Understand MACs and How They Work Call it a “Secret” (It’s 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

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

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.

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?

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?

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

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!

Is Our e-Cash Really Secure? Not Yet!

Duplicating Money Even if the Bad Guy doesn’t 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!

It’s 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

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 Guy’s copies are worthless!

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

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”

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 We’ll 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.

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

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

Secure iButton e-Cash with the DS1963L!

Wait Just a Minute! It’s Not Really That Easy! A More Advanced Attack

“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)

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 it’s not a fake. ?

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

Spy-Vs-Spy: What’s 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 What’s the secret?

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 wouldn’t even know that they have discovered the secret

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 What’s the secret times 452?

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

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

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!

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.

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.

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

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

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

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?

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

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!

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

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!

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.

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

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

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

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

Two MACs for Double Security 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

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!

Let’s 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

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.

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

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 hasn’t 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!

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

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! (It’s about time!) Ya-Hoo!

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?

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

The “Prisoner Exchange” Problem You have something of value Someone who you don’t 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!

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 don’t let go!

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) Don’t give up the product until they prove that they gave up the money (by staying long enough to read the iButton back)

“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

Alternative Philosophies Money could be lost if the human walks away and indeed WAS debited, but that’s 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)

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

That’s 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

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.

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?

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

B 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

A 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

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)

Preventing the A-B-A Cheat Each vending machine includes a random number with the balance (we’ll 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.

But, that’s 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 Provider’s entire system, so All the iButtons that use the same secret would be compromised!

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

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)

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!

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?

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 we’re up to seven hash operations per transaction! Master Secret Serial Number Device Secret SHA-1 Used to Authenticate Data from iButton Unique Device Secret

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!

All those MACs! Won’t it take forever just to buy a Cola? Now we’re doing seven complex MAC operations in each transaction A MAC operation involves thousands of steps and lots of computation

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!

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 Cola i i Outside, serving as personal e-cash Inside, doing the crypto work at very high speed

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

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

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 doesn’t always work reliably. Cryptography comes to the rescue again with “Secret Sharing” methods...

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

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

Still at Risk? Even secret sharing schemes can’t 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…..

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.

Assemble Partials in the iButton Partial Secret Master Secret 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. SHA-1

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

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

Secure e-Cash, cont’d... 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

Secure e-Cash, cont’d... 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

There’s One Attack Left... What about the Bad Guy who simply wants to BREAK the system?

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.

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.

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!

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

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 Employee ID Card Bob Jones 067388-654

True User Authentication PINs and Passwords

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”

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

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 (it’s not there when you need it)

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

“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.

Bind the User to the Token Include the user’s 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

Other DS1963S Applications

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.

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

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 Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Secret Counter Counter Secret Counter Counter Secret Counter Counter Secret Counter Counter Secret Counter Counter Secret Counter Counter Secret Counter Counter Secret Counter Counter

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

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 Other Page... File Page 0 File Page 1 Other Page... File Page 2

DS1963S Cryptographic Security

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

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!

2,900 years !

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

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

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

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

The Competition for Authentication What’s the secret word?

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

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

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.

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.

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

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

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!

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.)

Use SHA to Generate Pads MAC is essentially random if you don’t 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

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

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

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

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

Anonymous Authentication We don’t know WHO he is, but we know he’s REAL!

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

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

New SHA devices with EEPROM The DS1961S and DS2432 New SHA devices with EEPROM

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!

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

Benefits Battery-less Smaller Cheaper

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

(That’s French for THE END) FIN (That’s French for THE END)

e-Cash - “Electronic Money” The DS1963S eCash iButton Who I Am: Hardware and Software Engineer A student of cryptography Wrote crypto iButton comm layers Warnings: WE WILL COVER MANY THINGS YOU MAY ALREADY KNOW VERY WELL. This session is intended to give a ageneral understanding of the DS1963S and the methods we use to secure money and data in it.