+ All Categories
Home > Documents > Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller...

Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller...

Date post: 30-Jan-2018
Category:
Upload: phamtuyen
View: 213 times
Download: 0 times
Share this document with a friend
43
10.1 Introduction As we have seen in the previous chapters, the advent of ad hoc networks brought with it a flurry of research primarily focused on communication and protocols in every layer of the protocol stack. Practical applications of this research range from simple chat programs to shared whiteboards and other collaborative schemes. Although intended for diverse audiences and contexts, many of these applications share a common characteristic: they are information- centric. The information transferred may be a trivial conversation between friends, confidential meeting notes shared among corporate executives, or mission-critical military information. Despite the deployment of information-driven applications such as these, the call for ad hoc and sensor network security remains largely unanswered. If a priori trust relationship exists between the nodes of an ad hoc network, entity authentication can be sufficient to assure the correct execution of critical network functions. A priori trust can only exist in a few special scenarios like military networks and corporate networks, where a common, trusted authority manages the network, and requires tamper-proof hardware for the implementation of critical functions. An environment where a common, trusted authority exists is called a managed environment. On the other hand, entity authentication in a large network raises key management requirements. When tamper- proof hardware and strong authentication infrastructure are not available, like for example in an open environment where a common authority that regulates the network does not exist, any node of an ad hoc network can endanger the reliability of basic network functions. The correct operation of the network also requires fair share of the functions by each participating node as power saving is a major concern. The considered threats are thus not just limited to maliciousness, and a new type of misbehavior called selfishness should also be taken into account to prevent nodes that simply do not cooperate. With the lack of a priori trust, a classical network security mechanism based on authentication and access control cannot cope up with selfishness. 1
Transcript
Page 1: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.1 Introduction

As we have seen in the previous chapters, the advent of ad hoc networks brought with it a flurry of research primarily focused on communication and protocols in every layer of the protocol stack. Practical applications of this research range from simple chat programs to shared whiteboards and other collaborative schemes. Although intended for diverse audiences and contexts, many of these applications share a common characteristic: they are information-centric. The information transferred may be a trivial conversation between friends, confidential meeting notes shared among corporate executives, or mission-critical military information. Despite the deployment of information-driven applications such as these, the call for ad hoc and sensor network security remains largely unanswered.

If a priori trust relationship exists between the nodes of an ad hoc network, entity authentication can be sufficient to assure the correct execution of critical network functions. A priori trust can only exist in a few special scenarios like military networks and corporate networks, where a common, trusted authority manages the network, and requires tamper-proof hardware for the implementation of critical functions. An environment where a common, trusted authority exists is called a managed environment. On the other hand, entity authentication in a large network raises key management requirements. When tamper-proof hardware and strong authentication infrastructure are not available, like for example in an open environment where a common authority that regulates the network does not exist, any node of an ad hoc network can endanger the reliability of basic network functions. The correct operation of the network also requires fair share of the functions by each participating node as power saving is a major concern. The considered threats are thus not just limited to maliciousness, and a new type of misbehavior called selfishness should also be taken into account to prevent nodes that simply do not cooperate. With the lack of a priori trust, a classical network security mechanism based on authentication and access control cannot cope up with selfishness.

execution of critical network functions. A priori trust can only exist in a few special scenarios like military networks and corporate networks, where a common, trusted authority manages the network, and requires tamper-proof hardware for the implementation of critical functions. An environment where a common, trusted authority exists is called a managed environment. On the other hand, entity authentication in a large network raises key management requirements. When tamper-proof hardware and strong authentication infrastructure are not available, like for example in an open environment where a common authority that regulates the network does not exist, any node of an ad hoc network can endanger the reliability of basic network functions. The correct operation of the network also requires fair share of the functions by each participating node as power saving is a major concern. The considered threats are thus not just limited to maliciousness, and a new type of misbehavior called selfishness should also be taken into account to prevent nodes that simply do not cooperate. With the lack of a priori trust, a classical network security mechanism based on authentication and access control cannot cope up with selfishness.

1

Page 2: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.2 Distributed Systems Security

10.3 Security in Ad Hoc Networks

As we know, there is no fixed infrastructure in ad hoc networks and as the name implies they are formed on the fly. The devices connect to each other in their own communication range via wireless links. Individual devices act as routers when relaying messages to other distant devices.In this section we give an overview of the security issues over ad hoc and sensor networks

10.3.1 Requirements

The security services of ad hoc networks are not altogether different than those of other network communication paradigms. Below we describe the requirements ad hoc networks must meet.

10.3.1.1 Availability

Availability ensures that the desired network services are available whenever they are needed. Systems that ensure availability seek to combat denial of service (DoS) and energy starvation attacks. In ad hoc networks, ensuring availability is perhaps more important than it is in traditional Internet. As all the devices in the network depend on each other to relay messages, DoS attacks are easy to perpetrate. For example, a malicious user could try to jam or otherwise try to interfere with the flow of information. Or else, the routing protocol should be able to handle both the changing topology of the network and attacks from the malicious users by feeding the network with accurate information.

10.3.1.2 Authorization and Key Management

Authorization is another difficult matter in ad hoc networks. As there is little or no infrastructure, identifying users (e.g., participants in a meeting room) is not an easy task. There are problems with trusted third party schemes and identity-based mechanisms for key agreement. A generic protocol for password authenticated key exchange is described in [Asokan2000]. It has several drawbacks even though it is possible to construct very good authentication mechanisms for ad hoc networks. A password authenticated multi-party Diffie-Hellman key exchange seems to overcome many problems of the generic protocol.

10.3.1.3 Confidentiality and Integrity

Data confidentiality is a core security primitive for ad hoc networks. It ensures that the message cannot be understood by anyone other than the authorized personnel. With wireless communication, anyone can sniff the messages going through the air, and without proper encryption all the information is easily available. On the other hand, without proper authentication, it is difficult to enforce confidentiality. And if the proper authenticity has been established, securing the connection with appropriate keys does not pose a big problem. Data integrity denotes the immaculateness of data sent from one node to another. That is, it ensures that a message sent from node A to node B was not modified during transmission by a malicious node C.

