MiniSec: A Secure Sensor Network Communication

(1)

MiniSec:

A

Secure Sensor

Network

Communication

Architecture

Mark Luk,

Ghita Mezzour, Adrian Perrig

Virgil

Gligor

CyLab,

Carnegie Mellon University

University of

Maryland

Pittsburgh,

PA

College Park,

MD

[email protected],

[email protected]

ABSTRACT

energy consumptionwhile simultaneously providing the three

im-Secure sensor networkcommunication protocols need to provide portantproperties of secure communication: secrecy, authentica-three basic properties: data secrecy, authentication, and replay pro- tion, and message replay protection.

tection. Secure sensornetwork link layer protocols such as Tiny- TinySec, apopularsecurelinklayer protocol, achieves low en-Sec [10] and ZigBee [24] enjoy significant attention in the com- ergy consumption and memory usage. Unfortunately, it also sac-munity. However, TinySec achieves low energy consumption by rifices onthe level ofsecurity. For example, it employs asingle reducingthe level of security provided. In contrast, ZigBee enjoys network-wide key, such thatevery node in the network can mas-high security, but suffers from mas-high energy consumption. querade as any other node. Second, TinySec does not attempt to

MiniSec is a secure network layer that obtainsthe best of both protectagainst replay attacks.

worlds: lowenergy consumption andhigh security. MiniSec has ZigBee provides a higher level of security than TinySec since it two operatingmodes, one tailored for single-source communica- is notrestricted to a network-widekey. By keeping a per-message tion, andanother tailored for multi-source broadcast communica- counter asthe Initialization Vector (IV), ZigBee protects against tion. The latter does not require per-sender state for replay pro- messagereplayattacks.However,ZigBee is an expensive protocol. tection andthus scales to large networks. We present a publicly First,ZigBee sends the entire 8-byte IV with each packet, resulting available implementation of MiniSec for the Telos platform, and inhighcommunication overhead andhigh energy consumption by experimental results demonstrate our low energy utilization. the radio. Also,ZigBee requires per-senderstate, which consumes

INTRODUCTION

_{trast, previous}while retaining the security of a full-length IV per packet. In

con-approaches require two passes over the plaintext

Considerable attention

hadpbeen

paidto developing securesensor (one for encryption and one for authentication) and transmission

network communication protocols. Unfortunately, existing tech- of the full-length IV. Third, we exploit the fundamental distinc-nologies, such as TinySec and ZigBee, are unable to achieve low tionsbetween unicast and broadcast communication, providing two

*This

research was supported

in

partby CyLabat

Carnegie

Mellon

energy-optimized

communicationmodes. Inunicastmode, we

re-undergrant DAAD19-02-1-0389 fromthe Army ResearchOffice, duce the

radio's

energy

consumption

by

using synchronized

coun-and grants CNS-0347807 and CCF-0424422 from the National ters andperformingextracomputation. Although radically differ-Science Foundation, and by agift from Bosch. Virgil Gligor's entfromconventional networking protocols,such a scheme is de-work wassupportedbythe US Army ResearchLaboratoryunder sirable in this setting because ofthe stringent energy constraints the Cooperative Agreement DAAD19-01-2-001 1 for the Collab- ofsensor networks. In broadcast mode, we employ a Bloom-filter orative Technology Alliance for Communications and Networks. basedreplay protection mechanism that avoids per-sender state. Theviewsandconclusions containedhere are those of the authors

andshouldnotbeinterpreted asnecessarily representing theoffi- MinSec's improvementin energyconsumption comes at the cost cialpoliciesorendorsements, either express or implied, of ARO, ofamodest increase inmemory size, which isadesirable tradeoff

Bosch,CMU, NSF, orthe U.S. Government or any of its agencies. in sensor nodes. Note that TinySec had been developed for the Mica2motes in2003, when memory constraints were much more

stringentthanthey aretoday. The current trend in mote develop-ment reveals that memory size has been consistently increasing,

Permissionto makedigital or hard copies of all or part of this work for while energy constraints remain as stringent as ever. Thus,the de-personal or classroom use isgrantedwithout feeprovided that copies are signtradeoffs in MiniSec make it well-suited for current state-of-not made or distributed forprofit or commercial advantage and that copies the-art sensor devices.

bear this notice and the full citation on the firstpage.Tocopyotherwise,toWepsntMiecaaco lteouintoeursnore-republish, to post on servers or toredistributetolists, requires prior specific wr omncto,adipeettepoooo h eo

permission and/or a fee. wr ommao,adipeettepooo o h eo

(2)

eralpurpose security protocol available for this popular platform. sinceTinySec and SNEP almostdoubles the amount of computa-Furthermore, MiniSec's source code ispublicly available

1,

and it tion,the energy consumption also doubles. By comparing the num-canbe easily ported to other platforms. ber of block ciphercalls, OCB only requires

[

M

]

block cipher We evaluate MiniSec'sperformance against TinySec [10]. Our_{circustancs, ou} _{enegy cosump-} _tweecalls [20], while CBC-encryption and CBC-MAC together take be-

