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

1

Electronic Cash andUser Authentication

using the Dallas Semiconductor / Maxim

DS1963S Monetary iButton

2

e-Cash - “Electronic Money”

• The DS1963S eCash iButton

3

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.

4

What We Will Discuss

• How money and credit are handled now

• Why e-Cash is better

• The Evolution of a Secure eCash iButton

• The DS1963S Monetary iButton (MiB)

• Why Security is Important

• How the DS1963S features provide security

5

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

6

Be Sure You Understand!

• These slides indicate places where you should make sure that you are keeping up

• If you missed something, SPEAK UP!

• These slides will remind you

7

What is “Cash Money” ?

• A representation of value

• Recognized and validated by look, feel, familiarity

• Value is represented physically (ink on paper)

• Can be stolen by anyone with a physical advantage

8

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)

9

What’s New About Your Cash

Color ShiftingInk

WatermarkFine LinePrinting

Micro-printingSecurity Thread

PortraitSerial

Numbers

10

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

11

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

12

A Warning!

• “It is highly likely that an epidemic of global proportions - a serious threat to all human life - will be spread around the world quickly and efficiently on paper currency.” - From a joint statement by the World Health Organization and the United

States Centers for Disease Control in 1994.

13

What is a Credit Card?

• A representation of your responsibility

• Really just an ID card• Backed by you - the

individual• Recognized and

validated by look, feel, familiarity

14

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)

15

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

16

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

17

Why eCash is Like Cash?

• A representation of value

• Anonymous - The seller doesn’t care who you are

i

18

Why is eCash like a Credit Card?

• No denomination - No need to make change

• Information is electronic, access is simple and fast

• Audit trail is optional and personal

i

19

Why is eCash Better than Cashor 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

20

Why Not e-Credit Cards?• Credit Cards require database lookups

– Database lookups take time– Database currency is a problem

• All vendors must have a telephone or network connection to access database

• Not all recipients are connected or even “connectable” to the bank

• Vending equipment is too expensive

21

The Dallas SemiconductoriButton as an

Electronic Token fore-Cash Applications

22

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

RAM

ROM ID CONTROLBattery

23

Non-Volatile Memory

• Random Access Memory (RAM)

• Data is sustained by internal battery

• Special mechanisms to assure good data despite intermittent connections

• Memory organization using TMEX allows easy, efficient sharing of the memory area between users

24

Very Simple Connection

• Communicates 2-ways using one signal line

• Much simpler than radio, magnetic, or infra-red communications

• Very simple and inexpensive connection to electronic systems

• A variety of ways to get into computers (serial ports, parallel ports, USB ports, etc..)

25

Just a Touch...

• Communicating with an iButton requires a simple touch of the iButton to a reader

• Positive action by the user is required

• There is no doubt about the intent, no accidental communications take place

26

The Most Important Feature

• A unique Serial Number, sometimes called a “ROM ID”

• A permanent identifier that cannot be re-programmed

• No two iButtons EVER have the same serial number

RAM

ROM ID CONTROLBattery

27

An iButton Serial Number

15 00 00 00 01 40 D6 0C

FamilyCode

Unique Serial NumberError CheckCode

Shown in Hexadecimal notation

28

Facts about iButton Serial Numbers

• Written by a laser when iButton is manufactured• Every iButton is unique. No two iButtons will

ever have the same serial number• The biggest iButton serial number possible is

281,474,977,000,000 iButtons in each family• There can be 256 families, for a total of

18,010,000,000,000,000 iButtons in all!• We will NEVER run out of numbers

29

iButtons with Special Functions

• Temperature Sensors• Time/Temperature

Histograms• Time clocks (DS1994)• Password-protected

memories (DS1991)• Analog-to-Digital

Converters

30


• Do you know all about iButtons and their basic features?

• Do you know how iButtons are carried and used in day to day applications?

• Understand the Unique Serial Number?

31

Evolving eCash...

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

32

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

33

Think of it as Money

• The iButton contains a balance stored in the RAM by a monetary authority (like a bank)

• The balance represents your money remaining; the funds that are left in your iButton “account”

34

Is Money Stored in RAM Safe?

NO!

35

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?

36

Why is it So Easy to Cheat?

• Access to the iButton data is very easy (our own data books tell you how)

• The Bad Guy just writes in a bigger balance

• There’s no protection against anyone altering the memory contents

