Learning Center
Plans & pricing Sign in
Sign Out

Design and Implementation of Flexible Framework for Secure Wireless Sensor Network Applications


									                                                             (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                       Vol. 8, No.3, 2010

   Design and Implementation of Flexible Framework
   for Secure Wireless Sensor Network Applications

                      Inakota Trilok                                                           Mahesh U.Patil
     Department of Computer Science & Engineering                             National Ubiquitous Computing Research Centre
            National Institute of Technology                                  Centre for Development of Advanced Computing
                    Warangal, India                                                          Hyderabad, India

Abstract—Secure communications is an interesting and                      leads to higher consumption of energy. In such cases, high-
challenging research area in Wireless Sensor Networks (WSN)               energy and rechargeable batteries are used. There are some
fundamentally because of the low power constraints and small              contradictions between the communication energy cost and
memory footprints inherent in the technology. In this context,            cryptographic cost for WSN (See [1, 2]). So, the security
there are many hardware platforms like TelosB, MicaZ and                  technique needed depends on the application that is to be
Mote2 which implement a security layer in hardware, supporting            deployed into the network. Thus, there needs to be a balance
multiple modes of operation like encryption, integrity or                 between the amount of security that can be provided to these
combinations of both. However, not all hardware platforms                 networks and resources on the mote. This is different from
support hardware security which creates avenues of research in            conventional security solutions, since in WSN the security is
designing low power security algorithms in software. As with the
                                                                          tightly coupled to the application’s need.
development of security algorithms for WSN applications, there
is an urgent requirement to create a unified approach for                      TinyOS [22] is a free and open source embedded operating
application developers by which they can integrate and use                system which is specifically designed for wireless sensor
existing security algorithms thereby maintaining an abstraction           network application development. It follows a component
from the intricacies of the algorithm.                                    based architecture which enables application developers to
                                                                          integrate their application requirements with existing network
    This paper introduces a flexible framework which                       communication protocols. The application and operating
implements a unified API to add new security algorithms to a
                                                                          system is bundled into a final image which is burnt onto the
security library suite. This library integrates existing security
algorithms like TinySec, MiniSec etc. We also bring out the
                                                                          hardware thereby creating two tier architecture. Application
implementation of Advanced Encryption Standard (AES) in                   developers should wire a customized network stack for which
software supporting its various modes of operation. We have               knowledge of low level details of each of the algorithms is
integrated this implementation with the unified framework and              required. These algorithms could spawn diverse areas like
demonstrated its performance and our results. We compare our              network communication, dissemination, time synchronization,
software AES implementation with the Hardware AES                         and security, etc. Moreover, to modify the stack inorder to test
implementation, in all the supported mode settings.                       performance, knowledge of the interfaces provided by alternate
                                                                          algorithms also have to be understood. This requirement
    Keywords-Wireless Sensor Networks; Mote; Link Layer                   imposes an additional burden on the developer.
Security; Network Layer Security; Hardware Level Security,
Integrity; Encryption; Authentication.                                        There are number of security algorithms available in
                                                                          TinyOS communication protocol stack. Some of them like
                                                                          TinySec [3], SenSec [4] and CC2420/CC2430/CC2431 Radio
                      I.    INTRODUCTION                                  AES [5] operate at the link layer, while other algorithms like
    Wireless Sensor Networks (WSN) is a collection of                     MiniSec [6] exist at the network layer. As is seen above there is
distributed autonomous systems called sensor nodes that                   wide diversity in the implementation and detail of the
monitor and collect physical data for assessment and                      algorithms. This renders migration from one security algorithm
evaluation. These sensor nodes are very small in size, and are            to another a point of bother for the application developer. A
limited in resources like CPU, memory and network                         uniform access method for all security algorithms is desirable.
bandwidth. Moreover they are powered through small batteries.             The main contributions of this paper are:
All these make wireless sensor networks vulnerable to security
attacks and this is a crucial aspect of the sensor network. Much                  Introduction to an adaptive framework for WSN
of security is application specific and in applications like                       applications.
physical intrusion detection or perimeter protection these are of                 A general purpose security library suite composed of
utmost importance. As sensor nodes are powered through                            existing security algorithms for popular sensor node
batteries, security techniques must ideally consume less energy.                  hardware platforms.
Ironically, some sensor networks need high security which

                                                                                                     ISSN 1947-5500
                                                           (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                     Vol. 8, No.3, 2010
       An application developer’s perspective in creating a             CBC-MAC Authentication: This mode provides only
       custom network stacks specific to his application                 authentication of the payload [7].
                                                                        CCM Mode: This is Counter mode encryption and CBC-MAC
       Support for existing versions of TinyOS providing the            authentication mode that features authenticated encryption
       application developer an abstraction to low level                [20].
       implementation of the desired security algorithm                 OCB Mode: This Offset CodeBook, is a block-cipher mode of
       chosen. The application developer is provided with a             operation that features authenticated encryption for arbitrary
       common API’s for setting modes and updating keys for             length of data [7].
       all available security algorithms.
                                                                        Only-Encryption/Only-Decryption: In this mode, simple
       Implementation and integration of software AES and               encryption/decryption operations are performed without any
       hardware AES with same mode settings like encryption             mode settings.
       only, CBC-MAC integrity-only, counter encryption
       only and counter encryption - CBC-MAC integrity
       with dynamic and static key support.                                  III.   THE ADAPTIVE FRAMEWORK FOR SECURE WSN
                                                                                    APPLICATIONS AND IT’S DESIGN GOALS
   The paper is outlined as follows. Section 2 presents the
   background of various security protocols at different levels             We propose a flexible framework for programming
   and their limitations, Section 3 formulates the                      TinyOS. This framework is divided into multiple components
   implementation of flexible framework and its design goals,            as shown in Figure 1 and each component contains group of
                                                                        protocols: routing protocols, Time-synchronization protocols,
   and introduces software AES and various modes of
   operation used by us and Section 4 describes the results and         localization and security protocols. The application developer
                                                                        is required to wire a combination of these protocols for specific
   analysis of framework with software AES. Finally Section
   5 concludes with a peek into the future work.                        application using the framework. For example, an application
                                                                        can use TinyHop routing algorithm, Flooding Time
                                                                        Synchronization Protocol (FTSP) [9] with Hardware or
                     II.   BACKGROUND                                   Software security. In such a case this framework can be
                                                                        configured depending on the application’s need and the level of
A. Existing security protocols:                                         security required. So, we grouped these protocols into multiple
     TinySec [3] which is implemented at Link layer ensures             components by providing abstraction to the application
low energy consumption but the algorithm is vulnerable to               developer for easier access.
replay attacks. MiniSec [6] at Network layer ensures low
energy consumption but operates only a fixed level of security
which supports both encryption and authentication. Many
applications require a combination of both confidential and
non-confidential data which is not supported by MiniSec.
However hardware AES security hosts ensures low power
consumption and combinational levels of security. This feature
is available for hardware that contains IEEE 802.15.4
compliant RF transceiver like CC2420/CC2430/CC2431 chips
[6] and some of the motes that support this radio are TelosB,
MicaZ and Mote2. Not all motes like IRIS [19] etc support
hardware security. A software implementation of the AES
could be a way satisfies these requirements widely. We have
chosen AES for both efficiency and security reasons (see [8,

B. Supported block ciphers:
    There are many block ciphers available namely Skipjack
[16], RC5 [15], RC6 [11] and Rijndael [17]. Each cipher is                                 Fig. 1. Adaptive Framework
chosen based on the need of applications security, memory and
energy efficiency of the cipher [10].We have selected Rijndael
in the configuration of 128/128/10 (keysize/blocksize/rounds)
                                                                            Since one of the objectives of this paper is in providing a
but still our library suite supports [192—256]/128/[12—14]
                                                                        unified security access API to application developers, we
configurations. As, in WSN power is more of concern,
                                                                        introduce a use case of the framework with the security
choosing 128 bit key is more appropriate.
                                                                        component described. This security library lists available
                                                                        security algorithms, based on the version of TinyOS and the
C. Modes of Block cipher:                                               hardware platform chosen. There are two actors in the
CTR encryption: This is counter mode encryption. To make                framework, the application developer and the system
compatible with hardware AES we provided this option [18].              component developer. A system component developer

                                                                                                   ISSN 1947-5500
                                                                 (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                           Vol. 8, No.3, 2010
integrates security algorithms into the library suite in                    algorithm. For example, applications may use TinySec or
conjunction with the unified access API which we have                        MiniSec, Hardware AES or Software AES etc.
standardized. The system component developer is required to
create glue logic between the standardized API and the                      A. Hardware Independent AES with IEEE 802.15.4
algorithm’s internal functions. The application developer on the               Specification
other hand is required to use the unified access API to wire his
                                                                               In this section, implementation of the Software AES
application’s logic with the required security algorithm.
                                                                            security architecture with IEEE 802.15.4 specification which is
Algorithms implementing various modes of block ciphers
                                                                            provided in the framework security component is outlined.
discussed earlier are integrable into the security suite. We have
                                                                            According to IEEE 802.15.4 specification it has eight different
integrated our software AES with IEEE 802.15.4 specification
                                                                            security suites [13]. The Table IV, gives five modes and in last
and supported all modes for existing security algorithms is
                                                                            two modes each have different variants based on the chosen
outlined in Table V. We have also integrated security
                                                                            MAC value.
algorithms like TinySec [3], MiniSec [6], and Hardware
Security [5] in the suite. This framework is useful for security
related experimentations in perspective of both application
developer as well as System developer. Any new cipher can be
easily plugged-in and plugged-out. The unified APIs provided
for existing security algorithms removes the need of changing
the existing application code. The framework takes care of
mode settings based on chosen security layer and algorithm.
This framework is simple in ease of use, flexible and adaptive.

                            TABLE I

       command error t AFWAupdateKey(uint8_ t * key, set KEY);
       event void AFWAupdateKeyDone(uint8_ t * key);
       command error t AFWAsetTransmitMode( uint16_ t ctrl0,
                                               uint8_ t len );                            Fig. 2. Configuration file for Software AES
       command error t AFWAsetReceiveMode ( uint16_ t ctrl0,
                                               uint8_ t len );
       command error t AFWAsend( uint16_ t addr,
                                                                               The above Figure 2 depicts the configuration for software
                           message_ t *msg, uint8_ t len );
       event void AFWAsendDone( message_ t *msg,                            AES. We have configured in such a way that n-number of
                                            uint8_ t error);                modes can be integrate with AES module but only suitable
       command error t AFWAreset(uint8_ t Type);                            mode with AES module is loaded during the compile time.
       command error t AFWAget(uint8_ t *key, get KEY);                     This configuration makes developer easier to integrate AES
                                                                            module with any new mode.
    Ease of use: - It provides complete abstraction to the
application developer and introduces a GUI through which the                We will see each AES security suite in-detail:
application developer can select components of the lower                            CTR: This is counter mode encryption. It uses counter
layers. The framework will internally wire and create a                             value and it consists of sender’s address and 4-byte
template for application development. For example, if                               frame counter. We have not appended any flags and
application developer uses IRIS mote and needs software AES                         block counter to the data payload and hence this
with various mode settings, a project can be created for IRIS                       minimizes the power of mote. The block counter is the
mote using WSN IDE [21] and then call commands for mode                             number of blocks splited into 16 byte blocks within the
settings. Now the framework makes a setup and loads AES                             packet. This value can be calculated based on the size
library.                                                                            of the packet that is to be sent. The frame counter is
    Flexible: - Our framework is flexible, because it has feature                    maintained by the software AES and it is incremented
of plug-in and plug-out facility i.e. any security algorithm can                    for each packet automatically by software. The send
easily be integrated. Also, there are several schemes for key                       API includes frame counter and encrypted payload into
settings. In such a case dynamic key support is more robust                         the data payload of the packet. Below is the code
than the pre-configured key. We used Java Cryptographic [23]                         snippet for CTR mode encryption.
functions with mouse movement and keyboard random-key
generation. In this framework it supports both randomly
generated dynamic key and static key setting.                                        uint8_t *payload = call AMSend.getPayload(msg, len);
                                                                                     memcpy(, payload, len );
    Adaptive: - Level of security is application specific. So, it is                  call CtrI.AESctr encrypt((uint8_ t *), len,
                                                                                                               sec txl, nonceValue );
a choice of application developer to choose type of security                         memcpy(&fc1, &nonceValue[3], 4 );
needed. The framework is adaptive so that it can switch                              smsg.fc = fc1;
between levels of security and provides corresponding security                       memcpy(payload, &smsg, fcLen + len );
layer to the application based on selection of security                              return call AMSend.send( addr, msg, fcLen + len );

                                                                                                         ISSN 1947-5500
                                                         (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                   Vol. 8, No.3, 2010
 For example, if h ║ p1,...,pn is frame format then after                   call CcmI.AESccm auth((uint8_ t *), len,
 CTR mode encryption, packet sent will be h ║ zi ║ci,                                               sec txl,KeySizeB );
                                                                            call CcmI.truncateTag((uint8_ t *),len,
 where, ci =pi ⊕ AESk(xi ), h = header of TinyHop, zi =                                           appLen);
 Frame counter, ci = encrypted payload, xi = nonce                          call CcmI.AESccm encrypt((uint8_ t *), len,
 value or counter or initial vector.                                                                   sec txl,nonceValue );
                                                                            memcpy( &fc1, &nonceValue[3], 4 );
 CBC_MAC║SEC_M [0 − 7]: This mode provides                                  smsg.fc = fc1;
 only authentication. And the size of MAC value can                         memcpy( payload, &smsg, fcLen + len + appLen );
 vary between 4, 6, 8, 10, 12, 14, 16 byte. Here                            return call AMSend.send( addr, msg, fcLen + len +
 CBC_MAC║SEC_M[0− 7] is a macro setting that tells                                                   appLen );
 library to load AES with CBC_MAC mode. In the
 below code snippet truncateTag() command will                            For example, If h║p1, . . . , pn is frame format then after
 truncates MAC in the range {4,6,8,10,12,14,16} byte                      CCM mode, packet sent will be
 based on the SEC_M[0− 7] macro setting i.e. if the                               h ║ zi ║c1, . . . , cn ║ ENC(MAC)
 macro is set to one among the following SEC_M1,                          where, MAC = TruncSEC_M[0−7]{auth(h║p1, . . . , pn)},
 SEC_M2 ... SEC_M7 then each value maps to the
                                                                          ENC(MAC) = MAC ⊕ AESk(xi ),
 range {4,6,8,10,12,14,16} byte while SEC_M0 is
                                                                          ci = pi ⊕ AESk(xi ), zi = Frame Counter.
 reserved for future use. By default in CBC-MAC
 mode, length field is authenticated by software.
                                                                          AES_ENC: This is simplest mode. It provides simple
 In this it supports two protecting modes:                                AES encryption operation without any mode settings.
 (a) It protects header of TinyHop routing algorithm as                   Below is the code snippet that takes key size and
 well as the data payload. Suppose if h║p1,...,pn is frame                pointer to input array as an argument and produces
 format then after CBC_MAC authentication, packet                         encrypted output in the same input array.
 that is sent will be                                                       call AesI.startAES((uint8_ t)KeySize, (uint8_ t *)inPut);

     h║p1,...,pn ║ TruncSEC_M[0−7]{auth(h║p1,...,pn)}.
 (b) Protects only data payload. Suppose if h║p1,...,pn is                AES_DEC: This is simplest mode. It provides simple
 frame format then after CBC_MAC authentication,                          AES decryption operation without any mode settings.
 packet that is sent will be                                              Below is the code snippet that takes key size and
       h║p1,...,pn ║TruncSEC_M[0−7]{auth(p1,...,pn)}.                     pointer to input array as an argument and produces
                                                                          decrypted output in the same input array.
 Where, h = TinyHop header, pi= plain text.
                                                                            call AesI.startAES((uint8_ t)KeySize, (uint8_t *)inPut);

  uint8_t *payload = call AMSend.getPayload(msg, len);                 Figure 3, depicts the complete flow that takes changes in
  memcpy(, payload, len );                               the length field of the payload while sending a packet.
  call CtrI.AESctr encrypt((uint8_ t *), len,
                            sec txl, nonceValue );
  memcpy(&fc1, &nonceValue[3], 4 );
  smsg.fc = fc1;
  memcpy(payload, &smsg, fcLen + len );
  return call AMSend.send( addr, msg, fcLen + len );

CCM║SEC_M [0− 7]: This is AES counter mode
encryption and CBC-MAC authentication. Here
CBC_MAC║SEC_M[0 − 7] is a macro setting that tells
library to load AES with CCM mode and functionality
of SEC_M[0− 7] is same as previous mode setting. In
this mode first it authenticates header of TinyHop
routing algorithm and data payload using CBC-MAC
and then encrypts both data payload and MAC using
AES-CTR mode. Below is the code snippet for CCM
mode implementation.
                                                                                          Fig. 3. AES Security suite

  uint8_t *payload = call AMSend.getPayload(msg,                   FC = frame counter, fcLen = frame counter length
                                             len);                 len = length of the payload
  memcpy(, payload, len );                                sec_m = Number of bytes in authentication field for CBC-
  call CcmI.AESccm nonce(nonceValue);                                       MAC, encoded as (M-2)/2.

                                                                                                  ISSN 1947-5500
                                                             (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                       Vol. 8, No.3, 2010
B. Common API’s for Security algorithms                                   settings using two different motes i.e. IRIS and MicaZ. We
    Since, each security algorithm has its own parameter                  have taken application that sends encrypted packets using
settings; the developer has to know which API is to be used.              TinyHop routing algorithm to the Base Station. And then Base
We propose Security interface that contains common wrapper                Station decrypts the received packets and forwards the packet
API’s to set and get parameters for various security algorithms.          to serial forwarder where the user can view the original packet.
Before choosing security algorithm, application developer will            We sniffed the packets using sniffer to check whether packet is
choose version of tinyos and for this we created framework                encrypted or not in various mode settings. Tables II results are
[21] that lays above wrapper API’s. Some of the common                    obtained after installing software Advanced Encryption
API’s that we provided are:                                               Algorithm using TinyOS-2.1.0 without TinyHop routing
                                                                          algorithm and without our framework into MicaZ and IRIS
a) command error t AFWAupdateKey(uint8_t * key,                           motes.
                                      uint8_t setKEY );
                                                                                                     TABLE II
     event void AFWAupdateKeyDone(uint8_t * key);                             MEMORY UTILIZATION OF SOFTWARE AES USING TINYOS-2.1.0
                                                                                 FRAMEWORK WITHOUT T INYHOP ROUTING ALGORITHM
AFWAupdateKey() updates old key value to new key value
where KEY parameter defines which key is to be updated in                  Mote          ROM               RAM                 Name of
ACL entry. uint8_t *key is a pointer to an array containing 8-bit                      occupied          occupied              Cipher
unsigned integers. KEY is 8-bit unsigned integer that takes                             in bytes          in bytes             and its
macro value for ACL entries i.e. KEY0 or KEY1 or so on.                              (percentage)      (percentage)         configuration
b) command error t AFWAsetTransmitMode( uint16_t ctrl0,
                                                                          MicaZ     22256(17.38%)      2196(54.9%)         CCM mode
                                   uint8_t len );
                                                                                                                           with 16- byte
   command error t AFWAsetReceiveMode ( uint16_t ctrl0,
                                   uint8_t len );
AFWAsetTransmitMode() / AFWAsetReceiveMode() sets                                                                          AES 128/128/10
transmission and receiver mode for any security algorithm.                          22258(17.38%)      2196(54.9%)         CBC-MAC with
Parameter ctrl0 value can be a combination of macros given in                                                              16-byte MAC
Table IV and parameter len has value zero if the total payload
value is to be encrypted/decrypted otherwise len value                                                                     AES 128/128/10
specifies number of bytes to be encrypted or decrypted or                           22254(17.38%)      2196(54.9%)         CTR mode
number of bytes not to be encrypted or decrypted based on the
context and mode setting of ctrl0.                                                                                         AES 128/128/10
                                                                                    22242(17.37%)      2196(54.9%)         only        AES
c)   command error t AFWAsend( uint16_t addr, message_t                                                                    Encryption/
                          *msg, uint8_t len );                                                                             Decryption
     event void AFWAsendDone( message_t *msg,
                           uint8_t error );
                                                                                                                           AES 128/128/10
 AFWAsend( ) command is similar to AMSend() command.                       IRIS     21308(16.64%)     2404(30.05%)         CCM mode
This command will set correct length of the transmitted                                                                    with 16- byte
message when Hardware/Software AES security is used and
this command does nothing for other security algorithms.
                                                                                                                           AES 128/128/10
d) command error t AFWAreset(uint8_t Type);                                         21306(16.64%)     2404(30.05%)         CBC-MAC with
                                                                                                                           16-byte MAC
This command is used to reset MAC or Encryption
initialization vectors of security algorithm.                                                                              AES 128/128/10
                                                                                    21304(16.64%)     2404(30.05%)         CTR mode
e)   command error t AFWAget(uint8_t *key, KEY );

This command is used to get key value from ACL entry. KEY
is 8-bit unsigned integer that takes macro value for ACL                            21292(16.63%)     2404(30.05%)         AES 128/128/10
entries i.e. KEY0 or KEY1 or so on and the final result is                                                                 Only AES
fetched to key.                                                                                                            Encryption/
             IV. RESULTS AND ANALYSIS                                                                                      decryption
  We have tested our proposed framework and software
Advanced Encryption Standard (AES) with various mode

                                                                                                     ISSN 1947-5500
                                                            (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                      Vol. 8, No.3, 2010
   Table III results are obtained after installing software           composed of existing security algorithms for popular sensor
Advanced Encryption Algorithm using TinyOS-2.1.0 with                 node hardware platforms. The framework also supports
TinyHop routing algorithm and with our framework into                 existing versions of TinyOS providing the application
MicaZ and IRIS mote. The TinyHop routing algorithm                    developer an abstraction to low level implementation of the
occupies more memory as to manage routing information. Also           desired security algorithm chosen. We also Implemented and
we have removed distinction between key and frame counter             integrated software AES and hardware AES driver for
[13].                                                                 CC2420/CC2430/CC2431 radio chip [5] with same mode
                                                                      settings like encryption-only, CBC-MAC integrity-only,
                           TABLE III                                  counter encryption only and counter encryption – CBC-MAC
    MEMORY UTILIZATION OF SOFTWARE AES USING TINYOS-2.1.0             integrity with dynamic and static key support. We have tested
        FRAMEWORK WITH TINYHOP ROUTING ALGORITHM                      the code using with and without TinyHop routing algorithm.
Mote         ROM               RAM          Name of Cipher                The work presented in this paper can be applied to various
           occupied          occupied           and its               mote platforms. Future extensions are also possible to integrate
            in bytes          in bytes       configuration            various security modes with simple plug-in and plug-out
         (percentage)      (percentage)                               configuration file. Currently the framework is in-built with
                                           AES 128/128/10             WSN IDE [21] that creates templates for application and then
MicaZ   29848(23.31%)      3739(93.4%)     CCM mode with              application developer has to wire the modules manually. In the
                                           16-byte                    next design we extend this framework and security modules
                                                                      wiring with drag and drop options.

                                           AES 128/128/10                                             REFERENCES
        29850(23.32%)      3663(91.5%)     CBC-MAC with               [1]    K. Piotrowski, P. Langendoerfer, S. Peter,―How public key cryptography
                                           16-byte                           influences wireless sensor node lifetime,‖ Proc. of fourth ACM
                                                                             workshop on Security of adhoc and sensor networks(SASN 06), pages
                                                                             169-176,2006. ACM..
                                           AES 128/128/10,
                                                                      [2]    A. Wander, N. Gura, H. Eberle, V. Gupta, S. C. Shantz,―Energy analysis
        29774(23.26%)     3435(85.87%)     CTR mode                          of public-key cryptography for wireless sensor networks,‖ Proc. of Third
                                                                             IEEE International Conference on Pervasive Computing and
                                           AES 128/128/10,                   Communications (PerCom 05), pages 324-328, March 2005.
        29676(23.18%)     3359(83.97%)     Only        AES            [3]    Chris Karlof, Naveen Sastry, David Wagner, ―TinySec: Link Layer
                                                                             Encryption for Tiny Devices―, ACM Conference on Embedded
                                           Encryption/                       Networked Sensor Systems, 2004.
                                           Decryption                 [4]    Tieyan Li, Hongjun Wu, Xinkai Wang, Feng Bao,―SenSec Design, I2R
                                                                             Sensor Network Flagship Project‖; Technical Report TRv1.0.
                                                                      [5]    2.4 GHz IEEE 802.15.4/ZigBee-ready RF Transceiver, Chipcon
                                           AES 128/128/10,                   Products from Texas Instruments.
IRIS    28758(22.46%)     3923(49.03%)     CCM mode with              [6]    Mark Luk, GhitaMezzour, Adrian Perringm, Virgil Gligor,―MiniSec: A
                                           16-byte MAC                       Secure Sensor Network Communication Architeture‖, ACM
                                                                             International Conference on Information Processing in Sensro
                                                                             Networks, April 2007.
                                                                      [7]    Phillip Rogaway, Mihir Bellare, John Black, ―OCB: A block-cipher
                                           AES 128/128/10,                   mode of operation for efficient authenticated encryption‖, ACM
        28760(22.46%)     3831(47.88%)     CBC-MAC with                      Transactions on Information and System Security (TISSEC), Volume 6,
                                                                             Issue 3, pp.365-403, August 2003.
                                           16-byte MAC
                                                                      [8]    Devesh Jinwala, Dhiren Patel, K S Dasgupta,―Optimizing the Block
                                                                             Cipher Modes of Operations Overhead at the Link Layer Security
                                           AES 128/128/10,                   Framework in the Wireless Sensor Networks,‖ Proceedings of the 4 th
        28682(22.40%)     3555(44.43%)     CTR mode                          International Conference on Information Systems Security, LNCS,
                                                                             pp.258-272, Springer Berlin/Heidelberg, 2008.
                                                                      [9]    Miklos Maroti, Gyula Simon, Branislav Kusy, and Akos Ledeczi,―The
                                           AES 128/128/10,                   flooding time synchronization protocol,‖ in Proceedings of the 2nd
        28650(22.38%)     3359(41.98%)     only        AES                   international conference on Embedded networked sensor systems,
                                           Encryption/                       Baltimore, MD, USA, Nov. 2004, pp. 3949.
                                           Decryption                 [10]   Law, Y.W., Doumen, J., Hartel, P, ―Survey and benchmark block
                                                                             ciphers for wireless sensor networks‖; ACM Transactions on Sensor
                                                                             Networks, 2006.
                                                                      [11]   RC6 cipher -
                                                                      [12]   Mingbo Xiao, Xudong Wang, Guangsong Yang,―Cross-Layer Design
                                                                             for the Security of Wireless Sensor Networks‖, Proceedings of the 6th
           V.    CONCLUSION AND FUTURE WORK                                  World Congress on Intelligent Control and Automation, Jnue 21-
                                                                             23,2006 Dalian, China,pp(104-108).
                                                                      [13]   Naveen Sastry and David Wagner, ―Security Considerations for IEEE
   The framework implemented is unique for WSN                               802.15.4 Networks―. ACM Workshop on Wireless Security WiSe 2004,
applications. It has general purpose security library suite                  October 2004.

                                                                                                        ISSN 1947-5500
                                                                         (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                                   Vol. 8, No.3, 2010
[14] Kalpana Sharma, M.K. Ghose, Kuldeep, ―Complete Security Framework
     for Wireless Sensor Networks‖, (IJCSIS) International Journal of
     Computer Science and Information Security, Vol. 3, No. 1, 2009.                                              TABLE IV
[15] Rivest R; ―The RC5 Encryption Algorithm‖, Proceedings of the Second                        MODE SETTINGS FOR VARIOUS SECURITY ALGORITHMS
     International Workshop on Fast Software Encryption, 1994.
[16] Skipjack - a representative of a family of encryption algorithms as part
     of          the         NSA          suite         of        algorithms;          Algorithm                           ctrl0                         len             AES:                                                               0
[17] J.Daemen,          V.Rijmen,      ―AES         Proposal:      Rijndael‖,         Stand Alone        AES_STANDALONE ║KEY0                                   AES_STANDALONE ║KEY1                            0
[18] Helger Lipmaa, Phillip Rogaway and David Wagner. Comments to                     AES:               AES_INLINE ║[T║R]XKEY [0|1]                     X
     NIST Concerning AES-modes of Operations: CTR-mode Encryption. In
     Symmetric Key Block Cipher Modes of Operation Workshop,                          In-line            ║CBC_MAC║SEC_M[0 − 7]
     Baltimore, Maryland, USA, October 20, 2000.                                                         AES_INLINE ║[T║R]XKEY[0|1]                      X
[19] IRIS motes -                                   ║CT R
[20] Whiting, D., Housley, R. and N. Ferguson, ―AES Encryption                                           AES_INLINE ║[T║R]XKEY [0|1]                     X
     Authentication Using CTR Mode CBC-MAC,‖ IEEE P802.11 doc                                            ║CCM
     02/001r2, May 2002.                                                                                 AES_INLINE ║[[T║R]XKEY[0|1]                     X
[21]                                                                         ║CBC_MAC ║SEC_M[0 − 7]
[22]                                                           TinySec            TINYSEC_AUTH_ONLY                               0
[23]                                  TINYSEC_ENCRYPT_AND_AUTH                        0
                                                                                                         TINYSEC_DISABLED                                0
                                                                                                         TINYSEC_RECEIVE_                                0
                                                                                                         TINYSEC_RECEIVE_CRC                             0
                                                                                                         TINYSEC_RECEIVE_ANY                             0
                                                                                      MiniSec            MINISECU                                        0

                                                                                                                   TABLE V
                                                                                                MODE SETTINGS FOR VARIOUS SECURITY ALGORITHMS

                                                                                      Algorithm          Macro                       Description
                                                                                      AES            AES_ENC                  only AES encryption
                                                                                                     AES_DEC                  only AES decryption
                                                                                                     CTR                      AES        Counter-Mode
                                                                                                                              This mode is not secure,
                                                                                                                              to make compatible with
                                                                                                                              AES we provided this
                                                                                                     CBC_MAC                  4, 6, 8,10,12,14, 16 byte
                                                                                                     ║SEC_M[0-7]              -MAC. AES CBC-MAC,
                                                                                                                              it provides only
                                                                                                     CCM                      4,6,8,10,12,14,
                                                                                                     ║SEC_M[0-7]              16-byte MAC. AES
                                                                                                                              Counter mode
                                                                                                                              encryption and CBC-
                                                                                                                              MAC authentication

                                                                                                                  ISSN 1947-5500

To top