Designing & Verifying Secure Protocols of theDigital Marketplace

Swee K. GOO', James M. IRVINE', Allan TOMLINSON2, and Scarlet SCHWIDERSKI-GROSCHE2'Mobile Communications Group, 2Information Security Group,

University of Strathclyde Royal Holloway - University of London204 George Square, Glasgow GI 1 XW, UK Egham, Surrey TW20 OEX, UKEmail: sweegooj.irvine@eee.strath.ac.uk Allan.Tomlinson,Scarlet.Schwiderski-

Tel: +44-(0)141-5482061, Fax: +44-(0)141-5524968 Grosche@rhul.ac.uk

Abstract- The Mobile VCE's Digital Marketplace (DMP) is asystem, which allows very short term trading of radio resources.It uses autonomous agents to request and negotiate the provisionof communications services in a dynamic and competitivemanner. While showing great promise, many security concernsinvolving the adoption of the DMP infrastructure by the futuremobile communications industry remain unresolved. This paperexamines the cryptographic protocol that plays an essentialinfluencing role in creating a secure service negotiation platform.

Index Terms-security, protocol, marketplace, agents

I. INTRODUCTIONOnline markets are becoming common in today's

eBusiness world. Many are well established and allow adiverse range of products to be acquired simply. Examplesinclude Expedia, Amazon, eBid and ShoppingNet. Thoughthese platforms may be designed with a variety of objectives,they all function well as a meeting point and implement asimple negotiation strategy (i.e. advertise, search, bid or/andbuy). However, these market sites do not meet the specialisedneeds of the future mobile industry, in terms of transactionperformance, market scalability, negotiation timeframe andnon-standard product categorisation. This is because a mobilecommunication trading system is constrained by its consumerbuying behaviour, and also has other requirements such asvery short call set-up delay and complex many-to-manynegotiation strategies. Unlike tangible products, a mobileuser's control in making decision within the spectrum tradingis restricted by the lack of product characterisation.The Digital Marketplace (DMP) [1] functions as a freely

operating market platform for multiple access technologies, sothat highly dynamic mobile users can simply initiate a newcontract and switch network without the need to purchase anew device. Full details of the DMP operation can be found in[1]. For the DMP to be accepted in any future communicationssystem, security is a key concern. In [2], we have illustratedimportant security threats, security requirements and a securityarchitecture. One of which is the DMP negotiation protocol asit specifies essential rules that each DMP agent shouldinteract. However, these protocols may only be effective inguiding (and not enforcing) the interaction among agents. Ifone agent does not follow the rules or changes the negotiationsteps, critical issues may occur. Key system managers, such asDMP registry and mobility manager, are useful, but they may

0-7803-9206-X/05/$20.00 ©2005 IEEE86

only enforce the protocol sequence while not being able toprevent other anticipated problems such as an intruder'sattack. Additionally, the security advice [3], [4] for currentauction sites cannot be used to counteract problems such ascollusion and bid manipulation in spectrum trading. To assurethe negotiation protocols are robust against maliciousbehaviour and to prevent insecure DMP protocols, we needthese DMP protocols to be cryptographically designed basedon specific criteria (Section II), and verified with the specifiedsecurity properties in the paper (Section III).

II. MODELLING THE DMP CRYPTOGRAPHIC PROTOCOLSMany failures can be caused by a poorly designed protocol.

It is therefore important to highlight the following modellingcriteria:

A. Consideration FactorsAs depicted in Fig 1, we model our DMP cryptographic

protocols based on the follow:* Type ofcall session - Incoming or outgoing session.An incoming session specifies that a user terminated call

requires an additional protocol such as a paging service tocontact a registered DMP user (i.e. User Terminal Agent -UTA), while an outgoing session refers to a call initiated froma user specified terminal.* Type ofcustomer - With or without a service provider.The customer classification affects whether a primary

service provider or a broker is involved in the servicenegotiation. If the user does not subscribe to a serviceprovider, he/she migrates his/her own service negotiator (i.e.User Service Agent - USA) to the marketplace. A ServiceProvider Agent (i.e. SPA) is migrated to the marketplace if aservice negotiator is contracted to initiate a call contract onbehalf of a mobile user.* Type of negotiation mechanism - Simple sealed-bid

auction or complex multiple negotiations.The DMP enables its customers a choice of negotiation

