lecture 12 e-commerce and digital cash. as communication technologies, such as the internet and...

49
Lecture 12 E-Commerce and Digital Cash

Upload: gabriella-thompson

Post on 31-Dec-2015

219 views

Category:

Documents


2 download

TRANSCRIPT

Lecture 12 E-Commerce and Digital Cash

As communication technologies, such as the Internet and wireless networks, have advanced, new avenues of commerce have become available. This great potential to reach more customers has led to great potential for theft and fraud. Transmitting credit card and purchase information over nonprotected channels can lead to unwanted parties invading customer privacy and stealing vital credit information. Securing the information necessary to conduct electronic commerce is therefore very important.

We look at three examples of how cryptography can be used in electronic business transactions. We use the signatures with additional functionality. The mechanisms described in this lecture provide functionality beyond authentication and non-repudiation. In most instances, they combine a basic digital signature scheme with a specific protocol to achieve additional features which the basic method does not provide.

Outline

Secure Electronic Transaction Undeniable Signature Digital Cash

1 Secure Electronic Transaction Every time someone places an order in

an electronic transaction over the internet. These data must be protected from unwanted eavesdroppers in order to ensure the customer’s privacy and prevent credit fraud.

1.1 Requirements

protected. bemust numbers card

credit assuch n informatioaccount Sensitive : (4)

possible. as secure as

kept be shouldon transactia of details The : (3)

altered. becannot nsinstructiopayment

and orders purchase assuch Documents : (2)

forged. becannot signatures and edimpersonat

becannot on transactiain tsParticipan : (1)

Security

Privacy

Integrity

tyAuthentici

1.2 SET Protocol

In 1996, the credit card companies MasterCard and Visa called for the establishment of standards for electronic commerce. The result, whose development involved several companies, is called the SET. It starts with the existing credit card system and allows people to use it securely over open channels. The SET protocol is fairly complex, involving many technique details. In the following, we’ll discuss one aspect of the whole protocol, namely the use of dual signature.

1.2.1 ElementsParticipantsBankCardholderMerchantCardholder’s two pieces of informationGSO=goods and services order, which consists

of the cardholder’s and merchant’s names, the quantities of each item ordered, the prices, etc.

PI=Payment Instructions, including the merchant’s name, the credit card number, the total price, etc.

1.2.2 Problem

The bank does not need to know what the customer is ordering, and for security reasons the merchant should not know the card number. However, these two pieces of information need to be linked in some way. Otherwise, the merchant could attach the payment information to another order.

1.2.3 Transaction Scheme

The system uses a public hash function H. A public key algorithm RSA is used, and the cardholder, the merchant, and the bank have their own public and private keys. Let EC, EM, and EB denote the encryption functions for the cardholder, the merchant, and the bank , and let DC, DM, and DB be the decryption functions .

1.2.3 Transaction Scheme (Continued)

