STaR: Security Transparency and Reconﬁgurability

for Wireless Sensor Networks Programming

Roberta Daidone, Gianluca Dini and Marco Tiloca

Dipartimento di Ingegneria dell’Informazione, University of Pisa, Pisa, Italy

Keywords:

Security, Wireless Sensor Networks.

Abstract:

Wireless Sensor Networks (WSNs) are prone to security attacks. To protect the network from potential adver-

saries, it is necessary to secure communications between sensor nodes. If we consider a network of hetero-

geneous objects including WSNs, security requirements may be far more complex. A single application may

deal with different trafﬁc ﬂows, each one of which may have different security requirements, that possibly

change over time. In this paper, we present STaR, a software component which provides security transparency

and reconﬁgurability for WSNs programming. STaR allows for securing multiple trafﬁc ﬂows at the same time

according to speciﬁed security policies, and is transparent to the application, i.e. no changes to the original

application or the communication protocol are required. STaR can be easily reconﬁgured at runtime, thus

coping with changes of security requirements. Finally, we present our implementation of STaR for Tmote Sky

motes, and evaluate it in terms of memory occupancy, communication overhead, and energy consumption.

1 INTRODUCTION

In the recent years, Wireless Sensor Networks

(WSNs) have received an increasing amount of at-

tention and have been adopted in many application

scenarios, from environmental to healthcare monitor-

ing applications. In such scenarios, sensor nodes col-

lect environmental data, and transmit them to a central

base station through a wireless network. Sensor nodes

are typically resource constrained devices deployed in

unattended, possibly hostile environments. Given the

nature of WSNs, it is an easy task for an adversary to

eavesdrop messages and alter or inject fake ones. It

follows that secure communication is vital to assure

messages conﬁdentiality, integrity, and authenticity.

WSNs have been used chieﬂy for scientiﬁc pur-

poses, where an adversary has little incentive to at-

tack sensors (Cardenas, A.A., Roosta, T., and Sastry,

S., 2009). Now WSNs are employed also in Coop-

erating Objects Systems (COS) where mobile physi-

cal agents share the same environment to fulﬁll their

tasks, either in group or in isolation (CONET, 2008;

PLANET, 2010). Such agents not only sense the envi-

ronment, but also act on it. COS are a tempting target

for an adversary, since a security infringement may

easily translate into a safety one, with possible conse-

quences in terms of damages to things and injures to

people. Same considerations hold for WSNs in Crit-

ical Infrastructures (Albano, M., Chessa, S., and Di

Pietro, R., 2008; Buttyan, L., Gessner, D., Hessler,

A., and Langendoerfer, P., 2010).

Many solutions have been devised for WSNs se-

curity, including (Karlof, C., Sastry, N., and Wagner,

D., 2004) for secure communication, (Wong, C.K.,

Gouda, M., and Lam, S.S., 2000; Su, Z., Lin, C.,

Ren, F., Jiang, Y., and Chu, X., 2009; Gu, W., Dutta,

N., Chellappan, S., and Xiaole, B., 2011; Maerien,

J., Michiels, S., Huygens, C., and Joosen, W., 2010;

Dini, G., and Tiloca, M., 2010) for key management,

and (Hyun, S., Ning, P., Liu, A., and Du, W., 2008;

Lanigan, P.E., and Gandhi, R., and Narasimhan, P.,

2006) for secure code dissemination. Particular atten-

tion has been paid to component-based security archi-

tectures tailored to WSNs (Matthys, N., Huygens, C.,

Hughes, D., Michiels, S., and Joosen, W., 2012; Dini,

G., and Savino, I.M., 2010).

We present STaR, a modular, reconﬁgurable and

transparent software component for secure commu-

nications in WSNs. STaR guarantees conﬁdential-

ity, integrity, and authenticity by means of encryption

and/or authentication.

STaR is modular because it separates interfaces

from their implementations. This makes it easily

portable on different hardware (Moteiv Corporation,

2006; Crossbow Technology Inc., 2004) and network

stacks (IEEE, 2006; ZigBee Alliance, 2008). Modu-

Daidone R., Dini G. and Tiloca M..

STaR: Security Transparency and Reconﬁgurability for Wireless Sensor Networks Programming.

DOI: 10.5220/0004205200350040