mechanisms. Sealed-bid auctions present little sequentialinteraction among bidders and negotiation can be completedalmost instantly. Although the sealed-bid auction may notalways supply the best bid price, it is able to provide the bestcompetitive bid in a constrained timeframe. However, asealed-bid auction is more easily exposed to security threats[5],[6] as the complex best bid counter-offer strategy usuallyhas more control of the information released during the

/\Din cV Seald-bid

gNegotiaion otnta 2-.tge\Mechatnism/t RequstResponse IP,nendsue\?/ ~ ~ ~ P.d

Bilatema/ Multiple Cotninue atNegioti.on Set keBid

5-sfts Se-ticeBidPre£dU,re SeeviceBidResponse

C.ntpotA-ad (NO's sigw-un)t-o.l.nifoNO connecion

tCall SetupConiletnoton

Contents Ttans-issiontUliReleaseCtllJUpdateBillRepomt

Cottmittent Repot

Fig. I. Overview of the Involved Interaction Proceduresbidding [7],[8]. As a result, the negotiation protocol for asealed-bid auction is designed with additional protocol steps toincrease privacy protection by controlling the informationflowing between the corresponding parties during the servicenegotiation.

B. Protocol ExpressionThe following specifies the expressions for use in the DMP's

security protocols:XID Denotes the virtual identity of an agent, X. It may also consist

of some contact information of X.NA Denotes nonce generated by entity A whereby the subscripts

denote the origin. Nonce is randomly generated number for usein a single run of the protocol

KA B Denotes a key shared between A and BKAlpfinte) Denotes a secret key known only to AKA(publi.) Denotes a public key ofA{m}K Denotes a message m encrypted with a either long-term or short

term cryptographic key KX,Y Denotes the concatenation ofX and YSA(m) Denotes the message m signed by agent A. This is obtained by

encrypting the message with its secret key, KA(prntnt Thisdocument can be decrypted by the public key of KA(pubtic).

H[m] Denotes an unkeyed modification detection code/ hashingfunction generated on message m.

MACK[m] Denotes a Message Authentication code, generated on messagem using cryptographic key, K.

TA Denotes a generalised time-stamp ofA, used to validify thetime at which a key or ticket is created.

Tag,i,ht<m> Denotes the copy right and inheritance right to message content.

Due to space limitations, we can only describe sets ofDMP's security protocols in outline:

1) Session Key Establishment Between the User & DMPBefore a mobile user can initiate a call contract via the

DMP, a session key has to be established (as depicted in Fig2a & 2b), via either a 5 or 7 steps protocol (based on "Who

contacts the trusted key server, TrustCA, first?"). This is toprovide some flexibility in key controlling during the serviceinitialisation. In Fig 2a, the UTA relies on the marketplace toget authenticated public keys and a shared session key, issuedfrom a reliable key distribution centre. Since UTA has noknowledge of the authenticity of the MIA's public key,message I is thus left unencrypted by the UTA. This act couldallow an intruder to tamper with the identity and impersonatethe UTA. Thus, we have to rely on the subsequent protocolsteps to tackle this possible fooling and impersonating attackby adding desirable identity and nonce before each message isexchanged. The UTA could encrypt message I withTrustCA's public key, but the MIA will not be able to decryptand know who actually contact him and the purpose of thismessage unless TrustCA assists to extract the embeddinginformation. This approach could increase the protocolcomplexity. Alternatively, the additional 2-steps protocolillustrated in Fig 2b allows the UTA to receive the approvedMIA's public key (i.e. KUTA(pub,C)) and their shared key (i.e.KUTAMIA) simply from TrustCA. Though UTA has forwardedTrustCA's certification to MIA in Step 3, the MIA or theSecurity Manager in the DMP will still suspect if theforwarded KuTA(PUbl,)C has been legitimately issued from atrusted key server such as TrustCA. MIA can simply extractthe KUTAMIA and start the message encryption. However, as

UTA MIA TRUSTCAUTA1) UTA -)MIA: UTAID, NITX42) MIA 4 TrusiCA: (TrustCAoD UTA/D NtT4 MIA/D NAISIA SMU(If[UTAID NuT. MIA/D

NAMIAI) JKTVSIC40FIk)3) TrusiCA MIA: (TT,.,tCA UTAiD, NITA KIAA(pw-It KUTAAIASTA, C4(H[TT_C,4

UTAI, Nw-A, KMAA(PSIOch KvtTMAU)}KtTA^pbIId, (TT-SIC+ MIAIm NA510 KLTAWO&,KuTAMIO. STr.c.s(H[TT,..cs MAD NMA, Kut.osN,& KiTAMIAJ)}KtA{4beio)

4) MIA 4 UTA: tN 'Af, MJA,D)Kturt.p.o,tc ITT,C4, UTAI5 NtT.+ KAYIA(nTi.,tK iTaMLSTn.c.A(H[TT,e,c. UTALS NITA, KAvA"P.bttr KUTA.MIAK)TKtT4ANk

5) UTA 4MIA: (NM,AJKMbajC,)Fig. 2a. Key Establishment via MIA Contacting TrustCA First

1 ~~~~76 mmW

UTA dI MIA

251~!~

'I'RUSI'CAI) UTA 4 TrusICA: {TrustCAoD UTAID MIAID, NUT4 StTA1([UTAI MIAID,

NLt74))KT,CA0-CAkI2) TrustCA 4LUTA: 'Tr,.4, MIAsr NUTA KM,AIAOLS KUT0.114 STIICA(H[TThOICA,

