ieee transactions on parallel and distributed …mmahmoud/publications... · a secure payment...

A Secure Payment Scheme with LowCommunication and Processing Overhead

for Multihop Wireless NetworksMohamed M.E.A. Mahmoud and Xuemin (Sherman) Shen, Fellow, IEEE

Abstract—We propose RACE, a report-based payment scheme for multihop wireless networks to stimulate node cooperation,

regulate packet transmission, and enforce fairness. The nodes submit lightweight payment reports (instead of receipts) to the

accounting center (AC) and temporarily store undeniable security tokens called Evidences. The reports contain the alleged charges

and rewards without security proofs, e.g., signatures. The AC can verify the payment by investigating the consistency of the reports,

and clear the payment of the fair reports with almost no processing overhead or cryptographic operations. For cheating reports, the

Evidences are requested to identify and evict the cheating nodes that submit incorrect reports. Instead of requesting the Evidences

from all the nodes participating in the cheating reports, RACE can identify the cheating nodes with requesting few Evidences.

Moreover, Evidence aggregation technique is used to reduce the Evidences’ storage area. Our analytical and simulation results

demonstrate that RACE requires much less communication and processing overhead than the existing receipt-based schemes with

acceptable payment clearance delay and storage area. This is essential for the effective implementation of a payment scheme

because it uses micropayment and the overhead cost should be much less than the payment value. Moreover, RACE can secure the

payment and precisely identify the cheating nodes without false accusations.

Index Terms—Cooperation incentive schemes, network-level security and protection, payment schemes, and selfishness attacks

Ç

1 INTRODUCTION

IN multihop wireless networks (MWNs), the traffic origi-nated from a node is usually relayed through the other

nodes to the destination for enabling new applications andenhancing the network performance and deployment [1].MWNs can be deployed readily at low cost in developing andrural areas. Multihop packet relay can extend the networkcoverage using limited transmit power, improve area spectralefficiency, and enhance the network throughput and capa-city. MWNs can also implement many useful applicationssuch as data sharing [2] and multimedia data transmission[3]. For example, users in one area (residential neighborhood,university campus, etc.) having different wireless-enableddevices, e.g., PDAs, laptops, tablets, cell phones, etc., canestablish a network to communicate, distribute files, andshare information. However, the assumption that the nodesare willing to spend their scarce resources, such as batteryenergy, CPU cycles, and available network bandwidth, torelay others’ packets without compensation cannot be heldfor civilian applications where the nodes are autonomous andaim to maximize their welfare.

Selfish nodes will not relay others’ packets and make use of

the cooperative nodes to relay their packets, which degrades

the network connectivity and fairness. The fairness issue

arises when the selfish nodes make use of the cooperativenodes to relay their packets without any contribution to them,and thus the cooperative nodes are unfairly overloadedbecause the network traffic is concentrated through them.The selfish behavior also degrades the network connectivitysignificantly, which may cause the multihop communicationto fail [4].

Payment (or incentive) schemes [5] use credits (ormicropayment) to motivate the nodes to cooperate in relayingothers’ packets by making cooperation more beneficial thanselfishness. The nodes earn credits for relaying others’packets and spend these credits to get their packets relayedby others. In addition to cooperation stimulation, theseschemes can enforce fairness, discourage Message-Floodingattacks, regulate packet transmission, and efficiently chargefor the network services. Fairness can be enforced byrewarding the nodes that relay more packets and chargingthe nodes that send more packets. For example, the nodessituated at the network center relay more packets than theother nodes because they are more frequently selected by therouting protocol. Since the source nodes pay for relaying theirpackets, the payment schemes can also regulate packettransmission and discourage Message-Flooding attacks wherethe attackers send bogus messages to deplete the intermedi-ate nodes’ resources. Moreover, since the communicationsessions may be held without involving a trusted party (TP)and the nodes may roam among different foreign networks,the payment schemes can charge the nodes efficientlywithout contacting distant home location registers [6].

The existing credit card payment schemes are designedfor different system and threat models, which are infeasiblefor MWNs. For example, in credit card payment schemes,

IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 24, NO. 2, FEBRUARY 2013 209

. The authors are with the Centre for Wireless Communications, Departmentof Electrical and Computer Engineering, University of Waterloo, Waterloo,ON N2L 3G1, Canada. E-mail: {mmabdels, xshen}@bbcr.uwaterloo.ca.

Manuscript received 13 Nov. 2011; revised 22 Feb. 2012; accepted 8 Mar.2012; published online 20 Mar. 2012.Recommended for acceptance by S. Guo.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TPDS-2011-11-0831.Digital Object Identifier no. 10.1109/TPDS.2012.106.

1045-9219/13/$31.00 � 2013 IEEE Published by the IEEE Computer Society

each transaction usually has one customer and onemerchant, and the merchants’ number is low and they areknown before the transaction is held. For the paymentschemes in MWNs, there is usually one customer (the sourcenode) and multiple merchants (the intermediate nodes). Themerchants’ number is large because any network node canact as a merchant (or packet relay), and a transaction’s valueis much less than those in credit card payment schemes. Therelation between a customer and a merchant is usually shortdue to the network dynamic topology, and the nodes areinvolved in low-value transactions very frequently becauseonce a route is broken, a new transaction should be done toreestablish the route. Due to these unique characteristics,MWNs require a specially designed payment scheme.

A good payment scheme should be secure, and requirelow overhead. However, the existing receipt-based pay-ment schemes impose significant processing and commu-nication overhead and implementation complexity. Since atrusted party may not be involved in communicationsessions, the nodes compose proofs of relaying others’packets, called receipts, and submit them to an offlineaccounting center (AC) to clear the payment. The receipts’size is large because they carry security proofs, e.g.,signatures, to secure the payment, which significantlyconsumes the nodes’ resources and the available bandwidthin submitting them. The AC has to apply a large number ofcryptographic operations to verify the receipts, which mayrequire impractical computational power and make thepractical implementation of these schemes complex orinefficient. Moreover, since a transaction (relaying packets)value may be very low, the scheme uses micropayment, andthus a transaction’s overhead in terms of submitting andclearing the receipts should be much less than its value.Therefore, reducing the communication and the paymentprocessing overhead is essential for the effective imple-mentation of the payment scheme and to avoid creating abottleneck at the AC and exhausting the nodes’ resources.

In this paper, we propose RACE, a Report-basedpAyment sChemE for MWNs. The nodes submit light-weight payment reports (instead of receipts) to the AC toupdate their credit accounts, and temporarily store undeni-able security tokens called Evidences. The reports containthe alleged charges and rewards of different sessionswithout security proofs, e.g., signatures. The AC verifiesthe payment by investigating the consistency of the reports,and clears the payment of the fair reports with almost nocryptographic operations or computational overhead. Forcheating reports, the Evidences are requested to identify andevict the cheating nodes that submit incorrect reports, e.g.,to steal credits or pay less. In other words, the Evidences areused to resolve disputes when the nodes disagree about thepayment. Instead of requesting the Evidences from all thenodes participating in the cheating reports, RACE canidentify the cheating nodes with submitting and processingfew Evidences. Moreover, Evidence aggregation technique isused to reduce the storage area of the Evidences.

In RACE, Evidences are submitted and the AC appliescryptographic operations to verify them only in case ofcheating, but the nodes always submit security tokens, e.g.,signatures, and the AC always applies cryptographicoperations to verify the payment in the existing receipt-based schemes. RACE can clear the payment nearly without

applying cryptographic operations and with submittinglightweight reports when Evidences are not frequentlyrequested. Widespread cheating actions are not expected incivilian applications because the common users do not havethe technical knowledge to tamper with their devices.Moreover, cheating nodes are evicted once they commitone cheating action and it is neither easy nor cheap to changeidentities. Our analytical and simulation results demonstratethat RACE requires much less communication and proces-sing overhead than the existing receipt-based schemes withacceptable payment clearance delay and Evidences’ storagearea, which is necessary to make the practical implementa-tion of the payment scheme effective. Moreover, RACE cansecure the payment and precisely identify the cheating nodeswithout false accusations or stealing credits.

To the best of our knowledge, RACE is the first paymentscheme that can verify the payment by investigating theconsistency of the nodes’ reports without systematicallysubmitting and processing security tokens and withoutfalse accusations. RACE is also the first scheme that uses theconcept of Evidence to secure the payment and requiresapplying cryptographic operations in clearing the paymentonly in case of cheating.

The remainder of this paper is organized as follows.Section 2 reviews the related works. Section 3 gives thenetwork and adversary models. Section 4 presents RACE.Security analysis and performance evaluation are given inSections 5 and 6, respectively, followed by conclusion andfuture work in Section 7.

2 RELATED WORKS