In Proceedings of the 2nd International Conference on Sensor Networks (SENSORNETS-2013), pages 35-40

ISBN: 978-989-8565-45-7

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

larity allows for loading/unloading STaR modules to

match security requirements, add new features, or ex-

tend existing ones.

STaR allows for protecting multiple trafﬁc ﬂows at

the same time, according to different security policies.

STaR is reconﬁgurable because it makes it possi-

ble to change security policies on a per packet basis at

runtime. That is, it assures a ﬁne grained adaptability

to possible changes in security requirements.

STaR is transparent, because the application can

still rely on the communication interface already in

use. The application does not require to be redesigned

or recoded in order to exploit a certain security pol-

icy. This clearly separates the implementation of the

application from the STaR component. STaR char-

acteristics allows for reusing application components

in scenarios where security becomes relevant. Also,

STaR allows unskilled people to secure their applica-

tions, by simply selecting security policies to be ap-

plied. Besides, application developers need neither to

implement complex security procedures, nor to con-

ﬁgure unfriendly tools, such as network ﬁrewalls.

We evaluated our STaR implementation (Daidone,

R., Dini, G., and Tiloca, M., 2012) for TinyOS

(TinyOS Working Group, 2012) on Tmote Sky motes

(Moteiv Corporation, 2006), showing it is affordable

as to memory occupancy, communication overhead,

and energy consumption. STaR features a generic ar-

chitecture, and can be implemented for other hard-

ware platforms and WSNs operating systems.

The rest of this paper is organized as follows. Sec-

tion 2 presents the STaR architecture. Sections 3

describes STaR interfaces providing communication

and conﬁguration services. In Section 4 we discuss

the performance of our implementation of STaR. In

Section 5 we draw our conclusive remarks.

2 STaR ARCHITECTURE

STaR allows for securing multiple trafﬁc ﬂows ac-

cording to different security policies. Possible secu-

rity policies include packet encryption, packet authen-

tication, or both of them. The choice of appropriate

security policies is related to the speciﬁc application

and threat model, and is out of the scope of this paper.

As shown in Figure 1, the STaR component stays

between the application and the communication stack.

STaR intercepts both incoming and outgoing trafﬁc,

segments it into ﬂows, and secures them according

to the corresponding security policies. STaR assures

reconﬁgurability by allowing users to dynamically

change security policies, provides transparency of se-

curity with respect to the application, and exports the

Figure 1: STaR component overview.

Figure 2: Example of packet processed by STaR.

same interface as that of the underlying communica-

tion stack to the application.

The StarToApplication component provides the

application with the same communication interface

exported by the communication stack. The StarTo-

Communication component connects STaR to the un-

derlying communication stack. The StarLabelling

component classiﬁes packets into trafﬁc ﬂows, and de-

termines the associated label. The StarConﬁg compo-

nent allows users to enable/disable security policies,

and change their association to trafﬁc ﬂows, providing

reconﬁgurability at runtime. The StarEngine compo-

nent actually processes packets, according to the se-

curity policy associated to the trafﬁc ﬂow they belong

to. Distribution and revocation of necessary security

material are left to other system components, which

are not part of STaR and are out of the scope of this

paper. Figure 2 shows a packet processed by STaR,

with the Label ﬁeld prepended to the packet payload.

STaR modularity eases the porting of STaR onto

different communication stacks. Actually, a differ-

ent communication stack requires to customize the

StarToCommunication and StarToApplication com-

ponents, while other components remain unmodiﬁed.

Although the application developer is not required

to change the application code and/or behavior, she

has certain obligations in order to exploit STaR,

namely i) implementation of security policies; ii) traf-

ﬁc segmentation; iii) association of security policies

to trafﬁc segments; and, iv) STaR initialization.

3 SECURE SECURITY SERVICES

As described in Section 2, STaR relies on packet la-

bels to protect multiple trafﬁc ﬂows at the same time.

All packets belonging to a given packet ﬂow can be

associated to a common label, and secured before be-

ing transmitted, according to a speciﬁed security pol-

icy. Incoming packets can be unsecured upon being

SENSORNETS2013-2ndInternationalConferenceonSensorNetworks

received, according to the security policy associated

to the trafﬁc ﬂow they belong to.

STaR is responsible for securing/unsecuring pack-