[20F

Mhl

2B

Fcytinan

M+MCtoehe1ak

_e results show that under most circumstances o + to +4

block

cipher

calls,

depending

on

tion of security related tasks is

aboutofthnn

₃ _{the energy}

consumption

padding

(recall

_that _M

is

n_the

message

length,

_{and n is} _the

block-TinySec, yet we are still able to provide ahigherlevel ofsecurity.

size).

Themain contributions of this paper are s follows.

Bloomfilter. The Bloom filter is a

space-efficient

datastructure

* We introduce MiniSec, the first fully-implemented general used for fast probabilistic membership tests [4]. It features two purpose security protocol for the Telos sensor motes. functions: membership addition and membership query. It is possi-ble to have false positives, where a query returns true eventhough

* MiniSec simultaneously achieves low energy overhead and the element is not in the set. However, falsenegatives, where a ahighlevel of security(data secrecy, authentication, and re- query returns false whenthe element is in fact a member of the set, play protection). This is the first protocol to achieve replay is not possible.

protection inthe sensor network broadcast setting. A Bloom filterrequires an array of m bits and k hash functions. The array is first initialized to all zeros. Each hash function maps * We measuretheperformance ofMiniSec andshowthat, un- an element to one of the m array positions. To add an element,

der most real-world scenarios, MiniSec outperforms other the element is hashed byall k hash functions, and the k subsequent

comparable

sarray

positions

are set to one. Toquery for anelement,we usethe * The sourcecode of MiniSec is

publicly

available. We pro- khash functionstoarriveatthe k bit

positions.

Ifany ofthemwere

vide a

turnkey

system for sensor network

developers

that zero,then the element isnotin the set. If all bitswereset toone,

seamlessly integrates

into

TinyOS

applications,

then either the element is indeed in the

set,

orall k bitswereset to one

by

insertion of other elements. The latterdemonstratesafalse

2.

BACKGROUND

positive. The more elements are added to a Bloom filter, the higher_the

probability

_of_a_false

positive.

Severalencryption modes exist that achieve secrecy and authen- Bloom filters are wellsuited in the severe resource-constrained tication. We select OCB [20] as our encryption mode since it is environment of sensornodes because of space and time advantages.

especiallywell-suited forthe stringent energy constraints of sensor The space advantage isapparent, since it only requires O(nlogn)

nodes. In addition toOCB, MiniSec also uses Bloom filters [4] and bits to store a fingerprintof n messages. Bloom filters also exhibit loose time synchronization to minimize energy consumption. In the desirable propertythat adding and querying an element occurs concert, Bloom filters and loose timesynchronization canbe used in constant time.

toprovideefficientreplayprotection in broadcast communication.

In

this

section,

we

briefly review OCB and Bloom filters.

3.

PROBLEM

DEFINITION

OCB. OCB, or Offset CodeBook, isablock-cipher mode of

op-erationthat features authenticatedencryption. Givenaplaintextof

3.1 Assumptions

arbitrary length, OCB generates aciphertext thatsimultaneously We assume thatsymmetric keys are already established between provides authenticity and datasecrecy. OCB isprovably secure, each sender and itsreceivers. We recommend a different key for and isparameterizedon ablockcipherofblocksize n and a tag of each sender, but ourprotocol is by no means restricted to such a

length

'.

' is definedsuch that anadversaryisable to forge a valid setup. We also assume asecure routing protocol that can

success-ciphertextwithprobabilityof

2'.

fully route packets to theintended destination with non-zero prob-OCBoperates as follows. LetMbeanarbitrary lengthmessage ability.

that needs to beencryptedandauthenticated,Hbeanoptionalmes- A list of sensor network keying and routing protocols can be sageheader thatonly requiresauthentication, Kbe theencryption found in Section 9. Thegoal of MiniSec is to leverage such exist-key(whichisthekeyusedbytheunderlyingblockcipher), and N ing primitives to provide for secure node-to-node communication be anon-repeating nonce. First, OCBtakes inM, K, and N, and at low energy cost.

generates theciphertextcoreC. Concurrently, usingtheplaintext

M, ciphertext

C,

and

H,

OCB

generates

tag

of

length

r. The final

3.2 Attacker Model

output ofOCBK

(N,

M,

H)

is the tuple

(C, tag).

To decrypt aci- Sensor nodes rely onradio broadcasts for communication. We

phertext

(C, tag),

the receiver performs the reverse process on C to thus adopt the Dolev-Yao attacker model, where an attacker can arrive atplaintextM. Then, the receiverensures that the tag isas overhear, intercept, alter,or inject any messages into the radio

com-expected. Ifthereceiver computes adifferent tagthan theonein munication channel.

theciphertext,theciphertextisconsideredtobe invalid. We do not restrictattackers to computationally bounded motes. OCB is especially well suited for sensor nodes. First, OCB By using sufficiently long symmetric keys (i.e., 80 bits), we can avoidsciphertext expansion. Givenanarbitrary lengthmessagesM, defend against bruteforce attacks by a powerful adversary

[13].

OCBgeneratesciphertextwithlengthof

IMI

+ z.Disregardingthe

tag, the

ciphertext

core

has the same

length

as the

plaintext.

Sec-

3.3 Desired Properties

ond, OCBhassuperior performance,since itprovides secrecy and We now present thedesired properties of a secure sensor network authenticity in one pass of the block cipher. TinySec and ZigBee communication architecture.

provide the same security guarantees, but requires two passes of the Dt uhniain aaatetcto moeslgtmt

blockciher:

pass achievesn

sehetcrecy

with

CBC-enCrypton,eq andly

nodes to verify whether a message indeed originatedfrom another

anoter pss ahievsauhentcit wit CBCMAC.Consquenly, legitimate node (i.e., a node with which it shares a secret key) and

(3)

should not be able to participate in the network, either by injecting

4.

MINISEC OVERVIEW

their own messages or by modifying legitimate messages. We present MiniSec, a secure network layer that satisfies all the Data authentication is one of the basic building blocks of asecure security properties outlined in Section 3. MiniSec has two operat-system. For example, nodes need to verify commands from the ing modes: unicast and broadcast, henceforth known as MiniSec-U base station, and a base station needs to authenticate whether the and MiniSec-B. Both schemes employ the OCB-encryption scheme data readings indeed originate from valid nodes. to provide for data secrecy and authentication (see Section 2), while Typically, data authentication is achieved by the sendercomput- using a counter as a nonce. The two modes differ in the way ing a message-authentication code (MAC) over the payload andap- they manage the counters. In MiniSec-U, we employ synchronized pendingthat to the message. Upon reception, the packet is consid- counters, which require the receiver to keep a local counter for each ered tobe valid if the receiver recomputes the MAC and it matches sender. MiniSec-B has no such requirement for per-sender state. with the received MAC. ZigBee, TinySec and SNEP provide data Instead, meta-data to prevent replay attacks is stored in a Bloom authenticationbyusingthe CBC-MAC function, using Skipjack or Filter. Both schemes will be explained in detail in Sections 5 and 6,

RC5 as the block cipher. respectively.

DataSecrecy. Data secrecy, another basic requirement of any se- Notation. We use the following notation to describe our protocol cure communication system, prevents unauthorized parties from and cryptographic operations:

discovering the plaintext. It is typically accomplished by setting

up anencrypted communication channel. A,B

Communicating

nodes.

Encryptionschemes or modes can be evaluated based on differ- KAB OCBEncryption keyused for

communi-entcriteria. A

strong

level of

security

is the notion of semantic

cation

channel

from Ato B. Note

that

security [3, 9]. The Handbook of Applied Cryptography defines

key

KBA

would

be usedtoencryptdata semantic security such that "a passive adversary with polynomi- CAB Monotonically increasing counter ally bounded computational resources can learnnothing about the corresponding toKAB.

plaintext fromthe cipher text" [1]. Semantic security implies that

(C, tag)

AuthenticatedencryptionunderOCB,

aneavesdropper cannot gain any information about theplaintext,

OCBK(N,M,H)

where M is the

plaintext

message, H is even afterobservingmany encryptions ofthe same plaintext. an optimal message header that only

Insecure communicationprotocols, data secrecy is providedby needstobe

authenticated,

Nisa64-bit

acryptographic encryption scheme. To guarantee semantic secu- NA A nonce generatedby device A. rity, wetypically requireaprobabilisticencryption scheme and an

unique

initialization vector

(or IV)

for each

encryption

to add

vari-

5.

MINISEC-U:

UNICAST

COMMUNICA-ation totheciphertext.

TinySec uses CBC-encryption,while SNEP and ZigBee employ TION counter-mode encryption. MiniSec provides both authentication

andsecrecy using OCB-encryptionwith a non-repeating counter. 5.1 Motivation

ReplayProtection. A replay attack is when attackers record en- Both

TinySec

and SNEP have

developed

solutions for

provid-tirepacketsandreplaythem at a later time. TinySec is not resilient

ing

secure communication in the unicast

setting,

where wehave tosuch anattack,while SNEPprovidesprotection using a counter. onesenderA andonereceiver B.

Although

both

protocols

attempt Sections5 and 6 demonstratehow MiniSecprovides replayprotec- to minimize energy

consumption,

there are aspects of both that tion inthe unicast and broadcast setting,respectively. demonstrate inefficient energy usage.

TinySec

uses an

encrypted

Freshness. Since sensor nodes often stream time-varying mea- counter as its IV. This counter is appended to each message, result-surements, providingguarantee of messagefreshness is an impor- ing in a 2-byte overhead per packet. SNEP also uses a counter as tantproperty. There are two types of freshness: strong freshness the IV. However, SNEP conserves radio energy consumption by not and weakfreshness. MiniSecprovides amechanism to guarantee sending the counter with each packet. Instead, the counter is kept weakfreshness, where a receiver can determine apartialordering as internal state by both sender A and receiver B. However, dropped overreceivedmessageswithout a local reference time point. Note packets would cause the counters to become inconsistent, in which that both ZigBee and SNEPprovideweakfreshness,while TinySec case both parties need to participate in an expensive counter resyn-does notprovideany form offreshness. chronization protocol.

TinySec and SNEP represent two extremes: sending the entire Low Energy Overhead. Energy is an extremely scarceresource counter as opposed to not sending the counter at all. The key insight insensornodes. Thus,it is of_{* S}paramount importance forthesecu- _{~~~~~~~~~~behind}

behind Minise

_{MiniSec-U iS}

th

_that

otima

optimal

ene usae an beaev

_{energy usage}_can_{be achieved}by

by

rityprotocol to retain a low energy overhead. Inparticular, radio combining the best of both approaches. Similar to SNEP, MiniSec-communication consumes the most amount of energy. On the

Te-losplafor, sndigasinle yteis quialett excutn aout U

maintains

a

synchronized monotonically increasing

counter

CAB

los platform,

sending

a

single

byte

iS equivalent

to

executing

about between a sender A and a receiver B as the IV. However, MiniSec-U 4720 instructions. Thus, to reduce energy consumption, it is imper- includes the last x bits of the counter along with each packet. We ativetominimize communicationoverhead, call

this

theLB(Last

Bits) Optimization,

andthe lastx

bits

ofthe

Although public key cryptography hadenjoyedmajor advance- counteriscalledthe LB value.

By

keeping

xlow,the radio's energy

ment recently, it is still 3-4 orders of magnitude more expensive consumptionisalmost as low as notsending the counter at all. than symmetriccryptography intypicalsensornodes. Because it The LB

optimization

addresses one ofthe main drawbacks of requires less energy consumedbythe processor, securityprotocols SNEP, which is

running

the

expensive

counter

resynchronization

thatonly employ symmetric cryptography are preferredin sensor protocol when packets are dropped. Instead, the LB

optimiza-network~ ~

aplctin.ton

allows

resynchronization

to occur

"implicitly." Since

sender Resilient to Lost Messages. The relatively high occurrence of A sends the last x bits of the counter, receiver B can compare the dropped packets in wireless sensor networks requires a designthat last x bits of its local counter CAB to the LB value appended to the can tolerate high message loss rates. packet. As long as there are fewer then 2x dropped packets since

(4)

the last successfully received packet, the receiver can immediately

5.3 Energy Analysis

increment his counter such that the final x bits match the LB value. Let x be the number of lowest counter bits to append to the For example, let x be 3, and the counter CAB be synchronized on packet, and y be the maximum number of trial decryptions the re-both parties at 0. Sender A sends six packets, but the first five pack- ceiverperforms as explained above. Let random variable I repre-ets were dropped. Receiver B successfully receivesthe 6th packet, sent thetime at which the node is able to decrypt the message (if which was sent using CAB of 5. B would thus immediately incre- the nodesuccessfully decrypts the message), where 1 < I<y. The ment hits counter CAB to 5 and attempt decryption. goal ofthis section is to determine the parameters x andy.

The LB optimization is useful even if more than2x packets were Generally, a receiver would perform i decryptions, if there were dropped, since the receiver could simply continue to increment CAB atleast (i-1)2X and at mosti2X- 1 dropped packets. Thus, the

by2x andreattempt decryption. In practice, the receiver B would probability that exactly i decryptions occur is (wherePgar is the set a maximum such that after y consecutive failed decryptions, B probability that a message is garbled in transmission, and Pr is the would runthe expensive counterresynchronizationprotocol. probability that the message is received):

Lastly, by specifying the parameter x, we could arbitrary lower i2x-1

theprobability ofreverting totheresynchronizationprotocol. By P(I=i) (1-Pgar) ,

(1

-pr)kpr

monitoringthe quality of the channel, it is possible to analytically k=(i-1)2x

solve forthe optimal values of x and y such that energy consump- (1 - Pgar) (1 -

Pr)

(i-l)2x [1-(1-p

)2x]

tion isminimized. We demonstratethis in Section 5.3.

Thus,

_the

expectation

of I is:

Y

5.2 Protocol Description

E(I)

=_i=1

iP(I

=

i)

Inthis section, we describe the mechanics of MiniSec-U, in the Y

context ofsender A and receiver B. In MiniSec-U, each pair of =[1- (1

Pr)]

-i[(Pr)2X]1

sender and receivershare two keys, KAB to protect communication

from A toB, and KBA to protect communication from B to A. Fur- =

(1

p

)2x]

