Content uploaded by Mohamad Aljnidi
Author content
All content in this area was uploaded by Mohamad Aljnidi on Sep 13, 2015
Content may be subject to copyright.
Towards an Autonomic Security System for Mobile Ad Hoc Networks
Mohamad Aljnidi and Jean Leneutre
CNRS - UMR 5141 (LTCI)
TELECOM PARIS - INFRES Department
46, rue Barrault - 75013 Paris - France
{mohamad.aljnidi, jean.leneutre}@enst.fr
Abstract
We present our paradigm of autonomic networks through
a specific model of mobile ad hoc networks. Accordingly,
we define a security platform, in which we introduce ba-
sic solutions for building autonomic security systems. We
then present our relevant studies about event-driven net-
work security evolution, security-policy negotiation and en-
forcement, and collaboration between autonomic nodes.
1. Introduction
Human-driven administration is no more efficient in the
emerging, large-scale, complex systems. The need for self-
management solutions had already been recognized, and
many relevant initiatives were launched [8]. In our research,
which is in conformity with the Initiative of IBM [6], we
study the realization of Autonomic Computing properties
[9], to secure a type of mobile ad hoc networks, depend-
ing on high-level policies. A mobile ad hoc network can
be complex enough because of the potential employment
of many heterogeneous technologies in terms of hardware,
middleware or software. Nevertheless, we consider other
motivations in this context, such as scalability, mobility,
non-expert users and lack of infrastructure.
Different autonomic-computing aspects, such as self-
organization [4, 11], self-adaptation [14] and spontaneous
behavior [5], were already addressed in certain types of net-
works. Relatively recent studies try to define what an au-
tonomic network is [12]. For us, it is a network that can
evolve autonomously, in terms of membership and topol-
ogy, and can manage its evolution by itself, depending on
its autonomic systems. A network autonomic system can
detect network-evolution events, relevant to its context, and
can adapt itself and the network accordingly.
We use a specific model of wireless mobile ad hoc net-
works to realize our view of autonomic networks. Accord-
ing to this model, a network is created without a preex-
isting infrastructure, and evolves in an ad hoc manner in
terms of membership and topology. Its nodes are not sup-
posed to be homogeneous devices in terms of computing
and storage capabilities, networking techniques or power.
It is not supposed to have expert administrators. Besides,
subnetworks can be exported for certain periods, and rein-
tegrated in the mother network when they are back. We
consider this as a centralization functionality that we im-
pose in a supposedly-decentralized type of networks, and
we call it semi-centralization. In brief, we call MAutoNet
(Mobile Autonomic Network) a semi-centralized, wireless,
mobile, ad hoc, autonomic network of heterogeneous nodes
and non-expert users. This can be for example a home net-
work, a SOHO network, a business meeting network, an
emergency service network or a military tactic network.
MAutoNets have the same security requirements of con-
ventional networks, in addition to the security needs spe-
cific to wireless mobile ad hoc networks. However, existing
security solutions [3, 13, 15] appear to be incomplete for
MAutoNets in terms of Autonomic Computing [9], even if
they have self-management aspects [7, 10]. We are there-
fore working on new security models, architectures and pro-
tocols for MAutoNets [1, 2].
2. Security Platform
We suppose that each MAutoNet node must embed an
autonomic security architecture, which is compatible with
the heterogeneity of nodes, transparent to the end-user and
irrespective of the underlying networking techniques. Its
main components, as illustrated in figure 1, are the follow-
ing: 1) Security Agents: a set of software agents providing
security services, such as data confidentiality and integrity,
and security management services. 2) Security Manage-
ment Kit: a set of security management tools that can be
used either by an administrator, or in an autonomic context.
3) Autonomic Security Manager: the autonomic engine
which is responsible of securing communications, besides
assuming security self-management tasks. 4) Autonomic
Figure 1. Autonomic Security Architecture
Figure 2. Virtual Security Structure
Security Layer: an application-support security layer, em-
bedded in the communication stack, and encapsulating the
previous three components. 5) Security User Interface: a
set of high-level configuration and specification languages.
We propose a trust model that is built on a mutual trust
between each couple of nodes. This trust is established once
a secure relation is legally created between two nodes after
certain secure steps, as explained later in this section. The
nodes of a MAutoNet are virtually distributed on a set of
communities, so that the level of trust between two nodes of
the same community is the highest. Different levels of inter-
community trust are then defined, so that the level of trust
between two nodes is the same as the level of trust between
their communities. A variable set of MAutoNet nodes rep-
resents the board of security managers. We call them au-
thority nodes. Each community has one authority node, but
one authority node can be assigned to many communities.
This is because the authority role implies certain capabili-
ties, and a given community may not include nodes having
these capabilities. The first action to take to set up a secure
MAutoNet is to designate a qualified node as the authority
node of the first community. Afterwards, we can use this
authority node to insert other nodes in its community. We
can similarly create other communities and integrate them
in the network. The network evolves in terms of member-
ship when communities are integrated or revoked, and when
each community evolves in terms of node membership. A
node is within the security perimeter of a MAutoNet wen
it belongs to one of its communities. Figure 2 illustrates
what we call a MAutoNet virtual security structure, which is
characterized by a security perimeter delimited by the com-
munities, and encapsulating nodes and secure relations.
A mutual authentication should take place before a se-
cure relation is established between two MAutoNet nodes.
Authentication between a new node and an authority takes
place implicitly during the node insertion operation. Ac-
cording to the characteristics of the new node, the author-
ity assign it either a public-key certificate, or a secret key
shared uniquely with it. The result is an authority-node
secure relation. Similarly, authentication between two au-
thorities takes place implicitly during a community integra-
tion operation. The involved authorities exchange public-
key certificates. The result is an authority-authority secure
relation. As for authentication between two non-authority
nodes belonging to the same community, either certificates
assigned by the authority are enough, or the authority itself
intervenes as an authentication server. Finally, for authen-
tication between two non-authority nodes belonging to two
different communities, certificates assigned by relevant au-
thorities are used, and when a certificate is not available,
both authorities can intervene as authentication servers.
We categorize the MAutoNet nodes according to their
capabilities in terms of storage, computation and availabil-
ity. This categorization is configurable, but a default one
can be used, according to which a node can be a heavy-duty
device which is capable of performing asymmetric cryptog-
raphy and storing the associated materials, or a light-duty
device if not. An authority node is a heavy-duty device
which has also the required security server capabilities. Al-
though we consider automatic replacement of removed or
lost authorities, in the context of self-organization and self-
healing, an authority would rather have a limited mobility
and a long-life membership, as further characteristics. An
autonomic authority election mechanism is being studied on
this basis, as part of our autonomic security platform.
In a secure relation, cryptographic materials and access
rules depend on the trust level and the node roles and cate-
gories. Secure relations are classified accordingly. For ex-
ample, figure 2 illustrates a virtual security structure that
we already defined for a home MAutoNet [2]. In this MAu-
toNet, default node categorization is used and only two trust
levels are defined: a high trust between nodes of the same
community and a low trust between nodes of different com-
munities. A first classification, based on trust level, defines
two relation types: LTR for a Low-Trust Relation and HTR
Figure 3. Access Control Model
for a High-Trust relation. A second classification, based
on roles, defines two other types: ADR for an Authority-
Device Relation and AAR for an Authority-Authority Re-
lation. A final classification, based on categories, defines
three further types for device-device relations: HHR for a
relation between two heavy-duty devices, HLR for a rela-
tion between two devices of different categories and LLR
for a relation between two light-duty devices.
In terms of authorization rules, we define for a MAu-
toNet secure relation, a two-phase, self-organizing, access
control model illustrated in figure 3. In the first phase, ac-
cess is authorized or not according to what we call OBA
(Object-Based Authorization). Objects of a MAutoNet
node are categorized either as Private (unauthorized by de-
fault), or as accessible: Protected (shared with the author-
ity) - Friendly (authorized to the community) - Administra-
tive (shared between authorities) - Public (authorized to the
whole MAutoNet). In the second phase, we verify if the
access concerns a private object or an accessible one. In
the first case, a Discretionary Access Control (DAC), based
on the identity of the subject, is applied. DAC policy is sup-
posed to be defined by the node owner. In the second case, a
Secure-Relation-Based Access Control (SRBAC), based on
the trust level of the relation and the roles of its participants,
is applied. SRBAC is meant to be a variant of RBAC that
takes the trust level into consideration. A default SRBAC
policy is used initially, and then the autonomic security sys-
tem is responsible of enhancing and optimizing it.
3. Autonomic Security System
The autonomic security system is set up when the initial
communities are created and integrated. It is responsible of
detecting the network evolution events, related to security,
and of responding to them. In this context, it should man-
age variations in node membership (insertion, removal, ban-
ishment and reinsertion), virtual security structure (com-
munity integration, revocation, merging and splitting), net-
work scope (subnetwork exportation and reintegration, and
network merging and splitting), authority role (disposses-
sion, acquisition, delegation and retirement) and secure re-
lations (establishment and termination). We are working on
the event handling steps: monitoring, detection, analysis,
Figure 4. Security Policy System
and decision and execution of responses. We will focus in
the following on the last step, to show how authority nodes
might collaborate to execute responses to certain events.
3.1. Collaborative Delegation
Subnetworks may be exported for some specified time.
After deciding about what nodes to leave, when and for how
long, it is then up to the autonomic security system to make
of the designated subnetwork a secure MAutoNet. It should
create a virtual security structure for the subnetwork. Ex-
ported nodes can simply keep the same trust levels defined
for them in the mother network, and this will give subcom-
munities corresponding each to a community in the mother
network. The issue is in the need of those subcommunities
for authorities. The solution should not imply a lack in au-
thority nodes in the mother network. This is why one of the
security events is delegating the authority role to a node, ei-
ther to be an authority in the subnetwork or to replace an
exported authority node. Authority nodes collaborate to ac-
complish the exportation process. The collaboration allows
the synchronization of security information and materials.
It is also used here in a help for authority delegation. This
is when an authority does not find a qualified node in its
community to designate as delegated authority. The solu-
tion is to delegate the role to another delegated authority of
another participating community. This starts by a request
for delegation help, and then a negotiation is launched be-
tween involved authorities. The delegation help process is
implemented in our autonomic security system as a collab-
oration protocol called DHP (Delegation Help Protocol).
3.2. Security Policy Negotiation
We define three specification languages for security poli-
cies. The high-level language HSSI (Human / Security Sys-
tem Interface) is used by end-users to configure the security
system in general. The intermediate XML language SPML
(Security Policy Management Language) is used by admin-
istrators to perform security management tasks. The self-
management language SPLS (Security Policy Logic-based
Specification) is used by authority nodes for security pol-
icy analysis and recomposition. Each SPML instance is in-
terpreted into one or more Java applications. Enforcement
of security policies is then achieved by integrating the cor-
responding byte-code into the autonomic security system.
Figure 4 illustrates the life-cycle of a security policy ac-
cording to our security policy system. As the figure shows,
analysis and recomposition tracks have no human inputs,
which reflects the self-management behavior.
Each community of a MAutoNet has a set of network-
level security policies, which are the same in all commu-
nities, and a set of community-level security policies, of
which specific instances are enforced on different commu-
nities. Modification of security policies might be needed af-
ter some network security evolution. A need for negotiation
might then arise from conflicts with preexisting policies,
or with the security properties and configuration of certain
communities in case of changing network-level policies.
Nevertheless, there are other causes for negotiating secu-
rity policies: 1) Community integration (a new community
might have different network-level policies). 2) Delegation
termination (the returning subnetwork might have changed
its policies). 3) Merging communities (merged communi-
ties might have different community-level policies). 4) Im-
porting parts from other MAutoNets (potential differences
in any of the security policies). 5) Merging two MAutoNets
(it is necessary to negotiate the best policy specification for
the resulting network). To accomplish a security policy ne-
gotiation, each authority will analyze the SPLS instance of
the specified policy (figure 4), and accordingly launch the
negotiation module in its security management kit. SPLS-
formatted information will be then exchanged between au-
thorities in the context of a Security Policy Negotiation Pro-
tocol (SPNP). After having negotiated the specified policy,
and decided about its new specification, the autonomic re-
composition track is followed. We are working on the dif-
ferent issues of the security policy negotiation. We study
the potential assets and components of this operation, define
HSSI, SPML and SPLS languages, develop the negotiation
algorithm and specify and validate the SPNP protocol.
4. Conclusion
We defined our model of mobile autonomic networks
which we call MAutoNet. We presented its security archi-
tecture, virtual structure and models. We introduced au-
tonomic security systems. We focused on the collabora-
tion between authority nodes as a form of interoperability
between autonomic components. We introduced the rele-
vant Delegation Help Protocol (DHP), security policy sys-
tem and Security Policy Negotiation Protocol (SPNP).
We believe that autonomic behavior will be a must for
the networks of the future, and we intend to build the suit-
able framework for the future autonomic network security,
as the ultimate goal of our research.
References
[1] M. Aljnidi. S ´
ecurit´
e des r´
eseaux mobiles autonomes. In
Actes du Premier Workshop GET sur les R´
eseaux Spontan´
es,
2006.
[2] M. Aljnidi and J. Leneutre. Autonomic security for home
networks. In Proceedings of the First International Work-
shop on Self-Organizing Systems, 2006.
[3] D. Balfanz, D. Smetters, P. Stewart, and H. Wong. Talking
to strangers: Authentication in ad hoc wireless networks. In
Proceedings of the Symposium on Network and Distributed
Systems Security, 2002.
[4] A. Datta and K. Aberer. The challenges of merging two sim-
ilar structured overlays: A tale of two networks. In Proceed-
ings of the First International Workshop on Self-Organizing
Systems, 2006.
[5] L. M. Feeney, B. Ahlgren, and A. Westerlund. Spontaneous
networking: An application-oriented approach to ad hoc net-
working. IEEE Communications Magazine, 2001.
[6] P. Horn. Autonomic computing: Ibm’s perspective on the
state of information technology. Technical report, IBM Re-
search, 2001.
[7] S. L. Keoh and E. Lupu. Towards flexible credential verifi-
cation in mobile ad-hoc networks. In Proceedings of the 2nd
ACM Annual Workshop on Principles of Mobile Computing,
2002.
[8] J. O. Kephart. Research challenges of autonomic comput-
ing. In Proceedings of the 27th International Conference on
Software Engineering, 2005.
[9] J. O. Kephart and D. M. Chess. The vision of autonomic
computing. Computer, 2003.
[10] H. Luo, P. Zerfos, J. Kong, S. Lu, and L. Zhang. Self-
securing ad hoc wireless networks. In Proceedings of the
7th IEEE Symposium on Computers and Communications,
2002.
[11] T. Messerges, J. Curkier, T. Kevenaar, L. Puhl, R. Struik,
and E. Callaway. A security design for a general purpose,
self-organizing, multi-hop ad-hoc wireless network. In Pro-
ceedings of the First ACM Workshop on Security of Ad-Hoc
and Sensor Networks, 2003.
[12] S. Schmid, M. Sifalakis, and D. Hutchison. Towards auto-
nomic networks. In Proceedings of the First International
IFIP TC6 Conference on Autonomic Networking, 2006.
[13] F. Stajano and R. J. Anderson. The resurrecting duckling:
Security issues for ad-hoc wireless networks. In Proceed-
ings of the 7th International Workshop on Security Proto-
cols, 1999.
[14] S. S. Yau, Y. Yao, Z. Chen, and L. Zhu. An adaptable secu-
rity framework for service-based systems. In Proceedings of
the 10th IEEE International Workshop on Object-Oriented
Real-Time Dependable Systems, 2005.
[15] L. Zhou and Z. J. Haas. Securing ad hoc networks. IEEE
Network, 1999.
