Designing & Verifying Secure Protocols of the

Designing & Verifying Secure Protocols of the Digital Marketplace Swee K. GOO1, James M. IRVINE1, Allan TOMLINSON2, and Scarlet SCHWIDERSKI-GROSCHE2 1

Mobile Communications Group, University of Strathclyde 204 George Square, Glasgow G1 1XW, UK Email: sweegoo,[email protected] Tel: +44-(0)141-5482061, Fax: +44-(0)141-5524968 _

Abstract— The Mobile VCE’s Digital Marketplace (DMP) is a system, which allows very short term trading of radio resources. It uses autonomous agents to request and negotiate the provision of communications services in a dynamic and competitive manner. While showing great promise, many security concerns involving the adoption of the DMP infrastructure by the future mobile communications industry remain unresolved. This paper examines the cryptographic protocol that plays an essential influencing role in creating a secure service negotiation platform. Index Terms—security, protocol, marketplace, agents I.

O

INTRODUCTION

nline markets are becoming common in today’s eBusiness world. Many are well established and allow a diverse range of products to be acquired simply. Examples include Expedia, Amazon, eBid and ShoppingNet. Though these platforms may be designed with a variety of objectives, they all function well as a meeting point and implement a simple negotiation strategy (i.e. advertise, search, bid or/and buy). However, these market sites do not meet the specialised needs of the future mobile industry, in terms of transaction performance, market scalability, negotiation timeframe and non-standard product categorisation. This is because a mobile communication trading system is constrained by its consumer buying behaviour, and also has other requirements such as very short call set-up delay and complex many-to-many negotiation strategies. Unlike tangible products, a mobile user’s control in making decision within the spectrum trading is restricted by the lack of product characterisation. The Digital Marketplace (DMP) [1] functions as a freely operating market platform for multiple access technologies, so that highly dynamic mobile users can simply initiate a new contract and switch network without the need to purchase a new device. Full details of the DMP operation can be found in [1]. For the DMP to be accepted in any future communications system, security is a key concern. In [2], we have illustrated important security threats, security requirements and a security architecture. One of which is the DMP negotiation protocol as it specifies essential rules that each DMP agent should interact. However, these protocols may only be effective in guiding (and not enforcing) the interaction among agents. If one agent does not follow the rules or changes the negotiation steps, critical issues may occur. Key system managers, such as DMP registry and mobility manager, are useful, but they may

2

Information Security Group, Royal Holloway - University of London Egham, Surrey TW20 0EX, UK Allan.Tomlinson,[email protected] only enforce the protocol sequence while not being able to prevent other anticipated problems such as an intruder’s attack. Additionally, the security advice [3], [4] for current auction sites cannot be used to counteract problems such as collusion and bid manipulation in spectrum trading. To assure the negotiation protocols are robust against malicious behaviour and to prevent insecure DMP protocols, we need these DMP protocols to be cryptographically designed based on specific criteria (Section II), and verified with the specified security properties in the paper (Section III). II. MODELLING THE DMP CRYPTOGRAPHIC PROTOCOLS Many failures can be caused by a poorly designed protocol. It is therefore important to highlight the following modelling criteria: A. Consideration Factors As depicted in Fig 1, we model our DMP cryptographic protocols based on the follow: • Type of call session – Incoming or outgoing session. An incoming session specifies that a user terminated call requires an additional protocol such as a paging service to contact a registered DMP user (i.e. User Terminal Agent UTA), while an outgoing session refers to a call initiated from a user specified terminal. • Type of customer – With or without a service provider. The customer classification affects whether a primary service provider or a broker is involved in the service negotiation. If the user does not subscribe to a service provider, he/she migrates his/her own service negotiator (i.e. User Service Agent - USA) to the marketplace. A Service Provider Agent (i.e. SPA) is migrated to the marketplace if a service negotiator is contracted to initiate a call contract on behalf 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 sequential interaction among bidders and negotiation can be completed almost instantly. Although the sealed-bid auction may not always supply the best bid price, it is able to provide the best competitive bid in a constrained timeframe. However, a sealed-bid auction is more easily exposed to security threats [5],[6] as the complex best bid counter-offer strategy usually has more control of the information released during the

