Failure Analysis of an E-commerce Protocol using Model Checking

Failur eAnalysisof an E-commerceProtocolusingModel Checking

IndrakshiRay Indrajit Ray

Departmentof ComputerandInformationScience

Universityof Michigan-Dearborn

Email:�iray, indrajit� @umich.edu

Abtract: Theincreasingpopularityof electroniccommerce(e-commerce)hasnecessitatedthedevelopment

of e-commerceprotocols.Theseprotocolsensuretheconfidentialityandintegrity of informationexchanged.

In addition,researchershaveidentifiedotherdesirableproperties,suchas,money atomicity, goodsatomicity

andvalidatedreceipt,thatmustbesatisfiedby e-commerceprotocols.This papershows how modelcheck-

ing canbeusedto obtainanassuranceabouttheexistenceof thesepropertiesin ane-commerceprotocol.It

is essentialthatthesedesirablepropertiesbesatisfied,evenin thepresenceof siteor communicationfailure.

Usingthemodelcheckerweevaluatewhichfailurescausetheviolationof oneor moreof theproperties.The

resultsof theanalysisarethenusedto proposea mechanismthathandlesthefailuresto make theprotocol

failureresilient.

Keywords: e-commerce, failureanalysis,automatedverification,modelchecking, transactionmanagement

Contact Addr ess: IndrakshiRay Email: [email protected]

Departmentof ComputerandInformationScience

Universityof Michigan-Dearborn

Dearborn,MI 48188

Phone:(313)593-1794,Fax: (313)593-9967

FailureAnalysisof anE-commerceProtocolusingModelChecking


Abstract

The increasingpopularityof electroniccommerce(e-commerce)hasnecessitatedthe development

of e-commerceprotocols. Theseprotocolsensurethe confidentialityand integrity of informationex-

changed.In addition,researchershave identifiedotherdesirableproperties,suchas,money atomicity,

goodsatomicityandvalidatedreceipt,thatmustbesatisfiedby e-commerceprotocols.Thispapershows

how modelcheckingcanbe usedto obtainan assuranceaboutthe existenceof thesepropertiesin an

e-commerceprotocol. It is essentialthat thesedesirablepropertiesbesatisfied,evenin thepresenceof

siteor communicationfailure. Usingthemodelchecker we evaluatewhich failurescausetheviolation

of oneor moreof theproperties.Theresultsof theanalysisarethenusedto proposea mechanismthat

handlesthefailuresto make theprotocolfailureresilient.

1 Intr oduction

Thegrowing popularityof theworld wide webhasresultedin an increasedinterestin e-commerce.Con-

sequentlya numberof e-commerceprotocolshave beenproposed.Most of theseprotocolsensurethat the

informationthat is exchangedbetweenthepartiesinvolved in thee-commerce,is protectedfrom unautho-

rizeddisclosureandmodification.Moreover, researchershaveidentifiedseveralotherdesirablepropertiesof

e-commerceprotocols.Examplesof thesepropertiesincludemoney atomicityandgoodsatomicity[21], and

validatedreceipt[16]. Money atomicityensuresthatmoney is neithercreatednor destroyed in thecourse

of ane-commercetransaction.Goodsatomicityensuresthatamerchantreceivespaymentif andonly if the

customerreceivestheproduct.Validatedreceiptensuresthat thecustomeris ableto verify thecontentsof

theproductaboutto be received,beforemakingthepayment.Althoughsuchpropertieshave beenidenti-

fied,a majorproblemis verifying if a givene-commerceprotocolsatisfiestheseproperties,speciallyin the

presenceof network andsite failures. In this paperwe addresstheproblemof protocolverificationusing

existing softwareverificationtechniques.In particular, we usemodelchecking[1, 9, 13, 14] to themodeny

atomicity, goodsatomicityandvalidatedreceiptpropertiesof thesecuree-commerceprotocolproposedin

[16]. In [16] theauthorshave informally shown that,in theabsenceof failures,theirprotocolhasthemoney

atomicity, goodsatomicityandvalidatedreceiptproperties.

Thereasonsfor usingmodelcheckingareasfollows. First,modelcheckingis a completelyautomated

techniqueandconsiderablyfasterthanotherapproaches,suchas,theoremproving [2, 3, 7, 15]. Second,if a

propertydoesnot hold,a counterexampleis producedby themodelchecker which helpsin understanding

why thepropertydoesnothold. Last,but nottheleast,modelcheckinghaspreviouslybeenusedsuccessfully

to verify securityprotocols[9, 10, 11, 12]. In this paperwe usetheFailureDivergenceRefinement(FDR)

modelchecker [8]. Theprotocolthatis analyzedis expressedasacommunicatingsequentialprocess(CSP)

[18], which we call SYSTEM. Eachpropertythat we wish to checkis expressedasanotherCSP process,

which we call SPEC. If SYSTEMis a refinementof SPEC(thatis, thesetof behaviors generatedby SYSTEMis

asubsetof thosegeneratedby SPEC), we caninfer thattheprotocolsatisfiestheproperty.

1 of 27


An e-commerceprotocol,beingdistributedin nature,is subjectto siteand/orcommunicationsfailures.

Are thedesirablepropertiessatisfiedin theeventof a failure? Which propertiesarevalid whensomesite

fails?Our formalanalysishelpsanswerthesequestions.Fromtheanalysiswe find that,if thereis a failure,

mostpropertiesdo not hold for the protocoldescribedin [16]. Thussomeextra mechanismneedsto be

incorporatedinto the protocolthat will ensurethe propertieseven in the faceof failure. In this paperwe

show how to extendthebasicprotocolto incorporatethesemechanismsandmaketheprotocolfault tolerant.

Briefly, our contribution is asfollows. First, we show how to modelthee-commerceprotocolandthe

desirablepropertiesin a specificationlanguage,and thenverify thesepropertiesusingan existing model

checker. Formal specificationandverificationgive an increasedassurancethat the propertiesare indeed

satisfiedby theprotocol.Second,we show how to modelsiteandcommunicationfailures.WeusetheFDR

modelchecker to identify whichfailurespreserve thepropertiesandwhichonesdonot. Finally, wepropose

a mechanismto handlethe identifiedfailuresthatdo not preserve thedesirableproperties;integratingthis

mechanismwith theprotocolensuresthat theresultingprotocolsatisfiesmoney atomicity, goodsatomicity

andvalidatedreceiptevenin thepresenceof failures.

The restof the paperis organizedasfollows. Section2 briefly describesthe basicprotocol. Section

3 describessomerelatedwork in this area. Section4 describesthe FDR modelchecker andthendiscuss

how thebasicprotocolandthedesirablepropertiescanbemodeledandverifiedby theFDR modelchecker.

Section5 describeshow thedifferentformsof failurescanbemodeledby theprotocolandillustrateswhich

propertiesgetviolatedby siteor communicationfailures.Section6 proposesthemechanismthatis incorpo-

ratedinto thebasicprotocolsothatthepropertiesarepreservedin theeventof a failure.Section7 concludes

the paperwith a brief descriptionof someof the future directionswe would like to pursue.AppendixA

givesthe full specificationin CSP of the protocolwithout failureswhile AppendixB givesthe complete

listing of theprotocolwith failures.

2 BasicProtocol

Webegin with abrief descriptionof thee-commerceprotocolof [16]. Theprotocolis designedfor electronic

transactionsinvolving digital productsandis basedon thetheoryof crossvalidationthatis proposedby the

authorsof [16]. In thatwork theauthorsdemonstrateinformally thattheirprotocolsatisfiesmoney atomicity,

goodsatomicityandvalidatedreceiptpropertiesin theabsenceof failure.

Table1 shows thedifferentstepsin theprotocol.Theprotocolworksby exchangingmessagesbetween

a customer(C), a merchant(M) anda trustedthird party(TP). ThenotationX � Y : P is usedto denote

X sendsmessageP to Y. A merchanthasseveral productsto sell. The merchantplacesa descriptionof

eachproducton anon-linecatalogservicewith the trustedthird party togetherwith anencryptedcopy of

theproduct. If thecustomeris interestedin a product,hedownloadstheencryptedversionof theproduct

(step1 in table1) andthensendsa purchaseorderto themerchant(step2). Notethat thecustomercannot