2

Page 3: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.3.1.4 Non-Repudiation

Non-repudiation ensures that the origin of a message cannot deny having sent the message. It is useful for detection and isolation of compromised nodes. When a node A receives an erroneous message from a node B, non-repudiation allows A to accuse B using this message and to convince other nodes that B is compromised.

10.3.2 Security Solutions Constraints

Historically, network security personnel have adopted a centralized, largely protective paradigm to satisfy aforementioned requirements. This is effective because the privileges of every node in the network are managed by dedicated machines - authentication servers, firewalls, etc. - and the professionals who maintain them. Membership in such a network allows individual nodes to operate in an open fashion - sharing sensitive files, allowing incoming network connections - because it is implicitly guaranteed that any malicious user from outside world will not be allowed access.

To be efficiently applicable, security solutions for ad hoc networks should ideally have the following characteristics:

• Lightweight: Solutions should minimize the amount of computation and communication required to ensure the security services to accommodate the limited energy and computational resources of mobile, ad hoc-enabled devices;

• Decentralized: Like ad hoc networks themselves, attempts to secure them must be ad hoc: they must establish security without reference to centralized, persistent entities. Instead, security paradigms should levy the cooperation of all trustworthy nodes in the network;

• Reactive: Ad hoc networks are dynamic. Nodes - trustworthy and malicious - may enter and leave the network spontaneously and unannounced. Security paradigms must react to changes in network state; they must seek to detect compromises and vulnerabilities.

• Fault-Tolerant: Wireless mediums are known to be unreliable; nodes are likely to leave or be compromised without warning. The communication requirements of security solutions should be designed with such faults in mind; they should not rely on message delivery or ordering

10.3.3 Challenges

The wireless links present in an ad hoc network render it susceptible to attacks ranging from passive eavesdropping to active impersonation. Eavesdropping might give an attacker access to secret information, thus violating confidentiality.

As discussed earlier, for high survivability ad hoc networks need to have a distributed architecture with no central entities, which certainly increases vulnerability. Therefore, security mechanism needs to be dynamic, and should be adequately scalable

10.3.3.1 Key Management

Public key systems are generally recognized to have an upper hand in key distribution. In a public key infrastructure, each node has a public/private key pair. A node distributes its public key freely to the

3

Page 4: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

other nodes in the network; however it keeps its private key to only itself. A CA is used for key management and has its own public/private key pair. The CA's public key is known to every network node. The trusted CA is responsible to sign certificates, binding public keys to nodes, and has to stay online to verify the current bindings. The public key of a node should be revoked if this node is no longer trusted or leaves the network. If the CA is unavailable, nodes cannot get the current public keys of other nodes to establish secure connections

10.3.3.2 Secure Routing

The contemporary routing protocols designed for ad hoc networks (discussed in Chapter 2) cope well with dynamically changing topology, but are not designed to provide defense against malicious attackers. In these networks, nodes exchange network topology in order to establish routes between them, and are another potential target for malicious attackers who intend to bring down the network. As for attackers, we can classify them into external and internal. External attackers may inject erroneous routing information, replay old routing data or distort routing information in order to partition or overload the network with retransmissions and inefficient routing. Compromised nodes inside the network are harder to detect and are far more detrimental.

10.3.3.3 Intrusion Detection

Each MH in an ad hoc network is an autonomous unit and is free to move independently. This implies that a node without adequate physical protection is susceptible to being captured or compromised. It is difficult to track down a single compromised node in a large network. Hence, every node in a wireless ad hoc network should be able to work in a mode wherein it trusts no peer. While intrusion prevention techniques such as encryption and authentication can reduce the risks of intrusion, they cannot be completely eliminated.

10.3.4 Authentication

Authentication denotes the accurate, absolute identification of users who wish to participate in the network. Historically, authentication has been accomplished by a well-known central authentication server. The role of the server is to maintain a database of entities, or users, and their corresponding unique IDs.

10.3.4.1 Trusted Third Parties

One of the most rudimentary approaches to authentication in ad hoc networks uses a Trusted Third Party (TTP). Every node that wishes to participate in an ad hoc network obtains a certificate from a universally trusted third party. When two nodes wish to communicate, they first check to see if the other node has a valid certificate. Although popular, the TTP approach is laden with flaws. Foremost, it probably is not reasonable to require all ad hoc network-enabled devices to have a certificate. Secondly, each node needs to have a unique name. Although this is reasonable in a large internet, it is a bit too restrictive in an ad hoc setting. Recent research has introduced many appropriate variations of TTPs, and these are discussed later.

4

Page 5: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.3.4.2 Chain of Trust

The TTP model essentially relies on a fixed entity to ensure the validity of all nodes' identities. In contrast, the chain of trust paradigm relies on any node in the network to perform authentication. That is, if a node wishes to enter a network session, it may request any of the existing nodes for authentication. This paradigm fails if there are malicious modes within the network or the incoming nodes cannot be authenticated at all.

10.3.4.3 Location-Limited Authentication

Location-limited authentication levies on the fact that two nodes are close to one another and most ad hoc networks exist in a small area. Bluetooth and infrared are two of the most widely used protocols for this form of authentication. Although it may not seem obvious, location limited authentication is potentially very secure. The security is obtained from physical assurance and tamper-detection. That is, the authenticating node can be reasonably certain that the node it thinks is being authenticated is the node it is actually authenticating (i.e., there is no man-in-the-middle) by physical indications - the transfer light on the requesting node is blinking, the person operating the device is physically present, etc.

10.4 Key Management This section provides a detailed description of the dominant key management paradigms that have been developed for ad hoc networks. The discussion is prefaced with an overview of key management terminology and the generalized Diffie-Hellman algorithm - the de facto standard for contributory key agreement algorithms. Until recently, key agreement and distribution was a largely overlooked and neglected problem in the ad hoc networking domain.

10.4.1 Conceptual Background