Paging Service Incoming session

Type of Start

Call Session ?

PagingMsg PagingRequest ConfirmPagingRequest ConnectPaging ConfirmConnectPaging

Outgoing session

Continue at ConnectionRequest

ConnectionRequest ServiceRequest_ID ServiceRequest

Customer Type?

Involvement of a Service Provider

SPA Migration continue

Self-bidding user USA Migration

Choice of Negotiation Mechanism ?

Direct/ Sealed-bid auctions ContractRequest RequestResponse

Bilateral/ Multiple Negotiations 1-stage Procedure

2-stages Procedure

Continue at ServiceBid

ServiceBid ServiceBidResponse ContractAward ContractAward (NO’s signature) LocationInfo NO_connection Call Setup Confirmation Contents Transmission CallRelease CallUpdate BillReport Commitment Report

Fig. 1. Overview of the Involved Interaction Procedures

bidding [7],[8]. As a result, the negotiation protocol for a sealed-bid auction is designed with additional protocol steps to increase privacy protection by controlling the information flowing between the corresponding parties during the service negotiation. B. Protocol Expression The following specifies the expressions for use in the DMP’s security protocols: Denotes the virtual identity of an agent, X. It may also consist of some contact information of X. Denotes nonce generated by entity A whereby the subscripts NA denote the origin. Nonce is randomly generated number for use in a single run of the protocol KA,B Denotes a key shared between A and B Denotes a secret key known only to A KA(private) KA(public) Denotes a public key of A {m}K Denotes a message m encrypted with a either long-term or short term cryptographic key K X,Y Denotes the concatenation of X and Y Denotes the message m signed by agent A. This is obtained by SA(m) encrypting the message with its secret key, KA(private) . This document can be decrypted by the public key of KA(public). H[m] Denotes an unkeyed modification detection code/ hashing function generated on message m. MACK[m] Denotes a Message Authentication code, generated on message m using cryptographic key, K. Denotes a generalised time-stamp of A, used to validify the TA time at which a key or ticket is created. Tagright Denotes the copy right and inheritance right to message content.

contacts the trusted key server, TrustCA, first?”). This is to provide some flexibility in key controlling during the service initialisation. In Fig 2a, the UTA relies on the marketplace to get authenticated public keys and a shared session key, issued from a reliable key distribution centre. Since UTA has no knowledge of the authenticity of the MIA’s public key, message 1 is thus left unencrypted by the UTA. This act could allow an intruder to tamper with the identity and impersonate the UTA. Thus, we have to rely on the subsequent protocol steps to tackle this possible fooling and impersonating attack by adding desirable identity and nonce before each message is exchanged. The UTA could encrypt message 1 with TrustCA’s public key, but the MIA will not be able to decrypt and know who actually contact him and the purpose of this message unless TrustCA assists to extract the embedding information. This approach could increase the protocol complexity. Alternatively, the additional 2-steps protocol illustrated in Fig 2b allows the UTA to receive the approved MIA’s public key (i.e. KUTA(public)) and their shared key (i.e. KUTA,MIA) simply from TrustCA. Though UTA has forwarded TrustCA’s certification to MIA in Step 3, the MIA or the Security Manager in the DMP will still suspect if the forwarded KUTA(public) has been legitimately issued from a trusted key server such as TrustCA. MIA can simply extract the KUTA,MIA and start the message encryption. However, as 1

1) Session Key Establishment Between the User & DMP Before a mobile user can initiate a call contract via the DMP, a session key has to be established (as depicted in Fig 2a & 2b), via either a 5 or 7 steps protocol (based on “Who

3

5

1) 2) 3)

XID

Due to space limitations, we can only describe sets of DMP’s security protocols in outline:

2

4

4) 5)

