Trust-Based Secured Cooperation Incentive Scheme For Multi-Hop Wireless Network

Trust-Based Secured Cooperation Incentive Scheme For Multi-Hop Wireless Network

Shravanthi T Dept of CSE, BIT, VTU, India, Sowmya T Dept of CSE, BIT, VTU, ,Shresta N M Dept of CSE, BIT, VTU,India,

Abstract- Existing credit card payment schemes are designed for different system and threat models, which are infeasible for MWNs, we propose a 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, RACE can secure the payment and precisely identify the cheating nodes without false accusations.

Keywords- Cooperation incentive schemes, payment schemes, accusation.

1. INTRODUCTION

   In multihop wireless networks (MWNs), the traffic originated from a node is usually relayed through the other nodes to the destination for enabling new applications and enhancing the network performance and deployment [1]. MWNs can be deployed readily at low cost in developing and rural areas. Multihop packet relay can extend the network coverage using limited transmit power, improve area spectral efficiency, and enhance the network throughput and capacity. MWNs can also implement many useful applications such as data sharing [2] and multimedia data transmission [3]. For example, users in one area (residential neighborhood, university campus, etc) having different wireless-enabled devices, e.g., PDAs, laptops, tablets, cell phones, etc, can establish a network to communicate, distribute files, and share information.

   In this paper, we propose RACE, a Report-based pAyment sChemE for MWNs. The nodes submit lightweight payment reports (instead of receipts) to the AC to update their credit accounts, and temporarily store undeniable security tokens called Evidences. The reports

   contain the alleged charges and rewards of different sessions without security proofs, e.g., signatures.

   The AC verifies the payment by investigating the consistency of the reports, and clears the payment of the fair reports with almost no cryptographic operations or computational overhead. For cheating reports, the Evidences are requested to identify and evict the cheating nodes that submit incorrect reports, e.g., to steal credits or pay less. In other words, the Evidences are used to resolve disputes when the nodes disagree about the payment. Instead of requesting the Evidences from all the nodes participating in the cheating reports, RACE can identify the cheating nodes with submitting and processing few Evidences. Moreover, Evidence aggregation technique is used to reduce the storage area of the Evidences.

   In RACE, Evidences are submitted and the AC applies cryptographic operations to verify them only in case of cheating, but the nodes always submit security tokens, e.g., signatures, and the AC always applies cryptographic operations to verify the payment in the existing receipt-based schemes. RACE can clear the payment nearly without applying cryptographic operations and with submitting lightweight reports when Evidences are not frequently requested. Wide-spread cheating actions are not expected in civilian applications because the common users do not have the technical knowledge to tamper with their devices. Moreover, cheating nodes are evicted once they commit one cheating action and it is neither easy nor cheap to change identities.

   To the best of our knowledge, RACE is the first payment scheme that can verify the payment by investigating the consistency of the nodes reports without systematically submitting and processing security tokens and without false accusations. RACE is also the first scheme that uses the concept of Evidence to secure the payment and requires applying cryptographic operations in clearing the payment only in case of cheating.

2. RELATED WORKS

   The existing payment schemes can be classified into tamperproof- device (TPD) based and receipt-based schemes. In TPDbased payment schemes [7-10], a TPD is installed in each node to store and manage its credit account and secure its operation. For receipt-based payment schemes [11-20], an offline central unit called the accounting center stores and manages the nodes credit accounts. The nodes usually submit undeniable proofs for relaying packets, called receipts, to the AC to update their credit accounts.

   Table 2 gives the description of the used symbols in this paper.

   Table 2: Description of the used symbols.

   In this paper, we adopt the network model used in [7-17] that targets the civilian applications of MWNs, where the network has long life and the nodes have long-term relations with the network. As illustrated in Fig. 1, the considered MWN has an offline trusted party (TP) and mobile nodes. The TP contains the accounting center

   (AC) and the certificate authority (CA). The AC maintains the nodes credit accounts and the CA renews and revokes the nodes certificates. Each node A has to register with the trusted party to receive a symmetric key KA, private/public key pair, and certificate. The symmetric key is used to submit the payment reports and the private/public keys are required to act as source or destination node. We assume that the clocks of the nodes are synchronized. The details of this synchronization process are out of the scope of the paper, but several mechanisms have been proposed to synchronize the nodes clocks [21]. Once the AC receives the payment reports of a session and verifies them, it clears the payment if the reports are fair; else, it requests the Evidences to identify the cheating nodes. The CA evicts the cheating nodes by denying renewing their certificates.

   For the payment model, source nodes are charged for every transmitted message even if it does not reach the destination nodes, but the intermediate nodes are rewarded only for the delivered messages.