The existing payment schemes can be classified intotamper-proof-device (TPD)-based and receipt-basedschemes. In TPD-based payment schemes [7], [8], [9], [10],a TPD is installed in each node to store and manage itscredit account and secure its operation. For receipt-basedpayment schemes [11], [12], [13], [14], [15], [16], [17], [18],[19], [20], an offline central unit called the accounting centerstores and manages the nodes’ credit accounts. The nodesusually submit undeniable proofs for relaying packets,called receipts, to the AC to update their credit accounts.

In Nuglets [7], the self-generated and forwarded packetsby a node are passed to the TPD to decrease and increasethe node’s credit account, respectively. Packet purse andpacket trade models have been proposed. For the packetpurse model, the source node’s credit account is chargedthe full payment before sending a packet, and eachintermediate node acquires the payment for relaying thepacket. For the packet trade model, each intermediate noderuns an auction to sell the packets to the next node in theroute, and the destination node pays the total cost ofrelaying the packets. In SIP [8], after receiving a data packet,the destination node sends a RECEIPT packet to the sourcenode to issue a REWARD packet to increment the creditaccounts of the intermediate nodes. In CASHnet [9], thecredit account of the source node is charged and a signatureis attached to each data packet. Upon receiving the packet,the credit account of the destination node is also charged,and a digitally signed acknowledgement (ACK) packet is

210 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 24, NO. 2, FEBRUARY 2013

sent back to the source node to increase the credit accountsof the intermediate nodes.

The receipt-based payment schemes impose more over-head than the TPD-based schemes because they requiresubmitting receipts to the AC and processing them. How-ever, the TPD-based payment schemes suffer from thefollowing serious issues. First, the assumption that the TPDcannot be tampered with, cannot be guaranteed because thenodes are autonomous and self-interested, and the attackerscan communicate freely in an undetectable way if they couldcompromise the TPDs. Second, the nodes cannot commu-nicate if they do not have sufficient credits during thecommunication time. Unfortunately, the nodes at the net-work border cannot earn as many credits as the other nodesbecause they are less frequently selected by the routingprotocol. Finally, since credits are cleared in real time, themultihop communications fail if the network does not haveenough credits circulating around because the nodes do nothave sufficient credits to communicate. In [10], it is shownthat the overall credits in the network decline gradually withusing TPD-based schemes because the total charges may bemore than the total rewards. This is because the source nodeis fully charged after sending a packet but some intermediatenodes may not be rewarded when the route is broken.

In order to eliminate the need for TPDs, an offline centralbank called the AC is used to store and manage the nodes’credit accounts. In Sprite [11], for each message, the sourcenode signs the identities of the nodes in the route and themessage, and sends the signature as a proof for sending amessage. The intermediate nodes verify the signature,compose receipts containing the identities of the nodes inthe route and the source node’s signature, and submit thereceipts to the AC to claim the payment. The AC verifies thesource node’s signature to make sure that the payment iscorrect. However, the receipts overwhelm the networkbecause the scheme generates a receipt per message.

Unlike Sprite that charges only the source node, FESCIM[12] adopts fair charging policy by charging both the sourceand destination nodes when both of them are interested inthe communication. In PIS [13], the source node attaches asignature to each message and the destination node replieswith a signed ACK packet. PIS can reduce the receipts’number by generating a fixed-size receipt per sessionregardless of the number of messages instead of generatinga receipt per message in Sprite. In order to reduce thecommunication and processing overhead, CDS [14] usesstatistical methods to identify the cheating nodes thatsubmit incorrect payment. However, due to the nature ofthe statistical methods, the colluding nodes may manage tosteal credits, and some honest nodes may be falsely accusedof cheating which is called false accusations. Moreover,some cheating nodes may not be identified which is calledmissed detections, and it may take long time to identify thecheating nodes.

In [15], a payment scheme has been proposed for hybridad-hoc networks, but involving the base stations in everycommunication session may lead to suboptimal routes whenthe source and destination nodes reside in the same cell. Inaddition, corrupted messages are relayed to the base stationsbefore they are dropped because the intermediate nodescannot verify the authenticity and the integrity of themessages. In [16], each node has to contact the AC in eachcommunication session to get coins to buy packets from the

previous node in the route. However, the interactiveinvolvement of the AC in each session is inefficient, causeslong delay, and creates a bottleneck.

ESIP [17] proposes a communication protocol that can beused for a payment scheme. ESIP transfers messages fromthe source to the destination nodes with limited number ofpublic key cryptography operations by integrating publickey cryptography, identity-based cryptography, and hashfunction. Public key cryptography and hash function areused to ensure message integrity and payment nonrepudia-tion to secure the payment. Identity-based cryptography isused to efficiently compute a shared symmetric key betweenthe source node and each node in the route. Using these keys,the source node computes and sends a keyed hash value foreach intermediate node to verify the message integrity.Comparing to PIS, ESIP requires fewer public key crypto-graphy operations but with larger receipts’ size. Unlike ESIPthat aims to transfer messages efficiently from the source tothe destination nodes, RACE aims to reduce the overhead ofsubmitting the payment data to the AC and processing them.Although the communication protocol proposed in ESIP canbe used with RACE, we use a simple protocol due to spacelimitation and to focus on our contributions.

A mechanism is proposed in [18] to thwart packetdropping attacks. Payment is used to thwart the rationalpacket-dropping attacks, and a reputation system is used toidentify and evict the irrational packet dropping attackersonce their packet-dropping rates exceed a threshold. In [19],Zhu et al. propose a payment scheme, called SMART, fordelay tolerant wireless networks (DTNs). SMART useslayered coins and can secure the payment against a widerange of attacks such as Credit-Forgery, Nodular-Tontine, andSubmission-Refusal. Lu et al. [20] propose a payment schemefor DTNs which focuses on the fairness issue. The inter-mediate nodes earn credits for forwarding the deliveredmessages and gain reputation for forwarding the undeliv-ered messages which gives them preference in forwardingfuture messages. However, the payment schemes designedfor DTNs may not be efficiently applicable to MWNs becauseDTNs lack fully connected end-to-end routes and toleratelong packet delivery delay.

Table 1 summarizes the main features of RACE and theexisting payment schemes. RACE is more secure than CDSbecause it does not suffer from false accusations, misseddetections, and delay in identifying attackers, and it canthwart collusion attacks. Moreover, RACE requires muchless communication and processing overhead comparing toreceipt-based schemes [11], [12], [13], [17], yet with moreand acceptable storage area and payment clearance delay.

3 SYSTEM MODELS

3.1 Network Model

For military and disaster recovery applications, the networkcan be considered ephemeral because it is used for a specificpurpose and short duration. In this paper, we adopt thenetwork model used in [7], [8], [9], [10], [11], [12], [13], [14],[15], [16], [17] that targets the civilian applications ofMWNs, where the network has long life and the nodeshave long-term relations with the network. As illustrated inFig. 1, the considered MWN has an offline TP and mobilenodes. The TP contains the AC and the certificate authority(CA). The AC maintains the nodes’ credit accounts and the

MAHMOUD AND SHEN: A SECURE PAYMENT SCHEME WITH LOW COMMUNICATION AND PROCESSING OVERHEAD FOR MULTIHOP... 211

CA renews and revokes the nodes’ certificates. Each node Ahas to register with the trusted party to receive a symmetrickey KA, private/public key pair, and certificate. Thesymmetric key is used to submit the payment reports andthe private/public keys are required to act as source ordestination node. We assume that the clocks of the nodesare synchronized. The details of this synchronizationprocess are out of the scope of the paper, but severalmechanisms have been proposed to synchronize the nodes’clocks [21]. Once the AC receives the payment reports of asession and verifies them, it clears the payment if thereports are fair; else, it requests the Evidences to identify thecheating nodes. The CA evicts the cheating nodes bydenying renewing their certificates.

RACE can be used with any source routing protocol, suchas DSR [22], which establishes end-to-end routes beforetransmitting data. Source nodes’ packets may be relayedseveral hops by intermediate nodes to their destinations. Thenodes can contact the TP at least once during a period of fewdays. In this connection, the nodes submit the paymentreports and the Evidences (if requested), and receive renewed

certificates to be able to continue using the network. Thenodes also can purchase credits with real money to enablethe nodes that cannot earn sufficient credits, such as those atthe network border, to communicate, and also to avoid creditdecline because the total charges may be more than therewards when routes are broken. This connection can occurvia the base stations of cellular networks, Wi-Fi hotspots, orwired networks such as Internet.

For the payment model, source nodes are charged forevery transmitted message even if it does not reach thedestination nodes, but the intermediate nodes are rewardedonly for the delivered messages. Some schemes, such as [23],consider that the reward of relaying a packet is proportionalto the incurred energy in relaying the packet. This rewardingpolicy can be integrated with RACE, but similar to [11], [12],[13], [14], [15], [16], [17], [18], [19], [20], we use fixedrewarding rate, e.g., � credits per unit-sized packet tosimplify our description and focus on our contributions.

