research article seman: a novel secure middleware for mobile ad hoc...

19
Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networks Eduardo da Silva 1,2 and Luiz Carlos Pessoa Albini 1 1 Department of Informatics, Federal University of Parana (UFPR), 81531970 Curitiba, Brazil 2 Department of Informatics, Catarinense Federal Institute (IFC), 89245000 Araquari, Brazil Correspondence should be addressed to Eduardo da Silva; [email protected] Received 28 December 2015; Revised 18 April 2016; Accepted 26 April 2016 Academic Editor: Tzonelih Hwang Copyright © 2016 E. da Silva and L. C. Pessoa Albini. is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. As a consequence of the particularities of Mobile Ad Hoc Networks (MANETs), such as dynamic topology and self-organization, the implementation of complex and flexible applications is a challenge. To enable the deployment of these applications, several middleware solutions were proposed. However, these solutions do not completely consider the security requirements of these networks. Based on the limitations of the existing solutions, this paper presents a new secure middleware, called Secure Middleware for Ad Hoc Networks (SEMAN), which provides a set of basic and secure services to MANETs aiming to facilitate the development of distributed, complex, and flexible applications. SEMAN considers the context of applications and organizes nodes into groups, also based on these contexts. e middleware includes three modules: service, processing, and security. Security module is the main part of the middleware. It has the following components: key management, trust management, and group management. All these components were developed and are described in this paper. ey are supported by a cryptographic core and behave according to security rules and policies. e integration of these components provides security guarantees against attacks to the applications that usethe middleware services. 1. Introduction Mobile Ad Hoc Networks (MANETs) are very attractive in several scenarios, as [1] soldiers carrying out information on a battlefield; people sharing information during a meeting; attendees using notebooks in an interactive conference; rescuers working aſter disasters. MANETs are dynamically established without any fixed infrastructure or centralized administration, and their operation is held by the nodes themselves [2]. On the other hand, these characteristics also impose sev- eral challenges, and the major ones are related to security. In addition to conventional wireless communication problems, the dynamic topology facilitates action of adversaries, making MANETs susceptible to both passive and active attacks [2]. In a passive attack, an unauthorized adversary tries to discover or to use system information without interaction with the network, while in an active one, the adversary tries to break into the system aiming to affect its operation [3]. Due to these particularities, the development of applications for MANET is not an easy task [4]. In general networks, to support the resolution of het- erogeneity, scalability, and resource sharing problems and to allow the implementation of more complex and flexible appli- cations, middleware solutions have been successfully used [5]. ese solutions aim to provide interoperability and other services, as distribution of functionality, scalability, load bal- ancing, and fault tolerance [6]. Several middleware solutions have also been proposed to support applications and services on MANETs. ese solutions are message-oriented [7] and were classified, in a previous work [4], on tuple space-based, P2P-based, context- based, cross-layer, and application-oriented solutions. A complete analysis and comparison of these middleware solu- tions can be found in [4]. To support MANETs characteristics, a middleware must be lightweight in terms of the amount of processing, memory, and bandwidth consumption, to maintain its overhead as Hindawi Publishing Corporation Journal of Computer Networks and Communications Volume 2016, Article ID 3136853, 18 pages http://dx.doi.org/10.1155/2016/3136853

Upload: others

Post on 25-Jun-2020

4 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Research ArticleSEMAN A Novel Secure Middleware forMobile Ad Hoc Networks

Eduardo da Silva12 and Luiz Carlos Pessoa Albini1

1Department of Informatics Federal University of Parana (UFPR) 81531970 Curitiba Brazil2Department of Informatics Catarinense Federal Institute (IFC) 89245000 Araquari Brazil

Correspondence should be addressed to Eduardo da Silva eduardoifc-araquariedubr

Received 28 December 2015 Revised 18 April 2016 Accepted 26 April 2016

Academic Editor Tzonelih Hwang

Copyright copy 2016 E da Silva and L C Pessoa Albini This is an open access article distributed under the Creative CommonsAttribution License which permits unrestricted use distribution and reproduction in any medium provided the original work isproperly cited

As a consequence of the particularities of Mobile Ad Hoc Networks (MANETs) such as dynamic topology and self-organizationthe implementation of complex and flexible applications is a challenge To enable the deployment of these applications severalmiddleware solutions were proposed However these solutions do not completely consider the security requirements of thesenetworks Based on the limitations of the existing solutions this paper presents a new securemiddleware called SecureMiddlewarefor Ad Hoc Networks (SEMAN) which provides a set of basic and secure services toMANETs aiming to facilitate the developmentof distributed complex and flexible applications SEMAN considers the context of applications and organizes nodes into groupsalso based on these contextsThemiddleware includes threemodules service processing and security Securitymodule is themainpart of the middleware It has the following components key management trust management and group management All thesecomponents were developed and are described in this paper They are supported by a cryptographic core and behave accordingto security rules and policies The integration of these components provides security guarantees against attacks to the applicationsthat usethe middleware services

1 Introduction

Mobile Ad Hoc Networks (MANETs) are very attractive inseveral scenarios as [1] soldiers carrying out information ona battlefield people sharing information during a meetingattendees using notebooks in an interactive conferencerescuers working after disasters MANETs are dynamicallyestablished without any fixed infrastructure or centralizedadministration and their operation is held by the nodesthemselves [2]

On the other hand these characteristics also impose sev-eral challenges and the major ones are related to security Inaddition to conventional wireless communication problemsthe dynamic topology facilitates action of adversariesmakingMANETs susceptible to both passive and active attacks [2] Ina passive attack an unauthorized adversary tries to discoveror to use system information without interaction with thenetwork while in an active one the adversary tries to breakinto the system aiming to affect its operation [3] Due to these

particularities the development of applications for MANETis not an easy task [4]

In general networks to support the resolution of het-erogeneity scalability and resource sharing problems and toallow the implementation ofmore complex and flexible appli-cations middleware solutions have been successfully used[5]These solutions aim to provide interoperability and otherservices as distribution of functionality scalability load bal-ancing and fault tolerance [6]

Several middleware solutions have also been proposedto support applications and services on MANETs Thesesolutions are message-oriented [7] and were classified in aprevious work [4] on tuple space-based P2P-based context-based cross-layer and application-oriented solutions Acomplete analysis and comparison of these middleware solu-tions can be found in [4]

To support MANETs characteristics a middleware mustbe lightweight in terms of the amount of processingmemoryand bandwidth consumption to maintain its overhead as

Hindawi Publishing CorporationJournal of Computer Networks and CommunicationsVolume 2016 Article ID 3136853 18 pageshttpdxdoiorg10115520163136853

2 Journal of Computer Networks and Communications

small as possible Further it must self-adapt to the dynamicenvironment and handle unpredictable message loss Con-sidering the security requirements of MANETs and since themiddleware handles all the communication between a clientand an application itmust also considers the security require-ments [6] However middleware solutions do not consideror consider only partially the security requirements of theMANETs As a consequence security can be considered themain drawback of the solutions reported on [4] Thus theneed for developing a middleware arises which considers thesecurity challenges of MANETs and contains a set of com-ponents to provide secure services to applications

This paper proposes a new SecureMiddleware forMobileAd Hoc Networks called SEMAN (Secure Middleware forMobile Ad Hoc Networks) The middleware is based ongroups which are formed considering the context informa-tion Group members exchange information which can beused on decision making and services provisioning SEMANhas a security module which aims to ensure the system confi-dentiality and the resistance to following malicious attacksselfish byzantine impersonation and Sybil The contribu-tions of this paper are the new architecture of a secure mid-dleware for MANETs the design of a context-based groupmanagement and definition of strategies to the secure groupcommunication the integration of trust management andevaluation services and an identity-based key managementscheme integrated with the SEMAN cryptographic core

The remaining of the paper is composed of six sectionsSection 2 presents the network and the attack model Sec-tion 3 introduces SEMAN Secure Middleware for MobileAd Hoc Networks Section 4 details the security model ofSEMAN and how it can ensure security for middlewareclients Section 5 presents a scheme for secure group com-munication based on key agreements Section 6 presents theintegration of the security components to provide security toapplications on different scenarios Finally Section 7 presentsthe conclusions and some research directions

2 Network and Attack Model

The proposed middleware considers an asynchronous net-work composed of 119899 mobile nodes denoted by 119873

1 119873

119899

The description of SEMAN considers the notation presentedas follows

G1 cyclic additive group with order 119901

G2 cyclic multiplicative group with order 119901

119890 bilinear pairing in which 119890 G1times G1rarr G2

1198671(119909) hash function in which119867

1(119909) = 0 1

lowastrarr Glowast1

1198672(119909) hash function in which119867

2(119909) = G

2rarr Zlowast119901

119873F founder nodes119873119894 identification of node 119894

SK119894 private key of node 119894

PK119894 private key of node 119894

MSK master private key of systemMPK master public key of systemMSK119894 share of master private key hold by node 119894

It is assumed that only trust nodes participate in group ini-tialization phases

SEMAN aims to protect the network against some mali-cious attacks as selfish byzantine impersonation and SybilEven though SEMAN may be effective against other attacksthey were not considered in this paper

(i) Selfish Attacks A node presents a selfish behavior either asa consequence of a malicious and intentional act or to save itsown resources But regardless the reason the selfish behaviormay compromise the network activities and any decision-making scheme which needs the cooperation of nodes Toguarantee the security against a selfish behavior SEMANgroup operations are structured considering the secret shar-ing (119905 over 119899) technique in which 119899 minus (119905 + 1) nodes maybe unavailable or present a selfish behavior and the systemis able to attend the requests Further trust managementcomponent provides information about the behavior of nodesin a contextThus if a node is selfish and does not participateon group activities the other nodes will be aware of thisbehavior through the trust management component

(ii) Byzantine Attacks A malicious node may perform abyzantine attack against the system issuing false informationor making decisions on behalf of a group Thus a byzantineattack may compromise the reliability of the middlewareoperations The strategy to organize nodes into groups usingsecret sharing technique 119905-over-119899 increases the system pro-tection against these attacks Then a malicious node mustcompromise at least other 119905 nodes to perform any maliciousactivity on behalf of a group making its actions more dif-ficult and limited Also similar to selfish attack the trustmanagement provides ways for nodes to inform other onesif they detect some byzantine behavior Thus based on trustinformation byzantine nodes can be isolated

(iii) Impersonation Attacks An attacker may steal the identityof a node and compromise the system reliability issuingfalse information on behalf of this node A key managementservice is implemented to prevent this kind of attack againstthe system All secure services provided by the middlewareuse cryptography By using the key management the middle-ware ensures that an identity belongs to the node that isusing it Thus an attacker needs to compromised the entirekey management component to be success on this kind ofmalicious action Also a secure communication service pro-vided by the group management is implemented whichincreases the reliability of SEMAN against impersonationattacks ensuring that onlymembers of a closed group are ableto decrypt a message sent to this group

(iv) Sybil Attack In a Sybil attack a malicious node createsa false identity and gets the authorization of other nodes tohave this false identity accepted in the system Then systemreliability is affected since a unique node may perform sev-eral activities on behalf of a group Similar to impersonationattack key management helps to prevent the action of a Sybilattacker As the identity of a node is certified by the keymanagement it is necessary that an attacker compromises the

Journal of Computer Networks and Communications 3

Physical channel (nonreliable)

Secure channel(over physical channel)

Request RequestApplication Application

Securitymodule

Securitymodule

Middleware Middleware

Node Na Node Nb

Figure 1 Reliable communication using a secure middleware

key management scheme to be able to create a false identityand issue a valid publicprivate key pair to this new identityAlso the secure communication of the group managementcomponent increases the reliability of SEMAN against thisattack As the secure communication service ensures thatonly the members of a closed group are able to decrypt amessage sent to a group it prevents a node from creating afalse identity and from using this identity to receive messagessent to a group that it is not a member of

This section presented the network characteristics ad-dressed in this work and the attack model considered Fourkinds of attacks and how they may compromise the networkbehavior performance and operations were described

3 Secure Middleware for Mobile AdHoc Networks

This section describes the SEMAN the new context-basedmiddleware that utilizes a group approach to support deci-sion making related to security Based on [4] context-basedsolutions are more suitable for MANETs Further the groupapproach facilitates the nodes organization on the contextsand security-related decisionmaking Figure 1 illustrates howapplications may use the middleware to perform a reliablecommunication over an unreliable physical channel

SEMAN provides support to secure and reliable commu-nications between multiple nodes in scenarios susceptible tomalicious attacks It is composed of distributed modules anda set of group-based cryptographic operations To supportmiddleware operations nodes with similar requirementsform groups These groups called context groups are self-organized and dynamically formed with no user interactionconsidering only applications profiles and requirementsServices are provided and utilized by the applications in acontext and consequently they are made available to nodesthat belong to groups of this context

SEMAN is composed of a communication interface acatalog and threemodules services processing and securityas illustrated in Figure 2 Applications requests may be senteither to the middleware or to lower layers Without lossof generality only the former scenario is considered in this

paper All message exchanges between the middleware andthe applications are performed by using the communicationinterface which classifiesmessages and deliveries them to thecorrect module or application

The catalog is composed of a nonvolatile memory andis responsible for keeping all pending requests and securityinformation about applications and nodes like cryptographickeys trust information credential and so forth It is impor-tant to ensure the resistance in at least three scenarios (i)node crash (ii) network disconnection and (iii) long delaysin service provisioning These situations may result eitherfrom a malicious action or from the dynamic behavior ofMANETs

The next subsections present themain characteristics andfunctionalities of the three modules and their components

31 Services Module The services module is responsible forkeeping a list and details of all services and applicationshosted by the node to other nodes It encompasses theresource management mobility management and distrib-uted storage All these components are accessed by internaland external applications

311 Resource Management A service that provides infor-mation about location and availability of resources as nodesremote services and contents is very important forMANETs[8] This service must consider the following restrictions (i)mitigate the communication overhead avoiding unneededupdates about available resources (ii) be independent ofnodes geographical position and (iii) be independent of rout-ing protocol This component must consider the resourcesdiscovery and allocation as well as their location manage-ment

Resource management must offer at least four subcom-ponents as depicted in Figure 3 allocation registration dis-covery and location of resources Each subcomponentrequests and provides information to processing and securitymodules For example the security module provides infor-mation about nodes and applications authorization whilethe resource allocation subcomponent provides informationabout the use of resources to the processing module

Information about resources is locally stored and avail-able to all local applications that use the middleware servicesAlso this information can be available to other nodes con-sidering their context and permissions The control access ismaintained by securitymodule and is based on context groupformation

312 Mobility Management This component is particularlyimportant since mobile nodes can move and change theirgeographical positions unpredictably affecting the perfor-mance of distributed applications Besides nodes mobilitythis service must consider the applications mobility whichcan migrate from a node to another To provide an effectiveservice to applications it contains three subcomponents asdepicted in Figure 4 locationmanagement transfer manage-ment and disconnection management

Location management must provide information aboutnodes physical location to applications Thus it is assumed

4 Journal of Computer Networks and Communications

Application 1 Application 2 Application 3 Application 4 middot middot middot

Mid

dlew

are

Communication interface

Service module(i) Resources management

(ii) Mobility management(iii) Distributed storage

Security module(i) Group management(ii) Trust management(iii) Key management(iv) Security policies

Processing module(i) Requests management(ii) Components and services management

Catalog

Inte

rnal

com

mun

icat

ion

API

sLower layers

Figure 2 Architecture of the secure middleware

Services module

Resource managementResourceallocation

Resourceregistration

Resourcelocation Resource

discovery

Catalog

Processing moduleRequest

management

Servicemanagement

Security

Groupmanagement

Figure 3 Components of resource management module

Services module Processing module

Mobility managementGroup

management

Security

Locationmanagement

Disconnectionmanagement

Transfermanagement

Catalog

Figure 4 Components of mobility management module

Journal of Computer Networks and Communications 5

Services module Processing module

Distributed storage

Datadistribution

Dataexclusion

DataretrieveReplica

management

Catalog

Groupmanagement

Security

Figure 5 Components of distributed storage component

thatmembers of a group keep their location up-to-date in thisgroup Transfer management must allow mobile applicationsto keep the connection during a migration It aims to mit-igate the delay of applications transfers and to eliminate appli-cations losses resulting from the migration Finally discon-nection management must provide information about thereachability or disconnections of nodes that provide servicesthrough SEMAN

313 Distributed Storage This component allows nodes tostore their information in a distributed secure dynamicand self-organized way It does not depend on any specificnode availability and must be highly resistant to maliciousattacks Its main objective is to distribute context informationto nodes of a group related to this context This contextinformation is fragmented into the network and the absenceof some nodes should not affect the stored data retrieval

It is composed of four subcomponents illustrated inFigure 5 data distribution data retrieve replicamanagementand data exclusion All these components have a relationshipwith security and group management modules

Data distribution is responsible for disseminating infor-mation to remote nodes Data retrieve handles the accessrequests and locates remote data Replica management isresponsible for keeping enough active replicas to ensure theinformation availability and the data consistency Exclusiondata guarantees that when requested data will be excludedfrom all remote nodes in which it is stored

32 Processing Module Processing module is responsible forkeeping the central operation of SEMAN It is composed ofrequests management and services and components manage-ment

321 Requests Management This component is responsiblefor keeping a registration of all services requests made to themiddleware It keeps the registration of both pending andattended requests

An application is able to use simultaneously one or moreservices provided by the middleware Due to the dynamiccharacteristics of MANETs applications may not be aware of

Securitymodule

Requestsmanagement Catalog

Resourcesmanagement

Other components

Network

2 1

3

54

C1 C2 C3 Cnmiddot middot middot

Figure 6 Services requests

which services are being provided in a given time or whichnodes are hosting these services Figure 6 depicts how a ser-vice request is operated by SEMANUpon receiving a requestthe request management component gets the security param-eters with the security module Then it must check the avail-ability of the requested servicewith the resourcemanagementcomponent If the service is provided by the middleware itstores the information about the request into the catalog per-forms the required communications with other componentsand sends the request to the corresponding nodes

As services may be provided by more than one nodeSEMANmight

(1) request the service to all nodes that provide it increas-ing the service availability and reducing the replytime

(2) distribute the requests among nodes that provide itmaking a load balance or

(3) choose the more reliable node based on previousexperiences

During the service provisioning the middleware mayprovide mechanisms to prevent malicious attacks It mustauthenticate and authorize applications Also all messagesexchanged with the middleware must be ciphered to preventeavesdropping

6 Journal of Computer Networks and Communications

Security services

Trust Keys

Groups

Secu

rity

polic

ies

Cryp

togr

aphi

c cor

e

Figure 7 Security module diagram

322 Services and Components Management This compo-nent has a simple but essential function to the middlewareoperation It is responsible for keeping a registration of allservices and components provided by SEMAN When a userwants to make a service available through the middlewarethis services must be previously registered All relevant infor-mation of the new service as security policies and contextmust be stored into catalog Then other nodes can beinformed about the availability of the new service

This component must provide primitives to the registra-tion of new services as well the query of provided servicesSimilarly for each registered component it is necessaryto store information about access strategies and servicesrequirements

33 Conclusion This section presented an overview ofSEMAN its modules and main characteristics All next sec-tion will detail the security operations and module and howthey will provide security to the middleware applications

4 Security Module

This module is the central point of SEMAN Its componentsas depicted in Figure 7 include key management trust man-agement and groupmanagementThese components operatewith cryptographic operations and security policies compo-nents which provide basic security primitives to the module

Security services use a context-based group approachAll management operations and decision making are basedon information provided by other members of the contextgroup Thus nodes cooperate among themselves to increasethe reliability of available services However the use of allcomponents is not mandatory

41 Cryptographic Core To ensure that messages are notprone to eavesdropping all messages must be cipheredThough any cryptographic mechanism can be used identity-based ones seem to be more suitable for MANETs [9] Sym-metric schemes impose a high cost to manage pairwise secretkeys and when compared with traditional certificate-basedasymmetric schemes identity-based cryptography (IBC)presents at least three advantages [10]

(1) does not require certificates mitigating certificatesstorage distribution and verification cost

(2) makes easy noninteractive key agreement reducingcommunication and processing overhead

(3) removes the requirement of destination public keysauthentications before message sending

Another advantage to use IBC on MANETs is that theyhave a simple key management and a reduced storage costif compared with other methods On IBCs the identity of auser as e-mail or IP is used to derive the node public keyThus all nodes are able to disclose the public key of othernodes without data exchange However IBCs present adrawback Private key is generated and available by an entityknown as Private Key Generator (PKG) This characteristicimposes an implementation challenge since PKG can be asingle point of failure To mitigate the impact of a centralPKG in this work the PKG is distributed over the network

42 Cryptographic Operations SEMAN considers the use ofidentity-based cryptography Any IBC can be used depend-ing on middleware requirements Without loss of generalitythe Boneh and Franklin scheme is employed [11]

The main algorithms to perform cryptographic opera-tions and to support the secure communication betweennodes are composed of configuration and extraction andencryption and decryption The former two are detailed onSection 44 which discusses the key management since theyare related to system initialization and key issuing

The encryption and decryption algorithms are presentedas follows Let 119896 isin Z+ be a security parameter from securitymodule and G a generator of BDH parameter

(1) Encryption to encrypt119872 using a public key of node119894 follow the next steps

(a) calculate PK119894= 1198671(119873119894)

(b) choose a random 119903 isin Zlowast119902

(c) generate the encrypted text 119862 = ⟨119903119875119872 oplus

1198672(119892119903

119894)⟩ in which 119892

119894= (119873

119894PK119894) isin Glowast2

(2) Decryption let119862 = ⟨119880119881⟩ be the encrypted text usingthe public key of node 119894 To decrypt the message theprivate key SK

119894is necessary The following formula

shows as text may be decrypted

119881 oplus1198672( (SK

119894 119880)) = 119872 (1)

The proof of these algorithms can be found in [11]

43 Trust Management Though cryptography may be usedto ensure communication security it does not provide infor-mation about the reliability of the nodes [12] Further manycryptographic mechanisms such as keymanagement [13 14]rely on some degree of preestablished trust between nodesHowever trust in any kind of open network is very difficult tobe valued and has received a lot of attention from the securitycommunity [15]

In a previous work [16 17] TRUE was presented to eval-uate the trust between pairwise communicating nodes TRUEuses the concept of trust chains formed between nodes by

Journal of Computer Networks and Communications 7

06

06

04

06 02

01 08

08

08

05 08

07

04

03

03

02

03

nf

nb

nq

nx nw

nz nvnu

nt

nm

Figure 8 Example of trust chain 119866119909tr from node 119899119909