TRUSTCA MIA UTA UTA Æ MIA: UTAID, NUTA MIA Æ TrustCA: {TrustCAID, UTAID, NUTA, MIAID, NMIA, SMIA(H[UTAID, NUTA, MIAID, NMIA]) }KTrustCA(public) TrustCA Æ MIA: {TTrustCA, UTAID, NUTA, KMIA(public), KUTA,MIA, STrustCA(H[TTrustCA, UTAID, NUTA,, KMIA(public), KUTA,MIA])}KUTA(public), {TTrustCA, MIAID, NMIA, KUTA(public), KUTA,MIA, STrustCA(H[TTrustCA, MIAID, NMIA, KUTA(public), KUTA,MIA])}KMIA(public) MIA Æ UTA: {N’MIA, MIAID}KUTA(public), {TTrustCA, UTAID, NUTA, KMIA(public), KUTA,MIA, STrustCA(H[TTrustCA, UTAID, NUTA,, KMIA(public), KUTA,MIA])}KUTA(public) UTA Æ MIA: {N’MIA}KMIA(public)

Fig. 2a. Key Establishment via MIA Contacting TrustCA First 7 6

3

UTA

1 2

MIA

4 5

TRUSTCA 1) UTA Æ TrustCA: {TrustCAID, UTAID, MIAID, NUTA, SUTA(H[UTAID, MIAID, NUTA])}KTrustCA(public) 2) TrustCA Æ UTA: {TTrustCA, MIAID, NUTA, KMIA(public), KUTA,MIA, STrustCA(H[TTrustCA, MIAID, NUTA, KMIA(public), KUTA,MIA])}KUTA(public) 3) UTA Æ MIA: {UTAID, STrustCA(H[TTrustCA, MIAID, NUTA, KMIA(public), KUTA,MIA]), TTrustCA, MIAID, NUTA, KMIA(public), KUTA,MIA}KMIA(public) 4) MIA Æ TrustCA: {TrustCAID, UTAID, MIAID, NMIA, SMIA(H[UTAID, MIAID, NMIA])}KTrustCA(public) 5) TrustCA Æ MIA: {TTrustCA, UTAID, NMIA, KUTA(public), KUTA,MIA, STrustCA(H[TTrustCA, UTAID, NMIA, KUTA(public), KUTA,MIA])}KMIA(public) 6) MIA Æ UTA: {MIAID, N’MIA, KUTA,MIA, NUTA, SMIA(H[MIAID, N’MIA, KUTA,MIA, NUTA])}KUTA(public) 7) UTA Æ MIA: {{N’MIA}KUTA,MIA }KMIA(public)

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

there can be a lot of fake keys that are created to look like the one issued by TrustCA, a confirmation of the key authenticity is hence required from TrustCA to MIA in Step 5. This set of key establishment protocol is also to ensure the corresponding agents are really talking to each other rather than to an impostor. The market agent is represented by a Market Interface Agent (MIA). In this context, we also assume an offline secure key distribution exists between the user and the TrustCA, and between the DMP and the TrustCA, which has already been established via some key agreement protocols. 2) Initiation of Call Contract for an Outgoing Session This specifies details of how the entire DMP negotiation protocol works, such as how the Service Level Agreement (SLA) is securely packaged. This protocol set also models the embedding design factors such as the type of customer and the type of negotiation mechanism, as illustrated in Fig 1 (from protocol steps: ConnectionRequest to LocationInfo). Fig 3 describes an example of the call contract protocol, whereby a mobile user requires a quick sealed-bid contract with the help of a service provider. We assume that UTA may already has some 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], the DMP has specified more participants other than just the initiator 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 perform the task as allocated. Fraud speculation is hence much easier to 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, two different 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 the respective service agents. When NOA receives the contact information and public key of the contracted customer, UTA (in Step 11), UTA and NOA can then proceed with the establishment process of the contracted service provision, i.e. NO_connection. 3) Paging Protocol for an Incoming Session This paging protocol allows mobile users to be able to receive calls using some form of registration arrangement. We design it with consideration as to how the external paging message is packaged by a UHA at the service provider’s server and how the user acknowledges and informs UHA that he has successfully received the paging request from a NOA at the marketplace. Fig 4 illustrates the cryptographic protocols for the paging service. As these DMP protocols are primarily generated based on public key cryptography, we assume adequate computational resources are available to handle such calculations.