• There’s no easy way to detect that the fraud has been perpetrated

37

A Memory iButton Alone isNot Enough for Secure eCash

The Evolution of a

Better e-Cash iButton

38

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

39

Introducing Cryptography

• From simple substitution ciphers to highly advanced mathematical algorithms

• Cryptography is a science all its own!

• It has its own language, symbols, and lingo

MessageCIPHER

CryptogramPlaintext Ciphertext

40

Cryptography Lingo

• Message• Plaintext• Ciphertext• Cryptogram

Cipher• Algorithm

• Key• Secret• Encode, Encrypt

Decode, Decrypt• Attacker, or “Bad

Guy”

41

“Message”

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

42

Plaintext, Ciphertext

• Plaintext is the message that you wish to send

• It is clearly read and understood by anyone

• It is insecure

• Ciphertext is the encrypted message

• It makes no sense to anyone when they attempt to read it

• It is secure because the real contents cannot be read or understood

43

“Cryptogram”

• A Cryptogram is a Message that has been encrypted, or converted to a form that a person who does not have the secret “key” cannot understand.

• An entire Message, converted to Ciphertext, is a Cryptogram.

44

“Cipher” or Algorithm

• A “Cipher” is the process by which PlainText is converted into CipherText

• An Algoriothm is a series of operations that, when performed on the PlainText data, will turn it into Ciphertext.

• “Cipher” is a catch-all term for a variety of encryption algorithms

45

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

46

“Encrypt” < > “Decrypt”

• Encrypt means to make Plaintext into Ciphertext

• Decrypt is to make Ciphertext back into Plaintext once again

• Sometimes “Encode” and “Decode” are used to mean the same thing.

47

“Attacker”, “Bad Guy”

• The person or organization who wants to break your crypto-system and find out what the secret message contains

• Perhaps wants to alter the secret message before it gets to its rightful destination

• Sometimes, its your own courier, or your own customer!

48

A Little Bit About Ciphers...

49

Single Key Ciphers

• The old “Decoder Ring”• Both ends of the

conversation must know the same secret key

• Only one or a limited number of recipients

• Recipient can also encrypt messages using the same secret key

Hello

Cipher

pjighqr

Hello

Cipher

Cipher-text

Original message

Restored message

Key

Key

Same Key

50

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.

51

Whole-Message Authentication

• The entire message is encrypted

• No outsider can alter the message

• Could be a legal problem because the content is hidden from the authorities

• Can be very slow if the message is large

52

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 forall good men to come to the aid oftheir party.

187B6EF54B079A5C DIGEST

MESSAGE

HASHFUNCTION

53

Hashing is Used to Make Sure that Data is Un-Changed

• Run all the data through the hash function

• Send the resulting Hash along with the data

• The recipient can regenerate the Hash and compare it to the one that was sent to check the data for accuracy

• This makes transfer of data ultra-reliable

54

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)

55

A Simple Hash - Check DigitsA 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.

56


• Do you understand the concepts of Hashing?

• Do you understand WHY a Hash can tell us if the data in a message has been changed?

• This is an important concept - ASK NOW!

57

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 timefor all goodmen to come tothe aid of their party.

187B6EF54B079A5C DIGEST

MESSAGE

HASHFUNCTION

58

What Makes a Good Hashing Algorithm?

• Impossible to figure out any part of the input from the output digest

• Very unlikely to create a “collision” - the same digest made from different input data

• Time-tested, peer-reviewed, and very well scrutinized around the world

• Approved and spec’d by the government

59

Secure Hash Algorithm (SHA-1)• What is it?• How does it work?• Why do we use it?• It uses several methods to be secure:

– Diffusing - Each change in an input bit affects many bits of the output

– Reducing - Much about the input is lost in the course of the computation, keeping the process irreversible

– Obscuring - More than one input bit can cause changes in the same output bit

60

Secure Hash Algorithm

A B C D E

SUM

A B C D E

A B C D E

X

Data In

Constants

SHA Digest Output

Repeat this process 80 times!

160 bits

61

A Good Example of Peer Review in Action

• SHA-1 has MANY predecessors

• The Evolution of SHA-1:– MD-2 One method, but a little slow, so...– MD-4 Weakness was discovered, so...– MD-5 Never broken, but suspect, so...– SHA Better than any before, but….– SHA-1 The most trusted of them all!

62

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

63

Does a Hash Secure Our Balance Against A “Bad Guy”?

