Robust Node ID Assignment for Mobile P2P Networks

TL;DR

This paper introduces PJ-Sec, a robust node ID assignment mechanism for mobile P2P networks that enhances security against adversarial attacks through collaborative ID generation and formal security analysis.

Contribution

It proposes a novel collaborative node ID assignment method for mobile P2P networks, ensuring security and resistance to attacks.

Findings

PJ-Sec resists common attack vectors in mobile P2P networks.

Formal analysis confirms PJ-Sec's security properties.

The mechanism facilitates secure peer joining in dynamic environments.

Abstract

The advancement of portable mobile wireless devices such as smart-phones, PDA, etc., brought mobile peer-to-peer (P2P) as an extension of traditional P2P networks to provide efficient, low-cost communication among them in a cellular network. It is challenging to assign a unique identifier to each user, as an adversary can target to disrupt the P2P system, by carefully selecting user IDs or obtaining many pseudo-IDs. This work proposes a robust node-ID assignment mechanism for secure peer joining in mobile P2P system called PJ-Sec. PJ-Sec facilitates to generate nodeID for a joining peer by a collaborative effort of an existing peer (within the vicinity) and pre-selected vicinity head. PJ-Sec is formally analyzed using AVISPA model checker and found to be attack resistant.

Figures

Tables

Table 1. Table 1: Summary of cryptographic operations.

Security Protocols	Mul	Add	Hash	Inverse
Our Proposed	\cellcolorgreen!25 23	12	3	\cellcolorgreen!25 1
Protocol (PJ-Sec)	\cellcolorgreen!25			\cellcolorgreen!25
IAP  [11]	52	10	3	8
RIAPPA  [10]	147	25	3	21

Equations

$$\mathbb{H}(I{P}_N||P{U}_N||{\gamma }_1)$$

$$T_N=Sig{n}_{s_v}\{I{P}_N,P{U}_N,I{D}_N,I{D}_B,I{D}_V,T\}$$

$$(I{P}_N,{\alpha }_1,I{D}_N,I{D}_B,I{D}_V,time)$$

$$S(bits/s/Hz)=B{W}_{eff}.\eta .{\log }_2(1+SNR/SN{R}_{eff})$$

Full text

K****eywords Distributed Hash Table  $\cdot$ Mobile P2P  $\cdot$ Secure Node Assignment

1 Introduction

Annual Visual Networking Index (VNI) Forecasts, smart-phones will surpass 86% of mobile data traffic by 2021, and it will grow at a compound annual growth rate (CAGR) of 47% from 2016 to 2021 [1]. To reduce network traffic in a cellular network, an alternative solution is to introduce peer to peer (P2P) overlay communication through device-to-device (D2D)/Bluetooth/WiFi. Many research works have been carried out to collaborate P2P overlay with mobile infrastructure (5G/LTE-A/3G, etc.) to provide scalable and efficient data sharing such as C-Chord [2], V-Chord [3].

On the other hand, most of the P2P overlays are developed without considering the security aspects during the new identifier (ID) assignment. Generally, the overlays generate peer ID locally using hash computation over IP addresses (like Chord [4], Kademlia [5]), or randomly by client software as in Pastry [6], or by their assigned clusters which are selected by cluster members as in CAN [7].

The underlying assumption in these overlays is that its members (smart-phones, PDAs, etc.) behave honestly, which would be hard in a wireless environment. It is observed that the existence of anonymous peers and lack of central authority make the overlay vulnerable. Best way to develop a secure overlay is to restrict the malicious peer during the bootstrap process. Thus, secure node joining is considered to be the topmost priority to develop the secure routing primitives such as secure maintenance of routing table and routing messages as discussed in  [8, 9].

The centralized secure nodeID assignment mechanisms including a Robust Identity Assignment Protocol for P2P overlays (RIAPPA)  [10], and Identity Assignment Protocol (IAP)  [11] suffer from a single point of failure. On the other hand, decentralized solutions like  [12, 13] uses collaborative efforts of some existing peers without requiring a centralized server. But, these security protocols need high computation and communication overhead, so not suitable to use in mobile or cellular systems.