x -

(yY+

)

P(1

pr)y2

+y(l

-Pr)(y+1)2x

thermore, amonotonically increasing counter is assigned to each [1-(1

-Pr)2

key as the IV (CAB used to for key KAB), and is kept as internal

+(l-Pr)y2

+Y[1-(l-Pr)2x]

statebyboth sender and receiver.

I__

_ _ _

Weemploy OCB-encryption with the packet payload as M, packet 1-(1- Pr)2

header as H, counter CAB as the nonce, and KAB as the encryption

key. We selected Skipjack tobe the underlying blockcipherwith a Theexpectedenergyconsumed is thesumof theexpectedenergy blocksize of 64 bits. Since OCB requires the nonce to be the same

spent

whenaneventhappenstimes theprobabilityof this event to

lengthasthe block size, counter CAB can also be 64 bits. Alterna- occur

plus

the energy

required

for

receiving

xbits. At the

reception

tively,the counter could be of shorterlength, andbepaddedout to ofamessage, two scenarios arepossiblefor the receiver: (1) the 64-bits whenrequestedbythe OCB encryption function. The sec- receiver is able todecryptthe message at the i-th trialdecryption.

ondparameter of OCB isthe taglength, which we set to 32bits,a This eventoccurs with probability

P(I

=

i)

and its cost is

E(i

*

lengthsuitable for security in retailbanking [20]. Finally, receiver

EOCB)

=

E(I)EocB,

whereEOCB

represents

the cost ofan OCB

Bneeds to maintain counterCAB. Upon receiving anddecrypting a

decryption.

(2)The receiver is unable to

decrypt

the messageeven

validpacket,Bwould increment its local copyof CABaccordingly after

trying

y times. This

happens

either because more than

y2x

sothat it remains consistent with A. packetswerelostconsecutively,orbecause thepacketthatwasjust

Since OCB isprobabilistic, astrictly monotonicallyincreasing received is

garbled

due toatransmissionerror(an

unlikely

event). counterCAB guarantees semantic security. Even ifthe sender A re- Thus, let Erec be the energy forreceivingonebit,

Eresync

be

peatedlysendsthe same message, eachciphertextisdifferent since the energy requiredto execute the counterresynchronization pro-a different counter value is used. Also,once areceiver observes tocol, and

E(I)

be as described above, then the

expected

energy a counter value CAB, it rejects packets with an equal or smaller

consumption

per

packet

EEnergy

is:

countervalue.Therefore,anattacker cannotreplayanypacketthat

the receiver haspreviouslyreceived.

EEnergy

=E(I)EocB(1-

Pgar)+

There are four interesting issues about using counter CAB as the (1 pgar) (1

pr)y2x

IV. First, because of the nature of OCB encryption, the counter

[YEOCB

+Eresync

IPgar

+( xErec

itself is not a secret. Even if an attacker knows the counter, the Weneed to find the ideal x and y for a given environment. A

specified security properties are notcompromised. This contrasts lossychannel with high packet loss requires larger values for x and toCBCencryption usedbyTinySec, which requires a random and y. InSection 8 we discuss how to select x and y in practice.

unpredictablenonce asthe IV.Second,inorder toprovide

seman-tic

security, the counter cannot wrap around.

A

longer counter

6.

MINISEC-B:

BROADCAST

achieves higherlevel ofsecurity, yet adds additional overhead to

each

packet.

Since we do not

append

the entire counter to each

COMMUNICATION

packet, MiniSec enjoys the security benefits of a longercounter MiniSec-Ucannotbedirectlyusedto securebroadcast commu-without paying the communication cost. This allows us to use a 32- nication. First,itwouldbetooexpensiveto runthecounter resyn-bit orlongercounterwhileTinySecuses a16-bit counter.Third,de- chronization protocol among many receivers. Also, ifanodeB spite the LB optimization, large number of dropped packets could were to simultaneously receive packets from a large group of send-still cause the counters to be desynchronized. Appendix A presents ing nodes (A1 ,A2, . ..

,An),

B would need to maintain a counter for a counter resynchronization protocol similar to one used in SNEP. each sender, resulting in high memory overhead.

Finally, a different counter is needed to be instantiated per key. Similar to MiniSec-U, MiniSec-B uses OCB encryption to se-Thus, if we rekey, the counter can be reset to zero. cure broadcast communication. Simply encrypting each packet

(5)

with OCB provides secrecy and authenticity, while an increasing Threshold time counter can stillbe used as the IV to provide for partial ordering Vulnerability window

ofmessages. However,withoutsynchronizedcounters, there is no I

defense againstreplay attacks. In fact, defending againstreplay at- AT

AN

AT

AN

AT

tacks in abroadcast setting without per-sender state is currently an - > ----.I- ' - -openchallengeinthe sensor network community.

This section describes two related mechanisms used in

MiniSec-Bto

provide replay

protection.

First,

we

present

a

sliding-windows

l I

approachthat defends against replay attacks with a certain vulner- tr, tr2

ability window; replayed packets outside the sliding-window are l

always dropped. Next, we discuss a BloomFilter-basedapproach E Ei

which defends against attacks within the window.

Ett

Ei

l

6.1 Sliding-windows Approach

Wedefine anepochtobe a finite time

te,

and wesegment time Figure 1: Timeline. AT is the maximum time synchronization

into a series ofte-lengthepochs {E1,E2,E3,...}. Leveraging loose errorbetween sensor nodes. ANisthe maximum networklatency.

timesynchronization [8,21],each node agrees on the currentepoch

Ei

isthecurrentepoch. Thisfigureshows that apacketreceived at

Ei.

The maximum time synchronization error between any pair of

tri

could nothave been sent earlier than

tS2,

and apacketreceived nodesis AT. Finally, let AN be the maximum network latency. at tr2 couldhave beensentaftertS2

Simplyusing the currentepochnumber as the nonce for OCB-encryption defends againstreplay attacks from olderepochs.

Un-fortunately,

because of timesynchronization error and network la-

6.2 Bloom Filter-based

Approach

tency,such a scheme experienceshighfalsepositives atepochtran- As stated above, the sliding-windows based approach has the sitions, as legitimate packets sent from the previousepochwillbe drawback of a window of vulnerability for replaypackets. This

discarded. problem could be easily avoided by simply storing allpackets

re-The solution is to simply perform decryption with twopossible ceived within this window. Unfortunately, this solutionis not prac-candidateepochvalues forthe nonce. First, we defineepochlength tical for sensor nodes because of limited storage. Thus,we augment te to be 2AT +AN. Let

Ei

be the current epoch number, andti the sliding-windows approach with a countermaintained as inter-be the time at the start of

Ei.

Ifonereceives apacket within(ti, nal state by the sender, and two alternating Bloom Filters stored

ti

+ AT +AN), the two candidate values for the nonce are

Ei

and by all nodes. In concert, they provide replay protectionwithin the

Ei-

1. Ifone receives apacketwithin

(ti

+ AT +AN,

ti+i

), the two vulnerability window using constant storage.

candidate values are

Ei

and

Ej+i.

This threshold isdepicted in Similar to the counter used in MiniSec-U, counter CA is kept as Figure I asthe dotted line. internal state by sender A and is incremented each time it sends a The intuition is as follows. First, we define

ts,

tobe the local time packet. The only difference is that the sender resets thecounter at recordedbythe sender when packet i is sent, and

tri

tobe the local the beginning of each epoch, so that the counter itselfcan be short time experiencedbyreceiver whenpacket iisreceived. Further, enough to be transmitted with each packet. If we canbound the let

3,

be the actual network latency such that 0 <

an

<AN, and number of broadcast messages sent by a node in each epoch to k,

3t

be actual time synchronizationerrorsuch that -AT <

at

<AT. the length of the counter can be bounded tolog2(k).

Notethat a positive

at

indicatesthat the sender's clock is behind the Unlike MiniSec-U where simply the counter is used as the nonce receiver'sclock, while a negative

at

indicatesthe opposite. Thus, for OCB encryption, the nonce in this case is theconcatenation of

wehave the sender'snodelD A, CA, and current epoch number

Ei.

Thus, the

ts +an+at tr, cipher-text sent is (C, tag) OCBKA

(nodeID

ICA lEi,

M,H)). Note

tl lthatthis nonce is never reused for agivenkey epochnumbers do Inthe first case, as illustrated in Figure 1, we deal withpackets notwrap aroundduringasender's lifetime.

that are received within the range of

tr1

andtr2,where tr=

tj

+£, ReceiverBmaintains itsBloom Filters inthefollowingmanner. and tr2

ti

+AT +AN-e. Toshow that such traffic mustoriginate ABloom Filter

BFi

isassignedtoeachepoch

Ei.

Allvalidpackets

fromeither epoch

Ei-,

or

Ei,

the receiver needs to determine the correspondingtoepoch

Ei

arestored in

BFi,

using

(CA

sourceID)

earliest possiblevalue of

ts1

andthe latestpossible value of

ts2.

asthe Bloom Filterkey. At all times, each nodekeeps aBloom Since

ts, tri

-

at

-

an,

the earliest value of

ts1

is

tri

-AT-AN, Filter

BFi

forthecurrentepoch

Ei,

andeither

BFi-

1 fortheprevious

which falls within

Ei-1.

Similarly, since

tS2

tr2-

at

-

an,

the epoch

Ei-

1,orBFi+1forthenextepoch

Ej+

1.

Forexample, starting

latest valueof

tS2

istr2 + AT,which falls withinepoch

Ei.

atthebeginningofepoch

Ei

untilAT +ANintotheepoch,the node Inthe second case(not illustrated),wedealwithpacketsreceived maintains Bloom Filters

BFi

and

BFi-1.

After

at

+

an,

allpackets

within the range of tr3 and tr4 where tr3 ti +AT+AN+e and fromtheepoch

Ei-,

willbedropped,whilepacketsfromthenext tr4

tj+j

-e. Again,the receiver needs todeterminethe earliest epoch

Ej+j

willbe accepted. Thus,

BFi-1

is resetand reusedas

possiblevalue oftS3 and latestpossiblevalueof

tS4.

Using similar

BFi+1.

logic,wefindthat earliest valueof

tS3

istr3-AT-AN,which falls Inthe previous section, we concluded thatonlytwo candidate withinepoch

Ei.

Latest value oftS4 is tr4 +AT, which is within epochsexist foranyincomingpacket. Since wehave oneBloom

Ej+i

. filterassignedtoeachepoch,avalidpacketmustcorrespondto one

Based on this technique, there are only two candidate epochs for of the active two Bloom filters.

any incoming packet. However, if a valid packet hadbeen sent at When receiver B receives apacket, it needs to performtwo checks: the beginning of an epoch, an attacker can replay that packet for the 1) determine whether the packet is a valid packet encrypted under remainder of the epoch as well as

at

+

an

into the next epoch. Thus, OCB, and 2) determine whether the packet has been replayed. To the maximum windowof vulnerability for replay is