3.2 Adversary Model

The mobile nodes are probable attackers but the TP is fullysecure. The mobile nodes are autonomous and self-interestedand thus motivated to misbehave. The TP is run by anoperator that is motivated to ensure the network properoperation. As discussed in [24], it is impossible to realizesecure payment between two entities without a trusted thirdparty. The attackers have full control on their nodes and canchange their operation and infer the cryptographic data. Theattackers can work individually or collude with each otherunder the control of one attacker to launch sophisticatedattacks. These strong assumptions are necessary due toimplementing payment in the network. Similar to [11], [12],[13], [14], [15], [16], [17], [18], [19], [20], the attackers arerational in the sense that they misbehave only when they canachieve more benefits than behaving honestly. Particularly,the attackers aim to steal credits, pay less, and communicatefor free. Table 2 gives the description of the used symbols inthis paper.


TABLE 1Comparison between RACE and the

Existing Payment Schemes

Fig. 1. The architecture of the considered network.

TABLE 2Description of the Used Symbols

4 THE PROPOSED RACE

As shown in Fig. 2, RACE has four main phases. In

Communication phase, the nodes are involved in commu-

nication sessions and Evidences and payment reports are

composed and temporarily stored. The nodes accumulate

the payment reports and submit them in batch to the TP.

For the Classifier phase, the TP classifies the reports into fair

and cheating. For the Identifying Cheaters phase, the TP

requests the Evidences from the nodes that are involved in

cheating reports to identify the cheating nodes. The

cheating nodes are evicted and the payment reports

are corrected. Finally, in Credit-Account Update phase, the

AC clears the payment reports.

4.1 Communication

The Communication phase has four processes: route estab-lishment, data transmission, Evidence composition, andpayment report composition/submission.

Route establishment. In order to establish an end-to-endroute, the source node broadcasts the Route Request (RREQ)packet containing the identities of the source (IDS) and thedestination (IDD) nodes, time stamp (Ts), and Time-To-Live(TTL). TTL is the maximum number of intermediate nodes.After a node receives the RREQ packet, it appends itsidentity and broadcasts the packet if the number ofintermediate nodes is fewer than TTL. The destinationnode composes the Route Reply (RREP) packet for the nodesbroadcasted the first received RREQ packet, and sends thepacket back to the source node. The destination nodecreates a hash chain by iteratively hashing a randomvalue (hðKÞ) K times to produce the hash chain root (hð0Þ),where hði�1Þ ¼ HðhðiÞÞ and 1 � i � K. The optimal value of Kdepends on many factors such as the number of messagesthe source node needs to send, and the average number ofmessages sent through a route before it is broken, i.e., due tonode mobility. Estimating a good value for K can save thedestination node’s resources because once a route is broken,the unused hash values in the hash chain should not beused for another route to secure the payment. The nodescan estimate the value of K and periodically tune it.

The RREP packet contains the identities of the nodes inthe route (e.g., R ¼ IDS, IDA; IDB; IDD in the route shown inFig. 3), hð0Þ, and the destination node’s certificate andsignature (SigDðR;Ts; hð0ÞÞ). This signature authenticates thehash chain and links it to the route. The intermediate nodesverify the destination node’s signature, relay the RREPpacket, and store the signature and hð0Þ for composing theEvidence.

Data transmission. The source node sends data packetsto the destination node through the established route andthe destination node replies with ACK packets. For the Xthdata packet, the source node appends the message MX andits signature to R, X, Ts, and the hash value of the message(HðMXÞ) and sends the packet to the first node in the route.The security tokens of the Xth data and ACK packets areillustrated in Fig. 3. The source node’s signature is anundeniable proof for transmitting X messages and ensuresthe message’s authenticity and integrity. Signing the hash ofthe message instead of the message can reduce the Evidencesize because the smaller-size HðMXÞ is attached to theEvidence instead of MX. Before relaying the packet, eachintermediate node verifies the signature to ensure themessage’s authenticity and integrity, and verifies R and Xto secure the payment. Each node stores only the lastsignature for composing the Evidence, which is enough to


Fig. 2. The architecture of RACE.

Fig. 3. The security tokens of the Xth data and ACK packets.

prove transmitting X messages, e.g., after receiving the Xthdata packet, the nodes should store SigS(R, X, Ts, HðMXÞ)and remove SigS(R, X-1, Ts, HðMX�1Þ), and so on. The datatransmission process ends when the source node transmitsits last message, or if the route is broken, e.g., due to nodemobility or channel impairment. Algorithm 1 gives thepseudocode of the processes of data transmission andcomposition of Evidence and report.

After receiving the Xth data packet, Fig. 3 shows that thedestination node sends back an ACK packet containing thepreimage of the last sent hash value (or hðXÞ) to acknowledgereceiving the message MX, where hð1Þ is released in the firstACK and hð2Þ in the second and so on. Each intermediatenode verifies the hash value by making sure that hðX�1Þ isobtained from hashing hðXÞ. The nodes store only the lastreleased hash value for composing the Evidence. Thepossession of hðXÞ by a node is a proof of delivering Xmessages, but the possession of SigS(R, X, Ts, HðMXÞ) is aproof of delivering X-1 messages and receiving one.The number of delivered messages can be computed fromthe number of hashing operations to map hðXÞ to hð0Þ, and thenumber of transmitted messages (X) is signed by the sourcenode. An intermediate node cannot drop theXth data packetand claim delivering it because the hash function is one way,i.e., it is computationally infeasible to compute hðXÞ fromhðX�1Þ. Hash chains have been used for many purposes due totheir low energy and computational overhead, and non-repudiation and one-way properties. In RACE, hash chainsare used to reduce the number of public key cryptographyoperations, i.e., instead of generating a signature per ACKpacket to secure the payment, one signature is generated bythe destination node per K ACK packets.

If a node in the route does not receive a data or ACKpacket within a time interval, the session is considered stale.The node A can estimate this interval as nA� (cryptogra-phic_delay þ transmission_delay), where nA is the numberof nodes between A and the source node for data packets,and the number of nodes between A and the destinationnode for ACK packets. The cryptographic_delay is themaximum computation time required by a node to performthe cryptographic operations, and the transmission_delayincludes any other delays, such as the propagation,queuing, and channel contention delays.

Evidence composition. Evidence is defined as informationthat is used to establish proof about the occurrence of anevent or action, the time of occurrence, the parties involvedin the event, and the outcome of the event. The purpose of anEvidence is to resolve a dispute about the amount of thepayment resulted from data transmission. Fig. 4 gives thegeneral format of an Evidence. The figure shows that anEvidence contains two main parts called DATA and PROOF.The DATA part describes the payment, i.e., who pays whomand how much, and contains the necessary data to regeneratethe nodes’ signatures. From Fig. 4, the DATA contains the

identities of the nodes in the route (R), the number ofreceived messages (X), the session establishment time

stamp, the root of the destination node’s hash chain hð0Þ,the hash value of the last message (HðMXÞ), and the lastreceived hash value (hðVÞ). V ¼ X � 1 when the last received

packet is the Xth data packet because the route is brokenbefore receiving the Xth ACK packet that carries hðXÞ, but

V ¼ X when the last received packet is the Xth ACK packet.The DATA does not have hð1Þ when the route is broken after

receiving the first data packet because the ACK that has hð1Þ isnot received. The PROOF is an undeniable security tokenthat can prove the correctness of the DATA and protect

against payment manipulation, forgery, and repudiation.The PROOF is composed by hashing the destination node’s

signature and the last signature received from the sourcenode, instead of attaching the signatures to reduce the

Evidence size.Evidences have the following main features:

1. Evidences are unmodifiable: If X messages aredelivered, the intermediate nodes can composeEvidences for fewer than X messages, but not formore. This is because the intermediate nodes haveSigSðR; i;Ts;HðMiÞÞ and hðiÞ for i ¼ f1; 2; . . . ; Xg,which are sufficient for composing Evidences forfewer than X messages. However, the intermediatenodes cannot compose Evidences for more than Xbecause it is computationally infeasible to computeSigSðR; i;Ts;HðMiÞÞ or hðiÞ for i > X.

2. If the source and destination nodes collude, they cancreate Evidences for any number of messages becausethey can compute the necessary security tokens.

3. Evidences are unforgeable: If the source and destina-tion nodes collude, they can create Evidence forsessions that did not happen, but the intermediatenodes cannot, because forging the source anddestination nodes’ signatures is infeasible.

4. Evidences are undeniable: This is necessary to enablethe TP to verify them to secure the payment. Asource node cannot deny initiating a session or theamount of payment because it signs the number oftransmitted messages and the signature is includedin the Evidence.

5. An honest intermediate node can always composevalid Evidence even if the route is broken or the othernodes in the route collude to manipulate thepayment. This is because it can verify the Evidencesto avoid being fooled by the attackers.