usetheproductunlesshehasdecryptedit. Now themerchantdoesnot sendthedecryptingkey unlessthe

merchantreceivespayment.Thecustomerdoesnotpayunlessheis surethatheis gettingtheright product.

This is handledasfollows: themerchantsendstheproduct(step3) encryptedwith a secondkey, K2, such

2 of 27


1. TP � C : downloadof productencryptedwith key K1

2. C � M : purchaseorder

3. M � C : productencryptedwith a secondkey K2

4. M � TP : thedecryptingkey K̂ for theproductandtheapprovedpurchaseorder

5. C � TP : thepaymenttokenandcopyof thepurchaseorder

6. TP � C : thedecryptingkey

7. TP � M : paymenttoken

Table1: MessagesExchangedin theE-commerceProtocol

that K2 bearsa particularmathematicalrelationwith the key, K1, whereK1 is the key the merchantused

whenuploadingthe encryptedproducton the trustedthird party. Additionally, the merchantescrows the

decryptionkey, K̂, correspondingto K2, with the trustedthird party (step4). The mathematicalrelation

betweenthekeys K1 andK2, is thebasisfor thetheoryof crossvalidationthathasbeenproposed(see[16]

for completedetails). Briefly the theoryof crossvalidationstatesthat theencryptedmessagescompareif

andonly if theunencryptedmessagescompare.Thus,by comparingtheencryptedproductreceived from

the merchantwith the encryptedproductthat the customerdownloadedfrom the trustedthird party, the

customercanbesurethat theproductheis aboutto payfor is indeedtheproducthewanted.At this stage

thecustomeris yet to obtaintheactualproductbecausehedoesnothavethekey, K̂, to decrypttheencrypted

product.Oncethecustomeris satisfiedwith his comparison,hesendshis paymenttoken to thethird party

(step5). Thethird partyverifiesthecustomer’s financialinformationandforwardsthedecryptingkey to the

customer(step6) andthepaymenttokento themerchant(step7).

To provide confidentiality, integrity andnon-repudiability, the messagesexchangedareappropriately

signed,encryptedand(whenrequired)sentalongwith a cryptographicchecksum.Sincewe do not focus

on thecryptographicaspectsof theprotocolin thiswork, suchdetailsareabstractedawayandnot shown in

table1.

3 RelatedWork

Lowe [10, 11, 12] have usedtheFDR modelchecker to find attackson cryptographicprotocols.Roscoeet

al. [17] have usedtheFDR modelchecker togetherwith dataindependencetechniquesto prove thatsome

securityprotocolsarefreefrom attacks.

Heintzeet al. [9] focuson the non-securityaspectsof e-commerceprotocolsandusethe FDR model

checker to verify themoney andgoodsatomicitypropertiesof two e-commerceprotocols– NetBill [4, 19]

andDigicash[5]. Theimportantcontribution of thework is thatit illustrateshow to modelthee-commerce

protocolsandthepropertiesof interestin CSP. Thiswork confirmstheclaimsthattheNetBill protocoldoes

3 of 27


have money andgoodsatomicity andprovidesa counter-exampleto illustratewhy the Digicashprotocol

doesnothave money atomicity.

Heintzeetal. [9] assumethatneithertheNetBill servernorthecommunicationlinks to theNetBill server

ever fail. The authorssubstantiatethis assumptionby arguing that banks(the NetBill server providesthe

servicesof afinancialinstituition in thiswork) provide fail-safeserviceto customersand,in theworstcase,

communicationwith thebankcanbemadepossibleusinghand-delivery. Theauthorsfurtherassumethatthe

customerand/orthemerchantdonot fail arbitrarily; if they doso,theatomicitypropertiesareviolated.The

authorsarguethat, in this case,even if theatomicitypropertiesareviolated,only the failing agentsuffers

andno harmis causedto theotherparty.

We alsousethe FDR model checker to analyzean e-commerceprotocol. However, we give a more

comprehensive treatmentof siteandcommunicationfailuresthangivenby Heintzeet al. [9]. We allow the

customer, themerchant,the trustedthird partyandthecommunicationlinks to fail arbitrarily. We propose

additionalmechanismsthatensurethatdespitefailures,thedesirablepropertiesarestill preserved. In this

regardourwork is differentfrom thework of Heintzeet al.

4 Using FDR to Verify the Propertiesof the BasicProtocol

FDR [8] is a modelchecker, basedon thetheoryof CSP, thatallows oneto checkpropertiesof finite state

systems.In CSP, processesaredescribedusingeventsandoperators.Eventscausea processto change

state. The representationof statesis implicit. A processmay be composedof componentprocessesthat

requiresynchronizationon someevents;eachcomponentmustbewilling to participatein aneventbefore

theprocesscanmake astatetransition.This is how thecomponentprocessesinteractwith eachother.

In FDR, the finite statesystemis modeledas a process,say SYSTEM, and the propertyof interestis

modeledasanotherprocess,saySPEC. If SYSTEMis a refinementof SPEC(that is, the setof the possible

behaviors of SYSTEMis a subsetof the setof possiblebehaviors of SPEC), then the propertymodeledby

SPECholds. If somepropertydoesnot hold, FDR generatesa counter-examplethat illustratesunderwhat

scenariothepropertyis violated.Thecounter-examplegeneratedis veryusefulfor analyzinganddebugging

purposes.

In thefollowing paragraphswe describehow we modelour protocol. ThecompleteFDR specification

of theprotocolis providedin theappendixes.Figure1 describestheCSP notationsusedin ourmodel.

4.1 Modeling the Communication betweenthe Processes

Thecommunicationbetweenprocessesis synchronizedin CSP. To modelasynchronouscommunicationwe

follow theapproachof Heintzeetal. [9]. A sendersendsmessagesoverauniquechannel(thesender’s “out”

channelfor aparticularreceiver)while thereceiverreceivesthemessageoveranotherchannel(thereceiver’s

“in” channelcorrespondingto aparticularsender).Thuswhentwo agentsarecommunicating,two channels

areassociatedwith eachagentfor a total of four channels.Additionally, for eachpair of channel– sender’s

“out” andreceiver’s “in” – we have aprocessthatreadsdatafrom thesender’s “out” channelandwritesthe

datainto thereceiver’s “in” channel– for a total of two processes.

4 of 27


1. a?x

Input x on channela

2. a!x

Outputx onchannela

3. {|a|}

Setof eventsassociatedwith channela

4. a -> P

Definestheprocesswaiting for eventa, aftera it behaveslike P.

5. []x:X @ a?x -> P

Definestheprocessthatacceptsany elementx of X on channela andbehaveslike P.

6. P |˜| Q

Definestheprocessthatnon-deterministicallycanbehave like eitherP or Q.

7. P [] Q

Definestheprocessthatcanbehave like eitherP or Q. However, preferenceis givento theunblockedprocess.

8. P [|{}|] Q

Definestheprocessin whichprocessesP andQ runcompletelyindependentlyof eachother.

9. P [|X|] Q

Definestheprocesswhereall eventsin X mustbesynchronizedandtheeventsoutsideX canproceedindependently.

Figure1: List of CSPNotations

5 of 27


For example,to modelthecommunicationbetweenthemerchantandthecustomerfour channels,(minc ,

coutm , cinm , moutc ) andtwo processes(COMMmcandCOMMcm) areinvolved. TheprocessCOMMmcreadsa

datafrom channelcoutm andwrites the datato channelminc andthe processCOMMcmreadsa datafrom

channelmoutc andwritesit to channelcinm . TheprocessCOMMcmis modeledin CSP asfollows:

COMMcm= []x: {po} @(coutm ?x -> (minc !x -> COMMcm))

where�po � – thepurchaseorder– is thesetof all datathatis communicateddirectly from thecustomerto

themerchant.Similarly, wehave four channelsandtwo processesfor modelingthecommunicationbetween

merchantandtrustedthirdparty–channelsmoutt , tinm , toutm andmint andprocessesCOMMmtandCOMMtm

– andanothersetof four channelsandtwo processesfor representingthecommunicationbetweencustomer

andtrustedthird party – channelscoutt , tinc , toutc andcint andprocessesCOMMctandCOMMtc. We

modeltheprocessCOMMmc,COMMmt, COMMtm, COMMct, COMMtcin amannersimilar to COMMcm.

4.2 Modeling the Customer, Merchant and the Trusted Third Party Processes

