a cross-layer approach for integrating security mechanisms in sensor networks architectures

WIRELESS COMMUNICATIONS AND MOBILE COMPUTINGWirel. Commun. Mob. Comput. 2011; 11:267–276

Published online 06 July 2010 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/wcm.1006

SPECIAL ISSUE PAPER

A cross-layer approach for integrating securitymechanisms in sensor networks architecturesRodrigo Roman∗, Javier Lopez and Pablo Najera

Department of Computer Science, University of Malaga, Spain

ABSTRACT

The wireless sensor networks (WSN) paradigm is especially vulnerable against external and internal attacks. Therefore, itis necessary to develop security mechanisms and protocols to protect them. These mechanisms must become an integralpart of the software architecture and network stack of a sensor node. A question that remains is how to achieve thisintegration. In this paper we check how both academic and industrial solutions tackle this issue, and we present the conceptof a transversal layer, where all the different security mechanisms could be contained. This way, all the elements of thearchitecture can interact with the security mechanisms, and the security mechanisms can have a holistic point of view ofthe whole architecture. We discuss the advantages of this approach, and also present how the transversal layer concept wasapplied to a real middleware architecture. Copyright © 2010 John Wiley & Sons, Ltd.

KEYWORDS

architecture; cross-layer; middleware; security; sensor networks

*Correspondence

Rodrigo Roman, Department of Computer Science, University of Malaga, Spain.E-mail: [email protected]

1. INTRODUCTION

A wireless sensor network (WSN) can be abstracted asthe ‘skin’ of a computer system, an independent ‘sensorysystem’ capable of obtaining and processing physical infor-mation (e.g. temperature, soil mosture) through its ‘sensorycells’ (i.e. sensor nodes). With commercial applicationsranging from precision agriculture [1] to healthcare [2],sensor networks are slowly leaving the laboratories andreaching the real world. Nevertheless, the evolution of thisparadigm is far from over: there are still advances in thisarea in terms of complexity, heterogeneity and integration.The elements of a wireless sensor network, the sensor nodes,can be able to interact with complex devices (i.e. actors) thattake decisions according to the data received and performappropriate actions upon the physical world [3]. Sensornodes can also work in unconventional environments, suchas underwater [4], where their unique characteristics havea great influence over the architecture and the protocols ofthe network. Finally, sensor nodes can become an integralpart of other complex systems, such as embedded peer topeer systems (EP2P) [5], where nodes need to interact withother wireless devices in an ad hoc fashion.

One of the challenges that needs to be closely addressedin these evolved sensor networks is security. As sensor net-works are specially vulnerable against external and internal

attacks, it is necessary to implement certain security mech-anisms and protocols that will either minimize or preventthe malicious effects caused by such attacks. These secu-rity mechanisms should be, in most cases, adapted for everyspecific application, because the requirements of the appli-cation and its context will influence over their nature. Forexample, due to the limited bandwidth efficiency of thesea water medium [4], it is desirable to use protocols thatexchange as less bits as possible.

Aside from the development of security mechanisms,there is another important security-related aspect that mustbe also taken into account: the integration of those mech-anisms inside a software architecture and network stack.The components and different layers of a software architec-ture need the mechanisms as tools that will help to enforcethe security requirements. However, a single type of archi-tecture may not fit the needs of every kind of application.For example, cross-layer architectures seem to suit the spe-cific needs of underwater sensor networks (UWSN), whilecertain environments (e.g. home automation) with hetero-geneous devices can make use of the (non-strict) layeredarchitecture of ZigBee.

The purpose of this paper is to analyse how the securitymechanisms could be integrated with the existing archi-tecture paradigms (cross-layer and layered), allowing thepossibility of adapting or including new security mecha-

Copyright © 2010 John Wiley & Sons, Ltd. 267

Cross-layer integration of security mechanisms in sensor networks R. Roman, J. Lopez and P. Najera

nisms without breaking the design. As all these mechanismsshare the same goal, which is providing security to otherlogical parts of the architecture, they could be regarded as asingle logical unit within the architecture. Thus, the creationof a transversal layer for security that can be accessed byall the elements of the architecture is considered. Besides,we will explain how the concept of a transversal layer hasbeen successfully applied to a middleware architecture.

The paper is organized as follows. Section 2 reviews theadvantages and disadvantages of the existing architectureparadigms (layered and cross-layer) in sensor networks, andSection 3 discusses the relationship between these archi-tectures and the security mechanisms. Section 4 introducesthe concept of a transversal layer for security, and explainshow the different advantages of both layered and cross-layerarchitectures are retained. Section 5 illustrates the applica-bility of the transversal layer using the SMEPP middlewarearchitecture as an example. Finally, Section 6 concludes thepaper.

2. WIRELESS SENSOR NETWORKSARCHITECTURES

2.1. Layered and cross-layer approaches