Reducing the storage area of the Evidences is important

because they should be stored until the AC clears thepayment. Onion hashing technique can be used toaggregate Evidences. The underlying idea is that instead of

storing one PROOF per session, one compact PROOF can becomputed to prove the credibility of the payment of a group

of sessions. The compact Evidence contains the concatena-tion of the DATAs of the individual Evidences and one

compact PROOF that is computed by onion hashing thePROOFs of the individual Evidences. Let PROOF(i) refer tothe PROOF of the Evidence number i, the compact PROOF is

computed as follows:


Fig. 4. The general format of an Evidence.

H(. . . .,

H(H(PROOF(1), PROOF(2)), PROOF(3)),

. . . , PROOF(n))

PROOF(1) and PROOF(2) are concatenated and hashed,

and then PROOF(3) is added to the compact PROOF by

adding one hashing layer and so on. The compact PROOF

has the same size of the PROOF of individual Evidence, but

it can prove the credibility of the payment of multiple

sessions. The onion hashing technique enables the nodes to

aggregate a recent Evidence with the old compact Evidence,

i.e., Evidences are always stored in an aggregated form to

reduce their storage area. The technique is called onion

hashing because each aggregation operation requires add-

ing one hashing layer.However, the Evidence aggregation process is irreversible

because the hash function is unidirectional, i.e., the compact

Evidence cannot be decomposed to individual Evidences.

Thus, if the TP requests an Evidence that is aggregated in the

compact Evidence, the node has to submit the compact

Evidence and the TP has to verify all the PROOFs of the

sessions of the compact Evidence, instead of verifying only

the PROOF of the requested Evidence. Therefore, aggregat-

ing more Evidences can further reduce their storage area, but

with more communication and processing overhead if an

Evidence is requested. This is acceptable because Evidences

are requested only in case of cheating and RACE requests

the Evidences from few nodes instead of all the nodes in the

cheating reports. The aggregation level can be flexible and

dependent on the available memory space, e.g., a storage-

constrained node can aggregate all Evidences in only one

compact Evidence.Payment report composition/submission. A payment

report contains the session identifier, a flag bit (F), and the

number of messages (X). The session identifier is the

concatenation of the identities of the nodes in the session

and the time stamp. The flag bit is zero if the last received

packet is data and one if it is ACK. Table 3 gives numerical

examples for the payment reports of node A. For the first

report, A is the source node and claims sending 12

messages, but it did not receive the ACK of the last message

because F is zero. For the second report, A is the destination

node and claims receiving 17 messages. For the third report,

A is an intermediate node and claims receiving 15 messages,

but it did not receive the ACK of the last message. The

submission of reports and Evidences are illustrated in

Algorithm 2 and Fig. 5.

As shown in Fig. 5, node A sends a Report SubmissionPacket (RSP) to the TP at time ti to submit the reports of thesessions held since the last contact at ti�1. The packet containsthe reports of the sessions held in [ti�1;ti) (Reports[ti�1;ti)),time stamp, and a keyed hash value (HKAðÞ) to ensure thepacket’s integrity and authenticity, where KA is the long-term symmetric key shared between node A and the TP.Thus, the TP can make sure that the packet has not beenmanipulated and the reports are indeed sent by the intendednode, which is important to secure the payment and hold thenodes accountable for any misbehavior. If the TP requestsEvidences from node A, it sends an Evidences Request Packet(EREQ) containing the identifiers of the reports that theirEvidences are requested (Ses_IDs[ti�2;ti�1)). Node A replieswith Evidences Reply Packet (EREP) containing the requestedEvidences (Req_Evs[ti�2;ti�1)). If node A is honest, the TPsends a Renewed Certificate Packet (RCP) containing a renewedcertificate for node A with the same identity and public/private keys but with updated lifetime. Therefore, only theefficient hashing operations are used to submit the reportsand Evidences securely to the TP. Note that RSP and RCP arealso required in receipt-based payment schemes to submitthe receipts.

4.2 Classifier

After receiving a session’s payment reports, the AC verifiesthem by investigating the consistency of the reports, andclassifies them into fair or cheating. For fair reports, thenodes submit correct payment reports, but for cheatingreports, at least one node does not submit the reports or


TABLE 3Numerical Examples for Reports Submitted by Node A

Fig. 5. The submission of reports and Evidences.

submits incorrect reports, e.g., to steal credits or pay less.Fair reports can be for complete or broken sessions. For acomplete session, all the nodes in the session report thesame number of messages and F of one. If a session isbroken during relaying the Xth data packet, the reports ofthe nodes from S to the last node that received the packetreport X and F of zero, but the other nodes report X � 1 andF of one. If a session is broken during relaying the Xth ACKpacket, the nodes in the session report X messages, and thenodes from D to the last node that received the ACK reportF of one, but the other nodes report F of zero. The reportsare classified as cheating if they do not achieve one of theaforementioned rules.

Table 4 gives numerical examples for fair reports. Case 1is reports for complete session and Cases 2 to 4 are reportsfor broken sessions. For Case 1, all the nodes report thesame number of messages and F of one. For Case 2, thesession was broken during relaying the ACK packetnumber 11 and B is the last node that received the packet.For Case 3, the session was broken during relaying the datapacket number 8 and node A is the last node that receivedthe packet. For Case 4, the session was broken duringrelaying the first data packet, and node B is the last nodethat received the packet, and therefore nodes C and D didnot submit the payment report of the session.

4.3 Identifying Cheaters

As shown in Fig. 2, in the Identifying Cheaters’ phase, the TPprocesses the cheating reports to identify the cheatingnodes and correct the financial data. Our objective ofsecuring the payment is preventing the attackers (singularof collusive) from stealing credits or paying less, i.e., theattackers should not benefit from their misbehaviors. Weshould also guarantee that each node will earn the correctpayment even if the other nodes in the route collude tosteal credits. The AC requests the Evidence only from thenode that submits report with more payment instead of allthe nodes in the route because it should have the necessaryand undeniable proofs (signatures and hash chain ele-ments) for identifying the cheating node(s). In this way, theAC can precisely identify the cheating nodes with request-ing few Evidences. Numerical examples will be given inSection 5 to clarify how cheating nodes can be identifiedwithout false accusations.

To verify an Evidence, the TP composes the PROOF bygenerating the nodes’ signatures and hashing them. TheEvidence is valid if the computed PROOF is similar to theEvidence’s PROOF.

4.4 Credit-Account Update

As shown in Fig. 2, the Credit-Account Update phase receivesfair and corrected payment reports to update the nodes’credit accounts. The payment reports are cleared using thecharging and rewarding policy discussed in Section 3.

In receipt-based payment schemes, a receipt can becleared once it is submitted because it carries undeniablesecurity proof, but the AC in RACE has to wait untilreceiving the reports of all nodes in a route to verify thepayment. The maximum payment clearance delay (or theworst case timing) occurs for the sessions that are heldshortly after at least one node contacts the AC and the nodesubmits the report after the certificate lifetime (TCert), i.e., atleast one report is submitted after TCert of the sessionoccurrence. It is worth to note that the maximum timeduration for a node’s two consecutive contacts with the TPis TCert to renew its certificate to be able to use the network.

Fig. 6 shows the worst case timing of the submission andclearance of the reports with considering that the reportsare submitted every TCert, where SUB_R, SUB_E, CLR_FR,and CLR_CR refer to the events of submitting reports,submitting Evidences, clearing fair reports, and clearingcheating reports. At t1, the nodes submit the paymentreports of the sessions held in [t0; t1) and the fair reports ofthese sessions are cleared. Thus, the maximum paymentclearance delay of fair reports is TCert for the sessions heldshortly after t0, but the average payment clearance delay isTCert=2 for the sessions held in [t0; t1) assuming that thesessions are held according to uniform random distribution.At t2, the TP requests the Evidences of the cheating reports ofthe sessions held in [t0; t1). Thus, the maximum paymentclearance delay for cheating reports is 2� TCert for thesessions held shortly after t0, but the average paymentclearance delay is 1.5 TCert for the cheating reports of thesessions held in [t0; t1). The figure also shows that themaximum time for storing an Evidence is 2� TCert, e.g., forthe reports of sessions held shortly after t0. At t2, the nodesdelete the Evidences of the sessions held in [t0; t1) becausethe AC must have cleared their reports.

However, the nodes submit the reports at different timesbecause the connection to the TP may not be available on aregular basis, and thus the duration between each twosubmissions may not be the same and may be less than orequal to TCert. Hence, the maximum payment clearancedelay may be less than TCert. Ti is a continuous random


TABLE 4Numerical Examples for Fair Reports

Fig. 6. The worst case timing of the reports submission and clearance.

variable that denotes the time duration between two

submissions for a node, where Ti 2 ½0;TCert�. The submission