direct monitoring and recommendations of physical neigh-bors It supports applications in an autonomous and dynamicway while keeping the ability to resist malicious attacks Inthis approach each node creates in a self-organized strategy atrust network based on context to provide trust informationrepresented by a direct graph 119866tr = (119881tr 119864tr) in which ver-texes119881tr are the nodes and edges119864tr are the trust relationshipsbetween them The trust network or trust graph containsall trust information which a node has about other nodesin a context This information or evidences is gathered viadirect interaction or by recommendations considering thesystem security policies The trustworthiness of a node isalways locally computed with no kind of message exchangebased on the trust network In the next subsection are brieflypresented the operation of the TRUE and its procedures andan evaluation of the proposed service

431 Building Context-Based Trust Networks When joiningthe system each node119873

119894creates its own trust network 119866119894tr =

(119881119894

tr 119864119894

tr) in a self-organized way Initially nodes have knowl-edge only about nodes with which they have direct trust rela-tions and only such data is stored in the trust networkThenin predetermined time intervals (Δ119879ex) nodes exchange trustevidences with their physical neighbors propagating trustvalues through the network in an epidemic behavior [18 19]

During trust information exchange each node evaluatesthe relevance of the received evidences by calculating thetrustworthiness of the sender Then it decides whether itaccepts or not such evidences based on local policy rules If itaccepts the trust evidences then it incorporates the receivedinformation on its context-based trust network Otherwisetrust evidences are discarded

432 Trust Evaluation To evaluate the trust on node 119873119906

node 119873119909must either have a direct connection with node 119899

119906

in 119866119909tr or it finds at least one trust chain (TC) from119873119909to119873119906

in119866119909tr Trust chains represent a transitive trust from119873119909to119873119906

The trust network graph 119866119909tr is depicted in Figure 8 As node119873119909can find several different trust chains between itself and

119873119906in 119866119909tr each chain is denoted as TC119894

(119873119909119873119906)

If 119873119909has a direct trust with 119873

119906 only this value is con-

sidered on trust evaluation Otherwise it tries to find a trust

path in 119866119909

tr Upon finding a chain node 119873119909must compute

its trust Consider 1198731to 119873119898as the 119898 intermediary nodes

in the 119894th trust chain denoted as TC119894(119873119909119873119906) (2) estimates the

trustworthiness of TC119894(119873119909119873119906)

TC119894(119873119909119873119906)= TV(1198731199091198731)times

119898minus1

prod

119895=1

TV(119873119895119873119895+1)times TV(119873119898119873119906) (2)

Returning to Figure 8 there are several chains between 119899119909and

119899119906 for example

(1) chain (119873119909rarr 119873119902rarr 119873119898rarr 119873119906) trust chain value

TC1(119873119909119873119906)= 08 times 06 times 07 = 0336

(2) chain (119873119909rarr 119873119902rarr 119873119887rarr 119873119891rarr 119873119898rarr 119873119906) trust

chain value TC2(119873119909119873119906)= 08 times 03 times 05 times 08 times 07 =

0067

Furthermore nodes can use a threshold value for eachedge of the trust chain (120573 value) If at least one edge of thetrust chain has a trust value below this threshold the chain isdiscarded After calculating the trust value for all chains thetrust value TV

(119873119909119873119906)can be calculated applying a weighted

mean as follows

TV(119873119909119873119906)=

sum119896

119894=1(TC119894(119873119909119873119906)times (1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816))

sum119896

119894=1(1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816)

(3)

The weighted mean reduces the impact of transitivity intrust chains In fact the greater the chain the less reliable itisThus this method aims to privilege small chains followinga social perspective

44 KeyManagement SEMANemploys identity-based cryp-tography (IBC) [20] to perform its cryptographic operationswhich requires an entity acting as a Private Key Generator(PKG) As the PKG knows the master private key it is ableto decrypt or sign messages on behalf of any client withoutany active attack and without being detectedThis problem isknown as key escrow These issues have been considered themain drawback that leads to the low adoption of IBC outsideclosed environments [21] Boneh and Franklin suggesteddistributing the PKG to handle these problems using secretsharing schemes (119899 119905) in which 119899 nodes form a distributedPKG (D-PKG) and only a subset of 119905 + 1 nodes is able tocompute the master private key [11]

Several identity-based key management schemes havebeen designed for MANETs and most of them consider thedistribution of the PKG [9] However proposed schemes donot consider all characteristics of these networks

In a previous work [22] the Identity-based Fully SelfOrganized (119894FUSO) key management service was presentedwhich can be integrated with SEMAN The 119894FUSO considersan asynchronous network composed of 119899 nodes representedby1198731 1198732 119873

119899 in whichmalicious nodes can compromise

at most 119905 nodes and 119905 lt 119899 It considers that only trusted nodesparticipate in the system initialization Nodes which initializethe system are called founding nodes denoted by 119873F

8 Journal of Computer Networks and Communications

These nodes form the distributed PKG (D-PKG) in a fullydistributed way No node knows the master private key sinceit is distributed in 119905-over-119899 threshold scheme Also to adaptto the dynamism of the network 119894FUSO allows nodes to joinor leave the D-PKG

To prevent the system from cryptanalysis attacks the119894FUSO provides a way to update public and private keysof nodes similar to [23 24] The key update may occureither periodically according to a predetermined intervalor reactively when the number of revoked nodes reaches athreshold value Nodes are able to update their public keysautonomously and their private key by requesting to the D-PKG Further the 119894FUSO supports both implicit and explicitrevocations

441 Initialization The 119894FUSO must be initialized by a setof 119898 founding nodes (119873F) which must be able to securelyexchange information to initialize the system As the first stepof the initialization nodes must determine

(1) the system size 119899 and the security threshold 119905

(2) 119901 119902 two large prime numbers in which 119902 divides (119901minus1)

(3) G1 a cyclic additive group with order 119901

(4) a generator 119892 isin G1

(5) G2 a cyclic multiplicative group with order 119901

(6) the pairing type making sure that there exists a bilin-ear paring 119890 G

1times G1rarr G2of the chosen type

(7) G = ⟨119890G1G2⟩

This step can be performed jointly by nodes which areinitializing the group or proposed by one node to the others

To initialize the system founding nodes set up the D-PKG generating the master public key and its correspondingmaster private keyTheD-PKG is built in a distribute 119905-over-119899way among the 119899 founding nodes

442 New Members Joining the D-PKG In a MANET itis very important for a D-PKG to be highly dynamic anddecentralized and new nodes must be able to join thedistributed PKG at any timeThus these nodesmust receive ashare of MSK computed by at least 119905members of the D-PKG

If a newnode119873119896wants to join theD-PKG itmust contact

at least 119905 members of the D-PKG to get the correspondinginformation from these nodes The join of new nodes to theD-PKG must follow the following

(1) node119873119896selects 119905members of D-PKG denoted byΩ

(2) node119873119896requests each node of Ω to be accepted as a

member of the D-PKG

(3) each node 119873119895isin Ω sends a piece of information

119891(119895 119896) = 119878119896

119895back to119873

119896

(4) after receiving 119905 replies 119873119896can compute its polyno-

mial share MSK119896using a Lagrange interpolation

443 Issuing Node Private Key The 119894FUSO is composed ofa number of continuous nonoverlapping key update phasesdenoted by 119901

Δ in which Δ represents the phase index As in

[23] each 119901Δis associated with a unique binary phase string

denoted as strΔ For each 119873

119894 its public key is represented by

PK119894= 1198671(119873119894) while the corresponding private key is repre-

sented by SK119894= (PK

119894)MSK Recalling that in the 119894FUSO no

node knows MSK which is generated and stored in a fullydistributed way To retrieve its private key SK

119894 node119873

119894must

request theD-PKG for it and towait for at least 119905 repliesThusthe following steps must be executed

(1) 119873119894must select at least 119905 nodes from the D-PKG

This set of nodes is denoted by Ψ To minimize therequesting time the Ψ has all nodes of the D-PKG

(2) 119873119894requests its share of SK

119894to each node in Ψ

(3) each node119873119895isin Ψ sends back to119873

119894a share of the pri-

vate key 120590119895119894= (PK

119894)MSK119895

(4) upon receiving at least 119905 replies 119873119894computes its pri-

vate key SK119894as

SK119894= prod

119896isinΨ

(120590119896

119894)

120582119896

(4)

in which 120582119896= prod119896isinΨ

(119896(119896 minus 119894)) are appropriate La-grange coefficients

444 Key Renewing To prevent attacks against the dis-tributed PKG and potential threats resulting from compro-mised keys a technique similar to the one proposed in [23]known as key update or key renewing is employed Securitysolutions based on key update are common practices onMANETs [25ndash27] In the 119894FUSO a new key update phase119901119894+1

starts after a predetermined time threshold As all nodesmust update their keys if themembers of the distributed PKGdo not update the key of a given node 119873

119886 it is (implicitly)

considered revokedEach node 119873

119886can autonomously update its public key

PK119886119901119894

= (1198671(119873119886)1198671(str119894)) in which str

119894= str119894minus1

+ 1 On theother hand generating the phase private key involves at least119905 members of the D-PKG A given node 119873

119911 member of the

D-PKG sends a request to at least 119905 minus 1 other members of theD-PKG

445 KeyRevocation The 119894FUSOalso provides techniques toverify if the public key of a node is revoked Key revocationsmust be handled within the system as nodes must be ableto immediately verify the status of a public key [28] Almostall key management schemes for MANETs consider the keyrevocation based on expiration time [29] However this isnot sufficient since nodes must be able to revoke keys beforeexpiration as consequence of a compromise key or maliciousbehavior

Thus 119894FUSO supports both implicit and explicit revo-cations If any node is not allowed to recover the commonprivate key during a given phase 119901

119894 then it is neither able to

encrypt nor able to decrypt any information during this phaseand is considered implicitly revoked

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 2: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

2 Journal of Computer Networks and Communications

small as possible Further it must self-adapt to the dynamicenvironment and handle unpredictable message loss Con-sidering the security requirements of MANETs and since themiddleware handles all the communication between a clientand an application itmust also considers the security require-ments [6] However middleware solutions do not consideror consider only partially the security requirements of theMANETs As a consequence security can be considered themain drawback of the solutions reported on [4] Thus theneed for developing a middleware arises which considers thesecurity challenges of MANETs and contains a set of com-ponents to provide secure services to applications

This paper proposes a new SecureMiddleware forMobileAd Hoc Networks called SEMAN (Secure Middleware forMobile Ad Hoc Networks) The middleware is based ongroups which are formed considering the context informa-tion Group members exchange information which can beused on decision making and services provisioning SEMANhas a security module which aims to ensure the system confi-dentiality and the resistance to following malicious attacksselfish byzantine impersonation and Sybil The contribu-tions of this paper are the new architecture of a secure mid-dleware for MANETs the design of a context-based groupmanagement and definition of strategies to the secure groupcommunication the integration of trust management andevaluation services and an identity-based key managementscheme integrated with the SEMAN cryptographic core

The remaining of the paper is composed of six sectionsSection 2 presents the network and the attack model Sec-tion 3 introduces SEMAN Secure Middleware for MobileAd Hoc Networks Section 4 details the security model ofSEMAN and how it can ensure security for middlewareclients Section 5 presents a scheme for secure group com-munication based on key agreements Section 6 presents theintegration of the security components to provide security toapplications on different scenarios Finally Section 7 presentsthe conclusions and some research directions

2 Network and Attack Model

The proposed middleware considers an asynchronous net-work composed of 119899 mobile nodes denoted by 119873

1 119873

119899

The description of SEMAN considers the notation presentedas follows

G1 cyclic additive group with order 119901

G2 cyclic multiplicative group with order 119901

119890 bilinear pairing in which 119890 G1times G1rarr G2

1198671(119909) hash function in which119867

1(119909) = 0 1

lowastrarr Glowast1

1198672(119909) hash function in which119867

2(119909) = G

2rarr Zlowast119901

119873F founder nodes119873119894 identification of node 119894

SK119894 private key of node 119894

PK119894 private key of node 119894

MSK master private key of systemMPK master public key of systemMSK119894 share of master private key hold by node 119894

It is assumed that only trust nodes participate in group ini-tialization phases

SEMAN aims to protect the network against some mali-cious attacks as selfish byzantine impersonation and SybilEven though SEMAN may be effective against other attacksthey were not considered in this paper

(i) Selfish Attacks A node presents a selfish behavior either asa consequence of a malicious and intentional act or to save itsown resources But regardless the reason the selfish behaviormay compromise the network activities and any decision-making scheme which needs the cooperation of nodes Toguarantee the security against a selfish behavior SEMANgroup operations are structured considering the secret shar-ing (119905 over 119899) technique in which 119899 minus (119905 + 1) nodes maybe unavailable or present a selfish behavior and the systemis able to attend the requests Further trust managementcomponent provides information about the behavior of nodesin a contextThus if a node is selfish and does not participateon group activities the other nodes will be aware of thisbehavior through the trust management component

(ii) Byzantine Attacks A malicious node may perform abyzantine attack against the system issuing false informationor making decisions on behalf of a group Thus a byzantineattack may compromise the reliability of the middlewareoperations The strategy to organize nodes into groups usingsecret sharing technique 119905-over-119899 increases the system pro-tection against these attacks Then a malicious node mustcompromise at least other 119905 nodes to perform any maliciousactivity on behalf of a group making its actions more dif-ficult and limited Also similar to selfish attack the trustmanagement provides ways for nodes to inform other onesif they detect some byzantine behavior Thus based on trustinformation byzantine nodes can be isolated

(iii) Impersonation Attacks An attacker may steal the identityof a node and compromise the system reliability issuingfalse information on behalf of this node A key managementservice is implemented to prevent this kind of attack againstthe system All secure services provided by the middlewareuse cryptography By using the key management the middle-ware ensures that an identity belongs to the node that isusing it Thus an attacker needs to compromised the entirekey management component to be success on this kind ofmalicious action Also a secure communication service pro-vided by the group management is implemented whichincreases the reliability of SEMAN against impersonationattacks ensuring that onlymembers of a closed group are ableto decrypt a message sent to this group

(iv) Sybil Attack In a Sybil attack a malicious node createsa false identity and gets the authorization of other nodes tohave this false identity accepted in the system Then systemreliability is affected since a unique node may perform sev-eral activities on behalf of a group Similar to impersonationattack key management helps to prevent the action of a Sybilattacker As the identity of a node is certified by the keymanagement it is necessary that an attacker compromises the

Journal of Computer Networks and Communications 3

Physical channel (nonreliable)

Secure channel(over physical channel)

Request RequestApplication Application

Securitymodule

Securitymodule

Middleware Middleware

Node Na Node Nb

Figure 1 Reliable communication using a secure middleware

key management scheme to be able to create a false identityand issue a valid publicprivate key pair to this new identityAlso the secure communication of the group managementcomponent increases the reliability of SEMAN against thisattack As the secure communication service ensures thatonly the members of a closed group are able to decrypt amessage sent to a group it prevents a node from creating afalse identity and from using this identity to receive messagessent to a group that it is not a member of

This section presented the network characteristics ad-dressed in this work and the attack model considered Fourkinds of attacks and how they may compromise the networkbehavior performance and operations were described

3 Secure Middleware for Mobile AdHoc Networks

This section describes the SEMAN the new context-basedmiddleware that utilizes a group approach to support deci-sion making related to security Based on [4] context-basedsolutions are more suitable for MANETs Further the groupapproach facilitates the nodes organization on the contextsand security-related decisionmaking Figure 1 illustrates howapplications may use the middleware to perform a reliablecommunication over an unreliable physical channel

SEMAN provides support to secure and reliable commu-nications between multiple nodes in scenarios susceptible tomalicious attacks It is composed of distributed modules anda set of group-based cryptographic operations To supportmiddleware operations nodes with similar requirementsform groups These groups called context groups are self-organized and dynamically formed with no user interactionconsidering only applications profiles and requirementsServices are provided and utilized by the applications in acontext and consequently they are made available to nodesthat belong to groups of this context

SEMAN is composed of a communication interface acatalog and threemodules services processing and securityas illustrated in Figure 2 Applications requests may be senteither to the middleware or to lower layers Without lossof generality only the former scenario is considered in this

paper All message exchanges between the middleware andthe applications are performed by using the communicationinterface which classifiesmessages and deliveries them to thecorrect module or application

The catalog is composed of a nonvolatile memory andis responsible for keeping all pending requests and securityinformation about applications and nodes like cryptographickeys trust information credential and so forth It is impor-tant to ensure the resistance in at least three scenarios (i)node crash (ii) network disconnection and (iii) long delaysin service provisioning These situations may result eitherfrom a malicious action or from the dynamic behavior ofMANETs

The next subsections present themain characteristics andfunctionalities of the three modules and their components

31 Services Module The services module is responsible forkeeping a list and details of all services and applicationshosted by the node to other nodes It encompasses theresource management mobility management and distrib-uted storage All these components are accessed by internaland external applications

311 Resource Management A service that provides infor-mation about location and availability of resources as nodesremote services and contents is very important forMANETs[8] This service must consider the following restrictions (i)mitigate the communication overhead avoiding unneededupdates about available resources (ii) be independent ofnodes geographical position and (iii) be independent of rout-ing protocol This component must consider the resourcesdiscovery and allocation as well as their location manage-ment

Resource management must offer at least four subcom-ponents as depicted in Figure 3 allocation registration dis-covery and location of resources Each subcomponentrequests and provides information to processing and securitymodules For example the security module provides infor-mation about nodes and applications authorization whilethe resource allocation subcomponent provides informationabout the use of resources to the processing module

Information about resources is locally stored and avail-able to all local applications that use the middleware servicesAlso this information can be available to other nodes con-sidering their context and permissions The control access ismaintained by securitymodule and is based on context groupformation

312 Mobility Management This component is particularlyimportant since mobile nodes can move and change theirgeographical positions unpredictably affecting the perfor-mance of distributed applications Besides nodes mobilitythis service must consider the applications mobility whichcan migrate from a node to another To provide an effectiveservice to applications it contains three subcomponents asdepicted in Figure 4 locationmanagement transfer manage-ment and disconnection management

Location management must provide information aboutnodes physical location to applications Thus it is assumed

4 Journal of Computer Networks and Communications

Application 1 Application 2 Application 3 Application 4 middot middot middot

Mid

dlew

are

Communication interface

Service module(i) Resources management

(ii) Mobility management(iii) Distributed storage

Security module(i) Group management(ii) Trust management(iii) Key management(iv) Security policies

Processing module(i) Requests management(ii) Components and services management

Catalog

Inte

rnal

com

mun

icat

ion

API

sLower layers

Figure 2 Architecture of the secure middleware

Services module

Resource managementResourceallocation

Resourceregistration

Resourcelocation Resource

discovery

Catalog

Processing moduleRequest

management

Servicemanagement

Security

Groupmanagement

Figure 3 Components of resource management module

Services module Processing module

Mobility managementGroup

management

Security

Locationmanagement

Disconnectionmanagement

Transfermanagement

Catalog

Figure 4 Components of mobility management module

Journal of Computer Networks and Communications 5

Services module Processing module

Distributed storage

Datadistribution

Dataexclusion

DataretrieveReplica

management

Catalog

Groupmanagement

Security

Figure 5 Components of distributed storage component

thatmembers of a group keep their location up-to-date in thisgroup Transfer management must allow mobile applicationsto keep the connection during a migration It aims to mit-igate the delay of applications transfers and to eliminate appli-cations losses resulting from the migration Finally discon-nection management must provide information about thereachability or disconnections of nodes that provide servicesthrough SEMAN

313 Distributed Storage This component allows nodes tostore their information in a distributed secure dynamicand self-organized way It does not depend on any specificnode availability and must be highly resistant to maliciousattacks Its main objective is to distribute context informationto nodes of a group related to this context This contextinformation is fragmented into the network and the absenceof some nodes should not affect the stored data retrieval

It is composed of four subcomponents illustrated inFigure 5 data distribution data retrieve replicamanagementand data exclusion All these components have a relationshipwith security and group management modules

Data distribution is responsible for disseminating infor-mation to remote nodes Data retrieve handles the accessrequests and locates remote data Replica management isresponsible for keeping enough active replicas to ensure theinformation availability and the data consistency Exclusiondata guarantees that when requested data will be excludedfrom all remote nodes in which it is stored

32 Processing Module Processing module is responsible forkeeping the central operation of SEMAN It is composed ofrequests management and services and components manage-ment

321 Requests Management This component is responsiblefor keeping a registration of all services requests made to themiddleware It keeps the registration of both pending andattended requests

An application is able to use simultaneously one or moreservices provided by the middleware Due to the dynamiccharacteristics of MANETs applications may not be aware of

Securitymodule

Requestsmanagement Catalog

Resourcesmanagement

Other components

Network

2 1

3

54

C1 C2 C3 Cnmiddot middot middot

Figure 6 Services requests

which services are being provided in a given time or whichnodes are hosting these services Figure 6 depicts how a ser-vice request is operated by SEMANUpon receiving a requestthe request management component gets the security param-eters with the security module Then it must check the avail-ability of the requested servicewith the resourcemanagementcomponent If the service is provided by the middleware itstores the information about the request into the catalog per-forms the required communications with other componentsand sends the request to the corresponding nodes

As services may be provided by more than one nodeSEMANmight

(1) request the service to all nodes that provide it increas-ing the service availability and reducing the replytime

(2) distribute the requests among nodes that provide itmaking a load balance or

(3) choose the more reliable node based on previousexperiences

During the service provisioning the middleware mayprovide mechanisms to prevent malicious attacks It mustauthenticate and authorize applications Also all messagesexchanged with the middleware must be ciphered to preventeavesdropping

6 Journal of Computer Networks and Communications

Security services

Trust Keys

Groups

Secu

rity

polic

ies

Cryp

togr

aphi

c cor

e

Figure 7 Security module diagram

322 Services and Components Management This compo-nent has a simple but essential function to the middlewareoperation It is responsible for keeping a registration of allservices and components provided by SEMAN When a userwants to make a service available through the middlewarethis services must be previously registered All relevant infor-mation of the new service as security policies and contextmust be stored into catalog Then other nodes can beinformed about the availability of the new service

This component must provide primitives to the registra-tion of new services as well the query of provided servicesSimilarly for each registered component it is necessaryto store information about access strategies and servicesrequirements

33 Conclusion This section presented an overview ofSEMAN its modules and main characteristics All next sec-tion will detail the security operations and module and howthey will provide security to the middleware applications

4 Security Module

This module is the central point of SEMAN Its componentsas depicted in Figure 7 include key management trust man-agement and groupmanagementThese components operatewith cryptographic operations and security policies compo-nents which provide basic security primitives to the module

Security services use a context-based group approachAll management operations and decision making are basedon information provided by other members of the contextgroup Thus nodes cooperate among themselves to increasethe reliability of available services However the use of allcomponents is not mandatory