MIA,D N1TA KMAI,4(1Nce K&TAMIAsJ))KuTAPbhD)3) UTA 4MIA: (UTAoa Sr,noc4WHTT-Cu MIA,D NLTA KMI4)p.otict KUTAAMAJ), TTmnCA

MIA,D NuTA KM,4 C, KLTAvM,JKmoAM ,)4) MIA 4 TrusiCA: fTrustCAD, UTA,a MIA,0 NMIA SMMA(H[UTAID MIAID

NAjj41))KTr.cA(eno)5) TrustCA 4MIA: {TT_,,,C. UTAI, NM/A KLTrs,nnt.r KUTAMA, STeCA(H[TT-4c

UTA115 NA4IA KLTA(pbo&c KtTAMIAJ)}KwuM"bltC)6) MIA 4 UTA: (MJA,D NMo.4o K&TA0IA N,TA SM,A(H[MIAAD, N AM.O KITAAII.4,

NlTA])jKj.TA(,.bjj¢)7) UTA 4 MIA: ({Ng 'wjVKuTA.Ar'AAKAMO4bii)

Fig. 2b. Key Establishment via UTA Contacting TrustCA First

87

there can be a lot of fake keys that are created to look like theone issued by TrustCA, a confirmation of the key authenticityis hence required from TrustCA to MIA in Step 5. This set ofkey establishment protocol is also to ensure the correspondingagents are really talking to each other rather than to an

impostor. The market agent is represented by a MarketInterface Agent (MIA). In this context, we also assume an

offline secure key distribution exists between the user and theTrustCA, and between the DMP and the TrustCA, which hasalready been established via some key agreement protocols.

2) Initiation of Call Contractfor an Outgoing Session

This specifies details of how the entire DMP negotiationprotocol works, such as how the Service Level Agreement(SLA) is securely packaged. This protocol set also models theembedding design factors such as the type of customer and thetype of negotiation mechanism, as illustrated in Fig I (fromprotocol steps: ConnectionRequest to LocationInfo). Fig 3describes an example of the call contract protocol, whereby a

mobile user requires a quick sealed-bid contract with the helpof a service provider. We assume that UTA may already hassome kind of certificates, for instances, a valid User ID (i.e.returning DMP user) that MIA has given him earlier or a

payment creditability certificate from a credit card company,

TrustPayCert. Compared to work such as ContractNet [9], theDMP has specified more participants other than just theinitiator and the responders (or using a generic term such as

participants). This helps to distribute the responsibility of a

single entity to a few entities and makes each of them performthe task as allocated. Fraud speculation is hence much easierto discover and rectify. Apart from comprising UTA and USA,the user agents also consist of a User Home Agent (UHA) at

the service provider's server. For network operator, twodifferent agent types are required: a Network Home Agent(NHA) at the site of the network operator server and a

Network Operator Agent (NOA) for making bids to therespective service agents. When NOA receives the contactinformation and public key of the contracted customer, UTA(in Step11), UTA and NOA can then proceed with theestablishment process of the contracted service provision, i.e.NO_connection.

3) Paging Protocolfor an Incoming SessionThis paging protocol allows mobile users to be able to

receive calls using some form of registration arrangement. Wedesign it with consideration as to how the external pagingmessage is packaged by a UHA at the service provider'sserver and how the user acknowledges and informs UHA thathe has successfully received the paging request from a NOA at