The architecture and protocols of any kind of sensor net-work are highly dependant on the requirements of theapplication where it is deployed. For example, in scenarioswhere the location of the nodes is significant, routing proto-cols may route the packets using geographical information,while other scenarios (e.g. fire detection) may require pro-tocols that route the packets based on the data obtainedfrom the sensors. Therefore, any software architecture andnetwork stack designed for sensor networks should be flex-ible and extensible in order to support different types ofprotocols in different contexts. Whether this kind of archi-tecture should be designed as a rigid layered system oras a completely component-based system with cross-layerinteractions is yet to be specified.

Traditionally, network design has followed a layeredcommunication architecture. In this architecture, commu-nication tasks are separated into several layers, with aclear definition of the functionality of each layer. In a lay-ered communication stack, the interaction amongst layersoccurs through well-defined standardized interfaces thatconnect only the neighbouring layers in the stack. By usingthis approach, it can be possible to provide a high degreeof modularity and interoperability amongst heterogeneousnetworks.

The benefits of using a well-defined layered architectureare numerous. Due to its modularity, designers can easilyunderstand the behaviour of the overall system. It also accel-erates the development, design and implementation phasesby enabling parallelization of effort. Designers can focustheir effort on a particular subsystem with the assurancethat the entire system will interoperate. Moreover, individ-ual modules can be upgraded without requiring a complete

system redesign, increasing the longevity of the system.Widely used in wired networks (e.g. the Internet TCP/IPmodel), this kind of architecture can be also applied towireless networks, including sensor networks.

However, in the field of wireless networks, the traditionallayered communication architecture needs to be reconsid-ered. The unique problems and opportunities created bywireless links, the resource constraints inherent to sensornodes, and many other design challenges, are enabling thedevelopment of novel cross-layer designs [6]. Cross-layerdesign enables different layers of the communication stackto share state information or to coordinate their actions.For example, supplying information on a node’s remainingbattery energy to all of the nodes’ communication layers.

The use of a cross-layer approach in a sensor networkenvironment yields many advantages. Nodes could be ableto manage several performance aspects, such as powermanagement and error notification, that cut across tradi-tional layers. Also, nodes could have access to their currentresources and processes (e.g. wireless channel link prop-erties), which contributes favourably to the autonomy andself-configurability of the node (e.g. adapting its behaviourto the local state of the transmission medium). Besides,the inherent constraints of the nodes requires fine-grainedoptimization techniques between layers.

There are some aspects that have to be taken intoaccount when designing cross-layer architectures. Cross-layer design opens the floodgate of information flow acrosslayers, raising concerns on multiple, sometimes subtle,interactions amongst existing layers. This makes the archi-tecture more difficult to develop and maintain, as there maybe some new dependencies that must be taken into account.Also, the introduction of excessive and uncontrolled inter-actions can break the design of the system, hindering itsusefulness and longevity [7]. As a result, cross-layer design-ers must consider the impact of their design with a holisticview that includes the long-term development and innova-tion considerations. The benefits of the different cross-layerdesign proposals and its possible coexistence should bestudied in more deep [6]. Still, as of today, there have beenboth academic and standard network stacks that implementsome cross-layer optimizations in sensor networks.

2.2. Prototypes and industrial stacks

The use of cross-layer optimizations and architectures hasbeen widely considered in sensor networks designs andprototypes developed in the academia. In fact, in his sem-inal paper of 2002, Akyildiz considered the existence oftransversal management planes interacting with the lay-ered architecture [8]. Later, he even changed his initialpoint of view regarding sensor networks architectures andconsidered that the best solution is to use a unified cross-layer module [9]. Other architectural examples for wirelesssensor networks include TinyCubus [10], the ‘Sensor Proto-col’ [11], SensorStack [12] and many others. Even more, the‘de facto’ standard OS for sensor networks environments,

268 Wirel. Commun. Mob. Comput. 2011; 11:267–276 © 2010 John Wiley & Sons, Ltd.DOI: 10.1002/wcm

R. Roman, J. Lopez and P. Najera Cross-layer integration of security mechanisms in sensor networks

Figure 1. Outline of the ZigBee stack architecture.

TinyOS, introduces cross-layer optimizations as a part ofits core design [13].

The aspects of a network layer that should be includedinto a cross-layer design for sensor networks are outlinedby all these architectures. First, there are some services thatshould be accessed by all the layers of the network: powermanagement, network discovery, localization, synchroniza-tion, and security. Second, the network architecture shouldfollow a component-based approach, where the functional-ity that is used by two or more layers (e.g. symmetric keyalgorithms) should not be replicated. Third, there shouldexist mechanisms that allow one layer of the network toaccess the services of non-adjacent layers, for optimiza-tion purposes (e.g. an application accessing directly tothe hardware services). Finally, it should be required tohave certain mediators that provide system information andinternal information from other layers through well-definedinterfaces.