Meanwhile, a mobile or cellular DHT overlay can be framed to simplify the P2P applications like file-sharing. Moreover, the whole network can be divided into several clusters/vicinity with at least one serving super-peer/cluster head in each vicinity.

This work proposes a secure node joining protocol tailoring to super-peer based cellular overlays. This mechanism assigns nodeID to a new peer as a collaborative effort of an existing overlay member ( a friend peer) and its serving super-peer, mitigating Sybil, Eclipse, and man-in-the-middle (MITM) attacks..

The rest of the paper is organized as follows. Related work is presented in Section 2. Section 3 illustrates the system model, points out its vulnerability, and design requirement for ID assignment protocols. In Section 4, we present the proposed secure peer assignment protocol (PJ-Sec). Design requirement analysis, security analysis, and formal verification are discussed in Section 5. Implementation and result analysis of PJ-Sec are performed in Section 6. Finally, we present the concluding remarks in Section 7.

2 Related Work

There are several secure P2P nodeID assignment techniques proposed in past, which can be categorized as centralized and distributed key-based solutions.

2.1 Centralized nodeID generation

In this approach, new nodes are generated and certified through a certificate authority (CA) as in  [14, 15, 16]. Due to the centralized management of keys, it provides a unique identity for a new node. This feature makes it resistant against Sybil identities. These CAs are not responsible for distributing the nodeIDs uniformly in a virtual space, but the assigned IDs are properly bound with their assigned certificate through respective CA. Using these certificates, CAs can visualize illegal actions of nodes and revoke their certificates to eliminate the compromised nodeIDs. Certification revocation is costly due to processing and administrative overheads.

For generating nodeID,  [17, 18, 19] introduced joint authentication process such as identity based encryption (IBE) through trusted authority. In this, the hash function is computed over the signed public key, or human interaction with CAs to improve the efficiency. It helps CAs in the nodeIDs authentication process.

Caubet et al. in  [11] proposed an implicit certificate based solution. Implicit certificates ignore the issuer’s signature and thus, makes it less computing with reduced size. In this protocol, new nodeIDs are generated by collaboration with CA. To preserve user’s anonymity with traceability feature, RIAPPA [10], was proposed. RIAPPA uses two trusted third parties (TTP) and the IDs are authenticated by an external TTP using their real-world digital certificate, while the internal TTP manages their node IDs jointly.

Vinayagam et al. in  [20] presented a restricted identity-based proxy re-encryption mechanism to mitigate forge IDs in P2P overlays. Each peer has to register its ID to a proxy server, after joining into the overlay. After registration, the proxy generates a signature for each node, which can be verified during communication at both the (sender and receiver) ends. Thus, forge nodeIDs can be detected.

2.2 Distributed nodeID generation

The existing mechanisms in this category simplify new node joining in a distributed overlay. Dinger et al.  [13] verified the generated nodeID by a certain number of existing nodes ({E}) in the overlay. For unauthorized ID, the certificate is revoked by $N_{j}(\in\{E\})$ to protect from Sybil IDs. Certificate revocations would be unsuitable for a mobile phone due to energy consumption and tariff for the Internet.

Khan et al.  [12] proposed a secure identity establishment protocol, called MIDEP, for P2P distributed peers. It establishes a secure non-traceable public identity with the help of peer collaboration to avoid identity shadowing and MITM attacks. In this, a unique user ID is divided into different parts and some random parts are selected to send to the collaborators. Each collaborator receives a unique ID part for further processing. A temporary public ID is constructed after receiving a threshold number of processed (response from the collaborators) ID parts.