4.2.1 Modeling the Customer Process

Theprotocolstartswhenthecustomerbrowsesthecataloghostedon thetrustedthird partyanddownloads

theencryptedproductfrom there.Thedownloadingof theencryptedproductis modeledasthesendingof

theencryptedproductby thetrustedthird partyandthereceiptof theproductby thecustomer. Thus,wecan

saythat,initially thecustomerwaitsfor anencryptedproductfrom thetrustedthird party.

CUSTOMER= cint ?x -> DOWNLOADED_EGOODS(x)

Oncethe customerhasdownloadedthe product, it sendsa purchaseorder to the merchant. This is

modeledas:

DOWNLOADED_EGOODS(x) = coutm !po -> PO_SENT(x)

Thecustomerthenwaitsfor theencryptedproductfrom themerchant.Onreceiving amessagefrom the

merchant,thecustomerchecksto seeif themessageis indeedsomeencryptedproductsentby themerchant.

If so,thecustomerproceedsto thenext step,otherwiseit continuesto wait for theencryptedproduct.The

specificationfor thiseventis asfollows:

PO_SENT(x) = cinm ?y -> if (y==encryptedGoods1 or y==encryptedGoods2)

then RECEIVED_EGOODS(x,y)

else PO_SENT(x)

Thenext stepinvolvescomparingtheencryptedproductreceived from themerchantwith thosedown-

loadedfrom thethird party. If thetwo do notmatch,thecustomerterminatestheprotocol.

RECEIVED_EGOODS(x,y) = if (x==y) then RECEIVED_CORRECT_GOODS

else ABORT

6 of 27


Whenthecustomeris satisfiedwith theencryptedproduct,hesendsthepaymenttokento thethird party.

RECEIVED_CORRECT_GOODS = coutt !paymentToken -> TOKEN_SENT

After sendingthepayment,thecustomerwaitsfor amessagefrom thetrustedthird party. Thethird party

eithersendsthe customerthe key or an abortmessage,dependingon the outcomeof the protocol. Once

the customerhasreceived the messagefrom the third party, the protocolstops. Otherwisethe customer

continuesto wait for themessage.

TOKEN_SENT= cint ?y ->

if (y==key) then SUCCESS

else (if y== transactionAborted) then ABORT

else TOKEN_SENT

4.2.2 Modeling the Merchant Process

On the merchantside, the protocolbegins with the merchantwaiting to receive a purchaseorder from a

customer.

MERCHANT= minc ?x -> if (x==po) then PO_REC

else MERCHANT

The merchantin responsemustsendan encryptedproductto the customer. The merchantcanact in

two ways– eitherhesendsthecorrectencryptedproduct(denotedby encryptedGoods1 ) or an incorrect

encryptedproduct(denotedby encryptedGoods2 ). Thisnon-deterministicchoiceis modeledasfollows:

PO_REC= (moutc !encryptedGoods1 -> ENCRYPTED_GOODS_SENT) |˜|

(moutc !encryptedGoods2 -> ENCRYPTED_GOODS_SENT)

Oncethemerchanthassenttheencryptedproduct,hemustsendthedecryptionkey to thetrustedthird

party.

ENCRYPTED_GOODS_SENT = moutt !key -> KEY_SENT

After sendingthekey, themerchantwaitsto receive thepaymenttokenfrom thetrustedthird party. The

third partyeithersendsthepaymenttokenor atransactionabortmessageif thetransactionwasaborted.The

merchantprocessterminatesonceit receivesamessage,otherwiseit continuesto wait for themessage.

KEY_SENT = mint ?x -> if (x==paymentToken)

then SUCCESS

else if (x==transactionAbor te d)

then ABORT

else KEY_SENT

7 of 27


4.2.3 Modeling the Trusted Third Party

Thecustomerdownloadingtheencryptedproduct,is modeledfrom thethird party’send,asthetrustedthird

partysendingtheencryptedproductto thecustomer.

TP = toutc !encryptedGoods1 -> WAIT_TOKEN_KEY

Thenext stepinvolvesthe third partywaiting to receive thepaymenttoken from thecustomerandthe

key from themerchant.Whenthethird partyreceivesamessageit checksif themessageis apaymenttoken

or key or neither. Notethat,it is notknown whetherthekey or paymenttokenwill arrivefirst. If thepayment

tokenarrivesfirst, thethird partymustwait for thekey. On theotherhand,if thekey arrivesfirst, thethird

partymustwait for thepaymenttoken.Thisaspectof theprotocolis modeledasfollows:

WAIT_TOKEN_KEY= (tinc ?a -> if (a==paymentToken) then WAIT_KEY(a)

else WAIT_TOKEN_KEY) []

(tinm ?b -> if (b==key) then WAIT_TOKEN(b)

else WAIT_TOKEN_KEY)

WAIT_KEY(a) = tinm ?b -> if (b==key) then CHECK_TOKEN(a,b)

else WAIT_KEY(a)

WAIT_TOKEN(b) = tinc ?a -> if (a==paymentToken) then CHECK_TOKEN(a,b)

else WAIT_TOKEN(b)

Oncethe third party hasreceived both the key andthe paymenttoken, it proceedsto the next stepof

validatingthepaymenttokenwith thecustomer’s financialinstitution. Thedetailsof thevalidationprocess

is ousidethescopeof theoriginal protocoland,consequently, we omit thesestepsfrom thecurrentmodel.

Instead,themodelnon-deterministicallychoosesbetweentheoptions:(i) tokenokayor (ii) tokennotokay.

If thepaymenttokenis okay, thetrustedthird partyproceedsto sendout thekey to thecustomerandthe

token to themerchant.If thepaymenttoken is not okay anabortmessageis sentto thecustomerandthe

merchant,andtheprotocolterminates.

CHECK_TOKEN(a,b) = OK_TOKEN(a,b) |˜| NOK_TOKEN

OK_TOKEN(a,b) = SEND_TOKEN_KEY(a,b)

NOK_TOKEN= SEND_ABORT_MESSAGE

Theprocessof sendinganabortmessageto customerandmerchantis modeledby thefollowing step.

SEND_ABORT_MESSAGE= toutc !transAborted -> toutm !transAborted -> STOP

Theprocessesof sendingout thekey to thecustomerandthetokento merchantcanoccurin any order.

Thusthesendingoutof key andtokenby thetrustedthird partyis modeledasfollows.

SEND_TOKEN_KEY(a,b) = toutc !b -> SEND_TOKEN(a) |˜| toutm !a -> SEND_KEY(b)

SEND_TOKEN(a) = toutm !a -> SUCCESS

SEND_KEY(b) = toutc !b -> SUCCESS

8 of 27


4.3 Modeling the DesirableProperties

In thissectionwedescribehow wemodelthepropertiesof money atomicity, goodsatomicity, andvalidated

receipt.

4.3.1 Modeling Money Atomicity

Ourprotocoldoesnotdealwith thedetailsof how money is actuallytransferredfrom thecustomer’saccount

to themerchant’s account.Weassumethatthemerchantreceiving thevalidatedtokenis anacceptableform

of payment.Notethat,in reality theprocessis far morecomplex; themerchantprobablyhasto depositthis

tokenin a bankwhich will communicatewith thecustomer’s bankanddebitcustomer’s accountandcredit

merchant’s account.Theseissuesandthedetailsaboutmethodsof paymentswill beaddressedin a future

work.

The money atomicity propertystatesthat money is neithercreatednor destroyed in the processof an

electronictransaction.This propertyis satisfiedwhenthepaymenttoken,sentby thecustomer, is received

by themerchant.However, thepaymenttokenmaynot alwaysbereceivedby themerchant.Consider, for

example,the casewhen the paymenttoken cannotbe validatedby the third party becauseof insufficent

fundsor someothererror. In this case,thecustomerreceivesa transactionabortmessagewhich tells him

that the transactionwasabortedandthe paymenttoken wasnot forwardedto the merchant.Thusmoney

atomicity is satisfiedwhenoneof the following thingshappen:(i) thecustomersendsthe paymenttoken

andthe merchantreceives it or (ii) the customersendsthe paymenttoken andthenreceivesa transaction

abortmessage.This is modeledin CSP asfollows:

SPEC1 = STOP |˜| ((coutt.paymentTok en -> mint.paymentToken -> STOP)

[] (coutt.paymentToke n -> cint.transAborted -> STOP))

Thenext stepin theverificationof money atomicityinvolvesforming anew processcalledSYSTEM1by

combiningthemerchant,thecustomerandthetrustedthird partyprocesseswith theappropriatecommuni-

cationprocesses,andhidingall theirrelevantevents(thatis, all eventsotherthanthosespecifiedin SPEC1).

Toverify thatSYSTEM1satisfiesSPEC1weneedto checkthatSYSTEM1isafailure/divergencerefinement[18]

of SPEC1. Thischeckis doneautomaticallyby FDR, confirmingthatmoney atomicityis indeedsatisfiedby

theprotocol.

4.3.2 Modeling the GoodsAtomicity Property

Thegoodsatomicitypropertyensuresthata customerreceivestheproductif andonly if hehaspaid. Note

thatboththecorrectencryptedproductandthekey arerequiredby thecustomerin orderto gettheproduct.

Thusin our model,theproductcomprisesboththecorrectencryptedproductandthekey. Thepaymentis

madein theform of a token.Themerchantreceiving thetokensufficesasthecustomerhaving paid.

In theprotocol,thecustomermayreceive thecorrectencryptedproductfrom themerchant(denotedby

encryptedGoods1 ) or someincorrectone(denotedby encryptedGoods2 ). Thegoodsatomicityproperty

requiresoneof thefollowing thingsto happen:(i) thecustomerreceivesboththecorrectencryptedproduct

9 of 27


andthe keys andthemerchantreceivesthe token,or (ii) thecustomerreceivesjust the encryptedproduct

andneitherthemerchantgetsthepaymenttokennor thecustomerthekeys. For (i), notethat thecustomer

mayreceive thekey beforethemerchantreceivesthepaymenttokenor vice-versa.Thusgoodsatomicityis

specifiedasfollows:

SPEC2 = STOP |˜| ((cinm.encryptedGo ods 1 -> STOP) []

(cinm.encryptedGoo ds2 -> STOP) []

(cinm.encryptedGoods 1 -> cint.key -> mint.paymentToken -> STOP) []

(cinm.encryptedGood s1 -> mint.paymentToken -> cint.key -> STOP))

We createanotherprocesscalledSYSTEM2by combiningthe customer, merchant,third party andthe

communicationprocessesandhiding theunrelatedevents(theeventsnot associatedwith thespecification

of the goodsatomicity property). FDR proves that SPEC2 is a failure divergencerefinementof SYSTEM2

confirmingthattheprotocoldoesindeedhave goodsatomicity.

4.3.3 Modeling the Validated ReceiptProperty

The validatedreceiptpropertyensuresthat the customermakesthe paymentonly after he is satisfiedthat

theproductheis aboutto receive is theonethatheis payingfor.

In otherwords,thevalidatedreceiptpropertyensuresoneof the following thingshappen:(i) thecus-

tomerreceivessomeencryptedproductanddoesnotmakepayment(eitherbecausehehasreceivedincorrect

productor decidesnot to purchasetheproduct),or (ii) thecustomermakesthepaymentafterreceiving the

correctencryptedproduct.This is modeledasfollows:



(cinm.encryptedGoo ds1 -> coutt.paymentToken -> STOP))

Next we createa processSYSTEM3by combiningtheprocessesof themerchant,customer, third partyand

the communicationsprocessesanduseFDR to checkthat SYSTEM3is a failure divergencerefinementof

SPEC3. In thismannerweareensuredthattheprotocolalsohasthevalidatedreceiptproperty.

5 Detectingthe Violation of Propertiesin the Presenceof Failur es

Our protocol is not resilient to failures. If we allow the merchant,the customer, the third party and the

communicationmediumto fail arbitrarily, thepropertiesgetviolated.However therealsoexist someother

failuresthathavenoeffectontheproperties.In orderto build afailureresilientprotocol,weneedto identify

which failuresresultin thedestructionof theproperties.Themodelchecker aidsus in this process.In the

following paragraphswedescribehow wedetectthefailuresthatdonotpreserve thedesirablepropertiesof

money atomicity, goodsatomicity, andvalidatedreceipt.

10 of 27


5.1 Intr oducing Unreliability over the Communication Medium

Theprotocolgivenin AppendixA assumesthatthechannelsthroughwhich themerchant,customerandthe

third partycommunicatearereliable. In otherwords,any datasendby onepartyto anotherwill eventually

bereceivedby thesecondpartyandis not lost in transmission.

Recallfrom Section4.1thattheprocessmodelingthereliablecommunicationchannelthattransfersdata

from thecustomerto themerchantis givenby:


In an unreliablechannelthe datamay get lost. That is, datatransmittedby the customermay not be

received by themerchant.Soafter theeventof thecustomertransmittingthedata,oneof two thingsmay

happen:(i) thedatais lost or (ii) themerchantreceivesthedata. Note that thechoiceof what is going to

happenis notknown andhappensnon-deterministically. Thustheunreliablechannelis modeledasfollows:

COMMcm= []x: {po} DATAcm @(coutm ?x -> (COMMcm|˜| (minc !x -> COMMcm)))

With this modification,we recheckthe propertiesusingFDR. It turnsout that this unreliablechannel

hasno effect on the property. Incrementallywe introduceunreliability in the otherchannelsaswell and

testwhetherthepropertiesarepreserved.Ourexperimentsindicatethatthepropertiesareviolatedwhenthe

following channelsaremadeunreliable:(i) thechannelsconnectingthethird partyandthecustomerand(ii)

thoseconnectingthethird partyto themerchant.

5.2 Intr oducing Failur e in the Customer, Merchant and Trusted Third Party Processes

Theprotocolgivenin AppendixA, doesnot,in general,allow thecustomer, merchantandthird partyprocess

to abort.Now supposewe allow theseprocessesto abortarbitrarily, will thepropertiesstill hold?

5.2.1 Intr oducing Failuresin the CustomerProcess

First, let us considerthe customerprocessgiven in AppendixA. We allow the customerprocessto abort

only if he is not satisfiedwith the encryptedproducthe received. However, we believe that the customer

shouldbeableto abortat certainotherpointsin theprotocol,withoutputtingtheprotocolto risk.

As anexample,considerthefirst stepfor thecustomerprocess:


Supposewe allow the customerto abort in this step(eitherwillfully or becauseof a systemcrash). The

questionthen is, doesany propertyget violated? To find out, we needto model the possibility of the

customerabortingin thefirst step:

CUSTOMER= ABORT |˜| (cint ?x -> DOWNLOADED_EGOODS(x))

11 of 27


The above specificationsaysthat the customermay abort or wait for the downloadingof the encrypted

productin a non-deterministicmanner. After makingtheabove alterationto thecustomerprocess,we use

FDR to checkfor thesatisfactionof theproperties.As expected,thecustomerabortingin thefirst step,has

no effecton theproperties.

Similarly, wemakemodificationsto thespecificationto allow thecustomerprocessto abortin its second

step(that is, thecustomersendingthepurchaseorder)andchecktheproperties.The modificationsto the

secondstepalsodoesnot result in theviolation of theproperties.We make similar modificationsto each

stepin thecustomerprocessandcheckfor theviolationof theproperties.

Our resultsindicatethat suchmodificationto any step,exceptin the last stepof thecustomerprocess

(that is after thecustomerhassentthepaymenttoken),preservesall theproperties.Allowing thecustomer

to abort in the last stepviolatesboth money atomicity andgoodsatomicity. To illustratehow the money

atomicitypropertyis violated,weusetheFDR debuggerwhichgeneratesthefollowing sequenceof events.

toutc.encryptedGoo ds1 , cint.encryptedGoo ds1 , coutm.po, minc.po, moutc.encryptedGoo ds 1,

moutt.key, tinm.key, cinm.encryptedGoods 1, coutt.paymentToken, tinc.paymentToken,

toutc.transAborted , toutm.transAborted , mint.transAborted

Theabove sequencetells us that the following actionsareexecuted.Thecustomerdownloadstheen-

cryptedproductfrom thethird party, thensendsapurchaseorderto themerchant.Onreceiving thepurchase

order, the merchantsendsthe encryptedproductto thecustomerandthe key to the third party. The third