the marketplace. Fig 4 illustrates the cryptographic protocolsfor the paging service.As these DMP protocols are primarily generated based on

public key cryptography, we assume adequate computationalresources are available to handle such calculations.

1--2.f2b/2,

35_ Ir

I

. NO ..nne.tieCall Setup

_ Co-farmtionContentt T-nsCauSItlease

C Uld. Commit-t.,R.pftCmmilmentSepeC

SersiceRq-est

S SPA Migfi-

4

16

, 8

*1 10

C11Release Cell pd.tetilSepett

Teeninal MasiketD-oain SewicePreside,-ain Donmin

1) UTA 4 MIA: (UTAID, N'uTL STAT(H[UTAD, N'UT41),N;s.A,,S.UA(User ID) wP`),PaymentCert)KKIA(,oAli0,where PaymentCert= upfrontPayCert or/and TrustPayCert

2a)If the DMP user identity(User_ID) and the UTA identity(UTAuD) are invalid,MIA 4 UTA: (MIAD, N'7,TA, SWs4J("Invalid user. Try again ')KuT.4,,^,i,s

2b)If the payment creditability of a user fais,MIA 4 UTA: (MIAD,o N'uTh SAfA("Payment Invalid Updates required"))KbTA>^u,,,

2c)MIA 4 UTA: /MIAD,oN"MMIA, N'IT4, UHAD, User ID,TMIA MACtT{M , [MIA,N'-SOA. N'rT4, UHAi, User ID,TMIlA, ServiceNo, DMP ID, Expiry,Sso4(H[ServiceNo DMP_ID, ExpiryJ))KbT.4,pbbh6

3) UTA 4 UHA: {N'T,, UTAD,TuA,, User ID,TMIA MACLTWH,4 [NurA, UTAa,0TTTAUser_ID,TMIA/j, Tag ,& uHA<ServiceRequeSt>)K,,,HA,,5lwhere ServiceRequest is ServiceNo, DMP ID, Expiry,SM/4(H[ServiceNo,DMP_ID,Expiry]), Tu-,s GeneralRequirements, RequirementDetails, ServiceConditions,PaymentTypes, BidExpiry, MACuTA une [Tuss. GeneralRequirements,RequirementDetails,ServiceConditions, PaymentTypes, BidExpiry]

4) SPA 4 NOA: (Nsp.s SPA,, ContractRequest_ID,TSp,P MACspAN04 [Nsp, SPAD,ContractRequest ID, TY,spA, Tag,g,,_Va4<ContractRequest >}KseoAlnuee,)where ContractRequest is Brie/Requirement, ConnectionFlow, BriejServiceCond,PaymentArrangement, tenderExpiry, SspA(H[Brie(Requirement, ConnectionFlow,BrieBServiceCond, PaymentArrangement, tenderExpiryy)

5) NOA 4 SPA:[{NspA, NNOAe.NOA, ContractRequest ID, T5sp MACsp, NoA[Nsp,6 NNo,6NOAo, ContractRequest_ID,TspAP ,SvoAA yes or no `))KspAs"b,i,

Step 5 can aiso he ignored if the NOA chooses a nii response.

