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

e-Cash - “Electronic Money”
• The DS1963S eCash iButton
2

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

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
4

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
5

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
6

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
7

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

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

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
10

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
11

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

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
13

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

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
15

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
16

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

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
18

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
19

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
20

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

ROM ID
RAM
Battery
What is an iButton?
T
R
O
L
C
O
N
• 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
22

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
23

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

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
25

The Most Important Feature
• A unique Serial
Number, sometimes called a “ROM ID”
• A permanent identifier that cannot be reprogrammed
• No two iButtons EVER have the same serial number
ROM ID
RAM
Battery
T
R
O
L
C
O
N
26

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

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
28

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

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?
30

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

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
32

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”
33

Is Money Stored in RAM Safe?
NO!
34

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?
35

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
36

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

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
38

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

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

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

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
42

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

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

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…)
45

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

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

A Little Bit About Ciphers...
48

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
Cipher
Original message
Key
Ciphertext
Key
Hello
Restored message
49
Same
Key

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

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
51

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
187B6EF54B079A5C DIGEST
52

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
53

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

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

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

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
187B6EF54B079A5C DIGEST
57

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
58

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
59

Data In
Constants
Secure Hash Algorithm
160 bits
C A B D E
X
SUM
Repeat this process 80 times!
A B C D E
A B C
SHA Digest Output
D E
60

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

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
62

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
63

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
64

How to Prevent the Bad Guy from Making a New Hash
• 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
65

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
66

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

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

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

A New Crypto-Term:
• A MAC is a
Message Authentication C ode
•
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
70

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
71

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 cryptosystems and their application
72

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 timetested and approved algorithms.
73

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?
74

• 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?
75

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

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

78

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

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
80

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

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

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”
83

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

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
85

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

Secure iButton e-Cash with the DS1963L!
87

Wait Just a Minute!
A More Advanced Attack
88

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

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

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

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?
92

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
93

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?
94

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
95

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
96

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

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

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

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

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
101

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
102

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?
103

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
104

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

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
106

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 worldclass hashing functions and fast!
107

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

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
109

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
110

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
111

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

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
113

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

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
115

• 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.
116

• 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
117

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

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
119

• 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!
120

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?
121

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
122

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

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

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

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

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

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

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
129

• 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.
130

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?
131

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

• 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
133

– 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
134

– 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)
135

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

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

New Crypto-Term:
• 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
138

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

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

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?
141

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
Unique Device
Secret
Used to
Authenticate
Data from iButton
142

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

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
144

Time to Perform a MAC?
• In a typical microcontroller, 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!
145

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

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
147

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

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

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
150

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

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…..
152

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

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

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

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
156

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
157

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
158

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

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

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

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

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
163

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
164

True User Authentication
PINs and Passwords
165

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”
166

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
167

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

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

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

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
171

Other DS1963S Applications
172

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

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
174

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

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

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
177

DS1963S Cryptographic Security
178

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
179

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

2,900 years !
181

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

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

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
184

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
185

The Competition for
Authentication
What’s the secret word?
186

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
187

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
188

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

• 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.
190

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

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

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

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

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
195

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
196

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

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

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
199

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

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
201

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
202

The DS1961S and DS2432
New SHA devices with EEPROM
203

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

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
205

• Battery-less
• Smaller
• Cheaper
Benefits
206

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

FIN
(That’s French for THE END)
208

e-Cash - “Electronic Money”
• The DS1963S eCash iButton
209