www.elsevier.com/locate/comcom

Computer Communications 29 (2006) 2308–2321

Secure brokerage mechanisms for mobile electronic commerce

Oscar Esparza *, Jose L. Munoz, Miguel Soriano, Jordi Forne

Department of Telematics Engineering, Universitat Politecnica de Catalunya, C/ Jordi Girona 1 i 3, Campus Nord, Mod C3, UPC, 08034 Barcelona, Spain

Received 1 August 2005; received in revised form 30 November 2005; accepted 3 March 2006Available online 3 April 2006

Abstract

The possibility of making the Internet accessible via mobile devices has generated an important opportunity for electronic commerce.Nevertheless, some deficiencies deter a massive use of m-commerce applications. Security and easiness of use are unavoidable conditions.The use of brokerage systems constitutes an interesting solution to speed up the information delivery to the users. Moreover, brokers canuse mobile agents to efficiently and easily perform the search and retrieval of commercial information in the Internet. Although themobile agent technology is a very suitable choice for the m-commerce scenario, there are security issues that hinder its use. In particular,an important aspect that must be solved for the m-commerce scenario is the mobile agent protection from manipulation attacks per-formed by malicious hosts. The first part of this paper describes a mechanism to reach this protection. We describe how to use softwarewatermarking techniques in the mobile agent to detect manipulation attacks, and how the broker can be used to punish the malicioushosts. Once an m-commerce site is selected by the user, an end-to-end secure transaction must be established. The transaction can useseveral protocols, from a simple secure TLS channel to send a credit card number until a sophisticated payment protocol. In any case,Public Key Certificates (PKCs) are required for these protocols. It must be stressed that certificates management is a heavy process andthat clients in the brokerage scenario are usually resource-limited. For this reason, the best option is that clients delegate this task to thebroker. Notice that the broker is a Trusted Third Party (TTP) and, in general, it is not resource-limited. Therefore, the broker is appro-priate for storing and managing PKCs. The second part of this paper addresses this issue, with a particular emphasis in the certificatestatus management which is the most complex task of certificate management.� 2006 Elsevier B.V. All rights reserved.

Keywords: Broker; M-commerce; Mobile agent; Public Key Certificates (PKCs)

1. Introduction

The access to the Internet by means of mobile devicespotentially increases the number of users of e-commerce.For instance, one of the novelties of m-commerce is thepossibility of attracting clients in the neighborhoods ofcommercial and/or service centers by providing them withthe appropriate information in a short time. Unfortunate-ly, there are some aspects that hinder a massive implemen-tation and development of m-commerce services if they arecompared to habitual e-commerce services. Most of thesedrawbacks are related to the particular characteristics of

0140-3664/$ - see front matter � 2006 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2006.03.005

* Corresponding author. Tel.: +34 934010972; fax: +34 934011058.E-mail addresses: oscar.esparza@entel.upc.es (O. Esparza), jose.

munoz@entel.upc.es (J.L. Munoz), soriano@entel.upc.es (M. Soriano),jforne@entel.upc.es (J. Forne).

the wireless environment (usually less bandwidth, lowerlatency, less stability of connections, less predictable avail-ability) and the inherent constraints of the mobile devices(less powerful CPU, less memory, limitations on powerconsumption, form factor of displays, etc.). Additionally,there are other security drawbacks that can appear in thesewireless scenarios and that must be solved before usingm-commerce applications massively [20].

The use of a broker between the wired and the wirelessnetwork can ease the access to web information from themobile terminals, and it can also alleviate some of thesesecurity constraints. The main function of a broker is buf-fering and caching the information [21] in order to re-use it,and also sending useful data to mobile users in a predictivemode, reducing the overall data traffic in the wireless link.The solution presented in [26] was based on a broker withcache and proxy systems that delegates the information

O. Esparza et al. / Computer Communications 29 (2006) 2308–2321 2309

search and retrieval tasks to mobile agents. It also inte-grates in the broker the management of Public Key Certif-icates (PKCs) for securing end-to-end m-commercetransactions. Nevertheless, in that work neither the secureoperation of mobile agents nor the PKC status manage-ment was addressed. In this article the authors summarizethe improvements that must be performed over the brokerscenario to improve the security of the system.

The rest of the paper is organized as follows: Section 2reviews some typical issues of brokerage systems for m-commerce. Section 3 describes a solution to protect thesearch agents from manipulation attacks performed bymalicious hosts, as well as the way to punish them. Section4 deals with the PKCs management for securing m-com-merce transactions. Finally, some conclusions can be foundin Section 5.

2. Broker structure

This paper pretends to improve some aspects of the bro-ker architecture which was previously presented in [26].However, before introducing these improvements a shortoverview of this broker architecture is presented. This sec-tion also introduces some actual scenarios for brokeragesystems. Later, some aspects about how to manage mobil-ity can be found.

2.1. Broker functionalities

Fig. 1 shows a general view of the brokerage system. Thebroker acts as a mediator between the mobile users in thewireless network and the servers in the wired network(Internet). Mobile users can request for information or ser-vices in the Internet, these requests arrive to the broker,which creates a mobile agent programmed with somesearch patterns or service negotiation instructions. Thismobile agent is sent to the Internet to perform the taskson behalf of the user and, when finished, it returns to thebroker. The results are sent back to the mobile user in aresponse message, and additionally the broker can storethem in order to re-use these data in other requests. Thebroker must also provide access to a Public Key Infrastruc-ture (PKI) to secure the end-to-end transactions withselected m-commerce sites when needed.

WirelessNetwork

BROKERRequest

Response

Fig. 1. Broker a

Fig. 2 shows the main functionalities of the broker,which are detailed below:

(1) Information search and retrieval: tasks such assearching, advising, contacting, comparing, filteringand facilitating access to databases perfectly fit formobile agent technology [5]. In this sense, mobile agentscan perform some tasks on behalf of a user while themobile device remains off-line, which is very desirableon a noisy weak link with unpredictable disconnection.(2) Intermediate storage: the broker stores a copy of theinformation that it receives. This allows the broker to re-use these data in the transactions of other mobile users.Accordingly, the information must be organized insideproxy and cache systems to ease and speed up its searchinto the broker.(3) Customer Relationship Management (CRM): theknowledge of the user profile allows to manage theuser’s needs and wishes, and to deliver the services ina predictive fashion. The user profile can be managedand updated dynamically, depending on previous trans-actions or other external information sources. In partic-ular, in the wireless environment CRM can profit fromthe facilities of the push mechanism of current mobilecommunications protocols.(4) Certificate management: the access to a PKI is need-ed to provide most of the security services, such as integ-rity, privacy, authentication and access control. Thebroker can make lighter these tasks to the mobile usersby storing and managing Public Key Certificates (PKCs)and the status of these PKCs.

This paper deals with the mechanisms that the authorspropose to improve functions 1 and 4 to enhance the over-all usability and security of the brokerage system. Thesemechanisms are discussed in Sections 3 and 4, respectively.

2.2. Actual scenarios

The IST-FP6 SIMPLICITY project founded by theEuropean Union [1] works in an actual scenario for thebroker architecture. The goal of this project is reducingthe complexity of adapting systems beyond 3G byend-users and service providers mainly by: (1) providing

Internet

e-commerceservers

Mobile Agent

PKI

rchitecture.

TCP/IP

SECURITY

Java Virtual Machine Directory services Data mining User certificates

SEARCHINTERMEDIATE

STORAGE

CUSTOMERRELATIONS

MANAGEMENT

CERTIFICATEREPOSITORY

Informationsearch and retrieval

Cache and proxysystem

User profiling OCSP

Multi-Agent systemContent

managementPersonalized

content deliveryCRL management

Fig. 2. Broker functionalities.

2310 O. Esparza et al. / Computer Communications 29 (2006) 2308–2321

automatic customization of user access to services and thenetwork; and (2) automatically adapting services to termi-nal characteristics and user preferences.

SIMPLICITY specifies a system architecture encom-passing the Simplicity Device (SD) and the BrokerageFramework, and describing their interaction at the termi-nal (Terminal Broker) and the network (Network Broker)levels. This architecture defines a flexible and adaptableframework for assigning functionality to the network, theterminals and the SD. This flexibility is achieved via poli-cy-based technologies and user profiles.

In SIMPLICITY, an all-IP network is assumed as a ref-erence network scenario, where the Network Broker acts asan intelligent edge to the IP networking domain (seeFig. 3). The network is assumed to host and grant accessto a bunch of services, which can be as simple as the remotecontrol of an entertainment device via an infrared port, oras complex as to require location awareness, QoS support,message exchanges with network databases, etc.

Mobility, Co& Control

Mobility Gateway

Netw

APAP

APAP

Storage

Servers

Simplicity -enabledterminal

Fig. 3. SIMPLICITY all-

The Network Broker architecture comprises a policyrepository and various subsystems handling the differentavailable services and capabilities of the access network(e.g., AAA services, security, mobility management, etc.).One of these subsystems handles the interaction betweennetwork brokers in adjacent networks, which is needed toprovide an optimized end-to-end service across networkdomains.

Other actual scenarios are based on other reference net-works, different from all-IP networks. This is the case ofthe IST-FP6 UBISEC [2], another project founded by theEuropean Union, which it is based on Mobile NetworksOperators.

2.3. Managing mobility in brokerage systems

The broker architecture previously presented is intendedto facilitate the Internet access to mobile users. Neverthe-less, the management of mobility in brokerage systems

Internet

PSTN

IP domain

InternetApplication Platforms

InternetApplication Servers

MediaGateway

nnection Servers

ork Broker

IP network scenario.

O. Esparza et al. / Computer Communications 29 (2006) 2308–2321 2311

was not addressed in [26]. Although this paper is notfocused on mobility, the rest of this section discusses someaspects of this topic to provide a more general view of thebroker scenario.

It is worthy to clarify the concept of mobility. Accordingto the ITU-T Study Group 16 on Multimedia terminals,systems and applications [3], there is a differentiationbetween:

• Seamless mobility: The user/terminal is able to changethe network access point, as she/it moves, withoutinterrupting the current service session, i.e. handoversare possible. This kind of mobility is addressed in theSIMPLICITY project.

• Nomadic mobility (roaming): The ability of a user/ter-minal to change the network access point as she/itmoves while the service session is completely stoppedand started again, i.e. discrete changes of location aredone. This kind of mobility is addressed in the UBISECproject.

It is a strong requirement of the system that the brokerhas to be fully trusted by the mobile user, since it managesprivate user information and takes charge of several sensi-tive operations on behalf of the user, such as informationsearch and retrieval (Section 3) and certificate management(Section 4). In general, a user trusts a reduced set of bro-kers, and hence she maintains the attachment to a givenbroker as she moves and changes the network accesspoint.1 Nevertheless, when a new trusted broker is reach-able the user may change her attachment to increaseperformance.

The rest of this section discusses the security require-ments that the brokerage system must fulfil to supportnomadic and seamless mobility.

2.3.1. Seamless mobility

First of all, we consider the case when the user is goingto change her attachment from broker A to broker B, bothbelonging to the same trust domain. This situation typical-ly occurs when the user changes the broker due to a hand-over within the same network operator. In this case we canconsider that the user identically trusts both brokers(because they belong to the same network operator) andthe brokers also trust each other. Therefore, the users con-text can be securely transferred between the two brokers.

Fig. 4 shows a sample protocol for seamless mobility inbrokerage systems. The user U is initially attached to thebroker A, where some personalisation data is stored (theuser profile). These are the steps that must be followed toattach the mobile user U to a new broker B in the sametrust domain:

1 Handover or roaming do not necessarily imply the change of thebroker.

(1) The user U initially joined the network throughbroker A, which was previously trusted by the user.Mutual authentication between the user and the brokerwas required. Then, the broker A is storing the userprofile.(2) The mobile user U reaches broker B, that it is alsotrusted by the user because it belongs to the same trustdomain than A (they belong to the same networkoperator).(3) Mutual authentication between U and B is required.(4) The broker B needs the user profile, so it asks thisinformation to broker A. Access control mechanismssupporting strong authentication and authorization arerequired.(5) This user profile must be securely transferred from Ato B. A secure communications channel supportingauthentication, integrity and confidentiality is estab-lished, for instance using standardized secure communi-cations protocols such as TLS or IPSEC.