UTA

MIA

NOAs

UHA

1 Check Authenticity

2a/2b/2c Package Request

3

Confirm Genuineness

ServiceRequest

SPA SPA Migration 4 If interested

5

SLA Translation

SLA Abstraction

6 Bidding

7 8

Accept Awarded Contract

Bid Evaluation

9 10

NO_connection Call Setup Confirmation Contents Transmission CallRelease

CallRelease Commitment Report

CallUpdate BillReport

Penalty Commitment Update Report

Terminal Domain

Market Domain

Service Provider Domain

1) UTA Æ MIA: {UTAID, N’UTA, SUTA(H[UTAID, N’UTA]), N’MIA-1, SMIA(User_ID)*(option), PaymentCert}KMIA(public) where PaymentCert= upfrontPayCert or/and TrustPayCert 2a) If the DMP user identity(User_ID) and the UTA identity(UTAID) are invalid, MIA Æ UTA: {MIAID, N’UTA, SMIA(“Invalid user. Try again”)}KUTA(public) 2b) If the payment creditability of a user fails, MIA Æ UTA: {MIAID, N’UTA, SMIA(“Payment Invalid. Updates required”)}KUTA(public) 2c) MIA Æ UTA: {MIAID, N’’MIA, N’UTA, UHAID, User_ID, TMIA, MACUTA,MIA [MIAID, N’’MIA, N’UTA, UHAID, User_ID, TMIA], ServiceNo, DMP_ID, Expiry, SMIA(H[ServiceNo, DMP_ID, Expiry])}KUTA(public) 3) UTA Æ UHA: {N’UTA, UTAID, TUTA, User_ID, TMIA, MACUTA,UHA [N’UTA, UTAID, TUTA, User_ID, TMIA], Tagright_UHA}KUHA(public) where ServiceRequest is ServiceNo, DMP_ID, Expiry, SMIA(H[ServiceNo,DMP_ID, Expiry]), TUTA, GeneralRequirements, RequirementDetails, ServiceConditions, PaymentTypes, BidExpiry, MACUTA,UHA [TUTA, GeneralRequirements, RequirementDetails, ServiceConditions, PaymentTypes, BidExpiry] 4) SPA Æ NOA: {NSPA, SPAID, ContractRequest_ID, TSPA, MACSPA,NOA [NSPA, SPAID, ContractRequest_ID, TSPA], Tagright_NOA}KNOA(public) where ContractRequest is BriefRequirement, ConnectionFlow, BriefServiceCond, PaymentArrangement, tenderExpiry, SSPA(H[BriefRequirement, ConnectionFlow, BriefServiceCond, PaymentArrangement, tenderExpiry]) 5) NOA Æ SPA: {NSPA, NNOA, NOAID, ContractRequest_ID, TSPA, MACSPA,NOA[NSPA, NNOA, NOAID, ContractRequest_ID, TSPA], SNOA(“yes or no”)}KSPA(public) Step 5 can also be ignored if the NOA chooses a nil response. 6) SPA Æ NOA: {N’SPA, SPAID, T’SPA, MACSPA,NOA[N’SPA, SPAID, T’SPA], Tagright_NOA)]}KNOA(public) where ServiceBid is ServiceBidding_ID, BriefRequirement, ConnectionFlow, TechnologyReq, BriefServiceCond, TransportParameter, PaymentArrangement, BiddingExpiry, CallOrig&Dest, SSPA(H[ServiceBidding_ID, BriefRequirement, ConnectionFlow, TechnologyReq, BriefServiceCond, TransportParameter, PaymentArrangement, BiddingExpiry, CallOrig&Dest]) 7) NOA Æ SPA: {N’SPA, N’NOA, TNOA, ServiceBidding_ID, SNOA(BidPrice, Commitment), MACSPA,NOA[N’SPA, N’NOA, TNOA, ServiceBidding_ID]}KSPA(public) 8) SPA Æ NOA: {N’NOA, N’SPA, SPAID, T’SPA, MACSPA,NOA [N’NOA, N’SPA, SPAID, T’SPA], Tagright_NOA< ContractAward>}KNOA(public) where ContractAward is ServiceBidding_ID, BriefRequirement, ConnectionFlow, TechnologyReq, BriefServiceCond, TransportParameter, PaymentArrangement, ContractExpiry, AgreedPrice, CallOrig&Dest, LegalTerms, SSPA(H[BriefRequirement, ConnectionFlow, TechnologyReq, BriefServiceCond, TransportParameter, PaymentArrangement, ContractExpiry, AgreedPrice, CallOrig&Dest, LegalTerms]) 9) NOA Æ SPA: {N’NOA, SPAID, T’SPA, MACSPA,NOA[N’NOA, SPAID, T’SPA], {ContractAwardResponseSPA}KSPA,NOA}KSPA(public) where ContractAwardResponseSPA is N’SPA, ServiceBidding_ID, SNOA(H[N’SPA, ServiceBidding_ID]), BriefRequirement, ConnectionFlow, TechnologyReq, BriefServiceCond, TransportParameter, PaymentArrangement, ContractExpiry, AgreedPrice, CallOrig&Dest, LegalTerms, SSPA(H[BriefRequirement, ConnectionFlow, TechnologyReq, BriefServiceCond, TransportParameter, PaymentArrangement, ContractExpiry, AgreedPrice, CallOrig&Dest, LegalTerms]) 10) SPA Æ NOA: {N’NOA, SPAID, LocationInfoSPA}KNOA(public) where LocationInfoSPA is {SSPA(H[DMP_ID, UTA_Location, ServiceBidding_ID, KUTA(public)]), DMP_ID, UTA_Location, ServiceBidding_ID, KUTA(public)}KSPA,NOA

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