merchant. the to)( and , ,),( Send (4)

. the

is This ).( computingby Sign )3(

).||(

result theofhash thecompute then ,

||obtain to and eConcatenat (2)

.))((

and ))(( Calculate (1)

:following thedo should

. using

merchant for the pays cardholder The :SUMMARY

schemen Transactio

PIEPIMDDSGSOE

POMDDDSPOMD

GSOMDPIMDH

POMDGSOMD

PIMDPIMDGSOMD

PIEH

PIMDGSOEHGSOMD

PI

GSO

BM

C

B

M

Signature Dual

cardholder The

1 Algorithm

1.2.3 Transaction Scheme (Continued)

bank. the to)( and ,, Send (4)

.obtain to))(( Compute )3(

. signature

s'cardholder the verifiedhasmerchant then theequal, are

theyIf ).( and )))((||( Calculate (2)

. equal should which , ))(( Calculate (1)

:following thedo should

PIEDSGSOMD

GSOGSOED

DSEGSOEHPIMDH

GSOMDGSOEH

B

MM

CM

M

merchant The

1.2.3 Transaction Scheme (Continued)

completed.been hason transacti that theindicating ,cardholder

thereceipt to signeddigitally with encryptedan Return (1)

:following thedo should

payment. ngguaranteei merchant, the

ion toauthorizat signeddigitally with encryptedan Return (4)

.n instructiopayment obtain the to))(( Compute )3(

. signature

s'cardholder the verifiedhasbank then theequal, are

theyIf ).( and )||))((( Calculate (2)

. equal should which , ))(( Compute (1)

:following thedo should

C

M

BB

CB

B

E

E

PIPIED

DSEGSOMDPIEHH

PIMDPIEH

merchant The

bank The

1.2.3 Transaction Scheme (Continued)

)}( ,

,),({ .1

PIEPIMD

DSGSOE

B

M

BankCardholder

Merchant

)}(

,,.{2

PIE

DSGSOMD

B)}(.{3 GPEM

)}(.{4 TCEC

1.2.3 Transaction Scheme (Continued)

ty.authenticiprotect order toin required

are steps more several tions,implementa actualIn (4)

ordered. being is what idea

no has so , hash value theseesonly bank The )3(

. signature the todue,n informatio theofany modify

bank to or themerchant for the infeasible be It would (2)

number. card

credit theseenot does so and ns,instructiopayment theof

)( form encrypted theseesonly merchant The (1)

GSOMD

DS

PIEB

Comment.

2 Undeniable Signature Normal digital signatures can be copied exactly.

Sometimes this property is useful, as in the dissemination of public announcements. Other times it could be a problem. Imagine a digitally signed personal or business letter. If many copies of that document were floating around, each of which could be verified by anyone, this could lead to embarrassment or blackmail. The best solution is a digital signature that can be proven valid, but that the recipient cannot show to a third party without the signer’s consent.

2.1 Scenarios for Undeniable Signature

. ofactivity fraudulent the traceeasier to be also

It will . lost to is name s'n corporatio with associated

advantage marketing but the signatureown its with package

thesigning-re from prevent not does scenario this

course, Of . ofn cooperatio he without tsoftware the

ofty authentici e verify th tounable is .party third

a it to resell and package thisof copies make todecides

who,entity it to sells and package thesigns package.

software a creates n corporatio large some Suppose (1)

B

BA

B

A

C C

BA

A

2.1 Scenarios for Undeniable Signature (Continued)

process.ion verificatsignature the

in t involvemendirect s'ithout facility w theused that

anyone todate)later some(at prove tounable is then

signature, undeniablean uses If granted. is access before

document date and timeasign torequires room.box

deposit -safety a be example,for might, area secured

The bank). (the entity by controlled area secured

a toaccessgain to wishescustomer) (the Entity (2)

AA

B

A

AB

B

A

2.2 Basic Idea

this.confirms (4)

valid.is signature theifn calculatio thisdoonly

could result. the sends andkey privateher and

number random theusingn calculatio a does (3)

. it to sends andnumber random a generates (2)

signature. a with presents (1)

B

AB

A

AB

BA

2.2 Basic Idea (Continued)

herself. with

protocol thecompletes she ifonly validis signature

s' that convinced becan result. theshown then

and , from helpany without paper,on backwards

scheme thekedeasily wor have could He random.

are numbers s' that knowt doesn' because valid,is

signature s' that convince and aroundt turn can'

Explain.

A

ACC

A

BC

ACB

2.3 Chaum-Antwerpen Scheme

. iskey private s' ); , ,( iskey public s' (4)

). (mod

compute and 1} , 2, {1, integer random aSelect (3)

(2.1). step togo then ) (mod 1 If (2.2)

). (mod compute and element random aSelect (2.1)

) modulo order with element an (Select (2)

prime. a also is where12 prime random aSelect (1)

:following thedo should entity Each

key. public

ingcorrespond andkey private a selectsentity each :SUMMARY

for generationKey

)/1(

aAypA

py

qa

p

p

pq

qq + p

A

a

qp

3 Algorithm2 Algorithm

2.3 Chaum-Antwerpen Scheme (Continued)

. if

only and if signature theaccepts and )(mod computes (5)

. tosends and )(mod computes (4)

. to sends and )(mod computes (3)

}.1 , 2, {1, ,integerssecret random selects (2)

). , ,(key public authentic s' obtains (1)

:following theis on signature s' verify tofor protocol The .

. is messageon signature s' (2)

.) (mod Compute (1)

:following thedo should Entity .

.ofn cooperatio with thesignature thecan verify entity Any . modulo

order of subgroup the tobelonging message a signs :SUMMARY

schemeAntwerpen -Chaum

21

1

21

21

ww

pmwB

B w pzwA

Az pysz B

qx xB

ypAB

msA BonVerificati

smA

pms

AgenerationSignature

ABp

qmA

xx

a

xx

a

3 Algorithm

2.3 Chaum-Antwerpen Scheme (Continued)

ion.participat s'

signer he without tsignature ofion verificata as from transcript

accept thenever should party thirda , of process

ion verificatin the exchanged messages therecords ifEven (3)

.order of subgroup cyclic in the problem logarithm discrete theof

lity intractabi on thedependent is ofsecurity The (2)

resources. nalcomputatio sadversary'

theoft independen isy probabilit this;1only is

in signature theaccepting ofy probabilit Then the ).(mod

i.e., , message afor signature s' offorgery a is thatSuppose (1)

A

sB

C

B

q

/q

B pms

mA sa

3 Algorithm

3 Algorithm

3 Algorithm

Comment. Security

2.3 Chaum-Antwerpen Scheme (Continued)

.successful is schemeon verificati

h theeven thougforgery a signature a Claim (4.3)

or y;incorrectl protocolion verificat thePerform (4.2)

; of

schemeion verificatin the eparticipat toRefuse (4.1)

.signer by the signatures Disavowing (4)

3 Algorithm

).(ContinuedComment Security

A

2.3 Chaum-Antwerpen Scheme (Continued)

. to sends and ,)(mod computes

and 1}, , 2, {1, , integerssecret random selects (5)

halts. scheme

theand signature theaccepts ,) (mod If (4)

. to sends and ) (mod)( computes (3)

. to sends and ,)(mod computes

and 1}, , 2, {1, , integerssecret random selects (2)

)., ,(key public authentic s’ obtains (1)

forgery. a is signature ewhether th

or , using s signature valida disavow toattempting

is signer he whether tdetermines scheme this:SUMMARY

schemeAntwerpen -Chaumfor scheme Disavowal

21

21

1

21

21

21

Az pysz

qxxB

sBpmw

BwpzwA

Az pysz

qxxB

ypAB

A

xx

xx

a

xx

3 Algorithm

4 Algorithm

2.3 Chaum-Antwerpen Scheme (Continued)

. signature

thedisavow toattempting is and validis signature

that theconcludes otherwise, forgery; a is that

concludes then , If .) (mod )(

and ) (mod )( computes (8)

halts. scheme theand

signature theaccepts ,) (mod If (7)

. to sends and ) (mod)( computes (6)

12

12

21

1

s

A

Bs

Bccpwc

pwcB

sBpmw

BwpzwA

xx

xx

xx

a

2.3 Chaum-Antwerpen Scheme (Continued)

.1/only is

signature) thedisavowingin succeeds hence, (and

y thatprobabilit Then the not. does but that correctly,

follows that Suppose .) (mod

i.e., ,for signature ' indeed is thatSuppose (2)

correct). isforgery a is that conclusion s’ hence,

(and then correctly, follow

and if and ,) (mod i.e., forgery, a is If (1)

q

Acc

A

Bpms

msA s

sB

ccB

Apmss

a

a

4 Algorithm

4 Algorithm

Comment. Security

2.4 Further Consideration

t.isn' shethough

even software, theofbuyer legitimate a is shethat

convinced is . on toreply thesends then he replies,

When . on toit sends then he number, random

thehim sends When . with signature thevalidates

uslysimultaneo he, with signature the validateto

tries When copy. pirated aher sells He Company.

Software s' fromsalesman a she' that convinces

Then, wants.he whenever package software on the

signature thetecan valida He copy. legal a buys (1)

CC

AA

CA

B

C

ACB

B

2.4 Further Consideration (Continued)

privacy. personalher protect tofor way a

is signatureher verifies whogControllin changed.

have gsafter thin verifiedbe even toor context, of

out verifiedandshown be press, by the verifiable

be toencecorrespond personalnot want might

She signature.her verify toable be toanyone

t wantdoesn' instancesmany in ns;applicatio

oflot a have signatures undeniable so,Even (2)

A

A

3 Digital Cash

Cash is a problem. It’s annoying to carry, it spreads germs, and people can steal it from you. Checks and credit cards have reduced the amount of physical cash flowing through society, but the complete elimination of cash is virtually impossible. It'll never happen; drug dealers and politicians would never stand for it. Checks and credit cards have an audit trail; you can’t hide to whom you gave money.

Checks and credit cards allow people to invade your privacy to a degree never before imagined. You might never stand for the police following you your entire life, but the police can watch your financial transactions. They can see where you buy your gas, where you buy your food, who you call on the telephone—all without leaving their computer terminals. People need a way to protect their anonymity in order to protect their privacy.

A great social need exists for this kind of thing. With the growing use of the Internet for commercial transactions, there is more call for network-based privacy and anonymity in business. (There are good reasons people are reluctant to send their credit card numbers over the Internet.)

3.1 Scenarios for Digital Cash

Lobbyist Alice can transfer digital cash to congress critter Bob so that newspaper reporter Eve does not know Alice's identity. Bob can then deposit that electronic money into his bank account, even though the bank has no idea who Alice is. But if Alice tries to buy cocaine with the same piece of digital cash she used to bribe Bob, she will be detected by the bank. And if Bob tries to deposit the same piece of digital cash into two different accounts, he will be detected—but Alice will remain anonymous. Sometimes this is called anonymous digital cash.

3.2 Requirements for Digital Cash

(1) Independence. The security of the digital cash is not dependent on any physical location. The cash can be transferred through computer networks.

(2) Security. The digital cash cannot be copied and reused.

(3) Privacy (Untraceability). The privacy of the user is protected; no one can trace the relationship between the user and his purchases.

3.2 Requirements for Digital Cash (Continued)

(4) Off-line payment. When a user pays for a purchase with electronic cash, meaning no communication with the central bank is needed during the transaction.

(5) Transferability. The digital cash can be transferred to other users.

(6) Divisibility. A piece of digital cash in a given amount can be subdivided into smaller pieces of cash in smaller amounts. (Of course, everything has to total up properly in the end.)

3.3 Brands’s Digital Cash Scheme We describe a system that satisfies 1 through 4.

The system is much more complicated than the centuries old system of actual coins. This is because electronic objects can be reproduced at essentially no cost, in contrast to physical cash, which has usually been rather difficult to counterfeit. Therefore, steps are needed to catch electronic cash counterfeiters. This means that something like a user’s signature needs to be attached to an electronic coin. The “restricted blind signature” is used to preserve the anonymity.

3.3.1 Architecture of Brands’s Scheme

ParticipantsBankSpenderMerchant

AlgorithmsInitializationCreating a coinSpending a coinDepositing a coin

Bank

Spender Merchant

Initialization Initialization

Initialization

Creating a coin

Spending a coin

Depositing a coin

3.3.2 Algorithms of Brands’s Scheme

. modulointeger an outputs andinput as

intergers of tuple-4 a takefirst The . modulointeger

an outputs andinput as intergers of tuple-5 a take

first Thefunctions.hash public select two Also (4)

). , ,(Publish (3)

. modulo order with , ,element an Select (2)

prime.

also is 2/)1(such that prime large a Choose (1)

:following thedo should

merchant. thespender, thebank, theauthority,

central someby once done istion Initializa :SUMMARY

tionInitializa

0

21

21

q

Hq

H

ggg

pqggg

pqp authority central Some

5 Algorithm

3.3.2 Algorithms of Brands’s Scheme (Continued)

bank.

ith theregister w and numbertion identificaan Choose (1)

:following thedo should

spender. the to)(mod)(sendsbank The (2)

spender. thegidentifyinn informatio with along storeswhich

bank, thesent to is number The ).(mod computes

and numberidentity secret its choosesspender The (1)

:following thedo should

). , ,(Publish (2)

).(mod,

, compute and numberidentity secret its Choose (1)

:following thedo should

2

1

21

2211

M

pgIz

I

IpgI

u

hhh

pghgh

gh x

x

u

xx

x

Merchant The

bank the andspender The

bank The

3.3.2 Algorithms of Brands’s Scheme (Continued)

spender. the to and sends and ),(mod)(

and computes coin),each for number

different a ( number random a choosesbank The (1)

:following thedo should

). , , , , ,( numbers of tuple-6 aby drepresente

be coin willA value.same thehave coins All account.

an fromcash classical ng withdrawiis someonewhen

asjust identity, of proof requiresbank The coin. afor

asking bank, thecontactsspender The :SUMMARY

coin a Creating

2 ww

ww

gpgI

gg

w

rbazBA

spender the and bank The

6 Algorithm

3.3.2 Algorithms of Brands’s Scheme (Continued)

account.bank ssepender' thefrom deducted

iscoin theofamount The complete. now is ),,,,,(

coin The ).(mod computesspender The (6)

spender. the

to sends and )(mod computesbank The (5)

bank. the to sends and

))(mod,,,,( computesspender The (4)

allowed.not are 1Coin with

).(mod

, , , ,)(

computesspender The )3(

)., , , ,(

intergers of tuple-5 randomsecret a choosesspender The (2)

211

11

11

212

2121

21

2121

rbazBA

qcr

cqwxcc

c

qbazBAHc

A

pAb

ggazzggBgIA

xxs

s

wsxxs

3.3.2 Algorithms of Brands’s Scheme (Continued)

spender. the to sends

and on, transacti theof timeand date thengrepresentinumber

a is where), , , ,( computesmerchant The (3)

valid.iscoin that theknowsmerchant thecase, theis thisIf

).(mod,

whetherchecksmerchant The (2)

merchant. the to) , , , , ,(coin thegivesspender The (1)

:following thedo should

). , , , , ,(coin

theusingmerchant thepaysspender The :SUMMARY

coin a Spending

0

),,,,(),,,,(

d

ttMBAHd

pbz Ahag

rbazBA

rbazBA

bazBAHrbazBAHr

merchant the andspender The

7 Algorithm

3.3.2 Algorithms of Brands’s Scheme (Continued)

it. rejectsmerchant theOtherwise,

coin. theacceptsmerchant theholds, congruence thisIf

).(mod

whetherchecksmerchant The (5)

merchant. the to and sendsspender The

).(mod ,

computesspender The (4)

2121

21

2211

pBAgg

rr

qxsdrxsudr

drr

3.3.2 Algorithms of Brands’s Scheme (Continued)

s. techniquecontrol fraud theusesbank thedeposited,

previouslybeen hasit fcredited.I isaccount smerchant' theand

validiscoin thebeen,t hasn'it If deposited. previouslybeen

not has ) , , , , ,(coin that thechecksbank The (3)

).(mod

,, checksbank The (2)

). , ,( triple

theplus ) , , , , ,(coin thesubmitsmerchant The (1)

:following thedo should

). , , , , ,(

coin sspender' thedepositsmerchant The :SUMMARY

coin a Depositing

2121

),,,,(),,,,(

21

rbazBA

pBAgg

bz Ahag

drr

rbazBA

rbazBA

drr

bazBAHrbazBAHr

bank the andmerchant The

8 Algorithm

3.3.2 Algorithms of Brands’s Scheme (Continued)

hard. is problem logarithm discrete the

since do, omerchant t for the impossibley essentiall is

This .coin twice thesubmitting riesmerchant t The (2)

hard). is problem logarithm

discrete that thebelieves (if jail sent to then is

spender The occurred. has spending double that proof

hasit otherwise,discovercannot bank theSince

spender. theidentifies and )(mod computes

bank the,coin twice thespendsspender theIf (1)

spending. doublefor s techniquecontrol Fraud

1

u

pgI u

3.3.3 Anonymity of Brands’s Scheme

spender. heidentify t

couldbank The .each toingcorrespondperson the

with along , of valueoflist a keep couldbank then the

,1 takingIf coin. for the

a calls Brands what provide and numbers The (3)

.only sees and ,number and number

only the provides merchant, by the deposited isit

before ),,,,,(coin thebank The (2)

tion.identificaany provide toneedsnever spender the

merchant, eon with th transactientire theDuring (1)

1

21

1

c

c

ccw

rbazBA

signature blind restricted

seesnever

3.3.4 Other Security Concerns of Brands’s Scheme

bank. the tosubmitted are they beforemerchant from

) , ,( and ) , , , , ,(coin thesteals Eve (5)

it. spend totries

andspender thefromcoin thesteals Someone (4)

coin. a

forge tobank tries in the workingSomeone (3)

merchant. thecoin with

thespend to triesalsobut bank, in theit deposits

andspender thefromcoin a receives Eve (2)

coin.y unauthoritan make to triesSomeone (1)

21 drrrbazBA

Thank You!