Security Protocols for Wireless Sensor Networks

7Security Protocols for WirelessSensor Networks

7.1. INTRODUCTION

Thousands to millions of small sensors form self-organizing wireless net-works. Security for these sensor networks is not easy since these sensors havelimited processing power, storage, bandwidth, and energy.

A set of Security Protocols for Sensor Networks, SPINS, explores thechallenges for security in sensor networks. SPINS include µTESLA (themicro version of the Timed, Efficient, Streaming, Loss-tolerant Authenti-cation protocol), providing authenticated streaming broadcast, and SNEP(Secure Network Encryption Protocol), which provides data confidentiality,two-party data authentication, and data freshness, with low overhead. Anauthenticated routing protocol uses SPINS building blocks.

A sensor network should not leak sensor readings to neighboring networks.In many applications (e.g. key distribution), nodes communicate highlysensitive data. The standard approach for keeping sensitive data secret is toencrypt the data with a secret key that only intended receivers possess, henceachieving confidentiality. Given the observed communication patterns, securechannels are set up between nodes and base stations, and later bootstrap othersecure channels as necessary.

Authenticated broadcast requires an asymmetric mechanism, otherwise anycompromised receiver could forge messages from the sender. Asymmetriccryptographic mechanisms have high computation, communication, and

Wireless Sensor Network Designs A. Hac 2003 John Wiley & Sons, Ltd ISBN: 0-470-86736-1

214 SECURITY PROTOCOLS

storage overhead, which makes their usage on resource-constrained devicesimpractical. µTESLA overcomes this problem by introducing asymmetrythrough a delayed disclosure of symmetric keys, which results in an efficientbroadcast authentication scheme.

Wireless networks, in general, are more vulnerable to security attacks thanwired networks, due to the broadcast nature of the transmission medium.Furthermore, wireless sensor networks have an additional vulnerabilitybecause nodes are often placed in a hostile or dangerous environment wherethey are not physically protected.

In a target tracking application, nodes that detect a target in an areaexchange messages containing a timestamp, the location of the sending node,and other application-specific information. When one of the nodes acquiresa certain number of messages such that the location of the target can beapproximately determined, the node sends the location of the target tothe user.

7.2. SECURITY PROTOCOLS IN SENSOR NETWORKS

Small sensor devices are inexpensive, low-power devices. They have lim-ited computational and communication resources. The sensors form aself-organizing wireless network in a multi-hop routing topology. Typicalapplications may periodically transmit sensor readings for processing.

The network consists of nodes (small battery-powered devices) that com-municate with a more powerful base station, which in turn is connected to anoutside network. The energy source on the devices is a small battery. Com-munication over radio is the most energy-consuming function performed bythese devices, so that the communications overhead needs to be minimized.The limited energy supplies create limits for security, hence security needsto limit consumption of processor power. However, limited power supplylimits the lifetime of keys. Base stations differ from nodes in having longer-lived energy supplies and having additional communications connections tooutside networks.

These constraints make it impractical to use secure algorithms designed forpowerful workstations. For example, the working memory of a sensor node isinsufficient even to hold the variables (of sufficient length to ensure security)that are required in asymmetric cryptographic algorithms, let alone performoperations with them.

Asymmetric digital signatures for authentication are impractical for sensornetworks for a number of reasons, such as, long signatures with a highcommunication overhead of 50–1000 bytes per packet, a very high overhead

7.2. SECURITY PROTOCOLS IN SENSOR NETWORKS 215

to create and verify the signature. Also, symmetric solutions for broadcastauthentication are impractical: an improved k-time signature scheme requiresover 300 bytes per packet. TESLA protocol adapted for sensor networks tobecome practical for broadcast authentication is called µTESLA.

Adding security to a highly resource-constrained sensor network is feasible.The security building blocks facilitate the implementation of a securitysolution for a sensor network by using an authenticated routing protocol anda two-party key agreement protocol. The choice of cryptographic primitivesand the security protocols in the sensor networks is affected by the severehardware and energy constraints.

A general security infrastructure that is applicable to a variety of sensornetworks needs to define the system architecture and the trust requirements.

Generally, the sensor nodes communicate using RF (Radio Frequency),thus broadcast is the fundamental communication primitive. The baselineprotocols account for this property, which affects the trust assumptions, andis exploited to minimize energy usage.

The sensor network forms around one or more base stations, which interfacethe sensor network to the outside network. The sensor nodes establisha routing forest, with a base station at the root of every tree. Periodictransmission of beacons allows nodes to create a routing topology. Each nodecan forward a message towards a base station, recognize packets addressed toit, and handle message broadcasts. The base station accesses individual nodesusing source routing. The base station has capabilities similar to the networknodes, except that it has enough battery power to surpass the lifetime of allsensor nodes, sufficient memory to store cryptographic keys, and means forcommunicating with outside networks.

In the sensor applications there is limited local exchange and data process-ing. The communication patterns within the network fall into three categories:

