2008 International Conference on Information Science and Security
Service Discovery and Delivery System based on Trust
in Mobile Ad-Hoc Network
In-Sung Han1, Jin-Mook Kim2, Hwang-Bin Ryou1, Woo-Hyun Ahn1
1
Dept. Of Computer Science, Kwang Woon University, Korea
1
{ishan78,ryou,whahn}@kw.ac.kr
2
Dept. Of Computer Information, Sun Moon University, Korea
2
calf0425@sunmoon.ac.kr
service discovery is a prerequisite for good utilization
of shared resources in the network. In a mobile ad-hoc
network, any node may in principle operate as a server
and provide its services to other mobile ad-hoc
network node[4]. Any node may also operate as a
client and use the service discovery protocol to detect
available services in the network. The service
attributes discovered include IP addresses, port
numbers and protocols that enable the client to initiate
the selected service on the appropriate server.
In ad-hoc networks nodes composed of limited
devices, it is very important to minimize the total
number of transmissions, in order to reduce battery
consume of the devices. It is also important to
implement mechanisms to detect, as soon as possible,
both the availability and unavailability of services
produced when a device joins or leaves the network.
Security in these networks is also critical because there
are many chances of misuse both from fraudulent
servers and from misbehaving clients.
In this paper, we propose a service discovery
protocol with Trust-level of devices in mobile ad-hoc
networks. Our scheme is a fully distributed protocol in
which services offered by devices can be discovered
by others, without a central server. It provides location
of trusted services, protection confidential information,
secure communications, identification between devices,
and service access control by forming a reliable ad-hoc
network.
The remainder of this paper is organized as follows.
In Section 2, we summarize the related work for the
service discovery mechanism. Continuously we
introduce service discovery mechanism based on trust
in Section 3 and describe our implementation result in
Section 4. Finally, we conclude this paper in Section 5.
Abstract
Traditional service discovery protocols cannot be
applied directly to mobile ad hoc networks because of
their heterogeneity and mobility. It is also important to
implement mechanisms to detect, as soon as possible,
both the availability and unavailability of services
produced when a device joins or leaves the network.
Security in these networks is also critical because
there are many chances of misuse both from fraudulent
servers and from misbehaving clients. So, trust of
devices and service discovery security is an important
concern for mobile ad hoc network. In this paper, we
propose the service discovery middleware with Trust
of devices for the reliable service discovery and
delivery between the devices in mobile ad-hoc network.
The proposed system could discover and deliver stable
service based on Trust of devices in the network
because it avoided the security threat.
1. Introduction
The last few years have seen a rapid increase in the
usage of mobile devices such as laptops, cell-phones,
and PDA(Personal Data Assistants)[1]. The
accompanied maturity in wireless technologies(802.11,
bluetooth or IrDA) has made wireless networks almost
as ubiquitous as traditional wired networks. An
important consequence of such developments has been
the concept of ad-hoc networks. These networks are
characterized by their lack of required infrastructure
and ease of formation; each participating device is
mobile and the networks are formed temporarily.
Discovery of services and other named resources
is anticipated to be a crucial feature for the usability of
mobile ad-hoc networks in this dynamic environment,
different nodes offering different services may enter
and leave the network at any time. Efficient and timely
0-7695-3080-X/08 $25.00 © 2008 IEEE
DOI 10.1109/ICISS.2008.25
171
factors must be taken into account when selecting
between a push solution or a pull solution.
The DEAPspace algorithm is the only service
discovery protocol, listed above, that tries to minimise
the total number of transmissions. It uses a pure “push”
solution and each device periodically broadcast its
“world view” although none of them has to request a
service.
Kozat and Tassiulas proposed a service discovery
mechanism targeted at mobile ad-hoc networks. A
virtual backbone is constructed dynamically, assuring
that all nodes are part of this backbone or at least one
hop away. Here again, the service discovery system
does not provide mechanisms for service selection
when multiple service instances of the same type
coexist.
Konark is a middleware designed to support service
discovery and delivery in ad-hoc networks. Services
are expressed using XML. The service delivery itself is
based on SOAP. Unlike our approach, Konark requires
a multicast protocol for the actual discovery process.
2. Related Work
Dynamic service discovery is not a new problem.
There are several solutions proposed for fixed
networks, with different levels of acceptance, like
SLP[11], Jini [10] and Salutation [3]. Recently, other
protocols for dynamic environments have appeared:
UPnP ’ s SSDP [12], DEAPspace [5], Kozat and
Tassiulas’SDP [6] and Kornak[7]. Only a few
protocols have built-in security, the most important are
SSDS [8] and Splendor [2]. However, these solutions
can not be directly applied to an ad-hoc network,
because they were designed for and are more suitable
for (fixed) wired networks. We see three main
problems in the solutions enumerated:
First, many of them use a central server, such as
SLP1, Jini and Salutation. It maintains the directory of
services in the network and it is also a reliable entity
the security of the system is based on. An ad-hoc
network cannot rely upon to have any single device
permanently present in order to act as central server,
and furthermore, maybe none of the devices present at
any moment may be suitable to act as the server.
Second, the solutions that may work without a
central server, like SSDP, are designed without
considering the power constraints typical in wireless
networks. They make an extensive use of multicast or
broadcast transmissions which are almost costless in
wired networks but are power hungry in wireless
networks.
Third, security issues are not well covered. SSDS
provides security in enterprise environments but may
not work in ad-hoc networks with mobile services.
Splendor does not provide certificate revocation and
trust models of PKIs. They both depend on trustworthy
servers and they propose solutions which are provided
at the IP level. Accepting that alternatives to the
centralized approach are required, we consider two
alternative approaches to distributing service
announcements: The "Push" solution, in which a
device that offers a service sends unsolicited
advertisements, and the other devices listen to these
advertisements selecting those services they are
interested in. The "Pull" solution, in which a device
requests a service when it needs it, and devices that
offer that service answer the request, perhaps with
third devices taking note of the reply for future use. In
ad-hoc networks, it is very important to minimize the
total number of transmissions, in order to reduce
battery consume. It is also important to implement
mechanisms to detect as soon as possible both the
availability and unavailability of services produced
when a device joins or leaves the network. These
3. Proposed Architecture
In this section, we introduce our authorization
service discovery system architecture and describe
each module. Our system enables also each device to
act as a server, a client and intermediate
simultaneously. We use the term “client node" for any
device that is interested in using services being offered
by nodes in the network. We use the term “server
node” for any device whose service is being used by
nodes in the network. Our system defines components
that allow devices to assume such a dual role. Each
device includes our application that facilitates human
interaction to initiate and control advertising,
discovery, and service usage. It also includes service
discovery and delivery managers and trust level
managers that together maintain service objects and
information about services offered by nodes in the
network. A small-HTTP server present to handle
service delivery requests. Our’s two main parts is
service discovery-delivery and trust level.
3.1. Our Scheme
Proposed our system enables also each device to act
as a server, intermediate router and client
simultaneously. Fig 1 shows our authentication service
discovery and delivery system architecture for role of
client node, intermediate node and server node.
172
3.1.2. Role of Intermediate Node. For the role of
intermediate node, each node is using Cache Manager
and Trust Manager. This Cache Manager structurally
saves and manages the service related information in
cache, in case it received the advertisement service
from the server nodes that provides the service, in case
it has ever used the same service and in case the
neighbor node has previously performed any event
through it.
The Trust Manager authorizes message for service
discovery and verifying the Trust Level of client. This
explores the services matching with the service
keyword through Cache Manager and available service
with its Trust Level authority of the verified
intermediate node. In case there is service identical to
service keyword in the cache, it delivers the reply
message to the client node through unicast, in order to
deliver the technical statement T-WSDL to connect
between the service provider information and server
node. If such service does not exist, it delivers again to
the neighbor node, while the packet is automatically
removed from the network when the lifetime passes.
Fig. 1. Proposed Service Discovery System Architecture
3.1.1. Role of Client Node. For the role of client ,
each node is using Service Request Sending Module in
Application Layer and Trust Manager. The application
of service discovery is implemented with GUI(Graphic
User Interface) to easily input required service key
word that the client tries to discover services. The
client inputs the service keyword to application and
then initializes the service discovery. In addition, the
client may easily receive the service when discovering
the service-providing server node will deliver the
URL(Uniform Resource Location) that can be
connected to the node providing the service to
application.
In performing the role of client, Trust Manager
manages the necessary own trust information. The trust
information is the property that controls the service
access provided by server node, and the trust
information is expressed in the level property value. In
this paper, such trust information is defined as Trust
Level. In order to ensure the differentiated service,
server node may high Trust Level. By using such Trust
Level value, it is possible to limit the access of the
malicious or non-reliable node, and therefore, to
provide the safe service continuously. In Session 3.2,
the decision and management of the Trust Level value
are described in detail.
Service Resource Discovery & Advertisement
Manager is the network tier that creates the message to
discover the service. This forms the information
necessary to discover the service requested by the
client, and manages the packet configuration so that
service discovery message may be delivered to server
node through intermediate nodes. In Session 3.3, the
service discovery message configuration and operation
in creation of service request message are specifically
described.
3.1.3. Role of Server Node. To take the role of server
node for the service providence, each node is using
mHTTP Server[7] and Requested Service Delivery
Interface Module. For the service delivery, server node
creates the T-SOAP message including the server
authorization information and the server Trust Level,
and then delivers them to the client node. The client
may receive the service through the necessary modules
according to the connecting method and authority, by
checking the T-WSDL.
The Policy Manager defines the property of the
service access authority according to the Trust Level of
the client node, and manages the limited service access.
In Session 3.4, the service authority management is
described in detail.
3.2. Trust Level Manager
Modern mobile devices can form ad-hoc networks
to autonomously share data and services. While such
self-organizing, peer-to-peer communities offer
exciting collaboration opportunities, deciding whether
to trust another peer can be challenging. In this work,
we use a decentralized trust management middleware
for ad-hoc networks, based on reputation. One of the
main difficulties in managing reputation-based trust in
ad-hoc networks is that information about node
interactions is spread across the network, and no single
node has a complete global view of the nodes
reputations. Furthermore, malicious nodes might
tamper with reputation information while it is stored
173
of this device travels, is responsible for adding the
reputation of Nr to the message-hit. Depending on the
topology of the network, Nr has several immediate
neighbors and all of them are responsible for piggybacking its reputation to its query-hit messages. The
node Ns that generated the service discovery message
compares all message-hits originating from the same
node Nr, to ensure that all report the same reputation
for it. The reputation R of node is associated at Ns with
a confidence value C, which is equal to the number of
nodes that have reported R. Honest nodes are
encouraged through C to maintain multiple neighbors,
which makes attacks riskier, due to the entropy
introduced by the unstructured topology.
locally or transmitted, or even try to defame other
nodes. A middleware solution to these challenges can
facilitate secure node interoperability without user
intervention[9].
In this work, we assume a logical network of nodes
that provide data or services to each other. We will use
the term object to collectively refer to both data and
services. Each node Ni is identified by a public/private
key pair, and maintains connections to other nodes.
The network is unstructured, decentralized and selforganized, meaning that nodes make their own
decisions as to which nodes to connect to or to query
for object services. For object service discovery, each
node make query message Mj that included nonce N ,
timestamp T, lifetime TTL. So, a node broadcast to
vicinity nodes, and a node receive the replay message
rj from vicinity nodes. A node’s reputation Ri is
defined as the sum of ratings it has received so far,
Ri=∑ j rj.
When a node acts as a client of an object service, its
goal is to identify the node with the highest reputation,
that is offering the particular object. Knowing the
node’s reputation the client can decide whether to trust
the provider, depending on the minimum Trust Level
Lj it requires for this particular type of object. For
example, a peer might have different required Trust
Levels for different types of transactions, depending
on their cost. While the minimum trust levels are set
once by the user, discovering the providers with the
highest reputation Ri and comparing Ri to Lj to decide
whether a node can be trusted (if Ri < Lj) are the
responsibilities of the Trust level Manager. When a
node acts as a provider of an service, its goal is to have
as many clients as possible.
For decide trust of each node, each node operates
like follow steps. A node Ns searches for a requiring
service by sending service discovery message to its
vicinity nodes. These messages are evaluated locally in
each node and in case a node Nr offers a matching
service, the positive reply (message-hit) is returned to
Ns. The messages are propagated further, until their
number of hops to travel lifetime expires. The service
discovery message id is the same for the message, and
the possible message-hit, and rating messages that are
produced as a result of this service discovery messages.
It is defined as a random number, generated by the
node Ns that produced the service discovery message,
together with its public key. The message-hits follow
the same path as the queries to reach Ns. This is easily
achieved by the nodes caching the message ID from a
service discovery message they have routed and using
the reverse route when routing the corresponding
query-hit, which has the same message ID. Every
vicinity neighbor of Nr, through which a message-hit
3.3. Service Discovery Operation
Fig 2 shows the process of the service discovery and
delivery operation between the client servers based on
the Trust Level in the Ad-Hoc network.
Fig. 2. Service Discovery and Delivery Operation
3.3.1. Service Advertisement Message. First of all, C
as server node delivers the service advertisement
message to the nodes next to the service provided by C.
It delivers the same information as described in Fig 3.2
for the service advertisement.
Fig. 3. T-Service Advertisement Message Format
Such service advertisement message is delivered
periodically to the neighbor node, and such
neighboring intermediate nodes structuralize the
service information through the SSC Manager, to save
and manage it.
174
3.3.2. Service Advertisement Message. Based on
Trust Level, the client node delivers the same service
discovery protocol as S-REQ Message described in Fig
3.4 to the neighbor node. SSC Manager of the
neighbor Ins explores the cache save structure to
deliver the service that fits the Trust Level authority of
the client. If any identical service exists, intermediate
node will deliver the S-REP Message containing the TWSDL to the client node, in order to connect to server
node, as S-REP Message in Fig. 4.
3.3.4. T-SOAP Message Structure for Service
Delivery Request. The SOAP[13] is the XML-based
protocol for the information exchange under the
distributed environment. The SOAP message is
comprised of two types of data structure, that is, of the
SOAP header and SOAP body, and SOAP envelope
containing the Name Space used to define such header
and body. The body contains the XML format web
service request or the response to such request, and it
is used to represent the method names and factor
values mainly for service calling. The header is
optional, and in case the header exists, it is used to
deliver the additional information on the request
irrelative to the method calling and defined in the
SOAP body. For example, it may contain the
transaction, security, context and user profile
information.
Fig. 4. Service Discovery Request and Reply Message
Format
3.3.3. Service Delivery Message. Each node proposed
in this paper takes the both roles of client and server, at
the same time. The client node, to receive the service
from the server node, attempts the connection to the
server by using the T-WSDL from expended
WSDL[14].
Fig. 6. T-SOAP: Structure and Example of Extended SOAP
In this paper, we applied the T-SOAP where the
credentials factor of the SOAP header is defined, in
order to describe the information necessary for the user
authentication and approval. Fig. 6 shows T-SOAP for
required service delivery. For the user authentication,
the public key authentication method is used, and for
the approval, the property certificate used under the
privilege management based structure is used. We
structured the credentials factors as the two fields of
PublicKeyCertificateID to contain the information on
the user’s public key certificate necessary for the
authentication, and AttributeCertificateID to contain
the information on the user’s property certificate
necessary for the approval. The information on both
user’s public key certificate and the property certificate,
was made to contain only certificate serial number and
the certificate issuer’s location information as the
minimum information that may identify the certificate
Fig. 5. T-WSDL: Structure and Example of Extended
WSDL
Fig. 5 shows T-WSDL for Trust Level Policy At
that time, After setting its own Trust Level as privilege
account according to T-WSDL, client node sends the
property certificate to server node. server node
authenticates the client node through the public key,
and after such authentication finishes, it performs the
approval process based on the property information in
the property certificate after verifying the effectiveness
of the approval module and the property certificate of
the server property access control filter. When all
authentication and approval process finish, server node
provides the service the client wants.
175
Academic Publishers. ISBN 0-7923-8610-8, October
1999.
[2] F. Zhu, M. Mutka, L. Ni, "Splendor: A secure, private,
and location-aware service discovery protocol supporting
mobile services," in Proceedings of the First IEEE
International Conference on Percom'03. IEEE Computer
Society, March 2003.
[3] Brent A. Miller, Robert A. Pascoe, "Salutation service
discovery in pervasive computing environments,"
Techical Report, IBM White Paper, Febrary. 2000.
[4] Pall E. Engelstad, Yan Zheng, Rajeev Koodli, Charles E.
Perkins,"Service Discovery Architectures for On-Demand
Ad Hoc Networks," Ad Hoc & Sensor Wireless Networks,
2006.
[5] Michael Nidd, "Service Discovery in DEAPspace", in
Proceedings of IEEE Personal Communications, August.
2001.
[6] U. Kozat, L. Tassiulas, "Network layer support for
service discovery in mobile ad hoc networks", in
Proceedings of IEEE INFOCOM, San Francisco, USA,
April 2003.
[7] S. Helal, N. Desai, V. Verma, C. Lee, "Konark—a
service discovery and delivery protocol for ad hoc
networks", in Proceedings of the third IEEE Conference
on WCNC, New Orleans, March 2003.
[8] Steven E. Czerwinski, Ben Y. Zhao, Todd D. Hodes,
Anthony D. Joseph, and Randy H. Katz, "An architecture
for a secure service discovery service" , in Proceedings of
Mobicom'99, 1999.
[9] Thomas Repantis, Vana Kalogeraki. "Decentralized Trust
Management for Ad-Hoc PeertoPeer Networks," in
Proceedings of the 4th international workshop on
MPAC'06, 2006.
[10] Sun Microsystems, "Jini architecture specification
version 2.0 ," http://www.sun.com/software/jini/specs/.
June 2003.
[11] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service
location protocol", Internet Engineering Task Force: RFC
2165, 1997.
[12] Microsoft, The universal plug and play (upnp) forum.
http://www.upnp.org, 2003.
[13] Martin Gudgin, et al., "SOAP Version 1.2 Part 1;
Messaging Framework," W3C Working Draft, June 2002.
[14] Roberto Chinnici, et al., "Web Services Description
Language(WSDL) Version 1.2," W3C Candidate
Recommendation, 2002.
considering the transmission efficiency of the SOAP
message.
4. Implementation
Our proposed system is operating system and
programming language independent, since it provides
a framework in which services are described and
delivered using open standard XML technology over
IP network connectivity like konark. We have
implemented our prototypes in Java(Personal Java 1.2)
Personal Java 1.2 is JDK1.1.8 compliant. For this
implementation, we used Window CE based HP iPAQ
hx4700 Pocket PC from Hewlett-Packard Company.
With integrated wireless capabilities such as integrated
Bluetooth and Wi-Fi (WLAN), you can access the
Internet, email, and corporate data at home, at work or
on the go.
We provide a set of APIs, so that actual services
can be built easily. The API set includes service
advertisement and discovery, service description and
invocation, service registry management, service lease
management, several utility, and user interface APIs..
5. Conclusion
In this paper, we design and implement
authorization service discovery and delivery system
that offer suited access control service in ad-hoc
network environment. We decide access authorization
using access control policy information and implement
the module for issue and verification of attribute
certificate. In addition, we defined extended WSDL
that is T-WSDL for the explanation of requirement
about security service in a stage of advertisement and
discovery of service. We can describe access control
policy information that are needed certification and
permission of user in the expanded field. Also we
redefined T-SOAP that defined the element of SOAP
header to attach the information of user certification
and permission along with the SOAP requirement
message on demand service. In the next study subject,
As we developed more efficient client system that have
the cache in access control filter for client access
authorization decision because it dose not request the
access authorization decision about frequent request ,
we expect the improvement of system performance.
References
[1] A. Helal, B. Haskell, J. Carter, R. Brice, D. Woelk, and
M. Rusinkiewicz, "Any Time Anywhere Computing:
Mobile Computing Concepts and Technology," Kluwer
176