3. PROPOSED SCHEME

   As shown in Fig. 2, RACE has four main phases. In Communication phase, the nodes are involved in communication 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.

   Communication

   The Communication phase has four processes: route establishment, data transmission, Evidence composition, and payment report composition/submission.

   Route establishment: In order to establish an end-to- end

   route, the source node broadcasts the Route Request (RREQ) packet containing the identities of the source (IDS) and the destination (IDD) node, 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 its identity and broadcasts the packet if the number of intermediate nodes is fewer than TTL. The destination node composes the Route Reply (RREP) packet for the nodes broadcasted the first received RREQ packet, and sends the packet back to the source node. The destination node creates a hash chain by iteratively hashing a random value (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 K depends on many factors such as the number of messages the source node needs to send, and the average number of messages sent through a route before it is broken, i.e., due to node mobility. Estimating a good value for K can save the destination nodes resources because once a route is broken, the unused hash values in the hash chain should not be used for another route to secure the payment. The nodes can estimate the value of K and periodically tune it.

   The RREP packet contains the identities of the nodes in the route (e.g., R = IDS, IDA, IDB, IDD in the route shown in Fig. 3), h(0), and the destination nodes certificate and signature (SigD(R, Ts, h(0))). This signature authenticates the hash chain and links it to the route. The intermediate nodes verify the destination nodes signature, relay the RREP packet, and store the signature and h(0) for composing the Evidence.

   Data transmission: The source node sends data packets to the destination node through the established route and the destination node replies with ACK packets. For the Xth data packet, the source node appends the message MX and its 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 are illustrated in Fig. 3. The source nodes signature is an undeniable proof for transmitting X messages and ensures the messages authenticity and integrity. Signing the hash of the message instead of the message can reduce the Evidence size because the smaller-size H(MX) is attached to the Evidence instead of MX. Before relaying the packet, each intermediate node verifies the signature to ensure the messages authenticity and integrity, and verifies R and X to secure the payment. Each node stores only the last signature for composing the Evidence, which is enough to prove transmitting X messages, e.g., after receiving the Xth data 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 data transmission process ends when the source node transmits its last message, or if the route is broken,

   e.g., due to node mobility or channel impairment. Algorithm 1 gives the pseudo code of the processes of data transmission and composition of Evidence and report.

   After receiving the Xth data packet, Fig. 3 shows that the destination node sends back an ACK packet containing the pre-image of the last sent hash value (or h(X)) to acknowledge receiving the message MX, where h(1) is released in the first ACK and h(2) in the second and so on. Each intermediate node verifies the hash value by making sure that h(X-1) is obtained from hashing h(X). The nodes store only the last released hash value for composing the Evidence. The possession of h(X) by a node is a proof of delivering X messages, but the possession of SigS(R, X, Ts, H(MX)) is a proof of delivering X-1 messages and receiving one. The number of delivered messages can be computed from the number of hashing operations to map h(X) to h(0), and the number of transmitted messages (X) is signed by the source node. An intermediate node cannot drop the Xth data packet and claim delivering it because the hash function is one way, i.e., it is computationally infeasible to compute h(X) from h(X-1). Hash chains have been used for many purposes due to their low energy and computational overhead, and nonrepudiation and one- way properties. In RACE, hash chains are used to reduce the number of public key cryptography operations, i.e., instead of generating a signature per ACK packet to secure the payment, one signature is generated by the destination node per K ACK packets.

   Evidence composition: Evidence is defined as information that is used to establish proof about the occurrence of an event or action, the time of occurrence, the parties involved in the event, and the outcome of the event. The purpose of an Evidence is to resolve a dispute about the amount of the payment resulted from data transmission. Fig. 4 gives the general format of an Evidence. The figure shows that an Evidence contains two main parts called DATA and PROOF. The DATA describes the payment, i.e., who pays whom and how much, and contains the necessary data to regenerate the nodes signatures. From Fig. 4, the DATA contains the identities of the nodes in the route (R), the number of received messages (X), the session establishment time stamp (Ts), the root of the destination nodes hash chain h(0), the hash value of the last message (H(MX)), and the last received hash value (h(V)). V = X-1 when the last received packet is the Xth data packet because the route is broken before 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) is not received. The PROOF is an undeniable security token that can prove the correctness of the DATA and protect

   against payment manipulation, forgery, and repudiation. The PROOF is composed by hashing the destination nodes signature and the last signature received from the source node, instead of attaching the signatures to reduce the Evidence size.

   Evidences have the following main features:

   1. Evidences are unmodifiable: If X messages are delivered, the intermediate nodes can compose Evidences for fewer than X messages, but not for more. This is because the intermediate nodes have SigS(R, i, Ts, H(Mi)) and h(i) for i = {1, 2, .. , X}, which are sufficient for composing Evidences for fewer than X messages. However, the intermediate nodes cannot compose Evidences for more than X because it is computationally infeasible to compute SigS(R, i, Ts, H(Mi)) or h(i) for i > X.

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

   3. Evidences are unforgeable: If the source and destination nodes collude, they can create Evidence for sessions that did not happen, but the intermediate nodes cannot, because forging the source and destination nodes signatures is infeasible.

   4. Evidences are undeniable: This is necessary to enable the TP to verify them to secure the payment. A source node cannot deny initiating a session or the amount of payment because it signs the number of transmitted messages and the signature is included in the Evidence.

   5. An honest intermediate node can always compose valid Evidence even if the route is broken or the other nodes in the route collude to manipulate the payment. This is because it can verify the Evidences to avoid being fooled by the attackers.

   Reducing the storage area of the Evidences is important because they should be stored until the AC clears the payment. Onion hashing technique can be used to aggregate Evidences. The underlying idea is that instead of storing one PROOF per session, one compact PROOF can be computed to prove the credibility of the payment of a group of sessions. The compact Evidence contains the concatenation of the DATAs of the individual Evidences and one compact PROOF that is computed by onion hashing the PROOFs of the individual Evidences. Let

   PROOF(i) refer to the PROOF of the Evidence number i, the compact PROOF is computed as follows:

   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 adding one hashing layer.

   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 Submission Packet (RSP) to the TP at time ti to submit the reports of the sessions held since the last contact at ti-1. The packet contains the reports of the sessions held in [ti-1, ti) (Reports[ti-1, ti)), timestamp (Ts), and a keyed hash value (HKA()) to ensure the packets 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 been manipulated and the reports are indeed sent by the intended node, which is important to secure the payment and hold the nodes accountable for any misbehavior. If the TP requests Evidences from node A, it sends an Evidences Request Packet (EREQ) containing the identifiers of the reports that their Evidences are requested (Ses_IDs[ti-2, ti-1)). Node A replies with Evidences Reply Packet (EREP) containing the requested Evidences (Req_Evs[ti-2, ti- 1)). If node A is honest, the TP sends a Renewed Certificate Packet (RCP) containing a renewed certificate for node A with the same identity and public/private keys but with updated lifetime. Therefore, only the efficient hashing operations are used to submit the reports and Evidences securely to the TP. Note that RSP and RCP are also required in receipt-based payment schemes to submit the receipts.