• node to base station communication, e.g. sensor readings;• base station to node communication, e.g. specific requests;• base station to all nodes, e.g. routing beacons, queries or reprogramming

of the entire network.

The security goal is primarily to address these communication patterns,and to adapt the baseline protocols to other communication patterns, i.e. nodeto node or node broadcast.

The sensor networks may be deployed in untrusted locations. While itmay be possible to guarantee the integrity of each node through dedicatedsecure microcontrollers, such an architecture may be too restrictive anddoes not generalize to the majority of sensor networks. Perrig et al. (2001b)


assume that individual sensors are untrusted. The SPINS key setup preventscompromising of one node spreading to other nodes.

Basic wireless communication is not secure. Because it is broadcast, anyadversary can eavesdrop on the traffic, and inject new messages or replay andchange old messages. Hence, SPINS does not place any trust assumptions onthe communication infrastructure, except that messages are delivered to thedestination with nonzero probability.

Since the base station is the gateway for the nodes to communicate with theoutside world, compromising the base station can render the entire sensornetwork useless. Thus the base stations are a necessary part of the trustedcomputing base. All sensor nodes trust the base station: at creation time, eachnode is given a master key which is shared with the base station. All otherkeys are derived from this key.

Each node trusts itself and, in particular, the local clock is trusted to beaccurate, i.e. to have a small drift. This is necessary for the authenticatedbroadcast protocol.

7.2.1. Sensor Network Security Requirements

Message authentication is important for many applications in sensor net-works. Within the building sensor network, authentication is necessary formany administrative tasks (e.g. network reprogramming or controlling sensornode duty cycle). At the same time, an adversary can easily inject messages,so the receiver needs to make sure that the data used in any decision-makingprocess originates from the correct source. Informally, data authenticationallows a receiver to verify that the data really was sent by the claimed sender.

In the case of two-party communication, data authentication can beachieved through a purely symmetric mechanism: the sender and the receivershare a secret key to compute a Message Authentication Code (MAC) forall communicated data. When a message with a correct MAC arrives, thereceiver knows that it must have been originated by the sender.

This style of authentication cannot be applied to a broadcast setting withoutplacing much stronger trust assumptions on the network nodes. If onesender wants to send authentic data to mutually untrusted receivers, usinga symmetric MAC is insecure. A receiver knows the MAC key, and hencecould impersonate the sender and forge messages to other receivers. Hence,an asymmetric mechanism is needed to achieve authenticated broadcast.Authenticated broadcast can also be constructed from symmetric primitives,and asymmetry be introduced with delayed key disclosure and one-wayfunction key chains.


In communication, data integrity ensures the receiver that the received datais not altered in transit by an adversary. In SPINS, data integrity is achievedthrough data authentication, which is a stronger property.

Since all the sensor networks stream some forms of time-varying measure-ment, and they are guaranteed confidentiality and authentication, we alsomust ensure that each message is fresh. Informally, data freshness implies thatthe data is recent, and it ensures that no adversary has replayed old messages.Two types of freshness are defined: weak freshness, which provides partialmessage ordering, but carries no delay information, and strong freshness,which provides a total order on a request–response pair, and allows for delayestimation. Weak freshness is required by sensor measurements, while strongfreshness is useful for time synchronization within the network.

The following notation is used to describe security protocols and crypto-graphic operations:

• A, B are principals, such as communicating nodes;• NA is a nonce generated by A (a nonce is an unpredictable bit string, usually

used to achieve freshness);• M1|M2 denotes the concatenation of messages M1 and M2;• KAB denotes the secret (symmetric) key which is shared between A and B;• {M}KAB is the encryption of message M with the symmetric key shared by

A and B;• {M}(KAB,IV), denotes the encryption of message M, with key KAB, and

the initialization vector IV which is used in encryption modes such ascipher-block chaining (CBC), output feedback mode (OFB), or countermode (CTR);

• secure channel is a channel that offers confidentiality, data authentication,integrity, and freshness.

Security requirements are achieved by using two security building blocks:SNEP and µTESLA. SNEP provides data confidentiality, two-party dataauthentication, integrity, and freshness. µTESLA provides authentication fordata broadcast. The security for both mechanisms is bootstrapped with ashared secret key between each node and the base station. The trust to node-to-node interactions can be extended from the node-to-base-station trust.

SNEP has low communication overhead since it only adds bytes permessage. SNEP, like many cryptographic protocols, uses a counter, but trans-mitting the counter value is avoided by keeping state at both end points. SNEPachieves semantic security, a strong security property that prevents eaves-droppers from inferring the message content from the encrypted message.


The same simple and efficient protocol also gives us data authentication,replay protection, and weak message freshness.