ets and mapping ﬂow labels into security policies.

These tasks are totally transparent to the application.

The application can still rely on the original commu-

nication interface provided by the available commu-

nication stack, and does not require to be modiﬁed.

In order to manage associations between trafﬁc ﬂows

and security policies, STaR maintains two tables: i) a

Security Policy Table (SPT), and ii) a PolicyDB.

The SPT is formatted as follows. The Label ﬁeld

is one byte in size. Thus, STaR manages up to 256

different trafﬁc ﬂows at the same time. The PolicyID

ﬁeld speciﬁes the security policy to be adopted for a

given trafﬁc ﬂow. PolicyID entries in the SPT refer

to security policies speciﬁed in the PolicyDB by the

speciﬁc STaR implementation. The Active ﬁeld indi-

cates whether the security policy associated to a given

label has to be applied or not to packets belonging to

such trafﬁc ﬂow. The Active ﬁeld is set to TRUE by

default in all entries. SPTs of all network nodes are

supposed to be initialized in the same way at the net-

work startup. In order to manage the SPT at runtime,

STaR provides a set of conﬁguration functions, which

are described in Section 3.2.

The PolicyDB is formatted as follows. PolicyID

values in the PolicyDB have to match PolicyID entries

of the SPT to correctly retrieve the security policy im-

plementation provided by STaR. The EntryPoint ﬁeld

contains a reference to the code section which imple-

ments the policy (e.g. a C++ function pointer).

3.1 STaR Communication Support

The following communication functions are provided.

bool send(packet, size);

Provide the packet packet of size size to STaR. Return

TRUE in case of success, FALSE otherwise.

bool receive(packet, size);

Provide the application with the packet packet of size

size coming from STaR. Return TRUE in case of suc-

cess, FALSE otherwise.

int retrieveLabel(packet);

Return the label associated to the trafﬁc ﬂow which

the packet packet belongs to.

Policy retrievePolicy(label);

Return the security policy associated to label. Return

an error code if the Active ﬁeld in the SPT is set to

FALSE, or the policy is not present in the PolicyDB.

The application developer must determine the best

security policy to protect each trafﬁc ﬂow, and bind

each one of them to a speciﬁc label value. Speciﬁ-

cally, the retrieveLabel function must implement the

criteria according to which it is possible to infer which

trafﬁc ﬂow a given packet belongs to.

Packet P is transmitted according to the follow-

ing steps. The application provides STaR with packet

P, through the send function. Then, STaR retrieves

the label L associated to packet P through the re-

trieveLabel function, and the associated security pol-

icy SP through the retrievePolicy function. Then,

STaR builds a one byte ﬁeld, ﬁlls it with the label

L, and inserts it between the header and the payload

of packet P. Then, packet P is secured, according to

the security policy SP. Finally, STaR provides the se-

cured packet P to the communication stack, to deliver

it to the recipient node(s). The label must never be

encrypted, in order to assure that packet P is correctly

unsecured at the recipient side. However, the label

can be authenticated, in order to guarantee that it has

been actually generated by the STaR component. Fig-

ure 3 shows an outgoing packet processed by STaR.

Figure 3: Outgoing packet processing.

Packet P is received according to the following

steps. STaR receives the secured packet P from the

communication stack, and retrieves the label L from

the additional label, which can then be removed.

Then, STaR retrieves the security policy SP associ-

ated to label L, through the retrievePolicy function,

and unsecures packet P, according to SP. Finally,

STaR provides the unsecured packet to the applica-

tion, that receives it through the receive function. Fig-

ure 4 shows an incoming packet processed by STaR.

3.2 STaR Conﬁguration Services

STaR allows users to change security settings at run-

time, and provides a speciﬁc conﬁguration interface

aimed at changing how security policies are used, and

their association to trafﬁc ﬂows. In the following, we

describe the conﬁguration functions.

void enablePolicy(label);

STaR:SecurityTransparencyandReconfigurabilityforWirelessSensorNetworksProgramming

Figure 4: Incoming packet processing.

Set to TRUE the Active ﬁeld of the label SPT entry.

void disablePolicy(label);

Set to FALSE the Active ﬁeld of the label SPT entry.

void changePolicy(label, newPolicy);

Write newPolicy in the PolicyID ﬁeld of the SPT entry

