II.2 Seguridad en redes inal´ ambricas de sensores
II.2.2 Consideraciones de seguridad en la redes inal´ ambricas de sensores
Las medidas de seguridad y protocolos de cifrado de las redes inal´ambricas de sensores no deben ser consideradas iguales a la de otros tipos de redes. Existen ciertas carac- ter´ısticas en las redes inal´ambricas de sensores que hay que tomar en cuenta al dise˜nar medidas o protocolos de seguridad, y son las siguientes (Karl y Willig, 2005):
• La infraestructura de una red inal´ambrica de sensores est´a constituida de nodos diminutos y baratos, los cuales se distribuyen sobre una ´area que puede ser hostil. Al contrario de otras redes, generalmente es imposible el prevenir que los atacantes tengan acceso f´ısico a los nodos sensores. Esto usualmente se le conoce como captura de nodo. Es razonable suponer que el atacante puede lograr obtener el control total de un nodo capturado, y que puede leer su memoria o influir en el funcionamiento del software del nodo. Se necesitar´ıan dispositivos especiales de memoria segura para impedir al atacante de leer la memoria, sin embargo, ´estos raramente estar´an presentes en nodos sensores de bajo costo.
• Las limitaciones en cuanto a las capacidades de memoria y c´omputo son un fuerte obst´aculo para la implementaci´on de algoritmos criptogr´aficos. Especialmente los cifradores de llave asim´etrica son considerados muy costosos para los peque˜nos procesadores, y esto sin contar la gesti´on de llaves.
• Cuando se realiza el procesamiento intra-red, los nodos intermediarios deben te- ner acceso y modificar la informaci´on contenida en los paquetes. Por ende, un gran n´umero de partes deben estar involucradas en las transferencias de infor- maci´on seguras de extremo a extremo, lo cual complica el dise˜no de protocolos de seguridad.
• La cantidad finita de energ´ıa de los nodos sensores abre una nueva l´ınea de ataques. Este ataque consiste en forzar a los nodos sensores v´ıctimas a gastar su energ´ıa limitada m´as r´apidamente y quedar fuera de funcionamiento.
Un reto adicional mencionado por Sch¨afer (2004), es que los atacantes puedan tener mucha m´as energ´ıa a su disposici´on que los nodos sensores. Ya que las medidas de seguridad llevadas a cabo por el nodo sensor requieren energ´ıa adicional, y el estresar al nodo por medio de ataques va a llevarlo a agotar su energ´ıa m´as pronto de lo planeado originalmente, ocasionando una negaci´on de servicio.
II.2.3
Protocolos propuestos para seguridad en redes inal´ambricas
de sensores
En esta secci´on hablaremos de algunas de las propuestas y soluciones de seguridad m´as citadas en la literatura, estas van desde propuestas para seguridad en la capa de enlace de datos, hasta protocolos de gesti´on de llaves.
SNEP
SNEP (Perriget al., 2001b) usa cifrado de datos para lograr la confidencialidad y c´odigo de autenticaci´on de mensaje (MAC en ingl´es) con el fin de lograr la autenticaci´on e integridad en la comunicaci´on entre dos partes. Aparte de la confidencialidad, otra propiedad importante de seguridad es seguridad sem´antica, la cual asegura que alguien que husmee la red no obtenga informaci´on del texto claro, incluso si ve m´ultiples textos cifrados del mismo texto claro. Para lograr lo anterior, SNEP usa la t´ecnica de aleato- riedad, en la cual aparte de cifrar los mensajes con un cifrador de mensaje variable se le agrega una cadena de datos aleatoria (llamada vector de inicializaci´on IV). SNEP usa un contador compartido entre las partes de la comunicaci´on del cifrador de bloque
en modo CTR 1 como la cadena de bits aleatoria. SNEP ofrece las siguientes propie-
dades: seguridad sem´antica, autenticaci´on de datos, frescura de datos, bajo overhead de comunicaci´on.
µTESLA
Muchas de las propuestas para la autenticaci´on del broadcast resultan impr´acticas para su aplicaci´on en las redes de sensores. Esto se debe a que se basan en firmas digitales asim´etricas para lograr la autenticaci´on. El protocolo TESLA provee una manera de hacerlo eficientemente (Perrig et al., 2001a), pero tiene el inconveniente que no fue dise˜nado para ambientes con recursos de c´omputo muy limitados. µTESLA (Perrig et al., 2001b) resuelve estos inconvenientes de TESLA para las redes de sensores:
• TESLA provee autenticaci´on al paquete inicial mediante una firma digital, la cual es muy demandante para las redes de sensores. µTESLA utiliza solo mecanismos de cifrado sim´etrico.
• La revelaci´on de la llave en cada paquete requiere de demasiada energ´ıa para mandar y recibir. µTESLA realiza la revelaci´on de llave una vez cada cierto intervalo de tiempo.
• Ya que es demasiado demandante el almacenar una cadena de llave de un solo sentido en un nodo sensor. µTESLA restringe el n´umero de nodos fuente a au- tenticar.
µTESLA usa autenticaci´on sim´etrica pero introduce asimetr´ıa a trav´es de una reve- laci´on de llaves de las llaves sim´etricas, lo cual resulta en un esquema de autenticaci´on de broadcast eficiente. Para que la estaci´on base realice un broadcast con autenticaci´on a 1CTR es un modo de cifrado que utiliza un cifrador de bloque y un contador, para m´as informaci´on
los nodos,µTESLA requiere que la estaci´on base y los nodos tengan una sincronizaci´on de tiempo d´ebil, y que cada nodo conozca el l´ımite superior del error de sincronizaci´on.
SPINS Security Protocols for Sensor Networks
SPINS (Perriget al., 2001b) es un paquete con bloques de seguridad para la construcci´on de aplicaciones con seguridad en las redes inal´ambricas de sensores. Est´a optimizada para ambientes con recursos limitados y comunicaciones inal´ambricas. SPINS tiene dos bloques de construcci´on: SNEP y µTESLA. SNEP provee confidencialidad de datos, autenticaci´on de datos de dos partes, y frescura de datos,µTESLA provee un broadcast con autenticaci´on para varios ambientes con recursos limitados.
Todas las primitivas criptogr´aficas (cifrado, c´odigos MAC, operaci´on hash, generador de n´umeros aleatorios) son construidas a partir de un solo cifrador de bloque para as´ı ahorrar c´odigo. Esto junto con las primitivas de cifrado sim´etricas que se utilizan, reducen el overhead para su uso en las redes de sensores. En un medio de transmisi´on por broadcast tales como las redes de sensores, la autenticaci´on de datos a trav´es de un mecanismo sim´etrico no se puede aplicar al menos que todos los receptores conozcan la llave. µTESLA construye un broadcast con autenticaci´on con ayuda de primitivas sim´etricas, pero introduce asimetr´ıa con tiempo de revelaci´on de llave (”delayed key disclosure” en ingl´es) y funciones de cadena de llave de un solo sentido (”one-way function key chains” en ingles).
TinySec
TinySec (Karlof et al., 2004) es un paquete de seguridad gen´erico y ligero el cual se puede integrar a las aplicaciones de redes de sensores. Este paquete est´a incorporado en la distribuci´on oficial de TinyOS. TinySec provee las propiedades de seguridad necesa- rias para lograr autenticaci´on de mensaje e integridad (usando MAC), confidencialidad
de mensaje (a trav´es de cifrado), seguridad sem´antica (a trav´es de un vector de inicia- lizaci´on) y protecci´on contra reenv´ıo de mensajes previos.
TinySec usa un valorIV (vector de inicializaci´on) de 8 bytes y cifrado de cadenas de bloque (conocido como”CBC cipher block chaining” en ingl´es) para cifrar un mensaje de tama˜no variable.
Como cifrador de bloque se eligi´o al algoritmo llamado SkipJack, los creadores de TinySec dan razones detr´as de la elecci´on del cifrador de bloque utilizado (Karlofet al., 2004), llegando a la conclusi´on de que se debe utilizar SkipJack ya que es ligero en recursos, veloz y adem´as no est´a patentado.
TinyPK
El esquema de seguridad TinyPK (Watro et al., 2004) es un mecanismo para proveer autenticaci´on e intercambio de llaves entre una parte externa y la redes de sensores. TinyPK est´a basado en el bien conocido algoritmo de cifrado asim´etrico RSA, usando e = 3 como el exponente p´ublico. Para hacer a TinyPK pr´actico para dispositivos sensores de bajo consumo, se dise˜n´o el protocolo para que solamente se realicen las operaciones p´ublicas de llave asim´etrica en los nodos sensores.
TinyPK requiere de una m´odica cantidad de infraestructura de llave p´ublica. El primer elemento de la infraestructura es una autoridad de certificaci´on, la cual es una entidad con un par de llaves privada y p´ublica en las cuales conf´ıan todos los dem´as participantes. Cualquier agente externo que quiera participar en la red, requiere de un par de llaves p´ublica/privada y debe tener su propia llave p´ublica firmada con la llave privada de la autoridad de certificaci´on. Por ´ultimo, cada nodo sensor de la red debe
tener en si una copia de la llave p´ublica de la autoridad de certificaci´on.