Data confidentiality is one of the most basic security primitives and itis used in almost every security protocol. A simple form of confidentialitycan be achieved through encryption, but pure encryption is not sufficient.Another important security property is semantic security, which ensures thatan eavesdropper has no information about the plain text, even if it seesmultiple encryptions of the same plain text. For example, even if an attackerhas an encryption of a 0 bit and an encryption of a 1 bit, it will not helpit distinguish whether a new encryption is an encryption of 0 or 1. Thebasic technique for achieving this is randomization: before encrypting themessage with a chaining encryption function (i.e. DES-CBC (Data EncryptionStandard – Cipher Block Chaining)), the sender precedes the message witha random bit string. This prevents the attacker from inferring the plain textof encrypted messages if it knows plain text-cipher text pairs encrypted withthe same key.

However, sending the randomized data over the RF channel requiresmore energy. A cryptographic mechanism achieves semantic security withno additional transmission overhead. A shared counter is used between thesender and the receiver for the block cipher in counter mode (CTR). Sincethe communicating parties share the counter and increment it after eachblock, the counter does not need to be sent with the message. To achievetwo-party authentication and data integrity, a message authentication code(MAC) is used.

The combination of these mechanisms forms the Sensor Network Encryp-tion Protocol (SNEP). The encrypted data has the following format: E ={D}(Kencr,C), where D is the data, the encryption key is Kencr, and the counteris C. The MAC is M = MAC(Kmac, C|E). The keys Kencr and Kmac are derivedfrom the master secret key K. The complete message that A sends to B is:

A → B : {D}(Kencr,C), MAC(Kmac, C|{D}(Kencr,C)).

SNEP offers the following properties:

• Semantic security: Since the counter value is incremented after each mes-sage, the same message is encrypted differently each time. The countervalue is long enough never to repeat within the lifetime of the node.

• Data authentication: If the MAC verifies correctly, a receiver can be assuredthat the message originated from the claimed sender.

• Replay protection: The counter value in the MAC prevents replaying ofold messages. Note that if the counter were not present in the MAC, anadversary could easily replay messages.


• Weak freshness: If the message verified correctly, a receiver knows thatthe message must have been sent after the previous message it receivedcorrectly (that had a lower counter value). This enforces a message orderingand yields weak freshness.

• Low communication overhead: The counter state is kept at each end pointand does not need to be sent in each message. (In case the MAC does notmatch, the receiver can try out a fixed, small number of counter incrementsto recover from message loss. In case the optimistic resynchronization fails,the two parties engage in a counter exchange protocol, which uses thestrong freshness protocol).

Plain SNEP only provides weak data freshness, because it only enforces asending order on the messages within node B, but no absolute assurance tonode A that a message was created by B in response to an event in node A.

Node A achieves strong data freshness for a response from node B througha nonce NA (which is a random number sufficiently long such that it isunpredictable). Node A generates NA randomly and sends it along with arequest message RA to node B. The simplest way to achieve strong freshnessis for B to return the nonce with the response message RB in an authenticatedprotocol. However, instead of returning the nonce to the sender, the processcan be optimized by using the nonce implicitly in the MAC computation. Theentire SNEP protocol providing strong freshness for B’s response is:

A → B : NA, RA

B → A : {RB}(Kencr,C), MAC(Kmac, NA|C|{RB}(Kencr,C)).

If the MAC verifies correctly, node A knows that node B generated theresponse after it sent the request. The first message can also use plain SNEPif confidentiality and data authentication are needed.

7.2.2. Authenticated Broadcast

Asymmetric digital signatures for authentication are impractical for multiplereasons. They require long signatures with a high communication overheadof 50–1000 bytes per packet, and a very high overhead to create and verifythe signature. One-time signature schemes that are based on symmetriccryptography (one-way functions without trap doors) have a high overhead:Gennaro and Rohatgi’s broadcast signature based on Lamport’s one-timesignature requires over 1 kbyte of authentication information per packet,and Rohatgi’s improved k-time signature scheme requires over 300 bytesper packet.


TESLA protocol provides efficient authenticated broadcast. However,TESLA is not designed for such limited computing environments as areencountered in sensor networks. TESLA authenticates the initial packet witha digital signature, which is too expensive to compute on sensor nodes sinceeven fitting the code into the memory is a major challenge. For the samereason, one-time signatures are a challenge for use on sensor nodes.

Standard TESLA has an overhead of approximately 24 bytes per packet.For networks connecting workstations this is usually not significant. Sensornodes, however, send very small messages that are around 30 bytes long. Itis simply impractical to disclose the TESLA key for the previous intervalswith every packet: with 64-bit keys and MACs, the TESLA-related part of thepacket would constitute over 50 % of the packet.

The one-way key chain does not fit into the memory of a sensor node, sopure TESLA is not practical for a node to broadcast authenticated data.

The µTESLA solves the following inadequacies of TESLA in sensor net-works:

• TESLA authenticates the initial packet with a digital signature, which is tooexpensive for sensor nodes. µTESLA uses only symmetric mechanisms.

• Disclosing a key in each packet requires too much energy for sending andreceiving. µTESLA discloses the key once per epoch.

• It is expensive to store a one-way key chain in a sensor node. µTESLArestricts the number of authenticated senders.