• A bad guy could just change the balance, and then compute a new hash for it

• We would never know that money was added

• The Hash algorithm is only a part of the scheme

64

How to Make It Really Secure?

• Make it impossible for the Bad Guy to be able to compute a new Hash

• If he changes the balance, it is detectable because the Hash is no longer correct

65

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

Oh No! Security

by Obscurity!

66

Keeping A Part of the Message a Secret

• An unlimited number of different “secret parts” are possible

• The “secret part” can be provided by service providers - They 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

67


361B73F60A925C DIGEST

HASHFUNCTION

Mary had alittle lamb.

Hash A Message Plus a Secret

Message Secret

68

Store Message + Hash in iButton,

But NOT the secret


361B73F60A925C

Message + Hashstored in iButton

Attacker is missing

critical information

needed to alter the data

69

Vendor Checks the Message


361B73F60A925C

361B73F60A925C Re-CreatedHash

HashFunction

Mary had alittle lamb.

Vendor knows theSecret Part

If Hash in iButtonmatches, thethe data is OK

70

A New Crypto-Term: MAC

• A MAC is a Message Authentication Code

• It is simply a Hash when a portion of the input is kept secret

• No one can compute a valid MAC for an altered balance unless they know the secret

71

Understand MACs andHow 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

72

A Note About Cryptography

• Most failures of cryptographic systems are failures in their IMPLEMENTATION, and not in the cryptography itself

• There are many short-cuts that can be made that may greatly weaken the security

• There are time-tested rules for crypto-systems and their application

73

Crypto-System Rules

• Never depend on “Security By Obscurity”. Only full disclosure and peer-review can hope to guarantee a secure crypto-system

• Be sure that random numbers REALLY ARE random. Bad random numbers have been the downfall of many crypto systems.

• Never short-cut or circumvent the time-tested and approved algorithms.

74

Recap - Hashing:

• What is a Hash?

• What does a Hash allow us to detect?

• How would you send a letter so that any changes could be detected?

• Does all the data involved in the hash have to be sent along?

75

• How can we prevent a “Bad Guy” from

being able to change the message and then generate a new Hash for it?

• When a Hash is computed and part of the input data is kept secret, what is the Hash result or digest called?

76


• How can a MAC protect data from unauthorized changes?

• This is an important concept, so ASK NOW!

77

Back to the eCash iButton

• Put money balance in the iButton memory

• Compute a MAC of the balance and a secret

• No one can change the balance and also keep the MAC correct without the

secret!

78

Is Our e-Cash Really Secure?

Not Yet!

79

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!

80

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

81

How can we Prevent Duplication?

• What if all copier paper had unchangeable serial numbers embedded in it?

• Each iButton is unique, because it has a permanent lasered serial number inside

• We can include the unique iButton serial number in the input to our MAC

• Now the Bad Guy’s copies are worthless!

82

Be Sure You Understand WHY!

• Why does including the serial number in the MAC make duplication impossible?

• This is an important point!• ASK NOW!

83

Could the Bad Guy Re-Usethe Same iButton?

• The Bad Guy copies the money amount and the valid MAC to a diskette

• The Bad Guy then spends most or all of the money value in the iButton

• The Bad Guy writes the original amount and MAC back into the iButton from the diskette

• Bad Guy spends the SAME money all over again!

• This is called a “Replay Attack”

84

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.

85

Counter has Special Properties

• Counter cannot be reset, backed-up, or re-loaded• Counter is BIG, and cannot be wrapped-around

– It can count to 4,294,967,296!• Special precautions detect any attempt to set the

counter back or affect it (Tamper Bits)• The counter makes each write to the memory a

unique event and gives each “instance” of the balance a unique ID

86


• Why does including the counter in the MAC make replay attacks impossible?

• ASK NOW!

87

Secure iButton e-Cashwith the DS1963L!

88

Wait Just a Minute! It’s Not Really That Easy!

A More Advanced Attack

89

“Faking-Out” the Vendor

• The clever Bad Guy could make special hardware that can “pretend to be” an iButton

• Many micro-controllers and other programmable circuitry can be programmed to “pretend to be” an iButton

• This is called Emulating an iButton

• The Bad Guy copies the valid balance and MAC from a real iButton to his emulation of the iButton

• The Bad Guy uses the emulation iButton as money, sets the counter back each time he restores the original balance (he can do Re-Play attack because he controls the counter)