Castro et al.  [14] presented a cryptographic puzzle for binding generated ID with its corresponding node IP address. In this, each user chooses a key pair to make first p bits to zero after hashing the public key. This computational challenge limits the nodeIDs to generate Sybil IDs. Further, Rowaihy et al.  [21] proposed a series of cryptographic puzzles to limit the Sybil attack. They used refreshment mechanism for assigned challenges to avoid adversary recalculation of the given challenge. To reduce computational cost during refreshment, Costa et al.  [22] introduced an adaptive mechanism for generating computational puzzles which reduce forge ID attacks but not completely. Fang et al. [23] developed a multi-criteria fuzzy decision-making model considering the dynamic of networks. It is self-adaptive and uses game theory concept to predict trust in the fuzzy and complex environment. In this, a newly joined node is assigned (by the existing nodes) a nonessential data during the test-period to build the trust. It helps to isolate the node if the trust values are not reached to a threshold during a specific period.

Avramidis et al.  [24], proposed distributed trust infrastructure for Chord-based P2P overlay to reduce computational cost during new nodeID generation and verification. In this, nodes maintain a set of certificates as a tag of each revocation without executing the actual revocation process. To improve the distributed trust infrastructure, Shi et al.  [25] proposed a human-established trust model, which identifies Sybil IDs with the help of human feedback. These models take several communications to build trust among nodes including some possibility of forge ID generation. Inspired by the human-established trust model, Xianfu et al. [26] developed a guarantee-based trust model for Chord-based P2P networks in which, a joining peer evaluates all the eligible service peers using reputation. The new node joins with the service provider having a higher reputation. However, the presence of a malicious service provider would influence the trust establishment for local node-ID generation process [27], leading to a cascade effect.

3 System model, Adversary model, and Design Requirements

In this section, we discuss the operational structure of the super-peer based P2P overlay architecture and state the goal of an adversary.

3.1 System Model

Consider a system like (the current) Gnutella [28] network, which consists of super-peers [29]. In cellular networks, these super-peers consume Internet connection and wish to serve other peers (smart-phones) through WiFi/Bluetooth/D2D connectivity as in  [3, 2]. The overlay members (peers and super-peers) are connected within their communication range forming a cluster/vicinity as depicted in Figure  1a. Vicinity 1 and 2 are managed by separate super-peers under the same eNodeB 1 region, while vicinity 3 and 4 are in eNodeB 2 and eNodeB 3 respectively. A mobile station ($MS_{i}$) communicates with the target node ($MS_{j}$), which is within the range of WiFi connected super-peers (intra-region), within the same eNodeB (intra- region) or another eNodeB region (inter-region).

Each member has a unique overlay ID and constructs an overlay structure as shown in Figure 1b. In this, each ID is assigned with an $m$-bit DHT overlay ID. The $b$ most significant bit of $m$-bit specifies the corresponding $eNodeB$. Next, $p$-bit specifies the associated super-peer and remaining $h$-bit specifies the node under the super-peer. The ID assignment process of a new node is performed by a super-peer. The joining request may reach at super-peer through the existing peer(s).

3.2 Adversary model

We assume that vicinity head (or super-peer) are chosen periodically and on demand, by the majority (voting). The eNodeB and super-peer are assumed to be trusted. The adversary is considered to be a probabilistic polynomial time (PPT) which cannot break (existing standard) cryptographic mechanisms. The primary goal of the adversary is to generate multiple fake IDs called Sybil IDs targeting to perform different attacks and control the network.

• •

Sybil Attack: Maintaining multiple forge IDs to perform malicious activities is referred to as Sybil attack [15]. These artificial nodeIDs behave like a genuine nodeID of a network and try to spread themselves to take control over the network.

• •

Eclipse Attack: Purpose of this attack is to make a group of nodes isolated from rest of the network. In this, a genuine node is forced to communicate with others through adversary nodes.

• •

MITM Attack: Here, an intermediate node tries to manipulate or handle secretly two-party communication without their concern.

3.3 Design Requirements

A secure and robust identity assignment mechanism is desired to have the following features.

Uniqueness: This requirement is specific to reduce the Sybil attack to provide unique nodeID to each real identity. The solution should restrict adversaries to generate multiple IDs. 2. 2.