party receives the key. The customerreceives the encryptedproductandvalidatesit. The customerthen

sendsthepaymenttokento thethird party. At thispoint, it appearsthatthecustomerabortssincewe donot

seeany moremessagessentor receivedby thecustomer. Thethird partyreceivesthekey from themerchant,

thepaymenttokenfrom thecustomer, andthenvalidatesthetoken.Thetokenturnsout to beinvalid andan

abortmessageis sentby thethird partyto thecustomerandthemerchant.Sincethecustomerhasabortedin

themeantime,hedoesnot get thetransactionabortmessagefrom thethird party. Themerchant,however,

receivestheabortmessage.In theabovescenario,thecustomersendsout thepaymenttoken,but neitherthe

merchantreceivedthepaymenttokennor thecustomerthetransactionabortmessage.Thusmoney atomic-

ity is violated.Similarly, acounterexampleis generatedillustratinghow goodsatomicitywasviolated.For

thesake of brevity, we omit this counterexamplefrom thepaper.

Thus,our conclusionis that,thecustomercannotabortaftersendingout thepaymenttokenandbefore

receiving the key; if the customerdoesindeedabort we will no longer have money atomicity or goods

atomicity.

5.2.2 Intr oducing Failuresin the Merchant Process

Next, we considerthemerchantprocess.Like thecustomerprocess,themerchantprocesscanabortin its

first two stepswithout violating theproperties.Allowing themerchantto abortin its third step,that is after

themerchanthassentthekey to thetrustedthird partyresultsin theviolationof money atomicityproperty.

Thecounter-examplegeneratedby FDR is asfollows.

toutc.encryptedGoo ds1 , cint.encryptedGoo ds1 , coutm.po, minc.po, moutc.encryptedGoo ds 1,

cinm.encryptedGood s1, coutt.paymentToken

12 of 27


Theabove traceindicatesthat thefollowing actionswereexecuted:Thecustomerdownloadedtheen-

cryptedproductfrom the third party, andthensendsthepurchaseorderto themerchant.Themerchantin

responsesendsthe encryptedproductto the customer. The customer, after receiving the encryptedprod-

uct, sendsthepaymenttoken. Thenit waits for a responsefrom thethird party. Themerchantabortsafter

sendingthe encryptedproductto the customer. The third party hasreceived the paymenttoken from the

customerandis awaiting the key from the merchantwho hasalreadyaborted.Thus, in this case,neither

themerchantreceivesthepaymenttoken nor thecustomer, theabortmessage.Hencemoney atomicity is

violated.

A minor modificationto theprotocolhandlesthis problem. The third partyassociatesa timeoutevent

whenwaiting for responsesfrom customeror merchant.If thethird partyis waiting for a longtime,thetime

outeventoccursandit sendsanabortmessageto thecustomerandmerchant.

WAIT_KEY(a) = (tinm ?b -> if (b==key) then CHECK_TOKEN(a,b)

else WAIT_KEY(a))

[] (timeOut -> SEND_ABORT_MESSAGE)

WAIT_TOKEN(b) = (tinc ?a -> if (a==paymentToken) then CHECK_TOKEN(a,b)

else WAIT_TOKEN(b))


Theabove modificationto thethird partyprocessallows themerchantto unilaterallyabortin thethird step

without violatingmoney atomicity.

However, allowing themerchantprocessto abortin thelaststep,thatis, aftersendingthekey but before

receiving thepaymenttoken,violatesbothmoney atomicityandgoodsatomicity.

5.2.3 Intr oducing Failuresin the Trusted Third Party Process

Finally, we considerthe third partyprocess.The third partyprocesscanabortonly at its first step. In the

restof theprotocol,thethird partymustbeup andrunning.Notethat thetrustedthird party is providing a

serviceto its clients(customerandmerchant)andsothis is notanunrealisticdemandon thethird party.

6 Ensuring Failur e Resilenceof the Protocol

Fromtheabove discussionwe cansummarizethat

1. The customercannotabort(for any reason)after he hassentthe paymenttoken to the trustedthird

party.

2. Themerchantcannotabort(for any reason)afterhehassenttheproductdecryptionkey to thetrusted

third party.

3. Thetrustedthird partycannotabortunilaterallyafterits first step.

13 of 27


Note that the customer(merchant)will never make a consciousdecisionto abort after sendingout

the paymenttoken (after sendingout the productdecryptionkey) asthis is detrimentalto the customer’s

(merchant’s) interests.However, systemfailuresmaycausethecustomer(merchant)to abort. In this case,

after systemrecovery, the customer(merchant)shouldbe able to continuewith the restof the protocol;

thatis, thecustomer(merchant)shouldbeableto receive theproductdecryptionkey (paymenttoken)from

the trustedthird party. Note that this is equallytrue for communicationlink failure betweenthecustomer

(merchant)andthetrustedthird partyor failureof thetrustedthird partyitself.

To ensurethatthee-commerceprotocolis resilientto failuresweproposethefollowing extensionto the

basicprotocol.We assumethateachparty involved in thetransaction,keepsa copy of theinformationthat

it sendsto anotherparty– for examplepurchaseorder, paymenttokenandsoon – in its stablestoragetill

suchtime astheinformationis no longerneeded.Writes to thestablestorageareatomicanddurableuntil

intentionallypurged.

1. The customer, the merchantandthe trustedthird party usesa system-wideuniqueidentifier, Ti , to

denotethecurrente-commercetransaction.Theidentifieris a tupleof theform � PID � C � M � , where

PID is theidentifier for theproductthecustomer, C purchasesfrom themerchant,M. Thecustomer

storesa log recordof the form � Ti � INITIATE � to its stablestorageandthensendsthe purchase

orderto themerchant.

2. Whenthemerchantreceivesthepurchaseorder,it writesa log record � Ti � INITIATE � to its stable

storage;thenthe merchantchecksto seeif the purchaseorder is to its satisfaction. If it is not, the

merchantwritesanabortrecordin its log – � Ti � ABORT � andabortsthetransaction.It informsthe

customerof this decision.Otherwiseit sendstheencryptedproductto thecustomerandtheproduct

decryptionkey and the approved purchaseorder to the trustedthird party. Finally, it writes a log

recordto its stablestorageof theform � Ti � KEY � SENT � . At this stagethemerchantentersapoint

of no return;it cannotabortunilaterally.

3. After receiving a messagefrom themerchantthecustomerchecksto seeif it is anabortmessageor

theencryptedproduct.If it is anabort,thecustomerabortsthetransactionandwritesa log recordof

the form � Ti � ABORT � . Otherwisethecustomervalidatesthe encryptedproduct. If validated,the

customersendsthepaymenttokenandpurchaseorderto thetrustedthird partyandthenwritesa log

recordto its stablestorage.Thelog recordis of theform � Ti � PAYMENT � SENT � . This is thepoint

of noreturnfor thecustomer. If theencryptedproductis notvalidatedthecustomercaneitherrequest

theproductfrom themerchant,or abortthetransaction.

4. Oneof themessages- eitherthemessagecontainingthepaymenttokenandpurchaseorderfrom the

customeror themessagecontainingtheproductdecryptionkey andapprovedpurchaseorderfrom the

merchant- will arrive at thetrustedthird partybeforetheothermessage.On receiving themessage,

the trustedthird party associatesthe uniqueidentifier Ti to this currenttransactionandwrites a log

recordto its stablestorageof theform � Ti � INITIATE � . Thethird partystartsa timer at this point.

If the third party doesnot receive theothermessagebeforethe timer expires,it writesa log record

� Ti � ABORT � andsendsabortmessagesto boththecustomerandthemerchant

14 of 27


5. After receiving the paymenttoken from the customer, the third party validatesthe token with the

customer’sfinancialinstitution. If thevalidationfails thethird partywritesalog record � Ti � ABORT �andinformsboth thecustomerandthemerchant.Otherwise,after the third party hasreceived both

– the productdecryptionkey from the merchantand the paymenttoken from the customer– the

third party sendsthe paymenttoken to the merchantand writes a log record � Ti � PAYMENT �FORWARDED � , andsendsthedecryptionkey to thecustomerandwritesa log record � Ti � KEY �FORWARDED � .

6. After thecustomerreceivestheproductdecryptionkey from the trustedthird partyandsuccessfully

