Introduction to the E-class Room Scenario

This project will address the key management of a typical E-class scenario on mobile ad hoc network using NS-2.

E-class is a kind of application used for group communication, running on MANET. There is a Lecturer who sends the tutorial questions to a group of students (One to many communication/multicast).Students must submit their reply to Lecturer (One to one communication/unicast). I want to make this communication secure from other members in the MANET. So we will associate the concept of key management with this application.

There will be a group controller or server who will generate the keys and distribute it among interested members efficiently and securely in the group. Only the Members sharing group key will be able to participate in E-class in MANET.

Another important issue related to group communication is key maintenance as a member leaves or the new member joins the group. In this case, new group key should be generated and distributed to group members to maintain forward confidentiality and backward confidentiality.

Our basic aim is to provide secure group communication for E-class and managing the group key efficiently as member leaves or joins the group. We want to reduce the communication overhead by reducing the transmission of messages in the MANET.

Modeling

I assume there is a MANET consisting of several nodes. Lecturer (a new node) joins the MANET at a particular time. Shows it’s presence to all members in MANET.

Then the members who want to attend E-class will show their interest to lecturer.(may send group join type request).

I assume lecturer will be the group controller (GC)/server in our application.

GC will assign a private key to the new user and also assign group key (GK)to ahe user for accessing multicast content(tutorial questions).

After some time another node shows interest and it also gets the private key and GK for communication.

GC will wait for students for certain period of time say 10 min, after that it will not accept any more request from members(no member can join the group) and starts the class. The class may be run for certain period of time say 1 hour.

Now the GC prepares data packet (question), Student encrypts the data with group key and transmits to the group of stuThe student

will prepare the answer and send it to GC only. (GC will also have a unique key which GC will send to the user as the user joins the group.)

(Note:—-Several nodes may be in the MANET but an interested member having the group key will form the group and participate in class.

Key generation and encryption is not the issue we can randomly generate a number and can transform(encrypt) in a simple way.

The lecturer may wait for a certain time interval to receive answers from students then send next question.)

After some time a student leaves the group since it has moved out of MANET (because these are mobile nodes ) or it is not moved but not want to participate in E-class then GC must know this and need to update GK.

(Note: Leaving member may send leave_group req to GC or if the node has moved out of MANET then GC must detect it.)

In this case, old GK can’t be used to send new GK to group members because it’s known to leaving member also. So New GK will be sent to all users using their private keys. so if there were n users initially this key update message will be sent as( n-1) unicast message.

If the group is small then this key update cost is bearable if the group is large then it becomes significant to reduce such key update communication overhead using an efficient technique for key distribution and management.

Key distribution in MANET should localize the transmission of rekeying messages and rekeying communication should be minimal. Normally, if the key is changed, then the new key will be distributed through individual unicast messages to all the members of the group.

In this proposed scheme, the overhead will be reduced by sub-group broadcast or multicast messages and few unicast messages.

The whole network is considered as a collection of subgroups. If a member of a particular subgroup leaves the class, then the new key will be broadcasted individually to all the other subgroups. For all the other nodes of the subgroup in which the node leaves the class, the new key will be distributed using unicast. The node which is leaving will not get the new key. The net effect will be the reduction in message overhead.

Simulation Scenario

We assume that initially, a group of nodes (MANET) appears on the scene.
Step-1 At time say 10 a.m Faculty node (Group controller) joins the MANET to conduct a tutorial class for some time says, 1-hour class. It sends Hello messages to all members in the MANET.(Neighbors will get it directly. other will get through an intermediate node) .

Step-2 Interested member in the MANET will send join_reply to Faculty node (GC) directly if they are neighbors otherwise through intermediate nodes.

Step-3 Now the GC(Faculty Node) will generate group key(gk).
GC should distribute this group key securely to group members, so some mechanism must be applied. (it may be sent using individual keys of group members).

Step-4 After distribution of group key, GC will prepare a question Q1.Encrypts it E gk(Q1) and send it to the multicast group. All students in the group will receive and decrypt it Dgk(Q1).

Step-5 GC will wait for some time (say 5 min) to collect replies from students. Meanwhile, students prepare answer A1 and encrypt it with it’s individual key(ik) Eik(A1) and send to GC.

Step-6 After 5 minutes GC will again prepare a question Q2.Encrypts it E gk(Q2) and send it to the multicast group. All students in the group will receive and decrypt it Dgk(Q2). GC will wait for some time (say 5 min)to collect replies from students. Meanwhile, students prepare answer A2 and encrypt it with it’s individual key(ik) Eik(A2) and sends to GC.

Step-7 if students leave the group because it has moved out of ranges in that case group key need to be updated. In this case previous group key can not be used to distribute the new group key to students because leaving students knows that key. so new group key should be sent through individual keys of students.