2.3.2. Nomadic mobility

The support for nomadic mobility is straightforward. Asthe new broker B belongs to a different trust domain, it isdifficult to establish trust relationships between bothbrokers A and B (probably because they belong to differentnetwork operators with restricted roaming agreements). Asa consequence, the broker A will not transfer the userprofile to broker B because it will probably contain privateinformation. Therefore, the broker B must create a newuser profile for the user U.

3. Information search and retrieval

Millions of users depend on consulting the hugeamount of information disseminated around the Inter-net. Present ways of looking for information are usuallyslow and tedious. The success of new generation servicesis subject to the appearance of the appropriate mecha-nisms to consult the data and to make easier the user’stasks. These mechanisms should be capable of selectingthe wanted data from the rest and to give them to theuser in a short time. In our opinion, the use of mobileagents is a natural way to provide these new generationservices.

Mobile agents are software entities that consist mainlyof code, data and state, and that can migrate from hostto host performing actions autonomously on behalf of auser. Mobile agents not only fit naturally to heterogeneousenvironments, but they also permit an off-line and autono-mous execution and they improve aspects as network loador latency in comparison with habitual distributed systemsbased on message passing. For this reason, they can beused to give support to these wireless terminals that usuallyhave a lack on resources like bandwidth, CPU or battery.The mobile agent programming paradigm also introducesflexibility in service creation because the user can sendthe program logic directly to the server, instead of using

USER U

Trust Domain 1Operator 1

1

2

3

4

5

BROKER A

UserProfile

BROKER B

UserProfile

Fig. 4. Seamless mobility in brokerage systems.

2 In most cases, these techniques are subject to the existence of a PKI.

2312 O. Esparza et al. / Computer Communications 29 (2006) 2308–2321

static interfaces of classical distributed services. In conse-quence, mobile agents are especially useful to performautomatically functions in electronic services [6] likedistributed and parallel computing, data mining, activenetworks, network management, etc. Mobile agent tech-nology also fits perfectly to the m-commerce environmentbecause the mobile users can delegate to the mobile agentstedious tasks as information search and recovery, evenwhen these users are off-line.

3.1. Mobile agent security

Despite the overall benefits, massive use of mobileagents is mainly restricted by security issues [19,18]. It isworth remarking that mobile agent systems must face thenormal security problems of current distributed systems,and additionally others that appear due to the code mobil-ity. Considering that there are two main entities in this sce-nario, the mobile agent (or simply agent) and the executionplatform (host), these are the main threats that can befound [4]:

• Host protection: the system administrator’s duty is pro-tecting the hosts from attacks that try to exploit theweaknesses of the execution platform. In this sense,the hosts must be protected against the attacks thatcan perform agents while executing their code. A mali-cious mobile agent can try to eavesdrop or manipulateany kind of available data, or even can perform a denialof service attack in order to make the platform breakdown. The majority of these attacks can be detected oravoided by using techniques already in use in currentdistributed systems, like sand-boxing and a properaccess control.

• Communications protection: the agent can receiveattacks from any external entity while it is migratingfrom host to host. These attacks can be solved by using

well-known cryptographic protocols.2 These securitymeasures do not avoid the attacks, but can be used laterto look for responsibilities.

• Agent protection: while executing, the mobile agent canreceive attacks from other agents or from the executionplatform itself. On one hand, the attacks between agentscan be solved by using separate environments duringexecution. On the other hand, it is not so easy to protectthe agent from the attacks of the host. In fact, this isconsidered the most difficult security problem to solvein mobile agent systems for most of the authors[13,19]. The host has complete control of the executionand hence it can read or modify any part of the mobileagent: the code, the data, the state, the communications,the execution flow, or even the results. This is the reasonwhy there is no published solution that protects mobileagents completely from the attacks of executing hosts.These kinds of attacks are also known as the problemof the malicious hosts.

This problem of the malicious hosts is illustrated in thenext example for an m-commerce scenario with an interme-diate broker.

Example. A mobile user wants to find the most economicflight from Barcelona to Paris, so it demands this in-formation to the broker through the wireless network. Toperform this task, this mobile user sends a request to thebroker with an initial prize of $300. To start the search, thebroker creates a mobile agent programmed to comparethe prize obtained in the current airline with the cheapestprize obtained in the previous hosts. If the current airlinehas lower prize for this flight, the mobile agent will savethis prize in the variable bestprize and will set the variable

O. Esparza et al. / Computer Communications 29 (2006) 2308–2321 2313

bestairline to the current airline name. An easy example ofthe program logic in pseudo-code of this search agent canbe found in Fig. 5. This agent will migrate autonomouslyfrom server to server executing its program logic. So then,when the execution finishes in the last server, the mobileagent returns to the broker with the most economic prize inbestprize and the company that provides this service inbestairline. For simplicity, cryptographic protection to anypart of the mobile agent is not provided. Fig. 6 shows thecomplete process if all the servers act honestly.

Now consider what would happen if the last of theservers acts dishonestly and changes the prize in itsdatabase to a value that is lower than the prize containedin the variable bestprize. As a result, the variable bestairlineis set to this dishonest server and the product is finallybought to it. In this case the host carries out aneavesdropping attack reading the variable bestprize, andwith this privileged information the host changes itsdatabase in order to sell the product. Eavesdroppingattacks cannot be detected nor avoided because the hostcan access the entire agent’s data to analyze them. Theproblem gets worse when a malicious server carries out amanipulation attack. For example, the first server can setdirectly both variables to whatever values it wants and canmake the agent returning home.

Current approaches to protect mobile agents can bedivided in two main categories: (1) attack avoidanceapproaches, that try to avoid the attacks before they hap-pen; and (2) attack detection approaches, whose aim isdetection after the attack has been performed. Detectiontechniques are not useful for services where benefits fortampering a mobile agent are greater than the possiblepunishment in case of detection. In those cases, attackavoidance techniques are most useful. Unfortunately, pub-lished attack avoidance approaches do not protect theagent completely.

Fig. 5. Example of