decryptstheproduct,thecustomerwritesthelog record � Ti � FINISH � . At this timethecustomercan

remove themessagesit sentto theotherpartiesfrom its stablestorage.

7. The merchantalsowritesa log record � Ti � FINISH � , after it hasreceived thepaymenttoken from

thetrustedthird party. At this stagethemerchantcanalsoremove copiesof themessagesthat it sent

to otherparties,from its stablestorage.

6.1 Protocol Failur eAnalysis

Letusconsidereachof thepossiblefailurescenariosindividually andseewhy theprotocolis failureresilient.

Recallthatwe areinterestedin thecasesafterthecustomerhassentthepaymenttokenor themerchanthas

senttheproductdecryptionkey.

1. Merchant fails after sendingproduct decryption key but before writing log record � Ti � KEY �SENT � . After recovery from failure the merchantfinds from its log that Ti hasbeeninitiated but

theproductdecryptionkey hasnot beensentout (no informationaboutthekey having beensentis

recorded).Consequently, it queriesthe third party to find out the status. If the statusis abort, the

merchantaborts.If thetrustedthird partyhasnot receivedthekey, themerchantresendsthekey and

write theappropriaterecord. If the trustedthird partycannotprovide a status,themerchantresends

theencryptedproductto thecustomer, andthekey andapproved purchaseorderto the trustedthird

partyandwritestheappropriatelog records.It thenwaitsfor thepaymenttokenfrom thetrustedthird

party. Finally, asa resultof the statusquerythe merchantmay receive the paymenttoken. It then

finishesby writing theappropriatelog record.

2. Merchant fails after writing log record � Ti � KEY � SENT � . After recovery from failure, the

merchantfinds that it hasnot received the paymenttoken. It asksthe third party for the payment

token. Thethird party respondseitherby sendingthepaymenttokenor anabortmessage.If it is an

abortmessage,themerchantwrite � Ti � ABORT � in its stablestorageandabortsthe transaction.If

paymenttokenis receivedthemerchantwrites � Ti � FINISH � to log.

3. Merchant fails beforewriting � Ti � FINISH � . After recovery, merchantassumesthatpaymenttoken

hasnotbeenreceived.This is thenequivalentto thescenariomerchantfailing afterwriting log record

� Ti � KEY � SENT � .

15 of 27


4. Customer fails after sendingpayment token but before writing log record � Ti � PAYMENT �SENT � . After recovery, thecustomernotesfrom log thatTi hasbeeninitiatedbut nootherinformation

(suchas,informationabouttheproductreceived or paymenttoken sent)is recordedin the log. The

customer, in this case,getsin touchwith themerchantandasksfor theproduct.Themerchanteither

sendstheencryptedproductor anabortmessage.If thecustomerreceivestheencryptedproduct,the

customervalidatesit, sendsthepaymenttokenandwritestheappropriatelog record.

5. Customer fails after writing log record � Ti � PAYMENT � SENT � . After recovery thecustomer

notesthat the decryptionkey hasnot beenreceived. So it requeststhe trustedthird party for the

productdecryptionkey. Thetrustedthird partrespondswith eitheranabortmessageor thedecryption

key. If it is an abortmessage,the customerwrites � Ti � ABORT � to its log andaborts. If it is the

decryptionkey, thecustomerwrites � Ti � FINISH � to thelog andfinishes.

6. Customer fails before writing � Ti � FINISH � . After recovery, customerassumesthat it hasnot

receivedtheproductdecryptionkey from thetrustedthird party. Thisis thenequivalentto thescenario

customerfailing afterwriting log record � Ti � PAYMENT � SENT � .

7. Trusted third party fails beforewriting log record � Ti � INITIATE � . At thisstagethetrustedthird

party is not awareof the transactionTi. Consequentlythe trustedthird partydoesnothing. At some

point of time eitherthecustomeror themerchantwill get in touchaskingfor theproductdecryption

key or a statusquery. At this stagethetrustedthird partywill write thelog record � Ti � INITIATE �andaskthe customerfor the paymenttoken andpurchaseorder, andthe merchantfor the product

decryptionkey andtheapprovedpurchaseorder. It thenstartsthetimer.

8. Trusted third party fails after writing � Ti � INITIATE � . After recovery the trustedthird party

notesthatTi hasbeeninitiated. It asksthecustomerfor thepaymenttoken andpurchaseorder, and

the merchantfor theproductdecryptionkey andtheapproved purchaseorder. Oncethe third party

hasreceiveda responsefrom thecustomeror themerchant,it startsthetimer andwaitsfor theother

message.

9. Trusted third party fails before writing either log records � Ti � PAYMENT � FORWARDED �or � Ti � KEY � FORWARDED � . This the samescenarioas the third party failing after writing

� Ti � INITIATE � . Soit will take thestepscorrespondingto thissituation.

10. Trusted third party fails after writing oneof the records � Ti � PAYMENT � FORWARDED � or

� Ti � KEY � FORWARDED � but before writing the other. After recovery thethird partysendsthe

messagethatwasnot sentoutprior to failureandwritestheappropriaterecord.

6.2 Discussion

In themodifiedprotocolwe have assumedthatthetrustedthird partykeepsindefinitely, acopy of all infor-

mationexchangedwith itself duringthetransaction,aswell asthelog recordsit writesduringthetransaction.

16 of 27


On the otherhand,the customerandthe merchantareableto discardsuchmessagesafter eachhaswrit-

ten the � Ti � FINISH � recordin its log. The trustedthird party is requiredto keepthis messagesbecause

the customerand the merchantdo not communicateto the third party the successfulcompletionof their

respective portionsof thetransaction.This approachhastwo advantages:

1. it reducesthenumberof messagesexchangedin theprotocol,and

2. it reducestheinvolvementof thetrustedthird partyin theprotocol.

However, in practice,it will not bepossiblefor thethird partyto storecopiesof all messagesexchangedin

suchtransactionsfor anindefiniteperiodof time.

Thisproblemcanbesolvedin anumberof ways.

Approach1: Onesolutionis that the third partykeepsa recordof thetransactionsfor a specifiedamount

of timewhich is known to thecustomerandthemerchant.For thethird partyto respondto thequeries

of thecustomer(merchant)regardingthetransaction,thecustomer(merchant)mustplacethequery

within thespecifiedtimeperiod.

Approach2: After thecustomerhaswritten thelog record � Ti � FINISH � , thecustomersendsaacknowl-

edgmentto the trustedthird party. On receiving this messagethe trustedthird party writes a log

record � Ti � CUSTOMER � ACK � . Themerchantalsodoeslikewiseandthetrustedthird partywrites

� Ti � MERCHANT � ACK � in its log. After both recordshave beenwritten, the trustedthird party

discardscopiesof themessages.

If thetrustedthird partyfails beforereceiving oneor bothacknowledgments,it will askthecustomer

and/orthemerchantaboutthestatusof transactionTi at therespective sides.

Approach3: Whenthetrustedthird party is readyto expungetransactionmessagesit approachesthecus-

tomerandthemerchantfor thestatusof transactionTi attheirrespectivesides.Dependingonthestatus

thetrustedthird partywritesthelog records� Ti � CUSTOMER � ACK � and/or � Ti � MERCHANT �ACK � . After bothrecordshave beenwritten, thetrustedthird partydiscardscopiesof themessages.

Notethat,bothapproach2 and3 requiretheprotocolto beaugmentedby anextra roundof messages.

7 Conclusionand Futur e Work

In this paperwe have illustratedhow model checkingcanbe usedto get assurancethat an e-commerce

protocoldoessatisfythe propertiesof money atomicity, goodsatomicity, andvalidatedreceipt. We have

alsoshown how modelcheckingcanbe usedto detectviolation of propertiesin the presenceof site and

communicationfailures.Usingtheanalysis,weproposedamechanismthatpreservesthepropertiesevenin

theeventof sitesor communicationsfailures.

A numberof issuesstill remainto be investigated. In this paperour focus was on the non-security

aspectsof thee-commerceprotocol. In futurewe planto investigatethesecurityissuesof thee-commerce

protocolusingmodelchecking.Specifically, weneedto investigatewhetherourprotocolis proneto attacks.

17 of 27


This paperconsidereda singlerun of the protocol involving onemerchantandonecustomer. In real

life, a numberor merchantsandcustomerswill beexecutingtheprotocol,concurrently. We planto model

