Application-Driven Security in Wireless Sensor Networks

APPLICATION-DRIVEN SECURITY IN WIRELESS
SENSOR NETWORKS
(SEGURIDAD ORIENTADA A APLICACIONES EN REDES DE SENSORES)
By
Rodrigo Román Castro
SUBMITTED IN FULFILLMENT OF THE
REQUIREMENTS FOR THE DEGREE OF
DOCTOR IN COMPUTER SCIENCE
AT
UNIVERSITY OF MALAGA
CAMPUS DE TEATINOS
BLV. LOUIS PASTEUR, 35. 29071 MALAGA
2008
Advisor:
F. Javier López Muñoz
Profesor Titular, Universidad de Malaga
A aquellos que están en mi corazón
To those who are in my heart
ii
Table of Contents
Table of Contents
iii
List of Figures
vii
List of Tables
ix
Acknowledgements
xi
Acronyms
xiii
1 PRELIMINARIES - SENSOR NETWORKS
1.1 Introduction to Wireless Sensor Networks . . . . . . . . . .
1.1.1 Sensor Networks paradigm . . . . . . . . . . . . . .
1.1.1.1 The need to “sense” . . . . . . . . . . . .
1.1.1.2 An overview of Wireless Sensor Networks
1.1.1.3 Differences with Ad Hoc Networks . . . .
1.1.2 Sensing the real world . . . . . . . . . . . . . . . .
1.1.2.1 A brief history of Sensor Networks . . . .
1.1.2.2 Sensor Networks applications . . . . . . .
1.1.3 Sensor node hardware and software . . . . . . . . .
1.1.3.1 Node hardware . . . . . . . . . . . . . . .
1.1.3.2 Operating systems . . . . . . . . . . . . .
1.1.4 Network stack - cross-layering . . . . . . . . . . . .
1.1.4.1 Academic cross-layer architectures . . . .
1.1.4.2 ZigBee standard . . . . . . . . . . . . . .
1.2 Wireless Sensor Networks security . . . . . . . . . . . . . .
1.2.1 Security threats . . . . . . . . . . . . . . . . . . . .
1.2.2 Security mechanisms for Sensor Networks . . . . . .
1.2.2.1 Hardware protection . . . . . . . . . . . .
1.2.2.2 Secure communication channels . . . . . .
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
2
3
5
7
7
8
10
10
13
14
15
17
17
17
19
20
22
1.3
1.4
1.2.2.3 Protocols and services:
1.2.2.4 Protocols and services:
1.2.3 Security as a transversal layer .
Goals of this thesis . . . . . . . . . . .
1.3.1 Direct contributions . . . . . .
1.3.2 Outline of this dissertation . . .
Publications and funding . . . . . . . .
core protocols . . .
supporting protocols
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
25
27
28
30
31
32
2 SECURITY PRIMITIVES & KEY MANAGEMENT SERVICES 35
2.1 Insights on the use of security primitives . . . . . . . . . . . . . . . . 36
2.1.1 Description of the security primitives . . . . . . . . . . . . . . 36
2.1.2 Software implementation of primitives for WSN . . . . . . . . 41
2.1.2.1 Symmetric Key Cryptography and Hash functions . . 41
2.1.2.2 Public Key Cryptography . . . . . . . . . . . . . . . 42
2.1.2.3 Suitability of software implementations . . . . . . . . 44
2.1.3 Integrations on silicon for WSN . . . . . . . . . . . . . . . . . 45
2.1.3.1 Research efforts . . . . . . . . . . . . . . . . . . . . . 46
2.1.3.2 Industrial efforts . . . . . . . . . . . . . . . . . . . . 48
2.1.3.3 Applicability of HW designs . . . . . . . . . . . . . . 49
2.2 Key management approaches based on SKC . . . . . . . . . . . . . . 50
2.2.1 Key Management Systems (KMS) . . . . . . . . . . . . . . . . 50
2.2.2 Analyzing Key Management Systems for Sensor Networks . . 51
2.2.2.1 Main properties of a KMS . . . . . . . . . . . . . . . 52
2.2.2.2 KMS frameworks . . . . . . . . . . . . . . . . . . . . 55
2.2.3 KMS Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.2.3.1 The methodology . . . . . . . . . . . . . . . . . . . . 60
2.2.3.2 The prototype . . . . . . . . . . . . . . . . . . . . . 62
2.2.4 Applying the KMS Guidelines . . . . . . . . . . . . . . . . . . 63
2.2.4.1 Using the methodology: a concrete example . . . . . 63
2.2.4.2 Grouping real-world applications . . . . . . . . . . . 65
2.2.4.3 Protecting the groups through the methodology . . . 67
2.2.4.4 Open issues . . . . . . . . . . . . . . . . . . . . . . . 68
2.2.5 KMS Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.3 Key management approaches based on PKC . . . . . . . . . . . . . . 71
2.3.1 The case of traditional asymmetric cryptography . . . . . . . 71
2.3.1.1 Adapting PKI for Sensor Networks . . . . . . . . . . 72
2.3.1.2 Certificate format for Sensor Networks . . . . . . . . 73
2.3.1.3 Other PKI functions in Sensor Networks . . . . . . . 75
2.3.2 The case of identity-based cryptography . . . . . . . . . . . . 77
2.3.2.1 Identity-based and self-certified cryptography . . . . 77
2.3.2.2 Preliminaries and energy consumption estimations . 78
iv
2.3.2.3
2.3.2.4
Authenticated Key Exchange (AKE) . . . . . . . . .
Total energy cost and applicability discussions . . . .
3 SELF-AWARENESS SERVICES
3.1 Protocol diversity . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Heterogeneity of core protocols . . . . . . . . . . . .
3.1.1.1 Routing . . . . . . . . . . . . . . . . . . . .
3.1.1.2 Aggregation . . . . . . . . . . . . . . . . . .
3.1.1.3 Time synchronization . . . . . . . . . . . .
3.1.2 Protocols and self-awareness . . . . . . . . . . . . . .
3.2 Self-Configurability and situation awareness . . . . . . . . .
3.2.1 Situation awareness in Wireless Sensor Networks . . .
3.2.2 Development of lightweight awareness mechanisms . .
3.2.2.1 Types of abnormal events . . . . . . . . . .
3.2.2.2 Situation awareness mechanisms . . . . . .
3.2.2.3 Application influence on situation awareness
3.3 Intrusion Detection Systems . . . . . . . . . . . . . . . . . .
3.3.1 An overview of Intrusion Detection Systems (IDS) . .
3.3.1.1 Purpose of an IDS . . . . . . . . . . . . . .
3.3.1.2 IDS and wireless networks . . . . . . . . . .
3.3.1.3 IDS and Sensor Networks: related work . .
3.3.2 Applying IDS to Wireless Sensor Networks . . . . . .
3.3.2.1 Architecture . . . . . . . . . . . . . . . . . .
3.3.2.2 Agents tasks . . . . . . . . . . . . . . . . .
3.3.2.3 Support protocols . . . . . . . . . . . . . .
3.4 Trust Management . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Introduction to Trust Management . . . . . . . . . .
3.4.1.1 Trust and Sensor Networks . . . . . . . . .
3.4.1.2 Solutions for Ad Hoc Networks . . . . . . .
3.4.1.3 Solutions for WSN . . . . . . . . . . . . . .
3.4.2 Features of Trust Management Systems for WSN . .
3.4.2.1 Architecture and components . . . . . . . .
3.4.2.2 Initialization and information gathering . .
3.4.2.3 Information modeling . . . . . . . . . . . .
3.4.2.4 Existing computation models . . . . . . . .
4 APPLICABILITY OF SECURITY SERVICES
4.1 Middleware . . . . . . . . . . . . . . . . . . . . .
4.1.1 Security in the Middleware . . . . . . . . .
4.1.1.1 Middleware architecture . . . . .
4.1.1.2 Levels of security . . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
80
83
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
85
86
86
86
88
89
90
91
91
93
94
97
100
102
102
102
103
104
105
105
108
111
116
116
117
118
119
122
123
124
125
126
.
.
.
.
129
130
131
131
134
4.2
Connectivity - Sensor Networks and the Internet
4.2.1 Integrating WSN and the Internet . . . .
4.2.2 Security challenges . . . . . . . . . . . .
4.2.3 Security achievements and open issues .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
135
135
138
140
5 CONCLUSIONS
145
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
A Proof of the Spontaneous Watchdog Equation
B Resumen de la Tesis en Español
B.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Redes de Sensores y seguridad . . . . . . . . . . . . . . . . .
B.2.1 Redes de Sensores . . . . . . . . . . . . . . . . . . . .
B.2.2 Seguridad en Redes de Sensores . . . . . . . . . . . .
B.3 Objetivos y resultados de la tesis . . . . . . . . . . . . . . .
B.3.1 Objetivos de la tesis . . . . . . . . . . . . . . . . . .
B.3.2 Resultados de la tesis . . . . . . . . . . . . . . . . . .
B.4 Soporte para primitivas criptográficas . . . . . . . . . . . . .
B.4.1 Implementaciones software y hardware . . . . . . . .
B.4.2 Primitivas criptograficas en Redes de Sensores . . . .
B.5 Sistemas de administración de claves en Redes de Sensores .
B.5.1 Desarrollo de una metodologı́a de selección . . . . . .
B.5.2 Resultados del análisis . . . . . . . . . . . . . . . . .
B.6 Administración de claves con clave pública . . . . . . . . . .
B.6.1 Especificación de una infraestructura de clave pública
B.6.2 Otros paradigmas de clave pública . . . . . . . . . .
B.7 Servicio de autoinspección . . . . . . . . . . . . . . . . . . .
B.7.1 Mecanismos de conocimiento del entorno . . . . . . .
B.8 Detección de intrusiones y Redes de Sensores . . . . . . . . .
B.8.1 Propuesta de un sistema de detección de intrusiones .
B.9 Sistemas de confianza y Redes de Sensores . . . . . . . . . .
B.9.1 Especificación de la confianza en Redes de Sensores .
B.10 Redes de Sensores y middleware seguro . . . . . . . . . . . .
B.11 Integración de Redes de Sensores en Internet . . . . . . . . .
B.11.1 Problemas abiertos y propuestas de soluciones . . . .
B.12 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bibliography
153
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
155
155
156
156
158
160
160
161
162
163
164
165
166
167
167
168
169
170
170
172
173
174
175
177
178
180
181
182
vi
List of Figures
1.1
An overview of the architecture of WSN . . . . . . . . . . . . . . . .
3
1.2
Hardware elements of a sensor node . . . . . . . . . . . . . . . . . . .
11
1.3
Layered architectures for sensor nodes
. . . . . . . . . . . . . . . . .
14
1.4
Outline of the ZigBee stack architecture . . . . . . . . . . . . . . . .
16
1.5
Security as a transversal layer . . . . . . . . . . . . . . . . . . . . . .
27
1.6
“Complete Set” of security mechanisms . . . . . . . . . . . . . . . . .
29
2.1
KMS frameworks for WSN . . . . . . . . . . . . . . . . . . . . . . . .
56
2.2
KMS Guidelines web application. Input screen & Results screen . . .
62
2.3
Simple Certificate format for sensor networks . . . . . . . . . . . . . .
74
3.1
Importance of self-awareness mechanisms for sensor networks . . . . .
92
3.2
Simile: A sensor network as a living being . . . . . . . . . . . . . . .
93
3.3
Blueprint of an IDS Architecture for WSN . . . . . . . . . . . . . . . 106
3.4
Example of Piggybacking Forwarded Messages, with A as the “ticket” 112
3.5
Normal Watchdog, and Obfuscated Watchdog . . . . . . . . . . . . . 113
3.6
Network scenario with Spontaneous Watchdogs . . . . . . . . . . . . 114
3.7
Number of Spontaneous Watchdogs, Normal & Double Probability . . 115
3.8
Overall Architecture of a Trust Management System for WSN . . . . 122
4.1
An Overview of the SMEPP functional structure . . . . . . . . . . . . 132
4.2
The three levels of security in SMEPP . . . . . . . . . . . . . . . . . 134
4.3
WSN-Internet integration strategies . . . . . . . . . . . . . . . . . . . 136
vii
B.1 Estructura de una red de sensores . . . . . . . . . . . . . . . . . . . . 156
B.2 “Conjunto Integral” de mecanismos de seguridad . . . . . . . . . . . 160
B.3 Estructura de una arquitectura IDS para WSN . . . . . . . . . . . . . 173
B.4 Los tres niveles de seguridad en SMEPP . . . . . . . . . . . . . . . . 178
B.5 Estrategias de integración WSN-Internet . . . . . . . . . . . . . . . . 179
viii
List of Tables
1.1
Partial list of microcontrollers used in the sensor networks market . .
11
1.2
Partial list transceivers used in the sensor networks market.
. . . . .
12
2.1
Summary of Software implementations of ECC . . . . . . . . . . . . .
43
2.2
Summary of Hardware prototypes for PKC . . . . . . . . . . . . . . .
47
2.3
Relevant KMS Properties
. . . . . . . . . . . . . . . . . . . . . . . .
52
2.4
Classification of Real-World WSN applications . . . . . . . . . . . . .
65
2.5
KMS Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
2.6
Analysis of the energy consumption of acoustic modems. . . . . . . .
80
2.7
Energy cost of authenticated key exchange (in mJ) . . . . . . . . . .
84
3.1
Outsider and insider attacks in WSN . . . . . . . . . . . . . . . . . .
94
3.2
Relationship between WSN attacks and their symptoms . . . . . . . .
98
B.1 Clases de nodos sensores . . . . . . . . . . . . . . . . . . . . . . . . . 158
B.2 Propiedades relevantes de un protocolo KMS . . . . . . . . . . . . . . 166
B.3 Gasto energético de un intercambio de claves autenticado (en mJ) . . 169
B.4 Relación entre eventos anómalos y sus efectos colaterales . . . . . . . 171
ix
x
Acknowledgements
I have many things to write about, but the space is limited, and it is impossible to pour inside these
sheets of paper all my feelings. Therefore, I’ll be brief, but I’ll do it my way.
First, thanks to my PhD supervisor, Javier López Muñoz, for introducing me in the research
community, and for guiding me in this strange and fulfilling path, where one can eat gazpacho and
read newspapers in Malaga and the next day one can eat sushi and read research projects in Japan.
I kinda like it ˆ ˆ . Also, thanks to Jianying Zhou and the staff @ I 2 R, for the Singaporean days
and their trust. And thanks to Prof. Jose Marı́a Troya Linero, for believing in me.
During the development of this thesis, I have been fortunate enough to be surrounded by great
professionals, who have helped me in many different ways. Dr. M. Carmen Fernández Gago made
me see how both human beings and devices can believe in trust, in order to cooperate for the greater
good. Dr. David Galindo introduced me to the universe of mathematical cryptography. Prof. Gene
Tsudik made me understand that “there are no assumptions”. Prof. Stefanos Gritzalis showed me
the riddles of the Aegean Sea. And, as a friend and as a professional, Cristina Alcaraz Tello is one
of the best colleagues one can have. Kisses, “socia”.
All my other colleagues (Ana, Andres, Ángel, Arantxa, Gerardo, Jesús, Kino, Miguel, Montes,
Noelia, Onieva, Pablo, Pepe Vivas, Rubén) at our security research group, and other great guys @
UMA like Anto, illuminated my long working days. You guys are one of the best research groups
one can work and stay with. Your brightness go well beyond the walls of the office: Post-party
armchairs, ping-pong sessions, gaming sessions, feasts at “Gondor”... all those achivements will be
fondly remembered ˆ ˆ .
My friends also have been an unvaluable source of happiness. Maybe they have not influenced
in the direct realization of this thesis, but without their suppport and their friendship, life would
have been very different. I have very few space here to say what I should say. But you should know
that, deep in my heart, I am happy for your friendship.
Thanks to AnaIs, for being herself. Thanks to Carlos & Carmen (& the younglings), for their
big hearts. Thanks to Chavi, Arancha, David “Dioni”, Ale, Laura, Pepe, for many days of warm
friendship. Thanks to my Chinese language class, and the Chinese students from Chongqing - I
promise I’ll learn chinese someday. Thanks to Cristina Alcaraz, Manolin, Judith, and all the gang
xi
xii
at the residence. Thanks to Marisilla & Noe. Thanks to Leli. Thanks to Paraskevi & “Meili”, for
those walks on Kokkari. Thanks to Sergio Sánchez (and all his cinema troupe) for making me a
microscopic star in a world that moves at 24 frames-per-second. Thanks to Sergio Ramı́rez (and
Ale, Comanche, Pedro, Fran, and many others...) for the good meals and the good laughs. Thanks
to the friends I made in Singapore, because they are scattered around the world but I feel them very
near my heart: Cheng, Havard (& Judy), Kayo Nagazono, Liao Xinting (廖新婷 ), Marek Bieler
(and Rianti and Freya), Nobita Jong, Raghu, Ritchie Ri, Shumeet, Zhuang Wenyue (庄文玥 ), and
all the rest. Thanks to Roberto Vargas for our lunchtime game programming talks. Thanks to the
guys at the restaurant in Karlovassi, “my” fruit stall @ NUS biz school, the friends of my brother
(Jesus, Juanjo, Raul, etc), the Dı́az sisters (Alicia, Clara, Regina, Elena). And special thanks to
“Annie” Ruan Yi (阮奕 ) and “Nurdo” Xiao Ping (肖萍 ) for helping me grow as a human being.
My family is also part of this great project. Thanks to the “Castro” gang (Salvi, Sandra, Sara,
Jose, Cristina, Marı́a, Manuel, Jesus, Ana, Benjamin, Mayka, Antonio, Antonio Jr., Mario, Roberto,
Vanessa, Lucı́a, and all my cousins, aunts and uncles), the “Roman” gang (Edu, Sonia, Mario,
Laura, Coke, Monica, uncle Eduardo, aunt Carmela, aunt Carmen), my sister-in-law (Manme)...
... and, finally, thanks to my mother Ana Castro Rivera, my father Ramón Román Gámez and
my brother Ramón Román Castro. In fact, I think I could write another thesis just about them,
so I think it is better to stop now.
Pero ahora, en Español ˆ ˆ . Puedo agradeceros únicamente en un par de cosas en estas páginas,
pero tened por seguro que os agradezco que esteis ahı́ de todo corazón.
A AnaIs por ser ella misma, A Carlos & Carmen (& los chicos), por su gran corazón. A Chavi,
Arancha, David “Dioni”, Ale, Laura, Pepe, por la amistad que me regalais cada dı́a. A Cristina
Alcaraz, Manolin, Judith, y los de la “resi”. A Marisilla y Noe. A Leli. A Sergio Sánchez (y todos
los demás) por hacerme una microscópica estrella del celuloide y pasarlo de vicio en el intento. A
Sergio Ramı́rez (y Ale, Comanche, Pedro, Fran, y tantos otros...) por los “desconchones” y las
risas. A Roberto Vargas por las conversaciones sobre juegos. A los amigos de Ramón y mı́os (Jesus,
Juanjo, Raul, etc), a “las niñas” (Alicia, Clara, Regina, Elena). A mi familia materna (Salvi,
Sandra, Sara, Jose, Cristina, Marı́a, Manuel, Jesus, Ana, Benjamin, Mayka, Antonio, Antonio,
Mario, Roberto, Vanessa, Lucı́a, y todos mis primos, tios y tias) y paterna (Edu, Sonia, Mario,
Laura, Coke, Monica, tito Edu, tita Carmelita, tita Manme), a mi cuñá (Manme),...
Y por supuesto, a mi madre Ana Castro Rivera, a mi padre Ramón Román Gamez, y a mi
hermano Ramón Román Castro. Y aquı́ termino esta sección, porque si me pongo a hablar de ellos,
nunca acabarı́a. Y todo trabajo cientı́fico debe acabar en algún lado ˆ ˆ .
Acronyms
6lowpan - IPv6 over Low power WPAN.
ACK - Acknowledgement (packet).
ACL - Access Control List.
AES - Advanced Encryption Standard.
AKE - Authenticated Key Exchange.
BSL - Bootstrap Loader.
CA - Certification Authority.
CBC - Cipher-Block Chaining.
CCM - Counter with CBC-MAC.
CMOS - Complementary metal–oxide–semiconductor.
CRL - Certificate Revocation List.
DoS - Denial of Service.
DTN - Delay Tolerant Network.
ECB - Electronic codebook.
ECC - Elliptic Curve Cryptography.
ECDH - Elliptic Curve Diffie-Hellman.
ECDSA - Elliptic Curve Digital Signature Algorithm.
ECIES - Elliptic Curve Integrated Encryption Scheme.
ECMQV - Elliptic Curve Menezes Qu Vanstone (authenticated key exchange protocol).
ECMV - Elliptic Curve Menezes Vanstone (encryption / decryption).
EP2P - Embedded Peer-to-Peer Systems.
FFD - Full Function Device (ZigBee).
xiii
xiv
GCD - Greatest Common Divisor.
GCM - Galois Counter Mode.
GPS - Global Positioning System.
HTTP - Hypertext Transfer Protocol.
HVAC - Heating, Ventilating, and Air Conditioning.
HW - Hardware.
IBC - Identity-based Cryptography.
IDS - Intrusion Detection System.
IEEE - Institute of Electrical and Electronics Engineers.
IP - Internet Protocol.
IPsec - IP security.
IPv4 - Internet Protocol, version 4.
IPv6 - Internet Protocol, version 6.
ISM - Industrial, Scientific and Medical.
ITU-T - International Telecommunication Union, Telecommunication Standardization Sector.
IV - Initialization Vector.
JTAG - Joint Test Action Group (IEEE Standard 1149.1).
KMS - Key Management System.
MAC - Message Authentication Code.
MAC - Medium Access Control.
MANET - Mobile Ad Hoc Networks.
MMX - Matrix Math Extensions, MultiMedia eXtension.
nesC - Network Embedded System C.
NSA - U.S.A. National Security Agency.
OCB - Offset Codebook Mode.
OFB - Output Feedback.
OS - Operative System.
P2P - Peer-to-Peer Systems.
PAN - Personal Area Network.
PDA - Personal Digital Assitant.
xv
PHT - Pseudo-Hadamard Transformation.
PKC - Public Key Cryptography.
PKIX - X.509-based Public Key Infrastructures.
QoS - Quality of Service.
RA - Registration Authority.
RAM - Random Access Memory.
RF - Radiofrequency.
RFD - Reduced Function Device.
ROM - Read-only Memory.
RSA - Rivest-Shamir-Adleman (PKC algorithm).
SKC - Symmetric Key Cryptography.
SOK - Sakai, Ohgishi and Kasahara (identity-based key exchange protocol).
SSL - Secure Sockets Layer.
STREP - Specific Targeted Research Project.
SW - Software.
TCP - Transmission Control Protocol.
TLS - Transport Layer Security.
TLS-PSK - Transport Layer Security Pre-shared Key Ciphersuites.
USN - Underground Sensor Network.
UTC - Universal Time.
UWSN - Underwater Sensor Network.
WEP - Wired Equivalent Privacy.
WPA - Wi-Fi Protected Access.
WPAN - Wireless Personal Area Network.
WSN - Wireless Sensor Network.
CHAPTER
1
PRELIMINARIES - SENSOR NETWORKS
In this chapter, we introduce the concept of Wireless Sensor Networks,
highlighting their features, their differences with other wireless paradigms,
their hardware and software elements, and their specific network stack
requirements. Later, we explain why sensor networks are very vulnerable against external and internal attacks. We show the security
mechanisms that can be used to protect the network from internal and
external threats, and present how these security mechanisms should be
included inside a sensor network. Finally, we explain the major goal
of this thesis: to specify a “complete set” of application-aware security mechanisms that are necessary to minimally enforce the security
properties needed by the applications.
1
2
1.1
Introduction to Wireless Sensor Networks
1.1.1
Sensor Networks paradigm
1.1.1.1
The need to “sense”
While there is no universal definition of life, it can be argued that one of the characteristics that can define any living being is the ability to respond to changes in their
environment and inside themselves [1]. The environment is full of physical events,
which can be felt using our senses. In fact, humans are known to have sensory
cells that fall into the following categories: photoreceptors (for light), mechanoreceptors (for touch, sound, and equilibrium), chemoreceptors (for smell and taste),
thermoreceptors (for heat), and nociceptors (for pain). Through these senses, we
can maintain our internal biological equilibrium (i.e. homeostasis), but also we can
picture the physical world that surround us.
In fact, we need to perceive the physical world in order to survive. There are
some the basic needs that, as human beings, we need to fulfill: find food and water
to stay alive, create a shelter where we can be safe from the weather and other
menaces, communicate with other beings to socialize and perpetuate the species [2].
But without our senses, it would not be possible to decide whether food is edible
or not, to choose an adequate place to sleep, to participate in a social environment.
Beyond survival, we also need our senses to satisfy more complex needs such as
identity, creation, leisure, and freedom [3]. Although we can live without some of
our senses, it is difficult to imagine life if we were completely cut off from the physical
environment.
In a certain degree, most computer systems do live that kind of life. Computer
systems by themselves cannot perceive the physical world directly, like living beings
do. they are capable of acquiring information from external and internal sources,
such as storage devices, human-machine interfaces, operative systems, and so on.
They can also communicate with other computer systems in order to exchange information. But the ability to perceive the physical world is not inherent to their nature:
Computer systems are tightly tied to the realm of the abstract.
The existence of sensor hardware tries to build a bridge between the abstract
world and the physical world. Sensors are devices that can measure a physical quantity and convert it into a digital signal. For example, specific sensors such as thermistors, hygrometers, and photodetectors, allow a computer to “feel” the temperature,
humidity, and light intensity of its surroundings, respectively. Using these sensors,
computer systems ranging from the simplest washing machines to the Large Hadron
Collider (a particle accelerator located at the European Organization for Nuclear
Research (CERN) [4]) can acquire and process information coming from the physical
world. The ability to “feel” the environment using the sensors is usually an integral part of the design of the computer system. Besides, the physical information
3
Base Station
FLAT
HIERARCHICAL
Figure 1.1: An overview of the architecture of WSN
obtained by these knowledgeable computer systems is usually limited in terms of
scope: sensors only provide very specific information about the internal state of the
systems and, in some cases, about the condition of their immediate surroundings.
However, it would be particularly interesting to go further in terms of multiplicity
and scope. The ability to “feel” the physical world should be available as an offthe-shelf component, so any computer system, regardless of its design, could be
able to perceive the physical world and use the available information to improve its
behaviour and/or increase its capabilities. Moreover, a computer system should be
able to perceive the physical information of any areas and entities that are related
to its functionality (e.g. in HVAC systems, the rooms of a building). The ultimate
purpose of this vision is to consider the existence of a new dimension, where any
element of the virtual world can be able to obtain information and interact with any
element of the real world.
The realization of this vision will require of an independent “sensory system”
capable of obtaining and processing physical information, with “sensory cells” that
can be deployed in areas and entities of interest. An approach that can simulate this
sensory system in a computer environment is the wireless sensor networks paradigm
(known also as sensor networks or WSN [46]), which is the central character of this
thesis.
1.1.1.2
An overview of Wireless Sensor Networks
The structure of a wireless sensor network can be seen in Figure 1.1. A wireless sensor
network is composed by two types of devices: sensor nodes, and base stations. The
4
sensor nodes, also known as motes or simply nodes, are small and constrained devices
that have the ability to “feel”, “think”, “talk”, and “subsist”. They can “feel”,
because they can sense the physical features of their surrounding (e.g. temperature,
humidity, radiation, vibration) using hardware sensors. They can “think”, because
although they are highly constrained in both computational power and memory, they
are capable of processing information on their own. They can “talk”, because they
are equipped with wireless transceivers, and can collaborate towards a common goal.
Finally, they can “subsist” because they are in most cases powered by batteries, and
can survive in their deployment field for more than a year if their internal operations
are optimized.
Regarding the base station, it is a more powerful device that usually behaves as
an interface between the services provided by the sensor nodes (the “data acquisition
network”) and the users of the network (the “data dissemination network”). Normally, the base station collects all the information coming from the sensor nodes and
stores it for later use. Also, it can issue control orders to the sensor nodes in order
to change their behaviour. While it would seem that wireless sensor networks are
highly dependent of the existence of this base station, the architecture of the network
is not centralized. The sensor nodes do operate in a decentralized fashion, managing
themselves without accessing to the base station. Even more, they can choose to
store the information of the environment until a base station is available.
A powerful simile that can be used to illustrate the structure of wireless sensor
networks is to consider them as “living beings”. The sensor nodes behaves as “cells”1 ,
since they all belong to the same body (WSN), are usually loaded with the same
“DNA” (program), and cooperate unselfishly towards a common goal. On the other
hand, the base station could be considered as the “brain” 2 , since it receives and
processes all the physical information coming from the “cells”, and can also send
control information to them. Note that, in terms of communications, the “cells” also
behave as “nerves”, since they transmit (wirelessly) the information sensed by other
“cells” to the “brain”.
The services offered by wireless sensor networks can be classified into four major
categories: monitoring, alerting, provisioning of information “on-demand”, and actuating. As for the first case, sensor nodes can continuously monitor certain features
of their surroundings (e.g. measuring the ambient noise level) and timely send such
information to the base station. Secondly, sensor nodes can check whether certain
physical circumstances (e.g. a fire) are occurring, alerting the users of the system
when an alarm is triggered. In the third case, the network can be queried about
the actual levels of a certain feature, providing information “on-demand”. Finally,
sensor nodes can be able to change the behaviour of an external system (e.g. an
1
More specifically, sensor nodes should be considered “sensory cells”, since they feel the environment. However, we will consider them as “cells” for simplifications purposes.
2
More specifically, the base station should be the “brain stem”, because it is in charge of sending
and forwarding information to / from the users (the real “brain”). However, we will consider it as
a “brain” for simplification purposes.
5
irrigation system) according to the actual state of the context (e.g. humidity of the
soil)3 . Due to the computational capabilities of the sensor nodes, it is possible to
reprogram the network during its lifetime, or even use it as a distributed computing
platform under specific circumstances.
Aside from their structure and their services, there are some features that help to
define what a wireless sensor networks is: specificity, autonomy, self-configurability,
long lifetime, deployment location, and mobility. The embedded intelligence of sensor nodes allow them to perform various tasks, but their services, protocols and
architectures are highly dependent on the functionality of the network, due to their
inherent constraints. Also, unlike other more capable devices such as PDAs, there
is no human user directly controlling the sensor node: motes are usually accessed
through other motes or through the base station. In fact, sensor nodes can set up
their services and function properly in situations where there is no central control
available. Due to this autonomy, sensor nodes need to self-configure and maintain
themselves during the lifetime of the network. Precisely, a wireless sensor network
can function for long periods of time, ranging from several days to one or two years.
Regarding the network deployment, sensor nodes are usually deployed near the physical source of the events, and the exact deployment location of these sensor nodes is
usually not known in advance. Finally, sensor nodes are usually not mobile, although
there might be scenarios where some sensor nodes or even the base station need to
move (e.g. tracking a target).
Wireless sensor networks can be organized in a completely distributed way (flat
configuration), but they can also implement levels of hierarchy (hierarchical configurations). In flat configurations, all the nodes contribute in the decision-making
process and participate in the internal protocols, like routing. Conversely, in hierarchical configurations the network is divided into clusters or group of nodes. Inside a
cluster all organizational decisions, like data aggregation, are made by a single entity
called cluster head. It should be noticed that it is also possible to have a combination of the two previous configurations into the same network; for instance, to avoid
situations where the “spinal cord” of the network - the cluster heads - fail and the
information must be routed to the base station.
1.1.1.3
Differences with Ad Hoc Networks
Due to their specific features, wireless sensor networks are capable of providing the
services that are needed to create a digital “sensory system”. However, there might
exist other network paradigms that can fulfill the same role. It is then necessary to
study which are the differences between the wireless sensor networks paradigm and
other paradigms, in order to consider the creation of solutions specifically designed
for sensor networks. As a result, it will be established whether the wireless sensor
networks paradigm is really an useful contribution to the world or not.
3
These type of sensor networks are also known as Wireless Sensor and Actuator Networks
(WSAN).
6
The paradigm that is more closely related to the wireless sensor networks paradigm
is the ad hoc network paradigm [5]. A wireless ad hoc network is a collection of
wireless devices that can dynamically self-organize into an arbitrary and temporary
topology to form a network without necessarily using any pre-existing infrastructure.
An extension to this paradigm is the mobile ad hoc network paradigm (MANET),
which is composed by a self-configuring network of mobile devices connected by wireless links. In fact, wireless sensor networks could be considered as a specific subset
of ad hoc networks with only a very simple difference: the devices in wireless sensor
networks are able to “feel”.
However, the differences between ad hoc networks and wireless sensor networks
are significantly greater. In fact, one of the major differences between these paradigms
is their actual purpose. Ad hoc networks do provide ubiquitous information access:
The devices of an ad hoc network, which are usually owned by an user and may
not be fully cooperative, will interact with the other devices of the network to get
the information its user needs. However, the main goal of wireless sensor networks
is ubiquitous information providing: all the autonomous sensor nodes collaborate in
order to get some information of the environment that will be provided to a certain
user. In biological terms, an ad hoc network can be seen as a symbiosis of different
organisms (devices), and their interactions can be categorized as being mutualistic
(mutual benefit), parasitic (one is benefited, one is harmed), or commensal (only one
is benefited). On the other hand, wireless sensor networks should be considered as a
complete organism, where all the “cells” (sensor nodes) always collaborate towards
a common goal.
Another significant difference is the structure of the network and the characteristics of the information flow. While ad hoc networks are usually completely distributed networks, in wireless sensor networks there exists a central control system,
the base station. Note that this central control system may be present or not, and
the sensor nodes are autonomous enough to function properly without it. Regarding
the information flow, it is normal for the devices of an ad hoc network to open a
communication channel with other device in the network as part of their normal
functionality. However, in wireless sensor networks, most traffic is sent from the
sensor nodes to the base station, and viceversa. Only in a few exceptional cases one
node will send information directly to another sensor node.
There are other minor differences between ad hoc networks and wireless sensor
networks. For example, the devices of wireless sensor networks are usually more
constrained in terms of computational power and memory. Also, the lifetime of
wireless sensor networks is usually higher than the lifetime of an ad hoc network,
and the number of nodes located in a wireless sensor network deployment is also
higher. Finally, the protocols and services used by the nodes must be optimized
to just provide the specific functionality needed by the users of the wireless sensor
networks, and also must consider, with a high level of priority, the amount of energy
spent by their operations.
7
Aside from the previously presented differences, there exist an additional difference between wireless sensor networks and mobile ad hoc networks. The device
population of a MANET is highly dynamic, since in most cases devices enter and exit
the MANET continuously (e.g. office workers entering and exiting a meeting room).
As a result, the network’s wireless topology may change rapidly and unpredictably.
On the other hand, the population of wireless sensor networks stays uniform, with
few nodes entering or exiting the network at a given time. In the case of wireless
sensor networks with some mobile nodes, those nodes usually stay inside the network,
moving from one part of the network to another.
1.1.2
Sensing the real world
1.1.2.1
A brief history of Sensor Networks
The wireless sensor networks paradigm that has been introduced in the previous
section is not novel. In fact, there were “sensor networks” before “wireless sensor
networks” came into being [6]. The first known deployments of a “sensor network”
occurred in the U.S. military, during the Cold War. For example, a system of acoustic sensors (hydrophones) was deployed at strategic locations on the ocean bottom to
detect and track quiet Soviet submarines. This system was called the Sound Surveillance System (SOSUS), and has evolved into civil system that monitors events in
the ocean, such as seismic and animal activity [7]. Other “sensor network” systems
included networks of air defense radars that defended the continental United States
and Canada. This system has also evolved over the years to include aerostats as
sensors and Airborne Warning and Control System (AWACS) planes, and is also
used for drug interdiction. These sensor networks generally adopted a hierarchical
processing structure, and in many cases, human operators played a key role in the
system.
Modern research on sensor networks started on the late seventies with the Distributed Sensor Networks (DSN) program at the U.S. Defense Advanced Research
Projects Agency (DARPA). Technology components for a DSN were identified in
a Distributed Sensor Networks workshop in 1978 [8]. These included sensor HW,
communication capabilities, processing algorithms including self-location, and distributed software. Artificial Intelligence was also being considered at the time, in
particular for understanding signals and assessing situations, as well as various distributed problem-solving techniques. The resulting DSN program had to address
distributed computing support, signal processing, tracking, and test beds.
There were various interesting results derived from the DSN program in the eighties. Researchers at Carnegie Mellon University (CMU) developed an indoor test bed
with signal sources, acoustic sensors, and VAX computers. This test bed focused
on providing a network operating system that allowed flexible, transparent access to
distributed resources needed for a fault-tolerant DSN [9]. Researchers at the Massachusetts Institute of Technology (MIT), Cambridge, focused on knowledge-based
8
signal processing techniques [10] for tracking low-flying aircrafts helicopters using a
distributed array of acoustic microphones. Other applications included distributed
vehicle monitoring using a functionally accurate, cooperative architecture [11], and
tracking multiple targets in a distributed environment by using multiple-hypothesis
tracking algorithms [12]. Still, the size of the devices that were part of these systems was significant, and also communication was done by Ethernet and (in extreme
cases) microwave radio.
It was the advances in micro-electro-mechanical systems (MEMS) technology,
wireless communications, and digital electronics that allowed the existence of presentday4 wireless sensor networks. While DARPA continued its military-oriented research
with the SensIT program (1999), whose goal was to create sensor networks to be used
in battlefield surveillance, reconnaissance, and targeting [13], new research programs
without military-oriented goals started to appear. For example, “The Disappearing Computer”, a FET Proactive Initiative in the E.U. 5th Framework Programme
influenced by the “pervasive computing” vision of Mark Weiser and other visionaries, started funding sensor network-related projects, such as “Smart-Its” [14]. Also,
civil applications that took advantage of the sensing capabilities of sensor networks,
such as health applications and home applications, were envisioned [46]. Finally, the
emerging importance of sensor networks related research resulted on the creation of
the first specific international workshops (ACM WSNA (2002), ACM SenSys (2003),
ACM/IEEE IPSN (2003), ACM SASN (2003), and EWSN (2004)) and Journals
(ACM Transactions on Sensor Networks (2005)).
1.1.2.2
Sensor Networks applications
The evolution of sensor networks into a generic wireless “sensing layer” for computer
systems has opened a wide range of application possibilities. These kind of networks
can not be considered as the “panacea” for all the sensing needs of computer systems,
since they are not specially suitable for very complex applications (such as the Large
Hadron Collider [4]) or applications with hard Quality of Service (QoS) requirements.
Nevertheless, because of their particular characteristics, the benefits of using wireless
sensor networks for sensing the real world are numerous:
• The network can survive in its deployment area for long periods of time.
• The network can be able to run unattended.
• The overall cost of the network is low, due to the price of the nodes and the
use of a wireless interface.
• The network can be deployed by non-experts, and can be easy to maintain.
• The network can react to abnormal events, maintaining the availability of its
services.
4
With “present day” I refer to “as of 2008”
9
There are many types of applications that can take advantage of all these benefits.
According to Culler et. al. [15], those applications can be classified into the following
categories:
1. Monitoring space. The sensor network simply monitors the physical features
of a certain environment. This category includes applications such as environmental and habitat monitoring, precision agriculture, indoor climate control,
surveillance, treaty verification, and intelligent alarms.
2. Monitoring things. The sensor network controls the status of a physical
entity. This category includes applications such as structural monitoring, ecophysiology, condition-based equipment maintenance, medical diagnostics, and
urban terrain mapping.
3. Monitoring interactions. The sensor network monitors the interactions of
things (both inanimate and animate) with each other and the encompassing
space. This category includes applications such as wildlife habitats, disaster management, critical (information) infrastructure systems, emergency response, asset tracking, healthcare, and manufacturing process flow.
While all the application areas presented in the previous classification are mere
ideas of where wireless sensor networks could be applied, the research community
have already proven the usefulness of wireless sensor networks in real-world settings.
Some examples of prototypes and research areas include: Monitoring of ageing infrastructures [21], critical (information) infrastructures [257], surveillance [22], detecting
equipment vibration [16], control of vineyards [17], water quality analysis [28], control of glacier behavior [18], monitoring of an active volcano [19], habitat monitoring
[20], firefighters assistance [29], monitoring of assisted-living residents [24][23][26],
healthcare [27], smart environments [25], checking availability of washing machines
[30], and optimization of HVAC systems [31]. In fact, wireless sensor networks have
already jumped from the research laboratories to the commercial world, with applications such as precision agriculture [32], pipeline and freighter monitoring [16], and
many others.
Not only wireless sensor networks are useful for providing services to specific applications, but also are an important part of the “pervasive computing” paradigm
and the “‘Internet of Things” paradigm due to their “sensing layer” nature. Envisioned by Mark Weiser in 1991 [33] and continued by other visionaries such as
Satyanarayanan [34], the major idea behind pervasive computing is that “computers
will disappear into the background, weaving themselves into the fabric of everyday
life until they are indistinguishable from it”. In other words: the environment itself will be saturated with computing and communication capabilities, yet gracefully
integrated with human users. The elements of that augmented environment (e.g.
urban spaces [35]) will collaborate to process information coming from both the real
10
world (e.g. traffic conditions, room temperatures) and the virtual world (e.g. internal state of traffic lights and air conditioner), providing context-adapted services to
themselves, other machines, and humans.
On the other hand, the vision of the “Internet of Things” [36] considers that all
the elements of these pervasive environments will be connected to the Internet, thus
objects and locations in the real world (e.g. restaurants, roads) will be linked to
information on the web. As a result, it will be possible to convert real-world events
into meaningful information that could be analyzed anywhere, providing real entities
(e.g. humans) and virtual entities with the capability of making better decisions. In
both paradigms, the sensor networks play an important role either by providing an
intelligent environment the ability to understand its context or by enhancing the
capabilities of a single entity (e.g. a toy) with the ability to “sense”.
By using the wireless sensor networks paradigm, we can be able to create a heterogeneous set of applications linking the real world with the virtual world. However,
a specific configuration of a wireless sensor network may not work for two different
applications. In fact, different applications have different requirements, and these
requirements will have a significant influence over the actual structure, architecture,
and protocols of a wireless sensor network. As an example, we can cite the transmission media used in the wireless communications. In underwater sensor networks
(UWSN [145]), sensor nodes are deployed below the ocean surface, and it is necessary to use underwater acoustic modems, which have low bandwidth and are prone
to communication errors. On the other hand, in underground sensor networks (USN
[37]) sensor nodes are deployed completely below the ground, where it is necessary
to cope with extra challenges such as path loss due to material absorption. These
differences in the transmission channel will influence on the behaviour of the sensor
nodes and on the behaviour of the sensor network as a whole.
1.1.3
Sensor node hardware and software
1.1.3.1
Node hardware
A sensor node is made up of four basic components: sensing unit, processor unit,
transceiver, and power unit, as seen in Figure 1.2. The sensing unit consists of an
array of sensors that can measure the physical characteristics of its environment,
like temperature, light, vibration, and others. The processing unit is, in most cases,
a microcontroller, which can be considered as a highly constrained computer that
contains the memory and interfaces required to create simple applications. The
transceiver is able to send and receive messages through a wireless channel. Finally,
the power unit provides the energy required by all components, and such energy
may come from either a battery or from renewable sources. Note that there can be
also other components depending on the needs of the application, like external data
storage (e.g. flash memory), location devices (e.g. GPS chips), or cryptographic
chips. This section will focus on the processing unit and the transceiver unit because
11
Other Components
Sensing Unit
Temp.
Light
Vibr.
…
External Storage
Microcontroller
Transceiver
Power Unit
Figure 1.2: Hardware elements of a sensor node
they largely represent the capabilities that are available to a sensor node. Notice that
the energy consumption of the transceiver is far greater than the energy consumption
of the microcontroller, thus sensor nodes are encouraged to do as much in-network
processing as possible [38].
Microcontroller devices. Microcontrollers are specially suitable for the wireless
sensor networks environment, due to their cost-effectiveness: a microcontroller used
in a sensor node has enough computational capabilities and memory for executing
simple tasks while consuming as less energy as possible. The selection of a microcontroller depends on what services has to provide to the node in terms of energy
consumption, instruction memory and RAM memory, storage, speed, and external
IO ports.
Class I
Class II
Class III
Model
Atmega168MSP430F16xATmega128L PXA271 ARM920T
Frequency
4Mhz
8Mhz
8Mhz 13(416)Mhz 180Mhz
Word size
8bit
16bit
8bit
32bit
32bit
RAM memory
1kB
10kB
4kB
256kB
512kB
Inst. memory
16kB
48kB
128kB
32MB
4MB
Power (awake) <1mA
2mA
8mA
31-44mA 40-100mA
Power (slept) 0.1µA
1.1µA
15µA
390µA
40µA
Table 1.1: Partial list of microcontrollers used in the sensor networks market
It is possible to classify the microcontrollers used in sensor nodes by their overall capabilities, as seen in Table 1.1. Some of them are extremely constrained, and
barely support the “de-facto” standard operating system for sensor nodes, TinyOS
[78]. These devices will be called “class I”. An example of this type of device is the
Atmega168, which is used by the Arduino Mini node [84]5 . On the other side of the
5
Another example of a class I node was the uPart node by Particle Computer GmbH [88], but
this node is out of production as of 2008.
12
spectrum, there are microcontrollers that are as powerful as the microprocessors used
in PDAs, and can host complex operating systems or Java-based virtual machines.
These devices will be named “class III”. Examples of these devices are the PXA271
and the ARM920T, which are used in the iMote2 [85] and the SunSPOT [90], respectively. Finally, the devices that are resource-constrained but powerful enough to
hold a complex application will be known as “class II”. This is the most common
type of device for sensor nodes, and there are many microcontrollers that fall into
this category. One of them is the ATmega128L, used in the MICAz [85]6 , Mica2 [85]
and BTNode [86]. Another example is the MSP430F16x family, which is integrated
in the Tmote Sky [87], TelosB [85], and MSB nodes [89]7 .
Transceivers. One of the major features of sensor nodes are their ability to send
and receive messages through a wireless channel. Thus, it is necessary to integrate
a transceiver (i.e. transmitter-receiver) unit in the node. These transceivers have
to offer an adequate balance between a low data rate (e.g. between 19.2Kbps and
250Kbps) and a small energy consumption in low-voltage environments (i.e. around
3V), allowing the node to live for a extended period of time. Because of these reasons,
standards such as 802.11 cannot be used in this kind of networks.
Narrowband
Wideband
Model
CC1000
CC1020
CC2420
ZV4002
Frequency
300-1000Mhz 402-940Mhz
2.4Ghz
2.4Ghz
Max. Data Rate 76.8kbps
153.6kbps
250kbps
723.2kbps
Modulation
FSK/OOK FSK/GFSK/OOKDSSS-O-QPSKFHSS-GFSK
Turn on time
< 2ms
< 2ms
< 1ms
—
Power (RX)
9.6mA
19.9mA
18.8mA
65mA
Power (TX)
16.5mA
20.5mA
17.4mA
65mA
Power (slept)
< 1µA
< 1µA
< 1µA
140µA
Security
none
none
AES-128
SC-128
Table 1.2: Partial list transceivers used in the sensor networks market.
Transceivers in sensor networks can be divided into two categories, as seen in
Table 1.2: narrowband radios and wideband radios. Narrowband radios have less
throughput and are more susceptible to noise, but they have less power consumption
and faster wakeup times. These advantages and disadvantages of narrowband are
reversed in wideband radios: they are faster and more robust, but also more powerdemanding and slower to wake up. Narrowband radios work at lower frequencies
(433Mhz and 868Mhz in Europe, 915Mhz in USA), while wideband radios usually
work at higher frequencies (2.4Ghz). The most common narrowband transceiver is
6
An advanced version of the MICAz node, known as IRIS, provides 8kB of RAM instead of 4kB.
Note that the computational capabilities of the MSB nodes are slightly higher than the TelosB,
with 55kB ROM and 5kB RAM.
7
13
the CC1000, used by the BTNode [86] and the Mica2 [85]. A chip with similar
characteristics, the CC1020, is used on the MSB [89] nodes. On the wideband side,
the most common chip is the Chipcon CC2420, which is used by the MICAz [85],
TMote Sky [87], SunSpot [90], and IMote2 [85]. Other sensor nodes, like the BTNode
[86], use the bluetooth-enabled ZV4002 chip.
While a sensor network might employ the bluetooth standard for the wireless
channel, the energy consumption and other features of this standard discourages its
use. There is another standard that is more suitable for wireless sensor networks
context: IEEE 802.15.4 [57] for low-rate wireless personal area networks (PANs).
This standard specifies both the physical and medium access control layers, and
although it was aimed to PAN, it can provide a good data rate and a relatively
low energy consumption to sensor networks. The standard also provides support
for clustered sensor networks, differentiating between cluster heads (coordinators,
or FFD) and leaves (RFD). Nevertheless, the TinyOS network stacks use just some
of the capabilities of the IEEE 802.15.4 standard, although it can be possible to
implement the whole standard in a sensor node [77].
1.1.3.2
Operating systems
Operating systems (OS) manage the tasks and resources of a computer and provide
an interface to those resources that can be used by programmers and users. There
are many embedded devices that do not use or need an operating system, but the use
of an OS for sensor nodes can provide an efficient access to the hardware services and
simplify the development of applications [81]. Such OS must comply with certain
features given by the existing constraints: smallness in size, low energy consumption
capability, limited parallelism and event handling, and a good controller hierarchy.
Even more, a node OS should also provide services that are important to a sensor
node, such as communication protocols and neighbour discovery.
Initially developed by the U.C. Berkeley EECS Department, the “de-facto” standard operating system for sensor networks is TinyOS8 [78]. TinyOS is a low-footprint,
stable, portable OS based on modular components. These components can connect
to other components, post low priority tasks, and react to asynchronous events. Also,
TinyOS allows a good balance between portability and optimization by means of a
three-tier Hardware Abstraction Architecture (HAA), which provides three different
levels of abstraction. Finally, TinyOS facilitates the development of applications
by using a component-based extension to the C language, nesC. Note that, in order to simplify the structure of the OS, TinyOS does not provide dynamic memory
allocation and preemptive tasks, amongst other things.
Besides TinyOS, there are other OS with different design goals. For example,
Contiki [79] provides a very lightweight event-driven kernel protothread with optional
per process preemptive multithreading, and includes partial support for dynamic
8
As of 2008, the version of TinyOS is 2.0.2
14
Figure 1.3: Layered architectures for sensor nodes
allocation of memory. Full support for dynamic allocation of memory, alongside
with support for loadable modules, is offered by the SOS operating system [80]. All
these operating systems try to optimize the resources of the node, but there are other
abstractions, like the Java Virtual Machine used by the Sentilla motes [87], that are
focused on providing solutions for developing, deploying, integrating and managing
software solutions. Since every mote OS is based on different design principles,
the choice of an operating system for an specific sensor network mainly depends
on whether a certain OS provides the services and features that the application
developers need [81].
1.1.4
Network stack - cross-layering
Sensor networks are highly dependent of their communication channel. Without
proper connectivity, sensor nodes are not able to provide users with the information
obtained from its hardware sensors. Even more, no connectivity means no cooperation between nodes. As a result, it is very important to define an optimized network
stack for sensor networks. As mentioned in section 1.1.3.1, sensor nodes usually
use the IEEE 802.15.4 standard for the physical and medium access control layers.
However, it is not yet clear how the upper layers should be designed, because the
rigid layered communication architecture may not be completely suitable for sensor
networks. This particular issue is discussed in this section.
Traditionally, network design has followed a layered communication architecture.
In this architecture, communication tasks are separated into several layers, with
a clear definition of the functionality of each layer. In a layered communication
stack, interaction among layers occurs through well-defined standardized interfaces
that connect only the neighbouring layers in the stack. By using this approach, it
can be possible to provide a high degree of modularity and interoperability among
15
heterogeneous networks.
The benefits of using a well-defined layered architecture are numerous. Modularity provides the abstractions necessary for designers to understand the overall
system. It accelerates development of both design and implementation by enabling
parallelization of effort. Designers can focus their effort on a particular subsystem
with the assurance that the entire system will interoperate. Moreover, individual
modules can be upgraded without necessitating a complete system redesign, increasing the longevity of the system. Widely used in wired networks (e.g. the Internet
TCP/IP model), this kind of architecture can be also applied to wireless networks,
including sensor networks (cf. Figure 1.3) [46].
However, is precisely in the field of wireless networks where this traditional network stack point of view is being challenged. The unique problems created by wireless
links, the resource constraints inherent to sensor nodes, and many other design challenges, are enabling the development of novel cross-layer designs. Cross-layer design
enables different layers of the communication stack to share state information or to
coordinate their actions. For example, supplying information on a node’s remaining
battery energy to all of the nodes’ communication layers.
The use of a cross-layer approach in a wireless network environment yields many
advantages. Nodes must be able to manage several performance aspects, such as
power management, that cut across traditional layers. Also, nodes should have
access to their current resources and processes (e.g. wireless channel link properties),
which contributes favorably to the autonomy and self-configurability of the node.
This ubiquitous access to control and information is even more necessary due to the
inherent constraints of the nodes, that requires fine-grained optimization techniques,
and due to application-specific performance requirements, that suggest the need for
a general model that is tuneable to each application.
There are some aspects that have to be taken into account when designing crosslayer architectures. Cross-layer design opens the floodgate of information flow across
layers, raising concerns on multiple, sometimes subtle, interactions among existing
layers. This makes the architecture more difficult to develop and maintain, as there
may be some new dependencies that must be taken into account. Also, the introduction of excessive and uncontrolled interactions can break the design of the system,
hindering its usefulness and longevity [39]. As a result, cross-layer designers must
consider the impact of their design with a holistic view that includes the long-term
development and innovation considerations. The benefits of the different cross-layer
design proposals and its possible coexistence should be studied in more deep [40].
Still, as of today, there have been both academic and standard network stacks that
implement some cross-layer optimizations in sensor networks.
1.1.4.1
Academic cross-layer architectures
The use of cross-layer optimizations and architectures has been widely considered in
sensor networks designs and prototypes developed in the academia. In fact, in his
16
Figure 1.4: Outline of the ZigBee stack architecture
seminal paper of 2002, Akyildiz considered the existence of transversal management
planes interacting with the layered architecture [46]. Later, he even changed his
initial point of view regarding sensor networks architectures and considered that
the best solution is to use a unified cross-layer module [41]. Other architectural
examples for wireless sensor networks include TinyCubus [42], The “Sensor Protocol”
[43], SensorStack [44] and many others. Even more, the “de-facto” standard O.S for
sensor networks environments, TinyOS, introduces cross-layer optimizations as a part
of its core design [78].
The aspects of a network layer that should be included into a cross-layer design
for sensor networks are outlined by all these architectures. First, there are some
services that should be accessed by all the layers of the network: power management,
network discovery, localization, synchronization, and security. Second, the network
architecture should follow a component-based approach, where the functionality that
is used by two or more layers (e.g. encryption of messages) should not be replicated.
Third, there should exist mechanisms that allow one layer of the network to access
the services of non-adjacent layers, for optimization purposes (e.g. one application
accessing the hardware services directly). Finally, it should be required to have
certain mediators that provide system information and internal information from
other layers through well-defined interfaces.
17
1.1.4.2
ZigBee standard
One of the suites of high level communication protocols that have been standardized
and applied to some sensor networks deployments is the ZigBee stack [45]. Created in
2004 by the ZigBee Alliance, the major purpose of the ZigBee stack is to enable broadbased deployment of low cost, low power wireless networks that addresses the needs of
remote sensing, monitoring and control. In particular, the ZigBee stack is targeting
the following applications: Advanced Metering Infrastructure (AMI), Commercial
Building Automation (CBA), Home Automation (HA), Personal, Home and Hospital
Care (PHHC), Telecom Applications (TA), and Wireless Sensor Applications (WSA).
For wireless sensor networks, as of 2008 the ZigBee Alliance is still defining the profile
specification that will allow the creation of sensor networks applications through
ZigBee.
Figure 1.4 shows an overview of the ZigBee network stack, which operates over
the IEEE 802.15.4 standard. The network stack is organized into several layers: Network (NWK) layer, and Application (APL) layer. The network layer allows end-toend communication and multi-hop capabilities. The Application layer is partitioned
into several subcomponents: the Application Support Sublayer, which combines the
functionality of a traditional transport layer and of an application layer, the ZigBee
Device Object, in charge of storing design parameters and management commands,
and the Application Framework, containing the application profiles.
While the ZigBee network stack follows a layered approach, there are some crosslayer interactions. For example, the ZDO Management Plane allows all the ZigBee
layers to access the design information and management commands included inside
the ZigBee Device Object. Also, the Security Service Provider acts as a component
that is shared by the Network Layer and the Application Support Sublayer, and its
main task is to provide security mechanisms for data encryption. Besides from these
specific optimizations, the ZigBee stack does not consider the existence of certain
transversal services that should be used by all layers, such as power management.
Also, aside from the management planes, the ZigBee stack follows a strict layered
approach, where the application layer cannot have access to the services provided by
the link layer.
1.2
1.2.1
Wireless Sensor Networks security
Security threats
In any environment, either physical or logical, there exists the need of maintaining someone or something safe, away from harm. This is the role of security. On
any computer-related environment, security can be considered as a non-functional
requirement that maintains the overall system usable and reliable, protecting the
information and information systems. In fact, in wireless sensor networks, security
18
is of paramount importance: the network must be adequately protected against malicious threats that can affect its functionality. Due to the role of sensor networks as
a “sensory system”, any disturbance in a sensor network may have consequences in
the real world.
However, achieving this goal is not an easy task, because sensor networks are
especially vulnerable against external and internal attacks due to their peculiar characteristics. The devices of the network (i.e. sensor nodes) are highly constrained in
terms of computational capabilities, memory, communication bandwidth and battery
power. Additionally, it is easy to physically access such nodes because they must
be located near the physical source of the events, and they usually are not tamperresistant due to cost constraints. Furthermore, any internal or external device can
access to the information exchange because the communication channel is public.
As a result, sensor networks have to face multiple threats that may easily hinder
its functionality and nullify the benefits of using its services. These threats to WSN
can be categorized as follows:
• Common attacks
• Denial of service attack (DoS)
• Node compromise
• Impersonation attack
• Protocol-Specific attacks
Due to the features of sensor networks, there are some specific attacks targeting
the communication channels. An adversary can easily retrieve valuable data from the
transmitted packets that are sent (Eavesdropping). That adversary can also simply
intercept and modify the packets’ content meant for the base station or intermediate
nodes (Message Modification), or re-transmit the contents of those packets at a later
time (Message Replay). Finally, the attacker can send out false data into the network,
maybe masquerading as one of the nodes, with the objectives of corrupting the
collected sensors’ reading or disrupting the internal control data (Message Injection).
Since sensor networks are wireless service-oriented infrastructures, one of the
most problematic attacks that they may face is the Denial of Service attacks (DoS).
A DoS attack on a WSN may take several forms. The most important are the
following: Node collaboration, in which a set of sensor nodes act maliciously and
prevent broadcast messages from reaching certain section(s) of the sensor network,
jamming attack, in which an attacker jams the communication channel and avoid
any member of the network in the affected area to send or receive any packet, and
exhaustion of power, in which an attacker repeatedly requests packets from nodes to
deplete their battery life.
A sensor node is considered as being compromised when an attacker, through
various means, can either read or modify its internal memory. Attacks can be invasive
19
or non-invasive. An invasive physical attack is defined as an attack where the attacker
physically breaks into the hardware by modifying its hardware structure (e.g. using
focused ion beam, or drilling a hole in the storage media). On the other hand, A noninvasive attack is defined as an attack where the data is taken from the hardware
device without any form of structural modification done to the device itself (e.g.
taking advantage of the JTAG interface [49] ). Various complex attacks can be easily
launched from compromised sensor nodes, since the subverted node is a full-fledged
member of the network.
The most common attacks that can be launched using a compromised node are the
impersonation attacks. In an impersonation attack, a malicious node impersonates
a legitimate node, and uses its identity to mount active attacks such as sybil attacks
or node replication attacks. In a Sybil attack, a single sensor node takes on multiple
identities to deceive other sensor nodes. A sensor node that wishes to conduct the
Sybil attack can adopt a new identity by creating a new identity or by stealing the
identity of an existing sensor node. On the other hand, node or identity replication
is the simple duplication of sensor nodes. As sensor nodes tend to be physically
unprotected, it is feasible for an attacker to capture, replicate and insert duplicate
nodes back into selected regions of the network. Node replication is different from a
Sybil attack in that the multiple sensor nodes are duplicates and basically have the
same identities.
Complex attacks from subverted nodes can target the internal protocols used in
the network, such as routing. Attacks against routing protocols in a WSN fall into
one of the following categories [174] : corruption of the internal control information such as the routing tables (Spoofed Routing Information), selective forwarding
of the packets that traverse a malicious node depending on some criteria (Selective
Forwarding), creation of a “wormhole” that captures the information at one location and replays them in another location either unchanged (Wormhole attack) or
tampered (Sinkhole attack), creation of false control packets during the deployment
of the network (Hello Flood Attack), and creation of false acknowledge information
(Acknowledgment Spoofing). Other protocols can be attacked as well, such as data
aggregation (e.g. by forging the data before, during of after the aggregation process).
1.2.2
Security mechanisms for Sensor Networks
As we have previously seen, sensor networks are vulnerable to external and internal
attacks. The effects of those attacks in the network are not trivial, since they can
render the services of the network useless. It is clear that there is the need of
using security mechanisms either to prevent the attacks from influencing over the
functionality of the network or to minimize the adverse effects of such attacks. By
using the security mechanisms, it can be possible to enforce in sensor networks the
following security properties:
• Confidentiality. A given message must not be understood by anyone other than
20
the desired recipients.
• Integrity. The data produced and consumed by the sensor network must not
be maliciously altered.
• Authentication. The information received by the sensor nodes and the base
station must come from a valid member of the network.
• Authorization. Only authorized entities (sensor nodes and base station) can
be involved in providing information to the network.
• Availability. The users of a sensor network must be capable of accessing its
services when they need them.
• Freshness. The data produced by the sensor network must be recent.
• Self-Organization. Every sensor node must be independent and flexible enough
to self-organize and self-heal itself according to different situations.
In a sensor network context, the existing security mechanisms try to protect the
hardware of the sensor nodes, the communication channel, and the protocols and
services. By protecting the hardware of the sensor nodes, it is possible to detect
and/or prevent attacks that try to compromise a sensor node. A secure communication channel cannot be affected by most of the common attacks (eavesdropping,
modification, replay, and injection) that affect the exchange of messages between the
sensor nodes. Finally, with the adequate support, the protocols and services used
in the network can tolerate the existence of service disruptions and complex attacks
[259, 263].
1.2.2.1
Hardware protection
Sensor nodes are easy to access, since they have to be physically near of the event they
monitor. As a result, an adversary can try to compromise a sensor node. Once the
attacker obtains, subverts, and takes control over a sensor node, it can access to its
internal information, and also use it for malicious purposes by launching complex or
stealthy attacks. Therefore, there should be some kind of protection on the hardware
layer to avoid such attacks, like a tamper proof module (TPM). Such modules allow
the security credentials to be stored securely, preventing an attacker from retrieving
the credentials when the sensor node is compromised. Once a tampering of the chip is
detected, the TPM will destroy the keys and other information stored in the module.
Unfortunately, although adding a TPM into a sensor node would help to defend
against node compromise, the addition of the module will also significantly increase
its overall cost. As a result, it is necessary to use other software-based mechanisms
that are not dependent on any hardware configuration. Code attestation techniques
can not directly defend against node compromise, but they can be able to detect
21
whether a certain node has been compromised or not. Also, code obfuscation techniques increase the complexity of analysing the memory of a node.
Code attestation. Software based attestation enables a third party to verify the
code running on the system to detect any maliciously altered code. Usually code
attestation is done through the use of special hardware mechanisms proposed by the
Trusted Computing Group (TCG) and Next Generation Secure Computing Based
(NGSCB). However, these hardware mechanisms are costly and are not implemented
in the current version of the nodes, as of 2008. Thus this kind of software attestation
is designed to provide the detection of malicious code alteration and verify that the
nodes are using the correct codes.
A verification procedure is needed to effectively verify that the node’s code is
correct and not maliciously altered. A verifier needs to generate a random challenge
to be sent to the node. The node will then use this challenge to generate a response
using the verification procedure. The verifier will then compare the response against
an expected value. Any discrepancy would imply that the code in the node has
been modified. Data used in the code attestation usually includes the clock speed,
instruction set architecture, the memory architecture of the microcontroller and the
size of the device’s memory.
The verification procedure is mostly based on the “pseudorandom memory traversal” concept: using a seed (i.e. the random challenge) provided by the verifier, the
node must randomly access some positions of its own memory, summarizing them
into one report that will be used as a response. If the node is malicious, the time
used on calculating a valid response will be longer, and such delay can be detected
by the verifier [69]. An improvement over this basic scheme consist on sending an
obfuscated attestation routine alongside with the seed, thus delaying even more the
efforts of the malicious adversary to reply with a valid response [70].
Code obfuscation. Code obfuscation, or diversification, is a mechanism that allows the protection of a valuable piece of information (e.g. the security credentials)
contained inside the node. By obfuscating the code and data, the amount of time
needed by the attacker to analyze the compromised nodes will increase, thus it will
be more difficult to deduce the secrets from the extracted contents of program flash,
the EEPROM or the SRAM. The obfuscation methods must not be equal for all the
nodes. This is to prevent the attacker from using the same method to retrieve the
secrets once he/she is successful in compromising one node.
Those diversification techniques may include stack randomization, instruction set
randomization, library randomization, and system call randomization. In a sensor
node, it is possible to hide vital information, such as the secret keys, using a hash
function to scramble the information in the data segment [47]. By hiding the keys
in a randomized manner, it would be difficult for the attacker to find the keys from
the downloaded EEPROM.
22
1.2.2.2
Secure communication channels
In sensor networks, all devices communicate through a wireless channel. As a result,
the information flow can be easily accessed by anyone in the vicinity, and all packets
are unprotected against any kind of communication attack. Therefore, it is necessary
to establish a secure communication channel between sensor nodes, where no attacker
can eavesdrop, modify, replay, or inject messages. In order to create this channel it is
necessary to use security primitives, and it is also essential to distribute the security
credentials (secret keys) needed by such primitives.
Security primitives. Security primitives allow the sensor nodes to give a minimal
protection to the information flow, and can also be used as a foundation to create
secure protocols. Those security primitives are symmetric key cryptography schemes
(SKC), hash primitives, and public key cryptography (PKC). Since sensor nodes are
highly constrained in terms of resources, implementing the security primitives in
an efficient way (using less energy, computational time and memory space) without
sacrificing the strength of their security properties is one of the most important
challenges in this area.
Symmetric Key Cryptography (SKC) primitives use the same secret key to hide /
unhide information through encryption and decryption. Instances of these primitives
are able to provide confidentiality to a certain information flow, given that the origin
and the destination of the data share the same secret key. They can also provide
integrity and authentication if a certain mode of operation is used.
Cryptographic hash functions or hash primitives are utilized in order to compress
a set of data of variable length into a set of bits of fixed length. The result is a
“digital fingerprint” of the data, identified as a hash value. A cryptographic hash
function must satisfy two properties: i) given a hash value h, it should be hard to find
a message m such that hash(m) = h, and ii) it should be hard to find two different
messages m1 and m2 such that hash(m1 ) = hash(m2 ). Hash functions are typically
used for assuring the integrity of the information flow, providing a unique fingerprint
for every packet in the form of a Message Authentication Code (MAC).
Finally, Public key cryptography (PKC), also known as asymmetric cryptography,
is a form of cryptography that uses two keys: a key called secret key, which has to
be kept private, and another key named public key, which is publicly known. Any
operation done with the private key can only be reversed with the public key, and vice
versa. This nice property makes all PKC-based algorithms useful for authentication
purposes. Still, the computational cost of calculating their underlying operations
had hindered its application in highly-constrained devices, such as sensor nodes.
Key management. In order to create and share a secure channel by using security
primitives, the sensor nodes need to share certain security credentials. For example,
in SKC, when one node A encrypts the information with a certain secret key K, the
other node B will need the same secret key K for obtaining the original information
23
through decryption. The task of generating and distributing those keys has to be
done by a Key Management System (KMS).
There are three basic factors that every key management system for sensor networks should adequately fulfil: key storage, key distribution, and key maintenance.
• Key storage policies indicate the number of keys that a sensor node needs to
store in order to open a secure channel with other peers.
• Key distribution protocols define how the keys are issued to the sensor nodes.
A sensor node can receive its keys before the initial deployment of the network
or create its keys after the deployment using preloaded information.
• Key maintenance procedures specify how a sensor node can be included into
or erased from the network, receiving or nullifying a set of keys in the process.
There are two extreme design cases for a key management system: global keying
and pairwise keying. In global keying, a single key is created for the entire network,
and all the secure communications must be encrypted with that key. In the other
case, pairwise keying, a node must store a key for every other node inside the network,
thus every pair of nodes will have a particular secure channel.
These two cases are not feasible in a real scenario. In global keying, any tampered
sensor node will reveal the global secret key, thus opening all the communications of
the network to any potential attacker. Also, pairwise keying is not a scalable solution
due to the memory constraints of the sensor nodes. Therefore, security researchers
have been trying to develop more optimal solutions that are scalable and resilient,
amongst other properties. The existent systems developed by researchers can be
classified into four frameworks: “Key Pool” Framework, Mathematical Framework,
Negotiation Framework, and Public Key Framework. Every framework provides
different properties, and there is no framework that is completely adequate for every
sensor network scenario.
1.2.2.3
Protocols and services: core protocols
While protecting the communication channel keeps sensor networks safe against certain attacks, it does not entirely guarantee that other attacks will not affect them.
For example, a DoS attack can stop the provisioning of the services, and other
protocol-specific attacks crafted by malicious insiders can influence over the internal
behaviour of the network. Therefore, it is necessary to i) strengthen the minimal set
of protocols that sensor networks need in order to function properly (i.e. its “core”
protocols), and ii) create specialized protocols and services that can adequately provide support for the protection of the network. The following paragraphs will focus
on the core protocols of the network, which are routing (transmitting a packet from
one sensor node to another sensor node), data aggregation (briefing many sensor
readings into one single piece of data), and time synchronization (synchronizing the
clocks of the network).
24
Routing. Designing routing algorithms is a challenging area. All the nodes inside
a sensor network should be reachable (connectivity) while covering the maximum
possible area of environment using their sensors (coverage), even when the nodes inside the network start to fail due to energy issues or other problems (fault tolerance).
The algorithm should also work with any network size and node density (scalability)
and provide a certain quality of service. At the same time, designers must try to
lower the memory usage, speed, and energy consumption of the algorithms.
Security is another factor that cannot be ignored in the design of routing algorithms. Any potential adversary has a wide range of attacks at his disposition [174]
to manipulate the routing subsystem and take control over the routes, resulting in
eavesdropped, altered, spoofed or discarded packets. He can direct traffic over his
own nodes by advertising them as nodes with better (real or fake) connectivity or
speed. He can alter the routing control packets on his own benefit, and also spoof
the identity of the nodes using a sybil attack [63].
The key infrastructure may help in the protection against routing attacks by
authenticating nodes and protecting the confidentiality and integrity of the packets,
but it is not enough to protect the routing infrastructure. Any adversary can take
control of a set of legitimate nodes of the network and modify or discard any control
messages on his own benefit. He can also attack the network or certain sections of
it using a denial of service attack, jamming the communication signal or colliding
certain control packets. Therefore, it is essential to make the routing algorithm robust
against such attacks, by means of multiple braided paths, restricting the structure
of the topology, and other protection mechanisms.
Data aggregation. Inside sensor networks, the nodes generate an immense amount
of raw data product of their measurements. In most cases all these information must
be sent to the base station, thus there is a great cost, in terms of energy consumption and bandwidth usage, on transporting all the data from the nodes to the base
station. However, since nodes are physically near each other, there will be some data
redundancy. The role of aggregation is to exploit this redundancy by collecting the
data from a certain region and summarizing it into one report, hence decreasing the
number of packets sent to the base station.
Aggregated data can be easily attacked by a malicious adversary, even if the
communications are protected against any data injection attack or data integrity
attack. If an aggregator node is being controlled by an adversary, it can easily ignore
the data received from its neighbours and create a false report. Trusted aggregators
can still receive false data from faulty nodes or from nodes being controlled by an
adversary.
By using strong aggregation functions that are resilient against internal attacks, it
should be possible to defend the network against false data coming from malicious or
faulty nodes [72]. Another possible solution is to try to discover whether the reports
sent by a malicious aggregator are forged or not. One approach is to query the
aggregator itself about the data used to create the report [66]. Other approaches take
25
advantage of the density of sensor networks by using the nodes in the neighbourhood
of the aggregator as witnesses [51]. Finally, it is also possible to filter the packets
containing the report and the proofs in their way to the base station, hence decreasing
the amount of traffic created by false aggregations [76].
Time synchronization. The major task of sensor networks is the collection of
data from a certain physical environment. But the data itself should be linked to
the time it was collected in order to be properly used. Although sensor nodes are
able to know the local time, i.e. the time that has passed after the moment they
were born, it is necessary to create a set of protocols that allow the maintenance of
a global time. Such protocols are also essential for synchronizing the clocks of the
sensor nodes, avoiding problems such as clock drifts. If these issues are not dealt
with, services such as tracking and localization may provide erroneous results.
A time synchronization protocol must comply with certain design principles. The
use of high-demanding energy devices such as GPS should be limited to powerful
nodes (energy efficiency), the number of transmissions should be kept to a bare
minimum (transmission efficiency), factors such as the latency error and the jitter
should be taken into account (end-to-end latency), and the protocols should deal
with message loss and problems in message delivery (fault tolerance) [71]. Finally,
the protocol must stay secure: any protocol that incorrectly updates the clock of a
single sensor node can easily thwart the behaviour of the entire system.
Possible countermeasures against the security problems [178] include using authenticated broadcast mechanisms for avoiding the existence of malicious external
entities or compromised sensor nodes changing the clock information. Also, it is
possible to take advantage of the redundancy of the network, allowing many sensor
nodes to serve as the root for the global time in case no base station is present or
near, or letting one sensor node to get the time information from many sources discouraging the existence of a malicious entity with an abnormal clock drift. At last,
the sensor nodes can use approximations to get an upper bound on the error that
could be induced by an adversary, and use such approximation in case there is no
reliable information around.
1.2.2.4
Protocols and services: supporting protocols
Once the security of the core protocols have been discussed, the following paragraphs
will focus on introducing certain security mechanisms and systems that can assist the
decision-making processes of a sensor node. Besides, it will also show other protocols
and services that also need to be protected.
Intrusion Detection Systems. An intrusion can be defined as a set of actions
(i.e. attacks), either external or internal to a certain system, that can lead to an
unauthorized access or alteration of the system. The mission of an IDS (cf. [67])
is to monitor a certain system in order to detect possible intrusions in the network,
26
alert users after intrusions had been detected and, finally, reconfigure the network
provided that is possible. In a WSN environment, such IDS allows sensor nodes to
monitor themselves and to react to the abnormal situations in their environment,
providing an infrastructure that protects their normal operations and detects and
reacts to any possible attacks against network services.
An Intrusion Detection System must decide carefully where to locate its detection
agents, due to the distributed nature of the network and the constraints inherent
to the nodes. Choosing an adequate set of lightweight detection procedures, like
automata, packet analysis, and health monitoring systems, is also of importance.
Finally, agents should be able to collaborate in the detection processes, and send the
alerts to the base station for the sake of informing the user of the system about any
abnormal behaviour.
Trust Management Systems. The concept of trust (“the firm belief in the reliability or truth or strength of an entity”) derives from sociological or psychological
environments, and it can be applied to a computer environment. It helps the members
of a network to deal with uncertainty about the future actions of other participants.
As a result, trust becomes specially important in distributed systems such as sensor
networks because it may assist the execution of other protocols and services, by using
the output of a trust management system as an assistant in their decision-making
process.
It is possible to point out some aspects that can be considered crucial for creating
a satisfactory trust system. One is the initialization of the trust model. Another is
the interpretation of the events that occur during the lifetime of the network [54].
The evolution and density of the events that occur in sensor networks are also of
importance. Finally, due to the constraints of the nodes, it is imperative to balance
the overhead of the data collection process, and to make both these processes and
the trust and reputation models as lightweight as possible.
Authenticated broadcast and authenticated streams. The communications
model of sensor networks is mostly base-station centric: all sensor nodes have to send
the information they collect about their environment to the base station. Nevertheless, the base station can also send control information to a certain subset of the
sensor nodes of the network. The base station is considered by the sensor nodes as
a completely trusted entity. Consequently, it is of extreme importance to assure the
authentication of the packets that supposedly come from the base station. It may
be possible to use PKC for signing the contents of the message, or use SKC-based
techniques like µTESLA [65] in order to save resources.
However, in certain cases, it may be necessary to check for the authenticity and
integrity of a complete stream of data. This is the case of code update protocols,
which allow the whole network to be reprogrammed from the base station (sending
either interpreted code [61] or machine code [56]) by using the wireless channel. For
this purpose, it is possible to sign and send the hashed value of the entire stream, or
27
Cross-Layer
Transversal Sec. Layer
Layered Architecture
Service 1
Application Layer
Transport Layer
Network Layer
Service N
Link Layer
Physical Layer
Figure 1.5: Security as a transversal layer
include inside the signed i packets the hash value of the i+1 packets (i.e. hash-chain)
[52], or to use one-time signatures alongside with those hash-chains [59].
Other issues. There are many other security issues that have to be taken into
account while using sensor networks. For example, in case a sensor network is organized into zones (e.g. kitchen, bedroom, etc) using an overlay, it is necessary to
offer secure methods to manage that overlay, such as secure node lookup protocols.
Also, there may be some mechanisms that allow a fine-grained access control in case
the users can directly query the contents of a sensor network through delegated base
stations. Those delegated base stations have delegated privileges from the main base
station, thus in this context is essential to organize the delegation of privileges, granting or revoking them if necessary. There are other aspects that need to be protected
if included inside a sensor network, such as distributed computing, secure location,
secure mobile base station location, and so on. Moreover, other aspects such as
the existence of random number generators in sensor nodes [60] should be analyzed
carefully.
As a final note, there is a security property that is very important in certain
scenarios: Privacy [64]. For example, in a battlefield, it would be important to
hide the location and identities of the base station and the nodes that generated
the information. In contrast, in an earthquake rescue situation locating the source
nodes (if the nodes are worn by, for example, dogs) is an absolute must. Note that
this property can transcend beyond the technological dimension and affect its social
environment, since sensor networks could be used as a surveillance tool to collect
data about the behaviour of human beings.
1.2.3
Security as a transversal layer
In order to properly use the security mechanisms in wireless sensor networks, it is
necessary to include them inside a communication architecture. Even more, it is
28
necessary to define which are the interactions and relationships between these mechanisms and the other elements of the architecture. However, as seen in section 1.1.4,
it is not yet clear whether sensor networks should use a layered approach or should
focus on cross-layer architectures. As a result, we should be able to incorporate the
security mechanisms inside any existing sensor network architecture, being it layered
or cross-layer.
For this purpose, we believe that security must be considered as a transversal
layer, that in both layered and cross-layer architectures will be able to provide information and services to the other elements of the architecture. Security services
will be located inside that transversal layer, and they can be able interact between
them and between the other elements of the architecture using well-defined interfaces. Shown in Figure 1.5, this point of view is shared by some academic cross-layer
architectures [40][43][44], and it is also partially shared by the ZigBee standard [45].
In layered communication architectures, the existence of a transversal layer containing the security services will allow the modification of those services according
to the requirements of the applications (e.g. choose a different security primitive)
without causing collateral effects that may negatively affect the other layers. In addition, it can be possible to add new security services derived from the necessities of
the applications and / or long-term academic research.
On the other hand, in cross-layer architectures the security layer behaves as another component of the architecture that can be accessed from any other component,
providing security-related services and information. By centralizing all security services inside one single component, we can improve the overall stability and maintainability of the architecture, and also we can provide a better control over the possible
interactions and dependencies that may arise.
We can also justify the choice of a security transversal layer by analyzing the interaction between security services. Certain security services (e.g. code attestation)
might be used only by one layer (e.g. application layer), thus it is possible to think
that those services should be integrated within the layer that uses them. However,
those security services will probably interact with other security services (e.g. intrusion detection systems) which have interactions with many layers. Therefore it
is more adequate to locate the security services inside the transversal layer. Finally,
as aforementioned, the use of a transversal layer allows the modification of security
services and the inclusion of new security services, limiting the possible collateral
effects.
1.3
Goals of this thesis
With their ability to link the real world and the virtual world, Wireless Sensor
Networks open a wide range of possibilities for empowering the world of today. Unfortunately, these networks are inherently insecure: any malicious adversary can be
able to access or modify the information flow. If a sensor network is compromised,
29
Confidentiality
Aggregation Prot.
Integrity
Code Attestation
Intrusión Detection System
Authentication
Time Synch. Prot.
Authorization
Key Management
Trust
Self-Awareness
Routing Prot.
Figure 1.6: “Complete Set” of security mechanisms
the link between what is virtual (data) and what is real (physical features) will be
severed, and such inconsistency will render the sensor network useless. As a result,
it is necessary to develop security mechanisms to protect the functionality of these
kind of networks. This point of view is shared by the research community, and there
is an abundant literature on the subject of securing sensor networks.
There is a factor that still has not been widely considered in the development of
these security mechanisms: the influence of the applications. Sensor networks are
not general purpose systems, because they provide a very specific functionality using
highly constrained devices. In fact, the actual structure, architecture, and protocols
of wireless sensor networks needs to be tailored to the nature of the application.
For example, a medical diagnostics application will have higher QoS requirements
than an asset tracking application. Also, if the physical location of the nodes is of
paramount importance for a certain application (e.g. in urban terrain mapping), in
most cases the network will use a routing protocol based on geographical information.
However, in most cases, security mechanisms for sensor networks are designed
considering neither the type of nodes used in the network nor the context where the
application will run. And the nature of the application will have significant influence
over which security mechanisms should be used and how these security mechanisms
should behave. A class I node (cf. section 1.1.3.1) may not be able to run certain
security primitives, whereas a class III node may have no problems when executing
these primitives. Also, it will be not possible to use a non-scalable mechanism for
distributing security credentials if the size of the network is large.
Precisely, one of the major goals of this thesis is to consider the influence of the
applications and their context in the protection of sensor networks and the development of the security mechanisms. For every security mechanism, it is necessary to
point out where the application and its context will influence on its behaviour. Once
this influence is known, it can be possible to adapt the security mechanism so it can
offer good protection capabilities that can maintain the network secure.
Once we consider that the security mechanisms must be application-driven, other
major goal of this thesis is to specify a “complete set” of security mechanisms.
With “complete set”, we refer to a set of application-aware security mechanisms
that are necessary to minimally enforce the security properties that were shown in
section 1.2.2, either preventing the existence of attacks or minimizing their adverse
30
effects. This way, a sensor network implementing this “complete set” can offer a minimal protection to its overall functionality. Through these protection mechanisms,
we can reduce the gap between research and reality.
What we consider to be a “complete set” of security mechanisms is shown in
Figure 1.6. From the security perspective, it is necessary to create confidentiality,
integrity, authentication, and authorization services for the network to work adequately. They provide security support to the protocols of the network, such as
routing. However, these services need to use cryptographic primitives that could
work within a constrained device. Also, the security credentials used by those cryptographic primitives must be distributed through a key management system (KMS).
This thesis will focus on reviewing the suitability of the security primitives and analyzing the relationship between the application and the key management systems.
On the other hand, the protocols used in sensor networks (e.g. core protocols such
as routing) need other security services that reinforce their own internal protection
mechanisms. By detecting potential problems in the network and providing decision
tools, it will be possible to maintain the availability and freshness of the network.
Those security services are intrusion detection systems (IDS) and trust management
systems. The foundation of these services is the self-awareness service, whose main
task is to analyze the behaviour of a node and its neighbours in order to detect
abnormal events (e.g. a dead node, a malfunctioning sensor) that may happen in
the context of the application. All these services are very useful for allowing the
network to self-organize itself, and this thesis will study how to develop such services
(situation awareness, IDS, trust management) in a sensor network context.
As with any other software components, it should be possible to include the
“complete set” of security mechanisms inside a sensor network architecture. In order
to allow the maintainability of the mechanisms, and their adaptation to the necessities of the application, this set should be included as part of a security transversal
layer (cf. section 1.2.3). This thesis will show how this concept have been fulfilled
in a middleware architecture for sensor networks. Finally, since the ultimate role of
sensor networks is to become a pervasive “sensory system”, this thesis will analyze
if the sensor networks can securely be connected to the rest of the world, through the
Internet.
Regarding the scenarios considered in this thesis, we mainly consider the security
of scenarios where the nodes are static, and few or no nodes are mobile. This is the
network configuration used by most applications and research projects as of 2008.
Nevertheless, some of the mechanisms presented in this thesis may be also valid for
networks with some mobile nodes.
1.3.1
Direct contributions
The major contributions of this thesis to the area of wireless sensor networks security
are detailed below:
31
• Definition of a “complete set” of security mechanisms, and locate them as a
transversal layer in the sensor networks architecture.
• Description of the actual state of the art in cryptographic primitives for sensor
networks, and review the suitability of these primitives for the different classes
of sensor nodes.
• Analysis of the relationship between the application requirements and the properties of a key management system (KMS). We also develop a methodology that
can distinguish which protocol is the most suitable to the context where the
network is going to be deployed.
• Study of the suitability of the current state of the art in KMS for offering a
viable solution to the key establishment problem in wireless sensor networks,
determining where researchers should focus their effort in order to create useful
KMS protocols that could be used in real-world applications.
• Support for the existence of Public Key Infrastructures (PKI) in Sensor Networks. Applicability of other public key paradigms such as identity-based
cryptography or self-certified cryptography in specific environments such as
Underwater Sensor Networks.
• Development of lightweight awareness mechanisms that can detect the existence
of an abnormal event based on the presence of certain collateral effects. We
also show how the application influence over these detection processes.
• Development of an intrusion detection system for sensor networks that fulfills
all the following properties: full network coverage, simplicity, usefulness, and
adaptability.
• Analysis how the specific features of wireless sensor networks influence over the
definition of a trust management system for sensor networks.
• Explanation of how the concepts of the “complete set” of security mechanisms
have been applied in a real middleware architecture for sensor networks.
• Analysis of the secure interactions between wireless sensor networks and the
Internet, illustrating how they also depend on the application. We also describe
open issues in this area.
1.3.2
Outline of this dissertation
In this first chapter, we have reviewed the wireless sensor networks paradigm: its
specific features, devices, and architectures. We also have introduced the security
problems that may affect the functionality of sensor networks, alongside with the
32
security mechanisms that try to enforce certain security properties. Finally, we have
explained which are the goals and the contributions of this thesis.
Chapter 2 is focused on the security primitives and mechanisms in charge of
managing the security credentials needed by the primitives. We describe the security primitives and analyze their suitability for constrained devices. We review the
key management approaches based on symmetric keys, defining their properties and
providing a methodology that will allow the study of their applicability to real world
applications. Finally, we analyze two key management approaches based on public
key cryptography: classical and identity-based. In the classical approach, we illustrate how to provide support for a Public Key Infrastructure in a sensor network
context. In the identity-base approach, we show how certain key-escrowed public
key paradigms are advantageous for specific contexts.
The contents of Chapter 3 will primarily deal with self-awareness services, which
are essential for self-configurability. We explain how the sensor protocols can benefit
from the existence of these mechanisms, and we further develop situation awareness
mechanisms based on the analysis of the existing abnormal events that may happen
in a sensor network context. Later, we develop a blueprint of a distributed intrusion detection system for sensor networks, specifying its components, its detection
mechanisms, and some support protocols. Finally, we review the concept of trust
management systems for sensor networks, specifying which are the sensor networks
specific issues that must be taken into account while developing these kind of systems.
In Chapter 4 we review how the concepts presented in this thesis have been
included inside a research project, and will also analyze how assuring the security of
sensor networks is not enough to guarantee a secure integration of sensor networks
and the Internet. We will introduce the SMEPP research project, whose main goal
is to develop a secure EP2P middleware, and we will examine how the ideas of the
“complete set” of application-driven security mechanisms have been included inside
its architecture. Regarding the secure integration between the sensor networks and
the Internet, we will analyze what are the security problems that may hinder this
integration, and we will propose some solutions and point out some open problems.
The conclusion of this thesis can be found in Chapter 5, in which we summarize
our contributions and present research lines that must be taken into account by the
research community.
1.4
Publications and funding
The work presented in this thesis has been internationally awarded in different security and communication conferences, meetings and journals where experts have
provided their valuable insights and thoughts.
33
Journals:
1. R. Roman, J. Lopez, S. Gritzalis. Situation Awareness Mechanisms for Wireless Sensor Networks. IEEE Communications Magazine. Vol. 46, no. 4 (2008),
pp 102-107.
2. R. Roman, C. Alcaraz, J. Lopez. A Survey of Cryptographic Primitives and
Implementations for Hardware-Constrained Sensor Network Nodes. Mobile,
Networks and Applications (MONET) Journal, Springer. Vol. 12, no 4 (2007),
pp 231-244.
Book chapters:
3. R. Roman, C. Alcaraz, N. Sklavos. On the Hardware Implementation Efficiency
of Cryptographic Primitives. In Wireless Sensor Network Security, IOS Press.
ISBN: 978-1-58603-813-7.
4. R. Roman, M.C. Fernandez-Gago, J. Lopez, H.H. Chen. Trust and Reputation
Systems for Wireless Sensor Networks. In Security and Privacy in Mobile and
Wireless Networking, Troubador Publishing Ltd. ISBN: 978-1905886-906.
International conferences:
5. R. Roman, M.C. Fernandez-Gago, J. Lopez. Featuring Trust and Reputation
Management Systems for Constrained Hardware Devices. Proceedings of the
1st International Conference on Autonomic Computing and Communication
Systems (Autonomics 2007), Rome (Italy), October 2007.
6. M.C. Fernandez-Gago, R. Roman, J. Lopez. A Survey on the Applicability of
Trust Management Systems for Wireless Sensor Networks. Proceedings of the
3rd International Workshop on Security, Privacy and Trust in Pervasive and
Ubiquitous Computing (SecPerU 2007), pp. 25-30, Istanbul (Turkey), July
2007.
7. R. Roman, C. Alcaraz. Applicability of Public Key Infrastructures in Wireless
Sensor Networks. Proceedings of the 2007 European PKI Workshop: Theory
and Practice (EuroPKI’07), pp. 313-320, Mallorca (Spain), June 2007.
8. C. Alcaraz, R. Roman. Applying Key Infrastructures for Sensor Networks
in CIP/CIIP Scenarios. 1st International Workshop on Critical Information
Infrastructures Security (CRITIS 2006), pp. 166-178, Samos (Greece), AugustSeptember 2006.
9. J. Lopez, J.A. Montenegro, R. Roman. Service-Oriented Security Architecture
for CII based on Sensor Networks. 2nd International Workshop on Security,
Privacy and Trust in Pervasive and Ubiquitous Computing (SecPerU 2006),
Lyon (France), June 2006.
34
10. R. Roman, J. Zhou, J. Lopez. Applying Intrusion Detection Systems to Wireless Sensor Networks. IEEE Consumer Communications & Networking Conference (CCNC 2006), pp. 640-644, Las Vegas (EEUU), January 2006.
11. R. Roman, J. Zhou, J. Lopez. On the Security of Wireless Sensor Networks.
Proceedings of 2005 ICCSA Workshop on Internet Communications Security,
pp 681-690, LNCS 3482, Singapur, May 2005.
Spanish conferences:
12. D. Galindo, R. Roman, J. Lopez. An Evaluation of the Energy Cost of Authenticated Key Agreement in Wireless Sensor Networks. Proceedings of the
X Spanish Meeting on Cryptology and Information Security (RECSI’08), Salamanca, September 2008.
13. C. Alcaraz, R. Roman. Análisis de Primitivas Criptográficas para Redes de
Sensores. VI Jornadas de Ingenierı́a Telemática (JITEL’07), Malaga, Septiembre 2007.
14. R. Roman, J. Lopez, J. Zhou. Aplicación de Sistemas de Detección de Intrusiones en Redes de Sensores. Simposio sobre Computación Ubicua e Inteligencia Ambiental (UCAmI’05), pp 113-120, Granada, Septiembre 2005.
15. R. Roman, J. Lopez, J. Zhou. Análisis de seguridad en redes inalámbricas de
sensores. V Jornadas de Ingenierı́a Telemática (JITEL’05), pp 335-342, Vigo,
Septiembre 2005.
Also, the following articles are submitted for evaluation or under revision:
16. R. Roman, J. Lopez. Integrating Wireless Sensor Networks and the Internet:
A Security Analysis. Internet Research. Under revision.
17. D. Garrido-Marquez, P. Plaza-Tron, R. Roman, N. Sanz-Martı́n, J.L. SerranoMartı́n. Middleware seguro P2P para dispositivos de baja capacidad. Telecom
I+D 2008. Submitted for evaluation.
This thesis has been funded by the Institute of Infocomm Research (Singapore)
during its first year, and subsequently it has been funded by the Consejerı́a de Innovación, Ciencia y Empresa (Junta de Andalucı́a) under the III Andalusian Research
Plan and by the Ministry of Education and Science of Spain under the “Programa
Nacional de Formación de Profesorado Universitario”. Some parts of the work were
also carried out in the Laboratory of Information & Communication Systems Security of the University of the Aegean (Greece). Besides, part of the work carried out in
this thesis has been applied to the projects CRISIS (TIN2006-09242), CONSOLIDER
ARES (CSD2007-00004), and SMEPP (EU-FP6-IST 0333563).
CHAPTER
2
SECURITY PRIMITIVES & KEY
MANAGEMENT SERVICES
This chapter studies the different security primitives and key management services that can be used in sensor networks. We describe the
different security primitives, and provide an analysis of the suitability
of the hardware and software implementations of these primitives in
constrained devices. Next, we analyze whether the actual state of the
art in symmetric key-based key management systems (KMS) can satisfy
the requirements of sensor networks applications. For this purpose, we
develop a methodology that allows any user to easily select a KMS protocol according to the requirements of a sensor network application. Finally, we analyze two key management approaches based on public key
cryptography: classical and identity-based. In the classical approach,
we provide support for public key operations in the form of a Public Key
Infrastructure for sensor networks. In the identity-based approach, we
show how certain key-escrowed public key paradigms, such as identitybased cryptography, can perform better than other algorithms in extreme environments such as underwater sensor networks.
35
36
2.1
2.1.1
Insights on the use of security primitives
Description of the security primitives
The foundation of almost all the secure protocols that can be used in sensor networks,
and the tools that can aid these systems on integrating the security properties into
their operations, are the cryptographic primitives such as Symmetric Key Encryption (SKE), Hash functions, and Public Key Cryptography (PKC). Without these
primitives, it would not be possible to provide essential security services such as confidentiality of the communication channel, authentication of the peers involved in an
information exchange, and integrity of the messages, among others.
These primitives are not sufficient by themselves for guaranteeing the overall security of the whole network. For example, a malicious insider located inside the
network can easily bypass the protection of the communication channel. Nevertheless, without these primitives, it would be nearly impossible to create a secure and
functional environment. Moreover, it is possible to create better network services
based on the primitives. For example, by using secure code uploading, it will be
possible to update the behavior of a node or to implement mobile agents. Also, if a
group of nodes wants to communicate in a secure fashion, they can use the cryptographic primitives to protect the information flow between the members of the same
group.
Symmetric Key Cryptography (SKC)
Symmetric Key Cryptography (SKC) primitives are able to offer the necessary mechanisms for protecting the confidentiality of the information flow in a communication
channel. For achieving this confidentiality level is necessary that both the origin and
destination share the same security credential (i.e. secret key), which is utilized for
both encryption and decryption. As a result, any third-party that does not have
such secret key cannot access the information exchange. The security properties of
these primitives mainly resides on the complexity of their internal operations and
the length of the keys.
There are two types of SKC primitives: Stream Ciphers and Block Ciphers.
Stream Ciphers are simpler and faster, while Block Ciphers are more flexible and
powerful. These two types are discussed in more detail in the following paragraphs.
Stream ciphers and block ciphers. A stream cipher is a method of symmetric
cryptography that takes as an input a flow of bits of variable size and transforms it
into a ciphertext. For that purpose, these cryptographic algorithms combines, mainly
by using simple operators such as XOR, those input bits with a pseudorandom key
flow obtained from a cryptographic key and an initialization vector (IV). It is essential
to use such IV in stream ciphers for avoiding situations where one plaintext produces
the same ciphertext when encrypted with the same key.
37
On the other hand, a symmetric block cipher operates on a group of bits with a
fixed-size –usually 64 or 128 bits–, known as blocks. A block of plaintext is transformed into blocks of ciphertext by using several rounds of mathematical operations.
In all these rounds most block ciphers also have to transform the original key, using
a usually complicated process named key schedule. In cases where more than one
block has to be encrypted (e.g. a plaintext that is larger than the block size), it is
necessary to use a mode of operation (mode, for short). Moreover, if the plaintext is
not a multiple of the block size, some modes requires padding that plaintext.
Modes are just a set of operations using the block cipher inputs and outputs.
Some of them provide confidentiality, and a few of them provide integrity. Concretely, the earliest modes, as ECB (Electronic Codebook), OFB (Output Feedback)
or CBC (Cipher Block Chaining), provide only confidentiality. However, modes such
as CCM (Counter with MAC), GCM (Galois Counter Mode), OCB (Offset Codebook
Mode) and others modes guarantee both security properties by including a Message
Authentication Code (MAC). In addition, in order to generate some randomization
in the process, these modes, except ECB, needs of an initialization vector (IV) that
has to be combined with the original key.
The following subsections present a set of stream cipher and block cipher primitives that could be used in highly constrained devices. These primitives are arranged
according to their complexity, and hence according to the resources that they demand
to a device. Concretely, they are classified from less to more complex.
RC4. One of the better known stream cipher algorithm, which is used by several
protocols like Secure Sockets Layer (SSL) or Wi-Fi Protected Access (WPA), is RC4
[96] . This simple algorithm was designed by Ron Rivest in 1987, and it is also known
as ARC4 or ARCFOUR. There are two design decisions that explain its simplicity.
Firstly, it minimizes the execution time by using simple operations as XOR, AND,
addition and shifting. And secondly, it uses a block size of 8-bit, consuming less
memory space than others cryptosystems. Therefore, RC4 is highly suitable for
those architectures with extremely limited microcontrollers. However, RC4 must be
implemented carefully for avoiding any attacks as the detected in WEP [97] , where
the primitive was not properly initialized.
Skipjack. Skipjack [99] is considered one of the simplest and fastest block ciphers,
in comparison with other ciphers such as RC5, RC6 or AES. It was designed by the
NSA (U.S. National Security Agency), and declassified in 1998. The primitive uses
building blocks of 64 bits and a cryptographic key of 80 bits for encrypting data
blocks of 16 bits. Therefore, it is especially suitable for constrained sensor nodes
with 16-bit microcontrollers.
This primitive needs of 32 rounds to encrypt the plaintext, alternating two stepping rules known as A and B. Both rules can described as a linear feedback shift
register with additional non linear keyed G permutation (Feistel cipher of 4 rounds).
38
Also, the key schedule of Skipjack is straightforward, i.e. the key is cyclically repeated enough times to fill the key schedule buffer. Besides these obvious benefits
regarding the simplicity of the algorithm, this primitive does not provide the same
security than others, due to its small key size.
RC5 and RC6. In 1994, Ron Rivest designed a simple symmetric algorithm named
RC5 [107] . This primitive has variable parameters both in block size (32, 64, 128
bits), in key size (0 to 2040 bits) and in number of rounds (between 0 and 255),
although it is recommended to use a block size of 64 bits, a key size of 128 bits and 20
rounds. On the other hand, its internal operations are quite simple: integer additions,
bitwise XOR, and variable rotations, over two b /2 bits registers. An algorithm based
on RC5 is RC6 [108] , which it was designed by Ron Rivest, Matt Robshaw, Ray
Sidney and Yiqun Lisa Yin in 1998. It is very similar to RC5, except that its
recommended block size is 128 bits, and internally includes integer multiplication
and uses four b /4 bits registers.
In spite of using simple building blocks, resulting on a small code size in their
implementation, both algorithms are complex and slow, thus not all the highlyconstrained devices could support them. Basically, they use 32-bit registers for the
recommended block size (i.e. b /2 where b=64 in RC5, and b /4 where b=128 in RC6),
the number of rounds is high, and the key schedule is quite complex in comparison
with simpler ones such as in Skipjack.
AES & Twofish. The Advanced Encryption Standard (AES) [98] was designed in
1998 by Joan Daemen and Vicent Rijmen. It is a derivative of the Rijndael algorithm,
which supports a larger range of block and key sizes ranging between 128 bits and
256 bits. On the other hand, AES works with a fixed block size of 128 bits and a key
size of 128, 192 or 256 bits. Depending on the size of the key, the number of rounds
is 10, 12 and 14 respectively.
For encrypting, AES needs a 4 × 4 array of bytes (known as the state) over a
finite field. In each round (except the last round) four distinct stages are executed:
AddRoundKey, where the subkey is combined (XOR operation) with the state, SubBytes, where each byte is replaced with its entry in a fixed 8 bits lookup table,
ShiftRows, where bytes in each row of the state are shifted cyclically toward the left,
and MixColumns, where each column is multiplied with a fixed polynomial p(x).
Other block cipher algorithm similar to AES is Twofish [115] , designed in 1998
by Bruce Schneier, John Kelsev, Doug Whiting, David Wagner, Chris Hall and Niels
Ferguson. Twofish uses a block size of 128 bits with large key sizes (up to 256 bits).
Internally, it features a complex key schedule, and four different key-dependent 8x8
bits S-boxes. Besides, it uses other elements belonging to other cipher families,
concretely the pseudo-Hadamard transform (PHT(a,b)=α,β, where α = a + b mod
232 and β = a + 2b mod 232 ), and the maximum distance separable (MDS) matrix
(4 × 4) over GF(28 ).
Both AES and Twofish are quite fast in their encryption/decryption operations
39
due to their small number of rounds, and also some operations can be calculated in
8-bit registers. On the other hand they are considerably complex, which results on
a larger code size. Therefore, not all constrained devices can afford to implement
them in software.
Public Key Cryptography (PKC)
Public key cryptography (PKC), also known as asymmetric cryptography, is a form
of cryptography that uses two keys: a key called secret key, which has to be kept
private, and another key named public key, which is publicly known. Any operation
done with the private key can only be reversed with the public key, and viceversa.
This nice property makes all PKC-based algorithms useful for secure broadcasting
and authentication purposes. It is also an invaluable tool for allowing the secure
exchange of secret keys between previously unknown partners.
The computational cost of calculating the underlying primitive operations had
hindered its application in highly-constrained devices, such as sensor nodes. However, at present there are several PKC primitives that are being considered for a
sensor network environment. Obviously, it is important to know their properties to
determinate if they could be suitable in a constrained architecture. For example, the
algorithm RSA [112] is known by offering good cryptographic operations (encrypting
and signing), but limited microprocessors must pay a relatively high computational
cost. For all these reasons, it is necessary to analyze what kind of PKC primitives
are more suitable for the sensor nodes.
Elliptic Curve Cryptography. In 1985, Koblitz and Miller proposed one of the
most investigated PKC primitives in the field of WSN security, named Elliptic Curve
Cryptography (ECC) [100] . This interest is due to some interesting features offered
by ECC that are appropriated for WSN context, such as the small key size and fast
computation. ECC is based on elliptic curve structures defined as y2 = x3 + ax + b
over finite fields Fp or F2 m . Then, the base of security in this type of cryptosystem
is determined by the discrete logarithm problem. Concretely, given the parameters
a and c, the security is determined by the resolution of the equation ab = c.
The basic operation in ECC is the scalar point multiplication, which can be
calculated by the repetitive computation of point additions and doublings, and also
it requires an integer inversion calculated over affine coordinates. Although the point
multiplication operation is less expensive in computational terms than the primitive
operations of RSA (i.e. exponentiations), it is still quite resource intensive. For this
purpose, there exist several optimizations, such as the use of projective coordinates to
avoid the inversion operations, or the use of the Shamir’s trick method for minimizing
the verification time.
As aforementioned, ECC is able to offer the same security as other cryptosystems,
like RSA, providing signatures by using Elliptic Curve DSA (ECDSA) key establishment by using Elliptic Curve Diffie-Hellman (ECDH), and asymmetric encryption by
40
using Elliptic Curve Integrated Encryption Scheme (ECIES). Moreover, ECC works
with a smaller key size (160 bits in ECC is equivalent to 1024 bits in RSA), and its
basic operation executes in a reasonable time. These properties are very appreciated
by the research community in order to try their integration in sensor nodes.
Other cryptographic approaches. Other cryptographic approaches that could
be suitable for constrained architectures are Rabin’s scheme [106] , NtruEncrypt
[105] and MQ-schemes [103] . Overall, their execution time is quite optimal, but
their memory requirements in terms of the key size are very heavy.
In 1979, Michael Rabin proposed a high-speed scheme based on the factorization
problem of large prime numbers, known as Rabin’s scheme. Therefore, its security is
determined of the same way than RSA. This primitive is characterized by the speed
of its encryption and signature verification operation, which are built by a simple
squaring operation, i.e En,b ≡ x(x+b) mod n when b takes value zero. However, the
function of Rabin generates three results, and only one of these results is correct.
Also, the size of a single signature is quite large (512 bits).
Other asymmetric approach is NtruEncrypt and its corresponding signature scheme
NtruSign, which were created by Joseph H. Silverman, Jeffrey Hoffstein, Jill Pipher
and Daniel Lieman in 1996. These cryptographic primitives are usually based on a
polynomial ring R = Z (x)/((xN - 1), q), and their strength is based on the hardness of solving the Closest Vector Problem (CVP) and the Shortest Vector Problem
(SVP). Due to its simple primitive operations for encryption and signing, just mere
polynomial multiplications, NtruEncrypt claims to be faster than other asymmetric
encryption schemes, although it requires a public key size of 1169 bits.
Finally, the most recent asymmetric approach is the multivariate public-key cryptosystems, also known as MQ-schemes. Their security is determined by the hardness of solving w = V −1 (z) = (ω1 , ..., ωn ) ∈ K n , given a quadratic polynomial map
V = (γ1 , ..., γm ) : K n → K m . In particular, the security of the variant known as the
enTTS(20,28) algorithm, which belongs to the STS-UOV family of MQ-signatures,
is comparable to RSA-1024. A MQ-scheme is quite fast in its cryptographic operations, such as the verification of a signature. However, there is a significative storage
cost for restricted environments due to the size of the keys in RAM. Concretely, it
is necessary to book 879 bytes for the private key and 8680 bytes for the public
key. Obviously, this cryptosystem can only be supported by sensor nodes with high
memory capabilities.
Hash Functions
Cryptographic hash functions or hash primitives are utilized in order to compress a
set of data of variable length into a set of bits of fixed length. The result is a “digital
fingerprint” of the data, identified as a hash value. A cryptographic hash function
must satisfy two properties: i) given a hash value h, it should be hard to find a
message m such that hash(m) = h, and ii) it should be hard to find two different
41
messages m1 and m2 such that hash(m1 ) = hash(m2 ).
This kind of hash primitives are usually used to build other cryptographic primitives. For example, the Message Authentication Code (MAC) primitive provides
authenticity and integrity in the messages, either by using the CBC mode of operation in a process named CBC-MAC, or by taking advantage of the existence of hash
primitives. An example of hash function is SHA-1 algorithm [114] , which takes 512
bits and returns 160 bits, and operates with operations of additions, rotations, XOR,
AND, OR and NOT. Nevertheless, the complexity required for finding a collision is
only 263 [109, 110], hence it is recommended to use other stronger algorithms such
as SHA-256. The algorithm SHA-256 takes 512 bits and returns 256 bits. There are
other hash functions, such as RIPEMD-160 [111]. This hash function takes an input
of 512 bits and produces an output of 160 bits, and its internal operations are based
on rotations, permutations, shifts, and others.
2.1.2
Software implementation of primitives for WSN
There are many instances of these primitives (i.e. algorithms), and each one of them
has different requirements in terms of processing power, word size, etc. Our first goal
will be to review existing implementations of the less resource-demanding algorithms
in order to analyze their theoretical suitability to the different classes of sensor node
hardware [249, 251, 261].
2.1.2.1
Symmetric Key Cryptography and Hash functions
One of the first studies on the encryption overhead of SKC and Hash primitives in
constrained microcontrollers was made by Ganesan et. al. [53] in 2003. In their
software implementation, they discovered that the time required for encrypting a
single plaintext was much less than the time need for executing hash primitives.
Nonetheless, the average code size of a single primitive is less than 4000 bytes of
ROM. For example, the encryption time of a single byte of plaintext with the stream
cipher RC4 was 6µs, with RC5 was 26µs and with IDEA was 21µs, whereas the
execution of the hash primitive SHA-1 is 122µs for digesting one byte.
Later, in 2004 SKC primitives are introduced by means of a new cryptographic
package in Mica and Mica2 nodes over the “de-facto” standard OS for sensor nodes,
TinyOS1 . This package known as TinySec [91] provided the Skipjack primitive, which
needed 48µs for encrypting a byte, and the RC5 primitive, which needed 33µs for
encrypting a byte. RC5 was considerably better in encryption overhead than Skipjack. However, it did not include any hash primitives, so the integrity process was
achieved through of CBC-MAC, which generates the message authentication code
using the SKC primitives.
1
This library is only available in the 1.x version of the OS, and cannot be used in IEEE 802.15.4based nodes.
42
In 2006, Wei Law et. al. [74] and Jun Choi and Song [58] carried out a detailed
analysis on the encryption overhead of other instances of SKC primitives. Their
studies demonstrated that an optimized Skipjack improved in both encryption overhead (25µs) per byte and in memory overhead (2600 bytes for instructions) than the
rest of algorithms (an average of 8000 bytes). Nonetheless, RC4 achieved in terms
of memory overhead 428 bytes, thus it was much better than an optimized Skipjack
for extremely constrained devices. Note also that the memory consumption of most
primitives in terms of RAM memory is smaller than 100 bytes.
2.1.2.2
Public Key Cryptography
Until 2004, most security algorithms and protocols were based only on symmetric key
cryptography (SKC). The reason was quite simple: the use of public key cryptography
(PKC) in Wireless Sensor Networks was considered, even labelled, as ”not possible”.
However, Gura et. al.’s studies [101] opened a door of possibilities for the applicability
of PKC in sensor networks. They demonstrated that Elliptic Curve Cryptography
(ECC) could be used to implement PKC in highly-constrained contexts. ECC has
smaller requirements both in computation and memory storage. The cause of this
reduction is due to its small key sizes and its simpler primitives, in comparison with
other PKC algorithms such as RSA.
Moreover, Gura et. al.’s studies encouraged the research community to advance
more on this topic. In fact, Malan et. al. [102] presented in the same year the first
library with ECC primitives over the field F2 p , known as EccM 2.0. It worked with a
key size of 163 bit, achieving an average execution time of 34 seconds in its operations
(point multiplication and secret key generation). However, 34 seconds was not fast
enough for allowing the creation of secure services based on PKC. For that reason,
several studies started to optimize the ECC capabilities. One of the firsts ECC optimizations was presented by Gura et. al. in [101] . They ensured that performance of
ECC could be improved if it used projective coordinates instead of affine coordinates
to reduce the number of expensive operations, such as the inversion. Other of their
suggestions was to work over a field Fp instead of F2 p . Such optimizations were taken
into account by Batina et. al. [48] for their work on their hardware implementation
of ECC (cf. section 2.1.3.1).
As of 2008, there are several implementations using a few of the ECC optimizations previously described. For instance, Liu and Ning implemented TinyECC [62] ,
and Wang and Li implemented WMECC [73] . Concretely, TinyECC have a set of
implementations in various elliptic curve domains (sec128r1, secp128r2, secp160k1,
secp160r1, secp160r2, secp192k1, and secp192r1) according to the Standards for Efficient Cryptography Group [113] , while WMECC only has the implementation on the
secp160r1 elliptic curve domain. All of them work under TinyOS, and were codified
in nesC (Network Embedded System C).
Although, TinyECC and WMECC are very different both in design and in code,
43
they are relatively similar because they have in common some optimization techniques. Firstly, for getting optimization in the modular reduction in multiplications
and square, they make use of pseudo-Mersenne primes (being p a field prime, whose
value is 2n –c). Nonetheless, TinyECC is a little better in performance than WMECC
on this aspect. It can compute modular multiplication of large integers by using Hybrid Multiplication. Secondly, they use projective coordinates, although TinyECC
applied Jacobian representations (X,Y,Z) while WMECC utilized a combination of
representations between a modified Jacobian coordinates (X,Y,Z,aZ4 ) and Affine
coordinates (X, Y ).
Lastly, both implementations utilize two methods, Shamir’s trick method and
sliding window method, for reducing and improving operational calculus inverted in
scalar point multiplications. The purpose of the Shamir’s trick method (also known
as Strauss algorithm [165]) is to execute in parallel several point multiplications, and
this way is possible to minimize the signature verification time. The sliding window
method, grouping the scalars in s bits clusters, allows the reduction of the running
time by pre-computing point multiplications. It is important to notice that the precomputation phase in TinyECC is much more expensive than the pre-computation
phase in WMECC. WMECC uses a small window for both sliding window method
and Shamir’s trick method, and its initialization time is negligible.
Test - ROM size
Test - RAM size
ECC init
ECDSA init
Pub. Key Gen.
Signature
Verification
TinyECC
MICAz TelosB
28266
26048
2306
2327
1.837s
3.550s 5.225s
1.788s
1.916s 4.361s
2.431s 5.448s
WMECC
MICAz TelosB
57982
46156
1685
1657
1.809s 1.744s
0s
0s
1.261s 1.425s
1.348s 1.498s
2.017s
2.207
WMECC+
MICAz TelosB
29734
25774
1643
1599
1.809s 1.744s
0s
0s
1.261s 1.425s
1.348s 1.498s
2.019s 2.209s
Table 2.1: Summary of Software implementations of ECC
Table 2.1 shows the results obtained by the execution of TinyECC and WMECC
in the elliptic curve domain secp160r12 . This table summarizes the results obtained
after executing 20 rounds of the ECC primitives over the MICAz and TelosB nodes.
The first rows of the table shows the ROM and RAM size reserved for the primitives
and the test program, and the rest of rows shows the time spent in the execution
of the primitive. The differences between both nodes can be partially explained by
their architecture: the microcontroller of MICAz does not spend time in computing unsigned multiplications, but the microcontroller of TelosB (MSP430) dedicated
2
Regarding the versions used in this test, the version of TinyECC was 0.3, while the version of
WMECC had no version number (it was an internal beta version) and was retrieved on January
29nd, 2007.
44
several cycles to them.
Comparing both implementations, the WMECC package yields a better performance than the TinyECC package: It has no (ECDSA) initialization time, and the
time it needs to sign and verify a signature is slightly faster. However, its memory
footprint is simply prohibitive, thus it would be impossible to develop any kind of
application for a TelosB. Fortunately, we discovered that the major penalty of the
WMECC code was inside the SHA-1 function, and the TinyECC implementation
is precisely characterized by an optimized SHA-1 code. Thanks to the component
capabilities of the TinyOS operating system, we included the SHA-1 component of
TinyECC in the WMECC code, resulting on a new version of the WMECC package
(WMECC+) that is significantly better. By means of this optimization, which as of
2008 is included inside the official WMECC library, it can be perfectly possible to
create PKC-based applications on a constrained node such as the TelosB.
It can be concluded that the results obtained by the TinyECC and WMECC
implementations effectively reduced the running time for signing or verifying a signature to less than 2 seconds. This was an important improvement with respect to
the results obtained by Malan et. al.’s work. As a result, nowadays it is considered
that it is possible to use software implementations of PKC in constrained sensor
node. On the other hand, it would be better to reduce even more the execution time
of these primitives.
2.1.2.3
Suitability of software implementations
In order to analyze the suitability of these security primitives software implementations, we need to evaluate two specific factors: their execution time and their memory
consumption. If the sensor nodes are not fast enough to execute the primitives, the
communication process will be delayed. On the other hand, if the memory consumption of the primitives is prohibitive, sensor nodes will not be able to implement any
protocols and services.
Regarding execution time, both Symmetric Key Cryptography and Hash functions should not cause a penalty in communication. That is, the time required for
encrypting / digesting a byte should be less than the byte time, which represents
the time required for sending a single byte of data. For example, for a CC1000
transceiver with a bandwidth of 19.2kbps, the byte time is approximately 420µs, and
for the 802.15.4-based CC2420 with a bandwidth of 250kps, the byte time is closer
to 32µs.
Most of the symmetric key primitives can encrypt a byte in less than the smallest
byte time, 32µs. Besides, the penalty caused by the slowest block ciphers is not
very high: RC5, for example, only uses 33µs. On the other hand, hash functions are
slower: SHA-1 needs 122µs to digest a byte. However, most applications do not need
to send large volumes of data through the wireless channel, thus sensor networks will
not use the entire bandwidth, and the execution of the cryptographic primitives will
not cause a penalty in the communication between nodes. Suffice to say that the
45
high execution time of Public Key primitives, around 2 seconds, limits their use to
specific situations such as key negotiation or broadcast authentication.
Regarding memory consumption, the class type of a node will determine the
amount of memory available to the application logic, including the security primitives. Therefore, this class type will influence over the type of primitives that the
node can run. “Class III” nodes have roughly 256kB of RAM and 4MB of instruction
memory. These type of sensor nodes are powerful enough to cope with any kind of
cryptographic primitive, either symmetric or asymmetric, via software.
On the other side of the spectrum, we can find “Class I” nodes. These nodes,
with roughly 1kB of RAM and 16kB of instruction memory, can support software
implementations of block cipher algorithms such as AES, RC5, and Skipjack. However, the amount of memory left for implementing the application logic is quite small.
Therefore, it may be better to use stream cipher algorithms, whose memory requirements (e.g. 428 bytes of inst. memory for RC4) are quite small. Note that, due
to their extreme memory constraints, these kind of nodes are completely unable to
execute Public Key Cryptography on software.
Regarding “class II” nodes, they are the most common hardware platform used on
wireless sensor networks. With roughly 4-8kB of RAM and 48-128kB of instruction
memory, these nodes are powerful enough to support the execution of any cryptographic primitive on software. Still, considering the actual state of the art, a simple
application prototype with support for all the primitives in software will consume
34kB3 of instruction memory.
From this analysis we can assert that, as of 2008, sensor nodes are capable of
running cryptographic primitives such as Symmetric Key Cryptography, Public Key
Cryptography, and Hash functions on software. However, the inclusion of HW cryptographic modules in both “class I” and “class II’ nodes should be considered, in
order to reduce the overhead posed by the implementation of the primitives.
Besides, there is the need of designing and developing better cryptographic primitives, suitable for environments with small resource requirements. There are some
ongoing research projects that pursue this goal. For example, in April 2008, the
ECRYPT Stream Cipher Project [82] selected eight novel stream ciphers for their
final “portfolio”, and some of these ciphers have been already implemented in node
microcontrollers [116]. As of hash functions, there is an ongoing cryptographic hash
algorithm competition that pursues the creation of a new hash function standard
[83] which will surely foster the research in this field.
2.1.3
Integrations on silicon for WSN
The constraints inherent to the sensor nodes advise against the total dependence
on software-based implementations, even more in the case of expensive primitives
3
AES-128 consumes 8kB, and ECC consumes 26kB - including example code and the code of
the SHA-1 primitive (2kB).
46
such as PKC. The time a single node spends executing these primitives could be
used for other primordial tasks, or even for implementing the necessary steps that
are required to provide other security properties. Consequently, our goal in this
section will be to analyze the suitability of the implementation of these primitives
on hardware [249, 251, 261].
2.1.3.1
Research efforts
Most hardware extensions proposed by the research community for constrained devices such as sensor nodes aim to improve the execution of asymmetric cryptography
primitives, but they only exist as a mere proof-of-concept. It is then desirable that
these extensions are implemented as part of the microcontrollers or as external chips
so that they can be used for leveraging the load of the computing core.
Nearly all efforts in the research community have been aimed on providing hardware support to Elliptic Curve Cryptography (ECC). Wolkerstorfer et. al. [94], as
well as Kumar et. al. [95] developed integrated chips that can provide an excellent
performance for signing a message using ECDSA, but at the cost of a high operating
frequency. In the case of Wolkerstorfer, the chip has an area of 23000 gates implemented in 0.35µm CMOS technology, operates at 68.5Mhz, and is able to execute
a one point multiplication over F2191 in only 6.67ms. On the other hand, the chip
created by Kumar and Paar is slower, providing a point multiplication over F2131 in
18ms, but has less gates (almost 12k), and works at a slower operating frequency
(around 13Mhz). These implementations are not applicable to most sensor nodes,
although some microcontrollers, like the PXA271 and the ARM920T, would be able
to support them.
The implementation by Gaubatz et. al. [55] is more oriented to highly constrained
sensor nodes, since its operational frequency is only 500kHz. In their ECC scalar
point multiplication architecture, operations are performed over Fp100 , occupying a
chip area equivalent to 18720 gates in 0.13µm CMOS technology, and consuming just
under 400µW in signing and encrypting messages. ECDSA signatures and ECMV
decryptions are performed at around 410ms, and ECDSA verifications and ECMV
encryptions are performed at around 820ms. As for the optimizations, they efficiently
implement modular reduction, achieve a fast inversion algorithm, and implement all
arithmetic primitives in a bitserial fashion.
These implementations were further improved by Batina et. al. [48]. Their
Elliptic Curve Processor (ECP) included a Modular Arithmetic Logic Unit (MALU)
capable of computing modular additions and multiplications, using the same cells for
both purposes without having a full-length array of multiplexors. Moreover, squaring
is considered a special case of multiplication, and inversion is avoided mostly by
using projective coordinates. The results are promising: using 8104 gates (12kgates
including RAM) in 0.13µm CMOS technology, one point multiplication over F2131 is
performed in only 115ms, consuming less than 30µW in a operational frequency of
500kHz.
47
ECC is not the only primitive that researchers have considered for implementing
PKC in sensor networks. In [55], Gaubatz et. al. proposed the NtruEncrypt public
key cryptosystem as a possible candidate. This solution employs a small number of
gates (3000) and only consumes about 20µW in an operational frequency of 500kHz.
Encryption and verification operations are performed at around 58ms, decryptions
are calculated in almost 117ms, and messages are signed in almost 234ms. Another scheme, Rabin’s scheme, was proposed by the same authors [55]. The design
used less than 17000 gates with an average power consumption of 148.18µW, and
achieved speeds as low as 2.88ms for encrypting and verifying messages. However,
the downside comes from the decryption and signature operations: the processor has
to employ 1.089s for executing them.
Finally, the Multivariate public key cryptosystem was also considered due to its
benefits regarding Quantum Computing. The implementation made by Yang et. al.
[75] only included signature generation, since it was mostly oriented to RFID tags.
The optimal form, the circulant (LPSQR) form of enTTS(20,28), uses 17000 gates
in 0.25µm CMOS technology, and has a signature time of only 44ms and a energy
consumption of 25µA in an operational frequency of 100kHz. This speed is achieved
thanks to the substitution of the Lanczos’ method used in the internal operations
with the symmetric Gaussian elimination.
ECC
Gates
Technology
Frequency
Field
Point Mult.
Encryption
Decryption
Signing
Verifying
Energy
NTRU
Rabin
MQ
Wolker.
Kumar
Gaubatz
Batina
Gaubatz
Gaubatz
Yang
23000
0.35µm
68.5MHz
F2191
9.98ms
—
—
—
—
n.a.
12000
0.35µm
13.5Mhz
F2131
18ms
—
—
—
—
n.a.
18720
0.13µm
500khz
Fp100
∼ 400ms
—
—
—
—
∼ 133µA
12000
0.13µm
500kHz
F2131
115ms
—
—
—
—
∼ 10µA
3000
—
500kHz
—
—
58ms
117ms
234ms
58ms
∼ 6.6µA
17000
—
500kHz
—
—
2.88ms
1.089s
1.089s
2.88ms
∼ 49.4µA
17000
0.25µm
100kHz
—
—
—
—
44ms
—
25µA
Table 2.2: Summary of Hardware prototypes for PKC
Table 2.2 shows the different hardware prototypes categorized by their underlying
primitive, considering the operating voltage at 3V. Note that the encryption time
and other time-related rows are empty for ECC-based prototypes because the time
of completing a scalar point multiplication largely influences over the operations of
the algorithms. From the table, it is possible to notice that Batina et.al. hardware
implementation is the best ECC prototype. Comparing it with other primitives,
the prototype consumes slightly less energy, but the time for calculating an internal
operation (a point multiplication for a ECC-based primitive) is a bit larger. The
MQ prototype is really powerful for signing, but the size of its key is too large.
Regarding NTRU, it is well-balanced, but its signature is 1.169 bits, thus it needs
48
at least 5 packets in order to send a message. Lastly, Rabin is extremely fast on
encryption and verifying, although its signatures requires 512 bits.
2.1.3.2
Industrial efforts
Aside from the previously mentioned prototypes developed in research environments,
there are, as of 2008, very few solutions specifically designed for sensor nodes that are
able to provide hardware support for cryptographic primitives. However, it is possible
to take advantage of the existing hardware support included in the microcontrollers
and transceivers. For example, some wireless communications standards include
hardware support for symmetric key cryptography. In addition, by using processorspecific instructions sets like MMX, the execution of certain security primitives can
be improved.
Since all network packets must traverse the radio transceiver, this is the ideal
place where the hardware support could be located. The reason is simple: usually,
all communications have to be protected with SKC primitives in order to assure the
confidentiality, integrity and authentication of the packets that traverse the network.
Not all radio transceivers incorporate this type of support, though: only a certain
group of standards require the implementation of the primitives on silicon. One of
those standards, widely used on sensor networks, is the IEEE 802.15.4 standard [57].
All transceiver chips that implement the 802.15.4 standard can offer a suite of
AES-based symmetric key cryptography operations for assuring the confidentiality
and integrity of the network packets. The available suites are AES-CTR, AES-CBCMAC, and AES-CCM. The AES-CTR suite only provides confidentiality by using
AES in Counter Mode, thus behaving as a stream cipher. AES-CBC-MAC ensures
data integrity through Message Authentication Codes using AES in Cipher Block
Chaining Mode (CBC-MAC), where the size of the MAC can be 32, 64 or 128 bits
long. Finally, AES-CCM provides both confidentiality and integrity, by applying
integrity protection using AES-CBC-MAC and then encrypting the data using AESCTR mode.
In order to use these security suites, the application must create an ACL (access
control list) entry consisting on a source address, a destination address, a suite, and
the secret key of 128 bits to be used between the source and the destination. Once
the standard-compliant radio transceiver receives a packet with security enabled, it
looks up for an entry in the ACL, and applies the security suite if a match is found.
Note that, although there can be up to 255 ACL entries, the standard does not
specify a minimum size. Moreover, the only mandatory suite that the transceiver
must offer by default is AES-CCM with a 64-bit MAC.
Unfortunately, the 802.15.4 standard, and all the chips that implement it, is not
exempt of flaws [68] . One of the security suites, AES-CTR, is deeply flawed, since
it does not properly support replay detection and it is possible to launch Denial of
Service (DoS) attacks sending a single forged packet. Also, the acknowledgement
packets are not protected by a MAC, thus it is possible to forge them. Other minor
49
problems include deleting the ACL entries when entering low power mode. As a
result, chip manufacturers and application designers must take into account the
inherent problems of the standard.
As an example, the most common 802.15.4 chip integrated in sensor nodes as
of 2007, the Chipcon CC2420, implements all the recommended security suites (including the flawed AES-CTR), and also provides an additional simple encryption
mode where a 128 bit plaintext is encrypted with a 128 bit secret key. The hardware
implementation of these suites is quite fast: the CC2420 is able to apply AES-CCM
to a single packet in 222µs, and the simple encryption mode works in only 14µs.
However, its ACL has only two entries, thus the chip only provides “out-of-the-box”
support for two neighbors.
Regarding MMX, this SIMD instruction set was designed by Intel and introduced
in 1997 as part of the Pentium MMX microprocessors. Nowadays, this instruction
set is also part of the PXA27X family of microprocessors as “Wireless MMX”. This
extension provides 16 data registers of 64 bits and 8 control registers of 32 bits,
and is able to perform two 32-bit, four 16-bit, or eight 8-bit operations in a single
instruction. These operations range from simple mathematical and logical operations
like rotating, adding and multiplying to other specific operations such as calculating
the vector maximum/minimum.
These kind of extended instruction sets were not designed with cryptographic
primitives in mind, since they are focused on providing support for multimediabased tasks such as video compression, 2D and 3D graphics, and image processing.
Nonetheless, their parallelism capabilities can help to efficiently implement block
ciphers such as AES or Twofish [93], which use simple operations such as XOR
over a set of 8-bit registers. In the case of AES, it has a large internal parallelism,
thus there is potential for optimization. On the other hand, the Pseudo-Hadamard
Transformation in Twofish somewhat difficulties the parallelization process, although
it is still possible to optimize certain parts of the algorithm.
Hash functions can be also improved by the use of MMX instructions. For example, Nakajima and Matsui [104] explored the optimization of MD5, the RIPEMD
family, the SHA family, and Whirlpool, by processing two or three message blocks in
parallel using MMX registers for 32-bit oriented hash functions. This type of parallelization can be possible in embedded systems, but it has not been researched yet.
There were also some optimizations for 64-bit oriented hash functions like SHA-512
and Whirlpool, but these optimizations cannot be applied to the “Wireless MMX”
instruction set, because it cannot parallelize operations over 64-bit fields.
2.1.3.3
Applicability of HW designs
In a sensor network environment, it would be very advantageous to have hardware
modules that offer cryptographic support to the sensor nodes, leveraging the load of
the computing core. While the integration of such modules in a node would surely
increase its price, there might be some scenarios (e.g. military scenarios and critical
50
infrastructure scenarios) that can tradeoff overall cost for increased security.
In fact, the execution time of the most resource-demanding primitive, public
key cryptography, can be greatly improved by using hardware modules. The most
optimal ECC prototype by Batina et. al. [48] is approximately ten times faster than
the most efficient software implementation, and its energy consumption is much
smaller than the energy consumption of the microcontroller. Still, the prototype
performs ECC operations over F2131 , whereas it should be better to use F2163 or
greater for assuring a good security level. Another useful PKC algorithm that can
be integrated in hardware is Rabin. Due to the speed of its operations, it can be used
in scenarios that mainly require the nodes to encrypt messages or verify signatures.
While the integration of cryptographic modules in a node can be costly, there is
no cost associated with using the hardware capabilities that are available by default.
For IEEE 802.15.4-enabled nodes, it can be possible to use the simple AES-128
encryption mechanism already available on hardware as a foundation to implement
CBC-MAC in software [92]. Also, some class III nodes can take advantage of the
Wireless MMX instruction set to optimize the implementation of symmetric key
primitives such as AES and Twofish.
2.2
2.2.1
Key management approaches based on SKC
Key Management Systems (KMS)
Security primitives, such as Symmetric Key Cryptography (SKC), Public key cryptography (PKC), can provide a secure communication channel between two or more
devices with the properties of confidentiality, integrity, and authentication, protecting
the information flow against any unintended recipients. This is essential to create secure protocols and a secure infrastructure, because no external entities or unintended
recipients should be able to manipulate the contents of the messages exchanged by
two peers. However, such security primitives need certain security credentials, i.e.
secret keys, in order to work. The task of creating and distributing these keys, hence
constructing a secure key infrastructure, is done by the Key Management Systems
(KMS).
Creating KMS protocols is a mildly complex task in distributed systems, mainly
because of the capacity of the devices. However, in sensor networks, and due to the
inherent constraints existent in sensor nodes (e.g. memory, computational capabilities), the design of a KMS is not trivial. There are other aspects of sensor networks
that hinder this design process as well. Usually the network designer does not know
the exact deployment point of a sensor node, thus it is unknown which neighbors it
will have and which keys it should be preloaded with. Besides, in most cases the
public nature of the network and its wireless communication channel advises against
the unprotected negotiation of these security credentials.
There are two simple, yet unfeasible, solutions to this problem: global keying
51
and pairwise keying. In global keying, a single key is created for the entire network,
and all the secure communications must be encrypted with that key. In the other
case, pairwise keying, a sensor node must store a key for every other sensor node
inside the network, thus every pair of nodes will have a particular secure channel.
However, global keying has no network resilience because any tampered node will
reveal the global secret key, thus opening all the communications of the network to
any potential attacker. Also, pairwise keying is not a scalable solution due to the
memory constraints of the nodes.
Due to its importance for establishing the foundations of a secure system, the creation of KMS for sensor networks have received increasing attention in the scientific
literature, and many researchers have developed viable and valid KMS. Amongst all
those systems, there are no “ideal” KMS that could be applicable to every scenario.
The reason is simple. Every KMS give some priority to certain objectives, optimizing
certain properties (e.g. scalability) of the network while neglecting others (e.g. network resilience). However, the application and its context enforce the fulfilment of
certain requirements, and these requirements influence over the properties that the
KMS should have. Therefore, if a KMS protocol neglects certain properties, there
will be some scenarios where it will not be useful.
For example, several networks have to operate underwater, with special requirements regarding long and variable propagation delays, and limited bandwidth. As a
result, it is not possible to use KMS protocols that use too much bandwidth. On the
other hand, other networks can provide physical data to a domotics system located
inside a private home. In this case, the size of this sensor network is small, and it
may not be necessary to use complex KMS protocols that offer scalability as one of
their properties.
2.2.2
Analyzing Key Management Systems for Sensor Networks
As it has been mentioned, due to the actual number of KMS protocols, identifying and choosing one KMS protocol for a specific application is not a trivial task.
The requirements of a certain sensor network application will influence over the importance of certain properties (e.g. scalability, network resilience), and the KMS
protocols may be able to comply with those properties (e.g. support networks of
large size) or not (e.g. provide the credentials of other sensor nodes after a node
compromise attack).
Consequently, it is necessary to define which are the properties that a KMS
protocol may have, and how the requirements of the applications (e.g. network
size) influence over the importance of those properties (e.g. scalability). Both the
enumeration of the properties and the link between the application and the properties
have been underdeveloped in the literature, but are essential in order to choose an
adequate KMS protocol.
52
After identifying and defining the possible properties of a KMS protocol, we will
survey the state of the art in KMS protocols, classifying them according to the
nature of their underlying design. By analyzing this classification, we were able
to understand why the protocols included inside a specific framework provide some
specific properties. As a result, this classification will include not only their features
but also the properties that they explicitly have by design.
2.2.2.1
Main properties of a KMS
Property name
Memory footprint [Mem]
Communication overhead [Comm]
Processing speed [Sp]
Network bootstrapping [Sec]
Network resilience [Res]
Global conn. [GConn]
Connectivity
Local conn. [LConn]
Node conn. [NConn]
Scalability [Sca]
Extensibility [Ext]
Energy [En]
Description
ROM and RAM used for the protocol
Number of messages exchanged between peers
Computational cost of the protocol
Confidentiality of the bootstrap process
Resistance against stolen credentials
Existence of a “key path” between any node
Existence of a shared secret between neighbour nodes
Existence of a shared secret between any nodes
Support for big networks
Capability of adding new nodes
Optimization of the energy usage
Table 2.3: Relevant KMS Properties
A Key Management System can be classified by the properties it has. As seen
in Table 2.3, there are, in total, nine major properties, which are subdivided into
eleven properties: Memory Footprint, Processing Speed, Communication Overhead,
Security (Confidentiality), Network Resilience, Global Connectivity, Local Connectivity, Node Connectivity, Scalability, Extensibility, and Energy. For a single KMS,
any property can be positive (i.e. an advantage, the system is quite good at this
particular property), negative (i.e. a disadvantage, the system lacks strength on this
property), or neutral (i.e. the protocol is neither good nor bad in this property). All
those properties are described below.
It is important to note that the requirements of a certain sensor network application influence over the importance of certain properties. For example, an unreliable
communication channel will advise designers to use an algorithm with a small communication overhead. Therefore, the importance of every property (essential, important
but not essential, and non-important) will be determined by the requirements of a
particular application. This issue is also discussed within every property.
Memory footprint. A sensor node is usually very constrained in terms of
memory. For example, a MICAz node has only 4kB of Data Memory, 128kB of
Instruction Memory and 512kB of Storage memory [85], whereas a TelosB node
has 10kB of Data Memory, 48kB of Instruction Memory and 1024kB of Storage
memory [85]. In such context, it is essential for certain applications to reduce the
53
memory footprint as much as possible. Many protocols are designed to reduce the
memory space reserved to the security credentials (i.e., keys), primarily by reducing
the number of keys to be used for bootstrapping the entire infrastructure.
From a development point of view, it is very important to get enough free memory
for implementing the logic of the application. In complex applications, if the security
subsystem wastes too many resources, other subsystems of the node will have not
enough space to compute their tasks. Note that it is always possible to use the
storage memory to store some of the credentials and retrieve them when they are
needed. Nevertheless, this approach would slow down the operations of the node.
Processing speed. Sensor nodes are also constrained in terms of computing
power. For example, both MICAz nodes and TelosB nodes have a 8Mhz microprocessor. Although limited, the sensor nodes are able to provide the services required
by sensor networks at a decent speed. Most KMS are not very computationally expensive, and the time consumed in negotiating the pairwise keys is usually invested
in sending and receiving messages through the wireless channel. However, for some
computational intensive tasks like public key cryptography, the sensor nodes must
spend seconds in order to achieve their tasks.
The processing speed is a critical property whenever it is crucial to set up a
secure channel between two previously unknown sensor nodes in a fast way. As this
requirement decreases, so does the need of having a fast algorithm for negotiating a
secure key. An example of an scenario where processing speed is essential is when a
node located in a mobile entity, like a firefighter or a car, briefly meets with another
similar node and requires to share information with it.
Communication overhead. In most KMS, the sensor nodes must negotiate
with their peers the security credentials that they will share. Due to the size of
the data included inside the negotiation packets and the retransmissions that could
happen during those negotiations, there are some protocols that are specialized in
decreasing the overall communication overhead.
There are many scenarios and applications where the network should reduce its
communication overhead. For example, for a sensor network that must provide its
services as soon as possible, even during the deployment, any extra overhead would
hinder its operations. Also, if the communication channel is unreliable or prone to
errors, a high communication overhead would decrease the network resources faster.
Finally, there are some cases where the network should try to not advertise itself,
like a deployment of a sensor network for monitoring wildlife [64].
Network bootstrapping. The purpose of any KMS is to provide the nodes in
the network with some security credentials that the cryptographical primitives need
for their operation. The whole process of distributing the keys must be secure by
default. For example, the Confidentiality of the key distribution process in the first
moments of life of the network should be assured. However, some protocols consider
that the network is not in danger right after its deployment, thus it may be possible
to exchange secret information without any protection whatsoever.
54
If the environment where the sensor nodes are deployed is secure enough, Confidentiality is not an issue, since there is no attacker on the area that could steal
the security credentials. But problems may arise whenever the deployment area is
public or when the information managed by the sensor nodes is important. As these
two factors increase, so do the chances of a malicious attacker trying to hinder the
operation of the network.
Network resilience. In order to provide the right data, a sensor node must
be located near the source of the possible events. However, this also implies that
any node is vulnerable against physical capture, revealing its security credentials. In
order to avoid the disruption of the network services, some protocols are designed
to increase the network resilience, that is, the ability to cope with stolen credentials
and rogue nodes.
The importance of the network resilience varies depending on the nature of the
environment where the sensor nodes are deployed and on the resources an attacker
has to spent in order to capture a set of nodes. If the environment of a sensor network
is heavily protected or the chances of capturing a set of nodes are extremely low, then
the network designer does not need to take resilience into account. Consequently, the
need for network resilience increases as the chances of a sensor node being subverted
by an adversary become higher.
Connectivity. This network property is related to the chance of two sensor
nodes sharing the same security credentials. In general, most protocols try to provide the maximum connectivity while having a decent memory footprint or network
resilience. There are three main connectivity properties: Global Connectivity, Local
Connectivity, and Node Connectivity. Global Connectivity (Gconn.) is the ratio of
the size of the largest isolated component in the network and the size of network. If
the Gconn. is 100% it means that there is a “key path”, i.e. a secure routing path,
between all the nodes of the network. Local Connectivity (Lconn.) is defined like the
probability that two neighboring nodes share one secret key right after the network
deployment. If the Lconn. is 100% any node can securely communicate with any of
its neighbors without any negotiation. Finally, Node Connectivity (Nconn.) is the
probability of two nodes of the network sharing one secret key, regardless of their
location inside the network. If the Nconn. is 100% any node in the network can open
a pairwise secure channel with any other node.
Global Connectivity is, in most cases, an essential property, because in many
scenarios all nodes are equally important for providing the network services. Since
in most cases the location of the nodes inside the network is unknown, it is usually
important to have a high Local Connectivity, assuring that most nodes will be able
to set up a pairwise key with their neighborhood with as less overhead as possible.
Finally, Node Connectivity is indispensable in scenarios where nodes are mobile, and
it has some importance in risky scenarios where a certain nodes may need to open a
secure channel with other nodes beyond its neighbourhood as fast as possible. Note
that it would seem that Local Connectivity and Node Connectivity are the same
55
property, and, for many protocols, they are equal. However, there are some cases
where the nodes are able to negotiate a secret key with their immediate neighbors,
but not with any other node of the network. Therefore, it is important to make this
distinction.
Scalability. It is widely believed that someday there will be sensor network
deployments of thousands of nodes, even hundreds of thousands. Besides, it is sometimes necessary to increment the number of nodes inside a sensor network to increase
the sensing (or communication) coverage. For those reasons, a key management protocol should be able to negotiate the security credentials regardless the number of
nodes in the network (Scalability), or to include new nodes after the initial deployment finishes (Extensibility).
If a sensor network is composed by a small number of sensor nodes (i.e. less than
100), it can take advantage of protocols that are not scalable but offer other beneficial
properties. However, as the size of the network increases, Scalability becomes a
more important property. Regarding Extensibility, some scenarios must deal with
dangerous external conditions that would render a number of nodes unusable. This
problem is more significant in networks that have to provide a service for long periods
of time. On those networks, there should be some maintenance policies involving the
addition of more nodes inside the network.
Energy. A sensor node relies on batteries for powering itself, thus it must minimize its internal operations (sensing, communication, and so on) in order to live a
long lifetime. Since the negotiation of the security credentials is a time-consuming
and energy-consuming task (inferring the security credentials, sending/receiving data
to/from other peers,...), it is the purpose of some protocols to minimize the energetic
impact of their operations.
Although all protocols in sensor networks should be optimized to spend as less
energy as possible, there are some scenarios where saving energy is not the principal
aspect. For instance, a sensor network with a small useful lifetime does not need to
focus its resources in saving energy. Also, if accessing and maintaining the sensor
nodes is not a complicated and time-consuming operation, it is clear that the network
operators could easily replace the batteries of a sensor node if needed. Finally, there
are some network configurations where the sensor nodes can access to an “unlimited”
energy source, such as solar energy.
2.2.2.2
KMS frameworks
The problem of creating a secure and efficient Key Management System for Sensor Networks has spanned three major KMS frameworks: “Key-Pool” Frameworks,
Mathematical Frameworks and Negotiation Frameworks (see Figure 2.1). Each one
of these frameworks are focused on solving the KMS problem while trying to achieve
a balance in the overall properties of the system. It is worth mentioning the existence
of a fourth framework, public key framework, that is actually underdeveloped because of the widespread notion that public key cryptography is not feasible in sensor
56
KMS Frameworks
PKC-based
SKE-based
Mathematical-based
Key Pool-based
Combinatorics
Linear Algebra
Alg. Geometry
Negotiation-based
Figure 2.1: KMS frameworks for WSN
networks, whereas recent discoveries on the area (cf. section 2.1.2.2) proof the opposite. In the following, the first three frameworks will be presented, alongside with
their evolution and the properties that they explicitly have by design. The fourth
framework will be discussed in detail in section 2.3.
“Key Pool” Framework. The “key pool” paradigm is the pillar behind one of
the most important KMS frameworks to date. The main idea behind this framework
is quite simple: the network designer creates a “key pool”, a large set of precalculated
secret keys, and before the network deployment every sensor node in the network
is assigned with a unique “key chain”, i.e. a small subset of keys from the “key
pool” (Key pre-distribution phase). After the deployment, the sensor nodes can
interchange the identification numbers of the keys from their “key chains”, trying
to find a common key (shared-key discovery phase). If they find that they share
a common key, that key (or a derivation from that original key) will be used as
the pairwise key between the two sensor nodes. Otherwise, if two nodes want to
communicate but they do not share any key, they will try to find a “key path”
between them in order to negotiate a pairwise key (path-key establishment phase).
The basic scheme, introduced by Eschenauer and Gligor [122], is able to provide a
low memory overhead, due to the reduced size of the “key chain” in comparison with
the size of the “key pool”. It is also scalable, since the growing factor of the “key
chain” given a certain fixed connectivity is low. However, the overall connectivity
of the network depends on the probability that two nodes share a key in their “key
chains”, that is, the relationship between the size of a “key chain” and the size of the
“key pool”. The network resilience is affected by this as well: the more keys that are
obtained from stolen “key chains”, higher the chances of breaking the communication
channels. The communication overhead is also affected by the connectivity and the
number of keys in the “key chain”: every sensor node has to broadcast the ID number
of all their keys, and the lower the connectivity, the higher the number of “key paths”
that needs to be found. Finally, the overall security of the scheme is affected by the
unprotected transmission of the ID numbers of the keys.
The original scheme has been expanded by many researchers, trying to solve or to
57
improve the limitations associated with the “key pool” paradigm. One approach is
to optimize the assignment of the “key chains” by using Deployment Knowledge, i.e.
the knowledge of the final location of the nodes in the field. If a network designer
knows the area where a certain node is going to be deployed [128] (and, in some
cases, the probability density function that models the final location of the sensor
nodes [139]), it is feasible to construct and assign the “key chains” in a more efficient
manner, increasing the connectivity. The network designer may also know which are
the neighbors of any sensor node inside the network [131], thus creating a totally
optimized “key chain”.
Another approach is to reduce the communication overhead by linking the IDs of
the keys from a “key chain” to a simpler, smaller parameter. One idea is to cluster
the keys from the “key chain”, where a sensor node can deduce the IDs of the keys
inside a cluster given its representative ID [124]. Another idea consists in deducing
the IDs of the keys inside the “key chain” by using the ID of the sensor node and
a certain function [133, 137]. Finally, it is also possible to associate a key from the
“key chain” with the identity of the sensor nodes that also holds that key [121]. In
all cases, the communication overhead is reduced to one ID per node.
Other approaches change the behavior of the sensor nodes in the shared-key discovery phase, requiring them to have more than one common key in their “key chains”
in order to increase the network resilience, at the cost of decreasing the network connectivity [121]. Finally, the construction of the “key pool” can also be optimized.
One example is to shape the “key pool” as a grid and assign a row and a column
of keys to every node √[138], increasing the network Scalability (every sensor node
receives a total of 2 ∗ n keys, being n the number of sensor nodes inside the network) and decreasing the communication overhead if the designers of the network
take advantage of the Deployment Knowledge.
Mathematical Framework. Certain KMS use mathematical concepts belonging to the fields of Linear Algebra, Combinatorics and Algebraic Geometry for calculating the pairwise keys of the nodes, being by combining certain information after
the deployment phase or by specially crafting a “key pool”. All these KMS belong
to the Mathematical Framework, since they share some common properties. On the
one hand, their connectivity is very high, since by design almost all sensor nodes
can have a pairwise key with any node in the network. Also, the communication
overhead is low, since the nodes need to share only small bits of information. On
the other hand, the memory footprint is usually high because all nodes need to store
certain mathematical information (e.g. rows of a matrix), and the network resilience
and the scalability is highly tied to the design of the underlying mechanisms.
In the field of Linear Algebra, the most important scheme is the Blom scheme
[126]. In this scheme, there is a (λ+1)×N public Vandermonde matrix G, a symmetric random (λ + 1) × (λ + 1) secret matrix D, and a matrix A where A = (D · G)T . If
every node i stores a row of A and one column of G, every node can calculate the pairwise key it shares with another node j by doing A(i)·G(j) = A(j)·G(i). On the field of
58
Combinatorics, the Generalized Quadrangle and Symmetric Design models [120] are
the most important. Using Generalized Quadrangles GQ(s, t) a network designer can
construct a “key chain” of size s+1 where GQ(s, t) = GQ(q, q) = q 3 +q 2 +q+1 >= N .
Otherwise, by using Finite Projective Planes F P P (q) a network designer can construct a “key chain” of size q + 1 where q 2 + q + 1 >= N . In both Generalized
Quadrangles and Finite Projective Planes q must be a prime power. Finally, on
the field of Algebraic Geometry, the most important scheme is based on Bivariate
Polynomials [132]. In this scheme, every node A in the network is able to solve a
function f (A, y), where y is the identity of another node of the network, and f is a
bivariate polynomial of degree λ generated over a Finite Field Fq , being q a prime
large enough to contain a pairwise key, that satisfies the property f (x, y) = f (y, x).
All the previous schemes, with the exception of the Generalized Quadrangle,
provide full connectivity inside the sensor network, since every node can calculate
by itself the pairwise key that it shares with another node. However, these designs
are often difficult to apply, and they are not very scalable: The Linear Algebra and
Algebraic Geometry schemes needs a high amount of memory in order to store the
mathematical structures (i.e. rows of matrices and polynoms, respectively), and the
Combinatorics schemes only work as intended for certain network configurations (i.e.
when GQ(q, q) = N or F P P (q) = N ). These problems can be partially solved by
combining the basic schemes with the “key pool” paradigm. As a result, the keys
belonging to a pool are not keys, but tuplas of (D, G)i matrices [126] or bivariate
polynomials fi (A, y) [132]. Also, in the schemes that already use “key pools” such
as the Combinatorics schemes, the solution consist on constructing new “key chains”
that are derived from the previously existent chains, adding a probabilistic extension
to the deterministic core [120]. The drawback of these solutions is that the nodes
lose, although not to a great degree, their perfect connectivity.
There are some variations to the original schemes that pursue to increase the
network scalability as well, sacrificing other features like Local Connectivity. One
Blom-based scheme divides the network into a bipartite key graph, i.e. a graph where
all nodes in a set U are connected to at least one node in another set V and viceversa,
but there is no connection between nodes belonging to the same set [130]. As a result,
it is quite possible that many nodes will not share a pairwise key, but more nodes can
be included inside the network. Another polynomial-based scheme assigns a virtual
coordinate to every node, and all nodes belonging to the same virtual row or column
can calculate a pairwise key [132]. Both schemes can be enhanced if the deployment
information is known in advance [130],[132].
It is always possible to improve the features of the basic schemes if the deployment information is available in advance as well. On Blom-based schemes the nodes
belonging to the same area (i.e. an hexagon) share rows of the same secret matrix A,
while nodes belonging to adjacent areas can share rows of certain secret matrices F
to assure Global Connectivity [135]. The same idea can be used in polynomial-based
schemes: nodes deployed inside the same area can get 6 distinct polynomials, thus
59
they will be able to communicate with the nodes of the same area and with the nodes
in the adjacent areas [136]. Such schemes increase the network scalability without
sacrificing the local and Global Connectivity.
Negotiation Framework. It can be possible to let sensor nodes negotiate their
keys with their closer neighbors just after the deployment of the network, requiring
none or few steps in the Pre-distribution phase. This self-configuration approach is
usually seen as non-feasible because any potential adversary can attack the network at
this point and obtain the messages that contain the secret keys, effectively thwarting
the overall security of the network. However, it can be assumed that in several
scenarios the sensor nodes and the network itself are not endangered in the first
steps after the deployment, because the resources that an attacker has to spend in
order to break the security of the network does not justify the benefits obtained
from that attack. All the schemes that take this assumption into account can be
considered part of the Negotiation Framework.
All these schemes are extremely efficient in terms of memory, because all sensor
nodes only have to store the pairwise keys they share with their neighbors, scalability,
since the size of the network is not an issue, and resilience, as a sensor node can
only disclose the keys it share with its neighbors if an adversary takes control of
it. They also have a small energy consumption and a small communication overhead
(required to send the information needed to construct the keys and calculate the keys
themselves). Nevertheless, the connectivity of the network is strictly restricted to,
basically, one-hop neighbors. Also, the overall security of these schemes is usually
non-existent, since any entity listening to the communication channels can obtain
or derive the secret keys. As a result, these schemes are usually applied under the
assumption that there is little or no treat against the integrity of the network in its
first moments of life.
Improvements over the basic scheme involves increasing step by step the radio
transmission of the negotiation messages with different key materials, in order to
avoid other sensor nodes, being friendly or malicious, to learn the pairwise key between two nodes [119, 134]. The nodes can be also preloaded with a master secret
key in order to provide some level of protection to the first negotiation steps [123]. If
the network designer has an accurate knowledge of the deployment of the network,
i.e. the groups in which the network is going to be divided, that master key can also
be different for every group [127].
2.2.3
KMS Guidelines
One of the initial problems that a network designer must face in order to create secure
sensor networks is to choose an adequate KMS protocol for an specific application.
However, at present, it is quite difficult for those designers to select a single protocol
from all the existent research. In their descriptions, the protocols does not clearly
state which are the advantages and disadvantages they offer. Also, although there are
60
some research on the field [117] that offers a comparison of every KMS protocol, it is
still difficult for a designer to use those surveys as a tool, because they do not clearly
state which are the properties that those protocols have and in which scenarios they
would work better.
To solve this matter, we have developed a methodology (henceforth known as “the
(KMS) Guidelines”) [256] that allows any user to easily select a KMS protocol based
on the needs of the network application. The main goal of the Guidelines is threefold.
First, to facilitate the deployment of any real-world WSN application. By providing
network designers with a useful methodology, simple and very straightforward, it
will be a simple task to include support for key management in any sensor network,
because the network designer can distinguish in every situation which protocol is
the most suitable to the context where the network is going to be deployed. The
Guidelines are very easy to update, thus any final user can quickly take advantage
of any new protocols designed by the research community.
Second, to check whether the current state of the art in KMS can offer a viable
solution to the key establishment problem in wireless sensor networks. It is possible
to classify the existing applications for sensor networks into groups, and derive some
common properties from the requirements of those applications. By using those
requirements and the guidelines, we can analyze which are the actual KMS that are
more suitable to the actual applications.
Third, to determine where researchers should focus their effort in order to create
useful KMS protocols that could be used in real-world applications. Research on
key establishment for sensor networks is still strong as of 2008, but it is not exactly
known which are the most important research goals that are yet to be solved. The
guidelines will help to locate those goals by analyzing the application groups that
does not have a set of optimized key management protocols.
2.2.3.1
The methodology
The first component of the Guidelines is a table (the KMS Table) that contains KMS
protocols in two-column format. This table classifies the SKC-based KMS4 according
to their properties (cf. section 2.2.2.1), rather than their features or the underlying
mechanisms employed in their construction, such as Key Pools or Combinatorial
Designs. As the main purpose of a protocol is to fulfill the application requirements,
this approach is more suitable for comparing the applicability of KMS protocols to
real world scenarios.
The first column of the KMS Table specifies the name of the protocol in our
Guidelines (AT -number), followed by its “official” name given by their authors and
a reference to the publication where the detailed description of the protocol can be
4
Note that, for the sake of comparing SKC-based key management protocols with PKC-based
key management protocols, we have included Public Key Cryptography inside the KMS Table,
labelled as AT-XX.
61
found. The following columns shows the advantages and disadvantages of every protocol, that is, which properties does and does not fulfill a certain protocol. This table,
alongside with a deeper explanation about its notation, is shown in section 2.2.5.
The second component of the Guidelines is a set of rules that are applied sequentially to the KMS Table. The main purpose of this process is fairly simple: to
exclude the KMS protocols that are not suitable for a certain WSN application given
its requirements. Therefore, a network designer will not need to know and review all
the existent KMS protocols, just the protocols given as an output. These rules are
explained below.
1. The network designer must find out which properties are essential for a KMS in
the context of the application, called Main Properties, and which properties are
important but not essential in the context of the application, called Secondary
Properties. A network designer can deduce which properties are needed in
his/her own scenario by analyzing the requirements of the scenario and the
application based on the descriptions included in section 2.2.2.1.
2. The network designer must select all the KMS from the KMS Table that contain
one or more main properties in its advantages. This set of KMS will be called
KMS Candidate Set, and will contain all the possible protocols that could be
used for protecting the specific sensor network.
3. From the KMS Candidate Set, the network designer must discard all the protocols that have one of its main properties or secondary properties in its disadvantages. Note that if a property α is affected by the variables used on the design
of the protocol (i.e., the property is (-) or (X) or (×)), it should be ignored. As
a result of this step, the KMS Candidate Set will only contain protocols that
at least are good enough to respect the properties of the application.
4. From the resulting KMS Candidate Set, the network designer must discard all
the protocols that does not have every main property in its advantages. As a
result of this step, the KMS Candidate Set will contain protocols that provide
the essential properties required for the application.
5. Finally, the network designer must review the protocols contained in the KMS
Candidate Set, and choose the more suitable for the context of the application.
Note that it is possible to order the protocols inside the set by importance:
Those protocols with all or some of the secondary properties in its advantages
will be more interesting than the others. Also, the network designer must pay
attention to the design parameters of a protocol if a main or secondary property
α is dependant on them.
It is possible to obtain an empty KMS Candidate Set while applying the Guidelines, in case where there is no protocol that is able to fulfill the requirements needed
62
Figure 2.2: KMS Guidelines web application. Input screen & Results screen
by the application. Such situation is normal with the current State of the Art: There
are still some open issues in scenarios that researchers have to solve. It is also perfectly possible that there is no existing protocol that is able to fulfill the needs of the
designer, since every protocol must balance the importance of its properties in order
to provide the key management services.
In either case, a network designer can apply the Guidelines again, but this time
marking the properties that does not fulfill the requirements of steps number 3 (Main
Property ∨ Secondary Property ∈ Disadvantages [×]) and 4 (Main Property 6∈ Advantages [X]). Using the resulting list, the network designer can choose some KMS
that have less marked properties. After this point there are two options: Apply one
of those protocols for that scenario, or start a line of research based on the resulting protocols in order to create a new one that would fulfill the requirements of the
scenario.
Since the area of Key Management Systems is very dynamic, it is important to
assure that the Guidelines are extensible, i.e. that new protocols could be added
without major effort. This is in fact fairly easy: once a new protocol is discovered,
its creator should point out what advantages and disadvantages has the protocol
according to the properties presented in section 2.2.2.1. After that, the protocol can
receive an unique number inside the Guidelines, and be added into the KMS Table.
2.2.3.2
The prototype
Given that manually applying the Guidelines is a tedious process, we have designed
a web application that greatly facilitates the task of obtaining a KMS protocol.
This web application uses as an input the main and secondary properties required
63
by a certain scenario. Then, it returns the possible protocols that the designer
could use sorted by relevance, even in the case that there is no KMS protocol that
can fulfill the designer’s needs. This web application has been published under
the Spanish project CRISIS (CRitical Information Infrastructures Security based
on Internetworking Sensors)5 , and it is free to use for both academic and industrial
purposes.
The application is simple and easy to use. First, as seen in Figure 2.2a, the user
must input the Main Properties and the Secondary Properties of its application,
alongside with other information such as if the location of the sensor nodes are
known in advance. The interface of the application also offers context-sensitive help
for every listed property. After the properties are selected, the application will select
the most adequate KMS protocols and will present them to the user in order of
importance, as shown in Figure 2.2b. Lastly, it is possible to set up the application
to produce a printer-friendly result, thus the user can print such results and review
them later.
2.2.4
Applying the KMS Guidelines
As aforementioned, there is no Key Management System that can be considered as
“ideal” for every scenario: the context and the requirements of the applications that
are needed for every scenario are quite different from each other. However, it is
possible to recommend which set of KMS protocols can be used in certain scenarios
by applying the KMS Guidelines. From the requirements of every scenario, the
Guidelines will output the most suitable set of protocols.
This section will show how the Guidelines can be applied, and how it fulfills
the three goals that were presented before. First, a single application belonging
to a scenario will be analyzed, and the output of the Guidelines will be discussed.
Second, a set of real-world applications will be grouped according to their network
features and size, and it will be shown what kind of Key Management Systems can
be used for every one of the groups according to the Guidelines. Third, there will
be some discussions about the results produced by the Guidelines, that will help on
determining where researchers should focus their effort in order to create new KMS
protocols.
2.2.4.1
Using the methodology: a concrete example
One of the goals of the methodology was to provide network designers with a tool,
which could be used to find a set of suitable KMS based on the requirements of their
specific applications. A way of demonstrating this functionality is to elaborate an
example step by step. By using it, is possible to verify how the protocols that better
adjust to the original requirements are obtained as an output, using as input the
properties of an scenario.
5
http://www.isac.uma.es/CRISIS/
64
The example application will be “Monitoring of Ageing Infrastructures” [21].
In this application, a wireless sensor network system was deployed to monitor the
condition of a stretch of London Underground tunnel due to the construction of a
new tunnel on that area. In this specific trial, sensors transmitted the data to the
Base Stations located in the columns, and then the data was forwarded to a central
database. To point out the importance of this scenario, it should be noted that many
London Underground tunnels are over 75 years old, for example, and there are still
miles of cast-iron Victorian water mains in the UK.
The first step consist on finding out which are the main properties and the secondary properties of the application. The main property is Global Connectivity,
and the secondary properties are Resilience, Security, Local Connectivity, Scalability, Extensibility, and Node Connectivity. We will now explain in detail why these
properties were chosen.
Global Connectivity is considered a main property because in this application it
is essential for all sensor nodes to be able to find a routing path with each other at
any time, since an underground tunnel is a risky environment. The importance of the
application and the characteristics of the underground tunnel also make necessary to
consider Node Connectivity and Security as secondary properties: a node should have
some chances to connect to other nodes beyond its direct neighbourhood for safety
purposes (e.g. when the nodes in the immediate neighbourhood are inoperative),
and the initial keys exchanged in the deployment site should be safe.
Another three properties to consider as secondary properties are Scalability, Local
Connectivity, and Extensibility. Regarding Scalability, the number of nodes required
to provide the services is considerable, although mostly sure less than 1000. About
the Local Connectivity, it is important for the neighbours to have as few negotiations
as possible for establishing the pairwise keys. Finally, Extensibility is important
because there might be the need of changing existent faulty nodes during the course
of the application.
Now, there are some properties that are neither main nor secondary. Speed is not
an important issue because there is no need to quickly set up the sensor nodes for
negotiating the keys. About Memory, at this point it is still unknown which are the
exact requirements of the application, but the task of this network is just to collect
data and route it to the base station.
The Communication Overhead is also not essential. The network size is not large
and dense enough to consider reducing the overhead to a bare minimum. Also, the
importance of the Local Connectivity reduces the possible number of negotiations.
Lastly, Energy is always a factor to consider in every sensor network, but in this case
the nodes only calculate the keys on the start of the deployment, and the network
was useful only while a new tunnel was being built.
After the Main and Secondary properties are discovered, it is time to apply the
Methodology, constructing the KMS Candidate Set. The network designer can do
this operation manually, following the steps in section 2.2.3.1, or automatically, using
65
the web application shown in section 2.2.3.2. The results are the following: ATXX (Public Key Cryptography), AT-25 (Polynomial-Based Key Predistribution),
AT-41 (Dynamic Cluster-Based KMS), and AT-04 (Hybrid Designs - Generalized
Quadrangle).
Arrived to this point, it is up to the network designer to review and choose which
protocol is more suitable for his/her application. Since the network is organized in
a pseudo-cluster fashion (sensor nodes in the tunnel, base stations on columns), the
cluster-based protocol AT-41 can be applied. Still, AT-25 is simple, and offers all
the secondary properties as advantages. In addition, AT-XX (PKC) is complex, but
also can be a good choice for this scenario. The rest of the protocols (AT-04) could
also be useful, although many of their properties depends on the final parameters of
their design.
2.2.4.2
Grouping real-world applications
Scenario Type
One-Hop Net.
Simple
Simple Net.
Medium
Large
w. Mobile B.S.
Small
Small
w. Mobile Nodes
Medium
Short-lifetime Net.
Small
Examples
Industrial machinery
Office Monitoring
Wine production industry
Wildfire detection
Vehicle Tracking
Assisted-living residents
Safety-critical structures
Measuring noise pollution
Properties
LConn
GConn, LConn
Sca, GConn, LConn
Sca, GConn, LConn, Comm
GConn, LConn
NConn, GConn, Comm, LConn
NConn,Sca,GConn,Comm,LConn
LConn, Comm, En, Ext
Table 2.4: Classification of Real-World WSN applications
The number of scenarios where sensor networks can be used is specially broad.
Generally speaking, WSNs can be used in applications where sensors are unobtrusively embedded into systems, consequently involving operations like monitoring,
tracking, detecting, collecting or reporting. Such applications can range from simple
systems like measuring the environmental situation of a household to critical applications like monitoring the health of workers and the robustness of the infrastructures
of a coal mine.
In order to analyze which are the Key Management Systems that are more appropriate for a set of well-known applications, we have grouped them in Table 2.4
according to the mobility of the nodes and the network size. For all groups, we also
have detailed which must be the properties that are to be considered main (in roman
type), secondary (in italic type), or should be ignored (in strikethrough text). We
outline why we have chosen these properties to be (un)important for a certain group
in the following paragraphs.
The most simple networks are the One-Hop Networks, in which there is a single
base station and all the sensor nodes can communicate with it in one single hop or
66
two. In these networks, the Local Connectivity is a main property, since all sensor
nodes need to talk with the base station and, in some cases, with each other.
The next group is the Simple Networks, which are the sensor networks with only
one base station and with a network of static nodes. Regarding small networks (less
than 50-100 nodes), Local Connectivity is a secondary property, since it is permitted
to have some negotiations to create a pairwise key with the neighborhood. However,
Global Connectivity is a main property, because in small networks all nodes should
be connected to the network.
In Medium networks (less than 500-1000 nodes), both Global Connectivity and
Local Connectivity are secondary properties, since the redundancy of the network
allows to have a tiny fraction of the network unconnected. Scalability is also a secondary property, due to the size of the network. Lastly, in Big networks (more than
1000 nodes), Scalability is a main property because of the number of nodes. Other
secondary features are Local Connectivity, Global Connectivity, and Communication
Overhead, since the number of broadcasted messages should be reduced due to the
high number of nodes.
When the Base Station is mobile, it would seem that the situation is very different
than the previous scenarios. However, this is not the case. In Networks with Mobile
Base Station(s), the sensor nodes will have the same neighbors in all their lifetime,
with one exception: the base station. Therefore, the management of the keys in
the networks will be almost like the Simple Networks, but Global Connectivity and
Local Connectivity should be always main properties, due to the need of the routing
algorithms to be always connected to the base station.
The situation changes drastically when the sensor nodes are the devices that
move over the deployment field. In both small and medium-size networks of Mobile
Nodes with a Static Infrastructure, the Node Connectivity is a main property, because
it is essential to assure that all nodes are able to communicate with each other.
Another property to be considered as a secondary property is the Communication
Overhead, since the negotiations in certain periods of time can be plentiful. Finally,
the importance of other Connectivity properties (Global and Local) and Scalability
is the same as in Simple Networks. In addition, Speed could be considered as an
important property (main or secondary) depending on the actual speed of the nodes.
Finally, for Short Lifetime Networks, the application just requires to measure a
certain factor for a short period of time. This lessens the complexity of the network,
and as a result, properties like Energy and Extensibility become irrelevant. Moreover, Communication Overhead could turn out to be important because of staggered
deployment and the significance of start providing services as soon as possible.
Note that, both in Table 2.4 and in the previous paragraphs, we have not considered properties such as energy, extensibility, memory, resilience, security, and speed.
This is because, for classification purposes, we only point out those properties that
are relevant to the mobility of the nodes and the network size. The requirements of
the application and its context will indicate the importance of all those properties,
67
regardless of its mobility and size.
2.2.4.3
Protecting the groups through the methodology
Once is known how to apply the Methodology to a single application, it is time to
infer what are the best protocols and frameworks that could be used for protecting
the groups presented in the previous section. In fact, applications belonging to
the same group share most of their primary and secondary properties. Hence, the
protocols that are suitable for a certain group will be also suitable, in most cases, to
an application belonging to that group.
This analysis will have two parts. First, we will analyze the suitability of the
protocols by considering only those properties indicated in Table 2.4. Second, we will
take into account the properties indicated in Table 2.4 and all the other properties:
energy, extensibility, memory, resilience, security, and speed.
After performing the first analysis, it can be concluded that, as of 2008, it is
perfectly possible to provide link-layer secret keys to almost any kind of static sensor
network if only the size of the network and the node mobility are considered. In onehop network, simple - small networks, and short-lifetime networks, there is no need
to use complex protocols that need of “key pools” or complex negotiations: simple
mathematical schemes such as the Blom Key Predistribution and Polynomial Key
Predistribution are enough. On simple - medium/large networks scalability starts to
become an issue, and it is better to use other kind of protocols, such as Cluster-based
protocols like Panja or any “Key Pool” protocol. Note that other simple negotiation
schemes, such as Key Infection, may also work on any kind of static scenario.
Scenarios with Mobile Base Stations do not pose a problem, since a sensor node
may share a preinstalled pairwise key with that Base Station. As a result, it is
possible to use almost any of the protocols utilized on static networks. On the
other hand, in networks with mobile nodes, the number of protocols that fulfill their
requirements is limited. Nevertheless, Blom and Polynomial Key Predistribution
may work for small networks, but for bigger networks it may be necessary to use
PKC-based protocols.
While the results from the first analysis look promising, the results from the
second analysis are not so optimistic. One of the major problems that arises is the
issue of the extensibility of the network. Almost all the existing KMS protocols can
afford to install a few nodes after its initial deployment. However, most protocols
include by design a limit to the number of nodes that can be added after the initial
deployment. Therefore, the network designer will have almost no protocols to choose
if his/her application needs to change nodes or add new nodes from time to time.
A similar problem happens with Resilience. Many protocols are partially resilient,
and in fact, it is perfectly possible to choose a KMS protocol that provides partial
resiliency and partial extensibility. However, few protocols provide an almost perfect
resilience: that is, when a node that do provide little or no information about the keys
contained in other nodes. In this case, the explanation is simple: most protocols base
68
their design either on including more keys inside the node or on embedding certain
mathematical information (e.g. a column / row of a matrix), shared with other
nodes, that can be used to calculate a shared key.
The case of Speed is quite interesting. This property is essential in those networks where mobile nodes must establish a secure channel as fast as possible (almost
immediately) with other peers. However, there are very few protocols that can assure Speed and Node Connectivity at the same time. Moreover, if Extensibility is
required, then there is only one useful protocol, and this protocol (based on Generalized Quadrangles) is highly dependent on knowing in advance the maximum number
of sensor nodes included inside the network.
Regarding the security property, if the security of the network during its initial
deployment is not important, it can be possible to use some negotiation-base protocols such as Key Infection in all the groups. However, if the Extensibility or even
the Resilience (in some cases) of the network becomes important, these protocols
can not be applied to the network. As for Energy, very few protocols are especially
energy-consuming. The existing KMS protocols are also optimized to consume as
less memory as possible, so Memory is not a big issue.
As a final note, it is necessary to point out one particular problem that may
arise in certain large networks. It has been said in section 2.2.4.2 that, for large networks, the redundancy of the network allows to have a tiny fraction of the network
disconnected, thus global connectivity can be considered as a secondary property.
However, there are some situations (e.g. in actuator networks) where there should
be no sensor nodes disconnected from the network. In these situations, global connectivity becomes a main property, and most “key pool” based frameworks cease to be
useful. Even more, if extensibility becomes of importance (even as a secondary property), very few KMS protocols (mostly those based on mathematical frameworks)
can become useful for the network designer.
2.2.4.4
Open issues
The actual state of the art in KMS protocols for sensor networks allows the protection
of certain specific applications, mostly those applications with a small / medium
network size, limited resilience capabilities against malicious attackers, and able to
add some new sensor nodes after the deployment. As a result it can be affirmed, at
least from the point of view of key management, that the communication channel of
some sensor networks applications can be adequately protected as of 2008. However,
there are some issues that remain to be solved.
One of the open issues is to develop a KMS protocol with superior Extensibility
and Resilience properties. In fact, most KMS protocols do not pay attention to
the need of adding new sensor nodes to a sensor network after its deployment. This
particular viewpoint needs to change. Regarding Resilience, it is true that most KMS
protocols are based on redundancy (including extra security credentials) in order to
allow nodes to find and share pairwise keys with their neighbourhoods. While there
69
is the need of finding new design assumptions beyond redundancy, it is not clear if
it can be possible.
The creation of KMS protocols that are particularly suitable for certain scenarios
is another open issue that needs to be solved. Two of those scenarios have been
highlighted in the previous section, and are i) a network with mobile nodes that
move at a high speed, and ii) a static network of medium / large size where no nodes
should be disconnected from the network. It is even possible to find an additional
scenario: iii) an extensible network with almost no communication overhead, that
is, where the communication overhead is a main property (e.g. underwater sensor
networks).
At this point, we should also analyze why protocols AT-25 (Polynomial Key
Predistribution) and AT-13 (Blom Key Predistribution) are recommended most of
the time for covering the security requirements of the applications. In fact, network
designers may not understand this output from the methodology after reviewing the
internal operations of these protocols, because they are extremely simple and are
used as the building blocks for more complex and evolved protocols such as AT-26
(Key Predistribution using Random Subset) and AT-20 (Multiple Space Blom).
The reason is that these complex protocols were created for assuring the scalability of sensor networks, supporting dozens of thousands of nodes. However, most
actual applications are small or medium-size, with a number of nodes ranging from 50
to 1000. And for this size, the simpler protocols are good enough. Still, the security
of these primitives used by mathematical-based frameworks have not been formally
proven yet. If these primitives were to be found not secure, then there would be
more scenarios that need to find an adequate KMS protocol.
Before finishing this discussion, it is necessary to point out the possibility of
using Public Key Cryptography to distribute the keys of the network. In fact, in
almost all applications and scenarios, PKC is one of the most optimal solutions for
setting up and maintaining the keys of sensor networks. This technology was deemed
unsuitable for nodes due to their hardware constraints like limited computational
speed or memory size, but advances in the field like elliptic curve cryptography
(ECC) demonstrated that it is possible to calculate PKC operations in nodes (cf.
section 2.1.2.2). Discussions about the use of PKC will be included in section 2.3.
70
2.2.5
KMS Table
The notation used in the KMS Table is explained in the following table:
Notation
X/ ×
(X) / (×)
(-)
Description
Advantage / Disadvantage
Advantage / Disadvantage, depending on the design of the protocol
Either advantage or disadvantage, depending on the design of the protocol
Location of sensor nodes known before deployment
Also, every property is abbreviated: Communication Overhead (Cm), Global
Connectivity (GC), Local Connectivity (LC), Node Connectivity (NC), Energy (En),
Extensibility (Ext), Memory Footprint (Mm), Network Resilience (Rs), Scalability
(Sc), Security (Sec) and Speed (Sp).
Protocol
AT-01 - Key Infection [119, 134]
AT-02 - Generalized Quadrangle [120]
AT-03 - Symmetric Design [120]
AT-04 - Hybrid Designs - Gen. Quadrangle [120]
AT-05 - Random Pairwise Key [121]
AT-07 - Q-Composite [121]
AT-08 - Basic Prob. Key Predistribution [122]
AT-09 - BROSK [123]
AT-10 - Cluster Key Grouping [124]
AT-11 - Co-operative Pairwise Key Est. [125]
AT-13 - Blom Key Predistribution [126]
AT-14 - Multiple Space Key Predistribution [126]
AT-16 - Key Predistribution and D.K.[128]
AT-17 - Transmission Range Adjustment [129]
AT-18 - Mul. ID-Based one-way Function [130]
AT-20 - Mul. Space Blom (MBS) [130]
AT-21 - DMBS [130]
AT-23 - Closest Pairwise Key Predis. [131]
AT-24 - Grid Based Key Predistribution [132]
AT-25 - Polynomial Based Key Predis. [132]
AT-26 - Key Predis. using Random Subset [132]
AT-30 - RINK-RKP [133]
AT-33 - YG Blom Scheme [135]
AT-34 - LLK [136]
AT-36 - PIKE [138]
AT-37 - RKDS-PDF [139]
AT-40 - LEAP [140]
AT-41 - Dynamic Cluster-Based KMS [141]
AT-42 - Panja [142]
AT-XX - Public Key Cryptography-based KMS
Cm
(×)
×
X
(×)
(×)
X
(-)
×
X
(×)
(×)
×
×
X
(×)
X
X
X
(×)
GC
X
X
X
(-)
(-)
(×)
(×)
X
(×)
X
(×)
(-)
(×)
X
(×)
X
X
X
(×)
(×)
X
X
(×) (×)
(×) (-)
X
X
X
X X
LC NC En
X × (X)
×
X X
(-) (-)
(-) (-)
(×) (×) ×
(×) (×)
X × (X)
(×) (×)
×
X X
(×) (×) ×
(-) (×)
(-) (×) (-)
X ×
(×)
X
X
X
(×)
(×)
X
X
(×)
(-)
X
X
X
X
Table 2.5: KMS Table
(×)
×
×
X ×
(×) ×
(×)
(×)
(×) ×
(×)
(×)
×
×
X
×
Ex Mm Rs Sc Sec
× X X X ×
× X
× X ×
(×) X
(-)
× (×) (×) X X
(×) (-)
(-) (×) X
(×) X × X ×
(-) (×) X
X
X
× (-) (-) (-)
(-) X X
X (-) X
X (×)
×
× X × X
× (-) (-) (-)
(-) X X
× X X × X
× (-) X (-)
X (-) (-) (-) X
(-) (-) X
(×) (×) X X
× (-) X X
X (-) X X
(×) X
X
X (-) X
×
X
X (×) X
× X × X
X
X X X
Sp
(X)
X
X
X
×
×
×
×
X
×
×
×
×
X
×
×
71
2.3
2.3.1
Key management approaches based on PKC
The case of traditional asymmetric cryptography
One of the multiple uses of asymmetric cryptography has been to securely bootstrap
the pairwise key of two nodes over a public communication channel. Two nodes
just need to interchange their public keys and some information that will be used
to create the pairwise secret key and its associated values like initialization vectors.
If the public keys are certified by a trusted third party, both peers will be also
authenticated.
It has been proven that PKC is possible for sensor nodes using Elliptic Curve
Cryptography, for example by using an implementation of the ECDH-ECDSA handshake protocol [118] or by using the Elliptic Curve version of the Menezes-QuVanstone protocol, ECMQV [158, 157]. In fact, an implementation of ECDH is
available for sensor nodes in the TinyECC library6 [62]. With all the optimization
switches enabled, a MICAz node executes the ECDH operation in 2.1s, using ∼16kB
of ROM and ∼1.7kB of RAM. The TelosB executes the ECDH operation in 3.5s,
although the memory consumption is smaller: ∼11kB of ROM and ∼1.8kB of RAM.
As a result, it could be possible to create a framework that uses PKC to allow any sensor node to negotiate pairwise keys with its neighbors. In terms of the
properties presented in section 2.2.2.1, this solution is extremely good in terms of
security, scalability, connectivity, and resilience, with a small communication overhead while sending and receiving the public keys. The disadvantages of this solution
in comparison with the other frameworks is the high amount of memory required to
implement the actual PKC procedures and the time and energy needed to complete
the negotiation.
It would seem that for every single situation PKC (or any hybrid framework
based on PKC) is the ideal KMS protocol, obsoleting every KMS protocol based
on symmetric cryptography. Nevertheless, PKC is still an expensive and slow operation, and in networks that are not very complex other simpler protocols based
on symmetric cryptography can be used. In other words, there is no need to use a
full-fledged car where a motorbike can be equally useful. Nevertheless, if the network
is sufficiently complex (e.g. slow mobile nodes, very large networks, hard requirements on Resilience and Extensibility), or if there is the need of other services such
as signatures, then PKC is an ideal candidate.
Besides, it is also possible to mix the benefits of the previous frameworks with the
capabilities of the Public Key Cryptography in Hybrid Frameworks, where the PKC
would be used only for rekeying and for cases where two sensor nodes does not have a
common secret key. In addition, the improvements utilized in other symmetric keybased frameworks can be also used for enhancing any possible PKC-based protocol.
For example, if the deployment information of the sensor nodes is already known, the
6
The ECDH, ECIES, and ECDSA are supported in the v1.0 of the TinyECC library.
72
certificates of sensor nodes located in the neighborhood of a node can be preloaded,
avoiding the need to receive and verify such public keys.
However, the use of PKC alone is not enough for protecting a WSN: it is necessary to have a Public Key Infrastructure (PKI) that can be able to establish a
trusted identity, amongst other things such as defining the certificate format that
is more suitable for sensor nodes. In the following sections we will describe how to
define a PKI for sensor networks according to the PKIX model, while optimizing the
certificate format to the specific features of sensor networks.
2.3.1.1
Adapting PKI for Sensor Networks
The major components of a PKI, according to the PKIX model [143], are the following: the clients, which are the users of a PKI certificate; the Certification Authority
(CA), which establishes identities and creates digital certificates; the Registration
Authority (RA), which is responsible for the registration and initial authentication
of the clients; and the Repository, which stores the certificates and the Certification
Revocation Lists (CRLs). In order to provide the services of a PKI, such as initialization and certification, these components and their functionality must be mapped
to the entities of wireless sensor networks [255].
It is not trivial to apply a PKI to wireless sensor networks, though. It is necessary to develop an infrastructure that has the several distinctive features of sensor
networks in mind. For example, all sensor nodes have to be configured by the base
station in a secure environment before their final deployment in the network. Also,
the architecture of the network is highly decentralized, where the autonomous sensor
nodes collaborate towards a common goal, but all the critical information produced
by the network must be sent to the Base Station.
Although sensor networks are highly decentralized by nature, it is easy to notice
that there is a central system, the base station, that takes the role of initializing
the nodes of the network and interacting with the data provided by all these nodes.
Therefore, it is clear that the base station can be considered as the Certification
Authority. It is the base station, then, the entity responsible for creating the digital
certificates that associate the identity of a node with its public/private key pair.
Moreover, the base station can also take the role of Registration Authority, since
it is in charge of assigning the identity of all the nodes of the network before the
deployment of the network. As a side note, the base station can also create the
public/private key pair of a nodes, as the base station is trustworthy, and it is not
efficient for a node to create its own key.
Although the base station may also act as the Certificate Repository, this is
not practical for sensor networks. Most sensor nodes would need to route their
information through other sensor nodes in order to obtain the certificate information
from the base station, and the costs of doing so are quite prohibitive in terms of energy
and time. Therefore, it is better to adopt a decentralized solution for retrieving the
certificates. Every sensor node will have its own certificate, and will provide it to
73
any neighbor that requests it. This exchange can be done in the first steps of the
lifetime of the network.
In order to deploy a PKI, it is also obligatory to select an appropriate hierarchy
model. Fortunately, in most cases the architecture of sensor networks is extremely
simple: one base station that serves as the interface to hundreds or thousands of
sensor nodes, which only know and can communicate with the nodes belonging to
the same network. Therefore, it is safe to consider that most sensor networks will
use a simple hierarchical PKI architecture, with only one root CA.
The basic functionality of a PKI, that is, registration, initialization, key generation, certification, and certification retrieval, is done as follows: The base station
creates the public/private key pair of a sensor node, assigns an unique identification
to it, and creates the digital certificate that links that unique identification with its
public key. Later, it initializes the contents of the sensor node (such as configuration data and internal programming), including its certificate and the certificate of
the root CA (i.e. the base station itself). Later, when a sensor node retrieves the
certificate of one of its neighbors, it will be able to check its validity using the root
CA certificate.
2.3.1.2
Certificate format for Sensor Networks
In every PKI it is essential to use certificates for storing and exchanging the public keys. A certificate is a piece of information that includes the public key of an
entity, its identity, a signature by a trusted third party (the Certification Authority
explained in the previous section) that certifies the link between the identity of the
owner of the certificate and its public key, and other useful information. By using
certificates, any device can check if the public key of another device is valid or not.
As we are implementing a PKI for wireless sensor networks, we need to define
which should be the certificate format used inside the network. While it could be
possible to use the X.509v3 ITU-T [144] standard format for defining the contents of
the digital certificates, this standard defines many fields that might not be necessary
for the interactions between the members of a single sensor network. In the following
we will analyze the different fields of the X.509v3 certificate format, in order to check
whether some fields are not necessary or must exist.
• Version. Version Number of the Certificate. If the certificate is a simplified
certificate to be used only inside a sensor network, this field is not necessary.
• Serial Number. Serial number of the certificate, which must be unique for
each certificate issued by a given CA. Inside a sensor network, this field is not
necessary.
• Signature Algorithm Identifier. Signature algorithm ID for the certificate
signature algorithm. Since sensor nodes have limited capabilities, they should
74
Version
Serial Number
Signature Algorithm Identifier
Issuer Name
Validity Period (Not before/after)
Subject Name
Subject Public Key Information
Issuer unique ID / Subject unique ID
Extensions
Certificate Signature Algorithm
Certificate Signature
Figure 2.3: Simple Certificate format for sensor networks
support only one type of certificate signature algorithm (e.g. SHA-1/ECDSA).
Therefore, for a sensor network, this field is not necessary.
• Issuer Name. Identifies the entity that signed (and issued) the certificate.
Since there is only one CA in a sensor network, this field is not necessary.
• Validity Period (not before / after). Indicates when this particular certificate is not valid: before a certain date, after a certain date. For a sensor
network, this field must be changed. See section 2.3.1.3 for details.
• Subject name. Identifies a particular sensor node. This field must contain
the ID of the sensor node.
• Subject Public Key Information. This field contains the ID of the Public
Key Algorithm and the Public Key of the subject (sensor node). Since the Public Key Algorithm is unique for all the sensor nodes (cf. Signature Algorithm
ID field), this field must contain only the public key of the sensor node.
• issuerUniqueID, subjectUniqueID. These are optional fields, containing
the issuer unique ID attribute and the subject unique ID attribute. These
fields are not necessary.
• Extensions. Extensions for the X509v3 certificate. Since a sensor node certificate has no extensions, this field is not necessary.
• Certificate Signature Algorithm. Signature algorithm name for the certificate signature algorithm. As with the Signature Algorithm ID, this field is
not necessary.
75
• Certificate Signature. Contains a digital signature. By generating this
signature, the CA certifies the validity of the information contained within this
certificate. This field must exist.
We can conclude that the format of a digital certificate that stores the public keys
of the members of a certain sensor network (shown in Figure 2.3) can be simplified.
Due to its reduced size, the memory consumption and the communication overhead of
the PKC protocols will be reduced significantly. Note, however, that this simplified
certificate should be used only in the interactions between members of the same
network. If a sensor node exchanges certificates with other node located in another
context (e.g. another sensor network, or an Internet host), or if a mobile base station
wants to interact with the members of the network, this kind of simplified certificate
is not useful.
2.3.1.3
Other PKI functions in Sensor Networks
Thanks to the characteristics and peculiarities of the architecture of wireless sensor
networks, it is possible to identify which are the elements of sensor networks that
take the role of the PKI entities (CA, RA, repository). However, there are still other
PKI functions whose applicability must be discussed, such as Key Pair Recovery, Key
Update, Cross Certification, and Key Revocation. Some of these functions are not
required for a sensor network context, whereas other functions could be important
in certain scenarios [255].
The issues of key archival and key pair recovery are simple to solve. Since the
base station is considered as a fully trusted entity, all keys pairs can be stored inside
it, or in another secure server that interacts with it for redundancy purposes. On
the other hand, the issue of cross certification is a bit more complicated. For typical
sensor networks, with only one base station that behaves as the root CA, it is not
necessary to use cross-certificates. However, there are some scenarios where more
than one base station can be able to control the network. In addition, in hierarchical
configurations, a set of “cluster heads” control a cluster of sensor nodes. It is then
necessary to know if we should use cross-certificates to manage these extra base
stations and cluster heads.
The additional base stations can be static, also serving as an interface to the
functionality of the network, or mobile, directly querying the sensor nodes about
their status. Inside the network, mobile base stations can behave as any other sensor
node, except that they should have a short-lived (full) certificate signed by the main
base station, with enough privileges to influence over the behavior of the sensor
nodes. Regarding static base stations, there are usually only a few of them, thus
it can be possible to simply preload their certificates, signed by the root CA, into
all sensor nodes. Finally, it is not necessary to consider a cluster head as a CA,
since it has no need to either produce or sign any certificate of the other members of
its cluster. As a conclusion, there is no need to use cross-certificates, even in these
complex scenarios.
76
Regarding Key Revocation and Key Update, there may be some situations in
which it is important to use these services. For example, if one node is subverted
by an adversary but is discovered by the network, the base station should revoke
its certificate. Alerting the nodes about the revocation of the previous certificate is
not easy, though. It is prohibitive for the nodes to retrieve a Certificate Revocation
List from the base station (pull model), since querying the base station is a timeconsuming and energy-consuming process. A better solution would be to use a online
revocation notification mechanism (push model), where the base station alerts the
nodes of the network that a certain certificate has been revoked.
Upon receiving this authenticated message, the nodes of the network can then
request the public key of the node that had its certificate revoked. If the malicious
node is replaced with a new legitimate node, this new node will be able to provide
a valid certificate. On the other hand, the user of the network can retrieve the
malicious node and reprogram it. Updating the certificate of this now legitimate
node is an easy task, since the human administrator of the network has to physically
obtain the node for putting inside the new certificate, alongside with the private key
associated with it.
An aspect related to node revocation, and mentioned in mobile base stations, is
the existence of a validity period inside all certificates. Nevertheless, for short-lived
networks, the context of the application (“deployment”) is more important than the
expiration date. For instance, a short-lived network may measure the level of ambient
noise in a certain area for a week or more (Deployment A), but later the same sensor
nodes from that network can be reutilized in another area (Deployment B ). It should
be then more efficient to identify the deployment rather than the expiration date,
and discard any certificate that belongs to a previous deployment (e.g. a sensor node
belonging to the Deployment B does not accept any certificate that was created
during Deployment A). The root CA, then, has to assign new certificates to all the
sensor nodes before deploying them in a new area.
In long-lived networks, such as a network that monitors the overall conditions
of a vineyard for an entire year, this notion of “deployments” may not be enough,
since the sensor nodes will be continuously monitoring an environment for a long
period of time. Nevertheless, the expiration date of the certificates used in these
networks should not allow a situation where the sensor nodes are not able to use the
PKI services. What expiration date should be chosen is unknown at present due to
the lack of long-lived real-world deployments, but it is safe to assume that there is
no danger in configuring the certificates of the network to have no expiration date.
If there is no external influence, the network will function properly during all its
lifetime. And if there is any malicious influence, such as the destruction of the base
station, the owner of the network can “reboot” the whole network, reconfiguring it
and labelling it as a new “deployment”.
77
2.3.2
The case of identity-based cryptography
2.3.2.1
Identity-based and self-certified cryptography
Certificates are needed to establish a trusted link between a public key and the
identity of its owner (in our case a sensor node) in order to prevent man-in-the-middle
attacks. In a WSN, nodes are supposed to establish pairwise keys with nodes that
belong to the same network, and forbidden to do so with nodes or devices outside the
network. Therefore, in key establishment protocols like ECMQV or ECDH, the nodes
exchange their certificates in order to prove their identity and their membership. It
is natural to assume these certificates take the form of a signature by the base station
on the identity and public key of the node, as seen in section 2.3.1.2.
However, as we have discussed before, sensor nodes public and secret keys are
set up by the base station. Such a setting can be viewed as a key-escrowed system,
that is, there exists a trusted party who computes the secret keys of the users.
As a consequence one is tempted to analyze the applicability of different forms of
key-escrowed public key paradigms, like identity-based cryptography or self-certified
cryptography [250].
The concept of identity-based cryptography was proposed by Shamir in [162],
aimed at simplifying certificate management inherent to the deployment of public
key cryptography. The idea is that an arbitrary string uniquely identifying a user
(such as an e-mail address or a telephone number) can serve as a public key for
a cryptographic scheme. The user can not compute the corresponding secret key
anymore, but instead it must authenticate itself to a Key Generation Center from
which it obtains the corresponding private key via a secret channel.
The interest of IBC for WSN is that in IBC systems only the identity of the
sensors must be exchanged, and thus public keys and certificates need not be sent.
This results in an energy saving for the point of view of the communication between
sensors, which can be very considerable depending on the sensor’s transmitter. Additionally, in WSN the base station can naturally play the role of the Key Generation
Center in an IBC system. The base station embeds the secret key prior to its use in
the field, and no authentic nor secret channel is needed for key setup.
On the other hand, the self-certified cryptography paradigm [152, 160], advocates
for using an implicit certificate, as opposed to the traditional approach, where public
keys are authenticated by verifying an explicit certificate. The practical consequence
of using an implicit certificate is that the certificate and the public key are merged
into a single object, named as self-certified key. This again results in communication
savings, since now the sensors exchange identities and self-certified keys, but no
certificates. The conceptual consequence is that the link between the identity and
the self-certified key is only known to be authentic in the the course of a cryptographic
operation (i.e. only the legitimate user will be able to decrypt a ciphertext encrypted
with a self-certified encryption scheme).
78
2.3.2.2
Preliminaries and energy consumption estimations
In order to explain the applicability of identity-based cryptography and self-certified
cryptography to sensor networks, it is necessary to explain in more detail the concept
of Elliptic curves (already presented in section 2.1.1), and introduce the concept of
Pairings. In addition, we show some energy consumption estimations for elliptic
curve computations and for the transmission and reception of information. In these
estimations, we also introduce the concept of Underwater Sensor Networks.
Elliptic curves. Let GF(p) be a finite field. An elliptic curve over the field GF(p)
can be defined by an equation of the form y 2 +a1 xy +a3 y = x3 +a2 x2 +a4 x+a6 where
a1 , . . . , a6 ∈ GF(p) and satisfy certain restrictions (see [151]). A point of the curve
is specified by a pair (x, y) satisfying the above equation. It is possible to define an
addition law on the points of the elliptic curve together with a special point called
the ”point at infinity”, obtaining an abelian group G of order a certain integer n.
We use multiplicative notation for the group G and assume it is finitely generated by
an element g, i.e. every element h ∈ G can be uniquely written as h = g α for some
α ∈ Zn . An exponentiation refers to the operation g r for a randomly taken r ∈ Zn .
A multi-exponentiation mexp(l) refers to computing g1r1 · · · glrl , where g1 , . . . , gl ∈ G
and r1 , . . . , rl ∈ Zn , an operation that can be computed more efficiently than just
computing l single exponentiations due to Shamir’s trick (the Strauss algorithm
[165]).
Pairings. We start by defining the concept of bilinear map. Let G = hgi and GT
be cyclic groups of order q for prime q > 3. A map e : G × G → GT to a group GT
is called a bilinear map, if it satisfies the following two properties:
- Bilinearity: e(ga , gb ) = e(g, g)ab for all integers a, b
- Non-trivial: e(g, g) 6= 1 in GT .
and if it is efficiently computable.
Bilinear maps are usually implemented using the Weil or modified Tate pairings
on an elliptic curve. Let G = E(GF (r)) denote the group of points of an elliptic
curve E over the finite field GF (r) with order divisible by q such that q also divides
rα − 1, where α is the order of r in Z∗q and is called the MOV embedding degree. The
modified Tate pairing t(·, ·), which is the bilinear map usually recommended, takes
values in the subgroup GT of GF (rα )∗ of order q.
These curves correspond to the Type 1 category defined in [149, 153], and there
exist efficient hash functions H : {0, 1}∗ → G mapping bit strings to elements in G.
Additionally, the equality e(u, v) = e(v, u) holds for any u, v ∈ G.
Evaluation of computation energy. Our energy figures for elliptic curve computations are based on the work [164]. The elliptic curve used is E1 : y 2 = x3 − 3x + 157
79
over the field GF (p) where p = 2160 − 2112 + 264 + 1. GF (p) allows for several computational efficiency improvements, such as improved squaring in the group of points G
of the elliptic curve and efficient square roots in the finite field GF (p). The latter is
specially relevant in our context, since thanks to the technique of point compression
[100], a point h = (x, y) ∈ G can be represented only by its x-coordinate together
with a so-called compression bit. With the x-coordinate in hand, one can find y
satisfying y 2 = x3 − 3x + 157 by computing one square root in GF (p). This results
in at most two square roots, and the compression bit determines the right solution.
The amount of energy consumed by a primitive on a given processor is proportional to the time needed to execute the primitive. Using the ATmega128L [146]
microcontroller, the energy spent to compute an exponentiation on the above curve
is 30.02mJ, while computing a multiplication in GF (p) requires 12 · 10−3 mJ [164].
On the other hand, theoretical and experimental figures suggest that computing
multi-exponentiations mexp(2) and mexp(3) take about 22% and 44% more energy
respectively than that of a single exponentiation [148].
Since p = 3 mod 4, computing a square root modulo p requires 160 finite field
products and 1 division by virtue of Algorithm 3.36 in [159]. One field division can
be computed by one field inversion and one field product. Field inversion can be
done trough the Greatest Common Divisor (GCD) algorithm. By using Lehmer’s
[156] GCD computation method, the cost of 1 division equals 9 field multiplications
[147]. Hence, a square root modulo p consumes around 2 mJ.
Regarding pairings, [164] measures that computing the Tate pairing in the (supersingular) elliptic curve E2 : y 2 + y = x3 + x2 over GF (2171 ) and with MOV
embedding degree α = 4 consumes circa 258.44 mJ. Additionally, computing an exponentiation in G = E2 (GF (2171 )) can be done within 50.93 mJ. A hash evaluation
H : {0, 1}∗ → G requires roughly the same amount of processing time/energy than
an exponentiation [161].
Evaluation of communication energy (RF and Acoustic). The cost of using
the communication channel largely impacts the energy required to run any interactive protocol between sensor nodes. The most common situation in wireless sensor
networks is to use the air as a transmission medium, and most prototypes have been
deployed on such conditions. However, there are some scenarios where the sensor
nodes should be deployed in a lake or in the sea. For example, sensor networks
can be used to monitor oil platforms or underwater construction projects. These
networks have received the generic name of Underwater Sensor Networks (UWSN)
[145].
In these UWSN, it is unpractical to use radio frequency transceivers, because of
the severe attenuation factor presented by water. In order to open a communication
channel between sensors, it is necessary to use specific underwater acoustic modems.
These modems have different features than RF transceivers, and as a result, sending
one bit of information carries a high energy penalty.
The differences between radio transceivers and acoustic modems in terms of the
80
Working range
Throughput
Tx. consumption
Rx. consumption
µJ per bit (Tx)
µJ per bit (Rx)
Mica2
150 m
19.2 kbit/s
81mW
30mW
4.12 µJ
1.52 µJ
MICAz
100 m
250 kbit/s
52.2mW
59.1mW
0.204 µJ
0.23 µJ
UWM2000
1500 m
9600 bit/s
4000 mW
800 mW
416.66 µJ
83.33 µJ
UWM4000
4000 m
4800 bit/s
7000 mW
800 mW
1458.33 µJ
166.66 µJ
Table 2.6: Analysis of the energy consumption of acoustic modems.
energy consumed by transmitting and receiving one single bit of data are highlighted
in Table 2.6. It can be seen that the difference in consumption (J per bit) between
acoustic modems and RF transceivers is not negligible. For the radio transceivers,
we have considered the most popular sensor nodes platforms as of today, which
are the Mica2 and the MICAz [85]. The Mica2 transceivers use the 868/916 MHz
ISM bands, while the MICAz transceivers use the IEEE 802.15.4 standard. For the
acoustic modems, we have considered the UWM2000 and UWM4000 modems [155],
which are commonly used in research literature.
These results have been obtained using the information contained in the modem
and node datasheets, under the following assumptions: i) For the UWM2000 modem,
we have used the mean of the transmission power indicated in its datasheet (2-8W).
ii) For the transceivers used in the MICA2 and MICAz nodes, we have considered
the most expensive transmission mode, which is theoretically able to send one bit of
data to the maximum working range.
2.3.2.3
Authenticated Key Exchange (AKE)
In this section we present two algorithms that use identity-based cryptography and
self-certified cryptography to establish a pairwise key between two sensor nodes. The
description includes the overall energy cost of the algorithms and the number of bits
sent and received by a single node. For the sake of comparison, we also include
one of the most standardized key exchange protocols using “traditional” public key
cryptography.
Traditional approach: ECMQV. The elliptic curve version of the Menezes-QuVanstone authenticated key exchange protocol, ECMQV [158, 157], is described in
Algorithm 2.3.1. We provide an abridged version of the scheme which suffices for our
purposes.
KDF is a key derivation function, which can be implemented with SHA-160 for
example. Node A’s public key is pkA = g xA , where xA is A’s secret key. Similarly
for node B. In the first stage, the nodes exchange and verify certificates vouching
for the fact that pkA and pkB are public keys from nodes belonging to the network.
In a second stage, they exchange their ephemeral keys EA = g yA and EB = g yB ,
81
where yA , yB are taken at random from the finite field GF(p). We assume certificates
are minimalist and take the form of ECDSA [166] signatures (rA , sA ) and (rB , sB )
by the owner/manufacturer of the network on the messages idA ||pkA and idB ||pkB
respectively, where || denotes concatenation.
Algorithm 2.3.1 ECMQV key derivation for entity A
Require: Elliptic curve domain parameters G, g, n, the secret keys xA , yA and the
public elements pkA , pkB , EA , EB
Ensure: A secret key KAB shared with entity with public key pkB
1: m ← dlog2 (n)e/2
{m is the half bitlength of n}
m
2: uA ← (ux mod 2 ) + 2m
{ux is the x-coordinate of EA }
3: sA ← (yA + uA xA ) mod n
4: vA ← (vx mod 2m ) + 2m
{vx is the x-coordinate of EB }
5: zA ← sA vA mod n
s
z
6: KAB ← KDF (EBA · pkBA mod n)
Entity B runs the same algorithm by simply swapping the values (xA , yA , pkB , EA , EB )
in Algorithm 2.3.1 with (xB , yB , pkA , EA , EB ) and finally obtains the same key KAB
(cf. [157]).
The energy cost is dominated on the communication side by the exchange of
public keys, certificates and ephemeral keys. Public keys have 161 bits (160 bits +
1 compression bit), each ECDSA certificate has 320 bits, while each ephemeral key
contributes with 161 bits. Additionally, each message exchanged includes a payload
consisting on communicating nodes identities, protocol ID, message ID, checksum,
and low-level headers and footers, amounting to a total of 384 bits. In total, 2820
bits are exchanged, which means every such a bit is sent and received by each node.
On the computation side, each party has to verify an ECDSA signature, whose
individual computational cost is dominated by one multi-exponentiation mexp(2),
and has to run the ECMQV protocol, whose computational cost is dominated by
one exponentiation plus one multi-exponentiation mexp(2). Additionally, two square
roots are computed by each node to obtain the y-coordinate from the x-coordinate of
pkA , pkB , EA , EB . The overall energy cost of ECMQV for a single node thus amounts
to
2mexp(2) + 1exp + 2sqrt(+trans 1410 bits + recv 1410 bits)
(2.1)
Authenticated key exchange using identity-based keys. Due to the lack of
any standardized identity-based key exchange protocol, we describe a non-interactive
scheme due to Sakai, Ohgishi and Kasahara, the SOK protocol [163, 150]. We provide
an abridged version of the scheme which suffices for efficiency considerations. In order
to run the key agreement protocol, the nodes only need to exchange their identities.
The SOK protocol does not need any further communication between the parties for
building a shared authenticated key. However this key remains unchanged for the
82
life-time of the system (and thus this protocol does not provide forward secrecy),
which can be unacceptable in some applications. SOK was the first identity-based
authenticated key agreement protocol proposed in the literature.
In the SOK protocol, a hash function H : {0, 1}∗ → G is included in the domain
parameters of the system, together with gz , where the master secret key z is only
known to the base station. Node A’s secret key is skA = H(idA )z , while node B’s
secret key is defined as skB = H(idB )z .
Algorithm 2.3.2 SOK non-interactive ID-based key derivation for entity A
Require: Bilinear map domain parameters G, G1 , e, gz , n, the identity idB and the
secret key skA
Ensure: A secret¡key KAB shared¢ with entity with identity idB
1: KAB ← KDF e(skA , H(idB ))
¡
¢
Entity B on inputs idA , idB , skB computes the same key KAB ← KDF e(skB , H(idA ))
thanks to the bilinearity of the pairing,
e(skA , H(idB )) = e(H(idA )z , H(idB )) = e(H(idA ), H(idB )z ) =
= e(H(idB )z , H(idA )) = e(skB , H(idA ))
The energy cost on the communication side consists on exchanging messages
containing communicating nodes identities, protocol ID, message ID, checksum, and
low-level headers and footers, amounting to a total of 2 · 384 = 768 bits. This is
a huge communication saving with respect to the 2820 bits required by ECMQV.
On the computation side, each party has to perform one hash operation, which is
roughly equivalent to 1 exponentiation in G, plus 1 pairing computation. Thus, the
energy cost of SOK key agreement for a single node amounts to around
1expG + 1pairing(+trans 384 bits + recv 384 bits)
(2.2)
Self-certified ECMQV. In this variant of ECMQV, implicit public key certificates are used. A similar implicit certificate approach is included in Mandatory ECC
Security Algorithm Suite submitted to the IEEE P802.15 Working Group for Wireless Personal Area Networks [154]. We provide an abridged version of the scheme
which suffices for efficiency considerations.
The base station has a public key g0 = g z , where z ∈ Zn is secret, and h :
{0, 1}∗ → Zn is a public hash function. The self-certified public keys of the sensors are wA = g rA and wB = g rB , with rA , rB only known to the owner, while the
corresponding secret keys known to the nodes are xA = z · h(idA , wB ) + rA and
xB = z · h(idB , wB ) + rB with xA , xB ∈ Zn . The ECMQV-like public keys pkA , pkB
can be obtained by combining the public information together with self-certified keys,
83
h(id ,w )
h(id ,w )
i.e. pkA = g xA = g0 A A · wA and pkB = g xB = g0 B B · wB . This allows to build
a self-certified version of ECMQV.
In this version, sensors only exchange their self-certified public keys and the
ephemeral keys EA and EB , where yA , yB are taken at random from the corresponding finite field. It is important to note that they do not exchange nor verify any
certificates.
Algorithm 2.3.3 Self-certified ECMQV key derivation for entity A
Require: Elliptic curve domain parameters G, g, n, g0 , h, the secret keys xA , yA and
the public elements wA , wB , EA , EB
Ensure: A secret key KAB shared with entity with self-certified public key wB
1: m ← dlog2 (n)e/2
{m is the half bitlength of n}
2: uA ← (ux mod 2m ) + 2m
{ux is the x-coordinate of EA }
3: sA ← (yA + uA xA ) mod n
4: vA ← (vx mod 2m ) + 2m
{vx is the x-coordinate of EB }
5: zA ← sA vA mod
n
¢
¡ s
h(id ,w )
6: KAB ← KDF EBA · (g0 B B · wB )zA mod n
Entity B runs the same algorithm by simply swapping the values (xA , yA , wB , EA , EB )
in Algorithm 2.3.3 with (xB , yB , wA , EA , EB ) and finally obtains the same key KAB .
The energy cost is dominated on the communication side by the exchange of selfcertified public keys and ephemeral keys. Self-certified and ephemeral keys contribute
each with 161 bits, and can be exchanged in the same message7 . Therefore the
communication overhead of self-certified ECQMV amounts to 384 · 2 + 161 · 4 = 1412
bits, a 50% saving with respect to traditional ECMQV. On the computation side,
running the self-certified ECMQV protocol has a computational cost dominated by
one exponentiation plus one multi-exponentiation mexp(3), plus two square roots
in GF (p) for point decompression. The energy cost of ECMQV for a single node
amounts to
1mexp(3) + 1exp + 2sqrt(+trans 706 bits + recv 706 bits)
2.3.2.4
(2.3)
Total energy cost and applicability discussions
Using the previously shown equations, together with the energy figures from section 2.3.2.2, it is possible to calculate the energy consumption of a sensor node
engaged in the key exchange protocols in “normal” and underwater sensor networks,
in terms of mJ. The results are shown in Table 2.7. It turns out that, for the MICA
family of motes, self-certified ECMQV is the most efficient protocol. This is not surprising, since self-certified ECMQV requires 50% less information to be exchanged
7
The reason is that the validity of the self-certified keys is not checked until the key exchange
has been performed.
84
than ECMQV, while keeping a similar computational cost profile. The energy savings
of self-certified ECMQV with respect to ECMQV vary from 30% to 50% depending
on the platform considered.
MICA2
ECMQV
SOK
SC-ECMQV
UWM2000
ECMQV
SOK
SC-ECMQV
Comp.
107.26
309.39
77.25
Comp.
107.26
309.39
77.25
Comm.
7.95
2.16
3.98
Comm.
704.98
191.99
352.99
115.21
311.55
81.23
812.24
501.38
430.24
MICAz
ECMQV
SOK
SC-ECMQV
UWM4000
ECMQV
SOK
SC-ECMQV
Comp.
107.26
309.39
77.25
Comp.
107.26
309.39
77.25
Comm.
0.61
0.166
0.306
Comm.
2291.23
623.99
1147.24
107.87
309.55
77.56
2398.49
933.38
1224.49
Table 2.7: Energy cost of authenticated key exchange (in mJ)
The unexpected energy performance is to be found with the underwater sensor
nodes, for which identity-based AKE (the SOK protocol) has better performance
that standard AKE (ECMQV) for the UWM2000 and UWM4000 nodes, and it even
surpasses self-certified ECMQV in the case of UWM4000 nodes. Such a (energy-wise)
efficiency result for identity-based cryptography primitives is unknown in traditional
wired systems. The reason is quite simple: identity-based key exchange protocols
exchange less data than the other protocols, and the more energy is required to send
a bit of data, the more optimal identity-based key exchange becomes.
In fact, due to the special features of the underwater environment, the transmission channel is very slow and prone to errors, so application developers not only
consider the possible energy savings, but also the number of bits exchanged during
the key establishment process become of paramount importance. Precisely, identitybased AKE only exchanges 384 bits, while self-certified AKE exchanges 706 bits and
standard AKE exchanges 1410 bits. As a result, if energy is not an issue (e.g. due
to the use of a more powerful battery in the underwater node), it will be better to
use identity-based cryptography. On the other hand, if energy is considered to be a
problem, the features of the acoustic modem will influence over the choice between
identity-based AKE and self-certified AKE.
CHAPTER
3
SELF-AWARENESS SERVICES
This chapter deals with the importance of self-awareness services as
essential tools for achieving self-configurability in the context of sensor networks. We explain why the sensor protocols can benefit from
the existence of these mechanisms. Next, we develop several situation
awareness mechanisms, which can detect abnormal events that might
affect the behaviour of the network, and we also describe how these
awareness mechanisms are influenced by the nature of the sensor network application. Afterwards, we develop a blueprint of a distributed
IDS architecture that fulfills all the following properties: full network
coverage, simplicity, and adaptability. We describe its components, its
detection mechanisms, and some support protocols that may improve its
functionality. Finally, we study the applicability of trust management
systems in sensor networks, discovering how the intrinsic nature of the
sensor networks paradigm influences over these systems, and subsequently we define how the components of a trust management system
should behave in sensor networks.
85
86
3.1
3.1.1
Protocol diversity
Heterogeneity of core protocols
The core protocols can be considered as the minimal set of protocols that sensor
networks needs in order to function properly. These protocols are: routing (transmitting a packet from one sensor node to another sensor node), data aggregation
(briefing many sensor readings into one single piece of data), and time synchronization (synchronizing the clocks of the network). The properties and the behaviour of
these protocols is highly dependent on the characteristics of the sensor network application where they are running, because they must be adapted to the requirements
of the scenario. As a result, there are many core protocols from where an application
designer can choose the most optimal for his/her scenario.
3.1.1.1
Routing
In most sensor networks, it is not possible for a sensor node to open a direct communication channel with the base station or with any other sensor node in the network.
It is then necessary to make use of a routing service to send the information from
the sender to the receiver. However, due to the specific features of sensor networks,
the constrained nature of sensor nodes, and the requirements of every specific application (e.g. some applications may require the latency of the data to be as small as
possible), there exist different routing protocols that provide service for particular
scenarios.
Some of the challenges that need to be taken into account while designing these
routing protocols are the following [167]: Node deployment (existence of deterministic paths), energy consumption (balancing energy conservation and accuracy),
node/sensor heterogeneity (different sets of sensors and node capabilities), fault tolerance (environment adaptability), scalability (work with a huge number of nodes), mobility (existence of mobile devices), transmission media (MAC1 -design, error rates),
connectivity (variable topology), coverage (assure area coverage), aggregation (data
fusion), and quality of service (assure a certain latency).
The need to solve these specific challenges have spawned multiple routing protocols, which can be classified according to their underlying network structure, their
internal functionality and operations, and their relationship with other core protocols
such as data fusion [168][167].
Underlying network structure.
• Flat Routing. This category refers to routing protocols for multi-hop flat configurations. In flat networks, each node typically plays the same role and nodes
1
This MAC refers to Medium Access Control, not to Message Authentication Code
87
collaborate to perform the sensing task. In this case, the network usually implements simple routing tree protocols, where the information is sent from the
nodes to the base station.
• Data-centric Routing. Whenever the base station wants to query the network
for specific flows of information, it can use data-centric routing. These protocols
view the network as a huge distributed database system, where the sensor
nodes provide data according to the necessities of the base station. This type
of routing can be also known as Query-Based Routing.
• Hierarchical Routing. Some routing approaches focus on providing services to
hierarchical configurations, where the network is divided into clusters. Such
configurations can be either static, with powerful cluster heads, or dynamic,
where cluster heads are elected dynamically. For dynamic configurations, most
routing algorithm also specifies how to construct the clusters.
• Location-Based Routing Protocols. In this kind of routing, sensor nodes are
addressed by means of their locations. It can be possible to use relative coordinates, obtained by exchanging the distance between neighboring nodes, or
absolute coordinates, retrieved through small low-power GPS receivers.
Protocol operation.
• Multipath Routing Protocols. Some protocols use multiple paths rather than a
single path in order to enhance network performance. Alternate paths are usually kept alive by sending periodic messages. Therefore, network reliability can
be increased at the expense of increased overhead in maintaining the alternate
paths.
• Negotiation-Based Routing Protocols. The main idea of these protocols in
WSNs is to suppress duplicate information and prevent redundant data from
being sent to the next sensor or the BS. This purpose is achieved by conducting
a series of short negotiation messages before the real data transmission begins.
• QoS-based Routing. In QoS-based routing protocols, the network has to satisfy
certain QoS metrics (delay, energy, bandwidth, etc.) when delivering data to
the BS. These quality requirements can be provided by constructing the routing
path according to QoS factors or by maintaining certain QoS information of a
neighbourhood, amongst others.
• Coherent and Noncoherent Processing. This type of routing protocols are
closely related to the aggregation processes. In noncoherent routing, sensor
nodes will locally process the raw data before it is sent to the aggregators. In
coherent routing, the data is forwarded to aggregators after minimum processing (e.g. timestamping, duplicate suppression).
88
3.1.1.2
Aggregation
Due to the redundancy of the network, nodes staying in the same area (e.g. a
kitchen) will collect the same sensory data under normal circumstances. Sending all
this sensory data to the base station is a waste of energy, mainly due to the energy
consumption associated with the communication channel. Therefore, it is necessary
to reduce the existence of redundant data. This proccess is commonly known as
aggregation. A more formal definition of in-network aggregation is presented in [169]:
‘In-network aggregation is the global process of gathering and routing information
through a multihop network, processing data at intermediate nodes with the objective
of reducing resource consumption (in particular energy), thereby increasing network
lifetime’.
The aggregation process is closely related to the routing service. In fact, aggregation capabilities are usually embedded inside routing protocols. For example, the
routing paths may be constructed according to the physical layout of the environment, in order to adequately capture the sensory data of certain regions of interest.
A classification of the routing protocols according to their data fusion capabilities is
as follows [170]:
• Routing-driven algorithms. Routing schemes in this class focus on the route
design without explicit consideration of the fusion process as an additional
requirement. The goal of such algorithms is to minimize the total communication cost for gathering the data to the sink, and aggregation only occurs
opportunistically when routes intersect.
• Coding-driven algorithms. This class of algorithms focuses on coding techniques
at the source nodes for data reduction. Through compression, it is expected
that the data amount can be minimized, and further in-network fusion can be
either completely avoided or significantly reduced.
• Fusion-driven algorithms. In fusion-driven routing algorithms, routing paths
are heavily dependent on data correlation in order to fully benefit from information reduction resulting from data aggregation. In contrast to coding-driven
algorithms, fusion-driven algorithms often assume that data can be fused more
than once along its path, as long as it is deemed beneficial.
There are other aspects that have to be taken into account while developing
aggregation protocols. The network configuration (flat or hierarchical), the strategies
used to identify the nodes (existence of data-centric protocols), and others, greatly
influence over the internal behaviour of an aggregation protocol. Also, some protocols
seek a balance between lifetime maximization and quality of service, while other
protocols try to improve one factor in order to provide a better service for a certain
application context (e.g. maximize the amount of information collected at the sinks,
or focus on congestion control and end-to-end reliability) [171].
89
Finally, the means to represent the data and the nature of the in-network aggregation functions have to be considered as well. Some solutions adopt very simple
aggregation functions such as average, median, quantile, min, max, etc. On the
other hand, other applications will require of aggregation functions that do not affect significantly the precision of the transmitted information. As a result, these
applications need a more detailed representation of the data, which calls for more
complex functions and data structures (taking into account the spatial, temporal and
semantic correlation of the readings) [169].
3.1.1.3
Time synchronization
The primary function of sensor networks is to measure data. Alongside with data, in
most cases (e.g. for enabling the data fusion procedures) it is necessary to provide a
timestamp that indicates when the data was collected from the physical environment.
However, as with any distributed system, the clock values of all sensor nodes will
gradually diverge from each other due to various factors related to the physical
components of the computer clock. Therefore, it is necessary for all nodes to maintain
a common notion of time by means of time synchronization protocols.
Time synchronization protocols can be classified basically on two major categories: according to the strategies used to synchronize the clocks, and according to
the influence of the application on the synchronization process [172][173].
Synchronization issues.
• Master-slave vs. peer-to-peer. In the master-slave solution, The slave nodes
consider the local clock reading of the master as the reference time and attempt
to synchronize with it. On the other hand, other solutions are based on a peerto-peer structure, where all the nodes agree on the “actual” time.
• Clock correction vs untethered clocks. Some methods perform synchronization
by correcting the local clock in each node to run on par with a global time
scale. Other methods try to achieve a common notion of time without synchronization.
• Internal vs. external synchronization. Internal synchronization seeks to minimize the differences between the local clocks of the nodes, while external synchronization provide a standard source of time such as Universal Time (UTC).
• Probabilistic vs. deterministic synchronization. Deterministic algorithms guarantee that the clock offset will not exceed a certain bound. On the other hand,
probabilistic algorithms only provide a probabilistic guarantee on the maximum
clock offset, but have smaller energy requirements.
• Sender-to-receiver vs. receiver-to-receiver synchronization. Some methods synchronize a sender with a receiver by transmitting the current clock values as
90
timestamps. In contrast, other approaches exploits the properties of the physical broadcast medium.
Application-dependent features.
• Single-hop vs. multi-hop. In a single-hop network, a sensor node can directly
communicate and exchange synchronization information with any other sensor
in the network. On the other hand, sensors in a multi-hop network need to
synchronize their clocks more effectively.
• Stationary v. mobile networks. Mobility induces more difficulties in achieving synchronization. Therefore, it is necessary to design robust and effective
protocols with mobility in mind.
• MAC-layer approaches vs. standard approaches. It is possible to use the
Medium Access Control (MAC) layer of a sensor node to effectively carry out
the time synchronization process in order to achieve better energy efficiency.
The nature of the Medium Access Control layer is sometimes dependent of the
application, due to factors such as QoS and power awareness.
3.1.2
Protocols and self-awareness
All the aspects of a particular wireless sensor networks deployment are heavily influenced by both the scenario and the requirements of the application. The core
protocols that have to be implemented inside sensor nodes are no exception. The
exact nature of these protocols and its algorithms depends heavily on factors such
as expected quality of service, network configuration, supported number of devices,
lifetime, robustness, device capabilities, and many others.
One of the factors that should be considered by every protocol is security. Due
to the vulnerable nature of sensor networks, the core protocols should be able to
withstand attacks from malicious adversaries, either external or internal. However,
it is very difficult to define security mechanisms that could be seamlessly adapted to
every type of protocol. They must be prepared to analyze their internal processes
in order to detect failure or misbehaviour, and to react to these events in order to
maintain the functionality of the network.
For example, routing protocols must be able to maintain the consistency of their
routing tables (e.g. routing trees), to create clusters in a secure fashion, to avoid
packets to be sent to the wrong destination (route diversion), to securely negotiate
parameters, and many others [174][175]. Aggregation protocols need to assure the
integrity and authenticity of the sensory data before and after the aggregation takes
place [176][177]. Moreover, time synchronization protocols have to be robust against
false clock information or attacks that try to delay or influence over the negotiation
process [178][179].
91
However, all protocols, regardless of their design and functionality, need to be
aware of their environment. A sensor node that does not know its own situation and
the situation of its environment cannot react to possible events that may influence
its functionality. Therefore, it is essential to have certain self-awareness services
that provide this information (e.g. whether a certain node has disappeared from a
neighbourhood) to the protocols of the sensor node. In fact, this information is also
vital for the user of the network, because he/she should be able to know at all times
the state of the network.
Besides, self-awareness can facilitate the creation of security services such as intrusion detection systems and trust management systems. By using intrusion detection
systems, it is possible to know if a certain node is suspicious of misbehaviour or
malicious. This knowledge can be used by any of the core protocols to ignore any
interactions with these malicious entities. As for trust management systems, they
can indicate if a certain node can be trusted for a particular task (e.g. route a packet
to the base station), improving the overall intelligence of the core protocols.
3.2
3.2.1
Self-Configurability and situation awareness
Situation awareness in Wireless Sensor Networks
One of the specific features of sensor nodes is their inherent autonomy. By means
of their computational capabilities, nodes can analyze the data coming from their
embedded sensing units. Additionally, they operate without any preexisting infrastructure because they can communicate with their surroundings using wireless
transceivers. Furthermore, they can survive in their deployment site, even for years
in certain configurations, because they are powered by small batteries. Due to this
autonomy, sensor nodes are considered self-configurable entities that can be set up
without any major effort by non-experts. They just need to be programmed, deployed, and switched on. This self-configuration is not limited to the deployment
of the network: sensor nodes should configure themselves to run for long periods of
time (from months to years) with almost no human intervention.
However, in order to be fully autonomous and self-capable, it is essential for the
sensor nodes to be aware of their environment. That is, to recognize certain events
that might affect the behaviour of the network. For example, the nodes that are
affected when one of the routers of the network fails to work must be able to automatically notice it and react accordingly, as shown in Figure 3.1. The task of
detecting such events relies upon the existence of situation awareness mechanisms.
Without these mechanisms, a sensor node can not fully understand the current situation of its environment, and will not be able to configure itself in order to respond
to internal/external events.
Not only the nodes are interested on this kind of internal information, but the user
of the network as well. Once the network starts failing, the user will not detect the
92
Room Humidity
A
25% RH
…
…
Room A
ERROR
25% RH
100% RH
20% RH
30% RH
Figure 3.1: Importance of self-awareness mechanisms for sensor networks
reason of this failure: it will only know that the network or a part of it is not providing
its functionality. Logical events will remain undetected if there is no mechanism that
can inform the user about their occurrence. And since the user can be far away
from the deployment zone, any physical events that affect a set of sensor nodes can
also pass undetected. As a result, it should also be necessary to give the user access
to the output of the situation awareness mechanisms. Such audit information can
be requested (“on-demand”), or reported automatically when a special or abnormal
situation is detected.
Designing these kind of mechanisms specifically for a wireless sensor networks
is not an easy task, though. Due to the distributed nature of the network, most
sensor nodes are equally important for offering the services of the network (e.g.
monitoring the environment). Also, any occurring event will be detected mostly
by the neighbourhood in which the event takes place. Therefore, it is necessary to
adopt a decentralized solution, where total coverage is assured by making all nodes
and base stations participant in the analysis of the state of the network. This leads
to the second problem: the limiting resources of a typical sensor node. A sensor node
is very constrained in terms of battery life and processing power, so any detection
mechanism crafted for sensor nodes should consist only on simple tasks.
There are some existing techniques that allow to control simple factors such as
the actual situation of the sensor nodes. For example, it is possible to send periodical
“heartbeat” messages to other nodes in order to check whether they are alive [181].
This simple technique has been improved in [182] by sending that information to
the base station while trying to minimize the use of resources. Regarding attack
detection mechanisms, most approaches analyze the packet ratio of the network, and
their contents when possible [184]. For discovering specific attacks in the protocols
of the network it is also possible to use other techniques such as automata theory
93
- Back Pain
- Fever
- No Packets
- Destination
does not relay
Figure 3.2: Simile: A sensor network as a living being
[185].
3.2.2
Development of lightweight awareness mechanisms
As aforementioned, one of the key factors for the development of lightweight detection
mechanisms is the acquaintance of the problematic events that can occur and how
to properly detect them. For this purpose, we have used the simile of “a sensor
network as a living body” (already introduced in section 1.1.1.2), where a sensor
node is considered the “cell” of the system, and the base station is the “brain”, as
seen in Figure 3.2. Having in mind this simile, it is possible to think that the presence
of certain symptoms (i.e. collateral effects) will be indicative of the existence of a
disease (i.e. abnormal event) [248].
One of the difficulties associated with the diagnosis of a disease consists on separating the existing symptoms from the normal behavior of the body. However, the
functionality of sensor networks is usually fixed, with sensor nodes providing the
same services during all the lifetime of the network. Therefore, any deviation of
the behavioral pattern of the network, or the existence of a well-established set of
unusual patterns, can be considered as a potential effect of an abnormal event. Another issue that can affect the diagnosis is to distinguish one disease from another
one according to the existing symptoms. Nevertheless, in a sensor network context,
the mere possibility of detecting and warning about the existence of a problem can
be useful enough for the user of the network. Even more, it will be shown later that
most abnormal events do not share the same effects.
It is also important to point out that the symptoms associated to a specific illness
depend not only on the illness itself, but also on the patient characteristics. For
example, the symptoms of a myocardial infarction (heart attack) vary according to
the gender of the patient [180]. Therefore, it can be deduced that, in a sensor network
context, the detection of abnormal events from its associated collateral effects is
influenced by the nature of the application. In fact, according to the properties
94
of the application, there will exist some scenarios where the analyses must adapt
themselves to the behaviour of the network (e.g. the time frame where a node is not
sending packets). Also, there will be some other scenarios where the existence of an
abnormal event (e.g. the disappearance of a node) cannot be inferred directly.
3.2.2.1
Types of abnormal events
In order to discover what are the possible symptoms that sensor networks may suffer,
it is first necessary to know what the existing diseases are; that is, what the awareness
mechanisms want to detect. All abnormal situations are triggered by one or more
of the following principal causes: failure of a sensor node, an external attack, or an
internal attack. However, the diseases caused by attacks are far more numerous than
the ones caused by node failure. As shown in section 1.2.1, there are many kind of
attacks that can affect a sensor node, from the hardware layer to the application layer.
On the other hand, there are only two major events that the mechanisms should
detect in case of node failure: a node that becomes unavailable from the network,
and a sensor that malfunctions and provides inconsistent information. Therefore,
in the remainder of this section we focus on abnormal events caused by external or
internal attacks. Although attacks were already enumerated in section 1.2.1, this
section will explain them in more detail.
Outsider Attacks
Change Environment
Physical
Change Sensors
Hardware
Node Tampering
Injection
Comm. Channel
Replaying
Jamming
Insider Attacks
Protocol-specific attacks
Impersonation attacks
Message Creation
Packet Alteration
Feature Advertising
Time-Related Attacks
Table 3.1: Outsider and insider attacks in WSN
Outsider Attacks The purpose of a malicious outsider that has no prior knowledge of the network is to gain access over one or more of its elements in order to
influence on the network behaviour as a result. The only element that can be manipulated in a WSN is the sensor node. As mentioned in the introductory section,
a typical sensor node has mainly three tasks: obtain the physical information of
its surroundings with its built-in sensors, exchange control and data messages with
the nodes located in its neighbourhood, and process both the sensed data and the
information that comes from the radio. Therefore, any outsider can use three entry points: the physical environment of the sensor, the sensor node itself, and the
wireless communication channel.
95
It is conceivable to change the physical environment of the network with the
purpose of interfering with its normal operation. This operation is, in most cases,
extremely easy, since the sensor node must be physically close to the source of the
events in order to monitor them. For example, a sensor node that monitors the temperature and humidity of oil tanks must be located nearby the tanks. Consequently,
any outsider simply has to access the node and manipulate the environment (e.g.
pouring some water on it) in order to introduce bogus data into the network.
In a more extreme case, an outsider may try to change the hardware sensors of
the node with his/her own set of sensors. The difficulty of this attack may range
from easy (just plug a circuit board with modified sensors) to medium (separate the
existent sensors and solder new ones). Nevertheless, the scope of these manipulations,
environmental-based or hardware-based, is rather small due to the high density of
sensor networks and the embedded memory and intelligence of the node.
An attacker would be more interested in accessing the internal information contained inside the sensor node, obtaining any credentials like, for instance, secret
cryptographic keys. This kind of attack would allow the outsider to either modify or
clone the node, gaining the possibility of influencing the network with insider attacks.
Furthermore, modern sensor nodes are not tamper resistant because of cost issues.
However, as demonstrated by Becher, Benenson, and Dornseif [49], it is not trivial to physically attack a sensor node. By disabling the JTAG debugging interface
and implementing an adequate protection to other interfaces, a network designer
effectively forces any outsider to employ a significant amount of time to obtain the
information contained in the sensor node. Moreover, if the attacker actually possesses the necessary information to access the contents of the node (such as the BSL
password in a MSP430-based node), he/she should need more than 20 seconds to
read or write all the contents of the memory of the node.
Finally, the attacker could try to manipulate the communication channel. It is
easy to hear or to inject packets inside the network because of its wireless nature.
All the attacker needs is a device whose radio is compatible with the radio of the
wireless network (e.g. 802.15.4-enabled device) and find out which channel is being
used by the network (e.g. by employing a spectrum analyzer). Fortunately, if the
data contained in the network packets is protected by pairwise keys (cf. section 2.2)
the attacker can only try to deplete the energy of the target or create a denial-ofservice (DoS) attack.
Regarding packet injection, an attacker can inject inside the network a bogus
packet with a fake source. Such packet will be immediately discarded by its destination since the MAC (Message Authentication Code) field does not contain a valid
value. An attacker could also try to resend a previously captured packet, even if
he/she is not aware of its meaning. This kind of attack could be easily thwarted including a timestamp or a sequence number field inside the protected packet, although
it requires the sensor nodes to be time synchronized. In addition, an attacker can
try to jam the signal of the network, preventing nodes from sending and receiving
96
any kind of packet. This is a DoS attack, which is easily detectable but very difficult
to avoid.
Insider Attacks Once a malicious outsider has gained access to one or more of the
sensor nodes, it becomes an insider. At this point, the malicious insider has at his/her
disposition all the information stored in the node, like the security credentials, and
can gain access to the content of the communication flow that traverses the sensor.
That is, it can create and alter any packet being sent to this particular node. Note
that it is probable that the insider cannot snoop the information sent to other nodes
in its neighbourhood, since the subverted node may not have the necessary keys to do
that (cf. section 2.2.2.2). Still, this insider can effectively launch complex attacks to
the core protocols of the network that can damage the functionality of the network.
One of the most important protocols in WSN is routing because, due to the limited radio transmission range and energy constraints, it is not possible for a sensor
node to communicate with another node without the help of other ones in the network. Routing protocols are prone to be attacked in multiple ways, as shown by
Karlof and Wagner ([174]). The rogue node can spoof, alter, delay, or replay control
packets that contain routing information. It can also forward a certain subset of
the packets that receives (Selective Forwarding), dropping important packets such
as alerts. In addition, the node can try to advertise itself as a ”good” link towards
the base station (Sinkhole attack ), attracting the traffic from the neighbourhood. In
another sophisticate, although more difficult attack, the node can try to present multiple identities to other nodes in the network using stolen credentials (impersonation
attacks).
Data aggregation is another significant protocol for WSN that can be easily attacked by a malicious insider (cf. Sang et. al. ([176]). Data aggregation is performed
by an aggregator node, and its role is to collect the data from a certain area and
summarize it into one report, hence decreasing the number of packets that are sent
to the base station. There are three major points of attack against the aggregation
process: the source nodes, the aggregator node, and the report. A trusted aggregator
can receive false data from faulty nodes or from malicious nodes. If the aggregator
node itself is malicious it can easily ignore the data received from its neighbours and
create a false report. Regarding the report, it can also be modified while it is being
routed to the base station.
Finally, many applications such as tracking and localization require the local
clocks of the sensor nodes to be synchronized in order to guarantee the consistency
and freshness of the results. Therefore, time synchronization becomes another essential protocol for assuring the correct performance of a WSN and, at the same
time, another interesting point of attack for a malicious insider. As can be deduced
from Manzo et. al. ([178]), almost all attacks against this kind of protocols can be
classified into two types. The simplest attack consists on broadcasting a falsified
synchronization message, aiming to increase the clock skew (i.e. the difference in the
frequencies of the clock and the perfect clock). The second and more complex attack
97
can be done if the protocol uses a hierarchy to transmit the control messages. In
this case, the malicious insider can advertise itself as a node with a high level in the
hierarchy in order to influence over as many nodes as possible.
Summarizing, a malicious insider can perform a wide range of attacks against
the core protocols of sensor networks in order to affect its functionality. The scope
and effects of these attacks, alongside with the specific steps required to launch it,
depend on the specific implementation used by a network, though. Still, it is possible to obtain from the previously mentioned attacks five attack templates that any
generic IDS could partially detect: (i) impersonation attacks (when a node presents
fake/multiple credentials) (ii) message creation (related to malicious sensor nodes
creating fake packets regardless the state of the other nodes in the network), (iii)
packet alteration (when the contents of a relayed packet are changed in unacceptable
ways), (iv) feature advertising (when a sensor node broadcasts false control information), and (v) time-related attacks (related to whether packets are going to be
delayed or are not going to achieve their destination at all).
As a side note, it would be interesting to know if it is possible for a malicious
insider to take control over another sensor node via the communication channel. In
wired networks, this is the most common perception of “intrusion”, where a malicious
user access a system using so-called “exploits”. One possible way of doing so is
by using buffer overflow attacks [189], where a maliciously formed packet stores
data beyond the boundaries of a fixed buffer, overwriting memory locations of the
device. Another approach can be exploiting the mechanisms provided by the WSN
for updating the code, being machine code or interpreted code, inside the nodes.
Examples of these mechanisms are Deluge by Hui and Culler [56] and Mate by Lewis
and Culler [61], respectively.
Fortunately, the maximum size of the network packets on a WSN is usually fixed,
so it is possible to allocate a buffer large enough to manage any type of incoming packet and avoid a buffer-overflow attack. Still, the possible effects of a buffer
overflow in vulnerable sensor implementations are still unknown, although there are
some extensions, like the one developed by Regehr et. al. [190], that could help to
mitigate the problem. As for code update procedures, most existent protocols have
been secured using authentication mechanisms, like Deluge by Krontiris et. al. [59].
In conclusion, in a WSN environment it is not probable that a malicious insider can
spread itself to other nodes in the network.
3.2.2.2
Situation awareness mechanisms
Once the diseases are known, it is possible to examine them in order to diagnose
what are their related symptoms. That is, the analysis of the collateral effects of an
abnormal event will lead to the inference of the mechanisms that should be used in
order to detect them [248]. A summary of the different abnormal events alongside
with their effects can be found in Table 3.2. Note that, in most cases, the detection
mechanisms that infer the existence of abnormal events are not complex, and such
98
events can be detected just by storing and analyzing simple statistics generated by
the network. As a result, these mechanisms can be lightweight enough for constrained
environments.
Abnormal event (disease)
Collateral effect (symptom)
Jamming
Wide data unavailability
Hw. failure (“unavailable” node)
Data unavailability
Node subversion
Node temporarily unavailable
Tampered, Malfunctioning sensor
Deviations, Inconsistences
Packet Replaying
Packet too old
Impersonation Attacks
New neighbours, Packets per node
Message creation
Changes in packet density, Inconsistent alerts
Packet alteration
Changes in packet (only for broadcasted)
Feature advertising
Inconsistent feature with neighborhood
Long delays, Traffic imbalance
Time-Related attacks
Table 3.2: Relationship between WSN attacks and their symptoms
A jamming attack is very difficult to circumvent, although it produces a clear
symptom: an abnormal decrease in the number of packets coming from the affected
zone. Such symptom can be detected by both the base station and the nodes on the
routing path. Even more, nodes belonging or near the affected zone will detect an
unusual increment on the number of collisions. Note that a single node who is not
available due to hardware failure will also be detected by the base station and other
nodes because of disappearing packets. However, in the case of Hw. failure, there
will be no abnormal collisions going on in the neighborhood of the “dead” node.
A node will be temporarily unavailable from the network if an attacker is trying
to subvert it. In this case, the number and ratio of messages from that node will
drop to zero for a non-trivial period of time. Therefore, a node that returns to the
network after such period of time has passed should be considered suspicious by its
neighbors and the base station.
A set of false measurements (either coming from a tampered sensor or a malfunctioning one) can be detected by the node itself, the neighborhood, and the base
station. Certain values, such as the humidity of a room, do not fluctuate abruptly
unless there is an extreme situation (e.g. a flood) going on, and that fluctuation
should continue over time. The neighborhood of a sensor node should also be able to
sense the same physical readings if they are physically near. At last, the base station
may have a history of all the readings and could detect a significant deviation of the
expected values based on the context and on the history of the network.
A malformed packet, that is, a packet with an invalid Message Authentication
Code, can only be sent by a malicious attacker who created a packet without the
required credentials. Therefore, the existence of such packets is an evidence of an
attack. While it is not possible to detect the identity of the attacker from the
99
(possibly forged) fields, it is possible to estimate its position using the signal strength.
The attacker may also try to launch a DoS attack using these packets, although the
sensor nodes can opt to treat them all as one single alert.
An external attacker can also replay a previously captured packet, but these kinds
of attacks are easily detectable if the network packets have the necessary protection,
such as timestamps. In the simplest case, a node can choose to mark as suspicious
any packet whose timestamp is either too delayed or too advanced in terms of its
local clock.
Regarding attacks against the core protocols of the network, the symptoms created by an attack vary from protocol to protocol, because all protocols and algoritms
used in a WSN must be adapted to the particular context of the application (cf. section 3.1). Thus, there must be adapted detection mechanisms for every protocol
configuration (e.g. location anomaly detection [198] and disruptive routers detection [196]). However, it is still possible to describe what are the symptoms for the
non-specific attacks presented in the previous section.
About Impersonation Attacks, their symptoms can be detected by both sensor
nodes and base stations. For sybil attacks, where an adversary uses many identities,
nodes will immediately detect those identities as new neighbours, and the base station
can quickly check if those nodes were deployed by the network administrator. For
node replication attacks, where an adversary use the same identity in different regions
of the network, either the nodes or the base station can be able to detect that there
are more messages coming from an unique node identity.
Regarding message creation attacks, sensor nodes usually create and send packets
to the base station only inside specific times frames (known as “burst periods”2 ).
Also, under normal circumstances packets should not be sent outside that “burst
period”. If the sensor nodes or the base station detect a change on the packet
density of the network (i.e. more packets being sent within a “burst period”), there
is a chance that a message creation attack is taking place. Note that the change on
the packet density of the network can be caused by alerts and/or queries, thus this
factor needs to be taken into account.
Other mechanisms that can help in detecting fake alerts. An alert usually corresponds with a certain physical event, and nodes near to the source node will be able
to detect that event. Therefore, if a node routes an alert and is close enough to the
source node, it can check by its own or with other nodes whether such alert is real.
Even more, in most cases, a reply is sent after a query is broadcasted to a section of
the network by the base station. If a node sends a fake reply, the nodes routing that
information to the base station and belonging to the same section of the source node
should have received the query before. If no query was received or will be received
in a small period of time, the answer will be clearly a fake.
An attacker can also create a message on behalf of other nodes. This is usually
2
A normal period will be defined as the time frame between recurrent burst periods, including
the last of these ones.
100
the case of a malicious aggregator node sending a fake report to the base station.
Since most packets coming from aggregation points are the result of monitoring a
certain event, the nodes that depend on the aggregator have to send their messages
before any aggregation process takes place. As a result, if the aggregator node sends
a packet before receiving any information from nodes below it, it can be seen as
suspicious.
Packet alteration attacks are, unfortunately, very difficult to detect. Its more
obvious symptom is when a malicious node changes the information contained inside
a packet that has been forwarded. However, in sensor networks with basic security
services, the contents of a packet can only be read by its origin and its destination.
Therefore, no one of the neighbors is able to read the contents of a relayed packet.
There is a case in which this attack can be detected, though: broadcasted packets.
Therefore, a modified broadcasted packet can be easily detected by any node that
belongs to the group where the packet is being sent.
Another attack related to packet broadcasting is feature advertising. In certain
protocols, sensor nodes advertise themselves as having a certain property that makes
them more useful for the WSN as a whole (e.g. its distance to the base station in
number of hops). If a malicious node fakes one of these properties, it is clear that
such advertising will be suspicious if it is too deviated from the values generated in
the neighbourhood (e.g. a node advertising it is near the base station while being on
the edge of the network).
Finally, a malicious adversary can execute some time-related attacks by delaying,
selective forwarding, or dropping packets. Regarding delayed packets, this attack
shows symptoms while performed either isolated or continuously. It is atypical for
a packet to be relayed later than the normal amount of time it may spend inside
a normal sensor node under average stressful conditions. This deviation can be
detected by nodes in the neighborhood by comparing the ratio of messages entering
and exiting a certain node, or by the base station by comparing the time a packet
needs to be routed from its source.
When packets are selective forwarded (i.e. dropped) by a malicious node, it is
obvious that these packets will not be received either by the next hop or by the base
station. Nodes surrounding a malicious forwarder cannot verify if a specific packet
has been forwarded, due to the protection of the communication channel. However,
they may be able to check if there is an imbalance between the number of packets
going to that node and the number of packets coming from that node. Finally, any
node that drops packets relayed to it (a black hole) will not send practically any
message, and such piece of evidence can easily be detected almost immediately by
any neighbor.
3.2.2.3
Application influence on situation awareness
All the collateral effects that have been shown in the previous section always happen
whenever an abnormal event occurs. For example, whenever a sensor node stops
101
functioning, its neighbours will detect that it neither sends messages nor processes
packets. However, the way in which collateral effects are analyzed by the situation
awareness mechanisms, and the conclusions drawn by the execution of those mechanisms, is highly dependant on the application requirements and characteristics. For
example, in sensor networks with mobile nodes, the inexistence of packets cannot be
considered as the only symptom for Hw. failure, although this symptom may help
the old neighbourhood of the mobile node to realize that it moved.
The application and its context actually influence over the network architecture
(e.g. network size, node mobility) of a sensor network. For example, as seen in
section 2.2.4.2, an application that monitors industrial machinery will probably use
one-hop networks, while applications that monitor assisted-living residents on their
homes will consist on a small networks containing a mixture of mobile nodes (worn by
the user) and static nodes (monitoring the environment). The application will also influence over the network behaviour (e.g. length of the “burst period”). For instance,
sensor networks that need to provide their services with no real-time QoS requirements for a long period of time will probably have a short “burst period” followed
by a long “normal period”. Both the network architecture and the characteristics of
the network will then have influence on the situation awareness mechanisms.
Concerning network size, if a sensor network is a one-hop network, where the
packets arrive directly to the base station without any need of routing, certain abnormal events will not happen (e.g. routing attacks) or will not be detected by
the sensor nodes (e.g. jamming attacks). In such small networks, the analysis of
these specific abnormal events can be done through the base station. On the other
hand, if the size of the network is bigger than one-hop, all nodes can implement the
awareness mechanisms used in the network. The influence of the network size on the
mechanisms is not very significant, since only certain aspects such as the amount of
messages relayed by nodes needs to be taken into account.
For the situation awareness mechanisms, mobility is more significant than network
size. There are two types of mobility that need to be analyzed: base station mobility
and node mobility. When the base station is mobile (e.g. vehicle tracking scenarios),
the number of packets managed by a node will be influenced by its relative distance
(in number of hops) to the base station: nodes that are nearer the base station will
relay more packets. This fact have an effect on those situation awareness mechanisms
that depend on the analysis of the network load, such as the creation of messages
and the delayed packets.
If the nodes of the network are mobile, some collateral effects will only provide
partial information about an event. Even more, other collateral effects will not be
useful for detecting abnormal events. As already mentioned, an unavailable node
due to hardware failure will produce the same symptoms as a node that moves to
another area. A node that re-enters a certain neighbourhood may also produce the
same symptoms as a compromised node. As to time-related attacks, a node can
detect a false positive in the routing process whenever a node in charge of relaying
102
packets abandons the neighbourhood. Other aspects that need to be taken into
account are, for example, the extra number of packets that some nodes will have to
relay due to the traffic produced by the mobile nodes. Finally, nodes in networks with
mobile nodes cannot detect some impersonation attacks with the actual awareness
mechanisms, because it is very difficult to distinguish sybil nodes from mobile nodes.
Besides network architecture, the specific nature of the application also has an
effect on the network behaviour: number of messages sent, existence and length of a
“burst period”, expected values of the sensors, etc. This behavior influences how the
abnormal events are derived from the collateral effects. For example, for detecting
the message creation attack, it is essential to know both the packet density of the
network and the length of the “burst period”.
Also, the application will dictate which are the services that are implemented
inside the node, such as the capability of the network to generate alerts or the support
for a query subsystem that can obtain information from the network “on-demand”.
Both the type of events that the network can be aware of and the behaviour of some
awareness mechanisms will depend on the existence of these services. For example,
if a node is not capable of generating alerts, the implementation of the message
creation control mechanisms will be simpler, and there will be no need to check for
fake alerts.
3.3
Intrusion Detection Systems
3.3.1
An overview of Intrusion Detection Systems (IDS)
3.3.1.1
Purpose of an IDS
An intrusion can be defined as a set of actions (i.e. attacks), either external or
internal to a certain system, that can lead to an unauthorized access or alteration of
such system. The mission of an Intrusion Detection System, or IDS, is to monitor
computer networks and systems in order to detect possible intrusions in the network,
alert users after intrusions had been detected and, finally, reconfigure the network
provided that is possible [67].
Intrusion Detection Systems must gather and analyze audit data to check whether
there is an intrusion in progress or not. Data can be obtained from various sources. In
host-based IDS, data come from operating systems and application logs. In networkbased IDS, data come from the network packets. Additionally, some IDS use both
application/system logs and network packets information.
After the data gathering process, Intrusion Detection Systems analyze all the
information available, searching for possible attacks and intrusions. Data analysis
can be classified into two techniques: anomaly detection and misuse detection [191].
First ones store patterns of what can be considered as “normal” behaviour, and react
against any significant deviation of those patterns. Second ones compare the collected
103
information with predefined “signatures” of well-known attacks. None of them can
be considered better than the other; hence, both of them are usually employed in
IDS.
3.3.1.2
IDS and wireless networks
Intrusion detection systems are valuable tools for detection of possible attacks that
could be launched against a network, as well as for prevention of service interruption
or loss of data that could happen as a consequence of such intrusion. In wired netR
works, IDS research is a mature field, spanning multiple applications such as Snort°
[192] that are actively maintained and applied to networks everywhere. However, due
to the nature of the vulnerabilities and specific features of wireless networks, it is a
very difficult task to use that previous experience in order to create an IDS architecture for typical ad hoc networks and wireless sensor networks.
In a wireless network, any computer or device within the radio transmission range
of a node is capable of interchanging information with such node. This differs from
wired networks, where in most cases there is only a single point of entrance to the
network. Additionally, while in wired networks just a subset of the nodes are able
to provide a certain service (like a web service), in most wireless networks all nodes
are equally important for offering services. Moreover, wireless nodes are usually
constrained in terms of battery and computational power, hence the nodes are more
vulnerable against specific attacks, such as sleep deprivation attacks [193].
As a result, it is not possible to directly apply the hierarchical IDS architectures
used in wired networks. In fact, in hierarchical architectures, physically secured hosts
monitor the points of access of the network and centralized servers analyze the audit
trails and react against any possible intrusion. However, in wireless networks an
intruder could try to subvert any node belonging to the network without leaving any
global trail. Due to these reasons, wireless networks need to adopt a decentralized
solution.
In a decentralized solution a certain set of nodes should be able to collect and analyze the audit data produced in the whole network by using software systems called
IDS agents. Audit data may come from the packets circulating through the communication network and from the operating system and applications logs. During
the course of those analyses, both anomaly detection techniques and misuse detection techniques should be employed by the agents for detecting unknown or known
attacks. In certain cases, agents may start a collaborative process to provide assistance to other nodes in order to either improve the detection procedure or exclude a
malicious node.
There exists an abundant literature on the application of IDS for ad hoc networks and MANET networks [194]. Because ad hoc networks maintain a wireless
communication channel without relying on any fixed infrastructure, it is reasonable
that most IDS architectures in these scenarios use a decentralized approach, using in
some cases advanced techniques like mobile agents. It would be interesting if all these
104
IDS architectures could be applied to other wireless networks, such as wireless sensor networks. Nonetheless, this is not possible because ad hoc networks and wireless
sensor networks are essentially different in terms of infrastructure and functionality,
as seen in section 1.1.1.3. As a result, an IDS for wireless sensor networks must be
simple and highly specialized in order to react to the specific protocols used over the
network and against specific sensor networks threats.
3.3.1.3
IDS and Sensor Networks: related work
The importance of guaranteeing the security of the deployment of a WSN makes
research on security a priority. So far, most of the research for WSN has focused
on the security primitives and distribution of secret credentials (cf. chapter 2),
with some advances on the provisioning of secure protocols such as aggregation and
routing. Other fields like Intrusion Detection Systems have not been widely developed
until recently. The reason behind this underdevelopment could be that the concept
of “intrusion” is not clear in a wireless sensor network context.
In any case, there are some studies that show how some types of attacks could be
detected in the context of an intrusion detection system. A subset of this research
assumes the existence of a full-fledged intrusion detection system. For instance, the
work by Zhang, Yu and Ning [201] filters and detects the malicious nodes of the
network based on alerts. Also, in the work by Basile et. al. [188], the data provided
by the network is used as an input and, by using hidden markov models, the system
can discover and distinguish errors from attacks coming from the network.
A standard and full-fledged intrusion detection system for sensor networks has
not been defined yet, but some authors have explored how to develop such a system.
One part of the problem is the location of the IDS agents watching over the network.
Some works are concentrated on hierarchical network configurations, like Su et. al.
[187], where detection agents are located on the cluster heads monitoring the traffic
of the entire network. Some authors like Anjum et. al. [195] take the approach of
clustering the network dynamically as a measure for placing the detection agents.
Other authors, like Roman et. al. [258] and Khalil et. al. [199], put the agents
inside every node, although agents are subdivided into different entities with different
schedules and tasks such as monitoring the local or the surrounding events.
Other lines of research have been oriented to find the exact detection mechanisms
that should be used for detecting the attacks. As suggested by Doumit and Agrawal
[197], it is possible to use Hidden Markov Models inside powerful nodes as an anomaly
detection technique. Other works use automata theory for analyzing the behaviour
of the protocols and detect deviations, like DESERT by Inverardi et. al. [185].
Another simple approach, followed by da Silva et. al. [200] and Onat and Miri [184],
is to analyze the packet ratio of the network in conjunction with other statistics and
deduce the existence of attacks.
Another interesting aspect of intrusion detection systems is their relationship
with other systems and services. IDS are closely related to trust systems, and a
105
node marked as suspicious may lose some reputation in the trust process. This
type of relationship is analyzed by Ganeriwal and Srivastava [54]. Regarding node
monitoring, there are some works that focus on detecting the health of a member
of the network, like that one by Hsin and Liu [181]. Sending this kind of health
information to the base station is another aspect that has been optimized by Rost
and Balakrishnan [182]. Finally, the results obtained by the IDS can improve the
robustness of other protocols, such as the routing protocols [183].
3.3.2
Applying IDS to Wireless Sensor Networks
An intrusion detection system is a valuable security service for wireless sensor networks. It can inform the users of the network about the existence of internal and
external attacks, and it can provide other services inside the node, such as trust,
with information regarding the nodes that are suspicious or malicious. As a result,
this system allows the network to self-configure itself to react against any attacks,
improving its robustness.
There have been aspects related to IDS that have been discussed in previous
works, such as the situation of the detection agents, the nature of some detection
mechanisms, and so on. However, there have been no proposals of an IDS scheme
that fulfills all the following properties: full network coverage (cover all the information flow of the network), simplicity (use mainly simple components, statistics
and mechanisms), and adaptability (possibility to include new or existing detection
mechanisms, or to exclude those detection mechanisms that are not needed).
It is then our purpose to present a blueprint of an intrusion detection system that
fulfills all these properties. Situation awareness mechanisms, which were presented
in section 3.2, serve as the cornerstone for the development of this blueprint. By
using the mechanisms, we can comply with the simplicity property. The design
of the blueprint allow its adaptability, while the full network coverage is achieved
by distributing the detection tasks inside every node and inside every base station
[248, 258].
3.3.2.1
Architecture
As stated in section 3.3.1.2, any IDS for wireless sensor networks must be decentralized, mainly because any part of the network can be a possible point of intrusion: all
nodes can be manipulated or subverted, the communication channel is equally vulnerable in all the sections of the network, and any change in the internal behaviour
of the network can lead to a potential problem.
This ubiquitous nature of the attacks, which can happen anytime and anywhere,
leads to the positioning of the software detection elements, that is, the agents able
to detect and react against any possible intrusion. As in the case of the situation
awareness (cf. section 3.2), attacks can be detected by any member of the network:
the base station can become aware of a subtle variation on the messages and the
106
- Base Station
Agent
Sensors
- Node Local Agent
- Node Global Agent
Situation Awareness
Packets
Protocol-specific Analyses
Others
DATA ACQUISITION
- #packets (total , per period)
- Last Sequence no. / timestamp
- Others
DETECTION
- Measurements
- Collisions (Backoffs)
- Query / Alert information
STATISTICS
COLLABORATION
Malicious
Suspicious
ALERT DB
Figure 3.3: Blueprint of an IDS Architecture for WSN
data coming from the network, a node can analyze the data coming from its sensors
and from packets addressed to it, and that node can also detect any variations that
happen in its neighbourhood.
Consequently, the IDS agents must be located in every element of the network
- all nodes and all base stations. However, the constraints inherent to the nodes
belonging to the network, such as sparse resources and limited battery life, impose
a cautious planning about how agents must be deployed in the network and what
set of tasks they have to perform. This leads to the division of the node agents into
two parts: the node local agent and the node global agent. Since base stations are
supposed to have much more resources, the base station agents do not need this kind
of separation. These agents are discussed below in more detail.
• Node Local agents monitor the local activities of a sensor node. That is, they
check the information processed by the node, either sensor readings or packets
being forwarded by the node. They are located in every sensor node, and are
activated anytime the node has to process some information.
• Node Global agents watch over the communications of their neighbours, processing the information that can be extracted. They are also located in every
sensor node, and run their tests periodically, not continuously. Besides, it is
possible to adjust their activation levels due to the redundancy of the network.
Note that, for clustered networks with one-hop clusters, it can be possible to
include the Node Global Agent only in the cluster heads.
• Base Station agents analyze the information flow obtained from the sensor
nodes. Since the base station is rich in resources, it can be active at all times,
running complex algorithms for discovering any variations that can lead to
locating an intrusion.
The internal components of all agents is identical, and is shown in Figure 3.3. In
our architecture, the Data Acquisition component obtains data from the sources of
107
symptoms (e.g. packets and sensor information), and stores the processed information in the Statistics component. These two components are used by the Detection
component, which infers the existence of abnormal events. The Detection component
can proceed to its analyses periodically or when signalled by the Data Acquisition
component. All results are shared in the Alert Database component, where nodes are
labelled as suspicious or malicious. Finally, the architecture includes a Collaboration
component that can be activated when the node needs to share an event with other
of its subsystems, its neighbors, or the base station.
The data sources of the Data Acquisition component depend on the type of the
agent. For node local agents, the data sources are the sensed data and packets
being processed or sent by the node. For node global agents, the data sources are
packets circulating on the neighbourhood that are not directed to the node. Other
information such as the number of backoffs and the number of malformed packets
received is also important. On the other hand, the Base Station agents will use as
input all the information coming from the sensor nodes (e.g., messages, timing, etc.).
The information coming from the Data Acquisition component will feed the
Statistics component, which holds some statistics about the network. The basic
contents of this component for a sensor node, which are shared by both node global
and local agents, are described below.
• Number of Backoffs. Number of sequential backoffs occurred while transmitting
a packet. This field is reset for every packet sent.
• Backoff range. Arithmetic mean of the number of backoffs in this neighbourhood, alongside with an upper bound.
• Number of malformed packets. Number of malformed packets (i.e. packets with
an invalid Message Authentication Code) sent in the neighbourhood during a
certain period of time.
• Timestamp / Sequence number per sender. Information regarding the clock
differences between nodes or the expected sequence numbers, including upper
and lower bounds, per sender in the neighbourhood.
• Query queue. Contains queries forwarded by the node to its childs.
• Number of total packets per sender. Number of total packets received and sent
by a particular node of the neighbourhood.
• Number of packets per sender. Number of packets sent and received by a certain
node during the actual normal period and burst period.
• Packet range per sender. Arithmetic mean of the number of packets sent by
a certain node during its normal periods and its burst periods, alongside with
an upper and lower bound.
108
The Detection component will be in charge of obtaining the results from the
Data Acquisition component and the Statistics component, analyzing them for signs
of possible intrusion symptoms. This component can use both the situation awareness mechanisms introduced in section 3.2.2.2 and other detection mechanisms that
are part of existing or future research. In order to save energy, all tests that are
related to the Statistics component should not run continuously, but periodically on
a programmable schedule.
In case the Detection component considers that a node is behaving in an abnormal
way, it must store this information in the Alert Database component. The alert
database stores a counter for every node in the neighbourhood that is incremented
for every anomaly. A node may be labelled as “suspicious” or “malicious” after
certain thresholds are surpassed. These thresholds have to be tuned up depending
on both the importance of the network and the presence of false positives in the
detection process. There are certain symptoms that are a bigger indicator of an
intrusion, such as behaving as a black hole, and can lead directly to mark a node
with a certain label.
Finally, the Collaboration component allows sensor nodes to send queries to their
respective neighbourhoods in order to discuss their internal information. For instance, a node that receives a possible fake alert from another node can ask its
neighbourhood to check if the alert conditions also apply to them. This collaboration component must be able to securely communicate and interchange information
with its neighbours using schemes such as majority voting schemes [202].
Having this kind of architecture inside a sensor node does not pose a significant
overhead: a prototype implementation of the IDS component in TinyOS 2.0, including many situation awareness mechanisms, fits in less than 4Kb of ROM and 500b of
RAM. As a final note, a concern may arise on the subject of the node global agent
having to receive the packets from its neighborhood. However, the wireless nature
of the communication channel forces them to do so, in order to check if they are
the destination of the packet. While doing this checking, a node can update the
Statistics component (e.g. number of packets sent by a node).
3.3.2.2
Agents tasks
Every agent is in charge of detecting whether certain attacks are taking place using
their Detection components. This section will detail how these components work for
every type of agent.
Note that, in the development of the detection mechanisms presented in this
section, we have only considered a network model where all or most of the nodes are
static. Still, with or without support for mobile nodes, the detection tasks will be
located inside the same agents.
Node Local Agents. The primary source of information for the node local agents
is the information processed by the node where the agent is located. As a result,
109
this type of agent is able to analyze the contents of packets, the features of its
environment, and other local aspects in search of possible attacks.
Since the node local agent can inspect the contents of the packets that traverse it,
it can be specialized on analyzing and detecting abnormal situations (e.g., repetition
of control messages) in the specific protocols used in the network. The specification
of these detection mechanisms depends on how these protocols work. Besides, it is
possible to include here detection mechanisms developed by other researchers, like
Doumit and Agrawal [197], or Inverardi et. al. [185]. Nevertheless, it is still possible
to describe the detection procedures used to detect more generic attacks.
Regarding the jamming attack, the node can check whether the number of backoffs
occurred while sending a single packet is higher than a certain threshold contained in
the backoff range structure. If this is the case, the node can then try to contact their
neighbours in a collaborative process. If the channel does not allow such collaborative
process, then it is undoubtly jammed. Besides, the node can also measure the actual
noise in the communication channel, and use this information to effectively detect
the jamming [186].
On the subject of sensor tampering, the fluctuations and variations of sensory
data can be analyzed by the sensor node. The node can compare its actual reading
values or other node reading values with the normal physical values at a certain time
and date (e.g. temperature at midnight on winter), the overall sensory data of its
neighbourhood, and others. If all these readings are too deviated from the normal
values for a certain context and time, a node can suspect of the well-being of the
sensory data.
The malformed packets, that is, packets with an invalid Message Authentication
Code, are a clear symptom that there is a malicious outsider in the neighbourhood.
Still, no node can be accused as malicious, since the headers of the packets are
probably forged. In the case of repeated packets, it is also not possible to blame any
node: maybe a malicious outsider is replying a packet that listened some time ago.
In this case, the node local agent can simply analyze either the sequence number of
the packet or its timestamp.
Concerning created query answers, if one node sends an authenticated reply to the
base station answering to a certain query, nodes staying in the same area where that
query was sent can compare if that answer is related to one of the queries contained
in the “query queue”. A negative match (the results of the query are unrelated to
the query itself, or the node is answering to a nonexistent query) will lead to start
suspecting from that node.
A malicious node can also create bogus alerts in order to supply false information
to the base station about a certain physical event. However, if a node is nearer
enough of the source node, it can start a collaborative process in order to ask its
neighbours if the sensory data contained in the alert is not contradictory. A negative
answer will lead to mark the original source node as a suspicious node.
110
The node local agent can also detect the appearance of a new node with a previously unknown identification. Since only a trusted human user has the potential of
adding a new node to the neighbourhood, the node local agent can signal this type
of event to the Base Station, in order to advise the user of the existence of his/her
newly deployed node or to alert him that a possible impersonation attack is under
way. Note that the node global agent, whose operations are detailed below, can also
perform this task.
Node Global Agents. These agents are in charge of snooping the packets sent
in their neighbourhood, analyzing their headers, timing information, and others. An
important constraint of the node global agent is that it can only check the contents
of broadcasted packets (e.g. checking for feature advertising attacks), because every
packet with an unique destination node is supposed to be encrypted with a pairwise
key shared only by the sender and the receiver. Still, it is possible to detect the
symptoms of certain attacks just by using packet statistics.
For example, a node global agent can compare the total number of packets sent in
its neighbourhood with the average number of packets that should have been sent. In
case the number of packets is extremely low, it can be easily deduced that a jamming
attack has taken place. On the other hand, if the number of packets is higher than
the upper bound of the packet range (having into account the possible existence,
indicated by the node local agent, of alert messages and answers to queries) it is
mostly certain that there is some sort of message creation attack under way. This
kind of attack can also be detected if an aggregator node sends a packet without
having received anything from its children.
Node Destruction attacks and Blackhole attacks can be detected by checking the
number of packets sent by a particular node. If after a burst period of time the node
has not sent any packets, the agent should start a collaborative process asking the
node to give any indication of its existence. A negative answer will mark it as dead,
while a positive answer should mark it as suspicious of a blackhole attack. Besides,
a node that has disappeared but comes back after a significant period of time [49]
should raise an alarm as a possible compromised node.
On the other hand, detecting timing-related attacks, such as selective forwarding
and packet delaying, is very tricky. By default, it is not possible for a node to relate
a packet entering into a node to another packet exiting the same node. Nevertheless,
the use of certain support protocols described in section 3.3.2.3 may help. For example, if the sensor nodes implement the support protocol “Piggybacking Forwarded
Messages”, node global agents just need to check the contents of the forwarded queue,
and any packets that are not forwarded or are delayed too much are symptoms of
these timing-related attacks.
Still, there are some mechanisms that can be applied just using information related to the “Number of packets” and “packet range” lists. In regard to packet
delaying, it can be possible to check the exiting ratio of a node, i.e. how many time
passes between a node receives a packet and a node sends a packet. A high exiting
111
ratio can be an indicative of a malicious node, although it becomes a clear symptom
if the channel is not very busy and the probabilities of losing a packet due to noise
are low.
Selective forwarding can also be detected comparing the number of messages
directed to the suspicious node with the number of forwarded messages by that
suspicious node. Observe that a node global agent may have not snooped all packets
directed to the suspicious node (e.g. if the original sender is out of its range), but it
is clear that the suspicious node should forward at least the number of packets that
the node global agent overheard. Notice, however, that this process must be tweaked
when the suspicious node is an aggregator node - such node would forward only one
message per set of children.
Finally, on a side note, it is important to observe that the node global agent
may choose not to monitor the contents of certain broadcasted packets or certain
“tickets” in the Piggybacking Forwarded Messages protocol if there is another node
global agent that can do the work, thus saving energy on the process. For this
purpose, it is possible to use the ”Spontaneous Watchdog” support protocol, that
allows a node global agent to discover if a single packet is going to be monitored by
more than one agent.
Base Station Agents. The Base Station is the primary receiver of the messages
generated by the sensor nodes. Those messages are mainly used as a source of information of the events of the network, but it is also possible to employ such messages
for detecting a deviation on the normal behaviour of the network. This agent can
incorporate the mechanisms of other existent base station-centered protocols as another piece of the infrastructure, like the solutions developed by Zhang, Yu and Ning
[201] and Basile et. al. [188]. Aside from the data and the alerts, the base station
agent can also analyze other aspects related to the incoming packets.
If a sensor network is under a jamming attack, the base station will not receive
any messages coming from the affected zone. This can be easily detected when the
application requires a sensor network to periodically send information towards the
base station. Also, if within a “burst period” the base station receives too few or too
much messages, it can be possible to suspect the existence of selective forwarding
attacks and message creation attacks, respectively. Packet delaying attacks can also
be detected if the time spent by a packet of a certain node to cross the network is
greater than the average traversing time of packets coming from the same node.
3.3.2.3
Support protocols
We have developed some support protocols that can be included inside the IDS. One
of the support protocols, Piggybacking Forwarded Messages, relies on modifying the
format of the packets used in the network, for the sake of identifying the original
sender of a forwarded message. Another support protocol, Obfuscated Watchdog,
relies on expanding a well-known node monitoring technique to protect the nodes
112
To
B
DAT1
Node A
Node B
A
DAT1
To
C
Node C
A
DAT1
Figure 3.4: Example of Piggybacking Forwarded Messages, with A as the “ticket”
against subversion. Finally, the Spontaneous Watchdogs technique[262] allows node
global agents to choose whether to analyze the contents of a packet or not depending
on the redundancy of the network.
Piggybacking Forwarded Messages. Piggybacking acknowledgments is one wellknown technique in data transmission on wired protocols, such as Ethernet. In this
technique, when a node A sends a message α to a node B, the acknowledgement for
the data α can be included in a message directed from node B to node A, reducing
the number of ACKs in the network and saving bandwidth. An interesting variation,
mostly oriented to wireless environments, would be not to acknowledge the reception
of a packet, but the forwarding of a packet.
In a wireless environment, the sender of a packet will receive the same packet
forwarded by its original destination, if the signal strength is good enough between
them. That is, if node A sends a packet including α to node B, A will also hear the
forwarded packet by B that contains α. If the packet were not encrypted, the sender
could check if the original destination has forwarded the packet. Unfortunately, this
is usually not possible, because in a secure network all packets are encrypted with a
pairwise key. Following the previous example, A can receive all packets sent by B,
but it can not read their payload unless A is the destination of the packet.
However, it may be possible to add a field into the header or the data of the
packet that would go unprotected (in terms of encryption, not in terms of message
integrity) and could be used for acknowledging any forwarded packets. For example,
node B could add a field to all packets coming from A and forwarded to other nodes
that would indicate that their previous hop were A. With this field, from now on
called “ticket”, it is possible for a sender to check if its neighbours are behaving
properly. This process is shown in Figure 3.4.
If the ticket is just the identification of the sender of the packet, it is not possible to
detect packet delaying attacks since there is no way to discover if the data contained
in one packet corresponds to a certain forwarded packet. On the other hand, it is
possible to detect selective forwarding attacks by expecting the subtraction (packets
sent to node - packets piggybacked from node) not to be similar to zero if the forwarded
node is malicious. Nevertheless, the source node has to take into account both the
radio irregularities of its communication channel with the forwarding node and the
113
#####?
ALIVE?
ALIVE
Node A
ALIVE
Node B
Normal
Watchdog
Node A’
Obfuscated
Watchdog
Figure 3.5: Normal Watchdog, and Obfuscated Watchdog
status of the environment in terms of failed messages while making this subtraction.
It may also be possible to create the ticket using both the sender ID and a
certain feature of the original packet (e.g. its sequence number, or its Message
Authentication Code). As a result, the sender can check if the forwarding node is
executing a packet delaying attack by matching the feature of a forwarded packet
with the associated content of one of its previously sent packets. A sequence number
is smaller in size (e.g. 2 bytes), but the malicious forwarding node can try to guess
it. On the other hand, a MAC cannot be calculated in advance by that node, but
its size is bigger (e.g. 4 bytes).
If the forwarding node is malicious, the existence of such ticket forces the node to
send a packet that contains a valid ticket. The malicious node can interchange the
ticket of a packet with one of the tickets of previously received packets, effectively
cheating the delay detection process. But in any case, the packet containing the valid
data must be sent once the routing queue is empty, so the delay time is bounded by
the network load. Of course, the malicious node can alter the message, but avoiding
alteration attacks is not the purpose of this support protocol.
Obfuscated Watchdog. Hsin and Liu ([181]) introduced a distributed monitoring
mechanism for wireless sensor networks based on a two-phase timeout system: if a
node of the network does not produce any packets in a certain period of time, the
neighbours will consult the death of that node with its neighbourhood. It is also
possible to consult the node itself about its health, in case it is suspected to be dead.
In this way, nodes can act as active watchdogs of the other nodes.
Since it has been demonstrated that a node cannot be subverted in a trivial
period of time, it can be easily deduced that a subverted node will disappear from
the neighbourhood for a period of time before sending again any packets, thus any
reappearing node can be suspected to be a malicious node if the neighbourhood does
not show symptoms of a more broader attack, e.g. a jamming attack.
It is possible to increase the time an attacker needs to analyze and replicate the
source code of a node by adding a challenge-response process to the consulting procedure. That is, if a node A requests another node B a proof of its liveliness, the node
B must solve a small challenge included in A’s request, as seen in Figure 3.5. The
way that a node calculates the answer to a challenge is unique for every challenger,
i.e. node in the neighbourhood. As a result, the attacker is forced to analyze the
114
Node C
Node A
Node B
Node D
Figure 3.6: Network scenario with Spontaneous Watchdogs
code included in a subverted node before making a valid replication.
A simple way to include this challenge calculation into the nodes is to create the
challenge as a simple operation dependent of the pairwise keys shared by both nodes
(e.g. a simple XOR of the challenge with the pairwise key). Since it is possible
to learn the nature of the challenge just by subverting one single node, a possible
improvement is to tie the calculation of the answer with a set of parameters negotiated
in the first moments of the network. The use of self-modifying code techniques could
also be of interest.
Spontaneous Watchdogs The spontaneous watchdog technique, whose main goal
is to activate only one node global agent per packet circulating in the network (e.g.
only one node global agent analyzing a broadcasted packet), relies on the broadcast
nature of sensor communications, and takes advantage of their inherent redundancy.
As seen in Figure 3.6, for every packet circulating in the network, there are a set
of nodes that are able to receive both that packet and the relayed packet by the
next-hop. Hence, all these nodes have a chance to activate their node global agents
in order to monitor those packets. The process is as follows:
• The node will check if both the origin of the packet and the destination of the
packet are in its neighborhood.
• If true, the node can be a spontaneous watchdog. Consequently, it will deduce
how many nodes in the network are in its same situation.
• If the number of nodes that fulfill the requirements are n, a single node will
select itself as a node global agent for this packet with a probability of n1 . This
process can resemble as n people with 1 dice of m sides each, where n = m,
trying to obtain a 1 in the dice to activate the node global agent.
This technique requires all the nodes to store a list of the neighbors of the immediate neighbors of the node. This list is not scalable for high density networks:
115
it grows as a quadratic function ((n2 ) + n) of the number of one-hop neighbors n.
However, the size of the list can be reduced using Bloom filters [203], storing the
neighbors’ list of every neighbor as a bit array. For a Bloom filter configuration of
k = 1 (hash functions) and m
= 2 (number of bits m doubles the number of neighn
bors n), the size of the list is reduced 75%, at the cost of introducing a probability
between 16% and 40% of false positives.
By storing a list of neighbors for every node in its neighborhood, sensor nodes
are capable of calculating how many nodes can activate their node global agents
by intersecting the set of neighbors of the packet’s origin with the set of neighbors
of the packet’s destination. If there is only one node who fulfills the requirements,
it will activate its node global agent. Otherwise, if there are more than one node,
all of them will have the same probability to take the role. All decisions are made
independently from other nodes, hence the traffic of the network will not increase.
In Figure 3.6, for example, Node A wants to send a packet to Node B while
Nodes C and D are in the neighborhood. Both C and D will intersect the set of
neighbors of A ({B, C, D}) and B ({A, C, D}), and the result will be {C, D}, i.e.,
two neighbors. Therefore, both nodes have a chance of 21 to activate their node global
agents.
50
45
25 neighbors
45
25 neighbors
40
10 neighbors
40
10 neighbors
Scenario probability (%)
Scenario probability (%)
50
5 neighbors
35
3 neighbors
30
25
20
15
3 neighbors
30
25
20
15
10
10
5
5
0
5 neighbors
35
0
0
1
2
3
4
5
6
7
8
9
10
Number of spontaneous watchdogs (Nodes)
0
1
2
3
4
5
6
7
8
9
10
Number of spontaneous watchdogs (Nodes)
Figure 3.7: Number of Spontaneous Watchdogs, Normal & Double Probability
The spontaneous watchdog technique, however, does not assure that one and only
one node will activate its node global agent for every packet in the network. The
explanation of this problem lies in the independence of the nodes’ behavior. Since a
node does not communicate its decision to others, more than two nodes (or even no
node) may activate the node global agents. Therefore, there is a possibility where a
packet can go unsupervised.
The probability that α nodes have to activate their node global agents at the
same time is given by the following equation:
P Rnn−α,α · (m − 1)n−α
(3.1)
V Rm,n
where P Rnn−α,α is the formula of permutation with repeated elements, V Rm,n is
the formula of r-permutations with repetition, n is the number of nodes that could
f (α, n, m) =
116
activate their node global agents (i.e., the number of nodes that are going to throw
a dice), and m is the number of nodes that are going to influence on the probability
of activating the node global agents, normally equal to n (i.e., the number of sides
of every dice). The proof of this equation can be found in appendix A.
Figure 3.7a is plotted using (3.1) where n = m = {3, 5, 10, 25} and α = [0..10]. As
an example, if two nodes have n = 3 common neighbors, the probability of having
0, 1, 2, or 3 of them as spontaneous watchdogs is 0.296, 0.444, 0.222 and 0.038,
respectively.
As shown in Figure 3.7a, the probability of not supervising a packet is between
0.29 and 0.36. Therefore, in the spontaneous watchdog technique, one of three packets in the network will go unsupervised. Also, most packets will be analyzed by
one or two nodes of their neighborhood independently of the density of the network.
Thus, the energy consumption will be lesser in a high density neighborhood.
All these results depend on the assumption that every node has the same probability of activating its node global agent. However, it is possible to tweak the behavior
of the nodes by increasing that probability, hence decreasing the number of sides of
the “dice” (i.e., m in (3.1)). The results of an experiment where every node has
doubled its probability of being a watchdog (m = n2 ) are shown in Figure 3.7b. The
probability of not supervising a packet is only between 0.03 and 0.12, but the number
of nodes analyzing the same packet has increased by the order of one.
Therefore, it is possible to decrease the number of packets left unsupervised by
increasing the probability of a single node being a watchdog, but at the same time
the number of nodes activating their node global agents will increase. This is a
tradeoff between the security and energy utilization that network designers must
have in mind.
3.4
3.4.1
Trust Management
Introduction to Trust Management
The concept of trust (‘the firm belief in the reliability or truth or strength of an
entity’) derives from sociological or psychological environments. Trust is an essential
factor in any kind of network, social or computer networks, since it aids the members
of these networks to deal with uncertainty about the future actions of other participants. As a result, both trust and its management become specially important in
distributed systems or internet transactions.
The term trust management was first coined by Blaze et. al. [205] as an attempt
to build a coherent framework for security policies, credentials and trust relationships.
In a computing context, trust is usually defined in terms of the relationship between
a trustor (the subject that trusts an entity or a service) and a trustee (the entity
that is trusted). The basic tasks of a trust management system are the following:
determining initial trust, observing the trustee’s actual behaviour and updating trust
117
accordingly [207].
Usually, trust management systems can be classified into two categories: credentialbased trust management systems and behaviour-based trust management systems.
This classification is based upon the approach used in order to establish trust among
the peers of a system.
Credential-Based Trust Management Systems In this type of systems peers (or nodes)
use credential verification in order to establish trust with other peers (or nodes). The
primary goal of credential-based trust management systems is to enable access control. Therefore their concept of trust management is limited to verifying credentials
and restricting access to resources according to application-defined policies. A peer
requests for access to a restricted resource. The access is controlled by a resourceowner that provides access only if it can verify the credentials of the requesting peer.
Trust of the requesting peer in the resource-owner is not usually included. Thus,
this type of systems is useful when there is an implicit trust in the resource-owner.
However, these type of systems do not incorporate the need of the requesting peer
to establish trust on the resource-owner, for this reason they are not very good trust
management solutions for all decentralized systems. Credential-based trust management systems are PolicyMaker [205], its successor, KeyNote [206] or REFEREE [209].
Behaviour-Based Trust Management Systems These type of systems are also called
experience-based. In these models an entity trusts another entity based on past
experience or behaviour. Thus, entities can perform evaluation on the other entities
based on these features. These systems are mainly based on the concept of reputation
(‘What is generally said or believed about a person or the character or standing of
a thing’), which is quite related to the concept of trust. As it happens with the
term trust there are several definitions of reputation in a computing context. AbdulRehman and Hailes [204] define reputation as an expectation about an individual’s
behaviour based on information about or observations of its past behaviour. Jøsang
et. al. [213] define reputation as a mean of building trust; one can trust another
based on its good reputation.
There are some basic properties that any reputation-based trust model should
fulfil regardless their field of application: the model, the metrics, and the feedback.
The model specifies how reputation is built, the metrics establish how the reputation
values of an entity are stored, and the feedback indicates the type of output (either
positive or negative) given by the reputation. An example of trust system based on
reputation for e-commerce online applications is SPORAS [226]. Another example
of reputation model in the context of agent is REGRET [220].
3.4.1.1
Trust and Sensor Networks
Trust is a very important factor in the decision-making processes of any network
where uncertainty exists. That is, when the outcome of a certain situation cannot
118
be clearly established or assured. With no uncertainty, there is no need for a trust
management system: if an element of the network knows in advance the actual
behaviour of their partners (e.g. collaborative, malicious, faulty,...), it can make a
flawless decision. As a result, for knowing if a trust management system can be
applied to a WSN, it is necessary first to analyze the importance of uncertainty in
such environment.
Uncertainty originates basically from two sources [223]: information asymmetry
(a partner does not have all the information it needs about others), and opportunism
(transacting partners have different goals). On the context of sensor networks, opportunism is not a problem. All the elements of the network work towards the same
goal, and they have neither reason nor the will to behave egoistically. On the other
hand, a sensor node does not have information regarding others that will allow it
to know in advance how a transacting partner is going to behave. Therefore, there
exist some information asymmetry that the node must deal with.
Since all nodes belong to the same “living being” (i.e. always collaborate towards
a common goal), it is possible to think that the existence of information asymmetry
is not a real problem. When a sensor node chooses a partner to collaborate with,
such partner is supposed to be honest and fully collaborative. However, this is not
entirely true. As aforementioned in this chapter, sensor networks can suffer the
attack of malicious nodes or the existence of faulty nodes. As a result, uncertainty in
sensor networks is a problem that must be dealt with. Trust Management becomes
an important tool for securing long-lived sensor networks, allowing its autonomous
nodes to avoid “dubious nodes” that can affect the overall functionality and to choose
the “best partner” for a certain operation.
3.4.1.2
Solutions for Ad Hoc Networks
Existing trust management systems for ad hoc networks. In [216] the authors present a trust model for mobile ad hoc networks that can be used in a dynamic context within the routing process. Initially, each node is assigned a trust
value according to its identity. For instance, if no information is available about the
trustworthiness of a node the assigned value will be unknown. Each node records
the trust levels about their neighbours. Then, by using simple, logical calculations
similar to averages a node i can derive the trust level of node j, T Li (j).
In [225] secure routing is also considered but the way of assigning the trust levels
is carried out by evaluation of nodes over other nodes. Trust is evaluated considering
factors such as statistics, data value, intrusion detection or personal reference to
other nodes. The trust evaluation values, T E(i, j), are stored in a matrix. The
final trust value is calculated via a linear function that uses the values stored in the
matrix.
Reputation is considered in [218] as a way for building trust. The mechanism
builds trust through an entity called the trust manager. An important part of the
trust manager is the reputation handling module. Each node monitors the activities
119
of its neighbours and sends the information to the reputation manager. Then, the
information is passed to the reputation handling module and the reputation values
are obtained via simple metrics.
Zhu et. al. [219] provide a practical approach to compute trust in wireless
networks by viewing any individual mobile device as a node of a delegation graph G
and mapping a delegation graph from the source node S to the target node T into
an edge in the correspondent transitive closure of the graph G, from which the trust
value is computed.
Suitability of Existing Ad Hoc Solutions. As reviewed in section 1.1.1.3, ad
hoc networks and sensor networks are essentially different. Their subjacent infrastructures are different, and also both the behaviour and the functionality of their
elements are different. Due to these differences, it is not possible to directly apply ad
hoc trust management systems to wireless sensor networks, although there are some
aspects from their design (e.g. the existence of a reputation manager) that sensor
networks solutions should take into account [254].
Actually, it is possible to identify some of the exact issues that hinder the applicability of the previously reviewed ad hoc trust management solutions in wireless
sensor networks. For example, some approaches [216, 225] might not be suitable
for sensor networks due to initialization assumptions. These methods consider that
an initial trust value is given to each device according to their identity. This could
be considered a bit contradictory with the nature of sensor networks, as initially all
nodes in the WSN are preloaded with identification information created by the user.
Other approaches, such as [218], have no “memory” regarding the malicious activities performed by a device (e.g. when the reputation dropped below a predefined
threshold). This is of paramount importance for sensor networks, because a member
of the network do not behave maliciously by default. Finally, those schemes that
are designed for the specific architecture of ad hoc networks such as [219] cannot be
applied to sensor networks due to .
3.4.1.3
Solutions for WSN
Existing trust management systems for WSN. Research on trust and reputation systems for Wireless Sensor Networks is, as of 2008, at an early stage. Some
works have been done in recent years, however most of them are designed in order
to solve specific problems and do not identify the overall features that should characterize a trust management system for sensor networks. In the following, we will
discuss some of the most existing relevant approaches of trust management systems
for WSN, which have been mostly proposed for scenarios where the sensor nodes are
static and do not move from their deployment area.
One of the first works developed in this area was RFSN, by Ganeriwal and Srivastava [54]. They proposed a reputation-based framework for sensor networks where
120
nodes maintain reputation for other nodes and use it to evaluate their trustworthiness. Reputation is represented through a Bayesian formulation, more specifically,
a beta reputation system. The mathematical tool used for representing and updating the reputation values is the beta distribution of Jøsang [212]. The architecture
of the system consists of a watchdog mechanism, reputation, second hand information, trust and behaviour. Actually, many other systems are also based on watchdog
mechanisms for obtaining first hand information, such as [208].
The use of second hand information, or information coming from other nodes,
have been further extended in the literature. For example, in [228], The trust values are obtained taking into consideration different parameters: personal reference
and reference. The personal reference (Tpr(i) ) that a node which is computing trust
(judge) has on another node (suspect) is obtained by considering the events of the
network. Reference (Tr(i) ) is the kind of recommendation provided by the juries
(nodes that maintains the trust value of the suspect with the judge and sends out
the corresponding opinion periodically). Reference is obtained via a recommendation protocol to specify how the judge and the jury communicate to exchange the
information about the trust values. At last, the final trust value is obtained as a
weighted summation of the personal reference and the reference.
Other trust systems have been focusing on dealing with specific problems, like
detecting misbehaving nodes in “core protocols” (e.g. routing and aggregation).
[224] presents a location-centric architecture for isolating misbehaviour nodes and
establishing trust in sensor networks. The underlying problem the authors target
is a misbehaviour model in which a compromised or faulty node consistently drop
data packets while participating in signaling and routing protocols, always over static
networks.
The aggregation problem is considered in [227]. Aggregators use Jøsang’s belief
model in order to deal with uncertainty in data streams. The aggregator collects
information from other nodes, which is given in forms of reputation. The aggregator
node classifies the nodes into different groups based on their reputations. After
calculating these reputation values, the aggregator determines whether there are
compromised nodes. The best way to do that is by predefining a threshold.
There are other trust models specialized to work in hierarchical configurations,
trying to solve specific problems such as the election of a cluster head or detect failures
in clustered networks. If a malicious node becomes cluster head, it could affect
the services provided by all the members of a cluster. A possible countermeasure
introduced in [210] is to use a trust-based framework that reduces the likelihood of
a malicious or compromised node from being elected as a cluster head. The trust
parameters used are measurable and observable networks events. Thus, the trust
level, TN (Xi ), that node N has computed about node Xi , is calculated as a weighted
summation of those events.
Another example of cluster-based trust protocol is TIBFIT [211], whose main
121
purpose is to detect arbitrary node failures in an event-driven wireless sensor networks. A trust index is assigned to each node indicating its track record in reporting
past events correctly. The cluster head is in charge of analysing these trust indexes
and making event decisions. This trust index (TI) is a real number ranging from
zero to 1. Initially it is set to 1. For each report a node makes that the cluster head
estimates is incorrect the TI assigned to such a node decreases. The protocol is also
able to determine locations of the event reports.
Suitability of Existing WSN Solutions. It is clear that any trust management
system has to be specially designed and prepared for reacting against the particular
issues, such as autonomy, decentralization, and initialization, that can be found in
wireless sensor networks environments. In fact, the existing state of the art on
trust management systems can deal satisfactorily with some of the problems in this
area, creating useful solutions. Nevertheless, there are some aspects related to trust
management in sensor networks that have been neglected, or simply underdeveloped
[253].
The initialization of the trust and reputation values is one of those aspects. Some
systems do not consider it explicitly, and other systems tend to link initial reputation and trust values with authenticating the nodes [224]. However, in a realistic
sensor network setting, any node with no credentials should be expelled from the
network, since the communication channel needs to be protected with cryptographic
primitives. The exact nature of the initial trust and reputation values has not been
widely discussed yet.
Once the network starts functioning, the kind of information that is gathered will
determine how to calculate the reputation and trust values of a node. According to
the state of the art, possible information sources could be, for instance, forwarding
or dropping packets ([228, 224, 54]) or event reports [211]. Still, most of the existing
works on trust management for WSN concentrate only on the communication layer
of the network, forgetting information such as the sensory data. In addition, it was
already pointed out in [54] that not all events should be given the same importance
for calculating the reputation of a node. Still, this fact is not widely considered.
The past behaviour of a sensor node is also extremely important, but has received
little attention. Since all sensor nodes have to perform almost the same tasks continuously on time, a node should not be intermittently uncooperative. The consistence
in the trust readings is significant, as well. A normal sensor network environment
should produce very few reports regarding malicious activities. Therefore, the existence of different and contradictory reports should be evidence enough of malicious
activity and source of mistrust.
Another aspect that needs to be taken into account is the granularity of trust.
It is a very well-known property of trust that it is not universal. This means an
entity A may trust another entity B to perform an action but the level of trust
changes if the action is different (e.g. I must trust a mechanic to fix my car but
not to fix my teeth). Still, this concept has not been appropriately translated into
122
Base Station
Sensor Node
Trust
Entity
Trust
Entity
T
1st-Hand
Information
2nd-Hand
Information
…
…
Reputation
Manager
…
…
T
Trust
Manager
Trust Entity
Figure 3.8: Overall Architecture of a Trust Management System for WSN
the sensor networks context. For example, [208], gathers information and classifies
it into positive or negative events without specifying which kind of events should be
considered.
Regarding reputation, only a few systems take reputation explicitly into account
[208, 54, 227]. Still, having both reputation and trust in the same system is essential.
By not calculating the trust directly from the behaviour of a node, it is possible to
better handle aspects such as the evolution of the node, aging, etc.
As a final matter, one of the biggest constraints regarding trust management for
sensor networks is the overhead that the existence of this system may impose over the
constrained elements of the network. It is then imperative to balance the overhead
of the data collection process, and to make both these processes and the trust and
reputation models as lightweight as possible. Due to the broadcast nature of the
communications, the simplicity of the data collection processes, and the inherent
redundancy of sensor networks, we think it is possible to create a functional trust
management system for sensor networks.
3.4.2
Features of Trust Management Systems for WSN
As explained in the previous section, there have been many solutions that try to solve
the problem of applying trust values to decision-making processes in wireless sensor
networks. Although their underlying architecture is similar, there are some important
features and problems that are taken into account in some solutions, but partially or
completely ignored in others. Even more, some specific issues like the initialization
of reputation and trust are, in most cases, neglected. For the development of a
specialized trust management system, adequate for sensor networks, it is necessary
to review and point out which features have to be considered in a sensor network
context, alongside with the open problems that need further research [252]. This is
123
the major objective of this section.
3.4.2.1
Architecture and components
An important element of any trust management system is the trust entity. This entity
is in charge of obtaining, calculating and maintaining reputation and trust values.
For sensor networks, it is possible to define the structure of a generic trust entity, as
shown in Figure 3.8. In this structure, the “information” modules obtain information
about the behaviour of the members of its neighbourhood, either through observation
and experience (i.e. “first-hand information”) or by sharing the observed events with
other entities (i.e. “second-hand information”). After this process, the “reputation
manager” module can use this list of events to infer and store the reputation of the
members of its neighbourhood. Such reputation will be later used by the “trust
manager” module to obtain the trust values. Those values can be used either to
decide which is the best partner for a certain operation or to discover if one entity
should not be trusted. Both modules need to maintain and update their values
during the lifetime of the network.
This structure is clearly applicable to wireless sensor networks, because a sensor
node can obtain information about its surroundings either directly or indirectly. In
addition, the sensors have limited computational capabilities. Consequently, by using
lightweight algorithms, they can be able to infer the reputation of its neighbours and
decide if they trust them for certain operations. Moreover, this model of a trust
entity fits in the design of most of the existing work on trust for sensor networks that
consider reputation in their design [208, 54, 227].
Once the architecture has been introduced, it is time to define where the trust
entities should be located. That is: Which nodes need the trust values? In wireless
sensor networks, all the sensor nodes do. All sensor nodes participate on the protocols
that support the network, such as routing. The decisions regarding the execution of
the protocols (e.g. who could be the next node in the routing path when transporting
an “Out-of-Band” message) are usually made by the nodes on their own, and in
exceptional situations with the help of its direct neighbourhood (e.g. when clustering
a flat network, or when aggregating some data). Finally, faulty and/or malicious
nodes may appear on any part of the network.
As a result, the trust entities should be located either in every node of the network
for distributed networks or in the cluster heads for the hierarchical networks. This
is the same case as with the intrusion detection agents, which are also deployed
in a distributed manner (cf. section 3.3.2). In addition, and as pointed out by
Tanachaiwiwat [224], trust entities could also be implemented inside the base station.
Due to its role as a network manager and data repository, the base station receives
information from all the nodes in the network. As a result, its information asymmetry
is reduced: it has a global point of view of the state of the network, whereas sensor
nodes can only manage to observe their immediate surroundings. Although it cannot
directly influence over the behaviour of the nodes, it can issue orders that those nodes
124
must fulfill.
3.4.2.2
Initialization and information gathering
Before the entities in the nodes and the base station can start measuring the trust
of their neighbourhood, it is necessary to initialize adequately the trust and reputation values. This, which could be seen as a problem, is not that important. Before
deployment, sensor nodes are programmed in a controlled environment by the network manager, with similar tasks and services. Thus, at the beginning or their life
they can be completely trusted: Their hardware is supposed to be tested for failures
before deployment, and also at this stage any malicious adversary had neither the
time nor the chance to influence or subvert a node. Reputation is built over time,
using the behaviour of the nodes as a feedback. Initial reputation should not affect
negatively both trust and the decisions taken by the nodes. Note that other systems
tend to link initial reputation and trust values with authenticating the nodes. However, in a realistic sensor network setting, any node with no credentials should be
expelled from the network, since the communication channel needs to be protected
with cryptographic primitives due to its public nature.
After the network starts functioning, the nodes will provide its services, and the
trust management system will be able to start gathering “first-hand” and “secondhand” information from its direct neighbourhood. The monitoring process that gathers “first-hand information” must obtain general information from the behaviour of
the nodes, but also specific information related to the particular instances of the protocols used in the network. Precisely, the situation awareness mechanisms introduced
in section 3.2 can provide the trust entity with the information it needs about the
neigbourhood. Regarding protocol-specific information gathering (e.g. aggregation
by Zhang et. al. [227]), it can coexist with these situation awareness mechanisms,
providing complementary information.
A node should not only take into consideration this “first-hand information”
while observing other nodes, but also the reports produced by its neighbouring nodes
(“second-hand” information). Unfortunately, it is also possible to receive malicious
reports from tampered nodes. For this reason, there should be a mechanism for
assuring the correct management of the information. The inherent redundancy of
sensor networks can help to develop this kind of mechanism, since the existence of a
malicious report (e.g. a bad-mouthing attack) that is not coherent with the state of
the neighbourhood can be an indicative of a malicious presence.
On this information gathering process, it is important to note that a source
of second-hand information can be a sensor node accusing itself of being malicious.
Following the simile of the “living being”, this entire process is similar to the concept
of apoptosis, when a cell suicides due to malfunctioning, virus infection, or other
reasons [215]. Due to the embedded intelligence of a sensor node, it can detect
whether its batteries are low, its readings are inconsistent with its neighbourhood, or
its transceiver seems to not work. On discovering these issues, the sensor node can
125
try to alert its neighbourhood about its state. This situation can also be reported to
the base station: A malfunctioning sensor node can be recovered and subsequently
repaired by a human operator.
As with all second-hand information, it is possible for a malicious adversary to
try to take advantage of this apoptosis process. It can fake the message with the
purpose of alerting that a healthy, trusted node, has an internal problem. However,
if all these messages are sent using an authenticated channel (e.g. using techniques
such as µTESLA [65] or public key cryptography [217]), the only option left to
the adversary is to use its subverted nodes to accuse themselves of not functioning
properly. Even if such case occurs, this is counterproductive for the adversary: it
will alert the network and the base station about its existence.
3.4.2.3
Information modeling
Once the information, either “first-hand” or “second-hand”, has been gathered, the
trust entity can be able to output trust measurements based on existing reputation
values. The task of calculating and storing the reputation of a node relies on the
module known as reputation manager. Due to its memory constraints, a sensor node
cannot store all the events that its neighbours produce during its lifetime. Therefore,
it is necessary to create a lightweight reputation manager that could capture and
efficiently store the behaviour of other entities in the previous interactions, while
being able to update it with new information if possible.
The other part of the trust entity, the trust manager, is in charge of calculating
a certain trust measurement of a node using as an input its existing reputation, and
providing the trustor with a measurement that can help it to take a decision over a
certain trustee. This trust measurement should be obtained by taking into account
the risk of the interaction between the trustor and the trustee, and according to the
importance of the reputation value and that specific interaction. Risk and importance
are significant factors in the calculation of trust, but they also influence the selection
of a threshold. That is, when a certain trust value labels a trustee as “trusted” or
“untrusted” for a certain operation. There are other, non-exclusive ways to use the
trust values, such as when one trustor have to choose over a group of trustees.
While calculating the reputation of a node and its trust measurements, it is
essential to take into account the granularity of the trust management system. As
aforementioned, the reputation of a certain node is built according to its behaviour
and the events it triggers. Most systems simplify the reputation into one single set
of values. However, the actions of the nodes are not reduced to the execution of one
task. For example, a node can route information to the base station, and read the
physical measurements of its environment using the sensors, amongst others. A node
needs to maintain separate opinions about the existing actions of their peers, thus it
needs a different set of reputation values. A consequence of this fact is the need of
linking the existing events with the different reputation values they influence.
The existence of different reputation values also implies the existence of different
126
trust values. A specific trust value (e.g. routing) will help the node to decide about
the possible outcome of a specific interaction with another peer. On the other hand,
that value cannot be used in most cases to deduce what the peer could do in a
different task (e.g. sensing). For example, a node that loses data while forwarding
packets cannot be trusted as a message forwarder, but it may be trusted as a possible
source of data.
The dimension of sensor networks as balanced “living beings”, that should have
none or little deviation from its behavioral patterns, affects over the functionality of
both trust and reputation manager. For example, a node that acts truly maliciously
in the context of a sensor network will most surely keep such evil behaviour in
further interactions. Therefore, “bad” reputation should not be forgotten easily
while updating the reputation values. The evolution of the reputation on the aging
process is also an important factor that a node cannot ignore: a trust entity should
remember if a node achieved high “bad” reputation ratings on the past.
Also, the occurrence of certain events (e.g. the existence of a blackhole) have a
more direct impact on the reputation of a node. These events are a clear indicative of
malicious or erroneous activities. As a consequence, a node exhibiting such behaviour
should be flagged with a very low reputation value. In addition, the consistence of
the trust readings is also significant. A normal sensor network environment should
produce little or none reports regarding malicious activities. Therefore, the existence
of different and contradictory reports should be evidence enough of malicious activity
and source of mistrust.
Finally, all the important decisions taken by the nodes, such as node exclusion,
should be notified to the base station. It does not mean that the trust management
system has to be centralized, but that the base station, as the user of the network,
should know about the internal status of the network for logging, monitoring and
maintenance purposes. Also, the existence of a strange situation can be the symptom
of a greater problem, since sensor networks behaves satisfactorily by default. As a
result, the trust entity that exists inside the base station can use this newly acquired
information for the benefit of the whole network.
3.4.2.4
Existing computation models
We have focused our efforts on uncovering certain issues of trust management systems that are highly dependent on the specific features of sensor networks, but have
been neglected by the actual state of the art. As a result, we have not developed
some specific aspects such as the computational model that derives reputation and
trust values. Still, we include here a enumeration of these models for the sake of
completeness.
Usually, these methods are based in mathematical models such as statistics or
probability theory. This is very similar to approaches for ad hoc networks. As
these trust management systems are mainly behaviour-based, it is necessary to use
mathematical tools in order to compute the trust or reputation values.
127
Sometimes the trust values are calculated via simple or weighted summations of
the different data collected [221, 228]. Simple mathematical functions are also used
in [224]. Linear functions are also used in [221]. In this approach the calculation of
trust values is done in three different phases: at the node, at the cluster head and
at the base station. In each of these phases the calculation is done, for instance, by
functions such as
(P Ix,y ) + P Rx,y
T νx,y =
2
where T νx,y is the the trust value node x wants to calculate on node y. P Ix,y is
the past interaction trust value and P Rx,y is the peer recommendation trust value
of node y calculated by node x. These values are calculated using also similar linear
functions.
The approaches described above use simple mathematical functions such as summation or product. The exponential function can be also used, and this is the case
in TIBFIT [211]. TIBFIT tries to combat failures in the reporting event, thus each
node is assigned a T I, maintained at the cluster head. The T I is calculated as
T I = e−λν
where λ is a proportionality constant that is application dependent and ν is a variable
for each node maintained by the cluster head. This variable is incremented every
time the node makes a faulty report.
The beta distribution of Jøsang [212] is used in some systems developed for ad
hoc networks as well as for some systems for WSN [54, 227]. The advantage of
using this model is that is supported by a robust mathematical tool. This method
is based on the definition of an opinion that express the degree of belief in the truth
of a statement. This model is very suitable for the problem of aggregation in sensor
networks [227], as the aggregation of data problem is infiltrated with uncertainties
due to the unavoidable sampling errors, false data injected by either compromised
nodes or aggregators.
Probability theory is used in [208]. As we mentioned in section 3.4.1.3 this approach uses a watchdog mechanism in order to gather first-hand information. This
watchdog mechanism also records the outcomes of several events and classifies them
into positive or negative events, < p, n >. According to the Bayes theorem the
probability of a positive outcome, x, is defined as
(p + n + 1)! p
P (< p, n >, x|x)P (x)
x (1 − x)n
=
P<p,n> (x) = P (x| < p, n >) = P
p!n!
P (< p, n >, x|x)P (x)
This conditional probability is the posterior probability of reputation < p, n >.
128
CHAPTER
4
APPLICABILITY OF SECURITY SERVICES
This chapter studies how the different application-aware security mechanisms of the “complete set” can i) be included inside an architecture
and ii) used in the interactions with other networks. We present the
vision and goals of the EU STREP Project ‘Secure Middleware for Embedded Peer-to-Peer systems’ (SMEPP), and how the ideas presented
in this thesis, such as the transversality of security and the applicationoriented nature of the security mechanisms, are applied to an ongoing1
middleware architecture. Finally, we discover that the interactions between secure sensor networks and a secure Internet are not secure by
default, thus we examine the security problems that may hinder the relationship between these two networks, and we propose some solutions
while pointing out open problems in this area.
1
‘Ongoing’ as of 2008. The SMEPP project will finish on October 2009.
129
130
4.1
Middleware
The SMEPP project (Secure Middleware for Embedded Peer-to-Peer systems, FP6IST-033563) is an European STREP project funded by the European Union under
the 6th Framework Programme. It began on October 2006 and will finish on October
2009. The main objective of this project is to develop a new middleware, based on a
new network centric abstract model (embedded peer-2-peer), and trying to overcome
the main problems of the currently existing domain specific middleware proposals.
The middleware will be secure, generic and highly customizable, allowing for its
adaptation to different devices and domains.
Vision and goals of the SMEPP project
Embedded Peer-to-Peer Systems (EP2P) represent a new challenge in the development of software for distributed systems. P2P systems have brought about an important revolution in distributed computing paradigms, now that the roles of client and
server, which are the basis of the most widely used distributed computation models,
are disappearing. This scenario consists of systems in which all the elements of the
network are symmetrical and, in most cases, the mechanisms of communication are
not based on pre-existing infrastructures, but rather on dynamic ad hoc networks
among peers. At the same time, the recent technological advances in short distance
wireless communications and embedded systems have opened up new areas of application, where small, low-powered, low-cost systems collaborate in the processing
and management of information using wireless channels. These EP2P systems are
flexible enough to be applied in diverse areas, such as:
• Environmental monitoring: Monitoring of the effects of industrial plants on the
environment is a key issue in different application domains and particularly in
the field of nuclear energy. The use of EP2P opens up new fields that allow
monitoring in the case of small leaks during inspection or even in the case of
accidents where no other equipment is available.
• Home systems: A ”smart house” is usually made up of several intelligent devices
that can control home appliances or ”feel” its surroundings. EP2PS systems
can help in both the unobtrusive management of the smart house (from anywhere, to anywhere) and the collaboration between the embedded devices of
the house (e.g. ”nobody is in the room and the air conditioner is on. . . it
should be off”).
The SMEPP Middleware platform will have to comply with the following general EP2P objectives: adaptability, scalability, high availability, and ubiquity, as the
model will be based on the possibility of incorporating and removing resources in a
dynamic and adaptive way, and users can access those resources offered by the network anytime, anywhere. SMEPP applications will be covering and spanning over
131
a very heterogeneous terminal, gateway, sensor and device ecosystem (applications
may run on different devices, from PCs, Laptops, mobile phones and PDAs to sensor
nodes, with quite different network bandwidths, memory capacities and computing
power). The networking and routing protocols used will have to support the important dynamicity of the network topology (the elements come into the system and go
out in an independent way, involving frequent reorganization of the systems). The
latter objectives represent important technological challenges to tackle in the project
such as networking decentralization, network paths with transitory communications
(connections and disconnections happen in an unpredictable and frequent manner)
and a constantly changing topology.
A key aspect in the success of SMEPP is the possibility of abstracting all these
problems by means of the design of suitable middleware layers and blocks. Without such a middleware solution (including the tools and methodologies to support
its use), the definition, creation and maintenance of an application would be a very
complex task. The SMEPP middleware should hide the complexity of the underlying infrastructure while providing open interfaces to third parties for application
development. The development of such a middleware is challenging, since besides the
disappearance of the roles of client and server, which are the basis of the most extensively used current middleware (CORBA, J2EE, .NET), other critical requirements
appear, which have to be supported by these infrastructures (mobility, enhanced
security support for restricted computing power devices, node identification, service
discovery, advanced routing mechanisms and localization protocols, new quality of
software criteria, etc).
4.1.1
Security in the Middleware
4.1.1.1
Middleware architecture
The SMEPP Middleware architecture is shown in Figure 4.12 . It is divided into three
functional layers. The top layer consists of the Domain-specific Middleware services
and the Service Model Support that provide the actual API for application developers
for using the SMEPP Middleware. The second layer from the top is the Common
Middleware Services that provides the actual functionality of the Middleware defined
by the service model. Finally, the bottom layer is the distribution middleware that
contains all the framework implementations needed by the Middleware services for
providing the required functionalities.
Regarding security, it is considered as a transversal layer that can be accessed
by all the services of the middleware [260]. This point of view coincides with our
approach presented in section 1.2.3. The principal security components in this architecture are the following:
2
The interactions with other middleware frameworks is not indicated in this figure due to lack
of space.
132
Figure 4.1: An Overview of the SMEPP functional structure
133
• Group Security is concerned with the security related aspects of group establishment and maintenance. In SMEPP, the members of the network can join
certain groups, and they can access to the services of other peers only if they
belong to the same group. This component is responsible for the authentication
of peers which want to join these groups. Peers which have been authenticated
are either authorized to join the group or denied entry based on the group’s
access policy. Group Security also provides facilities for the secure communication amongst group members. This component is designed having one the
goals of this dissertation in mind: its mechanisms and algorithms are designed
according to the requisites of the application that is going to use the SMEPP
middleware.
• Cryptographic Services provide common functionality which is required for the
implementation of security-related components (e.g. Secure Topology Management, Group Security). This includes cryptographic primitives (encryption/decryption, digital signatures, Message Authentication Codes, unkeyed
hash functions) as well as supporting functions (random number generation,
key storage, certificate management). For the algorithms used in these services,
the SMEPP project considered the analyses presented in section 2.1.
• Infrastructure Security encompasses device-specific support for security functionality which facilitates the implementation of the security-related components. An important example are secure instruction sets (instruction set extensions for cryptography), which speed up cryptographic processing. These
features can be used to realize the Cryptographic Services more efficiently,
which in turn reduces the overhead incurred in all security-related components.
As an example of the relationship between this Security layer and other services,
we can mention the SMEPP Distribution Middleware. The components of this layer
will use the security services to control the authentication and authorization of new
peers, while protecting any routing-related information. Regarding the interaction
between components inside the same security layer, the Cryptographic Services component will use the cryptography extensions located in the Infrastructure Security
component if available. If the design is changed and new cryptographic extensions
are available, there is no need to change the whole architecture: the Cryptographic
Services component will simply use the new extensions.
Note that the Situation Awareness mechanisms are not explicitly mentioned in
this architecture. In fact, inside the SMEPP middleware, there are no services besides
routing that need the situation awareness mechanisms. As a result, the self-awareness
component exist as an independent component that only provides its services to
the secure routing mechanisms (e.g. to know if one node in the routing path has
disappeared). However, if in the future the self-awareness services are required by
other middleware services, it is only a matter of locating them inside the transversal
Security layer.
134
Figure 4.2: The three levels of security in SMEPP
4.1.1.2
Levels of security
In SMEPP, the application developer can choose the level of security that better
adapts to the scenario and the requirements of his/her application. These security
levels have been jointly developed by the security researchers of the SMEPP consortium, including ourselves, and are detailed in Figure 4.2. As shown in this table, it
is possible to configure what is the security credential used for entering a group, and
also the level of protection offered by a session key. By using a shared secret as a
security credential, the complexity of both the negotiation protocols and the security
components is reduced. However, the use of a shared secret is not recommended in
scenarios where a malicious attacker have chances to steal the information from the
devices. In such a case, it is better to use public key cryptography for limiting the
effects of those compromise attacks. Regarding the level of security offered by the
session keys, the simplest level that offer protection just assures the integrity of the
message and the authenticity of its source as a member of SMEPP. On the other
hand, the highest level of security also protects the confidentiality of the message,
dissuading any external devices from accessing the information flow.
The customization of the security parameters in SMEPP does not end here.
SMEPP features multiple security domains: one global domain (all the members
of SMEPP belong to this domain) and various group domains (one for each group
in a SMEPP application). Within SMEPP, it is possible to select different levels of
security for every domain. The application designer can choose to protect the global
domain and only allow the existence of authenticated peers, but it is also possible
to create a public network that anyone can join. On the other hand, it is possible
to modify the level of security of one particular group, allowing the coexistence of
groups that can be accessed by any member of SMEPP and groups that can only be
accessed with the right credentials (a simple shared key or a public key certificate).
135
The architecture of SMEPP follows a component-based model, thus it can be
possible to adapt the middleware to the requirements and constraints of the application. For example, if some security mechanisms are not used (e.g. the security level
that uses public key cryptography), then it is possible to just remove them from the
architecture. By using components, it is also possible to optimize the architecture:
one single component can provide services to different elements. For example, the
Cryptographic Services component provide security primitives to both type of domains, group (managed in the Group Security component) and global (managed in
the SMEPP Distribution Middleware components). As a final note, the use of public
key cryptography in the highest level of security was taken into consideration by the
SMEPP consortium partially because of the results presented in section 2.1.
4.2
4.2.1
Connectivity - Sensor Networks and the Internet
Integrating WSN and the Internet
The sensory cells of a living body need a brain that can react to the information
coming from the physical world. This simile can also be applied to sensor networks:
they need to interact with an external system in order to be useful. The simplest
sensor network deployment consists on a collection of sensor nodes and a base station.
Either a computer system or a human being will be connected to that base station,
and will make use of the information coming from the sensor nodes. For example, a
farmer can inspect the moisture of his crops just by looking at the data collected by
the base station.
The services of sensor networks could also be accessed by users located in external
networks, either through the base station or directly accessing to the sensor nodes.
Consequently, the flow of information produced by the networks could be retrieved
and analyzed by different applications situated in diverse geographical locations.
Furthermore, an operator could control a sensor network remotely, without physically
accessing the deployment field.
However, if those services were to be published by using standard interfaces in
a public network infrastructure, their potential would be fully unleashed. Any interaction with sensor networks would go beyond the notion of ”remote access”, into
the realm of ”collaboration”. Just as a living being’s brain pictures the state of its
surroundings by receiving information from many different types of sensory cells, the
flow of information provided by a single sensor network could be further combined
with other data sources or even with other sensor networks to create increasingly
complex services. Actual examples include coordinating patient’s health data with
the bed occupancy at hospitals in case of disaster [235], and triggering imaging via
satellite based on the input of different sensor networks measuring earthquake data
136
Front-End Proxy Solution
Data
Data
S-Data
Sensor Data
TCP/IP
TCP/IP
S-Proto
Sensor Protocol
MAC
MAC
802.15.4
IEEE 802.15.4
Data
Gateway Solution
TCP/IP Overlay Solution
Data
Data
TCP/IP
TCP/IP
S-Proto
Sensor Protocol
MAC
MAC
802.15.4
IEEE 802.15.4
Data
Data
Data
TCP/IP
TCP/IP
TCP/IP
MAC
Internet Host
MAC
802.15.4
Base Station
IEEE 802.15.4
Sensor Node
Figure 4.3: WSN-Internet integration strategies
[19].
All these visions can become a reality if sensor networks are connected to the
Internet. The operational challenges of a completely successful integration are enormous. For example, the vast number of data sources should be harnessed in order
to undertake broad scientific studies. Also, there should be mechanisms to discover
and tap into real-time data sources. In addition, query processing should also be
distributed across the Internet, pushing the query logic into the infrastructure [246].
However, the immediate benefits of a basic integration between sensors and Internet hosts are sufficient enough: any Internet user or device from any geographical
location in the world will be able to access to a sensor network services.
There are many approaches that can be used to open the services of sensor networks to the worldwide community. Sensor networks can behave as adjacent ”capillary networks” [243] that are not fully integrated in the Internet but provide its
services through a standard interface, or can behave as any other IP-based network
whose nodes are able to establish direct connections with any other Internet host.
Besides, there is a third option, where the sensor networks retain their independency
but allow the establishment of direct connections. These three approaches are shown
in Figure 4.3, and are discussed below.
In a front-end proxy solution, the base station serves as an interface between the
data acquisition network (sensor network) and the data dissemination network (the
Internet). The base station collects and stores all the information coming from a
sensor network, and also sends any control information to the sensor nodes. There
is no direct connection between the Internet and a sensor node: all incoming and
outgoing information will be parsed by the base station. As sensor networks are
137
completely independent from the Internet, they can implement their own protocols
and algorithms. From a functional point of view, the base station can offer the
services of its nodes (e.g. data streams) through standard mechanisms such as web
services [236] or web streams [230].
In the gateway solution, the base station acts as an application layer gateway,
in charge of translating the lower layer protocols from both networks (e.g. TCP/IP
and proprietary). As a result, the sensor nodes and the Internet hosts can exchange
information directly. In this approach, a sensor network can still maintain some of
its infrastructural independence, although it is necessary to create a translation table
that maps the sensor node addresses to IP addresses. Some web services solutions
such as TinyREST [239] take advantage of this approach. There is a small variation
of this solution, the Delay-Tolerant Network (DTN) gateway solution, where the base
station can be able to store and forward packets between the networks. In this case,
if the link between the base station and the sensor node is broken, the packet is not
transmitted and is stored for future forwarding [237].
Finally, in the TCP/IP overlay solution, sensor nodes do communicate with other
nodes using TCP/IP. Therefore, the main function of the base station is to behave
as a router, forwarding the packets from and to the sensor nodes. These nodes must
implement the protocols and standards used on the Internet, such as the TCP/IP
stack and web services interfaces. Currently, there exist implementations and specifications for IPv4 [229] and IPv6 [240] in sensor nodes, although it is widely assumed
that future deployments should be based on IPv6 [232]. Nodes can also provide
web services, by reporting its interface using the web service description language
(WSDL) and connecting to other hosts using HTTP [244].
While the advantages of connecting sensor networks with the Internet are obvious, it is not exactly clear whether sensor nodes should be completely integrated
inside the Internet or should maintain its independency as part of a cloud of ”adjacent” networks. Some of the infrastructural issues that have to be considered when
deploying sensor networks connected to the Internet are discussed below:
• Addressing: In order to send a message to a specific sensor node in the frontend proxy solution, it is necessary to incorporate such functionality into the
base station interface (e.g. as a web service). This is not the case of the other
solutions, where a sensor node can be directly addressable using IP addresses.
Nevertheless, it is not clear how IP addresses could be used in sensor networks that identify its nodes using location information or other data-centric
protocols.
• Protocols: By achieving interoperability at the network and application layers (TCP/IP and web services, respectively), it is possible to integrate sensor
networks inside the Internet. Besides, this is also beneficial for achieving interoperability between different vendors. On the other hand, by using specific
138
protocols that are tailored to the requirements of the application and the scenario where a sensor network is deployed, such network may be able to react
adequately and optimally to application-specific problems.
• Data Availability: When a sensor node is not available, it cannot be possible
to obtain neither data streams from its sensors nor historic values stored inside
its flash memory. However, if the data stream is accessed through a proxy or a
gateway, there can be specific network mechanisms that allow the provisioning
of data regardless of the state of the node (e.g. by measuring data from nodes
that are in the same context than the broken node).
• Network-specific issues: Sensor networks have very specific features that differentiate them from other network paradigms. Their nodes are battery-powered,
and in most scenarios they should provide their services for as much time as
possible. Besides, in order to save energy, the data rate of the wireless channel
is not high (i.e. 250kbps in the IEEE 802.15.4 standard). Therefore, both the
sensor networks protocols and the applications that use their services should
take into account these specific constraints.
4.2.2
Security challenges
In this dissertation, we have presented and developed a “complete set” of security
mechanisms whose sole purpose is to enforce the security properties that sensor
networks must have. It could be assumed that, once we have the foundations of a
secure sensor network, any interaction between a (secure) sensor network and the
(secure) Internet will be secure.
However, this is not the case. In this integration process, there will appear new,
previously unidentified security challenges that need to be taken into account by both
sides [247]. As the users of the network will connect remotely to the services provided
by the nodes, there is the necessity of protecting the information flow. Besides, the
aperture of sensor networks services to the whole world community will facilitate the
existence of unauthorized users trying to access the networks. Therefore, there must
exist some mechanisms for authenticating both nodes and users, for checking if an
user is authorized to access the node, and for detecting any attacks coming from the
outside network. Other factors such as availability and accountability need to be
considered, as well.
When a sensor node and an Internet host communicate, it is important to set up a
secure channel that supports end-to-end integrity and confidentiality services. If the
integrity of the sensory data is protected, attacks targeting the data stream will not
be able to falsify any readings. In addition, once the confidentiality of the sensory
data is assured, any adversary will not be able to read any sensitive information
from the data stream. The creation of a secure communication channel requires of a
common secret key between both peers, which should be negotiated using standard
139
Internet security protocols such as SSL/TLS [231]. Besides, it could be possible to
use some of the KMS Protocols presented in section 2.2. Note that, in most cases,
using pre-shared keys (e.g. as in TLS-PSK [233]) is not a feasible solution: it is not
flexible to force the users to share a fixed security credential with sensor nodes in
order to open a secure communication channel.
It is also important to provide support for device authentication and user authentication. An Internet host should have the certainty that he is reading sensory
data from the right node in the right network, while a sensor node should know that
is providing its services to the right client. Again, standard security protocols such
as SSL/TLS do provide authentication, although in most cases it requires the sensor
nodes to manage digital certificates and to belong to a certain public key infrastructure (PKI). Nonetheless, authenticating the devices that are interacting may not be
enough for specific scenarios, where the user that is trying to access the node should
also present some credentials.
The authorization problem is closely related to the authentication problem. Once
any user of the network (being a human user or a machine) proves its identity, it
may be necessary to check whether that user have the rights to access the sensory
data. For example, public data such as the temperature of an university building
may be accessed by everyone, while other data streams such as the radiation level of
a nuclear power plant should only be accessed by those who have enough authority.
Not only should the access to the data be controlled, but also the granularity of the
data, as well. Beyond data, it is also necessary to watch over control operations: sensors should be remotely reprogrammed and retasked, and only authorized personnel
should be able to do so.
Other specific issues that may arise while integrating sensor networks in the Internet are accountability, intrusion detection, and availability. Since a heterogeneous
set of users will be accessing the sensor networks services, it would be important to
record the interactions with those users. By analyzing those interactions with an
intrusion detection system, it could be possible to detect and react against possible attacks. Besides, by storing all interactions, we can be able to recreate security
incidents and abnormal situations. However, unlike Internet servers, most sensor
nodes have a limited amount of computational power and storage. Therefore, it is
necessary to develop simple but efficient detection mechanisms, and also to devise
an optimized way to store log data. Note that the detection mechanisms could be
included inside the IDS architecture developed in section 3.3.
Finally, as the main purpose of sensor networks is to provide sensory data to their
users, the availability of this data is another sensible subject that must be analyzed in
detail. If a sensor node is unavailable due to hardware error or any other malfunction,
any external hosts will not be able to query it for data streams. Moreover, the node
may be subject to external attacks by malicious hosts, and those attacks can affect
the node in a variety of ways: from saturating its scarce resources to exhausting its
battery. It is then vital to devise some mechanisms that can protect the nodes and
140
assure the availability of the data streams and other network services.
While protecting the interactions between the sensor networks and the Internet,
it is essential to have in mind the inherent limitations of the sensor node hardware.
In most cases, constrained sensor nodes may not have the resources to implement
full-fledged Internet protocols. Even more, sensor nodes should spend as less energy
as possible during their normal operation, if they are deployed for long periods of
time. Therefore, the protocols should be adapted to function optimally in these
limited devices. Even more, it should be considered if a sensor network deployment
allows the security tasks to be delegated to more powerful devices such as the base
station.
4.2.3
Security achievements and open issues
We have previously discussed that the secure integration of sensor networks and the
Internet is an underdeveloped research subject, with many factors such as authentication and availability that must be taken into account. Nevertheless, it is actually
possible to set up a sufficiently strong infrastructure where sensor networks can interact securely with Internet hosts. It is the purpose of this section to show these
findings, together with some open issues [247].
• Front-end proxy solution.
Although sensor networks must be sufficiently secure by themselves, it is necessary to protect the interactions between the networks and the Internet. In
a front-end proxy solution, the base station acts as a representative of all the
sensor nodes. By acting as any other Internet host, all the services of a sensor
network can be accessed through it. Therefore, most protection mechanisms,
such as key management or intrusion detection, can be implemented and deployed in the base station. As the Internet and sensor networks are logically
separated, it can be possible to protect the information exchange between an
Internet host and the base station by using any of the existing security standards, while any interaction between the base station and the sensor nodes can
make use of simpler security approaches. Besides, the sensor networks can implement specific mechanisms (e.g. sensor redundancy) to optimize and improve
the internal behaviour of the network.
Note that, in this case, the base station becomes a single point of failure: if the
base station is successfully attacked, an adversary may have access to all the
information flow. Moreover, if the base station malfunctions, sensor networks
will be completely inaccessible. A possible solution is to use multiple base
stations with the purpose of improving the availability of the network in case of
base station failure and including new features such as load balancing. However,
new challenges such as maintaining the information consistency between all the
base stations will need to be solved.
141
In this front-end proxy solution, Internet hosts can negotiate and establish
secure end-to-end channels with the base station by using standard protocols
such as TLS in the transport layer or WS-SecureConversation [242] in the
application layer. In contrast, the base station and the sensor nodes can make
use of simpler mechanisms such as pre-negotiated shared keys, or even public
key cryptography if it is available. Regarding authentication, as all nodes
are considered to be under control of the base station, such base station can
authenticate itself (e.g. present its own digital certificate) on behalf of its
sensor nodes. User authentication is also managed by the base station, either
by using public key certificates or other authentication mechanisms such as
(user, password) pairs or protocols like Kerberos [241].
About authorization, the base station can either analyze the credentials presented by the users (e.g. attribute certificates) or check whether the user is
authorized to perform certain operations (e.g. by using access control lists ACL). Afterwards, the base station can change how the network services are
provisioned: filtering the data provided by the sensor nodes, allowing the user
to change only certain configuration values of the nodes, and so on. About accountability and intrusion detection, there can be a close collaboration between
the sensor nodes and the base station to control and monitor the actual state of
the network. The base station can store and analyze any interaction between
the hosts and the nodes, and can also retrieve and analyze any behaviouralrelated information from the nodes themselves. Finally, the front-end proxy
solution alleviates certain problems such as the storage of historic data and
the availability of malfunctioning nodes. The base station can behave as a
”cache server” by storing the sensor nodes data, although it requires querying
the sensor nodes even if there is no data requests from external hosts. Also, it
can monitor whether a certain node is accessible or not, forwarding any control
information if the node becomes available again.
• TCP/IP overlay solution.
By considering the Internet and the sensor networks as separate entities, it is
not necessary to use the already limited resources of the sensor nodes to implement costly Internet standards. However, this situation changes in the TCP/IP
overlay solution, where the sensor nodes become Internet hosts. As a result,
sensor networks should be no longer considered as independent entities, and
both the protocols and the security mechanisms that are used in the Internet
hosts should also be supported by the sensor nodes.
As of 2008, it is possible to send IPv6 packets through a IEEE 802.15.4 network by using the 6lowpan specification [240]. For link-layer security, 6lowpan
recommends to make use of the security mechanisms defined at the link layer
by the IEEE 802.15.4 standard. However, for network layer security, IPsec is
currently not supported, and it is not clear whether sensor nodes will be able
142
to support the use of these low-level security mechanisms that have end-to-end
properties. In fact, the use of a full-fledged IPsec implementation for sensor
nodes is discouraged, and even some incoming standards such as ISA100.11a
[234] defines only a simple transport level security above UDP. 6lowpan advises
to identify the relevant security model and a preferred set of cipher suites that
are appropriate given the constraints [238].
Even if there is no support for an end-to-end secure channel at the network
layer, most applications still may need to create such channel to protect the
information flow. This issue can be partially solved by providing security at the
transport layer, using the TLS/SSL standard. A prototype known as Sizzle,
developed at Sun Microsystems in 2005 [118], serves as a proof-of-concept. In
order to save enough resources, Sizzle implements only a relatively small set
of cryptographic algorithms. In addition, there is no certificate parsing code,
thus clients may need to authenticate themselves using other mechanisms such
as passwords. Note that in case of connecting sensor nodes from different
networks, it may be possible to use those key management systems that allow
node connectivity (cf. section 2.2.2), such as protocols in the mathematical
framework or protocols based on public key cryptography.
Regarding user authentication, it may not be feasible to store user credentials (i.e. user and password pairs) inside a sensor node. In this case, all the
sensor nodes that belong to the same network should create a mechanism for
storing and maintaining such credentials. The same problem applies to user
authorization: it would be necessary to maintain the access control model in
a distributed form, which is an extremely difficult task. A possible solution is
to use Kerberos. For authentication, the sensor nodes just need to check the
ticket provided by the ticket granting server. Kerberos can also pass authorization information generated by other services. Note that Kerberos requires
continuous availability of a central server, and all devices must maintain their
clocks loosely synchronized. Furthermore, PKC solutions (identity certificates,
attribute certificates) can also be applied if supported.
The low storage capacity of highly constrained nodes significantly hinders the
accountability of the network. A possible solution could be to store only information regarding abnormal situations caused by hosts accessing to its services
(cf. section 3.3.2). The IDS in charge of detecting these abnormal situations
should include specific rules related to interactions with external devices, such
as clients trying to continuously access the services of the node. In addition,
storage capacity partially influences availability: a single node can only store
its readings for a limited time, thus the historic data should be either stored
elsewhere or summarized somehow.
• Gateway solution.
Some of the challenges that are associated with the TCP/IP overlay solution
143
can be partially solved using the gateway solution. The gateway (i.e. the
base station) can take the role of analyzing and / or storing the accountability
information regarding the interactions between hosts and nodes. It also can
store the historic data of the nodes, if they have the risk of running out of
storage space. In addition, it can improve the availability of the network acting
as a ”cache server” or as an intelligent forwarder, like in the front-end proxy
solution. On the other hand, if end-to-end secure channels are negotiated, it
should be necessary to implement non-trivial mechanisms in the gateway to
parse the information between an Internet host and a sensor node.
It should be pointed out that, in the TCP/IP overlay solution, the router that
connects the Internet and a sensor network must translate the IPv6 packets to 6lowpan packets. This translation can be performed within the base station, thus the
base station can be able to carry out the same tasks of the gateway (e.g. accountability, availability). Another aspect that needs to be highlighted is that some sensor
networks are composed by different types of nodes, where both cluster heads and
certain special nodes that control external systems have higher computational capabilities (i.e. similar to class III nodes). Consequently, it should be studied how to
implement full-fledged Internet protocols in these cluster heads and special nodes,
and how they could be accessed.
On a final note regarding the implementation of all these mechanisms and protocols, the computational capabilities of modern class II nodes may not be enough to
support standard Internet protocols. Contemporary sensor nodes are either limited
by low RAM (4kB) or low flash ROM (48kB). One of the 6lowpan stack implementations [245] needs 28kB of ROM. Also, Sizzle (SSL over nodes) requires 16kB of ROM
without including certificate parsing code (i.e. managing client-side certificates) and
6lowpan support. Besides, the RAM usage of a basic Sizzle program is very near to
4kB. As a result, it may be necessary to improve the minimal memory capabilities
of future class II nodes.
144
CHAPTER
5
CONCLUSIONS
This chapter concludes this thesis. We explain how we have accomplished our goal of the feasibility of a “complete set” of applicationaware security mechanisms by highlighting our contributions to the
field. We also introduce open problems that need to be solved and new
lines of research where the concepts and solutions presented in this
thesis could be applied.
145
146
5.1
Overview
Wireless Sensor Networks are capable of behaving as a digital “sensory system”,
obtaining and processing physical information through its “sensory cells”, the sensor
nodes. Any kind of computer system can use this flow of information to interact with
the real world, effectively creating a new dimension where the inanimate and the
animate are able to cooperate in new and interesting applications. Nevertheless, it is
essential to introduce security into this picture. Without security, the foundations of
this new dimension would be so weak that any small problem would make it crumble,
affecting both the abstract world and the real world.
The research community has acknowledged the importance of creating secure
sensor networks, and there are many solutions that try to protect these networks
from their hardware layer to the logic of their applications. However, there is a
factor that still has not been widely considered in the development of these security
mechanisms: the influence of the applications. In fact, every aspect of a particular
sensor network (e.g. its network architecture, its protocols, its functionality) is highly
dependent on the requirements of the application and its context.
In this thesis, we have considered the influence of the applications and their context in the development of a “complete set” of security mechanisms. This “complete
set”, which should be located inside a transversal layer in the architecture of sensor
networks, can be defined as a set of application-aware security mechanisms that are
necessary to minimally enforce the security properties.
In the course of this dissertation, We have shown that all these security mechanisms are feasible in a sensor network context. Besides, we have illustrated how the
nature of the applications and their context influence over the development of the
security mechanisms. All these accomplishments are described in more detail in the
following paragraphs.
Suitability of cryptographic primitives. Cryptographic primitives are the foundation to create confidentiality, integrity, authentication, and authorization services.
In addition, they are also useful for developing more complex security services. Due
to the existing constraints in the sensor node hardware and the different types of
nodes can be found in the market, our purpose was to review the suitability of the
actual state of the art in cryptographic algorithms for sensor nodes through their
existing software and hardware implementations. The results are satisfactory: All
sensor node devices (classes I, II, and III) can run symmetric key cryptography and
hash functions, and the sensor nodes with higher capabilities (classes II, III) can run
public key cryptography. If the application needs of optimized security primitives,
such as fast public key cryptography, it can be possible to include specific cryptographic hardware modules inside the sensor node. Besides, highly constrained nodes
(i.e. class I) can also use these hardware modules to implement the cryptographic
primitives.
147
Relationship between the requirements of an application and the properties of a Key Management System. It is essential to take into account the
requirements of an application in order to select an appropriate Key Management
System (KMS) for such application. For example, if we are going to set up a small
sensor network, we may not need a KMS protocol that is specifically designed to
support network scalability. Also, if we are going to add new nodes during the lifetime of the network, then we surely need a KMS protocol that is extensible, that
is, that allows the inclusion of new nodes. Our purpose was twofold: to specify the
different properties of a Key Management System, and to analyze the relationship
between those properties and the application requirements. Not only we have modelled the properties that define the features of a Key Management System, but also
we have uncovered how the importance of every property can be measured given the
requirements of a particular application and its context.
Methodology for selecting and analyzing Key Management Systems. In
order to study the viability of sensor-specific KMS protocols, we aimed to develop a
methodology that could analyze how KMS protocols behave in specific applications.
We pursued three goals: (1) provide a methodology that could allow network designers to select a suitable KMS protocol for his/her particular application, (2) to
check whether the current state of the art in KMS can offer a viable solution to the
key establishment problem in wireless sensor networks, and (3) to determine where
researchers should focus their effort in order to create useful KMS protocols that
could be used in real-world applications.
We have met all these goals. We have created a methodology based on the
relationship between protocol properties and application requirements. Not only the
methodology can be useful for network designers, but also we have used it to analyze
the state of the art in KMS protocols. As of 2008, it is perfectly possible to provide
link-layer secret keys to almost any kind of sensor network if only the size of the
network and the node mobility are considered. We have identified which are the areas
that need more research: i) networks with mobile nodes that move at a high speed, ii)
static networks of medium / large size where no nodes should be disconnected from
the network, and iii) extensible networks with almost no communication overhead,
that is, where the communication overhead is a main property (e.g. underwater
sensor networks). Also, it is necessary to develop KMS protocols with superior
Extensibility and Resilience properties.
Support for Public Key Cryptography. Since Public Key Cryptography can
be used in sensor networks, there is the need of a supporting infrastructure. That is,
a Public Key Infrastructure (PKI) that can be able to establish a trusted identity,
amongst other things such as defining the certificate format that is more suitable
for sensor nodes. Therefore, we have shown how the different elements of sensor
networks can behave as the different entities of a PKIX model. Besides, we have
148
used the X509v3 certificate format as a foundation to discover which fields are necessary in a sensor network context. Moreover, we have also studied how to apply to
sensor networks other PKI functions such as Key Pair Recovery, Key Update, Cross
Certification, and Key Revocation.
Identity-based cryptography and Self-certified cryptography. Sensor networks can be viewed as key-escrowed systems, that is, there exists a trusted party
(i.e. the base station) who computes the secret keys of the users. As a consequence,
it is possible to study the applicability of different forms of key-escrowed public key
paradigms, like identity-based cryptography or self-certified cryptography, for solving the Authenticated Key Exchange (AKE) problem. The results are encouraging:
One hand, self-certified cryptography (e.g. SC-ECMQV) is more efficient in terms
of communication and energy cost than other protocols based on classical public
key cryptography (e.g. ECMQV). On the other hand, identity-based cryptography,
quite inefficient in terms of speed, is extremely useful in underwater environments,
exchanging less data than the other protocols and having a smaller energy cost.
Development of lightweight awareness mechanisms. In order to be fully autonomous and self-capable, it is essential for the sensor nodes to be aware of their
environment. This self-awareness can help to detect certain events that might affect the behaviour of the network. Our goal was to develop lightweight awareness
mechanisms that could detect those abnormal events. For this purpose, we used
the simile of “a sensor network as a living body”, and considered that the presence of certain symptoms (i.e. collateral effects) will be indicative of the existence
of a disease (i.e. abnormal event). By analyzing the symptoms produced by node
malfunctioning, external attacks, and internal attacks, we derived a set of situation
awareness mechanisms. We also considered the fact that the symptoms associated
to an specific illness depend not only on the illness itself, but also on the patient
characteristics. Therefore, we also analyzed how the applications influence over our
situation awareness mechanisms.
Development of an Intrusion Detection System. Intrusion Detection Systems
(IDS) are valuable tools for detecting possible attacks that could be launched against
a network, as well as for preventing service interruption or loss of data that could
happen as a consequence of such intrusion. In Wireless Sensor Networks, an IDS can
detect which nodes are suspicious or malicious, and provide this information to other
protocols of the node (e.g. routing, aggregation). Due to the gaps in the existing
research, we focused on developing a blueprint of a distributed IDS architecture
that could fulfill all the following properties: full network coverage (cover all the
information flow of the network), simplicity (use mainly simple components, statistics
and mechanisms), and adaptability (possibility to include new detection mechanisms
and existing research, or to exclude those detection mechanisms that are not needed).
In this architecture, we considered that the software detection elements (known as
149
agents) should be located in all the entities of a sensor network. We also defined three
types of agents (node local agents, node global agents, and base station agents), and
specified their internal architecture, their specific tasks, where they should be located,
and when they should run their detection mechanisms. Furthermore, we also defined
four support protocols for our IDS: Piggybacking Forwarded Messages (identifies
the original sender of a forwarded message), Obfuscated Watchdog (protects the
nodes against subversion), and Spontaneous Watchdogs (allows node global agents
to choose whether to analyze the contents of a packet or not depending on the
redundancy of the network).
Trust Management Systems in WSN. Trust is a very important factor in the
decision-making processes of any network, such as sensor networks, where uncertainty
exists. That is, when the outcome of a certain situation cannot be clearly established
or assured. Therefore, it should be necessary to develop certain trust mechanisms
that help other services such as routing, aggregation and time synchronization to
choose a certain partner according to its reputation. The existing state of the art is
not complete, that is, it neglects certain aspects such as trust initialization that must
be taken into account. In our analyses, we discovered that those aspects depended
on the intrinsic nature of the sensor networks paradigm. We took into account
such nature for defining the possible components of a trust management system, the
initialization of trust, the nature of the “first-hand” and “second-hand” information
sources, the information modeling processes, and many other factors.
Security as a transversal layer: the SMEPP middleware. The SMEPP
project (FP6-IST-033563) is an European STREP project funded by the European
Union under the 6th Framework Programme. Its major goal is to develop a secure
middleware for embedded peer-2-peer devices (EP2P), including sensor nodes. The
ideas presented in this thesis have been successfully applied to the development of this
middleware, which is still under development as of 2008. More specifically, security
is considered as a transversal layer, where the security primitives benefitted from the
analyses performed in this thesis, and the key management systems considered the
requirements of the applications by defining different levels and dimensions (global
and group-based) of security. Moreover, the situation awareness mechanisms will be
used to help the routing services.
Secure integration of wireless sensor networks and the Internet. The advantages of connecting sensor networks to the Internet are enormous: Not only any
Internet user or device from any geographical location in the world would be able
to access to the sensor networks services, but also they could collaborate in order to
create complex services. Still, having a secure sensor network is not enough to protect this kind of interaction, because the security challenges that have to be solved
are significant: It is necessary to protect the information flow, to create mechanisms
for authenticating and authorizing both nodes and users, and to take into account
150
other factors such as availability and accountability need to be considered, as well.
We defined and studied these security challenges, describing some open problems
like the secure connection of networks by using TCP/IP protocols. We also pointed
out where the mechanisms presented in this thesis (situation awareness, specific key
management systems) could be of use.
5.2
Future work
During the development of this thesis, we have identified some issues and areas in
need of further research. One of those areas is related to the cryptographic primitives.
It may be necessary to develop specific primitives which are specially designed for
highly constrained devices such as sensor nodes. Also, the hardware prototypes have
not been integrated into sensor nodes like the MICAz or the TelosB [85]. It can
be interesting to analyze how the cryptographic chips will interact with the motes.
Note that the stream ciphers developed in the ECRYPT Stream Cipher Project [82]
could be very useful in a sensor network context, and the development process of a
new hash function standard [83] may yield interesting results in both software and
hardware implementations.
Regarding the Key Management Systems, we have identified several important
scenarios and properties that should be addressed by the research community. For
example, the scenario where there should be no nodes disconnected from the network
can be mapped to certain scenarios in Wireless Sensor and Actuator Networks, where
it should be essential to assure that all the Actuators are connected to the network.
Moreover, we have only specified the factors that a trust management system should
take into account in a sensor network context. It is necessary to further develop this
concept and create a fully functional and usable trust management system.
One of the most interesting research lines that we have uncovered is the interaction between the Internet and the sensor networks. We have proposed some solutions
to manage the security of front-end proxy configurations, and also suggested the use
of Kerberos to manage use authentication and authorization, but the suitability of
these solutions is yet to be completely proven. Besides, this research area has other
interesting open problems, such as maintaining the information consistency between
redundant base stations, open secure channels in a TCP/IP configuration, the management of the accountability of the events of the network and the maintenance of
the historic data, the implementation of secure Internet services in constrained sensor
nodes, etc.
Note that most of the analyses have been done only considering the existence
of a static network with very limited or no mobility. In fact, this is the network
configuration used by most applications and research projects as of 2008. Still, the
advent of cheaper nodes and better development tools will bring new applications
with new requirements, and the mobility of the nodes will surely play an important
role. While partial mobility has been considered in all the mechanisms (e.g. the
151
KMS protocols), certain mechanisms like Intrusion Detection Systems need to be
refined to support the existence of mobile nodes.
While it is important to provide security to wireless sensor networks, it is also
crucial to consider that sensor networks can be further integrated inside the pervasive computing paradigm. For example, in Personal Area Networks, sensor nodes
collaborate with other devices (e.g. RFIDs, wearable computing devices) to provide
human-centric services. These networks have their own specific security challenges
that need to be solved, such as the integration of different devices with different
capabilities, the highly dynamic nature of the network, the mobility of the human
user, and so on. Therefore, it will be necessary to develop both application-specific
mechanisms and situation-specific mechanisms, such as selecting the level of security
depending on the location of the user (e.g. home, office, urban space).
The problems are here for us to uncover, and the challenges are here for us to
solve, to bring security to the real world.
学海无涯 ...1
1
‘The sea of learning is boundless...’ (Thanks to Ainhoa for this phrase)
152
APPENDIX
A
Proof of the Spontaneous Watchdog Equation
The main purpose of equation (3.1) is to know the probability that α nodes have to
activate their global agents at the same time in a neighborhood of n possible global
agents, when the decision of a node cannot influence others. This problem can be
abstracted into another one:
We have n players (nodes) in a table, and every player has a dice with m
sides (where m is usually equal to n). We want to know the probability
of α players obtaining a “1” (i.e., activating the global agents) when all
players have thrown their dices once.
In this new problem, we want to solve:
f 0 (α, n, m)
f (α, n, m) = 00
f (α, n, m)
(A.1)
where f 0 (α, n, m) are all cases where n dices of m sides are thrown and α and only α
dices have a result of 1; f 00 (α, n, m) are all cases where n dices of m sides are thrown.
If a player throws a dice, the result can be within one of these two sets: {1} or
{2..m}. The number of possible cases where α and only α dices fall in the {1} set is
the number of permutations with repetition 1 of n elements (dices) where the value
that α elements fall into the {1} set and n − α elements fall into the {2..m} set is
n!
(A.2)
n − α! · α!
With (A.2), we have obtained the number of cases where α and only α dices fall
in the {1} set. For example, if we have n = 2 dices with m = 3 sides each, the
P Rnn−α,α =
1
We use permutations here because the order of the dices is important, since every dice (node
probability) is different and independent from the others.
153
154
number of cases where one and only one dice (α = 1) falls in the {1} set are equal
to 2, i.e., {(1,[2..3]), ([2..3],1)}.
For every case in the previous example, we have n−α dices that fall in the {2..m}
set, with m − 1 elements inside. Therefore, it is possible to know the number of cases
where α and only α dices have a result of 1, or f 0 (α, n, m), if we multiply (A.2) with
(m − 1)n−α :
f 0 (α, n, m) = P Rnn−α,α · (m − 1)n−α
(A.3)
because (m − 1)n−α are the ordered variations of m − 1 elements taken n − α times
with repetition. In the previous example (n = 2, m = 3, α = 1), the number of cases
where one and only one dice has a result of 1 are 2 · 2 = 4, i.e., {(1,2), (1,3), (2,1),
(3,1)}.
Finally, f 00 (α, n, m), or all cases where n dices of m sides are thrown, is the
r-permutations with repetition of m elements taken n times:
f 00 (α, n, m) = V Rm,n = mn
(A.4)
We can conclude that both (3.1) and (A.1) are equal, and both solve the same
problem.
APPENDIX
B
Resumen de la Tesis en Español
B.1
Introducción
Las redes inalámbricas de sensores (Wireless Sensor Networks [41]) se comportan
como los sentidos ‘digitales’ de un sistema computacional, obteniendo y procesando
información a través de sus ‘células nerviosas’: los nodos sensores. Cualquier sistema
computacional puede beneficiarse de este flujo de información para poder interactuar
con el mundo real, creando ası́ una nueva dimensión donde lo inanimado y lo animado
cooperan en nuevas e interesantes aplicaciones. Sin embargo, es esencial introducir
la seguridad dentro de las redes de sensores. Sin seguridad, los cimientos de esta
nueva dimensión serı́an frágiles como el cristal, y cualquier problema lo destrozarı́a
en pedazos, afectando posiblemente tanto al mundo lógico como al mundo real.
La comunidad cientı́fica ha reconocido la importancia de proporcionar seguridad
a las redes de sensores, y existen multitud de soluciones que tratan de proteger estas
redes desde el hardware a los protocolos de la red. Sin embargo, existe un factor
que no ha sido considerado en la mayorı́a de los desarrollos de los mecanismos de
seguridad: la influencia de la naturaleza de las aplicaciones y del contexto donde éstas
se ejecutan. Es más, todos los aspectos de una red de sensores (su arquitectura de red,
sus protocolos, su funcionalidad) son altamente dependientes de los requerimientos
de la aplicación y su contexto.
En esta tesis, hemos considerado la influencia de las aplicaciones y su contexto en
el desarrollo de un “conjunto integral” de mecanismos de seguridad. Este “conjunto
integral”, el cual deberı́a estar localizado en una capa transversal dentro de la arquitectura de las redes de sensores, puede definirse como el conjunto de mecanismos
de seguridad dependientes de la aplicación y su contexto que son necesarios para
imponer de una forma mı́nima las propiedades de seguridad que una red de sensores
deberı́a tener.
Este resumen en Español se organiza de la siguiente forma: en la sección B.2,
155
156
Red de Diseminación de Datos
Red de Adquisición de Datos
Estación Base
Nodos Sensores
Figure B.1: Estructura de una red de sensores
se explica el concepto de las redes de sensores y los problemas de seguridad asociados. En la sección B.3, se introducen los objetivos y resultados de la tesis. En las
siguientes secciones se desarrollan las propuestas realizadas en esta tesis: análisis de
primitivas de seguridad en la sección B.4, estudio del soporte ofrecido por mecanismos de administración de claves en la sección B.5, soporte para la existencia de
mecanismos basados en clave pública en la sección B.6, desarrollo de mecanismos de
autoinspección en la sección B.7, exposición de un sistema de detección de intrusiones
en la sección B.8, especificación de sistemas de confianza en redes de sensores en la
sección B.9, aplicación de la seguridad a un middleware seguro en la sección B.10, e
integración de las redes de sensores en Internet en la sección B.11. Finalmente, las
conclusiones se muestran en la sección B.12.
B.2
B.2.1
Redes de Sensores y seguridad
Redes de Sensores
Definición y propiedades. La estructura de una red de sensores puede observarse
en la figura B.1. En ella, una serie de dispositivos, los nodos sensores, se encargan de
recoger y almacenar la información del entorno. Utilizando sus limitadas capacidades
computacionales, la información se preprocesa para luego ser enviada a los nodos
vecinos a través de un canal de comunicaciones inalámbrico. Normalmente, toda la
información recogida se envı́a hacia la estación base, la cual suele servir de interfaz
entre los servicios de la red de sensores (red de adquisición de datos) y sus usuarios
(red de diseminación de datos). En cierta forma, una red de sensores puede ser
abstraı́da a un cuerpo vivo, en el que ciertas “células” (los nodos sensores) colaboran
entre sı́ para ofrecer una información del mundo fı́sico y enviarla al “cerebro”, la
estación base.
La estructura de la red de sensores puede ser puramente distribuida, de tal forma
157
que todos los nodos participan en los procesos de toma de decisiones y en los protocolos internos, como por ejemplo, el encaminamiento. Por otro lado, la red puede
funcionar de forma jerárquica, con agrupación de nodos en clusters. Dentro de esos
clusters, uno de los nodos, el lı́der del cluster, participa realmente en los procesos
y protocolos internos de la red, mientras que los demás nodos funcionan de forma
pasiva proporcionando únicamente información sobre el entorno. También es posible
combinar las estructuras jerárquica y distribuida de tal forma que la red pueda seguir
funcionando aún cuando parte de su espina dorsal (es decir, el conjunto de lı́deres de
clúster) deje de estar operativa.
La información que fluye por la red de sensores suele regirse por el tipo de comunicación muchos-a-uno, en la que todos los sensores envı́an sus lecturas a la estación
base. No obstante, también es frecuente el tipo uno-a-muchos en caso de que la
estación base envı́e información de control a un subconjunto de los sensores o a un
clúster. Finalmente, la comunicación uno-a-uno no suele prodigarse, aunque sı́ existe
la comunicación entre vecinos directos para poder resolver un problema de forma distribuida. En casos excepcionales, la estación base puede requerir una comunicación
con un nodo especı́fico de la red.
Con respecto a las funcionalidades de la red de sensores, la red puede monitorizar
de forma continuada una caracterı́stica fı́sica del entorno, como el nivel de ruido, o
bien puede detectar circunstancias especiales, como por ejemplo, un incendio forestal, y alertar al usuario. La red también puede funcionar como una base de datos
distribuida, proporcionando información al usuario cuando éste lo requiera, e incluso
puede influir sobre el funcionamiento de un sistema externo, como un sistema de
irrigación, modificando su comportamiento, según el contexto, si fuera necesario.
Aparte de sus capacidades de adquisición de información, estas redes poseen otras
caracterı́sticas singulares. Por ejemplo, debido a su autonomı́a, la red puede operar
sin la presencia de un operario humano, e incluso puede funcionar en situaciones en
las que no exista un sistema de control centralizado. Además, puede autoconfigurarse
para reaccionar ante situaciones adversas del entorno, siendo robusta ante problemas internos que puedan afectar a su funcionamiento general. Precisamente esta
capacidad de autoconfiguración permite que la red pueda ser instalada fácilmente,
activando sus elementos y dejando que éstos reconozcan su entorno. Respecto a la
vida útil, una red de sensores puede optimizarse para funcionar durante largos periodos de tiempo (desde varios dı́as a años). Finalmente, la inteligencia embebida
de la red le permite muchas tareas, desde el preprocesamiento de los datos (p. ej.
agregar datos redundantes) hasta la propia reprogramación de los nodos a distancia. Todas estas caracterı́sticas singulares diferencian a las redes de sensores de otros
paradigmas, como las redes ad hoc.
Por consiguiente, existe una gran multitud de escenarios que podrı́an beneficiarse
de los servicios y caracterı́sticas especiales que poseen las redes de sensores. Algunos
de los que despiertan más interés son, por ejemplo: infraestructuras crı́ticas, reacción
158
en zonas catastróficas, control de medio ambiente y análisis de la biodiversidad, edificios y entornos inteligentes, mantenimiento de maquinaria, agricultura de precisión,
cuidados médicos intensivos y de la tercera edad, logı́stica, etc.
Clase I
Clase II
Clase III
Velocidad
4 Mhz
4-8 Mhz
13-180 Mhz
RAM
64-512 B
4-10 kB
256-512 kB
ROM
1-4 kB
48-128 kB
4-32 MB
Table B.1: Clases de nodos sensores
Capacidades. Dado que los nodos sensores cumplen una función muy especı́fica,
su estructura interna también lo es. Los tres componentes principales de un nodo
sensor son: microcontrolador, placa sensorial, y transmisor/receptor. Las distintas
caracterı́sticas de los nodos sensores en materia de velocidad, tamaño de memoria
RAM, tamaño de memoria ROM, y energı́a, se encuentran detallados en la tabla B.1.
Los nodos sensores más comunes, como MICAZ y TelosB [85], que pueden realizar tareas tanto de colección de información como de procesamiento distribuido y
autoconfiguración, se encuadran dentro de la clase II. A pesar de que este tipo de
nodos posee unas capacidades bastante restringidas, existen nodos con capacidades
aún más restringidas, los de la clase I, que básicamente funcionan como dispositivos
pasivos que únicamente envı́an la información obtenida de sus sensores. Por el contrario, los nodos de clase III, son mucho más potentes que el resto, y suelen utilizarse
como lı́deres de cluster o como estaciones base móviles.
Respecto a la capacidad de sus transceptores, la mayorı́a de los nodos sensores
utiliza el estándar IEEE 802.15.4 para redes de área personal inalámbricas. Esta
especificación funciona en unas frecuencias muy variadas. Concretamente, 2.4 GHz,
915 MHz y 868 MHz, transmitiendo a 250 Kbps, 40 Kbps y 20 Kbps, respectivamente. Hay que hacer notar que el consumo energético del envı́o de información es
mucho mayor que el del procesamiento de datos en el microcontrolador, por lo que
se aconseja maximizar el procesamiento de los datos dentro del nodo.
B.2.2
Seguridad en Redes de Sensores
Ataques en el contexto de las redes de sensores. Como en cualquier otro
sistema de comunicaciones, dentro de una red de sensores es necesario garantizar
la correcta funcionalidad de todos sus componentes para que la red pueda prestar
sus servicios de una forma adecuada. Esto incluye el desempeño de una serie de
propiedades de seguridad que se derivan de los requisitos del contexto de la aplicación: confidencialidad de la información, integridad de la comunicación y del funcionamiento general de la red, autenticación de los componentes, disponibilidad,
capacidad de autoorganización, frescura de los datos, etc.
159
Sin embargo, alcanzar estos objetivos no es tarea fácil porque, debido a sus caracterı́sticas particulares, una red de sensores es especialmente vulnerable a ataques
internos y externos[259, 263]. Como se vio con anterioridad, los nodos de la red tienen
unas capacidades limitadas, lo que impide implementar de forma trivial mecanismos
de seguridad. Además, estos nodos pueden ser fı́sicamente accesibles de manera fácil
por cualquier adversario debido a que deben estar colocados cerca de los eventos
que deben monitorizar. Más aún, el canal de comunicaciones inalámbrico no está
protegido, por lo que resulta fácil para el atacante acceder y manipular el flujo de
información. Como resultado, las redes de sensores pueden verse afectadas por los
siguientes tipos de amenazas:
• Ataques al flujo de información:
– Eavesdropping, replay, manipulación de la información.
• Denegación de servicio:
– Colaboración, bloqueo de señal, agotamiento de baterı́a.
• Compromiso de un nodo:
• Suplantación de identidad:
– Múltiples identidades (sybil), replicación de identidad.
• Ataques especı́ficos a protocolos:
– Selective forwarding, wormhole attack, sinkhole attack, spoofed routing,
acknowledgement spoofing.
Primitivas, mecanismos y servicios de seguridad. Dada la vulnerabilidad
ante esta multitud de ataques, tanto internos como externos, es muy conveniente
desarrollar diversas medidas de protección que puedan evitar o suavizar los efectos
de dichos ataques. Por lo tanto, es indispensable proporcionar a los nodos sensores determinadas primitivas básicas (criptosistemas simétricos, los criptosistemas
asimétricos, y las funciones hash) para ası́ proteger el flujo de información y asentar las bases de protocolos seguros. Además, dado que las primitivas de seguridad
conllevan por lo general el uso de credenciales (p. ej. claves secretas) para poder
funcionar adecuadamente, también son necesarios procedimientos y sistemas eficaces
para la administración y gestión de tales credenciales.
Estos mecanismos de seguridad subyacentes son determinantes para defender la
red de posibles ataques, pero no son suficientes para protegerla frente a ataques
internos. Como resultado, los protocolos esenciales de una red de sensores (encaminamiento, agregación, sincronización temporal) deben ser lo suficientemente robustos
para soportar comportamientos maliciosos y fallos en la red. Otros protocolos como
160
Confidencialidad
Integridad
Atestación
Detección de Intrusos
Protocolos de Agregación
Autenticación
Autorización
Administración de Claves
Confianza
Autoinspección
Protocolos de Encaminamiento
Figure B.2: “Conjunto Integral” de mecanismos de seguridad
el agrupamiento dinámico (o clustering) y los algoritmos de localización también
requieren un elevado grado de seguridad.
Existen otros mecanismos de seguridad que deben ser tenidos en cuenta. Por
ejemplo, un nodo sensor debe ser capaz de descubrir situaciones anormales que
puedan estar ocurriendo a su alrededor. Además de para posibilitar la autoconfiguración, esta capacidad de autoinspección puede ser utilizada para crear servicios
de seguridad más complejos, como la detección de intrusiones o sistemas de manejo
de confianza. Finalmente, deberı́an también considerarse otros diversos aspectos
como la gestión segura de nodos y estaciones base móviles, delegación de tareas,
privacidad, creación de agentes seguros, programación remota segura, generación de
números aleatorios, administración de confianza, etc.
B.3
B.3.1
Objetivos y resultados de la tesis
Objetivos de la tesis
A pesar de los últimos avances en el campo de la seguridad en las redes de sensores,
existe todavı́a una clara separación entre las soluciones de seguridad y los requisitos
de las aplicaciones que se ejecutan dentro de esa red. Más concretamente, en la
mayorı́a de las ocasiones, cuando se afronta el diseño de una solución de seguridad
para una red de sensores, ésta se diseña sin tener en cuenta el contexto en el que tal
solución se usará.
Sin embargo, como hemos visto, las redes de sensores no son sistemas de propósito
general, sino que proporcionan una funcionalidad especı́fica utilizando dispositivos
cuyos recursos están altamente restringidos. Por lo tanto, y como parte esencial
en la selección y desarrollo de cualquier mecanismo de seguridad, es absolutamente
necesario, a nuestro parecer, considerar especialmente y con detalle las caracterı́sticas
de las aplicaciones, ası́ como los requisitos particulares de cada una de ellas.
Nuestra contribución consiste en la definición y desarrollo de lo que consideramos
como un “conjunto integral” de servicios de seguridad, mostrado en la figura B.2. Es
decir, unos servicios dependientes de la aplicación y su contexto que, utilizados de
una forma completa y correcta, evitarı́an los ataques a una red de sensores explicados
anteriormente, imponiendo de forma mı́nima las propiedades de seguridad que una
161
red de sensores deberı́a tener.
De esta forma, para que la red funcione adecuadamente desde la perspectiva de
seguridad, es necesario crear servicios de confidencialidad, integridad, autenticación,
y autorización, los cuales ofrecen el soporte necesario para los protocolos básicos de
la red, como por ejemplo, el encaminamiento. Tales servicios deben fundamentarse
en determinados algoritmos criptográficos a los que se les suministran las claves
necesarias a través del sistema de administración de claves.
Por otro lado, los protocolos básicos de la red necesitan otros servicios que refuercen sus propios mecanismos de protección frente a ataques externos y/o internos,
como por ejemplo servicios avanzados de detección y decisión: detección de intrusiones y mecanismos de confianza (trust). Otros refuerzos pueden provenir de un
servicio de autoinspección (self-awareness), que analiza el funcionamiento del nodo y
sus vecinos para reaccionar ante situaciones atı́picas que pueden darse en el contexto
de la aplicación.
De esta forma, los protocolos de la red pueden contar con mecanismos avanzados
para facilitar su funcionamiento seguro. Por ejemplo, un servicio de autenticación
puede llamar a un mecanismo de atestación de código (comprobación de la correctitud
del código de un nodo vecino) en base a las salidas del sistema detector de intrusiones.
Con respecto a la localización de este “conjunto integral” de servicios de seguridad dentro de la arquitectura de un nodo sensor, nuestra propuesta es distinguir la
seguridad como una capa transversal que proporcionará tanto servicios como información especı́fica a las demás capas de la arquitectura, con independencia de cuál
sea esa arquitectura (jerárquica o cross-layer). Los servicios de seguridad se localizan
dentro de esta capa transversal y pueden interactuar tanto entre ellos como con el
resto de capas de la arquitectura mediante interfaces bien definidas.
B.3.2
Resultados de la tesis
Las principales contribuciones de esta tesis al área de la seguridad en las redes de
sensores se detallan a continuación:
• Hemos definido un “conjunto integral” de mecanismos de seguridad, y los hemos
localizado dentro de una capa transversal en la arquitectura de un nodo sensor
(sección B.3 del resumen, sección 1.3 de la tesis).
• Hemos descrito el estado del arte actual en primitivas criptográficas para redes
de sensores, y revisado la idoneidad de éstas primitivas para las diferentes clases
de nodos sensores (sección B.4 del resumen, sección 2.1 de la tesis).
• Hemos analizado la relación entre los requerimientos de las aplicaciones y las
propiedades de un sistema de administración de claves (KMS). También hemos
desarrollado una metodologı́a que permite distinguir cuál protocolo KMS es
más idoneo para el contexto en el que una red de sensores va a funcionar
(sección B.5.1 del resumen, secciones 2.2.2 y 2.2.3 de la tesis).
162
• Hemos comprobado si el estado del arte en protocolos KMS ofrece una solución
viable al problema del establecimiento de claves en redes de sensores, y hemos
determinado en qué áreas deberı́a enfocar sus esfuerzos la comunidad cientı́fica
dentro de este campo (sección B.5.2 del resumen, sección 2.2.4 de la tesis).
• Hemos mostrado como la criptografı́a de clave pública puede ser utilizada dentro de una red de sensores, y hemos proporcionado soporte para una infraestructura de clave pública (PKI). Además, hemos mostrado como otros paradigmas
de clave pública como la criptografı́a basada en identidad puede ser utilizada
en entornos especı́ficos como las redes de sensores subacuáticas (sección B.6 del
resumen, sección 2.3 de la tesis).
• Hemos desarrollado mecanismos de conocimiento del entorno, los cuales permiten la capacidad de autoinspección: detectar la presencia de eventos anómalos
basada en la existencia de efectos colaterales. Además, mostramos como la aplicación y su contexto influyen sobre estos mecanismos (sección B.7 del resumen,
sección 3.2 de la tesis).
• Hemos desarrollado un sistema de detección de intrusiones para redes de sensores que cumple todas las siguientes propiedades: cobertura total, simplicidad,
y adaptabilidad (sección B.8 del resumen, sección 3.3 de la tesis).
• Hemos analizado como las caracterı́sticas especiales de una red de sensores
influyen sobre la definición de mecanismos de manejo de confianza (sección B.9
del resumen, sección 3.4 de la tesis).
• Hemos mostrado como el concepto de un “conjunto integral” ha sido aplicado
a una arquitectura real de middleware para redes de sensores (sección B.10 del
resumen, sección 4.1 de la tesis).
• Hemos analizado las interacciones seguras entre las redes de sensores e Internet,
mostrando como dependen de la aplicación. Finalmente, describimos trabajos
a realizar en este área (sección B.11 del resumen, sección 4.2 de la tesis).
B.4
Soporte para primitivas criptográficas
Para poder desarrollar mecanismos y protocolos de seguridad en una red de sensores,
es necesario utilizar los elementos criptográficos más básicos. Estos elementos son
las primitivas de Criptografı́a de Clave Simétrica (SKC), de funciones hash, y de
Criptografı́a de Clave Pública (PKC). Estas primitivas aseguran confidencialidad e
integridad en el canal (evitar que individuos sin permiso puedan realizar lecturas y/o
alteraciones en los paquetes), y autentificación de ambas partes de la comunicación.
No obstante, dado que los nodos sensores disponen de capacidades computacionales
muy limitadas, es necesario realizar un análisis para comprobar que las primitivas
163
criptográficas pueden ser soportadas por los diversos dispositivos utilizados en una
red de sensores [249, 251, 261].
B.4.1
Implementaciones software y hardware
Software. El análisis del estado del arte para comprobar si existe sobrecarga en
la ejecución de primitivas de clave simétrica y hash en microcontroladores ha demostrado la capacidad de los nodos sensores de ejecutar estas primitivas. Ganesan
et. al. [53]. demostraron que cifrar un texto plano de 1 byte con RC5 requerı́a un
tiempo de 26µs, con IDEA 21µs y con RC4 6µs. También, analizaron que a pesar
de que la función hash SHA-1 necesitaba 7777µs para comprimir 64 bytes, el espacio
reservado de memoria no superaba los 4000 bytes. Otros resultados realizados por
Wei Law et. al. [74] y Jun Choi and Song [58] mostraron que tanto Twofish como
AES alcanzan un tiempo de cifrado medio de 50µs, y Skipjack (optimizado) necesita
25µs. Con respecto al tamaño medio de memoria de instrucciones (ROM), RC4 es
el algoritmo más optimizado al reservar tan sólo 428 bytes. En cambio, Skipjack
necesita de 2600 bytes de ROM, y el resto de algoritmos alrededor de 8000 bytes. El
consumo de RAM de todos los algoritmos es muy bajo, casi nunca superando los 100
bytes.
Respecto a las primitivas de clave asimétrica, el trabajo en el área de la criptografı́a de curvas elı́pticas (ECC) de autores como Malan et. al. [102], Liu y Ning
[62], y Wang y Li [73], han demostrado que la criptografı́a de clave pública es posible
en el contexto de una red de sensores. Por ejemplo, para firmar un dato se necesitan
entre 1.3 y 1.9 segundos, y para verificar un dato se necesitan entre 2 y 2.4 segundos.
El programa que permita realizar la firma necesita de aproximadamente 25kB de
memoria ROM y 1.6kB de memoria RAM. Además, gracias a la naturaleza orientada a componentes de los sistemas operativos de nodos sensores, pudimos mejorar
el espacio ocupado en memoria de una de las implementaciones [73] en la plataforma
TelosB [85].
Hardware. En el ámbito de la criptografı́a simétrica, los nodos sensores que utilizan el estándar de comunicaciones IEEE 802.15.4 [57] tienen un soporte hardware
para la ejecución del estándar AES-128. Estas implementaciones hardware se caracterizan por ser rápidas en sus operaciones, por ejemplo, el transceptor CC2420
consigue cifrar un mensaje en 222µs con AES-CCM y en 14µs con un modo más
simple. No obstante, existen algunos modos del estándar que no deben ser utilizados
[68], y algunas implementaciones hardware especı́ficas tienen problemas (p. ej. las
lista de control de acceso del transceptor CC2420 sólo tiene dos entradas, permitiendo
únicamente dos vecinos seguros por nodo). Por otro lado, aquellos nodos sensores
que posean soporte para ejecutar instrucciones MMX (aquellos con el microcontrolador PXA27X de Intel), pueden tratar de conseguir paralelismos en el procesamiento
software de determinadas primitivas como AES, Twofish y SHA.
164
En el ámbito de la criptografı́a asimétrica, existen varios prototipos hardware,
pero sin ser integrados dentro de un nodo sensor. La mejor implementación de curvas
elı́pticas (ECC) [48] opera a 500kHz, con 8104 puertas bajo 0.13µm en tecnologı́a
CMOS, computando una operación de multiplicación de punto (la operación base de
las curvas elı́pticas) sobre F2131 en 115ms, y consumiendo menos de 30µW. Existen
otras implementaciones de otros algoritmos de criptografı́a de clave pública, entre
los que podemos destacar Rabin. Esta implementación cifra y verifica la firma de
mensajes en 2.88ms y consumiendo una media de 148.18µW.
B.4.2
Primitivas criptograficas en Redes de Sensores
Para analizar si las implementaciones software de las primitivas de seguridad son
adecuadas para los dispositivos de una red de sensores, es necesario evaluar su coste
computacional y su consumo de memoria. Para no retrasar el envı́o de paquetes,
es necesario que el tiempo que tarda una primitiva en ejecutarse sea menor que el
tiempo que tarda el transceptor en enviar datos (420µs para 19.2kbps, 32µs para
250kbps). Respecto a las primitivas de clave simétrica, éstas suelen ejecutarse en
menos de 33µs, pero las funciones hash son más lentas, procesando un byte en unos
122µs. No obstante, las redes de sensores no suelen utilizar todo el ancho de banda,
por lo que las primitivas de seguridad no retrasarán las comunicaciones.
Respecto al uso de memoria, un prototipo de un aplicación básica que disponga de
todas las primitivas criptográficas ocupa unos 34kB1 de memoria ROM. Un nodo de
clase I (1kB RAM, 16kB ROM) solo puede soportar el uso de criptografı́a simétrica
y funciones hash, mientras que los nodos de clase II (4-8kB RAM, 48-128kB ROM)
y clase III (256kB RAM, 4MB ROM) pueden incluir todas las primitivas, aunque
serı́a interesante aumentar la memoria disponible en futuros modelos de la clase
II. También serı́a importante el desarrollar nuevos algoritmos (p. ej. funciones de
cifrado en flujo como las obtenidas del proyecto ECRYPT Stream Cipher [82]) que
estuvieran adaptados a este tipo de dispositivos.
Como resultado, consideramos que a fecha de la realización de esta tesis es posible utilizar cualquier tipo de primitiva criptográfica en redes de sensores, aunque
serı́a importante desarrollar soporte hardware para nodos de clase I y clase II. Este
soporte hardware ha sido desarrollado principalmente en forma de prototipos, pero
es necesario que estos prototipos puedan ser incluidos dentro del diseño de los nodos
sensores o en forma de extensiones criptográficas. Además, algunas de las caracterı́sticas de los prototipos hardware existentes pueden mejorarse. Por ejemplo, la
seguridad del mejor prototipo de ECC se basa en el parámetro F2131 , cuando serı́a
mejor utilizar el parámetro F2163 o mayor.
No obstante, es posible aprovechar los recursos existentes para implementar una
solución hı́brida en la que la implementación software se beneficie de los recursos
1
AES-128 consume 8kB, y ECC consume 26kB - incluyendo código de ejemplo y la función hash
SHA-1 primitive (2kB).
165
hardware del nodo. Por ejemplo, si un nodo sensor esta equipado con un chip basado
en el estándar IEEE 802.15.4, es posible utilizar el modo más simple de la primitiva AES-128 para implementar diversos modos de cifrado y / o integridad, como
el CBC-MAC. Además, es posible aprovechar las instrucciones MMX en aquellos
microcontroladores que dispongan de ellas.
B.5
Sistemas de administración de claves en Redes de Sensores
Como es sabido, los mecanismos de seguridad para redes de sensores basan su funcionamiento en la existencia y uso de credenciales en general, y claves (simétricas
y/o asimétricas) en particular, con las que los nodos de una red de sensores pueden
proteger de una u otra forma los flujos de información. Las claves han de ser distribuidas segura y eficientemente a los nodos involucrados en la comunicación de tal
forma que sólo ellos sean capaces de, por ejemplo, leer el contenido de los paquetes
de información transmitidos.
Para lograr ese objetivo es esencial contar con un sistema de administración de
claves (Key Management System, KMS), y de los protocolos asociados (protocolos
KMS), que den soporte a la administración de las mismas para cada dispositivo, tarea
ésta que no es trivial en ninguna red de comunicaciones, y menos aún en una red de
sensores [117]. Precisamente, y debido a esas dificultades, una de las aportaciones
de esta investigación es crear una metodologı́a base que ayude al usuario final de la
red de sensores (como, por ejemplo, el diseñador de la red en unas ocasiones o el
administrador de la misma en otras) a encontrar el o los protocolos de KMS que más
se adecuen a sus necesidades [256]. La especificación de la metodologı́a tiene tres
objetivos claros:
1. Facilitar la provisión de seguridad a la implantación de cualquier aplicación de
redes de sensores del mundo real. La razón es que proporciona a los usuarios un
catálogo simple y directo para puedan incluir fácilmente un soporte de administración de claves en cualquier red de sensores. El usuario podrá distinguir en
cualquier situación qué protocolo es el más adecuado para el contexto en el que
la red se va a implantar. El catálogo es fácil de actualizar, de tal forma que los
usuarios puedan beneficiarse de nuevos protocolos diseñados por la comunidad
de seguridad.
2. Comprobar cuáles son las soluciones que el estado de la investigación de KMS
puede ofrecer a las aplicaciones existentes en redes de sensores. Agrupando las
aplicaciones existentes en escenarios, de tal forma que las aplicaciones dentro
de cada grupo compartan requisitos comunes, es posible aplicar la metodologı́a
para descubrir cuáles de los KMS son más adecuados para cada escenario y
para las aplicaciones que forman parte de ese grupo.
166
3. Determinar los nichos de aplicaciones del mundo real donde resulte más conveniente focalizar el esfuerzo de investigación para crear nuevos protocolos de
KMS. Es decir, uno de los resultados de la metodologı́a es el mapeo de los protocolos actualmente existentes en la literatura con respecto a las aplicaciones
o grupos de aplicaciones existentes. Ese mapeo ayudará a identificar en qué
escenarios es necesario concentrar la investigación pues pondrá de manifiesto
en cuáles de ellos o bien no existen soluciones hasta el momento, o bien las
existentes no cubren adecuadamente los requisitos.
B.5.1
Desarrollo de una metodologı́a de selección
Nuestro primer paso para el desarrollo de la metodologı́a ha consistido en establecer
una taxonomı́a de los protocolos KMS en cuatro bloques principales: Key Pool,
basados en operaciones matemáticas, basados en procesos de negociación y basados
en clave pública, que se diferencian entre sı́ por el tipo de mecanismo interno con
los que han sido diseñados. La elaboración de esta taxonomı́a nos ha permitido
comprender las razones por las cuales cada protocolo, incluso dentro de un mismo
bloque, provee propiedades especı́ficas.
Propiedad
Descripción
Memoria [Mem]
Memoria ROM y RAM consumida por el protocolo
Comunicación [Comm]
Número de mensajes intercambiados entre los nodos
Velocidad de procesamiento [Sp] Coste Computacional invertido en la ejecución del protocolo KMS
Protección en Despliegue [Sec]
Protección de las de claves durante el proceso de despliegue
Resistencia [Res]
Resistencia contra credenciales de seguridad robadas
Global [GConn]
Existencia de un camino de claves entre cualquier nodo
Conectividad Local [LConn]
Existencia de una clave compartida entre dos nodos vecinos
Nodal [NConn]
Existencia de una clave compartida entre cualquier nodo
Escalabilidad [Sca]
Capacidad para soportar redes grandes
Extensibilidad [Ext]
Capacidad de incluir nuevos nodos
Energı́a [En]
Coste energético invertido en las tareas de red y de computación
Table B.2: Propiedades relevantes de un protocolo KMS
Como segundo paso, es necesario analizar las propiedades de los protocolos KMS,
descubriendo la relación entre estas propiedades y los requisitos de la aplicación. Para
ello, no sólo se realizó un análisis de propiedades ya definidas en la literatura, sino
también la definición de nuevas propiedades. Ası́, hacemos una clasificación original
de nueve propiedades básicas de protocolos, siendo una de ellas desglosada en otras
tres dado que consideramos otros tantos aspectos diferentes dentro de esa misma
propiedad. Estas propiedades son descritas de forma resumida en la tabla B.2.
Finalmente, es posible proceder a la elaboración de un catálogo (KMS Table) que
ponga de manifiesto las caracterı́sticas especı́ficas de los diversos protocolos KMS. El
catálogo enumera las ventajas y desventajas de cada protocolo, si la presencia de una
propiedad depende de los criterios de diseño del protocolo, y si el protocolo necesita
167
de información adicional para su funcionamiento. Este catálogo (ver sección 2.2.5
de la memoria de la tesis), el cual puede ser suplementado con nuevos protocolos
e incluso con nuevas propiedades, se utiliza como base para la especificación de la
metodologı́a (detallada en la sección 2.2.3 de la memoria de la tesis) que nos permitirá
obtener el o los protocolos KMS que más se adecuen a las necesidades de un usuario.
B.5.2
Resultados del análisis
Tras agrupar las aplicaciones existentes en escenarios, de tal forma que las aplicaciones dentro de cada grupo compartan requisitos comunes, se pueden analizar esos
grupos utilizando la metodologı́a. Tras ese análisis, puede concluirse que el estado
de la investigación actual en KMS es adecuado para casi la mayorı́a de escenarios
estáticos si sólo se consideran aquellos aspectos relacionados con la movilidad y el
tamaño de la red. Ası́, es posible proteger adecuadamente redes de un salto, redes
simples de tamaño pequeño, mediano y grande, ası́ como redes con estaciones base
móviles.
Es importante hacer notar que la ejecución de la metodologı́a ha dejado patente
la existencia de escenarios en los que es necesario desarrollar nuevos protocolos de
administración de claves. Uno de estos escenarios son las redes donde los nodos
son móviles, y especialmente aquellas redes en las que las claves deban negociarse
rápidamente. Otros escenarios incluyen aquellas redes cuyo coste de comunicación
debe ser mı́nimo pero que necesitan ser extensibles, y redes simples de gran tamaño
en las que la conectividad global tiene que ser completa ya que ningún nodo deberı́a
estar desconectado de la red.
Con respecto al diseño de nuevos protocolos, es interesante nombrar algunas
propiedades a las que debe darse más importancia, tales como la resistencia y la
extensibilidad. Ambas están contempladas por casi la mayorı́a de protocolos que
funcionan sobre redes pequeñas, pero no sobre redes grandes, con lo cual se hace
indispensable desarrollar soluciones para estos tipos de escenarios. Por otro lado,
aunque los protocolos basados en clave pública ofrecen algunos servicios muy interesantes como la firma digital o la autorización, pueden ser demasiados complejos para
determinadas redes muy especı́ficas (p. ej. redes en las que las claves deben negociarse casi instantáneamente) en las que serı́a conveniente utilizar sólo criptografı́a de
clave simétrica.
B.6
Administración de claves con clave pública
En esta tesis hemos mostrado como el estado del arte en implementaciones tanto
software como hardware de curvas elı́pticas (ECC) permite que la criptografı́a de
clave pública en redes de sensores sea una realidad. Esto permite la creación de
sistemas de administración de claves con unas propiedades excelentes (escalabilidad,
168
conectividad, resistencia, protección en despliegue, comunicación), aunque con ciertas desventajas que no permiten su uso en escenarios muy especı́ficos (memoria,
energı́a, velocidad de procesamiento) Sin embargo, para que estos mecanismos criptográficos puedan ser utilizados a través de certificados, es necesaria la presencia de
una infraestructura de clave pública (PKI). Este ha sido nuestro objetivo [255], junto
con probar como otros paradigmas de clave pública como la criptografı́a basada en
identidades (identity-based cryptography) son también útiles en una red de sensores
[250].
B.6.1
Especificación de una infraestructura de clave pública
Para especificar una infraestructura de clave pública en redes de sensores, nos basamos
en el modelo PKIX [143]. Dentro de este modelo, existen las siguientes entidades:
los clientes, que son los usuarios de la PKI, la autoridad de certificación (CA), que
genera los certificados, la autoridad de registro (RA), que es responsable del registro
y la autenticación inicial de los clientes, y el repositorio, que almacena los certificados
y las listas de revocación de certificados (CRL).
En una red de sensores, la arquitectura de la PKI será jerárquica simple, en la
que sólo existe una autoridad de certificación. Precisamente, la estación base hace el
papel de autoridad de certificación y autoridad de registro. Esto es ası́ porque es la
estación base quién se encarga de asignar las identidades a los nodos y de prepararlos
antes de su distribución. Respecto al repositorio, los propios nodos sensores serán
quienes almacenen tanto sus propios certificados como el de la CA.
El formato del certificado está basado en el estándar X509v3. Para redes de
sensores simples, en los que los nodos sensores únicamente se relacionan entre ellos y
con la estación base, es posible simplificar el formato del certificado a los siguientes
campos:
• Periodo de Validez. Indica en qué periodo de tiempo el certificado es válido.
En redes de sensores, este campo puede simplemente ser un valor numérico
único para cada distribución de la red (p. ej. 0x00000000A para el control
de ruidos en Málaga en invierno, y 0x00000000B para el control de ruidos en
Málaga en verano).
• Nombre. Identifica a un nodo sensor. Debe contener el identificador del nodo
sensor.
• Clave pública. Contiene la clave pública del nodo sensor.
• Firma del certificado. Contiene una firma digital de la CA certificando de la
validez de la clave pública contenida en este certificado. Como se supone que
un nodo sensor tiene soporte para únicamente un tipo de algoritmo de firma
(p. ej. SHA-1/ECDSA), no es necesario indicar explı́citamente cual es este
tipo de algoritmo.
169
Otras funciones de una PKI son la recuperación de claves, la actualización de
claves, certificados cruzados, y la revocación de claves. Como la estación base generó
los certificados de los nodos, es posible utilizarla para recuperar claves perdidas. La
actualización de claves simplemente puede realizarse mediante un operario humano
o a distancia. La revocación de claves sigue un modelo “push”, puesto que es la
estación base quien avisa a los nodos de la revocación de un certificado. Finalmente,
la certificación cruzada no es necesaria, ya que ni estaciones base extra ni los lı́deres
de cluster necesitan de certificados raı́z propios.
B.6.2
Otros paradigmas de clave pública
Puesto que en una red de sensores existe una tercera parte confiable que genera
las claves secretas de los usuarios, serı́a posible utilizar otros paradigmas de clave
pública como los basados en identidad (identity-based cryptography) o los basados
en autocertificación (self-certified cryptography). Los mecanismos basados en identidad utilizan una primitiva criptográfica muy costosa en términos computacionales,
denominada ‘pairing’. Por otro lado, los mecanismos basados en autocertificación
no requieren de operaciones más complejas. Los gastos de un mecanismos de intercambio de claves “normal” (ECMQV), basado en identidad (SOK), y basado en
autocertificación (SC-ECMQV) se muestran en la siguiente lista.
• ECMQV. 2mexp(2) + 1exp + 2sqrt(+trans 1410 bits + recv 1410 bits)
• SOK. 1expG + 1pairing(+trans 384 bits + recv 384 bits)
• SC-ECMQV. 1mexp(3) + 1exp + 2sqrt(+trans 706 bits + recv 706 bits)
MICA2
ECMQV
SOK
SC-ECMQV
UWM2000
ECMQV
SOK
SC-ECMQV
Comp.
107.26
309.39
77.25
Comp.
107.26
309.39
77.25
Comm.
7.95
2.16
3.98
Comm.
704.98
191.99
352.99
115.21
311.55
81.23
812.24
501.38
430.24
MICAz
ECMQV
SOK
SC-ECMQV
UWM4000
ECMQV
SOK
SC-ECMQV
Comp.
107.26
309.39
77.25
Comp.
107.26
309.39
77.25
Comm.
0.61
0.166
0.306
Comm.
2291.23
623.99
1147.24
107.87
309.55
77.56
2398.49
933.38
1224.49
Table B.3: Gasto energético de un intercambio de claves autenticado (en mJ)
Una comparativa del gasto energético de cada uno de los mecanismos de intercambio de claves se muestran en la tabla B.3. Como primer resultado, puede observarse
que los mecanismos de autocertificación son mejores que ciertos mecanismos básicos
como el ECMQV. Sin embargo, el segundo resultado es uno de los más interesantes.
170
En entornos de redes de sensores subacuáticas [37], donde hay que utilizar transceptores acústicos como el UWM2000 y el UWM4000, los mecanismos basados en
identidad son mejores. Es más, debido a las caracterı́sticas especiales del medio subacuático (baja velocidad, alta tasa de fallos), es necesario enviar el menor número
de bits posible, y en este aspecto los mecanismos basados en identidad son también
óptimos.
B.7
Servicio de autoinspección
Dada la autonomı́a de procesamiento y comunicación de los nodos sensores, éstos
deben ser capaces de autoconfigurarse antes y durante el tiempo de vida de la aplicación, adaptándose a las circunstancias adversas que pudieran surgir. Sin embargo,
para conseguir esa capacidad de autoconfiguración es necesario que los nodos sensores
sean capaces de conocer su entorno; es decir, que se percaten y reconozcan determinados eventos que puedan afectar a su funcionamiento y al de la red. Ası́, los nodos
que se vean afectados por el malfuncionamiento de otro nodo vecino deben poder
detectar esa situación, e incluso reaccionar ante ella. Tal tarea ha de ser realizada
por el servicio de autoinspección.
Puesto que el objetivo de este servicio es, entre otros, el descubrimiento de eventos anómalos que afecten a una red de sensores, es conveniente, a nuestro juicio,
desarrollar un conjunto adecuado de mecanismos de conocimiento del entorno que
se fundamenten en la investigación de los efectos producidos por tales eventos. La
posibilidad existe dado que el conjunto de eventos anómalos que puede sufrir una
red de sensores, tanto ataques como malfuncionamientos, está bien documentado
(ver sección B.2.2).
B.7.1
Mecanismos de conocimiento del entorno
Relación entre eventos anormales y efectos colaterales. Para el desarrollo de
los mecanismos de conocimiento del entorno, hemos planteado la utilización del sı́mil
en el que consideramos a una red de sensores como un organismo vivo, a un nodo
sensor como una célula, y a la estación base como el cerebro del organismo. Teniendo
en cuenta este sı́mil, es posible pensar que la presencia de unos determinados sı́ntomas
(o efectos colaterales) pueden indicar la existencia de una enfermedad (o evento
anómalo). Por lo tanto, los mecanismos de conocimiento del entorno pueden detectar
eventos anómalos basándose en la existencia de sus efectos colaterales asociados.
Para realizar nuestra tarea, primero localizamos los diversos eventos anómalos
que pueden ocurrir dentro de una red de sensores, sean provocados por el malfuncionamiento de un nodo sensor, por un ataque externo, o por un ataque interno.
Una vez conocidos esos eventos, deducimos sus efectos colaterales asociados. Éstos
pueden verse en la tabla B.4, y los explicamos parcialmente a continuación.
171
Evento anómalo (“enfermedad”)
Efecto colateral (“sı́ntoma”)
Interferencia de señal
Datos no disponibles en una zona de la red
Malfuncionamiento de un nodo
Datos no disponibles en ese nodo
Manipulación de un nodo
Nodo temporalmente no disponible
Manipulación de la placa sensorial
Desviaciones, Inconsistencias
Reenvı́o de mensajes
Mensajes demasiado antiguo
Falsificación de la identificación
Nuevos vecinos, mensajes por nodo
Cambios en la densidad de paquetes
Creación de mensajes
Alteración de mensajes
Cambios en los mensajes broadcast
Transmisión de caracterı́sticas
Inconsistencias con los nodos vecinos
Ataques de Tiempo
Retrasos excesivos, desequilibrio del tráfico
Table B.4: Relación entre eventos anómalos y sus efectos colaterales
Los ataques de interferencia de señal siempre reducen el número de paquetes
recibidos de la zona afectada. Un nodo que no funcione dejará de enviar y procesar
paquetes. Además, si ese nodo vuelve a aparecer tras un periodo de tiempo significativo [49], es probable que haya sufrido una manipulación por un atacante. Las
mediciones erróneas de los nodos sensores pueden detectarse debido a fluctuaciones
anormales o valores fuera de lo común e inconsistentes con el entorno.
Respecto a la falsificación de identidad, un nodo detectará mensajes que provienen
de nuevos vecinos que anteriormente no existı́an, o detectará varios mensajes procedentes de un mismo origen si ha habido duplicación de identidades. En la creación
de mensajes, los mensajes creados aumentarán la densidad de mensajes enviados
por la red, y mensajes que envı́en alertas falsas pueden ser inconsistentes con su entorno. También es posible detectar ataques de alteración de mensajes y transmisión
de caracterı́sticas si los mensajes se envı́an en broadcast a varios destinatarios.
Respecto a ataques de tiempo (retraso de mensajes, descartar y / o ignorar mensajes), los ataques que retrasen mensajes pueden ser detectados ya que no es normal
que durante el proceso de encaminamiento un mensaje se retrase en un nodo durante
más tiempo del habitual. También, es obvio que los mensajes descartados no serán
enviados por el nodo malicioso, por lo que sus vecinos pueden detectar un desequilibrio entre en número de paquetes que entran en el nodo y el número de paquetes
que salen de ese nodo. Finalmente, respecto a los mensajes ignorados, un nodo que
descarte todos los mensajes que le llegan (blackhole attack) será fácilmente detectado
por sus vecinos.
Influencia de la aplicación. Todos estos efectos colaterales ocurren siempre que
exista un evento anómalo. Por ejemplo, cuando un nodo sensor deje de funcionar, sus
vecinos detectarán que ni envı́a ni procesa mensajes. No obstante, la forma en la que
los efectos colaterales pueden ser analizados por el servicio de autoinspección varı́a
según la aplicación utilizada en la red de sensores. Siguiendo el ejemplo anterior,
en una red de sensores en la que existan nodos móviles llevados por personas no
172
será posible considerar únicamente la inexistencia de mensajes como sı́ntoma de un
nodo defectuoso, puesto que un nodo móvil que abandone una zona de la red de
sensores podrı́a ser considerado como extinto por sus antiguos vecinos. Es necesario
considerar entonces la influencia de la arquitectura de la red y de los requisitos de la
aplicación a la hora de utilizar estos mecanismos de conocimiento del entorno.
Por ejemplo, en una red de un solo salto (p.ej. aquellas que monitoricen una
maquinaria industrial), los nodos no podrán detectar ciertos efectos colaterales debido a la falta de información (p. ej. interferencia de la señal) o a la inexistencia del
evento anómalo. Para estas redes pequeñas, el descubrimiento de aquellos eventos indetectables por los nodos puede realizarse en la estación base. Otro factor que influye
mucho sobre los mecanismos es la movilidad de los miembros de la red. En los casos
en los que la estación base sea móvil (p. ej. en escenarios de rastreo de vehı́culos),
la carga especı́fica de un nodo variará dependiendo de su localización respecto a la
estación base. Si son los nodos los que tienen la capacidad de movimiento, existen
varios efectos colaterales que o bien necesitan ser analizados en más profundidad
(p. ej. la desaparición de paquetes) o bien no ofrecen información sobre el evento
(aparición de nodos móviles en una zona de la red).
Además de la estructura de la red existen otros aspectos que también influyen
sobre el servicio de autoinspección. Dependiendo de la aplicación, la red de sensores
ofrece una serie de funcionalidades a sus usuarios (monitorización del entorno, generación de alertas, ...). Los eventos que se pueden detectar y la forma de detectarlos
están influenciados por esa funcionalidad. Por ejemplo, no es posible comprobar si
existen alertas erróneas en caso de que esta funcionalidad no exista dentro de la
red. Finalmente, la comprobación de ciertos eventos requiere del conocimiento de las
caracterı́sticas de la aplicación utilizada en la red de sensores. Por ejemplo, eventos
anómalos tales como la creación de mensajes, cuya detección dependen del número
de paquetes existentes dentro de un periodo de muestreo, dependen de caracterı́sticas
como la carga y la dimensión de la red.
B.8
Detección de intrusiones y Redes de Sensores
Como hemos argumentado, el servicio de autoinspección es esencial para monitorizar
el comportamiento de los elementos de una red de sensores y para permitir que los
nodos sensores se autoconfiguren. Además, es la piedra angular para el desarrollo de
un servicio de detección de intrusiones (IDS). Conociendo la situación de su entorno
un nodo sensor puede ser capaz, a través del servicio de IDS, de decidir cuándo un
vecino está actuando de forma maliciosa y reaccionar de forma adecuada [248].
Anteriormente han sido estudiados determinados aspectos en el desarrollo de un
IDS para redes de sensores, como la naturaleza de determinados mecanismos de
detección. Sin embargo, no ha sido propuesto hasta el momento ningún esquema
especı́fico de esta clase de sistemas que cumpla las siguientes propiedades de forma
conjunta:
173
Sensores
Conocimiento del Entorno
Mensajes
Análisis específicos de protocolos
Otros
ADQUISICIÓN DE DATOS
- #paquetes
- Números de Secuencia
- Otros
DETECCIÓN
- Lecturas del sensor
- Colisiones (“Backoffs”)
- Información de Alertas
ESTADÍSTICAS
COLABORACIÓN
Malicioso
Sospechoso
BBDD ALERTAS
Figure B.3: Estructura de una arquitectura IDS para WSN
• Cobertura total: cubrir todo el intercambio de información que fluye a través
de la red.
• Simplicidad: funcionar en un dispositivo de capacidades limitadas.
• Adaptabilidad: posibilidad de incluir nuevos mecanismos de detección, o excluir
aquellos mecanismos que no sean relevantes para la aplicación.
B.8.1
Propuesta de un sistema de detección de intrusiones
Nuestra propuesta de sistema que cubra esas propiedades de cobertura total, simplicidad y adaptabilidad se presenta en la figura B.3. Dado que los ataques pueden
producirse en cualquier punto de la red, la cobertura total se consigue con una
solución distribuida. Además, proveemos de dos sistemas de detección, adaptados
a las capacidades de los dispositivos existentes en la red. Por un lado, el Agente
Estación Base, localizado en la estación base, que se encarga de comprobar la información procedente de la red de sensores y de incluir mecanismos de detección que
necesiten de datos globales de la red [188]. Por el otro, el Agente Nodo, del que existe
una copia en todos los nodos de la red, y que se encarga de comprobar únicamente
la información de sus nodos vecinos.
Dentro de cada agente, existen unos componentes especializados en realizar las
tareas del sistema de detección de intrusiones, ası́ como de ofrecer información a los
demás servicios de la red. El componente Adquisición de Datos obtiene información
de las fuentes de los sı́ntomas (p. ej. mensajes, lecturas de sensores), y los almacena
en el componente Estadı́sticas, que proporciona información que puede ser utilizada
por servicios similares al protocolo SNMP. Este último componente informa principalmente al componente Detección, que infiere la existencia de eventos anómalos
procedentes de nodos maliciosos en base a los mecanismos de conocimiento del entorno y otros mecanismos de detección dependientes de los protocolos utilizados por
la aplicación. Dentro de este componente se incluyen sólo aquellos mecanismos que
174
sean estrictamente necesarios para analizar el comportamiento de la aplicación. Todos los resultados se guardan en la base de datos de alertas, donde los nodos se
clasifican en maliciosos o sospechosos. Esta BBDD puede servir de plataforma para
lanzar servicios complejos de seguridad, como la atestación de código. Finalmente,
existe un componente Colaboración para que el nodo comparta su información con
sus vecinos o con la estación.
Las limitaciones existentes en los nodos sensores imponen una división de las
tareas a realizar por el Agente Nodo. Las tareas de análisis locales al nodo son
realizadas por el Agente Nodo Local, mientras que los análisis de datos externos son
realizados por el Agente Nodo Global. Más especı́ficamente, las tareas del Agente
Nodo Local son las de detectar situaciones anómalas en los protocolos utilizados
por la red y en las lecturas de los sensores. Sus mecanismos de detección se ejecutan
cada vez que existan datos disponibles. Por otro lado, para poder ahorrar energı́a, los
mecanismos de detección del Agente Nodo Global sólo se ejecutan cada cierto tiempo,
por ejemplo al final de un periodo de muestreo. Estos mecanismos permiten descubrir
la existencia de ataques de interferencia de señal, malfuncionamiento del hardware,
mensajes retrasados, y mensajes ignorados. Además, ciertos mecanismos como el
análisis de paquetes enviados en broadcast pueden ser temporalmente desconectados,
en parte gracias a la redundancia de la red [258, 262].
Otros aspectos importantes que son gestionados por la estructura propuesta son el
tiempo de ejecución de los mecanismos de detección periódicos y la distribución de los
agentes (tanto locales como globales) en los diversos nodos de la red. Ambos aspectos
dependen, de nuevo, de la naturaleza de la aplicación. La carga de la red (el número
de mensajes enviados por unidad de tiempo), la importancia del tiempo de reacción
en los procesos de detección, y el gasto de energı́a admisible en un nodo, influyen
sobre la periodicidad de los procesos de detección. Respecto a la distribución de los
nodos, en sistemas jerárquicos es posible activar el agente nodo global únicamente
en lı́deres de cluster.
También es posible utilizar ciertos protocolos de soporte que ayuden al sistema
de detección de intrusiones a realizar su tarea. Por ejemplo, puede modificarse el
formato de los mensajes para facilitar la detección de mensajes descartados. También
es posible mejorar los mecanismos que comprueban el estado de otro nodo de la red.
Finalmente, pueden desconectarse temporalmente ciertos mecanismos de detección
en algunos nodos gracias a la redundancia de la red.
B.9
Sistemas de confianza y Redes de Sensores
El concepto de confianza (‘Esperanza firme que se tiene de alguien o algo’) deriva de
entornos sociológicos y psicológicos. La confianza es un factor esencial en cualquier
tipo de red, sea social o de ordenadores, ya que ayuda a los miembros de la red
a abordar el problema del desconocimiento de las futuras acciones de los demás
participantes de la red (incertidumbre). Como resultado, el manejo de la confianza
175
es muy importante en transacciones de Internet o en sistemas distribuidos.
El término ‘sistema de manejo de confianza’ en sistemas computacionales fue descrito primero por Blaze et al. [205]. Los objetivos principales de estos sistemas son:
i) determinar la confianza inicial en los participantes, ii) observar el comportamiento
de los miembros de la red, iii) actualizar la confianza en los demás miembros de
la red. En ciertos sistemas, también se tiene en cuenta la reputación (‘Opinión o
consideración en que se tiene a alguien o algo; Prestigio o estima en que son tenidos
alguien o algo’) a la hora de calcular la confianza que se tiene en otro miembro de la
red.
La confianza es un factor muy importante para la toma de decisiones en cualquier
tipo de red computacional donde exista la incertidumbre. La incertidumbre se origina
de dos fuentes [223]: la asimetrı́a de la información y el oportunismo. En un contexto
de redes de sensores, los nodos sensores trabajan para el bien común de la red, ası́
que no son oportunistas. Sin embargo, un nodo sensor no conoce el comportamiento
de sus vecinos a priori (p. ej. pueden fallar o ser maliciosos), por lo que existe
asimetrı́a en la información. Por lo tanto, la confianza es un factor a considerar en
una red de sensores. Por ejemplo, los algoritmos de encaminamiento pueden elegir
al siguiente nodo que reenviará el paquete de datos en base a la confianza que tenga
en sus vecinos.
Actualmente, existen muchos sistemas de manejo de confianza para redes ad hoc,
los cuales introducen ideas importantes (como el uso de la reputación) pero no pueden
ser directamente aplicables a redes de sensores [254]. Respecto a la investigación de
sistemas de manejo de confianza para redes de sensores, ésta se encuentra aún en
sus inicios. La mayorı́a del estado del arte es capaz de resolver problemas puntuales,
pero en la mayorı́a de los casos se han ignorado en el diseño de los sistemas aquellas
caracterı́sticas que definen a una red de sensores [253]. Es entonces nuestro objetivo el especificar cómo un sistema de manejo de confianza puede incorporar esas
caracterı́sticas especı́ficas para funcionar adecuadamente [252].
B.9.1
Especificación de la confianza en Redes de Sensores
Arquitectura y componentes. En un sistema de manejo de confianza, debe
existir una entidad que proporcione a los servicios de un nodo la capacidad de acceder
a las mediciones de reputación y confianza de los demás nodos. Esta entidad tiene
que componerse de los siguientes componentes:
• Un componente de adquisición de datos, el cual obtenga información a través
de dos fuentes: i) la observación del comportamiento de los demás nodos, y ii)
compartir información con otros nodos.
• Un componente de reputación, que almacene la reputación de los nodos de la
red.
176
• Un componente de confianza, que proporcione a los servicios de un nodo la
confianza que se tiene en los demás nodos para hacer determinadas operaciones
en base a su reputación.
Estas entidades deben localizarse en todos los miembros de una red de sensores
(estación base y nodos), ya que todos participan en los servicios y protocolos de la
red. Existe un caso excepcional a esta distribución: en las redes jerárquicas, los
lı́deres de clúster serán los únicos nodos que tengan activa su entidad.
Inicialización y adquisición de datos. Respecto a la inicialización de los valores de confianza y reputación, éstos suponen que, por defecto, todos los nodos son
confiables. La explicación es sencilla: todos los nodos fueron programados en un
entorno controlado y con la misión de llevar a cabo de forma conjunta los servicios
de la red. Con respecto a la adquisición de datos, ésta puede realizarse utilizando los
mecanismos de conocimiento del entorno vistos en la sección B.7.1, además de otros
mecanismos dependientes de la aplicación que analicen los protocolos especı́ficos utilizados en la red [227]. Es más, en el contexto de una red de sensores, es posible
utilizar el concepto de ‘apoptosis’. En términos médicos, la apoptosis ocurre cuando
una célula se suicida debido a ataques vı́ricos u otras causas [215]. En un contexto
computacional, un nodo sensor puede detectar su estado interno (p.ej. baterı́as bajas, malfuncionamiento de sus sensores) y avisar al resto de los nodos de cualquier
anomalı́a.
Modelado de la información. A la hora de modelar los valores de reputación y
confianza, hay varios detalles especı́ficos de las redes de sensores que hay que tener
en cuenta. Uno de ellos es la evolución de la reputación. Los nodos sensores no se
comportan anormalmente por defecto, ası́ que cualquier comportamiento manifiestamente maligno debe tener un gran reflejo en su reputación. Además, si un nodo
alcanza una reputación muy baja, este hecho deberı́a recordarse: un nodo que se haya
comportado de forma maliciosa posiblemente lo volverá a hacer en un futuro. Otro
aspecto es la granularidad: deben existir varios valores que modelen la reputación y
la confianza en un nodo. Por ejemplo, un nodo cuyos sensores no funcionen correctamente puede tener a su vez una de las mejores rutas de encaminamiento.
Otro aspecto a considerar es la influencia del riesgo y la importancia de la operación en la confianza. Ambas deciden cual es el lı́mite en el que un nodo puede
considerarse o no adecuado para una tarea determinada. Por ejemplo, un paquete
de datos puede ser encaminado por cualquier nodo, pero solo aquellos con máxima
confianza deberı́a encaminar paquetes de alerta. Finalmente, otro aspecto menor es
la necesidad de enviar notificaciones a la estación base, ya que la existencia de informes contradictorios con respecto a la confianza en un nodo ya puede ser indicativo
suficiente de la existencia de problemas dentro de la red.
177
B.10
Redes de Sensores y middleware seguro
El proyecto SMEPP (Secure Middleware for Embedded Peer-to-Peer systems, FP6IST-033563) es un proyecto STREP financiado por la Unión Europea dentro del 6o
programa marco. Comenzó en octubre del 2006 y finalizará en octubre del 2009. El
principal objetivo de este proyecto es el desarrollo de un middleware especialmente
diseñado para redes peer-2-peer empotradas, que pueda solucionar los problemas
de los middleware especı́ficos en este campo. El middleware desarrollado en este
proyecto será seguro, genérico, y altamente configurable, permitiendo su adaptación
a múltiples dispositivos y dominios de aplicación.
La seguridad es un aspecto crucial para el funcionamiento adecuado de un sistema P2P basado en dispositivos embebidos, ya que estos sistemas se encuentran
desprotegidos ante varios tipos de ataques externos e internos. Uno de los objetivos
primordiales de nuestro trabajo en el proyecto SMEPP es la integración de mecanismos de seguridad dentro de la arquitectura del middleware. Ası́, estos mecanismos
deberı́an estar disponibles al desarrollador de aplicaciones de SMEPP a través de
una capa transversal dentro de la arquitectura [260].
En SMEPP, los servicios de seguridad (seguridad en grupos, servicios criptográficos,
seguridad en la infraestructura) se localizan en una capa transversal, y son utilizados
por los demás servicios de SMEPP (p. ej. encaminamiento, manejo de grupos). Su
modularidad permite que se incluyan solamente aquellos mecanismos criptográficos
que vayan a ser utilizados en una aplicación determinada. El uso de componentes
también permite la reutilización de los mecanismos seguros para aquellos servicios
que los necesiten. Es necesario hacer notar que la elección de los mecanismos criptográficos a utilizar dentro de SMEPP se benefició de la existencia del trabajo presentado en la sección B.4. Además, los servicios de autoinspección vistos en la
sección B.7 están disponibles para que el servicio de encaminamiento pueda realizar
mejor su tarea.
Respecto a la adaptabilidad a las aplicaciones, la seguridad no viene impuesta
al desarrollador, sino que le es posible elegir el nivel de seguridad que desea y que
se adapte mejor a los requerimientos de su aplicación. Estos niveles de seguridad,
desarrollados conjuntamente por los miembros del consorcio SMEPP, están detallados
en la Figura B.4. SMEPP permite la configuración tanto del proceso de admisión en
un grupo como de la protección ofrecida por las claves de sesión. Si se utiliza una
clave secreta compartida como credencial de seguridad, se reduce la complejidad de
la negociación y de los componentes de seguridad. Por otro lado, es peligroso utilizar
claves compartidas si existe la posibilidad de que la información de un dispositivo
caiga en manos de un atacante. En ese caso, es aconsejable utilizar criptografı́a de
clave pública para limitar los efectos de posibles ataques. Respecto a la seguridad
ofrecida por las claves de sesión, éstas pueden simplemente asegurar la integridad y la
autenticidad de un mensaje como procedente de un miembro de un grupo SMEPP, o
además pueden proteger la confidencialidad del mensaje, evitando ası́ que dispositivos
178
Admisión en
grupo
Seguridad de
datos
Protección clave
de sesión
2
Criptografía de
clave pública
Autenticación y
Cifrado
Global y Local
(Anti–SCA)
1
Clave secreta
compartida
Autenticación
Global (Refresco
de clave)
0
Nada
Nada
Nada
Tipo
Nivel
Figure B.4: Los tres niveles de seguridad en SMEPP
externos al grupo accedan al flujo de información procedente de ese grupo.
SMEPP permite una granularidad extra a la hora de proteger las comunicaciones.
Una red SMEPP dispone de múltiples dominios de seguridad: Un dominio global (comunicaciones entre los miembros de una red SMEPP) y varios dominios de grupo
(comunicaciones entre los miembros de un mismo grupo). SMEPP permite ası́ elegir para cada dominio el nivel de seguridad que se desee. Mediante la protección
del dominio global, es posible elegir si una red SMEPP es accesible por cualquier
dispositivo o sólo accesible por aquellos dispositivos autorizados a hacerlo. Por otro
lado, es posible modificar el nivel de seguridad utilizado por un dominio de grupo en
particular, permitiendo la existencia de grupos cuyos servicios sean de acceso público
y de grupos con un grado de protección variable.
B.11
Integración de Redes de Sensores en Internet
Para que las redes de sensores no fueran mundos cerrados y se pudiera incrementar
su utilidad, serı́a necesario resolver los problemas de accesibilidad a los servicios
proporcionados por las mismas. Esos servicios deberı́an ser fácilmente accesibles
desde redes externas, bien a través de la estación base o bien accediendo directamente
a los contenidos de un nodo sensor. Como consecuencia, el flujo de información
producido por la red habrı́a de ser accedido y analizado por distintas aplicaciones
situadas en diferentes localizaciones geográficas. Además, deberı́a ser posible que un
operador controlara la red de forma remota.
Por lo tanto, el verdadero potencial de las redes de sensores podrı́a ser aprovechado
completamente si esos servicios fuesen publicados hacia fuera de la red utilizando
179
Front-End Proxy
Datos
Datos
S- Datos
S-Datos
TCP/IP
TCP/IP
S-Proto
Sensor Protocol
MAC
MAC
802.15.4
IEEE 802.15.4
Datos
Gateway
Capa TCP/IP
Datos
Datos
TCP/IP
TCP/IP
S-Proto
Sensor Protocol
MAC
MAC
802.15.4
IEEE 802.15.4
Datos
Datos
TCP/IP
TCP/IP
MAC
Equipo de Internet
MAC
802.15.4
Estación Base
Datos
TCP/IP
IEEE 802.15.4
Nodo Sensor
Figure B.5: Estrategias de integración WSN-Internet
interfaces estándar en una infraestructura de red pública como Internet. Las interacciones con las redes de sensores irı́an más allá, pasando del acceso remoto al universo
de la colaboración.
Existen varias estrategias de integración que pueden ser utilizadas para interconectar las redes de sensores con otros sistemas pertenecientes a la comunidad
Internet. Por un lado, las redes de sensores pueden funcionar sin estar completamente integradas en la infraestructura de Internet pero proporcionando sus servicios
a través de interfaces estándar. Esta solución se denomina basada en proxy. Por otro
lado, las redes pueden también comportarse como cualquier otra red basada en IP, de
tal forma que sus nodos puedan establecer conexiones directas con otros equipos de
Internet. En este caso, la solución pasa por crear especı́ficamente una capa TCP/IP.
Finalmente, en una tercera opción, basada en gateway, la red mantiene su independencia estructural pero permite el establecimiento de conexiones directas entre
equipos. Todas estas alternativas se muestran en la figura B.5.
Sea cual sea el mecanismo de integración, al conectar una red de sensores a Internet surgen muchos e interesantes desafı́os nuevos de seguridad, aún cuando la red de
sensores tenga un funcionamiento seguro por si sola [247]. Ya que los usuarios de Internet se conectarı́an de forma remota a los servicios proporcionados por la red, serı́a
necesario desarrollar mecanismos especı́ficos para proteger el flujo de información.
Además, el acceso de la comunidad Internet a los servicios de la red harı́a crecer
exponencialmente el número de potenciales usuarios maliciosos o no autorizados que
tratarı́an de manipular la red. Es entonces necesario crear mecanismos que puedan
tanto autenticar a los usuarios y a los nodos sensores, como verificar si se dispone de
180
los permisos necesarios para acceder a la red. Además, habrán de detectar posibles
ataques que se realicen desde el exterior. Otros factores como la disponibilidad y la
trazabilidad también deben ser tenidos en cuenta.
B.11.1
Problemas abiertos y propuestas de soluciones
• Solución basada en proxy. En esta solución, la estación base actúa como
un representante de todos los nodos sensores, proporcionando la funcionalidad de la red mientras está conectada a Internet como un equipo más. Ası́,
proponemos que los mecanismos de protección, tales como la negociación de
claves o la detección de intrusiones, sean implementados e incorporados dentro
de la estación base. Al estar las infraestructuras de Internet y la red de sensores
completamente separadas, el intercambio de información entre un equipo de Internet y la estación base se protegerá utilizando protocolos estándar, mientras
que las comunicaciones entre la estación base y los diversos nodos utilizarán
mecanismos de seguridad más sencillos y adaptados al entorno. Además, la red
de sensores incorporará mecanismos propios (p. ej. redundancia en las fuentes
de información) para aprovechar las capacidades de la red al máximo.
Una desventaja de nuestra solución es que la estación base se convierte automáticamente en un punto débil de la red: si se consigue atacar o impedir el
acceso a la estación base, toda la red de sensores se verá afectada (p. ej. un atacante podrá ver todo el flujo de información). Esta desventaja se puede paliar
mediante el uso de múltiples estaciones base, que evitarı́an problemas como la
no disponibilidad de la red en caso de fallos, e incluso introducirı́an ventajas
como el balanceo de carga. De hecho, el uso de múltiples estaciones conlleva
interesantes desafı́os como el mantenimiento de la coherencia de la información
entre todas las estaciones base.
• Solución basada en capa TCP/IP. Resolver los problemas de seguridad en
la integración total de las infraestructuras de las redes de sensores e Internet
no es trivial. Es posible enviar paquetes IPv6 a través de una red de sensores
(utilizando la especificación 6lowpan), pero no existe una especificación definida
de mecanismos de protección en la capa de red. Aún cuando no exista esa
capacidad de crear un canal seguro de comunicación extremo a extremo, las
aplicaciones necesitan de este servicio. Serı́a posible utilizar estándares como
TLS/SSL, o utilizar protocolos de distribución de claves basados en operaciones
matemáticas.
La autenticación y autorización de usuarios es otro problema a resolver, aunque
proponemos que puede solucionarse utilizando Kerberos [241]. También es
necesario resolver problemas tales como conservar los datos de trazabilidad de
la red, o permitir la disponibilidad tanto de los servicios del nodo como de
los datos históricos producidos por el nodo. Posibles soluciones consistirı́an
181
en almacenar únicamente información respecto a incidentes detectados por un
IDS (trazabilidad), y comprimir y / o almacenar los datos históricos en otro
lugar (disponibilidad).
• Solución basada en gateway. Algunos de los problemas asociados al uso
de TCP/IP pueden ser parcialmente resueltos utilizando una solución basada
en gateways. La estación base puede analizar y/o almacenar todas las interacciones entre los nodos y equipos remotos, guardar los datos históricos de los
nodos, mejorar la disponibilidad de la red, etc. Es más, ya que para enviar
paquetes IPv6 a una red de sensores es necesario traducir los paquetes a 6lowpan, la estación base puede realizar estos roles de análisis. Sin embargo, si se
utilizan mecanismos que proporcionen una canal seguro extremo a extremo,
será entonces necesario implementar soluciones no triviales.
B.12
Conclusiones
En el transcurso de esta tesis, hemos demostrado como los mecanismos de seguridad mostrados en el “conjunto integral” son posibles dentro de una red de sensores.
Además, también hemos mostrado como la naturaleza de las aplicaciones y su contexto influyen sobre el desarrollo de los mecanismos de seguridad. Todas las contribuciones realizadas en el ámbito de esta tesis están resumidas en la sección B.3,
y se encuentran en más detalle dentro de las secciones que forman parte de este
capı́tulo.
Además, en el marco de esta tesis se han descubierto y definido diversas áreas
de investigación que quedan abiertas para ser resueltas en un futuro. Estas son la
adecuación de los mecanismos de seguridad a los entornos móviles, la definición de
primitivas adaptadas a dispositivos de baja capacidad, el desarrollo de mecanismos
especı́ficos de administración de claves, la interacción segura entre las redes de sensores e Internet, y la utilización segura de las redes de sensores con otros paradigmas
como el de las redes de área personal.
182
Bibliography
183
184
[1] G. Witzany. The Logos of the Bios 2. Bio-Communication. Helsinki, Umweb
(2007). ISBN 952-5576-04-7
[2] A. H. Maslow. A Theory of Human Motivation. Psychological Review, no. 50,
pp. 370-396, 1943.
[3] M. A. Max-Neef, A. Elizalde, M. Hopenhayn. Human scale development : conception, application and further reflections. New York : The Apex Press. ISBN
094525735X, 1991.
[4] European Organization for Nuclear Research (CERN). LHC - The Large Hadron
Collider.
http://lhc.web.cern.ch, 2008.
[5] M.G. Rubinstein, I.M. Moraes, M. Elias, M. Campista, L.H.M.K. Costa,
O.C.M.B. Duarte. A Survey on Wireless Ad Hoc Networks. In Mobile and Wireless Communication Networks, pp. 1-33, August 2006. Springer-Verlag, ISBN:
0387346341.
[6] C. Chong and S.P. Kumar, Sensor Networks: Evolution, Opportunities, and Challenges. Proceedings of the IEEE, vol. 91, no. 8, pp. 1247-1256, 2003.
[7] C. E. Nishimura, D. M. Conlon. IUSS dual use: Monitoring whales and earthquakes using SOSUS. Mar. Technol. Soc. Journal, vol. 27, no. 4, pp. 13–21, 1994.
[8] Proceedings of the Distributed Sensor Nets Workshop. Pittsburgh, (USA),
Carnegie Mellon University, 1978.
[9] R. Rashid, G. Robertson. Accent: A communication oriented network operating
system kernel. ACM SIGOPS Operating Systems Review, vol. 15, no. 5, December 1981.
[10] R. T. Lacoss. Distributed mixed sensor aircraft tracking. Proceedings of the 6th
American Control Conference, pp. 1827-1830, Minneapolis (USA), June 1987.
[11] V.R. Lesser, D.D. Corkill. The distributed vehicle monitoring testbed: A tool for
investigating distributed problem solving networks. Readings from the AI magazine, pp. 69–85, ISBN: 0-929280-01-6, 1989.
[12] C.Y. Chong, K.C. Chang, S. Mori. Distributed tracking in distributed sensor
networks. Proceedings of the American Control Conference, 1982.
[13] DARPA. SensIT - Sensor Information Technology.
http://www.sainc.com/sensit/goals.htm
185
[14] Smart-Its Consortium. The Smart-Its Project.
http://www.smart-its.org/
[15] D. Culler, D. Estrin, M. Srivastava. Overview of Sensor Networks. IEEE Computer, vol. 37, no. 8, pp. 41-49, August 2004.
[16] Sensor Nets / RFID. Intel Corporation.
http://www.intel.com/research/exploratory/wireless_sensors.htm
[17] Gregory J. Millman, Accenture. Virtual Vineyard.
http://www.accenture.com/Global/Research_and_Insights/Outlook/
By_Alphabet/VirtualVineyard.htm
[18] K. Martinez, P. Padhy, A. Elsaify, G. Zou, A. Riddoch, J.K. Hart, H.L.R. Ong.
Deploying a Sensor Network in an Extreme Environment. Proceedings of Sensor
Networks, Ubiquitous and Trustworthy Computing (SUTC 2006), pp. 186-193,
Taichung (Taiwan), June 2006.
[19] J.M. Lees, J.B. Johnson, M. Ruiz, L. Troncoso, M. Welsh. Reventador Volcano
2005: Eruptive Activity Inferred from Seismo-Acoustic Observation. Journal of
Volcanology and Geothermal Research, in press.
[20] R. Szewczyk, J. Polastre, A. Mainwaring and D. Culler. Lessons from a Sensor Network Expedition. Proceedings of the 1st European Workshop on Wireless
Sensor Networks (EWSN 2004), pp. 307-322, Berlin (Germany), January 2004.
[21] Wired and Wireless Intelligent Networked Systems (WINES) - Smart Infrastructure Project. http://www.winesinfrastructure.org/
[22] T. He, S. Krishnamurthy, L. Luo, T. Yan, L. Gu, R. Stoleru, G. Zhou, Q. Cao, P.
Vicaire, J. A. Stankovic, T. F. Abdelzaher, J. Hui, B. Krogh. VigilNet: An integrated sensor network system for energy-efficient surveillance. ACM Transactions
on Sensor Networks, vol. 2, no. 1, pp 1-38, February 2006.
[23] Harvard University. The CodeBlue Project.
http://www.eecs.harvard.edu/~mdw/proj/codeblue
[24] A. Wood, G. Virone, T. Doan, Q. Cao, L. Selavo, Y. Wu, L. Fang, Z. He, S. Lin,
J. Stankovic. ALARM-NET: Wireless Sensor Networks for Assisted-Living and
Residential Monitoring. Technical Report CS-2006-11, Department of Computer
Science, University of Virginia, 2006.
186
[25] D. Minder, P. J. Marrón, A. Lachenmann, K. Rothermel. Experimental construction of a meeting model for smart office environments. Proceedings of the
First Workshop on Real-World Wireless Sensor Networks (REALWSN 2005),
Stockholm (Sweden), June 2005.
[26] Cadi Scientific Pte Ltd. CADI SmartSenseTM .
http://www.cadi.com.sg
[27] Nordic Collaboration Project. Biomedical Wireless Sensor Network Project.
http://www.bwsn.net
[28] N. Ramanathan, L. Balzano, D. Estrin, M. Hansen, T. Harmon, J. Jay, W. J.
Kaiser, G. Sukhatme. Designing Wireless Sensor Networks as a Shared Resource
for Sustainable Development. Proceedings of the International Conference on Information and Communication Technologies and Development (ICTD 2006), pp.
256-265, Berkeley (USA), May 2006.
[29] University
of
California,
http://fire.me.berkeley.edu/
Berkeley.
FIRE
Project.
[30] A. Krishnamurthy, B. Kamasi, C. McCoy, K. Mallela. Project Laund-re-mote.
[31] W. Watts, M. Koplow, A. Redfern, P. Wright. Application of Multizone HVAC
Control Using Wireless Sensor Networks and Actuating Vent Registers. Texas
University A&M Repository, 2007.
[32] Crossbow Technology, Inc. eKo Pro – Precision Agriculture.
http://www.xbow.com/eko/, 2008
[33] M. Weiser. The Computer for the Twenty-First Century. Scientific American,
Vol 265 no 3, pp. 94-104, September 1991.
[34] M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE Personal Communication, Vol 8 no 4, pp. 10-17, August 2001.
[35] F. Calabrese, K. Kloeckl, C. Ratti, M. Bilandzic, M. Foth, A. Button, H. Klaebe,
L. Forlano, S. White, P. Morozov, S. Feiner, F. Girardin, J. Blat, N. Nova, M.P.
Pieniazek, R. Tieben, K. van Boerdonk, S. Klooster, E. van den Hoven, J. Martı́n
Serrano, J. Serrat, D. Michelis, E. Kabisch. Urban Computing and Mobile Devices.
IEEE Pervasive Computing, vol. 6, no. 3, pp. 52-57, Jul-Sept 2007.
[36] International Telecommunication Union. The Internet of Things. ITU Internet
Reports 2005.
187
[37] I.F. Akyildiz, E.P. Stuntebeck. Wireless Underground Sensor Networks: Research Challenges. Ad Hoc Networks Journal, vol. 4, no. 6, pp. 669-686, November
2006.
[38] V. Shnayder, M. Hempstead, B. Chen, G. Werner Allen, M. Welsh. Simulating
the Power Consumption of Large-Scale Sensor Network Applications. Proceedings of the 2nd international conference on Embedded networked sensor systems
(SenSys’04), pp. 188-200, Baltimore (USA), November 2004.
[39] V. Kawadia, P.R. Kumar. A cautionary perspective on cross-layer design. IEEE
Wireless Communications, vol. 12, no. 1, pp. 3-11, February 2005.
[40] V. Srivastava, M. Motani. Cross-Layer Design: A Survey and the Road Ahead.
IEEE Communications Magazine, vol. 43, no. 12, pp. 112-119, December 2005.
[41] I.F. Akyildiz, M.C. Vuran, O.B. Akan. A Cross-Layer Protocol for Wireless
Sensor Networks. Proceedings of the 40th Annual Conference on Information
Sciences and Systems, pp. 1102-1107, Princeton (USA), March 2006.
[42] P.J. Marrón, D. Minder, A. Lachenmann, K.Rothermel. TinyCubus: An Adaptive Cross-Layer Framework for Sensor Networks. it – Information Technology
journal, vol. 47, no. 2, pp. 87-97. 2005.
[43] D. Culler, P. Dutta, C. Tien Ee, R. Fonseca, J. Hui, P. Levis, J. Polastre, S.
Shenker, I. Stoica, G. Tolle, J. Zhao. Towards a Sensor Network Architecture:
Lowering the Waistline. Proceedings of the 10th Workshop on Hot Topics in
Operating Systems (HotOS X), pp. 139-144, Santa Fe (USA), 2005.
[44] R. Kumar. Adaptable Protocol Stack Architecture for Future Sensor Networks.
PhD Thesis, Georgia Institute of Technology, 2006.
[45] ZigBee Alliance. ZigBee Specification
http://www.zigbee.org/
[46] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci. Wireless sensor
networks: a survey. Computer Networks: The International Journal of Computer
and Telecommunications Networking, vol. 38, no. 4, pp. 393-422, March 2002.
[47] A. Alarifi, W. Du. Diversifying Sensor Nodes to Improve Resilience Against Node
Compromise. Proceedings of the 4th ACM Workshop on Security of Ad Hoc and
Sensor Networks (SASN 2006), pp. 101-112, Alexandria (USA), October 2006.
188
[48] L. Batina, N. Mentens, K. Sakiyama, B. Preneel, I. Verbauwhede. Low-Cost
Elliptic Curve Cryptography for Wireless Sensor Networks. Proceedings of the
3rd European Workshop on Security and Privacy in Ad hoc and Sensor Networks
(ESAS 2006), pp. 6-17, Hamburg (Germany), September 2006.
[49] A. Becher, Z. Benenson, M. Dornseif. Tampering with Motes: Real-World Physical Attacks on Wireless Sensor Networks. Proceedings of the 3rd International
Conference on Security in Pervasive Computing (SPC’06), pp. 104-118, York
(United Kingdom), April 2006.
[50] D. Malan, T. Fulford-Jones, M. Welsh, S. Moulton. CodeBlue: An Ad Hoc
Sensor Network Infrastructure for Emergency Medical Care. Proceedings of the
International Workshop on Wearable and Implantable Body Sensor Networks,
London (United Kingdom), April 2004.
[51] W. Du, J. Deng, Y. S. Han, P. K. Varshney. A witness-based approach for data fusion assurance in wireless sensor networks. Proceedings of the IEEE 2003 Global
Communications Conference (GLOBECOM’03), pp. 1435-1439, San Francisco
(USA), December 2003.
[52] P. K. Dutta, J. W. Hui, D. C. Chu, D. Culler. Securing the Deluge Network
Programming System. Proceedings of the 5th International Conference on Information Processing in Sensor Networks (IPSN’06), pp. 326-333, Nashville (USA),
April 2006.
[53] P. Ganesan, R. Venugopalan, P. Peddabachagari, A. Dean, F. Mueller, M. Sichitiu. Analyzing and Modeling Encryption Overhead for Sensor Network Nodes.
Proceedings of the 2nd ACM International Conference on Wireless Sensor Networks and Applications (WSNA 2003), pp. 151-159, San Diego (USA), September
2003.
[54] S. Ganeriwal and M. B. Srivastava. Reputation-Based Framework for High Integrity Sensor Networks. Proceedings of the 2nd ACM Workshop on Security of
Ad Hoc and Sensor Networks (SASN’04), pp. 66-77, Washington DC (USA),
2004.
[55] G. Gaubatz, J.-P. Kaps, E. Öztürk, B. Sunar. State of the Art in Ultra-Low
Power Public Key Cryptography for Wireless Sensor Networks. Proceedings of the
2nd IEEE International Workshop on Pervasive Computing and Communication
Security (PerSec 2005), pp. 146-150, Hawaii (USA), March 2005.
189
[56] J. W. Hui, D. Culler. The Dynamic Behavior of a Data Dissemination Protocol for Network Programming at Scale. Proceedings of 2nd International Conference on Embedded Networked Sensor Systems (SenSys’04), pp. 81-94, Baltimore
(USA), November 2004.
[57] IEEE Standard, 802.15.4-2006. Wireless medium access control and physical
layer specifications for low-rate wireless personal area networks. ISBN 0-73814997-7, 2006.
[58] K. Jun Choi, J.-I. Song. Investigation of Feasible Cryptographic Algorithms for
Wireless Sensor Network. Proceedings of the 8th International Conference on
Advanced Communication Technology (ICACT 2006), Phoenix Park (Korea),
February 2006.
[59] I. Krontiris, T. Dimitriou. Authenticated In-Network Programming for Wireless
Sensor Networks. Proceedings of the 5th International Conference on AD-HOC
Networks & Wireless (ADHOC-NOW 2006), pp. 390-403, Ottawa (Canada), August 2006.
[60] A. Francillon, C. Castelluccia. TinyRNG: A Cryptographic Random Number
Generator for Wireless Sensors Network Nodes. Proceedings of the 5th International Symposium on Modelling and Optimization in Mobile, Ad Hoc and
Wireless Networks (WiOpt 2007), pp. 1-7, Limassol (Cyprus), April 2007.
[61] P. Levis, D. Culler. Maté: A Tiny Virtual Machine for Sensor Networks. ACM
SIGOPS Operating Systems Review, vol. 36, no. 5, pp. 85-95, December 2002.
[62] A. Liu, P. Ning. TinyECC: A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks. Technical Report TR-2007-36, North Carolina
State University, Department of Computer Science, November 2007.
[63] J. Newsome, E. Shi, D. Song, A Perrig. The Sybil Attack in Sensor Networks:
Analysis & Defenses. Proceedings of the IEEE 3nd International Workshop on
Information Processing in Sensor Networks (IPSN’04), pp. 259-268, Berkeley
(USA), April 2004.
[64] C. Ozturk, Y. Zhang, W. Trappe, M. Ott. Source-location privacy for networks
of energy-constrained sensors. Proceedings of 2nd IEEE Workshop on Software
Technologies for Future Embedded and Ubiquitous Systems (WSTFEUS’04), pp.
68-72, Vienna (Austria), May 2004.
190
[65] A. Perrig, R. Szewczyk, V. Wen, D. Cullar, J. D. Tygar. SPINS: Security protocols for sensor networks. Proceedings of 7th International Conference on Mobile
Computing and Networking (MOBICOM’01), pp. 521-534, Rome (Italy), July
2001.
[66] B. Przydatek, D. Song, A. Perrig. SIA: Secure information aggregation in sensor
networks. Proceedings of 1st International Conference on Embedded Networked
Sensor Systems (SenSys’03), pp. 255-265, Los Angeles (USA), November 2003.
[67] R. Bace. Intrusion Detection. New Riders, 2000. ISBN 1-57870-185-6.
[68] N. Sastry, D. Wagner. Security considerations for IEEE 802.15.4 networks.
Proceedings of 2004 ACM Workshop on Wireless security (Wise’04), pp. 32-42,
Philadelphia (USA), October 2004.
[69] A. Seshadri, A. Perrig, L. van Doorn, P. Khosla. SWATT: SoftWare-based ATTestation for Embedded Devices. Proceedings of the 2004 IEEE Symposium on
Security and Privacy, pp. 272-282, Oakland (USA), May 2004.
[70] M. Shaneck, K. Mahadevan, V. Kher, Y. Kim. Remote Software-Based Attestation for Wireless Sensors. Proceedings of the 2nd European Workshop on Security in Ad-hoc and Sensor Networks (ESAS 2005), pp. 27-41, Visegrad (Hungary),
July 2005.
[71] B. Sundararaman, U. Buy, A. D. Kshemkalyani. Clock synchronization for wireless sensor networks: a survey. Ad-Hoc Networks, vol. 3, no. 3, pp. 281-323,
Elsevier, May 2005.
[72] D. Wagner. Resilient aggregation in sensor networks. Proceedings of 2nd ACM
workshop on Security of Ad Hoc and Sensor Networks (SASN’04), pp. 78-87,
Washington DC (USA), October 2004.
[73] H. Wang, B. Sheng, C. C. Tan, Q. Li. WM-ECC: an Elliptic Curve Cryptography
Suite on Sensor Motes. Technical Report WMCS-2007-11, College of William &
Mary, October 2007.
[74] Y. W. Law, J. Doumen, P. Hartel. Survey and Benchmark of Block Ciphers for
Wireless Sensor Networks. ACM Transactions on Sensor Networks, vol. 2, no. 1,
pp 65-93, February 2006.
191
[75] B.-Y. Yang, C.-M. Cheng, B.-R. Chen, J.-M. Chen. Implementing Minimized
Multivariate Public-Key Cryptosystems on Low-Resource Embedded Systems. Proceedings of the 3rd International Conference on Security in Pervasive Computing
(SPC 2006), York (UK), April 2006.
[76] F. Ye, H. Luo, S. Lu, L. Zhang. Statistical en-route filtering of injected false data
in sensor networks. IEEE Journal on Selected Areas in Communications, vol. 23,
no. 4, pp. 839-850, April 2005.
[77] J. Flora. Tiny15Four, An IEEE 802.15.4 implementation in TinyOS. Master
Thesis, Department of Computer Science, University of Copenhagen, Denmark,
2007.
[78] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D.
Gay, J. Hill, M. Welsh, E. Brewer, D. Culler. TinyOS: An Operating System
for Sensor Networks. On Ambient Intelligence, Springer-Verlag, ISBN 978-3-54023867-6, 2005.
[79] A. Dunkels, B. Gronvall, T. Voigt. Contiki - a lightweight and flexible operating
system for tiny networked sensors. Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks, pp. 455-462, Tampa (USA),
November 2004.
[80] C.-C. Han, R. Kumar, R. Shea, E. Kohler, M. Srivastava. SOS - A Dynamic
operating system for Sensor Networks. Proceedings of the 3rd International Conference on Mobile Systems, Applications, and Services (Mobisys 2005), Seattle
(Washington), 2005.
[81] F. Olusola. The Evaluation of TinyOS with Wireless Sensor Node Operative
Systems. Halmstad University, Technical Report IDE0711, January 2007.
[82] ECRYPT Network of Excellence. eSTREAM, the ECRYPT Stream Cipher
Project.
http://www.ecrypt.eu.org/stream/
[83] NIST. Plan for New Cryptographic Hash Functions.
http://www.nist.gov/hash-function
[84] Arduino developer team. Open hardware: Arduino Mini node.
http://www.arduino.cc/
[85] Crossbow Technology, Inc.
http://www.xbow.com/
192
[86] Art of Technology AG.
http://www.btnode.ethz.ch
[87] Sentilla Corporation. TMote Sky Datasheet.
http://www.sentilla.com/pdf/eol/tmote-sky-datasheet.pdf
[88] Particle Computer GmbH.
http://www.particle-computer.de
[89] Scatterweb GmbH. MSB Datasheet.
http://www.scatterweb.com/downloads/MSB-datasheet-doc1.0-en.pdf
[90] Sun Microsystems, Inc. Sun Small Programmable Object Technology.
http://www.sunspotworld.com/products/
[91] C. Karlof, N. Sastry, D. Wagner. TinySec: a link layer security architecture
for wireless sensor networks. Proceedings of 2nd International Conference on
Embedded Networked Sensor Systems (SenSys 2004), pp. 162-175, Baltimore
(USA), November 2004.
[92] K. Sun, P. Ning, C. Wang, A. Liu, Y. Zhou. TinySeRSync: Secure and Resilient Time Synchronization in Wireless Sensor Networks. Proceedings of the
13th ACM Conference on Computer and Communications Security (CCS’06),
pp. 264-277, Alexandria (USA), November 2006.
[93] K.Aoki and H. Lipmaa. Fast implementations of the AES candidates. Proceedings of 3rd AES conference, New York (USA), pp. 106-120, April 2000.
[94] J. Wolkerstorfer. Scaling ECC Hardware to a Minimum. In ECRYPT workshop
- Cryptographic Advances in Secure Hardware - CRASH 2005. Leuven (Belgium),
September 2005. Invited Talk.
[95] S. Kumar, C. Paar. Are standards compliant elliptic curve cryptosystems feasible
on RFID?. Proceedings of Workshop on RFID Security, Graz (Austria), July
2006.
[96] B. Schneier. Applied Cryptography, 2nd edition. Wiley, ISBN 0-471-12845-7,
1996.
[97] S. Fluhrer, I. Mantin, A. Shamir. Weaknesses in the Key Scheduling Algorithm of
RC4. proceedings of the 8th Annual Workshop on Selected Areas in Cryptography
(SAC 2001), pp. 1-24,Toronto (Canada), August 2001.
193
[98] J. Daemen, V. Rijmen. The Design of Rijndael. Springer, ISBN 3-540-42580-2,
2002.
[99] NIST-CSRC. SKIPJACK and KEA Algorithm Specifications, version 2, May
1998. http://csrc.nist.gov/CryptoToolkit/
[100] I. Blake, G. Seroussi, N. P. Smart. Elliptic Curves in Cryptography. Cambridge
University Press, ISBN 0-521-65374-6, 2000.
[101] N. Gura, A. Patel, A. Wander. Comparing elliptic curve cryptography and RSA
on 8-bit CPUs. Proceedings of the 2004 Workshop on Cryptographic Hardware
and Embedded Systems (CHES 2004), pp. 119-132, Cambridge (USA), August
2004.
[102] D. J. Malan, M. Welsh, M. D. Smith. A Public-key Infrastructure for Key
Distribution in TinyOS Based on Elliptic Curve Cryptography. Proceedings of
1st IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks (SECON 2004), pp. 71-80, Santa Clara (USA), October
2004.
[103] C. Wolf, B. Preneel. Taxonomy of Public Key Schemes Based on the Problem of
Multivariate Quadratic Equations. Cryptology ePrint Archive, Report 2005/077.
[104] Junko Nakajima, Mitsuru Matsui. Performance Analysis and Parallel Implementation of Dedicated Hash Functions. Proceedings of the International Conference on the Theory and Applications of Cryptographic Techniques: Advances
in Cryptology (Eurocrypt 2002), pp. 165-180, Amsterdam (Holland), April-May
2002.
[105] J. Hoffstein, J. Pipher, J. H. Silverman. NTRU: a Ring based Public Key Cryptosystem. Proceedings of the 3rd Algorithmic Number Theory Symposium (ANTS
1998), Portland (USA), June 1998.
[106] M. O. Rabin. Digitalized Signatures and Public Key Functions as Intractable
as Factorization. Technical Report MIT/LCS/TR-212, Massachusetts Institute
of Technology (1979).
[107] R. L. Rivest. The RC5 Encryption Algorithm. Proceedings of the 2nd International Workshop on Fast Software Encryption (FSE 1994), pp. 86-96, Leuven
(Belgium), December 1994.
194
[108] R. L. Rivest, M. J. B. Robshaw, R. Sidney, Y. L. Yin. The RC6 Block Cipher,
v1.1. August 1998,
http://theory.lcs.mit.edu/~rivest/
[109] X. Wang, Y. Lisa Yin, H. Yu. Finding Collisions in the Full SHA-1. Proceedings
of the 25th Annual International Cryptology Conference (CRYPTO 2005), pp.
17-36, California (USA), August 2005.
[110] M. Cochran. Notes on the Wang et al. 263 SHA-1 Differential Path. Cryptology
ePrint Archive: Report 2007/474.
[111] H. Dobbertin, A. Bosselaers, B. Preneel. RIPEMD-160, a strengthened version
of RIPEMD. Proceedings of the 3rd International Workshop on Fast Software
Encryption (FSE 1996), pp. 71-82, Cambridge (UK), February 1996.
[112] R. Rivest, A. Shamir, L. Adleman. A Method for Obtaining Digital Signatures
and Public-Key Cryptosystems. Communications of the ACM, vol. 21, no. 2, pp.
120-126, 1978.
[113] SECG - Standards for Efficient Cryptography Group.
http://www.secg.org/
[114] X. Wang, A. Yao, F. Yao. New Collision search for SHA-1. Rump Session of
the 25th Annual International Cryptology Conference (CRYPTO 2005), Santa
Barbara (USA), August 2005.
[115] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. Hall, N. Ferguson. The
Twofish Encryption Algorithm: A 128-Bit Block Cipher. Wiley, ISBN 0-47135381-7, 1999.
[116] G. Meiser. Efficient Implementation of Stream Ciphers on Embedded Processors. Master Thesis, Ruhr-University Bochum (Germany), May 2007.
[117] A. Camtepe, B. Yener. Key distribution mechanisms for wireless sensor networks: a survey. Rensselaer Polytechnic Institute, Computer Science Department, Tech. Rep. 05-07, March 2005.
[118] V. Gupta, M. Wurm, Y. Zhu, M. Millard, S. Fung, N. Gura, H. Eberle, S.
Chang Shantz. Sizzle: A Standards-based end-to-end Security Architecture for
the Embedded Internet. Pervasive and Mobile Computing Journal (special issue
on selected papers from PerCom 2005), vol. 1, no. 4, pp. 425-445, December 2005.
195
[119] R.J. Anderson, H. Chan, A. Perrig. Key Infection: Smart Trust for Smart Dust.
Proceedings of the 12th IEEE International Conference on Network Protocols
(ICNP 2004), pp 206-215, Berlin (Germany), October 2004.
[120] S. A. Camtepe, B. Yener. Combinatorial Design of Key Distribution Mechanisms for Wireless Sensor Networks. IEEE/ACM Transactions on Networking,
vol. 15, no. 2, pp. 346-358, April 2007.
[121] H. Chan, A. Perrig, D. Song. Random Key Predistribution Schemes for Sensor
Networks. Proceedings of the 2003 IEEE Symposium on Security and Privacy,
pp. 197-213, May 2003.
[122] L. Eschenauer, V.D. Gligor. A key-management scheme for distributed sensor
networks. Proceedings of the 9th ACM conference on Computer and communications security (CCS ’02), pp 41-47, Washington (USA), November 2002.
[123] B. Charles Lai, D.D. Hwang, S. Pete Kim, I. Verbauwhede. Reducing Radio
Energy Consumption of Key Management Protocols for Wireless Sensor Networks. Proceedings of the ACM/IEEE International Symposium on Low Power
Electronics and Design (ISLPED 2004), pp. 351-356, Newport (USA), August
2004.
[124] D.D. Hwang, B. Charles Lai, I. Verbauwhede. Energy-Memory-Security Tradeoffs in Distributed Sensor Networks. Proceedings of the 3rd International Conference on Ad-hoc Networks and Wireless (ADHOC-NOW 2004), pp. 70-81, Vancouver (Canada), July 2004.
[125] R.D. Pietro, L.V. Mancini, A. Mei. Random key-assignment for secure Wireless
Sensor Networks. Proceedings of the 1st ACM workshop on Security of ad hoc
and sensor networks (SASN ’03), pp 62-71, Fairfax (USA), October 2003, .
[126] W. Du, J. Deng, Y. S. Han, P. Varshney, J. Katz, A. Khalili. A Pairwise Key
Pre-distribution Scheme for Wireless Sensor Networks. ACM Transactions on
Information and System Security (TISSEC), vol. 8, no. 2, pp 228-258, May 2005.
[127] B. Dutertre, S. Cheung, J. Levy. Lightweight Key Management in Wireless
Sensor Networks by Leveraging Initial Trust. Technical Report SRI-SDL-04-02,
System Design Laboratory, SRI International, April 2004.
[128] W. Du, J. Deng, Y. S. Han, P. Varshney. A Key Predistribution Scheme for
Sensor Networks Using Deployment Knowledge. IEEE Transactions on Dependable and Secure Computing, Vol. 3, No. 2, pp 62-77, January-March 2006.
196
[129] J. Hwang, Y. Kim. Revisiting Random Key Pre-distribution Schemes for Wireless Sensor Networks. Proceedings of the 2nd ACM workshop on Security of Ad
Hoc and Sensor Networks (SASN ’04), pp 43-52, Washington (USA), October
2004.
[130] J. Lee, D.R. Stinson. Deterministic Key Predistribution Schemes for Distributed Networks. 11th International Workshop on Selected Areas in Cryptography (SAC 2004). Canada, August 2004. Revised Selected Papers published in
Lecture Notes in Computer Science 3357 (2005), pp 294-307.
[131] D. Liu, P. Ning. Improving Key Pre-Distribution with Deployment Knowledge
in Static Sensor Networks. ACM Transactions on Sensor Networks (TOSN), vol.
1, no. 2, pp. 204-239, November 2005.
[132] D. Liu, P. Ning, R. Li. Establishing Pairwise Keys in Distributed Sensor Networks. ACM Transactions on Information and System Security, vol. 8, no. 1, pp.
41-77, February 2005.
[133] S. Zhu, S. Xu, S. Setia, S. Jajodia. Establishing Pairwise Keys for Secure
Communication in Ad hoc Networks: A Probabilistic Approach. Proceedings of
the 11th IEEE International Conference on Network Protocols (ICNP’03), pp.
326-335, Atlanta (USA), November 2003.
[134] Y. H. Kim, M. H. Kim, D. H. Lee, C. Kim. A Key Management Scheme for
Commodity Sensor Networks. Proceedings of the 4th International Conference
on Ad-Hoc, Mobile, and Wireless Networks (ADHOC-NOW’05), pp 113-126,
Cancun (Mexico), October 2005.
[135] Z. Yu, Y. Guan. A key pre-distribution scheme using deployment knowledge
for wireless sensor networks. Proceedings of the 4th International Symposium on
Information Processing in Sensor Networks (IPSN’05), pp. 261-268, Los Angeles
(USA), April 2005.
[136] Y. Zhou, Y. Zhang, Y. Fang. LLK: a link-layer key establishment scheme for
wireless sensor networks. Proceedings of the IEEE Wireless Communications and
Networking Conference (WCNC’05), pp. 1921-1926 (vol. 4), New Orleans (USA),
March 2005.
[137] M. Mehta, D. Huang, L. Harn. RINK-RKP: A Scheme for Key Predistribution and Shared-Key Discovery in Sensor Networks. Proceedings of the 24th
IEEE International Performance Computing and Communications Conference
(IPCCC’05), pp. 193-197, Phoenix (USA), April 2005.
197
[138] H. Chan, A. Perrig. PIKE: Peer Intermediaries for Key Establishment in Sensor Networks. Proceedings of the 24th Conference of the IEEE Communications
Society (Infocom’05), pp. 524-535 (vol. 1), Miami (USA), March 2005.
[139] T. Ito, H. Ohta, N. Matsuda, T. Yoneda. A key pre-distribution scheme for
secure sensor networks using probability density function of node deployment.
Proceedings of the 3rd ACM workshop on Security of ad hoc and sensor networks
(SASN’05), pp. 69-75, November 2005.
[140] S. Zhu, S. Setia, S. Jajodia. LEAP: Efficient Security Mechanisms for LargeScale Distributed Sensor Networks. Proceedings of the ACM Conference on Computer and Communications Security (CCS ’03), pp. 62-72, Washington (USA),
October 2003.
[141] X. Huang, M. Yang. Secure Key Management Protocol for Wireless Sensor Network Based on Dynamic Cluster. Proceedings of the 49th Annual IEEE GLOBECOM 2006, pp. 1-6, San Francisco (USA), Nov.-Dec. 2006.
[142] B. Panja, S. Madria, B. Bhargava. Energy and Communication Efficient Group
Key Management Protocol for Hierarchical Sensor Networks. Proceedings of the
IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy
Computing (SUTC’06), pp. 384-393, Taichung (Taiwan), June 2006.
[143] Public-Key Infrastructure (X.509) (pkix) Charter.
http://www.ietf.org/html.charters/pkix-charter.html
[144] R. Housley, W. Polk, W. Ford, D. Solo. RFC 3280: Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Request
for Comments, April 2002.
[145] I. Akyildiz, D. Pompili and T. Melodia. Underwater acoustic sensor networks:
Research challenges. Ad Hoc Networks Jounal (Elsevier), vol. 3, no. 3, pp. 257279, May 2005.
[146] Atmega128L Datasheet.
http://www.atmel.com/dyn/resources/prod_documents/2467S.pdf.
[147] R. Brent. Some integer factorization algorithms using elliptic curves. Australian Computer Science Communications (8), pp. 149-163, 1986.
[148] B.B. Brumley. Efficient three-term simultaneous elliptic scalar multiplication
with applications. Proceedings of the 11th Nordic Workshop on Secure IT Systems
(NordSec ’06), pp. 105-116, Linköping (Sweden), October 2006.
198
[149] L. Chen, Z. Cheng, N.P. Smart. Identity-based key agreement protocols from
pairings. Int. J. Inf. Sec., vol. 6, no. 4, pp. 213-241, 2007.
[150] R. Dupont, A. Enge. Provably secure non-interactive key distribution based on
pairings. Discrete Applied Mathematics, vol. 154, no. 2, pp. 270-276, 2006.
[151] A. Menezes, D. Hankerson, S. Vanstone. Guide to Elliptic Curve Cryptography.
Springer-Verlag, 2004.
[152] M. Girault. Self-certified public keys. In EUROCRYPT, vol. 574, pp. 490-497,
1991.
[153] S.D. Galbraith, K.G. Paterson, N.P. Smart. Pairings for cryptographers. Cryptology ePrint Archive, Report 2006/165, 2006. http://eprint.iacr.org/.
[154] IEEE P802.15 Working Group for Wireless Personal Area Networks. Mandatory
ECC Security Algorithm Suite. http://ieee802.org/15/index.html
[155] LinkQuest Inc. Underwater acoustic modems. http://www.link-quest.com/,
2007.
[156] D. H. Lehmer. Euclids algorithm for large numbers. Amer. Math. Monthly, vol.
45, no. 4, pp. 227-233, April 1938.
[157] L. Law, A. Menezes, M. Qu, J. Solinas, S.A. Vanstone. An efficient protocol
for authenticated key agreement. Des. Codes Cryptography, vol. 28, no. 2, pp.
119-134, 2003.
[158] A. Menezes, M. Qu, S. Vanstone. Some new key agreement protocols providing
mutual implicit authentication. Proceedings of the 2nd Workshop on Selected
Areas in Cryptography (SAC 95), 1995.
[159] A. Menezes, P. van Oorschot, S. Vanstone. Handbook of Applied Cryptography. Discrete Mathematics and its Applications. CRC Press, 1997. Available at
http://www.cacr.math.uwaterloo.ca/hac/.
[160] H. Petersen, P. Horster. Self-certified keysconcepts and applications. Proceedings of Communications and Multimedia Security’97, pp. 102-116, 1997.
[161] M. Scott. Deterministic hashing to points on IBE-friendly elliptic curves, 2005.
[162] A. Shamir. Identity-based cryptosystems and signature schemes. Proceedings of
CRYPTO 84 on Advances in cryptology, pp. 47-53, Santa Barbara (California),
1985.
199
[163] R. Sakai, K. Ohgishi and M. Kasahara. Cryptosystems based on pairing over
elliptic curve (in japanese). Proceedings of the 2001 Symposium on Cryptography
and Information Security, Oiso (Japan), 2001.
[164] P. Szczechowiak, L.B. Oliveira, M. Scott, M. Collier and R. Dahab. Nanoecc:
Testing the limits of elliptic curve cryptography in sensor networks. Proceedings
of the European conference on Wireless Sensor Networks (EWSN’08), pp. 305320, Bologna (Italy), January-February 2008.
[165] Strauss. Addition chains of vectors. American Mathematical Monthly, vol. 71,
no. 7, pp. 806-808, Aug.-Sept. 1964.
[166] Accredited Standards Committee X9. American national standard x9.62-2005,
public key cryptography for the financial services industry, the elliptic curve digital
signature algorithm (ecdsa), 2005.
[167] J. N. Al-Karaki, A. E. Kamal. Routing Techniques in Wireless Sensor Networks: A Survey. IEEE Wireless Communications, vol. 11, no. 6, pp. 6-28, December 2004.
[168] K. Akkaya, M. Younis. A Survey on Routing Protocols for Wireless Sensor
Networks. Ad Hoc Networks Journal (Elsevier), vol. 3, no. 3, pp. 325-349, May
2005.
[169] E. Fasoloy, M. Rossiy, J. Widmer, M. Zorziy. In-network Aggregation Techniques for Wireless Sensor Networks: A Survey. IEEE Wireless Communications,
vol. 14, no. 2, pp. 70-87, April 2007.
[170] H. Luo, Y. Liu, S.K. Das. Routing Correlated Data in Wireless Sensor Networks: A Survey. IEEE Network, vol. 21, no. 6, pp. 40-47, Nov.-Dec. 2007.
[171] R. Rajagopalan, P.K. Varshney Data Aggregation Techniques in Sensor Networks: A Survey. IEEE Communications Survey, vol. 8, no. 4, 4th quarter 2006.
[172] B. Sundararaman, U. Buy, A.D. Kshemkalyani. Clock Synchronization for
Wireless Sensor Networks: A Survey. Ad hoc Networks Journal (Elsevier), vol.
3, no. 3, pp. 281-323, May 2005.
[173] Ya. R. Faizulkhakov. Time Synchronization Methods for Wireless Sensor Networks: A Survey. Programming and Computer Software (Pleiades), vol. 33, no.
4, pp. 214-226, 2007.
200
[174] C. Karlof, D. Wagner. Secure Routing in Wireless Sensor Networks: Attacks
and Countermeasure. Ad-Hoc Networks, vol. 1, no. 2-3, pp. 293-315, Elsevier,
September 2003.
[175] G. Ács, L. Buttyán. Secure Routing in Wireless Sensor Networks. On Wireless
Sensor Network Security, IOS Press. ISBN: 978-1-58603-813-7.
[176] Y. Sang, H. Shen, Y. Inoguchi, Y. Tan, N. Xiong. Secure Data Aggregation in
Wireless Sensor Networks: A Survey. Proceedings of the 7th International Conference on Parallel and Distributed Computing, Applications and Technologies
(PDCAT 2006), pp. 315-320, Taipei (Taiwan), December 2006.
[177] H. Alzaid, E. Foo, J.G. Nieto. Secure Data Aggregation in Wireless Sensor
Network: a Survey. Proceedings of the Australasian Information Security Conference 2008: Conferences in Research and Practice in Information Technology
(CRPIT). March 2008.
[178] M. Manzo, T. Roosta, S. Sastry. Time Synchronization Attacks in Sensor Networks. Proceedings of the 3th ACM Workshop on Security of Ad Hoc and Sensor
Networks (SASN 2005), pp. 107-116, Alexandria, (USA), November 2005.
[179] A. Boukerche, D. Turgut. Secure time synchronization protocols for wireless
sensor networks. IEEE Wireless Communications, vol. 14, no. 5, pp. 64-69, October 2007.
[180] R.J. Goldberg, C. O’Donnell, J. Yarzebski, et al. Sex differences in symptom
presentation associated with acute myocardial infarction: a population-based perspective. Am Heart Journal, vol. 136, no. 2, pp 189-195, 1998.
[181] C. Hsin, M. Liu. A distributed monitoring mechanism for wireless sensor networks. Proceedings of the 3rd ACM workshop on Wireless Security (WiSe 2002),
pp. 57-66, Atlanta (USA), September 2002.
[182] S. Rost, H. Balakrishnan. Memento: A Health Monitoring System for Wireless
Sensor Networks. Proceedings of the 3rd IEEE Conference on Sensor, Mesh, and
Ad Hoc Communications and Networks (SECON 2006), pp. 575-584, Reston
(USA), September 2006.
[183] A. Patwardhan, J. Parker, A. Joshi, M. Iorga, T. Karygiannis. Secure Routing
and Intrusion Detection in Ad Hoc Networks. Proceedings of the 3rd IEEE International Conference on Pervasive Computing and Communications (PerCom’05),
pp. 191-199, Hawaii (USA), March 2005.
201
[184] I. Onat, A. Miri. An Intrusion Detection System for Wireless Sensor Networks.
Proceedings of the IEEE International Conference on Wireless and Mobile Computing, Networking and Communicatons (WiMOB 2005), pp. 253-259, Montreal
(Canada), August 2005.
[185] P. Inverardi, L. Mostarda, A. Navarra. Distributed IDS for enhancing Security
in Mobile Wireless Sensor Networks. Proceedings of the 20th International Conference on Advanced Information Networking and Applications (AINA 2006), pp.
116-120 (vol. 2), Vienna (Austria), April 2006.
[186] W. Xu, W. Trappe, Y. Zhang, T. Wood. The Feasibility of Launching and
Detecting Jamming Attacks in Wireless Networks. Proceedings of the 6th ACM
international symposium on Mobile ad hoc networking and computing (MOBIHOC’06), pp. 46-57, Urbana-Champaign (USA), 2005.
[187] C. C. Su, K. M. Chang, Y. H. Kuo, M. F. Horng. The New Intrusion Prevention
and Detection Approaches for Clustering-based Sensor Networks. Proceedings of
the IEEE Wireless Communications and Networking Conference (WCNC 2005),
pp. 1924-1932 (vol. 4), New Orleans (USA), March 2005.
[188] C. Basile, M. Gupta, Z. Kalbarczyk, R. K. Iyer. An Approach for Detecting and
Distinguishing Errors versus Attacks in Sensor Networks. Proceedings of the 2006
International Conference on Dependable Systems and Networks (DSN 2006), pp.
473-484, Philadelphia (USA), June 2006.
[189] J. Pincus, B. Baker. Beyond Stack Smashing: Recent Advances in Exploiting
Buffer Overruns. IEEE Security & Privacy, vol. 2, no. 4, July 2004.
[190] J. Regehr, N. Cooprider, W. Archer, E. Eide. Efficient Type and Memory Safety
for Tiny Embedded Systems. Proceedings of the 3rd Workshop on Programming
Languages and Operating Systems (PLOS 2006), San Jose (USA), October 2006.
[191] S. Kaplantzis, N. Mani. A Study on Classification Techniques for Network Intrusion Detection. Proceedings of the IASTED International Conference on Networks and Communication Systems (NCS 2006), Chiang Mai (Thailand), March
2006.
[192] J. Beale. the Snort Development Team. Snort 2.1, Intrusion Detection, 2nd
Edition. Syngress Publishing, May 2004.
[193] F. Stajano, R. Anderson. The Resurrecting Duckling: security issues for ubiquitous computing. IEEE Computer, vol. 35, no. 4, April 2002.
202
[194] T. Anantvalee and J. Wu. A Survey on Intrusion Detection in Mobile Ad Hoc
Networks. Wireless/Mobile Network Security. Y. Xiao, X. Shen, and D.Z. Du
(eds.), Springer, December 2006.
[195] F. Anjum, D. Subhadrabandhu, S. Sarkar, R. Shetty. On Optimal Placement
of Intrusion Detection Modules in Sensor Networks. Proceedings of the 1st International Conference on Broadband Networks (BROADNETS 2004), pp. 690-699,
San Jose (USA), October 2004.
[196] S. Cheung, B. Dutertre, U. Lindqvist. Detecting Disruptive Routers in Wireless
Sensor Networks. In Proceedings of the 5th International Conference on AD-HOC
Networks & Wireless (ADHOC-NOW 2006), pp. 19-31, Ottawa (Canada), August
2006.
[197] S. S. Doumit, D. P. Agrawal. Self-Organized Criticality & Stochastic Learning
based Intrusion Detection System for Wireless Sensor Networks. In Proceedings
of the IEEE Military Communications Conference (MILCOM 2003), Cincinatti
(USA), October 2003.
[198] W. Du, L. Fang, P. Ning. LAD: Localization Anomaly Detection for Wireless
Sensor Networks. Journal of Parallel and Distributed Computing (JPDC), vol.
66, no. 7, pp 874-886, July 2006.
[199] I. Khalil, S. Bagchi, C. Nina-Rotaru. DICAS: Detection, Diagnosis, and Isolation of Control Attacks in Sensor Networks. Proceedings of the 1st International
Conference on Security and Privacy for Emerging Areas in Communication Networks (SecureComm 2005), pp. 89-100, Athens (Greece), September 2005.
[200] A.P.R. da Silva, M.H.T. Martins, B.P.S. Rocha, A.A.F. Loureiro, L.B. Ruiz,
H.C. Wong. Decentralized Intrusion Detection in Wireless Sensor Networks. Proceedings of the 1st ACM International Workshop on Quality of Service & Security in Wireless and Mobile Networks (Q2SWinet 2005), pp. 16-23, Montreal
(Canada), October 2005.
[201] Q. Zhang, T. Yu, P. Ning. A Framework for Identifying Compromised Nodes
in Sensor Networks. Proceedings of the 2nd International Conference on Security and Privacy in Communication Networks (SECURECOMM’06), pp. 1-10,
Baltimore (USA), Aug.-Sept. 2006.
[202] Y. Zhang and W. Lee. Intrusion Detection Techniques for Mobile Wireless
Networks. ACM/Kluwer Wireless Networks Journal, vol. 9, no. 5, pp. 545-556,
September 2003.
203
[203] B. Bloom. Space/Time Trade-offs in Hash Coding with Allowable Errors. Communications of the ACM, vol. 13, no. 7, pp. 422-426, July 1970.
[204] A. Abdul-Rahman, S. Hailes. Supporting Trust in Virtual Communities. Proceedings of the 33rd Hawaii International Conference on System Sciences, pp. 9,
Hawaii (USA), January 2000.
[205] M. Blaze, J. Feigenbaum, J. Lacy. Decentralized Trust Management. Proceedings of the 1996 IEEE Symposium on Security and Privacy, p. 164, 1996.
[206] M. Blaze, J. Feigenbaum, A. D. Keromytis. KeyNote: Trust Management for
Public-Key Infrastructures (position paper). Proceedings of the 6th International
Workshop on Security Protocols, p. 625, Cambridge (UK), April 1998.
[207] S. Ruohomaa, L. Kutvonen. Trust Management Survey. Proceedings of the
3rd International Conference on Trust Management (iTrust’05), pp. 77-92, Paris
(France), May 2005.
[208] H. Chen, H. Wu, X. Zhou, C. Gao. Reputation-based Trust in Wireless Sensor
Networks. Proceedings of the 2007 International Conference on Multimedia and
Ubiquitous Engineering (MUE’07), pp. 603-607, Seoul (Korea), April 2007.
[209] Y.-H. Chu, J. Feigenbaum, B. LaMacchia, P. Resnick, M. Strauss. REFEREE:
Trust Management for Web Applications. Computer Networks and ISDN Systems, vol. 29, pp. 953-964, 1997.
[210] G. V. Crosby, N. Pissinou, J. Gadze. A Framework for Trust-based Cluster
Head Election in Wireless Sensor Networks. Proceedings of the Second IEEE
Workshop on Dependability in Sensor Networks and Systems (DSSNS’06), 2006.
[211] M. Krasniewski, P. Varadharajan, B. Rabeler, S. Bagchi, Y. Charlie Hu. Tibfit:
Trust index based fault tolerance for arbitrary data faults in sensor networks. Proceedings of the International Conference on Dependable Systems and Networks
(DSN’05), pp. 672-681, Los Alamitos (USA), 2005.
[212] A. Jøsang, R. Ismail. The beta reputation system. Proceedings of the 15th Bled
Electronic Commerce Conference e-Reality: Constructing the e-Economy, Bled
(Slovenia), June 2002.
[213] A. Jøsang, R. Ismail, C. Boyd. A Survey of Trust and Reputation Systems for
Online Service Provision. Decision Support Systems, vol. 43, no. 2, 2006.
204
[214] S. D. Kamwar, M. T. Schlosser, H. Garcia-Molina. The eigentrust algorithm for
reputation management in p2p networks. Proceedings of the 12th International
Conference on World Wide Web (WWW’03), pp. 640-651, Budapest (Hungary),
2003.
[215] A. Lawen. Apoptosis - An Introduction. BioEssays, vol. 25, no. 9, pp 888-896,
2003.
[216] Z. Liu, A. W. Joy, and R. A. Thompson. A Dynamic Trust Model for Mobile Adhoc Networks. Proceedings of the 10th IEEE International Workshop on Future
Trends of Distributed Computing Systems, pp. 80-85, Suzhou (China), May 2004.
[217] J. Lopez. Unleashing public-key cryptography in wireless sensor networks. Journal of Computer Security, vol. 14, no. 5, pp. 469-482, 2006.
[218] Y. Rebahi, V. E. Mujica-V, D. Sisalem. A Reputation-Based Trust Mechanism
for Ad-hoc Networks. Proceedings of the 10th IEEE Symposium on Computers
and Communications (ISCC 2005), pp. 37-42, La Manga del Mar Menor (Spain),
June 2005.
[219] H. Zhu, F. Bao, K. Kim. Computing of Trust in Wireless Networks. Proceedings
of the 60th IEEE Vehicular Technology Conference, pp. 2621-2624 (vol. 4), Los
Angeles (California), September 2004.
[220] J. Sabater, C. Sierra. REGRET: A Reputation Model for Gregarious Societies.
Proceedings of the 4th Workshop on Deception Fraud and Trust in Agent Societies, ACM Press, 2001.
[221] R. A. Shaik, H. Jameel, S. Lee, S. Rajput, Y.J. Song. Trust Management
Problem in Distributed Wireless Sensor Networks. Proceedings of the 12th International Conference on Embedded and Real-Time Computing Systems and
Applications (RTCSA’06), pp. 411-414, Sydney (Australia), 2006.
[222] R. Sherwood, L. Seungjoon, B. Bhattacharjee. Cooperative peer groups in nice.
Computer Networks, vol. 50, no. 4, pp. 523-544, 2006.
[223] A. Srinivasan, J. Teitelbaum, H. Liang, J. Wu, and M. Cardei. Reputation and
Trust-based Systems for Ad Hoc and Sensor Networks. In A. Boukerche, editor,
On Trust Establishment in Mobile Ad-Hoc Networks. Wiley & Sons, 2007.
[224] S. Tanachaiwiwat, P. Dave, R. Bhindwale, and A. Helmy. Location-centric Isolation of Misbehavior and Trust Routing in Energy-Constrained Sensor Networks.
205
Proceedings of the IEEE Conference on Performance, Computing and Communications (IPCCC’04), pp. 463-469, Phoenix (USA), April 2004.
[225] Z. Yan, P. Zhang, and T. Virtanen. Trust Evaluation Based Security Solutions
in Ad-hoc Networks. Proceedings of the Seventh Nordic Workshop on Security IT
Systems (NordSec’03), 2003.
[226] G. Zacharia and P. Maes. Trust management through reputation mechanisms.
Applied Artificial Intelligence, vol. 14, no. 9, pp. 881-907, 2000.
[227] W. Zhang, S. Das, and Y. Liu. A Trust Based Framework for Secure Data
Aggregation in Wireless Sensor Networks. Proceedings of the IEEE SECON 2006,
pp. 60-69, Reston (USA), September 2006.
[228] Z.Yao, D. Kim, I. Lee, K. Kim, and J. Jang. A Security Framework with Trust
Management for Sensor Networks. Proceedings of the Workshop of the 1st International Conference on Security and Privacy for Emerging Areas in Communication Networks (SECURECOMM’05), pp. 190-198, Athens (Greece), 2005.
[229] T. Braun, T. Voigt, A. Dunkels. TCP support for sensor networks. Proceedings
of the Fourth Annual Conference on Wireless on Demand Network Systems and
Services (WONS 2007), pp. 162-169, Obergurgl (Austria), January 2007.
[230] R. Dickerson, J. Lu, J. Lu, K. Whitehouse. Stream Feeds: an Abstraction for
the World Wide Sensor Web. Proceedings of the Conference on the Internet of
Things (IOT 2008), pp. 360-375, Zurich (Switzerland), March 2008.
[231] T. Dierks, E. Rescorla. RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1, Request for Comments, April 2006.
[232] M. Domingues, C. Friaças, and P. Veiga. Is global IPv6 deployment on track?,
Internet Research, vol. 17, no. 5, pp. 505-518, 2007.
[233] P. Eronen, H. Tschofenig. RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS), Request for Comments, December 2005.
[234] ISA. ISA100.11a, Release 1. Available at: http://www.isa.org/isa100/
[235] G. Kambourakis, E. Klaoudatou, S. Gritzalis. Securing Medical Sensor Environments: The CodeBlue Framework Case. Proceedings of the Second International Conference on Availability, Reliability and Security (ARES 2007), pp.
637-643, Vienna (Austria), April 2007.
206
[236] A. Kansal, S. Nath, J. Liu, F. Zhao. SenseWeb: An Infrastructure for Shared
Sensing, IEEE Multimedia, vol. 14, no. 4, pp. 8-13, 2007.
[237] M.R. Kosanovic, M.K. Stojcev. Implementation of TCP/IP Protocols in Wireless Sensor Networks. Proceedings of the XLII International Scientific Conference
on Information, Communication and Energy Systems and Technologies, (ICEST
2007), pp. 143-146, Ohrid (Macedonia), 2007.
[238] N. Kushalnagar, G. Montenegro, C. Schumacher. RFC 4919: IPv6 over LowPower Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals. Request for Comments, August 2007.
[239] T. Luckenbach, P. Gober, S. Arbanowski, A. Kotsopoulos, K. Kim. TinyREST
- a Protocol for Integrating Sensor Networks into the Internet. Proceedings of
the First Workshop on Real-World Wireless Sensor Networks (REALWSN 2005),
Stockholm, Sweden.
[240] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. RFC 4944: Transmission of
IPv6 Packets over IEEE 802.15.4 Networks. Request for Comments, September
2007.
[241] C. Neuman, T. Yu, S. Hartman, K. Raeburn. RFC 4129: The Kerberos Network
Authentication Service (V5). Request for Comments, July 2005.
[242] OASIS Web Services Secure Exchange TC (2007). OASIS Standard: WSSecureConversation 1.3.
Available at: http://www.oasis-open.org/committees/ws-sx/
[243] G. Privat (2006). From Smart Devices to Ambient Communication. Workshop
’From RFID to the Internet of Things’, Brussels, Belgium. Available at:
http://cordis.europa.eu/ist/audiovisual/neweve/e/conf6-70306/conf6-70306.htm
[244] B. Priyantha, A. Kansal, M. Goraczko, F. Zhao. Tiny Web Services for Sensor
Device Interoperability. Proceedings of the ACM/IEEE International Conference
on Information Processing in Sensor Networks (IPSN 2008), St. Louis, USA.
[245] Sensinode Ltd. (2008). Nanostack, a 6lowpan implementation. Available at:
http://www.sensinode.com
[246] M. Welsh. Extending the Internet Architecture to Sensor Networks: Some Open
Questions. Microsoft Research Sensor Networks Workshop 2005. Available at:
http://www.eecs.harvard.edu/~mdw/
207
[247] R. Roman, J. Lopez. Integrating Wireless Sensor Networks and the Internet:
A Security Analysis. Internet Research. Submitted for evaluation.
[248] R. Roman, J. Lopez, S. Gritzalis. Situation Awareness Mechanisms for Wireless
Sensor Networks. IEEE Communications Magazine. Vol. 46, no. 4 (2008), pp 102107.
[249] R. Roman, C. Alcaraz, J. Lopez. A Survey of Cryptographic Primitives and
Implementations for Hardware-Constrained Sensor Network Nodes. Mobile, Networks and Applications (MONET) Journal, Springer. Vol. 12, no 4 (2007), pp
231-244.
[250] D. Galindo, R. Roman, J. Lopez. An Evaluation of the Energy Cost of Authenticated Key Agreement in Wireless Sensor Networks. Proceedings of the X Spanish
Meeting on Cryptology and Information Security (RECSI’08), Salamanca, Spain.
[251] R. Roman, C. Alcaraz, N. Sklavos. On the Hardware Implementation Efficiency
of Cryptographic Primitives. On Wireless Sensor Network Security, IOS Press.
ISBN: 978-1-58603-813-7.
[252] R. Roman, M.C. Fernandez-Gago, J. Lopez, H.H. Chen. Trust and Reputation
Systems for Wireless Sensor Networks. On Security and Privacy in Mobile and
Wireless Networking, Troubador Publishing Ltd. ISBN: 978-1905886-906.
[253] R. Roman, M.C. Fernandez-Gago, J. Lopez. Featuring Trust and Reputation
Management Systems for Constrained Hardware Devices. Proceedings of the 1st
International Conference on Autonomic Computing and Communication Systems
(Autonomics 2007), Rome (Italy), October 2007.
[254] M.C. Fernandez-Gago, R. Roman, J. Lopez. A Survey on the Applicability of
Trust Management Systems for Wireless Sensor Networks. Proceedings of the
3rd International Workshop on Security, Privacy and Trust in Pervasive and
Ubiquitous Computing (SecPerU 2007), pp. 25-30, Istanbul (Turkey), July 2007.
[255] R. Roman, C. Alcaraz. Applicability of Public Key Infrastructures in Wireless
Sensor Networks. Proceedings of the 2007 European PKI Workshop: Theory and
Practice (EuroPKI’07), pp. 313-320, Mallorca (Spain), June 2007.
[256] C. Alcaraz, R. Roman. Applying Key Infrastructures for Sensor Networks in
CIP/CIIP Scenarios. Proceedings of the 1st International Workshop on Critical Information Infrastructures Security (CRITIS 2006), pp. 166-178, Samos
(Greece), August-September 2006.
208
[257] J. Lopez, J.A. Montenegro, R. Roman. Service-Oriented Security Architecture
for CII based on Sensor Networks. 2nd International Workshop on Security, Privacy and Trust in Pervasive and Ubiquitous Computing (SecPerU 2006), pp. 1-6,
Lyon (France), June 2006.
[258] R. Roman, J. Zhou, J. Lopez. Applying Intrusion Detection Systems to Wireless
Sensor Networks. Proceedings of the 3rd IEEE Consumer Communications and
Networking Conference (CCNC 2006), pp. 640-644, Las Vegas (USA), January
2006.
[259] R. Roman, J. Zhou, J. Lopez. On the Security of Wireless Sensor Networks.
Proceedings of 2005 ICCSA Workshop on Internet Communications Security, pp
681-690, LNCS 3482, Singapur, May 2005.
[260] D. Garrido-Marquez, P. Plaza-Tron, R. Roman, N. Sanz-Martin, J.L. SerranoMartin. Middleware seguro P2P para dispositivos de baja capacidad. Telecom I+D
2008, Submitted for evaluation.
[261] C. Alcaraz, R. Roman. Análisis de Primitivas Criptográficas para Redes de
Sensores. VI Jornadas de Ingenierı́a Telemática (JITEL’07), Malaga, Septiembre
2007.
[262] R. Roman, J. Lopez, J. Zhou. Aplicación de Sistemas de Detección de Intrusiones en Redes de Sensores. Simposio sobre Computación Ubicua e Inteligencia
Ambiental (UCAmI’05), pp 113-120, Granada, Septiembre 2005.
[263] R. Roman, J. Lopez, J. Zhou. Análisis de seguridad en redes inalámbricas de
sensores. V Jornadas de Ingenierı́a Telemática (JITEL’05), pp 335-342, Vigo,
Septiembre 2005.