41 Cryptographic Core To ensure that messages are notprone to eavesdropping all messages must be cipheredThough any cryptographic mechanism can be used identity-based ones seem to be more suitable for MANETs [9] Sym-metric schemes impose a high cost to manage pairwise secretkeys and when compared with traditional certificate-basedasymmetric schemes identity-based cryptography (IBC)presents at least three advantages [10]

(1) does not require certificates mitigating certificatesstorage distribution and verification cost

(2) makes easy noninteractive key agreement reducingcommunication and processing overhead

(3) removes the requirement of destination public keysauthentications before message sending

Another advantage to use IBC on MANETs is that theyhave a simple key management and a reduced storage costif compared with other methods On IBCs the identity of auser as e-mail or IP is used to derive the node public keyThus all nodes are able to disclose the public key of othernodes without data exchange However IBCs present adrawback Private key is generated and available by an entityknown as Private Key Generator (PKG) This characteristicimposes an implementation challenge since PKG can be asingle point of failure To mitigate the impact of a centralPKG in this work the PKG is distributed over the network

42 Cryptographic Operations SEMAN considers the use ofidentity-based cryptography Any IBC can be used depend-ing on middleware requirements Without loss of generalitythe Boneh and Franklin scheme is employed [11]

The main algorithms to perform cryptographic opera-tions and to support the secure communication betweennodes are composed of configuration and extraction andencryption and decryption The former two are detailed onSection 44 which discusses the key management since theyare related to system initialization and key issuing

The encryption and decryption algorithms are presentedas follows Let 119896 isin Z+ be a security parameter from securitymodule and G a generator of BDH parameter

(1) Encryption to encrypt119872 using a public key of node119894 follow the next steps

(a) calculate PK119894= 1198671(119873119894)

(b) choose a random 119903 isin Zlowast119902

(c) generate the encrypted text 119862 = ⟨119903119875119872 oplus

1198672(119892119903

119894)⟩ in which 119892

119894= (119873

119894PK119894) isin Glowast2

(2) Decryption let119862 = ⟨119880119881⟩ be the encrypted text usingthe public key of node 119894 To decrypt the message theprivate key SK

119894is necessary The following formula

shows as text may be decrypted

119881 oplus1198672( (SK

119894 119880)) = 119872 (1)

The proof of these algorithms can be found in [11]

43 Trust Management Though cryptography may be usedto ensure communication security it does not provide infor-mation about the reliability of the nodes [12] Further manycryptographic mechanisms such as keymanagement [13 14]rely on some degree of preestablished trust between nodesHowever trust in any kind of open network is very difficult tobe valued and has received a lot of attention from the securitycommunity [15]

In a previous work [16 17] TRUE was presented to eval-uate the trust between pairwise communicating nodes TRUEuses the concept of trust chains formed between nodes by

Journal of Computer Networks and Communications 7

06

06

04

06 02

01 08

08

08

05 08

07

04

03

03

02

03

nf

nb

nq

nx nw

nz nvnu

nt

nm

Figure 8 Example of trust chain 119866119909tr from node 119899119909

direct monitoring and recommendations of physical neigh-bors It supports applications in an autonomous and dynamicway while keeping the ability to resist malicious attacks Inthis approach each node creates in a self-organized strategy atrust network based on context to provide trust informationrepresented by a direct graph 119866tr = (119881tr 119864tr) in which ver-texes119881tr are the nodes and edges119864tr are the trust relationshipsbetween them The trust network or trust graph containsall trust information which a node has about other nodesin a context This information or evidences is gathered viadirect interaction or by recommendations considering thesystem security policies The trustworthiness of a node isalways locally computed with no kind of message exchangebased on the trust network In the next subsection are brieflypresented the operation of the TRUE and its procedures andan evaluation of the proposed service

431 Building Context-Based Trust Networks When joiningthe system each node119873

119894creates its own trust network 119866119894tr =

(119881119894

tr 119864119894

tr) in a self-organized way Initially nodes have knowl-edge only about nodes with which they have direct trust rela-tions and only such data is stored in the trust networkThenin predetermined time intervals (Δ119879ex) nodes exchange trustevidences with their physical neighbors propagating trustvalues through the network in an epidemic behavior [18 19]

During trust information exchange each node evaluatesthe relevance of the received evidences by calculating thetrustworthiness of the sender Then it decides whether itaccepts or not such evidences based on local policy rules If itaccepts the trust evidences then it incorporates the receivedinformation on its context-based trust network Otherwisetrust evidences are discarded

432 Trust Evaluation To evaluate the trust on node 119873119906

node 119873119909must either have a direct connection with node 119899

119906

in 119866119909tr or it finds at least one trust chain (TC) from119873119909to119873119906

in119866119909tr Trust chains represent a transitive trust from119873119909to119873119906

The trust network graph 119866119909tr is depicted in Figure 8 As node119873119909can find several different trust chains between itself and

119873119906in 119866119909tr each chain is denoted as TC119894

(119873119909119873119906)

If 119873119909has a direct trust with 119873

119906 only this value is con-

sidered on trust evaluation Otherwise it tries to find a trust

path in 119866119909

tr Upon finding a chain node 119873119909must compute

its trust Consider 1198731to 119873119898as the 119898 intermediary nodes

in the 119894th trust chain denoted as TC119894(119873119909119873119906) (2) estimates the

trustworthiness of TC119894(119873119909119873119906)

TC119894(119873119909119873119906)= TV(1198731199091198731)times

119898minus1

prod

119895=1

TV(119873119895119873119895+1)times TV(119873119898119873119906) (2)

Returning to Figure 8 there are several chains between 119899119909and

119899119906 for example

(1) chain (119873119909rarr 119873119902rarr 119873119898rarr 119873119906) trust chain value

TC1(119873119909119873119906)= 08 times 06 times 07 = 0336

(2) chain (119873119909rarr 119873119902rarr 119873119887rarr 119873119891rarr 119873119898rarr 119873119906) trust

chain value TC2(119873119909119873119906)= 08 times 03 times 05 times 08 times 07 =

0067

Furthermore nodes can use a threshold value for eachedge of the trust chain (120573 value) If at least one edge of thetrust chain has a trust value below this threshold the chain isdiscarded After calculating the trust value for all chains thetrust value TV

(119873119909119873119906)can be calculated applying a weighted

mean as follows

TV(119873119909119873119906)=

sum119896

119894=1(TC119894(119873119909119873119906)times (1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816))

sum119896

119894=1(1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816)

(3)

The weighted mean reduces the impact of transitivity intrust chains In fact the greater the chain the less reliable itisThus this method aims to privilege small chains followinga social perspective

44 KeyManagement SEMANemploys identity-based cryp-tography (IBC) [20] to perform its cryptographic operationswhich requires an entity acting as a Private Key Generator(PKG) As the PKG knows the master private key it is ableto decrypt or sign messages on behalf of any client withoutany active attack and without being detectedThis problem isknown as key escrow These issues have been considered themain drawback that leads to the low adoption of IBC outsideclosed environments [21] Boneh and Franklin suggesteddistributing the PKG to handle these problems using secretsharing schemes (119899 119905) in which 119899 nodes form a distributedPKG (D-PKG) and only a subset of 119905 + 1 nodes is able tocompute the master private key [11]

Several identity-based key management schemes havebeen designed for MANETs and most of them consider thedistribution of the PKG [9] However proposed schemes donot consider all characteristics of these networks

In a previous work [22] the Identity-based Fully SelfOrganized (119894FUSO) key management service was presentedwhich can be integrated with SEMAN The 119894FUSO considersan asynchronous network composed of 119899 nodes representedby1198731 1198732 119873

119899 in whichmalicious nodes can compromise

at most 119905 nodes and 119905 lt 119899 It considers that only trusted nodesparticipate in the system initialization Nodes which initializethe system are called founding nodes denoted by 119873F

8 Journal of Computer Networks and Communications

These nodes form the distributed PKG (D-PKG) in a fullydistributed way No node knows the master private key sinceit is distributed in 119905-over-119899 threshold scheme Also to adaptto the dynamism of the network 119894FUSO allows nodes to joinor leave the D-PKG

To prevent the system from cryptanalysis attacks the119894FUSO provides a way to update public and private keysof nodes similar to [23 24] The key update may occureither periodically according to a predetermined intervalor reactively when the number of revoked nodes reaches athreshold value Nodes are able to update their public keysautonomously and their private key by requesting to the D-PKG Further the 119894FUSO supports both implicit and explicitrevocations

441 Initialization The 119894FUSO must be initialized by a setof 119898 founding nodes (119873F) which must be able to securelyexchange information to initialize the system As the first stepof the initialization nodes must determine

(1) the system size 119899 and the security threshold 119905

(2) 119901 119902 two large prime numbers in which 119902 divides (119901minus1)

(3) G1 a cyclic additive group with order 119901

(4) a generator 119892 isin G1

(5) G2 a cyclic multiplicative group with order 119901

(6) the pairing type making sure that there exists a bilin-ear paring 119890 G

1times G1rarr G2of the chosen type

(7) G = ⟨119890G1G2⟩

This step can be performed jointly by nodes which areinitializing the group or proposed by one node to the others

To initialize the system founding nodes set up the D-PKG generating the master public key and its correspondingmaster private keyTheD-PKG is built in a distribute 119905-over-119899way among the 119899 founding nodes

442 New Members Joining the D-PKG In a MANET itis very important for a D-PKG to be highly dynamic anddecentralized and new nodes must be able to join thedistributed PKG at any timeThus these nodesmust receive ashare of MSK computed by at least 119905members of the D-PKG

If a newnode119873119896wants to join theD-PKG itmust contact

at least 119905 members of the D-PKG to get the correspondinginformation from these nodes The join of new nodes to theD-PKG must follow the following

(1) node119873119896selects 119905members of D-PKG denoted byΩ

(2) node119873119896requests each node of Ω to be accepted as a

member of the D-PKG

(3) each node 119873119895isin Ω sends a piece of information

119891(119895 119896) = 119878119896

119895back to119873

119896

(4) after receiving 119905 replies 119873119896can compute its polyno-

mial share MSK119896using a Lagrange interpolation

443 Issuing Node Private Key The 119894FUSO is composed ofa number of continuous nonoverlapping key update phasesdenoted by 119901

Δ in which Δ represents the phase index As in

[23] each 119901Δis associated with a unique binary phase string

denoted as strΔ For each 119873

119894 its public key is represented by

PK119894= 1198671(119873119894) while the corresponding private key is repre-

sented by SK119894= (PK

119894)MSK Recalling that in the 119894FUSO no

node knows MSK which is generated and stored in a fullydistributed way To retrieve its private key SK

119894 node119873

119894must

request theD-PKG for it and towait for at least 119905 repliesThusthe following steps must be executed

(1) 119873119894must select at least 119905 nodes from the D-PKG

This set of nodes is denoted by Ψ To minimize therequesting time the Ψ has all nodes of the D-PKG

(2) 119873119894requests its share of SK

119894to each node in Ψ

(3) each node119873119895isin Ψ sends back to119873

119894a share of the pri-

vate key 120590119895119894= (PK

119894)MSK119895

(4) upon receiving at least 119905 replies 119873119894computes its pri-

vate key SK119894as

SK119894= prod

119896isinΨ

(120590119896

119894)

120582119896

(4)

in which 120582119896= prod119896isinΨ

(119896(119896 minus 119894)) are appropriate La-grange coefficients

444 Key Renewing To prevent attacks against the dis-tributed PKG and potential threats resulting from compro-mised keys a technique similar to the one proposed in [23]known as key update or key renewing is employed Securitysolutions based on key update are common practices onMANETs [25ndash27] In the 119894FUSO a new key update phase119901119894+1

starts after a predetermined time threshold As all nodesmust update their keys if themembers of the distributed PKGdo not update the key of a given node 119873

119886 it is (implicitly)

considered revokedEach node 119873

119886can autonomously update its public key

PK119886119901119894

= (1198671(119873119886)1198671(str119894)) in which str

119894= str119894minus1

+ 1 On theother hand generating the phase private key involves at least119905 members of the D-PKG A given node 119873

119911 member of the

D-PKG sends a request to at least 119905 minus 1 other members of theD-PKG

445 KeyRevocation The 119894FUSOalso provides techniques toverify if the public key of a node is revoked Key revocationsmust be handled within the system as nodes must be ableto immediately verify the status of a public key [28] Almostall key management schemes for MANETs consider the keyrevocation based on expiration time [29] However this isnot sufficient since nodes must be able to revoke keys beforeexpiration as consequence of a compromise key or maliciousbehavior

Thus 119894FUSO supports both implicit and explicit revo-cations If any node is not allowed to recover the commonprivate key during a given phase 119901

119894 then it is neither able to

encrypt nor able to decrypt any information during this phaseand is considered implicitly revoked

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 3: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Journal of Computer Networks and Communications 3

Physical channel (nonreliable)

Secure channel(over physical channel)

Request RequestApplication Application

Securitymodule

Securitymodule

Middleware Middleware

Node Na Node Nb

Figure 1 Reliable communication using a secure middleware

key management scheme to be able to create a false identityand issue a valid publicprivate key pair to this new identityAlso the secure communication of the group managementcomponent increases the reliability of SEMAN against thisattack As the secure communication service ensures thatonly the members of a closed group are able to decrypt amessage sent to a group it prevents a node from creating afalse identity and from using this identity to receive messagessent to a group that it is not a member of

This section presented the network characteristics ad-dressed in this work and the attack model considered Fourkinds of attacks and how they may compromise the networkbehavior performance and operations were described

3 Secure Middleware for Mobile AdHoc Networks

This section describes the SEMAN the new context-basedmiddleware that utilizes a group approach to support deci-sion making related to security Based on [4] context-basedsolutions are more suitable for MANETs Further the groupapproach facilitates the nodes organization on the contextsand security-related decisionmaking Figure 1 illustrates howapplications may use the middleware to perform a reliablecommunication over an unreliable physical channel

SEMAN provides support to secure and reliable commu-nications between multiple nodes in scenarios susceptible tomalicious attacks It is composed of distributed modules anda set of group-based cryptographic operations To supportmiddleware operations nodes with similar requirementsform groups These groups called context groups are self-organized and dynamically formed with no user interactionconsidering only applications profiles and requirementsServices are provided and utilized by the applications in acontext and consequently they are made available to nodesthat belong to groups of this context

SEMAN is composed of a communication interface acatalog and threemodules services processing and securityas illustrated in Figure 2 Applications requests may be senteither to the middleware or to lower layers Without lossof generality only the former scenario is considered in this

paper All message exchanges between the middleware andthe applications are performed by using the communicationinterface which classifiesmessages and deliveries them to thecorrect module or application

The catalog is composed of a nonvolatile memory andis responsible for keeping all pending requests and securityinformation about applications and nodes like cryptographickeys trust information credential and so forth It is impor-tant to ensure the resistance in at least three scenarios (i)node crash (ii) network disconnection and (iii) long delaysin service provisioning These situations may result eitherfrom a malicious action or from the dynamic behavior ofMANETs

The next subsections present themain characteristics andfunctionalities of the three modules and their components

31 Services Module The services module is responsible forkeeping a list and details of all services and applicationshosted by the node to other nodes It encompasses theresource management mobility management and distrib-uted storage All these components are accessed by internaland external applications

311 Resource Management A service that provides infor-mation about location and availability of resources as nodesremote services and contents is very important forMANETs[8] This service must consider the following restrictions (i)mitigate the communication overhead avoiding unneededupdates about available resources (ii) be independent ofnodes geographical position and (iii) be independent of rout-ing protocol This component must consider the resourcesdiscovery and allocation as well as their location manage-ment

Resource management must offer at least four subcom-ponents as depicted in Figure 3 allocation registration dis-covery and location of resources Each subcomponentrequests and provides information to processing and securitymodules For example the security module provides infor-mation about nodes and applications authorization whilethe resource allocation subcomponent provides informationabout the use of resources to the processing module

Information about resources is locally stored and avail-able to all local applications that use the middleware servicesAlso this information can be available to other nodes con-sidering their context and permissions The control access ismaintained by securitymodule and is based on context groupformation

312 Mobility Management This component is particularlyimportant since mobile nodes can move and change theirgeographical positions unpredictably affecting the perfor-mance of distributed applications Besides nodes mobilitythis service must consider the applications mobility whichcan migrate from a node to another To provide an effectiveservice to applications it contains three subcomponents asdepicted in Figure 4 locationmanagement transfer manage-ment and disconnection management

Location management must provide information aboutnodes physical location to applications Thus it is assumed

4 Journal of Computer Networks and Communications

Application 1 Application 2 Application 3 Application 4 middot middot middot

Mid

dlew

are

Communication interface

Service module(i) Resources management

(ii) Mobility management(iii) Distributed storage

Security module(i) Group management(ii) Trust management(iii) Key management(iv) Security policies

Processing module(i) Requests management(ii) Components and services management

Catalog

Inte

rnal

com

mun

icat

ion

API

sLower layers

Figure 2 Architecture of the secure middleware

Services module

Resource managementResourceallocation

Resourceregistration

Resourcelocation Resource

discovery

Catalog

Processing moduleRequest

management

Servicemanagement

Security

Groupmanagement

Figure 3 Components of resource management module

Services module Processing module

Mobility managementGroup

management

Security

Locationmanagement

Disconnectionmanagement

Transfermanagement

Catalog

Figure 4 Components of mobility management module

Journal of Computer Networks and Communications 5

Services module Processing module

Distributed storage

Datadistribution

Dataexclusion

DataretrieveReplica

management

Catalog

Groupmanagement

Security

Figure 5 Components of distributed storage component

thatmembers of a group keep their location up-to-date in thisgroup Transfer management must allow mobile applicationsto keep the connection during a migration It aims to mit-igate the delay of applications transfers and to eliminate appli-cations losses resulting from the migration Finally discon-nection management must provide information about thereachability or disconnections of nodes that provide servicesthrough SEMAN

313 Distributed Storage This component allows nodes tostore their information in a distributed secure dynamicand self-organized way It does not depend on any specificnode availability and must be highly resistant to maliciousattacks Its main objective is to distribute context informationto nodes of a group related to this context This contextinformation is fragmented into the network and the absenceof some nodes should not affect the stored data retrieval

It is composed of four subcomponents illustrated inFigure 5 data distribution data retrieve replicamanagementand data exclusion All these components have a relationshipwith security and group management modules

Data distribution is responsible for disseminating infor-mation to remote nodes Data retrieve handles the accessrequests and locates remote data Replica management isresponsible for keeping enough active replicas to ensure theinformation availability and the data consistency Exclusiondata guarantees that when requested data will be excludedfrom all remote nodes in which it is stored

32 Processing Module Processing module is responsible forkeeping the central operation of SEMAN It is composed ofrequests management and services and components manage-ment

321 Requests Management This component is responsiblefor keeping a registration of all services requests made to themiddleware It keeps the registration of both pending andattended requests

An application is able to use simultaneously one or moreservices provided by the middleware Due to the dynamiccharacteristics of MANETs applications may not be aware of

Securitymodule

Requestsmanagement Catalog

Resourcesmanagement

Other components

Network

2 1

3

54

C1 C2 C3 Cnmiddot middot middot

Figure 6 Services requests

which services are being provided in a given time or whichnodes are hosting these services Figure 6 depicts how a ser-vice request is operated by SEMANUpon receiving a requestthe request management component gets the security param-eters with the security module Then it must check the avail-ability of the requested servicewith the resourcemanagementcomponent If the service is provided by the middleware itstores the information about the request into the catalog per-forms the required communications with other componentsand sends the request to the corresponding nodes

As services may be provided by more than one nodeSEMANmight

(1) request the service to all nodes that provide it increas-ing the service availability and reducing the replytime

(2) distribute the requests among nodes that provide itmaking a load balance or

(3) choose the more reliable node based on previousexperiences

During the service provisioning the middleware mayprovide mechanisms to prevent malicious attacks It mustauthenticate and authorize applications Also all messagesexchanged with the middleware must be ciphered to preventeavesdropping

6 Journal of Computer Networks and Communications

Security services

Trust Keys

Groups

Secu

rity

polic

ies

Cryp

togr

aphi

c cor

e

Figure 7 Security module diagram

322 Services and Components Management This compo-nent has a simple but essential function to the middlewareoperation It is responsible for keeping a registration of allservices and components provided by SEMAN When a userwants to make a service available through the middlewarethis services must be previously registered All relevant infor-mation of the new service as security policies and contextmust be stored into catalog Then other nodes can beinformed about the availability of the new service

This component must provide primitives to the registra-tion of new services as well the query of provided servicesSimilarly for each registered component it is necessaryto store information about access strategies and servicesrequirements

33 Conclusion This section presented an overview ofSEMAN its modules and main characteristics All next sec-tion will detail the security operations and module and howthey will provide security to the middleware applications

4 Security Module

This module is the central point of SEMAN Its componentsas depicted in Figure 7 include key management trust man-agement and groupmanagementThese components operatewith cryptographic operations and security policies compo-nents which provide basic security primitives to the module

Security services use a context-based group approachAll management operations and decision making are basedon information provided by other members of the contextgroup Thus nodes cooperate among themselves to increasethe reliability of available services However the use of allcomponents is not mandatory

41 Cryptographic Core To ensure that messages are notprone to eavesdropping all messages must be cipheredThough any cryptographic mechanism can be used identity-based ones seem to be more suitable for MANETs [9] Sym-metric schemes impose a high cost to manage pairwise secretkeys and when compared with traditional certificate-basedasymmetric schemes identity-based cryptography (IBC)presents at least three advantages [10]

(1) does not require certificates mitigating certificatesstorage distribution and verification cost

(2) makes easy noninteractive key agreement reducingcommunication and processing overhead

(3) removes the requirement of destination public keysauthentications before message sending

Another advantage to use IBC on MANETs is that theyhave a simple key management and a reduced storage costif compared with other methods On IBCs the identity of auser as e-mail or IP is used to derive the node public keyThus all nodes are able to disclose the public key of othernodes without data exchange However IBCs present adrawback Private key is generated and available by an entityknown as Private Key Generator (PKG) This characteristicimposes an implementation challenge since PKG can be asingle point of failure To mitigate the impact of a centralPKG in this work the PKG is distributed over the network

42 Cryptographic Operations SEMAN considers the use ofidentity-based cryptography Any IBC can be used depend-ing on middleware requirements Without loss of generalitythe Boneh and Franklin scheme is employed [11]

The main algorithms to perform cryptographic opera-tions and to support the secure communication betweennodes are composed of configuration and extraction andencryption and decryption The former two are detailed onSection 44 which discusses the key management since theyare related to system initialization and key issuing

The encryption and decryption algorithms are presentedas follows Let 119896 isin Z+ be a security parameter from securitymodule and G a generator of BDH parameter