durations of the nodes are independent and identically

distributed (i.i.d.) random variables. In order to estimate the

average and maximum payment clearance delay, we con-

sider two models. For model I, each node contacts the TP

when it accumulates a large number of reports or when the

remaining time of its certificate’s lifetime is short, to reduce

the communication overhead. We model this behavior with

truncated exponential distribution given in (1), where the

probability that a node contacts the TP is high as Ti

approaches TCert. For model II, a node submits the reports

once it has a connection to the TP and the connections are

uniformly distributed over the time interval [0;TCert].Equations (2) and (3) give the probabilities of submitting

the reports at most by time t for models I and II, respectively.

The payment of a session is cleared when all the nodes in the

session submit their reports. T(n) is a continuous random

variable that denotes the time duration for n nodes to contact

the AC, where TðnÞ 2 ½0;TCert�. Equation (4) gives the

probability that T(n) is less than or equal to t. The probability

density functions of T(n) using models I and II are given in (5)

and (6), respectively. Equation (7) gives the average time

duration for n nodes to contact the AC, which is equivalent to

the maximum payment clearance delay for a session.

Equation (8) gives the average payment clearance delay for

a session with n nodes assuming that sessions are held

according to uniform distribution

fðTiÞ ¼� � e��t

1� e��TCert; ð1Þ

PðTi � tÞ ¼ 1� e��t

1� e��TCert; ð2Þ

PðTi � tÞ ¼ t

TCert; ð3Þ

PðTðnÞ � tÞ ¼Yi¼n

i¼1

PðTi � tÞ; ð4Þ

fðTðnÞÞ ¼ e��t � � � n � ð1� e��tÞn�1

ð1� e��TCertÞn ; ð5Þ

fðTðnÞÞ ¼ n

TCert� t

TCert

� �n�1

; ð6Þ

EðTðnÞÞ ¼Z TCert

o

t � fðTðnÞÞdt; ð7Þ

PCðnÞ ¼EðT ðnÞÞ

2; ð8Þ

EðTiÞ ¼1

�� 1� ð� � TCert þ 1Þ � e��TCert

1� e��TCert

� �: ð9Þ

We have selected � to be 1/7 and TCert to be 10, 15, and20 days, to make the average time duration between twosubmissions by a node (given in (9)) to be 3.9, 4.9, and 5.73days, respectively. Figs. 7 and 8 show the probabilities thatthe payment of a session with n nodes is cleared at most bytime t for models I and II, respectively, with TCert of 15 daysand � of 1/7. The figures show that the increase of the routelength (n) decreases the probability of clearing the paymentby time t because the AC has to wait more time to receivethe reports from more nodes. Moreover, the maximumpayment clearance delay is less than TCert with highprobability. Figs. 9 and 10 show the average paymentclearance delay at different values of n for models I and II,respectively. It can be seen that the average paymentclearance delay can be much less than TCert. For example, atn ¼ 5 nodes and TCert ¼ 15 days, the average payment


Fig. 7. PðTðnÞ � t) versus t at different values of n for model I. Fig. 8. PðTðnÞ � t) versus t at different values of n for model II.

Fig. 9. The average payment clearance delay for model I.

clearance delay is 5 and 6.2 for models I and II, respectively.It can also be seen that shortening TCert can decrease thepayment clearance delay.

Although our analysis demonstrates that the paymentclearance delay can be less than TCert when the nodessubmit their reports according to truncated exponential anduniform distributions, this delay is bounded by TCert andacceptable due to using postpaid payment model where thenodes communicate first and pay later, i.e., the nodes do notneed to wait until clearing the payment to communicate.Moreover, the nodes can purchase credits with real money.

5 SECURITY ANALYSIS

Our security objective is preventing an attacker or even agroup of colluding attackers from achieving gains such asstealing credits or paying less. The signatures of the sourcenode can ensure the messages’ integrity and authenticityand secure the payment. Signatures and hash chains havenonrepudiation property because it is computationallyinfeasible to compute a node’s signature without knowingthe private key used in generating the signature, and tocompute hðiÞ from hði�1Þ. This nonrepudiation property isused to secure the payment by enabling the nodes tocompose valid Evidences and enabling the TP to verify theEvidences to identify the cheating nodes.

In order to evaluate the Identifying Cheaters’ phase,numerical examples for cheating reports are given in Table 5.In Cases 1 and 2, the reports of the intermediate anddestination nodes are consistent but the source node claimssending fewer number of messages. The source node cancompose valid Evidence if it cheats because it has the tokensSigS(R, 6, Ts, HðM6Þ) and hð6Þ, and thus it is ineffective torequest the Evidence from the source node. The TP canrequest the Evidence from an intermediate node or thedestination node. The source node is a cheater if the Evidenceis correct because the Evidence cannot be composed withoutthe source node’s signature for 10 messages, and theintermediate and destination nodes cannot compute thissignature. For Case 2, it is obvious that the route was brokenat node B during relaying the data packet number ten. ForCase 3, the source and destination nodes’ reports areconsistent but the intermediate nodes claim relaying moremessages. If an intermediate node submits valid Evidence,the source and destination nodes are cheaters because theEvidence should contain the source node’s signature for

12 messages and hð11Þ or hð12Þ. It is ineffective to request theEvidence from the source or the destination node because theycan collude to generate valid Evidence.

In Case 4, the reports of the intermediate and destinationnodes are consistent but the source node claims sendingmore messages. This case may be rare because the rationalattackers will attempt to steal credits or pay less. The TP canclear the payment according to the nodes’ reports withoutrequesting Evidences to achieve our security strategy anddiscourage submitting incorrect reports because the sourcenode pays more if it lies and the other nodes lose credits ifthey lie. However, the TP can identify the cheating nodes byrequesting the Evidence from the source node because itshould contain hð12Þ or hð11Þ. If the Evidence is correct, thedestination node is evicted but the intermediate nodesshould not be evicted because eight messages may beindeed relayed in the session and the source and destina-tion nodes collude to falsely accuse the intermediate nodes.Case 5 is similar to Case 4 but the source and destinationnodes report the same number of messages. The payment iscleared according to the nodes’ reports to punish the nodesthat submit incorrect reports without stealing credits.

In Cases 6 and 7, node B can prove the credibility of itsreports and earn the deserved payment even if the othernodes in the session collude. For Case 7, node B claimsdelivering seven messages but the other nodes claimreceiving seven messages and delivering only six messages.If node B is honest, its Evidence should have hð7Þ. If theEvidences of node B are valid, the source and destinationnodes are cheaters in Case 6, but only the destination node isa cheater in Case 7. For Case 8, as long as the destinationnode acknowledges receiving the message number seven,


Fig. 10. The average payment clearance delay for model II.

TABLE 5Numerical Examples for Cheating Reports

the intermediate nodes are rewarded for seven messages. InCases 9 and 10, “–” means that the node does not submit thepayment report of the session. For Case 9, if node A submitsvalid Evidence, the source and destination nodes are cheatersbecause they established a session but did not submit thepayment reports. The nodes B and C are not rewarded todiscourage unsubmitting the payment reports. For Case 10,the source node is charged but the intermediate nodes arenot rewarded without requesting Evidences in order topunish the nodes that do not submit payment reports.

The attackers may launch Multiple-Redemptions and One-Redemption attacks to deceive the AC. For Multiple-Redemp-tions attack, the attackers submit the same payment reportsmultiple times to be rewarded several times for the samesessions. The AC can thwart the attack and identify theattackers because it can ensure whether the payment of asession has been cleared before using the session uniqueidentifier that includes the identities of the nodes inthe session and time stamp. For One-Redemption attack,the attackers attempt to make the payment reports ofdifferent sessions have the same identifier to pay oncebecause the AC clears the reports having the same identifieronce. This attack is not possible in RACE because asession’s identifier changes once the route or the timechanges, i.e., the reports are different even if the samenodes participate in different sessions at different times.

Evidence Forgery and Manipulation attacks target theEvidence composition process. For Evidence-Forgery attack,the attackers attempt to forge Evidences for sessions that didnot happen to steal credits, and for Evidence-Manipulationattack, the attackers attempt to manipulate valid Evidencesto increase their rewards. In RACE, Evidences are undeni-able, unforgable, and unmodifiable. The source node cannotdeny initiating a session and the amount of paymentbecause its signature is included in the Evidence. Theattackers cannot forge Evidences or manipulate them withusing secure hash function and public-key cryptosystembecause it is impossible to compute hðiÞ from hði�1Þ orcompute the nodes’ signatures without knowing the privatekeys. Moreover, it is also impossible to modify the sourcenodes’ signatures, compute the private keys from the publicones, and compute the hash value of the signatures withoutcomputing the signatures. The TP can identify the attackersthat forge Evidences because the Evidences’ verifications fail.