90

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.

?

91

Methods for Authentication

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

92

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?

93

What if Someone Overhearsthe 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

94

A Better Way to Authenticate

• Choose a number at random• Ask them to multiply their

secret by the random number• The secret itself was not ever

revealed to be compromised• If a Bad Guy overhears the

answer, it will be of no use next time because the random number is always different

What’s the secret times 452?

95

Challenge-and-Response

• The random number is called a Challenge, and the answer is the Response.

• No one in between the two can fool us, even if we passed the challenge-and-response down a line of intermediaries.

• Recording the response is of no use in any subsequent transaction

96

Can we Make an iButton that can Prove it is Authentic?

• We need a special iButton with some new features - Enter the DS1963S

• It can keep secrets securely hidden inside• It can compute SHA-1 MACs inside• It can take a Challenge and generate a Response

(the MAC of the challenge and a secret)• We can test the result to see if the iButton really

does know the secret

97


• Why does being able to keep a secret and perform Challenge & Response make it possible for an iButton to be authenticated?

• Why does the Challenge need to be a random number?

• This is important, so• ASK NOW!

98

Security Depends on Keeping a Secret from a Bad Guy

• The Bad Guy can get his hands on as many of these iButtons as he needs, and he can take them where ever he wants to “work on them” in privacy.

99

Protecting the Secret

• Secret is stored in static RAM

• It is maintained by a very small Lithium power cell inside the iButton steel container

• Battery connection would have to be maintained during dis-assembly and probe without any interruption, or the secret would be scrambled and lost.

100

A Secure Assembly MethodSilicon Chip(Face Down)

Printed CircuitBoard

Solder Bumps

EpoxyUnderfill

Flip-Chip Technique Makes a “Circuit Sandwich” that would be very difficult to take apart

Secrets

101

Secure Assembly

• Silicon hides secrets under metal layers

• Silicon is flipped and soldered face-down to a circuit board

• Ultraviolet-light-hardened epoxy is flowed between the silicon chip and the board by capillary action

• Almost impossible to dismantle or probe

102

A Stainless Steel Vault

Sealing the entire device in Stainless Steel makesa very durable package that’s very difficult to open

Lithium BatteryCircuitBoard

Circuit“Sandwich”

Sealed, Stainless Steel Enclosure Integral Power Source

103

Is all this data REALLY from the iButton?

• A Bad Guy could bring a valid iButton to authenticate himself

• He could then substitute a fake iButton with illegal money value in it for the transaction

• Can we be sure the monetary data we read from the iButton really came from the same iButton that we have authenticated?

104

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

105


• How can a simple Challenge & Response exchange guarantee that the data we read really came from the iButton, and not a Bad Guy injecting false information?

• ASK NOW!

106

Requirements to Perform Secure e-Cash

• Authenticate the iButton device to make sure its not an Emulation

• Verify that all of the data has not been in any way corrupted or altered in the communications path

• Validate the monetary balance and make sure it has not been altered

107

Accomplishing iButtonChallenge and Response

• A MAC of all the data and a secret would protect the data from being manipulated, and would prove that the device knows the secret, and is therefore authentic

• The entire exchange of data to and from the device can be protected from intervention

• The device must be able to perform world-class hashing functions - and fast!

108

A Secure Hashing Algorithm

• We need a secure, trusted, well-tested hashing algorithm implemented in silicon.

• SHA-1 has all the features we need, and is one of the easier hashes to implement in hardware logic and registers.

109

SHA-1 is No Easy Task

• SHA-1 done the “usual” way would take a lot of room, and so the new iButtons be expensive to manufacture (fewer parts can be made from each wafer processed)

• Instead, we have designed a unique SHA-1 engine that uses a very efficient method to keep the hardware small, and therefore keep the cost down

110

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

111

Authenticate not just the iButton, but the Data from it as well

• Include the challenge, the balance, the serial number and the secret in the MAC input

• Now the MAC, if it checks, proves that the device knows the secret, and

• That all the data we got from the device is authentic and accurate, too.

• Once we know that the data from the iButton is authentic, we can check the MAC on the balance and know that it is valid as well

112

Validate Everything!

Serial Number

Secret

Balance MAC

Balance

Challenge

SHA-1 SHA-1

Match?

Random

Un-trusted Connectionbetween iButton & Reader

Secret

113

Two MACs for Double Security