The µTESLA is discussed for the case where the base station broad-casts authenticated information to the nodes, and the case where a node isthe sender.

µTESLA requires that the base station and nodes are loosely time synchro-nized, and each node knows an upper bound on the maximum synchroniza-tion error. To send an authenticated packet, the base station simply computesa MAC on the packet with a key that is secret at that point in time. When anode gets a packet, it can verify that the corresponding MAC key has not yetbeen disclosed by the base station (based on its loosely synchronized clock,its maximum synchronization error, and the time schedule at which keys aredisclosed). Since a receiving node is assured that the MAC key is known onlyby the base station, the receiving node is assured that no adversary couldhave altered the packet in transit. The node stores the packet in a buffer, andat the time of key disclosure, the base station broadcasts the verification keyto all receivers. When a node receives the disclosed key, it can easily verifythe correctness of the key. If the key is correct, the node can now use it toauthenticate the packet stored in its buffer.


P1

K0

F

K1 K2 K3 K4

P7P2 P3 P4 P6P5

F F F

Time

Figure 7.1 Using a time-released key chain for source authentication.

Each MAC key is one in a key chain, generated by a public one-wayfunction F. To generate the one-way key chain, the sender chooses the lastkey Kn of the chain randomly, and repeatedly applies F to compute all otherkeys: Ki = F(Ki+1). Each node can easily perform time synchronization andretrieve an authenticated key of the key chain for the commitment in a secureand authenticated manner, using the SNEP building block.

Figure 7.1 shows an example of µTESLA. Each key of the key chaincorresponds to a time interval and all packets sent within one time intervalare authenticated with the same key. The time until keys of a particularinterval are disclosed is two time intervals in this example. The receiver nodeis assumed to be loosely time synchronized and knows K0 (a commitmentto the key chain) in an authenticated way. Packets P1 and P2 sent in intervalone, contain a MAC with key K1. Packet P3 has a MAC using key K2. So far,the receiver cannot authenticate any packets yet. Let us assume that packetsP4, P5, and P6 are all lost, as well as the packet that discloses key K1, so thereceiver can still not authenticate P1, P2, or P3. In interval four, the base stationbroadcasts key K2, which the node authenticates by verifying K0 = F(F(K2)),and hence knows also K1 = F(K2), so it can authenticate packets P1, P2 withK1, and P3 with K2.

Instead of adding a disclosed key to each data packet, the key disclosureis independent of the packets broadcast, and is tied to time intervals. Withinthe context of µTESLA, the sender broadcasts the current key periodically ina special packet.

µTESLA has multiple phases: sender set-up, sending authenticated pack-ets, bootstrapping new receivers, and authenticating packets. For simplicity,µTESLA is explained for the case where the base station broadcasts authenti-cated information, and the case where nodes send authenticated broadcasts.

During the sender set-up, the sender first generates a sequence of secretkeys (or a key chain). To generate a one-way key chain of length, thesender chooses the last key Kn randomly, and generates the remaining valuesby successively applying a one-way function F [e.g. a cryptographic hashfunction such as MD5 (Message Digest 5)]: Kj = F(Kj+1). Because F is aone-way function, anybody can compute forward, e.g. compute K0, . . . , Kj


given Kj+1, but nobody can compute backward, e.g. compute Kj+1 given onlyK0, . . . , Kj, due to the one-way generator function. This is similar to the S/Key(Secret Key) one-time password system.

During broadcasting of authenticated packets, the time is divided intointervals and the sender associates each key of the one-way key chain withone time interval. In time interval t, the sender uses the key of the currentinterval, Kt, to compute the MAC of packets in that interval. The sender willthen reveal key Kt after a delay of δ intervals after the end of the time intervalt. The key disclosure time delay δ is of the order of a few time intervals, aslong as it is greater than any reasonable round-trip time between the senderand the receivers.

During bootstrapping of a new receiver, the important property of theone-way key chain is that once the receiver has an authenticated key of thechain, subsequent keys of the chain are self-authenticating, which means thatthe receiver can easily and efficiently authenticate subsequent keys of theone-way key chain using the one authenticated key. For example, if a receiverhas an authenticated value Ki of the key chain, it can easily authenticateKi+1, by verifying Ki = F(Ki+1). Therefore to bootstrap µTESLA, each receiverneeds to have one authentic key of the one-way key chain as a commitmentto the entire chain. Another requirement of µTESLA is that the sender andreceiver are loosely time synchronized, and that the receiver knows the keydisclosure schedule of the keys of the one-way key chain. Both the loose timesynchronization, as well as the authenticated key chain commitment, canbe established with a mechanism that provides strong freshness and point-to-point authentication. A receiver sends a nonce in the request message tothe sender. The sender replies with a message containing its current timeTS (for time synchronization), a key Ki of the one-way key chain used in apast interval i (the commitment to the key chain), and the starting time Ti ofinterval i, the duration Tint of a time interval, and the disclosure delay δ (thelast three values describe the key disclosure schedule).