As for industrial standards, one of the suites of highlevel communication protocols that have been standard-ized and applied to some sensor networks deploymentsis the ZigBee stack [14]. Created in 2004 by the Zig-Bee Alliance, the major purpose of the ZigBee stack isto enable broad-based deployment of low cost, low powerwireless networks that addresses the needs of remote sens-ing, monitoring and control. In particular, the ZigBee stackis targeting the following applications: Advanced MeteringInfrastructure (AMI), Commercial Building Automation(CBA), Home Automation (HA), Personal, Home and

Hospital Care (PHHC), Telecom Applications (TA), andWireless Sensor Applications (WSA). For wireless sensornetworks, as of 2009 the ZigBee Alliance is still definingthe profile specification that will allow the creation of sensornetworks applications through ZigBee.

Figure 1 shows an overview of the ZigBee networkstack, which operates over the IEEE 802.15.4 standard.The network stack is organized into two distinct layers:Network (NWK) layer, and Application (APL) layer. TheNetwork layer allows end-to-end communication and multi-hop capabilities. The Application layer is partitioned intoseveral subcomponents: the Application Support Sublayer,which combines the functionality of a traditional transportlayer and of an application layer, the ZigBee Device Object,in charge of storing design parameters and managementcommands, and the Application Framework, containing theapplication profiles.

While the ZigBee network stack follows a layeredapproach, there are some cross-layer interactions. For exam-ple, the ZDO Management Plane allows all the ZigBeelayers to access the design information and managementcommands included inside the ZigBee Device Object.Besides from specific optimizations, the ZigBee stack doesnot consider the existence of certain transversal servicesthat should be used by all layers, such as power manage-ment. Also, aside from the management planes, the ZigBeestack follows a strict layered approach, where the applica-tion layer cannot have access to the services provided bythe link layer.

Wirel. Commun. Mob. Comput. 2011; 11:267–276 © 2010 John Wiley & Sons, Ltd. 269DOI: 10.1002/wcm


3. SECURITY AND INTEGRABILITY

3.1. Security mechanisms for sensornetworks

In any environment, either physical or logical, there existsthe need of maintaining someone or something safe,away from harm. This is the role of security. On anycomputer-related environment, security can be consideredas a non-functional requirement that maintains the over-all system usable and reliable, protecting the informationand information systems. In fact, in any kind of sensornetwork, security is of paramount importance: the networkmust be adequately protected against malicious threats thatcan affect its functionality. Also, due to the role of sensornetworks as ‘sensory systems’ and ‘actuator systems’, anydisturbance in a sensor network may have consequences inthe real world.

However, achieving this goal is not an easy task, becausesensor networks are specially vulnerable against externaland internal attacks due to their peculiar characteristics.The devices of the network (i.e. sensor nodes) are highlyconstrained in terms of computational capabilities, memory,communication bandwidth and battery power. Additionally,it is easy to physically access such nodes: either they must belocated near the physical source of the events, or their mobil-ity allows an attacker to easily locate and subvert them.Furthermore, any internal or external device can accessto the information exchange because the communicationchannel is public.

As a result, sensor networks have to face multiple threatsthat may easily hinder its functionality and nullify the ben-efits of using its services: communication channel attacks,denial of service, node compromise, impersonation attacks,protocol-specific attacks, etc. It is clear that there is the needof using security mechanisms either to prevent the attacksfrom influencing over the functionality of the network or tominimize the adverse effects of such attacks [15].

The communication channel can be adequately pro-tected against external attacks by using security primitives,although the security credentials (i.e. secret keys) need to bedistributed using key distribution protocols. Support proto-cols, such as situation awareness mechanisms and intrusiondetection systems, can offer a basic level of protection to‘core protocols’ (routing, aggregation, time synchroniza-tion). Note that these ‘core protocols’ also can, and should,implement protection mechanisms of their own. Besides,there are other specific protocols, such as code distribution,that must be able to withstand specific attacks. Finally, it ispossible to include other security protocols, such as codeattestation (i.e. check whether the code of a node is validand not tampered), that may help to maintain the overallsecurity of the network.

3.2. Integrating the security mechanisms

By means of the security mechanisms, it is possible tocreate and implement secure services and protocols that

fulfil essential security properties such as confidentiality,integrity and authentication. For example, by using securityprimitives such as block ciphers and message authentica-tion codes, we can create secure protocols that are ableto protect the communication channel between nodes orbetween peers. Also, as survivability is an important issuein sensor networks, any situation awareness mechanism incharge of monitoring the behaviour of the nodes and theirneighbourhoods will provide crucial information for allow-ing self-configurability in presence of possible problems(e.g. nodes ‘dying’, broken links).