In our opinion, attack detection approaches are promis-ing because they are usually easier to implement andrequire less resources than avoidance ones. Attack detec-tion approaches permit the agent sender to know if itsagent was tampered during the execution due to illegalmodifications of code, data or execution flow. The aim ofthis kind of proposals is dissuading the malicious hostbecause detection can lead to a punishment. So then, theharder the punishment, the less attacks will be performed.This section explains a new attack detection technique thatcan be used to protect mobile agents in the brokerage sce-nario. The proposal is based on embedding a watermarkinto the mobile agent, i.e. Mobile Agent Watermarking(MAW). The rest of this section summarizes how theMAW approach works, and how can affect its use to thebrokerage scenario.

3.2. Software watermarking and mobile agent security

Watermarking is normally used to provide copyrightprotection for digital contents. A distributor embeds amark into a digital object, so ownership of this digitalobject can be proved. This mark is usually a secret messagethat contains the distributor’s copyright information. Theproblem arises when a dishonest user tries to delete themark of the digital object in order to claim the authorshipbefore redistribution. In consequence, the strength ofwatermarking schemes must be based on the difficulty oflocating and changing the mark. Most of the watermarkingapproaches try to protect the intellectual property of multi-media objects, especially images. However, there are someproposals that try to protect the copyright of a piece ofcode [8,27].

Despite software copyright protection and mobile agentsecurity are problems with lots of similarities, nobodytried to conjugate them before. In both cases there is an

a search agent.

BROKER(Origin Host)

W

W

Original Mobile Agent Marked Mobile Agent

Agent Sending

W

WATERMARK

InternetWirelessNetwork

BROKER(Origin Host)

Request: flight Barcelona-Parisinitialp rize: 300

Response: Airline2, 250

bestprize=300bestairline=void

PKI

1

6

2

3

4

AIRLINE1$270

AIRLINE2$250

AIRLINE3$310

5

bestprize=270bestairline=AIRLINE1

bestprize=250bestairline=AIRLINE2

bestprize=250bestairline=AIRLINE2

Fig. 6. Flight search example.

2314 O. Esparza et al. / Computer Communications 29 (2006) 2308–2321

executable code that goes to and comes from the networkand must be protected against manipulations. In the form-er, the aim is protecting the authorship of this code fromthe attacks of malicious users that try to modify, substituteor delete the embedded watermark. For this reason, pub-lished software watermarking techniques try to protectthe watermark mainly from semantic preserving programtransformations,3 for instance obfuscation, transformationor optimization of programs. On the contrary, in mobileagent security the aim is assuring that the code was execut-ed properly. The objective of the malicious hosts is manip-ulating the code to obtain an execution on their own profit.Finally, notice that software watermarking techniques aremore useful for the agent’s protection than for the copy-right protection because the use of semantic preservingprogram transformations do not affect to the tasks of theagent’s code.

3.3. Mobile Agent Watermarking

The rest of this section summarizes the main character-istics of the MAW approach.4 Later, we describe the appli-cation of MAW to the brokerage scenario.

3.3.1. Watermark embedding and transference

Before sending the agent, the broker embeds a water-mark into the agent’s code by using software watermarkingtechniques [8]. These software watermarking techniques arenot used to protect the agent’s copyright, but for detectingmanipulation attacks performed during the execution.After that, the broker sends this marked mobile agent tobe executed in the Internet servers. In each server, the exe-cution of the marked code creates a logically structureddata container where the embedded watermark will betransferred. The agent can put any kind of informationinto the container, for example dummy data, input data,intermediate variable values, data that come from commu-nications, and finally the results. The agent diffuses (repeatsvalues) and confuses (changes values) all this informationinto the container. The way this information is put into

3 Transformations that affect to the appearance of the code but do notmodify the tasks that it performs.

4 Further information about this approach can be found in [11].

the container and the information itself constitutes thetransferred watermark. In short, the container is the digitalcover where the agent’s code transfers the embedded water-mark, and hence it can be used as a proof to verify the exe-cution integrity. Furthermore, the container hides theresults to the malicious servers, that is to say, a maliciousserver should not tell the difference between the executionresults and the transferred watermark. These watermarkembedding and transference processes are shown in Figs.7 and 8, respectively.

All the transferred data must be properly signed toavoid manipulations during the agent’s journey. The agentmust be signed by the origin host to assure the integrity andauthenticity of the code and data. So then, any manipula-tion performed over these data will be detected by thehosts. In the same sense, each container must be signedby its host. So then, any kind of manipulation over the con-tainers will be detected by the origin host. Additionally, theagent can be sent encrypted to avoid eavesdropping attacksduring the agent’s journey, so only the hosts will read itscontents. In the same sense, the hosts can encrypt the con-tainers to assure their confidentiality, so only the originhost can read them.

SoftwareWatermarking

Code

Data

Code

Data

Fig. 7. Watermark embedding.

AIRLINE2

W

ContainerAIRLINE1

W

ContainerAIRLINE1

ContainerAIRLINE2

CodeW

Data

Container AIRLINE2

dummydata

input data

communicationsdata

constants

RESULTS

Intermediatevariablevalues

WatermarkTransference

Frompreviousserver

To thenext

server

Fig. 8. Watermark transference.

O. Esparza et al. / Computer Communications 29 (2006) 2308–2321 2315

3.3.2. Attack detection

When the agent returns home, the broker tries to detectthe attacks performed during execution. To do so, the brokerverifies that all the containers fulfill a set of integrity rules.These rules must be inferred from the modifications per-formed over the original agent’s code during the watermarkembedding process. If a container does not fulfill the integri-ty rules, this means that the corresponding server modifiedthe mobile agent, so it is malicious. Notice that the way thebroker uses to verify the execution integrity is the same forall the servers, but this does not mean that all the containershave the same watermark. In fact, the transferred water-marks are different because they depend on each execution.Consequently, colluding servers cannot extract any informa-tion of the watermark comparing their containers. Justremark that none of the entities can perform a repudiationattack because all the data are properly signed.

3.3.3. Example of MAW

Fig. 9 shows some easy modifications that can be appliedto the agent of Section 3.1 to detect manipulation attacksusing MAW. Again for simplicity, cryptographic protectionto any part of the mobile agent has not been provided.

The agent’s code must transfer the watermark and hidethe results into the container. The techniques used in theexample are based on diffusing 5 and confusing 6 the infor-mation into the container:

5 Diffusing values means repeating these values into several differentplaces.

6 Confusing values means modifying these values to different ones, forexample by adding constant values.

• The agent’s code can introduce any kind of availabledata into the container, like input data, constants orintermediate variable values, and finally the results.

• The agent can ask for information in which the user isnot interested in. For instance, the agent of Fig. 9 asksfor the price of a flight from Madrid to Paris, but theuser is only interested in the flight from Barcelona toParis.

• The container must be dependent on the execution flowin order to detect any change in it.

• None of the parts of the mobile agent must give infor-mation about its intentions to make the code harder toanalyze. The more difficult to understand is the code,the more secure is the approach. In this sense, the useof techniques like obfuscation [9,14] can be additionallyuseful.

Fig. 10 shows the containers that would be obtained ifall the three airline servers act honestly and give the realprices of their databases to the agent. The containers ofthe example are located inside the array of integers f [ ][ ].Fig. 11 shows some of the integrity rules that can beinferred from the marked code. Applying these rules tothe containers it is possible to verify that all the hosts werehonest. This Fig. 11 also shows the rules to extract the exe-cution results from the containers.

3.4. Advantages and drawbacks of MAW

MAW can be considered a lightweight attack detectiontechnique compared with other detection approaches[28,22,15] because it permits to verify the execution integrity

Fig. 9. Search agent using MAW.

2316 O. Esparza et al. / Computer Communications 29 (2006) 2308–2321

of all the servers without thinking in terms of suspicionand without re-executing the agent. Additionally, the serv-ers do not need to store any kind of proof. However,MAW has some drawbacks that affect mainly to the per-formance of the system. First of all, the broker mustembed the watermark into the agent’s code and must inferthe rules from these modifications. This means that thereis an increase in the original code size, because embeddinga watermark always means that some overhead is added

to the code. Additionally, the mobile agent must carry adata container for each server, instead of just the resultsof the execution. Finally, the mobile agent model is notgeneral because it is required that the agent comes backto the broker with all the containers when the transactionfinishes.

3.5. Application to the brokerage system

Regarding the use of MAW in the brokerage system, itis not restricted by the drawbacks that have been presentedpreviously.

• Lose of performance: the code size and execution timecan be substantially increased depending on theembedded watermark, so creating, storing, sendingand running marked agents could consume moreresources than usual. As Collberg et al. pointed out,recent studies about some graph theoretic softwarewatermarks [7] expose that the size of the code couldbe increased in a 40–75%, and that the execution timecould be increased an average of 22%. We considerthat this fact can be a restriction when the agent senderhas limited resources (less bandwidth, lower latency,less stability of connections), like a mobile terminalconnected to the wireless network. For this reason,mobile devices do not send mobile agents directly,but the broker performs this task. In fact, it is easierto increase resources like CPU, memory or bandwidthin the broker and in the Internet servers than in themobile devices.

• Mobile agent model: the mobile agent must return tothe broker after the execution. This agent model fitsperfectly with the search and retrieval needs of thebroker. Each query of a mobile user can lead the bro-ker to create a mobile agent that will migrate fromhost to host taking execution results and finally, thisagent will return to the broker with all the askedinformation.

3.6. Host revocation

Attack detection approaches like MAW are not enoughto protect the mobile agent on their own. This kind ofmechanisms must be attached with some punishment poli-cies. Usually, an honest server will turn into maliciousbehaviour only in case that the benefits for tampering theagent would be greater than the punishment. Thus, theharder the punishment, the less attacks will be performedby these servers.

This paper explains a punishment based on host revoca-tion, that is to say, avoiding the malicious servers to receiveagents any more. The aim of host revocation is (1) dissuad-ing the honest servers from performing attacks becausethey can be punished, (2) punishing them in case that thisdissuasion technique does not work, and (3) avoiding theattacks of previous malicious hosts. If a server acted

Fig. 11. Rules that must fulfill the containers of the example.

7 In [11] can be found a more detailed explanation of how these proofswork, and how they can be sent securely.

Origin Host

270Barcelona-Paris

280Madrid-Paris

250Barcelona-Paris

290Madrid-Paris

310Barcelona-Paris

250Madrid-Paris

f[][]

p1=753p2=1154

p1=593p2=944

p1=553p2=944

p1=553p2=854

Databases

1602140775596191068513

1482149787584110006859

1612153784588110007255 Container Airline1

Container Airline2

Container Airline3

Airline1 Airline2 Airline3

Fig. 10. Honest execution of the example agent.

O. Esparza et al. / Computer Communications 29 (2006) 2308–2321 2317

maliciously once, it can attack other agents again, so avoid-ing this server to receive agents impedes possible attacks.

The broker must distinguish malicious servers from thehonest ones to avoid sending agents to them. Unfortunate-ly, it is not possible to know if an honest host can turnmalicious in the current transaction. However, it is possibleto know if a host acted maliciously in the past if a TrustedThird Party (TTP) stores a list with all the malicious hosts.The lack of a TTP with these punishment capabilities canbe solved by adding a Host Revocation Authority to themobile agent system [10]. The HoRA must be consideredan independent entity in the mobile agent system, in thesame way as the Certification Authority (CA) is consideredan independent entity in the Public Key Infrastructure(PKI). Each host that wants to execute agents must askthe HoRA to issue a Host Certificate (HC). HCs are similarto Attribute Certificates (ACs) [17] because they bind the

mobile agent execution capability to the host identity.When a server acts maliciously, the HoRA only needs torevoke the corresponding HC to avoid that the brokersends agents to it. Obviously, the HoRA needs proofs torevoke a host. In this sense, the broker must use one ofthe existing detection and proving approaches [28,11].

These are the main tasks that the HoRA must performto achieve the punishment mechanism [10]:

• Host revocation: the HoRA is responsible for manag-ing the revocation information of its database and, inparticular, is responsible for adding new malicioushosts. Obviously, the HoRA must have proofs ofthe malicious behaviour before adding a new host.These proofs must be provided by the broker anddepend on the detection mechanisms used. Forinstance, in the MAW approach the proofs are thecontainers. As it has been said, all the exchanged datamust be properly signed to avoid manipulations dur-ing the transference. In this case, the broker must senda signed message with all the proofs, so its integrityand authenticity can be assured. So then, any kindof manipulation over this message will be detectedby the HoRA. Additionally, this message can be sentencrypted to avoid eavesdropping attacks, so only theHoRA will read its contents. The HoRA will alsoanswer with a signed message containing the decisionabout the revocation.7