related to label. The Active ﬁeld remains unchanged.

4 STaR TinyOS Implementation

We implemented the STaR component (Daidone, R.,

Dini, G., and Tiloca, M., 2012) for TinyOS 2.1.1,

which is available at (TinyOS Working Group, 2012).

We implemented the described security features with

reference to the Tmote Sky motes (Moteiv Corpora-

tion, 2006) and the CC2420 chipset (Texas Instru-

ments, 2012). We have implemented the Skipjack

encryption module (U.S. National Security Agency

(NSA), 1998) and the SHA-1 module for integrity

hashing (Eastlake, D., and Jones, P., 2001), and are

working to provide more standard security protocols.

4.1 STaR Memory Footprint

ROM memory available on Tmote Sky motes is 48

kB, and may be a severe constraint while dealing with

complex modules like those composing STaR. In or-

der to evaluate memory consumption on Tmote Sky

motes, we considered the TinyOS image size wiring

the STaR submodules separately.

S is the image size in bytes of the original TinyOS

stack and the RadioCountToLeds application, which

is one of the provided demo applications.

C = S + C is the image size in bytes of the original

TinyOS stack and the RadioCountToLeds application

(S), wired to the StarConﬁg module (C). C =

C − S is

the memory occupancy of the StarConﬁg module.

E = S + C + E is the image size in bytes of the

original TinyOS stack and the RadioCountToLeds ap-

plication (S), wired to the StarConﬁg module (C) and

the Skipjack submodule of the StarEngine module

(E). E =

E −

C is the memory occupancy of the Skip-

jack submodule of the StarEngine module.

A = S + C + A is the image size in bytes of the

original TinyOS stack and the RadioCountToLeds ap-

plication (S), wired to the StarConﬁg module (C) and

the SHA-1 submodule of the StarEngine module (A).

A =

A −

C is the memory occupancy of the SHA-1

submodule of the StarEngine module.

Table 1: Detailed memory occupancy.

Memory Memory

occupancy (B) occupancy (%)

Application and TinyOS stack 13372 27.86

StarConﬁg 854 1.78

StarEngine (Skipjack) 2046 4.26

StarEngine (SHA-1) 3900 8.12

Available memory 27828 57.98

Table 1 provides information on memory occu-

pancy, and shows the percentages of Tmote Sky

ROM occupied by the original application and

STaR (sub)modules. If we sum the contributions of

the StarConﬁg, Skipjack and SHA-1 modules, we ob-

serve our STaR implementation totally requires the

14.16% of the overall memory available on a Tmote

Sky mote. Since the application together with the

TinyOS stack requires the 27.85% of the available

memory, we have the 57.99% of 48 kB available for

other uses. Thus, memory required by STaR is rea-

sonable with respect to the available memory.

4.2 STaR Performance Evaluation

In our analysis, we assumed STaR operates on top of

the 2.4 GHz physical layer, with a 250 Kb/s bit rate

(Texas Instruments, 2012). We modeled the impact

of security considering i) network performance degra-

dation due to security processing and extra trasmis-

sions overhead, and ii) the extra energy consumption,

due to extra processing and transmissions. We evalu-

ated the security processing overhead by means of ex-

periments. The extra transmission overhead has been

computed considering the bit rate and the packet size.

Energy consumption has been evaluated analytically.

Figure 5: Send and Secure events nesting.

Figure 5 shows events which take place when we

transmit a secured packet with STaR, according to the

TinyOS Send/SendDone schema. The STaR process-

SENSORNETS2013-2ndInternationalConferenceonSensorNetworks

Table 2: STaR d

proc

contributions overview.

Policy d

proc

(µs) Standard deviation (µs)

NONE 142 0

ENC 1239.70 1.96

HASH 32853.50 2.53

ENC + AUTH 33948.65 3.01

ing overhead time interval is the extra time required

to process the packet according to the chosen security

policy. This time has been evaluated experimentally.

In our experiments, we observed one sender de-

vice at a time transmitting secured packets whose pay-

load is 8 bytes in size. In order to increase the accu-

racy of our results, we performed 10 repetitions of 20

transmissions for each experiment. Results shown in

Table 2 are averaged over all the different repetitions.

We also report the standard deviation we derived from

the independent replication method.

Considerable delays are due to the standard en-