The components and different layers of a software archi-tecture need these security mechanisms as tools that willhelp to enforce the security requirements of an applica-tion. Therefore, the security mechanisms themselves mustbecome an integral part of the software architecture. Aquestion that remains is where and how to integrate theminside the architecture. It is necessary to maintain the logicalcoherence in the design of the architecture, while allowingthe possibility of either adapting or including certain secu-rity mechanisms in order to comply with the requirementsof the applications. Besides, due to the limited resourcesavailable to most sensor nodes, there should exist certainoptimizations such as different services sharing the sameprimitive.

By including the security services as a well-defined layerwithin a layered architecture, we can benefit from theadvantages of this approach: modularity, interoperabilityassurance and localized design and upgrading. Still, thereare situations where the functionality of a layer would needto be replicated within the architecture. For example, an end-to-end secure channel located at the application layer [16]can use the same cryptographic mechanisms of a securelink layer communication channel [17]. Besides, there areother situations where a service need to access informationcontained in other layers in order to work correctly. Forexample, in order to know the actual state of a node andits neighbourhood, it is necessary to analyse variables suchas actual battery levels, packet signal strength and packetheaders. Moreover, a radio fingerprint mechanism in thephysical layer [18] can be used by other layers to authen-ticate the source of a message and detect attacks such asreplication attacks.

All these concerns have been considered by prototypesfrom the academia and industrial standards, and most ofthem suggest some cross-layer optimizations for integrat-ing the security mechanisms as part of an architecture. It wasalready pointed out by Srivastava [6] that security relatedissues need to be handled across the layers in a holistic man-ner. This point of view is shared by most designs comingfrom the academia, such as the ‘sensor protocol’ [11] andSensorStack [12]. In particular, the ‘sensor protocol’ con-siders that security should be encapsulated in a single layer,not distributed amongst layers. However, that architectureprovides few discussions about this particular issue.

Regarding the ZigBee stack, the need to optimize theresource usage in the implementation of the security mech-anisms is acknowledged by the definition of a specific



Layered ArchitectureCross-Layer Transversal Sec. Layer

Service 1

Service N

Physical Layer

Link Layer

Network Layer

Transport Layer

Application Layer

Figure 2. Security as a transversal layer.

component, the Security Service Provider. This componentis shared by the Network Layer and the Application SupportSublayer, and its main task is to provide security mecha-nisms for data encryption. However, the architecture doesnot provide support for other security services, such as intru-sion detection and self-healing systems, that need a holisticpoint of view of the whole architecture.

From the previous discussions, it would seem clear thatin a sensor network context the security mechanisms andservices need to interact with the existing layers of an archi-tecture in unconventional ways, by considering cross-layerapproaches. Nevertheless, as both cross-layer architecturesand layered architectures are to be found in the real world, itis necessary to evaluate how the security mechanisms couldbe satisfactorily integrated with any type of architecturewithout endangering the consistency of its design.

4. SECURITY AS A TRANSVERSALLAYER

The major purpose of the security mechanisms is usually notto implement the logic of the application, but to offer supportfor the creation of secure applications. We can see then thesecurity mechanisms as tools, used either by other elementsof the architecture or by other security mechanisms. As theyshare the same goal, they can be considered as a singlelogical unit inside the architecture, thus we could group allthe security mechanisms within a single layer. By usingthis approach, we can have a better management of all themechanisms, delimiting their functionality and controllingtheir interdependencies. As for the relationship between themechanisms and the rest of the architecture, the mechanismsshould be able to access all the elements of the architecturein order to obtain information, and the architecture itselfshould be able to access any of the security services whenneeded.

Therefore, security should be considered as a transversallayer (cf. Figure 2), that in both layered and cross-layerarchitectures will be able to provide information andservices to the other elements of the architecture. Secu-rity services and primitives (e.g. protocols, algorithms)are located inside that transversal layer, and they inter-act between them and between the other elements of thearchitecture through well-defined interfaces. Besides, thetransversal layer only provides security-related services,

invokes the services of other layers in order to obtain infor-mation, and signals specific events to warn other layersabout a specific situation. Therefore, any layer cannot accessthe functionality of other layers through the transversal layerin an indirect way.

From a technical point of view, the interfaces providedby the transversal layer must follow these two principles:independence and extensibility. The specific implementa-tion details of the algorithms and protocols should not affectthe definition of the interfaces, so the components that usethe transversal layer do not need to change their implemen-tation whenever a existing primitive is upgraded or changed.This can be achieved by defining a common interface forservices and primitives of the same type (e.g. symmetriccryptography primitives), and also by using mechanismssuch as the ‘factory’ design pattern (in a similar fashion tothe Java Security API [19]). As similar primitives and ser-vices will use the same type of interface, it is simple to adda new element whenever it is needed.