• Host Status Checking: before sending an agent, the bro-ker must consult the status of the servers of the agent’sitinerary to delete all the revoked. As a result, revokedservers will not receive agents any more. To do so, theHoRA issues a Host Revocation List (HRL), i.e. a

InternetWirelessNetwork

BROKER

PKI

AIRLINE1

AIRLINE2

AIRLINE3

End-to-endtransaction

HoRA CA

H-OCSP

HRL CRL

Certificate managementRepositoryOCSP ResponderPath ValidationAgent’s itinerary controlHost Revocation

Fig. 12. End-to-end secure transaction.

8 Just remember that in the case of the HRL, it is only distributed to thebroker and therefore it does not affect to the wireless link or wireless client.

2318 O. Esparza et al. / Computer Communications 29 (2006) 2308–2321

digitally signed list of revoked HCs. Then, the brokermust download a copy of this HRL and update itperiodically.

Fig. 12 shows the HoRA location into the brokeragescenario. The broker must be capable of downloading theHRL periodically in order to perform the host statuschecking, that is to say, the broker must know the revokedservers to avoid sending agents to them. Furthermore, thebroker is responsible for detecting attacks to its agents (forinstance using MAW), and to send the proofs to the HoRAto revoke the new malicious hosts.

4. Certificate management

From the example of Section 3, let us consider that final-ly, the user selects Airline2 as the most economic airline.Then, the user must establish an end-to-end secure transac-tion with the Airline2 site to order the ticket (see Fig. 12).The transaction can use several protocols, from a simplesecure TLS channel to send a credit card number until asophisticated payment protocol. In most cases, PublicKey Certificates (PKCs) are required for these protocols.It must be stressed that certificates management is a heavyprocess and that clients in the brokerage scenario areresource-limited. For this reason, the best option is thatclients delegate this task to the broker. Notice that thebroker is a TTP and, in general, it is not resource-limited.Therefore, the broker is the appropriate point in thescenario to be used as PKC repository. However, end usersnot only must have the PKCs available in the broker, butthey must also be able to check that the PKCs involvedin the transaction are valid at the time of usage, that isto say, the PKCs have not been revoked.

4.1. PKC status distribution

A solution to distribute the status of PKCs from thePKIs to the end users is to use Certificate Revocation Lists

(CRLs). A CRL is basically a digitally signed list ofrevoked certificates. The CRL has been standardized aspart of X.509 [29] and it has also been profiled for theInternet in [16]. Notice that in the case of PKCs, a list isnot as good idea as in the case of host certificates becausethe size of a CRL can be considerable. If CRLs are directlydistributed to the end entities, on one hand, this implies aconsiderable waste of bandwidth in the wireless link andon the other hand, a cache in the wireless terminal.8 To dis-tribute PKCs status data to end entities, there is an alterna-tive option called Online Certificate Status Protocol(OCSP) [25]. OCSP is a protocol that provides a signedyes/no status response about a certain certificate or certif-icates. In [23], we presented an analytical performancestudy about CRL and OCSP. From that study, it followsthat CRLs are not the best choice in a bandwidth con-strained link as it is the wireless link. However, CRLs arethe best option for status distribution between the PKIsand the broker because the status information containedin a CRL can be re-used by all the end users, while OCSPis the best option in the wireless link because of the reducedsize of the OCSP response that only contains the dataabout the asked certificates. Moreover, if there is a needfor transaction-specific authorization information, OCSPcan provide it by means of protocol extensions. However,OCSP is not free of vulnerabilities. Let us analyze it indepth to find its weak spots in our m-commerce scenario.

OCSP responses can contain three times in them:

• thisUpdate is the time at which the status being indi-cated is known to be correct.

• nextUpdate is the time at which newer informationwill be available about the status of the certificate.

• producedAt is the time at which the OCSP responder(broker) signed this response.

O. Esparza et al. / Computer Communications 29 (2006) 2308–2321 2319

The user may also send a nonce in its request. In thiscase, the broker has to include the nonce in the signaturecomputation, and thereby the request and the responseare cryptographically bound. However, a denial of servicevulnerability is evident with respect to a flood of queries.The production of a signature significantly affects responsegeneration cycle time, thereby exacerbating the situation.Unsigned error responses open up OCSP to another denialof service attack, where the attacker sends false errorresponses.

In order to alleviate these denial of service vulnerabil-ities, the broker may pre-produce signed responses speci-fying the status of certificates at a certain time [25]. Thetime at which the status was known to be correct shallbe reflected in the thisUpdate field of the response.The time at which newer information will be availableis reflected in the nextUpdate field, while the time atwhich the response was produced will appear in theproducedAt field of the response. However, the use ofpre-computed responses allows replay attacks in whichan old (good) response is replayed prior to its expirationdate but after the certificate has been revoked. Ourdeployment of OCSP should carefully evaluate the benefitof pre-computed responses against the probability ofreplay attacks. In this sense, notice there is the followingtrade-off:

The online signature consumes much processing time.To reduce the possibility of falling into denial of service,the broker may pre-compute the responses and storethem in a cache. But pre-produced responses are suscep-tible of generating reply attacks. To avoid the replayattacks, the broker needs to generate pre-producedresponses within a short period of time which consumesmany processing resources and this fact may lead thebroker again to denial of service.

4.2. H-OCSP

The result of the previous discussion is that the brokerwould benefit from a mechanism to pre-produce respons-es with low processing resources utilization. Below, weoutline our proposal called H-OCSP that reaches thistarget.

H-OCSP exploits the fact that a One Way Hash Func-tion (OWHF) is much faster to compute than a digitalsignature. When a pre-produced response needs to beupdated because its nextUpdate has become obsolete,a OWHF is performed to update this response insteadof a new signature. Using a OWHF will permit the repos-itory to update the responses more frequently withoutfalling into denial of service. H-OCSP is based on theEven et al. algorithm [12] and it works as follows: whena response is going to be pre-produced, the responderadds a hash chain to it. The hash chain permits the bro-ker to update the pre-produced response in successiveperiods with scarce resources utilization. The hash chain