UT A

N O As

C onfirm Incom ing genuin eness C onnR equest 2

1 Select N O A

3

4

NHA

UHA

5 T erminal D om ain

M arket D omain

Service P rovider Domain

Network O perator Domain

1) UHA Æ NHA: {NUHA, UHAID, UTAID, PagingInfo, MACUHA,NHA[NUHA,, UHAID, UTAID]} KNHA(public) 2) NHA Æ NOA: {NUHA, NNHA, UHAID, UTAID, PagingInfo, MACNHA,NOA[NUHA, NNHA, UHAID, UTAID]} KNOA(public) 3) NOA Æ NHA: {NUHA, NNHA, NNOA, UTAID, SNOA(“yes” or “no”), MACNHA,NOA[NUHA, NNHA, NNOA,UTAID]}KNHA(public) 4) NOA Æ UTA: {NUHA, UHAID, NNOA, PagingInfo, MACNOA,UTA[NUHA, UHAID, NNOA] }KUTA(public) 5) UTA Æ UHA: {NUHA, EPID, UTAID, MACUTA,UHA[NUHA, EPID, UTAID]}KUHA(public) where PagingInfo is {NUHA, EPID, UTAID, TUHA, contactMsg, SUHA(H[NUHA, EPID, UTAID, TUHA])}KUTA,UHA

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

III. INFORMAL VERIFICATION OF THE DMP CRYPTOGRAPHIC PROTOCOLS The modelling problems of the DMP’s security protocol can become complex and difficult to solve if we consider too many concurrent interacting protocol sessions at one time. To reduce these complexities, we employ simple security mechanisms and negotiation procedures to fulfil the basic security needs of the DMP protocol. This also prevents too many complex encrypted messages (e.g. Secure Electronic Transaction [10]) so that we can make an initial analysis and focus sufficiently on the designed protocol of the negotiation process. Hence, we present the modelling and verification of the DMP security protocols in a comprehensible and relatively concise form, where informal analysis can be conducted on the interleave runs of the DMP protocol. In doing so, we ensure that the proposed protocols are in line with the overall security objectives of the DMP, such as: Privacy/ Secrecy/ Confidentiality – To insure nontraceability, bindings of the user’s real identity and also his relationship with relevant domain authorities are essential and hence, it is an obligation to follow these circumstances in the specified DMP cryptographic protocols. We also see the need of privacy protection in profile building, whereby no bidder should be capable of deriving a) the quantity of the bid request initiated from the SPA/ USA and b) which particular network operator has responded to the same bid request, during the service negotiation. To meet this requirement, we have designed the negotiation protocol (Fig 1 & Fig 3) in a way that only SPA or USA knows the association details of a particular ServiceNo and its generated ContractRequest_IDs and ServiceBidding_IDs. Shared key/ secret (e.g. KUTA,MIA, KSPA,NOA and KUTA,UHA) for use in symmetry encryption helps to ensure the message confidentiality such as the contact message of the paging protocol and details of the awarded contract. With this property being followed, only the winning bidder (i.e. NOA) can collect the item bid upon. We employ virtual identities and digital signatures/ certificates in our designed protocols to denote the various needs (e.g. membership identity and service identity) for establishment of service contract or at various