3at

+

2an.

verify if it is a valid packet, the receiver performs OCB

(6)

decryp-tion. Sincethe counter and the source address are included in the packets will all be rejected.

packet as plaintext, the only portion of the nonce that is missing Replay Protection in MiniSec-B. The entire network lifetime is is the epoch number. The receiver can recover the epoch number segmented into epochs. MiniSec-B leverages loose time synchro-easily, sincethere only exists two candidate epoch number for any nization to prevent replayed packets from previous epochs. Next, received packet. Hence, the receiver attempts OCB decryption with each receiver uses a Bloom Filter to track packet history foreach both. If both decryption fail, the packet is dropped.

epoch.

Thus,

MiniSec-Bachieves

protection against

replay

attacks.

Next, the receiver needs to determine whether the packet has been replayed. Since theepoch number is known, B queries the

corresponding Bloom Filter for this packet. If the query returns

8.

IMPLEMENTATION

true, the packet is considered to be a replay and is consequently

dropped. Ifthe Bloom Filter declares that this packet is fresh, the

8.1 System Architecture

packet is considered tobe a non-replayed packet. It is consequently We have developed MiniSec for the Moteiv Telos motes - a pop-accepted and added intothe Bloom Filter. ular architecture in the sensor network research community. It fea-Using such a counter provides for semantic security since send- tures the 8MHz TI MSP430 micro-controller, a 16-bit RISC proces-ingthe same message never results in the same cipher-text. Also, sor that is well known for its low energy consumption. Although this scheme provides for replay protection. If receiver B were to re- we implemented MiniSec on the Telos motes, our designprinciples ceive areplay packet,hashingthe source ID and counterCA,would are general enough such that porting MiniSec to different sensor result in amatch in all the corresponding bits in the Bloom Filter. platforms should yield similar performance results.

