Detailed Design for Security in P2P

Views:
 
Category: Entertainment
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

Detailed Design : 

Detailed Design 1.Module Description 2.Complexity 3.Evaluation Parameters 4.Test Cases

Module Description : 

1.Input 2.Ouput 3.Algorithm 4.Steps Module Description

1.Decentralized Design for Nodes : 

The key of nodes, already generated are put up in the witness table and registry table. The tables are then propagated to all the nodes which are in the intersection set of the random routes.(this decreases the cost of sending the table to each node) 1.Decentralized Design for Nodes

2.Security for P2P Nodes : 

Edge Key:-Every pair of node share a unique key(symmetric key) Algorithm used is RSA In this module the public and private key pair unique to each node is generated. 2.Security for P2P Nodes

3.Verification Process : 

The sender node is verified in this using the public keys stored in the registry table and the witness table. The sender encrypts its message using ECC algorithm and the edge key The receiver decrypts the message using the same edge key and ECC algorithm 3.Verification Process

4.Dealing with Offline Nodes : 

If the intermediate node is offline, the sender node needs to find alternate route to the destination . If the destination is offline the message gets dropped. 4.Dealing with Offline Nodes

Test Cases. : 

1.send the message 2.receive the message 3.verify the sender 4.updating the registry and witness table 5.identifying the attacker node Test Cases.

1.Send the message : 

INPUT:-Text file, image file,multi media file EXPECTED OUTPUT:-The file sent successfully CONDITION:-The size of the input file 1.Send the message

2.Receive the message : 

INPUT:-The sender node identification EXPECTED OUTPUT:-The requisite file is downloaded CONDITION:-It should not be an executable file and should not be malicious. 2.Receive the message

3.Verify the sender : 

INPUT:-the name of the sender EXPECTED OUTPUT:-the status of the sender CONDITION:-the node should be an already existing node which has not be identified as Sybil node. 3.Verify the sender

4.Updating the registry and witness table. : 

INPUT:-Information about message received. OUTPUT:-the offline and attacker nodes are isolated by deleting their entries in the tables. CONDITION:-should be performed at every message sent and received and whenever a new route is identified. 4.Updating the registry and witness table.

5.Identifying the attacker node. : 

INPUT:-the indication of message to be received from an unidentified node OUTPUT:- the status of the node CONDITION:- the intersection of random routes need to be done to get the list of attacker nodes. There should not be many edges between the attacker node and the sender node. 5.Identifying the attacker node.

Evaluation Parameters : 

Sybil node identification rate:-Irrespective of the number of Sybil nodes relationship with the healthy node, they should be able to be identified Sybil node. Error rate:-Number of infected or malicious files received. Verification Overhead:- The verification process should not become too much time consuming. It should limit the number of nodes which will be included in the verification process. Evaluation Parameters

COMPLEXCITY : 

Checking of the public key pair while verification and not just one public key Finding out all the random routes possible from the node. Picking out only the nodes which are present in the intersection of two or more random routes. Transferring the registry and witness table only to these nodes. COMPLEXCITY

TOOLS USED : 

JDK 1.6 Javafx (scripting language) TOOLS USED

authorStream Live Help