cryption and authentication algorithms, while the ac-

tual STaR contribution to the processing delay is just

142 µs. This is the additional delay required to add the

label ﬁeld, which is negligible if compared to the one

introduced by standard cryptographic computations,

such as those performed by Skipjack and SHA-1.

The transmission overhead has been evaluated an-

alytically, considering a 250 Kb/s bit rate (Texas In-

struments, 2012). Speciﬁcally, we have considered

the time required to transmit the additional bytes

added by STaR, according to the speciﬁc security pol-

icy. The original application packet size, including

the header and the Cyclic Redundancy Check (CRC)

is 21 bytes. The time d

required to transmit the orig-

inal application packet is the ratio between the packet

size in bits and the bit-rate: d

21·8

0.250

= 672 µs.

Table 3: STaR d

contributions overview.

Policy d

(µs) Increase (%)

NONE 32 4.76

ENC 32 4.76

HASH 672 100

ENC + AUTH 672 100

Table 3 provides an overview of the transmis-

sion overhead, considering different security policies.

Considerable delays of the HASH and ENC + AUTH

policies are due to the standard SHA-1 hashing out-

put size, which is 20 bytes long. In fact, the actual

STaR contribution to the transmission delay is just

32 µs, that is the time required to transmit the one byte

label ﬁeld added to the original packet. We believe

that this delay is affordable, since it is due to the in-

crease of just one byte of the original packet size.

We expressed energy consumption contributions

as E

= P

× d

. Let d

be the delay due to the consid-

Table 4: STaR energy consumption contributions.

Policy

Processing Transmission

proc

= 1.08mW P

= 31.32mW

proc

(µs) (mJ) (µs) (mJ)

NONE 142 153.4 32 1002.2

ENC 1239.7 1338.9 32 1002.2

HASH 32853.5 35481.8 672 21047.0

ENC + AUTH 33948.7 36664.6 672 21047.0

ered operation i. P

= V

× I

is the single power con-

tribution, i.e. the product between voltage and current

of the MSP430 and CC2420 components.

Table 4 provides an overview of such contribu-

tions. Considerable increases in per packet energy

consumption are due to the standard encryption and

authentication algorithms, while the actual STaR con-

tribution to energy consumption is the one reported

in the NONE policy entry: E

proc

+ E

= 1155.6 mW

that is the energy consumed to add the label ﬁeld to

the original packet and transmit it. The extra energy

consumption is affordable, if compared to contribu-

tions due to standard security mechanisms as SHA-1.

5 CONCLUSIONS

We have presented STaR, our security software com-

ponent for WSNs. It protects multiple trafﬁc ﬂows at

the same time, according to different security policies.

STaR is transparent to the application, which can rely

on the same communication interface already in use.

STaR allows users to change security policies and

their association to trafﬁc ﬂows at runtime. Finally,

we have considered our preliminary implementation

of STaR for Tmote Sky motes, and provided a per-

formance evaluation in terms of memory occupancy,

communication overhead, and energy consumption.

Our results show that STaR is efﬁcient as well as af-

fordable even in the considered resource scarce hard-

ware platform. In fact, the heaviest impact on perfor-

mance is due to the adopted standard security algo-

rithms, and not to the presence of STaR. Future works

will extend STaR interfaces, add services such as key

management, and compare STaR implementations on

different architectures.

ACKNOWLEDGEMENTS

This work has been supported by EU FP7 Network

of Excellence CONET (Grant Agreement no. FP7-

224053) and EU FP7 Integrated Project PLANET

STaR:SecurityTransparencyandReconfigurabilityforWirelessSensorNetworksProgramming

(Grant agreement no. FP7-257649). We also thank

Davide Di Baccio for his precious help.

REFERENCES

Albano, M., Chessa, S., and Di Pietro, R. (2008). Informa-

tion Assurance in Critical Infrastructures via Wireless

Sensor Networks. In Proceedings of the Fourth In-

ternational Conference on Information Assurance and

Security, pages 305–310.

Buttyan, L., Gessner, D., Hessler, A., and Langendoer-

fer, P. (2010). Application of wireless sensor net-

works in critical infrastructure protection: challenges

and design options. IEEE Wireless Communications,

17(5):44–49.

Cardenas, A.A., Roosta, T., and Sastry, S. (2009). Rethink-