Therefore, B would suspect a replay attack and reject the packet. To implement MiniSec, we rewrote part of the TinyOSnetwork Notethat such a replay policy would detect all replayed attacks, stack. Specifically, we created GenericCommMiniSec based on resulting a0%false negative rate. However,because Bloom Filters GenericComm, a "generic" TinyOS network stack. Instead ofusing may cause false positives; afresh packet may be deemed to be a re- the interface AMStandard for Active Message transmission, played packet. There are various trivial solutions to lowering false GenericCommMiniSec directs all messages to AMStandardMiniSec, positives. Forexample,byselectingthe size of the Bloom Filter m a custom-made ActiveMessage layer that encrypts outgoing mes-and duration of anepoch, theprobabilityoffalsepositives canbe sages and decrypts received packets. To use MiniSec, adeveloper loweredarbitrarily [4]. simply needs to replace GenericComm with GenericCommMiniSec in

the application's configuration file.

7. SECURITY ANALYSIS

Packet Format. We base MiniSec's

packet

formatonthecurrent

TinyOS

packet header for Telos mote's CC2420 radio. The Telos Inthis section, we provide an analysis on the level of security mote is one of the first wireless sensor devices to be equippedwith promised by both MiniSec-U and MiniSec-B. First, we discuss an IEEE 802.15.4 radio. Figure 2 shows the packet format for plain propertiesthat are common across both protocols. Next, we dis- TinyOS, TinySec, and MiniSec.

cusshow these protocols are different. The fields that MiniSec share with original TinyOS are: length, Authentication. Both MiniSec-U and MiniSec-B use OCB en- FrameControl

Field,

datasequence

number,

destination PAN ad-cryption toprovide for data authentication over thepayload and

dress,

destination

address,

and the AM number. MiniSecreplaces packetheader. The security of OCB's authentication scheme is di- the2-byteCRC witha4-bytetag, since the tagalreadyprotects the rectly related to

',

the lengthofthe tag. By setting to be 32 packet from

tampering.

Inthe

original TinyOS,

the

1-byte

groupID

bits, an adversary has a 1 in 232 chance of forging a correct tag serves as a crude form ofaccess control. Each set of communi-for aparticularmessage. This suffices for themajorityofpractical

cating

nodes share adifferent group-ID, and messages with

for-applications.

eign group-IDs

are

dropped.

This field is no

longer

necessary in

SecrecyandSemanticSecurity. Semanticsecurity requiresthat MiniSec because access control is achieved through the use of dif-noncesdo not repeat. (Also notethat since the senderuses astrictly

ferent

cryptographic

keys.

Finally,

similar to

TinySec,

MiniSec

monotoniccounter asthe nonce, eachciphertext would be different

requires

a

2-byte

source address, which is absent in a standard

evenifthe

plaintext

werethe

same.)

Avoiding repetition

ofnonce

TinyOS

packet.

Thenet overhead ofaMiniSec

packet

is

3-byte

is easy. In MiniSec-U, the counter is kept as internal state, and increase over a standard TinyOS packet. thus can be madearbitrarily long. Wechoose 8bytes,which means

that the nonce would not repeat until aftersending 264 messages.

8.2

MinSec-U

Implementation

InMiniSec-B,the nonce is the concatenation ofsourcelD, epoch MiniSec-U uses two

security primitives:

OCB encryption and number e, and a counter. By using all threevariables,twomessages

Skipjack.

We selected

Skipjack

to be the

block-cipher

because of inthe network would never share the same nonce. efficient

computation

and low memory

footprint

[12]. To make Weak Freshness. In MiniSec-U, the receiver can arrive at the

encryption

asflexibleas

possible,

weset

Skipjack's

block sizeto64 countervalue used foreach

packet

by

verifying

the

validity

of OCB bits.

Furthermore,

we use80-bit

symmetric

keys,

since Lenstraand

decryption.

While inMiniSec-B, thecountervalue is included in Verheul recommended that such

keys

areconsidered tobe secure the packetaplaintxtInbthcase,the re r

cuntil

2012, evenagainst resourceful adversaries [13]. When 80-bit

the~~~~~~~

~~ ~

pake as

plitx,I

ohcss tercie a sh keys become insecure, we would use 128-bit AES keys, which is countervalue of twomessages to enforce message

ordering,

thus

providing

weakfreshness. secureforatleast thenext20 years.

Miie*

adMnSc- xiitdfeet eairin replay OCB

implementation

is

ported

from

Rogaway's original

OCB

Minitection.

and MiniSec-B

exhibitdifferentbehaviorlibrary2

tothe nesC interface.

Similarly,

the

Skipjack

implemen-protection.

~~~~~~~~~~~~tation

is ported to nesC from Yee Wei Law's implementation [12]. Replay Protection in MiniSec-U. Each sender and receiver keeps In total, MiniSec-U requires about 4000 lines of nesC code, and a synchronized counter that is used as the nonce in OCB