M → S : NM

S → M : TS|Ki|Ti|Tint|δMAC(KMS, NM|TS|Ki|Ti|Tint|δ)Since the confidentiality is not needed, the sender does not need to encrypt

the data. The MAC uses the secret key shared by the node and base sta-tion to authenticate the data, the nonce NM allows the node to verifyfreshness. Instead of using a digital signature scheme as in µTESLA, thenode-to-base-station authenticated channel is used to bootstrap the authenti-cated broadcast.

During authenticating of the broadcast packets, when a receiver receivesthe packets with the MAC, it needs to ensure that the packet could not


have been spoofed by an adversary. The threat is that the adversary alreadyknows the disclosed key of a time interval and so it could forge the packetsince it knows the key used to compute the MAC. Hence the receiver needsto be sure that the sender has not yet disclosed the key that correspondsto an incoming packet, implying that no adversary could have forged thecontents. This is called the security condition, which receivers check for allincoming packets. Therefore, the sender and receivers need to be loosely timesynchronized and the receivers need to know the key disclosure schedule. Ifthe incoming packet satisfies the security condition, the receiver stores thepacket (it can only verify it once the corresponding key is disclosed). If thesecurity condition is violated (the packet had an unusually long delay), thereceiver needs to drop the packet, since an adversary might have altered it.

As soon as the node receives a key Kj of a previous time interval, itauthenticates the key by checking that it matches the last authentic key forwhich it knows Ki, using a small number of applications of the one-wayfunction F : Ki = Fj−i(Kj). If the check is successful, the new key Kj is authenticand the receiver can authenticate all packets that were sent within the timeintervals i to j. The receiver also replaces the stored Ki with Kj.

When the nodes broadcast authenticated data, there are additional newproblems. Since the node is severely memory limited, it cannot store thekeys of a one-way key chain. Moreover, recomputing each key from theinitial generating key Kn is computationally expensive. Another issue is thatthe node might not share a key with each receiver, hence sending out theauthenticated commitment to the key chain would involve an expensivenode-to-node key agreement. Broadcasting the disclosed keys to all receiverscan also be expensive for the node and drain precious battery energy.

The two viable approaches for addressing this problem are as follows:

• The node broadcasts the data through the base station. It uses SNEP to sendthe data in an authenticated way to the base station, which subsequentlybroadcasts it.

• The node broadcasts the data. However, the base station keeps the one-waykey chain and sends keys to the broadcasting node as needed. To conserveenergy for the broadcasting node, the base station can also broadcast thedisclosed keys, and/or perform the initial bootstrapping procedure fornew receivers.

7.2.3. Applications

Secure protocols can be built out of the SPINS secure building blocks with anauthenticated routing application, and a two-party key agreement protocol.


Using the µTESLA protocol, a lightweight, authenticated, dedicated (ad hoc)routing protocol builds an authenticated routing topology. Ad-hoc routingdoes not offer authenticated routing messages, hence, it is potentially easy fora malicious user to take over the network by injecting erroneous, replayingold, or advertising incorrect routing information.

The authenticated routing scheme assumes bidirectional communicationchannels, i.e. if node A hears node B, then node B hears node A. The routediscovery depends on periodic broadcast of beacons. Every node, uponreception of a beacon packet, checks whether or not it has already received abeacon (which is a normal packet with a globally unique sender ID (identifier)and current time at base station, protected by a MAC to ensure integrity andthat the data is authentic) in the current epoch. (Epoch means the intervalof a routing updates.) If a node hears the beacon within the epoch, it doesnot take any further action. Otherwise, the node accepts the sender of thebeacon as its parent to route towards the base station. Additionally, thenode would repeat the beacon with the sender ID changed to itself. Thisroute discovery resembles a distributed, breadth first search algorithm, andproduces a routing topology.

However, in the above algorithm, the route discovery depends only on thereceipt of a route packet, not on its contents. It is easy for any node to claim tobe a valid base station. The µTESLA key disclosure packets can easily functionas routing beacons. Only the sources of authenticated beacons are acceptedas valid parents. Reception of a µTESLA packet guarantees that that packetoriginated at the base station, and that it is fresh. For each time interval, theparent is accepted as the first node sending a packet that is later successfullyauthenticated. Combining µTESLA key disclosure with the distribution ofrouting beacons allows us to charge the costs of the to transmission of thekeys to network maintenance, rather than to the encryption system.

This scheme leads to a lightweight authenticated routing protocol. Sinceeach node accepts only the first authenticated packet as the one to use inrouting, it is impossible for an attacker to re-route arbitrary links within thesensor network. Furthermore, each node can easily verify that the parentforwarded the message: by our assumption of bidirectional connectivity, ifthe parent of a node forwarded the message, the node must have heard that.