Stability: To maintain its own reputation, this requirement enforces that a node should not change its own nodeID itself. The collaboration effort while node IDs generation would perfect in stability. 3. 3.

Joint Management: This requirement is necessary to avoid Eclipse attack. In this, nodeIDs must be issued with collaboration among few peers. 4. 4.

Verifiable: In which, member nodes can be able to check whether the nodeID and generated certificate are appropriately bounded or not. 5. 5.

Traceability: This requirement facilitates that a misbehavior node should be traced with its given identity and generated nodeID. If a user does some malicious actions within its overlay, then the proposed scheme should be able to trace back the corresponding user at a later point of time and could be able to match the nodeID with the user’s unique identity. 6. 6.

Revocability: This requirement states that if any malicious activity is detected, the certificate of the corresponding user can be revoked. 7. 7.

Uniformity: This requirement is necessary to distribute a load of an overlay to generate uniformly nodeIDs. NodeID should be assigned from a uniform distribution of overlay IDs within an allocated ID space. 8. 8.

Scalability: It provides a large number of nodes to associate in the overlay. 9. 9.

Efficient: This requirement is necessary to save communication cost, computational cost, and energy consumption of overlay mobile members.

4 PJ-Sec: The Proposed Scheme

The basic idea of PJ-Sec is that a new node has to know a friend (bootstrap) node which would forward the joining request to the corresponding super-peer (in its vicinity).

4.1 Protocol Specification

PJ-Sec facilitates to compute an overlay ID for a new node (N) in collaboration of three entities (new node ($N$), its friend node ($B$) and vicinity head ($V$)). The Operation of the proposed scheme consists of three phases, namely, initialization phase, joining phase, and the endorsement phase. as depicted in Figure 2 and discussed below.

Initialization Phase: Let $\mathbb{G}$ be a group of large prime order $\mathbb{P}$ and $G\in\mathbb{G}$ be the primitive element of $\mathbb{G}$. The system-wide parameters $\langle\mathbb{G},\mathbb{P},G\rangle$ are available to all entities. The bootstrap node ($B$) and vicinity head ($V$) already exist in the overlay and thus, they have chosen $s_{b}$ and $s_{v}$ $(\in{\leftarrow}{\mathbb{Z}_{\mathbb{P}}}^{*}$) as their private key respectively. $PU_{B}$ (= $s_{b}\boldsymbol{\cdot}G$) and $PU_{V}$ (= $s_{v}\boldsymbol{\cdot}G$) are the corresponding public keys of B and V. 2. 2.

Joining Phase: It is assumed that the new node (N) willing to join into the overlay, has all the public parameters and the ID of at least one friend node. The public parameters can be obtained while installing the overlay code, while a friend nodeID can be obtained through a different channel.

$N$ selects a random number $s_{n}$ $\overset{\,U}{\leftarrow}{\mathbb{Z}_{\mathbb{P}}}^{*}$ as its private key, calculates $PU_{N1}$ ($=s_{n}\boldsymbol{\cdot}G$) and executes the following steps.

• Step 1:

$N$ contacts to its friend node ($B$), with a joining request containing its unique ID (such as IP address/ real identity) and its public key as $\langle IP_{N}||PU_{N}\rangle$.

• Step 2:

After receiving the joining request from $N$, $B$ extracts $IP_{N}$ and $PU_{N}$ and calculates $\beta_{1}=(s_{b}\boldsymbol{\cdot}PU_{N})$. Afterwards $B$ sends $\langle IP_{N}||PU_{N1}||\beta_{1}\rangle$ to $V$.

• Step 3:

Once, V receives the forwarded joining request from $B$, it computes $\gamma_{1}=(v\boldsymbol{\cdot}\beta_{1})$ and $\gamma_{2}=(v\boldsymbol{\cdot}PU_{B})$. If forwarded node is not a trusted node, the forwarded ID to generate a nodeID would be rejected. Otherwise, $V$ computes overlay ID for node $N$ ($ID_{N}$) as:

[TABLE]

