International Journal of Engineering Trends and Technology (IJETT) – Volume 22 Number 1- April 2015
A Simple Model of Rekeying Anatomy using Map
Theory
P. Srinivasa Rao1, P.Rajasekhar2
1,2
Final M.Tech Student1, Assistant Professor2
Dept of CSE, Avanthi Institute of Engineering & Technology-Narsipatnam,A.P
Abstract:- Group key management is hard task to maintain
security and performance time in networks. Many
researches done on this concept on group key management.
We propose a novel multiple key management using the
map theory. In this we implemented a recursive method to
generate group key and also implemented the revocation of
the key when the users are addicted or evicted.
I.INTRODUCTION
Key management is the management of
cryptographic keys in a cryptosystem. This incorporates
managing the era, trade, stockpiling, utilization, and
substitution of keys. It incorporates cryptographic
convention outline, key servers, client techniques, and
other important conventions.
Key management concerns keys at the client level,
either between clients or frameworks. This is rather than
key planning; key booking regularly alludes to the inner
treatment of key material inside the operation[1][2].
Effective key management is discriminating to the
security of a cryptosystem. Practically speaking it is
ostensibly the most troublesome part of cryptography on
the grounds that it includes framework approach, client
preparing, authoritative and departmental cooperation’s,
and coordination between these components.
Cryptographic systems may use different types of
keys, with some systems using more than one. These may
include symmetric keys or asymmetric keys. In a
symmetric key algorithm the keys involved are identical
for both encrypting and decrypting a message. Keys must
be chosen carefully, and distributed and stored securely.
Asymmetric keys, in contrast, are two distinct keys that are
mathematically linked. They are typically used in
conjunction to communicate[3].
Before any secured correspondence, clients must
set up the subtle elements of the cryptography. In a few
occasions this may oblige trading indistinguishable keys
(on account of a symmetric key framework). In others it
may oblige having the other party's open key. While open
keys can be straightforwardly traded (their comparing
private key is kept mystery), symmetric keys must be
traded over a protected correspondence channel. Some time
ago, trade of such a key was greatly troublesome, and was
enormously facilitated by access to secure channels, for
example, a discretionary pack. Clear content trade of
ISSN: 2231-5381
symmetric keys would empower any interceptor to
instantly take in the key, and any encoded information.
Another system for key trade includes typifying
one key inside another. Commonly an expert key is
produced and traded utilizing some protected strategy. This
system is typically lumbering or lavish (breaking an expert
key into various parts and sending each with a trusted
messenger for instance) and not suitable for utilization on a
bigger scale. When the expert key has been safely traded, it
can then be utilized to safely trade ensuing keys without
any difficulty. This strategy is normally termed Key Wrap.
A typical strategy uses Block figures and cryptographic
hash functions.[4][5]
A related system is to trade an expert key (once in
a while termed a root key) and infer auxiliary keys as
required from that key and some other information
(frequently alluded to as expansion information). The most
widely recognized utilization for this strategy is likely in
Smart Card based cryptosystems, for example, those found
in keeping money cards. The bank or credit system installs
their mystery key into the card's protected key stockpiling
amid card creation at a secured generation office. At that
point at the Point of offer the card and card per user are
both ready to determine a typical arrangement of session
keys taking into account the imparted mystery key and
card-particular information, (for example, the card serial
number). This technique can likewise be utilized when
keys must be identified with one another( (i.e.,
departmental keys are attached to divisional keys, and
individual keys fixing to departmental keys). Be that as it
may, binds keys to one another thusly builds the harm
which may come about because of a security rupture as
aggressors will learn something about more than one key.
This diminishes entropy, with respect to an assailant, for
every key included.
The significant issue is length of key utilization,
and accordingly recurrence of substitution. Since it
expands any assailant's obliged exertion, keys ought to be
much of the time changed. This likewise confines loss of
data, as the quantity of put away encoded messages which
will get to be meaningful when a key is found will diminish
as the recurrence of key change increments. Truly,
symmetric keys have been utilized for long stretches as a
part of circumstances in which key trade was extremely
troublesome or just conceivable discontinuously.
Preferably, the symmetric key ought to change with every
message or cooperation, so that just that message will get
http://www.ijettjournal.org
Page 17
International Journal of Engineering Trends and Technology (IJETT) – Volume 22 Number 1- April 2015
to be clear if the key is found out (e.g., stolen,
cryptanalyzed, or social designed)[6].
II.RELATED WORK
In multicast bunch correspondences, a legitimate
MKD protocol [7][8] is needed for producing and
dispersing a mystery grouping key that can be utilized to
secure (scramble) information sent from one source to all
objectives that are part of the same grouping. Since
multicast groupings are frequently extremely rapid,
because of the join of new parts and the leave of old parts,
the MKD needs to handle such grouping participation
changes by re-creating and re-circulating new grouping
keys.
Group Key Management means dealing with the
keys in a gathering correspondence. The vast majority of
the
gathering
correspondences
use
multicast
correspondence so that if the message is sent once by the
sender, it will be gotten by all the clients. The fundamental
issue in multicast bunch correspondence is its security.
With a specific end goal to enhance the security, different
keys are given to the clients. Utilizing the keys, the clients
can scramble their messages and send them furtively.
There are two types of key management systems


Integrated Key Management System
Third-Party Key Management System
A key administration arrangement (KMS) is a coordinated
methodology for producing, appropriating and overseeing
cryptographic keys for gadgets and applications.
Contrasted with the term key administration, a KMS is
custom-made to particular utilization cases, for example,
secure programming overhaul or machine-to-machine
correspondence. In a comprehensive methodology, it
covers all parts of security - from the safe era of keys over
the protected trade of keys up to secure key taking care of
and stockpiling on the customer. In this way, a KMS
incorporates the backend usefulness for key era,
appropriation, and substitution and additionally the
customer usefulness for infusing keys, putting away and
overseeing keys on gadgets. With the Internet of Things,
KMS turn into a pivotal part for the security of joined
gadgets [9].
Key exchange (also known as "key establishment") is
any method in cryptography by which cryptographic keys
are exchanged between users, allowing use of a
cryptographic algorithm.
If sender and receiver wish to exchange encrypted
messages, each must be equipped to encrypt messages to
be sent and decrypt messages received. The nature of the
equipping they require depends on the encryption
technique they might use[10][11]. If they use a code, both
will require a copy of the same codebook. If they use a
cipher, they will need appropriate keys. If the cipher is a
symmetric key cipher, both will need a copy of the same
key. If an asymmetric key cipher with the public/private
key property, both will need the other's public key.
The key exchange issue is the manner by which to
exchange whatever keys or other data are required so that
ISSN: 2231-5381
nobody else can get a duplicate. Generally, this obliged
trusted messengers, political sacks, or some other secure
channel. With the approach of open key/ private key figure
calculations, the scrambling key (otherwise known as open
key) could be made open, following (in any event for
brilliant calculations) nobody without the unscrambling
key (otherwise known as, the private key) could
unscramble the message.
III. PROPOSED WORK
In our proposed work contains a system for
gathering key management and productive correspondence
cost in correspondence. It contains a calculation for
creating keys for part removal and expansion from a
gathering. This methodology is purported as rekeying.
From secure key era we embrace chebyshev map cycle
idea. It is utilized for creating positive keys for clients.
There is an impediment in past methodology, for example,
the premise of the above calculation is semi-bunch
property, which is constantly valid for Chebyshev
delineate. On the other hand, we must perceive that, on one
hand, Chebyshev guide is characterized over genuine
numbers and delicate to introductory conditions. Then
again, machine can just do estimated other than exact
reckoning. Subsequently, machine can't do "genuine"
riotous calculation since it is a sound judgment that a × b ×
c ̸= b × c × an if a; b; c are genuine numbers
Multicast key management, which is much not the
same as unicast key management, is a standout amongst the
most appealing region of cryptography. For unicast
application the Diffie-Hellman key exchange convention
can be utilized to make a KEK (Key Encryption Key)
between two elements. At that point utilize this KEK to
dispatch or overhaul a session key. Interestingly, the
circumstances is significantly more convoluted for a
multicast application. A multicast application should
powerfully handle multi-elements. Case in point, in an
element multicast bunch, the participation is alterable all
the time because of oftentimes clients' expansion and
expulsion. So the key materials will most likely be
uncovered if no security approaches are embraced.
In the previous two decades, analysts have
proposed numerous multicast key management plans .
These plans can be sorted into three separate sorts:
concentrated, decentralized and circulated. A concentrated
gathering key management plan includes a Key Server
(KS) to produce and appropriate imparted key to all
gathering parts by means of a correspondence channel. The
decentralized key management separates the entire
gathering into littler subgroups. Every subgroup is
controlled by a solitary or a few KS. A Distributed plan
permits every part to participate in a gathering key era
collectively. Each of the three plans has its own particular
points of interest and detriments. The incorporated plan is
the least complex one yet has the danger of single-pointdisappointment. Decentralized plan includes some
correspondence many-sided quality between two parts
inside distinctive subgroups. Conveyed plan is some way
or another more unpredictable than the other two, however
it doesn't include KS. This peculiarity is extremely helpful
on account of nobody can assume the part of KS, e.g. a
sensor Ad-hoc system application.
http://www.ijettjournal.org
Page 18
International Journal of Engineering Trends and Technology (IJETT) – Volume 22 Number 1- April 2015
The objective of the multicast key exchange
calculation can be communicated as takes after: By trading
messages over untrusted system, multi-elements have the
capacity figure the mystery offer key freely. Amid the
whole process, nobody is in charge of the key era or
dissemination.
F1(x) = x mod N
Fn(x) = 2xFn-1(x) –Fn-2(x) mod N
Our proposed System as shown below
n is number of members in the group
Where x is users secret key
N is any integer which less 256 and greater than 0
F0(x) = 1 mod N
The Algorithm is as follows:
(2) The second member calculates Fn2 (Fn1 (· · · Frni+3(x)))
There are some notations such as ‘n’ is number of members
in the group. ‘x’ is public key for user. ‘N’ is large prime
number.
and sends it to the next.
(3) Repeat this until the last member calculates Fn(Fn-1 (· · ·
Fn-i+1(x))) and sends it to the first member.
(1) The first member calculates F1 (x) and sends it to the
2. Send master key
Network
1. Register
2. Send master key
1.Register
Send Initial key
Start key generation
process
Rotates up to no
of users cycles
User 1
Send second key
User 3
Send third key
…….n
Send nth key
second member.
By n − 1 stages message exchange by any member and the
(2) The second member calculates F2 (x) and sends it to
the third one.
ith member calculates the group session key by:
Fi (Fi-1 (· · · F1(Fn(Fn-1(· · · Fi+1(x)))))) which is equal to
(3) Repeat this until the last member calculates Frn(x) and
sends it to the first member.
(1) The first member calculates Fn1 (Frn(x)) and sends it to
the second member.
(2) The second member calculates F2 (F1 (x)) and sends it
to the next.
(3) Repeat this until the last member calculates Frn(Frn-1 (x))
and sends it to the first member.
Stage i.
(1) The first member calculates F1 (Frn(· · · Frn-i+2(x))) and
sends it to the second member.
ISSN: 2231-5381
F12….rn(x)
We call calculation a multicast key exchange calculation,
yet users may watch that this calculation appears to unicast
correspondence. Every hub conveys shared at each one
stage. In other way we ought to recognize that this
calculation initially is intended for building a multicast
session key between gathering parts. After n stages
running, all parts have the capacity arrange a session key,
which will be utilized as a part of multicast
correspondence. This is the reason it is named multicast
key exchange calculation.
In this we proposed a multicast key exchange
protocol, here we illustrate an example. Consider we have
three nodes w, y and Z acts as key server.
Initially all nodes calculate their individual keys using
chebyshev map as shown below.
At z node x=2, n=3, N=7
http://www.ijettjournal.org
Page 19
International Journal of Engineering Trends and Technology (IJETT) – Volume 22 Number 1- April 2015
Node z
Node w
1500
Processing time
F3(2)=2*2 F3-1(2) - T3-2(2) mod N
=26
At w node x=3, n=3, N=4
F3(3)=2*3 F3-1(3) - F3-2(3) mod N
=99
At y node x=4, n=3, N=4
F3(4)=2*4 F3-1(4) - F3-2(4) mod N
=120
After calculating of individual keys all nodes exchange
keys in secure channel.
LKH
1000
OFT
OKD
500
CKCSS
0
Proposed
Simultaneous users
Node y
In our protocol maximum all computations very low.
zkey
zkey
wkey
IV. CONCLUSION
In our work we proposed a recursive group key
generation method for multicast key exchange algorithm. It
mainly implemented for reducing the man in the middle
attack and impersonation attack. Using this methodology
we maximum prevent these attacks and increases the
performance of the system. We tested on multiple users in
the network and also the performance.
wkey
Ykey
Ykey
After sending individual keys, node z contains z*w*y key,
node w contains w*y*z key and node y contains y*z*w. It
satisfies the main feature association rule.
Experimental analysis:
We experimentally implemented the proposed
technique in dotnet technology under c# language .Our
experimental results shows more accurate and efficient
results than the traditional approach.We presented a
comparison that shows the complexity of the group
generation and the processing time of the process. Table1.
The comparisons of key generation in simultaneous join or
leave operations are shown below.
Protocols
Join
Leave
LKH
OFT
OKD
CKCS
Proposed
m log2 n
m log2 n
m log2 n
m+1
O(2n(n − 1))
m log2 n
m log2 n
m log2 n
1
O(2n(n − 1))
ISSN: 2231-5381
REFERENCES
[1] Sanjoy Paul. Multicasting on the Internet and Its
Applications. Kluwer Academic Publishers, Norwell, MA,
USA, 1998.
[2] M. Park, Y. Park, H. Jeong, and S. Seo. Secure multiple
multicast services in wireless networks. Mobile
Computing, IEEE Transactions on, PP(99):1, 2012.
[3] H. Harney and C. Muckenhirn. Group key management
protocol (gkmp) protocol specification, 1997.
[4] H. Harney and C. Muckenhirn. Group key management
protocol (gkmp) architecture, 1997.
[5] Jack Snoeyink, Subhash Suri, and George Varghese. A
lower bound for multicast key distribution. Comput. Netw.,
47(3):429– 441, February 2005.
[6] Min-Ho Park, Young-Hoon Park, and Seung-Woo Seo.
A cellbased decentralized key management scheme for
secure multicast in mobile cellular networks. In Vehicular
Technology Conference (VTC 2010-Spring), 2010 IEEE
71st, pages 1 –6, may 2010.
[7] Jen-Chiun Lin, Feipei Lai, and Hung-Chang Lee.
Efficient group key management protocol with one-way
key derivation. In
Proceedings of the The IEEE Conference on Local
Computer Networks 30th Anniversary, LCN ’05, pages
336–343, Washington, DC, USA, 2005. IEEE Computer
Society.
[8] Wen Tao Zhu. Optimizing the tree structure in secure
multicast key management. Communications Letters,
IEEE, 9(5):477 – 479, may 2005.
[9] Jun Sik Lee, Ju Hyung Son, Young Hoon Park, and
Seung Woo Seo. Optimal level-homogeneous tree structure
for logical key hierarchy. In Communication Systems
Software and Middleware and Workshops, 2008.
http://www.ijettjournal.org
Page 20
International Journal of Engineering Trends and Technology (IJETT) – Volume 22 Number 1- April 2015
COMSWARE 2008. 3rd International Conference on,
pages 677 –681, jan. 2008.
[10] Chung Kei Wong, Mohamed Gouda, and Simon S.
Lam. Secure group communications using key graphs.
IEEE/ACM Trans. Netw., 8(1):16–30, February 2000.
[11] Sandro Rafaeli and David Hutchison. A survey of key
management for secure group communication. ACM
Csomput. Surv.,
BIOGRAPHIES
P. Srinivasa Rao M.S (I.T),University of
Madras, Currently pursuing M.Tech in
Dept.
of
computer
science
and
Engineering,
Avanthi
Institute
of
Engineering & Technology-Narsipatnam
and his research interests are Mobile
communication and MIS and Network
security. Working as a Financial Planner at Edelweiss
Financial services ltd., Visakhapatnam.
P.Rajasekhar working as Assistant
Professor in avanthi institute Of
Engineering.&tech,
makavarapallem,
narsipatnam. His areas of interest are data
mining, network security and cloud
computing.
ISSN: 2231-5381
http://www.ijettjournal.org
Page 21