International Journal of Engineering Trends and Technology (IJETT) – Volume17 Number6–Nov2014
A Prototype of Rekeying Method Using RecursiveMap Theory
1
S.Sairam ,2M.satyanarayana
Final M.Tech Student,1 Assistant Professor
1,2
Dept of CSE, Swaranandhra college of Engg&tech, Seetharampurm,Jntu-k
2
Abstract:- Group key management is main part to ensure
access control over the network for a group of users. The
main issue is computation and communication complexity
of this process. For this we introduced a group key
management using map theory. We adopted Chebyshev
map recursion theory to solve this. For above problems we
stated which computation complexity means indefinite
values in group key generation and which is not satisfying
the association rules. To achieve this we extend the domain
of Chebyshev maps from real number setto finite field.
I.INTRODUCTION
Multicast over remote systems is a critical also
difficult objective, yet a few issues must be tended to
before numerous gathering applications can be sent on a
huge scale. Multicasting is a more effective strategy for
supporting bunch correspondence than unicasting or
television, as it permits transmission and directing of
parcels to numerous goals utilizing less system assets.
Alongside boundless arrangement of remote systems, the
quick enhancing capacities of cell phones, furthermore an
undeniably refined portable work power around the world,
content furthermore benefit suppliers are progressively
keen on supporting multicast interchanges over remote
systems.
Applications of remote multicast help gathering
focused portable trade, military order also control,
separation
instruction,
and
smart transportation
frameworks. A lot of people new m-commerce
applications, including portable barters, will likewise pick
up noteworthy profit if bunch correspondence among
versatile clients is upheld by remote systems. Such
applications require proceeded network, nuclear all-ornone exchanges, and secure and dependable remote
multicast.
In military situations, strategic data might be
multicast to clients, tanks, and planes; such applications
request insignificant defer and secure and solid remote
multicast. Separation instruction and excitement
administrations can be offered to portable or remote
clients; such applications oblige high data transmission and
close continuous remote multicast for quality review. Keen
transportation frameworks include the element directing or
rerouting of individual vehicles. Current movement data,
and in addition the most administer furthermore slightest
tedious courses, can be multicast to drivers; later on,
business airplane may fly on the most proficient courses
guided, to some extent, by multicasts of area data
ISSN: 2231-5381
concerning other close-by air ship, objects, and ends of the
line. The dependability furthermore rightness of area data
are real issues in remote multicast.
Multicast interchanges have been upheld for at
any rate the recent years in the Web environment for
settled clients utilizing wired connections. In such
situations, a host joins a multicast bunch by advising a
nearby multicast switch that in turn contacts other multicast
switches; a multicast tree is accordingly made through a
multicast directing convention [1]. The multicast switch
intermittently sends inquiries to figure out if any of the
hosts in its scope is still a part of the multicast bunch.
All host-multicast switch correspondence is
performed through the Internet Group Management
Convention (IGMP) [1]; Internet IP multicasting has been
actualized utilizing Mbone, a virtual overlay system [3].
Since not all IP switches help multicast steering, the
sending of multicast datagrams is taken care of by
"multicast switches" through "passages" Representation
Step by step instructions to guarantee the cooperation of
portable clients (regardless of how problematic the
circumstances), particularly for portable trade
Applications dispersed over various systems.
Multicast Over Remote Networks interfacing multicast
switches; burrows basically pass through yet are not
prepared by unicast switches (see Figure 1). Passages are
executed by epitomizing IP multicast parcels in an unicast
IP parcel to the following multicast- competent switch.
Existing multicast help for settled clients can be reached
out to versatile clients in remote situations. Nonetheless,
applying such backing to remote multicast is troublesome
for some reasons (see Table 1); for instance, the data
transmission accessible in the two headings of any given
remote connection may not be square with (the connections
may even be unidirectional), therefore influencing the
measure of control and flagging data that can travel either
way. The client's portability could accordingly prompt
wasteful multicast tree/network, loss of bundles, wrong
directing, even the tossing of multicast bundles. The
current multicast conventions are planned for an altered
topology, however impromptu remote systems may
encounter changes of topology because of the development
of middle hubs amid multicast sessions.
II.RELATED WORK
For some applications, solid what's more secure
multicast is an essential necessity. Giving end-to end
dependability obliges identification of bundle misfortune,
http://www.ijettjournal.org
Page 256
International Journal of Engineering Trends and Technology (IJETT) – Volume17 Number6–Nov2014
alongside blunder recuperation. Bundle misfortune can be
identified through one of two methodologies: Senderstarted. Beneficiaries return affirmations for accurately got
bundles; clocks can be utilized to identify bundle
misfortunes at the sender. Be that as it may, if each
beneficiary sends an affirmation for a bundle it gets, input
implosion can happen.
Beneficiary started. Negative affirmations (as in
the beneficiary started methodology) are utilized by
beneficiaries to educate the sender about bundle misfortune
by means of negative acknowledgments. Misfortune
recuperation can be performed through particular
retransmission to the beneficiaries that did not get parcels.
It is carried out either by setting up a gathering of
beneficiaries, separating the gathering into bunches with
assigned group sets out capable toward retransmission, or
by nearby retransmission, placing a neighboring
beneficiary that has effectively gotten the bundles.
Bunching is helpful principally when the
gathering example is thick; however no such presumptions
can be made for portable clients. Security issues in remote
multicast merge because of the utilization of remote
connections that are at danger of being listened in, the
natural show nature of a few remote connections needing
control on collectors, and the utilization of flooding for
tree/network development. Security dangers incorporate
complete loss of administration, data taking alternately
alteration, and adjustment of steering tree/cross section
permitting unapproved clients.
The security issues can be tended to in various
courses; for instance, parcels in remote multicast can be
scrambled utilizing symmetric (private-key) or deviated
(open key) plans. In any case the key conveyance and rekey courses of action, in light of client versatility and
participation changes, can make huge transforming and
organize overhead. In gathering key encryption, a groupkey
administration convention safely conveys a typical key to
all clients of a multicast bunch [4]. Bunch validation is
verifiably given by ownership of the key; sender validation
can be given by means of different means, including
computerized mark. Firewalls can give secure remote
multicast, however they include critical many-sided quality
and may make client cooperation what's more coordinated
effort more troublesome if clients are spread crosswise
over diverse systems.
The extent of multicast parcels can likewise be
restricted by switches and sources to give some level of
security for remote multicast; however the conveyance of
remote multicast bunch clients may change about whether,
along these lines obliging changes in extension. The
overhead of these progressions and the likelihood that a
versatile client quits getting multicast bundles for some
time of time ought to be assessed. An alternate route for
ISSN: 2231-5381
system originators to give some security to remote
multicastis to oblige that steering conventions uphold
participation control; for instance, in center based or
established tree multicast conventions, the focal point(s)
can be given an approval rundown to check marked
joinrequests from collectors. Permits attempting to give
clients data on administrations they will require within a
brief span of time Permits clients/organizations to get
suggestion of different items and administrations from
outsiders also different clients Permits attempting to
decrease the measure of stock required by overseeing inhouse and stock progressing.
Aides find items and administrations Continuous
multicast with dynamic interest by numerous clients
Unbalanced non-real time multicast including hundreds or
more gadgets Topsy-turvy constant multicast including
different clients Topsy-turvy non-real time multicast
including few substances Topsy-turvy non-real time
multicast including conceivably extensive quantities of
substances Unicast/multicast including few substances
Security and unwavering quality of remote multicast are
real necessities. Low postpone needed (few hundred ms to
a second). Expulsion from bunch because of discontinuous
integration or concise disconnectivity altogether influences
conceivable result.
Unwavering quality and Qos necessities are
definitely not critical. Long reaction time of a couple of
minutes is fair. Irregular network or short disconnectivity
may be endured, as different retransmissions/retries are
conceivable because of long reaction time. High transfer
speed and low defer needed (for example, a couple of
hundred ms to a second). An administration intrusion
because of discontinuous network or short disconnectivity
essentially influences clients' general experience.
Most multicast necessities are straightforward.
Security also Qos are not issues. Reaction time of minutes
is bearable. Discontinuous network alternately short
disconnectivity is passable because of long reaction time.
Most
multicast
necessities
are
straightforward.
Dependability and Qos are not significant issues. Reaction
time of minutes is bearable. For some clients, protection
may be an issue, contingent upon items and administrations
being suggested. Unwavering quality and Qos prerequisites
are definitely not critical. Reaction time of a couple of
seconds is average. Other multicast prerequisites
furthermore issues Term of multicast session can be long
and include different players in diverse systems. Few
messages can be sent without a multicast session.
Security is not a real issue, however for some;
security may be, as data on acquiring propensities may be
recorded. The multicast session may be altogether long (>1
hour). One or more messages can be sent without setting
up unequivocal multicast session. Clients ought to be
http://www.ijettjournal.org
Page 257
International Journal of Engineering Trends and Technology (IJETT) – Volume17 Number6–Nov2014
permitted to pick in (or withdraw). Validation of clients,
exactness of data, and conceivable clashes of investment
must be tended to. In the event that multicast not
accessible, an arrangement of unicast steps may finish the
exchange. Area precision may be an imperative variable.
M-trade applications and necessities.switches in the ways
among the trusted switches are disallowed from changing
directing data.
III. PROPOSED WORK
In our proposed work contains a method for group key
management and efficient communication cost in
communication. It contains an algorithm for generating
keys for member eviction and addition from a group. This
process is so called as rekeying. From secure key
generation we adopt chebyshevmap iteration concept. It is
used for generating definite keys for users. There is a
limitation in previous process such as the basis of the
above algorithm is semi-group property,which is always
true for Chebyshev map theoretically. However,we must
notice that, on one hand, Chebyshev map is defined over
real numbers and sensitive to initial conditions.On the
other hand, computer can only do approximate otherthan
precise computation. Therefore, computer cannot do“real”
chaotic computation since it is a common sense thata × b ×
c = b × c × a if a; b; c are real numbers.
Multicast key management, which is much
different from unicast key management, is one of the most
attractive areaof cryptography. For unicast application
theDiffie-Hellmankey exchange protocol can be employed
to establish a KEK(Key Encryption Key) between two
entities. Then use thisKEK to dispatch or update a session
key. In contrast, the situation is much more complicated for
a multicast application. A multicast application must
dynamically handle multi-entities. For example, in a
dynamic multicast group, the membership is changeable all
the time due to frequently users’ addition and eviction. So
the key materials will probably be revealed if no security
policies are adopted.
For instance, if the key is not updated after the membership
change, a newcomer is able to read the contents before his
coming, or a evictor is capable of reading the content after
ISSN: 2231-5381
his leaving. In this case, multicast key management scheme
should provide forward secrecy and backward secrecy for
security reasons in some special applications and example
Pay-Per-View.
In the past two decades, researchers have
proposed many multicast key management schemes .These
schemes can be categorized into three different types:
centralized, decentralized and distributed. A centralized
group key management scheme involves a Key Server
(KS) to generate and distribute shared key to all group
members via a communication channel. The decentralized
key management divides the whole group into smaller
subgroups. Each subgroup is controlled bya single or
several KS. A Distributed scheme allows each member to
take part in a group key generation collaboratively. Each of
the three schemes has its own advantages and
disadvantages. The centralized scheme is the simplest one
but has the risk of single-point-failure. Decentralized
scheme adds some communication complexity between
two members within different subgroups. Distributed
scheme is somehow more complex than the other two, but
it doesn’t involve KS. This feature is very useful in the
case of no one can play the role of KS, e.g. a sensor Adhoc network application.
The goal of the multicast key exchange algorithm
can be expressed as follows: By exchanging messages over
untrusted network, multi-entities are able to compute the
secret share key independently. During the entire process,
no one is responsible for the key generation or distribution.
Our chebyshev map is as follows:
T0(x) = 1 mod N
T1(x) = x mod N
Tn(x) = 2xTn-1(x) –Tn-2(x) mod N
where x ∈ {0; 1; 2; · · ·N − 1} and N is a prime. In some
literature, it is reported that N does not have to be a
prime,it can also be a product of two large primes.
However, from security reasons, N should be a large prime
and N + 1should have a large prime factor. Especially, if
we define the equation over GF(N), and force x to be the
primitive root modulo N
http://www.ijettjournal.org
Page 258
International Journal of Engineering Trends and Technology (IJETT) – Volume17 Number6–Nov2014
2. Send master key
Network
1. Register
2. Send master key
1. Regis
ter
Send Initial key
Start key generation
process
Rotates up to no
of users cycles
User 1
Send second key
User 3
Send third key
The Algorithm is as follows:
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.
(1) The first member computes T1 (x) and sends it to the
second member.
(2) The second member computes T2 (x) and sends it to the
third one.
(3) Repeat this until the last member computes Trn (x) and
sends it to the first member.
(1) The first member computes Tr1 (Trn(x)) and sends it to
the second member.
(2) The second member computes T2 (T1 (x)) and sends it
to the next.
(3) Repeat this until the last member computes Trn(Trn-1
(x))and sends it to the first member.
Stage i.
(1) The first member computes T1 (Trn (· · · Trn-i+2(x)))and
sends it to the second member.
(2) The second member computes Tr2 (Tr1 (· · · Trn-i+3(x)))
and sends it to the next.
(3) Repeat this until the last member computesTrn(Trn-1 (· · ·
Trn-i+1(x))) and sends it to the first member.
By n − 1 stages message exchange by any memberand the
ith member computes the group session key by:
Ti (Ti-1 (· · · T1(Tn(Tn-1(· · · Ti+1(x))))))which is equal to
T12….rn(x)
We call algorithm a “Multicast” key exchange algorithm,
but readers may observe that, this algorithm seems to
unicast communication. Each node communicates peer to
peer at each stage. However, we should notice that this
algorithm originally is designed for establishing a multicast
ISSN: 2231-5381
…….n
Send nth key
session key between group members. After n stages
running, all members are able to negotiate a session key,
which will be used in multicast communication. This is
why it is named “multicast” key exchange algorithm.
IV. EXPERIPENTAL ANALYSIS
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.
T0(x)=1;
T1(x)=x mon N;
Tn(x)=2.x Tn-1(x)- Tn-2(x) mod N
Initially all nodes calculate their individual keys using
chebyshev map as shown below.
At z node x=2, n=3, N=7
T3(2)=2*2 T3-1(2) - T3-2(2) mod N
=26
At w node x=3, n=3, N=4
T3(3)=2*3 T3-1(3) - T3-2(3) mod N
=99
At y node x=4, n=3, N=4
T3(4)=2*4 T3-1(4) - T3-2(4) mod N
=120
After calculating of individual keys all nodes exchange
keys in secure channel.
http://www.ijettjournal.org
Page 259
Node z
Node w
Node y
zkey
zkey
wkey
wkey
Processing time
International Journal of Engineering Trends and Technology (IJETT) – Volume17 Number6–Nov2014
1200
1000
800
600
400
200
0
LKH
OFT
OKD
CKCSS
Ykey
Proposed
Simultaneous users
Ykey
In our protocol maximum all computations very low.
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.
The computational overhead for these Protocols
depend on the number of keys that need to be generated
and encrypted by the server. In below table contains the
key generation overhead at simultaneous join or leave
operation. In LKH the group members do not participate in
middle node keys calculation in each join or leave
operation. In OFT only the new member at join and the
remaining members at leave need to update the keys in
their paths.
In OKD, when a member joins the group all the
necessary keys should be delivered to him/her by unicast
and all the remaining members can update their middle
node keys by themselves, but at leave some nodes are
responsible for updating the affected keys. Therefore in
these protocols the key generation overhead islog2nfor a
single member andmlognwhen m members join/leave the
group simultaneously. The CKCS has the smallest
overhead for key generation comparing with the others.
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
IV. CONCLUSION
In this paper we have concentrated on the field of
multicast key exchange, which is a attractive sub-field of
cryptography. We deeply analyze the multicast key
management schemes proposed in and consequently figure
out the fatal limitations. That is, due to the authors’
inappropriate assumptions, the three algorithms are not
practical at all. However, enlightened by those literatures,
we propose another algorithm based on the extended
Chebyshev polynomial to achieve multicast key exchange.
Correctness and security analysis indicate that this new
algorithm is reasonable and practical.
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 Transaction, 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, SubhashSuri, and George Varghese.A
lowerbound for multicast key distribution.Comput.Netw.,
47(3):429–441, February 2005.
[6] Min-Ho Park, Young-Hoon Park, and Seung-Woo Seo.
A cellbaseddecentralized key management scheme for
secure multicastin 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 IEEE Conference on Local Computer
Networks30th 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, JuHyung Son, Young Hoon Park, and
Seung WooSeo. Optimal level-homogeneous tree structure
http://www.ijettjournal.org
Page 260
International Journal of Engineering Trends and Technology (IJETT) – Volume17 Number6–Nov2014
for logical keyhierarchy.In Communication Systems
Software
and
Middleware
and
Workshops,
2008.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] SandroRafaeli and David Hutchison.A survey of key
management
for
secure
group
communication.ACMComput.Surv.,
35(3):309–329, September 2003.
[12] Yan Sun, Wade Trappe, and K. J. R. Liu. A scalable
multicast key management scheme for heterogeneous
ISSN: 2231-5381
wireless networks.IEEE/ACM Trans. Netw., 12(4):653–
666, August 2004.
[13] V. Kondratieva and Seung-Woo Seo. Optimized hash
tree
for
authentication
in
sensor
networks.
Communications Letters, IEEE,11(2):149 –151, Feb. 2007.
[14] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor,
andB.Pinkas. Multicast security: a taxonomy and some
efficient constructions. In INFOCOM ’99.Eighteenth
Annual Joint Conference of the IEEE Computer and
Communications Societies.Proceedings.IEEE, volume 2,
pages 708 –716 vol.2, mar 1999.
http://www.ijettjournal.org
Page 261