Precisely, the specific security elements that are con-tained within the transversal layer can be chosen accordingto the necessities of the applications and the capabilities ofthe devices. For example, if a specific application employsdigital signatures, the transversal layer can provide an inter-face for accessing a signature service. Such service can beimplemented by using lightweight algorithms (e.g. signa-ture algorithms based on Elliptic Curve Cryptography) ifthe devices are constrained in terms of resources. Morepowerful devices can implement more algorithms (e.g.identity-based signatures) inside the transversal layer. Thetransversal layer should also provide the services and prim-itives it contains whenever it is queried, so it is possible fortwo devices to negotiate security elements that they have incommon.

Note that the definition of wrappers that allow any com-ponent of the transversal layer to access the functionality ofelements located outside it is also important. Any changein the interface of the architecture will impact on the wrap-per, but not on the implementation of the security elementslocated inside the transversal layer. In addition, if we donot define interfaces that access functional parts of the ele-ments of the architecture (such as sending messages througha communication channel), then it will not be possible tobypass the layered structure of an architecture through thetransversal layer.

4.1. Benefits and applicability oftransversal layers

By using the transversal layer approach, it can be possibleto retain most of the benefits of a layered architecture. Allthe security mechanisms and services are contained withinthe transversal layer, thus the modularity of the system ispreserved. Besides, the transversal layer should only beaccessed through well-defined interfaces, thus any compo-nent/layer of the system, located either inside or outside thetransversal layer, will know how to interoperate with them in



advance. In addition, since the transversal layer is isolatedfrom the other layers, and even the internal componentsof the transversal layer can only access other componentsthrough their interfaces, it can be possible to either modifyof upgrade the internal design of the layer without interfer-ing with the other elements of the architecture. Note alsothat a layer cannot use the transversal layer as a bridge toaccess the services of unconnected layers, thus there is norisk of hidden dependencies.

The benefits of cross-layer architectures are also main-tained by the transversal layer. The services containedwithin the transversal layer can access information pub-lished by the services of other layers, thus having a holisticpoint of view of the state of the device. For example, a situ-ation awareness service, in charge of monitoring the actualstate of a node and its neighbourhood, can retrieve node sta-tus information from other layers. The external layers canalso benefit from this transversal approach in many ways.First, since there is just one instance of a security mechanism(e.g. a cryptographic primitive), there is no need to replicateits functionality in order to implement different protectionmechanisms (e.g. link layer protection and end to end pro-tection). Second, all security mechanisms and services canbe accessed by all the layers of the architecture. As a result,it can be possible to implement more effective protectionprocedures. For example, if an intrusion detection system isincluded in the architecture, both applications and commu-nication protocols can use its outputs to limit any interactionwith rogue nodes.

Finally, the possible disadvantages that may exist when-ever cross-layer relationships are included in an architectureare reduced when using the transversal layer. The informa-tion flow between the transversal layer and other layersis delimited by well-defined interfaces, thus interactionsamongst existing layers are no longer subtle. Any changeinside the elements of the transversal layer must adhere tothe definition of the interfaces, thus the chances of break-ing the design of the whole architecture are slim. This levelof isolation also limits the possible dependencies that mayappear between layers after a change takes place.

Not only the transversal layer retains the benefits ofboth layered and cross-layer architectures, but also it canbe integrated within both types. In layered communicationarchitectures, the existence of a transversal layer contain-ing the security services will allow the modification of thoseservices according to the requirements of the applications(e.g. choose a different security primitive) without caus-ing collateral effects that may negatively affect the otherlayers. In addition, it can be possible to add new security ser-vices derived from the necessities of the applications and/orlong-term academic research.

On the other hand, in cross-layer architectures, the secu-rity layer behaves as another component of the architecturethat can be accessed from any other component, provingsecurity-related services and information. By centraliz-ing all security services inside one single component, wecan improve the overall stability and maintainability ofthe architecture, and also we can provide a better control

over the possible interactions and dependencies that mayarise.

5. IMPLEMENTING TRANSVERSALLAYERS: THE SMEPPARCHITECTURE

We have applied the concept of a transversal layer con-taining security mechanisms to a complex middlewarearchitecture, developed under the European project SMEPP(Secure Middleware for Embedded Peer-to-Peer systems,FP6-IST-033563) [20]. The main purpose of this middle-ware is to allow the development of secure applicationsfor different types of embedded devices interacting in aP2P fashion without any pre-existing infrastructures. Thisparticular paradigm is known as Embedded Peer-to-Peer(EP2P) system.

The general SMEPP Middleware architecture is shownin Figure 3. It is divided into three functional layers. Thetop layer consists of the Domain-specific Middleware ser-vices and the Service Model Support that provide the actualAPI for application developers for using the SMEPP Mid-dleware. The second layer from the top is the CommonMiddleware Services that provides the actual functionalityof the Middleware defined by the service model. Finally,the bottom layer is the distribution middleware that containsall the framework implementations needed by the Middle-ware services for providing the required functionalities. Onsensor networks, the architecture is simplified to containonly those components that are useful to obtaining andprocessing data in a local environment, and it is knownas SMEPPLight. This lightweight architecture retains thecomponents related to Groups, Events, Topology and Secu-rity.