encryp-tion. The receiver would only accept messageswith higher counter

2http:!!www.cs.ucdavis.edu!rogaway!ocb!code-2.0.htm,

accessed values than the those maintained in the node state. Thus, replayed June 26, 2006

(7)

1 2 1 2 2 1 1 0.28 2 Len FCF DSN DstPAN DstAddr AM Grp Data CRC

(a)

TinyOS

2 1 2 2 1 2 2 0.28 4

Leni FCF DSN DstPAN DstAdd AM SrcAddr Ctr Etw Dta MIC

(b) TinySec-AE

1 F 2 1 2 2 1 2 0...28 4

~en

FCF DSN DstPAN DstAddr AM SrcAddr E a Tag/MIC Ctr[0:2]

(c)

MiniSec-U

1 212 2 2 2 0.28 4

enFCF DSN DstPAN AM SrcAddri t

Tag,'MIC

Ctr[0:2] Ctr[3:7]

(d) MiniSec-B

Figure2: Packet Format. The size of each field is indicated in bytes. The packet fonnat is based on the TinyOS packet for CC2420 radio. The diagonally

hashedregions areauthenticated;the checkered regions areencrypted;the gray region represents where we overload thecorresponding field with the counter.

consumes874bytesof RAMand 16 KB of code memory. We also show howthe sensor network administrator can calculate PacketFormat. MiniSec-U uses the LB optimization by sending custom values of m and h appropriate for a particular network pa-the last x bits of pa-the sender's counter along with each packet. Since rameterized on the network activity and underlyinghardware. TinyOS payloads arenever greater than 29 bytes, we can safely The false positive rate of a Bloom filter canbe calculatedbased overloadthe first 3 bits of the lengthfield to storethese bits, as on number of stored items. Thus, we first upper boundP,u, the shown in Figure 2(c). This is a significant advantage since we do average number of packets received in one epoch oflengthte. If not sufferany communicationoverhead for sending the last x bits this is known a priori (e.g., regular heartbeats), the sensor network ofthe counter. administrator can directly configure the Bloom filter accordingly.

Ourempirical results show thatby using the last 3 bits of the Else, we make the following argument.

counter, even underhighpacket drop rate, the counterresynchro- Let t1 be a realistic lower bound of a node's lifetime,EC be energy nization protocol was rarely executed. Because of the above rea- capacity of the node's battery, andEpbe energy consumption for sons, we use the default value of x 3for the remainder of the receiving one packet. In the worse case, all energy provided by the

paper. battery will be used for packet reception. Hence, maximum

possi-ble

packets

receivedoverthe entire lifetime of the node is

EC/Ep.

8.3

MiniSec-B

Implementation

The

number of packets

received in

one

epoch,

P,u,

can

be

calculated

Inaddition tothe security primitives in MiniSec-U, MiniSec-B as follows.

utilizes loose time synchronization and Bloom filters. Here, we Ecte discusspracticalissues in selectingepoch durationte and Bloom

p1

Ept1

filter

configurations.

In our calculations, we set

t1

to 12 months, Ec to 2850 mAH TimeSynchronization. As discussed inSection 6, epoch length (AA DuracellCoppertop alkaline battery3), and

Ep

to0.0441mAS

te mustbe at least

23t

+

3a.

Recentadvancement in secure sensor (receiving a TinyOS packet on CC2420 radio [18]). Average packet network time synchronization [8, 21] enables pairwise time syn- reception rate Pu

is

7.48 packets per second.

chronization with error of mere ,us. Transmission delay between Each packet adds one item intoour Bloom filter. In traditional

neighboringnodes are onthe order of ms. Even under extreme pes- networking fashion, we model packet reception as a Poisson pro-simisticconditions,epoch lengthof 1second islonger than neces- cess. Thus, the number of packets received within an epoch can saryaccordingtothe needs of MiniSec-B. For the remainder of our be approximated by a Poissondistribution with mean of

Pp.

This

analysis,wewill useepochduration te Is. model allows us to bound the maximum number of received pack-Bloom filter configurations. A pack-Bloom filter is defined by two ets in an epoch with high probability. The cumulative distribution configurations: size of the Bloom filterm, and number of hash func- function of a Poisson process is F(kk!l:) where k is number of tions h. We will show that under rather pessimisticassumptions of occurrences, A is the Poisson mean P,u, and F is the incomplete the hardware and network activity, we can achieve a

1%Y

false

(8)

Table 1: Overhead. Table comparing packet size, communication overhead, and total energy spent in transmitting one TinyOS packet. Our of allthree security protocols, MiniSec achieves the lowest communication overhead with respect to a standard TinyOS network stack.

Payload Packet Security Total Energy Increase (B) Overhead (B) Overhead (B) Size (B) (mAs) overTinyOS

TinyOS 24 12 - 36 0.034

-TinySec 24 17 5 41 0.0387 13.9%

SNEP 24 20 8 44 0.0415 22.2%

MiniSec 24 15 3 39 0.0368 8.3%

0.03

gamma function. By settingthe CDF of the Poisson distribution

to anarbitrarily high probabilityp andsolving for k, we conclude 0.025

MiniSec.DroPrate-08

thatonewouldnotreceivemorethan k

packets

inone

epoch

with

G-\

MiniSecDroPrate0.4

probability p. In our case, we set p to 0.99, and arrived at k= 14. m 0.02_ TinySec

Inother words, with probability of 0.99, we would never add more

than 14 items to our Bloom filter during anepoch. 6 0.015 Giventhis information, we can set a particular false positive rate

and solve for

appropriate configurations

forthe Bloom filter sizem = 0.01 -

-andnumber of hash functions h. Thisproblemhad been previously r - *

studiedbyAlmeida etal.'s work on SummaryCache, wherethey 0005 _ . evaluatedthe statistics behind Bloom filters

[11].

The

probability

I I ° °

of afalsepositive after inserting n elements is 2 4 6 8 10

y:Max

Decryption Attempts

Thus, wtthwos Figure3:Optimaly.Max number ofdecryptionattempts beforecounter

Thus,

with theworstcase of of n 14elements, we can achieve resynchronization. Also shows aggregate energy consumptionof all

secu-a

1%

false

positive

ratewithm=18

bytes

and h=8 hash functions.

rity

related features.

Notethat this bound is

extremely pessimistic,

asthe false

posi-tive rateshould besignificantlylower inpractice.There are several

factors: counter is reset at the beginning of each epoch, the length of the

countercanbe bounded

by

lg2

(k),

where k is the maximum

num-* False positive rate increases as morepackets are added into bers ofpackets sent in eachepoch. Next, it isunlikelyfor k to be the Bloom filter. However, our calculation is based on the large, since such resource-constrained nodes are unlikely to contin-falsepositive rate atthe end of theepoch,whichcorresponds uallybroadcastlargeamounts of data. An 8-bit counter is already tothehighest possiblefalsepositive rate. Forexample, we extremely generous since it allows for 255 packets per epoch of one statedthat we achieve a1%falsepositive rate with our Bloom second.

filterconfiguration. However, if we were inthe middle of an This 8-bit counter could be declaredas anaddition field.

How-epoch,ourcalculationactuallyshows a 0.014% false positive ever,basedontheTinyOS packetformat,weproposean

optimiza-rate. tion that overloads this counter withexisting headers. First, 3 bits