We first present definitions necessary to discuss and compare key management paradigms.

Definition 10.1:

A group key is a secret that is used by two or more parties to communicate securely. Group keys are symmetric; that is, the same group key is used to encrypt and decrypt messages. Like most symmetric keys, group keys should be ephemeral in order to uphold key secrecy. Key secrecy guarantees that the group key cannot be discovered by a passive adversary within a feasible amount of time [Kim2000]. In general, group key secrecy assumes that the passive adversary has never been a member of the group. However, many group applications require that only current members of the group know the secret.

Definition 10.2: Key independence ensures that a passive adversary who knows a proper subset of group keys Ic K cannot discover any other group key K e (K - K).

Definition 10.3: Forward secrecy ensures that a passive adversary (member or non-member) who knows a contiguous subset of old group keys cannot discover subsequent group keys.

Definition 10.4: Backward secrecy ensures that a passive adversary who knows a contiguous subset of group keys cannot discover preceding group keys.

Definition 10.5: Key establishment is the process, protocol, or algorithm by which a group key is created and distributed to the group. Key establishment is generally discussed as two discrete problems, namely, key agreement and key distribution.

5

Page 6: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

Definition 10.6: Key agreement is a protocol by which two or more parties contribute to the creation of a shared group key. Definition 10.7: Key distribution is the process by which each group member is apprised of the group key

one systems may necessitate key agreement and distribution protocols, while others may only have one or the other. Paradigms that only employ a key distribution protocol are often referred to as centralized. A single entity, typically the group controller or a trusted third party, is responsible for generating and distributing the key.

Centralized key management techniques are often effective in the context of static group membership with the underlying transfer medium being reliable. Although quite simple, centralized approaches to key management have a single point of failure and attack. That is, an active adversary needs only to compromise the key manager to affect the security of the entire group.

Distributed key management techniques require that two or more group members contribute to the creation of the group key and one or more public values could be broadcast to the group. Upon receipt of the public value(s), each group member uses its own secret to calculate the actual group key. Most forms of distributed key management and agreement are based on a generalization of the well-known Diffie-Hellman algorithm

Definition 10.8: Key integrity ensures that the group key is a function of all authenticated group members and no one else.

One of the easiest ways for an adversary to sacrifice key integrity is by compromising prior keys or the individual contribution - the secret shared key - of a group member. This closely related form of attack is known as a known key attack.

Definition 10.9: A protocol is vulnerable to a known key attack if compromise of past session keys allows a passive adversary to compromise future group keys, or an active adversary to impersonate one of the protocol parties [Steinerl996].

10.4.2 Diffie-Hellman Key Agreement 10.4.2.1 Overview The Diffie-Hellman key agreement protocol [Diffiel976], developed by Whitfield Diffie and Martin Hellman is perhaps the largest publicly-known cryptographic breakthrough of the twentieth century. Unlike other cryptosystems, the Diffie-Hellman protocol provided a way for two parties to agree on a secret key and use it to communicate over an insecure medium in an ad hoc fashion (i.e., the parties did not need prior secrets to agree on the new key).

6

Page 7: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.2.3 Analysis

Despite the widespread acceptance of Diffie-Hellman, it is susceptible to the man-in-the-middle attack. For example, if an active adversary, Carol, is able to intercept the transmission of the Alice's public value, substitute her own, and send it to Bob. Similarly, Carol may intercept Bob's public value, substitute her own, and send it to Alice. The result of such an attack is that Bob's messages are actually understood by Carol, not Alice, and Alice's messages are understood by Carol as well, not Bob. The above attack is made feasible by the lack of authentication in Diffie-Hellman, as it was proposed in 1976. Diffie, van Oorschot, and Wiener realized the vulnerability of the initial protocol and presented an authenticated alternative to the original protocol in 1992.

7

Page 8: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.3 N-Party Diffie-Hellman Key Agreement

10.4.3.1 Overview Several years after its inception, the Diffie-Hellman key agreement protocol was generalized to n participants. The revised protocol, henceforth referred to as Generalized Diffie-Hellman (GDH), is nearly identical to its predecessor: members agree on an a priori G and a; each member then generates its own secret iV, e G.

Key Agreement

The Generalized Diffie-Hellman consists of two stages - upflow and downflow. Each member's contributions are collected during the upflow stage, and the resultant intermediate values are broadcast to the group in the downflow stage.

Setup

The setup for GDH is identical to that of two-party Diffie-Hellman: all participants, Mh . . ., M„ choose a cyclic group, G, of order q, and a generator, or in G; each member then chooses a secret share, TV, e G.

8

Page 9: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.3.3 Group Mutation

The above protocol depicts the key agreement protocol when all group members are present at group genesis. Many contexts (e.g., ad hoc multicasting) necessitate group mutation after the initial group has been formed. In order to ensure key freshness, forward and backward secrecy, the group key must be changed whenever group membership changes (e.g., when a new member joins or an existing member departs, voluntarily or otherwise). A few straightforward extensions to GDH accommodate such mutation.

Member Addition

M„ generates a new secret, Nn. Note that this step may be removed from the protocol if backward secrecy is not required, as Nn simply prevents Mn+1 from calculating the previous group key(s).

9

Page 10: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.3.4 Analysis

Perhaps the most notable strength of GDH is the ease with which it allows group members to generate and distribute a shared group key over an insecure medium. Unfortunately, the basic form of GDH is computationally complex, and does not scale to large group contexts. In addition, the message size and the frequency demanded from the protocol require considerable bandwidth. These requirements may be prohibitive in some ad hoc networking environments. Although GDH is often classified as a distributed paradigm, it does have a heavy reliance on a group control, M„. Compromising M„, therefore, may compromise the integrity of the group or, at a minimum, significantly increase the amount of work required of the remaining members in order to establish a new controller.

10.4.4 The Ingemarsson Protocol

10.4.4.1 Overview