• Two MACs:– One authenticates the iButton and the data, and

secures the communications link to the device– One protects the monetary balance against

being changed or faked by a Bad Guy

• The entire transaction can be validated

• All of the data is checked

114


• How can a SHA-1 algorithm provide e-Cash security from attackers?

• Why is it a benefit to have the SHA-1 engine inside the iButton?

• ASK NOW!

115

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

116

• The machine reads the MAC from the iButton• The machine performs the same MAC computation

on the same data, and the secret (that it knows)• The machine verifies the match between the two

MACs to see if the iButton is authentic• The machine now knows that the iButton is real (the

iButton has proved that it knows the secret)• The machine also knows that the data has not been

tampered with in the communications path.

117

• The machine takes the monetary balance, the serial number, and the counter and generates a MAC using the monetary secret (that it knows)

• If the MAC matches the one from the iButton, the money has been proven to be valid and unaltered

• The machine subtracts the cost of the cola from the balance and generates a new monetary MAC using the secret that it knows

• The machine writes the debited amount, with the new valid MAC, back into the iButton

118

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!

119

We have to do more...

• The machine generates a new random challenge and reads the device data back again

• The machine checks the MAC from the device with the one that it generated to be sure that the iButton and the data is authentic and not just a playback of what the machine wrote out before

• A playback would be the same, but the challenge is new each time and so the response is different

• Only an iButton that knows the secret can make a proper response

120

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

121

They call it “Tear”?

• Another crypto-term: “Tear” - When the media (in this case, the iButton) is taken away before the transaction can be completed and checked

• At most stages in the transaction, we can abort if the iButton device departs too soon, and no harm is done (no money or product has changed hands)

• What if all is well right up until we try to check and see if the debit was successful, and we find that the iButton has gone away?

122

Accidental, or Intentional?

• A Good Guy might simply remove the iButton too early by accident

• We need to handle “innocent tear” very well to keep customer confidence and comfort

• Bad Guy could cause precise loss-of-contact

• Be sure that the result of intentional tear does not produce a profit for a Bad Guy

123

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!

124

Even a Child Knows...

• Eye your opponent carefully

• Try your best to look intimidating

• Get into a position where your opponent does not have an advantage

• Make the exchange suddenly, and quickly

• Grab the item you want and don’t let go!

125

We Handle it the Same Way

• Make sure the iButton is real and the money contained in it is valid

• Make the transaction as quickly as possible (to reduce the odds that “tear” will occur)

• Don’t give up the product until they prove that they gave up the money (by staying long enough to read the iButton back)

126

“Tolerate the incompetent humans, they know not what they do”

• The philosophy for dealing with tear is very important in e-Cash vending system design

• What if we simply refuse to give up product? – “Let the transaction finish, or NO COLA!”

• The thirsty and frustrated human is very likely to present the iButton again

• Our machine will just wait for the iButton to return and finish the job when (and if) it does

127

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)

128


• Do you understand what Tear is and why it could be a problem?

• ASK NOW!

129

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

130

• And it took two hashing operations in the iButton:– One to generate a MAC for the data that the machine

read when the iButton arrived, and

– One to generate a MAC for the data that the machine read back to check that the debit completed.

131

What Else can they Throw at Us?

• As we have seen, it is very important that the vending machine read the iButton back after the debit to be sure that it “took”.

• But, if the iButton appears to have been properly debited, how do we know that the debit was our own?

132

This next one is a bit Complicated...

The A-B-A Cheat

133

• A scenario for yet another way of cheating:– Bad Guy attempts to buy a cola from Machine A– Bad Guy removes the iButton before the debit can be

read back and checked by the machine– Bad Guy goes to Machine B using the same iButton

(which has not been debited)– Bad Guy allows the full transaction to complete at

Machine B, and gets a cola. His iButton is debited for the cost of one cola.

– So far, so good.

B

134

– Bad Guy now returns to machine A and touches

the same iButton again– Machine A reads the iButton, observes the

correctly debited amount, the correct serial number, and the correct counter value and assumes that it (A) had completed the prior transaction after all. It thereby assumes that it owes this customer a cola!

– Machine A vends a Cola.

A

135

– Customer got two Colas for the price of one!– And the cost of one Cola has been added to two

different coin boxes! We have duplicated money!– (Banker-types consider it very bad if cola

machines create new money on their own)

136

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.

137

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!

138