The attackers may launch Impersonation, Packet-Replay,and Free-Riding attacks to target route establishment, reportsubmission, and data transmission processes. For Imperso-nation attack, the attackers impersonate legitimate nodes tocommunicate freely or steal credits. This attack is impos-sible because the nodes use their private keys in signing thepackets and use their secret symmetric keys in submittingthe payment reports. In Packet-Replay attack, the attackersrecord valid packets and replay them in different placeand/or time to establish sessions under the name of othersto communicate freely. In RACE, stale packets cannot beused to establish sessions because time stamps are used toverify the freshness of the packets. For Free-Riding attack,two colluding intermediate nodes in a legitimate sessionattempt to communicate freely by manipulating the packetsto add their data. This is impossible in RACE because the

integrity of the packets can be verified at each node, andthus the first intermediate node after the attacker can detectany addition or modification to the packets and thwart theattack by dropping them. The integrity of the data packetscan be ensured by verifying the source nodes’ signatures,and the integrity of the ACK packets can be ensured byverifying the hash chain elements.

The attackers may attempt to manipulate their reports tolaunch Reduced-Payment and False-Accusation attacks. ForReduced-Payment attack, some intermediate nodes maycollude with the source node to submit reports with lesspayment to charge the source node less. For example, if �intermediate nodes launch this attack successfully in asession with n nodes, the colluders can save ððn� 2��Þ �ðX � !Þ � �Þ credits, where X and ! are the correct andthe submitted number of messages, respectively, and thusthe source node can compensate the colluding intermediatenodes. In RACE, even if a group of nodes colludes to reducethe rewards of an honest node, the honest node cancompose valid Evidence and earn the correct payment, suchas Cases 6 and 7 in Table 5. For False-Accusation attack, theattackers manipulate their reports to insert nonexistentnodes in a session to let the TP accuse them of not reportingthe session. In RACE, if the victim nodes are intermediate,the payment is cleared without punishing or rewardingthem as discussed in Cases 9 and 10 in Table 5, but if thevictim nodes are source or destination, the attackers areevicted because they cannot submit correct Evidences.

The charging and rewarding policy can counteractrational cheating actions. If the nodes are charged only forthe successfully delivered messages, the destination nodesmay collude with the source nodes to not send ACK packetsso as not to pay. To prevent this, the source nodes arecharged for undelivered messages. If the intermediatenodes are rewarded for the relayed messages that do notreach the destination, the colluding intermediate nodes canincrease their rewards with consuming low resources byrelaying only the smaller size signatures but not themessages to compose valid Evidences and claim relayingthe messages. To prevent this, the intermediate nodes arerewarded only for delivered messages.

6 PERFORMANCE EVALUATION

Public-key cryptography is widely used to secure thewireless networks [25], [26], [27]. Using public-key crypto-graphy in RACE is necessary to secure the payment becauseit enables the nodes to compose valid Evidences and enablesthe TP to identify the cheating nodes. Public-key crypto-graphy technology and hardware implementation havebeen improved, and the signing and verifying operationscan be performed by mobile nodes with acceptable over-head. In [28], digital signatures can be computed efficientlyin two steps. The offline step is independent of the messageand performed before the message to be signed is available;and a lightweight online step is performed once themessage to be signed becomes available. In [29], FPGAimplementation of the RSA cryptosystem can efficientlyperform the signing and verifying operations in severalmilliseconds. Moreover, the proposed communication pro-tocol in [17] that transfers messages from the source to the


destination nodes with limited number of public-key-cryptography operations can be used with RACE, but thefocus of this paper is on reducing the communication andthe payment processing overhead.

6.1 Simulation Setup

We built up a simulator to evaluate the overhead of RACE.50 mobile nodes with 150 m transmission range aredeployed in a square cell of 1,200 m by 1,200 m. Constant-bit-rate traffic source is implemented in each node as anapplication layer and the source and destination pairs arerandomly chosen. We use the modified random waypointmodel [30] to emulate the nodes’ mobility. Specifically, anode travels toward a random destination that is uniformlyselected within the network field; upon reaching thedestination, it pauses for some time; and the process repeatsitself afterwards. The nodes’ speed is uniformly distributedin the range [0; Smax] m/s, where Smax is 5 and 10 m/s, andthe pause time is 20 s. The data packets are transmitted withthe rate of 0.5 packet/s. We simulate the Dynamic SourceRouting protocol (DSR) [22]. The time stamp, node’sidentity (IDi), and message number (X) are 5, 4, and 2bytes, respectively, and the hash chain size is 35. Thesimulation results are averaged over 200 runs and pre-sented with 95 percent confidence interval. Table 6summarizes the simulation parameters.

In the simulation, we consider 1,024-bit RSA digitalsignature scheme [31] because the verifying operationsperformed by the intermediate and destination nodesrequire less time than the signing operations performedby the source node. According to NIST guidelines [32], thesecure private keys should have at least 1,024 bits. For thehash function, we use SHA-1 [33] with digest size of20 bytes. We evaluate the expected processing delay due toperforming the cryptographic operations by the mobilenodes using Crypto++5 library [34] and a laptop with anIntel processor at 1.2 GHZ and 1 GB RAM. The computationtimes of signing and verifying operations are 15.63 and0.53 ms, respectively, and the computational time ofhashing a 512-byte message is 29 �s. The resource of a realmobile node may be less than a laptop, so the measuredcomputational times are scaled by the factor of five andconsidered as delays to simulate performing the crypto-graphic operations in a limited-resource node. From [35],the consumed energy for signing and verifying operations

are 546.5 and 15.97 mJ, respectively, and the consumedenergy for hashing a 512-byte message is 389:29 �J.

With these network parameters, the simulated networkis well connected and the route length is acceptable. Thestatistics of the simulated network demonstrate that theprobability that a route has fewer than seven nodes is 0.89,the average route length is 4.21, and the network con-nectivity is 0.98. The network connectivity is the ratio ofconnected routes to the total number of possible routes,assuming any two nodes can be source and destination pair.

6.2 Storage Overhead

The sizes of receipts, payment reports, and Evidencesdepend on the number of intermediate nodes because thenodes’ identities are attached to them. Thus, changing thenetwork parameters such as the network size, the nodes’radio transmission range and density, etc., will change theroute length and have the same effect on RACE and receipt-based schemes. Table 7 gives the average size of receipt,report, and Evidence for RACE and receipt-based paymentschemes. The receipt size in ESIP is larger than that of PISdue to attaching two hash values from the source node’shash chain and another two hash values from the destina-tion node’s hash chain. For Sprite, ESIP, PIS, and RACE,1 MB storage area can store up to 3,531, 7,282, 16,425, and10,082 receipts and Evidences, respectively. Although PISrequires low storage area, it needs two signatures permessage, i.e., one from the source node and another fromthe destination node.

Fig. 11 shows the average Evidences’ storage area versusthe aggregation level (L) for 1,000 Evidences. To better clarifythe effect of L on the storage area, the internal plot shows theaverage storage area at small aggregation level (L � 10), butthe external plot shows the average storage area at large


TABLE 6Simulation Parameters

TABLE 7Average Sizes of Receipts, Report, and Evidence (Bytes)

Fig. 11. The average storage area at different aggregation levels.

aggregation levels up to 90. The aggregation level i meansthat the 1,000 Evidences are stored in 1,000/i compactEvidences. The figure demonstrates that the increase of Lover 10 has little effect on the storage area but increases thenumber of redundant Evidences that are submitted if anEvidence is requested. For example, if L is two, 500 aggregatedEvidences are stored and each one can prove the payment fortwo reports, so if an Evidence is requested, the node submits acompact Evidence for two reports. Similarly, if L is 1,000, allthe Evidences are aggregated in only one compact Evidence,and thus if an Evidence is requested, the node submits acompact Evidence for 1,000 reports.

Fig. 12 gives the required storage area to store Evidencesversus the number of Evidences without aggregation andwith aggregating the Evidences in nE compact Evidences.Without aggregation, the Evidences occupy larger storagearea, and the storage area can be reduced when all theEvidences are aggregated in one compact Evidence.

Several measures have been taken to reduce theEvidences’ size in RACE. One Evidence is composed persession regardless of the number of messages instead ofgenerating an Evidence per message. The nodes’ signaturesare hashed to reduce the PROOF size and differentEvidences can be aggregated to a smaller size compactEvidence. Moreover, the nodes of MWN are typicallyequipped with limited energy supplies and the network ischaracterized with limited bandwidth, and it is feasible tobuild cost-effective nodes with more than a gigabyte of flashmemory [36], [37]. Therefore, storage area may not be themain concern, but bandwidth and energy are more scarce,i.e., reducing the amount of submitted data is moreimportant than the size of stored data. As we will discussin Section 6.3, the amount of submitted reports in RACE ismuch less than that of receipt-based payment schemes.

