Wireless Sensor Networks (WSNs) are prone to security attacks. In order to protect the network from potential adversaries, it is necessary to secure communications between sensor nodes. Also, if we consider a network of heterogeneous objects including WSNs, security requirements may be far more complex. In particular, a single application may deal with multiple di erent tra c ows, each one of which may have di erent 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 tra c ows at the same time according to speci ed security policies, and is totally transparent to the application, i.e. no changes to the original application or the communication protocol are required. Also, STaR can be easily recon gured at runtime, thus coping with changes of security requirements. Finally, we present our preliminary implementation of STaR for Tmote Sky motes, and evaluate its impact on performance, in terms of memory occupancy, communication overhead, and energy consumption.
In the recent years, Wireless Sensor Networks (WSNs) have received an increasing amount of attention and have been adopted in many application scenarios, from environmental to healthcare monitoring applications. In such scenarios, sensor nodes typically collect environmental data, and transmit them to a central base station through a wireless network. Sensor nodes are resource constrained devices that are deployed in unattended, possibly hostile environments.
Given the nature of WSNs, it is an easy task for an adversary to eavesdrop messages as well as alter or inject fake ones. It follows that secure communication is vital in order to assure messages con dentiality, integrity, and authenticity.
So far, deployment of WSNs have been used chie y for scienti c purposes,
where an adversary has little incentive to attack the sensors [
Now things are changing. Recently, WSNs have been employed in
Cooperating Objects Systems (COS) where mobile physical agents share the same
environment to ful ll their tasks, either in group or in isolation [
In this paper, we present STaR, a modular, recon gurable and transparent
software component for secure communications in WSNs. STaR guarantees con
dentiality, integrity, and authenticity by means of encryption and/or
authentication. STaR is modular because it separates interfaces from their implementations.
This makes STaR easily portable on di erent hardware [
By means of STaR, it is possible to protect multiple tra c ows at the same time, according to di erent security policies. STaR is recon gurable because it allows 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 also transparent, because the application can still rely on the communication interface already in use. Also, the application does not have to be redesigned or recoded in order to exploit a certain security policy. This clearly separates the implementation of the application from the STaR component. STaR characteristics allow for easily reusing application components in application scenarios where security becomes relevant. Also, STaR allows unskilled people to secure their applications, by simply selecting security policies to be applied. Besides, application developers need neither to implement complex security procedures, nor to con gure unfriendly tools, such as network rewalls.
We present our preliminary implementation of STaR [
The rest of this paper is organized as follows. In Section 2 we present some related work. Section 3 presents the STaR architecture. In Sections 4 and 5 we describe STaR interfaces providing communication and con guration services, respectively. Section 6 presents our prototype implementation of STaR for the TinyOS platform, and discusses our performance evaluation on Tmote Sky motes. In Section 7 we draw our conclusive remarks. 2
Many solutions have been devised for WSNs security, including [
In [
STaR assumes the presence of multiple tra c ows, and allows for securing them in di erent ways, according to di erent security policies. Possible security policies include packet encryption, packet authentication, or both of them.
STaR considers each application packet as belonging to one speci c tra c ow. In order to do that, each packet belonging to a tra c ow f is associated to a speci c label Lf . Also, each label refers to a speci c security policy SPf . Then, STaR processes every packet belonging to ow f according to the security policy SPf associated to label Lf . As shown in Figure 1, the STaR component stays between the application and the rest of communication stack. STaR intercepts both incoming and outgoing tra 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. Furthermore, STaR provides transparency of security with respect to the application. That is, STaR exports the same interface as that of the underlying communication stack to the application. Therefore, in order to exploit the security services provided by STaR, it is not necessary to either re-design or re-code the application.
The STaR component consists in ve sub-components, namely StarToApplication, StarToCommunication, StarLabelling, StarCon g, and StarEngine. The StarToApplication component provides the application with the same communication interface exported by the communication stack. The StarToCommunication component makes it possible to connect STaR to the underlying communication stack. The StarLabelling component classi es packets into tra c ows, and determines the associated label. The StarCon g component allows users to enable/disable security policies, and change their association to tra c ows, thus providing recon gurability at runtime. Finally, the StarEngine component actually processes packets, according to the security policy associated to the tra c ow they belong to. Figure 2 shows a packet processed by STaR, with the Label eld prepended to the packet payload. So far, the StarEngine component relies on standard security algorithms and does not consider any key management mechanism. We assume that key management is provided by an external component. In other words, STaR focuses on securing communication, assuming keys have been already deployed and are properly managed.
Note that the modularity of STaR simpli es the porting of STaR onto di erent communication stacks. Actually, a di erent communication stack requires to customize the StarToCommunication and StarToApplication components, whereas the other components remain unmodi ed.
Although the application developer is not required to change the application code and/or behavior, he/she has certain obligations in order to exploit STaR, namely i) implementation of security policieres; ii) tra c segmentation; iii) association of security policies to tra c segments; and, nally, iv) STaR initialization. We deal with these issues in the next sections. 4
As described in Section 3, STaR assumes that each packet belongs to a speci c tra c ow. That is, each packet is logically associated to a speci c label that represents a particular tra c ow.
STaR relies on packet labels in order to protect multiple tra c ows at the same time. All packets belonging to a given packet ow can be associated to a common label, and secured before transmission, according to a speci ed security policy. Conversely, incoming packets can be unsecured upon being received, according to the security policy associated to the tra c ow they belong to.
STaR is responsible for both securing/unsecuring packets and mapping ow labels into security policies. As shown in Section 3, these tasks are totally transparent to the application. In fact, the application can still rely on the original communication interface provided by the available communication stack, and does not require to be modi ed. In order to manage associations between tra 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 and can range from 0 to 255. That is, STaR is able to manage up to 256 di erent tra c ows at the same time. The PolicyID eld speci es the security policy to be adopted for a given tra c ow. PolicyID entries in the SPT refer to security policies speci ed in the PolicyDB by the speci c STaR implementation. Finally, the Active eld indicates whether the security policy associated to a given label has to be applied or not to packets belonging to such tra c ow. The Active eld is set to TRUE by default in all entries. Also, SPT s of all network nodes are supposed to be initialized in the same way at the network startup. In order to manage the SPT at runtime, STaR provides the user with a set of con guration functions, which are described in Section 5. Table 1 shows an example of SPT. Note that di erent labels can be associated to the same security policy. That is, packets belonging to di erent tra c ows can be secured in the same way.
The PolicyDB is formatted as follows. PolicyID values in the PolicyDB have
to match PolicyID entries of the SPT, in order to correctly retrieve the
security policy implementation provided by STaR. The EntryPoint eld contains a
reference to the code section which implements the policy (e.g. a C++ function
pointer). If we consider an environment which allows for dynamically loading
new security modules [
Label PolicyID Active 0 SP005 TRUE 1 SP013 TRUE 2 SP152 FALSE ... ... ... 254 SP152 TRUE 255 SP020 FALSE Table 1. Example of Security Policy Table.
PolicyID EntryPoint
SP005 errCode (*encrypt)(bu er)
... ...
SP152 errCode (*authenticate)(bu er)
Table 2. Example of PolicyDB Table. STaR provides the user with four communication functions, namely send, receive, retrieveLabel, and retrievePolicy. In the following, we describe such functions in terms of their parameters and behavior. bool send(packet, size); bool receive(packet, size); Provide packet of size size to STaR. Return TRUE in case of success. Provide packet of size size to the application. Return TRUE in case of success.
These two functions are responsible for communication between the application and the lower layers. Note that the signatures reported above change their implementation according to the adopted communication protocol. As speci ed in Section 3, the application developer has to implement both tra c segmentation into ows and the association between security policies and tra c ows.
The retrieveLabel function implements tra c segmentation whereas the operation retrievePolicy implements the association between security policies and tra c ows as follows. int retrieveLabel(packet); Return the label associated to the tra c ow which packet belongs to. Policy retrievePolicy(label);
Return the security policy associated to the label label. Firstly, access the SPT to retrieve the PolicyID associated to label label. Then, access the PolicyDB to retrieve the policy. Return an error code in case 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 tra 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 tra c ow a given packet belongs to.
Of course, a base version of retrieveLabel can behave according to a default set of criteria. For instance, it can consider all packets as belonging to a single common tra c ow, and associate them a common label value. By doing so, all packets would be protected according to the same security policy. 4.2
In the presence of STaR, the transmission of a packet P takes place according to the following steps. First, the application provides STaR with packet P , through the send function. Then, STaR retrieves the label L associated to packet P through the retrieveLabel function, and the associated security policy SP through the retrievePolicy function.
After that, 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 secured packet P to the communication stack, and delivers it to the scheduled recipient nodes.
Note that the additional label byte must never be encrypted, in order to assure that packet P is correctly unsecured at the recipient side. However, the label byte can be authenticated, in order to guarantee that it has been actually generated by the STaR component. Figure 3(a) shows how an outgoing packet is processed in the presence of STaR.
Conversely, the reception of a packet P takes place according to the following steps. STaR receives the secured packet P from the communication stack, and retrieves the label L from the additional label byte, which can then be removed.
After that, STaR retrieves the security policy SP associated to label L, through the retrievePolicy function, and unsecures packet P , according to SP . Finally, STaR provides the unsecured packet to the application, that receives it through the receive function. Figure 3(b) shows how an incoming packet is processed in the presence of STaR. 5
STaR allows users to dynamically change security settings at runtime, and provides a speci c con guration interface aimed at changing how security policies are used, as well as their association to tra c ows.
If the operating system allows for changing some program modules at runtime, it is possible to add and remove policies and tra c ows, in order to match new security requirements more e ectively. STaR provides seven con guration functions, namely enablePolicy, disablePolicy, changePolicy, addPolicy, removePolicy, addFlow, and removeFlow. In the following, we describe such functions as to their parameters and behavior. void enablePolicy(label); Set to TRUE the Active eld of the SPT entry related to label label. Then STaR starts applying such security policy to all packets belonging to the tra c ow associated to label label. void disablePolicy(label); Set to FALSE the Active eld of the SPT entry related to label label. Then STaR stops applying such security policy to all packets belonging to the tra c ow associated to label label. void changePolicy(label, newPolicy); Write newPolicy in the PolicyID eld of the SPT entry related to label label. The Active eld of the SPT entry remains unchanged.
Thanks to the STaR con guration interface, the application is allowed to change security settings at runtime. To change a security policy, a speci c control message is needed. Such a message is injected into the network as a common message, but belongs to a speci c ow used for STaR management. Messages belonging to this ow are processed by STaR in a special manner and not forwarded to the rest of communication stack, because their purpose is to change the behavior of the StarEngine component.
Also, STaR can dynamically change its behavior even in software platforms
which does not allow for dynamically loading/unloading modules, such as TinyOS
[
The following four functions can be implemented only if the operating system allows for dinamically changing the program loaded on sensor nodes. void addPolicy(PolicyID, EntryPoint);
Add the policy identi ed by PolicyID to the PolicyDB. EntryPoint speci es the code section to be executed to apply the speci ed policy. void removePolicy(PolicyID); void addFlow(label);
Remove the policy identi ed by PolicyID from the PolicyDB.
Add a ow with ID label to the SPT. Firstly, verify it is not a copy of another ow, then set the PolicyID eld to UNDEFINED and the Active eld to FALSE. These elds will be set by a policy association. void removeFlow(label);
Remove the ow identi ed by label from the SPT. 6
We implemented the STaR component [
In order 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 demo applications provided with TinyOS. { 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 application (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 Skipjack submodule of the StarEngine module. { A^ = S + C + A is the image size in bytes of the original TinyOS stack and the RadioCountToLeds application (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.
Memory Memory occupancy (B) occupancy (%)
Table 3 provides more detailed information on memory occupancy. As explained above, we considered the original TinyOS stack together with the RadioCountToLeds application, each STaR module separately, and the amount of memory still available. If we sum the contributions of the StarCon g, Skipjack and SHA-1 modules, we observe that 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:86% of the available memory, we have the 57:98% of 48 kB still available for other uses. We believe that the amount of memory required by STaR is reasonable with respect to the available memory. Also, STaR modular implementation allows for saving memory by loading only a few of the available modules, provided that the speci c software platform makes it possible, and it is well known what modules are needed. 6.2
In our analysis, we assumed that STaR is operating on top of the 2.4 GHz
physical layer, with a 250 Kb/s bit rate [
We evaluated the security processing overhead by means of experiments, while the extra transmission overhead has been computed analytically, considering the bit rate and the packet size. Also, energy consumption has been evaluated analytically, considering single energy contributions.
Figure 5 shows the sequence of events which take place when we transmit a secured packet with STaR, according to the TinyOS Send/SendDone schema. The time interval named STaR processing overhead is the extra time required to process the packet according to the chosen security policy. This time has been evaluated experimentally.
Policy dproc ( s) deSvitaatniodnar(d s) NONE 142 0 ENC 1239.70 1.96
HASH 32853.50 2.53 ENC + AUTH 33948.65 3.01
In our experiments, we observed one sender device at a time transmitting secured packets whose payload is 8 bytes in size. In order to increase the accuracy of our results, we performed 10 repetitions of 20 transmissions for each experiment. The results shown in Table 4 are averaged over all the di erent repetitions. We also report the standard deviation we derived from the independent replication method.
The rst line shows the delay associated to the NONE policy, i.e. packets just cross the STaR component, which adds the label corresponding to neither encryption nor authetication. In this case we have a constant delay because STaR always performs the same simple sequence of operations.
The second line shows the delay associated to the ENC policy. In this case packets are labelled in order to be encrypted. Then, the label is recognized by the StarEngine module, which encrypts packets using Skipjack. We notice a considerable increase in the delay due to the block encryption operations. If we consider Cipher-block chaining (CBC ) Skipjack, we can use this algorithm also for authentication.
The third line shows the delay associated to the HASH policy. In this case, packets are labelled in order to be hashed. Then, the label is recognized by the StarEngine module, which applies SHA-1 on packets.
Finally, the fourth line shows the delay associated to the ENC + AUTH policy. In this case, packets are labelled in order to be encrypted by Skipjack as well as authenticated by means of SHA-1 hashing. This delay should be close to dENC + dHASH dNONE because it combines the behaviors of the encryption policy and the hashing policy. We subtract the delay due to labelling (dNONE), because we consider it twice when summing dENC and dHASH, but it is actually performed just once.
If we consider values in Table 4 we have dENC + dHASH dNONE = 33951:2 s with a standard deviation of 3:20 s. Thus, we think the reported delay is coherent, and the error acceptable. Note that considerable delays are due to the standard encryption and authentication algorithms, while the actual STaR contribution to the processing delay is just 142 s. This is the additional time required to add the label eld to packets, thus assuring that each one of them is correctly processed according to the associated security policy. We believe that this delay is negligible if compared to the ones introduced by standard cryptographic computations, such as those performed by Skipjack and SHA-1.
The transmission overhead has been evaluated analytically, with a bit rate
equal to 250 Kb/s [
Policy NONE ENC
HASH
ENC + AUTH
voltage and current of the MSP430 microcontroller and the CC2420 chipset,
which are responsible for processing and transmission, respectively [
This work has been supported by the EU FP7 Network of Excellence CONET (Grant Agreement no. FP7-224053); the EU FP7 Integrated Project PLANET (Grant agreement no. FP7-257649); the TENACE PRIN (n. 20103P34XC) funded by the Italian Ministry of Education, University and Research; and the Regione Toscana POR CReO 2007 - 2013, LINEA DI INTERVENTO 1.5.a - 1.6, BANDO UNICO R&S ANNO 2012, Piattaforma Integrata per la Gestione delle Operazioni Aeroportuali - PITAGORA. We would also like to thank Davide Di Baccio for his help during the implementation phase of our work.