negotiation stages. It is also vital to realise that long term virtual identity/ alias may only be suitable for use in a nonclassified message exchange or protocol run, whereas onetime-use virtual identity offers higher security protection and control, for instance, during initial network and session setups. Confidential message exchange can be truly accomplished when only its intended recipients decipher the encrypted message. For this reason, we have encrypted all the main identities, so that replay attack is not possible in any case. Only information that is necessary to carry out the transaction is revealed to authorised entities. If the desired identity is properly encrypted, the legitimate recipient upon receiving this message is then able to prove that the (illegitimate) sender is not what he claims to be. This theory is adopted and demonstrated in one of the examples, Key Establishment Protocol (Fig 2b), where UTAID is added and encrypted in message 5 instead of MIAID. In addition to this, identity theft needs to be prevented, possibly via entity authentication. Only then, illegitimate service access (or service request) and profile correlation of the personalised service can then be evaded. However, for total secrecy or anonymity, mobile user should use digital cash mechanism (i.e. upfrontPayCert) for membership registration and service payment. Data authenticity relies on data origin authentication using signatures, which are also based on the usage of message authenticity. This is also to assure that the message encrypted with A’s secret key did originate from the real originator, A. For example, TrustCA assures MIA that the public keys did originate from it (TrustCA) in Key Establishment Protocol (Fig 2a, Step 3) by giving a digital signature at the hashed issued keys. The hashing function provides the extra integrity measure in the DMP’s protocols. Correct communications and interpretations of contract rules - To achieve these, we have proposed a standard template for capturing tender details, and enforced market registration to avoid rule non-compliance. For example, the UTA’s SLA shown in message 4 (Fig 3) denotes the various details of the user service needs in the form of a document represented by GeneralRequirements, RequirementDetails, ServiceConditions, PaymentTypes, BidExpiry, SUTA(H[ GeneralRequirements,RequirementDetails, ServiceConditions, PaymentTypes, BidExpiry]). In addition, we also make sure that the DMP security protocols carry encrypted components that are in distinctive formats so as to prevent the oracle attack [11]. This is illustrated in Message 6 in Fig 2b’s protocol whereby MIA did not forward the exact message 5, TTrustCA, UTAID, NMIA, KUTA(public), KUTA,MIA, STrustCA(H[ TTrustCA, UTAID, NMIA, KUTA(public), KUTA,MIA]) it received from TrustCA, to UTA. Others include: • We have freshness indicators for two different requirements; a nonce is used to maintain the freshness of a protocol run while a timestamp is required to ensure the freshness of particular encrypted information such as message or nonce, in order to prevent replay attack and oracle state. The nonce can be interpreted and used as a key to prevent a similar issue of misinterpretation such as