New Crypto-Term: Class Break

• When all the devices in a system are broken by breaking a single device.

• The consequences of a Class Break would be very serious indeed!

• Making a system-wide key change across millions of deployed iButtons would be almost impossible - and very costly

139

How to Prevent a Class Break

• Reduce the odds or increase the difficulty– Better physical security (expensive and ultimately

limited)

• Catch ‘em in the act of trying to break the device– Booby-traps that wipe the secret when you try to break

in and get it (expensive, sometimes they might false alarm and erase legitimate money, also ultimately limited)

140

A Different Secret for each iButton?

• Legitimate vendors would have to know every secret for every iButton that might arrive– There could be millions of secrets!

– Requires huge memories, or network connections at each and every vending machine

– A database nightmare!

141

A Better Way to put a Unique Secret in Each iButton

• Give each device a secret that is computed from a master secret and the unique device serial number

• The method should make it impossible to figure out the master secret given the unique device secret

• We will need a fast way to re-create each devices unique secret when it arrives

• Sound familiar?

142

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!

Serial NumberMasterSecret

SHA-1

Unique DeviceSecret

Used to Authenticate

Data from iButton

Device Secret

143


• Do you understand what a Class Break is?

• Why does having a different key in each iButton prevent a Class break?

• ASK NOW!

144

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

145

Time to Perform a MAC?

• In a typical micro-controller, could be as slow as 1/2 second or more for each MAC

• That would be 3.5 seconds or more just to do this simple Cola transaction!

146

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

ii

Inside, doingthe crypto workat very high speed

Outside,serving as personal e-cash

Cola

147

The Ultimate Co-Processor• The Monetary iButton can perform MACs very quickly

• It has functions that allow it to check MACs from other iButtons without revealing the sensitive secrets

• It can keep the secrets better than any micro controller

• It has its own unique serial number

• It has its own stainless-steel vault

• It has its own backup power cell

• It is a safe place to store accumulated funds

• It has room for configuration and price data

• It can be easily installed, retrieved or exchanged

• It is inexpensive

148


• Do you understand how the same DS1963S iButton can be both an eCash carrier and a co-processor?

• ASK NOW!

149

What about other Points of Risk?

• The biggest risk is often the people or systems at the service providers own facilities

• Employees could profit by stealing the master secrets that they may have access to at work

• Master secrets must be kept under lock-and-key, and security of that type is expensive and doesn’t always work reliably.

• Cryptography comes to the rescue again with “Secret Sharing” methods...

150

Protecting the Master Secrets

• Another crypto-term: “Secret Sharing”

• Breaks the master secret into several “partial secrets”

• Partial secrets may be distributed among VIPs or kept in different vaults (physical or electronic, like CiBs).

• No single employee needs to ever have access to all the partial secrets.

• No partial secret is of any use without all of the others.

• Partial secrets must be brought together only when the master secret is to be re-created

151

Shared/Split Secrets

Partial Secret

Master Secret

Partial SecretPartial Secret

152

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

153

Assemble the Partial Secrets inside the iButton

• Use the Hash mechanism inside the Monetary iButton as a secret sharing tool

• Re-build the master secret entirely inside the confines and security of the iButton

• The master secret NEVER exists outside the iButton, and is NEVER exposed to employees or anyone else

• Partial secrets can be injected at various points along the process, even in different cities or factories

• The final partial might not be injected until the iButton is given value and handed to the customer. Any iButton taken from the system before that step is useless to an attacker.

154

Assemble Partials in the iButton

Partial Secret

Master SecretSHA-1

We send each partial into the iButton and buildthe new master secret one-by-one. The results are never exposed outsidethe iButton.

155


• Do you understand how Secret Sharing is done?

• Understand WHY? • ASK NOW!

156

Recap: A Scheme and iButtonfor Secure e-Cash

• Provides a secure steel container for eCash

• Secures a monetary value using a Hash

• Uses the unique iButton ID to protect monetary value against duplication

• Uses non-resetable counters to protect monetary value against Re-Play Attacks

157

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

158

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

159

There’s One Attack Left...

What about the Bad Guy who simply wants to BREAK the system?

160

The Sneakiest Attack of Them All The “Competitor Attack”

• Most attackers wish to profit from their efforts

• Competitors may profit by simply breaking the system, causing customers to distrust it

• The simplest attack is to destroy the device, but that leaves obvious evidence behind