The authenticated routing scheme above is just one way to build authenti-cated ad-hoc routing protocol using µTESLA. In protocols where base stationsare not involved in route construction, µTESLA can still be used for security.In these cases, the initiating node will temporarily act as base station andbeacons authenticated route updates. However, the node here will need tohave significantly more memory resource than the sensor nodes exploredhere in order to store the key chain.

7.3. COMMUNICATION SECURITY IN SENSOR NETWORKS 225

A convenient method to bootstrap secure connections is public-keycryptography protocols for symmetric-key set-up. Unfortunately, resource-constrained sensor nodes prevent us from using computationally expensivepublic-key cryptography. Therefore, the protocols are used solely fromsymmetric-key algorithms. Hence symmetric protocol that uses the basestation is applied as a trusted agent for key set-up.

Assume that node A wants to establish a shared secret session key SKABwith node B. Since A and B do not share any secrets, they need to use a trustedthird party S, which is the base station in our case. In our trust set-up, bothA and B share a secret key with the base station, KAS and KBS, respectively.The following protocol achieves secure key agreement as well as strong keyfreshness:

A → B : NA, A

B → S : NA, NB, A, B, MAC(KBS, NA|NB|A|B)

S → A : {SKAB}KAS, MAC(K′AS, NA|B|{SKAB}KAS)

S → B : {SKAB}KBS, MAC(K′BS, NB|A|{SKAB}KBS)

This protocol uses SNEP protocol with strong freshness. The nonces NAand NB ensure strong key freshness to both A and B. The SNEP protocolis responsible for ensuring confidentiality (through encryption with thekeys KAS and KBS) of the established session key SKAB, as well as messageauthentication (through the MAC using keys K

′AS and K

′BS) to make sure that

the key was really generated by the base station. Note that the MAC in thesecond protocol message helps to defend the base station from denial-of-service attacks, so the base station only sends two messages to A and B if itreceived a legitimate request from one of the nodes.

A nice feature of the above protocol is that the base station performs mostof the transmission work. Other protocols usually involve a ticket that theserver sends to one of the parties, who forwards it to the other node, whichrequires more energy for the nodes to forward the message. The Kerberos keyagreement protocol achieves similar properties, except that it does not providestrong key freshness. However, it would be straightforward to implement itwith strong key freshness by using SNEP with strong freshness.

7.3. COMMUNICATION SECURITY IN SENSOR NETWORKS

Application messages are exchanged through the network, and the mobilecode is sent from node to node. Because the security of mobile code greatly


affects the security of the network, protection of the messages containingmobile code is an important part of communication security scheme.

The possible threats to a network if communication security is compromisedare as follows:

(1) Insertion of malicious code is the most dangerous attack that can occur.Malicious code injected into the network could spread to all nodes,potentially destroying the whole network or, even worse, taking over thenetwork on behalf of an adversary. A seized sensor network can eithersend false observations about the environment to a legitimate user orsend observations about the monitored area to a malicious user.

(2) Interception of the messages containing the physical locations of sensornodes allows an attacker to locate the nodes and destroy them. Thesignificance of hiding the location information from an attacker lies inthe fact that the sensor nodes have small dimensions and their locationcannot be trivially traced. Thus, it is important to hide the locations of thenodes. In the case of static nodes, the location information does not ageand must be protected through the lifetime of the network.

(3) Besides the locations of sensor nodes, an adversary can observe the appli-cation specific content of messages including message IDs, time stampsand other fields. Confidentiality of those fields in our example applicationis less important than confidentiality of location information, because theapplication-specific data does not contain sensitive information, and thelifetime of such data is significantly shorter.

(4) An adversary can inject false messages that give incorrect informationabout the environment to the user. Such messages also consume thescarce energy resources of the nodes. This type of attack is called sleepdeprivation torture.

In the security scheme, the security levels are based on private key cryp-tography utilizing group keys. Applications and system software access thesecurity API as a part of the middleware defined by the sensor networkarchitecture. Since data contain some confidential information, the content ofall messages in the network is encrypted.

The sensor nodes in the network are assumed to be allowed to access thecontent of any message.

The deployment of security mechanisms in a sensor network creates addi-tional overhead. The latency increases due to the execution of the securityrelated procedures, and the consumed energy directly decreases the lifetimeof the network. To minimize the security related costs, the security overhead,


and consequently the energy consumption, should relate to the sensitivity ofthe encrypted information. Following the taxonomy of the types of data inthe network, three security levels are defined:

• security level I is reserved for mobile code, the most sensitive informationsent through the network;

• security level II is dedicated to the location information conveyed inmessages;

• the security level III mechanism is applied to the application specificinformation.

The strength of the encryption for each of the security levels correspondsto the sensitivity of the encrypted information. Therefore, the encryptionapplied at level I is stronger than the encryption applied at level II, while theencryption on level II is stronger than the one applied at level III.

Different security levels are implemented either by using various algorithmsor by using the same algorithm with adjustable parameters that change itsstrength and corresponding computational overhead. Using one algorithmwith adjustable parameters has the advantage of occupying less memoryspace.