But it involves communication overhead in terms of the number of re-keying message transmissions so we need to group all the students in subgroups or clusters, associating keys to clusters and reduce the transmission of key update messages.

Performance Evaluation:

Trace files could be generated to analyze messages being transmitted from GC to students and students to GC.

A number of key update messages or encryption sent by GC as the no of students joining and leaving in the class varies can be evaluated in terms of a graph.

With respect to E-class, we can show the attendance of students after simulation of the E-class.

About the Implementation: A TCL level application agent for ns2 will be developed to simulate the proposed key management system for a typical E-Class scenario. The simulations will be done using ns2.28 or any higher version of ns2 on Linux.

Implementation of the Protocol as an Application level Agent in ns2.

To implement the proposed protocol we need a new protocol agent in ns2. For that, we are developing a new Agent EclassAgent by inheriting a c level agent called MessagePassing.

The files /common/messpass.h and /common/messpass.c of ns2 Provides a basic Message Passing Mechanism. If we attach this agent in mobile nodes, then we can send data from one point to another. This is like a UDP communication scenario. So there will not be any acknowledgment.

The following function of messpass.c will be used to send a data packet. For handling this function from a TCL script, it provides a command interface.

void MessagePassingAgent::sendto(int nbytes, AppData *data, const char* flags, ns_addr_t dst)
{
 Packet *p;

 if (nbytes == -1) {
 printf("Error: packet size for MessagePassingAgent should not be -1\n");
 return;
 } 

 // check packet size (we don't fragment packets)
 if (nbytes > size_) {
 printf("Error: packet greater than maximum MessagePassingAgent packet size\n");
 return;
 }

 double local_time = Scheduler::instance().clock();
 p = allocpkt();
 hdr_ip* iph = hdr_ip::access(p);
 iph->daddr() = dst.addr_;
 iph->dport() = dst.port_;
 hdr_cmn::access(p)->size() = nbytes;
 hdr_rtp* rh = hdr_rtp::access(p);
 rh->flags() = 0;
 rh->seqno() = ++seqno_;
 hdr_cmn::access(p)->timestamp() = 
 (u_int32_t)(SAMPLERATE*local_time);
 p->setdata(data);
 target_->recv(p);
 idle();
}

The following is the command interface for using sendto function