• Another method is to corrupt the monetary data in the device, but that would also be somewhat obvious

• The “sneakiest” attack would be to corrupt the secrets. Since they cannot be read out, no one could be sure if a non-working part had been scrambled or had simply failed.

161

A Counter on the Secrets• An attempt to make competitor attacks more

easily detectable and obvious• Like the data pages, each secret also has a counter

that goes up one count when the secret is changed• This can be used to detect over-written secrets as

opposed to hardware or memory failures.• The secret counter can be included in the

monetary MAC to lock the monetary value even more tightly to the state of the iButton and secret.

162


• Do you understand why someone would want to disrupt the system even if they did not profit directly from their attack?

• ASK NOW!

163

The DS1963S eCash iButton

• Securely stores monetary balances

• Can be reliably authenticated

• Can reliably authenticate a user

• Detects alteration of the monetary balance

• Detects alteration of the I/O data exchanged

• Detects alteration of the secrets

• Physically secure, durable steel container

• Fast, efficient internal cryptographic engine

164

Can the DS1963S iButton only Represent Money?

• Other data may also be secured– Secure employee information

– Secure access rights, door lists, security levels

– Secure credit card information

– Secure photograph

– Secure biometric Data

• Tamper-Proof Employee/Student ID

Bob Jones

EmployeeID Card

067388-654

165

True User Authentication

PINs and Passwords

166

User Authentication

• The Internet needs a way to authenticate users - to make sure they are really who they say they are - before allowing them access to sensitive information

• Software systems need a secure way to authenticate users

• Access Control and Door Lock systems need more reliable and secure “keys”

167

Problems Handling PINs and Passwords

• For an Internet server, handling thousands (or millions) of user PINs or passwords is a huge task

• The time to authenticate a user includes looking up their PIN or password in the huge database

• Having many copies of a database of user secrets makes them more easily compromised

• Sending PINs or passwords over the network raises the risk of their interception

168

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)

169

A Better Way…

• Combine the best of Tokens and Passwords

• Something You Bring (the Token)

• Something You Know (your Password)

170

“Something You Bring, Something You Know…”

• The authentic user must bring a unique, physical token and present it,

• The authentic user must know something that is secret, and prove that he knows it,

• Only when both the secret and the token are present is the user truly authenticated.

171

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

172

Other DS1963S Applications

173

The Monetary iButton as a Key

• Access Control, Safes, Lockers, Stand-alone Door Locks all need versatile electronic keys that cannot be duplicated.

• Because data can also be protected from alteration, access levels, door lists, and employee ID can be stored securely in the iButton as well.

174

Accessory Authentication

• Manufacturers want to be sure that customers use only genuine accessories

• Secret-keeping and Hashing can allow an appliance to authenticate the accessories that are connected to it, and refuse to work with third-party knock-offs

175

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

DataDataDataDataDataDataDataDataData

DataDataDataDataDataDataDataDataData

SecretSecretSecretSecretSecretSecretSecretSecret

CounterCounter

CounterCounter

CounterCounter

CounterCounter

CounterCounter

CounterCounter

CounterCounter

CounterCounter

176

Multiple Service Providers

• As many as seven service providers can share the device

• Each providers space is independent from the others

CitiCorp

NationsBank

Eat At Joe’s

Etc...

DS1963S

177

1-Wire File Compatible

• 1-Wire File directory and file structures may be used throughout

• 1-Wire File directory pages can be protected, too

• Allows dynamic RAM memory allocation as providers are added

File Directory

File Page 0

File Page 1

File Page 2

Other Page...

Other Page...

178

DS1963S Cryptographic Security

179

The “Brute Force” Attack

• Any and every cryptosystem is susceptible to a “Brute Force” attack

• The attacker simply tries each and every possible key until one works

• Time depends on maximum rate that keys can be tried and number of possible keys

180

Is a 64-bit Secret Big Enough?

• On average, finding out the secret would require (2^64)/2 SHA operations, or about 9,223,000,000,000,000,000 computations.

• A very fast computer can perform a SHA-1 computation in about 1 microsecond.

• It would take about 2,900 years using 1000 ultra-fast computers to break the secret!

181

2,900 years !

182

Other Crypto-Attacks?

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

183

iButton Data Security-Vs-Cost

More Security

Higher Cost

DS1991Password-Protected Memory

DS1963LMonetary iButton

DS1955/DS1957