RC6 (symmetric block cipher) is suitable for modification of its securitystrength because it has an adjustable parameter (number of rounds) thatdirectly affects its strength. The overhead for the RC6 encryption algorithmincreases with the strength of the encryption measured by the number ofrounds.

The multicast model of communication inherent for the sensor networkarchitecture suggests deployment of group keys. Otherwise, if each pair ofnodes would require a key or a pair of keys, communication between thenodes would have to be unicast based. This would significantly increase thenumber of messages. Since the addition of security in a sensor network mustnot require the change of the whole sensor network architecture, group keysare utilized.

All nodes in the network share an initial set of master keys, and the numberof keys depends on the estimated lifetime of the network. The longer thelifetime, the more keys are needed in order to expose less material for a knowncipher text attack. The alternative approach, where the keys are establisheddynamically and propagated through the network, is not acceptable. Aprotocol that guarantees that all nodes received a key is required. Such arequirement is not feasible in a network where the nodes do not keep trackof their neighbors.


One of the keys from the list of master keys is active at any moment.The algorithm for the selection of a particular key is based on a pseudo-random generator running at each node with the same seed. Periodically andsynchronously on each node, a new random number is generated and usedto provide and index an entry in the table of available master keys. Thisentry contains the active master key. The keys for three levels of securitycorresponding to the three types of data are then derived from the activemaster key.

In security level I, the messages containing mobile code are less frequentthan messages that the application instances on different nodes exchange.This allows us to use strong encryption in spite of the resulting overhead. Forinformation protected at this security level, nodes use the current master key.The set of master keys, the corresponding pseudo-random number generator,and a seed are credentials that a potential user must have in order to accessthe network. Once the user obtains those credentials, he/she can insert anycode into the network. If a malicious user breaks the encryption on this levelusing a brute force attack, he/she can insert harmful code into the network.

In security level II (data that contains locations of sensor nodes) a securitymechanism is provided that isolates parts of the network, so that breach ofsecurity in one part of the network does not affect the rest of the network.

According to the assumptions about the applications expected to run insensor networks, the locations of sensor nodes are likely to be includedin the majority of messages. Thus, the overhead that corresponds to theencryption of the location information significantly influences the overallsecurity overhead in the network. This must be taken into account when thestrength of the encryption at this level is determined. Since the protection levelis lower for the location information than for mobile code, the probabilitythat the key for level II can be broken is higher. Having the key, an adversarycould potentially locate all nodes in the network. To constrain the damage toonly one part of the network, the following security mechanism is proposed.Sensor nodes use location-based keys for level II encryption. The location-based keys enable separation between the regions where the location of nodesare compromised and those areas where nodes continue to operate safely.

The area covered by a sensor network is divided into cells. Nodes withinone cell share a common location-based key, which is a function of a fixedlocation in the cell and the current master key. Between the cells, there isa bordering region whose width is equal to the transmission range. Nodesbelonging to those regions have the keys for all adjacent cells. This ensuresthat two nodes within a transmission range from each other have a commonkey. The dimensions of the cells must be big enough for the localized natureof the algorithms in the network to ensure that the traffic among the cells is


relatively low, compared with overall traffic. The areas can be of an arbitraryshape with the only requirement that the whole sensor terrain is covered.A division of the area in uniformly sized cells is the most appropriatesolution, because it allows a fast and easy way for a node to determine its cellmembership. The network is divided into hexagonal cells, since it ensuresthat the gateway nodes have at most three keys.

Part of the bootstrapping mechanism for sensor nodes is the process ofdetermining their cell membership. In this process, the notion of extendedcell is used. An extended cell is a hexagonal cell having the same center as theoriginal cell, and the distance between its sides and the sides of the originalcell is equal to the transmission range of the sensor nodes. The extended cellcontains the original cell and corresponding bordering regions. Figure 7.2shows three neighboring cells and their corresponding extended cells. Eachnode compares its location against each extended cell and determines whetherit is in an extended cell or not. If a node is within the extended cell of Cx, itwill have the key of Cx, KCx. The nodes within the bordering regions (shadedareas) have multiple keys. For example, the nodes that are adjacent to cellsC1 and C2 have two keys: KC1 and KC2, respectively.

In security level III, the application specific data is encrypted using a weakerencryption than the one used for the two other types of data. The weakerencryption requires a lower computational overhead for application specificdata. Additionally, the high frequency of messages with application specificdata prevents the use of stronger and resource consuming encryption. There-fore, an encryption algorithm demanding fewer computational resources isapplied with a corresponding decrease in the strength of security.

The key used for the encryption of level III information is derived from thecurrent master key. The MD5 (Message Digest 5) hash function accepts themaster key and generates a key for level III. Since the master key is periodicallychanged, the corresponding key at this level follows those changes.

C3

C1

C2

Cell

Extended cell

KC1, KC2

KC2, KC3

KC1, KC3

KC1, KC2,KC3

Figure 7.2 Cells, extended cells, and areas with multiple keys.


