Study and Design of Energy Eﬃcient Block Cipher for ... and Design of Energy Eﬃcient Block...

Study and Design of Energy Efficient Block Cipher forWireless Body Area Networks (WBANs)

A Thesis

Submitted For the Degree of

Master of Science (Engineering)

in the Faculty of Engineering

by

Nivedita Datta

Supercomputer Education and Research Centre

Indian Institute of Science

BANGALORE – 560 012

JULY 2014

i

�Nivedita Datta

JULY 2014

All rights reserved

TO

My parents and my sister

who have encouraged and supported me

in every phase of my life

Acknowledgements

This thesis would not have been possible without the support, guidance and love from

so many people around me. I would like to especially thank my advisor, Professor N.

Balakrishnan for his encouragement, insight and patience. I was fortunate to be a part

of Professor N. Balakrishnan’s research group, and learn from his seemingly unlimited

supply of clever ideas and kindness. I have learned from him not only how to conduct

high-quality research, but also how to create a healthy work-life balance. I am also

thankful to Prof. Veni Madhavan and Dr. T.V. Prabhakar for their valuable inputs that

helped me complete my work in time.

I am indebted and thankful to my parents and sister, for patiently supporting me

through difficult times and believing in me. Without their unwaivering faith in me

and their support to pursue my dreams I would never have been able to complete my

Master’s.

A major portion of this thesis was born out of the numerous coffee breaks and endless

discussions with Avinash, Sovan and all my lab mates. Without their ingenious ideas

and endless criticisms about solving various problems, this thesis would never have been

possible. I thank them all for coming into my life and helping me grow.

i

Abstract

With the advent of better health care and medical technology, as well as miniaturized

devices with built-in radios, today we can see Wireless Body Area Networks (WBANs)

emerging as one of the main research topics. The sensor nodes worn by patients in a

WBAN collect and/or process large amount of data for continuous health monitoring or

analysis. However, as the data being dealt with is private and sensitive, even protected

by law in many countries, secure data transmission in WBAN is one of key the issues

and needs to be addressed before it can be widely deployed. The communication of the

sensitive data among the sensors or sensor to health servers give rise to data security

concerns like integrity, confidentiality, authentication etc. and the focus of this thesis

is to ensure confidentiality of data using encryption, specifically in energy constrained

applications as in WBAN.

In this thesis, the energy consumption by 14 of the most popular symmetric ci-

phers including 11 of the ciphers which are commonly used in lightweight encryption

applications have been studied using simulation tool Avrora for MICAz platform. A

new metric called MSEC (Metric for Security v/s Energy Consumption) that quantifies

the trade-off between energy consumption and security of a cipher has been proposed.

In the simulation, the number of CPU cycles have been taken as a measure of energy

consumed. It has been shown that the least energy of 0.03 mJ per block is consumed

by TEA while LED-64 consumes 2800% (28 times) more energy which is the highest

among the investigated ciphers. Taking into consideration the security of these ciphers,

the MSEC for these algorithms are -95.56 and -0.615 respectively as their effective key

ii

iii

length is very low and can be broken by brute-force. Comparisons show that based on

MSEC, AES is the most optimal cipher with MSEC value of 73.3.

The same suite of algorithms has also been ported on to a hardware mote called

TelosB and the energy consumed by the algorithms and their metric value have been

measured. We have observed that as TelosB consumes approximately 60% less energy

per CPU cycle as compared to MICAz platform. The total energy consumed by ciphers

on TelosB is lesser than MICAz thus resulting to comparatively higher metric value for

TelosB. It has been shown that the least energy of 0.0123 mJ per block is consumed by

TEA while LED-64 consumes 2700% (26.9 times) higher. Taking into consideration the

security of these ciphers, the MSEC for these algorithms are -97.69 and -0.75 respectively.

Comparisons show that based on MSEC, AES is the most optimal cipher on TelosB as

well with MSEC value of 73.3. The comparison between the simulation on Avrora for

MICAz and the actual realization on a hardware mote has shown that the two results

are similar.

A deeper study of the lightweight algorithms has also shown that they innovatively

mix the various stages of a traditional SPN (Substitution Permutation Network) based

cipher like AES. In this thesis, one such new algorithm called LEA (Lightweight Encryp-

tion Algorithm) has been proposed which has a skeletal structure similar to AES. The

proposed algorithm uses AES S- box for byte-wise substitution and AES key scheduling

to generate the round keys. Further, the ShiftRows in AES is replaced by StateTranspose

step and a new non-linear step called MixBits has been introduced in this cipher which

performs bit-wise operations like bitwise shifts and XOR on the input blocks to increase

the diffusion property of the cipher. The MixBits step is analogous to the MixColums

step of AES. In addition, for improved security, it uses key whitening as proposed in

DESX. Based on observations for DESX, the effective key length of LEA comes down to

191 bits which gives a MSEC value of 154.38 while consuming 0.0219 mJ per block on

TelosB platform.

We have observed that as an effect of the MixBits step, LEA has large number

of active S-boxes per round and the properties of confusion and diffusion are spread

iv

across all the output bytes by end of round 3 of the cipher. In order to perform the

preliminary cryptanalysis on LEA, a bytewise randomness test was conducted for LEA

on a sample size of 232 in which a very small standard deviation of around 4000 (mean

value = 16777216) was observed by end of round 3 indicating that all the possible byte

values are spread uniformly across the output block. Also, the energy consumed by LEA

is compared with the existing lightweight algorithms and we found that it consumes

around 15% more energy than AES but lesser than most other lightweight encryptions

proposed in the literature. However the MSEC value of LEA proposed is higher than

AES. From the initial cryptanalytic studies, it is possible to conclude that fewer rounds

of the proposed algorithm will give rise to better energy efficiency than AES. A detailed

cryptanalysis would be needed to provide definitive answer.

Contents

Acknowledgements i

Abstract ii

Keywords xiii

Notation and Abbreviations xiv

1 Introduction 11.1 Overview of Wireless Body Area Networks . . . . . . . . . . . . . . . . . 11.2 WBAN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Sensor Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Base Station Level . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.3 Remote Server Level . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Challenges in WBAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 WSNs v/s WBANS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5.1 Inverse Square Law . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5.2 Energy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5.3 Radio Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5.4 Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.6 Organization of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Security and Adversary Models for WBANs 182.1 Network Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.1 Properties of nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Security Requirements of WBAN . . . . . . . . . . . . . . . . . . . . . . 20

2.2.1 Data Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.2 Data Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.3 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.4 Data Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.5 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3 Security Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4 Adversary Model for WBAN . . . . . . . . . . . . . . . . . . . . . . . . . 23

v

CONTENTS vi

2.4.1 Types of adversary . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4.2 Adversary target . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4.3 Capabilities of an adversary . . . . . . . . . . . . . . . . . . . . . 252.4.4 Available resources . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Recommended key length . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Survey and Simulation of Block Ciphers 293.1 Survey of Simulation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1 NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.2 TOSSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.1.3 OMNet++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.4 Avrora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.5 OPNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Survey of Block Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.1 AES-128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.2 DESXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.3 HIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.4 IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.5 KLEIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.6 LBLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.7 LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.8 mCrypton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.9 Piccolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.10 PRESENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.11 TEA and XTEA . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.12 SEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 Platform and Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.1 Experiment Platform . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.4 Experiments and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.1 Memory Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.2 Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . . 473.4.3 Energy Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.5 MSEC: Metric for Security v/s Energy Consumption . . . . . . . . . . . 503.5.1 Strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.5.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4 Sensors and Operating Systems for WSNs 554.1 Types of Sensor Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.1 MICAz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.2 MICA2DOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.1.3 Imote-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.1.4 TelosB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

CONTENTS vii

4.1.5 Tmote Sky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2 Types of Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.1 WSN OS design concerns . . . . . . . . . . . . . . . . . . . . . . . 594.2.2 Survey of Operating Systems . . . . . . . . . . . . . . . . . . . . 61

4.3 Energy Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.4 MSEC: Metric for Security v/s Energy Consumption . . . . . . . . . . . 68

5 LEA: Lightweight Encryption Cipher 715.1 IEEE 802.15.4 security framework . . . . . . . . . . . . . . . . . . . . . . 715.2 SPN based ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2.1 S-box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.2 P-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.3 Round Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.3 Design Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3.1 Key Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3.2 Input and Output State . . . . . . . . . . . . . . . . . . . . . . . 76

5.4 Structure of LEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.4.1 Key Whitening . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.4.2 The Round Transformation . . . . . . . . . . . . . . . . . . . . . 79

5.5 SubBytes Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 805.5.1 State Transpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.5.2 MixBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.5.3 AddRoundKey step . . . . . . . . . . . . . . . . . . . . . . . . . . 845.5.4 Key Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.6 The Inverse Cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.7 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.7.1 Effective Key Length . . . . . . . . . . . . . . . . . . . . . . . . . 875.7.2 Performance on motes . . . . . . . . . . . . . . . . . . . . . . . . 87

5.8 Strength of LEA against statistical attacks . . . . . . . . . . . . . . . . . 875.8.1 Confusion and Diffusion . . . . . . . . . . . . . . . . . . . . . . . 885.8.2 Bytewise Randomness Test . . . . . . . . . . . . . . . . . . . . . . 91

5.9 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.9.1 Independence of plain text and ciphertext . . . . . . . . . . . . . 955.9.2 Mathematical Property of LEA . . . . . . . . . . . . . . . . . . . 965.9.3 Avalanche Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.9.4 Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6 Conclusions 107

A Sage for Cryptography 110A.1 S-Boxes and Their Algebraic Representations . . . . . . . . . . . . . . . . 111

Bibliography 116

List of Figures