ofthis counter may be overloaded in thelengthfield. Next,the re-* We makethe pessimistic assumption that all energy is con- maining 5 bits of the counter may be embedded in the destination sumedbythe radio forpacket reception. Inpractice,energy address, since the destination field is 2 bytes and it is unlikely for is consumed for sending packets, controlling other devices a network to have more than 2048 broadcasting participants. Fur-(LEDs, sensors), and computation. thermore, unlike unicasts, the destination address is generally not * We modelthepacket reception as aPoissonprocess. How- needed for

routing

inbroadcasts.

ever, we don't usethe meanpacketarrival rate for falseposi- 8.4 Evaluation

tivecalculation.Instead,we usethe99thpercentilebased on To

analytically

evaluatethecostof

security,

weconsiderboth the the CDF of the Poisson distribution. Thus, withprobability communicationoverheadoneach

packet

aswellas

computational

of0.99, wewouldhave afalsepositive ofat most 1%. As overhead from

packet

processing.

Longer

packets

are

extremely

a matteroffact, using the same Bloom filterconfiguration,

costly

because of theextraenergy

consumption

by

the radio. Even falsepositiveratewould not exceed0.0001%withprobabil-

sending

one additional

byte

per

packet

would

require significant

ity

of0.5. amount of energy. As shown in Table 1, MiniSec was able to

de-* We assume ideal conditions forbatteries (constant current crease asecurityoverhead of 5bytes by TinySecto 3bytes.In

ad-draw, constant temperature, no self-discharge prior to de- dition, MiniSecemploys OCB, whichprovides for authentication

ployment). Inpractical settings, such ideal conditions are and secrecy with fewer block

cipher

calls than its

cryptographic

impossibletoachieve. Thus, batterycapacity and number of

counterpart

in

TinySec.

receivedpacketsaresignificantlylower. MiniSec-U. MiniSec-U was able to save on packet header size by using synchronized counters between sender and receiver. First,as Packet Format Figure 2(d) shows the packet header for MiniSec- specified above, the LB optimization has the default value of x=3.

B where the sender sends the entire counter with eachpacket. The Using the expected energy equation from Section 5.3, it is possible default counter is 8 bits long, which we claim to be sufficient in to solve for the the optimal y, or max number of decryption attempts most networks based on the following reasoning. First, since the before counter resynchronization. Consequently, given the optimal

(9)

0.014 | | | | |

|T:eous

candidate solutions,such as RandomKey Predistribution [5-7,

0.012 mi

.eU

14,

19],

Key

Infection

[2],

and LEAP

[23].

Asymmetric

schemes

.b~yS~ based onelliptic curve cryptography [15] and Diffie-Hellman [22]. .01

0.01 have also been

proposed

Secure routing is another requirement for securecommunication, such that

packets

wouldbe

successfully

routedwithnon-zero

prob-0.006 ability as long as a path of non-compromised exists between the

.0 sender and receiver.Inpractice, a sensornetwork deployer canuse

I40.004

7r

--- one ofthe following

routing

techniques,

such as INSENS [?,?],

O 0.002 ARRIVE[?],JAM[?],and Secure SensorRouting: A Clean Slate

Approach [16].

0

0.2

0.4

0.6

0.8

The body of work most closely related to MiniSec consists of

Packet Drop Rate other secure communication protocols such as TinySec [10], Zig-Bee [24], and SNEP [17]. SNEP, part ofthe SPINS protocol suite, is one ofthe first attempts at a secure link layer protocol. It achieves

Figure4: DropRate. Expected energy of securty with respect to packet low energy consumption by keeping a consistent counter between

drop rate. the sender and receiver, such that an IV is not required to be

ap-pended to each packet. However, packet loss would cause the counters to become inconsistent. Consequently, SNEP would have

y, one cansolve forthe expected energy consumedbyall security

toute

a

coue rnchroni.

.atonsprotoco

that

isulo

han

reae etrs to execute acounter

resynchronization

protocol

that iS slow and

related_{features. *} _{~~~~~~~~~~~~expensive}_{in terms of energy consumption. Inspired by SNEP,} Figure 3 illustrates our findings given different packet drop rates

MiniSecvmakestvarious improvementsmtoilowernenergy

consump-based on analysis in Section 5.3. The aggregate energy consumed

tin.

Ones

oizio

isptorede

n

the

pro

y

thatuthe

byTinySec is constant, as the energy overhead of security is al-

resnchOn

ization

ps

to

be

ted.

ways the amount of energy consumedby receiving 5 extrabytes

TinySecnisain

protocol

designedb

inthe

header,

computing

CBC-MAC, and

decrypting

the

packet.

Tiacheves

low

ener co

tono

b

resing partof

et

pac

ke

MiiecU

onteohrhn,bhvsdfeetybsdo'ni

Itachieves low

energy

consumpDtion

by

reusing

part

ofthe

packet

MiniSec-U,on the otherhand, behaves differently based on envi- header as the IV.

Thus, they

were able to arrive at an 8-byte IV, ronmental conditions. Given a packet droprate, ahigher y value butonl

addIn.

ah2-byte

ere

overheadrper

packe

HoweIVe,

exibt loe enrg cosmpin sic'trdcs h rbblt but

only adding

a

2-byte

counteroverhead per

packet.

However,

ofexhibits

e

ener

consmton,zsin

itr ces

H

eroait

more serious drawbacks of

TinySec

are that

(1)

it

only provides

ofcrunningyexhibithe int esychronimagiona

proto , in- forauthentication and datasecrecy,but notreplay protection; (2)it

creasing yehisiisi

maiabnuses

a

single

network-wide

key,

which

isvulnerable to

single

node

consumptionof counterresynchronizationbecomes less and less of compromise.

a factor in total energyconsumption.

a*factor

_in_{total energy}

consumption.

opoie

ZigBee

_{is a set of}_{security standards}_proposed_by _a_consortium MiniSec-B. Figure 4 illustrates energy consumption between Tiny- interested in promoting embedded wireless technology. The secu-Sec, MiniSec-B, and MiniSec-U using an optimalvalue y, while rity protocol is very similar to SNEP. However, the entire 8-byte varyingpacket droprate. The energy consumption of MiniSec-U counter is sent in the clear instead of being kept as consistent state is computedby first solving for the optimal y. Using this value, we between sender and receiver. Thus, ZigBee consumessignificantly wereable to calculate theexpectedenergy of security. MiniSec-B more energy than the other two protocols.

consumes a constant amount ofenergy, as its performance is not

effectedbylossiness ofthe communication channel. Byleveraging 10. CONCLUSIONS an8-bit counter and loose timesynchronization,the receiver never

needs~~~ toru aycutrrsnhoiaonptcl. Oneter Battery energy is the main resource to conserve in current

wire-needsuccessfully rcuteiresapck

at,only potwoo

.decryption lesssensornetworks. Researchers have

proposed

several

approaches

ceiver for

securing

communicationthatoptimize eitherforhigh level of

and 8 hash

Under

functionsneeds tobeperformed.

hash

funoactircustneds,t Miniecr

onu

1

security

orfor low energy utilization. Oursecure sensornetwork

U o r n n n a

acommunication

package,

MiniSec, offers a

high

level of

security

of energy of

TinySec.

As

packet drop

rateincreases

beyond

0.9,

..

We

TinySec is more efficientthan MiniSec-U because of thehighnum-

while requiring

much lessenergy than