4. FLOW CHART Transaction Process Flow at Intermediate Nodes:

Start

Payment Gateway Verification Flow Chart:

Start

Receive Transaction Request From Client

Send Request for Report Submission

No If Available for Transaction

Yes

Report Fetch Process

Stop

Send Approve Response

Verify Report

Transaction Process

NO If Verification is successful?

YES

Receive Signature of Client

Verify Hash value by recalculation

Submit details for Account Update

Pass The Signature to the Next Node

NO If Verified?

YES

Invalidate the transaction

Invalidate the transaction

Validate Transaction

Identity Cheating Node

Receive Hash Value

Pass Validated data for Account updatae

Pass Validated data for Account updatae

Stop

CONCLUSION

In this paper, we have designed a system that provides secure offline payment scheme that reduces the processing overhead on PG(Payment gateway).The nodes submit lightweight payment reports and temporarily store Evidences. The fair reports can be cleared with almost no cryptographic operations. The PG runs heavy cryptographic algorithms only when the nodes submit incorrect hash values and those nodes are evicted for future transactions.

REFERENCES

1. G. Shen, J. Liu, D. Wang, J. Wang, and S. Jin, Multi-hop relay for next-generation wireless access networks, Bell Labs Technical Journal, vol. 13, no. 4, pp. 175-193, 2009.

2. C. Chou, D. Wei, C. Kuo, and K. Naik, An efficient anonymous communication protocol for peer-to-peer applications over mobile ad-hoc networks, IEEE Journal on selected areas in communications, vol. 25, no. 1, January 2007.

1. S. Marti, T. Giuli, K. Lai, and M. Baker, Mitigating routing misbehavior in mobile ad hoc networks, Proc. of ACM Mobile Computing and Networking (MobiCom00), pp. 255265, Boston, Massachusetts, USA, August 6-11, 2000.

2. G. Marias, P. Georgiadis, D. Flitzanis, and K. Mandalas, Cooperation enforcement schemes for MANETs: A survey, Wiley's Journal of Wireless Communications and Mobile Computing, vol. 6, issue 3, pp. 319332, 2006.

3. Y. Zhang and Y. Fang, A secure authentication and billing architecture for wireless mesh networks, ACM Wireless Networks, vol. 13, no. 5, pp. 663678, October 2007.

4. L. Buttyan and J. Hubaux, Stimulating cooperation in selforganizing mobile ad hoc networks, Mobile Networks and Applications, vol. 8, no. 5, pp. 579-592, October 2004.