(1) Encryption to encrypt119872 using a public key of node119894 follow the next steps

(a) calculate PK119894= 1198671(119873119894)

(b) choose a random 119903 isin Zlowast119902

(c) generate the encrypted text 119862 = ⟨119903119875119872 oplus

1198672(119892119903

119894)⟩ in which 119892

119894= (119873

119894PK119894) isin Glowast2

(2) Decryption let119862 = ⟨119880119881⟩ be the encrypted text usingthe public key of node 119894 To decrypt the message theprivate key SK

119894is necessary The following formula

shows as text may be decrypted

119881 oplus1198672( (SK

119894 119880)) = 119872 (1)

The proof of these algorithms can be found in [11]

43 Trust Management Though cryptography may be usedto ensure communication security it does not provide infor-mation about the reliability of the nodes [12] Further manycryptographic mechanisms such as keymanagement [13 14]rely on some degree of preestablished trust between nodesHowever trust in any kind of open network is very difficult tobe valued and has received a lot of attention from the securitycommunity [15]

In a previous work [16 17] TRUE was presented to eval-uate the trust between pairwise communicating nodes TRUEuses the concept of trust chains formed between nodes by

Journal of Computer Networks and Communications 7

06

06

04

06 02

01 08

08

08

05 08

07

04

03

03

02

03

nf

nb

nq

nx nw

nz nvnu

nt

nm

Figure 8 Example of trust chain 119866119909tr from node 119899119909

direct monitoring and recommendations of physical neigh-bors It supports applications in an autonomous and dynamicway while keeping the ability to resist malicious attacks Inthis approach each node creates in a self-organized strategy atrust network based on context to provide trust informationrepresented by a direct graph 119866tr = (119881tr 119864tr) in which ver-texes119881tr are the nodes and edges119864tr are the trust relationshipsbetween them The trust network or trust graph containsall trust information which a node has about other nodesin a context This information or evidences is gathered viadirect interaction or by recommendations considering thesystem security policies The trustworthiness of a node isalways locally computed with no kind of message exchangebased on the trust network In the next subsection are brieflypresented the operation of the TRUE and its procedures andan evaluation of the proposed service

431 Building Context-Based Trust Networks When joiningthe system each node119873

119894creates its own trust network 119866119894tr =

(119881119894

tr 119864119894

tr) in a self-organized way Initially nodes have knowl-edge only about nodes with which they have direct trust rela-tions and only such data is stored in the trust networkThenin predetermined time intervals (Δ119879ex) nodes exchange trustevidences with their physical neighbors propagating trustvalues through the network in an epidemic behavior [18 19]

During trust information exchange each node evaluatesthe relevance of the received evidences by calculating thetrustworthiness of the sender Then it decides whether itaccepts or not such evidences based on local policy rules If itaccepts the trust evidences then it incorporates the receivedinformation on its context-based trust network Otherwisetrust evidences are discarded

432 Trust Evaluation To evaluate the trust on node 119873119906

node 119873119909must either have a direct connection with node 119899

119906

in 119866119909tr or it finds at least one trust chain (TC) from119873119909to119873119906

in119866119909tr Trust chains represent a transitive trust from119873119909to119873119906

The trust network graph 119866119909tr is depicted in Figure 8 As node119873119909can find several different trust chains between itself and

119873119906in 119866119909tr each chain is denoted as TC119894

(119873119909119873119906)

If 119873119909has a direct trust with 119873

119906 only this value is con-

sidered on trust evaluation Otherwise it tries to find a trust

path in 119866119909

tr Upon finding a chain node 119873119909must compute

its trust Consider 1198731to 119873119898as the 119898 intermediary nodes

in the 119894th trust chain denoted as TC119894(119873119909119873119906) (2) estimates the

trustworthiness of TC119894(119873119909119873119906)

TC119894(119873119909119873119906)= TV(1198731199091198731)times

119898minus1

prod

119895=1

TV(119873119895119873119895+1)times TV(119873119898119873119906) (2)

Returning to Figure 8 there are several chains between 119899119909and

119899119906 for example

(1) chain (119873119909rarr 119873119902rarr 119873119898rarr 119873119906) trust chain value

TC1(119873119909119873119906)= 08 times 06 times 07 = 0336

(2) chain (119873119909rarr 119873119902rarr 119873119887rarr 119873119891rarr 119873119898rarr 119873119906) trust

chain value TC2(119873119909119873119906)= 08 times 03 times 05 times 08 times 07 =

0067

Furthermore nodes can use a threshold value for eachedge of the trust chain (120573 value) If at least one edge of thetrust chain has a trust value below this threshold the chain isdiscarded After calculating the trust value for all chains thetrust value TV

(119873119909119873119906)can be calculated applying a weighted

mean as follows

TV(119873119909119873119906)=

sum119896

119894=1(TC119894(119873119909119873119906)times (1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816))

sum119896

119894=1(1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816)

(3)

The weighted mean reduces the impact of transitivity intrust chains In fact the greater the chain the less reliable itisThus this method aims to privilege small chains followinga social perspective

44 KeyManagement SEMANemploys identity-based cryp-tography (IBC) [20] to perform its cryptographic operationswhich requires an entity acting as a Private Key Generator(PKG) As the PKG knows the master private key it is ableto decrypt or sign messages on behalf of any client withoutany active attack and without being detectedThis problem isknown as key escrow These issues have been considered themain drawback that leads to the low adoption of IBC outsideclosed environments [21] Boneh and Franklin suggesteddistributing the PKG to handle these problems using secretsharing schemes (119899 119905) in which 119899 nodes form a distributedPKG (D-PKG) and only a subset of 119905 + 1 nodes is able tocompute the master private key [11]

Several identity-based key management schemes havebeen designed for MANETs and most of them consider thedistribution of the PKG [9] However proposed schemes donot consider all characteristics of these networks

In a previous work [22] the Identity-based Fully SelfOrganized (119894FUSO) key management service was presentedwhich can be integrated with SEMAN The 119894FUSO considersan asynchronous network composed of 119899 nodes representedby1198731 1198732 119873

119899 in whichmalicious nodes can compromise

at most 119905 nodes and 119905 lt 119899 It considers that only trusted nodesparticipate in the system initialization Nodes which initializethe system are called founding nodes denoted by 119873F

8 Journal of Computer Networks and Communications

These nodes form the distributed PKG (D-PKG) in a fullydistributed way No node knows the master private key sinceit is distributed in 119905-over-119899 threshold scheme Also to adaptto the dynamism of the network 119894FUSO allows nodes to joinor leave the D-PKG

To prevent the system from cryptanalysis attacks the119894FUSO provides a way to update public and private keysof nodes similar to [23 24] The key update may occureither periodically according to a predetermined intervalor reactively when the number of revoked nodes reaches athreshold value Nodes are able to update their public keysautonomously and their private key by requesting to the D-PKG Further the 119894FUSO supports both implicit and explicitrevocations

441 Initialization The 119894FUSO must be initialized by a setof 119898 founding nodes (119873F) which must be able to securelyexchange information to initialize the system As the first stepof the initialization nodes must determine

(1) the system size 119899 and the security threshold 119905

(2) 119901 119902 two large prime numbers in which 119902 divides (119901minus1)

(3) G1 a cyclic additive group with order 119901

(4) a generator 119892 isin G1

(5) G2 a cyclic multiplicative group with order 119901

(6) the pairing type making sure that there exists a bilin-ear paring 119890 G

1times G1rarr G2of the chosen type

(7) G = ⟨119890G1G2⟩

This step can be performed jointly by nodes which areinitializing the group or proposed by one node to the others

To initialize the system founding nodes set up the D-PKG generating the master public key and its correspondingmaster private keyTheD-PKG is built in a distribute 119905-over-119899way among the 119899 founding nodes

442 New Members Joining the D-PKG In a MANET itis very important for a D-PKG to be highly dynamic anddecentralized and new nodes must be able to join thedistributed PKG at any timeThus these nodesmust receive ashare of MSK computed by at least 119905members of the D-PKG

If a newnode119873119896wants to join theD-PKG itmust contact

at least 119905 members of the D-PKG to get the correspondinginformation from these nodes The join of new nodes to theD-PKG must follow the following

(1) node119873119896selects 119905members of D-PKG denoted byΩ

(2) node119873119896requests each node of Ω to be accepted as a

member of the D-PKG

(3) each node 119873119895isin Ω sends a piece of information

119891(119895 119896) = 119878119896

119895back to119873

119896

(4) after receiving 119905 replies 119873119896can compute its polyno-

mial share MSK119896using a Lagrange interpolation

443 Issuing Node Private Key The 119894FUSO is composed ofa number of continuous nonoverlapping key update phasesdenoted by 119901

Δ in which Δ represents the phase index As in

[23] each 119901Δis associated with a unique binary phase string

denoted as strΔ For each 119873

119894 its public key is represented by

PK119894= 1198671(119873119894) while the corresponding private key is repre-

sented by SK119894= (PK

119894)MSK Recalling that in the 119894FUSO no

node knows MSK which is generated and stored in a fullydistributed way To retrieve its private key SK

119894 node119873

119894must

request theD-PKG for it and towait for at least 119905 repliesThusthe following steps must be executed

(1) 119873119894must select at least 119905 nodes from the D-PKG

This set of nodes is denoted by Ψ To minimize therequesting time the Ψ has all nodes of the D-PKG

(2) 119873119894requests its share of SK

119894to each node in Ψ

(3) each node119873119895isin Ψ sends back to119873

119894a share of the pri-

vate key 120590119895119894= (PK

119894)MSK119895

(4) upon receiving at least 119905 replies 119873119894computes its pri-

vate key SK119894as

SK119894= prod

119896isinΨ

(120590119896

119894)

120582119896

(4)

in which 120582119896= prod119896isinΨ

(119896(119896 minus 119894)) are appropriate La-grange coefficients

444 Key Renewing To prevent attacks against the dis-tributed PKG and potential threats resulting from compro-mised keys a technique similar to the one proposed in [23]known as key update or key renewing is employed Securitysolutions based on key update are common practices onMANETs [25ndash27] In the 119894FUSO a new key update phase119901119894+1

starts after a predetermined time threshold As all nodesmust update their keys if themembers of the distributed PKGdo not update the key of a given node 119873

119886 it is (implicitly)

considered revokedEach node 119873

119886can autonomously update its public key

PK119886119901119894

= (1198671(119873119886)1198671(str119894)) in which str

119894= str119894minus1

+ 1 On theother hand generating the phase private key involves at least119905 members of the D-PKG A given node 119873

119911 member of the

D-PKG sends a request to at least 119905 minus 1 other members of theD-PKG

445 KeyRevocation The 119894FUSOalso provides techniques toverify if the public key of a node is revoked Key revocationsmust be handled within the system as nodes must be ableto immediately verify the status of a public key [28] Almostall key management schemes for MANETs consider the keyrevocation based on expiration time [29] However this isnot sufficient since nodes must be able to revoke keys beforeexpiration as consequence of a compromise key or maliciousbehavior

Thus 119894FUSO supports both implicit and explicit revo-cations If any node is not allowed to recover the commonprivate key during a given phase 119901

119894 then it is neither able to

encrypt nor able to decrypt any information during this phaseand is considered implicitly revoked

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 4: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

4 Journal of Computer Networks and Communications

Application 1 Application 2 Application 3 Application 4 middot middot middot

Mid

dlew

are

Communication interface

Service module(i) Resources management

(ii) Mobility management(iii) Distributed storage

Security module(i) Group management(ii) Trust management(iii) Key management(iv) Security policies

Processing module(i) Requests management(ii) Components and services management

Catalog

Inte

rnal

com

mun

icat

ion

API

sLower layers

Figure 2 Architecture of the secure middleware

Services module

Resource managementResourceallocation

Resourceregistration

Resourcelocation Resource

discovery

Catalog

Processing moduleRequest

management

Servicemanagement

Security

Groupmanagement

Figure 3 Components of resource management module

Services module Processing module

Mobility managementGroup

management

Security

Locationmanagement

Disconnectionmanagement

Transfermanagement

Catalog

Figure 4 Components of mobility management module

Journal of Computer Networks and Communications 5

Services module Processing module

Distributed storage

Datadistribution

Dataexclusion

DataretrieveReplica

management

Catalog

Groupmanagement

Security

Figure 5 Components of distributed storage component

thatmembers of a group keep their location up-to-date in thisgroup Transfer management must allow mobile applicationsto keep the connection during a migration It aims to mit-igate the delay of applications transfers and to eliminate appli-cations losses resulting from the migration Finally discon-nection management must provide information about thereachability or disconnections of nodes that provide servicesthrough SEMAN

313 Distributed Storage This component allows nodes tostore their information in a distributed secure dynamicand self-organized way It does not depend on any specificnode availability and must be highly resistant to maliciousattacks Its main objective is to distribute context informationto nodes of a group related to this context This contextinformation is fragmented into the network and the absenceof some nodes should not affect the stored data retrieval

It is composed of four subcomponents illustrated inFigure 5 data distribution data retrieve replicamanagementand data exclusion All these components have a relationshipwith security and group management modules

Data distribution is responsible for disseminating infor-mation to remote nodes Data retrieve handles the accessrequests and locates remote data Replica management isresponsible for keeping enough active replicas to ensure theinformation availability and the data consistency Exclusiondata guarantees that when requested data will be excludedfrom all remote nodes in which it is stored

32 Processing Module Processing module is responsible forkeeping the central operation of SEMAN It is composed ofrequests management and services and components manage-ment

321 Requests Management This component is responsiblefor keeping a registration of all services requests made to themiddleware It keeps the registration of both pending andattended requests

An application is able to use simultaneously one or moreservices provided by the middleware Due to the dynamiccharacteristics of MANETs applications may not be aware of

Securitymodule

Requestsmanagement Catalog

Resourcesmanagement

Other components

Network

2 1

3

54

C1 C2 C3 Cnmiddot middot middot

Figure 6 Services requests

which services are being provided in a given time or whichnodes are hosting these services Figure 6 depicts how a ser-vice request is operated by SEMANUpon receiving a requestthe request management component gets the security param-eters with the security module Then it must check the avail-ability of the requested servicewith the resourcemanagementcomponent If the service is provided by the middleware itstores the information about the request into the catalog per-forms the required communications with other componentsand sends the request to the corresponding nodes

As services may be provided by more than one nodeSEMANmight

(1) request the service to all nodes that provide it increas-ing the service availability and reducing the replytime

(2) distribute the requests among nodes that provide itmaking a load balance or

(3) choose the more reliable node based on previousexperiences

During the service provisioning the middleware mayprovide mechanisms to prevent malicious attacks It mustauthenticate and authorize applications Also all messagesexchanged with the middleware must be ciphered to preventeavesdropping

6 Journal of Computer Networks and Communications

Security services

Trust Keys

Groups

Secu

rity

polic

ies

Cryp

togr

aphi

c cor

e

Figure 7 Security module diagram

322 Services and Components Management This compo-nent has a simple but essential function to the middlewareoperation It is responsible for keeping a registration of allservices and components provided by SEMAN When a userwants to make a service available through the middlewarethis services must be previously registered All relevant infor-mation of the new service as security policies and contextmust be stored into catalog Then other nodes can beinformed about the availability of the new service

This component must provide primitives to the registra-tion of new services as well the query of provided servicesSimilarly for each registered component it is necessaryto store information about access strategies and servicesrequirements

33 Conclusion This section presented an overview ofSEMAN its modules and main characteristics All next sec-tion will detail the security operations and module and howthey will provide security to the middleware applications

4 Security Module

This module is the central point of SEMAN Its componentsas depicted in Figure 7 include key management trust man-agement and groupmanagementThese components operatewith cryptographic operations and security policies compo-nents which provide basic security primitives to the module

Security services use a context-based group approachAll management operations and decision making are basedon information provided by other members of the contextgroup Thus nodes cooperate among themselves to increasethe reliability of available services However the use of allcomponents is not mandatory

41 Cryptographic Core To ensure that messages are notprone to eavesdropping all messages must be cipheredThough any cryptographic mechanism can be used identity-based ones seem to be more suitable for MANETs [9] Sym-metric schemes impose a high cost to manage pairwise secretkeys and when compared with traditional certificate-basedasymmetric schemes identity-based cryptography (IBC)presents at least three advantages [10]

(1) does not require certificates mitigating certificatesstorage distribution and verification cost

(2) makes easy noninteractive key agreement reducingcommunication and processing overhead

(3) removes the requirement of destination public keysauthentications before message sending

Another advantage to use IBC on MANETs is that theyhave a simple key management and a reduced storage costif compared with other methods On IBCs the identity of auser as e-mail or IP is used to derive the node public keyThus all nodes are able to disclose the public key of othernodes without data exchange However IBCs present adrawback Private key is generated and available by an entityknown as Private Key Generator (PKG) This characteristicimposes an implementation challenge since PKG can be asingle point of failure To mitigate the impact of a centralPKG in this work the PKG is distributed over the network

42 Cryptographic Operations SEMAN considers the use ofidentity-based cryptography Any IBC can be used depend-ing on middleware requirements Without loss of generalitythe Boneh and Franklin scheme is employed [11]

The main algorithms to perform cryptographic opera-tions and to support the secure communication betweennodes are composed of configuration and extraction andencryption and decryption The former two are detailed onSection 44 which discusses the key management since theyare related to system initialization and key issuing

The encryption and decryption algorithms are presentedas follows Let 119896 isin Z+ be a security parameter from securitymodule and G a generator of BDH parameter

(1) Encryption to encrypt119872 using a public key of node119894 follow the next steps

(a) calculate PK119894= 1198671(119873119894)

(b) choose a random 119903 isin Zlowast119902

(c) generate the encrypted text 119862 = ⟨119903119875119872 oplus

1198672(119892119903

119894)⟩ in which 119892

119894= (119873

119894PK119894) isin Glowast2

(2) Decryption let119862 = ⟨119880119881⟩ be the encrypted text usingthe public key of node 119894 To decrypt the message theprivate key SK

119894is necessary The following formula

shows as text may be decrypted

119881 oplus1198672( (SK

119894 119880)) = 119872 (1)

The proof of these algorithms can be found in [11]

43 Trust Management Though cryptography may be usedto ensure communication security it does not provide infor-mation about the reliability of the nodes [12] Further manycryptographic mechanisms such as keymanagement [13 14]rely on some degree of preestablished trust between nodesHowever trust in any kind of open network is very difficult tobe valued and has received a lot of attention from the securitycommunity [15]

In a previous work [16 17] TRUE was presented to eval-uate the trust between pairwise communicating nodes TRUEuses the concept of trust chains formed between nodes by

Journal of Computer Networks and Communications 7

06

06

04

06 02

01 08

08

08

05 08

07

04

03

03

02

03

nf

nb

nq

nx nw

nz nvnu

nt

nm

Figure 8 Example of trust chain 119866119909tr from node 119899119909

direct monitoring and recommendations of physical neigh-bors It supports applications in an autonomous and dynamicway while keeping the ability to resist malicious attacks Inthis approach each node creates in a self-organized strategy atrust network based on context to provide trust informationrepresented by a direct graph 119866tr = (119881tr 119864tr) in which ver-texes119881tr are the nodes and edges119864tr are the trust relationshipsbetween them The trust network or trust graph containsall trust information which a node has about other nodesin a context This information or evidences is gathered viadirect interaction or by recommendations considering thesystem security policies The trustworthiness of a node isalways locally computed with no kind of message exchangebased on the trust network In the next subsection are brieflypresented the operation of the TRUE and its procedures andan evaluation of the proposed service

431 Building Context-Based Trust Networks When joiningthe system each node119873

119894creates its own trust network 119866119894tr =

(119881119894

tr 119864119894

tr) in a self-organized way Initially nodes have knowl-edge only about nodes with which they have direct trust rela-tions and only such data is stored in the trust networkThenin predetermined time intervals (Δ119879ex) nodes exchange trustevidences with their physical neighbors propagating trustvalues through the network in an epidemic behavior [18 19]

During trust information exchange each node evaluatesthe relevance of the received evidences by calculating thetrustworthiness of the sender Then it decides whether itaccepts or not such evidences based on local policy rules If itaccepts the trust evidences then it incorporates the receivedinformation on its context-based trust network Otherwisetrust evidences are discarded

432 Trust Evaluation To evaluate the trust on node 119873119906

node 119873119909must either have a direct connection with node 119899

119906

in 119866119909tr or it finds at least one trust chain (TC) from119873119909to119873119906

in119866119909tr Trust chains represent a transitive trust from119873119909to119873119906

The trust network graph 119866119909tr is depicted in Figure 8 As node119873119909can find several different trust chains between itself and

119873119906in 119866119909tr each chain is denoted as TC119894

(119873119909119873119906)

If 119873119909has a direct trust with 119873

119906 only this value is con-

sidered on trust evaluation Otherwise it tries to find a trust

path in 119866119909

tr Upon finding a chain node 119873119909must compute

its trust Consider 1198731to 119873119898as the 119898 intermediary nodes

in the 119894th trust chain denoted as TC119894(119873119909119873119906) (2) estimates the

trustworthiness of TC119894(119873119909119873119906)

TC119894(119873119909119873119906)= TV(1198731199091198731)times

119898minus1

prod

119895=1

TV(119873119895119873119895+1)times TV(119873119898119873119906) (2)

Returning to Figure 8 there are several chains between 119899119909and

119899119906 for example

(1) chain (119873119909rarr 119873119902rarr 119873119898rarr 119873119906) trust chain value

TC1(119873119909119873119906)= 08 times 06 times 07 = 0336

(2) chain (119873119909rarr 119873119902rarr 119873119887rarr 119873119891rarr 119873119898rarr 119873119906) trust

chain value TC2(119873119909119873119906)= 08 times 03 times 05 times 08 times 07 =

0067

Furthermore nodes can use a threshold value for eachedge of the trust chain (120573 value) If at least one edge of thetrust chain has a trust value below this threshold the chain isdiscarded After calculating the trust value for all chains thetrust value TV

(119873119909119873119906)can be calculated applying a weighted

mean as follows

TV(119873119909119873119906)=

sum119896

119894=1(TC119894(119873119909119873119906)times (1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816))

sum119896

119894=1(1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816)

(3)

The weighted mean reduces the impact of transitivity intrust chains In fact the greater the chain the less reliable itisThus this method aims to privilege small chains followinga social perspective

44 KeyManagement SEMANemploys identity-based cryp-tography (IBC) [20] to perform its cryptographic operationswhich requires an entity acting as a Private Key Generator(PKG) As the PKG knows the master private key it is ableto decrypt or sign messages on behalf of any client withoutany active attack and without being detectedThis problem isknown as key escrow These issues have been considered themain drawback that leads to the low adoption of IBC outsideclosed environments [21] Boneh and Franklin suggesteddistributing the PKG to handle these problems using secretsharing schemes (119899 119905) in which 119899 nodes form a distributedPKG (D-PKG) and only a subset of 119905 + 1 nodes is able tocompute the master private key [11]