DS199XMemoryiButtons

DS1963SNext-GenerationMonetary iButton

Java-poweredCryptographiciButton

$$$$

Very Secure,

Low CostUltra

Secure,

High Cost

184

The DS1955/DS1957 Cryptographic iButton

• The Java-powered Cryptographic iButton has even better physical and electronic security:– More metal layers covering secrets

– Freeze and other tamper detectors

– “Instant Zeroization” wipes secrets quickly

• Performs Dual-Key Encryption very fast• Can help limit the scope of some attacks through

its programming capabilities

185

DS1955/DS1957 also has Drawbacks...

• More expensive (very large die size)

• Illegal to export or sell to some customers

• Much more versatile, but not as fast in performing some operations, like SHA-1

• Difficult to justify for “small cash” use

186

The Competition for Authentication

What’s the secret word?

187

Dedicated Hardware Lock-and-Key Chipsets

• They use much weaker algorithms and small key sizes - subject to simple attacks

• Most of them use “Security By Obscurity” and try to keep their algorithms a secret

• They have no built-in provisions to authenticate the user– Steal a key and you can use it any time

188

e-Cash iButton Applications

• Bus/Train Fares• Parking Meters• Telephone Card• Gasoline Card• Multi-Credit Card• Student Union Card• Utility Use Metering• Locker/Post Box Access

189

Conclusions

• The Monetary iButton DS1963S can be a secure, effective and versatile e-Cash token.

• Levels of physical and cryptographic security are suitable for dollar amounts similar to what a person might carry in a purse or wallet.

• A world-class algorithm in its pure form attains higher levels of monetary and data security for the cost than ever before.

190

• The Monetary iButton does not perform encryption, and so is free of export and national security restrictions.

• The Monetary iButton makes an excellent user authentication token for Internet, Intranet or other electronic user authentication applications.

191

More Uses for the DS1963S

It just keeps getting better!

192

Small Message Encryption

• One Time Pad is a fundamental concept of cryptographic theory

• SHA-1 (being irreversible) make a great One-Time-Pad generator

193

Theory of the “One-Time-Pad”

• Given a message byte, called the PAD

• XOR the byte with a secret random byte

• The result is a random number!

• No information about the original byte remains so long as the PAD byte is unknown.

• This is the most SECURE cipher possible!

194

Pads are the most basic cipher

• Both parties to the conversation share the same pad

• The pad is created entirely using random numbers

• It is unbreakable!

• (So long as the PAD is never be used again! Each pad is good for ONE message.)

195

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

196

Randomize to Prevent Replay

• Inject a random challenge (called a “salt” in this case) to make each message random

• Include the challenge in the message

197

Small Message Encryption


Random Number

Cipher-Text

MAC

Secret

SHA-1

Ciphertext

198

Small Message Decryption


Cipher-Text

MAC

Secret

SHA-1Random Number

Ciphertext

199

The DS1963S for Small Message Encryption/Decryption

• Every message appears entirely random (even the same message repeated)

• 20 bytes of One-Time-Pad in about 1ms

• World class security at very low cost

• Micro needs only perform XOR function

• Secrets are stored safely in DS1963S

• Built-in Secret rotation facility

200

Anonymous Authentication

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

201

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

202

Anonymous Authentication

• Do not bind the secret to the ROM ID (serial number) of the device

• Agent (local computer or iButton reader) does not send the ROM ID to the server

• Server can authenticate the iButton, but does not get an identity from the iButton

203

The DS1961S and DS2432

New SHA devices with EEPROM

204

Features

• One secret, four data pages

• 8-byte scratchpad (versus 32 bytes)

• Write to memory cannot be performed without proper MAC (you must know the secret to write to the device)

• Slightly slower SHA computation

• Battery-less!

205

Drawbacks

• One secret (one service provider)• Not equipped to serve as a co-processor

(designed to work with the DS1963S as a co-processor)

• EEPROM has some special problems in intermittent contact environments

• Limited EEPROM write cycles• Does not have anonymous capability

206

Benefits

• Battery-less

• Smaller

• Cheaper

207

Future

• DS1963S co-processor in IC package

• DS1961S token with anonymous mode

• A “Debit-Only” Co-Processor

• SHA-1 security in other devices

208

FIN

(That’s French for THE END)

209

e-Cash - “Electronic Money”

• The DS1963S eCash iButton

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

Documents

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