6) SPA 4NOA:{S sp,6 SPAD,0 TspA, MACSPA,NOAIN'SP4, SPAD, Tsp.4],TaggOsSeOA<ServiceBid>d])KvoAt_b1,c,where ServiceBid is ServiceBidding_ID, BriejRequirement, ConnectionFlow,TechnologyRReqBrieBServiceCond, TransportParameter, PaymentArrangement,BiddingExpiry,CallOrig&Dest,SspAt(I[ServiceBidding_ID, Brie/Requirement,ConnectionFlow, TechnologyReq,BriefSServiceCond, TransportParameter,PaymentArrangement, BiddingExpiry, CallOrig&Dest])

7) NOA 4SPA:{Nssp.,N'N,TTO,A ServiceBidding_ID, SNoA(BidPrice, Commitment),

MACSPA,NSANspA N'WA ,+TT,,W ServiceBidding IDjJKspA lent1ii8) SPA 4 NOA:(NN OA 'SPA, SPA,0 TspA, MACSpA[ NoA N',o NSP4 SPA,0T'spT,s,

Tagr,,h,s,oA< ContractAward>}KtoAw,a,,where ContractAward is ServiceBidding ID, BrieRequirement, ConnectionFlow,TechnologyReq, BriefServiceCond, TransportParameter, PaymentArrangement,ContractExpiry, AgreedPrice, CallOrig&Dest, LegalTerms,SspA(H[BrieeRequirement, ConnectionFlow, TechnologyReq,BrieHSeSiceCond,TransportParameter, PaymentArrangement, ContractExpiry, AgreedPrice,CallOrig&Dest, LegalTerms])

9) NOA 4 SPA:{NNo,6 SPA,0TTspA, MACspA NoA[N,NoA, SPA,0TTs',PJ,(Cont-ractwardRespo-sesp,)KspxNo,4NKspAOb,,where ContractAwardResponsespA is N'sp,ServiceBiddingD NID, SN0.4(H[N'sP.ServiceBidding_ID]), BriefRequirement, ConnectionFl ow, TechnologyReq,BriefServiceCond, TransportParameter, PaymentArrangement, ContractExpiry,AgreedPrice, CallCrig&Dest, LegalTenns, SspA(H[Brie/Requirement,ConnectionFlow, TechnologyReq, Brie/ServiceCona, TransportParameter,PaymentArrangement, ContractExpiry, AgreedPrice, CallOrigetDest, Legal Terms])

10)SPA 4NOA:s (/No 4 SPA, Location1nfospsiKvoA(s,b1kwhere LocationlnfospA is(SPA(H[DMP_ID, UTA_Location,ServiceBidding_ID,KuK-A"besl,J), DMP_ID, UTA Location, ServiceBidding_ID KurAC,b,,,,}KspA,Na4

Fig. 3. Overview of the Negotiation Protocol for an Outgoing Session withService Provider's Control (Using Direct-bid Strategy)

88

Terminal Market Service Provider Net-ork OperatorDomain Domain Domain Domain

1) UHA 4NHA: iNUH4 UHA,D UTAID PogingInfo, MACUH.NH4VXNA., UHA1DUTA D]) K,nH4Ceptr)2) NHA 4NOA: INUH4, NVH4 UHAID5 UTAIA PagingInfo, MACNH4 W4[NVHL N.VH4UHA,a UTAtD]) K,V04bipla,3) NOA - NHA: tNUHAv NXVH4 NNvo UTAIc Svo4("yes " or "no'), MAC.Vnt.v04[NtnNvmA Nvo.4, UTArDnJKH,qa4(paairl4) NOA 4 UTA: INs4. UHAD, NvO4 Paginglnfo, MACV04AUTA[NUH4. UHAID, Nvo4) bT.4(p.b1,5) UTA 4 UHA: (NOHt EPID UTA,I MACT4 UH4[NUH4 EPID UTAtDJ}KtH4"PaEti0where Paginglnfo is (Nu'H.4 EPID UTAID, TuH., contactMsg. Sb'4(H[Nt.H, EPID UTAIDrTtRH,J)K&T4H.a4

Fig. 4. Operation of the DMP's Paging Protocol

III. INFORMAL VERIFICATION OF THE DMP CRYPTOGRAPHICPROTOCOLS

The modelling problems ofthe DMP's security protocol canbecome complex and difficult to solve if we consider toomany concurrent interacting protocol sessions at one time. Toreduce these complexities, we employ simple securitymechanisms and negotiation procedures to fulfil the basicsecurity needs of the DMP protocol. This also prevents toomany complex encrypted messages (e.g. Secure ElectronicTransaction [10]) so that we can make an initial analysis andfocus sufficiently on the designed protocol of the negotiationprocess. Hence, we present the modelling and verification ofthe DMP security protocols in a comprehensible and relativelyconcise form, where informal analysis can be conducted onthe interleave runs of the DMP protocol. In doing so, weensure that the proposed protocols are in line with the overallsecurity objectives ofthe DMP, such as:

Privacy/ Secrecy/ Confidentiality - To insure non-traceability, bindings of the user's real identity and also hisrelationship with relevant domain authorities are essential andhence, it is an obligation to follow these circumstances in thespecified DMP cryptographic protocols. We also see the needof privacy protection in profile building, whereby no biddershould be capable of deriving a) the quantity of the bid requestinitiated from the SPA/ USA and b) which particular networkoperator has responded to the same bid request, during theservice negotiation. To meet this requirement, we havedesigned the negotiation protocol (Fig I & Fig 3) in a way thatonly SPA or USA knows the association details of a particularServiceNo and its generated ContractRequest iDs andServiceBidding_IDs. Shared key/ secret (e.g. KUTAMIA, KSPA,NOAand KUTA, UHA) for use in symmetry encryption helps to ensurethe message confidentiality such as the contact message of thepaging protocol and details of the awarded contract. With thisproperty being followed, only the winning bidder (i.e. NOA)can collect the item bid upon. We employ virtual identities anddigital signatures/ certificates in our designed protocols todenote the various needs (e.g. membership identity and serviceidentity) for establishment of service contract or at various

negotiation stages. It is also vital to realise that long termvirtual identity/ alias may only be suitable for use in a non-classified message exchange or protocol run, whereas one-time-use virtual identity offers higher security protection andcontrol, for instance, during initial network and session set-ups. Confidential message exchange can be trulyaccomplished when only its intended recipients decipher theencrypted message. For this reason, we have encrypted all themain identities, so that replay attack is not possible in anycase. Only information that is necessary to carry out thetransaction is revealed to authorised entities. If the desiredidentity is properly encrypted, the legitimate recipient uponreceiving this message is then able to prove that the(illegitimate) sender is not what he claims to be. This theory isadopted and demonstrated in one of the examples, KeyEstablishment Protocol (Fig 2b), where UTAID is added andencrypted in message 5 instead of MIAJD. In addition to this,identity theft needs to be prevented, possibly via entityauthentication. Only then, illegitimate service access (orservice request) and profile correlation of the personalisedservice can then be evaded. However, for total secrecy oranonymity, mobile user should use digital cash mechanism(i.e. upfrontPayCert) for membership registration and servicepayment.

Data authenticity relies on data origin authentication usingsignatures, which are also based on the usage of messageauthenticity. This is also to assure that the message encryptedwith A's secret key did originate from the real originator, A.For example, TrustCA assures MIA that the public keys didoriginate from it (TrustCA) in Key Establishment Protocol(Fig 2a, Step 3) by giving a digital signature at the hashedissued keys. The hashing function provides the extra integritymeasure in the DMP's protocols.

Correct communications and interpretations of contractrules - To achieve these, we have proposed a standardtemplate for capturing tender details, and enforced marketregistration to avoid rule non-compliance. For example, theUTA's SLA shown in message 4 (Fig 3) denotes the variousdetails of the user service needs in the form of a documentrepresented by GeneralRequirements, RequirementDetails,ServiceConditions, PaymentTypes, BidExpiry, SUTA(H[GeneralRequirements,RequirementDetails, ServiceConditions,PaymentTypes, BidExpiry]). In addition, we also make surethat the DMP security protocols carry encrypted componentsthat are in distinctive formats so as to prevent the oracle attack[11]. This is illustrated in Message 6 in Fig 2b's protocolwhereby MIA did not forward the exact message 5, TTruS CA,UTAIm NMIA KUTA(public), KUTAMIA, STrustCA(H[ TTiu,OCA, UTAID,NMIA, KurA(public), KUTAM,A2) it received from TrustCA, to UTA.

Others include:* We have freshness indicators for two different

requirements; a nonce is used to maintain the freshness ofa protocol run while a timestamp is required to ensure thefreshness of particular encrypted information such asmessage or nonce, in order to prevent replay attack andoracle state. The nonce can be interpreted and used as akey to prevent a similar issue of misinterpretation such as

89

a component's functionality. Besides that, a nonce isfrequently employed in situation where little or no directrelationship is required to elaborate between theidentities/ aliases. The key reason for this is that the nonceis difficult to correlate between the identities/ aliases sincethey are only random numbers. This argument isillustrated in a) the protocol for session key establishmentbetween the user and the DMP, and b) paging protocolwhere NUTA (Fig 2a & 2b) and NUHA (Fig 4) are explicitlyutilised to represent message identity of respectiveprotocol run.

* The entity authentication is assisted by public keycryptography whereby a trusted authenticator, TrustCA, isinvolved. Further to the existing authenticationmechanisms for key distribution and messageauthentication, we have also proposed a separate securityprotocol for mutual authentication for mobile userwishing to initiate a connection request to the DMP.Virtual identities (for agent and service identification) areused to avoid an intruder guessing or correlating therelationships between the different administrative andsupporting entities for the service requestor and the bidderthroughout the DMP operation.

* Control of information release is achieved in several waysin the DMP: the negotiation procedures (1 and 2 stages),digital signatures, encryption techniques (that areassumed to be provided by network), trust policy control(or authorisation to access and rights to forward usingTagrjght). The policy requirement is implemented at thesystem level. Theft of rights and rights replication oughtto be counteracted and these problems can be unravelledby one of the secrecy mechanisms such as digitalsignature. With these measures employed in the protocols,assurance of the DMP security can then be pursued; onlya specified or legitimated entity/ agent can gain access tothe application such as bid evaluation so as to protectDMP entities from Denial of Service and misuse ofresources. This property is particularly imperative to thesecurity manager and the market registry.

Only when these security requirements are met, robust andsafe adoption of the DMP's trading platform can be achieved.If any of these fails, a penalty should be applied and theregulation authorities in the marketplace must remove anyunapproved act.

IV. CONCLUSION

Our proposed solutions are largely focused on theinteraction procedures between various administrative agentsat different DMP negotiation stages. We attempt to cover keyprotection measures required for security purposes, usingsimple but vital security mechanisms (e.g. digital signatures).Understanding the real behaviour of a security protocol is avery demanding task due to the immense amount of possiblemalicious actions. Weaknesses in such protocols are also hardto identify, as they can be the result of subtle design flaws. Toavoid further complexity to the protocol verification, we

consider less concurrently running interacting protocolsessions at one time. Negotiation rules and negotiationrequirements are also incorporated in order that the mobileindustry can conveniently and safely request servicenegotiation via the DMP. New sets of protocol are alsodeveloped for use: with or without the control of a serviceprovider and to securely support the different auctionmethodologies (either direct or multi negotiation strategies).With that, informal protocol verification in the DMP's securityprotocols is being conducted to identify the anticipatingweaknesses. However, to ensure the designed securityprotocols of the DMP are truly safe and to prevent insecureprotocols reaching the public domain, our future work willexamine formal verification techniques [10] to providethorough evaluation of the DMP's security protocols.

ACKNOWLEDGMENT

The work reported in this paper has formed part of the PDEarea of the Core 3 Research Programme of the Virtual Centreof Excellence in Mobile & Personal Communications, MobileVCE, www.mobilevce.com, whose funding support, includingthat of EPSRC, is gratefully acknowledged. Full detailedtechnical reports on this research are available to IndustrialMembers of Mobile VCE.

REFERENCES

[1] Irvine, J., "Adam Smith Goes Mobile: Managing Serviced Beyond 3Gwith the Digital Marketplace", European Wireless 2002, Italy, Feb.2002.

[2] Goo, S. K., Irvine, J., Dunlop, J., Tomlinson, A., Schwiderski-Grosche,S., "Security Requirements for Mobile Service Provision via a DigitalMarketplace", European Wireless 2005, Cyprus, Apr 2005.

[3] Banksafeonline.org.uk - General advice on staying safe online,http://Hwww.banksafeonline.org.uk/advice.html

[4] Computer Crime and Intellectual Property Section (CCIPS) of theCriminal Division of the U.S. Department of Justice - Cyberethics WebSites, http://www.cybercrime.gov/linksl.htm

[5] Franklin, M. K. and Reiter, M. K., "The Design and Implementation ofA Secure Auction Service", Proc. ofIEEE Symposium on Security andPrivacy, pp.2-14, Oakland, California, May 1995.

[6] Porter, R., and Shoham, Y., "On Cheating in Sealed-Bid Auctions",Proc. of the 4th ACM Conf on Electronic Commerce, San Diego,California, USA, June 2003.

[7] Reimers, K., "The Non-market Preconditions of Electronic Markets:Implications for Their Evolution and Applicability", European JournalofInformation Systems, Vol.5(2), pp.75-84, 1996.

[8] Fatima, S. S., Wooldridge, M. J. and Jennings, N. R., "Multi-issueNegotiation Under Time Constraints", Proc. of the Ist Int'l Joint ConfOn Autonomous Agents and Multi-Agent Systems, Bologna, Italy, 2002.

[9] "FIPA Contract Net Interaction Protocol Specification", Foundation forIntelligent Physical Agents, http://www.fipa.org/specs/fipa00029/, Dec.2002.

[10] Bella, G., Massacci, F., and Paulson, L. C., "Overview of theVerification of SET," Int Journal on Information Security, 2004.

[11] Lowe, G., "Some New Attacks upon Security Protocols", Proc. of the9th IEEE Computer Security Foundations Workshop, 1996.

90