The previously discussed generalized version of the Diffie-Hellman algorithm was published in 1996. Prior to its publication, a number of more restrictive variations on Diffie-Hellman have been presented; the Ingemarsson et al. (from now on simply referred to as Ingemarsson protocol) protocol [Ingemarsson 1982] was the first of these attempts. The performance and applicability of this protocol has since been surpassed by more effective protocols.

10.4.4.2 Design

10

Page 11: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

The design of the Ingermasson protocol requires that group members be organized as a logical ring. Each member of the group receives the intermediate value from its predecessor, exponentiates using its own share, and forwards the result to its successor. After n-\ rounds, the protocol is complete, and each member calculates the group key

10.4.4.5 Analysis

As the above complexity analysis indicates, the Ingemarsson protocol is quite slow - the slowest of all protocols discussed here. In addition, many of the design requirements make the resulting protocol quite restrictive, especially for ad hoc networks. Firstly, all members must join and form a ring synchronously; and secondly, the protocol requires members to maintain their predecessor and successor at all times. The later requirement is especially prohibitive in fault-prone environments, where group members need to be constantly regrouping due to departure without notice or faults in the network.

11

Page 12: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.5 The Burmester and Desmedt Protocol

10.4.5.1 Overview

The Burmester and Desmedt protocol [Burmester 1994] presents a much faster variation of the generalized Diffie-Hellman. The setup phase of the Burmester and Desmedt protocol is identical to that of basic GDH; however, the group key construction is considerably different.

The Burmester and Desmedt protocol [Burmester 1994] presents a much faster variation of the generalized Diffie-Hellman. The setup phase of the Burmester and Desmedt protocol is identical to that of basic GDH; however, the group key construction is considerably different.

10.4.5.4 Analysis

Similar to the Ingemarsson protocol, the Burmester protocol requires n + 1 exponentiations per group member; however, each exponentiation is significantly less complex. However, implementations of the Burmester protocol are unlikely to achieve theoretical performance measures described above due to a heavy reliance on synchronous broadcast messaging. Although sequential broadcasts do not compromise the security of the protocol, they will most likely result in decreased performance.

10.4.6 The Hyper cube Protocol

12

Page 13: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.6.1 Overview

The high number of messages required by the Ingemarsson and Burmester protocols motivated Becker and Willie to define lower bounds on the communication complexity of the Diffie-Hellman based key agreement protocols. To minimize communication overhead, they developed the Hypercube and Octopus protocols [Becker 1998]. The two protocols differ only in their logical arrangement of group members.

10.4.6.2 Design

The Hypercube Protocol requires 2d participants, where d represents the dimensions of the cube. Each participant is logically positioned as a point in the cube; each edge of the cube depicts a key exchange. Because parallel edges represent exchanges that can be executed in parallel, a total of d rounds are required.

13

Page 14: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

14

Page 15: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.7 The Octopus Protocol

10.4.7.1 Overview

The restrictive requirements of the Hypercube protocol - the necessity of 2d group members - motivated Becker and Willie to develop a more flexible protocol. The resulting protocol, named Octopus [Beckerl998], allows an arbitrary number of group members to contribute to the group key. While minimizing the number of messages and rounds, the Octopus protocol has a desirable communication complexity.

15

Page 16: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.7.3 The Protocol

Notation

10.4.8 The CLIQUES Protocol Suite

10.4.8.1 Overview

The CLIQUES protocol [Steinerl998] remains one of the most effective and popular key management paradigms in use today. Unlike many of its predecessors, CLIQUES is more than simply a protocol: it is comprehensive key management paradigm, which includes well-defined group semantics, four key agreement protocols, an application programming interface (API), and an empirical analysis. In addition, CLIQUES has been specifically designed to accommodate dynamic and fault-prone group settings. That is, semantics for single and mass member join and leave, group merge and partition are included in the suite.

10.4.8.2 Design

Unlike the protocols discussed thus far, CLIQUES is largely eventdriven; that is, it uses membership events (e.g., join, leave, and merge) to trigger key regeneration. Because group events may occur concurrently, CLIQUES is designed above a synchronous networking layer. The wellknown Spread toolkit, which ensures total or causal ordering for broadcast messages, is employed at this layer. CLIQUES use a group controller group mutation events - add, remove, merge, partition, etc. However, the group controller is not solely responsible for key generation

16

Page 17: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

Setup :Members of the group select p, q, G, and a. In addition, each member is assigned a sequential identifier in 1...n. Mn assumes the role of the group controller.

17

Page 18: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.4.8.5 GDH.3

Overview

The GDH.3 protocol targets at reducing the number of exponentiations required by each member. Reducing the number and relative expense of exponentiations is of paramount importance in ad hoc networking context wherein the nodes have constraints on their computational capabilities.

Setup

Members of the group select p, q, G, and a. In addition, each member is assigned a sequential identifier in 1...n. Mn assumes the role of the group controller.

s

10.4.9 The Tree-Based Generalized Diffie-Hellman Protocol

10.4.9.1 Overview

One major problem with CLIQUES is the amount of time it takes to generate and distribute the group key. Recall that Mn must wait for n-\ members exponentiate the immediate and the cardinal values. The Treebased Generalized Diffie-Hellman (TGDH) key agreement protocol [Kim2000] seeks to improve this performance by structuring the key generation hierarchically rather than linearly. The tree-based key agreement algorithm provides an interesting contrast to CLIQUES because the actual algorithm used to

18

Page 19: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

generate the keys (Diffie-Hellman) is identical; the only major difference between the two is the structure of the contributing nodes.

10.5 Secure Routing

The provision of security services in the MANET context faces a set of challenges specific to its environment. The insecurity of the wireless links, energy constraints, relatively poor physical protection of nodes in a hostile environment, and the vulnerability of statically configured security schemes have been identified [Zhou 1999, Stajanol999] as challenges in the literature. Nevertheless, the single most important feature that differentiates MANET is the absence of a fixed infrastructure.

10.5.1 Problems Affecting Secure Ad Hoc Routing

10.5.1.1 Infrastructure

An ad hoc network is an infrastructureless network. Unlike traditional networks, there is no pre-deployed infrastructure such as centrally administered routers or strict policy for supporting end-to-end routing.

