Agent-based Scalable Design of a Cross-Layer Security Framework for Wireless Sensor Networks Monitoring Applications Marco Pugliese, Luigi Pomante, Fortunato Santucci Center of Excellence DEWS University of L’Aquila L’Aquila, Italy
[email protected], {luigi.pomante, fortunato.santucci}@univaq.it Abstract—Secure monitoring services supported by flexible, manageable, and cheap systems in areas where ordinary networks are unsuitable: this is one of to-day challenges in health monitoring engineering. Wireless Sensor Networks represent a promising technological solution but resource constraints and exposure to external attacks could limit their employment. The design and the implementation of an effective security to provide the monitoring service with the reasonable level of reliability is the scope of this paper. Following the platform-based design methodology, we have designed and implemented a “Secure Platform” to support Monitoring Applications which is compliant to requirements such as modularity, optimized usage of resource, solution scalability. To this aim, the Secure Platform exploits mobile agents and we have enhanced middleware solutions already available in literature. Security functions implemented in the Secure Platform have been a distributed intrusion detection system, based on a simplified approach to Hidden Markov Models, supported by an hybrid cryptographic scheme, based on network topology authentication. These security functions have been proposed by the same authors in [12] and [13]. Detailed design and the description of the software enhancements to the middleware platform are presented in this paper. Keywords—Security Framework; Wireless Sensor Network; Platform-based design; Mobile Agent; Middleware Layer; Hybrid Cryptography; Intrusion Detection; Anomaly Detection.
I.
INTRODUCTION
Wireless Sensor Networks can be successfully employed in many monitoring applications, for different scenarios, e.g. for home-land security and counterterrorism (infrastructure and critical buildings integrity). Monitoring services are based on the detection of anomalies on the monitored system (or environment) due to exceptional events occurring in the monitored environment or to malicious attacks. This paper is focused on the design issues of the security framework to be implemented shared on the nodes of a WSN. Currently some early implementations related to middleware functional enhancements have been carried on. The platformbased design methodology, introduced in [16], has been followed resulting in the availability of a “Secure Platform”: this module includes the functions of intrusion detection and crypto-secured links, the former based on Weak Process
Models, a simplified version of the Hidden Markov Models, and the latter based on network topology authentication. In [12] and [13] the security analysis and the comparison with other state-of-art security mechanisms can be found. The distributed nature of intrusion detection systems led us to consider an agent based approach to its implementation over the network. Among the agent-based middleware solutions available from literature, e.g. [8], we refer to AGILLA, a mobile agent based middleware solution proposed in [1] [4], which complies with almost all functional requirements for the Secure Platform. Full compliancy implies some functional upgrades to AGILLA architecture which have been proposed and applied. The main contribution of this paper is in the SW design and implementation approach of security mechanisms “directly” on the WSN, i.e. on a resource constrained network, without the support of external “resource unconstrained” facilities. Very few similar contributions can be found in literature as the most put intelligence (usually most resource consuming in computational and memory terms) outside the WSN and WSN is reduced to a mere transport layer. On the contrary, we believe and we are going to show experimentally that, under certain limitations, a WSN can be functionally “autonomous” not only for sensing operations. This paper is organized as follows: Sections II and III deal with the platform-based design approach to the Secure Platform; Sections IV and V deal with the introduced architectural upgrades and enhancements to AGILLA solution. II.
PLATFORM-BASED DESIGN
The reference platform-based architecture of the proposed WSN-based Monitoring System is shown in Fig. 1. The adoption of a platform-based design results in the availability of a software platform which is the basis for the development of further service components and security enhancements. The platform-based design methodology differentiates very clearly the roles for functions and for the architecture. A system implements a set of functions; a function is an abstract view of the behavior of the system. An architecture is a set of components, either abstract or with a physical dimension, that is used to implement a function.
Applications
Agent-based Applications
Application A2
Application A1
Application An
Agent A1
AgentA2
AgentAn
Application Execution Environment (AEE) Local memory
Shared memory MW services
SW component
SW component
Mobile Agent Application Execution Environment (MA-AEE) Local memory
Shared memory MA-MW services
Secure Platform
SW component
SW component
Secure Platform Sensor Node
Sensor Node
Sensor Node
Sensor Node
Sensor Node
Underlying WSN Deployment
Sensor Node
Sensor Node
We adopt a mobile agent architecture to design and develop the proposed Secure Platform. Resource constraints and topology dynamics in WSN imply restrictions for the software architectural choices where fundamental requirements are distribution, flexibility and scalability. We will show that the agent based middleware proposed in [4] optimizes the design of distributed applications on clustered sensor networks. Cluster heads are not permanently assigned to specific nodes but dynamically re-assigned to any node according to eligibility criteria. This justifies our choice of agents. A key concept from [4] is agent migration. During cloning, it copies its code and state to another node (strong cloning) and resumes executing on both the old and new nodes. Mobile agents support datacentric applications. Code migrates towards data independently from node addressing. Applications distribution through mobile agents results much less costly compared to traditional data broadcasting or code diffusion approaches. From [4] we recall the concept of “tuple space” as a local memory shared by local agents. Zooming on the Secure Platform layer, Fig. 2 represents its internal architecture when applications are designed and implemented through Mobile Agents: in this case the application execution environment is denoted by MA-AEE (Mobile Agent-AEE). Mobile agents implement cluster-domain functions while SW components implement single nodedomain functions.
Sensor Node
Underlying WSN Deployment
Fig. 1 Reference platform-based architecture of the Monitoring System
A component is an element with specified interfaces and explicit context dependency [16]. The internal platform structure is composed by “interconnected” static software “components” (SW components) which represent abstractions of the “wired” hardware “components”. Each SW component offers a set of API to the upper Application Execution Environment (AEE), the software environment where the applications are developed and executed. AEE is mainly composed by the MW services set with the support of a shared memory. Functions of each SW Component are mapped into the underlying deployed Sensor Nodes. To greatly simplify routing protocol we adopt a clustered network topology for the underlying WSN: cluster heads host functions related to the cluster as a whole while ordinary cluster members host nodespecific functions.
Sensor Node
Sensor Node
Fig. 2 Mobile Agent-based Secure Platform Architecture
III.
SECURE PLATFORM INTERNAL ARCHITECTURE
In this section we define the security functions associated to mobile agents and SW components. ID Threat Model IRL Local Configuration Data
Anomaly Detection Logic
Defence Strategy
Audit Data
Alarm Tracking
IRLA Countermeasure Application
Fig. 3 IDS functional blocks
In [13] a novel scheme for ID has been proposed based on Weak Process Models [7] [9] [17], a simplified version of the well-known Hidden Markov Models [3] [15]. Fig. 3 depicts the functional architecture adopted in [13] for IDS [2]: Intrusion Detection (ID) block includes the functions to detect anomalies from the audit information and generate alarms; the Threat Model (TM) block implements the WPM-based model for abnormal system behaviour and the Anomaly Detection Logic (ADL) block implements detection and alarm generation functions. The Intrusion Reaction Logic (IRL) schedules the intervention priority toward the compromised nodes according to specific criteria (defence strategy) [10]. Finally, IRLA applies the countermeasures against attacks to compromised nodes, including node isolations (quarantine), key revocations, link release or inclusions in black lists / grey lists. Local Configuration Data (LCD) indicates specific settings for each node to be applied to the security mechanisms in the platform. The mapping between IDS functions and SW components and agent components is the following: ADL and TM blocks are mapped into SW components while IRL and IRLA blocks into a mobile agent, which is denoted by Intrusion Reaction Agent (IRA). SW component are indicated with smoothed squares (Fig. 4). This design allows the optimal allocation and
code distribution for those functions that should not be implemented anywhere: IRA agents will be hosted only on WSN cluster heads. Fig. 5 gives the external characterization of our WPMbased IDS: at the observation step k, audit data are applied to a set of Anomaly Rules (implemented in the ADL Component). An Anomaly Rule can give two possible results: “no anomalies”, resulting in the message being processed further, or “anomaly detected” resulting in a “threat observable” o k (Fig. 5). Each produced threat observable enters into TM Component where the “estimated current state” x k is computed and issued to ADL again. The estimation algorithm introduced in [13] is much lighter respect to Viterbi algorithm [5] and identifies the possible states sequences (rather than the most probable states trace as Viterbi estimator returns). A weighting score s k is associated to each possible states sequence states up to o k : if the score s k results greater than a certain threshold, an alarm, indicated with Al[s k ] , is therefore generated and issued to IRL. Threat Model
Local Conf. Data
Anomaly Detection Logic
Defense Strategy
Audit Data
Alarm Tracking
modules. In [12] a novel scheme for data-link cryptography based on network topology authentication (Topology Authenticated Key Scheme, TAKS) has been proposed. Once generated, the cryptographic key is managed by the TinySec layer [11], [18]. cm[sk]
msg
Fig. 4 Mobile Agent based IDS Architecture
TAK Fig. 6 External characterization of TAKS block
Fig. 6 gives its external characterization. If a control message (msg) enters the TAKS Component, the key management protocol looks for the relevant cryptographic parameters into LCD to start node authentication and, if successful, the key is generated and a ciphered link is established. Moreover, TAKS component processes IRLA countermeasures, indicated with cm[s k ] , by translating the command into a signalling procedure to revoke / update keys and, definitively, to release data-links. The complete internal structure of the Secure Platform is depicted in Fig. 7 where IDS and TAKS blocks are integrated.
IV.
PLATFORM BASED DESIGN USING AGILLA AGENTS
1.
Tuple Space, which supports inter-agent communications: each agent can read and write information into the local tuple space or into the remote Tuple Space on a neighboring node (included in the Neighbors List).
2.
Neighbor List, which defines the cluster members. Each Tuple Space on the nodes included in the Neighbor List can be accessed by the Agent hosted on the node where the Neighbor List is stored;
3.
Agent Migration (strong or weak migration dependently if the current execution state is ported on the other node or not) between a node and the nodes included in its Neighbor List.
ID
Threat Model
Local Conf. Data
Local Conf. Data
The middleware AGILLA [1] [4] provides several functions; here we list those useful for our purposes: Countermeasure Application
ok
TAKS
xk
Anomaly Detection Logic
Al[sk]
msg
Audit Data Fig. 5 External characterization of IDS block
Now we focus on the cryptographic scheme that supports secured data exchange among the Secure Platform distributed
Current version of AGILLA does not implement a direct interface with any external SW Component, i.e. it is not possible to directly write or read data into a Tuple Space or into a Neighbor List which, instead, are managed by the AGILLA Manager [1].
distance between two consecutive CHs is always 1 no matter network size.
Defense Strategy
al[sk]
Agent-based Applications
Alarm Tracking
Agent A1
AgentA2
Countermeasure Application
AGILLA MA-AEE
cm[sk]
TAKS
Local memory
Tuple space
MA-AEE cm[sk]
AGILLA services
al[sk] ok
msgs xk Local Conf. Data
AgentAn
Threat Model
Anomaly Detection Logic
SW component
SW component
Secure Platform Sensor Node
Sensor Node
Sensor Node
Sensor Node
Sensor Node
Underlying WSN Deployment
ID
Fig. 8 Enhanced AGILLA Mobile Agent-based Secure Platform Architecture
Agent-based Applications
msgs
TAK
Fig. 7 Mobile Agent component-based internal structure
IRA
A. Enhancements to AGILLA middleware Therefore the upgrades we applied to AGILLA architecture are the development of interfaces between any external SW component to:
Communication Unit;
Neighbors List;
Tuple Space.
Enhancements have been implemented as an embedded SW stub developed in NesC [6]. Fig. 8 schematically represents this interface as a bold line joining the SW component to the AGILLA MA-AEE. Fig. 9 shows the definitive internal structure for the Secure Platform. The agent diffusion mechanism across the network is the following: as soon as a node becomes a CH, an IRA migrates from the parent node to this node. Therefore the agent reads alarms and observables from the Remote Tuple Space (we can say that IRA has detected and then aggregated alarm and observables from its CM); in the latter scenario, as soon as the CM has become CH, the IRA (weakly) clones itself toward this new CH and reads alarms and observables from the Remote Tuple Space on the new joined CM. If an Anomaly Rule is structured such that an observable can propagate from a node to its parent node (i.e. from a CM to its own CH), we can generate an “observable back-propagation” effect from any sensor node to the base station. This effect may allow IDS to detect “cooperative” threats attacking “topologically” distant nodes in the network [13]. It is important to understand that the implementation cost does not depend on cluster size (in terms of number of member nodes); although we supposed a spanning tree topology, which implies certain constraints for agent mobility, it is important to take into account that the logic
AGILLA MA-AEE Local memory
Tuple space AGILLA services
ID
TAKS
Fig. 9 Definitive Mobile Agent-based Secure Platform Architecture
V.
IMPLEMENTATION ISSUES
As discussed above, in order to fully exploit the AGILLA middleware for the implementation of the proposed security framework, some of the highlighted AGILLA limitations should be removed in order to make the proposed approach effective. The first issue that has been actually addressed is related to the interface with the Communication Unit. In particular, the first enhancement made to AGILLA has been to add some basic mechanisms to make able the agents to retrieve some information about the radio traffic from the nodes. More in detail:
The node-resident part of the middleware has been modified in order to allow the evaluation of some indicators, customizable by the designer, based on the analysis of the radio traffic (e.g. Al[sk]);
The interface of the middleware towards the agents has been modified to allow an agent to retrieve the value of such indicators by pushing them on its stack.
In this way, the agents are able to check for anomalous values (i.e. alarm), as described in the previous sections. Moreover, this possibility has been added while keeping the
existing interaction mechanisms between agents and nodes: the agent sees the added indicators as virtual sensors (Fig. 10) accessible as if they were normal sensors (i.e. light, temperature, etc…) by means of the sense instruction. Stack
Agent
Radio Traffic
Radio Traffic Indicators
Radio
Fig. 12 AGILLA architecture
Node (SW) Node (HW)
Sensors
typedef struct AgillaReading { uint16_t type; uint16_t reading; } AgillaReading; Fig. 13 “Agilla reading” structure
Fig. 10 Virtual sensor architecture
As a very simple example, if each node evaluates the number of received packets, an agent could retrieve such an information as shown in Fig. 11. It is worth noting that the approach is exactly the same used to read the temperature sensor. In the sample code the agent turns on the red led when the number of received packets is greater than 10. In order to make such a first extension to the AGILLA framework, a deep study (that will be very useful for future work) of the original architecture has been performed. First of all, it has been needed to understand the mapping mechanisms between AGILLA instructions and nesC components: each instruction is implemented by a component, stored in the opcodes directory, that offers the BytecodeI interface that includes the execute command. Such a command is called to execute an instruction that is identified by the codes stored in AgillaOpcodes.h used as parameters for the interface. Fig. 12 shows the overall architecture of the AGILLA middleware. Then, for our goal, it has been modified the implementation of the sense instructions. In particular, since this one is dependent of the actual sensor board installed on a node, for practical reasons, we have considered the OPsenseMTS310CA and OPsenseDummy implementations. The main section of the implementations is related to the use of the OpStackI.popOperand command that retrieve from the stack the sensor number so initializing a proper structure, called AgillaReading (Fig. 13), used to collect sensor readings. SENSE SENSE
SENSE
pushc temp sense halt
pushc num_packets sense halt
pushc num_packets sense pushcl 10 cgt rjumpc ONGREEN ONRED pushc 1 putled pushc SENSE jumps ONGREEN pushc 2 putled pushc SENSE jumps
Fig. 11 Virtual sensor equivalence and access
/* Sensor’s IDs for MTS310 board */ typedef enum { AGILLA_STYPE_ANY = 0, AGILLA_STYPE_SOUNDER = 0, AGILLA_STYPE_PHOTO = 1, AGILLA_STYPE_TEMP = 2, AGILLA_STYPE_MIC = 3, AGILLA_STYPE_MAGX = 4, AGILLA_STYPE_MAGY = 5, AGILLA_STYPE_ACCELX = 6, AGILLA_STYPE_ACCELY = 7, AGILLA_STYPE_NUM_PACKETS = 8, //NEW } AgillaSensorType; Fig. 14 “Agilla Sensor Type” structure
By means of the type field, the execute function calls the right getData in order to retrieve the correspondent value. So, it is possible to introduce new (virtual) sensors by adding new elements in the AgillaSensorType structure (Fig. 14) defined in the file Agilla.h and by defining a proper getData to be called in the execute function. The TinyOS 1.x interface that defines commands and events for the sensors management is ADC. The OPsenseMTS310CAM component provides an alias for each sensor and manages the dataReady event by calling the saveData function that fills the reading field of the struct AgillaReading. Then, saveData posts the task senseDone that then calls the pushReading function to push the read value (real or virtual) on the agent stack. Finally, we have identified the AGILLA component where it is possible to access to all the details about the radio traffic. It is called NetworkInterfaceM and it is the starting point for the evaluation of the desired indicators. A. Validation In order to validate the first AGILLA extensions and to give the flavour as it could be possible to exploit them to build an IDS following the design described in the previous sections, the following shows a sample agent-based application. More in details, as discussed before, by means of the middleware the agents access to some information about the radio traffic (i.e. in this case just the number of the packets received by a node) like
if they were sensor readings and reacts, as specified by the whole applications, on the base of the values read. The demo application (Fig. 15) is then based on a sample WSN composed of 4 MicaZ nodes and a MIB510 board (connected to a PC) where 3 Agilla agents are injected for monitoring purposes. Such agents exploit the proposed middleware extensions and the Agilla reaction mechanism while moving on the WSN. The final goal is to detect the nodes that present one or more radio traffic indicators out of standard value (i.e. in this case the agents checks for a number of received packets greater than a defined threshold). The agents developed for such a purpose, called TupleOut, Dynamic and Alarm, are described in the following.
BEGIN
OUT
REDTGL
// INIT pushc 0 setvar 0 // MANAGEMENT pushc 25 putled // Red led on getvar 0 copy inc setvar 0 // CHECK pushc num_packets // ID of the virtual sensor sense // Read the virtual sensor pushcl 5 // Threshold cgt rjumpc OUT // If > Threshold go to OUT pushc BEGIN // Else go to BEGIN jumps // ALARM pushc num_packets // ID of the virtual sensor sense pushc 2 // Number of tuple fields out // Insert the alarm tuple rjumpc REDTOGGLE // EXIT (ERROR) halt // EXIT (OK) pushc 8 sleep pushc 25 putled halt
Fig. 16 TupleOut agent pusht VALUE // Type pushrt num_packets // Sensor ID pushc 2 // Number of fields pushc DO regrxn Fig. 17 Agilla reaction Fig. 15 Demo application architecture
TupleOut is a static agent, virtually present on each node to be monitored, that access to the radio traffic indicators evaluated by the node-side middleware, checks for anomalous values and insert a proper tuple on the tuple space of the node to signal an eventual alarm. In the proposed example the agents injected on the node #1 checks for a number of received packets greater than 5 and, when such a case, it inserts the alarm tuple on the Tuple Space of the node #1 (the agent code is shown in Fig. 16). Dynamic is a dynamic (strong move in the whole WSN nodes) agent that looks for alarm tuples in the nodes tuple spaces. It exploits a template-based match by type reaction (Fig. 17) to detect an alarm tuple and then to eventually send to the Alarm agent (see below) the alarmed node ID. Finally, the Alarm agent is a static one that resides in the base station of the WSN (node #0). It receives alarm signals and alarmed node IDs and manages them. In the example, it simply displays by means of the leds the alarmed node ID and sends also such an information to the connected PC.
This simple demo application has been very useful to validate the extension made to the AGILLA middleware and to give the flavour how could be possible to use AGILLA agents to implement the presented security framework. VI.
CONCLUSION AND FUTURE WORKS
Our contribution is the definitive verticality respect to WSN technology. Our approach to detection is fully distributed with a dynamic hierarchical architecture rather than centralized with a static hierarchical architecture. Security functions are executed autonomously by nodes in the network without any support from outside (like servers or database) and complexity in IDS management is reduced due to the clustered tree topology which avoids overheads for loop checks and polling routines among neighboring nodes. Currently we are carrying on early experimentations on few MicaZ sensor nodes. Moreover we are packing ADL code for WSN development environment. A well-suited application scenario is biomedicine, where WSN are deployed as body area networks and a sink node is integrated in a PDA. In such case, the security and reliability are absolute qualifying indicators for the effectiveness of the monitoring system.
ACKNOWLEDGEMENTS We would like to thank Francesca Falcone and Catia Maiorani, two young engineers of the University of L’Aquila that, during their thesis work, have actively collaborated to some of the design and implementation activities reported in this paper.
[9] [10] [11]
[12]
REFERENCES [1] [2] [3] [4]
[5] [6]
[7] [8]
AGILLA Project, http://mobilab.wustl.edu/projects/agilla/index.html V. Bhuse, and A. Gupta, “Anomaly intrusion detection in wireless sensor networks,” J. High Speed Networks, vol. 15, n. 1, 2006 Y. Ephraim, and N. Merhav, “Hidden Markov Processes”, IEEE Trans. Inform. Theory, vol. 48, no. 6, 2002 C.-L. Fok, G.C. Roman, and C. Lu, “Agilla: A Mobile Agent Middleware for Sensor Networks,” Technical Report, Washington University in St. Louis, WUCSE-2006-16, 2006 G. Forney, “The Viterbi Algorithm,” Proc. IEEE, vol. 61, 1973 D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler, “The nesC Language: A Holistic Approach to Networked Embedded Systems,” In Proc. ACM SIGPLAN 2003 A. Giani, “Detection of Attacks on Cognitive Channels,” Ph.D. Thesis, Dartmouth College, Hanover, NH, 2006 S. Hadim, and M. Nader, “Middleware Challenges and Approaches for Wireless Sensor Networks,” IEEE Distributed Systems on-line 15414922, IEEE Computer Society, vol. 7, n. 3, 2006
[13]
[14] [15] [16]
[17]
[18]
G. Jiang, “Robust Process Detection Using Nonparametric Weak Models,” Intern. J. of Intelligent Control and Systems, vol. 10, 2005 S. Kaplantzis, “Classification Techniques for Network Intrusion Detection,” Technical Report, Monash University, 2004 C. Karlof, N. Shastry, and D. Wagner, “Tinysec: a Link Layer Security Architecture for Wireless Sensor Networks,” In Proc. of SenSys’04, 2004 M. Pugliese, and F. Santucci, “Pair-wise Network Topology Authenticated Hybrid Cryptographic Keys for Wireless Sensor Networks using Vector Algebra,” In Proc. 4th IEEE Intern. Workshop on Wireless Sensor Networks Security (WSNS08), Atlanta, 2008 M. Pugliese, A. Giani, and F. Santucci, “A Weak Process Approach to Anomaly Detection in Wireless Sensor Networks,” In Proc. 1st Intern. Workshop on Sensor Networks (SN08), Virgin Islands, 2008 M. Pugliese, “Managing Security Issues in Advanced Applications of Wireless Sensor Networks,” PhD Thesis, University of L’Aquila, 2008 L. Rabiner, and B. Juang, “An Introduction to Hidden Markov Models,” IEEE ASSP Magazine, 1986 A. Sangiovanni-Vincentelli, and G. Martin, “Platform-based design and software design methodology for embedded systems,” Design & Test of Computers, IEEE, vol. 18, n. 6, 2001 Y. Sheng, and G. Cybenko, “Distance Measures for Nonparametric Weak Process Models,” In Proc. IEEE Intern. Conference on Systems, Man and Cybernetics, vol. 1, 2005 TinyOS, http://www.tinyos.net/
