Distributed collaborative

7/29/2019 Distributed collaborative

1/28

DISTRIBUTED COLLABORATIVE KEY

AGREEMENT PROTOCOLS FOR DYNAMIC

PEER GROUPS

Project Guide:M.N.SUDHA, M.E.,

Project members:

R.PRASANTH

M.BALAJI


2/28

REQUIREMENTS OF GROUP KEY

AGREEMENT

Distributed: there is no centralized key server, which

has the following limitations:

A single point of failure; and

Not suitable for peer groups and ad hoc networks.

Collaborative: all group members contribute their own

part to generate a group key.

Dynamic: the protocol remains efficient even when the

occurrences of join/leave events are very frequent.


3/28

ABSTRACT

We consider several collaborative key agreement and

authentication protocols for dynamic peer groups.

Distributed nature in which there is no centralized key

server

Collaborative nature in which the group key is

contributory dynamic nature in which existing members

may leave the group while new members may join.


4/28

Continue

Instead of performing individual rekeying operationsi.e recomputing the group key after join or leaverequest.

we discuss an interval-based approach of rekeyingalgorithm named Queue-batch algorithm.

We further enhance the algorithm in twoaspect:authentication & implementation.

Authentication focuses on the security improvementwhile implementation realizes the interval-based alg inreal network settings.


5/28

PURPOSE OF PROJECT

The purpose of the proposed system is to provide themembers of a group with secure common group key .

The dynamic nature of the system allows the existing

members to leave the group while new members canjoin, instead of performing individual rekeyingoperations.

The system uses Queue-batch algorithm for re-keying.The algorithm can substantially reduce the computationand communication workload in a highly dynamicenvironment


6/28

EXISTING SYSTEM

The existing system involves either centralized keyserver and individual rekeying is done for join or leaveoperations in case of distributive key generationalgorithms .

In case of individual re-keying, after every join or leaveoperation each member individually rekeys.

More resources are used for re-keying because it is donefor each join or leave operations.

In case of using a centralized server, the risk of singlepoint failure is more.


7/28

PROPOSED SYSTEM Rekeying is done after a batch of join or leave

operations. The protocol remains efficient even when

the occurrences of join/leave events are very frequent.

Here Key information does not depend on centralized

key server. So it is free from the problem of single

point failure.

Computational and Communication cost is less.Resources used for rekeying is minimized because it is

being done for batch of join/leave operations.


8/28

Tree-Based Group Diffie-Hellman Protocol

(TGDH)

A key tree is formed. Each node v represents a secret(private) key Kv and a blinded (public) key BKv.

BKv = Kv mod p, where and p are public parameters.

Every member holds the secret keys along the key path,and all the blinded keys in the key tree.

K0 is the group key.

0

M1 M2

2

4 6

7

1

53

8 11 12

M3

M4 M5

M6


9/28

QUEUE-BATCH ALGORITHM

Two stages: Queue-subtree and Queue-merge.

Queue-subtree: Within the idle rekey interval, form a

subtree T with all joining members, just like individual

rekeying for a single join event.

Queue-merge: At the beginning of the next rekey

interval, prune all departed leaf nodes if any and add the

subtree T to the highest leave position (or attach T tothe shallowest position).

Elect the sponsors who can help broadcast the new

blinded keys.


10/28

DATA FLOW DIAGRAM


11/28

MODULES

GROUP KEY GENERATION WITHIN

THE WORKGROUP .

REKEYING OF GROUP KEY.

SHARING THE RESOURCES WITHIN

THE GROUP


12/28

GROUP KEY GENERATION WITHIN

THE WORKGROUP

In this module we implement the Diffie-Hellman treebased protocol to generate the group key. The private

key of the leaf nodes are decided by the particular group

member.

The member makes a request for the public key of other

child node. And once it gets it, with the knowledge of

the public key of one child node and the private key of

the other we can get the private key of its parent nodeusing the diffie hellman algorithm.

In future, all the message sent by a member to all others

in the peer group is encrypted using this group key.


13/28

REKEYING OF GROUP KEY

Queue-batch algorithm performs the best among theinterval-based algorithms. The algorithm reduces the

latency and the workload created due to re-keying

operation that is performed at the beginning of the re-

keying intervals.

In Queue batch algorithm, as and when members join,

they are stored as in a temporary tree and at the

beginning of a re-keying interval this tree is attached tothe tree with existing members.

It is attached to the highest departed position, so that the

height of the tree does not increase much.


14/28

SHARING THE RESOURCES WITHIN

THE GROUP

The new group key is been generated after the batch of

join and leave using the Queue Batch algorithm in the

second module.

From now onwards this new group key is used forencryption for all data sharing among the members of

the peer group.

In this module we would be able to show all thecommunication and data sharing among all the members

present in our work group.


15/28

SCREEN SHOTS

Continue


16/28

LOGIN WINDOW


17/28

SIGN UP


18/28

GROUP KEY DISPLAY


19/28

SIGN IN WINDOW


20/28

SQL SERVER WINDOW


21/28

SEND REQUEST


22/28

VIEW REQUEST


23/28

VIEW GROUP WINDOW


24/28

SEND FILES WINDOW


25/28

VIEW FILES WINDOW


26/28

AFTER DELETION


27/28

CONCLUSION

The key agreement setting is performed in which thereis no centralized key server to maintain or distribute thegroup key.

We show that one can use the TGDH protocol toachieve such distributive and collaborative keyagreement.

To reduce the rekeying complexity, we propose to usean interval-based approach to carry out rekeying formultiple join and leave requests at the same time.


28/28

THANK YOU

Documents

Distributed collaborative