10.5.1.2 Frequent Changes in Network Topology

Ad hoc network nodes may frequently change their locations. This results in frequently changing neighbors on whom a node has to rely for routing. As we shall see, this has a significant impact on the implementation of secure routing over MANETs.

19

Page 20: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.5.1.3 Wireless Communication

As the communication is through a wireless medium, it is possible for any intruder to easily tap it. Wireless channels offer poor protection and routing related control messages can be tampered. The wireless medium is susceptible to signal interference, jamming, eavesdropping and distortion. An intruder may easily eavesdrop to find out sensitive routing information or jam the signals to prevent propagation of routing information. What is worse is that an intruder could even interrupt messages and distort them to manipulate routes. Secure routing protocols should be designed to handle such problems.

10.5.1.4 Problems with Existing Ad Hoc Routing Protocols

Existing ad hoc routing protocols possess many security vulnerabilities, routing security is very often peculiar to a specific protocol. It may happen that a given vulnerability is present in a given protocol, while it does not exist in another. Therefore, in the following discussions we consider security flaws in the context of a particular protocol.

10.5.1.4.1 Implicit Trust Relationship amongst Neighbors

Most ad hoc routing protocols are cooperative by nature and depend on neighboring nodes to route packets by inherently trusting all participants. This naive trust model allows malicious nodes to paralyze an ad hoc network by inserting erroneous routing updates, replaying old messages, changing routing updates or advertising incorrect routing information.

10.5.1.4.2 Throughput

Ad hoc networks maximize total network throughput by using all available nodes for routing and forwarding. However, a node may misbehave by agreeing to forward packets and then fail to do so, because it is overloaded, selfish, malicious or out of service. Although the average loss in throughput due to a single misbehaving node may not be too high, it may be significantly high in the case of a group attack.

10.5.1.4.3 Attacks using Modification of Protocol Message Fields

Current routing protocols assume that nodes do not alter the protocol fields in the messages passing through them. As we have already seen, routing protocol packets carry important control information that governs the behavior of data transmission. Since the level of trust in a traditional ad hoc network cannot be measured or enforced, enemy nodes or compromised nodes may participate directly in the route discovery and may intercept and filter routing protocol packets to disrupt communication.

Remote Redirection with Modified Route Sequence Number (AODV)

Remote redirection attacks are also called black hole attacks [Deng2002]. In these attacks, a malicious node uses the routing protocol to advertise itself as the shortest path to those nodes whose packets it wants to intercept. As we have seen earlier, protocols such as AODV instantiate and maintain routes by assigning monotonically increasing sequence numbers in order to route packets towards a specific destination. In AODV, any node may divert traffic through itself simply by advertising a route to a node with a destination sequence number greater than the authentic (or actual) value.

20

Page 21: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

Redirection with Modified Hop Count (AODV)

A redirection attack is also possible in certain protocols, such as AODV, by modification of the hop count field in the route discovery messages. When routing decisions cannot be made by other metrics, AODV uses the hop count field to determine the shortest path. By setting the hop count field of the RREP to infinity, routes will tend to be created that do not include the malicious node. Once the malicious node has been able to insert itself between two communicating nodes, it is able to do nearly anything with the packets exchanged between them.

Denial of Service with Modified Source Routes

A denial of service attack is also possible in the DSR routing protocol, which explicitly states routes in data packets. These routes lack any integrity checks and a simple denial of service attack can be launched by altering the source routes in packet headers. Modification to source routes in DSR may also include introduction of loops in the specified path.

10.5.1.5 Attacks using Impersonation

Current ad hoc routing protocols do not authenticate the source IP address. Consequently, a malicious node can launch many attacks by altering its own MAC or IP address, with the goal of pretending to be some other node. This is called impersonation.

10.5.1.6 Attacks using Fabrication

Generation of false routing messages is termed as fabrication of messages. Such attacks are usually difficult to detect. Below we describe some attacks based on fabrication

10.5.1.6.1 Falsifying Route Error Messages (AODV or DSR)

AODV and DSR implement path maintenance measures to recover broken routes whenever nodes move. If the destination node or an intermediate node along an active path moves, the node upstream of the link breakage broadcasts a route error message to all active upstream neighbors. In addition, the node also invalidates the route for this particular destination in its routing table. The vulnerability here is that routing attacks can be launched by sending false route error messages.

10.5.1.6.2 Route Cache Poisoning in DSR

This is a passive attack that can occur in DSR due to its optional promiscuous mode of updating routing tables. This occurs when information stored in the routing table at routers is deleted, altered or injected with the false information. In addition to learning routes from headers of packets being processed by a node along a path, routes in DSR may also be determined from promiscuously received packets.

10.5.1.6.3 Routing Table Overflow Attack

In routing table overflow attack, the attacker attempts to create routes to non-existent nodes. The goal of the attacker is to create enough routes to prevent new routes from being created, or even overwhelm the protocol to flush out legitimate routes from the routing tables. Proactive routing algorithms attempt to discover routing information continuously, while reactive algorithms create only when they are needed.

21

Page 22: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.5.1.7 Detect and Isolate Misbehaving Nodes

As we discussed earlier, misbehaving nodes can affect the network throughput adversely in worst-case scenario. The existing ad hoc routing protocols do not include any mechanism to identify these misbehaving nodes. Therefore, it is necessary to clearly define misbehaving nodes in order to prevent false positives. On the other hand, it may be possible that a node appears to be misbehaving when it is actually encountering temporary problem such as overload or low battery.

10.5.1.8 Information Leaking on Network Topology

Ad hoc routing protocols carry routes discovery packets in clear text (e.g., AODV and DSR). These packets contain the routes to be followed. By analyzing these packets, any intruder can find out the structure of the network. The attacker might use this information to determine which nodes are adjacent to the target or the physical location of a particular node. Such an attack can be carried out passively; it can also reveal roles of nodes in the network and their location.

10.5.1.9 Lack of Self-Stabilization