multiple runsof the protocolusingmultiple merchantsandcustomersandseewhetherpropertieshold or

not. Wealsoplanto investigatethesecurityissuesinvolvedin multiple runsof theprotocol.

In this protocol,we assumethat thecustomerprovidesthe third partywith a paymenttokenwho vali-

datesit andthenforwardsit to themerchant.However, in reality, theprocessis morecomplex. For example,

thecustomer’s bankandthemerchant’s bankmayalsobeinvolved andeachof theseentitiesandthecom-

municationchannelsareproneto failures. We needto model theseaspectsin detailsandverify whether

money atomicityholdsor not in this scenario.Wealsoneedto investigatehow themany differentformsof

electronicpaymentschemesthatareavailabletoday[6, 20] canbe incorporatedinto our protocolandthe

resultingsolutionsbeverifiedfor theexistenceof theproperties.

In future, we plan to improve uponthe basicprotocol. Onesuchimprovementinvolves reducingthe

involvementof the trustedthird party. Not only is theperformanceof the trustedthird party an issue,but

also its vulnerability to denial of serviceattacks. We plan to investigatetwo approachesto reducethis

problem.Thefirst approachinvolvesmodifying theprotocolto reducetheinteractionswith thethird party.

Thesecondapproachinvolvesdistributing themultiple rolesplayedby thetrustedthird partyoveranumber

of (possibly)semi-trustedthird party.

References

[1] J. M. Atlee andJ. D. Gannon.State-basedModel Checkingof EventDrivenSystemsRequirements.

IEEE TransactionsonSoftware Engineering, 19(1):13–23,January1993.

[2] D. Bolignano. An Approachto the FormalVerificationof CryptographicProtocols. In Proceedings

of the 3rd ACM Conferenceon Computerand CommunicationsSecurity, New Delhi, India, pages

106–118.ACM Press,March1996.

[3] D. Bolignano.TowardstheFormalVerificationof ElectronicCommerceProtocols.In Proceedingsof

the10thIEEE ComputerSecurityFoundationsWorkshop, June1997.

[4] B. Cox, J. D. Tygar, andM. Sirbu. NetBill SecurityandTransactionProtocol. In Proceedingsof the

FirstUSENIXWorkshopin Electronic Commerce, pages77–88,July 1995.

[5] A. Fiat D. ChaumandM. Naor. ”untraceableelectroniccash”. In Advancesin Cryptology – Proceed-

ingsof CRYPTO ’88, pages200–212.Springer-Verlag,1990.

[6] S.Dukach.SNPP:A SimpleNetwork PaymentProtocol.Technicalreport,MIT Laboratoryfor Com-

puterScience,1992.Availablefrom ftp://ana.lcs.mit.ed u/ pub /sn pp/ sn pp- paper .ps .

[7] B. DutertreandS.Schneider. Usinga PVSEmbeddingof CSPto Verify AuthenticationProtocols.In

TheoremProving in Higher OrderLogics, volume1275of Lecture Notesin ComputerScience, pages

121–136.Springer-Verlag,1997.

18 of 27


[8] Formal Systems(Europe)Ltd. Failure DivergenceRefinement- FDR2 User Manual, version2.64

edition,August1999.

[9] N. Heintze,J. Tygar, J. Wing, andH. Wong. Model CheckingElectronicCommerceProtocols. In

Proceedingsof the2ndUSENIXWorkshopin Electronic Commerce, pages146–164,November1996.

[10] G. Lowe. BreakingandFixing theNeedham-SchroederPublic-key ProtocolUsingFDR. In Toolsand

Algorithmsfor theConstructionandAnalysisof Systems:SecondInternationalWorkshop,TACAS96

, pages147–166,1996.

[11] G. Lowe. SomeNew AttacksUponSecurityProtocols.In Proceedingsof the1996IEEE Computer

SecurityFoundationsWorkshop. IEEE ComputerSocietyPress,1996.

[12] G. Lowe andA. W. Roscoe.UsingCSPto detecterrorsin theTMN protocol. IEEE Transactionson

Software Engineering, 23:659–669,1997.

[13] W. Marrero,E. Clarke,andS.Jha.A Model Checker for AuthenticationProtocols.In Proceedingsof

theDIMACSWorkshopon DesignandFormal Verificationof SecurityProtocols. RutgersUniversity,

NJ,September1997.

[14] J.Mitchell, M. Mitchell, andU. Stern.AutomatedAnalysisof CryptographicProtocolsUsingMurphi.

In Proceedingsof theIEEESymposiumon SecurityandPrivacy, Oakland,CA, pages141–151,1997.

[15] L. C. Paulson. Proving Propertiesof SecurityProtocolsby Induction. TechnicalReportTR409-lcp,

ComputerLaboratory, University of Cambridge,December1996. Availablefrom http://www.cl.

cam.ac.uk/ftp/paper s/ rep ort s/ .

[16] I. Ray, I. Ray, andN. Narasimhamurthy. A Fair-ExchangeProtocolwith AutomatedDisputeResolu-

tion. Technicalreport,Universityof Michigan-Dearborn,1999.Submittedfor publication.

[17] A. W. Roscoe.Proving SecurityProtocolswith Model Checkersby DataIndependenceTechniques.

In Proceedingsof the1998IEEE ComputerSecurityFoundationsWorkshop. IEEE ComputerSociety

Press,1998.

[18] A. W. Roscoe.TheTheoryandPracticeof Concurrency. PrenticeHall, GreatBritain, 1998.

[19] M. Sirbu andJ. D. Tygar. NetBill: An InternetCommerceSystemOptimizedfor Network Delivered

Services.IEEE PersonalCommunications, pages34–39,August1995.

[20] L. H. Stein,E. A. Stefferud,N. S. Borenstein,andM. T. Rose.TheGreenCommerceModel. Tech-

nical report,First Virtual HoldingsIncorporated,1994. Availablefrom http://www.fv.com/t ech /

green- model.html .

[21] J.D. Tygar. Atomicity in ElectronicCommerce.In Proceedingsof the15thAnnualACM Symposium

on Principlesof DistributedComputing, pages8–26,May 1996.

19 of 27


Appendix A – Initial Specificationof the Protocol

-- This is the first specification of the protocol that

-- verifies money atomicity, goods atomicity and validated receipt

-- The protocol assumes that the merchant, customer or the

-- trusted third party processes do not abort at any step

-- in the protocol. Further it assumes that communication

-- channels are reliable.

datatype KEY = key

datatype MESSAGE= transAborted

datatype PO = po

datatype ENCRYPTEDGOODS= encryptedGoods1|e ncr ypt edGoods2

datatype TOKEN = paymentToken

-- Channel declarations

channel coutm : {po}

channel moutc : {encryptedGoods1,en cry pt edGoods2}

channel moutt : {key}

channel toutc : {key,encryptedGoods 1,e nc ryp ted Goods 2,t ran sAbor ted }

channel toutm : {paymentToken,trans Abort ed}

channel minc : {po}

channel tinc : {paymentToken}

channel cinm : {encryptedGoods1, enc ryp te dGoods 2}

channel tinm : {key}

channel cint : {key,encryptedGoo ds1 ,en cr ypt edGoods2 ,tr ans Abort ed}

channel mint : {paymentToken,tra nsAbor te d}

channel coutt : {paymentToken }

-- The customer process


DOWNLOADED_EGOODS(x) = coutm !po -> PO_SENT(x)

PO_SENT(x) = cinm ?y -> if (y==encryptedGoods1 or y==encryptedGoods2)


else PO_SENT(x)

20 of 27


RECEIVED_EGOODS(x,y) = if (x==y) then RECEIVED_CORRECT_GOODS

else ABORT

RECEIVED_CORRECT_GOODS = coutt !paymentToken -> TOKEN_SENT



else if (y==transAborted) then ABORT

else TOKEN_SENT

--The merchant process

MERCHANT= minc ?x -> if (x==po) then PO_REC

else MERCHANT

PO_REC= (moutc !encryptedGoods1 -> ENCRYPTED_GOODS_SENT) |˜|


ENCRYPTED_GOODS_SENT = moutt !key -> KEY_SENT

KEY_SENT = mint ?x -> if (x== paymentToken) then SUCCESS

else if (x== transAborted) then ABORT