Several identity-based key management schemes havebeen designed for MANETs and most of them consider thedistribution of the PKG [9] However proposed schemes donot consider all characteristics of these networks

In a previous work [22] the Identity-based Fully SelfOrganized (119894FUSO) key management service was presentedwhich can be integrated with SEMAN The 119894FUSO considersan asynchronous network composed of 119899 nodes representedby1198731 1198732 119873

119899 in whichmalicious nodes can compromise

at most 119905 nodes and 119905 lt 119899 It considers that only trusted nodesparticipate in the system initialization Nodes which initializethe system are called founding nodes denoted by 119873F

8 Journal of Computer Networks and Communications

These nodes form the distributed PKG (D-PKG) in a fullydistributed way No node knows the master private key sinceit is distributed in 119905-over-119899 threshold scheme Also to adaptto the dynamism of the network 119894FUSO allows nodes to joinor leave the D-PKG

To prevent the system from cryptanalysis attacks the119894FUSO provides a way to update public and private keysof nodes similar to [23 24] The key update may occureither periodically according to a predetermined intervalor reactively when the number of revoked nodes reaches athreshold value Nodes are able to update their public keysautonomously and their private key by requesting to the D-PKG Further the 119894FUSO supports both implicit and explicitrevocations

441 Initialization The 119894FUSO must be initialized by a setof 119898 founding nodes (119873F) which must be able to securelyexchange information to initialize the system As the first stepof the initialization nodes must determine

(1) the system size 119899 and the security threshold 119905

(2) 119901 119902 two large prime numbers in which 119902 divides (119901minus1)

(3) G1 a cyclic additive group with order 119901

(4) a generator 119892 isin G1

(5) G2 a cyclic multiplicative group with order 119901

(6) the pairing type making sure that there exists a bilin-ear paring 119890 G

1times G1rarr G2of the chosen type

(7) G = ⟨119890G1G2⟩

This step can be performed jointly by nodes which areinitializing the group or proposed by one node to the others

To initialize the system founding nodes set up the D-PKG generating the master public key and its correspondingmaster private keyTheD-PKG is built in a distribute 119905-over-119899way among the 119899 founding nodes

442 New Members Joining the D-PKG In a MANET itis very important for a D-PKG to be highly dynamic anddecentralized and new nodes must be able to join thedistributed PKG at any timeThus these nodesmust receive ashare of MSK computed by at least 119905members of the D-PKG

If a newnode119873119896wants to join theD-PKG itmust contact

at least 119905 members of the D-PKG to get the correspondinginformation from these nodes The join of new nodes to theD-PKG must follow the following

(1) node119873119896selects 119905members of D-PKG denoted byΩ

(2) node119873119896requests each node of Ω to be accepted as a

member of the D-PKG

(3) each node 119873119895isin Ω sends a piece of information

119891(119895 119896) = 119878119896

119895back to119873

119896

(4) after receiving 119905 replies 119873119896can compute its polyno-

mial share MSK119896using a Lagrange interpolation

443 Issuing Node Private Key The 119894FUSO is composed ofa number of continuous nonoverlapping key update phasesdenoted by 119901

Δ in which Δ represents the phase index As in

[23] each 119901Δis associated with a unique binary phase string

denoted as strΔ For each 119873

119894 its public key is represented by

PK119894= 1198671(119873119894) while the corresponding private key is repre-

sented by SK119894= (PK

119894)MSK Recalling that in the 119894FUSO no

node knows MSK which is generated and stored in a fullydistributed way To retrieve its private key SK

119894 node119873

119894must

request theD-PKG for it and towait for at least 119905 repliesThusthe following steps must be executed

(1) 119873119894must select at least 119905 nodes from the D-PKG

This set of nodes is denoted by Ψ To minimize therequesting time the Ψ has all nodes of the D-PKG

(2) 119873119894requests its share of SK

119894to each node in Ψ

(3) each node119873119895isin Ψ sends back to119873

119894a share of the pri-

vate key 120590119895119894= (PK

119894)MSK119895

(4) upon receiving at least 119905 replies 119873119894computes its pri-

vate key SK119894as

SK119894= prod

119896isinΨ

(120590119896

119894)

120582119896

(4)

in which 120582119896= prod119896isinΨ

(119896(119896 minus 119894)) are appropriate La-grange coefficients

444 Key Renewing To prevent attacks against the dis-tributed PKG and potential threats resulting from compro-mised keys a technique similar to the one proposed in [23]known as key update or key renewing is employed Securitysolutions based on key update are common practices onMANETs [25ndash27] In the 119894FUSO a new key update phase119901119894+1

starts after a predetermined time threshold As all nodesmust update their keys if themembers of the distributed PKGdo not update the key of a given node 119873

119886 it is (implicitly)

considered revokedEach node 119873

119886can autonomously update its public key

PK119886119901119894

= (1198671(119873119886)1198671(str119894)) in which str

119894= str119894minus1

+ 1 On theother hand generating the phase private key involves at least119905 members of the D-PKG A given node 119873

119911 member of the

D-PKG sends a request to at least 119905 minus 1 other members of theD-PKG

445 KeyRevocation The 119894FUSOalso provides techniques toverify if the public key of a node is revoked Key revocationsmust be handled within the system as nodes must be ableto immediately verify the status of a public key [28] Almostall key management schemes for MANETs consider the keyrevocation based on expiration time [29] However this isnot sufficient since nodes must be able to revoke keys beforeexpiration as consequence of a compromise key or maliciousbehavior

Thus 119894FUSO supports both implicit and explicit revo-cations If any node is not allowed to recover the commonprivate key during a given phase 119901

119894 then it is neither able to

encrypt nor able to decrypt any information during this phaseand is considered implicitly revoked

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 5: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Journal of Computer Networks and Communications 5

Services module Processing module

Distributed storage

Datadistribution

Dataexclusion

DataretrieveReplica

management

Catalog

Groupmanagement

Security

Figure 5 Components of distributed storage component

thatmembers of a group keep their location up-to-date in thisgroup Transfer management must allow mobile applicationsto keep the connection during a migration It aims to mit-igate the delay of applications transfers and to eliminate appli-cations losses resulting from the migration Finally discon-nection management must provide information about thereachability or disconnections of nodes that provide servicesthrough SEMAN

313 Distributed Storage This component allows nodes tostore their information in a distributed secure dynamicand self-organized way It does not depend on any specificnode availability and must be highly resistant to maliciousattacks Its main objective is to distribute context informationto nodes of a group related to this context This contextinformation is fragmented into the network and the absenceof some nodes should not affect the stored data retrieval

It is composed of four subcomponents illustrated inFigure 5 data distribution data retrieve replicamanagementand data exclusion All these components have a relationshipwith security and group management modules

Data distribution is responsible for disseminating infor-mation to remote nodes Data retrieve handles the accessrequests and locates remote data Replica management isresponsible for keeping enough active replicas to ensure theinformation availability and the data consistency Exclusiondata guarantees that when requested data will be excludedfrom all remote nodes in which it is stored

32 Processing Module Processing module is responsible forkeeping the central operation of SEMAN It is composed ofrequests management and services and components manage-ment

321 Requests Management This component is responsiblefor keeping a registration of all services requests made to themiddleware It keeps the registration of both pending andattended requests

An application is able to use simultaneously one or moreservices provided by the middleware Due to the dynamiccharacteristics of MANETs applications may not be aware of

Securitymodule

Requestsmanagement Catalog

Resourcesmanagement

Other components

Network

2 1

3

54

C1 C2 C3 Cnmiddot middot middot

Figure 6 Services requests

which services are being provided in a given time or whichnodes are hosting these services Figure 6 depicts how a ser-vice request is operated by SEMANUpon receiving a requestthe request management component gets the security param-eters with the security module Then it must check the avail-ability of the requested servicewith the resourcemanagementcomponent If the service is provided by the middleware itstores the information about the request into the catalog per-forms the required communications with other componentsand sends the request to the corresponding nodes

As services may be provided by more than one nodeSEMANmight

(1) request the service to all nodes that provide it increas-ing the service availability and reducing the replytime

(2) distribute the requests among nodes that provide itmaking a load balance or

(3) choose the more reliable node based on previousexperiences

During the service provisioning the middleware mayprovide mechanisms to prevent malicious attacks It mustauthenticate and authorize applications Also all messagesexchanged with the middleware must be ciphered to preventeavesdropping

6 Journal of Computer Networks and Communications

Security services

Trust Keys

Groups

Secu

rity

polic

ies

Cryp

togr

aphi

c cor

e

Figure 7 Security module diagram

322 Services and Components Management This compo-nent has a simple but essential function to the middlewareoperation It is responsible for keeping a registration of allservices and components provided by SEMAN When a userwants to make a service available through the middlewarethis services must be previously registered All relevant infor-mation of the new service as security policies and contextmust be stored into catalog Then other nodes can beinformed about the availability of the new service

This component must provide primitives to the registra-tion of new services as well the query of provided servicesSimilarly for each registered component it is necessaryto store information about access strategies and servicesrequirements

33 Conclusion This section presented an overview ofSEMAN its modules and main characteristics All next sec-tion will detail the security operations and module and howthey will provide security to the middleware applications

4 Security Module

This module is the central point of SEMAN Its componentsas depicted in Figure 7 include key management trust man-agement and groupmanagementThese components operatewith cryptographic operations and security policies compo-nents which provide basic security primitives to the module

Security services use a context-based group approachAll management operations and decision making are basedon information provided by other members of the contextgroup Thus nodes cooperate among themselves to increasethe reliability of available services However the use of allcomponents is not mandatory

41 Cryptographic Core To ensure that messages are notprone to eavesdropping all messages must be cipheredThough any cryptographic mechanism can be used identity-based ones seem to be more suitable for MANETs [9] Sym-metric schemes impose a high cost to manage pairwise secretkeys and when compared with traditional certificate-basedasymmetric schemes identity-based cryptography (IBC)presents at least three advantages [10]

(1) does not require certificates mitigating certificatesstorage distribution and verification cost

(2) makes easy noninteractive key agreement reducingcommunication and processing overhead

(3) removes the requirement of destination public keysauthentications before message sending

Another advantage to use IBC on MANETs is that theyhave a simple key management and a reduced storage costif compared with other methods On IBCs the identity of auser as e-mail or IP is used to derive the node public keyThus all nodes are able to disclose the public key of othernodes without data exchange However IBCs present adrawback Private key is generated and available by an entityknown as Private Key Generator (PKG) This characteristicimposes an implementation challenge since PKG can be asingle point of failure To mitigate the impact of a centralPKG in this work the PKG is distributed over the network

42 Cryptographic Operations SEMAN considers the use ofidentity-based cryptography Any IBC can be used depend-ing on middleware requirements Without loss of generalitythe Boneh and Franklin scheme is employed [11]

The main algorithms to perform cryptographic opera-tions and to support the secure communication betweennodes are composed of configuration and extraction andencryption and decryption The former two are detailed onSection 44 which discusses the key management since theyare related to system initialization and key issuing

The encryption and decryption algorithms are presentedas follows Let 119896 isin Z+ be a security parameter from securitymodule and G a generator of BDH parameter

(1) Encryption to encrypt119872 using a public key of node119894 follow the next steps

(a) calculate PK119894= 1198671(119873119894)

(b) choose a random 119903 isin Zlowast119902

(c) generate the encrypted text 119862 = ⟨119903119875119872 oplus

1198672(119892119903

119894)⟩ in which 119892

119894= (119873

119894PK119894) isin Glowast2

(2) Decryption let119862 = ⟨119880119881⟩ be the encrypted text usingthe public key of node 119894 To decrypt the message theprivate key SK

119894is necessary The following formula

shows as text may be decrypted

119881 oplus1198672( (SK

119894 119880)) = 119872 (1)

The proof of these algorithms can be found in [11]

43 Trust Management Though cryptography may be usedto ensure communication security it does not provide infor-mation about the reliability of the nodes [12] Further manycryptographic mechanisms such as keymanagement [13 14]rely on some degree of preestablished trust between nodesHowever trust in any kind of open network is very difficult tobe valued and has received a lot of attention from the securitycommunity [15]

In a previous work [16 17] TRUE was presented to eval-uate the trust between pairwise communicating nodes TRUEuses the concept of trust chains formed between nodes by

Journal of Computer Networks and Communications 7

06

06

04

06 02

01 08

08

08

05 08

07

04

03

03

02

03

nf

nb

nq

nx nw

nz nvnu

nt

nm

Figure 8 Example of trust chain 119866119909tr from node 119899119909

direct monitoring and recommendations of physical neigh-bors It supports applications in an autonomous and dynamicway while keeping the ability to resist malicious attacks Inthis approach each node creates in a self-organized strategy atrust network based on context to provide trust informationrepresented by a direct graph 119866tr = (119881tr 119864tr) in which ver-texes119881tr are the nodes and edges119864tr are the trust relationshipsbetween them The trust network or trust graph containsall trust information which a node has about other nodesin a context This information or evidences is gathered viadirect interaction or by recommendations considering thesystem security policies The trustworthiness of a node isalways locally computed with no kind of message exchangebased on the trust network In the next subsection are brieflypresented the operation of the TRUE and its procedures andan evaluation of the proposed service

431 Building Context-Based Trust Networks When joiningthe system each node119873

119894creates its own trust network 119866119894tr =

(119881119894

tr 119864119894

tr) in a self-organized way Initially nodes have knowl-edge only about nodes with which they have direct trust rela-tions and only such data is stored in the trust networkThenin predetermined time intervals (Δ119879ex) nodes exchange trustevidences with their physical neighbors propagating trustvalues through the network in an epidemic behavior [18 19]

During trust information exchange each node evaluatesthe relevance of the received evidences by calculating thetrustworthiness of the sender Then it decides whether itaccepts or not such evidences based on local policy rules If itaccepts the trust evidences then it incorporates the receivedinformation on its context-based trust network Otherwisetrust evidences are discarded

432 Trust Evaluation To evaluate the trust on node 119873119906

node 119873119909must either have a direct connection with node 119899

119906

in 119866119909tr or it finds at least one trust chain (TC) from119873119909to119873119906

in119866119909tr Trust chains represent a transitive trust from119873119909to119873119906

The trust network graph 119866119909tr is depicted in Figure 8 As node119873119909can find several different trust chains between itself and

119873119906in 119866119909tr each chain is denoted as TC119894

(119873119909119873119906)

If 119873119909has a direct trust with 119873

119906 only this value is con-

sidered on trust evaluation Otherwise it tries to find a trust

path in 119866119909

tr Upon finding a chain node 119873119909must compute

its trust Consider 1198731to 119873119898as the 119898 intermediary nodes

in the 119894th trust chain denoted as TC119894(119873119909119873119906) (2) estimates the

trustworthiness of TC119894(119873119909119873119906)

TC119894(119873119909119873119906)= TV(1198731199091198731)times

119898minus1

prod

119895=1

TV(119873119895119873119895+1)times TV(119873119898119873119906) (2)

Returning to Figure 8 there are several chains between 119899119909and

119899119906 for example

(1) chain (119873119909rarr 119873119902rarr 119873119898rarr 119873119906) trust chain value

TC1(119873119909119873119906)= 08 times 06 times 07 = 0336

(2) chain (119873119909rarr 119873119902rarr 119873119887rarr 119873119891rarr 119873119898rarr 119873119906) trust

chain value TC2(119873119909119873119906)= 08 times 03 times 05 times 08 times 07 =

0067

Furthermore nodes can use a threshold value for eachedge of the trust chain (120573 value) If at least one edge of thetrust chain has a trust value below this threshold the chain isdiscarded After calculating the trust value for all chains thetrust value TV

(119873119909119873119906)can be calculated applying a weighted

mean as follows

TV(119873119909119873119906)=

sum119896

119894=1(TC119894(119873119909119873119906)times (1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816))

sum119896

119894=1(1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816)

(3)

The weighted mean reduces the impact of transitivity intrust chains In fact the greater the chain the less reliable itisThus this method aims to privilege small chains followinga social perspective

44 KeyManagement SEMANemploys identity-based cryp-tography (IBC) [20] to perform its cryptographic operationswhich requires an entity acting as a Private Key Generator(PKG) As the PKG knows the master private key it is ableto decrypt or sign messages on behalf of any client withoutany active attack and without being detectedThis problem isknown as key escrow These issues have been considered themain drawback that leads to the low adoption of IBC outsideclosed environments [21] Boneh and Franklin suggesteddistributing the PKG to handle these problems using secretsharing schemes (119899 119905) in which 119899 nodes form a distributedPKG (D-PKG) and only a subset of 119905 + 1 nodes is able tocompute the master private key [11]

Several identity-based key management schemes havebeen designed for MANETs and most of them consider thedistribution of the PKG [9] However proposed schemes donot consider all characteristics of these networks

In a previous work [22] the Identity-based Fully SelfOrganized (119894FUSO) key management service was presentedwhich can be integrated with SEMAN The 119894FUSO considersan asynchronous network composed of 119899 nodes representedby1198731 1198732 119873

119899 in whichmalicious nodes can compromise

at most 119905 nodes and 119905 lt 119899 It considers that only trusted nodesparticipate in the system initialization Nodes which initializethe system are called founding nodes denoted by 119873F

8 Journal of Computer Networks and Communications

These nodes form the distributed PKG (D-PKG) in a fullydistributed way No node knows the master private key sinceit is distributed in 119905-over-119899 threshold scheme Also to adaptto the dynamism of the network 119894FUSO allows nodes to joinor leave the D-PKG

To prevent the system from cryptanalysis attacks the119894FUSO provides a way to update public and private keysof nodes similar to [23 24] The key update may occureither periodically according to a predetermined intervalor reactively when the number of revoked nodes reaches athreshold value Nodes are able to update their public keysautonomously and their private key by requesting to the D-PKG Further the 119894FUSO supports both implicit and explicitrevocations

441 Initialization The 119894FUSO must be initialized by a setof 119898 founding nodes (119873F) which must be able to securelyexchange information to initialize the system As the first stepof the initialization nodes must determine

(1) the system size 119899 and the security threshold 119905

(2) 119901 119902 two large prime numbers in which 119902 divides (119901minus1)

(3) G1 a cyclic additive group with order 119901

(4) a generator 119892 isin G1

(5) G2 a cyclic multiplicative group with order 119901

(6) the pairing type making sure that there exists a bilin-ear paring 119890 G

1times G1rarr G2of the chosen type

(7) G = ⟨119890G1G2⟩

This step can be performed jointly by nodes which areinitializing the group or proposed by one node to the others

To initialize the system founding nodes set up the D-PKG generating the master public key and its correspondingmaster private keyTheD-PKG is built in a distribute 119905-over-119899way among the 119899 founding nodes

442 New Members Joining the D-PKG In a MANET itis very important for a D-PKG to be highly dynamic anddecentralized and new nodes must be able to join thedistributed PKG at any timeThus these nodesmust receive ashare of MSK computed by at least 119905members of the D-PKG

If a newnode119873119896wants to join theD-PKG itmust contact

at least 119905 members of the D-PKG to get the correspondinginformation from these nodes The join of new nodes to theD-PKG must follow the following

(1) node119873119896selects 119905members of D-PKG denoted byΩ

(2) node119873119896requests each node of Ω to be accepted as a

member of the D-PKG

(3) each node 119873119895isin Ω sends a piece of information

119891(119895 119896) = 119878119896

119895back to119873

119896

(4) after receiving 119905 replies 119873119896can compute its polyno-

mial share MSK119896using a Lagrange interpolation

443 Issuing Node Private Key The 119894FUSO is composed ofa number of continuous nonoverlapping key update phasesdenoted by 119901

Δ in which Δ represents the phase index As in

[23] each 119901Δis associated with a unique binary phase string

denoted as strΔ For each 119873

119894 its public key is represented by

PK119894= 1198671(119873119894) while the corresponding private key is repre-

sented by SK119894= (PK

119894)MSK Recalling that in the 119894FUSO no

node knows MSK which is generated and stored in a fullydistributed way To retrieve its private key SK

119894 node119873

119894must

request theD-PKG for it and towait for at least 119905 repliesThusthe following steps must be executed

(1) 119873119894must select at least 119905 nodes from the D-PKG

This set of nodes is denoted by Ψ To minimize therequesting time the Ψ has all nodes of the D-PKG

(2) 119873119894requests its share of SK

119894to each node in Ψ

(3) each node119873119895isin Ψ sends back to119873

119894a share of the pri-

vate key 120590119895119894= (PK

119894)MSK119895

(4) upon receiving at least 119905 replies 119873119894computes its pri-

vate key SK119894as

SK119894= prod

119896isinΨ

(120590119896

119894)

120582119896

(4)

in which 120582119896= prod119896isinΨ

(119896(119896 minus 119894)) are appropriate La-grange coefficients

444 Key Renewing To prevent attacks against the dis-tributed PKG and potential threats resulting from compro-mised keys a technique similar to the one proposed in [23]known as key update or key renewing is employed Securitysolutions based on key update are common practices onMANETs [25ndash27] In the 119894FUSO a new key update phase119901119894+1

starts after a predetermined time threshold As all nodesmust update their keys if themembers of the distributed PKGdo not update the key of a given node 119873

119886 it is (implicitly)

considered revokedEach node 119873

119886can autonomously update its public key

PK119886119901119894

= (1198671(119873119886)1198671(str119894)) in which str

119894= str119894minus1

+ 1 On theother hand generating the phase private key involves at least119905 members of the D-PKG A given node 119873

119911 member of the

D-PKG sends a request to at least 119905 minus 1 other members of theD-PKG

445 KeyRevocation The 119894FUSOalso provides techniques toverify if the public key of a node is revoked Key revocationsmust be handled within the system as nodes must be ableto immediately verify the status of a public key [28] Almostall key management schemes for MANETs consider the keyrevocation based on expiration time [29] However this isnot sufficient since nodes must be able to revoke keys beforeexpiration as consequence of a compromise key or maliciousbehavior

Thus 119894FUSO supports both implicit and explicit revo-cations If any node is not allowed to recover the commonprivate key during a given phase 119901

119894 then it is neither able to

encrypt nor able to decrypt any information during this phaseand is considered implicitly revoked

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 6: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

6 Journal of Computer Networks and Communications

Security services

Trust Keys

Groups

Secu

rity

polic

ies

Cryp

togr

aphi

c cor

e

Figure 7 Security module diagram