where, $\mathbb{H}$ is a standard hash function like SHA1.

Pilot V generates a token ($T_{N}$) as shown in Eqn. 2 for $ID_{N}$, which includes unique real ID of node N ($IP_{N}$), its public key ($PU_{N}$), friend node overlay ID ($ID_{B}$), the Pilot ID ($ID_{V}$) and issuing token time stamp ($T$). V returns the signed token ($T_{N}$) to $B$ (friend node of $A$) which is signed by the pilot’s private key ($s_{v}$).

[TABLE]

• Step 4:

B verifies the $ID_{N}$ using its private key as follows. It computes $\beta_{2}=(s_{b}\boldsymbol{\cdot}\gamma_{2})$ and $\beta_{3}=s_{v}\boldsymbol{\cdot}s_{b}\boldsymbol{\cdot}G$. Subsequently, it computes $ID^{\prime}_{N}$ as $\mathbb{H}(IP_{N}||PU_{N}||\beta_{2})$. Then, it verifies $ID^{\prime}_{N}\stackrel{{\scriptstyle?}}{{=}}ID_{N}$. On successful verification B sends $(ID_{N}||T_{N}||\beta_{3})$ to N.

Endorsement Phase: After receiving the response from $B$, $N$ computes $\alpha_{2}=(s_{n}\boldsymbol{\cdot}\beta_{3})$ and $ID_{N}^{\prime}=\mathbb{H}(IP_{N}||PU_{N}||\alpha_{2})$. Finally, it checks $ID_{N}^{\prime}\stackrel{{\scriptstyle?}}{{=}}ID_{N}$ to confirm its token ($T_{N}$) and use it for further communication from other members.

Later on, while communicating a peer can verify the $ID_{N}$ from its token. If the verifying peer trusts the vicinity node, it trusts $ID_{N}$ otherwise computes the trust through its associated pilot vicinity-head.

5 Analysis

5.1 Design Requirement Analysis

Our proposed nodeID assignment PJ-Sec achieves the following features.

• •

Uniqueness: In our scheme, each user uses its own unique identity ($IP_{N}$) as its mobile number. It assumes that smart-phones are the component of the cellular P2P overlay; therefore, they are verified by its unique identity to stop generating many overlay IDs for a single mobile. Each unique overlay ID is wrapped with its unique identification to generate a unique nodeID and its corresponding token. This token can be verified at each communicating peer to prevent the Sybil IDs. So each ID is assumed to be unique.

• •

Stability: The proposed scheme collaborates an existing member peer and the head peer to offer stability among overlay IDs. Therefore, a single node fails to change the nodeID.

• •

Joint Management: In our mechanism, each new node concatenates its public key with own unique identity ($IP_{N}$) and sends to a friend node ($B$) with joining request in the overlay. Further, this information forwards to vicinity head ($V$) after concatenating node $B$’s public key. A token ($T_{N}$) is generated and verified by the friend node before the final assignment of new ID. Moreover, the nodeID (Eqn. 1) is computed as the collaborative effort of three different nodes $N$, $B$, and $V$.

• •

Verifiable: In our approach, the generated token (Eqn. 2) can verify to the nodeID $ID_{N}$ and further, It can be verified by any member node.

• •

Traceability: Our scheme traces any node with the help of six parameters of the token $T_{N}$, i.e.,

[TABLE]

As described earlier in the protocol specification section. In the verification phase, the ID ($ID_{N}$) can be checked with its real identity ($IP_{N}$) along with the collaborated nodeIDs and the validity concerning issuing time.

• •

Revocability: The proposed scheme achieves this requirement at a pilot with the help of received token $T_{N}$. Since the pilot keeps the information of its member MSs, the forge IDs are detected and the corresponding token would be revoked.

• •

Uniformity: In our proposed mechanism, the joining request of the new node would be forwarded to another vicinity head which is connected to WiFi in the case of more than ($2^{p}$) smart-phones within p-bit virtual space of a vicinity head.

• •