1.1 3-tier hierarchal architecture of WBANs [1] . . . . . . . . . . . . . . . . . 31.2 WBAN v/s WSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Inverse Square Law [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Inverse Square Law [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5 First Order Radio Model [4] . . . . . . . . . . . . . . . . . . . . . . . . . 111.6 Zigbee Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.7 Power consumed by Radio (in watts) . . . . . . . . . . . . . . . . . . . . 151.8 WSN Applications and Radio distance . . . . . . . . . . . . . . . . . . . 16

2.1 Network model of WBANs . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 NS2 Graphical interface: NAM . . . . . . . . . . . . . . . . . . . . . . . 313.2 Comparison of Energy Consumption for Evaluated Ciphers . . . . . . . . 493.3 Comparison of Evaluation Metric . . . . . . . . . . . . . . . . . . . . . . 54

4.1 Sensor Node Architecture [5] . . . . . . . . . . . . . . . . . . . . . . . . . 564.2 Types of Sensor Motes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3 Architecture of TinyOS [5] . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.5 Typical TCPA300 current measurement system [6] . . . . . . . . . . . . . 674.6 Energy Per Byte (in µJ) consumed on TelosB . . . . . . . . . . . . . . . 694.7 MSEC value for investigated ciphers on TelosB platform . . . . . . . . . 70

5.1 Skeletal structure of SPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2 Keylength: 256 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.3 Example of a STATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4 Key Whitening: Whitening Key XORed with STATE . . . . . . . . . . . 795.5 StateTranspose: Rows and columns of STATE interchanged . . . . . . . 815.6 Add Round Key: STATE XOR Round Key-i . . . . . . . . . . . . . . . . 855.7 Only MixBits One iteration . . . . . . . . . . . . . . . . . . . . . . . . . 935.8 Only MixBits Two iteration . . . . . . . . . . . . . . . . . . . . . . . . . 945.9 Only MixBits Three iteration . . . . . . . . . . . . . . . . . . . . . . . . 955.10 LEA Round Transformation One iteration . . . . . . . . . . . . . . . . . 965.11 LEA Round Transformation Two iteration . . . . . . . . . . . . . . . . . 975.12 LEA Round Transformation Three iteration . . . . . . . . . . . . . . . . 98

ix

LIST OF FIGURES x

5.13 LEA Round Transformation without MixBits One iteration . . . . . . . . 995.14 LEA Round Transformation without MixBits Two iteration . . . . . . . 1005.15 LEA Round Transformation without MixBits Three iteration . . . . . . . 1015.16 Energy consumption comparison of LEA on MICAz . . . . . . . . . . . . 1035.17 Energy consumption comparison of LEA on TelosB . . . . . . . . . . . . 1045.18 MSEC comparison of LEA on MICAz . . . . . . . . . . . . . . . . . . . . 1055.19 MSEC comparison of LEA on TelosB . . . . . . . . . . . . . . . . . . . . 106

A.1 Sage: common functions examples . . . . . . . . . . . . . . . . . . . . . . 111A.2 Sage: Substitution Cipher Example . . . . . . . . . . . . . . . . . . . . . 112A.3 Sage: Basic S-box operations . . . . . . . . . . . . . . . . . . . . . . . . . 112A.4 Sage: S-box Construction using Polynomial System Generator . . . . . . 113A.5 Sage: Difference Distribution Matrix generation . . . . . . . . . . . . . . 114A.6 Sage: Linear Approximation Matrix generation . . . . . . . . . . . . . . 114A.7 Sage: Linear Approximation Matrix generation for AES S-box . . . . . . 115A.8 Sage: Difference Distribution Matrix generation for AES S-box . . . . . . 115

List of Tables

1.1 Radio Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Output power settings and typical current consumption (2.45 GHz) . . . 14

1.3 Output power settings and typical current consumption (2.45 GHz) . . . 14

1.4 Spectrum of Radio Hardware CC2420 [7] . . . . . . . . . . . . . . . . . . 17

2.1 WBAN Sensors and their properties [8] . . . . . . . . . . . . . . . . . . . 20

2.2 WBAN Security threats and solutions [9] . . . . . . . . . . . . . . . . . . 22

3.1 Summary of Investigated Block Ciphers . . . . . . . . . . . . . . . . . . . 36

3.2 Summary of Lightweight Block Ciphers . . . . . . . . . . . . . . . . . . . 43

3.3 Summary of Memory Requirement . . . . . . . . . . . . . . . . . . . . . 47

3.4 Summary of Energy Consumption . . . . . . . . . . . . . . . . . . . . . . 48

3.5 Comparison of Metric Value for Block Ciphers . . . . . . . . . . . . . . . 53

4.1 Summary of Operating Systems for WSNs . . . . . . . . . . . . . . . . . 64

4.2 Energy Cost on MICAz v/s TelosB . . . . . . . . . . . . . . . . . . . . . 67

4.3 Energy Consumption by Ciphers on TelosB . . . . . . . . . . . . . . . . . 68

4.4 Comparison of Metric Value for Block Ciphers . . . . . . . . . . . . . . . 69

5.1 IEEE 802.15.4 Security Framework . . . . . . . . . . . . . . . . . . . . . 72

5.2 Bit flip probability in ciphertext . . . . . . . . . . . . . . . . . . . . . . . 89

5.3 One bit key change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.4 One bit plaintext change . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.5 One bit ciphertext change . . . . . . . . . . . . . . . . . . . . . . . . . . 91

xi

LIST OF TABLES xii

5.6 Standard deviation of frequency of byte values . . . . . . . . . . . . . . . 92

Keywords

Wireless Sensor Networks, Body Area Networks, Survey, Lightweight

Encryption, LEA, Metric, Security

xiii

Notation and Abbreviations

� AES Advanced Encryption Algorithm

� BER Bit Error Rate

� CPU Central Processing Unit

� DES Data Encryption Standard

� DESL Data Encryption Standard Lightweight

� DoS Denial of Service

� LEA Lightweight Encryption Algorithm

� MAC Message Authentication Code

� MIPS Million Instructions Per Second

� MSEC Metric for Security v/s Energy Consumption

� nesC network embedded system C

� NS-2 Network Simulation 2

� OMNet++ Objective Module Network Test-bed in C++

� PDA Personal Device Assistant

� SEA Scalable Encryption Algorithm

xiv

LIST OF TABLES xv

� TEA Tiny Encryption Algorithm

� TOSSIM TinyOS SIMulator

� WASN Wireless Actuators Sensor Network

� WBAN Wireless Body Area Network

� WSN Wireless Sensor Network

� γ key length of cipher

� y(γ) Security provided by a cipher with key length γ

� r radius of area covered by radio

� k length of message

� �amp power required for the transmit amplifier to reach an acceptable Eb/Na

� ETxelec Transmitter Electronics

� ERxelec Receiver Electronics

� α beam of width of directional antenna

� λ wavelength of the signal

Chapter 1

Introduction

1.1 Overview of Wireless Body Area Networks

A Wireless Body Area Network(WBAN) [10] [11] [12] is formally defined by IEEE 802.15

[13] [14] [15] [16] as “a communication standard optimized for low power devices and

operation on, in or around the human body (but not limited to humans) to serve a

variety of applications including medical, consumer electronics / personal entertainment

and other”. In simpler terms, a Body Area Network can be defined as a system of

miniaturized low power devices and bio-sensor/actuators worn on or implanted inside a

human body.

A WBAN consists of small devices with inbuilt or external sensors [17] [18] which

can be worn by a person or can be implanted inside the body. These devices also have

inbuilt radio which enables them to communicate wirelessly among themselves or with a

special node called the base station(BS) [19] [20]. These devices sense various parameters

from their environment and forward the sensed data to the base station with or without

post-processing on the data. These devices can continuously monitor a person’s health

and give feedback to the user or to the medical personnel.

The WBAN devices can either be a sensor or an actuator [21]. A sensor device will

measure various parameters of the body including temperature, blood pressure, heart

rate and blood glucose either externally or internally. Actuators on the other hand can

1

Chapter 1. Introduction 2

take some action based on the sensed data or command received from the user/medical

personnel. eg. an actuator device with in-built insulin reservoir can pump correct dose

of insulin to the blood based on the sensed glucose levels or command received from an

authenticated medical personnel. These WBAN devices process and forward the sensed

data to the base station device with which usually is a hand-held device such as a PDA

or a smart phone. The base station mostly processes and forwards the aggregated data

to the remote servers over the Internet for further processing and analysis.

1.2 WBAN Architecture

With the technological advances made in the field of processors and hardwares, today we

can have miniature devices with their own processor, memory, sensors and radio. The

WBAN system consists of miniature sensor devices that can communicate wirelessly

[22] [1] among themselves or with the hand-held device which acts as the base station.

The base station can process the data before forwarding it to a remote server over the

Internet. Figure 1.1 shows a generalized multi-tier system architecture [23] that mainly

consist of 3 different layers. The lowest or the first layer consist of the sensing devices;

the second layer is the base station which might be a PDA or a cellphone; and the last

layer is the remote server to which all the data is sent which can be accessed by a medical

personnel with proper privileges.

1.2.1 Sensor Level

AWBAN consist of numerous devices that periodically sense data from their environment

and forward the sensed data either to a leader node [24] [25] [26] of the network which

will later forward the aggregated data to the base station or they can directly forward the

data to the base station. A sensor device should have the following properties: minimal

weight, miniature size, low power operations, easy to integrate into an existing network

and easy application based customization.


Figure 1.1: 3-tier hierarchal architecture of WBANs [1]

1.2.2 Base Station Level

A base station which mostly consist of a PDA or a cell phone/smart phone should perform

the following tasks:

� Initialization, configuration and synchronization of the nodes.

� Monitor and control node operation.

� Collect the sensor data.

� Processing and integration of the data collected from all the sensors.

� Act as a trusted party for security services among nodes.

� Securely forward the aggregated data to the remote servers using the Internet

services.


1.2.3 Remote Server Level

A healthcare service provider [27] mostly runs a service that would collect the data from

all the patients, store them on the server, further process and analyze them, update

the patient’s medical records and send recommendations if needed. Based on changes

observed in a patient’s data, a patient can be notified in case of an emergency or an

alternate course of therapy can be recommended based on the new data, patient’s old

data and similar prior cases.

1.3 Challenges in WBAN

Although most of the challenges [28] faced by a WBAN are same as the generic WSNs,

some major concerns in a WBAN for healthcare application are the following:

Extreme Energy Efficiency For ease of use and comfort for the users and widespread

adoption of WBAN [29], the sensor devices deployed must be small in size with

enough power supply to last for a range starting from few days to a few months

or years depending on the application and the placement of the device eg. a node

which is implanted inside the body is expected to have a much longer lifetime on a

single battery as compared to the ones worn on body which can be easily recharged.

However, the size of the device also restricts the size of the power source it can

carry. Hence, the energy usage [30] by the WBAN devices should be minimal.

Managing Interference With a widespread adoption of WBANs, when multiple peo-

ple wearing WBAN come into range of each other, there will be an interference [31]

and network co-ordination will be difficult [29]. Also when two or more WBANs

are in range of each other, a node from one WBAN might read a message from

another WBAN. This might be an issue especially in network where an actuator

node might act on a message received from another WBAN. This issue can however

be resolved by implementing proper user-authentication service [32] [33] which will

confirm the correctness of source of the message before taking any action.


Security Unauthorized access [32] [33] or manipulation of a node [10] in the network

might have a severe consequence on the performance of the whole network. eg.

an adversary might try to inject false packets [34] into the network or manipulate

packets in transit. Hence user authentication and data integrity checks will help

prevent the consequences due to such attacks [35] [36] [37] [38].

Privacy As WBANs will be dealing with potentially sensitive health data about people,

we need to protect the user’s privacy [10] [38] [39]. An adversary might passively

listen to the communication and try to overhear the critical information. Hence

confidentiality of the data is achieved by encrypting patient’s data with a secret key

to secure the node-to-node communication, node to base station communication

and base station to remote server communication.

1.4 WSNs v/s WBANS

Although WBANs share some common features with the generic Wireless Sensor Net-

works (WSNs) like low computation power, small memory, small energy resource etc.,

the solutions for generic WSN applications might not be applicable to WBAN due to

the differences listed out in Fig. 1.4. Of all the differences between WBAN and WSN, a

few properties of WBAN which makes its security needs [12] [27] different than that of

the generic WSNs has been briefly described below:

Energy consumption Unlike generic WSNs, the sensors or devices in WBANs are

placed on or implanted inside human body thus restricting the flexibility of regu-

larly charging the device or replacing the energy source. Hence a security solution

needs to be designed with minimal communication and computation operations so

that sensor/device can run for a long time with minimum energy requirement.

Memory As most of the devices and bio-sensors have to be very small in order to not

create problems for the user, there is a restriction on the amount of memory that

can be placed on these devices. In a few projects that are being implemented,


the amount of memory available on each node is not enough for the current cryp-

tographic algorithms like AES, DES etc. which leads to a requirement of newer

encryption algorithm with lower memory requirement.

Topology As communication in WBAN mainly happens from sensor to base station,

WBAN has a star topology [40] and the communication distance is mostly within

a short range (radius of 1-1.5 m). As the communication range is less, single-hop

communication is enough for the communication. Also, position of the sensors are

relatively constant except for some body movement hence the network topology

does not change dynamically.

Network Structure As the sensors (nodes) are not dynamically added or removed

from the network and the number of nodes in a network is relatively very less

(4-64), they don’t need to periodically keep discovering their neighbors.

Based on the above mentioned features of WBANs which differentiates it from the

generic WSNs, the existing asymmetric encryption protocols are not an optimal or fea-

sible solution for ensuring data communication security.

On the other hand, most common data encryption protocols like AES [41], IDEA

[42], RC5 [43] etc which are used for bulk encryption in most applications are quite com-

plex and involve large number of rounds or steps making it resistant to many attacks.

However, the complexity causes consumption of large amount of CPU power and energy.

As the nodes in WBANs are resource constrained and recharging the power source of the

WBAN nodes might not be easy, a deeper study of these encryption protocols is needed

to analyze if they can be used in WBANs . eg. It was shown by Ruangchaijatupon

et al. [44] that 3500 encryptions using blowfish with 32 bit key on a hand-held device

can drain up to 75% of its battery power. Hence we need to design an energy efficient

cryptographic protocol specific to the needs of WBANs.


Figure 1.2: WBAN v/s WSNs

1.5 Motivation

With the advent of better health care and medicine technology, as well as miniaturized

devices, today we can see WBAN emerging as one of the main research trend where large

amount of data can be collected and/or processed by the devices worn by patients for

continuous health monitoring or analysis. WBANs can prove to be helpful not only for

patients but can also to assist disabled people or to help monitor children when their

parents are away. However, as the data being dealt with is private and sensitive, even

protected by law in many countries, secure data transmission in WBAN is one of the

issues which needs to be addressed before it can be widely and/or commercially used.

The communication of these sensitive data among the sensors or sensor to health servers

give rise to data security concerns like integrity, confidentiality, authentication [38] etc.

The focus of this thesis is to understand the needs specific to BAN which makes it

different from the generic Wireless Sensor Networks (WSNs) and thus design an efficient

light weight encryption protocol for BANs. In WBANs, most of the nodes are on a single-

hop range of each other and have limited and non-replenishable energy source which are


mostly neither rechargeable nor replaceable. Hence the total energy consumed has to be

reduced in order to increase the effective lifetime of a node. According to the radio model

proposed by Heinzelman et al. [4], data communication consumes most of the energy as

compared to data sensing or data processing. Hence one of the desirable communication

pattern is to use a short-range communication instead of long-range communications

as long-range transmission consumes more energy [45]. Thus in case of WSN scenarios

where the node density is high, the data packets can be forwarded through intermediate

nodes thus leading to a multi-hop path.

In this section, node model, energy model and energy consumed by the node for

both communication and computations will be explored. It can be seen that the amount

of energy consumed by encryption is significant when the communication range is low

thus making it a major concern for WBAN.

1.5.1 Inverse Square Law

As mentioned above, the data communication [4] (transmission and receiving) consumes

most of the power in case of wireless communication because unlike in wired commu-

nication, the messages transmitted wirelessly decay in an accelerated manner. This is

because as the radio signals are radiated from their source, they start spreading out

rapidly like ripples. The radio signals decay according to the inverse square law which

states that the intensity of the signal at a particular point is inversely proportional to

the square of its distance from the source of the signal i.e. Intensity ∝ 1/r2. Fig. 1.3

shows that as the distance (range) of the radio doubles, the power consumed increases

by four times.

So in case of the WSNs, as the power is constrained, messages that need to travel

long distance are sent across via intermediate nodes using a multi-hop communication

architecture. So each node dissipates a small amount of energy rather than a single node

dissipating large amount of energy to transmit data over large range. The inverse-square

law and the spread of signal intensity over distance is illustrated in Fig 1.4.


Figure 1.3: Inverse Square Law [2]

1.5.2 Energy Model

A sensor node consumes energy for three main functions [45]: acquisition, data commu-

nication and data processing.

1. Acquisition: The amount of energy consumed for data acquisition or sensing is

negligible compared to the energy consumed for data processing or communication.

However, the amount of energy consumed for sensing data depends on the type of

parameter being sensed and the frequency of sensing the data.

2. Data Communication: This includes the energy consumed for transmitting data

as well as for receiving messages. Most of the energy of a sensor node is con-

sumed by radio communication than any other task specially in case of long range

communications.

3. Data Processing: The amount of energy consumed for processing the data is very

less as compared to the energy consumed for communication of data over a long

range. eg. “The energy needed to transmit 1 KB over a 100 m distance is approx-

imately equivalent to the energy necessary to carry out 3 million instructions at a


Figure 1.4: Inverse Square Law [3]

speed of 100 million instructions per second (MIPS)” [45]. The energy consumed

for a certain operation however might vary based on the underlying hardware and

the instruction set.

Heinzelman et al. [4] proposed an energy model for the sensor nodes in a net-

work where the base station is fixed and all the other nodes of the network are

energy constrained. A low power consumption radio has been considered in this

model which was slightly better than a few other standards like the bluetooth. In

this model, they considered the following radio characteristics:

Table 1.1: Radio Characteristics

Operation Energy Dissipated

Transmitter Electronics (ETx−elec)Receiver Electronics (ERx−elec) 50 nJ/bit(ETx−elec = ERx−elec = Eelec)Transmitter Amplifier (�amp) 100 pJ/bit/m2

where (�amp) is the power required for the transmit amplifier to reach an

acceptable signal to noise ratio Eb/Na. Apart from the above parameters, an r2

energy loss is also assumed due to channel transmission. So to transmit a k -bit


long message over a distance d using this radio model, the radio consumes:

ETx(k, d) = ETx−elec(k) + ETx−amp(k, d)

ETx(k, d) = Eelec ∗ k + �amp ∗ k ∗ d2 (1)

and the energy consumed by the radio to recieve a k -bit long message is:

ERx(k) = ERx−elec(k)

ERx(k) = Eelec ∗ k (2)

Hence as we can see, the energy expended to transmit data over a wireless radio

is directly proportional to d2 where d is the distance over which the packets are

transmitted.

Figure 1.5: First Order Radio Model [4]


1.5.3 Radio Model

A sensor node can have two different types of antennas: omni-directional or direc-

tional [46] [47]. An omni-directional antenna transmits a signal with equal strength

over 360�angle so any node which lies within it’s radius r can receive the signal. A

directional antenna however has a beam of width α and can be aimed at a particular

direction. So a sensor node with directional antennas of beam α should have at least

�2π/α� antennas to cover a 360�angle. However all the antennas do not need to be ac-

tivated at a time but depending on the location of the target node, the corresponding

antenna can be activated.

To detect and interpret a received message properly, the message must be trans-

mitted/received with sufficient strength. As discussed in previous section, the signal

attenuates with distance in the transmission medium and one of the major causes for

signal dissipation is free space loss. So for an ideal isotropic antenna, the free space loss is

equal to(4πd)2

λ2 where λ is wavelength of the signal and d is the distance to be traveled.

As stated by inverse square law, energy required by the antenna for the message to reach

all the other nodes within a given radius r is proportional to the area it has to cover.

Hence for radius r, an omni-directional antenna [46] will consume power proportional to

πr2 while for a directional antenna with a beam of α radians, the energy consumed will

be proportional to α2 r

2.

1.5.4 Energy Consumption

We will now calculate the amount of energy consumed during wireless communication

and do a comparative analysis of the amount of energy consumed for different radio

ranges for a mote. For illustrative purposes, TelosB motes have been used to do the

analysis. A TelosB [48] mote has a CC2420 [49] radio by default and Zigbee [1] is the

default wireless communication protocol. For the CC2420 radio at 2.4 Ghz, the PHY

layer [50] of 802.15.4 specifies a baud rate of 250 Kbps.


Figure 1.6: Zigbee Frame Structure

802.15.4 PHY layer has maximum packet size of 127 bytes including the payload

where the maximum payload size is 100 bytes in case of Xbee series 1 while the Xbee

Series 2 modules have larger header size thus allowing a maximum of 72 bytes of payload.

Fig. 1.6 shows the generic packet structure of a zigbee frame which is a communication

standard in 802.15.4. In case of WBANs, as the number of nodes are less, 16-bit address-

ing format is commonly used thus reducing the header size of a Xbee series 1 packet to

13 bytes.

The sensor nodes like TelosB which make use of radio like CC2420 have prede-

fined radio levels which can be fixed when deploying the nodes or it can be changed in

the program based on the needs of application. The different radio output levels and

along with its output power (in dBm) given in the CC2420 datasheet [49] can be seen

in Table 1.2 where the first column gives the value of the power level to be set for the

radio, second column gives the corresponding register value, third and fourth columns

give the output power value and the current consumption respectively.

As the above table gives us the power consumed by the radio in dBm, we can

easily convert the value to watts using the formula:

P(W ) = 10((P(dBm)−30)/10) (3)

After we have the power consumed in watts, we can easily and calculate the energy

consumed in terms of joules using the following formula:


Table 1.2: Output power settings and typical current consumption (2.45 GHz) [49]PA LEVEL TXCTRL register Output Power Current Consumption

(dBm) (mA)31 0xA0FF 0 17.427 0xA0FB -1 16.523 0xA0F7 -3 15.219 0xA0F3 -5 13.915 0xA0EF -7 12.511 0xA0EB -10 11.27 0xA0E7 -15 9.93 0xA0E3 -25 8.5

E(J) = P(W ) ∗ t(s)

or,

joules = watts * seconds

So for the different power levels, the power consumed by radio (in mW) is summarized

in table 1.3 and Fig 1.7 shows the increase in power consumed (in mW) as the radio range

increases. Here the radio range varies from a few centimeters for output power level 3

and it goes up to a range of 1 meter for output level 31. This is the communication range

supported by the in-built radio the mote and for applications which need larger radio

range, an external radio antenna need to be connected to the node to further increase

its range to a few meters to 100 meters or more.

Table 1.3: Output power settings and typical current consumption (2.45 GHz)PA LEVEL Output Power (dBm) Power (mW)31 0 127 -1 0.79423 -3 0.50119 -5 0.31615 -7 0.19911 -10 0.17 -15 0.03163 -25 0.00316


Figure 1.7: Power consumed by Radio (in watts)

As can be seen in Fig 1.7, the power consumed increases exponentially with

increasing radio range and the amount of energy consumed by radio will be much higher

as compared to the data processing at larger radio ranges. Also Meulenaer et al. [7]

have summarized the properties of the hardware radio CC2420 and given the energy

consumed by the radio in terms of Joules. The details can be seen in Table 1.4

Now, as shown by Salama et al. [51], AES consumes 4.2 µJ per byte of encryption

while energy consumed to transmit one byte of data varies from 0.816 µJ per byte to

1.66 µJ per byte depending on the the power level set for the radio. So for a block of

16 bytes of data, encryption takes around 4.2 * 16 = 67.2 µJ while sending a packet

with 16 bytes payload and 13 bytes of header will take (13 + 16) * 1.66 = 48.14 µJ at

the highest radio power level (31). Hence it it is observed that when the communication

range is very small (≤ 1 m), the encryption consumes a significant amount of energy.


Figure 1.8: WSN Applications and Radio distance

The radio signals decay according to the inverse square law which states that the

intensity of the signal at a particular point is inversely proportional to the square of its

distance from the source of the signal i.e. Intensity ∝ 1/r2 . The energy model also

shows that the energy expended to transmit data over a wireless radio is directly pro-

portional to d2 where d is the distance over which the packets are transmitted. Hence

the amount of energy required by the antenna for the message to reach all the other

nodes within a given radius r is proportional to the area it has to cover. It it is observed

that when the communication range is very small (≤1 m), the encryption consumes a

significant amount of energy but with inreasing distance, the energy consumed by com-

putation becomes negligible. range WSN applications which operate within a distance

of 3 meters.

As encryption alone consumes a significant amount of energy in short-range appli-

cations like WBANs, designing a lightweight cipher for such applications will significantly


Radio Bandwidth Power Level Power Level(min) (max)

CC2420 250 Kbps -25 dBm 0 dBm

Steps Transmit energy/bit Transmit energy/bit Max outdoor range(min) (max)

31 102 nJ/bit 208 nJ/bit 80 m

Table 1.4: Spectrum of Radio Hardware CC2420 [7]

increase the lifetime of a sensor node. Fig 1.8 shows the various applications of WSN

and the average radio range of the nodes in the networks. The focus of this thesis is to

analyze the energy consumption of existing block ciphers and to design a new lightweight

block cipher that will consume less energy hence increasing the lifetime of a node. This

work is applicable to the WSN applications like WPAN and WBAN which work in the

range of less than 3 meters.

1.6 Organization of this thesis

In the next chapter, the security model of the WBAN including the security require-

ments of a WBAN, security assumptions for nodes and the adversary model are pre-

sented. Chapter 3 then covers the survey of various simulation tools and the 14 different

symmetric block ciphers that have been implemented for MICAz platform (TinyOS oper-

ating system) and have been compared based on their memory requirements and energy

consumption. In addition, a new metric called MSEC has been introduced to quantify

the security v/s energy consumption trade-off for the ciphers. Chapter 4 then introduces

the various hardwares and operating systems that are commonly used for WSNs. Apart

from that, the energy consumption results of the same suite of ciphers on TelosB platform

along with their MSEC value has also been presented in Chapter 4. We then discuss

the details of the proposed lightweight cipher in chapter 5 along with the motivation

for design, implementation details and experimental results. Chapter 6 summarizes the

contributions and present suggestions for future work.

Chapter 2

Security and Adversary Models for

WBANs

2.1 Network Model

A WBAN [52] consists of multiple miniature devices equipped with sensors and/or ac-

tuators that are located on or inside the body. The sensors measure various parameters

such as the temperature, heart rate, blood pressure etc. Each node within a WBAN

has a unique ID which can be used for authentication purpose. The nodes have limited

energy, memory and computation resources. These sensor nodes also have a radio inter-

face to communicate wirelessly with a special node called the the base station which is

generally PDA or a smart phone.

Figure 2.1: Network model of WBANs

18

Chapter 2. Security and Adversary Models for WBANs 19

As the range of a WBAN is limited to the size of a body, we assume that all the

nodes are in the network range all the time and the network structure does not change

dynamically. As we can see in the figure 2.1, all the sensor nodes are assumed to be at

the same level and all of them can directly communicate with the base station without

need of an intermediate node (single hop communication). Hence,a WBAN has a star

topology where the base station acts as the hub node. Also new nodes are added to the

network only when needed and there are no redundant nodes in a WBAN so the nodes

need to be robust.

All the sensors on the body periodically collect medical data and forward it to the

base station which in turn can process and analyse the collected data. The base station

for each WBAN and hence for each patient is unique and acts as the gateway between

the WBAN and the external network. The external network is mostly a remote server

where an authorized medical personnel can read or analyze patient data. In most cases,

the communication between the base station and the remote sever happens wirelessly

over the Internet.

2.1.1 Properties of nodes

The most significant properties of a WBAN node can be summarized as follows:

Operating space In or around the body. Typically has a range of up to 3 meters (1.5

meters radius).

Network Size The number of nodes in the network is restricted to typically less than

64 devices per WBAN.

Data rate Depending on the sensor type, data rate might vary from sub-kbps to up to

10 Mbps

Target lifetime A sensor device worn on body is expected to run for around a week

on a single charge while the implants are expected to have a much longer lifetime

of up to a few years.


Topology Mostly star topology with the PDA acting as the hub node.

Peak power consumption The power consumption varies largely with as less as 0.1mW

in standby mode while up to 30mW when fully operational.

Device duty cycle Duty cycle in the WBAN nodes is adaptive and varies from around

0.001% upto 100% depending on whether it is in sleep mode or active mode.

Few common sensor node types in a WBAN along with it’s properties like data rate,

accepted range of latency etc are summarized below in Table 2.1

Application Target Data Rate Latency BER (bit error rate)Drug delivery < 16Kbps < 250 ms < 10−10

Deep brain stimulation < 320 Kbps < 250 ms < 10−10

Capsule Endoscope > 1 Mbps < 10−10

ECG 192 Kbps < 250 ms < 10−10

EEG 86.4 Kbps < 250 ms < 10−10

EMG 1536 Kbps < 250 ms < 10−10

Glucose level monitor 1 Kbps < 250 ms < 10−10

Audio 1 Mbps < 20 ms < 10−5

Video/medical imaging < 20 Mbps < 100 ms < 10−3

Voice 50 - 100 Kbps per flow < 10 ms < 10−3

Table 2.1: WBAN Sensors and their properties [8]

2.2 Security Requirements of WBAN

Based on the type of application and the criticality of the data that is being dealt with,

a network can have different security requirements. e.g. an application might not be

worried about keeping the data secret but can only be concerned about the correctness

of the data that is being received by the other devices. In this section, various security

requirements in a WBAN and their solutions will be briefly discussed.

2.2.1 Data Confidentiality

As the data being dealt with is private to a patient, one of the security requirements

is to ensure that even if the adversary captures the packets by eavesdropping, he/she


should not be able to disclose the data. This can be achieved by encrypting the data

with a secret key before transmission.

2.2.2 Data Authentication

It is essential to verify that the data received by the base station is sent by the actual

sensor node and not by an adversary i.e. authenticity of the packet source has to be

ensured. Data authentication [33] can be achieved in WBANs by making use of Message

Authentication Code (MAC) in all the packets which are being transmitted so that the

receiver knows packet has originated from a trusted source.

2.2.3 Data Integrity

An adversary can alter a patient’s data when it is being transmitted over an insecure

channel. It can be very dangerous specially in life-critical matters if an altered packet is

being accepted by the base station or the remote server. Therefore proper data integrity

solutions [53] [54] [55] should be incorporated as a part of the security framework so that

the tampered data packets can be detected at the receiving end.

2.2.4 Data Freshness

One of the most common attacks which is carried out by an adversary is a replay arrack

where he stores the captured packets and later replays them. Data freshness ensures

that the packets being received is fresh and not reused. Data freshness is mostly ensured

by making use of a nonce or a time-stamp in the packets.

2.2.5 Availability

Availability ensures that a patient’s information is always available to the medical per-

sonnel. However availability can be targetted in WBAN by an adversary by either

physically capturing a node or jamming the network or draining out the power of the


node by flooding it with false packets. This can be an issue as lack of updated health

data might even result to loss of life.

The various attacks which can be carried out by an adversary to compromise the

above mentioned security requirements along with their possible security solutions have

been summarized below in Table 2.2

Security Threats Security Requirements Possible Security SolutionsUnauthenticated or Key establishment and trust setup - Random key distributionunauthorized access - Public key cryptographyMessage disclosure Confidentiality and privacy - Link/network layer encryption

- Access controlMessage modification Integrity and authenticity - Keyed secure hash function

- Digital signatureDenial-of-service (DoS) Availability - Intrusion detection

- RedundancyNode capture and Resilience to node compromise - Inconsistency detection andcompromised node node revocation

- Tamper-proofingRouting attacks Secure routing - Secure routing protocolsIntrusion and high-level Secure group management, - Secure group communicationsecurity attacks Intrusion detection, - Intrusion detection

Secure data aggregation

Table 2.2: WBAN Security threats and solutions [9]

2.3 Security Assumptions

The most critical device in this architecture is the back-end server [56] which is managed

by the hospital or the medical center and it periodically recieves raw or processed data

from all the active WBAN base stations. It is assumed that the back-end servers are

physically protected and has proper authenication and access control mechanism so that

only authorized people can access the patient data. The back-end server thus acts as a

trusted third party so once authenticated, all the devices in the network trust it.

Also there needs to be a secure end-to-end communication between the base stations

and the external servers hence the communication needs to be encrypted and measures

should be taken to ensure data integrity and authentication. There are various key

establishment protocols [57] [58] [59] which can be used for establishing a shared key


between different entities of a WBAN for a secured communication. However, as key

establishment protocol is out of scope of this thesis, for efficiency reasons, it is assumed

that the symmetric key is pre-established between the between the devices and can be

renewed [60] [61] [62] regularly using any of the existing algorithms. Also for authentica-

tion purposes, the each base station belonging to a WBAN is registered at the back-end

server. The area of focus in this thesis is the node to base station communication than

the base station to end server communication.

Each nodes in the network has a unique ID [52] [63] which is known only to that

particular node and the base station. The node ID is manually programmed into the

node before being deployed into a network and an entry is manually added to the base

station when a new node is added to the network. As the network is not dynamic in

structure, whenever a new node is added to the network, the secret key between the node

and the base station is programmed before deployment. All the nodes in a WBAN have

a unique secret key and a new node introduced into the network later will not have a key

same as any of the other nodes in the WBAN. Also, if a device is being replaced due to

power drain or any other issue, it is assumed to have a key different than the previous

node and the entry has to be manually updated in the base station. Also the nodes are

assumed to be tamper-proof hence the memory will be flushed if any attempts are made

to physically tamper the node to retrieve the key or data. An adversary can however

try to corrupt the software of the node which can be detected using intrusion detection

system(IDS) [64] [65] [66].

2.4 Adversary Model for WBAN

To understand the security requirements of the WBAN, we need to first understand the

adversary model in WBAN including his/her capabilities and computation power. A

brief description of the same has been covered in this section.


2.4.1 Types of adversary

An adversary in the WBAN can be categorized as the following [67]:

1. An adversary can be an active or a passive entity. A passive attacker can eavesdrop

on the communication channel or can carry out side-channel attacks. An active

adversary on the other hand is able to read, tamper or inject false messages into

the network.

2. An adversary can be an internal or an external entity with respect to the system.

3. The adversary can be a single entity or a coordinated group of entities

4. The adversary can be sophisticated, with specialized equipments or unsophisticated

with people who are not experts of the field and hence depend on the commercially

available equipments.

2.4.2 Adversary target

An adversary might be trying to target [67] one of the following:

1. The patient: An adversary might be an individual who want to obtain private data

about the patients including health data, location data or blackmail-worthy data.

An adversary might also try to cause a physical harm to the patient, especially in

case of networks with actuator nodes.

2. Device manufacturer : The adversary might want to engage in some company es-

pionage or fraud.

3. System resources : The adversary might want to utilize system resources of the

node like the CPU power and wrongly compromise a WBAN network.

4. Insurance companies: The adversary in this case might be a user who wants to

tamper the medical data in order to get money from the insurance companies.


2.4.3 Capabilities of an adversary

As the communications among the nodes in a WBAN occurs wirelessly, we assume

that the adversary can observe all the (encrypted) messages all the time. Also, the

adversary can easily eavesdrop or inject false packets into the network using a simple

radio transmitter/receiver. Following are the capabilities of an adversary [68], [69] :

� Compromise a sensor node.

� Alter the data integrity.

� Passively listen to messages and store them for replaying later.

� Inject fake messages into the network.

� Exhaust resources like power by continuously sending fake messages to the nodes.

� Destroying the packets carrying information of high importance.

� Breach the location privacy of a user/node.

� Target availability by capturing or disabling a node.

� Physically tampering the device. However in case of WBANs, as the nodes are

worn on or inside the body, an outsider will not be able to physically tamper the

device. Hence this attack is mostly carried out by the user/wearer of the device.

2.4.4 Available resources

It does not make any sense to even attempt to design security protocols against an

all-powerful adversary [70]. Hence in this section, we will be discussing the realistic

computational power of a WBAN adversary. The main classes of resource [71] to be

considered are: funding, equipment, expert knowledge and time. Hence the adversaries

can broadly be classified into three categories: clever outsiders, knowledgeable insiders

and funded organizations.

The commodity sensors are mostly targeted by the clever outsiders who are trying


out different things or by the knowledgeable insiders if there is a gain from the attack.

Let us assume that an adversary has a system with 3.6 GHz processor, it means he has

a computational power equivalent to 3.2 * 109 clock cycles per second. As shown by

Schneier et. al. [72] in 1999, encrypting a block of data on a Pentium took an aver-

age of 145 clock cycles per byte with Rijndael taking 59 clock cycles per byte. A few

benchmark results were published by Crypto++ [73], [74], [75] for most commonly used

ciphers. The programs were optimized for speed and the tests were run on an Intel Core

2 1.83 GHz processor under Windows Vista in 32-bit mode , Intel Pentium 4 (Prescott)

CPU and on an AMD Opteron 8354 2.2 GHz processor under Linux. As shown, AES in

counter(CTR) mode gives a throughput of 139 MBps, 132 MBps and 198 MBps on the

three different platforms taking an average of 12.6, 21.2 and 10.6 clock cycles per byte

of data. Hence assuming the best case for the adversary, we will assume a throughput

of approx 200 MBps (10 clock cycles per byte of encryption) for further calculations.

Clever outsiders Assuming that the effective lifetime of a health related data is around

100 years and say, an encryption algorithm takes 10.6 clock cycles [75], then one

system with 1.8 GHz processor can carry out (1.8 * 109)/(10 * 16) = 11.25 * 106

data block encryptions per second. Hence the number of encryption operations

that can be carried out in 100 years using 10 systems is 12.5 * 106 * 60 * 60 * 24

* 365 * 100 * 10 = 3.547 * 1016 i.e. 251.65 operations. Hence using only brute-force

attack, an effective key length of 52 bits should be enough to protect the data from

first class of adversary i.e. clever outsiders(single entity).

Knowledgeable insiders Similarly, if the adversary is a knowledgeable insider who can

say, use 10% CPU on 1000 machines, each with say 1.8 GHz processors each and

taking an average of 10 cycles per byte of encryption, then one system can carry

out (1.8 * 109)/(10 * 16) = 11.25 * 106 data block encryptions per second. Hence

using 100 systems for 100 years, a total of 7.0956 * 1016 i.e. 254.97 operations can be

done approximately. This implies that using only brute-force, an effective length

of 55 bits should be enough to protect the data from second class of adversary i.e.


knowledgeable insiders.

Funded organizations Now we will consider the last group of adversary which is the

strongest in terms of computational power i.e. funded organizations. Let us assume

that the funded organization spends around USD 10000 to retrieve information

about a person which enables him to buy say 100 6-core processors, each with a

computational power of 3.4 GHz. So taking an average of 10 cycles per byte of

encryption, then a single core can carry out (3.4 * 109)/(10 * 16) = 21.25 * 106

data block encryptions per second. So using 600 cores in parallel, it can check 67.5

* 108 keys per second. So with the given computational power, the adversary can

check a total of 67.5 * 108 * 60 * 60 * 24 * 365 * 100 = 264.20 different keys. This

implies that using only brute-force, an effective length of 65 bits should be enough

to protect the data from third class of adversary i.e. funded organizations.

The adversary models that have been described in the thesis are contemporary and

cover all the attacks and threats that have been reported against the well known WSN

applications. However it must be noted that with passage of time, due to newer innova-

tions in cryptanalytic methods and enhanced computer resources available as depicted by

Moore’s law, we can calculate using Lenstra’s formula[76] that the decrypting capabilities

improve by 7 bits per decade.

2.5 Recommended key length

Key length is one of the critical parameters that determines the security level of a cipher.

It defines an upper bound for the effort required in exhaustive key search. If the key is

recovered by an adversary, then all security of the communications will be compromised.

The security level [76] of a cipher is defined in terms of a known plaintext attack i.e. if

an adversary has a pair of plaintext and it’s corresponding ciphertext, what is the effort

to recover the key. For a γ-bit key, if the key recovery cannot be done in less effort than

exhaustive key search, then the cipher is said to have a security level of γ. Hence the

exhaustive key search for γ bit keys will have to search through an average of 2γ-1 keys


with the worst case scenario of searching up to 2γ keys.

As shown by Lenstra [76], given a cipher with security level γ, taking into account

the Moore’s law [77] which says that the computation power doubles every 18 months,

the year y(γ) till which the cipher will provide adequate protection is calculated as:

y(γ) = 1982 +3(γ − 56)

2(2.1)

Here we assume that the speed of the cipher being evaluated is same as DES. Using the

above equation, we can see that for a block cipher with security level γ ≥ 128, we get

an estimate of y(128) = 2090 i.e. a key length of 128 bits should be able to protect our

data approximately for next 75 to 80 years.

Similarly, given an year y, if we want to calculate the requited security strength γ,

it is given by

γ(y) = 56 +2(y − 1982)

3(2.2)

Hence if we want our data to be secure for next 100 years, say till year 2115, we get

γ(2115) = 144.66 ≈ 145. Similarly, with increasing effective lifespan of our data, we can

calculate the effective key length required to keep the data secure.

2.6 Discussion

As we have seen in this chapter, only 65 bits long key is enough to protect our data from

an adversary with limited computational power against brute-force attack. However,

many algorithms are susceptible to other attacks like the linear cryptanalysis [78], dif-

ferential cryptanalysis [79], algebraic attacks [80] [81], impossible differential attacks [82]

etc. which exploit the mathematical weakness of the algorithm and can drastically bring

down the effective key-length of the algorithm. Hence as recommended by NIST [83] [84],

most algorithms should have a key length of at least 128-bits in order to protect the data

for next 100 years.

Chapter 3

Survey of Simulation Tools for WSN

and Block Ciphers

As WSN is emerging as one of the most active area for network research, many different

protocols and applications are being developed and need to be tested properly before they

can be deployed. So to reduce the development cost and deployment time of a project,

most works are being simulated before implementing them on actual hardwares. In the

first part of the chapter, we review a few simulation tools and discuss their advantages

and disadvantages. The various aspects of the simulation tools [85] [86] that will be

reviewed include ease of coding, platforms supported, energy modeling support and GUI

support to visualize the simulations.

3.1 Survey of Simulation Tools

A few of the most common publicly available simulation tools are being reviewed in this

section.

3.1.1 NS-2

NS-2 [87] [88] stands for network simulator version 2 which was first developed in 1989.

It is a discrete-event simulator where the programs are written in C++ and interfacing at

29

Chapter 3. Survey of Simulation Tools for WSN and Block Ciphers 30

front-end is done using a scripting language called TCL [89]. NS-2 is actively maintained

and there is ongoing work to develop NS-3 [90]. It is open source and can be used for

simulation of both wired and wireless networks.

Advantages and Disadvantages

One of the advantages of NS-2 is that being a non-specific simulator, it can support a

wide range of protocols at different levels. Also it supports 802.11 and 801.15.4 wireless

MAC [91] for mobile sensor networks and simple energy model [92] is supported.

This simulator however also has some limitations. First, precise timing simula-

tion is not supported by NS-2 although we can add timing model to the simulation.

Also the simulator supports only simple mobility models [93] for the nodes and external

applications need to be imported in our project for more complex mobility. Another

disadvantage is that the graphic interface NAM (Network AniMator) does not provide

much flexibility to interact with the program. A sample screenshot of NAM can be seen

in Fig. 3.1.1

Also as NS-2 was targeted to generic IP networks and not WSNs, there are some

limitations when we simulate WSN applications on NS-2. Firstly, the layers that is in-

cluded in NS-2 model is not really present in the WSNs hence NS-2 might not give us the

correct results. Secondly, NS-2 cannot simulate the inherent properties of WSNs like the

bandwidth, power consumption or low-energy models. Thirdly, NS-2 does not support

scalability of the network to the range at which WSNs work. i.e. NS-2 cannot support

more than 100 nodes at a time while WSNs work with thousands of nodes. Also, NS-2

cannot simulate a network which is a hybrid of wired and wireless components. Hence,

NS-2 might not be the best option to work with if we want to simulate a typical WSN

scenario.


Figure 3.1: NS2 Graphical interface: NAM

3.1.2 TOSSIM

TOSSIM (TinyOS SIMulator) [94] [95] is a simulator specially built for TinyOS, an open

source operating system developed for embedded networks. It was first developed by

Berkley’s project team in 2003. It is built using C++ and Python and was mainly built

for the Mica2 platform but works well for MICAz [96] as well. TOSSIM is an emulator

rather than a simulator as it runs the actual code that can be directly transferred to

the hardware platform. It also provides an emulated radio model and the programs on

TOSSIM can be run directly on the command line in unix-based environments or using

cygwin for windows environment.


One of the main merits of TOSSIM is that it is open-source and has detailed documenta-

tion available online. Also it supports a GUI module called TinyViz [97] which provides


the user with various options to interact with the program. Also it can simulate networks

scaled to a range of thousands of nodes and accurately simulates the mote’s hardware

including the I/O, ADC and the sensors. In addition, it has an extension called Power-

TOSSIM [98] for energy consumption modeling.

However this emulator also has a few disadvantages. First, TOSSIM can run only

the codes written in nesC, and event-driven component-based language which is imple-

mented on TinyOS. Second, as TOSSIM is designed to simulate only the codes that have

been written on TinyOS, it cannot be used to simulate nodes with any other operating

systems. Third, as TOSSIM is specifically designed for WSN simulation, it cannot be

used to simulate generic computer networks. Also, as TOSSIM has a probabilistic bit

error model for the wireless networks, it cannot be used to efficiently evaluate the low-

level protocols. So as we can see, TOSSIM has both advantages and disadvantages to be

used for WSN simulation.

3.1.3 OMNet++

The Objective Module Network Test-bed in C++ (OMNeT++) [99] [100] is an open

architecture, component based simulation environment built in C++. It provides a non-

commercial license [101] for use at academic institutions or for non-profit organizations

as well as a commercial license for “profit” organizations. It can run easily on Unix and

windows systems and can be used for simulating both wired as well as wireless scenarios.

It also provides a hierarchal nested architecture and has a GUI module created using the

Tk library.


OMNeT++ has many advantages including a powerful GUI module that provides fea-

tures for tracing and easy debugging. It has a Mobility framework [102] [103] that allows

the nodes to communicate via packets and supports features like node mobility, dynamic

connection management and wireless channel model. It also supports monitoring of

power consumed.


One of the major drawback of OMNeT++ however is the lack of inbuilt protocol

library. Also though many protocols are being developed for WSN using OMNeT++ and

codes for many of the projects are freely available online, most of the available models

have been developed by various independent groups hence they do not share a com-

mon interface. This might lead to compatibility issues when trying to integrate various

models.

3.1.4 Avrora

Avrora [104], [105] [106] is an open-source cycle-accurate simulator for sensor programs

and networks and its latest version is written in Java. It was developed by University

of California, Los Angeles Compilers group and it can typically emulate two platforms,

Mica2 and MicaZ. This simulator is also open source and has online documentation

available online.


One of the major advantages of Avrora is that can scale to networks of up to 10,000

nodes, handling as many as 25 nodes in real-time. It also has several monitors that lets

us track the program as it progresses and get summary of parameters such as energy

consumption by various components, packet monitoring, CPU cycles etc. Also, as Avrora

runs the code instruction by instruction, it provides better speed and scalability.

However the biggest demerit of this simulator is that it does not support GUI.

Also it does not provide any network communication tools and hence cannot be used for

simulating network management algorithms.

3.1.5 OPNET

OPNET [107] [108] is a commercial network simulator by Opnet Technologies, however

a free academic license is also available. It is an object oriented, general purpose net-

work simulator based on the hierarchal model and was introduced in 1987 as the first


commercial network simulator. It was originally built for fixed networks but has been

later updated with modules to support wireless communication and is based on C++.

It also has a detailed manual and provides a good online tutorial.


One of the strengths of OPNET is it’s accurate radio propagation modeling where various

characteristics of the transceivers and antennas are modeled [109] in detail. It provides

support for CCIR, Free Space, Hata, TIREM etc for modeling the radio propagation.

OPNET also has various specialized modules [110] [111] [112] like Wireless, UMTs and

mobility management modules like random waypoint, arbitrary trajectories etc. Also

it has graphical support and can model 3D [113] outdoor scenarios taking into account

various obstacles like the buildings and terrains.

One of the major drawback of OPNET is that it does not support energy models

directly. Also as it’s kernel is not open source, external tools are not supported.

Choice of Simulation tool

As can be seen in the above section, most of the simulators explored in this work support

simulation of wireless networks and can also be used for simulating low level protocols.

The simulation of protocols for WBAN do not need complex mobility framework as the

position of the nodes is relatively fixed. Also the number of nodes in a WBAN is very

less. However, as the focus of this thesis is on energy requirement of block ciphers in a

WBAN, the simulation tool needed for analyzing the investigated ciphers must support

energy profiling of the nodes.

Based on these requirements, NS-2 cannot be a suitable choice as it does not

support simulation of lower layer protocols. Also OPNET does not support energy

models while TOSSIM has an extension called PowerTOSSIM for energy tracing but it

has some compatibility issues with TinyOS 2.x. OMNeT++ on the other hand can be

taken as one of the suitable candidates for simulating WBAN but as most projects of

OMNeT++ are developed independently, there might be some compatibility issues in


developing applications which need modules developed by different groups.

Based on the above observations, AVRORA was used to simulate all the programs

for MICAz platform as it is highly scalable, can support up to 25 nodes in real time and

supports energy profiling. The energy monitor of AVRORA gives a summary of total

CPU cycles consumed and a detailed report of energy consumption including the total

energy consumed and energy consumed by various components of the mote like LEDs,

CPU, flash memory, radio etc.

3.2 Survey of Block Ciphers

In spite of the large number of works being done in the field of security in WBAN, there

are a very few available literature providing a proper evaluation framework to compare

the existing protocols based on their energy needs. Cazorla et al. [114] has done a study

of 17 different block ciphers including 12 lightweight block ciphers and have compared

the memory requirements and energy consumption in terms of CPU cycles required.

However, there is no restriction on memory usage with a few algorithms taking up to

17K ROM. Another comparative study published by Law et al. [115] has analyzed 8

block ciphers and presented benchmark results on memory requirement and CPU cycles

required in different modes of operation including CBC, CFB, OFB and CTR. Also,

Hager et al. [116] have concluded that if the power consumed by various operations are

same, then the energy consumed in terms of joules is proportional to the time needed.

In these papers, CPU cycle count has been taken as the parameter for evaluating the

energy efficiency.

This thesis analyses and sums up the various investigated ciphers for their energy

consumption, attack effort needed to break them and their memory requirement. Most of

the motes these days support at least 4K RAM and ROM. Hence, a compact implemen-

tation of all the investigated ciphers has been done which require utmost 4K RAM and

4K ROM thus reducing the concern for limited memory availability. The other major

concern in WSN is energy efficiency which has mostly been calculated in terms of CPU


cycles. However, as can be seen from Table 2 of [117], the energy consumed may not be

proportional to the no. of CPU cycles due to different amount of energy consumed by

various operations and subsystems, which again is dependent on the underlying archi-

tecture. Hence, in this thesis, energy efficiency of various ciphers is being evaluated in

terms of joules which gives us a better estimate of energy consumption.

A total of 14 different block ciphers are being investigated among which 11 are

lightweight block ciphers while only 3 are conventional block ciphers. Details of various

parameters (key length, block size, number of rounds) of the investigated ciphers are

presented in Table 3.1.

Table 3.1 shows that the major difference between the lightweight block ciphers and

the conventional ciphers is in their block size and key length. As opposed the conven-

tional ciphers which mostly have 128 bit key, many of the lightweight ciphers provide a

choice of key length varying between 64, 80, 96 or 128 bits depending on security needs.

Similarly, most of the lightweight ciphers have a block size of 64 bits as compared to the

conventional block ciphers which mostly have 128 bit blocks.

In rest of this section, all the algorithms under investigation have been briefly de-

scribed along with the various attacks against them and they have been summarized

in Table 3.2. based on their common operations and best cryptanalytic attacks against

them.

Table 3.1: Summary of Investigated Block CiphersAlgorithm Block Size Key Length # Rounds Structure

AES-128 [41] 128 128 10 SPNDESXL [118] 64 184 16 FeistelHIGHT [119] 64 128 32 FeistelIDEA [42] 64 128 8.5 Lai-MasseyKLEIN [120] 64 64, 80, 96 12, 16, 20 SPNLBLOCK [121] 64 80 32 FeistelLED [122] 64 64, 128 32, 48 SPNmCrypton [123] 64 64, 96, 128 12 SPNPiccolo [124] 64 80, 128 25, 31 FeistelPRESENT [125] 64 80, 128 31 SPNTEA [126] 64 128 Var FeistelXTEA [127] 64 128 Var FeistelSEA [128] 96 96, ... Var Feistel


3.2.1 AES-128

The AES [41] is a block cipher chosen as a standard by NIST in 2000. Based on Rijndael

cipher, it was submitted by Joan Daemen and Vincent Rijmen, and is one of the most

common block cipher. Structurally, it is an SPN (Substitution-Permutation Network)

based cipher which can encrypt under key length of 128, 192 or 256 bits with 10, 12 or

14 iterations respectively.

Security: Till 2006, the best attack known for AES-128 was against its 7-round version

[129] and only side-channel attacks were known for the full version AES until May 2009.

The first key-recovery attack on full-version AES is biclique cryptanalysis [130] with a

complexity of 2126.1 which was published by Bogdanov et al. in 2011. Other interesting

attacks on AES are meet-in-the-middle attack [131] and an improved meet-in-the-middle

attack by Demirci et al. [132]

3.2.2 DESXL

DESL and DESXL [118] are the lightweight versions of DES (Data Encryption Standard)

proposed by Leander et al. DESL takes an input of 64 bits, a 56 bit key and iterates

through 16 rounds similar to DES but using a single S-box for all rounds instead of

using 8 S-boxes which brought down the gate complexity of the cipher. One of the main

weakness in DES was the linear property of S-boxes [78] which has been strengthened by

using a single more non-linear S-box 8 times hence also reducing the memory requirement.

DESX is a DES variant that takes 184 bit key and uses key whitening method to reinforce

security. We have chosen DESXL for the analysis in this work as it has best of both i.e.

DESX and DESL.

Security: There are a few papers which have studied the weakness in these DES variants.

Philip Rogaway [133] shows that the effective key length in DESX is 119 bits instead of

184 bits. Although no attacks have yet been exhibited against DESXL, like in DESX,


DESXL will have an effective key length of 119 bits. Hence the best attack against

DESXL is by brute-force with complexity of 2119.

3.2.3 HIGHT

HIGHT [119] is a hardware-oriented lightweight encryption protocol proposed by Hong

et al. and all its operations are 8-bit-processor-oriented . It takes a 64 bits block, 128

bits key, goes through 32 iterations and is based on generalized Feistel structure. Unlike

most conventional block ciphers, HIGHT consists mainly of simple operations like XOR,

addition mod 28, subtraction mod 28 and left bitwise rotation and has “on-the-fly” key

generation.

Security: One of the best known attack on full version of HIGHT is biclique cryptanal-

ysis [134] which needs 248 chosen plaintexts for the analysis and has a time complexity

of 2125.93. Another interesting attack presented by Chen et al. [135] is the impossible

differential attack on 27-rounds HIGHT which needs 2120 memory access and has a time

complexity of 2126.6. Jiqiang Lu. [136] also presents three different attacks on 25-, 26-

and 28-round version HIGHT.

3.2.4 IDEA

IDEA [42] is a conventional symmetric block cipher introduced in 1991 by James Massey

and Xuejia Lai and was intended to be the successor of DES. It takes a 64 bit input and

128 bits key and iterates through 8 identical transforms (round) followed by an output

transform (half round) thus having 8.5 rounds in total.

Security: Two of the most effective attacks, a linear attack on 5-round IDEA with a

time complexity of 2103 encryptions and a similar attack on 7.5 round IDEA with a time

complexity of 2115.1 encryptions, were proposed by Biham et al. [137]. However in 2012,

the full-version IDEA was broken using narrow biclique [138] so that the key could be


recovered with a complexity of 2126.1.

3.2.5 KLEIN

KLEIN [120] is a family of lightweight block ciphers proposed at RFIDSec 2011 which is

designed for resource-constrained devices such as sensors and RFID tags and is based on

SPN structure. It combines a 4-bit Sbox with Rijndael’s byte oriented MixColumn which

allows its compact implementation in both hardware and software. KLEIN operates on

64 bits input block and supports variable key lengths: 64, 80 or 96 bits with variable

number of rounds: 12, 16 or 20.

Security: One of the most effective attacks against the full-version KLEIN is the biclique

cryptanalysis [139] with a complexity of 262.84 for KLEIN-64 while Abed et al. [140]

proposed a biclique attack against KLEIN-80 and KLEIN-128 with a complexity 279.00

and 295.18 respectively. Another practical attack against 8-round KLEIN was proposed

by Aumasson et al. [141] which exploits the existence of differentials of unexpectedly

high probability.

3.2.6 LBLOCK

LBLOCK [121] is a lightweight encryption protocol proposed by Wenling Wu and Lei

Zhang which takes a 64-bit size block and an 80-bit key. The design of LBLOCK is

Feistel structure based, has 32 iterations and is 4-bit oriented which can be implemented

efficiently.

Security: Kakaro et al. [142] presented an Impossible Differential attack against 21-

round and 22-round version of LBLOCK with a complexity of 269.5 and 279.28 respectively.

On the other hand, biclique attack against LBLOCK has been explored mainly in two

papers. Kakaro et al. [143] have proposed biclique attack against reduced round versions

and full version LBLOCK with a complexity of 278.76. Wang et al. [144] presented a

biclique attack against full version LBLOCK with a complexity of 278.40 and also proposed


a new key scheduling algorithm for LBLOCK which would improve its diffusion property.

3.2.7 LED

The LED block cipher [122] was designed keeping hardware compaction and small silicon

footprint in mind. One of its key feature is its non-existent key-schedule: the user

provided key is used instead as it is. Based on AES-like design, it also uses S-boxes and

a variant of MixColumns and ShiftRows. It is designed to take fixed length 64 bit input

block with a choice of key length (and no of rounds) of 64 or 128 bits (32 or 48 rounds

respectively) and re-uses the S-box of PRESENT [125].

Security: One of the best attack against full version LED is the biclique cryptanalysis

presented by Abed et al. [140] which breaks LED-64 and LED-128 with a complexity

of 263.58 and 2127.42 respectively. Jeong et al. [145] also proposed a biclique attack on

29-rounds LED-64 and 45-round LED-128 with a computational complexity of 263.58 and

2127.45 respectively. Another interesting attack published by Isobe and Shibutani [146] is

a meet-in-the-middle attack on 8-round LED-64 and 16-round LED-128.

3.2.8 mCrypton

mCrypton [123] is a lighter version of the block cipher Crypton [147] designed specifically

for resource-constrained devices. It has 64 bit block size with flexibility for key length

(64, 96 and 128 bits). It is based on SPN structure and iterates for 32 rounds. The key

scheduling algorithm consists of 2 stages: round key generation using S-box transforma-

tion and key variable update using word-wise rotations and bitwise rotations within the

word.

Security: Jeong et al. [148] presented the first biclique attack against mCrypton-

64/96/128 with a computational complexity of 263.18, 294.81 and 2126.56 respectively. A

related-key impossible differential attack [149] was published in 2012 for mCrypton-96

and mCrypton-128 with time complexity of 274.9 and 266.7 respectively.


3.2.9 Piccolo

Piccolo [124] is a lightweight encryption protocol which takes 64 bits block, has a choice

of key lengths: 80 bits(25 rounds) and 128 bits(31 rounds) and is based on variant of

4-line type-II generalized Feistel network. The main feature in Piccolo’s round function

is its compact 4-bit S-boxes which takes only 4 NOT, 3 XOR and 1 XNOR gate i.e.

about 12 GE(Gate Equivalent) and it is one of the first block ciphers to have a hardware

implementation in less than 1000 gates.

Security: Most of the security concerns for Piccolo are related to biclique attacks. Jeong

et al. [145] presents a biclique attack against Piccolo 80/128 with a complexity of 279.13

and 2127.35 respectively. Another paper [134] also presents a biclique attack against full

version Piccolo-80/128 with a complexity of 279.34 and 2127.36 respectively while [150]

presents a biclique attack on full version Piccolo-80 and 28-round Piccolo-128 with a

complexity of 278.95 and 2126.79.

3.2.10 PRESENT

PRESENT [125] was proposed at CHES 2007 as a SPN structure based ultra-lightweight

cipher that iterates for 31 rounds. Like a few other lightweight ciphers, PRESENT also

has a block length of 64 bits while it provides a choice of key length: 80 bits and 128

bits. Each round consists of three steps: addRoundKey step which is a XOR operation,

sBox layer which uses a 4-bit Sbox 16 times in parallel in each round and pLayer, a linear

bitwise permutation step.

Security: A lot of cryptanalytic attention was given to PRESENT due to its linear bias.

Joo Yeon Cho [151] proposed a key recovery attack against 25-round PRESENT using

multi-dimensional linear cryptanalysis with a data complexity of 262.4. It also proposed

an advanced key search technique for 26-round PRESENT with data complexity of 264.

Other papers [152], [153], [154], [155] in the literature have also exploited the linear


bias in the cipher to propose various attacks. However, Biclique cryptanalysis [140]

has recently(in 2013) been proposed against full version PRESENT-80/128 with time

complexity of 279.49 and 2127.32 respectively.

3.2.11 TEA and XTEA

TEA(Tiny Encryption Algorithm) [126] is a lightweight block cipher designed by D.

Wheeler and N. Needham in 1994. However, due to a few weaknesses found in TEA [156],

it was replaced by XTEA [127]. It has a block size of 64 bits, 128 bit key, is based on

Feistel structure and has very simple F-function. The simplicity of the algorithm is

compensated by large no. of rounds(recommended 64).

Security: Many of the weaknesses of TEA were published by Kelsey et al. [156] along

with a related-key attack against TEA which requires only 223 chosen plaintexts and

one related query with a time complexity of 232. There has been quite a few papers

on cryptanalysis of XTEA of which a few attacks were published in 2012. Bogdanov

and Wang [157] identified zero correlation linear approximation for 14 and 15 rounds of

TEA and XTEA using which they designed key recovery attacks for 21-round TEA and

25-round XTEA. Also, a meet-in-the-middle attack [158] and an impossible differential

attack [159] against reduced XTEA was published in AfricaCrypt 2012.

3.2.12 SEA

SEAn,b [128] is a low cost encryption protocol designed specifically for hardware with

limited instruction set. Also the encryption protocol is scalable w.r.t. text size, key

length and processor word size. It is based on Feistel structure, does “on-the-fly” key

derivation and has variable no of rounds.

Security: No security attacks published against SEA except the weaknesses given in

the original paper.


Table 3.2: Summary of Lightweight Block Ciphers

Algorithm Common Operations Summary Of Attacks

AES-128 Byte substitution Biclique Cryptanalysis: 2126.2

Shift rows (transposition)

Mix columns

Add round key

DESXL Key whitening (XOR) No attacks published

HIGHT Addition mod 28 Biclique cryptanalysis: 2125.93

Subtraction mod 28 Related key attack: 2125.83

XOR

S-bit left rotate

IDEA Modular addition Narrow biclique: 2126.1

Modular multiplication

XOR

KLEIN Round transformation: Biclique on full version:

XOR, rotate bytes, Sbox KLEIN-64: 262.81

Key schedule: cyclic shifts, KLEIN-80: 279.00

swap, XOR KLEIN-96: 295.18

mCrypton S-box Biclique against full version

Bit permutation mCrypton-64: 263.18

Column to row transposition mCrypton-96: 294.81

Subkey addition mCrypton-128: 2126.56

PRESENT Subkey addition Biclique:

S-box layer 22 round PRESENT-80: 279.49

PRESENT-80(Full): 279.49

PRESENT-128(Full): 2127.32


Piccolo 4 bit Sbox Biclique on full version:

Byte permutation Piccolo-80: 279.13

Piccolo-128: 2127.35

LBLOCK Subkey Addition Biclique on full version: 278.7

8 S-boxes Impossible differential:

4 bits permutation 21/22 round: 269.5/279.28

LED No key schedule Biclique on full version:

LED-64: 263.58

LED-128 2127.25

TEA Addition, shifts, XOR 17 round TEA: 257 chosen plaintext

Related key attack: 232

SEA “on-the-fly” key derivation No security analysis published

XOR, 3-bit Sbox, rotations

addition mod 2b (b=word size)

XTEA Left & right shift; 23-round XTEA: MITM: 2117

XOR Impossible differential: 262.3

Additions Related-key differential attack(27 rounds):

2115.15

Three-subset MITM attack against 25 round

XTEA: 2120.4 encryptions


3.3 Platform and Methodology

All the implementations and analysis in this thesis have been done on TinyOS 2.1.2

using TOSSIM (Tiny OS SIMulator) and Avrora with MicaZ as the target hardware for

simulation. For all ciphers except TEA and XTEA, the code provided by Cazorla et

al. [114] were ported to TinyOS, one of the first operating systems designed specifically

for embedded applications, for analysis purpose where as code for TEA and XTEA were

taken directly from the author’s paper. The various components of our experimental

setup have been briefly described below:

3.3.1 Experiment Platform

TinyOS

TinyOS [160], [161] is an open source operating system designed for resource constrained

devices like in Wireless Sensor Networks, ubiquitous computing and smart meters. It

started as a project in collaboration between the University of California, Berkeley with

Intel Research and Crossbow Technology. The operating system and user application

on this platform is written in nesC [162], [163], a dialect of C language which can pro-

vide hardware abstraction to emulate the actual behavior of motes. TinyOS has been

described in details in later chapters.

MICAz

MICAz [96], [164] is one of the oldest sensor mote which is an 8-bit micro-controller

based 2.4 GHz mote with 128 Kb flash memory, 4K RAM and 4K EEPROM. It is based

on Atmel AVR [165] and Chipcon CC2420. It has a 51 pin connector for connection to

sensor board and supports analog inputs, digital I/O, I2C, SPI and UART. It supports

various sensing devices including sensors for temperature, pressure, acceleration etc. &

takes 2 AA cells as power source.


Avrora

As discussed before, Avrora [104], [105] is an open-source cycle-accurate simulator for

sensor programs and networks and its latest version is written in Java. It can typically

emulate two platforms, MICA2 and MICAz and can scale to networks of up to 10,000

nodes, handling as many as 25 nodes in real-time. It has several monitors that lets

us track the program as it progresses and gets summary of parameters such as energy

consumption by various components, packet monitoring, CPU cycles etc.

3.3.2 Methodology

Wemeasured the energy consumption of the investigated ciphers for encrypting/decrypting

one block of data and energy per byte was calculated as energyPerBlock/blockSize. To

calculate the energy consumed, we implemented the various ciphers in nesC for TinyOS

2.1.2 and then simulated the program on Avrora with target hardware platform as MI-

CAz and with parameter as ‘real-time’ which gives a result very close to the actual

execution of program on motes.

Once the code is compiled on TinyOS, it creates a TinyOS image of the program

which can be burned on the actual hardware and gives a summary of the RAM and

ROM usage when installed on the hardware. On simulation with Avrora, we can find

the break-up of energy consumption by various components like radio, CPU, flash etc.

which can be used for further analysis.

3.4 Experiments and Results

3.4.1 Memory Requirement

A summary of the memory requirement by the investigated ciphers is presented in Table

3.3. As we can see, all the implementations require both RAM and ROM of size less

than 4K. If compared with the results published in [114], most of our implementations


take comparatively less ROM though many of them take more RAM. However, our im-

plementations have a proper trade-off between their RAM and ROM requirements to fit

into most of the resource constrained motes. The ROM requirement indicates memory

usage due to the large tables and S-boxes which are regularly accessed during different

steps of key scheduling, encryption and decryption. RAM requirement however indicates

the memory needed by the temporary variables and the program code which provides

interface to interact with the underlying components. The RAM and ROM require-

ments in our implementations have been optimized by deciding which values should be

pre-calculated and stored in the memory and which values can be calculated on-the-fly.

As we can see, our implementation of block ciphers like PRESENT and AES-128

has higher ROM requirement due to the large pre-calculated look-up tables stored in

the memory in order to speed up the P-layer. Similarly, their RAM requirement is

large as they accesses various tables from memory during key scheduling and encryp-

tion/decryption. TEA and XTEA however have low RAM requirements as their key

scheduling phase does not use preloaded tables from the memory. Similarly if we com-

pare the memory requirements of DES with DESXL, we see that both RAM and ROM

requirements of DESXL is comparatively less as it uses only one S-box instead of 8

S-boxes as in DES.

Table 3.3: Summary of Memory RequirementAlgorithm AES-128 DES DESXL HIGHT IDEARAM(in Bytes) 1071 1382 476 292 132ROM(in Bytes) 2222 3950 3100 1418 2050

Algorithm mCrypton-64 SEA TEA Piccolo-80 LBLOCKRAM(Bytes) 336 642 28 236 310ROM(Bytes) 2254 1974 1276 2144 1656

Algorithm KLEIN-80 LED-64 XTEA PRESENT-80RAM(Bytes) 228 168 36 1090ROM(Bytes) 1668 2014 1196 3222

3.4.2 Energy Consumption

The summary of energy consumed by the various investigated ciphers for encryption one

block data and energy per byte is given in Table 3.4.2 and a graph for the same is shown


in Fig 3.4.3

Table 3.4: Summary of Energy ConsumptionAlgorithm Block Size Clock Encryption Encryption

(bits) cycles (mJ/block) (µJ/byte)AES-128 128 22584 0.069 4.31DES 64 69782 0.175 21.8DESXL 64 70836 0.193 24.15HIGHT 64 13928 0.043 5.37IDEA 64 25950 0.079 9.87KLEIN-80 64 18192 0.056 7.0mCrypton-64 64 116097 0.172 21.5PRESENT 64 25286 0.077 0.292Piccolo-80 64 22390 0.068 0.506LBLOCK 64 19780 0.061 0.125LED-64 64 378270 1.16 9.758TEA 64 8036 0.024 0.182XTEA 64 15866 0.048 0.258SEA 96 13589 0.041 0.376

3.4.3 Energy Analysis

There are a few papers [114] [115] which have investigated various block ciphers for

different parameters including energy in terms of CPU cycles. However, as seen in [117],

if we compare the KATAN family of ciphers with CLEFIA, it consumes more number of

cycles but less energy in terms of mJ.

Similarly, LED and PRESENT consume same amount of energy though LED takes

1.5 times the CPU cycles consumed by PRESENT. Also, KLEIN serial takes almost con-

sumes almost same energy as PRESENT inspite of consuming 3 times more CPU cycles.

Hence the energy comparison in terms of CPU cycles might be misleading in some cases.

This justifies the work in this thesis wherein we have computed the energy consumption

of ciphers in terms of mJ which gives us a better estimate than merely concluding on

the basis of CPU cycles.

If we analyze the energy consumption as given in Table 3.4.2, TEA and XTEA

are among the least energy consuming ciphers as they have very simple round functions


while we also have ciphers like LED and Piccolo which consume more energy than con-

ventional block ciphers like AES and IDEA. As we can see in the above table, being a

hardware-oriented cipher, LED-64 does not perform well on a generic hardware platform

and consumes more energy than any other investigated cipher. Similarly, the round func-

tion of PRESENT is much simpler as compared to mCrypton resulting in less energy

consumption.

Figure 3.2: Comparison of Energy Consumption for Evaluated Ciphers

As can be seen in the work presented by Cryptolux [166], a cryptology research group

within the Computer Science and Communications (CSC) research unit of the University

of Luxembourg, AES has higher throughput than the ciphers like DESXL, LED, Piccolo

etc indicating it takes lesser time hence lesser energy to encrypt same amount of data

than the other ciphers. However ciphers like HIGHT, LBLOCK and mCRYPTON are

shown to have better throughput. Similarly ECRYPT [167] has also summarized the


throughput of various ciphers and it can be seen that AES has more throughput than

DES, DESXL and XTEA but has lesser throughput than ciphers like mCRYPTON,

PRESENT, HIGHT etc. However, our work shows that AES consumes lesser CPU

cycles hence has better throughput than all the investigated ciphers except TEA. This

difference in result occurs because the results shown in most of these works [166] [167]

are based on hardware implementations for the smallest gate-equivalent implementation

of these block ciphers while our work compares all the block ciphers based on their

performance on a generic hardware.

Though the above analysis gives us an estimate of the energy consumption, it

doesn’t give any information on the security vs. energy efficiency trade-off for the ciphers.

Hence we have introduced a comparison metric in the next section which takes into

account the energy consumption and the best security provided by the ciphers and lets

us compare the various ciphers based on their security vs. energy efficiency trade-off.

3.5 MSEC: Metric for Security v/s Energy Consump-

tion

As already discussed, key length of the cipher is one of its important security parameter

as larger key length implies larger key space and hence it increases the complexity of

key-search attacks. As recommended by BlueKrypt, minimum key length for symmetric

cipher is 128 bits to keep a data secure. However, it comes with an overhead of increased

complexity as larger key size requires larger no. of cycles for diffusion thus resulting to

more energy consumption. So a few metrics have already been proposed in the literature

to quantify the trade-off between various parameters of a cipher implementation. One

such metric has been proposed by Eisenbarth et al. [168] to evaluate the code size v/s

performance trade-off of the ciphers, namely code size * cycle count / block size and

it was observed that AES provided an excellent size vs. performance trade off while

DESXL had lowest metric among the ciphers investigated in the thesis.


Another such metric to compute the code size v/s performance trade-off was in-

troduced by Rinne et al. [169] where the ratio of throughput and code size was taken

to compute the metric value of a cipher. For this metric also, among the investigated

ciphers, AES provided the best trade-off while DES and its variants were shown to have

the lowest metric values.

For applications like WBANs where the energy available is constrained, our de-

sired property in the block ciphers is more security at the expense of less energy. The

above mentioned metrics however do not consider security as a parameter and the energy

consumption values alone however do not reveal any information on the security being

provided by the cipher. Hence we need to find a way to measure the trade-off between

the security provided by the cipher and energy consumed to maximize our security gain.

So a new metric called MSEC (Metric for Security v/s Energy Consumption) has been

proposed to quantify the security v/s energy consumption trade-off for any cipher based

on the best attack that the cipher can resist. This metric allows us to quantify the

trade-off for a cipher on any underlying hardware.

The security component of the metric is calculated in terms of number of years till

which a cipher will remain secure against brute force attack. This value is calculated

using the formula given by Lenstra y(γ) = 1982 + 3(γ−56)2

where γ is the effective key

length of a cipher and it takes the advance in computational power as given by Moore’s

law into account . The securedY earsLeft can then be calculated as y(γ)−CurrentY ear

and the effective key length of a cipher is calculated based on the available literature.

The comparison metric for evaluation of security v/s energy consumption trade-off is:

MSEC = securedY earsLeft/normalizedEnergy

where normalizedEnergy is the energy consumed by a cipher normalized w.r.t. the

energy consumed by AES so the value of normalizedEnergy is 1 for AES. The MSEC

value can be easily calculated for any cipher based on the current literature and has to

be updated with advances in cryptanalytic attacks against the cipher. A larger metric

value indicates better security v/s energy consumption trade-off while a negative metric

value indicates that based on the current technology, the cipher is no more safe to be


used.

As we can see in the above, the metric value is directly proportional to the number

of years a cipher will be secure implying that the greater the number of years before a

cipher can be broken by brute force, more will be the metric value. Similarly, the metric

value is inversely proportional to the energy consumed implying lesser the energy con-

sumption, greater will be the metric value indicating that the cipher provides a better

energy cost v/s security trade-off. However, the metric value that is being calculated

for a cipher is specific to the implementation of the ciphers done for this thesis and also

depends on the underlying hardware. For different implementations of the same cipher

or with different underlying hardware, the energy consumed by the cipher will vary re-

sulting to changes in the metric value.

We have calculated the metric value for all the investigated ciphers. The value of

the comparison metric for the various investigated ciphers is given in Table 5 and Fig.

2 shows a graph for the same. As we can see, AES has the highest value for the metric

thus indicating that for our implementation, it gives the best trade-off between energy

consumed and security provided(by full version cipher). As there is no attack better

than brute-force against full-version XTEA, its effective key length is taken as 128 bits.

AES is followed by XTEA, HIGHT and IDEA as they provide equivalent security but

consume slightly more energy. On the other hand, as expected, TEA has the least metric

value as they can be broken easily with time complexity of 243.

Hence we can see that this metric gives a good estimate of security vs. energy

consumption trade-off and can easily be calculated for any cipher to evaluate its perfor-

mance against the others. Although in this work, we have calculated the metric value

only for full version ciphers, this metric value can easily be calculated for their reduced

round versions as well. This metric thus provides a framework to help us select one

among many available ciphers as per the need.


Table 3.5: Comparison of Metric Value for Block CiphersAlgorithm AES-128 DES DESXL HIGHT IDEA

Metric Value 73.3 -7.41 0.96 58.98 31.83

Algorithm KLEIN-80 mCrypton-64 PRESENT-80 Piccolo-80 LBLOCK

Metric Value 1.55 -2.07 1.44 1.35 1.70

Algorithm LED-64 TEA XTEA SEA

Metric Value -0.615 -95.56 54.09 23.27

3.5.1 Strength

The key differentiator of this work is the normalized energy cost and “secured years

left” parameter for the metric, which clearly brings out the trade-off between strength of

encryption and energy consumed which is important in WSNs. There are many papers

in the existing literature which analyze the energy cost of ciphers but no metric has been

yet proposed to quantify the energy-security trade-off in a systematic manner. This

metric lets us do a comparative analysis of various implementations of full version or

reduced round ciphers efficiently for any underlying hardware.

3.5.2 Conclusion

The security of data communication has been studied taking care of the limited energy

availability and a good trade-off between the security provided and energy consumed has

been found by using the new metric. We show that the ciphers like AES, HIGHT or

XTEA have a good performance considering the security-energy trade-off while ciphers

like LED or mCrypton-64 with 64 bit key have negative metric value as 64 bit key length

can easily be broken using brute force by today’s technology. On the other hand, cipher

like TEA has the least metric value as it has an effective key length of 43 bits indicating

that they are the least suitable choice for data security.

If we compare the MSEC value of the ciphers with the metric value for throughput

v/s code size [169], it can be seen that TEA has better throughput v/s code size trade-

off as compared to XTEA, SEA, HIGHT etc as it takes lesser energy to encrypt data

indicating it is a better choice for encrypting data. However, when the security aspect of


Figure 3.3: Comparison of Evaluation Metric

a cipher is taken into account, it can be seen that TEA can be easily broken and hence

is not recommended to be used for encryption. However, this aspect of a cipher is not

reflected in the metric proposed by Rinne et al. [169]

Similarly, the metric proposed by Eisenbarth et al. [168] quantifies the energy v/s

size trade-off and shows that AES has the lowest metric value among the investigated ci-

phers indicating best energy v/s size trade-off followed by TEA, IDEA, KLEIN, HIGHT

etc. This implies that the use of cipher for an application is recommended in the in-

creasing order of the metric values. However, when security provided by the ciphers is

considered, it can be seen that the ciphers like TEA or KLEIN are not recommended as

they have already been broken or can be easily broken by brute force in the next few

years. However the security aspect of the ciphers is not reflected by this metric as well.

Chapter 4

Sensors and Operating Systems for

WSNs

In the previous chapter, various simulators for WSN and energy consumed by various

block ciphers on MICAz mote has already been discussed in details. However, many sim-

ulators do not support real time execution of the program and simulators like TOSSIM

or AVRORA which can simulate real world scenarios more accurately cannot support

large number of nodes in ‘real-time’ mode.

Also, not all simulators can accurately emulate the hardware behavior of the motes

as they vary with application. Also, when the simulators/emulators are designed, there

is a trade-off between the “ Accuracy and necessity of detail versus performance and

scalability” [170] so the results given by the simulation might be mistaken due to em-

ulation of “Idealized hardware, protocols and non-realistic radio models”. In addition,

a few of the simulators do not support power profiling of nodes while hardware directly

gives us access to measure the energy. Hence, the same suite of ciphers have been ported

to a TelosB hardware and the same set of experiments have been run on the same.

In this chapter, we will first discuss the features of a few common sensors like it’s

memory, transceiver type, microcontroller and external memory. After that, we will

discuss about few of the most common operating systems [5] [171] which are used for

designing a WSN.

55

Chapter 4. Sensors and Operating Systems for WSNs 56

4.1 Types of Sensor Nodes

Due to the various advances occurring in MEMS (Micro-Electro Mechanical Systems)

based sensor technology, today we can see various miniaturized and cheap wireless sensors

that can sense and process the data. As we can see in Fig 4.1, the main components of

a sensor node are the sensing unit, battery, transceiver and the memory. In this section,

various features of motes like radio properties, flash memory and ROM size, processor

speed etc has been discussed.

Figure 4.1: Sensor Node Architecture [5]

4.1.1 MICAz

MICAz [164] [96] is one of the oldest sensor motes that was specifically designed for

deeply embedded sensor networks. It is a 2.4 GHz mote based on ATmega128L, a low-

power microcontroller and can communicate wirelessly. It has an inbuilt IEEE 802.15.4

compliant RF transceiver with a data rate of 250 kbps and communicates in the range

of 2.4 to 2.8 GHz. It also has a 51-pin expansion connector that supports analog inputs,

I2X, SPI, Digital I/O and UART interfaces. Apart from that, it has an expansion

connector for sensor boards for sensing parameters like temperature, barometric pressure,

acceleration etc.


(a) MICAz mote (b) MICA2DOT mote (c) Imote-2 mote

(d) TelosB mote (e) Tmote Sky mote

Figure 4.2: Types of Sensor Motes

4.1.2 MICA2DOT

MICA2DOT [172] [173] is a 3rd generation wireless smart micro-sensor mote that is

battery powered and very small in size. It is also a ATmega128L micro-controller based

mote that can communicate wirelessly and also supports wireless remote reprogramming.

It mainly runs the TinyOS operating system and has a 868/916MHz, 433MHz or 315MHz

multi-channel transceiver with an extended range. It takes a 3V coin cell as energy source

and communicates with base stations that use MICA2 radio module. It has 18 solderless

expansion pins for connecting 6 analog inputs, digital I/O and a serial communication

or UART interface and has on board temperature sensor, battery monitor and LED.


4.1.3 Imote-2

Imote-2 [174] [175] or the Intel Mote 2 is an advanced wireless sensor note, contains

PXA271 which is a low power XScale processor and can be powered using batteries with

a voltage range of 3.2 - 4.5 V. It has an 802.15.4 compliant radio [49] (CC2240) and a

built-in 2.4 GHz antenna that provides a range of about 30 meters. It comes with a

wireless MMX co-processor and also supports external radio through SDIO and UART.

External radio modules like bluetooth can also be enabled. The CC2420 radio has a

data rate of 250 kbps with 16 channels. Apart from that, the processor has many I/O

options and can support various sensors, radio options etc. including I2C, GPIO, SDIO,

PWM, fast infrared port, camera interface etc.

4.1.4 TelosB

TelosB [48] [176] is an open source platform developed and published by UC Berkley.

It is based on 8 MHz TI MSP430 microcontroller with 10 kB RAM and a 802.15.4

compliant RF transceiver with a data rate of 250 kbps which operates at the bandwidth

of 2.4 to 2.4835 GHz. It also has an integrated on-board antenna and optional sensor

suite (TPR2420) that integrates light, humidity and temperature sensors. It also has

low power consumption modes and has a small wakeup latency. It can be powered by

two AA batteries or via USB port connected to the computer.

4.1.5 Tmote Sky

Tmote Sky [177] [178] is an ultra low power wireless mote that is based on 8 MHz Texas

Instruments MSP430 micro-controller with 10 kb RAM and 48 kb flash memory. Like

TelosB and MICAz, Tmote Sky also has a 2.4 GHz IEEE 802.15.4 compliant wireless

transceiver with a data rate of 250 kbps. It also has an integrated on-board antenna

with an indoor range of 50 meters and outdoor range of up to 125 meters. It has

integrated humidity, temperature and light sensors. Apart from that, it has a 16-pin

expansion support along with an optional SMA antenna connector. Also it has low


power consumption, low wakeup latency and supports programming and data collection

via USB.

4.2 Types of Operating Systems

As the nodes of WSNs have limited resources like CPU power, memory, battery power

etc., OS (Operating Systems) designs for WSNs have to face additional challenges as

compared to the traditional operating systems. A few of the important features of

OS for WSNs include its architecture, programming model, memory management and

resource sharing. In this section, major concerns for designing an OS for the WSNs are

discussed. After that, a brief discussion is presented about a few common OS designed

specifically for WSNs along with their merits and limitations.

4.2.1 WSN OS design concerns

First a brief discussion about the major issues related to designing an OS for WSNs is

given.

Architecture

The architecture design [22] [179] [180] [181] of an OS influences the kernel size as well as

on the services provided by it. Monolithic architecture, micro-kernel architecture, layered

and virtual-machine architecture are the few most common OS architecture types.

A monolithic architecture does not have any definite structure and can be seen as

a bundle of various services with interfaces to use the service. The advantage of this

architecture is that it has smaller memory footprint and has lower module interaction

costs. However, it is hard to understand, modify or maintain.

Another OS choice is the micro-kernel architecture where the kernel has minimum

functionality and there are various user level servers like file server, time server etc to

provide various services. Thus it has a small kernel size and provides better reliability

and ease of customization. However it has poor performance due to frequent user-kernel


boundary crossing.

Another architectural choice is virtual machines where virtual machines resembling

hardware is exported into user programs. Although it provides a better portability, it

has poor performance.

On the other hand, as the layered architecture implements services in layers, it

is reliable and easy to manage and understand. However it is mostly less efficient than

other implementations.

Programming Model

The two popular programming models [182] [183] supported by WSNs are event-based

programming [184] and multithreaded programming. Multithreaded programming is a

common application development model but as it is resource intensive, it is not a good

programming model for WSNs. Event based programming on the other hand is good for

designing applications in resource-constrained scenarios but the programming model is

different than the traditional applications which means application developers have to

learn a new programming model which might not be an easy task. Hence work is going

on to develop a light weight multi-threaded model for WSN.

Memory Management

In traditional OS, memory is generally allocated to various processes exclusively. How-

ever as the sensor nodes are resource constrained, sharing of memory between various

threads or processes might be another approach [185] [186]. This might lead to the issue

of memory protection. Also the early WSN OS like TinyOS assumed that only one appli-

cation runs on the sensor node at a time and hence did not have any memory protection

mechanisms. However, with emerging domains of applications for WSNs, OS needs to

efficiently support execution of multiple threads at a time.


Resource Sharing

As discussed before, initial WSN OS assumed execution of single process at a time hence

did not have to manage multiple programs running concurrently. However most of the

WSNs OSs these days provide some variation of multi-threading [186] [187], hence it

needs to manage resource allocation and sharing.

4.2.2 Survey of Operating Systems

In this section, we will briefly discuss few of the most common operating systems for

WSNs.

TinyOS

TinyOS [188] [160] is an open source, component based application specific OS designed

for the WSNs. It has a very low footprint of 400 bytes and has an inbuilt library that

supports various network an communication protocols. It has a monolithic architecture

hence provides a single shared stack. It does not have separate user space and kernel

space. Initial versions of TinyOS did not support multithreading and strictly followed

event-driven programming model but version 2.1 onward, it has introduced TinyOS

threads called the TOS threads which has a very low overhead of only 0.92% [189]. The

job scheduling in earlier versions of TinyOS was a non-preemptive FIFO (first-in-first-

out) model. However as mentioned by Levis et al. [190] EDF (earliest deadline first)

scheduling algorithm has also been added to TinyOS to facilitate real-time applications.

Apart from this, TinyOS also provides database support in form of TinyDB and supports

nesC [162] [163] for application development. An extensive documentation for TinyOS

can be found online and it supports various platforms including Mica, Mica2, MicaZ and

Tmote.


Figure 4.3: Architecture of TinyOS [5]

Contiki

Contiki [191] is a lightweight open source OS designed for low-power internet commu-

nications. It can run on a range of low-power wireless devices like wismote, micaz, sky,

msb430 etc. and supports both IPv4 and IPv6 standards. It is highly memory efficient

and consumes only about 2 kilobytes of RAM and 40 kilobytes of ROM. It supports stan-

dard IP protocols like HTTP, TCP, UDP etc and a few low-power standards like 6lowpan,

RPL and CoAP. Contiki however does not support multicast, hence it does not provide

any implementation of ICMP (Internet Group Management Protocol). Also it has very

low power consumption, runs on a pair of AA batteries and provides powertrace [192]

to trace energy consumed. Other features of Contiki include proto-threads [193], mul-

titasking kernel and preemptive multithreading. Contiki follows a modular architecture

where the kernel follows an event driven model but the individual processes have optional

threading facilities. Multi-threading is achieved in Contiki using proto-threads which are

stackless, lightweight, portable and have very small memory overhead. Unlike TinyOS,

Contiki supports dynamic memory management and dynamic linking of programs.


Mantis

MANTIS (MultimodAl system for NeTworks of In-situ wireless Sensors) [194] is an

energy efficient lightweight operating system with a very small footprint of only 500 bytes

including kernel, scheduler and network stack. Key feature of the MANTIS operating

system (MOS) is that it can be easily ported across various platforms including a PDA

or a PC. Another key feature of MOS is that the nodes can be remotely managed. MOS

is based on layered OS architecture where each layer acts as a virtual machine. The

RAM is managed logically as 2 parts by MOS: one part is used for allocating memory

to the global variables at compile time while the other part is reserved as a heap from

which stack space is allocated to the threads. Also as shown by Bhatti et al., context

switching introduces an overhead of 60 µs which is less than 1%. For task scheduling,

MOS uses preemptive priority based scheduling and within each priority queue, round

robin approach is used. MOS also supports dynamic memory management but incurs

high overhead and hence is avoided if possible. Like Contiki, MANTIS also does not

support multicast hence it does not have protocols for group management. Also MOS

enables resource sharing by making use of mutexes and semaphores which can be declared

by applications when needed. Various applications for MOS can be developed in C which

can be run on Mica2, MicaZ and Telos platforms and the applications can be simulated

on AVRORA.

LiteOS

LiteOS [195] is a Unix-like OS developed for WSNs at University of Illinois. It provides

support for object oriented programming in form of LiteC++ and has a Unix-like shell.

Also it has a very small footprint and is composed of three components: LiteShell, LiteFS,

and the Kernel. LiteShell is the Unix-like shell which resides on the base-station and

supports various shell commands. The next component is the LiteFS which is the LiteOS

file system and it mounts all the neighbouring nodes as files. The third major component

is the kernel that resides on the node and it supports multithreading, dynamic loading,

provides synchronization support and uses round robin and priority-based scheduling.


LiteOS is a multitasking OS and runs all the applications as separate threads. However

the node goes to sleep when there are no active tasks in the system. Communication

among sensor devices in LiteOS happens in form of files where a each node creates files

for its neighbouring nodes and a file for the radio interface. When some data needs to

be transmitted, it is placed on the file corresponding to the radio interface and then sent

wirelessly. LiteOS applications can be developed in LiteC++ for MicaZ and AVR series

MCU and can be simulated through AVRORA [105].

All the investigated operating systems has been summarized in Table 4.1.

Table 4.1: Summary of Operating Systems for WSNsOS Architec- Programming Scheduling Memory Communica- Resource

ture model Management tion Protocol Sharing

Support

TinyOS Monolithic Primarily event FIFO Static Active Message Virtualization,

driven, TOS thread memory Completion

added later management Events

Contiki Modular Protothreads FIFO Dynamic memory uIP and Rime Serialized

and events Interrupts management Access

execute w.r.t. and linking

priority

MANTIS Layered Threads Five priority Dynamic memory COMM layer at Mutexes and

classes and management kernel level, semaphores

further priority supported but networking

in each high overhead layer at

priority class user level

LiteOS Modular Threads Priority based Dynamic memory File based Through

and events scheduling and management communication synchronization

round robin supported primitives

in each

priority class

4.3 Energy Analysis

In the previous chapter, we have discussed the energy consumed by the investigated

ciphers when the code was simulated on MICAz mote. However, as the MICAz is one

of the oldest motes with only an 8-bit microprocessor and with improving technology,

we have motes that are 16-bit microprocessor based and more energy efficient, we have

implemented the same codes for TelosB mote which is 16-bit microprocessor based and


has the contiki operating system for which code has been written in C.

In this section, we will discuss the experimental setup for measuring the energy

consumed by various ciphers and discuss the energy consumption behaviour.

Experimental Setup

For the experimental setup to measure the power consumed, the main components are

tektronix TDS5104 digital oscilloscope [196] [197] and TCPA300 current probe [6]. The

tektronix TDS5104 digital phosphor oscilloscope is a graph-displaying device i.e. it can

draw graph for various electrical signals. In most applications, it shows the variation

of the signal over time where the X-axis represents the time and the Y axis represents

the current consumption. It can support upto 5 GS/s of sample rate with a maximum

record length of 16 M.

To carry out the experiments, the code was first written on the TelosB mote which

was then connected to a battery with a power of 3V. Once the code was running, the mote

is connected to a current probe amplifier which in turn is connected to the oscilloscope.

For our experimental setup, a Tektronix TCPA300 current probe was used which is an

AC/DC current probe thus letting us measure both AC and DC current simultaneously.

Also the current feedback process used in the probe provides better linearity than most

current measurement systems. Apart from that, TCPA300 has high sensitivity, AC or

DC coupling of signal and one-button auto-balancing feature.

As can be seen in Fig.4.5, a typical current measurement system consist of an oscil-

loscope, the current probe amplifier and a compatible current probe. After the setup is

ready, the current probe is connected to the wire connecting mote to the power source

and graphs were generated with details of current consumption patterns. Once the graph

is generated, the average current consumed or time taken by an operation can be easily

calculated. The TDS5104 oscilloscope provides various features like horizontal or verti-

cal bars which lets us measure the value between two points. It also allows us to take

screenshot of a graph and save the graph data in CSV format so that the graph can be

easily constructed again.


(a) Tektronix TDS 5104 oscilloscope (b) Tektronix TCPA 300

Figure 4.4: Experimental Setup

Energy Consumption and Analysis

In this section, we first summarize the current consumed by various algorithms after

which we will compare the current consumed by TelosB with the current consumption

patterns of MICAz. The energy consumed by various block various ciphers to encrypt

a block of data and energy per byte has been summarized in Table 4.3 and has been

graphically shown in Fig 4.6

As we can see in Table 4.3, the amount of energy consumed by few lightweight ciphers

on a generic hardware like TelosB is even higher than the traditional block ciphers like

AES and HIGHT. This happens because many of these ciphers have been designed on

a hardware optmized for the functions used in them. So on a generic platform like

MICAz, TelosB etc. which have a generic architecture and instruction set, the software

performance of the cipher goes down.

We can also observe that the energy being consumed by TelosB for a particular

algorithm is less than in MicaZ. As shown by Piotrowski et al. [198], based on the

information obtained from documentation of the motes, an estimation can be made for

overall energy consumption and the power consumed by mote in one clock cycle. Here


Figure 4.5: Typical TCPA300 current measurement system [6]

the estimation is calculated for power supply of 3V and the clock frequency for the motes

is taken from the documentation.

� TelosB with TI MSP430 microprocessor working at 8MHz, 4mA → 12 mW,

– 12 mW / 8 MHz = 1.5 nWs

� MICAz (and MICA2) with ATmega128L at 7.37MHz, 10mA → 30 mW,

– 30 mW / 7.37 MHz = 4.07 nWs

So we can see that at around same clock frequency, MSP430 (TelosB) consumes 63%

less energy as compared to ATmega128L processor. Also, Meulenaer et al. [199] have

summarized the energy consumed by MICAz and TelosB as shown below in Table 4.2.

Table 4.2: Energy Cost on MICAz v/s TelosBEnergy Cost MICAz TelosB

Compute for 1 Tclk 3.5 nJ 1.2 nJ

So as we can see in Table 4.2, TelosB consumes around 65% less energy than MICAz

when computing for 1 clock cycle. This also shows that TelosB is more energy efficient

as compared to MICAz.


Table 4.3: Energy Consumption by Ciphers on TelosBAlgorithm Block Key Time Energy Energy

length length per block per block per byte(bits) (bits) (in msec) (in mJ) (in µJ)

AES-128 128 128 3.72 0.0194 1.213DES 64 56 8.67 0.0452 5.661DESXL 64 184 9.36 0.0488 6.107HIGHT 64 128 4.84 0.0252 3.158IDEA 64 128 6.16 0.0322 4.019KLEIN-80 64 80 3.76 0.0196 2.453mCrypton-64 64 64 9.68 0.0503 6.290PRESENT 64 80 45.28 0.2363 14.77Piccolo-80 64 80 3.76 0.0196 2.453LBLOCK 64 80 3.2 0.0167 2.088LED-64 64 64 100.0 0.522 65.25TEA 64 128 2.36 0.0123 1.5399XTEA 64 128 2.84 0.0148 1.85SEA 96 96, ... 4.32 0.0226 1.88

4.4 MSEC: Metric for Security v/s Energy Consump-

tion

We have already discussed the details of the metrics MSEC which has been proposed

in this thesis. Also we have already analysed the energy consumed by the investigated

ciphers. In this section, we will calculate the metric value as per the energy consumed

by the ciphers when run on TelosB hardware motes and compare these results with the

values obtained when the code was run on MICAz mote. The value of metric for the

various investigated ciphers is given in Table 4.4 and Fig 4.7 shows graph for the same.

If the energy consumption values of MICAz and TelosB are compared, it can be

seen that the amount of energy consumed by the various ciphers on TelosB is lower

than on MICAz. However, the ratio of energy consumed by various ciphers is mostly

similar on both platforms indicating that the ratio of number of clock cycles on the two

platforms are similar. However, due to difference in the underlying hardware architec-

ture and instruction set in the two platforms, the ratio of the energy consumed on the


Figure 4.6: Energy Per Byte (in µJ) consumed on TelosB

two platforms differ for ciphers like DES, LED, mCRYPTON etc. However, as TelosB

consumes around 65% less energy per cycle than MICAz, total energy consumed by a

cipher on TelosB is lesser even if consumes more cycles than MICAz.

Table 4.4: Comparison of Metric Value for Block CiphersAlgorithm AES-128 DES DESXL HIGHT IDEA

Metric Value 73.3 -10.18 11.15 58.38 31.94

Algorithm KLEIN-80 mCrypton-64 PRESENT-80 Piccolo-80 LBLOCK

Metric Value 1.53 -4.26 1.44 1.36 1.15

Algorithm LED-64 TEA XTEA SEA

Metric Value -0.75 -97.69 62.51 20.11

Similarly, if we compare MSEC value for the ciphers for the two platforms, we can

see that the value of the metric for all the ciphers is slightly higher on TelosB platform

as compared to MICAz mote as TelosB consumes lesser energy per clock cycle hence

providing a better energy v/s security trade-off. Also, like in case of MICAz, the metric


Figure 4.7: MSEC value for investigated ciphers on TelosB platform

value for TEA and DES are comparatively less even in case of TelosB because these two

ciphers can be easily broken thus providing a bad energy v/s security trade-off. On the

other hand, AES has the highest value of the metric followed by XTEA, HIGHT and

IDEA implying they provide the best security v/s energy trade-off among the investigated

ciphers.

Chapter 5

LEA: Lightweight Encryption

Cipher

A brief discussion about the IEEE 802.15.4 security framework has been included in this

chapter as it has been proposed as security solution for WBANs. After that, details of

LEA along with its design rationale, performance details and security analysis has been

described in the chapter.

5.1 IEEE 802.15.4 security framework

With the advent of hardware technology, we have been able to miniaturize the devices

to a scale where we can easily wear the devices on or inside our body for constant

monitoring of various health parameters. Also WBAN finds its applications not only in

medical domain but can also be used in non-medical applications such as monitoring a

baby or elderly people, measuring health vitals for athletes, computer assisted physical

rehabilitation [23] etc. However, before WBAN can be widely adopted, a few major

issues need to be taken care of, one of which is the communication security.

As we will be dealing with sensitive and private information about a patient which is

even protected by law in many countries, we need to devise a strong security mechanism

to protect our data against various possible threats. As shown by Saleem et. al. [200] and

71

Chapter 5. LEA: Lightweight Encryption Cipher 72

Somasundaram et.al. [201], adopting IEEE 802.15.4 security framework for WBAN is one

of the probable security solutions to ensure safety of our data. IEEE 802.15.4 security

framework uses AES encryption in various modes to provide different security solutions

like access control, data freshness, confidentiality and access control. The various modes

of AES along with the security services provided by them are summarized in table 5.1.

Table 5.1: IEEE 802.15.4 Security FrameworkName Description Access Confiden- Frame Sequential

control tiality integrity freshnessNull No SecurityAES-CTR Encryption only, ✓ ✓ ✓

CTR modelAES-CBC-MAC-128 128 bit MAC ✓ ✓

AES-CBC-MAC-64 64 bit MAC ✓ ✓

AES-CBC-MAC-32 32 bit MAC ✓ ✓

AES-CCM-128 Encryption & ✓ ✓ ✓ ✓

128 bit MACAES-CCM-64 Encryption & ✓ ✓ ✓ ✓

64 bit MAC

The AES cipher that is being used in the IEEE security suite 802.15.4 is a traditional

block cipher which was originally designed for bulk encryptions of data with no restric-

tions on power consumption. However for application like WBAN which is restricted

in it’s resources, we need a lightweight cipher which will keep the data secure for it’s

effective lifetime. As already discussed, in case of WBANs, the effective lifespan of data

is around 100 years which implies that after 100 years, the data becomes invalid. Hence

our security requirement is to provide confidentiality for only 100 years, which is much

lower than the security actually provided by AES.

As the new lightweight cipher is based on SPN, we will briefly discuss about the

SPN structure in the next section before discussing the details of the new algorithm LEA

(Lightweight Encryption Cipher).


5.2 SPN based ciphers

The new cryptographic algorithm that has been proposed in this thesis is based on SPN

(Substitution Permutation Network) structure. Hence we shall be briefly describing the

components and properties of SPN based ciphers in this section. An SPN structure is a

series of linked mathematical operations that takes a block of text and key as input and

applies several ‘rounds’ or ‘iterations’ of Substitution boxes (S-boxes) and a permutation

layers (P-layer) to produce the block of ciphertext. These transformations generally use

operations that are efficient to perform in hardware, such as the exclusive-or (XOR) or

bitwise rotation. Also, in each round, a round key is introduced , which in turn is derived

from the user provided key.

Decryption on the other hand is done simply by reversing the process of encryption.

Here we make use of the inverse of S-boxes and P-layer and apply the round keys in the

reverse order to get back the original text.

An SPN structure with a key K can thus be represented as an invertible mapping

fK : {0, 1}N → {0,1}N where N is the number of bits in plaintext and ciphertext which

consist of R rounds. A Substitution-Permutation block cipher consist of 3 different

phases:

1. Key mixing Phase: input to the round is XORed with a part of the key or a round

key which is derived from the key.

2. Substitution boxes (S-box)

3. Bits mixing or permutation

Fig. 5.1 gives the block diagram of an SPN with 3 rounds and 16 bit input and output

block size. It shows the encryption of a 16 bit block of data using four different S-boxes

and the keys K1, K2 and K3 are the round keys derived from the user provided key. Each

of the above step is briefly described below:


Figure 5.1: Skeletal structure of SPN

5.2.1 S-box

The substitution layer is a non-linear step in the SPN structure that makes use of an m

x n S-box to substitute a block of m bits by another block of n bits. The property of non

linear mapping of S-boxes imply that the output bits of an S-box cannot be represented

as a linear operation on its input bits. An m x n S-box can thus be represented as a

mapping S: {0,1}m → {0,1}n. This substitution should be one-to-one so that a unique

inverse S-box can be constructed for the decryption. The S-boxes used in SPN structures

usually have the same length of input and output block as opposed to the S-box in DES

(Data Encryption Standard) that has different input and output block length. However,


a good S-box will not just permute the bits in each block but will have the property

that changing one input bit will change about half of the output bits, thus ensuring the

avalanche effect by providing confusion in input bits.

5.2.2 P-layer

The permutation layer applies several operations on the input bits to permute their

order. The P-layer takes the output of one S-box, permutes the bits and feeds it to the

next S-box thus providing diffusion across the S-box inputs.

5.2.3 Round Key

Most of the SPN based ciphers have a key expansion round where a number of various

simple operations are applied on the user given key and it is expanded into a large

number of round keys. In most ciphers, a round key is XORed with the data block at

end of each round.

The two principles in an SPN based ciphers are:

1. Invertibility: All the operations and the S-box should be invertible to ensure proper

decryption.

2. Confusion and diffusion: Avalanche effect

• A small change in input text should affect large number of output bits.

• S-box: changing 1 bit should change almost half the bits in output.

• Enough number of rounds to propagate a small change through out the block.

We have already discussed in few of the most common SPN based ciphers like KLEIN,

LED, PRESENT, mCRYPTON and AES in chapter 3. In the next section, we will dis-

cuss in details the various aspects of the proposed cipher LEA including its architecture,

building blocks, some implementation details and its statistical properties.


5.3 Design Rationale

In this section, we will discuss the design rationale that are made while designing the

new cipher.

5.3.1 Key Length

The new block cipher takes a fixed 128-bit block size with a key length of 256-bit key

length. The 256-bit key K is further divided into two halves say K’ and K” where the

first half K’ is used for key whitening which has been described later while the key K”

is used to generate the round keys for encryption.

As discussed already, key length is one of the most important parameters of a cipher

and we have already shown in in Section 2.4 that a minimum of 128 bit key length is

required in order to protect the data for next 75 to 80 years approximately. Hence a key

length of 256-bit is used in this cipher to protect data for a much longer duration.

Similar to AES, the key in case of this cipher can be pictured as a 4 x 4 matrix

where each cell contains a single byte of data. The representation of the 256-bit key is

given in Fig. 5.2. As can be seen in the figure, the 256-bit key is divided into 2 parts

of 16 bytes (128 bits) each. The first half of this key K’ is used for key whitening while

the second half K” is used for key expansion to generate round keys for the cipher.

5.3.2 Input and Output State

The cipher takes a fixed length input of 128 bits and produces a 128 bit output. The

input and output block of the cipher is pictured as a 4 x 4 array of bytes called STATE

as can be seen in Fig. 5.3.. In some steps of the cipher, operations occur on a 4-byte

vector which is also referred to as word and has indices in range 0..3, 4..7 etc.


Figure 5.2: Keylength: 256 bits

5.4 Structure of LEA

The new block cipher LEA (Lightweight Encryption Cipher) is an SPN (Substitution

Permutation Network) based block cipher which has been designed specifically for low

power applications. With a structure similar to AES, LEA has an input and output

block of a fixed length of 128 bits and goes through 9 similar rounds and a LastRound

which is slightly different in structure than the other rounds. Each round consist of four

different transformations:

• SubBytes: Byte substitution using an S-box.

• StateTranspose: Transpose of the STATE matrix.

• MixBits: A non linear bit mixing step.

• AddRoundKey: The RoundKey is XORed with the STATE at end of each round.


Figure 5.3: Example of a STATE

However, before the rounds begin, there is a step of KeyWhitening which will be ex-

plained later. The skeleton structure of the LEA cipher is given below.

EncryptLEA(STATE, RoundKey)

{KeyWhitening(STATE, K’);

for i = 1 to 9:

Round(STATE, RoundKey-i);

LastRound(STATE, RoundKey-10);

}Hence the decryption skeletal structure has the exact same steps but in reversed order.

DecryptLEA(STATE, RoundKey)

{invLastRound(STATE, RoundKey-10);

for i = 9 to 1:

Round(STATE, RoundKey-i);

KeyWhitening(STATE, K’);

}


5.4.1 Key Whitening

As discussed already, in case of LEA with 256-bit key, the key is divided into two parts

K’ and K” where the key K’ is used for Key Whitening. This step is nothing but a

byte-wise XOR of the whitening key K’ with the STATE matrix and has been illustrated

in Fig. 5.4.

Figure 5.4: Key Whitening: Whitening Key XORed with STATE

It should be noted that as Key Whitening is a simple bytewise XOR, the reverse of

this transformation is Key Whitening itself.

5.4.2 The Round Transformation

A high-level description of the structure of LEA in a pseudo-C notation can be given as:

Round(STATE, RoundKey)

{SubBytes(STATE);

StateTranspose(STATE);

MixBits(STATE);

AddRoundKey(STATE, RoundKey);

}And the last round of the cipher is defined as:

LastRound(STATE, RoundKey)

{


SubBytes(STATE);

MixBits(STATE);

AddRoundKey(STATE, RoundKey);

}

As can be seen above, the StateTranspose step has been removed in the last round.

This has been done to keep the skeletal structure of LEA similar to AES. Also, in case

of decryption, the steps are exactly the same but they occur in the reverse order to get

back the original text.

5.5 SubBytes Transformation

Before the SubBytes step for round i, the STATE is XORed with RoundKeyi−1 for

round 2 to 10 while before round 1, the STATE is XORed with the whitening key K’

instead. After the STATE is XORed with the whiting key, each byte of the STATE is

independently input to an 8 x 8 S-box. The S-box of AES is re-used for the LEA cipher

which is a non-linear byte-wise substitution box. As mentioned by Daemen et al. [41],

the S-box is invertible and is a composition of two different transformations which are

described below:

1. First, taking the multiplicative inverse in GF(28) where the multiplication corre-

sponds to multiplication of the polynomials modulo m(x) = x8 + x4 + x3 + x + 1

or ’11B’ in hexadecimal. 00 gets mapped to itself.

2. Then an affine transformation is applied over GF(2) which is defined as below:


y0

y1

y2

y3

y4

y5

y6

y7

=

1 0 0 0 1 1 1 1

1 1 0 0 0 1 1 1

1 1 1 0 0 0 1 1

1 1 1 1 0 0 0 1

1 1 1 1 1 0 0 0

0 1 1 1 1 1 0 0

0 0 1 1 1 1 1 0

0 0 0 1 1 1 1 1

x0

x1

x2

x3

x4

x5

x6

x7

+

1

1

0

0

0

1

1

0

For decryption of data, the inverse S-box is applied to the bytes of the STATE. When

implementing the cipher, the S-box and the inverse S-box is stored in the memory as a

256 bytes lookup table each.

5.5.1 State Transpose

In this step, the STATE matrix is transposed i.e. all the rows of the STATE matrix are

turned into columns and vice versa. The matrix transpose operation has been illustrated

in Fig. 5.5

Figure 5.5: StateTranspose: Rows and columns of STATE interchanged

The transpose of an m x n matrix A can thus be defined as an n x m matrix AT such

that: (AT )i,j = Aj,i ∀i, j.


5.5.2 MixBits

MixBits is a new non-linear step with bitwise operations that has been introduced

in LEA. This step takes an input of 128 bits (16 bytes) which is grouped into four 32-bit

words and bitwise operations are performed on the words. This step consist of only

simple operations like XOR and bitwise shifts. As we can see in the pseudocode for

MixBits, after the data is divided into four words, a similar set of operation is performed

on each word. Such a set of operation is termed as a step. The MixBits transformation

has been designed in such a way that even a single bit change in the input should affect

at least one byte in each step.

In step-i, the value of word-i is affected by the value of the other three words. As

can be seen, the amount by which each word is shifted to either left or right is a prime

number. This choice of shift amount is made to avoid any frequent pattern repeatition

or frequent coincidence of the shift values with the byte boundary. Also, each word in

a step is shifted to both left and right so that a single bit change can affect atleast one

byte of the output and the shift values have been chosen such that a even a single bit

change can affect up to two different bytes in each step.

MixBits(state):

BYTE i;

WORD temp[4]=0;

for i = 0 to 3:

temp[i] = ((state[i][0]) << 24) |

((state[i][1]) << 16) |

((state[i][2]) << 8) |

((state[i][3]));

for i = 0 to 3:

temp[i] += (((temp[(i+1)%4]<<2) ˆ (temp[(i+1)%4]>>13)) ˆ

((temp[(i+2)%4]<<3) ˆ (temp[(i+2)%4]>>11)) ˆ

((temp[(i+3)%4]>>5) ˆ (temp[(i+3)%4]<<7)))


for i = 0 to 3: put back temp values to state

Here temp[0 .. 3] are the four 32-bit words and ˆ represents the bitwise XOR

operation. As we can see, in each step, value of a word is getting updated and the next

step uses updated word value for further operations. This can further be illustrated in

the following manner.

temp[0]’ += ((temp[1]<<2) ˆ (temp[1]>>13) ˆ (temp[2]<<3) ˆ

(temp[2]>>11) ˆ (temp[3]>>5) ˆ (temp[3]<<7));

temp[1]’ += ((temp[2]<<2) ˆ (temp[2]>>13) ˆ (temp[3]<<3) ˆ

(temp[3]>>11)ˆ (temp[0]’>>5) ˆ (temp[0]’<<7));

temp[2]’ += ((temp[3]<<2) ˆ (temp[3]>>13) ˆ (temp[0]’<<3) ˆ

(temp[0]’>>11)ˆ (temp[1]’>>5) ˆ (temp[1]’<<7));

temp[3]’ += ((temp[0]’<<2) ˆ (temp[0]’>>13) ˆ (temp[1]’<<3)

ˆ (temp[1]’>>11) ˆ (temp[2]’>>5) ˆ (temp[2]’<<7))

So we can see that by the end of MixBits transformation, the last word temp[3] is

getting affected by the updated values of temp[0], temp[1] and temp[2]. While iterating

through multiple rounds, this step spreads even a single bit change across multiple bytes.

As we can see, for encrypting data, in step-i, operations are performed on different

words and the value is added to word-i. Similarly, for decrypting the data, we use

the InvMixBits step which is the opposite of MixBits step i.e. the value obtained by

performing various operations on different words in step-i is subtracted from word-i and

the order of operations in InvMixBits is the reverse of MixBits. Pseudocode for the

InvMixBits (Inverse MixBits) transformation is given below.

InvMixBits(state):

BYTE i;

WORD temp[4]=0;


for i = 0 to 3:

temp[i] = ((state[i][0]) << 24) |

((state[i][1]) << 16) |

((state[i][2]) << 8) |

((state[i][3]));

for i = 3 to 0:

temp[i] -= (((temp[(i+1)%4]<<2) ˆ (temp[(i+1)%4]>>13)) ˆ

((temp[(i+2)%4]<<3) ˆ (temp[(i+2)%4]>>11)) ˆ

((temp[(i+3)%4]>>5) ˆ (temp[(i+3)%4]<<7)))

for i = 0 to 3: put back temp values to state

Also, as already mentioned, MixBits (and InvMixBits) is a non-linear step i.e.

MixBits(A) ⊕ MixBits(B) �= MixBits(A⊕ B)

and the same inequality holds for InvMixBits as well.

5.5.3 AddRoundKey step

In this step, the round key which is derived from the user provided cipher key is bitwise

XORed with the STATE array. The length of each round key is same as the input block

i.e. 128 bits. The round key transformation which is a function of the STATE and the

round key can be denoted as AddRoundKey (STATE, RoundKey) and is illustrated

in Fig. 5.6. For decryption, the same round keys are used but in the reversed order to

get back the original text.

5.5.4 Key Scheduling

As mentioned already, the algorithm LEA uses the same key scheduling algorrithm as

AES which takes the 128 bit cipher key as input and generates a total of 11 round keys

(for 10 rounds), 128 bits long each. The key scheduling is divided basically into two

steps: the cipher key is first expanded to an Expanded Key which is of length 11 * 128


Figure 5.6: Add Round Key: STATE XOR Round Key-i

bits. The Expanded Key is then divided into 11 round keys of equal length (128 bits)

where the first 16 bytes of the Expanded Key form the first round key, the next 16 bytes

form the second round key and so on.

5.6 The Inverse Cipher

In case of encryption, the first step is the key whitening after which 10 iterations of

the same round transformations happens. However in case of decryption, the inverse

round transformations take place and end of the 10 rounds, the key whitening step is

again performed to recover the original data. The inverse of the key whitening is itself.

As opposed to the S-box which is used for encryption, an inverse S-box is used for the

bytewise substitution when decrypting the data and as the order of operations is reverse

in case of decryption, the non linear S-box step becomes the last in the inverse round

transformation.

So the pseudo-C notation for the inverse round transformation can be given as:

invRound(STATE, RoundKey)

{AddRoundKey(STATE, RoundKey);

invMixBits(STATE);

StateTranspose(STATE);


SubBytes(STATE);

}And the inverse last round of the cipher is defined as:

invLastRound(STATE, RoundKey)

{AddRoundKey(STATE, RoundKey);

invMixBits(STATE);

SubBytes(STATE);

}

Also as we can see in the structure of the cipher, the order of the steps StateTranspose

and SubBytes is indifferent as the StateTranspose step only transposes the STATE but

does not change the byte values. However, as the MixBits round is a non linear step and

affects the byte values, the order of the steps AddRoundKey and MixBits or similarly

AddRoundKey and invMixBits in case of decryption cannot be interchanged as it will

produce varying results depending on order of operation.

5.7 Implementation details

LEA has been implemented using C for Contiki as well as in nesC for TinyOS and the

implementations are fairly simple. Also as it doesn’t have many lookup tables except the

S-box and inverse S-box, the memory occupied by code is very less and can be easily fit

into a mote. Also, the S-box for encryption and the inverse S-box which is used during

decryption have been stored in memory as 16 x 16 lookup table each thus occupying a

total of 256 * 2 = 512 bytes. Although the lookup table takes up a significant amount of

memory, we prefer storing the pre-calculated S-box in the memory instead of calculating

the values in runtime as a lookup operation takes significantly lesser time and energy

than calculating the values.

Also, the inverse of the step StateTranspose is itself as transpose of a transposed


matrix gives back the original matrix i.e. for any matrix say A, ((A)T )T = A. Hence

the same function can be used for both encryption and decryption thus increasing the

reusability of code and occupying lesser memory.

5.7.1 Effective Key Length

Although as per the design of LEA, the total key length is 256 bits. However, out of these

only 128 bits are used to generate the round key while the other 128 bits are used for key

whitening. As was observed for DESX in which the Key Whitening transformation was

introduced for the first time, a whitening key of length 128 bits increased the effective key

length of the cipher by only 63 bits. So based on this, the effective key length of LEA is

taken as 128+63 = 191 bits for other security tests and analysis of LEA. However further

analysis of LEA is needed to calculate the actual effective key length of the cipher.

5.7.2 Performance on motes

Code for LEA was written in both nesC and C for TinyOS and Contiki operating systems

respectively. Also the code has been implemented for both 8-bit microcontroller and 16-

bit microcontroller based motes. In case of LEA, most time and energy is taken up by

MixBits step when implemented on motes as the operations in this step take place on

32-bit words at a time on an 8-bit/16-bit microcontroller which takes significantly more

time. Our implementation of LEA takes 4.06 ms for encrypting one block of data on

TelosB mote thus consuming around 1.38 µJ per byte while it consumes around 4.94 µJ

per byte on MICAz mote.

5.8 Strength of LEA against statistical attacks

In this section, we discuss the statistical properties of LEA including the avalanche effect

for properties like confusion and diffusion. Also a bytewise randomness test has been

conducted on a dataset of 232 random 128-bit strings to check the frequency of each byte

value.


5.8.1 Confusion and Diffusion

As identified by Claude Shannon, confusion and diffusion are the two desirable statistical

property of a secure cipher. As defined by Channon in his paper “Communication Theory

of Secrecy Systems” published in 1949, his original definitions were as follows:

1. Confusion refers to making the relationship between the key and the ciphertext

as complex and as involved as possible

2. Diffusion refers to the property that redundancy in the statistics of the plaintext

is “dissipated” in the statistics of the ciphertext.

So the property of diffusion states that many output bits should depend on a single

input bit so if a cipher has a good diffusion property, a single bit change in the input

should change each output bit with a probability of half. This property is also termed

as Strict Avalance Criterion. On the other hand, the relationship between the key bits

and the ciphertext bits is termed as the property of confusion so in a cipher with good

confusion property, a single bit change in the key should change each output bit with a

probability of half.

As discussed before, the property of confusion is primarily achieved by using the

non-linear S-box while transposition of input bits using various mechanisms including

swapping of symbols or linear transformations results in a diffusion property.

Statistical tests have been conducted to determine the various properties of the

ciphertext, its relationship with the plaintext and it’s dependency on plaintext as well

as key bits. The tests have been conducted on three files with 500 randomly generated

128-bit strings. The 128-bit strings are taken as the input block (plaintext for LEA) and

the output of the reduced round LEA as well as full version LEA has been analysed.

Table 5.2 summarizes the relationship between the plaintext and ciphertext bits

where the value in the table represents the probability of a bit being flipped in the

output. As we can see, for randomly chosen strings, the probability of a bit being flipped

is half for all the reduced round versions as well as full version LEA which shows that

no information about the plaintext bits is directly revealed by the ciphertext obtained.


Table 5.2: Bit flip probability in ciphertextNumber of File 1 File 2 File 3Iterations

10 rounds 0.502422 0.499766 0.4592349 rounds 0.496484 0.500703 0.5010948 rounds 0.497109 0.498824 0.4994537 rounds 0.503359 0.501563 0.5058596 rounds 0.506484 0.497959 0.5020315 rounds 0.500313 0.500156 0.5004964 rounds 0.495707 0.500234 0.4950783 rounds 0.502812 0.500938 0.4957032 rounds 0.497656 0.501875 0.5003911 rounds 0.512891 0.496875 0.492656

Table 5.3 on the other hand depicts the statistical relationship between the key

bits and the cipher text i.e. the property of confusion. For this, the same plaintext block

was encrypted with two keys which differ exactly by 1 bit and the resulting ciphertexts

were compated. As can be seen in the table, in case of 1-round LEA, the probability

of bit flip is only around 0.17 which is very less hence it will give out some information

about the input. Similarly in some cases, 2-round LEA also shows a slight skewedness.

However 3-round version onward, the bit flip probability is half thus showing that many

output bits depend on each key bit.

Table 5.3: One bit key changeNumber of File 1 File 2 File 3Iterations

10 Round 0.500469 0.499688 0.4975009 Round 0.510000 0.496094 0.4965638 Round 0.498828 0.506797 0.4937507 Round 0.498906 0.505859 0.4946096 Round 0.496641 0.501016 0.5021095 Round 0.496719 0.500859 0.5000004 Round 0.497812 0.507031 0.4987503 Round 0.493281 0.499531 0.5026562 Round 0.489219 0.491641 0.4803911 Round 0.170313 0.171578 0.167422


Table 5.4 and 5.5 show the dependence of the ciphertext bits value on the

plaintext bits i.e. diffusion. To do this, same key was used to encrypt a plaintext pair

where the two plaintexts differ only by a single bit and the resulting ciphertexts were

compared. This result has been summarized in Table 5.4 where we can see that there is a

significant bias in the probability of a bit being flipped in the resulting ciphertext. This

bias can be further used with some more sophisticated cryptanalytic methods to reveal

(partial or full) information about the key ot the plaintext. However 3-round version

onward, the probability of a ciphertext bit being flipped due to a single bit change in

plaintext is half implying it wont directly reveal any information about the input text.

Table 5.5 on the other hand explores the effect of decrypting related ciphertexts

i.e. a ciphertext pair differing only by one bit. The values in the table depicts the

probability of a plaintext bit being flipped when a ciphertext pair differing only by 1 bit

is being decrypted using the same key. As can be seen from the table, till 3-round version

LEA, the probabilty of a bit being flipped is less than half implying it will give some

information about the plaintext block. However, 4-round version onward, probability of

a bit being flipped is half implying it wont directly give out information about the input.

Table 5.4: One bit plaintext changeNumber of File 1 File 2 File 3Iterations



Table 5.5: One bit ciphertext changeNumber of File 1 File 2 File 3Iterations


5.8.2 Bytewise Randomness Test

A randomness test has been conducted to check the frequency of each byte value occuring

in the output of the new algorithm. To check that, we first generated four different sets

of random data from www.random.org [202], each containing 256 4-byte strings. For

this test, we denote the different data sets of 256 strings each as temp1, temp2, temp3

and temp4. Now we analyse the effect of MixBits step on all combinations of temp1,

temp2, temp3 and temp4. As each of them have 256 strings each, a total of (28)4 = 232

different 16-bytes long strings are analysed to check the pattern of each value occuring

in the output value.

To conduct the test, we track the changes occuring in the value of temp1 as an

effect of various bitwise and bytewise operations that depend on temp2, temp3 and

temp4. Hence we have a 2D counter bin which has 4 columns corresponding to 4 bytes

in each string and there are 256 rows corresponding to the different values an 8-bit byte

can take. After a particular set of operations are conducted on each of the 232 different

string combinations being analysed, we check the value of all the bytes in temp and

accordingly increment the corresponding counter values.

For the resulting data to be random, each value should ideally occur equal number

of times hence not revealing any extra information about the original data. So for 232

different strings, each byte value should occur 232/256 = 224 i.e. 16777216 times. We will


now study the effect of three different operation set: only MixBits, round transformation

of LEA and round transformation of LEA without MixBits step and each will further be

analysed for one, two and three iterations of the operation set.

Table 5.6 below summarizes the standard deviation of the frequency of each byte

value occuring in a sample space of 232

Table 5.6: Standard deviation of frequency of byte valuesNumber of Byte LEA round LEA round MixbitsIterations Number transformation transformation only

without MixBits

1 1 4177.385 3554993.459 6896.2841 2 4020.017 7463742.207 9554.8431 3 4272.756 4224997.198 7895.9531 4 8412.210 3498389.785 53120.563

2 1 4186.717 3594952.825 4005.5162 2 4506.388 4333440.005 4012.3212 3 4155.279 1052688.063 4138.0952 4 4020.218 2641131.701 4048.847

3 1 4116.876 5436312.163 4195.1153 2 4483.408 1999840.064 4259.4733 3 4025.428 8504939.365 4215.0813 4 3973.258 6136984.928 3865.674

The frequency of each value occuring in the data set has been shown in the

graphs below which have been represented as scatter plots. In these graphs, the X-axis

represents all the possible values of a byte thus varying from 0 to 255 while the Y-axis

represents the frequency of each value where the mean of the data is 16777216. The

dotted red line in the graphs represents the mean value of the data while the blue dots

on the graph represent the frequency of all the values from 0 to 255. As we can see, in

case of LEA round transformations and MixBits only, the frequency of each value gets

closer to the mean value with each iteration. We can see in Table 5.6 that the standard

deviation is very low in case of LEA round transformations and MixBits only but is very

large in case of LEA round transformations without MixBits.

As we can see in the graphs, in case of LEA round transformation without MixBits,

for most cases there is atleast one value with frequency zero i.e. it doesnot occur even


once in a sample size of 232. However, when the MixBits step is introduced, the frequency

of different values are more uniform and the standard deviation value drastically goes

down. This shows that MixBits step increases the uniformity of data.

(a) Byte 1 (b) Byte 2

(c) Byte 3 (d) Byte 4

Figure 5.7: Only MixBits One iteration




Figure 5.8: Only MixBits Two iteration

5.9 Security Analysis

In order to measure the security provided by this algorithm, a set of various tests have

been performed to check the following measures:

1. Independence of plain text and ciphertext

2. Mathematical properties of the cipher

3. Avalanche Effect

4. Cryptanalysis




Figure 5.9: Only MixBits Three iteration

5.9.1 Independence of plain text and ciphertext

This set of test was performed on the output of LEA to test the hypothesis that the

output produced by a cipher should be random in nature. To check this property, all

the 15 randomness tests including frequency test, entropy test, block frequency test etc

as given by NIST were conducted on a stream of output obtained by encrypting 10,000

blocks of data and it was found that all the tests were cleared by the output stream

generated by LEA.




Figure 5.10: LEA Round Transformation One iteration

5.9.2 Mathematical Property of LEA

A few other tests were conducted on output of LEA to check its mathematical properties.

If a cipher satisfies any of the following tests, it implies the cipher is weak.

Affine Property

To conduct this test, 4 different randomly chosen known plaintext blocks were encrypted

and it was checked if one block can be derived as a combination of the three other blocks.




Figure 5.11: LEA Round Transformation Two iteration

Complementation Property

A test was conducted to check if the ciphertext obtained by complementing the key or

the plaintext block or both is directly related to the original ciphertext.

It was observed that both these tests did not hold for LEA.

5.9.3 Avalanche Effect

As discussed already, the relationship of the plaintext and the key with the ciphertext is

termed as avalance effect. The desired property in a cipher is that many bits of ciphertext




Figure 5.12: LEA Round Transformation Three iteration

should depend on each single bit of key and plaintext. Hence, a single bit change in key

or plaintext should affect many bits of the resulting ciphertext.

As already shown in the previous section, round 3 onward, even a single bit change in

key or plaintext causes a ciphertext bit to flip with a probability of half thus indicating

a high level of confusion and diffusion.




Figure 5.13: LEA Round Transformation without MixBits One iteration

5.9.4 Cryptanalysis

In this section, we will discuss the strength or weakness of LEA against some of the most

common cryptanalytic attacks.

Dictionary attack

As LEA has a block size of 128 bits, 2128 different plaintext blocks will be required by

the attacker in order to launch a dictionary attack. This attack can be launched against

any deterministic block cipher irrespective of its design. However it should be noted




Figure 5.14: LEA Round Transformation without MixBits Two iteration

that to encrypt 2128 blocks of data using 50 computers in parallel with each computer

encrypting at the rate of one terabit (1012) per second will take more than 219 years thus

making this attack an impractical approach to break the cipher.

Collision

An input block of 128 bits can have 2128 different values. As stated by birthday paradox,

for a cipher with an input block of n bits, collision can occur with a probability of 50%

after encrypting 2n/2 different text blocks. As LEA has an input block size of 128 blocks




Figure 5.15: LEA Round Transformation without MixBits Three iteration

with approximately 3.4 * 238 different output values, collision happens with a probability

of 50% after encrypting approximately 2.2 * 1019 blocks while the probability increases

to 75% after encrypting 3.1 * 1019 different blocks. This attack also applies to any cipher

with 128-bit input block irrespective of its design.

Key Collision

Similar to what was mentioned above for collision of ciphertext values, for a key of length

k bits, collision might occur with a probability of 50% after checking 2k/2 different keys.


This attack also applies to all the ciphers with key lenght k irrespective of the cipher

design.

Linear Cryptanalysis

To mount the linear cryptanalytic attack, the two different operations which can be

targeted are: non linear S-box and MixBits step. As the S-box used in LEA is same as

AES, the non linear property provided to LEA by the S-box step will be the same. Few

papers in the literature have shown that the maximum linear distribution probability of

the AES S-box is 2-6 and the number of active S-boxes by end of round 4 in LEA is 32.

Hence the linear distribution probability of LEA by end of round 4 as an effect of S-Box

will be approximately 2-192. The properties of linear properties of MixBits still under

investigation.

Related Key Attack

Related key attack is a form of cryptanalysis in which the attacker can get encrypt data

under various keys whose values are not known to the attacker but the mathematical

relation between the keys is known to him. As the key scheduling algorithm of LEA is

same as AES, LEA might be vulnerable to the related key attacks which can be launched

against AES. The resistance of LEA against related key attacks is being investigated.

Truncated Differential Attack

For some ciphers, it might be possible to predict only a part of the difference after every

round and it might be advantageous to reveal only a few bits of the text. However, as

LEA has a strong diffusion property, it is likely to resist truncated differential attack.

The resistance of LEA against truncated differential attack is being investigated.

Timing Attack

The number of instructions used or the number of memory access done to encrypt or

decrypt data does not depend on the value of the data or the key being processed. Hence


LEA is expected to resist timing attacks.

So as seen above, LEA has cleared the initial cryptanalytic attacks and further work

is needed to check its resistance against more complex attacks that can be launched

against block ciphers. Also, though LEA consumes around 15% more energy than AES

on both the platforms i.e. 4.94 µJ per byte on MICAz mote and 1.38 µJ per byte on

TelosB, it provides a much higher security of 2191 (effective key length = 191 bits) at a

very small overhead and thus gives MSEC value of 144.24 on MICAz while 154.38 on

TelosB platform. The comparison of energy and MSEC values of LEA with the other

investigated ciphers is shown in the graphs below (Fig5.16 - Fig5.19 ).

Figure 5.16: Energy consumption comparison of LEA on MICAz


Figure 5.17: Energy consumption comparison of LEA on TelosB


Figure 5.18: MSEC comparison of LEA on MICAz


Figure 5.19: MSEC comparison of LEA on TelosB

Chapter 6

Conclusions

In this thesis, various properties of a WBAN including the network architecture and

radio model of the nodes have been explored first. As the power consumed by the radio

to transmit message across distance a d is inversely proportional to d2, it was shown that

for WBAN applications which work at very small radio range (up to 3 mtrs), significant

amount of energy is consumed by data encryption.

Subsequently, the security requirements of WBAN along with the security model

and adversary model of WBAN has been explored and it is shown that a key length of

65 bits should be enough to protect the data for 100 years against brute force attack.

However, many advanced attacks bring down the effective key length of a cipher, NIST

recommend a minimum key length of 128 bits which can provide enough security till the

year 2090.

Various simulation tools like NS-2, TOSSIM, OPNET, AVRORA etc have been

studied including their properties like the type of networks supported, number of nodes

that can be simulated, protocols supported etc. Based on the requirements for simulat-

ing a WBAN network like limited mobility of nodes, fewer nodes in a network, detailed

energy profiling support and real time simulation of the nodes, AVRORA was chosen to

simulate various block ciphers as it is highly scalable, cycle-accurate, supports real-time

simulation and provides detailed energy consumption summary for each node.

14 different block ciphers including 11 different lightweight ciphers were taken from

107

Chapter 6. Conclusions 108

an open source library and ported to TinyOS and Contiki operating systems and energy

consumption analysis was done. It was found that as TelosB is more energy efficient

than MICAz, all the investigated ciphers consume lesser energy on TelosB than MICAz

but the ratio of energy consumed by most ciphers is similar across the two platforms.

However, as the energy consumption value does not give any information about se-

curity provided by the ciphers, a new metric has been proposed in this thesis to quantify

the energy v/s security trade-off provided by various ciphers and we have observed that

among the investigated ciphers, AES provided the best trade-off and has a metric value

of 73.3 on both MICAz and TelosB where as the ciphers with smaller key length or

the ciphers which can be easily broken have very low metric value indicating that those

ciphers might not be the best choice to provide security for longer duration.

Although AES was conceived to be a general purpose algorithm without the con-

sideration of the energy consumed, our studies and those elsewhere point that on generic

hardwares, AES is more energy efficient as compared to other lightweight algorithms

available in the literature. This is due to the fact that most of the algorithms retain

the basic SPN structure of AES and have added changes to the confusion and diffusion

properties through additional computations. Also many lightweight ciphers have nibble-

wise operations which cannot be realized

LEA proposed in this thesis also takes around 15% more energy than AES but takes

lower than most other lightweight encryptions proposed in the literature. From the ini-

tial cryptanalytic studies, it is possible to conclude that fewer rounds of the proposed

algorithm will give rise to better energy efficiency than AES. Also, though LEA con-

sumes around 15% more energy as compared to AES, but at the cost of a small energy

overhead, we are able to get a much higher MSEC value of around 154.38 which indicates

LEA provides a much better trade-off between energy consumed and security provided.

The statistical tests show that it reaches the acceptable level of confusion and dif-

fusion by end of round three. Also LEA has cleared all the randomness tests prescribed

by NIST. As LEA has higher number of active S-boxes compared to AES, it is expected

Chapter 6. Conclusions 109

to have a good resistance against linear and differential attacks. However, further anal-

ysis of linear and differential properties of the MixBits step is needed to get a better

estimate of the attack effort needed to break the cipher. Also LEA is expected to resist

other attacks like related key attack, truncated differential attack etc. but a detailed

cryptanalysis would be needed to provide definitive answer.

Future Work

It was shown in the thesis that a proper understanding of various sub-systems

and their roles in SPNs is a must for designing energy efficient block cipher. However no

systematic study of the trade-off between the contribution to the strength of the cipher by

individual blocks are considered, such a study would reveal the trade-off between security

and energy at the operation level. This can give a far clearer insight into designing energy

efficient lightweight encryption for a given strength of security.

The thesis has focused mostly on SPNs. However a variety of various cipher family

including feistel, Lai-Massey etc. can also be studied for their energy efficiency.

In most radio systems, the physical layer security is inbuilt. Often the sensor

nodes also use data compression. The interplay between all of these operations from

energy point of view would yield a holistic view of energy efficient system design. This

is particularly important in the growing context of the sensors in the encryption units

and the radio being integrated into a single chip.

Appendix A

Sage for Cryptography

Sage is a free, open-source math software that can be used for algebra, number theory,

geometry, num,erical computations, cyrptography and related areas. The binary file

as well as the source code fot the package is freely available on the official website of

Sage for download and it supports windows, linux based OS and Mac OSX. In linux

based systems, once the Sage package is downloaded and extracted, it can be easily run

using the command sage which will give a sage prompt where various commands can

be given. Sage can be used to pervorm a variety of operations starting from simple

addition, subtraction etc. to performing matrix operations, solving equations, calculus

and differential equations as well. A detailed documentation is provided online on how

to solve various mathematical problems using Sage. A typical screenshot of Sage is given

in Fig A.1 which shows commands and output for a few common functions like matrix

multiplication, finding factors of a number, solving linear equations etc.

In this section, we will be mainly discussing about the cryptography related

functions supported by Sage. One of the features provided by Sage is a user interface to

interact with a few of the classical ciphers like shift cipher, affine cipher, substitution and

transposition cipher etc. It also supports a few number systems including the binary,

octal, hexadecimal and radix-64 number system. A screenshot for substitution cipher

is shown in Fig A.2. For this, we first need to specify the number system in which the

110

Appendix A. Sage for Cryptography 111

Figure A.1: Sage: common functions examples

input will be provided. In this example, it is specified as AlphabeticStrings() how-

ever it can take other values like HexadecimalStrings(), BinaryStrings(),

OctalStrings() etc. After the number system is specified, we specify the cipher

we want to use which has been specified as SubstitutionCryptosystem(M)in this

case. Once this is done, we provide the key for the alphabet substitution and then the

plaintext can be input to the cryptosystem for encryption.

A.1 S-Boxes and Their Algebraic Representations

The simple functions for substitution cipher, shift cipher etc. supported by Sage

can be used to learn the basics of the classical ciphers. However, these functions are not

much useful to perform any operations related to the modern ciphers. For this purpose,


Figure A.2: Sage: Substitution Cipher Example

Sage has a module which supports few operations that can be performed on the S-boxes

which are used by most of the modern ciphers. Examples of few functions provided by

the module along with a script to analyse AES S-box will be discussed in this section.

To support algebraic operations on S-boxes, Sage has a class called

class sage.crypto.mq.sbox.SBox(*args, **kwargs)

which can be used as shown in Fig A.3.

Figure A.3: Sage: Basic S-box operations


As we can see in Fig A.3, S is initialized to the values of a 4 x 4 S-box. The val-

ues specified here corresponds to the S-box of the cipher PRESENT. Also, the outpt

given by an S-box for a particular input can be specified in decimal or binary as S(1)

or S([0,0,0,1])respectively. However, the bits by default are interpreted in big

endian order. Hence if we want the operations in little endian order, the function

mq.SBox()takes an optional parameter as big endian=<bool> where <bool>can

be true or false.

We have seen how to initialize an S-box by manually specifying the values. However,

Sage also provides an alternate method to initialize the values of an S-box by specifying

the co-efficients of its polynomial system generator. Eg. a 4-bit S-box can be constructed

as follows using its polynomial system generator (Fig A.4).

Figure A.4: Sage: S-box Construction using Polynomial System Generator

Now that we know how to construct an S-box, we will see how to generate

difference distribution matrix and linear approximation matrix for an S-box. Difference

Distribution Matrix and Linear Approximation Matrix are the characteristic matrix gen-

erated for an S-box which are then used for differential and linear cryptanalysis respec-

tively. The S-box used in the examples below to generate the characteristic matrix is

taken from the cryptanalysis tutorial given by Howard Heys [203]. Figure A.5 and A.6

show the command to generate Difference Distribution Matrix and Linear Approximation

Matrix respectively.

Apart from these, there are many other useful functions provided by the module like

calculating maximal linear bias, maximal difference probability, conjunctive normal form


Figure A.5: Sage: Difference Distribution Matrix generation

Figure A.6: Sage: Linear Approximation Matrix generation

representation of an S-box etc which have not been covered in this section but a detailed

documentation of all these functions is available online.

However, when we are working with Sage and if we want to initialize a variable

with values for an AES S-box which is a bytewise S-box, Sage throws an error saying

manually only 255 values can be specified to initialize an S-box. Hence, to construct

the AES S-box in Sage, we use the alternate method of initializing the S-box using

Polynomial System Generator and then the Difference Distribution Matrix and Linear

Approximation Matrix can be calculated for the S-box.


The following lines of code can be directly run on the Sage command line or it can

be saved as a script and run from the unix command line. To run the code as a script,

the file should be saved with an extension of .sage and then the script can be run from

the command line as

sage <filename>.sage

Following is the script to generate the Difference Distribution Matrix and Linear

Approximation Matrix for AES S-box as shown in Fig A.8 and A.7 respectively.

Figure A.7: Sage: Linear Approximation Matrix generation for AES S-box

Figure A.8: Sage: Difference Distribution Matrix generation for AES S-box

Bibliography

[1] S. Farahani, ZigBee Wireless Networks and Transceivers. Newton, MA, USA:

Newnes, 2008.

[2] R. Faludi, Building Wireless Sensor Networks with ZigBee, XBee, Arduino, and

Processing. O’Reilly Media, 1st edition ed., December 2010.

[3] D. of Physics and F. S. U. Astronomy, “Inverse square law, general.” http://

hyperphysics.phy-astr.gsu.edu/hbase/forces/isq.html.

[4] W. R. Heinzelman, A. Chandrakasan, and H. Balakrishnan, “Energy-efficient com-

munication protocol for wireless microsensor networks,” in Proceedings of the 33rd

Hawaii International Conference on System Sciences-Volume 8 - Volume 8, HICSS

’00, (Washington, DC, USA), pp. 8020–, IEEE Computer Society, 2000.

[5] M. O. Farooq and T. Kunz, “Operating systems for wireless sensor networks: A

survey,” Sensors, vol. 11, no. 6, pp. 5900–5930, 2011.

[6] Tektronix, “Tcpa300/400 amplifiers tcp300/400 series ac/dc current probes.”

http://www.element14.com/community/servlet/JiveServlet/

download/49169-1-101994/TCPA300manual.pdf.

[7] J. Gummeson, D. Ganesan, M. D. Corner, and P. J. Shenoy, “An adaptive link layer

for heterogeneous multi-radio mobile sensor networks,” IEEE Journal on Selected

Areas in Communications, vol. 28, no. 7, pp. 1094–1104, 2010.

[8] C. Cordeiro, “Use cases, applications, and requirements for bans,” 2007.

116

BIBLIOGRAPHY 117

[9] S. Saleem, S. Ullah, and H. S. Yoo, “On the security issues in wireless body area

networks,” JDCTA, vol. 3, no. 3, pp. 178–184, 2009.

[10] M. Hanson, H. Powell, A. Barth, K. Ringgenberg, B. Calhoun, J. Aylor, and

J. Lach, “Body area sensor networks: Challenges and opportunities,” Computer,

vol. 42, pp. 58–65, Jan 2009.

[11] M. Chen, S. Gonzalez, A. Vasilakos, H. Cao, and V. C. Leung, “Body area net-

works: A survey,” Mob. Netw. Appl., vol. 16, pp. 171–193, apr 2011.

[12] B. Latre, B. Braem, I. Moerman, C. Blondia, and P. Demeester, “A survey on

wireless body area networks,” Wirel. Netw., vol. 17, pp. 1–18, Jan. 2011.

[13] http://www.ieee802.org/, “Ieee 802.15 working group for wpan.” http://www.

ieee802.org/15/.

[14] http://www.ieee802.org/, “Ieee 802.15 wpan task group 4 (tg4).” http://www.

ieee802.org/15/pub/TG4.html.

[15] D. J. A. Gutierrez, “Ieee std. 802.15.4 enabling pervasive wireless sensor networks.”

http://www.cs.berkeley.edu/˜prabal/teaching/cs294-11-f05/

slides/day21.pdf.

[16] I. S. ASSOCIATION, “Ieee 802.15: Wireless personal area networks (pans).”

http://standards.ieee.org/about/get/802/802.15.html.

[17] M. Tubaishat and S. Madria, “Sensor networks: an overview,” Potentials, IEEE,

vol. 22, pp. 20–23, April 2003.

[18] C. Buratti, A. Conti, D. Dardari, and R. Verdone, “An overview on wireless sensor

networks technology and evolution,” Sensors, vol. 9, no. 9, pp. 6869–6896, 2009.

[19] K. Akkaya, M. Younis, and W. Youssef, “Positioning of base stations in wireless

sensor networks,” Communications Magazine, IEEE, vol. 45, pp. 96–102, April

2007.

BIBLIOGRAPHY 118

[20] Y. Shi and Y. T. Hou, “Optimal base station placement in wireless sensor net-

works,” ACM Trans. Sen. Netw., vol. 5, pp. 32:1–32:24, nov 2009.

[21] M. van de Panne and E. Fiume, “Sensor-actuator networks,” in Proceedings of

the 20th Annual Conference on Computer Graphics and Interactive Techniques,

SIGGRAPH ’93, (New York, NY, USA), pp. 335–342, ACM, 1993.

[22] J. L. Hill, System Architecture for Wireless Sensor Networks. PhD thesis, Univer-

sity of California, Berkeley, 2003. AAI3105239.

[23] E. Jovanov, A. Milenkovic, C. Otto, and P. de Groen, “A wireless body area

network of intelligent motion sensors for computer assisted physical rehabilitation,”

Journal of NeuroEngineering and Rehabilitation, vol. 2, no. 1, pp. 1–10, 2005.

[24] M. Shirmohammadi, K. Faez, and M. Chhardoli, “Lele: Leader election with load

balancing energy in wireless sensor network,” in Communications and Mobile Com-

puting, 2009. CMC ’09. WRI International Conference on, vol. 2, pp. 106–110, Jan

2009.

[25] G. Chen, J. W. Branch, and B. K. Szymanski, “Local leader election, signal

strength aware flooding, and routeless routing,” in In 5th IEEE Intern. Workshop

Algorithms for Wireless, Mobile, Ad Hoc Networks and Sensor Networks, pp. 4–8,

IEEE CS Press, 2005.

[26] Q. Dong and D. Liu, “Resilient cluster leader election for wireless sensor networks,”

in Sensor, Mesh and Ad Hoc Communications and Networks, 2009. SECON ’09.

6th Annual IEEE Communications Society Conference on, pp. 1–9, June 2009.

[27] D. M. Barakah and M. Ammad-uddin, “A survey of challenges and applications

of wireless body area network (wban) and role of a virtual doctor server in ex-

isting architecture,” in Proceedings of the 2012 Third International Conference on

Intelligent Systems Modelling and Simulation, ISMS ’12, (Washington, DC, USA),

pp. 214–219, IEEE Computer Society, 2012.

BIBLIOGRAPHY 119

[28] M. Patel and J. Wang, “Applications, challenges, and prospective in emerging body

area networking technologies,” Wireless Commun., vol. 17, pp. 80–88, Feb. 2010.

[29] A. Boulis, D. Smith, D. Miniutti, L. Libman, and Y. Tselishchev, “Challenges in

body area networks for healthcare: the mac,” Communications Magazine, IEEE,

vol. 50, pp. 100–106, May 2012.

[30] G. Anastasi, M. Conti, M. Di Francesco, and A. Passarella, “Energy conservation

in wireless sensor networks: A survey,” Ad Hoc Netw., vol. 7, pp. 537–568, may

2009.

[31] G. Zhou, T. He, J. Stankovic, and T. Abdelzaher, “Rid: radio interference detection

in wireless sensor networks,” in INFOCOM 2005. 24th Annual Joint Conference

of the IEEE Computer and Communications Societies. Proceedings IEEE, vol. 2,

pp. 891–901 vol. 2, March 2005.

[32] M. Das, “Two-factor user authentication in wireless sensor networks,” Wireless

Communications, IEEE Transactions on, vol. 8, pp. 1086–1090, March 2009.

[33] R. Yasmin, E. Ritter, and G. Wang, “An authentication framework for wireless

sensor networks using identity-based signatures,” in Computer and Information

Technology (CIT), 2010 IEEE 10th International Conference on, pp. 882–889, June

2010.

[34] S. Schaust, M. Drozda, and H. Szczerbicka, “Impact of packet injection models

on misbehaviour detection performance in wireless sensor networks,” in Mobile

Adhoc and Sensor Systems, 2007. MASS 2007. IEEE Internatonal Conference on,

pp. 1–6, Oct 2007.

[35] A. Pathan, H.-W. Lee, and C. seon Hong, “Security in wireless sensor networks:

issues and challenges,” in Advanced Communication Technology, 2006. ICACT

2006. The 8th International Conference, vol. 2, pp. 6 pp.–1048, Feb 2006.

BIBLIOGRAPHY 120

[36] Y. Wang, G. Attebury, and B. Ramamurthy, “A survey of security issues in wire-

less sensor networks,” Communications Surveys Tutorials, IEEE, vol. 8, pp. 2–23,

Second 2006.

[37] Y. Wang, G. Attebury, and B. Ramamurthy, “A survey of security issues in wireless

sensor networks,” IEEE Communications Surveys Tutorials, vol. 8, pp. 2–23, 2006.

[38] M. Li, W. Lou, and K. Ren, “Data security and privacy in wireless body area

networks,” Wireless Communications, IEEE, vol. 17, pp. 51–58, February 2010.

[39] S. Warren, J. Lebak, J. Yao, J. Creekmore, A. Milenkovic, and E. Jovanov, “In-

teroperability and security in wireless body area network infrastructures,” in in

Proceedings of the 27th Annual International Conference of the IEEE Engineering

in Medicine and Biology Society, 2005.

[40] S. Ullah, B. Shen, S. M. R. Islam, P. Khan, S. Saleem, and K. S. Kwak, “A study

of MAC protocols for WBANs,” Sensors, vol. 10, pp. 128–145, Dec. 2009.

[41] J. Daemen, J. Daemen, J. Daemen, V. Rijmen, and V. Rijmen, “Aes proposal:

Rijndael,” 1998.

[42] X. Lai and J. L. Massey, “A proposal for a new block encryption standard,”

pp. 389–404, Springer-Verlag, 1991.

[43] R. L. Rivest, “The rc5 encryption algorithm,” 1995.

[44] P. Ruangchaijatupon and P. Krishnamurthy, “Encryption and power consumption

in wireless lans,” The Third IEEE Workshop on Wireless LANs, 2011, pp. 148–152,

2001.

[45] F. Shebli, I. Dayoub, A. M’foubat, A. Rivenq, and J. M. Rouvaen, “Minimizing

energy consumption within wireless sensors networks using optimal transmission

range between nodes,” in Signal Processing and Communications, 2007. ICSPC

2007. IEEE International Conference on, pp. 105–108, Nov 2007.

BIBLIOGRAPHY 121

[46] E. Kranakis, D. Krizanc, and E. Williams, “Directional versus omnidirectional

antennas for energy consumption and k-connectivity of networks of sensors,” in

Proceedings of the 8th International Conference on Principles of Distributed Sys-

tems, OPODIS’04, (Berlin, Heidelberg), pp. 357–368, Springer-Verlag, 2005.

[47] J. J. Carr, “Directional or omnidirectional antenna?.” http://www.dxing.

com/tnotes/tnote01.pdf.

[48] MEMSIC, “Telosb.” www.memsic.com/userfiles/files/Datasheets/

WSN/telosb_datasheet.pdf.

[49] Chipcon, “Cc2420 2.4 ghz ieee 802.15.4 / zigbee-ready rf transceiver.” https:

//inst.eecs.berkeley.edu/˜cs150/Documents/CC2420.pdf.

[50] S. C. Ergen, “ZigBee/IEEE 802.15.4 summary,” tech. rep., EECS Berkeley, sep

2004.

[51] D. S. A. Minaam, H. M. Abdual-Kader, and M. M. Hadhoud, “Evaluating the

effects of symmetric cryptography algorithms on power consumption for different

data types.,” I. J. Network Security, vol. 11, no. 2, pp. 78–87, 2010.

[52] M. Mana, M. Feham, and B. A. Bensaber, “A light weight protocol to provide

location privacy in wireless body area networks,” CoRR, vol. abs/1103.3308, 2011.

[53] A. Durresi, V. Paruchuri, R. Kannan, and S. S. Iyengar, “A lightweight protocol

for data integrity in sensor networks.”

[54] I. Kamel and H. Juma, “Article a lightweight data integrity scheme for sensor

networks.”

[55] R. Acharya and K. Asha, “Data integrity and intrusion detection in wireless sensor

networks,” in Networks, 2008. ICON 2008. 16th IEEE International Conference

on, pp. 1–5, Dec 2008.

BIBLIOGRAPHY 122

[56] D. Singele, B. Latr, B. Braem, M. Peeters, M. Soete, P. Cleyn, B. Preneel, I. Mo-

erman, and C. Blondia, “A secure cross-layer protocol for multi-hopwireless body

area networks,” in Ad-hoc, Mobile and Wireless Networks (D. Coudert, D. Simplot-

Ryl, and I. Stojmenovic, eds.), vol. 5198 of Lecture Notes in Computer Science,

pp. 94–107, Springer Berlin Heidelberg, 2008.

[57] L. Yao, B. Liu, G. Wu, K. Yao, and J. Wang, “A biometric key establishment

protocol for body area networks.,” IJDSN, vol. 2011, 2011.

[58] W. Drira, . Renault, and D. Zeghlache, “A hybrid authentication and key estab-

lishment scheme for wban.,” in TrustCom (G. Min, Y. Wu, L. C. Liu, X. Jin, S. A.

Jarvis, and A. Y. Al-Dubai, eds.), pp. 78–83, IEEE Computer Society, 2012.

[59] E. Yksel, H. R. Nielson, and F. Nielson, “A secure key establishment protocol for

zigbee wireless sensor networks.,” Comput. J., vol. 54, no. 4, pp. 589–601, 2011.

[60] G. Jolly, M. C. Kusu, P. Kokate, and M. F. Younis, “A low-energy key management

protocol for wireless sensor networks.,” in ISCC, pp. 335–340, IEEE Computer

Society, 2003.

[61] G. Wang, D. Choi, and D. Kang, “A lightweight key renewal scheme for clustered

sensor networks,” in Proceedings of the 3rd International Conference on Ubiqui-

tous Information Management and Communication, ICUIMC ’09, (New York, NY,

USA), pp. 557–565, ACM, 2009.

[62] C.-L. Wang, T.-P. Hong, G. Horng, and W.-H. Wang, “A key renewal scheme

under the power consumption for wireless sensor networks.,” in JCIS, Atlantis

Press, 2006.

[63] J. Y. Khan and M. R. Yuce, New Developments in Biomedical Engineering. InTech,

2010.

[64] I. Butun, S. Morgera, and R. Sankar, “A survey of intrusion detection systems

BIBLIOGRAPHY 123

in wireless sensor networks,” Communications Surveys Tutorials, IEEE, vol. 16,

pp. 266–282, First 2014.

[65] A. Farooqi and F. Khan, “Intrusion detection systems for wireless sensor networks:

A survey,” in Communication and Networking (D. lzak, T.-h. Kim, A.-C. Chang,

T. Vasilakos, M. Li, and K. Sakurai, eds.), vol. 56 of Communications in Computer

and Information Science, pp. 234–241, Springer Berlin Heidelberg, 2009.

[66] T. Bhattasali and R. Chaki, “A survey of recent intrusion detection systems for

wireless sensor network,” CoRR, vol. abs/1203.0240, 2012.

[67] M. Rushanan, A. D. Rubin, D. F. Kune, and C. M. Swanson, “Sok: Security and

privacy in implantable medical devices and body area networks,” in In Proceedings

of the IEEE Symposium on Security and Privacy 2014, IEEE Computer Society.

[68] S. Movassaghi, M. Abolhasan, J. Lipman, D. Smith, and A. Jamalipour, “Wireless

body area networks: A survey,” IEEE Communications Surveys Tutorials, March

2014.

[69] S. Saleem, S. Ullah, and K. S. Kwak, “A study of ieee 802.15.4 security framework

for wireless body area networks,” Sensors, vol. 11, no. 2, pp. 1383–1395, 2011.

[70] S. Avancha, J. Undercoffer, A. Joshi, and J. Pinkston, “Wireless sensor networks,”

ch. Security for Wireless Sensor Networks, pp. 253–275, Norwell, MA, USA: Kluwer

Academic Publishers, 2004.

[71] Z. Benenson, P. M. Cholewinski, and F. C. Freiling, “Vulnerabilities and attacks in

wireless sensor networks,” in Wireless Sensor Network Security, vol. 1 of Cryptology

and Information Security Series, pp. 22–43, 2008.

[72] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, “Perfor-

mance comparison of the aes submissions,” 1999.

BIBLIOGRAPHY 124

[73] Crypto++, “Crypto++ 5.6.0 benchmarks on an intel core 2 1.83 ghz pro-

cessor under windows vista in 32-bit mode.” http://www.cryptopp.com/

benchmarks.html.

[74] Crypto++, “Crypto++ 5.6.0 benchmarks on an intel pentium 4 (prescott) cpu.”

http://www.cryptopp.com/benchmarks-p4.html.

[75] Crypto++, “Crypto++ 5.6.0 benchmarks on an amd opteron 8354 2.2 ghz proces-

sor under linux.” http://www.cryptopp.com/benchmarks-amd64.html.

[76] A. K. Lenstra, “Key length,” 2004.

[77] U. o. M.-S. L. UMSL, “Moore’s law.” http://www.umsl.edu/˜abdcf/

Cs4890/link1.html.

[78] M. Matsui, “Linear cryptanalysis method for des cipher,” in Advances in Cryptol-

ogy EUROCRYPT 93, vol. 765 of LNCS, pp. 386–397, Springer Berlin Heidelberg,

1994.

[79] E. Biham and A. Shamir, “Differential cryptanalysis of des-like cryptosystems,” in

Proceedings of the 10th Annual International Cryptology Conference on Advances

in Cryptology, CRYPTO ’90, (London, UK, UK), pp. 2–21, Springer-Verlag, 1991.

[80] N. Courtois, “Fast algebraic attacks on stream ciphers with linear feedback.,”

in CRYPTO (D. Boneh, ed.), vol. 2729 of Lecture Notes in Computer Science,

pp. 176–194, Springer, 2003.

[81] W. Meier, E. Pasalic, and C. Carlet, “Algebraic attacks and decomposition of

boolean functions,” in Advances in Cryptology - EUROCRYPT 2004 (C. Cachin

and J. Camenisch, eds.), vol. 3027 of Lecture Notes in Computer Science, pp. 474–

491, Springer Berlin Heidelberg, 2004.

[82] R. Li, B. Sun, and C. Li, “Impossible differential cryptanalysis of spn ciphers,”

Information Security, IET, vol. 5, pp. 111–120, June 2011.

BIBLIOGRAPHY 125

[83] BlueKrypt, “Cryptographic key length recommendation.” http://www.

keylength.com/en/3/.

[84] BlueKrypt, “Fact sheet nsa suite b cryptography(2013).” http://www.

keylength.com/en/6/.

[85] M. Korkalainen, M. Sallinen, N. Karkkainen, and P. Tukeva, “Survey of wireless

sensor networks simulation tools for demanding applications,” in Networking and

Services, 2009. ICNS ’09. Fifth International Conference on, pp. 102–106, April

2009.

[86] M. Imran, A. Said, and H. Hasbullah, “A survey of simulators, emulators and

testbeds for wireless sensor networks,” in Information Technology (ITSim), 2010

International Symposium in, vol. 2, pp. 897–902, June 2010.

[87] Y. Xue, H. S. Lee, M. Yang, P. Kumarawadu, H. Ghenniwa, and W. Shen, “Perfor-

mance evaluation of ns-2 simulator for wireless sensor networks,” in Electrical and

Computer Engineering, 2007. CCECE 2007. Canadian Conference on, pp. 1372–

1375, April 2007.

[88] NS-2, “Description: a webpage introduced ns-2..” http://www.isi.edu/

nsnam/ns/.

[89] http://www.mathcs.emory.edu/, “Tcl and otcl programming.” http:

//www.mathcs.emory.edu/˜cheung/Courses/558/Syllabus/

A2-Tcl/Tcl-1-vars.html.

[90] NS-3, “Ns-3..” http://www.nsnam.org/.

[91] S. Mohapatra and P. Kanungo, “Performance analysis of aodv, dsr, {OLSR} and

{DSDV} routing protocols using {NS2} simulator,” Procedia Engineering, vol. 30,

no. 0, pp. 69 – 76, 2012. International Conference on Communication Technology

and System Design 2011.

BIBLIOGRAPHY 126

[92] D. Timmermann, “Simulation of mobile wireless networks with accurate modelling

of non-linear battery effects,” in In proceedings of Applied simulation and modeling

(ASM, 2003.

[93] S. Panda and R. Mohapatra, Implementation and Comparison of Mobility Models

in NS-2. B.tech thesis, National Institute of Technology, Rourkela, May 2009.

[94] Berkley, “Simulating tinyos networks.” http://www.cs.berkeley.edu/

˜pal/research/tossim.html.

[95] Stanford, “Tossim.” http://tinyos.stanford.edu/tinyos-wiki/

index.php/TOSSIM.

[96] capsilwiki, “Micaz.” http://capsil.org/capsilwiki/index.php/

MICAz.

[97] www.tinyos.net, “Simulating tinyos applications in tossim.” http://www.

tinyos.net/tinyos-1.x/doc/tutorial/lesson5.html.

[98] E. Perla, A. O. Cathain, R. S. Carbajo, M. Huggard, and C. Mc Goldrick, “Pow-

ertossim z: Realistic energy modelling for wireless sensor network environments,”

in Proceedings of the 3Nd ACM Workshop on Performance Monitoring and Mea-

surement of Heterogeneous Wireless and Wired Networks, PM2HW2N ’08, (New

York, NY, USA), pp. 35–42, ACM, 2008.

[99] OMNeT++, “Omnet++.” http://www.omnetpp.org/.

[100] Y. Ben-Itzhak, E. Zahavi, I. Cidon, and A. Kolodny, “Nocs simulation framework

for omnet++,” in Networks on Chip (NoCS), 2011 Fifth IEEE/ACM International

Symposium on, pp. 265–266, May 2011.

[101] I. o. C. E. Embedded computing Systems group, “Comparision of network-

simulators.” https://ti.tuwien.ac.at/ecs/people/albeseder/

simcomp/simcomp.

BIBLIOGRAPHY 127

[102] W. Drytkiewicz, S. Sroka, V. Handziski, V. H, A. Kpke, H. Karl, and T. U. Berlin,

“A mobility framework for omnet++,” 2003.

[103] M. Lobbers and D. Willkomm, A Mobility Framework for OMNeT++ User Man-

ual. Technical University of Berlin.

[104] Stanford, “Avrora.” http://tinyos.stanford.edu/tinyos-wiki/

index.php/Avrora.

[105] B. L. Titzer and et al., “Avrora: Scalable sensor network simulation with pre-

cise timing,” in IN PROC. OF THE 4TH INTL. CONF. ON INFORMATION

PROCESSING IN SENSOR NETWORKS (IPSN, pp. 477–482, 2005.

[106] B. Titzer, D. Lee, and J. Palsberg, “Avrora: scalable sensor network simulation

with precise timing,” in Information Processing in Sensor Networks, 2005. IPSN

2005. Fourth International Symposium on, pp. 477–482, April 2005.

[107] G. F. Lucio, M. Paredes-farrera, E. Jammeh, M. Fleury, and M. J. Reed, “Opnet

modeler and ns-2: Comparing the accuracy of network simulators for packet-level

analysis using a network testbed,” in In 3rd WEAS International Conference on

Simulation, Modelling and Optimization (ICOSMO, pp. 700–707, 2003.

[108] J. Guo, W. Xiang, and S. Wang, “Reinforce networking theory with opnet simula-

tion,” JITE, vol. 6, pp. 215–226, 2007.

[109] J. Potemans, B. V. d. Broeck, Y. Guan, J. Theunis, E. V. Lil, and A. V. d. Capelle,

“Implementation of an advanced traffic model in opnet modeler.” http://www.

sciencedirect.com/science/article/pii/S1877050910005454.

[110] I. S. Hammoodi, B. Stewart, A. Kocian, and S. McMeekin, “A comprehensive

performance study of opnet modeler for zigbee wireless sensor networks,” in Next

Generation Mobile Applications, Services and Technologies, 2009. NGMAST ’09.

Third International Conference on, pp. 357–362, Sept 2009.

BIBLIOGRAPHY 128

[111] D. Akba and H. Gmkaya, “Real and {OPNET} modeling and analysis of an en-

terprise network and its security structures,” Procedia Computer Science, vol. 3,

no. 0, pp. 1038 – 1042, 2011. World Conference on Information Technology.

[112] Z. Lu and H. Yang, “Traffic in opnet simulation,” in Unlocking the Power of OP-

NET Modeler, pp. 194–206, Cambridge University Press, 2012. Cambridge Books

Online.

[113] S. R. Ramyah, “3d visualization of umts/wlan integration using opnet modeler,”

Wireless Sensor Network, vol. 4, pp. 281–285, December 2012.

[114] Survey and benchmark of lightweight block ciphers for wireless sensor networks,

LNCS, SECRYPT 2013(May 2013), 2013.

[115] Y. W. Law, J. Doumen, and P. Hartel, “Survey and benchmark of block ciphers

for wireless sensor networks,” ACM Trans. Sen. Netw., vol. 2, no. 1, pp. 65–93.

[116] C. T. R. Hager, S. F. Midkiff, J. min Park, and T. L. Martin, “Performance and

energy efficiency of block ciphers in personal digital assistants,” in In Proceedings

of the 3rd IEEE International Conference on Pervasive Computing and Commu-

nications (PerCom 2005), pp. 127–136, IEEE Computer Society.

[117] L. Batina, A. Das, B. Ege, E. B. Kavun, N. Mentens, C. Paar, I. Verbauwhede, and

T. Yalcin, “Dietary recommendations for lightweight block ciphers: Power, energy

and area analysis of recently developed architectures.” Cryptology ePrint Archive,

Report 2013/753, 2013.

[118] G. Leander, C. Paar, A. Poschmann, and K. Schramm, “New lightweight des vari-

ants,” in FSE, pp. 196–210, 2007.

[119] D. Hong, J. Sung, S. Hong, J. Lim, S. Lee, B. Koo, C. Lee, D. Chang, J. Lee,

K. Jeong, H. Kim, J. Kim, and S. Chee, “Hight: A new block cipher suitable for

low-resource device,” in CHES 2006, vol. 4249 of LNCS, pp. 46–59, Springer.

BIBLIOGRAPHY 129

[120] Z. Gong, S. Nikova, and Y. Law, “Klein: A new family of lightweight block ciphers,”

in RFID. Security and Privacy, vol. 7055 of LNCS, pp. 1–18, Springer Berlin

Heidelberg, 2012.

[121] W. Wu and L. Zhang, “Lblock: A lightweight block cipher,” in Applied Cryptog-

raphy and Network Security, vol. 6715 of LNCS, pp. 327–344, 2011.

[122] J. Guo, T. Peyrin, A. Poschmann, and M. Robshaw, “The led block cipher,” in

Cryptographic Hardware and Embedded Systems - CHES 2011, volume 6917 of

LNCS, pp. 326–341, Springer, 2011.

[123] C. Lim and T. Korkishko, “mcrypton a lightweight block cipher for security of

low-cost rfid tags and sensors,” in Information Security Applications, vol. 3786 of

LNCS, pp. 243–258, Springer Berlin Heidelberg, 2006.

[124] K. Shibutani, T. Isobe, H. Hiwatari, A. Mitsuda, T. Akishita, and T. Shirai,

“Piccolo: An ultra-lightweight blockcipher,” in CHES 2011, vol. 6917 of LNCS,

pp. 342–357.

[125] A. Bogdanov, L. Knudsen, G. Leander, C. Paar, A. Poschmann, M. Robshaw,

Y. Seurin, and C. Vikkelsoe, “Present: An ultra-lightweight block cipher,” in

Cryptographic Hardware and Embedded Systems - CHES 2007, vol. 4727 of LNCS,


[126] D. Wheeler and R. Needham, “Tea, a tiny encryption algorithm.,” pp. 97–110,

Springer-Verlag, 1995.

[127] R. M. N. . D. J. Wheeler, “Tea extensions.”

[128] F.-X. Standaert, G. Piret, N. Gershenfeld, and J.-J. Quisquater, “Sea: A scalable

encryption algorithm for small embedded applications,” in Smart Card Research

and Advanced Applications, vol. 3928 of LNCS, pp. 222–236, 2006.

BIBLIOGRAPHY 130

[129] N. Ferguson, J. Kelsey, S. Lucks, B. Schneier, M. Stay, D. Wagner, and D. Whiting,

“Improved cryptanalysis of rijndael,” in Fast Software Encryption, vol. 1978 of

LNCS, pp. 213–230, 2001.

[130] A. Bogdanov, D. Khovratovich, and C. Rechberger, “Biclique cryptanalysis of the

full aes.” Cryptology ePrint Archive, Report 2011/449, 2011.

[131] H. Demirci and A. A. Seluk, “A meet-in-the-middle attack on 8-round aes,” in

15th International Workshop, Fast Software Encryption 2008, vol. 5086 of LNCS,

pp. 116–126, 2008.

[132] H. Demirci, . Takn, M. oban, and A. Baysal, “Improved meet-in-the-middle at-

tacks on aes,” in Progress in Cryptology - INDOCRYPT 2009, vol. 5922 of LNCS,


[133] P. Rogaway, “The security of desx,” 1996.

[134] J. Song, K. Lee, and H. Lee, “Biclique cryptanalysis on lightweight block cipher:

Hight and piccolo,” Int. J. Comput. Math., vol. 90, no. 12, pp. 2564–2580, 2013.

[135] J. Chen, M. Wang, and B. Preneel, “Impossible differential cryptanalysis of

the lightweight block ciphers tea, xtea and hight,” in Progress in Cryptology -

AFRICACRYPT 2012, vol. 7374 of LNCS, pp. 117–137, 2012.

[136] J. Lu, “Cryptanalysis of reduced versions of the hight block cipher from ches 2006,”

2006.

[137] E. Biham, O. Dunkelman, and N. Keller, “New cryptanalytic results on idea,” in

LNCS, pp. 412–427, Springer, 2006.

[138] D. Khovratovich, G. Leurent, and C. Rechberger, “Narrow-bicliques: Cryptanaly-

sis of full idea,” in In EUROCRYPT 2012, pp. 392–410, Springer, 2012.

BIBLIOGRAPHY 131

[139] Z. Ahmadian, M. Salmasizadeh, and M. R. Aref, “Biclique cryptanalysis of the

full-round klein block cipher,” IACR Cryptology ePrint Archive, vol. 2013, p. 97,

2013.

[140] F. Abed, C. Forler, E. List, S. Lucks, and J. Wenzel, “Biclique cryptanalysis of

present, led, and klein.” Cryptology ePrint Archive, Report 2012/591, 2012.

[141] J.-P. Aumasson, M. Naya-Plasencia, and M.-J. Saarinen, “Practical attack on

8 rounds of the lightweight block cipher klein,” in Progress in Cryptology IN-

DOCRYPT 2011, vol. 7107 of LNCS, pp. 134–145.

[142] F. Karako, H. Demirci, and A. Harmanc, “Impossible differential cryptanalysis

of reduced-round lblock,” in Information Security Theory and Practice. Security,

Privacy and Trust in Computing Systems and Ambient Intelligent Ecosystems,

vol. 7322 of LNCS, pp. 179–188, 2012.

[143] F. Karako, H. Demirci, and A. Harmanc, “Biclique cryptanalysis of {LBlock} and

{TWINE},” Information Processing Letters, vol. 113, no. 12, pp. 423 – 429, 2013.

[144] Y. Wang, W. Wu, X. Yu, and L. Zhang, “Security on lblock against biclique

cryptanalysis,” in Information Security Applications, vol. 7690 of LNCS, pp. 1–14,

2012.

[145] K. Jeong, H. Kang, C. Lee, J. Sung, and S. Hong, “Biclique cryptanalysis of

lightweight block ciphers present, piccolo and led.” Cryptology ePrint Archive,

Report 2012/621, 2012.

[146] T. Isobe and K. Shibutani, “Security analysis of the lightweight block ciphers xtea,

led and piccolo,” in Information Security and Privacy, vol. 7372 of LNCS, pp. 71–

86, Springer Berlin Heidelberg, 2012.

[147] C. H. Lim, “Crypton: A new 128-bit block cipher - specification and analysis,”

1998.

BIBLIOGRAPHY 132

[148] K. Jeong, H. Kang, C. Lee, J. Sung, S. Hong, and J. Lim, “Weakness of lightweight

block ciphers mcrypton and led against biclique cryptanalysis,” Peer-to-Peer Net-

working and Applications, pp. 1–17, 2013.

[149] H. Mala, M. Dakhilalian, and M. Shakiba, “Cryptanalysis of mcryptona lightweight

block cipher for security of rfid tags and sensors,” International Journal of Com-

munication Systems, vol. 25, no. 4, pp. 415–426, 2012.

[150] Y. Wang, W. Wu, and X. Yu, “Biclique cryptanalysis of reduced-round piccolo

block cipher,” in Information Security Practice and Experience, vol. 7232 of LNCS,

pp. 337–352, 2012.

[151] J. Y. Cho, “Linear cryptanalysis of reduced-round present.” Cryptology ePrint

Archive, Report 2009/397, 2009.

[152] G. Leander, “On linear hulls, statistical saturation attacks, present and a crypt-

analysis of puffin,” in Advances in Cryptology EUROCRYPT 2011, vol. 6632 of

LNCS, pp. 303–322, Springer Berlin Heidelberg, 2011.

[153] J. Nakahara, P. Sepehrdad, B. Zhang, and M. Wang, “Linear (Hull) and Alge-

braic Cryptanalysis of the Block Cipher PRESENT,” in Proceedings of CANS’09,

vol. 5888 of LNCS, pp. 58–75, Springer Berlin / Heidelberg.

[154] B. Collard and F.-X. Standaert, “Multi-trail statistical saturation attacks,” in

Applied Cryptography and Network Security, vol. 6123 of LNCS, pp. 123–138, 2010.

[155] B. Collard and F.-X. Standaert, “A statistical saturation attack against the block

cipher present,” in Topics in Cryptology CT-RSA 2009, vol. 5473 of LNCS,


[156] J. Kelsey, B. Schneier, and D. Wagner, “Related-key cryptanalysis of 3-way, biham-

des,cast, des-x, newdes, rc2, and tea,” in DES, RC2, and TEA, Proceedings of

the 1997 International Conference on Information and Communications Security,

pp. 233–246, 1997.

BIBLIOGRAPHY 133

[157] A. Bogdanov and M. Wang, “Zero correlation linear cryptanalysis with reduced

data complexity,” in Fast Software Encryption, vol. 7549 of LNCS, pp. 29–48,

2012.

[158] Y. Sasaki, L. Wang, Y. Sakai, K. Sakiyama, and K. Ohta, “Three-subset meet-in-

the-middle attack on reduced xtea,” in Progress in Cryptology - AFRICACRYPT

2012, vol. 7374 of LNCS, pp. 138–154.

[159] J. Chen, M. Wang, and B. Preneel, “Impossible differential cryptanalysis of the

lightweight block ciphers tea, xtea and hight.” Cryptology ePrint Archive, Report

2011/616, 2011.

[160] T. 2.1.2, “Tinyos.” www.tinyos.net.

[161] Wikipedia, “Tinyos.” http://en.wikipedia.org/wiki/TinyOS.

[162] sourceforge, “nesc: A programming language for deeply networked systems.”

http://nescc.sourceforge.net/.

[163] Wikipedia, “nesc.” http://en.wikipedia.org/wiki/NesC.

[164] Crossbow, “Micaz datasheet.” http://www.openautomation.net/

uploadsproductos/micaz_datasheet.pdf.

[165] Amtel, “Atmel avr 8-bit and 32-bit microcontrollers.” http://www.atmel.

com/products/microcontrollers/avr/.

[166] U. o. L. CryptoLUX, “Lightweight block ciphers.” https://www.cryptolux.

org/index.php/Lightweight_Block_Ciphers.

[167] E. II, “Block ciphers.” http://www.ecrypt.eu.org/lightweight/

index.php/Block_ciphers.

[168] T. Eisenbarth, Z. Gong, T. Guneysu, S. Heyse, S. Indesteege, S. Kerckhof, F. Koe-

une, T. Nad, T. Plos, F. Regazzoni, F.-X. Standaert, and L. van Oldeneel tot

BIBLIOGRAPHY 134

Oldenzeel, “Compact implementation and performance evaluation of block ciphers

in attiny devices,” in Proceedings of the 5th International Conference on Cryptology

in Africa, AFRICACRYPT’12, (Berlin, Heidelberg), pp. 172–187, Springer-Verlag,

2012.

[169] S. Rinne, T. Eisenbarth, and C. Paar, “Performance analysis of contemporary

light-weight block ciphers on 8-bit.”

[170] E. Egea-Lpez, J. Vales-Alonso, A. S. Martnez-Sala, P. Pavn-Mario, and J. Garca-

Haro, “Simulation tools for wireless sensor networks,” in Proceedings of the Inter-

national Symposium on Performance Evaluation of Computer and Telecommuni-

cation Systems (SPECTS ’05), SPECTS, 2005, July 2005.

[171] A. M. V. Reddy, A. P. Kumar, D. Janakiram, and G. A. Kumar, “Wireless sensor

network operating systems: a survey,” Int. J. Sen. Netw., vol. 5, pp. 236–255,

Aug. 2009.

[172] C. Technology, “Mica2dot wireless sensor mote.” http://www.eol.ucar.edu/

isf/facilities/isa/internal/CrossBow/DataSheets/mica2dot.

pdf.

[173] W. Technologies, “Mprx50 mica2dot series.” http://www.willow.co.uk/

html/mpr5x0-_mica2dot_series.php.

[174] C. Technology, “Crossbow technologies imote2 data sheet.” wsn.cse.wustl.

edu/images/e/e3/Imote2_Datasheet.pdf.

[175] C. Technology, “Imote2 hardware reference manual.” web.univ-pau.fr/

˜cpham/.../Imote2_Hardware_Reference_Manual.pdf.

[176] U. Berkeley, “Telosb usb interface.” webs.cs.berkeley.edu/tos/

hardware/telos/telos-revb-2004-09-27.pdf, september 2004.

BIBLIOGRAPHY 135

[177] moteiv, “tmote sky ultra low power ieee 802.15.4 compliant wireless sen-

sor module.” www.eecs.harvard.edu/˜konrad/projects/.../

tmote-sky-datasheet.pdf.

[178] C. 2.6, “The tmote sky board.” http://contiki.sourceforge.net/docs/

2.6/a01784.html.

[179] W. Dong, C. Chen, X. Liu, and J. Bu, “Providing os support for wireless sensor

networks: Challenges and approaches,” Commun. Surveys Tuts., vol. 12, pp. 519–

530, Oct. 2010.

[180] L. Gu, “t-kernel: Providing reliable os support to wireless sensor networks,” in

In Proc. of the 4th ACM Conf. on Embedded Networked Sensor Systems (SenSys,

pp. 1–14, ACM Press, 2006.

[181] S. Park, J. W. Kim, K.-Y. Shin, and D. Kim, “A nano operating system for

wireless sensor networks,” in Advanced Communication Technology, 2006. ICACT

2006. The 8th International Conference, vol. 1, pp. 4 pp.–348, Feb 2006.

[182] L. Mottola and G. P. Picco, “Programming wireless sensor networks: Fundamental

concepts and state of the art,” ACM Comput. Surv., vol. 43, pp. 19:1–19:51, apr

2011.

[183] B. Rubio, M. Diaz, and J. Troya, “Programming approaches and challenges for

wireless sensor networks,” in Systems and Networks Communications, 2007. IC-

SNC 2007. Second International Conference on, pp. 36–36, Aug 2007.

[184] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali, “Protothreads: Simplifying event-

driven programming of memory-constrained embedded systems,” in In Proc. 2006

SenSys, pp. 29–42, ACM Press, 2006.

[185] K. Sohraby, D. Minoli, and T. Znati, Operating Systems for Wireless Sensor Net-

works. John Wiley Sons, may 2007.

BIBLIOGRAPHY 136

[186] W. Dargie and C. Poellabauer, Fundamentals of Wireless Sensor Networks: Theory

and Practice. Wireless Communications and Mobile Computing, Wiley, 2010.

[187] H. ying Zhou and K. mean Hou, “Limos: A lightweight multi-threading operating

system dedicated to wireless sensor networks,” in Wireless Communications, Net-

working and Mobile Computing, 2007. WiCom 2007. International Conference on,

pp. 3051–3054, Sept 2007.

[188] P. Levis, S. Madden, J. Polastre, R. Szewczyk, A. Woo, D. Gay, J. Hill, M. Welsh,

E. Brewer, and D. Culler, “Tinyos: An operating system for sensor networks,” in

in Ambient Intelligence, Springer Verlag, 2004.

[189] K. Klues, C.-J. M. Liang, J. Paek, R. Musaloiu-E, P. Levis, A. Terzis, and R. Govin-

dan, “Tosthreads: Thread-safe and non-invasive preemption in tinyos,” in Proceed-

ings of the 7th ACM Conference on Embedded Networked Sensor Systems, SenSys

’09, (New York, NY, USA), pp. 127–140, ACM, 2009.

[190] P. Levis and C. Sharp, “Schedulers and tasks.” http://www.tinyos.net/

tinyos-2.x/doc/pdf/tep106.pdf.

[191] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki - a lightweight and flexible oper-

ating system for tiny networked sensors,” in Proceedings of the 29th Annual IEEE

International Conference on Local Computer Networks, LCN ’04, (Washington,

DC, USA), pp. 455–462, IEEE Computer Society, 2004.

[192] A. Dunkels, J. Eriksson, N. Finne, and N. Tsiftes, “Powertrace: Network-level

power proling for low-power wireless networks,” technical report t2011:05, Swedish

Institute of Computer Science, mar 2011.

[193] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali, “Protothreads: Simplifying event-

driven programming of memory-constrained embedded systems,” in Proceedings of

the 4th International Conference on Embedded Networked Sensor Systems, SenSys

’06, (New York, NY, USA), pp. 29–42, ACM, 2006.

BIBLIOGRAPHY 137

[194] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald,

A. Torgerson, and R. Han, “Mantis os: An embedded multithreaded operating

system for wireless micro sensor platforms,” Mob. Netw. Appl., vol. 10, pp. 563–

579, Aug. 2005.

[195] Q. Cao, T. Abdelzaher, J. Stankovic, and T. He, “The liteos operating system:

Towards unix-like abstractions for wireless sensor networks,” in Proceedings of the

7th International Conference on Information Processing in Sensor Networks, IPSN

’08, (Washington, DC, USA), pp. 233–244, IEEE Computer Society, 2008.

[196] Tektronix, “Digital phosphor oscilloscope datasheet.” http://www.tek.com/

datasheet/tds5000-series-digital-phosphor-oscilloscope.

[197] Tektronix, “Digital phosphor oscilloscopes tds5000 series.” http://www.

kumnong.co.kr/files/tek_tds5000.pdf.

[198] K. Piotrowski, P. Langendoerfer, and S. Peter, “How public key cryptography influ-

ences wireless sensor node lifetime,” in Proceedings of the Fourth ACM Workshop

on Security of Ad Hoc and Sensor Networks, SASN ’06, (New York, NY, USA),

pp. 169–176, ACM, 2006.

[199] G. D. Meulenaer, F. Gosset, F. xavier St, and O. Pereira, “On the energy cost of

communication and cryptography in wireless sensor networks,” in In Proceedings

of the 4th IEEE International Conference on Wireless and Mobile Computing,

Networking and Communications (WIMOB 2008, pp. 580–585, IEEE Computer

Society Press, 2008.

[200] S. Saleem, S. Ullah, and K. S. Kwak, “A study of ieee 802.15.4 security framework

for wireless body area network,” CoRR, vol. abs/1102.0682, 2011.

[201] M. Somasundaram and R. Sivakumar, “Security in wireless body area networks: A

survey,” in 2011 International Conference on Advancements in Information Tech-

nology With workshop of ICBMG 2011, vol. 20 of International Proceedings of

Computer Science and Information Technology, pp. 18–23, IACSIT Press, 2011.

BIBLIOGRAPHY 138

[202] RANDOM.ORG, “Random string generator.” http://www.random.org/

strings/.

[203] H. M. Heys, “A tutorial on linear and differential cryptanalysis,” Cryptologia,

vol. 26, pp. 189–221, July 2002.

Date post:	28-Apr-2018
Category:	Documents
Upload:	hanhi
View:	218 times
Download:	2 times