Regarding security, in both SMEPP and its lightweightimplementation SMEPPLight it is considered as a transver-sal layer that can be accessed by all the services of themiddleware. This point of view coincides with the approachpresented in Section 4. The principal security componentsin this architecture contained within the transversal layerare the following:

� Group Security is concerned with the security relatedaspects of group establishment and maintenance. InSMEPP, the members of the network can join cer-tain groups, and they can access to the services ofother peers only if they belong to the same group.This component is responsible for both the authentica-tion of peers which want to join these groups and thesecure communication amongst group members. Asthis component is isolated from the actual componentthat manages the groups, it is possible to implementdifferent levels of security (e.g. joining a group usingeither symmetric keys or public/private key pairs) with-out modifying the entire architecture, and differentgroups can have a different level of protection accord-ing to their own security requirements. Besides,this



Streaming NW Browsing

Extensions Service Model Support

SMEPP API Languages/ Tools

SMEPP Common Services

Service Management Group Management Overlay Network Mgmt.

Extension Management Event Management

SMEPP Enabling Services (SMEPP distribution MW)

Secure High Level Peer Communication (SHLPC)

Topology Management

Adaptation Layer

SMEPPSecurity

Group Security

CryptographicServices

Infrastructure Security

APPLICATIONS AND SERVICES

VIRTUAL MACHINES / OPERATING SYSTEM

Figure 3. An Overview of the SMEPP functional structure.

component does not send any information through thenetwork, thus there is no hidden interdependencieswith the lower layers.

� Cryptographic Services provide common function-ality which is required by other components (e.g.Secure Topology Management, Group Security).This includes cryptographic primitives (encryp-tion/decryption, digital signatures, Message Authen-tication Codes, unkeyed hash functions) as well assupporting functions (random number generation, keystorage, certificate management). As there is one singleinstance of every primitive, located within this com-ponent, there is no need to replicate their functionalityover all the architecture. Besides, since the servicesoffered by this component are provided through well-defined interfaces, it is a simple task to replace theprimitives located within the component.

� Infrastructure Security encompasses device-specificsupport for security functionality which facilitatesthe implementation of the security-related compo-nents. An important example are secure instruction sets(instruction set extensions for cryptography), whichspeed up cryptographic processing. These features canbe used to realize the Cryptographic Services more effi-ciently, which in turn reduces the overhead incurredin all security-related components. This componentneeds to be rewritten for every specific device wherethe middleware is implemented, but any changes willnot affect the other components of the architecture.

As an example of the relationship between this securitylayer and other services, we can mention the Group Securitycomponent. Its services are used by the SMEPP Common

Services layer (Group Management component, authenti-cates a certain peer) and by the SMEPP Distribution MWlayer (Secure High Level Peer Communication component,protects the messages of a group). Regarding the interac-tion between components inside the same security layer,the Cryptographic Services component will use the cryp-tography extensions located in the Infrastructure Securitycomponent if available. If the design is changed and newcryptographic extensions are available, there is no need tochange the whole architecture: the Cryptographic Servicescomponent will simply use the new extensions.

5.1. Implementation and prototypes

The SMEPP middleware has been successfully imple-mented and tested by the SMEPP consortium in bothhigh-end devices (PCs), PDA-like devices and sensordevices. For high-end devices we have used Java SE tech-nology, while for PDA-like devices we have used JavaME technology with the Connected Device Configuration(CDC) framework. On sensor networks, we have used nesCover TinyOS, and the memory footprint of the SMEPPLightmiddleware (56KB RAM, 2944B ROM) is good enoughto implement secure applications for MICAz-class nodes(128KB RAM, 4-8KB ROM).

Both the Java implementation (through the UM-RTCOMcomponent model [21]) and the nesC implementation usecomponent-oriented programming, thus the interfaces ofthe transversal layer can be appropriately defined. Theinterfaces of the different primitives and protocols of thetransversal layer are defined independently of their specificimplementations, allowing extensibility and reusability.



For example, all the different security levels (no security,authentication through shared keys, authentication throughpublic key cryptography) of the Group Security componentare implemented using different protocols (the ISO/IEC9798-2 standard [22] and a modified Needham-Schroeder-Lowe protocol [23]), but are provided through a singlenegotiationStep() method. This way, in order to joina group, the Group Management component can choose acertain security level without changing its implementationlogic.

The mechanisms that are located inside the transversallayer are also adapted to the capabilities of the differentdevices. For example, the SMEPP middleware includes allthe different security levels and primitives implemented,while the SMEPPLight version of the middleware only sup-port group authentication through shared keys and supportfor public key cryptography can be excluded. Note that ifa specific application does not need to use a security level,such level can be deleted at design time, thus reducing thesize of the overall middleware.