else KEY_SENT

--The Trusted Third Party Process

TP = toutc !encryptedGoods1 -> WAIT_TOKEN_KEY


else WAIT_TOKEN_KEY) |˜|



WAIT_KEY(a) = tinm ?b -> if (b==key) then CHECK_TOKEN(a,b)

else WAIT_KEY(a)

WAIT_TOKEN(b) = tinc ?a -> if (a==paymentToken) then CHECK_TOKEN(a,b)

21 of 27


else WAIT_TOKEN(b)








SUCCESS= STOP

ABORT = STOP


COMMct = []x: {paymentToken} @(coutt ?x -> (tinc !x -> COMMct))

COMMmc= []x: {encryptedGoods1,e ncr ypt edGoods2 } @(moutc ?x

-> (cinm !x -> COMMmc))

COMMmt= []x: {key} @(moutt ?x -> (tinm !x -> COMMmt))

COMMtc = []x: {key,encryptedGood s1, enc ry pte dGoods 2, tra nsAbor te d} @(toutc ?x

-> (cint !x -> COMMtc))

COMMtm= []x: {paymentToken,tran sAbort ed}@(tou tm ?x -> (mint !x -> COMMtm))

COMM= (((( COMMct [|{}|] COMMmt) [|{}|]

COMMtc) [|{}|] COMMtm) [|{}|] COMMcm)[|{}|] COMMmc

CIO = {| coutm, coutt, cinm, cint |}

MIO = {| moutt, moutc, minc, mint |}

TIO = {| toutm, toutc, tinm, tinc |}

COMMIO= union(CIO, union (MIO, TIO))

22 of 27


SYSTEM1= (((CUSTOMER [|{}|] MERCHANT)[|{}|] TP) [|COMMIO|] COMM)\

diff(COMMIO,{coutt .p ayment Token,ci nt. tra ns Aborte d, mint.paymentToken})


diff(COMMIO,{cinm.e nc ryp ted Goods 1,c int .ke y, min t.p aymentTo ken })


diff(COMMIO,{cinm. enc ryp ted Goods 1,c inm .e ncr ypt edGoods2 ,co utt .p ayment Token})

-- This is the money atomicity property

SPEC1 = STOP |˜| ((coutt.paymentTok en -> mint.paymentToken -> STOP)

[] (coutt.paymentToke n -> cint.transAborted -> STOP))

-- This is the goods atomicity property

SPEC2 = STOP |˜|

((cinm.encryptedGoo ds1 -> STOP) [] (cinm.encryptedGo ods 2 -> STOP)

[] ( cinm.encryptedGood s1 -> cint.key -> mint.paymentToken -> STOP)

[] ( cinm.encryptedGood s1 -> mint.paymentToken -> cint.key -> STOP))

-- This is the validated receipt property

SPEC3 = STOP |˜|

((cinm.encryptedGo ods 2 -> STOP) [] (cinm.encryptedGood s1 -> STOP) []

(cinm.encryptedGoods 1 -> coutt.paymentToken -> STOP))

23 of 27


Appendix B – Specificationwith the Intr oduction of Failur es

-- This is the modified specification of the protocol that

-- assures money atomicity, goods atomicity and validated receipt

-- in the face of failures.

datatype KEY = key

datatype PO = po

datatype EGOODS= encryptedGoods1|encr yp ted Goods2

datatype TOKEN = paymentToken

datatype MESSAGE= transAborted

-- Channel declarations

channel coutm : {po}

channel moutc : {encryptedGoods1,en cry pt edGoods2}

channel moutt : {key}

channel toutc : {key,encryptedGoods 1,e nc ryp ted Goods 2,t ran sAbor ted }

channel toutm : {paymentToken,trans Abort ed}

channel minc : {po}

channel tinc : {paymentToken }

channel cinm : {encryptedGoods1, enc ryp te dGoods 2}

channel tinm : {key}

channel cint : {key,encryptedGoo ds1 ,en cr ypt edGoods2 ,tr ans Abort ed}

channel mint : {paymentToken,tra nsAbor te d}

channel coutt : {paymentToken }

channel timeOut

-- The customer process

CUSTOMER= ABORT |˜| ( cint ?x -> DOWNLOADED_EGOODS(x) )

DOWNLOADED_EGOODS(x) = ABORT |˜| ( coutm !po -> PO_SENT(x))

PO_SENT(x) = ABORT |˜|

(cinm ?y -> if (y==encryptedGoods 1 or y==encryptedGoods2)


else PO_SENT(x))

RECEIVED_EGOODS(x,y) =

24 of 27


ABORT |˜| (if (x==y) then RECEIVED_CORRECT_GOODS

else ABORT)

RECEIVED_CORRECT_GOODS = ABORT |˜| (coutt !paymentToken -> TOKEN_SENT)



else if (y==transAborted) then ABORT

else TOKEN_SENT

--The merchant process

MERCHANT= ABORT |˜| ( minc ?x -> if (x==po) then PO_REC

else MERCHANT)

PO_REC= ABORT |˜| (moutc !encryptedGoods1 -> ENCRYPTED_GOODS_SENT) |˜|


ENCRYPTED_GOODS_SENT = ABORT |˜| (moutt !key -> KEY_SENT)

KEY_SENT = mint ?x -> if (x== paymentToken) then SUCCESS

else if (x==transAborted) then ABORT

else KEY_SENT

--The Trusted Third Party Process

TP = ABORT |˜| (toutc !encryptedGoods1 -> WAIT_TOKEN_KEY)


else WAIT_TOKEN_KEY) []



WAIT_KEY(a) = (tinm ?b -> if (b==key) then CHECK_TOKEN(a,b)

else WAIT_KEY(a))

25 of 27



WAIT_TOKEN(b) = (tinc ?a -> if (a==paymentToken) then CHECK_TOKEN(a,b)

else WAIT_TOKEN(b))









SUCCESS= STOP

ABORT = STOP

COMMcm= []x: {po} @(coutm ?x -> (COMMcm|˜| (minc !x -> COMMcm)))

COMMct = []x: {paymentToken} @(coutt ?x -> (tinc !x -> COMMct))

COMMmc= []x: {encryptedGoods1,e ncr ypt edGoods2 }@(moutc ?x ->

( COMMmc|˜| (cinm !x -> COMMmc)))

COMMmt= []x: {key} @(moutt ?x -> (COMMmt |˜| (tinm !x -> COMMmt)))

COMMtc = []x: {key,encryptedGood s1, enc ry pte dGoods 2, tra nsAbor te d}@(to utc ?x

-> (cint !x -> COMMtc))

COMMtm= []x: {transAborted,paym ent Token}@(tou tm ?x -> (mint !x -> COMMtm))

COMM= (((( COMMct [|{}|] COMMmt) [|{}|]

COMMtc) [|{}|] COMMtm) [|{}|] COMMcm)[|{}|] COMMmc

CIO = {| coutm, coutt, cinm, cint |}

MIO = {| moutt, moutc, minc, mint |}

26 of 27


TIO = {| toutm, toutc, tinm, tinc |}

COMMIO= union(CIO, union (MIO, TIO))


union(diff(COMMIO,{ cou tt. paymentT oke n, min t.p aymentTo ken ,

cint.transAborted}) ,{ tim eOut})


union(diff(COMMIO,{ cin m.enc ryp ted Goods 1,e ncr ypt edGoods2 ,

cint.key,mint.payme nt Token} ),{ ti meOut} )


union(diff(COMMIO, {|c inm ,c out t|} ),{ ti meOut} )

-- This is the money atomicity property

SPEC1 = STOP |˜| (coutt.paymentToke n -> ((cint.transAborted -> STOP) |˜|

(mint.paymentToke n -> STOP)))

-- This is the goods atomicity property



( cinm.encryptedGoods 1 -> cint.key -> mint.paymentToken -> STOP)

[] ( cinm.encryptedGood s1 -> mint.paymentToken -> cint.key -> STOP))

-- This is the validated receipt property

SPEC3 = STOP |˜| ((cinm.encryptedGo ods 1 -> STOP)

[] (cinm.encryptedGoo ds 2 -> STOP)

[] (cinm.encryptedGoo ds 1 -> coutt.paymentToke n -> STOP))

27 of 27

Documents

Failure Analysis of an E-commerce Protocol using Model Checking