ing security properties, threat models, and the design

space in sensor networks: a case study in SCADA sys-

tems. Ad Hoc Networks, 7(8):1434–1447.

CONET (2008). Cooperating Objects NETwork of

excellence, European Commission, 7th Frame-

work Programme, Grant Agreement n. 224053.

http://www.cooperating-objects.eu/.

Crossbow Technology Inc. (2004). MPR/MIB User’s Man-

ual.

Daidone, R., Dini, G., and Tiloca, M. (2012). STaR imple-

mentation source code. http://www.iet.unipi.it/g.dini/

download/code/star.zip.

Dini, G., and Savino, I.M. (2010). A Security Architec-

ture for Reconﬁgurable Networked Embedded Sys-

tems. International Journal of Wireless Information

Networks, 17:11–25.

Dini, G., and Tiloca, M. (2010). Considerations on Secu-

rity in ZigBee Networks. In Proceedings of the IEEE

International Conference on Sensor Networks, Ubiq-

uitous, and Trustworthy Computing, pages 58–65.

Eastlake, D., and Jones, P. (2001). RFC 3174.

http://tools.ietf.org/html/rfc3174.

Gu, W., Dutta, N., Chellappan, S., and Xiaole, B. (2011).

Providing End-to-End Secure Communications in

Wireless Sensor Networks. IEEE Transactions on

Network and Service Management, 8(3):205–218.

Hyun, S., Ning, P., Liu, A., and Du, W. (2008). Seluge: Se-

cure and DoS-Resistant Code Dissemination in Wire-

less Sensor Networks. In Proceedings of the 2008 In-

ternational Conference on Information Processing in

Sensor Networks, pages 445–456.

IEEE (2006). IEEE Std. 802.15.4-2006. IEEE, Inc., New

York.

Karlof, C., Sastry, N., and Wagner, D. (2004). TinySec: a

link layer security architecture for wireless sensor net-

works. In Proceedings of the 2nd international confer-

ence on Embedded Networked Sensor Systems, pages

162–175.

Lanigan, P.E., and Gandhi, R., and Narasimhan, P. (2006).

Sluice: Secure Dissemination of Code Updates in

Sensor Networks. In Proceedings of the 26th IEEE

International Conference on Distributed Computing

Systems, pages 53–62.

Maerien, J., Michiels, S., Huygens, C., and Joosen, W.

(2010). MASY: MAnagement of Secret keYs for

federated mobile wireless sensor networks. In Pro-

ceedings of the 6th IEEE International Conference

on Wireless and Mobile Computing, Networking and

Communications, pages 121–128.

Matthys, N., Huygens, C., Hughes, D., Michiels, S., and

Joosen, W. (2012). A Component and Policy-Based

Approach for Efﬁcient Sensor Network Reconﬁgura-

tion. In Proceedings of the 2012 IEEE International

Symposium on Policies for Distributed Systems and

Networks, pages 53–60.

Moteiv Corporation (2006). Tmote iv Low Power Wireless

Sensor Module.

PLANET (2010). PLAtform for the deployment and

operation of heterogeneous NETworked cooperat-

ing objects, European Commission, 7th Frame-

work Programme, Grant Agreement n. 257649.

http://www.planet-ict.eu/.

Su, Z., Lin, C., Ren, F., Jiang, Y., and Chu, X. (2009). An

Efﬁcient Scheme for Secure Communication in Large-

Scale Wireless Sensor Networks. In Proceedings of

the 2009 WRI International Conference on Communi-

cations and Mobile Computing, volume 3, pages 333–

337.

Texas Instruments (2012). CC2420 2.4 GHz IEEE 802.15.4

/ ZigBee ready RF Transceiver. http://focus.ti.com/lit/

ds/symlink/cc2420.pdf.

TinyOS Working Group (2012). TinyOS Home Page.

http://www.tinyos.net/.

U.S. National Security Agency (NSA) (1998). SKIPJACK

and KEA algorithm speciﬁcations.

Wong, C.K., Gouda, M., and Lam, S.S. (2000). Secure

group communications using key graphs. IEEE/ACM

Transactions on Networking, 8(1):16–30.

ZigBee Alliance (2008). ZigBee Speciﬁcation.

SENSORNETS2013-2ndInternationalConferenceonSensorNetworks