Routing protocols should be able to recover from an attack in finite time. An intruder should not be able to permanently disable the network by injecting a small number of malformed routing packets. For example, AODV is prone to self-stabilization problems as sequence numbers are used to verify route validity and incorrect state may remain in routing tables for a long period of time.

10.5.2 Secure Routing Protocols

Current efforts towards the design of secure routing protocols are mainly oriented to reactive (on-demand) routing protocols such as DSR or AODV, where a node attempts to discover a route to some destination only when it has a packet to send to that destination. On-demand routing protocols have been demonstrated to have significantly lower overheads than proactive routing protocols in many scenarios, as they are able to react quickly to topology changes, yet being able to reduce routing overhead in periods or areas of the network in which changes are less frequent.

Major secure routing protocols for ad hoc networks can be classified into four categories:

• Those using pre-deployed security infrastructure;

• Those aiming at concealing the network topology;

• Those targeting at mitigating node misbehavior;

• Other routing protocols.

10.5.2.1 Using Pre-Deployed Security Infrastructure

Here, we assume existence of certain amount of security infrastructure.

10.5.2.1.1 Assumptions

The type of ad hoc environment that we are dealing with here is called managed-open environment which assumes that there is opportunity for pre-deployment. Nodes wishing to communicate can exchange initialization parameters beforehand, perhaps within the security of an infrastructured

22

Page 23: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

network where session keys may be exchanged or through a trusted third party like a certification authority.

10.5.2.1.2 The ARAN Protocol

The Authenticated Routing for Ad-hoc Networks (ARAN) [Dahill2002] detects and protects against malicious actions by third parties and peers in an ad hoc environment. ARAN introduces authentication, message integrity and non-repudiation in an ad hoc environment. ARAN makes use of cryptographic certificates for the purposes of authentication and non-repudiation. Route discovery in ARAN is composed of two distinct stages. The first stage is simple and requires little extra work from peers beyond traditional ad hoc protocols.

Stage 1

The stage one contains a preliminary certification stage and a mandatory end-to-end authentication stage. This lightweight stage does not demand too many resources

Stage 2

Stage two is performed only after discovery of shortest path in Stage one is over as the destination certificate is required in this phase. Data transfer can be pipelined with the shortest path discovery operation employed in Stage two.

Route Maintenance

ARAN is an on-demand protocol where nodes keep track of whether routes are active or not. When an existing route is not used after some pre-specified lifetime, it is simply deactivated (i.e., expired) in the route table. Nodes also use Error (ERR) packets to report links in active routes that are broken due to node movement.

Key Revocation

ARAN attempts a best effort key revocation that is backed up with limited time certificates. In the event that a certificate needs to be revoked, the trusted certificate server, node T, sends a broadcast message to the ad hoc group announcing the revocation.

10.5.2.2 Concealing Network Topology

10.5.2.2.1 Using Independent Security Agents

This is called the non-disclosure method (NDM). In NDM, a number of independent security agents (SA) are distributed over the network. Each of these agents SA owns a pair of asymmetric cryptographic keys KSAi and KSAI-- Suppose node S wishes to transmit a message M to a receiver node R without disclosing its own location.

10.5.2.2.2 Utilizing Zones

As we have discussed in an earlier chapter, the ZRP protocol is a hierarchical algorithm where the network is divided into zones which operate independently from each other. Such a hierarchical routing structure is favorable with respect to security since it should be able to confine certain problems to

23

Page 24: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

small portion of the hierarchy, leaving other portions unaffected. ZRP has some features that appear to make it somewhat less susceptible to routing attacks.

10.5.3 The Wormhole Attack

The wormhole attack is a severe threat against ad hoc routing protocols that is particularly challenging to detect and prevent. In a wormhole attack, a malicious node can record packets (or bits) at one location in the network and tunnel them to another location through a private network shared with a colluding malicious node. A dangerous threat can be perpetrated if a wormhole attacker tunnels all packets through the wormhole honestly and reliably since no harm seems to be done: the attacker actually seems to provide a useful service in connecting the network more efficiently. However, when an attacker forwards only routing control messages and not data packets, communication may be severely damaged. As an example, when used against an on-demand routing protocol such as DSR, a powerful application of the wormhole attack can be mounted by tunneling each RREQ message directly to the destination target node of the request. This attack prevents routes more than two hops long from being discovered, as RREP messages would arrive at the source faster than any other replies or, worse, RREQ messages arriving from other nodes next to the destination than the attacker would be discarded since already seen.

Temporal leashes (using precise time synchronization) or Geographical leashes (using location information) are used to calculate delay bounds on a packet. These bounds when compared to actual values can help in anomaly detection.

10.6 Cooperation in MANETs

As opposed to networks using dedicated nodes to support basic networking functions such as packet forwarding and routing, in ad hoc networks these functions are carried out by all available network nodes. There is no reason, however, to assume that the nodes in the network will eventually cooperate with one another since network operation consumes energy, a particularly scarce resource in a battery powered environment like MANETs. The new type of node misbehavior that is specific to ad hoc networks is caused by the lack of cooperation and goes under the name of node selfishness [Yoo2006]. A selfish node does not directly intend to damage other nodes with active attacks (mainly because performing active attacks can be very expensive in terms of energy consumption) but it simply does not cooperate to the network operation, saving battery life for its own communications.

10.6.1 CONFIDANT

The CONFIDANT (Cooperation Of Nodes, Fairness In Dynamic Ad hoc NeT works) cooperation mechanism [Buchegger2002a, Buchegger2002b] detects malicious nodes by means of observation or reports about several types of attacks, thus allowing nodes to route around misbehaved nodes and thereby isolate them. CONFIDANT works as an extension to a routing protocol such as DSR. Here, nodes are provided with:

24

Page 25: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

• A monitor for observations;

• Reputation records for first-hand and trusted second-hand observations about routing and forwarding behavior of other nodes;

• Trust records to control trust given to received warnings;

• A path manager to adapt their behavior according to reputation and to take action against malicious nodes.