results from applying d + 1 times a OWHF h over a secretnonce (1)

R!h

Rd!h

Rd�1!h� � �!h

Ri!h� � �R

2!hR

1!hR0 ð1Þ

Let us define the parameters involved in the process:

primaryUpdateValue (R) is the secret nonce. R isonly known by the responder (broker) and it is generat-ed for each new pre-produced response.maximumUpdateIndex (d) is the maximum numberof periods that a pre-produced response can beupdated.baseUpdateValue (R0) is the last value of the hashchain and it is included in the signature computationof the pre-produced response. R0 is computed by apply-ing (d + 1) times h over R

R0 ¼ hdþ1ðRÞ ð2Þ

currentUpdateValue (Ri) is computed by applying(d + 1 � i) times h over R

Ri ¼ hdþ1�iðRÞ ð3Þ

where i is the number of periods ‘‘D’’ elapsed from thedocumented one (the documented validity period is theperiod included in the response). D is defined as

D ¼ nextUpdate� thisUpdate ð4Þ

A relying party can verify the validity of a pre-producedresponse that it is living beyond its documented life-time, say, at time t, where t is included within the period[nextUpdate + (i � 1)D, nextUpdate + iD], bychecking the equality of Eq. (5)

R0 ¼ hiðRiÞ with i 6 d ð5Þ

It must be stressed that to forge a currentUpdate-

Value with the information provided by a previous updatevalue an attacker needs to find a pre-image of a OWHFwhich is by definition computationally infeasible.

It is obvious that if a pre-produced response becomesstale because the status of the certificate it refers changes,a new signature must be performed, in other words,H-OCSP is only applicable to responses that need toupdate their documented life-time. However, notice thatthe majority of the response updates are due to the factthat the documented life-times become obsolete, hencethe H-OCSP will have indeed a great impact over thebroker performance.

Notice also that H-OCSP produces the desired behav-iour of pre-produced responses:

For one thing, the responder (broker) can use pre-pro-duced responses with a small life-time which reducesthe risk of replay attacks. For another, the broker canupdate its pre-produced responses at low cost whichreduces the risk of denial of service.

2320 O. Esparza et al. / Computer Communications 29 (2006) 2308–2321

Apart from processing capacity in the broker, band-width in the wireless link can also be saved withH-OCSP. To do so, pre-produced responses are cachedby clients. Let us assume that a previous H-OCSPresponse for a certain certificate is stored in the client’scache. Then, if the client needs to check the status ofthe same certificate later, she can ask the responderfor a currentUpdateValue instead of downloadinga standard OCSP response which has a much biggersize. Moreover, if a client performs the majority of hisrequests for a small set of certificates while othercertificates are more rarely requested, it becomes likelyto have cached responses for these certificates and thestatus checking can be performed only sending thecurrentUpdateValue.

On the other hand, a client may wish to keep anOCSP response as a consumer protection issue. If a cli-ent performs an important or a delicate transaction, itmay later arise a conflict about the content of theexchanged messages. Usually, digital signatures per-formed during the transaction are used to solve this kindof non-repudiation trials. Therefore it is necessary tohave a proof of the status of the involved certificatesin the precise moment that the transaction was per-formed. Notice that the hash chain permits to store oldresponses for a certain certificate with a reduced storagecapacity. This storage can be performed by the broker oreven by the client for the certificates she considersimportant.

In [24], we presented and evaluated an ASN.1 proto-col for H-OCSP. The result of the evaluation was thatthe computational load of the H-OCSP responderdecreased relatively fast, when the H-OCSP respondertook advantage of the pre-computed responses. In thesteady state, we obtained that for our evaluation scenar-io the H-OCSP responder consumed around five timesless processing capacity than the standard OCSPresponder.

5. Conclusions

Brokerage mechanisms constitute an interesting optionfor m-commerce. Using a broker permits to store the infor-mation demanded by the wireless terminals in order to re-use it. This scheme reduces the content retrieval time in thewireless link. The broker can also delegate the search andinformation recovery tasks to mobile agents, and it canintegrate the user certificate management. The use of thesemechanisms implies the consideration of additional securi-ty aspects and this paper summarizes the work done by theauthors to improve them.

The first issue that addresses this paper is the mobileagent protection from manipulation attacks performed bymalicious hosts. The authors are not aware of any pub-lished work that completely solves this problem. In thiswork, the authors have presented an approach to solve thisproblem by means of Mobile Agent Watermarking (MAW)

and Host Revocation Authorities (HoRAs) that issue listsof revoked hosts (HRLs). If a host has been revoked it isconsidered malicious and it will not be part of any agent’sitinerary.

Finally, a secure transaction based on Public Key Certif-icates (PKCs) must be established between the m-com-merce site and the end client. PKCs management is aheavy process for a mobile client due to the constraintsin the handsets and the special features of the wireless envi-ronment. The second issue that this paper addresses is howcertificate management can be simplified with the delega-tion to the broker of critical tasks as certificate storageand certificate status checking. Regarding this last aspect,the authors present a new and more secure protocol calledH-OCSP for status checking to be used between the brokerand the end users.

Acknowledgments

We thank the anonymous referees’ valuable commentsand suggestions on the improvement of this paper. Thiswork is supported by the Spanish Research Council underthe projects SECONNET (CICYT TSI2005-07293-C02-01), ARPA (CICYT TIC2003-08184-C02-02), and theEuropean Research Council under the project UBISEC(IST-FP6 506926).

References

[1] IST SIMPLICITY Project: <http://www.ist-simplicity.org/>.[2] IST UBISEC Project: <http://www.ubisec.org/>.[3] ITU-T SG16: <http://www.itu.int/ITU-T/studygroups/com16/

index.asp/>.[4] D. Chess, Security issues in mobile code systems, in: Mobile

Agents and Security, LNCS, vol. 1419, Springer-Verlag, Berlin,1998.

[5] D. Chess, B. Grosof, C. Harrison, D. Levine, C. Parris, G. Tsudik,Itinerant agents for mobile computing, in: Readings in Agents, 1997.