Finally, we notethatnothingprevents theuseof MiniSec-B in [1] Handbook ofApplied Cryptography. CRC Press, 1997. unicasts. Sincethe energy consumption of MiniSec-B and MiniSec- [2] Ross Anderson, Haowen Chan, and Adrian Perrig. Key U are comparableunder normalconditions, while MiniSec-B far infection: Smarttrustforsmartdust. In

Proceedings of

IEEE

outperforms MiniSec-U under high packet loss, MiniSec-B is a International ConferenceonNetwork Protocols (ICNP much more robustprotocol. Ifloose timesynchronizationisavail- 2004), October 2004.

able, simplyrunning MiniSec-B for all communication is an attrac- [3] M. Bellare, A.

Desai,

E. Jokipii, and P. Rogaway. A concrete

solution.

tive

soluhon.des

security

_{modes of}treatment

operation.

of

symmetric encryption: Analysis

_In

Proceedings of

_FOCS

97,

_pagesof the 394-403, 1997.

9. RELATED WORK

[4] B. Bloom. Space/time trade-offs in hash coding with

_{allowable errors. In Communications of the ACM, July 1970.} Key establishment and management are considered to be pre- [5] Haowen Chan, Adrian Perrig, and DawnSong. Random key requisites in secure sensor network communication, and have been predistribution schemes for sensor networks. In IEEE extensively studied in the research community. There are numer- Symposium on Security and Privacy, May 2003.

(10)

[6] W. Du, J. Deng, Y Han, and P.Varshney. A pairwise key APPENDIX pre-distribution scheme for wireless sensor networks.In

Proceedings of the Tenth ACM Conference on Computer and

A. MINISEC-U COUNTER

CommunicationsSecurity (CCS 2003), pages 42-51,October RESYNCHRONIZATION 2003.

[7] L.Eschenauer and V. D. Gligor. A key-management scheme Reliable Unicast. If the message type is a reliable unicast, this fordistributedsensornetworks.InACMCCS,November implies there exists some type of acknowledgment protocol. Thus,

2002. the sender couldusethepresenceof ACKstodetermine ifthe

ack-[8] S.Ganeriwal, S. Capkun, C. Han, and M. B. Srivastava. P

Secure timesynchronizationservice forsensornetworks.In ets had been

received

and authenticated successfully, which implies

WiSe, 2005. whether the counter is consistent between sender and receiver.

[9] Shafi Goldwasser and Silvio Micali. Probabilistic encryption. However, MiniSec is intended to beanetworklayer protocol. Journal of Computer Security, 28:270-299, 1984. Sincereliable messaging istypically implementedat ahigher layer,

[10] Chris Karlof, Naveen Sastry, and David Wagner. TinySec: A this approach might not be appropriate. Nevertheless, we note that linklayer securityarchitecture for wireless sensor networks. if reliable messaging is used, cooperation between the transport InProceedings of the Second ACM Conference on Embedded layer and MiniSec would be a viable solution.

Networked Sensor Systems (SenSys 2004),November 2004.

[11] J.Almeida L. Fan, P. Cao and A. Broder. Summarycache: A Best Effort Unicast. Without support for reliable message deliv-scalable wide-area web cachesharing protocol.InACM ery,TinyOS packetsarebest effort. In thecaseof unicast messages, SIGCOMM98, 1998. where there only exists one receiver B, B can directly query sender [12] Yee Wei Law, Jeroen Doumen,and Pieter Hartel. Survey and A for the counter. Note that we use a nonce NB to guarantee strong

benchmark of blockciphersforwirelesssensornetworks. freshness. ACM TransactionsonSensorNetworks,2(1):65-93,

February 2006.

[13] Arjen K. Lenstraand Eric R.Verheul. Selecting B A: (NB,MACK' (NB)) cryptographic keysizes.Journalof Cryptology, A B: (CA, MACK/

(CAIINB))

14(4):255-293, 2001. Al

[14] D. Liu, P. Ning,and W. Du.Group-basedkeypre-distribution Since neither thenonceNBnorthe counterCA aresecrets,they

inwirelesssensornetworks.InWiSe,April 2005. canbesentinthe clear. However, NB needstobe authenticatedto [15] D. Malan, M.Welsh,and M.Smith. Apublic-key prevent a DOS attack, and CA needs to be authenticated to prevent infrastructure forkeydistribution in TinyOS basedonelliptic an attacker from injecting incorrect counter values. Any generic curvecryptography. In IEEESECON,October 2004. MAC function would be sufficient. Furthermore, we assume an-[16] Bryan Parno, Mark Luk, Evan Gaustad, and Adrian Perrig. other pre-existing secretK'B and there are numerous methods of

Securesensornetworkrouting: A clean-slateapproach.In p i s

Proceedings of ConferenceonFutureNetworking

bootstrapping

this

secretfromthe OCB

encryption

key.

Technologies (CoNEXT),December 2006.

[17] Adrian Perrig,Robert Szewczyk, Victor Wen, David Culler, and J. D. Tygar. SPINS:Securityprotocolsforsensor networks.InSeventh AnnualInternational Conferenceon MobileComputing and Networks(MobiCom2001), pages 189-199, Rome,Italy, July 2001.

[18] JosephPolastre, Robert Szewczyk, and David Culler. Telos:

Enablingultra-low power wirelessresearch.InIPSN/SPOTS,

2005.

[19] M. Ramjumar and N. Memon. An efficientkey

predistributionscheme for ad hoc network security.In IEEE JournalofSelected Areas inCommunications, March 2005. [20] P. Rogaway, M.Bellare,and J. Black. OCB: Ablock-cipher

mode ofoperation for efficientauthenticated encryption.In ACMTISSEC,November 2001.

[21] K. Sun, P. Ning, C. Wang, A. Liu, and YZhou.

TinySeRSync: Secure and resilient timesynchronizationin wirelesssensornetworks.InACMCCS, November 2006. [22] R. Watro, D. Kong, S.-F. Cuti, C.Gardiner,C.Lynn,and

P. Kruus.TinyPK: Securingsensornetworkswithpublic key technology. InSASN,October 2004.

[23] S.Zhu,S.Setia, and S.Jajodia.LEAP: Efficientsecurity mechanisms forlarge-scaledistributedsensornetworks.In

Proceedings ofthe Tenth ACMConferenceonComputer and CommunicationsSecurity (CCS 2003),pages62-72,October 2003.

[24] ZigBee Alliance.Zigbeespecification. Technical Report Document

053474r06,

Version 1.0, ZigBeeAlliance,June 2005.

MiniSec: A Secure Sensor Network Communication

MiniSec:

[email protected]

Categories

INTRODUCTION

Carnegie

Fcytinan

comparable

section,

M, ciphertext

tag, the

blockciher:

Communicating

OCBK(N,M,H)

TinySec

behind Minise

keeping

5.3 Energy Analysis

expectation

spent

E(I)EocB,

garbled

EEnergy

seman-tic

provide replay

6.1 Sliding-windows Approach

Un-fortunately,

(nodeID

ts, tri

epoch.

8.1 System Architecture

packet

eign group-IDs

requires

MinSec-U

plitx,I

TinyOS

packets

MiniSec.DroPrate-08

appropriate configurations

positive

routing

costly

cipher

|T:eous

routing

toute

oizio

consumpDtion

maiabnuses

wire-needsuccessfully rcuteiresapck

previous

Proceedings of

symmetric encryption: Analysis

A. MINISEC-U COUNTER

received

bootstrapping