The dynamic behavior of CONFIDANT is as follows. Nodes monitor their neighbors and change the reputation accordingly. If they have some reason to believe that a node is misbehaving, they can take action in terms of their own routing and forwarding and they can decide to inform other nodes by sending an ALARM message. When a node receives such an ALARM either directly or by promiscuously listening to the network, it evaluates how trustworthy the ALARM is based on the source of the ALARM and the accumulated ALARM messages about the node in question. It can then decide whether to take action against the misbehaved node in the form of excluding routes containing the misbehaved node, re-ranking paths in the path cache, reciprocating by non-cooperation, and forwarding an ALARM about the node.

10.6.2 Token-Based

In an approach presented in [Yang2002], each node of the ad hoc network has a token in order to participate in the network operations, and its local neighbors collaboratively monitor to detect any misbehavior in routing or packet forwarding services. Upon expiration of the token, each node renews its token via its multiple neighbors: the period of validity of a node's token is dependent on how long it has stayed and behaved well in the network.

A well-behaving node accumulates its credit and renews its token less frequently as time evolves. The security solution is composed of four closely connected components:

• Neighbor verification: describes how to verify whether each node in the network is a legitimate or malicious node;

• Neighbor monitoring: describes how to monitor the behavior of each node in the network and detect occasional attacks from malicious nodes;

• Intrusion reaction: describes how to alert the network and isolate the attackers;

• Security enhanced routing protocol: explicitly incorporates the security information collected by other components into the ad hoc routing protocol.

In the token issuing/renewal phase, it is assumed a global secret key (SK)/public key (PK) pair, where PK is well known by every node of the network. SK is shared by k neighbors who collaboratively sign the token requested or renewed by local nodes. On the other hand, token verification follows three steps: 1) identity match between the nodes's ID and the token ID, 2) validity time verification, 3) issuer signature. If the token verification phase fails, the corresponding node is rejected from the network and both routing and data packets are dropped for that node. Routing security relies on the redundancy of routing information rather than cryptographic techniques enforced by suitably modifying the AODV protocol and the Watchdog technique described earlier.

25

Page 26: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.8 Intrusion Detection Systems

The use of wireless links renders a wireless ad hoc network vulnerable to malicious attacks, ranging from passive eavesdropping to active interference. In wired networks, however, the attacker needs to gain access to the physical media (e.g., network wires, etc.) or pass through a plethora of firewalls and gateways. In wireless networks, the scenario is much different as there are no firewalls or gateways in place and attacks can take place from all directions. Every node in the ad hoc network must be prepared for such encounters with the adversary.

Each mobile station in an ad hoc network is an autonomous unit in itself, free to move independently. This means that a node without adequate physical protection is very much susceptible to being captured, hijacked or compromised. It is difficult to track down a single compromised node in a large network; attacks stemming from compromised nodes are far more detrimental and much harder to detect. Thus, every node in a wireless ad hoc network should be able to work in a mode wherein it trusts no peer.

10.8.1 Overview

The protocols and systems which are meant to provide useful services can be a prime target for attacks such as Distributed Denial of Service (DDoS). Intrusion detection can be used as a second line of defense to protect network systems because once an intrusion is detected response can be put in place to minimize the damage or gather evidence for prosecution or take counter offensive measures. In general terms, "Intrusion" is defined as "any set of actions that attempt to compromise integrity, confidentiality or availability of a resource".

Thus, intrusion detection is all about capturing audit data, and on the basis of this audit data determining whether it is a significant aberration from normal system behavior. If yes, then IDS infers that the system is under attack. Based on the type of audit data, IDS can be classified into 2 types:

• Network-based: Network-based IDS sits on the network gateway and captures and examines network packets that go through the network hardware interface;

• Host-based: Host-based IDS relies on the operating system audit data to monitor and analyze the events generated by the users or programs on the host.

10.8.2 Unsuitability of Current IDS Techniques

Since almost all of current network-based IDS sit on the network gateways and routers and analyze the network packets passing through them, they are rendered ineffective for wireless ad hoc networks, given the lack of any fixed infrastructure. In case of MANETs, the only available audit data is restricted to the communication activities taking place within a node's radio range, and any IDS meant for these type of networks should be made to work with this partial and localized kind of audit data. Traditional anomaly detection models of IDS cannot be used for wireless ad hoc networks, as the separating line between normalcy and anomaly is obscure.

26

Page 27: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

10.8.3 An IDS Architecture for Ad Hoc Networks

IDS should be both distributed and cooperative to suit the needs of wireless ad hoc networks. What this statement means is that every node in the wireless ad hoc network should participate in possible intrusion detection. Each node is responsible for detecting intrusion locally and independently, but neighboring nodes have some mutual understanding and can collaboratively investigate in a broader range.

IDS agents at different nodes communicate with each other to collectively detect the presence or absence of intrusions in the network. A Typical IDS agent, may include the following modules:

• Local Data Collection: The Local Data Collection module gathers streams of real time audit data from eclectic sources, which might include user and system activities within the mobile node, communication activities by this node as well as any communication activities within the radio range of this node and observable to this node;

• Local Detection Engine: The Local Detection Engine analyzes the local audit data for evidence of anomalies. This requires the IDS to maintain some expert rules for the node against which the audit data collected would be checked. However, as more and more appliances are becoming wireless, the types of planned attacks against these appliances is going to increase and this may make the existing expert rules insufficient to tackle these newer attacks.

10.8.3.1 Intrusion Response

The type of intrusion response for wireless ad hoc networks depends on the type of intrusion, the type of network protocols and the confidence in the veracity of the audit trace data. The response might range from resetting the communication channels between nodes, or identifying the compromised nodes and precluding them from the network.

10.8.4 Anomaly Detection

In this section we discuss anomaly detection issues in IDS systems.

10.8.4.1 Detecting Abnormal Updates to Routing Tables

For ad hoc routing protocols, the primary concern is that false routing information generated and transmitted by a compromised node may be eventually used by other nodes in the network. Thus, a good candidate for audit data would be the updates of routing information. A legitimate change in the routing table is caused by physical motion of the nodes or changes in the membership of the network.