int MessagePassingAgent::command(int argc, const char*const* argv)
{
 PacketData* data;
 ns_addr_t dst;

 ………………..
 ………………..
 ………………..

 } else if (argc == 6) {
 if (strcmp(argv[1], "sendto") == 0) {
 data = new PacketData(1 + strlen(argv[3]));
 strcpy((char*)data->data(), argv[3]);
 dst.addr_ = atoi(argv[4]);
 dst.port_ = atoi(argv[5]);
 if (dst.port_ == 0) dst.port_ = here_.port_;
 sendto(atoi(argv[2]), data, 0, dst);
 return TCL_OK; 
 ………………..
 ………………..
 ………………..
}
 

The following function of messpass.c will receive a data packet which is addressed to its port. For handling the Recieved data in a TCL script, it provides an interface which will pass the instant of data to the tcl script, and we can use the data in tcl script itself. The bold lines in the following code provide that mechanism.

void MessagePassingAgent::recv(Packet* pkt, Handler*)
{
 if (app_ ) {
 // If an application is attached, pass the data to the app
 hdr_cmn* h = hdr_cmn::access(pkt);
 app_->process_data(h->size(), pkt->userdata());
 } else if (pkt->userdata() && pkt->userdata()->type() == PACKET_DATA) {
 // otherwise if it's just PacketData, pass it to Tcl

 PacketData* data = (PacketData*)pkt->userdata();

 hdr_ip* iph = hdr_ip::access(pkt);
 Tcl& tcl = Tcl::instance();
 tcl.evalf("%s recv %d %d %d {%s}", name(),
 iph->saddr(), iph->sport(),
 hdr_cmn::access(pkt)->size(), data->data());
 } else {
 // It wasn't PacketData, or userdata() was NULL
 // so pass an empty string to Tcl


 hdr_ip* iph = hdr_ip::access(pkt);
 Tcl& tcl = Tcl::instance();
 tcl.evalf("%s recv %d %d %d {}", name(),
 iph->saddr(), iph->sport(),
 hdr_cmn::access(pkt)->size());
 
 }
 Packet::free(pkt);
}

Class Agent/EClassAgent -superclass Agent/MessagePassing

In the following lines, we are inheriting a class called EClassAgent from the super class Agent/MessagePassing After inheriting the class, we can extend its functionality. For example, the following code extends the functionality of the recv function of the c code. In this case, if an agent/node receiving data at that particular port, it will process the data according to the proposed protocol.

Agent/EClassAgent instproc recv {source sport size data} {
$self instvar node_ RegisteredStudentsNodeIDs LecturerGroupKey
global ns BROADCAST_ADDR BroadcastDelay
set rng [new RNG]
$rng seed 0

# extract message ID from message
set message_id [lindex [split $data ":"] 0]



switch $message_id {
"LBCN" { 
# The Student Node Recieves a Lecture Beacon Message
puts "\nNode [$node_ node-addr] Recieved Message Type with ID: $message_id\n"
$ns trace-annotate "Node [$node_ node-addr] Recieved Message Type with ID: $message_id"
}

"RFLR" { 
# The Lecturer Node Recieves a 'Register For Lecture' Message
# Update the Public Key List
lappend ThePublicKeysOfTheStudentNodes [lindex [split $data ":"] 1]

# Update the Registered Students Node ID List 
lappend $RegisteredStudentsNodeIDs $source
puts "\nNode [$node_ node-addr] Recieved Register For Lecture Message from $source"
$ns trace-annotate "Node [$node_ node-addr] Recieved Register For Lecture Message from $source"

$self RegisterTheStudentAndSendGroupKey $source
}

"URFL" { 
# The Lecturer Node Recieves a 'Unregister For Lecture' Message
# Remove the Student from the list and Update the Registered Students Node ID List
set idx [lindex [lsearch $RegisteredStudentsNodeIDs $source] 0]
set RegisteredStudentsNodeIDs [lreplace $RegisteredStudentsNodeIDs $idx $idx ]
# Remove the public key of the Student from the list and Update the Key List
set ThePublicKeysOfTheStudentNodes [lreplace $ThePublicKeysOfTheStudentNodes $idx $idx ]
}
"REGS" { 
# The Student Node Recieves the Group Key After Successful Registration
# The Student Node Stores the LecturerGroupKey

set LecturerGroupKey [lindex [split $data ":"] 1]
puts "\nNode [$node_ node-addr] Recieves Group Key For The Lecture from $source"
$ns trace-annotate "Node [$node_ node-addr] Recieves Group Key For The Lecture from $source"

}
"TUTL" { 
# The Student Node Recieves the Tutorial

set tutorialtext [lindex [split $data ":"] 1]
puts "\nNode [$node_ node-addr] Recieves Tutorial from $source"
$ns trace-annotate "Node [$node_ node-addr] Recieves Tutorial $tutorialtext from $source"
} 
"QUES" { 
# The Student Node Recieves the Question Paper

set Questions [lindex [split $data ":"] 1]
puts "\nNode [$node_ node-addr] Recieves Question Sheet from $source"
$ns trace-annotate "Node [$node_ node-addr] Recieves Question Sheet from $source"
set AnsweringTime [expr [$ns now] + [$rng integer 50]]
$ns at $AnsweringTime "$self SubmitAnswers $source"
#$self SubmitAnswers $source
} 

"ANSS" { 
# The Lecturer Node Recieves a Answer Sheet Message


set Answer [lindex [split $data ":"] 1]

# The Answer May be Decrypted by using the Private Key of the node - It can be done latter

puts "Node [$node_ node-addr] Recieved Answer Sheet from $source"
$ns trace-annotate "Node [$node_ node-addr] Recieved Answer Sheet from $source"

} 

default {
puts "\nNode [$node_ node-addr] Recieved An Unknown Message Type with ID: $message_id\n"
}

} ;# end of switch

}

Similarly, send function of the c code also will be handled from the tcl code according to the requirements of the proposed protocol as follows.

Agent/EClassAgent instproc Send_Message_to_a_Node {size message_id data addrs port} {
$self instvar node_
global ns BROADCAST_ADDR BroadcastDelay

$self sendto $size "$message_id:$data" $addrs $port
}

Agent/EClassAgent instproc Broadcast_Message_to_All {size message_id data port} {
$self instvar node_
global ns MESSAGE_PORT BROADCAST_ADDR BroadcastDelay
$ns trace-annotate "[$node_ node-addr] sending message $message_id"
$self sendto $size "$message_id:$data" $BROADCAST_ADDR $port
}

The terminal window output and nam output

The following NAM scenario shows a typical E-Class network scenario .consists of 50 nodes.

Here we assume 49 student nodes and 1 lecture delivering node.

In the following NAM scenario, Node 0 is Lecture delivering node and the cluster of nodes in the same color belong to same subgroup.
Here we use k-mean clustering to make clusters. But practically any node irrespective of its location can be a member of any subgroup.

Nodes are actively communicating with one another as per the protocol.

 The Console/Terminal window Output