Scalability: Large mobile P2P overlay is virtually divided into vicinity range to make less computation and inexpensive communication (D2D/Bluetooth/WiFi) during ID generation in our proposed mechanism. So, the overlay structure supports huge new peers to join with respective vicinity without using Internet cost and much energy consumption.

5.2 Security Analysis

This sub-section analyses the security aspect of PJ-Sec from different attacks related to the nodeID assignment.

• •

Sybil Attack: In PJ-Sec, each ID is a function of its $IP_{N}$, $PU_{N}$ and $\gamma_{1}$, which is signed by the vicinity head and endorsed by the friend node in the token. Therefore, a malicious node fails to generate Sybil IDs without compromising a friend node and the Vicinity head.

• •

Eclipse Attack: Any node cannot generate own preferable IDs to place itself near to a target node due to the collaborative nodeID generation process and a random hash digest. Therefore, the attackers are not able to select any victim peer to launch an Eclipse attack.

• •

MITM Attack: It is not feasible for an attacker to successfully execute the node assignment phase of PJ-Sec due to the verification operation at each stage.

5.3 Formal security verification

Our proposed secure nodeID assignment protocol is verified/validated using a state-of-the-art tool (AVISPA [30]), which provides automatic security verification and analyzes the specified security goals to measure whether the mechanism is SAFE or not. To examine a protocol through AVISPA, it is to be codded in High-Level Protocol Specification Language (HLPSL) and integrated through back-end servers. These servers are responsible for providing automatic security verification and analysis for the HLPSL specification codes after getting the intermediate form (IF) of the code using $hlpsl2if$ translator.

The present version of AVISPA supports four back-end servers which can be integrated with HLPSL. The first back-end is “On-the-Fly Model-Checker" (OFMC), which explores the network state through the demand-driven way. Second, CL-AtSe back-end translates the transition relation of a protocol specification in the intermediate format (IF) into a set of constraints to find whether attacks have been imposed or not. SAT is the third back-end based on the model checker, which generates and feds propositional formulae into SAT solver. The found module in the SAT process would be translated back into an attack to analyze the specified security goals. TA4SP is the fourth back-end which stands for “Tree Automata based on Automatic Approximation for the Analysis of Security Protocols". It approximates the intruder’s knowledge using regular tree language.

In AVISPA, each participant assigns a role to play with some initial parameters and communicates with others through the channel (Dolev-Yao (dy) model  [31]) during the protocol execution. In this, the declaration channel (i.e., dy) may be secure or insecure. The intruders assume to play a legitimate role during the simulation run. After the successful execution, OUTPUT FORMAT (OF) is generated to describe the security analysis under the given conditions.

All roles specification of the players (i.e., new node $N$, friend/bootstrap node $B$, and pilot $V$) in the proposed protocol using HLPSL language are depicted in Figures 3 (a), (b), and (c) respectively. The operators $secret()$ is used to verify the secrecy of communication between players. In this verification, the intruders are provided with the knowledge of the players with their overlay Ids and common system parameters. Figure  4 defines the session, security goals, and the environment for our proposed protocol. The results are shown in Figures  5 (a) and (b) are obtained after execution of the security test at OFMC and CL-AtSe back-end respectively. Both the results confirm that our scheme satisfies authentication goals for participants.

6 Implementation and Result Analysis

We implemented the schemes using pairing-based cryptography (PBC) library in an Intel Core i5 2.30GHz processor laptop PC with 64 bits OS type Ubuntu 16.04 LTS system to calculate the computational cost, whereas MATLAB R2016a is used to determine the consumed network bandwidth during node generation process.

6.1 Computational Cost

Figure  7 compares the computational overhead of our proposed PJ-Sec and the existing secure node ID assignment through key-based mechanisms. Our scheme took 0.0357735 seconds while RIAPPA [10] and IAP  [11] (existing protocols) took 0.124545 seconds and 0.041516 seconds respectively.

We compared the proposed scheme also with the existing schemes on the basis of intensive operations involved and summarized in Table  1. The comparison shows (Figure 7) that our scheme has significantly less operations than others.