6.3 Communication Overhead

The communication overhead depends on the number andthe size of receipts and reports. The number of receipts andreports generated in a session depends on the frequency ofbreaking the route between the source and destinationnodes because a new receipt/report is generated when theroute is broken, and therefore, the MAC layer and thesimulation parameters will have the same effect on RACEand the receipt-based payment schemes. From Table 7,RACE requires submitting only 23.84 bytes for eachpayment report. This amount of data is much less than

those of the existing receipt-based payment schemesbecause security tokens, e.g., signatures, are systematicallysubmitted in receipt-based schemes but they are submittedonly in case of cheating in RACE. Even if there are manycheaters in the network, RACE requires less communicationoverhead than the existing receipt-based schemes because acheater is excluded once it commits a cheating action. A 512KB data transmission is sufficient for submitting 1,765, 3,641,and 8,192 receipts in Sprite, ESIP, and PIS, respectively, andsubmitting 21,992 reports in RACE.

Table 8 gives the average amount of data to submitreceipts and reports for 10-minute data transmission. Thesource and destination nodes are randomly selected, and anew route is established each time the route between thesource and destination nodes is broken. It can be seen that alarge amount of data are submitted in Sprite because areceipt is generated per message and the receipt size islarge. PIS requires submitting less amount of data than ESIPbecause its receipts’ size is less as indicated in Table 7, butPIS requires two signatures for transmitting a message. Theamount of data to submit reports in RACE are much lessthan those of the receipt-based schemes. Table 8 indicatesthat more reports and receipts are submitted at high nodemobility because the routes are more frequently broken, i.e.,the source node’s messages are transmitted over a largernumber of routes.

6.4 Payment Processing Overhead

Tables 9 and 10 give the processing overhead for clearingthe payment of 10-minute data transmission at differentnode speed in terms of the number of cryptographicoperations, the total energy cost, and the processing time,assuming that the AC is a laptop with an Intel processor at1.2 GHZ and 1 GB RAM. The tables indicate that RACEdoes not need any cryptographic operations for clearing thepayment in case of fair reports. The tables also givethe overhead of verifying an Evidence with X messages.The simulation results indicate that the payment clearanceoverhead of RACE is much less than the existing receipt-based payment schemes. It can also be seen that moreoverhead is required at high node mobility becausemore receipts are generated due to breaking the routesmore frequently, which shows that receipt-based paymentschemes may not be efficiently applicable in case of highnode mobility, but the nodes’ speed has no effect on the paymentclearance overhead in RACE if the reports are fair.


Fig. 12. The average storage area versus the number of Evidences.

TABLE 8The Average Amount of Data to

Submit Receipts and Reports (KB)

The low payment processing overhead can reduce thecomplexity and provide flexibility to the practical imple-mentation of the AC. Moreover, since the payment schemesuse micropayment, the overhead cost should be much lessthan the payment for the effective implementation of theseschemes. The communication and processing overhead ofthe receipts will be very large with taking into account thefollowing facts: 1) the simulation results given in Tables 8, 9,and 10 are only for 10-minute data transmission; 2) thenodes may contact the TP once every few days because thisconnection may not be available on a regular basis and toreduce the communication overhead; and 3) once a route isbroken, a new route is established with a new receipt, andthus multiple receipts may be generated per session.

RACE can significantly reduce the overhead of submit-ting the payment reports and clear the payment with almostno cryptographic operations or processing overhead whencheating actions are infrequent. Widespread cheating is notexpected in civilian applications because the common usersdo not have the technical knowledge to tamper with theirdevices and the manufacturing companies (which are

limited) cannot sacrifice their reputation and face liabilityfor making tampered devices. Moreover, a cheating node isevicted once it commits one cheating action, and changingidentity is not easy or cheap, e.g., the TP can impose fees forissuing new certificates.

7 CONCLUSION AND FUTURE WORK

In this paper, we have proposed RACE, a report-basedpayment scheme for MWNs. The nodes submit lightweightpayment reports containing the alleged charges andrewards (without proofs), and temporarily store undeniablesecurity tokens called Evidences. The fair reports can becleared with almost no cryptographic operations or proces-sing overhead, and Evidences are submitted and processedonly in case of cheating reports in order to identify thecheating nodes. Our analytical and simulation resultsdemonstrate that RACE can significantly reduce thecommunication and processing overhead comparing tothe existing receipt-based payment schemes with acceptablepayment clearance delay and Evidences’ storage area, whichis necessary for the effective implementation of the scheme.Moreover, RACE can secure the payment, and identify thecheating nodes precisely and rapidly without false accusa-tions or missed detections.

In RACE, the AC can process the payment reports to knowthe number of relayed/dropped messages by each node. Inour future work, we will develop a trust system based onprocessing the payment reports to maintain a trust value foreach node. The nodes that relay messages more successfullywill have higher trust values, such as the low-mobility andthe large-hardware-resources nodes. Based on these trustvalues, we will propose a trust-based routing protocol toroute messages through the highly trusted nodes (whichperformed packet relay more successfully in the past) tominimize the probability of dropping the messages, and thusimprove the network performance in terms of throughputand packet delivery ratio. However, the trust system shouldbe secure against singular and collusive attacks, and therouting protocol should make smart decisions regardingnode selection with low overhead.

ACKNOWLEDGMENTS

A part of this paper has been presented in IEEE ICC 2011.

REFERENCES

[1] G. Shen, J. Liu, D. Wang, J. Wang, and S. Jin, “Multi-Hop Relay forNext-Generation Wireless Access Networks,” Bell Labs Technical J.,vol. 13, no. 4, pp. 175-193, 2009.

[2] C. Chou, D. Wei, C. Kuo, and K. Naik, “An Efficient AnonymousCommunication Protocol for Peer-to-Peer Applications OverMobile Ad-Hoc Networks,” IEEE J. Selected Areas in Comm.,vol. 25, no. 1, pp. 192-203, Jan. 2007.

[3] H. Gharavi, “Multichannel Mobile Ad Hoc Links for MultimediaCommunications,” Proc. IEEE, vol. 96, no. 1, pp. 77-96, Jan. 2008.

[4] S. Marti, T. Giuli, K. Lai, and M. Baker, “Mitigating RoutingMisbehavior in Mobile Ad Hoc Networks,” Proc. MobiCom ’00,pp. 255-265, Aug. 2000.

[5] G. Marias, P. Georgiadis, D. Flitzanis, and K. Mandalas,“Cooperation Enforcement Schemes for MANETs: A Survey,”Wiley’s J. Wireless Comm. and Mobile Computing, vol. 6, no. 3,pp. 319-332, 2006.


TABLE 9The Required Cryptographic Operations for Clearing the

Payment of 10-Minute Data Transmission with Smax of 5 m/s

TABLE 10The Required Cryptographic Operations for Clearing the

Payment of 10-Minute Data Transmission with Smax of 10 m/s

[6] Y. Zhang and Y. Fang, “A Secure Authentication and BillingArchitecture for Wireless Mesh Networks,” ACM Wireless Net-works, vol. 13, no. 5, pp. 663-678, Oct. 2007.

[7] L. Buttyan and J. Hubaux, “Stimulating Cooperation in Self-Organizing Mobile Ad Hoc Networks,” Mobile Networks andApplications, vol. 8, no. 5, pp. 579-592, Oct. 2004.

[8] Y. Zhang, W. Lou, and Y. Fang, “A Secure Incentive Protocol forMobile Ad Hoc Networks,” ACM Wireless Networks, vol. 13, no. 5,pp. 569-582, Oct. 2007.

[9] A. Weyland, “Cooperation and Accounting in Multi-Hop CellularNetworks,” PhD thesis, Univ. of Bern, Nov. 2005.

[10] A. Weyland, T. Staub, and T. Braun, “Comparison of Motivation-Based Cooperation Mechanisms for Hybrid Wireless Networks,”J. Computer Comm., vol. 29, pp. 2661-2670, 2006.

[11] S. Zhong, J. Chen, and R. Yang, “Sprite: A Simple, Cheat-Proof,Credit Based System for Mobile Ad-Hoc Networks,” Proc. IEEEINFOCOM ’03, vol. 3, pp. 1987-1997, Mar./Apr. 2003.

[12] M. Mahmoud and X. Shen, “FESCIM: Fair, Efficient, and SecureCooperation Incentive Mechanism for Hybrid Ad Hoc Networks,”IEEE Trans. Mobile Computing, vol. 11, no. 5, pp. 753-766, May 2012.

[13] M. Mahmoud and X. Shen, “PIS: A Practical Incentive System forMulti-Hop Wireless Networks,” IEEE Trans. Vehicular Technology,vol. 59, no. 8, pp. 4012-4025, Oct. 2010.