[6] D. Chess, C. Harrison, A. Kershenbaum, Mobile agents: are they agood idea, IBM Research Report, 1995.

[7] C. Collberg, A. Huntwork, E. Carter, G. Townsend, Graph theoreticsoftware watermarks: implementation, analysis, and attacks, in: 6thInternational Workshop on Information Hiding, LNCS, vol. 3200,Springer-Verlag, Berlin, 2004.

[8] C. Collberg, C. Thomborson, Software watermarking: models anddynamic embeddings, in: Principles of Programming Languages 1999,POPL’99, 1999.

[9] C. Collberg, C. Thomborson, D. Low, A taxonomy of obfuscatingtransformations, Technical Report 148, The University of Auckland,1997.

[10] O. Esparza, M. Soriano, J.L. Munoz, J. Forne, Host revocationauthority: a way of protecting mobile agents from malicious hosts, in:International Conference on Web Engineering (ICWE 2003), LNCS,vol. 2722, Springer-Verlag, Berlin, 2003.

[11] O. Esparza, M. Soriano, J.L. Munoz, J. Forne, Punishing manipu-lation attacks in mobile agent systems, in: IEEE Global Telecommu-nications Conference (Globecom 2004), 2004.

[12] S. Even, O. Goldreich, S. Micali, Online/offline signatures, Journal ofCryptology 9 (1996) 35–67.

[13] W.M. Farmer, J.D. Guttman, V. Swarup, Security for mobile agents:issues and requirements, in: 19th National Information SystemsSecurity Conference, 1996.

O. Esparza et al. / Computer Comm

[14] F. Hohl, Time limited Blackbox security: protecting mobile agentsfrom malicious hosts, in: Mobile Agents and Security, LNCS, vol.1419, Springer-Verlag, Berlin, 1998.

[15] F. Hohl, A protocol to detect malicious hosts attacks by usingreference states, 1999.

[16] R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public KeyInfrastructure Certificate and CRL Profile, 1999. RFC 2459.

[17] ITU/ISO Recommendation, X.509 Information Technology OpenSystems Interconnection – The Directory: Authentication Frame-works, 2000. Technical Corrigendum.

[18] W. Jansen, Countermeasures for Mobile Agent Security, ComputerCommunications, Special Issue on Advanced Security Techniques forNetwork Protection, 2000.

[19] W. Jansen, T. Karygiannis, Mobile Agent Security, Special publica-tion 800-19, National Institute of Standards and Technology (NIST),1999.

[20] N.C. Juul, N. Jørgensen, The security hole in WAP: an analysis of thenetwork and business rationales underlying a failure, InternationalJournal of Electronic Commerce 7 (4) (2003) 73, Summer.

[21] T.S. Loon, V. Bharghavan, Alleviating the latency and bandwidthproblems in WWW browsing, in: USENIX Symposium on InternetTechnologies and Systems, 1997.

[22] Y. Minsky, R. van Renesse, F. Schneider, S.D. Stoller, Cryptographicsupport for fault-tolerant distributed computing, in: Seventh ACMSIGOPS European Workshop, 1996.

[23] J.L. Munoz, J. Forne, Evaluation of Certificate Revocation Policies:OCSP vs. Overissued CRL, in: DEXA Workshops 2002. Workshopon Trust and Privacy in Digital Business (TrustBus02), pp. 511–515,IEEE Computer Society, 2002.

[24] J.L. Munoz, J. Forne, O. Esparza, I. Bernabe, M. Soriano, UsingOCSP to secure certificate-using transactions in m-commerce, in:Applied Cryptography and Network Security, LNCS, vol. 2846,Springer-Verlag, Berlin, 2003, pp. 280–292.

[25] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, X.509Internet Public Key Infrastructure Online Certificate Status Protocol –OCSP, 1999. RFC 2560.

[26] M. Soriano, D. Ponce, Security and usability proposal for mobileelectronic commerce, IEEE Communications Magazine 40 (2002)62–67.

[27] J.P. Stern, G. Hachez, F. Koeune, J.J. Quisquater, Robust objectwatermarking: application to code, in: Information Hiding, LNCS,vol. 1768, Springer-Verlag, Berlin, 1999.

[28] G. Vigna, Cryptographic traces for mobile agents, in: MobileAgents and Security, LNCS, vol. 1419, Springer-Verlag, Berlin,1998.

[29] ITU/ISO Recommendation X.509, Information technology OpenSystems Interconnection – The Directory: Public Key and AttributeCertificate Frameworks, 1997.

Oscar Esparza was born in Viladecans (Spain) in1975. In 1999, he received his M.S. Degree inTelecommunication Engineering in the TechnicalUniversity of Catalonia (UPC). In the same yearhe joined the AUNA Switching EngineeringDepartment. Since 2001 he works as AssistantProfessor in the Department of TelematicsEngineering of the UPC. In 2004, he received thePh.D. Degree in Mobile Agent Security.

unications 29 (2006) 2308–2321 2321

Jose L. Munoz was born in Terrassa (Spain) in1975. In 1999, he received the M.S. Degree inTelecommunication Engineering in the TechnicalUniversity of Catalonia (UPC). In the same yearhe joined the AUNA Switching EngineeringDepartment. Since 2000 he works as AssistantProfessor in the Department of TelematicsEngineering of the UPC. In 2003, he received thePh.D. Degree in Network Security.

Miguel Soriano was born in Barcelona in 1967. He

received his M.S. Degree in TelecommunicationsEngineering in the Technical University of Cata-lonia (UPC) in 1992, and the Ph.D. Degree in1996. In 1991, he joined the Cryptography andNetwork Security Group at the Department ofApplied Mathematics and Telematics. Currentlyworking as an Associate Professor in the Depart-ment of Telematics Engineering of the UPC.

Jordi Forne was born in Barcelona in 1967. He

received his M.S. Degree in TelecommunicationsEngineering in the Technical University ofCatalonia (UPC) in 1992, and the Ph.D. Degreein 1997. In 1991, he joined the Cryptography andNetwork Security Group at the Department ofApplied Mathematics and Telematics. Currentlyworking as an Associate Professor in theDepartment of Telematics Engineering of theUPC.