10.8.4.2 Detecting Anomalous Activities in Other Layers

For medium access protocols, trace data could be in the form of total number of channel requests, the total number of nodes making those requests, etc., for last s seconds. The class can be the range of the current requests by a node. The classifier of the trace data describes the normal profile of a request. Anomaly detection model can then be computed on the basis of the deviation of the trace data from the normal profile.

27

Page 28: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

CHAPTER 2: Sensor Network Platforms and Tools

A real-world sensor network application most likely has to incorporate all these elements, subject to energy, bandwidth, computation, storage, and real-time constraints. This makes sensor network application development quite different from traditional distributed system development or database programming. With ad hoc deployment and frequently changing network topology, a sensor network application can hardly assume an always-on infrastructure that provides reliable services such as optimal routing, global directories, or service discovery

There are two types of programming for sensor networks, those carried out by end users and those performed by application developers. An end user may view a sensor network as a pool of data and interact with the network via queries. Just as with query languages for database systems like SQL, a good sensor network programming language should be expressive enough to encode application logic at a high level of abstraction, and at the same time be structured enough to allow efficient execution on the distributed platform.

Sensor Node Hardware Sensor node hardware can be grouped into three categories, each of which entails a different set of trade-offs in the design choices. • Augmented general-purpose computers: Examples include lowpower PCs, embedded PCs (e.g., PC104), custom-designed PCs (e.g., Sensoria WINS NG nodes),1 and various personal digital assistants (PDA). These nodes typically run off-the-shelf operating systems such as Win CE, Linux, or real-time operating systems and use standard wireless communication protocols such as Bluetooth or IEEE 802.11. Because of their relatively higher processing capability, they can accommodate awide variety of sensors, ranging from simple microphones to more sophisticated video cameras.

However, when power is not an issue, these platforms have the advantage that they can leverage the availability of fully supported networking protocols, popular programming languages, middleware, and other off-the-shelf software.

• Dedicated embedded sensor nodes:

Examples include the Berkeley mote family [98], the UCLA Medusa family [202], Ember nodes,2 and MIT µAMP [32]. These platforms typically use commercial off-the-shelf (COTS) chip sets with emphasis on small form factor, low power processing and communication, and simple sensor interfaces. Because of their COTS CPU, these platforms typically support at least one programming language, such as C.

• System-on-chip (SoC) nodes:

Examples of SoC hardware include smart dust [109], the BWRC picoradio node [187], and the PASTA node.3 Designers of these platforms try to push the hardware limits by fundamentally rethinking the hardware architecture trade-offs for a sensor node at the chip design level. The goal is to find new ways of integrating CMOS, MEMS, and RF technologies to build extremely low power and small footprint sensor nodes that still provide certain sensing, computation, and communication capabilities.

28

Page 29: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

7.1.1 Berkeley Motes

The Berkeley motes are a family of embedded sensor nodes sharing roughly the same architecture. Figure 7.1 shows a comparison of a subset of mote types

Let us take the MICA mote as an example. The MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing. A separate and much less capable coprocessor is only active when the MCU is being reprogrammed. The ATmega103L MCU has integrated 512 KB flash memory and 4 KB of data memory. Given these small memory sizes, writing software for motes is challenging. Ideally, programmers should be relieved from optimizing code at assembly level to keep code footprint small.

29

Page 30: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

30

Page 31: Web viewThe MICA motes have a two-CPU design, as shown in Figure 7.2. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing

When applying such a model to programming networked embedded systems, such as sensor networks, the application programmers need to explicitly deal with message passing, event synchronization, interrupt handing, and sensor reading. As a result, an application is typically implemented as a finite state machine (FSM) that covers all extreme cases: unreliable communication channels, long delays, irregular arrival of messages, simultaneous events, and so on. In a target tracking application implemented on a Linux operating system and with directed diffusion routing, roughly 40 percent of the code implements the FSM and the glue logic of interfacing computation and communication [142].

At the extreme, embedded operating systems tend to expose more hardware controls to the programmers, who now have to directly face device drivers and scheduling algorithms, and optimize code at the assembly level.

Although these techniques may work well for small, stand-alone embedded systems, they do not scale up for the programming of sensor networks for two reasons.

• Sensor networks are large-scale distributed systems, where global properties are derivable from program execution in a massive number of distributed nodes. Distributed algorithms themselves are hard to implement, especially when infrastructure support is limited due to the ad hoc formation of the system and constrained power, memory, and bandwidth resources.

• As sensor nodes deeply embed into the physical world, a sensor network should be able to respond to multiple concurrent stimuli at the speed of changes of the physical phenomena of interest.

In the rest of the chapter, we give several examples of sensor network software design platforms. We discuss them in terms of both design methodologies and design platforms. A design methodology implies a conceptual model for programmers, with associated techniques for problem decomposition for the software designers.

There is no single universal design methodology for all applications. Depending on the specific tasks of a sensor network and the way the sensor nodes are organized, certain methodologies and platforms may be better choices than others. For example, if the network is used for monitoring a small set of phenomena and the sensor nodes are organized in a simple star topology, then a client-server software model would be sufficient.

7.3 Node-Level Software Platforms

Most design methodologies for sensor network software are nodecentric, where programmers think in terms of how a node should behave in the environment. A node-level platform can be a nodecentric operating system, which provides hardware and networking abstractions of a sensor node to programmers, or it can be a language platform, which provides a library of components to programmers. A typical operating system abstracts the hardware platform by providing a set of services for applications, including file management, memory allocation, task scheduling, peripheral device drivers, and networking. For embedded systems, due to their highly specialized applications and limited resources, their operating systems make different trade-offs when providing these services. For example, if there is no file management requirement, then a file system is obviously not needed. If there is no dynamic memory allocation, then memory management can be simplified. If prioritization among tasks is critical, then a more elaborate priority scheduling mechanism may be added.

31


Recommended