6.2 Bandwidth Consumption

To know the bandwidth consumption during secure ID assignment, we use the performance estimation of network Traffic model  [3] to compare our proposed protocol with the existing mechanisms. In this, the available bandwidth ($R_{0}$) is set randomly in the range [0.75$R_{0}$, 1.25$R_{0}$]. MSs and pilots are set at the maximum bandwidth 0.1$R_{0}$ ($C_{p}$), while it is 1.0$R_{0}$ ($C_{w}$) for the eNodeB and backbone network. We set $R_{0}$ = 100 kbps to approximate it to a realistic speed during a file upload. During secure node joining process, the protocols use Shannon capacity formula (S(bits/s/Hz)) as in [32]. It captures the time-varying capacity of the wireless channel.

[TABLE]

where $BW_{eff}$ is the efficiency of LTE to approximate for the system bandwidth ($R_{0}$). $SNR_{eff}$ approximates for the SNR implementation of the efficiency of LTE. The factor $\eta$ is a correction factor which is considered as one. In our simulation, we used the values $\eta$ = 0.9 and $SNR_{eff}$ = 1.23 which is the best fit to the link adaptation curve [32]. It is also considered in the network that channel fitting takes an upper limit of $S$ according to the hard spectral efficiency given by modulation and coding set. For the single stream case, coding set is considered as 4/5, e.g., 64QAM.

For sending joining request in centralized solutions such as RIAPPA [10] protocol, new nodes have to communicate internal TTP and then, the TTP communicates with external TTP for generating the ID. So, total communication ($TC_{RIAPPA}$) for generating a new key within RIAPPA would be $3*C_{w}$. On the other hand, IAP [11] has to communicate with single TTP to assign a new ID which takes $2*C_{w}$ communications. For distributed solutions as in Dinger et al.  [13], a new node ID assignment mechanism performs the trust among $(r/2)$ number of nodes and they can be transferred the request through eNodeB or WiFi. So, total communication ($TC_{DistributedSol}$) for assigning a secure ID for a new member within this distributed solution would be $1.5(r*C_{p})$. In our proposed mechanism, new ID generates securely with the collaborative effort of vicinity head and an existing node within its vicinity. Therefore, total communication ($TC_{PJ-Sec}$) for generating a secure nodeID would be $4*C_{p}$. In the simulation, We analyze the capacity required to serve these requests to assign new IDs up to 500 new nodes. The result shows that the total network trafficking is significantly lower in our proposed security scheme (PJ-Sec) than other security protocols as depicted in Figure 7.

Further, we analyze the bandwidth consumption effect in the presence of adversaries with or without mitigation through our proposed solution (PJ-Sec). Figure  8 compares the bandwidth consumption to generate Sybil (or forge) Ids within a fixed 3-bit domain and the reduced consumption using our security mechanism PJ-Sec. It happens due to each unsuccessful verification (in PJ-Sec), at mediator (or friend) nodes, stops new Id generation process. Figure 9 shows the effect of an expansion of the forge Id domain space from 1 to 10-bit. The proposed protocol requires significantly lesser bandwidth as the forge Id domain space is expended.

7 Conclusion

In this work, we propose a secure node joining protocol, called PJ-Sec tailoring to DHT-based mobile P2P. The proposed PJ-Sec protocol can be utilized to tune other existing P2P mechanisms as well. To defend against Sybil attack, PJ-Sec provides nodeID as a collaborative effort of existing overlay peer (friend node) and vicinity head. PJ-Sec is formally proved using the well-known AVISPA verification tool and shown to be secure. The performance of the scheme in regards to computation and bandwidth cost is analyzed and observed to be highly efficient when compared with the existing schemes. Implementing the whole technique on a smart-phone is a part of our ongoing work.

Acknowledgement

This work is funded by the E-security Division, Ministry of Electronics and Information Technology, Government of India, through the project grant number 12(7)/2015-ESD.