322 Services and Components Management This compo-nent has a simple but essential function to the middlewareoperation It is responsible for keeping a registration of allservices and components provided by SEMAN When a userwants to make a service available through the middlewarethis services must be previously registered All relevant infor-mation of the new service as security policies and contextmust be stored into catalog Then other nodes can beinformed about the availability of the new service

This component must provide primitives to the registra-tion of new services as well the query of provided servicesSimilarly for each registered component it is necessaryto store information about access strategies and servicesrequirements

33 Conclusion This section presented an overview ofSEMAN its modules and main characteristics All next sec-tion will detail the security operations and module and howthey will provide security to the middleware applications

4 Security Module

This module is the central point of SEMAN Its componentsas depicted in Figure 7 include key management trust man-agement and groupmanagementThese components operatewith cryptographic operations and security policies compo-nents which provide basic security primitives to the module

Security services use a context-based group approachAll management operations and decision making are basedon information provided by other members of the contextgroup Thus nodes cooperate among themselves to increasethe reliability of available services However the use of allcomponents is not mandatory

41 Cryptographic Core To ensure that messages are notprone to eavesdropping all messages must be cipheredThough any cryptographic mechanism can be used identity-based ones seem to be more suitable for MANETs [9] Sym-metric schemes impose a high cost to manage pairwise secretkeys and when compared with traditional certificate-basedasymmetric schemes identity-based cryptography (IBC)presents at least three advantages [10]

(1) does not require certificates mitigating certificatesstorage distribution and verification cost

(2) makes easy noninteractive key agreement reducingcommunication and processing overhead

(3) removes the requirement of destination public keysauthentications before message sending

Another advantage to use IBC on MANETs is that theyhave a simple key management and a reduced storage costif compared with other methods On IBCs the identity of auser as e-mail or IP is used to derive the node public keyThus all nodes are able to disclose the public key of othernodes without data exchange However IBCs present adrawback Private key is generated and available by an entityknown as Private Key Generator (PKG) This characteristicimposes an implementation challenge since PKG can be asingle point of failure To mitigate the impact of a centralPKG in this work the PKG is distributed over the network

42 Cryptographic Operations SEMAN considers the use ofidentity-based cryptography Any IBC can be used depend-ing on middleware requirements Without loss of generalitythe Boneh and Franklin scheme is employed [11]

The main algorithms to perform cryptographic opera-tions and to support the secure communication betweennodes are composed of configuration and extraction andencryption and decryption The former two are detailed onSection 44 which discusses the key management since theyare related to system initialization and key issuing

The encryption and decryption algorithms are presentedas follows Let 119896 isin Z+ be a security parameter from securitymodule and G a generator of BDH parameter

(1) Encryption to encrypt119872 using a public key of node119894 follow the next steps

(a) calculate PK119894= 1198671(119873119894)

(b) choose a random 119903 isin Zlowast119902

(c) generate the encrypted text 119862 = ⟨119903119875119872 oplus

1198672(119892119903

119894)⟩ in which 119892

119894= (119873

119894PK119894) isin Glowast2

(2) Decryption let119862 = ⟨119880119881⟩ be the encrypted text usingthe public key of node 119894 To decrypt the message theprivate key SK

119894is necessary The following formula

shows as text may be decrypted

119881 oplus1198672( (SK

119894 119880)) = 119872 (1)

The proof of these algorithms can be found in [11]

43 Trust Management Though cryptography may be usedto ensure communication security it does not provide infor-mation about the reliability of the nodes [12] Further manycryptographic mechanisms such as keymanagement [13 14]rely on some degree of preestablished trust between nodesHowever trust in any kind of open network is very difficult tobe valued and has received a lot of attention from the securitycommunity [15]

In a previous work [16 17] TRUE was presented to eval-uate the trust between pairwise communicating nodes TRUEuses the concept of trust chains formed between nodes by

Journal of Computer Networks and Communications 7

06

06

04

06 02

01 08

08

08

05 08

07

04

03

03

02

03

nf

nb

nq

nx nw

nz nvnu

nt

nm

Figure 8 Example of trust chain 119866119909tr from node 119899119909

direct monitoring and recommendations of physical neigh-bors It supports applications in an autonomous and dynamicway while keeping the ability to resist malicious attacks Inthis approach each node creates in a self-organized strategy atrust network based on context to provide trust informationrepresented by a direct graph 119866tr = (119881tr 119864tr) in which ver-texes119881tr are the nodes and edges119864tr are the trust relationshipsbetween them The trust network or trust graph containsall trust information which a node has about other nodesin a context This information or evidences is gathered viadirect interaction or by recommendations considering thesystem security policies The trustworthiness of a node isalways locally computed with no kind of message exchangebased on the trust network In the next subsection are brieflypresented the operation of the TRUE and its procedures andan evaluation of the proposed service

431 Building Context-Based Trust Networks When joiningthe system each node119873

119894creates its own trust network 119866119894tr =

(119881119894

tr 119864119894

tr) in a self-organized way Initially nodes have knowl-edge only about nodes with which they have direct trust rela-tions and only such data is stored in the trust networkThenin predetermined time intervals (Δ119879ex) nodes exchange trustevidences with their physical neighbors propagating trustvalues through the network in an epidemic behavior [18 19]

During trust information exchange each node evaluatesthe relevance of the received evidences by calculating thetrustworthiness of the sender Then it decides whether itaccepts or not such evidences based on local policy rules If itaccepts the trust evidences then it incorporates the receivedinformation on its context-based trust network Otherwisetrust evidences are discarded

432 Trust Evaluation To evaluate the trust on node 119873119906

node 119873119909must either have a direct connection with node 119899

119906

in 119866119909tr or it finds at least one trust chain (TC) from119873119909to119873119906

in119866119909tr Trust chains represent a transitive trust from119873119909to119873119906

The trust network graph 119866119909tr is depicted in Figure 8 As node119873119909can find several different trust chains between itself and

119873119906in 119866119909tr each chain is denoted as TC119894

(119873119909119873119906)

If 119873119909has a direct trust with 119873

119906 only this value is con-

sidered on trust evaluation Otherwise it tries to find a trust

path in 119866119909

tr Upon finding a chain node 119873119909must compute

its trust Consider 1198731to 119873119898as the 119898 intermediary nodes

in the 119894th trust chain denoted as TC119894(119873119909119873119906) (2) estimates the

trustworthiness of TC119894(119873119909119873119906)

TC119894(119873119909119873119906)= TV(1198731199091198731)times

119898minus1

prod

119895=1

TV(119873119895119873119895+1)times TV(119873119898119873119906) (2)

Returning to Figure 8 there are several chains between 119899119909and

119899119906 for example

(1) chain (119873119909rarr 119873119902rarr 119873119898rarr 119873119906) trust chain value

TC1(119873119909119873119906)= 08 times 06 times 07 = 0336

(2) chain (119873119909rarr 119873119902rarr 119873119887rarr 119873119891rarr 119873119898rarr 119873119906) trust

chain value TC2(119873119909119873119906)= 08 times 03 times 05 times 08 times 07 =

0067

Furthermore nodes can use a threshold value for eachedge of the trust chain (120573 value) If at least one edge of thetrust chain has a trust value below this threshold the chain isdiscarded After calculating the trust value for all chains thetrust value TV

(119873119909119873119906)can be calculated applying a weighted

mean as follows

TV(119873119909119873119906)=

sum119896

119894=1(TC119894(119873119909119873119906)times (1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816))

sum119896

119894=1(1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816)

(3)

The weighted mean reduces the impact of transitivity intrust chains In fact the greater the chain the less reliable itisThus this method aims to privilege small chains followinga social perspective

44 KeyManagement SEMANemploys identity-based cryp-tography (IBC) [20] to perform its cryptographic operationswhich requires an entity acting as a Private Key Generator(PKG) As the PKG knows the master private key it is ableto decrypt or sign messages on behalf of any client withoutany active attack and without being detectedThis problem isknown as key escrow These issues have been considered themain drawback that leads to the low adoption of IBC outsideclosed environments [21] Boneh and Franklin suggesteddistributing the PKG to handle these problems using secretsharing schemes (119899 119905) in which 119899 nodes form a distributedPKG (D-PKG) and only a subset of 119905 + 1 nodes is able tocompute the master private key [11]

Several identity-based key management schemes havebeen designed for MANETs and most of them consider thedistribution of the PKG [9] However proposed schemes donot consider all characteristics of these networks

In a previous work [22] the Identity-based Fully SelfOrganized (119894FUSO) key management service was presentedwhich can be integrated with SEMAN The 119894FUSO considersan asynchronous network composed of 119899 nodes representedby1198731 1198732 119873

119899 in whichmalicious nodes can compromise

at most 119905 nodes and 119905 lt 119899 It considers that only trusted nodesparticipate in the system initialization Nodes which initializethe system are called founding nodes denoted by 119873F

8 Journal of Computer Networks and Communications

These nodes form the distributed PKG (D-PKG) in a fullydistributed way No node knows the master private key sinceit is distributed in 119905-over-119899 threshold scheme Also to adaptto the dynamism of the network 119894FUSO allows nodes to joinor leave the D-PKG

To prevent the system from cryptanalysis attacks the119894FUSO provides a way to update public and private keysof nodes similar to [23 24] The key update may occureither periodically according to a predetermined intervalor reactively when the number of revoked nodes reaches athreshold value Nodes are able to update their public keysautonomously and their private key by requesting to the D-PKG Further the 119894FUSO supports both implicit and explicitrevocations

441 Initialization The 119894FUSO must be initialized by a setof 119898 founding nodes (119873F) which must be able to securelyexchange information to initialize the system As the first stepof the initialization nodes must determine

(1) the system size 119899 and the security threshold 119905

(2) 119901 119902 two large prime numbers in which 119902 divides (119901minus1)

(3) G1 a cyclic additive group with order 119901

(4) a generator 119892 isin G1

(5) G2 a cyclic multiplicative group with order 119901

(6) the pairing type making sure that there exists a bilin-ear paring 119890 G

1times G1rarr G2of the chosen type

(7) G = ⟨119890G1G2⟩

This step can be performed jointly by nodes which areinitializing the group or proposed by one node to the others

To initialize the system founding nodes set up the D-PKG generating the master public key and its correspondingmaster private keyTheD-PKG is built in a distribute 119905-over-119899way among the 119899 founding nodes

442 New Members Joining the D-PKG In a MANET itis very important for a D-PKG to be highly dynamic anddecentralized and new nodes must be able to join thedistributed PKG at any timeThus these nodesmust receive ashare of MSK computed by at least 119905members of the D-PKG

If a newnode119873119896wants to join theD-PKG itmust contact

at least 119905 members of the D-PKG to get the correspondinginformation from these nodes The join of new nodes to theD-PKG must follow the following

(1) node119873119896selects 119905members of D-PKG denoted byΩ

(2) node119873119896requests each node of Ω to be accepted as a

member of the D-PKG

(3) each node 119873119895isin Ω sends a piece of information

119891(119895 119896) = 119878119896

119895back to119873

119896

(4) after receiving 119905 replies 119873119896can compute its polyno-

mial share MSK119896using a Lagrange interpolation

443 Issuing Node Private Key The 119894FUSO is composed ofa number of continuous nonoverlapping key update phasesdenoted by 119901

Δ in which Δ represents the phase index As in

[23] each 119901Δis associated with a unique binary phase string

denoted as strΔ For each 119873

119894 its public key is represented by

PK119894= 1198671(119873119894) while the corresponding private key is repre-

sented by SK119894= (PK

119894)MSK Recalling that in the 119894FUSO no

node knows MSK which is generated and stored in a fullydistributed way To retrieve its private key SK

119894 node119873

119894must

request theD-PKG for it and towait for at least 119905 repliesThusthe following steps must be executed

(1) 119873119894must select at least 119905 nodes from the D-PKG

This set of nodes is denoted by Ψ To minimize therequesting time the Ψ has all nodes of the D-PKG

(2) 119873119894requests its share of SK

119894to each node in Ψ

(3) each node119873119895isin Ψ sends back to119873

119894a share of the pri-

vate key 120590119895119894= (PK

119894)MSK119895

(4) upon receiving at least 119905 replies 119873119894computes its pri-

vate key SK119894as

SK119894= prod

119896isinΨ

(120590119896

119894)

120582119896

(4)

in which 120582119896= prod119896isinΨ

(119896(119896 minus 119894)) are appropriate La-grange coefficients

444 Key Renewing To prevent attacks against the dis-tributed PKG and potential threats resulting from compro-mised keys a technique similar to the one proposed in [23]known as key update or key renewing is employed Securitysolutions based on key update are common practices onMANETs [25ndash27] In the 119894FUSO a new key update phase119901119894+1

starts after a predetermined time threshold As all nodesmust update their keys if themembers of the distributed PKGdo not update the key of a given node 119873

119886 it is (implicitly)

considered revokedEach node 119873

119886can autonomously update its public key

PK119886119901119894

= (1198671(119873119886)1198671(str119894)) in which str

119894= str119894minus1

+ 1 On theother hand generating the phase private key involves at least119905 members of the D-PKG A given node 119873

119911 member of the

D-PKG sends a request to at least 119905 minus 1 other members of theD-PKG

445 KeyRevocation The 119894FUSOalso provides techniques toverify if the public key of a node is revoked Key revocationsmust be handled within the system as nodes must be ableto immediately verify the status of a public key [28] Almostall key management schemes for MANETs consider the keyrevocation based on expiration time [29] However this isnot sufficient since nodes must be able to revoke keys beforeexpiration as consequence of a compromise key or maliciousbehavior

Thus 119894FUSO supports both implicit and explicit revo-cations If any node is not allowed to recover the commonprivate key during a given phase 119901

119894 then it is neither able to

encrypt nor able to decrypt any information during this phaseand is considered implicitly revoked

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 7: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Journal of Computer Networks and Communications 7

06

06

04

06 02

01 08

08

08

05 08

07

04

03

03

02

03

nf

nb

nq

nx nw

nz nvnu

nt

nm

Figure 8 Example of trust chain 119866119909tr from node 119899119909

direct monitoring and recommendations of physical neigh-bors It supports applications in an autonomous and dynamicway while keeping the ability to resist malicious attacks Inthis approach each node creates in a self-organized strategy atrust network based on context to provide trust informationrepresented by a direct graph 119866tr = (119881tr 119864tr) in which ver-texes119881tr are the nodes and edges119864tr are the trust relationshipsbetween them The trust network or trust graph containsall trust information which a node has about other nodesin a context This information or evidences is gathered viadirect interaction or by recommendations considering thesystem security policies The trustworthiness of a node isalways locally computed with no kind of message exchangebased on the trust network In the next subsection are brieflypresented the operation of the TRUE and its procedures andan evaluation of the proposed service

431 Building Context-Based Trust Networks When joiningthe system each node119873

119894creates its own trust network 119866119894tr =

(119881119894

tr 119864119894

tr) in a self-organized way Initially nodes have knowl-edge only about nodes with which they have direct trust rela-tions and only such data is stored in the trust networkThenin predetermined time intervals (Δ119879ex) nodes exchange trustevidences with their physical neighbors propagating trustvalues through the network in an epidemic behavior [18 19]

During trust information exchange each node evaluatesthe relevance of the received evidences by calculating thetrustworthiness of the sender Then it decides whether itaccepts or not such evidences based on local policy rules If itaccepts the trust evidences then it incorporates the receivedinformation on its context-based trust network Otherwisetrust evidences are discarded

432 Trust Evaluation To evaluate the trust on node 119873119906

node 119873119909must either have a direct connection with node 119899

119906

in 119866119909tr or it finds at least one trust chain (TC) from119873119909to119873119906

in119866119909tr Trust chains represent a transitive trust from119873119909to119873119906

The trust network graph 119866119909tr is depicted in Figure 8 As node119873119909can find several different trust chains between itself and

119873119906in 119866119909tr each chain is denoted as TC119894

(119873119909119873119906)

If 119873119909has a direct trust with 119873

119906 only this value is con-

sidered on trust evaluation Otherwise it tries to find a trust

path in 119866119909

tr Upon finding a chain node 119873119909must compute

its trust Consider 1198731to 119873119898as the 119898 intermediary nodes

in the 119894th trust chain denoted as TC119894(119873119909119873119906) (2) estimates the

trustworthiness of TC119894(119873119909119873119906)

TC119894(119873119909119873119906)= TV(1198731199091198731)times

119898minus1

prod

119895=1

TV(119873119895119873119895+1)times TV(119873119898119873119906) (2)

Returning to Figure 8 there are several chains between 119899119909and

119899119906 for example

(1) chain (119873119909rarr 119873119902rarr 119873119898rarr 119873119906) trust chain value

TC1(119873119909119873119906)= 08 times 06 times 07 = 0336

(2) chain (119873119909rarr 119873119902rarr 119873119887rarr 119873119891rarr 119873119898rarr 119873119906) trust

chain value TC2(119873119909119873119906)= 08 times 03 times 05 times 08 times 07 =

0067

Furthermore nodes can use a threshold value for eachedge of the trust chain (120573 value) If at least one edge of thetrust chain has a trust value below this threshold the chain isdiscarded After calculating the trust value for all chains thetrust value TV

(119873119909119873119906)can be calculated applying a weighted

mean as follows

TV(119873119909119873119906)=

sum119896

119894=1(TC119894(119873119909119873119906)times (1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816))

sum119896

119894=1(1

10038161003816100381610038161003816TC119894(119873119909119873119906)

10038161003816100381610038161003816)

(3)

The weighted mean reduces the impact of transitivity intrust chains In fact the greater the chain the less reliable itisThus this method aims to privilege small chains followinga social perspective

44 KeyManagement SEMANemploys identity-based cryp-tography (IBC) [20] to perform its cryptographic operationswhich requires an entity acting as a Private Key Generator(PKG) As the PKG knows the master private key it is ableto decrypt or sign messages on behalf of any client withoutany active attack and without being detectedThis problem isknown as key escrow These issues have been considered themain drawback that leads to the low adoption of IBC outsideclosed environments [21] Boneh and Franklin suggesteddistributing the PKG to handle these problems using secretsharing schemes (119899 119905) in which 119899 nodes form a distributedPKG (D-PKG) and only a subset of 119905 + 1 nodes is able tocompute the master private key [11]

Several identity-based key management schemes havebeen designed for MANETs and most of them consider thedistribution of the PKG [9] However proposed schemes donot consider all characteristics of these networks

In a previous work [22] the Identity-based Fully SelfOrganized (119894FUSO) key management service was presentedwhich can be integrated with SEMAN The 119894FUSO considersan asynchronous network composed of 119899 nodes representedby1198731 1198732 119873

119899 in whichmalicious nodes can compromise

at most 119905 nodes and 119905 lt 119899 It considers that only trusted nodesparticipate in the system initialization Nodes which initializethe system are called founding nodes denoted by 119873F

8 Journal of Computer Networks and Communications

These nodes form the distributed PKG (D-PKG) in a fullydistributed way No node knows the master private key sinceit is distributed in 119905-over-119899 threshold scheme Also to adaptto the dynamism of the network 119894FUSO allows nodes to joinor leave the D-PKG

To prevent the system from cryptanalysis attacks the119894FUSO provides a way to update public and private keysof nodes similar to [23 24] The key update may occureither periodically according to a predetermined intervalor reactively when the number of revoked nodes reaches athreshold value Nodes are able to update their public keysautonomously and their private key by requesting to the D-PKG Further the 119894FUSO supports both implicit and explicitrevocations

441 Initialization The 119894FUSO must be initialized by a setof 119898 founding nodes (119873F) which must be able to securelyexchange information to initialize the system As the first stepof the initialization nodes must determine

(1) the system size 119899 and the security threshold 119905

(2) 119901 119902 two large prime numbers in which 119902 divides (119901minus1)

(3) G1 a cyclic additive group with order 119901

(4) a generator 119892 isin G1

(5) G2 a cyclic multiplicative group with order 119901

(6) the pairing type making sure that there exists a bilin-ear paring 119890 G

1times G1rarr G2of the chosen type

(7) G = ⟨119890G1G2⟩

This step can be performed jointly by nodes which areinitializing the group or proposed by one node to the others

To initialize the system founding nodes set up the D-PKG generating the master public key and its correspondingmaster private keyTheD-PKG is built in a distribute 119905-over-119899way among the 119899 founding nodes

442 New Members Joining the D-PKG In a MANET itis very important for a D-PKG to be highly dynamic anddecentralized and new nodes must be able to join thedistributed PKG at any timeThus these nodesmust receive ashare of MSK computed by at least 119905members of the D-PKG

If a newnode119873119896wants to join theD-PKG itmust contact

at least 119905 members of the D-PKG to get the correspondinginformation from these nodes The join of new nodes to theD-PKG must follow the following

(1) node119873119896selects 119905members of D-PKG denoted byΩ

(2) node119873119896requests each node of Ω to be accepted as a

member of the D-PKG

(3) each node 119873119895isin Ω sends a piece of information

119891(119895 119896) = 119878119896

119895back to119873

119896

(4) after receiving 119905 replies 119873119896can compute its polyno-

mial share MSK119896using a Lagrange interpolation

443 Issuing Node Private Key The 119894FUSO is composed ofa number of continuous nonoverlapping key update phasesdenoted by 119901

Δ in which Δ represents the phase index As in

[23] each 119901Δis associated with a unique binary phase string

denoted as strΔ For each 119873

119894 its public key is represented by

PK119894= 1198671(119873119894) while the corresponding private key is repre-

sented by SK119894= (PK

119894)MSK Recalling that in the 119894FUSO no

node knows MSK which is generated and stored in a fullydistributed way To retrieve its private key SK

119894 node119873

119894must

request theD-PKG for it and towait for at least 119905 repliesThusthe following steps must be executed

(1) 119873119894must select at least 119905 nodes from the D-PKG

This set of nodes is denoted by Ψ To minimize therequesting time the Ψ has all nodes of the D-PKG

(2) 119873119894requests its share of SK

119894to each node in Ψ

(3) each node119873119895isin Ψ sends back to119873

119894a share of the pri-

vate key 120590119895119894= (PK

119894)MSK119895

(4) upon receiving at least 119905 replies 119873119894computes its pri-

vate key SK119894as

SK119894= prod

119896isinΨ

(120590119896

119894)

120582119896

(4)

in which 120582119896= prod119896isinΨ

(119896(119896 minus 119894)) are appropriate La-grange coefficients

444 Key Renewing To prevent attacks against the dis-tributed PKG and potential threats resulting from compro-mised keys a technique similar to the one proposed in [23]known as key update or key renewing is employed Securitysolutions based on key update are common practices onMANETs [25ndash27] In the 119894FUSO a new key update phase119901119894+1

starts after a predetermined time threshold As all nodesmust update their keys if themembers of the distributed PKGdo not update the key of a given node 119873