a component’s functionality. Besides that, a nonce is frequently employed in situation where little or no direct relationship is required to elaborate between the identities/ aliases. The key reason for this is that the nonce is difficult to correlate between the identities/ aliases since they are only random numbers. This argument is illustrated in a) the protocol for session key establishment between the user and the DMP, and b) paging protocol where NUTA (Fig 2a & 2b) and NUHA (Fig 4) are explicitly utilised to represent message identity of respective protocol run. • The entity authentication is assisted by public key cryptography whereby a trusted authenticator, TrustCA, is involved. Further to the existing authentication mechanisms for key distribution and message authentication, we have also proposed a separate security protocol for mutual authentication for mobile user wishing to initiate a connection request to the DMP. Virtual identities (for agent and service identification) are used to avoid an intruder guessing or correlating the relationships between the different administrative and supporting entities for the service requestor and the bidder throughout the DMP operation. • Control of information release is achieved in several ways in the DMP: the negotiation procedures (1 and 2 stages), digital signatures, encryption techniques (that are assumed to be provided by network), trust policy control (or authorisation to access and rights to forward using Tagright). The policy requirement is implemented at the system level. Theft of rights and rights replication ought to be counteracted and these problems can be unravelled by one of the secrecy mechanisms such as digital signature. With these measures employed in the protocols, assurance of the DMP security can then be pursued; only a specified or legitimated entity/ agent can gain access to the application such as bid evaluation so as to protect DMP entities from Denial of Service and misuse of resources. This property is particularly imperative to the security manager and the market registry. Only when these security requirements are met, robust and safe adoption of the DMP’s trading platform can be achieved. If any of these fails, a penalty should be applied and the regulation authorities in the marketplace must remove any unapproved act. IV. CONCLUSION Our proposed solutions are largely focused on the interaction procedures between various administrative agents at different DMP negotiation stages. We attempt to cover key protection measures required for security purposes, using simple but vital security mechanisms (e.g. digital signatures). Understanding the real behaviour of a security protocol is a very demanding task due to the immense amount of possible malicious actions. Weaknesses in such protocols are also hard to identify, as they can be the result of subtle design flaws. To avoid further complexity to the protocol verification, we

consider less concurrently running interacting protocol sessions at one time. Negotiation rules and negotiation requirements are also incorporated in order that the mobile industry can conveniently and safely request service negotiation via the DMP. New sets of protocol are also developed for use: with or without the control of a service provider and to securely support the different auction methodologies (either direct or multi negotiation strategies). With that, informal protocol verification in the DMP’s security protocols is being conducted to identify the anticipating weaknesses. However, to ensure the designed security protocols of the DMP are truly safe and to prevent insecure protocols reaching the public domain, our future work will examine formal verification techniques [10] to provide thorough evaluation of the DMP’s security protocols. ACKNOWLEDGMENT The work reported in this paper has formed part of the PDE area of the Core 3 Research Programme of the Virtual Centre of Excellence in Mobile & Personal Communications, Mobile VCE, www.mobilevce.com, whose funding support, including that of EPSRC, is gratefully acknowledged. Full detailed technical reports on this research are available to Industrial Members of Mobile VCE. REFERENCES [1]

Irvine, J., “Adam Smith Goes Mobile: Managing Serviced Beyond 3G with 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 Digital Marketplace”, European Wireless 2005, Cyprus, Apr 2005. [3] Banksafeonline.org.uk – General advice on staying safe online, http://www.banksafeonline.org.uk/advice.html [4] Computer Crime and Intellectual Property Section (CCIPS) of the Criminal Division of the U.S. Department of Justice - Cyberethics Web Sites, http://www.cybercrime.gov/links1.htm [5] Franklin, M. K. and Reiter, M. K., “The Design and Implementation of A Secure Auction Service”, Proc. of IEEE Symposium on Security and Privacy, 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 Journal of Information Systems, Vol.5(2), pp.75-84, 1996. [8] Fatima, S. S., Wooldridge, M. J. and Jennings, N. R., “Multi-issue Negotiation Under Time Constraints”, Proc. of the 1st Int’l Joint Conf. On Autonomous Agents and Multi-Agent Systems, Bologna, Italy, 2002. [9] “FIPA Contract Net Interaction Protocol Specification”, Foundation for Intelligent Physical Agents, http://www.fipa.org/specs/fipa00029/, Dec. 2002. [10] Bella, G., Massacci, F., and Paulson, L. C., “Overview of the Verification of SET,” Int’l Journal on Information Security, 2004. [11] Lowe, G., “Some New Attacks upon Security Protocols”, Proc. of the 9th IEEE Computer Security Foundations Workshop, 1996.