[14] M. Mahmoud and X. Shen, “Stimulating Cooperation in Multi-hop Wireless Networks Using Cheating Detection System,” Proc.IEEE INFOCOM ’10, Mar. 2010.

[15] N. Salem, L. Buttyan, J. Hubaux, and M. Jakobsson, “NodeCooperation in Hybrid Ad Hoc Networks,” IEEE Trans. MobileComputing, vol. 5, no. 4, pp. 365-376, Apr. 2006.

[16] J. Pan, L. Cai, X. Shen, and J. Mark, “Identity-Based SecureCollaboration in Wireless Ad Hoc Networks,” Computer Networks,vol. 51, no. 3, pp. 853-865, 2007.

[17] M. Mahmoud and X. Shen, “ESIP: Secure Incentive Protocol withLimited Use of Public-Key Cryptography for Multi-Hop WirelessNetworks,” IEEE Trans. Mobile Computing, vol. 10, no. 7, pp. 997-1010, July 2011.

[18] M. Mahmoud and X. Shen, “An Integrated Stimulation andPunishment Mechanism for Thwarting Packet Drop in MultihopWireless Networks,” IEEE Trans. Vehicular Technology, vol. 60,no. 8, pp. 3947-3962, Oct. 2011.

[19] H. Zhu, X. Lin, R. Lu, Y. Fan, and X. Shen, “SMART: A SecureMultilayer Credit Based Incentive Scheme for Delay-TolerantNetworks,” IEEE Trans. Vehicular Technology, vol. 58, no. 8,pp. 4628-4639, Oct. 2009.

[20] R. Lu, X. Lin, H. Zhu, X. Shen, and B.R. Preiss, “Pi: A PracticalIncentive Protocol for Delay Tolerant Networks,” IEEE Trans.Wireless Comm., vol. 9, no. 4, pp. 1483-1493, Apr. 2010.

[21] B. Wehbi, A. Laouiti, and A. Cavalli, “Efficient Time Synchroniza-tion Mechanism for Wireless Multi Hop Networks,” Proc. IEEEPersonal, Indoor and Mobile Radio Comm. (PIMRC), 2008.

[22] D. Johnson and D. Maltz, “Dynamic Source Routing in Ad HocWireless Networks,” Mobile Computing, Chapter 5, pp. 153-181,Kluwer Academic Publishers, 1996.

[23] L. Anderegg and S. Eidenbenz, “Ad Hoc-VCG: A Trustful andCost-Efficient Routing Protocol for Mobile Ad Hoc Networks withSelfish Agents,” Proc. ACM MobiCom, Sept. 2003.

[24] H. Pagnia and F. Gartner, “On the Impossibility of Fair ExchangeWithout a Trusted Third Party,” Technical Report TUD-BS-1999-02, Darmstadt Univ. of Technology, Mar. 1999.

[25] K. Sanzgiri, D. LaFlamme, B. Dahill, B. Levine, C. Shields, andE. Belding-Royer, “Authenticated Routing for Ad Hoc Net-works,” IEEE Selected Areas in Comm., vol. 23, no. 3, pp. 598-610, Mar. 2005.

[26] Y. Hu, A. Perrig, and D. Johnson, “Ariadne: A Secure On-DemandRouting Protocol for Ad Hoc Networks,” Proc. ACM MobiCom,Sept. 2002.

[27] B. Wu, J. Chen, J. Wu, and M. Cardei, “A Survey of Attacks andCountermeasures in Mobile Ad Hoc Networks,” Wireless NetworkSecurity, Springer Network Theory and Applications, vol. 17, pp 103-135, 2007.

[28] S. Even, O. Goldreich, and S. Micali, “On-Line/off-line DigitalSignatures,” Crypto ’89: Proc. Advances in Cryptology, pp. 263-277,1990.

[29] O. Nibouche, M. Nibouche, A. Bouridane, and A. Belatreche, “FastArchitectures for FPGA-Based Implementation of RSA EncryptionAlgorithm,” Proc. IEEE Field-Programmable Technology Conf., Dec.2004.

[30] J. Yoon, M. Liu, and B. Nobles, “Sound Mobility Models,” Proc.ACM MobiCom, Sept. 2003.

[31] A. Menzies, P. Oorschot, and S. Vanstone, Handbook of AppliedCryptography. CRC Press, http://www.cacr.math.uwaterloo.ca/hac, 1996.

[32] Nat’l Inst. of Standards and Technology (NIST), “Recommenda-tion for Key Management - Part 1: General (Revised),”SpecialPublication 800-57 200, 2007.

[33] NIST, “Digital Hash Standard,”Fed. Information ProcessingStandards Publication 180-1, Apr. 1995.

[34] D. Wei, “Crypto++ Library 5.6.0,” http://www.cryptopp.com,Oct. 2011.

[35] N. Potlapally, S. Ravi, A. Raghunathan, and N. Jha, “A Study ofthe Energy Consumption Characteristics of Cryptographic Algo-rithms and Security Protocols,” IEEE Trans. Mobile Computing,vol. 5, no. 2, pp. 128-143, Mar./Apr. 2006.

[36] P. Desnoyers, D. Ganesan, H. Li, M. Li, and P. Shenoy, “PRESTO:A Predictive Storage Architecture for Sensor Networks,” Proc. 10thWorkshop Hot Topics in Operating Systems (USENIX HotOS), June2005.

[37] A. Mitra, A. Banerjee, W. Najjar, D. Zeinalipour-Yazti, V.Kalogeraki, and D. Gunopulos, “High-Performance Low PowerSensor Platforms Featuring Gigabyte Scale Storage,” Proc. IEEE/ACM Third Int’l Workshop Measurement, Modeling, and PerformanceAnalysis of Wireless Sensor Networks (SenMetrics ’05), July 2005.


Mohamed M.E.A. Mahmoud received the PhDdegree (April 2011) in electrical and computerengineering from the University of Waterloo,Waterloo, Ontario, Canada. He is currently apostdoctoral fellow with the Centre for WirelessCommunications, Department of Electrical andComputer Engineering, University of Waterloounder the supervision of Professor Sherman(Xuemin) Shen. His research interests includewireless network security, privacy-preserving

schemes, anonymous and secure routing protocols, trust and reputationsystems, cooperation incentive mechanisms, and cryptography. He isthe first author for more than 20 papers published in major IEEEconferences and transactions. He won the prestigious Best PaperAward from the IEEE International Conference on Communications(ICC’09), Dresden, Germany, 2009. This award was one of only 14given, among 1,046 papers presented and more than 3,000 submitted,and was the sole award for the Communication and InformationSystems Security Symposium. He also served as a technical programcommittee member and reviewer for many conferences and journals.

Xuemin (Sherman) Shen received the BScdegree from Dalian Maritime University, China,in 1982, and the MSc and PhD degrees fromRutgers University, Camden, New Jersey, in1987 and 1990, respectively, all in electricalengineering. He is currently a professor and theUniversity research chair with the Centre forWireless Communications, Department of Elec-trical and Computer Engineering, University ofWaterloo, Ontario, Canada. He is the author or

coauthor of three books and more than 400 papers and book chapterson wireless communications and networks, control, and filtering. Heserves as the editor-in-chief for peer-to-peer networking and applica-tions and an associate editor for Computer Networks, ACM/WirelessNetworks, and Wireless Communications and Mobile Computing. Hehas also served as a guest editor for ACM Mobile Networks andApplications. His research focuses on mobility and resource manage-ment in interconnected wireless/wired networks, ultra wideband wirelesscommunications networks, wireless network security, wireless bodyarea networks, and vehicular ad hoc and sensor networks. He is aregistered professional engineer in the Province of Ontario and adistinguished lecturer of the IEEE Communications Society. He receivedthe Excellent Graduate Supervision Award in 2006 and the OutstandingPerformance Award in 2004 and 2008 from the University of Waterloo,the Premier’s Research Excellence Award in 2003 from the Province ofOntario, and the Distinguished Performance Award in 2002 and 2007from the Faculty of Engineering, University of Waterloo. He served asthe tutorial chair for the 2008 IEEE International Conference onCommunications, the technical program committee chair for the 2007IEEE Global Telecommunications Conference, the general co-chair forthe 2007 International Conference in Communications and Networkingin China, and the 2006 International Conference on Quality of Service inHeterogeneous Wired/Wireless Networks, and the founding chair forIEEE Communications Society Technical Committee on P2P Commu-nications and Networking. He also serves as a founding area editor forthe IEEE Transactions on Wireless Communications and an associateeditor for the IEEE Transactions on Vehicular Technology and the KICS/IEEE Journal of Communications and Networks. He has also served asa guest editor for theIEEE Journal on Selected Areas in Communica-tions, IEEE Wireless Communications, and the IEEE CommunicationsMagazine. He is a fellow of the IEEE.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


ieee transactions on parallel and distributed …mmahmoud/publications... · a secure payment...

Documents