119886 it is (implicitly)

considered revokedEach node 119873

119886can autonomously update its public key

PK119886119901119894

= (1198671(119873119886)1198671(str119894)) in which str

119894= str119894minus1

+ 1 On theother hand generating the phase private key involves at least119905 members of the D-PKG A given node 119873

119911 member of the

D-PKG sends a request to at least 119905 minus 1 other members of theD-PKG

445 KeyRevocation The 119894FUSOalso provides techniques toverify if the public key of a node is revoked Key revocationsmust be handled within the system as nodes must be ableto immediately verify the status of a public key [28] Almostall key management schemes for MANETs consider the keyrevocation based on expiration time [29] However this isnot sufficient since nodes must be able to revoke keys beforeexpiration as consequence of a compromise key or maliciousbehavior

Thus 119894FUSO supports both implicit and explicit revo-cations If any node is not allowed to recover the commonprivate key during a given phase 119901

119894 then it is neither able to

encrypt nor able to decrypt any information during this phaseand is considered implicitly revoked

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 8: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

8 Journal of Computer Networks and Communications

These nodes form the distributed PKG (D-PKG) in a fullydistributed way No node knows the master private key sinceit is distributed in 119905-over-119899 threshold scheme Also to adaptto the dynamism of the network 119894FUSO allows nodes to joinor leave the D-PKG

To prevent the system from cryptanalysis attacks the119894FUSO provides a way to update public and private keysof nodes similar to [23 24] The key update may occureither periodically according to a predetermined intervalor reactively when the number of revoked nodes reaches athreshold value Nodes are able to update their public keysautonomously and their private key by requesting to the D-PKG Further the 119894FUSO supports both implicit and explicitrevocations

441 Initialization The 119894FUSO must be initialized by a setof 119898 founding nodes (119873F) which must be able to securelyexchange information to initialize the system As the first stepof the initialization nodes must determine

(1) the system size 119899 and the security threshold 119905

(2) 119901 119902 two large prime numbers in which 119902 divides (119901minus1)

(3) G1 a cyclic additive group with order 119901

(4) a generator 119892 isin G1

(5) G2 a cyclic multiplicative group with order 119901

(6) the pairing type making sure that there exists a bilin-ear paring 119890 G

1times G1rarr G2of the chosen type

(7) G = ⟨119890G1G2⟩

This step can be performed jointly by nodes which areinitializing the group or proposed by one node to the others

To initialize the system founding nodes set up the D-PKG generating the master public key and its correspondingmaster private keyTheD-PKG is built in a distribute 119905-over-119899way among the 119899 founding nodes

442 New Members Joining the D-PKG In a MANET itis very important for a D-PKG to be highly dynamic anddecentralized and new nodes must be able to join thedistributed PKG at any timeThus these nodesmust receive ashare of MSK computed by at least 119905members of the D-PKG

If a newnode119873119896wants to join theD-PKG itmust contact

at least 119905 members of the D-PKG to get the correspondinginformation from these nodes The join of new nodes to theD-PKG must follow the following

(1) node119873119896selects 119905members of D-PKG denoted byΩ

(2) node119873119896requests each node of Ω to be accepted as a

member of the D-PKG

(3) each node 119873119895isin Ω sends a piece of information

119891(119895 119896) = 119878119896

119895back to119873

119896

(4) after receiving 119905 replies 119873119896can compute its polyno-

mial share MSK119896using a Lagrange interpolation

443 Issuing Node Private Key The 119894FUSO is composed ofa number of continuous nonoverlapping key update phasesdenoted by 119901

Δ in which Δ represents the phase index As in

[23] each 119901Δis associated with a unique binary phase string

denoted as strΔ For each 119873

119894 its public key is represented by

PK119894= 1198671(119873119894) while the corresponding private key is repre-

sented by SK119894= (PK

119894)MSK Recalling that in the 119894FUSO no

node knows MSK which is generated and stored in a fullydistributed way To retrieve its private key SK

119894 node119873

119894must

request theD-PKG for it and towait for at least 119905 repliesThusthe following steps must be executed

(1) 119873119894must select at least 119905 nodes from the D-PKG

This set of nodes is denoted by Ψ To minimize therequesting time the Ψ has all nodes of the D-PKG

(2) 119873119894requests its share of SK

119894to each node in Ψ

(3) each node119873119895isin Ψ sends back to119873

119894a share of the pri-

vate key 120590119895119894= (PK

119894)MSK119895

(4) upon receiving at least 119905 replies 119873119894computes its pri-

vate key SK119894as

SK119894= prod

119896isinΨ

(120590119896

119894)

120582119896

(4)

in which 120582119896= prod119896isinΨ

(119896(119896 minus 119894)) are appropriate La-grange coefficients

444 Key Renewing To prevent attacks against the dis-tributed PKG and potential threats resulting from compro-mised keys a technique similar to the one proposed in [23]known as key update or key renewing is employed Securitysolutions based on key update are common practices onMANETs [25ndash27] In the 119894FUSO a new key update phase119901119894+1

starts after a predetermined time threshold As all nodesmust update their keys if themembers of the distributed PKGdo not update the key of a given node 119873

119886 it is (implicitly)

considered revokedEach node 119873

119886can autonomously update its public key

PK119886119901119894

= (1198671(119873119886)1198671(str119894)) in which str

119894= str119894minus1

+ 1 On theother hand generating the phase private key involves at least119905 members of the D-PKG A given node 119873

119911 member of the

D-PKG sends a request to at least 119905 minus 1 other members of theD-PKG

445 KeyRevocation The 119894FUSOalso provides techniques toverify if the public key of a node is revoked Key revocationsmust be handled within the system as nodes must be ableto immediately verify the status of a public key [28] Almostall key management schemes for MANETs consider the keyrevocation based on expiration time [29] However this isnot sufficient since nodes must be able to revoke keys beforeexpiration as consequence of a compromise key or maliciousbehavior

Thus 119894FUSO supports both implicit and explicit revo-cations If any node is not allowed to recover the commonprivate key during a given phase 119901

119894 then it is neither able to

encrypt nor able to decrypt any information during this phaseand is considered implicitly revoked

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 9: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Journal of Computer Networks and Communications 9

On the other hand the explicit revocation of the 119894FUSO isbased on a list of revoked nodes stored by nodes themselvesUpon detecting the misbehavior of node 119873

119886 node 119873

119887gen-

erates a signed accusationmessage against119873119886 whichmust be

sent to theD-PKGTo avoid the interception of the accusationmessage it is sent via broadcast encryption This techniquebesides decreasing the communication cost of revocationincreases the security since the malicious nodes are not ableto read the accusation message

Upon receiving an accusation message against 119873119886from

119873119887 a member of the D-PKG will drop it if119873

119887has been pre-

viously revoked Otherwise it saves the accusation messageTo prevent false accusations against legitimate nodes a node119873119886is diagnosed as compromised just when the accusations

against it reach a revocation threshold 120574 in a predeterminedtime windowThe value of 120574 defines the trade-off between thefalse accusations tolerance and the compromise detectabilityOnce the revocation threshold is reached a key revocationagainst node119873

119886is generated and published

45 GroupManagement This section presents how the groupmanagement must be carried out to support the activitiesof SEMAN It this paper a group is a set of nodes sharingcommon interests and willing to cooperate on activitiesrelated to this interest This ldquocommon interestrdquo is also calledcontext Context information must be frequently updatedand made available to other nodes to allow the efficientorganization of groups [30]

Due to several varieties of services provided by a mid-dleware many kind of distinct groups may be formed withdifferent mobility pattern lifetime organization strategiesinternal politics and joining rules characteristics Howeverindependent of group characteristics system must provideresources management to allow the creation and update ofexisting groups and their profiles

To support several kinds of applications with strong andlight security restrictions two groupmanagement techniquesare used yellow pages and closed groups Yellow pages groupsor open groups provide primitives allowing nodes to freelyform groups and to avail services related to its context Asthese groups are open they do not consider the trustworthi-ness of their members Thus these groups are indicated toservices that require a lower trust level or when applicationsthemselves are responsible for this task

Closed groups use trustmanagement information at theirformationThus all services provided bymembers of a closedcontext group obey the preestablished security require-ments Also both internal and external group secure com-munication are allowed

451 Storage Information about Existing Groups In SEMANcontext groups are considered services available in the net-work Information about the existence of groups and theirmain features must be available to nodes that want to partic-ipate in these groups or to enjoy services provided by themTo this end it is important that themiddleware provides waysto manage this information and make it available during itsoperations Many architectures were proposed to organizethe service provisioning on MANETs An initial study about

these architectures can be found in [31] Solutions can beclassified into with directories and without directories

In the first approach information about groups is storedin a directory which can be centralized or distributed Nodeswhich store information about directories are called servernodes Every time a node wants to provide a data it finds outsome server node and requests the storage of this data Onthe other hand a node that wants to use this data needs onlyto contact a server node and gets a list of nodes which areproviding it

In the second approach information about groups is notstored in a directory and must be propagated or requestedwhen needed Thus when a node wants to provide a servicein the network it diffuses this information in order to reachthe higher number of nodes It can be employed by global orcontrolled flooding techniques When a node wants to usea service and it does not have local information about thisservice it requests such an information in the network viaglobal or controlled flooding

There is not a consensus about which strategy is moresuitable for MANETs Group discovery is considered goodwhen presenting a high availability keeping a low communi-cation cost and small delaysThus if the network has just fewservice requirements a strategy without directories with ondemand queries would be more suitable On the other handa network with many services but with few queries wouldgenerate unnecessary communications to keep informationabout these services

Any one of these architectures may be used on SEMANIn this work the use of a fully distributed directories archi-tecture is considered When a new group is created its infor-mation is disseminated in the network All nodes locally storeinformation about groups Thus every time a node needsinformation about a group itmay get it locally without delaysor additional costs

452 Yellow Pages The first group formation strategy in theSEMAN is called yellow pages This technique based in thetraditional yellow pages works as a directory of services fullyopen and dynamic Group formation is directly related tosome kind of provided serviceWhen a nodewants to providea service it informs the middleware which propagates thisinformation to all other nodes to make them aware of thenew service

When another node wants to use a service it requeststo the middleware a list of nodes which are providing theservice Based on this list the node may request or not theservice considering information from the trust managementmodule

This kind of approach is important in providing serviceswithout a high level of security Any node can freely partic-ipate in a group and provide a given service Client appli-cations can therefore determinate the trust level they wantin a service Thus the middleware based on informationprovided by the trust management module can select themore trustworthy nodes which are providing the service

Formation of anOpenGroup Before initiating a group a nodeneeds to certify that there is no other group with the same

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 10: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

10 Journal of Computer Networks and Communications

characteristics of the new one To this it queries its localdirectory If the group already exists the node joins this group(Section 452) Otherwise it creates the new group

When a node wants to form a new context group itdefines all main features of this group as identifier mobilitypattern context information service provided and initialnodes Other informationmay be included tomake the groupmanagement easier Then it disseminates this informationthrough the network as discussed in Section 451

Joining and Leaving an Open Group When a node wantsto participate in an open group 119866

120572 it needs to create a

message informing that it is providing the same services asdescribed in the group 119866

120572profile Then it must disseminate

this information through the network in order that all nodesbe aware that it is providing such services Note that thereis no strategy to block the participation of nodes on opengroups Any node may send a message informing that it isparticipating in this group

Similarly when a node wants to leave a group it justcreates a message informing that it is leaving the group anddisseminates this information through the network How-ever as this message is not mandatory or nodes may leaveunpredictably and involuntary the network is necessarysome technique are necessary to ensure the consistency ofnodes participating in a group Thus the node which hascreated the group or the older one periodically performsqueries to members checking their availability So at theend of a cycle a list of available nodes is disseminated intonetwork It is important that checking interval be not so smallin order to prevent a high communication overhead

Using Secure Services of Open Groups Open groups do notprovide native secure communication methods betweenmembers or to service requests As nodes are able to freelyjoin groups the group key establishment is difficult But thisdoes not block that services provided by open groups requireciphered and signed message requests

When a node wants to request any service to membersof an open group it makes a request directly to these nodesby using either unicast or multicast messages If it wants touse cipheredmessages it may use the security primitives pro-vided by the middleware for communication between nodessupported by cryptographic operations and key managementcomponents

453 Closed Groups While some services may be supportedby an open groupmanagement scheme other services requirea more controlled management In this case the middlewareprovides a dynamic closed group management service toapplications These groups are formed based on applicationscontext interest and security requirements

An example of closed groups is the key managementdescribed in Section 44 and in [22] which requires a hightrustworthy and restrict service This section describes theclosed group management operations as group formationnew members joining and leaving

Closed Group Formation As previously assumed groups areformed based on applications context Each node is able toautonomously promote the formation of a group without acentral entity or a group manager During the group for-mation the creator node must only specify the group profileand security requirements

A groupmay be composed of a set of nodes with a uniqueassumption these nodes must be able to securely exchangeinformation to initialize the group Then to start a groupnodes must determinate

(1) group size 119899 and the security threshold 119905(2) 119901 and 119902 two large prime numbers in which 119902 divides

(119901 minus 1)(3) G1 a cyclic additive group of order 119901

(4) generator 119892 isin G1

(5) G2 a cyclic multiplicative group of order 119901

(6) the paring type to ensure that exists a bilinear paring119890 G1times G1rarr G2to the choose paring

(7) G = ⟨119890G1G2⟩

These values must be defined by all nodes through anagreement approach or may be proposed by a founder nodeto the other ones After that each founder node must havethe following public elements

(1) prime numbers 119901 and 119902(2) generator 119892 and cyclic additive group G

1

(3) cyclic multiplicative group G2

(4) Zlowast119902 an elliptic field with order 119902

(5) 1198671(119909) a hash function in which 119867

1(119909) = 0 1

lowastrarr

Glowast1

(6) 1198672(119909) a hash function in which119867

2(119909) = G

2rarr Zlowast119901

To initialize the group nodes must generate a publicidentification of this group and a signature This signatureis distributed between group members by using a thresholdcryptographic scheme (119898 119905) among the119898 founder nodes asfollows

(1) Each node 119873119894chooses a bivariate symmetric poly-

nomial function 119891119894(119909 119910) over Zlowast

119902in which the two

variables 119909 and 119910 must be at most order 119905 Thepolynomial function is described as

119891119894(119909 119910) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119910119895 (5)

in which 119886119894119896119895isin Zlowast119902 119886119894119896119895= 119886119894

119895119896 and 119886119894

00= 119911119894

(2) Each119873119894computes 119891119894

119897(119909) for all119873

119897founder nodes as

119891119894

119897(119909) = 119891

119894(119909 119897) =

119905

sum

119896=0

119905

sum

119895=0

119886119894

119896119895119909119896119897119895 (6)

Then119873119894securely sends 119891119894

119897(119909) to119873

119897

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 11: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Journal of Computer Networks and Communications 11

(3) Each node 119873119894computes its share of the signature

Sign119894

Sign119894= 119891119894(119909) =

119899

sum

119895=1

119891119895

119894(119909) =

119899

sum

119895=1

119891119895(119909 119894) = 119891 (119909 119894) (7)

(4) Signature Sign is not known by any node but isdefined as

Sign = sum

119873119894isin119898

Sign119894mod 119902 (8)

Each node 119873119894 after computing its share Sign

119894 publishes

119892Sign119894 When nodes receive 119905 shares they are able to compute

the group identity as ID = sum119905

119894=1119892Sign119894 Then the group iden-

tity ID can be published to all other nodesAfter group formation nodes which want to collaborate

in a specific context or interest must search a group andrequest its participation in this group As each group is setwith its profile and security requirements nodes themselvesmay decide whether available groups attend their own inter-ests

Joining As describe in Section 453 each closed group has itsprofile and requirementsThus nodes themselvesmay decideon participating or not of a group If a node119873

119909wants to join

a group 119866120572it must request to 119866

120572members the participation

authorization To be able to join119866120572119873119909needs the approval of

at least 119905members The following steps must be performed

(1) node119873119909chooses 119905 nodes of group 119866

120572 denoted by Ω

(2) node 119873119909requests each node of Ω to be accepted as

member of group 119866120572

(3) each node119873119895isin Ω sends an information share 119891(119895 119896)

back to node119873119896

(4) upon receiving 119905 replies119873119909may compute its polyno-

mial share Sign119909by using Lagrange interpolation

Sign119896= 119878119896(119909) =

119905

sum

119895=1

120582119895119878119896

119895=

119905

sum

119895=1

120582119895119891 (119895 119896) = 119891 (119909 119896) (9)

After computing Sign119909 119873119909is able to participate in all

group operations

Members Exclusion When a node does not attend anymorethe security or trust requirement of a group it must have itsparticipation revoked To this signed accusationmessages areemployed with a list of revoked associations When a givennode119873

119909has a number of accusations higher than a threshold

120574 it has its association revoked The value of 120574 is a groupparameter defined on its creation profile

When a node119873119886 based on information provided by trust

management believes that 119873119909does not satisfy anymore the

group requirements it issues a signed accusation messageand sends it to all other group members To thwart excludednodes from receiving this message the signed accusationmessage must be unknown by them Thus a variant of

the identity-based broadcast encryption proposed on [32] isused

Let E be the set of excluded nodes then node 119873119886gen-

erates the parameters for the broadcast encryption

(1) forall119894 isin N E computes PK119894= 1198671(119873119894)

(2) it randomly selects 119903 isin Zlowast119901and forall119894 isin N E computes

119904119894= 1198672((PK119903

119894MPK))

(3) it randomly selects 119896 isin Zlowast119901and computes a message

encrypting key119870 = (119892 119892)119896

(4) it randomly selects 120572 isin Zlowast119901

(5) it computes Hdr = (1198621 1198622 1198623) in which

1198621= 119892119903

1198622= (119892120572)119896

1198623= 119888119894= (1198921minus1120572

)

1119904119894

119873119894isinNE

(10)

After that 119873119886has the key 119870 and Hdr and uses 119870 to

encrypt the accusationmessage119870 generating119862119870 Finally119873

119911

broadcasts the ciphered message (Hdr 119862119870)

When a nonrevoked node 119873119887receives this message it is

able to retrieve the accusation message119870 encapsulated in theheader Hdr using its private key SK

119887 as follows

(1) computes 119904119894= 1198672((SK

119887 1198621))

(2) retrieves 119888119894from 119862

3and computes

(119862minus1

2 119888119904119894

119894) times (119892 119862

2)

= (((119892120572)119896

)

minus1

((1198921minus1120572

)

1119904119894

)

119904119894

) times 119892 (119892120572)119896

= (119892 119892)minus119896(120572minus1)

times (119892 119892)119896120572

= 119870

(11)

With119870 node119873119887is able to decrypt the encryptedmessage

119862119870 extracting the accusation message 119870 Upon receiving

120574 accusations each node creates an association revocationregister and stores it locally in a revoked associations listThislist may be made publicly available to all nodes in order thatexternal member be aware that119873

119909is no longer authorized to

provide service in name of the group

46 Conclusion This section presented the security moduleand its components Cryptographic operations trust man-agement group management and key management compo-nents were detailed Also how these components will ensuresecurity to the middleware was explained

5 Secure Group Communication

To allow secure group communication the use of a groupkey agreement protocol is proposed This kind of protocolallows that a group of users exchange information over aninsecure and public communication channel and agree on asecret key to be used to derive a session keyThen the session

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 12: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

12 Journal of Computer Networks and Communications

key can be used to ensure requirements as authenticationconfidentiality and integrity

The group key agreement approach is attractive todynamic networks since it does not require the presenceof a central controller or a leader In this case all usersgenerate the key sessionThus no node is able to control or topredict the session keyThis kind of approach has beenwidelyemployed in distributed and collaborative applications asfile sharing distributed computing and audio and videoconferences among others

Several proposals to session group key establishment canbe found in the literature [33ndash35] Any scheme that makesuse of identity-based approachmay be easily employed in theSEMANWithout the loss of generality the scheme proposedby Zhang et al in [35] is assumed An advantage of thisscheme is that it allows outside group nodes to send cipheredmessages to group members This makes the secure servicerequest to closed groups easier

In the key agreement members of a group 119866120572issue

signed messages The union of all signed messages issuedby them form a group encryption key called GEK

120572 which

may be public However only members of the group are ableto derive the group decryption key GDK

120572 The next subsec-

tions present the key agreement operations and the groupencryption and decryption key generation

51 Agreement Agiven node119873119894 with the private key SK

119894and

member of group 119866120572 must perform the following steps to

carry out the key agreement(1) to choose a random number 120578

119894isin Zlowast119902

(2) to compute 119903119894= 119892120578119894

(3) to choose a random number 119896 isin Zlowast119902

(4) to compute 1198921= 119892119896

(5) for all 1 le 119895 le 119899 to compute 119891119895= 1198672(119873119895) in which

1198672(119909) is a hash function

(6) for all 1 le 119895 le 119899 to compute 119911119894119895= SK119894119891120578119894

119895

(7) to publish 120590119894= (119903119894 984858119894 119911119894119895119895isin1119899119895 =119894

)In this case 984858

119894is the identity-based signature on value 119903

119894

Element 119911119894119895= SK119894119891120578119894

119895is not published but kept secret by node

119899119894

52 Encryption Key Generation and Use To get a groupencryption key a node firstly checks the 119899 tuple of signaturemessage (119903

1 9848581) (119903

119899 984858119899) If all signatures are valid then it

computes

119908 =

119899

prod

119894=1

119903119894

119876 = (

119899

prod

119894=1

1198671(119873119894) 1198921)

(12)

Then it sets the group encryption key as GEK = (119908119876)To encrypt a message 119872 any node member or not of thegroup generates a ciphered text as follows

(1) selects 120588 isin Zlowast119902

(2) computes 1198881= 119892120588 1198882= 119908120588 and 119888

3= 119872 oplus119867

3(119876120588)

(3) generates the ciphered text 119888 = (1198881 1198882 1198883)

After the ciphered text 119888 generation it can be sent throughthe network and only members of destination group are ableto decrypt the transmitted message

53 Decryption Key Generation and Use Each node 119873119894

checks the 119899 tuples of signed messages (1199031 9848581) (119903

119899 984858119899) If

all signatures are valid node 119873119894computes GDK = prod

119899

119895=1119911119895119894

and makes the following verification

(GDK119894 119892)

= (119891119894 119908) sdot 119876 (13)

If the equation is correct node 119873119894accepts the key GDK as

decryption group key Otherwise it aborts the procedureWhen a node 119873

119894 member of group receives a ciphered

message 119888 = (1198881 1198882 1198883) it uses the decryption key GDK as

119872 = 1198883oplus 1198673( (GDK 119888

1) (119891minus1

119894 1198882)) (14)