The consortium have also created various prototypes totest the viability of the SMEPP middleware as a frameworkfor the development of secure EP2P applications. Thoseprototypes are digital home services with mobile devicesand nuclear power plant monitoring [24]. Our digital homeprototype is focused on elderly care, where either the useror the system itself can raise an alarm when an exceptionalsituation arises. Using the group capabilities of SMEPP, itis possible to discover an user (e.g. a member of the family)that can accept the alarm. Once a communication chan-nel is established, both users can securely exchange textmessages, images and/or video streams.

As for nuclear power plant monitoring, we concentrateon Dosimetric Control and Environmental RadiologicalControl. A network of operators wearing SMEPP-enableddosimeters can provide real-time information on the radi-ation levels of the power plant, and the EP2P capabilitiesof the network allows an efficient response if any operatorgets exposed to harmful levels of radiation. Besides, in caseof an emergency, more devices can be scattered to get anaccurate information on the state of the power plant. All theinteractions between the devices are protected by using thesecurity capabilities of the SMEPP middleware.

6. CONCLUSIONS

The integration of security mechanisms and protocols insidethe software architecture and network stack of a sensor net-work is not a trivial issue. In this paper, we have presentedthe concept of a transversal layer, where all the differ-ent security mechanisms are contained. This way, all theelements of an architecture can interact with the securitymechanisms, and the security mechanisms can have a holis-tic point of view of the whole architecture. In addition, thisconcept of a transversal layer has been successfully imple-mented and tested in a middleware architecture developedunder the European project SMEPP [20].

The transversal layer retains the benefits of layered archi-tectures (modularity, interoperability, design longevity),while the advantages of cross-layer architectures (optimiza-tion, tunable design) are maintained and its disadvantages(hidden dependencies, poor design) are adequately con-trolled. Note that the transversal layer approach has all thesebenefits because the major purpose of the security mecha-nisms is to provide services to the different elements ofthe architecture, and they only access other elements eitherto obtain information regarding the state of the device orto signal an event. Future research includes analysing howthis transversal layer concept could help on optimizing theprovisioning of security when using specific sensor networkprotocols such as 6LoWPAN [25].

ACKNOWLEDGEMENTS

This work has been partially supported by the Euro-pean Union through the SMEPP (EU-FP6-IST 0333563)project and by the Spanish Ministry of Science and Inno-vation through the ARES (CSD2007-00004) and SPRINT(TIN2009-09237) projects. The latter is co-financed byFEDER (European Regional Development Fund).

REFERENCES

1. Crossbow Technology, Inc. eKo Pro - Precision Agricul-ture. Available at: http://www.xbow.com/eko/[accessedon 20th February 2009].

2. Cadi Scientific Pte Ltd. CADI SmartSenseTM. Availableat: http://www.cadi.com.sg[accessed on 20th February2009].

3. Melodia T, Pompili D, Gungor VC, Akyildiz IF. Com-munication and coordination in wireless sensor andactor networks. IEEE Transactions on Mobile Computing

2007; 6(10): 1116–1129.4. Lanbo L, Shengli Z, Jun-Hong C. Prospects and problems

of wireless communication for underwater sensor net-works. Wireless Communications and Mobile Computing

2008; 8(8): 977–994.5. Brogi A, Popescu R, Gutierrez F, Lopez P, Pimentel E. A

service-oriented model for embedded peer-to-peer sys-tems. Electronic Notes in Theoretical Computer Science

2008; 194(4): 5–22.6. Srivastava V, Motani M. Cross-layer design: a survey and

the road ahead. IEEE Communications Magazine 2005;43(12): 112–119.

7. Kawadia V, Kumar PR. A cautionary perspective oncross-layer design. IEEE Wireless Communications

2005; 12(1): 3–11.8. Akyildiz IF, Su W, Sankarasubramaniam Y, Cayirci E.

Wireless sensor networks: a survey. Computer Networks:



The International Journal of Computer and Telecommu-

nications Networking 2002; 38(4): 393–422.9. Akyildiz IF, Vuran MC, Akan OB. A cross-layer protocol

for wireless sensor networks. Proceedings of the 40th

Annual Conference on Information Sciences and Systems,2006; 1102–1107.

10. Marron PJ, Minder D, Lachenmann A, Rothermel K.TinyCubus: an adaptive cross-layer framework for sen-sor networks. IT—Information Technology Journal 2005;47(2): 87–97.

11. Culler D, Dutta P, Tien Ee C, et al. Towards a sensornetwork architecture: lowering the waistline. Proceed-

ings of the 10th Workshop on Hot Topics in Operating

Systems—HotOS X, 2005; 139–144.12. Kumar R. Adaptable protocol stack architecture for future

sensor networks. Ph.D. Thesis, Georgia Institute of Tech-nology, 2006.

13. Levis P, Madden S, Polastre J, et al. TinyOS: an operat-ing system for sensor networks. In Ambient Intelligence,Weber W, Rabaey J, Aarts E (eds). Springer: Berlin Hei-delberg, 2005; 115–148.