The major assumptions of security schemes are that the sensor nodes areperfectly time synchronized and have exact knowledge of their location. It isrealistic for the nodes to be synchronized up to microseconds.

7.4. SUMMARY

As sensor networks deployment becomes widespread, security issues becomea central concern. A suite of security building blocks is optimized for resource-constrained environments and wireless communication. SPINS (SecurityProtocol for Sensor Networks) has two secure building blocks: SNEP (SecureNetwork Encryption Protocol) and µTESLA (the micro version of the Timed,Efficient, Streaming, Loss-tolerant Authentication protocol). SNEP providesthe following important baseline security primitives: data confidentiality,two-party data authentication, and data freshness. Efficient broadcast authen-tication is an important mechanism for sensor networks. µTESLA is a protocolthat provides authenticated broadcast for severely resource-constrained envi-ronments. These protocols are practical even on minimal hardware: theperformance of the protocol suite easily matches the data rate of the network.The suite of security building blocks can be used for building higher levelprotocols.

In the security scheme, the security levels are based on private key cryp-tography utilizing group keys. Applications and system software access thesecurity API as a part of the middleware defined by the sensor networkarchitecture. Since data contain some confidential information, the content ofall messages in the network is encrypted.

PROBLEMS

Learning Objectives

After completing this chapter you should be able to:

• demonstrate understanding of the security protocols in sensor networks;• discuss what is meant by design integration;• explain what sensor network security requirements are;• explain what an authenticated broadcast is;• discuss communication security in sensor networks.

PROBLEMS 231

Practice Problems

Problem 7.1: How feasible is adding security to a sensor network?Problem 7.2: What communication patterns should be considered by secu-

rity?Problem 7.3: What are the SPINS assumptions regarding security in wireless

communication?Problem 7.4: How is the base station considered in security of the network?Problem 7.5: What is data freshness?Problem 7.6: What is a secure channel?Problem 7.7: What are the properties of SNEP?Problem 7.8: What are the phases in µTESLA?

Practice Problem Solutions

Problem 7.1:

Adding security to a highly resource-constrained sensor network is feasible.The security building blocks facilitate the implementation of a securitysolution for a sensor network by using an authenticated routing protocol anda two-party key agreement protocol. The choice of cryptographic primitivesand the security protocols in the sensor networks is affected by the severehardware and energy constraints.

Problem 7.2:

The security goal is to adapt the baseline protocols to communication patterns,i.e. node to node or node broadcast, and to address primarily the followingcommunication patterns:

• node-to-base-station communication, e.g. sensor readings;• base-station-to-node communication, e.g. specific requests;• Base station to all nodes, e.g. routing beacons, queries or reprogramming

of the entire network.

Problem 7.3:

Basic wireless communication is not secure. Because it is broadcast, anyadversary can eavesdrop on the traffic, and inject new messages or replayand change old messages. Hence, SPINS does not place any trust assumptionson the communication infrastructure, except that messages are delivered tothe destination with nonzero probability.


Problem 7.4:

The base station is the gateway for the nodes to communicate with theoutside world, hence, compromising the base station can render the entiresensor network useless. Thus, the base stations are a necessary part of thetrusted computing base. All sensor nodes trust the base station: at creationtime, each node is given a master key which is shared with the base station.All other keys are derived from this key.

Problem 7.5:

Informally, data freshness implies that the data is recent, and it ensures thatno adversary has replayed old messages. Weak freshness provides partialmessage ordering, but carries no delay information. Strong freshness providesa total order on a request–response pair, and allows for delay estimation.Weak freshness is required by sensor measurements, while strong freshnessis useful for time synchronization within the network.

Problem 7.6:

A secure channel is a channel that offers confidentiality, data authentication,integrity, and freshness.

Problem 7.7:

SNEP offers the following properties:

• Semantic security: Since the counter value is incremented after each mes-sage, the same message is encrypted differently each time. The countervalue is long enough never to repeat within the lifetime of the node.

• Data authentication: If the MAC verifies correctly, a receiver can be assuredthat the message originated from the claimed sender.

• Replay protection: The counter value in the MAC prevents replaying ofold messages. Note that if the counter were not present in the MAC, anadversary could easily replay messages.

• Weak freshness: If the message is verified correctly, a receiver knows thatthe message must have been sent after the previous correctly receivedmessage (that had a lower counter value). This enforces message orderingand yields weak freshness.

• Low communication overhead: The counter state is kept at each end pointand does not need to be sent in each message. (In case the MAC does notmatch, the receiver can try out a fixed, small number of counter incrementsto recover from message loss. In case the optimistic resynchronization fails,

PROBLEMS 233

the two parties engage in a counter-exchange protocol, which uses thestrong freshness protocol).

Problem 7.8:

µTESLA has multiple phases: Sender set-up, sending authenticated packets,bootstrapping new receivers, and authenticating packets.

Documents

Security Protocols for Wireless Sensor Networks