54 Conclusion This section presented how to provide asecure group communication through SEMAN How nodesmay use cryptographic services to make an agreement andprovide secure group communication to applications wasdiscussed

6 Components Integration inDifferent Scenarios

Policy management component is responsible for supportingthe security module integrating the trust key and groupmanagement components Thus the development of strate-gies is fundamental to provide security in several scenariosin which applications may be provided by SEMAN

This section discusses some cases which show how themiddleware may be used in different scenarios Securityparameters described to each scenario are configured onthe security policy component part of the security moduleIt is important to point out that several scenarios can befound in a unique network Some applications may be bettersuitable to open scenarios while other ones require a morerigorous security control SEMAN allows the configurationof these different scenarios since applications and nodes areorganized into context with profiles and security parameterset according to provided services

Three scenarios are presented

(i) open indicated to applications which do not require ahigh security control

(ii) partially restrict indicated to applications whichrequire an intermediary security support but do notrequire a rigid control on their operations

(iii) restrict indicated to applications which require a highsecurity level on their operations

To each presented scenario distinct security policiesare indicated Table 1 illustrates how security components

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 13: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Journal of Computer Networks and Communications 13

Table 1 Security policies for distinct scenarios

Trust Key Groups

RestrictBlock evidenceexchanges withnonreliable nodes

Allow the service to be provided to each distinctgroup119905 value greater than 1198992

Prioritize closed group creationTrust restriction to group joining

Partiallyrestrict

Trust values of 120572and 120573 between 04and 06

A unique system to all the middleware119905 value greater than 1198992

Prioritize closed group creationAllow the service providing in closed groups

Open Trust values of 120572and 120573 less than 04

A unique system to all the middlewareSmall 119905 valueGreat interval between updates

Most part of provided services in open groups

may be set to proposed scenarios However these scenariosparameters and politics are not static and new environmentsand configurations may be proposed and configured by mid-dleware users

Next subsections detail these scenarios and how securitycomponents may be integrated in the service provisioningto applications Each scenario discusses how SEMAN canensure the desired security and the communication overheadimposed by it However the measurement of this kindof overhead is a complex task since these values dependon several factors group size update interval thresholdvalues and others Then a more realist approximation of theoverhead is a future work

61 Open Scenarios A first scenario that SEMAN may beemployed is an open environment which requires a lessrigorous security control Several applications may provideservices in an open scenario An example is the data andfile distributed storage service In this case users may sharefor a while data or files that do not require a high level ofconfidentiality and availability as video or audio files

(1) Trust management adopting TRUE values of 120572 and120573 may be small less than 04 Then middleware willconsidermore nodes reliable on evaluated context Asa consequencemore nodeswill be considered reliableto provide services in this context

(2) Key management using 119894FUSO values of 119905 may alsobe small less than 1198982 in which 119898 is the membersof D-PKG Also update interval may be high Thensystem overhead is reduced while the service isoffered to users considering the defined parameters

(3) Group management in open scenarios services maybe provided in open groups and users themselves canquery the trust management component to decide bythe use or not of the offered services

Note that in this scenario a unique great group may beused to the key management of the entire middleware Thenall applications which need cryptographic services use thesame service

To all other services provided in the network the trustmanagement may provide trust information on the contextof these services For example a resource localization servicehave a different context than a distributed storage Nodes

Applications Data sharing

Other applications

SEMANTrust Group

Processingand services

module

Secu

rity

mod

ule

ContextSharing

ContextkeyManagement

Type OpenSharing

Type OpenKeyManagement

System 1

Type GlobalKey

120572 120573 lt 04

120572 120573 lt 04

Figure 9 Open scenario

which provide these services may be organized into opengroups but their users may use trust values to choose the bestservers to their requirements

Figure 9 illustrates a possible configuration of the secu-rity module to satisfy applications in an open scenario Inthis case the ldquodata sharingrdquo application requests servicesto the middleware Services and processing modules replyapplication requests and if necessary make queries to thesecurity module In this scenario trust management providetwo contexts ldquosharingrdquo and ldquoKeyManagementrdquo Both have 120572and 120573 values lower than 04

The context KeyManagement is queried by the key man-agement system for key issuing revocation and updateThough trust management values will be considered in thekey issuing threshold values to the acceptance are smallThus any node may request participation as a D-PKG mem-ber making the group open but the private master key isissued only if this node satisfies aminimal trust requirements

The other context is called Sharing and may be queriedby applications on the acceptance or not of services providedby members of an open group named ldquoSharingrdquo Note thatany node is able to participate in this group If necessarygroup members or client applications may query the globalkey management system to check the identity authenticity ofany group member

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 14: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

14 Journal of Computer Networks and Communications

Applications Resourcelocation

Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type Openlocation

Type ClosekeyManagement

System 1

Type Global

Key

Requests

RequestsContextLocation05 lt 120572 120573 lt 07

ContextkeyManagement05 lt 120572 120573 lt 07

Figure 10 Partially restrict scenarios

With these configurations middleware provides justsome security guarantees to applications Applications whichperform queries to trust management may receive unreliableinformation since system is susceptible to false accusationattacks The key management is vulnerable to impersonationattacks since an attacker needs to compromise a smallnumber of D-PKGmembers to be accepted and to receive itsown private key or even to be a D-PKG member

62 Partially Restrict Scenarios A second scenario is a par-tially restrict scenario in which an intermediary securitycontrol is necessary A service examplewhich can be classifiedas partially restrict is the resource localization In this case itis important to provide guarantees of nodes authenticity butat same time it does not need to block any node to provide aservice to applications

In this case security parameters and threshold valuesmay be set with more restrictions than previous scenarioHereafter some suggestions are presented

(1) trust management using TRUE 120572 and 120573 values maybe between 05 and 07 Then middleware willexchange information with nodes that have an inter-mediary trust evaluation in the context As a conse-quence the communication overhead will be smallerthan previous scenario while it keeps a higher controlof transmitted information

(2) key management with 119894FUSO 119905 value for the masterkey sharing should be higher than 1198982 to preventnetwork partitioning attacks Further key updateintervals may not be large to block unreliable nodesto be on the system for a long time

(3) group management in this scenario some applica-tions may be provided in closed groups but themajority may be organized into open groups Thus

even all nodes being able to join a group and toprovide services in this context client applicationsmay use trust management information to select thebest node to request a service

Note that in this scenario a unique group may be used tothemiddleware-wide keymanagementThus all applicationswhich need cryptography use the same service As on openscenarios the trust management must have information ofa context which will be queried by key management forexample key-management For all other provided servicesthe trustmanagementmay provide trust information on theirown context

Figure 10 illustrates how SEMAN components maybe integrated to satisfy security requirements on partiallyrestrict scenarios ldquoResource locationrdquo application requestsservices to the middleware which are received by the ser-vices and processingmodulesWhen necessary some queriesare made to the security module Two contexts are envis-aged KeyManagement and Location On both contextstrust management 120572 and 120573 values are between 05 and 07

As in open scenarios KeyManagement context is queriedby the key management for key issuing revocation andupdate However only nodes of the closed group namedldquoKeyManagementrdquo are accepted to be members of the D-PKG Thus the participation of nodes as D-PKG membersis more restrictive making the system more reliable Also120572 and 120573 parameters of the KeyManagement context may beincreased to ensure more security to keymanagement and toclient applications

The other context is called Location and may be queriedby application itself in the acceptance or not of servicesprovided by members of group named ldquoLocationrdquo As in theopen groups any node may be member of this group andif necessary client applications may query the global keymanagement to check the identity authenticity of a node

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 15: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Journal of Computer Networks and Communications 15

Applications e-commerce Other applications

SEMAN Trust Group

Processingand services

module

Secu

rity

mod

ule

Type CloseTransactions

Type CloseDPKG-Transactions

System 1

Type Restrict

Key

RequestsContextTransaction

ContextDPKG-Transactions

120572 120573 gt 07

120572 120573 gt 07

Figure 11 Restrict scenarios

With these configurations the system should be protectedagainst impersonation attacks Also higher 120572 and 120573 valuesmake the propagation of false accusations against a nodereputation more difficult Thus the middleware ensures tousers the authenticity of nodes which are participating inthese groups

63 Restrict Scenarios The third scenario is a restrict envi-ronment in which a more rigorous security control is neces-saryThis context considers the applications which cannot becompromised in face of attacks These applications performin general essential tasks to users and if affected bymaliciousattacks may compromise the integrity of provided servicesExamples are the e-commerce or financial transactionsTheseservices may receive the guarantee from the middleware thatthey are protected against malicious attacks

In this case security parameters and threshold valuesmust be set with many restrictions The following are somesuggestions

(1) trust management if TRUE is adopted 120572 and 120573

values must be higher than 07 Then middlewarewill exchange information only with reliable nodes inrelated context As a consequence less nodes will beable to join groups of this context

(2) key management with 119894FUSO 119905 values for master keysharing must be higher than 1198982 Further updatephase interval cannot be highThen the system over-head is increased but services provided will ensuresecurity against malicious attacks

(3) group management in restrict scenarios applicationsmust be provided in closed groups with a morerestrictive control on group joining

Note that for this kind of scenario different key man-agement group may be used for each application Thus

more restrictive applications may have their own context-related key management This blocks malicious nodes eventhe ones not participating in the group that is providing aservice to be a D-PKG member On the other hand a globalkey management scheme may be implemented to provideservice to groups with less restrictive applications For allother services the trust management may provided trustinformation on the services context

Figure 11 illustrates the integration of SEMAN compo-nents on restrict scenarios E-commerce application requestsservices to middleware Requests are received by the servicesand processing modules that if necessary query the secu-rity module Two contexts are envisaged DPKG-Transactionand Transaction On both contexts trust management has 120572and 120573 values higher than 07

The DPKG-Transaction is queried by the key manage-ment of closed group ldquoTransactionrdquo To this group manage-ment allows the formation of a closed group called ldquoDPKG-Transactionrdquo which has only the nodes that satisfy therequirements to be a D-PKG member These D-PKG mem-bersmake queries to the closed group ldquoTransactionsrdquo to checknodes reliability and issue private keys to them

The other context is called Transactions and it is queriedby members of closed group with same name which areresponsible for the acceptance or not of a new member or bythe exclusion of a currentmember Unlike previous scenariosto participate in a group nodes need to satisfy the trustrequirements defined by group policies increasing the systemsecurity and protection against malicious attacks

64 Hybrid Scenarios Three distinct scenarios of securitymodule configuration were presented However in practiceeach application which is using the middleware services maypresent a different scenario For example at the same timemiddleware may provide services to applications that requirea high level of security and also to an open oneThus SEMAN

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 16: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

16 Journal of Computer Networks and Communications

security policies must be directed to applications and servicescontexts which use the security module

A recommendation to the use of SEMAN in these sce-narios is the setting of a global key management whichsatisfies all servicesThus the entire network is supported by aunique D-PKG and all users have a unique publicprivate keypair to use on all applications Trust management must offerinformation about users in two contexts key-management

and key-management-dpkgTrust information about first context (key-management)

is used by key management when D-PKG members performusers private key issuing update or revocation In this caseusers with trust value in this context less than a threshold(that must be high) will not have their keys issued or updateby D-PKG members

Trust information of the second context (key-manage-ment-dpkg) is used by D-PKG members on decisions aboutthe acceptance or not of new D-PKG member These restric-tions must be higher than the key issuing restrictions Forexample a node can be authentic and has the right to have itsprivate key issued by a D-PKG However it cannot be reliableenough to be member of D-PKG

With a secure key management middleware ensuresthe protection of cryptographic operations against maliciousattacks and the authenticity of members Thus each appli-cation may be provided inside a context of closed or opengroups which requires a high level of reliability or allows thatservices to be provided by any node Thus each applicationwill be protected against malicious actions depending of itsown policies

65 Conclusion This section presented a study of some sce-narios which SEMAN may be employed to satisfy applica-tions requirements

7 Conclusions and Future Directions

This paper proposed secure context-basedmiddleware calledSEMAN which employs a group approach to support secu-rity making decisions The middleware architecture and anoverview of its operations were discussed Also how SEMANservices must be provided and how group approach may beapplied to ensure the security were presented

SEMAN has three modules services processing andsecurity The first two are responsible for providing servicesand for requests management Securitymodule is responsiblefor ensuring the security to applications that use the servicesprovided by SEMANThis module is composed of trust keyand group management components All these componentswere detailed focusing on how they can be used to ensurethe security to applications

Securitymodule components are integrated throughpoli-cies management which is responsible for security parame-ters of each provided service Further all activities are sup-ported by identity-based cryptographic operations The inte-gration of these components was discussed in distinct sce-narios in which some configuration suggestions were pre-sented to satisfy applications requirements

Table 2 Expected communication overhead

Trust Key GroupsRestrict Low Low HighPartially restrict Medium Low MediumOpen High Very low Low

SEMAN provides security against selfish impersonationSybil and byzantine attacks But other attacks can be foundon MANET and may affect the middleware efficacy At theend some scenarios inwhich SEMANmay be employedwerepresented These scenarios are classified into open partiallyrestrict and restrict Table 2 illustrates the expected overheadin each presented scenario SEMAN does not impose a highcommunication overhead Key management for exampleneeds more messages exchanges during a group creation andupdate However key updates do not occur frequently

Group management presents an overhead that dependson the way groups are organized Closed groups have higheroverhead than open ones However even closed groups havea higher communication cost only during group formationFurther secure group communication allows multicast mes-sages decreasing the quantity of individual messages

Trust management imposes a higher communicationoverhead when groups are open and then 120572 and 120573 valuesare smaller However even this higher quantity of messagesis performed just among neighbor nodes not affecting theentire networkThen securitymodule of SEMANcanbe usedto ensure the security requirements of application while notimposing a high communication overhead to network

To increase the system reliability new services can beintegrated to SEMAN and may be performed in future workas integrating with analysis tools of external environment tohelp automatic and dynamic configuration of security pol-icies proposing the integration of SEMAN with other cer-tificateless public key cryptography implementing and eval-uating the middleware in real scenarios and designing anaccounting scheme integrated with trust management toimpede that denial of service attacks overhead the systemwith false control messages Further a study should be per-formed in order to reduce de requirements of exponentialand pairing computations Authors suggest the use of certifi-cateless public key cryptography or other alternative modelscomparing their computational cost

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

This study is partially funded by CNPq Grants 4480042013-6

References

[1] B Wu J Chen J Wu and M Cardei ldquoA survey of attacksand countermeasures in mobile ad hoc networksrdquo in WirelessNetwork Security Y Xiao X S Shen and D-Z Du Eds

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 17: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

Journal of Computer Networks and Communications 17

Signals and Communication Technology chapter 12 pp 103ndash135 Springer New York NY USA 2007

[2] P Papadimitratos and Z J Haas ldquoSecuring mobile ad hocnetworksrdquo in The Handbook of Ad Hoc Wireless Networkschapter 21 pp 457ndash481 CRCPress Boca Raton Fla USA 2005

[3] R ShireyRFC 2828 Internet Security Glossary EUAMarina delRey Calif USA 2000 httpwwwietforgrfcrfc2828txt

[4] E da Silva and L C P Albini ldquoMiddleware proposals formobile ad hoc networksrdquo Journal of Network and ComputerApplications vol 43 pp 103ndash120 2014

[5] P A Bernstein ldquoMiddleware a model for distributed systemservicesrdquo Communications of the ACM vol 39 no 2 pp 86ndash981996

[6] J Al-Jaroodi I Jawhar A Al-Dhaheri F Al-Abdouli andN Mohamed ldquoSecurity middleware approaches and issuesfor ubiquitous applicationsrdquo Computers and Mathematics withApplications vol 60 no 2 pp 187ndash197 2010

[7] S Hadim J Al-Jaroodi and N Mohamed ldquoTrends in middle-ware for mobile ad hoc networksrdquo Journal of Communicationsvol 1 no 4 pp 11ndash21 2006

[8] I Chlamtac M Conti and J J-N Liu ldquoMobile ad hoc net-working imperatives and challengesrdquo Ad Hoc Networks vol 1no 1 pp 13ndash64 2003

[9] E da Silva A L dos Santos L C P Albini and M N LimaldquoIdentity-based key management in mobile ad hoc networkstechniques and applicationsrdquo IEEE Wireless Communicationsvol 15 no 5 pp 46ndash52 2008

[10] H-Y Chien and R-Y Lin ldquoImproved ID-based security frame-work for ad hoc networkrdquo Ad Hoc Networks vol 6 no 1 pp47ndash60 2008

[11] D Boneh and M Franklin ldquoIdentity-based encryption fromthe weil pairingrdquo in Advances in CryptologymdashCRYPTO 2001 JKilian Ed vol 2139 of Lecture Notes in Computer Science pp213ndash229 Springer London UK 2001

[12] X Li J Slay and S Yu ldquoEvaluating trust in mobile ad hocnetworksrdquo in Proceedings of the Workshop of International Con-ference on Computational Intelligence and Security (CIS rsquo05)Springer Xirsquoan China 2005

[13] J van der Merwe D Dawoud and S McDonald ldquoA surveyon peer-to-peer key management for mobile ad hoc networksrdquoACM Computing Surveys vol 39 no 1 article 1 Article ID1216371 2007

[14] M Nogueira G Pujolle E Silva A Santos and L AlbinildquoSurvivable keying for wireless ad hoc networksrdquo in Proceedingsof the IFIPIEEE International Symposiumon IntegratedNetworkManagement (IM rsquo09) pp 606ndash613 IEEE CommunicationsSociety Long Island NY USA June 2009

[15] M Blaze J Feigenbaum and J Lacy ldquoDecentralized trustmanagementrdquo in Proceedings of the 17th IEEE Symposium onSecurity and Privacy (SP rsquo96) pp 164ndash173 Oakland Calif USAMay 1996

[16] M Misaghi E da Silva and L C P Albini ldquoDistributed self-organized trust management for mobile ad hoc networksrdquo inNetworked Digital Technologies R Benlamri Ed vol 293 ofCommunications inComputer and Information Science pp 506ndash518 Springer 2012

[17] E da Silva M Misaghi and C P Luiz ldquoTrue a trust evaluationservice for mobile ad hoc networks resistant to maliciousattacksrdquo Journal of Digital Information Management vol 10 no4 pp 262ndash271 2012

[18] JWMickens andBDNoble ldquoModeling epidemic spreading inmobile environmentsrdquo in Proceedings of the 4th ACMWorkshopon Wireless Security (WiSe rsquo05) pp 77ndash86 ACM CologneGermany September 2005

[19] X Zhang G Neglia J Kurose and D Towsley ldquoPerformancemodeling of epidemic routingrdquo Computer Networks vol 51 no10 pp 2867ndash2891 2007

[20] A Shamir ldquoIdentity-based cryptosystems and signatureschemesrdquo in Advances in Cryptology G R Blakley and DChaum Eds vol 196 of Lecture Notes in Computer Science pp47ndash53 Springer New York NY USA 1985

[21] A Kate and I Goldberg ldquoDistributed private-key generatorsfor identity-based cryptographyrdquo in Security and Cryptographyfor Networks J A Garay and R De Prisco Eds vol 6280of Lecture Notes in Computer Science pp 436ndash453 SpringerBerlin Germany 2010

[22] E da Silva and L C P Albini ldquoTowards a fully self-organizedidentity-based key management system for MANETsrdquo in Pro-ceedings of the 9th International Conference on Wireless andMobile Computing Networking and Communications (WiMobrsquo13) pp 717ndash723 Lyon France October 2013

[23] Y Zhang W Liu W Lou and Y Fang ldquoSecuring mobile ad hocnetworks with certificateless public keysrdquo IEEE Transactions onDependable and Secure Computing vol 3 no 4 pp 386ndash3992006

[24] H Luo J Kong P Zerfos S Lu and L Zhang ldquoURSA ubiq-uitous and robust access control for mobile ad hoc networksrdquoIEEEACM Transactions on Networking vol 12 no 6 pp 1049ndash1063 2004

[25] L Zhou and Z J Haas ldquoSecuring ad hoc networksrdquo IEEENetwork vol 13 no 6 pp 24ndash30 1999

[26] J Kong P ZerfosH Luo S Lu and L Zhang ldquoProviding robustand ubiquitous security support formobile ad-hoc networksrdquo inProceedings of the International Conference onNetwork Protocols(ICNP rsquo01) pp 251ndash260 Washington DC USA November2001

[27] S Yi and R Kravets ldquoMOCA mobile certificate authority forwireless ad hoc networksrdquo in Proceedings of the 2nd Annual PKIResearch Workshop (PKI rsquo03) National Institute of Standardsand Technology (NIST) Gaithersburg Md USA 2003

[28] K Hoeper and G Gong ldquoKey revocation for identity-basedschemes in mobile ad hoc networksrdquo in Ad-Hoc Mobile andWireless Networks T Kunz and S S Ravi Eds vol 4104 ofLecture Notes in Computer Science pp 224ndash237 Springer 2006

[29] V Daza P Morillo and C Rafols ldquoOn dynamic distributionof private keys over MANETsrdquo Electronic Notes in TheoreticalComputer Science vol 171 no 1 pp 33ndash41 2007

[30] O Courand O Droegehorn K David et al ldquoContext awaregroup management in mobile environmentsrdquo in Proceedingsof the 14th IST Mobile and Wireless Communications SummitNokia Research Center Dresden Germany 2005

[31] C N Ververidis and G C Polyzos ldquoService discovery formobile ad hoc networks a survey of issues and techniquesrdquoIEEECommunications SurveysampTutorials vol 10 no 3 pp 30ndash45 2008

[32] J Hur C Park and S O Hwang ldquoPrivacy-preserving identity-based broadcast encryptionrdquo Information Fusion vol 13 no 4pp 296ndash303 2012

[33] D Augot R Bhaskar V Issarny and D Sacchetti ldquoAn efficientgroup key agreement protocol for ad hoc networksrdquo in Pro-ceedings of the 6th IEEE International Symposium on a World

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 18: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

18 Journal of Computer Networks and Communications

of Wireless Mobile and Multimedia Networks (WoWMoM rsquo05)pp 576ndash580 Washington DC USA June 2005

[34] B E Jung ldquoAn efficient group key agreement protocolrdquo IEEECommunications Letters vol 10 no 2 pp 106ndash107 2006

[35] L Zhang Q Wu B Qin and J Domingo-Ferrer ldquoProvablysecure one-round identity-based authenticated asymmetricgroup key agreement protocolrdquo Information Sciences vol 181no 19 pp 4318ndash4329 2011

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

Page 19: Research Article SEMAN: A Novel Secure Middleware for Mobile Ad Hoc Networksdownloads.hindawi.com/journals/jcnc/2016/3136853.pdf · 2019-07-30 · 3. Secure Middleware for Mobile

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of