14. ZigBee Alliance. ZigBee Specification. Available at:http://www.zigbee.org/ [accessed on 20th February2009].

15. Walters JP, Liang Z, Shi W, Chaudhary V. Wireless sensornetwork security: a survey. In Security in Distributed,

Grid, and Pervasive Computing, Xiao Y (ed.). AuerbachPublications: CRC Press, 2006; 367–410.

16. Chung A, Roedig U. DHB-KEY: an efficient key distri-bution scheme for wireless sensor networks. Proceedings

of the 4th IEEE International Workshop on Wireless

and Sensor Networks Security—WSNS2008, 2008; 840–846.

17. Luk M, Mezzour G, Perrig A, Gligor V. MiniSec: a securesensor network communication architecture. Proceed-

ings of the 6th International Conference on Information

Processing in Sensor Networks—IPSN’07, 2007; 479–488.

18. Bonne Rasmussen K, Capkun S. Implications of radiofingerprinting on the security of sensor networks.Proceedings of the 3rd International Conference on

Security and Privacy in Communications Networks—

SecureComm’07, 2007; 331–340.19. Java Cryptography Architecture (JCA) Reference

Guide. Available at: http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html[accessed on 20th February 2009].

20. SMEPP Consortium. Secure Middleware for Embed-ded Peer-to-Peer Systems, FP6-IST-033563. Availableat: http://www.smepp.org/ [accessed on 20th February2009].

21. Diaz M, Garrido D, Llopis L, Rus F, Troya JM. UM-RTCOM: an analyzable component model for real-time

distributed systems. Journal of Systems and Software

2008; 81(5): 709–726.22. International Organization for Standardization, ISO/IEC

9798-2:2008. Mechanisms Using Symmetric Encipher-

ment Algorithms, 2008.23. Lowe G. Breaking and fixing the Needham–Schroeder

public-key protocol using FDR. Proceedings of the 2nd

International Conference on Tools and Algorithms for

the Construction and Analysis of Systems—TACAS, 1996;147–166.

24. Crossbow Solutions Blog. RadMote—Mobile Frame-work for Radiation Monitoring. Available at: http://blog.xbow.com/xblog/2007/12/radmote—mobil.html [acce-ssed on 20th February 2009].

25. Kushalnagar N, Montenegro G, Schumacher C. IPv6 over

Low-Power Wireless Personal Area Networks (6LoW-

PANs): RFC 4919, August 2007.

AUTHORS’ BIOGRAPHIES

Rodrigo Roman is a postdoctoralresearcher working at the University ofMalaga, where he obtained his Ph.D. inComputer Science on 2008. Previously,between 2003 and 2005, he workedat the Institute of Infocomm Research(I2R) in Singapore on the topic ofSensor Network Security, which isnowadays his primary research area.

At present, he is also focusing on security for ubiquitousand pervasive computing and in critical information infras-tructure protection. Dr Roman has participated in variousSpanish and international research projects in those areas,including projects in FP6 and FP7 European Programmes.

Professor Javier Lopez received hisM.Sc. and Ph.D. degrees in ComputerScience in 1992 and 2000, respectively,from University of Malaga, and workedas a system analyst in the private sec-tor from 1991 to 1994. He is currentlya Full Professor and Head of Depart-ment, and during last 10 years hasdeveloped part of his research in USA,

Japan and Australia. His activities are mainly focused onnetwork security and critical information infrastructures,leading a number of national and international researchprojects in those areas, including projects in FP5, FP6and FP7 European Programmes. Professor Lopez is theCo-Editor in Chief of International Journal of Informa-tion Security (IJIS) and Spanish representative in theIFIP Technical Committee 11 on Security and Protec-tion in Information Systems. Besides, he is member ofthe editorial board of, amongst others, the SCI-indexedjournals Computers & Security, Computer Networks,



Wireless Communications and Mobile Computing, Com-puter Communications, Journal of Network and ComputerApplications and International Journal of CommunicationSystems.

Pablo Najera is a Ph.D. candidate inComputer Science at the University ofMalaga, Spain. He graduated with hon-ors as a Computer Science Engineerfrom the University of Malaga in 2006.He was awarded the most outstandingstudent of the year when he graduated.In 2007, he also obtained, with honors,a Master in Software Engineering and

Artificial Intelligence. Working in the Computer ScienceDepartment, he has participated in various internationalresearch projects, doing research on RFID technology,applications and privacy issues. At this moment he is pursu-ing his Ph.D. degree on Computer Engineering obtaining aGraduate Research Assistant Fellowship from the SpanishMinistry of Science and Education. The topic of his Ph.D. isthe design of security mechanisms for ubiquitous scenariosin personal area networks.


a cross-layer approach for integrating security mechanisms in sensor networks architectures

Documents