Arquitectura de seguridad para la cooperación entre robots aéreos y redes de sensores

Proyecto Fin de Carrera Ingeniería de Telecomunicación Formato de Publicación de la Escuela Técnica Superior de Ingeniería Autor: F. Javier Payán Somet Tutor: Juan José Murillo Fuentes Dep. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2013 Tesis Doctoral Doctorado en Ingeniería Automática, Electrónica y de Telecomunicación Arquitectura de Seguridad para la Cooperación entre Robots Aéreos y Redes de Sensores Autor: Francisco José Fernández Jiménez Director: José Ramiro Martínez de Dios Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2023 Tesis Doctoral Doctorado en Ingeniería Automática, Electrónica y de Telecomunicación Arquitectura de Seguridad para la Cooperación entre Robots Aéreos y Redes de Sensores Autor: Francisco José Fernández Jiménez Director: José Ramiro Martínez de Dios Catedrático de Universidad Escuela Técnica Superior de Ingeniería Universidad de Sevilla 2023 A mis padres Agradecimientos Me gustaría dar las gracias a todas aquellas personas que han estado a mi lado todos los años que ha costado hacer esta Tesis Doctoral, que han sufrido conmigo y me han animado. Si tú has sido una de ellas... ¡Muchas gracias! Particularmente, quiero agradecer a mi amigo y director de Tesis Doctoral su dedicación, consejos, ideas, gestiones, correcciones, colaboración en artículos, ...Esta Tesis Doctoral no hubiera sido posible sin su ayuda y colaboración, y parte de ella le pertenece. Me gustaría dar las gracias también a todos aquellos que han ayudado en la realización de los experimentos: a Alejandro Rosa Neupavert por realizar los ataques de Red Team, a Rafael Salmoral por pilotar los robos aéreos, a todo el ŞGRVC Robotics LabŤ por facilitar los dispositivos, accesorios y software complementario necesario, y a la empresa LafargeHolcim por permitir utilizar su cementera de Jerez de la Frontera. Por último, doy las gracias a mis compañeros del Departamento de Ingeniería Telemática por su preocupación, apoyo y compañerismo, por sus enseñanzas y colaboraciones, por ayudarme con la burocracia y por facilitarme la realización de esta Tesis Doctoral. III Resumen En esta Tesis Doctoral se ha diseñado, desarrollado, implementado, experimentado y validado SNSR (Sensor Network Security using Robots), una arquitectura novedosa, abierta y Ćexible que mejora la seguridad en las redes inalámbricas de sensores estáticas al beneĄciarse de la cooperación de la red de sensores con los robots. En SNSR, los robots realizan la autenticación de nodos sensores y la localización basada en radio (lo que permite el cálculo de topología centralizado y el establecimiento de rutas) e interactúan directamente con los nodos para enviarles conĄguraciones o recibir informes de estado y anomalías sin intermediarios. El funcionamiento de SNSR se divide en etapas conĄguradas en una estructura iterativa de retroalimentación, que permite repetir la ejecución de etapas para adaptarse a cambios, responder a ataques o detectar y corregir errores. El uso de robots brinda a SNSR capacidades mejoradas de detección y mitigación de ataques, y mejora la prevención al reemplazar tareas que en las arquitecturas tradicionales son propensas a ataques o requieren información preestablecida. Esto proporciona altos niveles de seguridad y adaptabilidad sin requerir mecanismos complejos. Para implementar SNSR se ha creado un nuevo sistema operativo de red simple e independiente de la red de sensores que proporciona Ćexibilidad para probar diferentes conĄguraciones, algoritmos y protocolos, pero sin llegar a los niveles físico y de enlace. Se ha desarrollado e implementado una nueva pila de protocolos, ubicada sobre una capa de enlace existente. Esta pila de protocolos se compone de un nivel de aplicación, un nivel de transporte, un nivel de red y un nivel de adaptación al nivel de enlace. El nivel de adaptación hace que los niveles superiores sean independientes del nivel de enlace real. El nivel de aplicación permite ejecutar las aplicaciones de gestión de cada entidad siguiendo las especiĄcaciones de SNSR. Se ha realizado un análisis cualitativo de seguridad frente a 33 ataques de seguridad diferentes. Además, se ha creado una plataforma de pruebas que permita la experimentación repetible y rigorosa de nuevas tecnologías, protocolos y métodos de seguridad basados en SNSR tanto en escenarios reales como en virtualizados. Con ella se han realizado miles de experimentos con distintos escenarios virtuales y reales con robots terrestres y aéreos. Los resultados han demostrado la seguridad, eĄciencia y escalabilidad de SNSR. V XII Índice 4.5.2.1 launcher 161 4.5.2.2 launchermn 162 4.5.2.3 Comparativa entre versiones 164 4.5.3 Argumentos de los lanzadores 165 4.5.4 Descripción del escenario 166 4.5.5 Creación de la red y las entidades 172 4.5.6 Interacción con el escenario 172 4.5.7 Finalización del escenario y recopilación de datos 178 4.6 Control de escenarios de prueba en entorno real 179 4.6.1 Agente 180 4.6.2 Aplicación web 182 4.6.3 Actualizadores 185 4.7 Conclusiones 185 5 Experimentación y evaluación 187 5.1 Configuración de SNSR 188 5.2 Análisis cualitativo de seguridad 191 5.2.1 Ataques analizados 192 5.2.2 Análisis frente a jamming 194 5.2.3 Análisis frente a tampering 194 5.2.4 Análisis frente a node destruction 195 5.2.5 Análisis frente a LL collision 195 5.2.6 Análisis frente a LL exhaustion 196 5.2.7 Análisis frente a unfairness 196 5.2.8 Análisis frente a denial-of-sleep 196 5.2.9 Análisis frente a service request power attack 197 5.2.10 Análisis frente a benign power attack 197 5.2.11 Análisis frente a spoofed routing information attack 198 5.2.12 Análisis frente a acknowledgment spoofing 198 5.2.13 Análisis frente a routing table overflow 199 5.2.14 Análisis frente a routing table poisoning 199 5.2.15 Análisis frente a route cache poisoning 199 5.2.16 Análisis frente a rushing attack 200 5.2.17 Análisis frente a hello flooding 200 5.2.18 Análisis frente a black hole attack 201 5.2.19 Análisis frente a sink hole 201 5.2.20 Análisis frente a selective forwarding 201 5.2.21 Análisis frente a wormhole attack 202 5.2.22 Análisis frente a Sybil 202 5.2.23 Análisis frente a Byzantine attack 202 5.2.24 Análisis frente a TL flooding 203 5.2.25 Análisis frente a TL desynchronization 203 5.2.26 Análisis frente a information disclosure 204 Índice XIII 5.2.27 Análisis frente a eavesdropping 204 5.2.28 Análisis frente a traffic analysis 204 5.2.29 Análisis frente a man-in-the-middle 205 5.2.30 Análisis frente a attacks on cryptographic techniques 205 5.2.31 Análisis frente a node replication 206 5.2.32 Análisis frente a packet injection 206 5.2.33 Análisis frente a packet duplication 207 5.2.34 Análisis frente a packet alteration 207 5.2.35 Conclusiones del análisis 207 5.3 Evaluación en laboratorio en ausencia de ataques 208 5.4 Comparación de las configuraciones de SNSR experimentadas 212 5.5 Comparación según la topología de la red 217 5.6 Comparación según el tamaño de la red 219 5.7 Experimentos de campo con robot terrestre 223 5.8 Escenarios reales con robot aéreo 227 5.9 Experimentos con ataques 231 5.9.1 Ataques de Red Team 232 5.9.2 Ataques de suplantación de robot y comparativa de métodos de detección de baliza 234 5.9.2.1 Conexión al robot sin ataques 237 5.9.2.2 Comportamiento ante el ataque IG 238 5.9.2.3 Comportamiento ante el ataque RK 239 5.9.2.4 Comportamiento ante el ataque RD 239 5.9.3 Fallos fatales en nodos aleatorios 240 5.10 Conclusiones 243 6 Conclusiones 247 6.1 Conclusiones 247 6.2 Líneas futuras de trabajo 249 Índice de Figuras 255 Índice de Tablas 259 Índice de Códigos 261 Bibliografía 263 Notación, acrónimos y convenciones utilizadas Notación izda. Izquierda dcha. Derecha ∥Concatenación de cadenas PRxClave privada de la entidad x PUxClave pública de la entidad x Certy xCertiĄcado de la entidad xĄrmado por la entidad y IDxIdentidad de la entidad x EK(P)Encriptación del mensaje Pusando la clave K E−1 K(P)Desencriptación del mensaje Pusando la clave K EPRx(P)Firma digital del mensaje Prealizado por la entidad x E−1 PUx(S) VeriĄcación de que la Ąrma digital S ha sido realizada por la entidad x RCuerpo de los números reales CCuerpo de los números complejos A\BDiferencia entre el conjunto Ay el B ♣A♣Cardinalidad del conjunto A ∀CuantiĄcador universal ∥v∥Norma del vector v m´od Módulo, resto de una división entera def =Igual por deĄnición OOrden XV XVI Notación, acrónimos y convenciones utilizadas Acrónimos 6LoWPAN IPv6 over Low-Power Wireless Personal Area Networks. 116 AEAD Authenticated Encryption with Associated Data (encriptación autenticada con datos asociados). 56 AES Advanced Encryption Standard (Estándar de Encriptación Avanzado). 113, 114 AL Application Layer (nivel de aplicación). 50, 53, 62, 65, 84, 101, 114, 124, 125, 130, 132, 133, 147Ű150, 155, 201, 202, 204Ű206 AODV Ad hoc On-Demand Distance Vector. 33, 195, 198 APS Application Support Sublayer (subnivel de soporte de aplicaciones). 33Ű35, 37Ű39, 64 ASN.1 Abstract Syntax Notation One (Notación Sintáctica Abstracta 1). 115 BFS Breadth First Search (búsqueda en anchura). 40, 250 BGP Border Gateway Protocol (protocolo de puerta de enlace de frontera). 120 BS Base Station (estación base). 1, 2, 4, 7, 10Ű13, 24Ű26, 29Ű31, 33, 39Ű41, 43Ű51, 54, 55, 59, 60, 65, 67, 68, 71, 73, 75Ű83, 87, 89, 91Ű98, 100Ű107, 111Ű113, 115, 116, 118Ű124, 127Ű131, 133, 148Ű150, 156, 157, 159, 160, 166, 170Ű172, 176, 189, 192, 194, 195, 197Ű199, 201Ű206, 208Ű217, 219Ű225, 228, 229, 231Ű233, 237, 240, 241, 245, 248, 250, 251, 253Ű256 CA Collision Avoidance (Prevención de Colisiones). 32, 57 CA CertiĄcate Authority (Autoridad de CertiĄcación). 21, 22, 38, 47Ű49, 55, 69, 75, 78, 104, 160, 189, 191, 231, 235, 250Ű252, 254 CBKE CertiĄcate-Based Key Establishment (establecimiento de claves basado en certiĄ- cados). 37Ű39, 191 CH Cluster Head (cabeza de clúster). 13, 25Ű27, 30, 253 CLI Command-Line Interface (interfaz de línea de comandos). 170, 172Ű174 CN Common Name (Nombre Común). 48, 50, 54, 235, 239 CoAP Constrained Application Protocol (Protocolo de Aplicación Restringida). 22 CR CertiĄcate Repository (Repositorio de CertiĄcados). 47 CRC Cyclic Redundancy Check (VeriĄcación de Redundancia Cíclica). 46 CRL CertiĄcate Revocation List (Lista de Revocación de CertiĄcados). 39, 47, 48, 54, 55, 73, 77Ű81, 83, 84, 86, 89, 91, 93, 94, 96, 100Ű102, 104, 105, 111, 115, 116, 119, 123, 155, 156, 158, 160, 169, 180, 186, 209, 213, 221, 225, 234, 251, 252, 259 CSMA Carrier Sense Multiple Access (Acceso Múltiple con Escucha de Señal Portadora). 32, 57 Notación, acrónimos y convenciones utilizadas XVII CTP Collection Tree Protocol. 25 DFS Depth First Search (búsqueda en profundidad). 120 DH Diffie-Hellman. 69 DoS Denial of Service (Denegación de Servicio). 17, 24, 26, 29, 38, 46, 68, 88, 233 DTLS Datagram Transport Layer Security (Seguridad de la Capa de Transporte de Datagramas). 22, 30, 69, 113, 132, 137, 186, 189, 205, 207, 229, 231, 235, 236, 248, 253 ECC Elliptic Curve Cryptography (Criptografía de Curva Elíptica). 21, 22, 28Ű30, 38, 52, 113, 116, 137, 186, 190, 191, 248, 253, 254 ECDHE Elliptic-Curve DiffieŰHellman Ephemeral (Diffie-Hellman de Curva Elíptica Efímero). 114, 123 ECDSA Elliptic-Curve Digital Signature Algorithm (Algoritmo de Firma Digital de Curva Elíptica). 39, 114, 190 ECQV Elliptic Curve Qu-Vanstone. 191 FCS Frame Check Sequence (secuencia de comprobación de trama). 57 FFD Full-Function Device (dispositivo de función completa). 32 GCM Galois/Counter Mode. 114 GNSS Global Navigation Satellite System (sistema global de navegación por satélite). 26 GPL GNU General Public License (Licencia Pública General de GNU). 113, 133 GTS Guaranteed Time Slot. 196 HMAC Hash-based Message Authentication Code (Código de Autenticación de Mensaje basado en Hash). 35 HTB Hierarchical Token Bucket. 161 HTTP Hypertext Transfer Protocol (Protocolo de Transferencia de Hipertexto). 180Ű182 HTTPS Hypertext Transfer Protocol Secure (Protocolo Seguro de Transferencia de Hipertexto). 180 IANA Internet Assigned Numbers Authority. 113, 133 IDS Intrusion Detection Systems (Sistemas de Detección de Intrusos). 2, 19, 23Ű25, 30, 97, 250, 251 IKE Internet Key Exchange. 67, 69 IoT Internet of Things (Internet de las Cosas). 1, 13, 15, 21, 29, 114 XVIII Notación, acrónimos y convenciones utilizadas IP Internet Protocol (Protocolo de Internet). 116, 134, 181, 183, 185 IPS Intrusion Prevention System (Sistema de Prevención de Intrusos). 97 IPsec Internet Protocol security (Seguridad del Protocolo de Internet). 22 ITU International Telecommunication Union (Unión Internacional de Telecomunicaciones). 163 IV Initialization Vector (vector de inicialización). 56 IWSAN Industrial Wireless Sensor and Actuator Network (red de sensores y actuadores inalámbrica industrial). 15 IWSN Industrial Wireless Sensor Network (red de sensores inalámbrica industrial). 14 Java EE Java Enterprise Edition. 180 JSON JavaScript Object Notation. 114, 124, 160, 166, 170, 174, 177 JSP JavaServer Pages. 180 LL Link Layer (nivel de enlace). 46, 50Ű52, 57, 60, 62, 67, 73, 74, 84, 88, 103, 109, 112Ű115, 123, 124, 130, 133, 134, 136, 137, 140, 142, 158, 159, 161, 163, 169, 189, 193, 195Ű197, 203Ű205, 207, 208, 210, 211, 214, 215, 222, 225, 229, 234, 256, XXI LLAL Link Layer Adaptation Layer (nivel de adaptación al nivel de enlace). 130, 133, 134, 138, 143, 186, 248, 252, 253 LLC Logical Link Control (Control de Enlace Lógico). 32, 57 LPWAN Low Power Wide Area Network (red de área amplia de baja potencia). 15 LR-WPAN Low-rate Wireless Personal Area Network (redes inalámbricas de área personal con tasas bajas de transmisión de datos). 15, 31 MAC Media Access Control (Control de Acceso al Medio). 15, 31, 32, 34, 35, 57Ű59, 127, 181, 182, 209, 212, 225 MAC Message Authentication Code (Código de Autenticación de Mensaje). 19, 39Ű41, 46, 54, 56, 66, 69, 84, 105, 133Ű135, 159, 204, 205, 207 MANET Mobile Ad hoc Network (red ad hoc móvil). 11 MIC Message Integrity Code (Código de Integridad del Mensaje). 35, 56 MITM Man in the Middle attack. 69 MQV MenezesŰQuŰVanstone. 69, 191 MS Mobile Station (estación móvil). 44 MTU Maximum Transmission Unit (unidad de transmisión máxima). 57Ű59, 101, 107, 124, 132, 135, 140, 142, 146, 189 Notación, acrónimos y convenciones utilizadas XIX NL Network Layer (nivel de red). 52, 57, 60Ű66, 80, 95, 100, 101, 125, 130, 134, 137, 138, 140, 144, 149, 150, 193, 198, 202, 203, 206, 207, XXI NOS Network Operating System (Sistema Operativo de Red). 4, 5, 7, 106Ű108, 131, 158, 159, 185, 186, 248, 249, 252 OHC One-way Hash Chain (cadena hash unidireccional). 27, 39, 40 OSI Open Systems Interconnection (Interconexión de Sistemas Abiertos). 17, 32, XXI OTA Over-the-Air (por el aire). 179, 250 PAN Personal Area Network (red de área personal). 33, 34 PDU Protocol Data Unit (unidad de datos de protocolo). 53, 59, 62, 65, 66, 75, 124 PFS Perfect Forward Secrecy (secreto perfecto hacia adelante). 38, 66, 71 PHY Physical layer (nivel físico). 56, 109, 193, 194, 196, 207 PKG Private Key Generator (generador de claves privadas). 22 PKI Public Key Infrastructure (Infraestructura de Clave Pública). 21, 22, 28Ű30, 47Ű49, 55, 160, 186, 248 RA Registration Authority (Autoridad de Registro). 47 RFD Reduced-Function Device (dispositivo de función reducida). 32 RSA RivestŰShamirŰAdleman. 21, 113 RSSI Received Signal Strength Indicator (indicador de fuerza de la señal recibida). 19, 26 RTT Round-Trip Time (tiempo de ida y vuelta). 125Ű127, 129, 142, 144, 236 SCTP Stream Control Transmission Protocol (Protocolo de Transmisión de Control de Flujo). 141 SDN Software DeĄned Networking (Redes DeĄnidas por Software). 25, 30, 31, 51, 59, 116, 253 SDT Sleep Deprivation Torture. 196, 197 SDU Service Data Unit (unidad de datos de servicio). 57, 58, 61, 65, 124, 137 SHA Secure Hash Algorithm (Algoritmo de Hash Seguro). 114, 116, 181Ű183, 185, 190 SNSR Sensor Network Security using Robots. 3Ű7, 9, 28, 30, 31, 43, 44, 47Ű51, 62, 70, 72, 73, 76, 83, 84, 86, 96, 97, 103, 106Ű108, 112Ű115, 125, 127, 129, 130, 137, 149, 150, 155, 160, 164, 185Ű188, 191Ű208, 212, 229, 231, 232, 234, 240, 243Ű245, 247Ű253, 255, 259 SSH Secure SHell. 183 SSP Security Service Provider (Proveedor de Servicios de Seguridad). 35 XX Notación, acrónimos y convenciones utilizadas SVG Scalable Vector Graphics (GráĄcos Vectoriales Escalables). 171, 179 SVM Support Vector Machines (máquinas de vectores de soporte). 24 TC Trust Center. 34Ű39, 191, 195, 202Ű204, 206 TCP Transmission Control Protocol (Protocolo de Control de Transmisión). 62, 64, 66, 141, 142 TL Transport Layer (nivel de transporte). 50Ű52, 65Ű67, 73, 74, 82Ű84, 90, 94, 100, 101, 112Ű114, 124, 133, 136, 139, 141, 142, 149, 193, 198, 203Ű205, 207, 216, 252, XXI TLS Transport Layer Security (Seguridad de la Capa de Transporte). 22, 62, 69, 137 TLV tipo, longitud y valor. 114, XXI TSP Traveling Salesman Problem (problema del vendedor viajero). 27 TTL Time To Live (tiempo de vida). 60 UAV Unmanned Aerial Vehicle (vehículo aéreo no tripulado). 26Ű28, 30, 31, 44 UDP User Datagram Protocol (Protocolo de Datagramas de Usuario). 133, 134, 137, 141, 142, 161, 164, 169, 185, 189, 220 UML UniĄed Modeling Language (Lenguaje UniĄcado de Modelado). 78, 134, 138, 142, 147 URL Uniform Resource Locator (localizador de recursos uniforme). 181 UWB Ultra-WideBand (banda ultraancha). 209 VANET Vehicular Ad hoc Networks (red ad hoc vehicular). 11 WSN Wireless Sensor Network (red inalámbrica de sensores). 1Ű5, 7, 9Ű31, 39, 41, 43, 44, 46, 47, 49Ű51, 59, 71, 75Ű78, 92, 97, 100, 101, 106Ű108, 114, 116, 129, 131, 186, 188, 189, 243, 245, 247Ű249, 253, 254 ZAP ZigBee Application ProĄle (perĄl de aplicación ZigBee). 34 ZC ZigBee Coordinator (coordinador de ZigBee). 32Ű36, 38 ZDO ZigBee Device Object (objeto de dispositivo ZigBee). 34 ZED ZigBee End Device (dispositivo Ąnal de ZigBee). 32Ű34, 37 ZR ZigBee Router (enrutador de ZigBee). 32Ű34, 36, 37 ZSE ZigBee Smart Energy. 37Ű39, 191, 193, 194, 207, 208, 244, 248 Notación, acrónimos y convenciones utilizadas XXI Convenciones utilizadas Cadenas y operaciones de cadenas Se denominará cadena a una secuencia de símbolos elegidos de un conjunto especíĄco. Se consideran solo dos conjuntos: alfabeto binario 0,1 y octetos 0,1,...,255, dando lugar a cadenas binarias y cadenas de octetos. La longitud de una cadena será el número de símbolos que contiene. Si la longitud es 0, a la cadena se la denomina cadena vacía. Se deĄne la operación concatenación de dos cadenas aybde longitudes mynrespectivamente, como la generación de una nueva cadena cde longitud m+n en la que los m símbolos más a la izquierda coincide con los de ay, los n más a la derecha, con los de b. Se representará como: c=a∥b Mensajes transmitidos Cuando se quiera mostrar el contenido de un mensaje transmitido desde una entidad ORIGEN a otra entidad DESTINO, se utilizará la siguiente representación: ORIGEN →DESTINO :campo1∥campo2∥... Si el mensaje es de difusión, se utilizará ∗ como DESTINO . El termino mensaje se utiliza aquí de manera genérica como información transmitida por la red, pero recibe distintos nombres según el nivel del modelo de Interconexión de Sistemas Abiertos (OSI, Open Systems Interconnection) que lo trata: trama en el nivel de enlace (LL, Link Layer), paquete en el nivel de red (NL, Network Layer), segmento o datagrama en el nivel de transporte (TL, Transport Layer), etc. A menos que se especiĄque, los campos deben verse como cadenas de octetos opacos con una codiĄcación dependiente de la implementación. Es decir, si no se especiĄca, la codiĄcación de los campos es libre siempre que el receptor y emisor se pongan de acuerdo previamente en la implementación a usar. La arquitectura deĄnida aquí podría implementarse utilizando codiĄcaciones habituales: • Utilizando campos de tamaño predeĄnidos o añadiendo un subcampo previo que indique la longitud. • Utilizando determinadas cadenas de octetos (podría ser un único octeto) como separadores de campos. • Dividiendo cada campo en tres subcampos: tipo, longitud y valor (TLV). • Utilizando lenguajes de marcado, etc. Orden de transmisión El orden de transmisión se hará utilizando el formato little-endian donde se transmiten primero los bits menos signiĄcativos de cada campo, siendo el último en transmitirse el bit más signiĄcativo. Si un campo está compuesto por varios octetos (un octeto son 8 bits), será enviado en orden desde el primer octeto en transmitirse, que es aquel que contiene el bit menos signiĄcativo, hasta el último octeto que contenga el bit más signiĄcativo. 6Capítulo 1. Introducción Contribución 6: Experimentación y validación de todas las contribuciones anteriores. Para validar la implementación y la plataforma de pruebas, y caracterizar el comportamien- to de SNSR se han realizado miles de experimentos con distintos escenarios virtuales y reales con robots terrestres y aéreos. En estos experimentos se han probado diferentes medidas de seguridad, conĄguraciones, número de nodos y topologías en condiciones normales y con ataques. Los resultados han demostrado la seguridad, eĄciencia y escalabilidad de SNSR. 1.4 Publicaciones Las contribuciones de esta Tesis Doctoral han dado como resultado las publicaciones cientíĄcas que se enumeran a continuación. Destaca el artículo de 17 páginas publicado en la revista IEEE Internet of Things Journal cuyo factor de impacto en 2021 es de 10,238 y es Q1 en todas sus categorías. También se ha publicado un conjunto de datos experimentales (dataset). El código desarrollado en esta Tesis Doctoral está pendiente de ser publicado. 1.4.1 Artículos en revistas indexadas 1. Francisco Jose Fernandez-Jimenez and Jose Ramiro Martinez De Dios, A Robot- Sensor Network Security Architecture for Monitoring Applications, IEEE Internet of Things Journal 9 (2022), no. 8, 6288Ű6304. [41] Indicios de calidad del año 2021 (Web of Science): Journal Impact Factor =10,238; Categoría COMPUTER SCIENCE, INFORMATION SYSTEMS = 9/164, Q1, Decil 1, Percentil 94,82; Categoría ENGINEERING, ELECTRICAL & ELECTRONIC = 18/276, Q1, Decil 1, Percentil 93,66; Categoría TELECOMMUNICATIONS = 6/93, Q1, Decil 1, Percentil 94,09. 2. José Ramiro Martínez-de Dios, Anibal Ollero, Francisco José Fernández, and Carolina Regoli, On-Line RSSI-Range Model Learning for Target Localization and Tracking, Journal of Sensor and Actuator Networks 6 (2017), no. 3. [122] Indicios de calidad del año 2021 (Web of Science): Journal Impact Factor = (no disponible); Categoría TELECOMMUNICATIONS = 48/115, Q2, Percentil 58,70. 3. Javier Munoz-Calle, Francisco J. Fernandez-Jimenez, Teresa Ariza, Antonio J. Sierra, and Juan M. Vozmediano, Computing Labs on Virtual Environments: A Flexible, Portable, and Multidisciplinary Model, IEEE Revista Iberoamericana de Tecnologias del Aprendizaje 11 (2016), no. 4, 235Ű341. [102] Indicios de calidad del año 2021 (Web of Science): Journal Impact Factor = (no disponible); Categoría COMPUTER SCIENCE, INTERDISCIPLINARY APPLICATIONS = 132/156, Q4, Percentil 15,71. 1.4.2 Aportaciones a congresos internacionales 1. Francisco J Fernández-Jiménez and J Ramiro Martínez-de Dios, Design of a Robot- Sensor Network Security Architecture for Monitoring Applications, ROBOT 2017: 1.5 Estructura del documento 7 Third Iberian Robotics Conference, Springer International Publishing, 2018, pp. 200Ű212. [40] 1.4.3 Datasets 1. Material de varios experimentos virtuales y reales realizados, como versiones de información de topología, resultados obtenidos y ejemplos de los certiĄcados utilizados. También se incluye la deĄnición de la información de topología y los mensajes de la aplicación de gestión utilizando el formato Protocol Buffers. [42] 1.5 Estructura del documento El resto del documento está estructurado como se indica a continuación. El Capítulo 2 resume el estado del arte de la seguridad en las WSN y la colaboración entre robots móviles y las WSN. Se muestra la taxonomía de los principales trabajos descritos y se hace una comparación con SNSR. También se describen con más detalle el protocolo INSENS [ 26 ] y el estándar ZigBee con el perĄl de aplicación ZigBee Smart Energy [8, 113] cuya seguridad será analizada en el Capítulo 5. El Capítulo 3 presenta el diseño de la nueva arquitectura de seguridad SNSR que combina robots y redes de sensores. Se analizan los requisitos que debe cumplir la torre de protocolos de la WSN para poder implementarla. Se describen las fases de funcionamiento, las relaciones entre tipos de entidades, protocolos de comunicación, información almacenada y parámetros de conĄguración para el caso de usar un robot y una BS. Este capítulo desarrolla la Contribución 1 y la Contribución 2 de esta Tesis Doctoral. El Capítulo 4 explica el NOS desarrollado capaz de ejecutarse en distintos equipos (robot, BS y nodos sensores) que implementa las funcionalidades descritas en la arquitectura SNSR y que no depende de una WSN concreta. Dada la Ćexibilidad de SNSR, también se detallan las decisiones tomadas a la hora de implementar la arquitectura. Se describe el compositor/orquestador de escenarios virtuales para probar estas redes sin necesidad de hacerlo en un entorno real, y el sistema de gestión remota que permite controlar los dispositivos empleados en escenarios reales. También se realiza una descripción de herramientas utilizadas para simular ataques. Este capítulo desarrolla la Contribución 3, la Contribución 4 y la Contribución 5 de esta Tesis Doctoral. El Capítulo 5 muestra un análisis comparativo de seguridad y detalla los experimentos llevados a cabo para validar la arquitectura SNSR y la implementación desarrollada junto con los resultados obtenidos. Se han realizado pruebas en laboratorio así como experimentos con robots terrestres y aéreos en entornos de monitorización de infraestructuras y de industrias. Este capítulo desarrolla la Contribución 6 de esta Tesis Doctoral. El Capítulo 6 resume las principales conclusiones de esta Tesis Doctoral y propone líneas futuras de trabajo e investigación. 2 Estado del arte Grandes descubrimientos y mejoras implican invariablemente la cooperación de muchas mentes. Alexander Graham Bell En este capítulo se hace una revisión de trabajos cuyo objetivo es mejorar la seguridad de una WSN y de aquellos que han empleado robots en colaboración con ellas, que es la idea principal de esta Tesis Doctoral. Este estado del arte permite tener una panorámica de la situación de la que parte esta Tesis Doctoral y las novedades que aporta respecto a trabajos previos. La Sección 2.1 comienza con una visión general de la diversidad de las WSN existentes y las características de estas que diĄcultan encontrar una arquitectura de seguridad genérica. A continuación, en la Sección 2.2, se describen las vulnerabilidades habituales y los ataques conocidos. Después, en la Sección 2.3, se muestran las medidas de seguridad desarrolladas en otros trabajos. La segunda parte del capítulo comienza en la Sección 2.4, que revisa la colaboración entre robots móviles y las WSN. Se muestran las tareas que han realizado los robots en este contexto y se analizan trabajos donde contribuyen a mejorar la seguridad de la WSN. En la tercera parte, comenzando en la Sección 2.5.1, se muestra una taxonomía de los principales trabajos descritos en las partes anteriores, para dar una visión general al lector de las características de esos trabajos. Después, en la Sección 2.5.2, se hace una comparación de SNSR respecto a los trabajos anteriores. Por último, en la Sección 2.6 y la Sección 2.7, se explican con más detalles aquellos trabajos y especiĄcaciones cuya seguridad será analizada cualitativamente en el Capítulo 5 y que será comparada con la seguridad de SNSR. Puede consultar en la Sección 5.2 este análisis, así como la justiĄcación de la elección. Además de la literatura comentada en este capítulo, para la realización de esta Tesis Doctoral se han tenido que consultar otros trabajos relativos a problemas secundarios que han surgido en la implementación y experimentación de SNSR. Se comentarán brevemente estos trabajos en las secciones correspondientes de capítulos posteriores. 9 10 Capítulo 2. Estado del arte 2.1 Redes inalámbricas de sensores Genéricamente, una WSN es un conjunto de dispositivos o nodos sensores equipados con sensores que monitorizan el entorno y que colaboran para hacer llegar la información obtenida a un nodo sumidero, también conocido como nodo pasarela o BS, usando comunicaciones inalámbricas. Es un tipo de red inalámbrica ad hoc especializada para las condiciones anteriores. Las WSN han sido usadas en muchos campos distintos [ 78 ] y son muy dependientes de la aplicación para la que se van a utilizar. A partir del concepto general surgen una gran diversidad de tipos de WSN, con requisitos y características diferentes. Se pueden destacar las siguientes características de una WSN que inĆuyen en las tecnologías necesarias para su implantación [78, 29, 120, 56]: • Diversidad en las capacidades de los dispositivos. Los dispositivos se clasiĄcan en distintos tipos según las capacidades que afectan a la aplicación concreta, como por ejemplo el consumo de energía y acceso a esta (usando la red eléctrica, con baterías, captando energía del medio, ...), la potencia computacional, el almacenamiento disponible, etc. [ 78 ]. Los nodos sumideros suelen ser considerados diferentes a los nodos sensores. En cuanto a los nodos sensores, estos podrían ser considerados todos similares (red homogénea) o pertenecer a distintos tipos (red heterogénea). En una red heterogénea, los nodos sensores suelen realizan distintas funciones según su tipo. En redes homogéneas, los nodos también podrían realizar funciones especiales asignadas por turnos a distintos nodos. Habitualmente se buscan nodos sensores de bajo costo, de reducidas dimensiones y eĄcientes en consumo de energía. Esto es crítico en aplicaciones donde se usan nodos sensores que no se pueden recuperar una vez que agotan su batería. Lo anterior implica que normalmente los nodos sensores van a tener recursos muy limitados. Con estos dispositivos de bajo costo, la robustez se consigue mediante estrategias donde se emplean muchos nodos y su operación se adapta para conseguir mantener el funcionamiento esperado de la red. Gran parte del esfuerzo investigador en los últimos años se ha centrado en el objetivo de diseñar WSN eĄcientes cuyo tiempo de funcionamiento sin tener que intervenir sea el mayor posible [51]. • Redundancia de funcionalidad. Los nodos sensores pueden estar desplegados de tal manera que ninguno de ellos sea imprescindible, ya que su misma funcionalidad la puede proporcionar otro nodo. Por ejemplo, varios nodos pueden tomar medidas de la misma variable, y cualquiera de ellas sería suĄciente. Esto a priori es deseable al hacer la red más robusta, pero a veces puede ser imposible realizarlo o entrar en conĆicto con otros requisitos como el coste en dispositivos, despliegue, transmisión y procesamiento de la información y de mantenimiento. La redundancia disponible afecta a la posibilidad de Ąltrar y detectar medidas erróneas y el esfuerzo necesario para garantizar la Ąabilidad de las comunicaciones, proteger nodos críticos, detectar nodos caídos y reemplazarlos. • Política de recuperación ante fallos en nodos. Los nodos pueden tener fallos parciales o totales, fortuitos o intencionados. Por ejemplo, un nodo podría agotar su batería o haber sido comprometido por un atacante y comportarse de manera 2.1 Redes inalámbricas de sensores 11 incorrecta. Si la redundancia es alta en la red, se puede ignorar o excluir el nodo sin mayor inconveniente. Pero si la red no tiene redundancia o esta cae por debajo de una calidad de servicio admisible, los nodos deben ser sustituidos o reparados. El coste de un nodo, el coste del despliegue inicial de un nuevo nodo y el de reparación suelen decidir la mejor acción a tomar. Por ejemplo, las WSN usadas para monitorizar el medio ambiente suelen usar nodos de muy bajo costo que se despliegan densamente en el área objetivo. En estos casos, cuando el número de nodos con fallos es excesivo lo normal es volver a repoblar el área desplegando nuevos nodos. En otros casos, con nodos sensores accesibles, es más eĄciente intentar realizar la reparación evitando tener que hacer reconĄguraciones adicionales. • Número de sumideros o BS. Las WSN más simples suelen contar con una única BS. Pero también existen otras con múltiples BS para aumentar la robustez de la red, disminuir la distancia que deben recorrer los datos y reducir la congestión, entre otros beneĄcios. Los nodos pueden enviar las medidas a una BS seleccionada o a varias de manera simultánea o alternativa. Sin embargo, tener varias BS puede traer consigo inconvenientes, como la necesidad de agregar la información recopilada en todas las BS y de crear mecanismos de selección de BS en los nodos sensores y el posible aumento en los mensajes transmitidos. • Dinamismo en el número de nodos. Esto hace referencia a la frecuencia con la que se añaden o se eliminan nodos. InĆuye en aspectos tales como los protocolos de enrutamiento usados, el descubrimiento mutuo entre los nodos y la red, el proceso de reconĄguración y la autenticación de nuevos nodos. Un dinamismo alto implica WSN más complejas y dedicar más energía a mantener la conectividad y seguridad de la red. • Estáticas o con elementos móviles. En las WSN más comunes todas las entidades (nodos sensores y sumideros) que pertenecen a ella son estáticas, permaneciendo en la misma posición desde que son desplegadas. En estos casos se dice que la WSN es estática. En otros casos, es posible que sumideros, nodos sensores o ambos sean móviles. Si hay muchos elementos móviles, se habla de WSN móviles y se aplican técnicas similares a las redes ad hoc móviles (MANETs, Mobile Ad hoc Networks) y redes ad hoc vehiculares (VANETs, Vehicular Ad hoc Networkss) adaptándolas a dispositivos con menores recursos. • Tipos de interacciones entre entidades de la red. Los elementos que se pueden relacionar entre sí y si la comunicación es bidireccional, unidireccional, por difusión o multidifusión es otra característica que puede cambiar de una WSN a otra. En las WSN más simples los sensores envían sus medidas a la BS en mensajes unidireccionales y la BS anuncia su disponibilidad mediante difusión por inundación. Para la transmisión Ąable de los datos se requiere comunicación bidireccional. En otras, los nodos sensores tienen que colaborar entre sí para formar y mantener la red. Por último, existen redes cuya actividad va más allá de sensorizar, donde existen nodos actuadores y se permite la comunicación bidireccional y grupal entre todas las entidades. Un ejemplo serían las WSN industriales donde los nodos participan en el control de procesos. 12 Capítulo 2. Estado del arte • Topología de la red.En algunas WSN se busca una determinada topología de la red. El alcance radio y características de los dispositivos, la eĄciencia energética o la necesidad de redundancia en la red son factores que inĆuyen. Además, la topología tiene implicaciones en el direccionamiento y el enrutamiento usado. Las topologías más habituales son las siguientes: – Topología en estrella. Los nodos se conectan a un nodo central que actúa como conmutador entre ellos. En redes simples, la BS es el nodo central y los nodos sensores no necesitan implementar nivel de red. Se conocen también como redes de un solo salto debido a que los sensores están conectados a la BS, a diferencia de las redes multisalto. Son fáciles de desplegar y ampliar. Sin embargo, tiene algunos inconvenientes: solo son posibles si el alcance radio de los sensores lo permite, el nodo central se convierte en un único punto de fallo y cuello de botella, la probabilidad de colisiones durante las transmisiones aumenta y los nodos alejados gastan mucha más energía al transmitir debido a la atenuación (el consumo de la comunicación vía radio aumenta en función del cuadrado de la distancia). A veces, aunque esta topología sea posible, muchas veces se preĄeren topologías multisalto ya que transmitir en nsaltos pequeños controlando la potencia de transmisión consume aproximadamente nveces menos que en un único salto. – Topología en árbol. Existe un nodo raíz (habitualmente la BS) al que se conectan otros nodos que forman el siguiente nivel de la jerarquía y así sucesivamente. El consumo energético es mayor en los niveles más próximos al nodo raíz debido al procesado y reenvío de mensajes de otros nodos. La formación del árbol no suele venir dada por las condiciones físicas de la red, sino siguiendo reglas preestablecidas cuando un nodo descubre a su vecindad. El direccionamiento y enrutamiento suelen ser sencillos y de bajo coste. Los nodos hojas pueden ser más simples que el resto ya que no retransmiten mensajes de otros nodos. Sin embargo, existe un único punto de fallos global y cada nodo es crítico para los que están debajo de él, por lo que cuando un nodo falla suele ser necesario regenerar el árbol. Un caso límite es la topología lineal, utilizadas en algunas WSN destinadas a monitorizar infraestructuras lineales como oleoductos y líneas eléctricas. – Topología mallada. Los nodos se comunican con los vecinos que están a su alcance como iguales y todos funcionan como encaminadores retransmitiendo mensajes. El número máximo de vecinos con los que se relaciona cada nodo puede estar limitado. La malla se dice que es completa cuando cada nodo está conectado con todos los demás, y en caso contrario se denomina malla parcial. En redes cableadas esta topología suele ser costosa debido al tendido de cableado adicional que involucra, pero en redes inalámbricas no existe ese problema. Sin embargo, requiere que todos los nodos sean similares y aumenta el consumo energético destinado a mantener las conexiones con vecinos. Esta topología es más robusta que las anteriores debido a que puede existir más de un camino posible entre dos nodos. Los criterios para elegir el camino que debe seguir un paquete pueden diferencia a una WSN de otra. 2.1 Redes inalámbricas de sensores 13 Una misma red puede tener distintas topologías simultáneamente, sobre todo en redes heterogéneas. • Agrupación de nodos en clústeres o no. Existen WSN que internamente se subdividen en grupos de nodos o clústeres [ 110 ]. En cada clúster se elije un nodo cabeza de clúster (CH, Cluster Head). Solo el CH se comunica con el resto de la red y los otros nodos del clúster solo se comunican entre ellos y el CH. Al CH también se le suelen asignar otras funciones especiales si las hubiera, destacando la agregación y fusión de información antes de enviarla a la BS. Se hace que los nodos CH tengan un mayor gasto energético para reducir el consumo del resto de nodos. El resultado es una red jerárquica que busca mejorar la escalabilidad y la eĄciencia energética. La elección del CH es un problema adicional que deben resolver estas redes, ya sea con algoritmos distribuidos o centralizados. En redes heterogéneas es habitual escoger a los nodos con más recursos. En redes homogéneas es posible asignar esta tarea por turnos. Los nodos CH forman una red inter-clúster entre ellos que no tiene que tener las mismas características que la subred intra-clúster. Por ejemplo, pueden tener distinta topología, encaminamiento, etc. A las redes que no contemplan la agrupación en clústeres se les suele denominar redes planas. • Diversidad en el enrutamiento. Normalmente el enrutamiento y el direccionamien- to usado es consecuencia del resto de características y requisitos de la WSN, pero a veces viene impuesto por compatibilidad con los dispositivos usados, para poder hacer comparativas entre distintos protocolos de enrutamiento o para permitir el acceso desde el exterior cuando la WSN se integra en arquitecturas de IoT. Existen multitud de protocolos de enrutamiento y distintos criterios de clasiĄcación [ 6 , 131 ]. Tienen gran inĆuencia en el consumo energético global y la seguridad de la red. • WSN determinista o no determinista. Una WSN se considera determinista cuando es posible determinar con anterioridad al despliegue la posición que ocupará cada sensor. Con lo anterior es posible calcular y conĄgurar todos los nodos sensores antes de su despliegue. Esto solo es aplicable a muy pocas redes, y normalmente la posición exacta de los sensores será desconocida, puede ser variable e incluso pueden añadirse nuevos nodos más adelante. En estos casos, la red se denomina no determinista y requiere sistemas más complejos y adaptativos. • Cuándo y cómo se envían las medidas. Las medidas pueden enviarse de manera periódica, al producirse un cambio signiĄcativo en el valor monitorizado o por petición expresa. Los requisitos de retardo y Ąabilidad de transmisión diĄeren de una aplicación a otra [37]. • Autonomía de los nodos sensores. El grado de autosuĄciencia de los nodos y si la red es autoconĄgurable también puede ser diferente según la WSN. Los nodos pueden ser activos e iniciar la formación de la red si no detectan ninguna a la que unirse o esperar a detectarla. Pueden anunciar la disponibilidad de datos y descubrir al sumidero o esperar que este se anuncie o pida los datos. Aunque las WSN como redes ad hoc se pueden autoconĄgurar y autoorganizar sin necesidad de infraestructura previa, esto a veces implica un consumo energético no adecuado para determinadas aplicaciones y además puede conllevar problemas de seguridad. Por 14 Capítulo 2. Estado del arte consiguiente, en algunas arquitecturas se utilizan elementos centralizados o nodos con funcionalidades especiales encargados de la conĄguración y organización de la red. • Dominios administrativos, federación y compartición de la red. La propiedad y gestión de una red puede involucrar a una única organización o a varias. La red puede tener un uso exclusivamente privado o ser pública y permitir su uso por otras organizaciones. La participación de múltiples organizaciones trae consigo problemas de incompatibilidad, seguridad y conĄanza que pueden requerir una negociación previa antes del despliegue. Se dice que las redes tienen un dominio administrativo único cuando todos los participantes pertenecen a una misma organización o comparten un punto de conĄanza común, que permite negociar con antelación las credenciales y mecanismos de seguridad que se emplearán. Si la red tiene dominios administrativos múltiples, los participantes no tienen que haber tenido contacto previo y pertenecen a distintas organizaciones y dominios de seguridad. Esto imposibilita la negociación previa y requiere el establecimiento ad hoc de parámetros compatibles. Por otro lado, la federación consiste en la colaboración de múltiples redes con distintos dominios administrativos para un Ąn común, y la compartición de la red implica que una misma red se utilizar para proporcionar varios servicios independientes a la vez [ 64 ]. Tanto la federación y la compartición implica que la red debe estar preparada para aplicar distintos parámetros de seguridad simultáneamente. • Diversidad en la seguridad exigida. La seguridad tiene un coste de computación, de almacenamiento volátil y no volátil y de transmisión. Además, puede ser incompatible con algunas funcionalidades de la red, especialmente con la agregación y fusión de datos si no se desea que el nodo que realiza esta tarea tenga acceso a los datos en claro. En este último caso las técnicas de cifrado estándar no lo permitirían y se necesitaría emplear cifrado homomórĄco [ 7 ], que permite realizar operaciones algebraicas sobre los datos cifrados. No todas las aplicaciones tienen los mismos requisitos de seguridad. Estos requisitos pueden ser de disponibilidad del servicio, integridad de los datos, conĄdencialidad de la información, privacidad de los usuarios, autorización, autenticación, no repudio y frescura de los mensajes [ 29 ]. Por ejemplo, una posible aplicación puede permitir que los datos sean accesibles públicamente, por lo que no le puede interesar que vayan cifrados, y aún así quiera que se garantice la autenticidad de ellos. Los administradores de una WSN deben evaluar la probabilidad de que se produzcan ataques, el valor y privacidad de los datos transmitidos, el coste de aceptar información falsa, la facilidad de acceder a los dispositivos por terceras personas y la conĄanza de los participantes entre otros criterios para deĄnir el nivel de seguridad requerido. En deĄnitiva, existe una gran variedad de tipos de WSN [ 78 , 29 , 120 , 56 ]. Muchas veces las distintas capacidades requeridas compiten entre sí y puede que una funcionalidad que se introduce para optimizar unas de las características implica el empeoramiento de otra, por lo que hay que adoptar criterios que optimicen el funcionamiento global. Esta variedad también se reĆeja en el número de estándares y tecnologías comerciales existentes que muchas veces compiten entre sí y otras veces se complementan. En [ 37 ] se describen muchas de ellas aplicables a una red de sensores inalámbrica industrial (IWSN, 2.2 Vulnerabilidades y ataques en WSN 15 Industrial Wireless Sensor Network) o una red de sensores y actuadores inalámbrica industrial (IWSAN, Industrial Wireless Sensor and Actuator Network), destacando el IEEE 802.15.4 [ 1 ]. Este estándar deĄne los niveles físicos y de Control de Acceso al Medio (MAC, Media Access Control) para su uso en redes inalámbricas de área personal con tasas bajas de transmisión de datos (LR-WPAN, Low-rate Wireless Personal Area Network). Su versión inicial fue publicada en el 2003 y desde entonces se ha ampliado mediante modiĄcaciones y revisiones (que consolidan las modiĄcaciones previas). En la actualidad incorpora multitud de niveles físicos y MAC lo que le proporciona mucha Ćexibilidad y es la base de otros protocolos de alto nivel como ZigBee (que se detallará en la Sección 2.6), ISA100.11a (también conocido como IEC 62734 o ISA100), 6LowPAN (del IETF, detallado en los RFC 4919 y RFC 4944), 6TiSCH (RFC 9030 del IETF), WirelessHART o WIA-PA. Entre los posibles competidores destacan Bluetooth (IEEE 802.15.1), sobre todo la versión Low Energy, Wireless IO-Link (IEC 61139-3), Wi-Fi (la familia de estándares IEEE 802.11, especialmente el IEEE 802.11ah o Wi-Fi HaLow desarrollado pensando en IoT o la última versión, IEEE 802.11ax o Wi-Fi 6, que reduce el consumo y aumenta la robustez), y estándares de red de área amplia de baja potencia (LPWAN, Low Power Wide Area Network) como pueden ser LoRaWAN, Sigfox, NB-IoT o LTE-M. Dado que en esta Tesis Doctoral no nos centraremos en los niveles bajos, no se detallarán las características de las tecnologías antes enunciadas, pero sí se han tenido en cuenta las diferencias a la hora de buscar una solución de seguridad que pueda ser adaptable a distintos niveles físicos y de enlace. Las WSN pueden formar parte de sistemas IoT. En estos sistemas se puede habilitar la comunicación con los sensores y actuadores de una WSN desde el exterior de esta, a través de pasarelas. En IoT por consiguiente aumentan los riesgos relativos a la privacidad y seguridad y hay que resolver problemas relativos al control de acceso externo que antes no surgían. No es el objetivo de esta Tesis Doctoral analizar la seguridad de las aplicaciones concretas que se ejecutan en la WSN, incluyendo las relacionadas con IoT. El resto del estado del arte se focalizará en las WSN usadas para la monitorización de instalaciones industriales y grandes infraestructuras civiles, donde los nodos, una vez desplegados, permanecen estáticos a excepción de cambios de posición ocasionales y donde pueden también añadirse o quitarse nodos a lo largo del tiempo. En muchas de estas aplicaciones de WSN para la monitorización, la seguridad es un aspecto crítico. 2.2 Vulnerabilidades y ataques en WSN Las WSN tienen una gran superĄcie de ataque, entendida como el conjunto de vulnerabilidades y técnicas, también conocidas como vectores de ataques, que puede utilizar un usuario no autorizado (atacante) para lograr que un ataque tenga éxito. Estas vulnerabilidades se originan principalmente por las siguientes características de las WSN [167, 29, 51, 150]: • Los nodos sensores son frecuentemente de bajo costo y tienen limitados sus recursos computacionales y energéticos. Esto restringe las operaciones que pueden realizar. Es habitual desplegar los nodos sensores en entornos donde no hay disponible una 22 Capítulo 2. Estado del arte del estado de los certiĄcados a la CA u otra autoridad de conĄanza. El trabajo [ 62 ] discute el uso de certiĄcados en Seguridad de la Capa de Transporte de Datagramas (DTLS, Datagram Transport Layer Security) [ 125 ], y muestra pautas sobre cómo reducir el costo de su uso, por ejemplo, mediante el uso de la veriĄcación previa, reanudación de sesiones, etc. • La criptografía basada en identidad es un sistema alternativo donde la clave pública es la identidad en sí, por lo que no es necesario transmitirla. Sin embargo, tiene varias desventajas. Para empezar, requiere una tercera entidad de conĄanza, conocida como generador de claves privadas (PKG, Private Key Generator), que genera y conoce todas las claves privadas (en PKI la CA no conoce las claves privadas). Si el PKG se ve comprometido, toda la red estará comprometida. Además, la revocación es más compleja ya que no se pueden reutilizar identiĄcadores. Por último, es más costosa desde el punto de vista computacional debido al proceso de emparejamiento (asociación bilinear de una identidad a un punto en la curva ECC). Recientemente, [ 168 ] propuso una adaptación de esta alternativa para WSN donde se evitaba realizar el proceso de emparejamiento, aunque limitando su empleo a la operación de Ąrma digital. • La criptografía sin certiĄcados (certiĄcateless) es una variante de la anterior. Esta alternativa resuelve el problema de la custodia de claves que presentaba la anterior, pero requiere de nuevo el intercambio de claves públicas, ya que no se pueden derivar directamente de la identidad. Además, sigue siendo muy exigente computacionalmente. Un ejemplo de un trabajo que adapta esta alternativa a WSN es [ 89 ], que también evita el costoso proceso de emparejamiento a costa de limitar su uso a la Ąrma digital. En los sistemas híbridos se busca combinar las ventajas de la criptografía simétrica y la asimétrica. Muchos de los protocolos seguros en funcionamiento son híbridos. La criptografía asimétrica se usa principalmente para la autenticación inicial y durante la negociación de la clave simétrica de sesión. Diffie-Hellman [ 32 ] es un protocolo muy usado para el intercambio de claves. Tras intercambiar las claves de sesión, se usa criptografía simétrica para cifrar y autenticar el resto de los mensajes porque es signiĄcativamente más eĄciente. De este modo el mayor costo de la criptografía asimétrica se amortiza con el tiempo. Esta manera de operar se utiliza en los principales protocolos de seguridad de Internet tales como Seguridad del Protocolo de Internet (IPsec, Internet Protocol security) [ 81 ], Seguridad de la Capa de Transporte (TLS, Transport Layer Security) [ 31 ] y DTLS [ 125 ]. Algunos autores han realizado esfuerzos para implementar los protocolos anteriores en WSN: [ 124 ] es un ejemplo de uso de IPsec, y [ 115 ] es un ejemplo de uso de TLS/DTLS. DTLS también se usa en el Protocolo de Aplicación Restringida (CoAP, Constrained Application Protocol) [ 134 ], un protocolo de transferencia web especializado para redes y nodos restringidos con pocos recursos. Esta solución también ha sido adoptada por ZigBee Smart Energy [ 113 ], aunque usando un protocolo basado en Standards for Efficient Cryptography 1 (SEC 1) [19]. 2.3 Medidas de seguridad para WSN 23 2.3.2 Detección de ataques Muchos sistemas de seguridad se basan en la detección de los ataques, y la identiĄcación y localización de los atacantes ya sean externos o internos. Este es el caso de los IDS. El trabajo [ 76 ] presenta un estudio comparativo de varios IDS usados en WSN y divide su operación en 3 tareas: recogida de información, creación de un modelo de detección y generación de respuesta ante un ataque. La monitorización de la red y la detección de anomalías pueden ser realizadas por todos los nodos como en [ 153 ], en un conjunto de nodos seleccionados como en [ 11 ], o de manera centralizada mediante el análisis del tráĄco de la red como en [ 58 ]. No todos los nodos tienen que realizar las mismas tareas, sino que pueden realizarse de manera heterogénea, dependiendo de los recursos de cada entidad, como propone [ 158 ]. También existen IDS basados en agentes móviles tales como el descrito en [48]. La recolección de anomalías (o eventos de interés) para su posterior procesado puede realizarse de manera distribuida, como hacen por ejemplo [ 88 , 103 , 99 ], o centralizada como en [ 76 , 132 ]. La principal desventaja de los métodos descentralizados es que los nodos solo tienen un conocimiento local y parcial de la red, y su tasa de detección es menor. Muchos autores se centran en la capacidad de detectar diferentes ataques mediante el análisis de la información recopilada. Se pueden distinguir las siguientes categorías principales de IDS [120]: • Basados en anomalías (anomaly-based). En este caso, primero se extraen patrones asociados al comportamiento normal del sistema de la observación del funcionamiento de la red sin ataques. Posteriormente, las desviaciones respecto a los anteriores patrones se clasiĄcan como ataques potenciales [ 76 ]. Si la red cambia o se introducen nuevas funcionalidades hay que repetir el proceso anterior. Estos IDS son dependientes del método usado para extraer patrones normales, pero permiten incluso la detección de ataques desconocidos. • Basados en el uso indebido (misuse-based). En estos IDS se analizan los ataques conocidos y de ellos se saca la Ąrma o huella característica que los identiĄca (secuencia de acciones que realizan, mensajes que se producen durante su ejecución, patrones de comportamiento de los atacantes, etc.). Si se vuelven a producir eventos que coincidan con una huella de ataque conocida, se identiĄcarán como posible ataque. Son capaces de detectar con precisión y eĄciencia los ataques conocidos, pero la desventaja es que no son capaces de detectar ataques desconocidos. • Basados en especificaciones (specification-based). Aquí, se desarrollan manualmente un conjunto de especiĄcaciones y restricciones. Un evento que no cumpla lo anterior se identiĄca como un comportamiento anormal y se evalúa como posible ataque. Trata de combinar las ventajas de las dos anteriores categorías, permitiendo la detección eĄciente incluso de ataques desconocidos. Sin embargo, el desarrollo manual de las especiĄcaciones y restricciones es un proceso laborioso y suele requerir invertir mucho tiempo, sobre todo en las redes más complejas. Si se consigue simpliĄcar el sistema y reducir su superĄcie de ataque, este tipo de IDS son viables. 24 Capítulo 2. Estado del arte Se han adoptado muchos métodos para el análisis de eventos e inferir ataques. Ejemplos de estos métodos son los siguientes: •Coincidencia de patrones (pattern matching) [77]. •Desviación del comportamiento normal del tráĄco [16]. • Aprendizaje automático (machine learning) usando por ejemplo redes neuronales y máquinas de vectores de soporte (SVM, Support Vector Machines) [76]. •Macrodatos (big data) [88]. •Modelos de predicción de energía [99]. •ConĄanza y reputación [147]. Idealmente un IDS debería detectar cualquier tipo de ataque. Sin embargo, la detección de algunos ataques es difícil usando técnicas genéricas. Por este motivo algunos trabajos desarrollan detectores para ataques especíĄcos. Por ejemplo, en [ 108 ] se hace una revisión de los detectores especializados en la detección de nodos clonados en redes estáticas y [ 59 ] presenta un detector especíĄco para ataques de DoS de baja tasa basado en el análisis de señales y en macrodatos. De los trabajos previos con IDS, destacamos algunas conclusiones. Para empezar, la funcionalidad de detección en los propios nodos y la transmisión de anomalías puede suponer un consumo energético considerable. Un atacante puede aprovechar esto para provocar el agotamiento prematuro de la batería de los nodos. La detección no es perfecta y se deben considerar los efectos de los falsos positivos/negativos además de la probabilidad de que estos se produzcan. Gran parte de los trabajos previos se centran en el procesamiento de la información de anomalías, pero también se deben considerar la capacidad de observar anomalías y la transmisión de anomalías y acciones correctivas. Los atacantes pueden interferir con la transmisión de anomalías, generar anomalías falsas e incluso comprometer a los miembros de un IDS distribuido. 2.3.3 Medidas de seguridad centralizadas Los trabajos existentes presentan soluciones distribuidas y centralizadas a los problemas de seguridad. Las ventajas que los esquemas distribuidos aportan a una WSN son el aumento de la independencia y autonomía de los nodos, autoorganización y la ausencia de un punto de fallo único (single point of failure) [ 108 ]. Un punto de fallo único es un componente del sistema cuyo fallo provoca el fallo del sistema completo. Las desventajas incluyen la necesidad de incrementar el intercambio de mensajes y de realizar cálculos adicionales en nodos con recursos limitados (provocando un mayor consumo energético), el uso de información local e incompleta y la mayor probabilidad de que un nodo malicioso inĆuencie al sistema completo. Los esquemas centralizados aprovechan la heterogeneidad de las diferentes entidades y tratan de que el trabajo más exigente se realice en las entidades más Ąables y con más recursos [ 25 ]. Esa entidad normalmente suele ser la BS, pero también pueden ser nodos que cumplan determinados requisitos, como que estén conectados a una fuente de alimentación 2.4 Robots en redes de sensores 25 o que tengan la mayor carga de batería, que estén situados en posiciones estratégicas, etc. La elección de las entidades encargadas puede ser permanente o por turnos. Si la elección no está predeterminada, se convierte en un problema que hay que resolver con protocolos de elección auxiliares, que, de nuevo, pueden ser distribuidos o centralizados. Estas soluciones requieren la transmisión de mensajes a mayores distancias y presentan un cuello de botella y un punto único de fallo en el elemento centralizado. Además, es necesario que existan rutas establecidas para comunicarse con él y el establecimiento de estas rutas puede ser atacado. El cálculo de rutas es una tarea que puede ser centralizada, evitando que los atacantes puedan inĆuir en el proceso. En la versión básica de INSENS (Intrusion-Tolerant Routing in Wireless Sensor Networks) [ 25 , 26 ], la BS calcula las rutas a ella desde todos los nodos y selecciona los vecinos con los que un nodo debe comunicarse usando la información topológica local que estos le envían. Se hará una descripción más detalla de este trabajo en la Sección 2.7 dada sus similitudes con el trabajo desarrollado en esta Tesis Doctoral. Más reciente es el protocolo descrito en [ 3 ], donde el cálculo de rutas también se realiza en la BS buscando la detección del wormhole attack (en la Sección 5.2.21 se describe este ataque) aunque sin ofrecer protección contra otros tipos de ataques. Otro ejemplo de enrutamiento centralizado es el paradigma Redes DeĄnidas por Software (SDN, Software DeĄned Networking), que desacopla el plano de control, que es el plano de red que toma las decisiones de cómo enrutar paquetes, del plano de datos, que es el plano que realiza el reenvío de paquetes. Esto ha sido aplicado en las WSN haciendo que los nodos reciban instrucciones de un controlador centralizado de cómo deben procesar los paquetes que reciben. El trabajo [ 104 ] ha hecho un extenso estudio de implementaciones de SDN en WSN. SDN hace que la gestión de la red sea más Ćexible y simpliĄcada, pero requiere que la comunicación con el controlador sea Ąable. Al principio, los nodos deben descubrir una ruta al controlador por otros medios (por ejemplo, usando protocolos de encaminamiento sencillos como Collection Tree Protocol (CTP)). Posteriormente, la conexión con el controlador no debe interrumpirse. Estos requisitos permiten la aparición de nuevos ataques contra los que hay que protegerse, como muestran [132, 34]. Otros ejemplos de centralización son el uso de un centro de conĄanza en ZigBee para generar la clave de red y autenticar los nodos que se unen a la red, el uso de un centro de generación de claves para generar claves privadas parciales de nodos en [ 89 ], la elección centralizada de CH en redes con clústeres como se hace en [ 157 ] y la implementación de IDS con tareas centralizadas como se indicó previamente en [76, 132, 58]. 2.4 Robots en redes de sensores Desde el punto de vista de esta Tesis Doctoral, un robot es una entidad móvil dotada de capacidades computacionales, de detección y de comunicación. Recientemente, los robots aéreos se han convertido en herramientas comunes en tareas de monitorización tales como inspección, detección de fallos o mantenimiento predictivo, y esta tendencia parece que se incrementará en el futuro reciente [135, 111, 118]. A diferencia de los nodos sensores, los robots tienen menos restricciones en computación, consumo de energía y ancho de banda. Usados en las WSN, los robots han obtenido 26 Capítulo 2. Estado del arte resultados notables al ayudar a resolver una amplia variedad de problemas [ 138 ]. En [ 138 , 161 , 118 ] se describen trabajos y sistemas donde robots móviles colaboran con las WSN. Por ejemplo, los robots se han empleado para: • Localización de nodos. El robot puede ubicarse a sí mismo mediante técnicas de localización con dispositivos que empleen un sistema global de navegación por satélite (GNSS, Global Navigation Satellite System) o sin ellos y a partir de su posición usar triangulación con medidas RSSI para localizar a los nodos [116]. • Despliegue, reparación y sustitución de nodos. El robot teleoperado o de manera autónoma puede transportar y situar nodos sensores (nuevos o de reemplazo) en las posiciones deseadas, sobre todo en lugares de difícil acceso. También se puede utilizar para reparar o reposicionar los nodos [95]. • Reparación temporal del funcionamiento de la WSN. Un robot puede sustituir temporalmente un fallo de un nodo que afecte a la conectividad de la red [23]. • Recargar baterías. Algunos investigadores han usado el robot para que periódicamente vaya recargando la batería de los distintos nodos. • Agregación y recolección de datos. El robot hace rondas visitando a todos los nodos y ayuda a transportar la información obtenida por los sensores al sumidero. También puede hacer las veces de sumidero intermitente [94]. • Extensión de cobertura. El robot conecta zonas de la WSN aisladas del resto, como si fuera un router. Sin embargo, a pesar de sus ventajas potenciales, la cooperación entre redes de sensores y robots para mejorar la seguridad de WSN aún está poco investigada [118]. En muchos trabajos que integran robots móviles con WSN, la seguridad suele ser un objetivo accesorio o un efecto secundario. Por ejemplo, si un robot se emplea para mejorar la robustez ante fallos de conectividad, también aumenta la protección contra ataques DoS. A continuación, se describen dos trabajos que sirven como ejemplo de esto. En [ 157 ] se usa un vehículo aéreo no tripulado (UAV, Unmanned Aerial Vehicle) para seleccionar los nodos que funcionarán como CH de una WSN con clústeres. El UAV da vueltas constantemente por el área ocupada por la WSN recopilando la energía disponible en cada nodo y los datos generados por el clúster desde la última vez. Con los datos de energía disponible, se elige a los nodos que tengan más energía como CH. Se parte de la hipótesis de que un atacante siempre quiere convertirse en CH, lo que le permitiría falsiĄcar todos los datos del clúster, pero los nodos no pueden inventarse su energía residual durante mucho tiempo porque se está monitorizando periódicamente y se detectarían valores incoherentes con facilidad. Demuestra, mediante simulaciones, que este tipo de elección centralizada reduce el consumo y la probabilidad de que un nodo malicioso sea elegido como CH respecto a otros protocolos de elección de CH. Presupone que el robot y la BS conocen la posición exacta de todos los nodos y pueden calcular en qué momento pasará el robot por cada zona. La BS notiĄca a todos los nodos la hora de la próxima visita del robot. El resto de medidas de seguridad son simples: cada nodo tiene claves simétricas preestablecidas con el robot, la BS y una lista de vecinos que se emplean para establecer al inicio otras claves de comunicación entre ellos y una clave de grupo; el robot emplea 2.4 Robots en redes de sensores 27 la clave de grupo (que todos los nodos de un clúster conocen y podrían utilizar si son maliciosos) para enviar por difusión la identidad del CH elegido y una lista negra de nodos que se deben excluir; simula su propuesta considerando que no se pueden producir ataques durante la fase de establecimiento de claves; y no considera ningún ataque diferente al previamente comentado. El trabajo [ 75 ] propone usar un UAV para la recolección de datos directamente desde una serie de nodos que denomina anclaje de datos (data anchors), que pueden ser los CH u otros nodos, y, para este propósito, desarrolla un algoritmo de selección de ruta. El objetivo principal es maximizar el tiempo de vida de la red, optimizando la elección de los nodos de anclajes de datos y una ruta que pase por todos ellos. La elección de la ruta la modela como un caso de problema del vendedor viajero (TSP, Traveling Salesman Problem) en vez de un problema de planiĄcación de ruta de cobertura [ 20 ], sin tener en cuenta el alcance radio y obligando a que el robot pase exactamente por la posición de cada nodo de anclaje de datos. Adicionalmente a ese objetivo, se añade la posibilidad teórica de que el UAV sea capaz de tomar las mismas medidas que realizan los nodos sensores para comprobar si un nodo está comportándose correctamente y calcular un índice de conĄanza. No se indica cómo los nodos saben cuál es su anclaje de datos más cercano y si ellos lo son ni ninguna otra medida de seguridad. Desde el punto de vista de la seguridad general de la WSN, el número de trabajos es muy pequeño y los robots se han propuesto principalmente para la tarea de distribuir claves, como por ejemplo [146, 130] que se describen a continuación. En [ 146 ] se usa un elemento móvil para distribuir claves simétricas compartidas a un grupo de nodos situados en una zona alrededor de él de pequeño radio, para sustituir los esquemas de predistribución de claves simétricas aleatorias. Esto se realiza tratando de minimizar las zonas de diseminación y el número de claves que debe almacenar cada nodo, pero garantizando la conectividad de la red, tanto si se conoce la posición de los nodos como si no. Todas las claves son simétricas y para la autenticación utiliza una adaptación de µ Tesla [ 117 ] que se basa en el uso de una cadena hash unidireccional (OHC, One-way Hash Chain) (ver la Sección 2.7). Todos los nodos llevan preinstalada una clave global y el último valor de la OHC. En cada zona, el robot envía dos mensajes, uno con la clave que se quiere difundir cifrada con la clave global y otro para autenticar el mensaje anterior. Este sistema presenta varias vulnerabilidades. Un atacante puede obtener las claves transmitidas si se hace con la clave global comprometiendo uno de los nodos. El uso de OHC es susceptible de ataques packet duplication (ver descripción en Sección 5.2.33) yrushing attack. Por último, solo se consideran ataques pasivos a nivel local y el autor menciona que el robot podría monitorizar la red para detectar claves comprometidas y revocarlas, aunque no explica cómo llevarlo a cabo. En [ 130 ] se usa un UAV como centro de coordinación y distribución de claves públicas. Un nodo que quiere comunicarse con otro nodo vecino, que previamente ha anunciado su identidad por difusión, debe solicitar la clave pública del otro extremo al UAV. El robot conoce la clave pública autorizada para cada identidad y los nodos solo necesitan conocer a priori la clave pública del robot. Todas las comunicaciones con el UAV van cifradas con criptografía asimétrica. Los nodos confían en el UAV y se supone que el robot no puede capturarse, así que la clave pública devuelta por el robot se supone auténtica. El vecino debe también realizar el mismo proceso. Ambos nodos, usando las claves públicas, acuerdan 28 Capítulo 2. Estado del arte una clave simétrica que utilizan para cifrar el resto de sus comunicaciones (mediante el algoritmo RC4 que en la actualidad está desaconsejado). El autor no menciona ninguna medida para evitar la duplicación de mensajes o que impidan la falsiĄcación de identidades ni cómo se comunican nodos que no sean vecinos, limitándose a la tarea descrita. Además, parece ineĄciente el empleo exclusivo de la criptografía asimétrica en las comunicaciones con el UAV (a diferencia de lo que se hace entre nodos). Estos trabajos restringen el rol del robot a la distribución de claves y no aprovechan completamente la cooperación entre los robots y las WSN o las capacidades del robot en otras tareas de seguridad. 2.5 Comparación del estado del arte A continuación, se muestra una taxonomía de los principales trabajos descritos en las secciones anteriores, para dar una visión general al lector de las características de esos trabajos, y, después, se hace una comparación de SNSR respecto a los trabajos anteriores. 2.5.1 Taxonomía del estado del arte La Tabla 2.1 muestra la taxonomía de los trabajos previamente presentados más recientes o signiĄcativos, de acuerdo al tema de seguridad tratado, sus mecanismos de defensa, el uso de mecanismos centralizados y el empleo de robots móviles. En esta tabla se han usado las siguientes abreviaturas y símbolos: Ref. Referencia bibliográĄca del trabajo ✓Sí ×No P Mecanismos de prevención D Mecanismos de detección M Mecanismos de mitigación C Mecanismos centralizados R Uso de robots móviles Tabla 2.1 Taxonomía del estado del arte. Ref. Tema P D M C R Características destacadas [83] Criptografía ✓× × × × PKI distribuido implementado con ECC en nodos sensores de bajos recursos [152] Criptografía ✓× × × × Implementación hardware de algoritmos criptográĄcos en sensores, incluyendo ECC Continúa en la siguiente página ż 2.5 Comparación del estado del arte 29 Tabla 2.1 (Continúa de la página anterior) Ref. Tema P D M C R Características destacadas [121] Criptografía ✓× × × × Revisión de protocolos de WSN que usan ECC, nuevo protocolo que almacena claves públicas prevalidadas en los nodos [63] Criptografía ✓× × × × Se usa ECC para la gestión distribuida de claves grupales [89] Criptografía ✓× × ✓× Agregación de Ąrmas ECC, adaptación de criptografía asimétrica sin certiĄcados a WSN [113] Estándar ✓× × ✓× Arquitectura comercial estándar con protocolos que usan tanto criptografía simétrica como asimétrica [62] Criptografía ✓× × ✓× Pautas para reducir la sobrecarga del uso de PKI en IoT [168] Criptografía ✓×✓ ✓ × Adaptación de criptografía asimétrica basada en identidad a WSN [76] IDS ×✓×✓× Recopilación centralizada de anomalías, IDS basado en anomalías [153] IDS ×✓×✓× Detección de anomalías realizada en todos los nodos [11] IDS, Enrutamiento ✓ ✓ ✓ × × Detección y análisis de anomalías realizados solo en nodos seleccionados [58] IDS ×✓×✓× Solo la BS detecta ataques analizando el tráĄco de red, IDS basado en uso indebido [158] IDS ×✓×✓× La detección se realiza de forma heterogénea en función de los recursos de cada entidad [88] IDS ×✓× × × Recopilación y detección distribuidas y procesamiento de big data [99] IDS ×✓ ✓ ✓ × Recopilación de anomalías distribuidas, detección de ataques mediante modelos de predicción de energía [59] IDS ×✓×✓× IDS especíĄco para ataques DoS de baja tasa en protocolos de enrutamiento [147] IDS ×✓× × × IDS basado en conĄanza y reputación con parámetros ambientales [26] Enrutamiento ✓× × ✓× Protocolo de enrutamiento seguro donde la BS calcula todas las rutas y vecinos de todos los nodos [3] Enrutamiento ✓ ✓ ✓ ✓ × Protocolo de enrutamiento reactivo centralizado para detectar solo wormhole attacks Continúa en la siguiente página ż 30 Capítulo 2. Estado del arte Tabla 2.1 (Continúa de la página anterior) Ref. Tema P D M C R Características destacadas [132] IDS ×✓×✓× Revisión de ataques especíĄcos a SDN en WSN, IDS especializado para SDN [157] Elección de CH ✓× × ✓ ✓ Elección centralizada asistida por UAV de CH para evitar la interferencia de nodos maliciosos [75] Recolección ×✓×✓ ✓ Se emplea un UAV para recopilar datos y tomar medidas directas. [146] Criptografía ✓× × ✓ ✓ Distribución basada en geometría de claves compartidas a un grupo de nodos usando un robot móvil [130] Criptografía ✓×✓ ✓ ✓ El uso de un UAV como centro de distribución y coordinación de claves públicas 2.5.2 Comparativa con el trabajo realizado No es fácil comparar SNSR, que se describirá con más detalle en el Capítulo 3, con otros trabajos previos. SNSR considera la seguridad de la WSN en su conjunto incluyendo mecanismos de prevención, detección y mitigación desde el establecimiento de la red, mientras que la mayoría de los trabajos previos se centran en aspectos de seguridad concretos. Además, el uso de un robot en WSN solo se considera teóricamente en unos pocos trabajos de manera muy limitada. Aunque SNSR aún no ha sido detallado, en esta sección se va a hacer una comparativa a alto nivel de sus ideas claves, técnicas y funcionalidades respecto a otros trabajos. La utilización de criptografía asimétrica ECC en WSN ya se ha realizado en [ 113 , 83 , 152 , 121 , 63 , 89 ], y hay diferentes alternativas para autenticar las claves públicas [ 62 , 168 , 89 ]. La arquitectura propuesta podría funcionar con cualquiera de ellas, pero se propone el uso de PKI con reanudación de sesión y prevalidación de certiĄcados por eĄciencia. SNSR también va a requerir el empleo de un protocolo de intercambio de claves autenticado, pero es Ćexible y no impone ninguno. En la implementación realizada, se ha preferido usar el protocolo estándar DTLS, que está ampliamente probado y escrutado. En SNSR, todas las entidades de la red detectan anomalías (a diferencia de [ 11 ]o[ 58 ]), de acuerdo con su rol, en línea a lo que hace [ 158 ], pero de una manera mucho más simple: reportando fallos de comunicación o comportamientos que no siguen la especiĄcación (sin carga computacional adicional) y aprovechando la observación directa del robot. La detección de anomalías en los nodos implica principalmente costos de transmisión, pero proporciona una detección de ataques más rápida y evita el uso continuo del robot. La recopilación y el análisis de anomalías están centralizados en la BS (a diferencia de [ 88 ] o [ 99 ]) para liberar recursos en los nodos. La simpliĄcación proporcionada por SNSR hace posible implementar un IDS basado en especiĄcaciones y no excluye el uso de otros IDS como [ 120 ] y [ 76 ] o detectores para ataques especíĄcos utilizando la infraestructura proporcionada. A diferencia de muchos IDS que solo proponen algoritmos de detección 2.6 Descripción de ZigBee con el perfil de aplicación ZigBee Smart Energy 31 [ 59 , 88 , 153 ], SNSR también tiene mecanismos de mitigación que pueden cambiar la conĄguración de la red durante los ataques. Solo [ 11 ] y [ 99 ] proponen otros mecanismos de mitigación. SNSR reduce signiĄcativamente las tareas que realizan los nodos, el componente más débil desde el punto de vista de la seguridad en WSN, con el ahorro computacional y energético que ello conlleva. Por ejemplo, los nodos no realizan el descubrimiento de vecinos o la BS, una tarea común en otros trabajos [ 26 , 113 , 130 ]. Además, SNSR evita la necesidad de protocolos de enrutamiento dinámicos, lo que reduce aún más la inĆuencia de los nodos. Puede soportar varios mecanismos de enrutamiento. También podría usar enrutamiento estático durante la creación de la red y luego cambiar a un enrutamiento distinto como SDN. Algunos trabajos asumen que los requisitos de seguridad durante la conĄguración inicial de la red pueden ser menores que durante el funcionamiento normal porque hay más supervisión. Por ejemplo, en [ 146 ], al principio, todos los nodos comparten la misma clave global. Sin embargo, [ 26 ] y SNSR consideran en su diseño que los nodos podrían tener software malicioso preinstalado o que siempre es posible realizar ataques pasivos. En cuanto a seguridad de las WSN con robots, [ 157 ] presenta un método para la elección de CH asumiendo que los nodos maliciosos reportan un mayor consumo de energía y no pueden engañar al UAV. [ 75 ] requiere que el robot tenga las mismas capacidades de detección que los nodos sensores para determinar la conĄabilidad de los nodos. En ambos trabajos la seguridad es un objetivo secundario y se centran únicamente en problemas particulares. [ 146 ] distribuye claves simétricas a un grupo de nodos, pero un atacante podría escuchar las claves transmitidas si conoce la clave global preinstalada en todos los nodos. Además, el robot se autentica mediante técnicas basadas en cadenas hash, que son susceptibles de sufrir ataques packet duplication yrushing attack. El trabajo [ 130 ] propone un protocolo de acuerdo de claves usando criptografía con claves públicas obtenidas de un UAV para evitar almacenarlas en nodos. Ni [ 146 ] ni [ 130 ] consideran la captura del UAV. Esto sería fatal para la seguridad ya que el UAV tiene información insustituible, que también está preconĄgurada en los nodos. En SNSR, el robot no distribuye claves. Prevalida las claves públicas, por lo que los nodos necesitan menos esfuerzo para detectar claves incorrectas. Además, la captura de un robot no es crítica ya que es posible revocar el certiĄcado del robot capturado y utilizar otro robot con un certiĄcado y claves diferentes. 2.6 Descripción de ZigBee con el perfil de aplicación ZigBee Smart Energy ZigBee [ 8 ] es una especiĄcación de protocolos que se apoyan en el nivel físico y de MAC del estándar IEEE 802.15.4 [ 1 ] para LR-WPAN que se usa para crear redes WSN con poco ancho de banda, entre otras aplicaciones. La deĄne el Connectivity Standars Alliance, antes llamado ZigBee Alliance, desde el 2004. Se han creado varias versiones y en esta Tesis Doctoral se describe la versión de 2015, que era la más reciente con documentos públicos accesibles a la fecha de comienzo de su análisis. Otros autores han analizado las versiones anteriores [ 170 , 10 ], e incluso algunos detectaron fallos de seguridad [ 169 , 137 ]. 38 Capítulo 2. Estado del arte distintos fabricantes sean compatibles. Los dominios de aplicación clave son la medición, la tariĄcación, la detección de errores y la respuesta a la demanda y el control de carga. En estos entornos los requisitos de seguridad son altos. Se han creado varias versiones y en esta Tesis Doctoral se describe la versión 1.2a [ 113 ], que era la más reciente de la cual se disponían documentos públicos a la fecha de comienzo de su análisis. En ZSE, el TC siempre debe ser el ZC, que a su vez debe ser un punto de suministro (Energy Service Interface) capaz de comunicarse con la red de la compañía suministradora. También se introduce el concepto de redes de área doméstica virtuales que se forman en ediĄcios con múltiples viviendas que comparten red ZigBee. En estas redes, el TC, conocido como TC federado, contiene información de los dispositivos que forman parte de cada red virtual y previene la comunicación a nivel de aplicación entre dispositivos de diferentes redes virtuales. La principal medida de seguridad de ZSE es que requiere el establecimiento de claves con el TC mediante el uso de CBKE. Esto debe ser realizado en un punto Ąnal diferente al empleado por el resto de ZSE, que se denomina Key Establishment y que debe de ser descubierto antes de poder realizar el CBKE. El CBKE usa ECC según los algoritmos deĄnidos en Standards for Efficient Cryptography 1 (SEC 1) [ 19 ], con 2 suites de cifrado. La más débil utiliza claves públicas de 22 bytes, con la curva sect163k1 dando lugar a certiĄcados de 48 bytes. La otra usa claves públicas de 37 bytes, con la curva sect283k1 , generando certiĄcados de 74 bytes que equivalen a usar claves simétricas de 128 bits. Se requiere fragmentación para poder transmitir estos certiĄcados. Cada dispositivo tiene una clave privada y un certiĄcado digital Ąrmado por una CA. El certiĄcado digital incluye la clave pública, la dirección IEEE extendida del dispositivo de 64 bits e información adicional como el tipo de dispositivo, el identiĄcador de la red, fechas de validez, etc. Los certiĄcados proporcionan un mecanismo para vincular criptográĄcamente una clave pública con la identidad y las características de un dispositivo. Los dispositivos también tienen la clave raíz pública de la CA para validar los certiĄcados. Los certiĄcados pueden ser generados por el fabricante, el distribuidor o el usuario Ąnal. Tras realizarse el procedimiento CBKE entre dos dispositivos, ambos comparten la misma clave LK, se han autenticado, han conĄrmado que la clave es correcta y que ningún extremo ha controlado la generación de la clave. La nueva LK es única y cumple el requisito de secreto perfecto hacia adelante (PFS, Perfect Forward Secrecy). Durante la puesta en marcha de los dispositivos es obligatorio el uso de TCLK únicas preinstaladas derivadas de códigos de instalación que han sido previamente comunicados al TC. No se permiten uniones a la red con claves globales. La TCLK preinstalada solo se utiliza para obtener la NK y realizar operaciones que solo requieran cifrado en el nivel de red. Solo se utilizan en la primera autenticación y solo se admitirán de nuevo si el dispositivo es expulsado de la red y posteriormente se une. El TC no elimina las claves de un dispositivo al recibir un anuncio de que se marcha, pero sí cuando él lo expulsa. Así evita ataques de DoS si se suplantan las direcciones. Cualquier operación que use el cifrado en el APS requiere la obtención de una nueva TCLK usando CBKE. En APS es obligatorio el uso de fragmentación debido a la longitud de algunos comandos. Todos los comandos deĄnidos por ZSE van cifrados con la LK, aunque se siguen usando otros comandos previamente deĄnidos que solo usan NK, como los usados en el 2.7 Descripción de INSENS 39 descubrimiento de servicios. Se puede (y se recomienda si hay conĄanza) usar el establecimiento de claves entre dispositivos usando como intermediario el TC. Un dispositivo puede prohibir la comunicación con el punto Ąnal Key Establishment si el solicitante no es el TC. Así, el TC puede aplicar políticas, realizar comprobaciones y la Lista de Revocación de CertiĄcados (CRL, CertiĄcate Revocation List) estaría centralizada. Antes de pedir una clave LK al TC, se intenta hacer una vinculación con el otro destino y solo si le responde con éxito se pone en contacto con el TC. El otro dispositivo aceptaría solo nuevas LK esperadas. Existen otros aspectos que pueden inĆuir en la seguridad. En ZSE es importante que los dispositivos estén sincronizados por lo que hay servidores de tiempo (ordenados por preferencia) y clientes que se sincronizan a ellos. La sincronización se intenta realizar una vez al día para no sobrecargar la red, utilizando cifrado en el APS. Existe la posibilidad de comunicar alarmas y errores a un dispositivo central. Se deĄne un procedimiento para cambiar el TC estando la red en funcionamiento, haciendo previamente copias de seguridad de toda la información del TC existente, salvo de las LK (se guardan en su lugar los valores devueltos al aplicar una función hash). Los dispositivos deben establecer una nueva TCLK usando CBKE tras el cambio. La comunicación Inter-PAN está admitida y la existencia de dispositivos no ZSE con códigos de instalación registrados en el TC, pero que no podrán obtener nuevas LK. Por último, si se permite la actualización remota de Ąrmware, este debe ir Ąrmado digitalmente usando el Algoritmo de Firma Digital de Curva Elíptica (ECDSA, Elliptic-Curve Digital Signature Algorithm). 2.7 Descripción de INSENS El protocolo INSENS (Intrusion-Tolerant Routing in Wireless Sensor Networks) [ 25 , 26 ] es un protocolo que trata de minimizar y tolerar los efectos que pueden provocar nodos maliciosos dentro de una red de sensores. En [ 25 ] se describe INSENS para una WSN con una BS que es reĄnado en [ 26 ], donde se le denomina INSENS básico. En esta Tesis Doctoral haremos referencia a él simplemente como INSENS. En [ 26 ] también se muestra un INSENS mejorado para WSN con múltiples BS, que, a pesar de su nombre, es un protocolo totalmente diferente que solo comparte el objetivo con el anterior. INSENS no intenta detectar atacantes, solo ignorarlos o tolerarlos, alegando que la detección es costosa y difícil de llevar a cabo en las WSN. Un atacante puede hacer que una parte de la red quede inoperativa, por lo que únicamente es adecuado para aplicaciones no críticas con medidas redundantes. El objetivo es mejorar la seguridad de los mensajes procedente de los nodos con destino a la BS. No se considera la comunicación entre nodos distantes ni el envío de mensajes desde la BS a los nodos salvo durante el establecimiento de la red. Para proteger los mensajes, los nodos comparten una clave con la BS, que se utiliza para generar otras claves de cifrado simétrico y de generación de MAC, y un número de secuencia inicial de cadena hash unidireccional (OHC, One-way Hash Chain) usado para autenticar los mensajes de difusión (adoptado de µ Tesla [ 117 ]). La BS es la única entidad autorizada a iniciar difusiones. Una OHC consiste en una secuencia de números generados por la BS aplicando sucesivamente una función hash unidireccional H : n1,n2,...,nk−1,nk:nk=H(nk−1) . Se comparte el último número nk con los nodos y 40 Capítulo 2. Estado del arte en cada difusión se incluye un número de secuencia previo. Los nodos pueden veriĄcar que el mensaje ha sido originado por la BS si el número de secuencia guardado o el último visto se obtiene aplicando H repetidamente un número limitado de veces. Este mecanismo es eĄciente, pero tiene como inconvenientes la posibilidad de agotar la secuencia a lo largo de la vida de la red o la posibilidad de que un nodo no pueda comprobar la autenticidad si pierde muchos mensajes previos si no se incorporan mecanismos para el reinicio de la secuencia como ocurre en este trabajo. Los sensores no autentican ni cifran los mensajes intercambiados entre sí. La principal novedad de INSENS es el descubrimiento de rutas, que se realiza en tres rondas de mensajes (todos incluyen el mismo número de secuencia de OHC). Primero la BS envía un mensaje de petición de ruta (REQ) a todos por inundación. Esto se utiliza también para que los nodos detecten a sus vecinos. Los nodos vuelven a reenviar el mensaje REQ si el número de secuencia es válido y no está repetido, guardando la información de sus vecinos. En el mensaje reenviado se modiĄca el identiĄcador del origen y un MAC usando la clave compartida con la BS y que es calculado a partir del que tenía el primer mensaje recibido (MAC anidado), cuyo origen se convierte en su nodo padre. Los nodos no pueden veriĄcar los MAC recibidos, pero los almacenan para enviarlos posteriormente a la BS. En segundo lugar, los nodos envían un mensaje de feedback (FDBK) a la BS con los identiĄcadores y MAC recibidos de cada vecino cifrados con la clave compartida con la BS, utilizando como siguiente salto su nodo padre. Por último, la BS recopila información de la topología a partir del conocimiento parcial que cada nodo le envía, comprobando que es coherente y calcula las rutas. INSENS permite distintas técnicas de cálculo, pero los autores proponen uno para su implementación con 2 rutas (la más corta y otra que no contenga nodos de la primera ni de sus vecinos ni de vecinos de vecinos, en lo posible). La BS envía un mensaje encriptado a cada nodo según el orden seguido por una búsqueda en anchura (BFS, Breadth First Search) conteniendo la tabla de reenvío. A diferencia de las tablas de reenvío más habituales que eligen el siguiente salto según el destino, aquí la elección se realiza usando el destino, el origen y el último emisor para asegurar que los mensajes siguen la ruta establecida por la BS. En el mismo trabajo se reconocen limitaciones de seguridad, por ejemplo, indicando que es vulnerable al ataque rushing. Un análisis de seguridad en profundidad de INSENS se realizará en la Sección 5.2. También existen limitaciones de funcionamiento en tanto que no se proponen procedimientos para añadir o eliminar nodos, el reinicio de la OHC en el caso de que se agotara la secuencia y la fragmentación de mensajes largos. Para los experimentos se utilizó un mecanismo sencillo de fragmentación y cifrado RC5 en modo CBC usando 12 rondas que en la actualidad es inseguro [13]. El protocolo INSENS mejorado pasa a ser totalmente distribuido. Ahora se utilizan varias BS que no calculan las rutas ni las vecindades ni tienen contraseñas individuales compartidas con cada nodo. Las únicas similitudes con INSENS son el empleo de OHC para autenticar los mensajes REQ empleados para anunciar la presencia de las BS. Los nodos deben mantener un número de OHC por cada BS. La seguridad se basa en el empleo de una clave global preinstalada en todos los dispositivos que estos usan para intercambiar claves aleatorias de manera cifrada. Cada nodo genera una clave individual para cada vecino con el que sea posible una comunicación bidireccional y otra común para reenviar los mensajes REQ mediante difusión. Después del intercambio de claves, se borra la clave 2.8 Conclusiones 41 global. Para permitir la introducción posterior de nuevos nodos, se guardan una serie de números aleatorios y sus MAC usando la clave global para poder veriĄcar que los nuevos poseen la clave global original. Los nodos envían los datos a todas las BS simultáneamente siguiendo los caminos inversos a los realizados por los mensajes REQ. Los mensajes se cifran en cada salto usando la clave individual que establecieron cada par de vecinos. Si un atacante consiguiera hacerse con la clave global antes de que fuera borrada por un nodo, toda la red quedaría expuesta a posteriores manipulaciones. Esta es la principal debilidad de este protocolo. 2.8 Conclusiones La seguridad es crítica en muchas aplicaciones de monitorización basadas en WSN que operan de manera desatendida durante largos períodos de tiempo. La gran superĄcie de ataque que presentan las WSN y los diferentes requisitos de seguridad han motivado el desarrollo de una amplia variedad de arquitecturas y protocolos para prevenir, detectar y mitigar muchos tipos de ataques. Muchas técnicas de seguridad de redes clásicas se consideran demasiado complejas para ser realizadas con los recursos limitados de las WSN, por lo que muchas soluciones tienden a simpliĄcarlas. Además, muchos trabajos se centran en ataques especíĄcos. Recientemente, los robots aéreos se han convertido en herramientas comunes en muchas tareas de monitorización, como inspección, detección de fallos o mantenimiento predictivo, y esta tendencia parece ir en aumento. La cooperación entre robots y WSN ha obtenido resultados notables en muchos problemas. Sin embargo, a pesar de sus ventajas potenciales, el empleo de esta cooperación para mejorar la seguridad de las WSN aún está poco investigada. 3 Arquitectura de seguridad La simplicidad es la máxima soĄsticación. Leonardo da Vinci Es te capítulo está destinado a describir la Contribución 1 de esta Tesis Doctoral ŞDiseño de una nueva arquitectura de seguridad combinando robots y WSNŤ y la Contribución 2 de esta Tesis Doctoral ŞArquitectura SNSR con un robot y una estación baseŤ. En él se presenta el diseño de una nueva arquitectura de seguridad combinando robots y WSN, llamada SNSR, que explota las sinergias entre el procesamiento heterogéneo y las capacidades de comunicación del robot y los nodos sensores con el Ąn de proporcionar soluciones computacionalmente eĄcientes y seguras contra los ataques de estas redes. Los robots se emplean para conĄgurar el funcionamiento seguro de la WSN y son responsables de realizar la autenticación de los nodos sensores. La comunicación en un solo salto entre un robot y cada nodo sensor mejora signiĄcativamente la seguridad. La arquitectura SNSR se puede adaptar a redes ya existentes y es Ćexible al proponer alternativas a la hora de realizar muchos procedimientos que pueden ser particularizados en diferentes implementaciones y conĄguraciones. SNSR se puede generalizar para el uso de múltiples BS y robots simultáneamente. Solo se contempla el caso con un robot y una BS en esta Tesis Doctoral y, por sencillez, SNSR se explica usando este caso. El capítulo se puede dividir en tres grandes bloques. En la Sección 3.1, se comenzará analizando el problema de la seguridad en las WSN utilizadas en instalaciones industriales o infraestructuras. Después, en la Sección 3.2 se esbozará la idea propuesta. Comenzando con el segundo bloque, la Sección 3.3 describirá la arquitectura de la red, incluyendo los requisitos que debe cumplir la torre de protocolos de la WSN donde se vaya a implementar y los fundamentos para garantizar una comunicación segura y Ąable entre componentes de la red. Al Ąnal de este bloque, se dará una visión general de las fases de funcionamiento y las relaciones que se producirán entre los distintos tipos de entidades. En el último bloque, que comienza en la Sección 3.4, se profundizará en la información de la topología de la red almacenada, así como el funcionamiento y protocolos utilizados en cada una de las fases de la red. Se terminará, en la Sección 3.10, con un cuadro resumen 43 44 Capítulo 3. Arquitectura de seguridad de todas las opciones que permite la arquitectura SNSR y los parámetros de conĄguración vistos a lo largo del capítulo. 3.1 Planteamiento del problema Un conjunto de nodos sensores estáticos (que también se denominarán simplemente nodos o, por asociación, sensores) están desplegados en unas instalaciones industriales o en una gran infraestructura civil. Cada nodo recopila mediciones que interesan ser supervisadas, Ąltra las mediciones y las transmite a una estación base (BS, Base Station), que también es estática. En la BS las mediciones son registradas, procesadas y/o transmitidas a un centro remoto. Esta es una conĄguración típica de muchos esquemas existentes en aplicaciones de monitorización. Además de los nodos sensores y la BS, el sistema incluye un robot aéreo, también denominado vehículo aéreo no tripulado (UAV, Unmanned Aerial Vehicle) o genéricamente estación móvil (MS, Mobile Station), que realiza tareas de inspección y detección de fallos. A los elementos participantes en la red los llamaremos genéricamente entidades y existirán tres tipos: BS, robot y nodo sensor. La Figura 3.1 muestra un ejemplo de red. Alcance radio máximo 1 2 3 4 5 6 7 9 8 10 11 12 Figura 3.1 Ejemplo de topología de red. 3.1.1 Consideraciones sobre la estación base Se supone que la estación base es un equipo con suĄcientes recursos (memoria, potencia computacional, comunicaciones) y no está limitada en cuanto al consumo de energía que puede utilizar por estar conectada directamente a la red eléctrica mediante un sistema de alimentación ininterrumpida. Dispondrá de varios adaptadores de red que le permitirá conectarse a distintas redes usando diferentes tecnologías de comunicación. Podrá conectarse a la WSN como sumidero de información, a la red local de la empresa y, opcionalmente tendrá una conexión de largo alcance radio con el UAV (de mayor alcance que las conexiones que puede tener con los nodos). Se supone que está lo suĄcientemente protegida y vigilada de tal manera que sea prácticamente imposible el acceso no autorizado a ella y su manipulación. 3.1 Planteamiento del problema 45 3.1.2 Consideraciones sobre los nodos sensores Se supone que los nodos son dispositivos con limitaciones computacionales y energéticas, porque son de bajo costo o están alimentados con baterías y deben consumir la menor cantidad de energía posible durante su funcionamiento. Cada sensor tiene un rango de alcance radio rde manera que, si la distancia entre dos nodos es menor que r, podrán comunicarse. Un robot o una BS podrían tener un rango de alcance mayor, pero no podrían comunicarse bidireccionalmente con un nodo si se encuentran a una distancia mayor de r. No se consideran distintos tipos de nodos (al contrario de lo que hace el estándar IEEE 802.15.4 [ 1 ]). Todos los nodos contemplados tienen la capacidad de reenviar mensajes. La topología de la red formada por los nodos y la BS es una topología de malla en la que existen nodos que no tienen conectividad directa con la BS, por lo que muchos mensajes deben realizar varios saltos para llegar a su destino. La topología de árbol podría verse como un caso simpliĄcado de topología de malla. La Figura 3.1 muestra un ejemplo de topología de red considerada en esta Tesis Doctoral. Los nodos sensores están diseñados para operaciones de monitorización a largo plazo y no hay fuertes medidas de seguridad para acceder a ellos, por lo que están expuestos a degradación por el medio ambiente y ataques maliciosos incluyendo la manipulación del propio dispositivo y del software que ejecuta, la extracción de información, la clonación o la destrucción total. El número de nodos puede ser desde unos cientos de nodos o menos (red mediana) hasta miles de nodos o más (red grande). Los nodos no son móviles y la posición de cada uno de ellos es estática en circunstancias normales. 3.1.3 Consideraciones sobre los robots Al igual que una BS, un robot es un equipo con muchos recursos (memoria, capacidad computacional, comunicaciones) y su consumo de energía puede ser mucho mayor que la de cualquier nodo, ya sea porque dispone de una batería de gran capacidad o porque la recarga pueda hacerse de manera sencilla y rápida. Pero, a diferencia de una BS, es más probable un acceso no autorizado a él mediante la captura y robo por parte de un agente malicioso. Un robot dispone de componentes capaces de localizar la posición de las fuentes que emiten los mensajes que recibe con la suĄciente precisión para distinguir cada nodo por separado. Un robot es capaz de moverse por la zona donde están desplegados los nodos y es capaz de acercarse lo suĄcientemente a cada uno de ellos y a la BS como para establecer comunicación (a una distancia menor de r). Se da por hecho que el robot ha recibido información sobre la posición de la BS, la zona donde pueden encontrarse los nodos y el valor de r. Pueden existir varios robots en una red, pero supondremos que solo uno puede estar en funcionamiento en un determinado instante, pudiendo el resto de robots ŞsuplentesŤ relevarlo de sus funciones si las condiciones lo requieren. 46 Capítulo 3. Arquitectura de seguridad 3.1.4 Consideraciones sobre las comunicaciones Se considera que la red y el escenario son realistas, por lo que pueden producirse errores de comunicación y fallos en los nodos. La red no es muy dinámica: los nodos sensores no suelen fallar, no se añaden frecuentemente nuevos nodos a la red y los nodos son estáticos. Se asume que el canal de comunicación es no Ąable: la pérdida de paquetes puede ser originada por colisiones, interferencias y ruido entre otras causas, y la probabilidad de que ocurra no es despreciable y puede ser diferente en distintos emplazamientos del escenario. El nivel de enlace (LL, Link Layer) de cada elemento de la red comprobará, usando VeriĄcación de Redundancia Cíclica (CRC, Cyclic Redundancy Check) o un Código de Autenticación de Mensaje (MAC, Message Authentication Code), que la trama recibida es correcta y en caso contrario la descartará. Se supone que los canales de comunicación entre entidades del mismo tipo son simétricos, es decir, si una entidad xpuede recibir mensajes de otra entidad y, entonces ytambién podrá recibir mensajes de x. Existirán parámetros de comunicación que pueden ser diferentes de una red a otra. Estos afectarán al comportamiento de las comunicaciones. Serán preestablecidos por el propietario de la WSN. Ejemplos de estos parámetros son: • Tiempos de espera máximos para recibir una determinada respuesta esperada y política de reintentos. •Protocolos de seguridad empleados en cada nivel de red incluyendo algoritmos de cifrado, tipos de certiĄcados, funciones hash, etc. • Utilización de mecanismos para detectar el fallo de comunicación con el otro extremo (envío de mensajes periódicos o keepalive). Todos estos parámetros serán conocidos por conĄguración por la BS y el robot antes de su puesta en funcionamiento. 3.1.5 Consideraciones sobre las amenazas Se pueden capturar físicamente los nodos y extraer toda la información que almacena. También se puede modiĄcar el software de un nodo, de tal manera que ejecuten código malicioso. Pero todo esto no puede hacerse instantáneamente, por lo que estos ataques requieren una cantidad de tiempo no despreciable. La captura de un robot por parte de un agente malicioso se detectaría rápidamente y el atacante no tendría tiempo suĄciente para poder utilizar las claves criptográĄcas contenidas en el robot antes de que sean invalidadas. Se supone que el rango de alcance radio de un atacante des mayor que el de un nodo, ry que pueden provocar interferencias en parte de la red. Se considera que los ataques de DoS o con interferencias intencionadas (en inglés, jamming) no pueden continuar constantemente sin ser detectados y eliminados. 3.1.6 Requisitos deseados de la solución Se desea encontrar un método de conĄgurar y mantener una red de manera segura y robusta, para redes medianas o grandes. Los métodos utilizados deben ser eĄcientes energéticamente y con poca sobrecarga en el funcionamiento normal de la red. La red 3.2 Idea general de la solución propuesta 47 debe ser capaz de resistir ataques como los descritos, aunque a consecuencia de estos se comprometan o destruyan nodos o robots. 3.2 Idea general de la solución propuesta Esta arquitectura combina robots y WSN explotando las sinergias entre el procesamiento heterogéneo y las capacidades de comunicación del robot y los nodos de la WSN con el Ąn de proporcionar soluciones computacionalmente eĄcientes y seguras para los ataques más comunes. La arquitectura SNSR contiene importantes novedades sobre los esquemas de seguridad de WSN tradicionales. El robot se emplea para conĄgurar el funcionamiento seguro de la red de sensores y es responsable de realizar la autenticación y revocación de los nodos sensores. En otras palabras, el robot implementa funcionalidades de seguridad que en los esquemas tradicionales son asumidas por la estación base, permitiendo la comunicación en un solo salto entre el robot y cada nodo sensor, lo que mejora signiĄcativamente la seguridad. En la Figura 3.2, se muestra un esquema general con la arquitectura SNSR y los módulos principales de seguridad implementados en cada entidad: el robot, la BS y los nodos sensores. Además de estos módulos de seguridad, cada elemento llevará a cabo el resto de las tareas necesarias para su funcionamiento, aunque no se muestran en la Ągura, por ejemplo, para el robot, la navegación y para un nodo sensor, la recogida de mediciones. La arquitectura incluye técnicas de seguridad proactivas, como el uso de un esquema de clave pública, y también técnicas reactivas, como la detección de anomalías, que está descentralizada en cada entidad. La BS contiene los módulos principales de una PKI X.509 descritos en [ 14 ] que incluye: •Una Autoridad de CertiĄcación (CA, CertiĄcate Authority), que es responsable de emitir, actualizar y Ąrmar los certiĄcados digitales. • Una Autoridad de Registro (RA, Registration Authority), que veriĄca la identidad del propietario de un certiĄcado digital que solicita el uso de la CA. • Un Repositorio de CertiĄcados (CR, CertiĄcate Repository), que almacena e indexa certiĄcados digitales y una CRL que contiene los certiĄcados que han dejaron de ser válidos. En nuestra arquitectura, se supone por simplicidad que los anteriores tres módulos se sitúan en la BS. Sin embargo, también pueden estar en una entidad externa remota que proporcione mayor seguridad física y de red sin suponer ninguna modiĄcación en el funcionamiento del resto de módulos. La BS también incluye módulos para la sincronización de información con robots, así como la supervisión de la red y recopilación de anomalías. Opcionalmente, también puede establecer la topología de la red decidiendo vecindades y calcular las rutas entre todas las entidades. Todas las entidades de la red tendrán un certiĄcado digital X.509 Ąrmado por la CA que habrá sido instalado previamente antes de que la entidad comience su funcionamiento. Un certiĄcado digital relaciona la identidad de su propietario con una clave pública, ambos Ąrmados por la autoridad certiĄcadora. Al usar el formato X.509 [ 14 ], el certiĄcado digital 54 Capítulo 3. Arquitectura de seguridad • Puesta en marcha inicial. Recuperación de los parámetros de conĄguración, inicialización de todos los componentes y veriĄcaciones iniciales. • Detección de otras entidades como el robot y comunicación con estas a través de una aplicación de gestión. El funcionamiento con cada entidad dependerá del tipo aunque con una base común. • ModiĄcación de la conĄguración posterior para adaptarse a la topología de la red. Los nodos sensores recibirán esta conĄguración a través del robot o la BS. La BS lo hará con la información de la topología calculada. • En el caso de BS y robot, cálculo y almacenamiento de la información de la topología de red. Esta información será intercambiada entre el robot y la BS de manera que se mantenga sincronizada y actualizada. • Monitorización del funcionamiento del resto de componentes y de las comunicaciones. Detección de posibles anomalías. Las anomalías se almacenarán hasta que puedan ser transmitidas a la BS o el robot (preferentemente al que sea vecino). El robot transferirá las anomalías que haya detectado él junto con las detectadas por otros nodos a la BS lo antes posible. Servicio de seguridad El servicio de seguridad proporciona al resto de componentes de la entidad: • La realización del proceso de saludo utilizado para el establecimiento de conexiones locales o remotas que implica la autenticación del otro extremo y la negociación de algoritmos de seguridad y claves a utilizar. • Si es necesario, según la conĄguración y utilizando los algoritmos negociados, la generación de campos de cabecera adicionales para proporcionar seguridad a la transmisión de los datos en distintos niveles del plano de comunicación, el cifrado de los datos y la generación del MAC. • La implementación de los algoritmos de seguridad, de criptografía asimétrica y simétrica, de funciones hash, etc. • La generación de números aleatorios seguros. Muchos algoritmos de seguridad requieren usar números aleatorios que no deberían ser predecibles. También se utilizan en protocolos de comunicación para evitar colisiones, elegir números de secuencia o de transacciones únicos, elección de rutas, etc. •El almacenamiento de todo el material de seguridad como: – CertiĄcados de la autoridad certiĄcadora CertCA y el suyo propio Ąrmado por esta CertCA ID . –La clave privada asociada a su certiĄcado PRID . – Una Lista de Revocación de CertiĄcados (CRL, CertiĄcate Revocation List). No es necesario que los nodos sensores contengan la lista completa si todos los certiĄcados tienen un CN único. Solo necesitarían los certiĄcados revocados de tipo robot, ya que el resto de las entidades con las que se comunican han 3.3 Arquitectura 55 debido ser autenticadas antes de ser conĄgurados. La BS y el robot sí necesitan la lista completa. – Parámetros de seguridad, algoritmos empleados, números de secuencia, claves maestras y temporales, y números de serie de los certiĄcados de las entidades con las que tiene una conexión segura. Todos estos datos se utilizan durante la comunicación segura entre entidades. Si se utiliza el saludo de reanudación, que se explicará en la Sección 3.3.2.4, también incluirá un testigo que identiĄ- que unívocamente estos parámetros. El almacenamiento de los números de serie permite identiĄcar si hay establecida una conexión con una entidad que pertenece a la CRL cuando esta se actualice. – Dependiendo del modo de difusión elegido (ver Sección 3.3.1.4), es posible que sea necesario almacenar la clave pública de la estación base para poder autenticar los mensajes de difusión. Cuando un certiĄcado sea comprometido (por ejemplo, un nodo sensor o el robot ha sido capturado), este debe ser revocado por la CA (que en principio está integrada con la BS). La revocación de un certiĄcado implica la generación de una nueva CRL que debe ser transmitida a todas las entidades de la red. La transmisión a los nodos sensores se hará usando uno de los siguientes procedimientos: • La BS transmite un mensaje conteniendo la nueva versión de la CRL a cada nodo con el que la BS haya establecido una sesión de extremo a extremo. • La BS inunda la red con un mensaje de difusión que contiene la nueva versión de la CRL. Este mensaje puede ser Ąrmado por la BS para garantizar la autenticidad. • El robot también puede actualizar la CRL de los nodos que actualmente tienen una sesión establecida con él. Al recibir una actualización de la CRL, el servicio de seguridad comprobará si algunas de las conexiones actuales están utilizando los nuevos certiĄcados revocados y, si es así, cerrará estas conexiones. Tener centralizadas todas las funciones de seguridad en un único componente en vez de hacerlo en cada nivel que las necesita tiene ventajas como la reducción del espacio de almacenamiento necesario tanto en código como en memoria. Pero la reutilización de la información requiere que los distintos niveles confíen entre sí, cosa que es habitual en el software de nodos sensores [8]. Este servicio debe ser similar en todos los tipos de entidades y las funciones relacionadas con la seguridad pero especíĄcas de un tipo de entidad quedarían fuera. Por ejemplo, previamente se indicó que la BS podría contener los módulos principales de una PKI (o estar en una entidad externa) y estos módulos no serían incluidos en el servicio de seguridad. Los niveles de comunicación son independientes del nivel de seguridad empleado y de esta manera el protocolo de seguridad empleado podría cambiar sin inĆuirles. Tener protocolos de seguridad comunes en distintos niveles facilita su mantenimiento, pero implica que los protocolos sean lo suĄcientemente Ćexibles para adaptarse a las particularidades de cada nivel. Si se analizan los distintos protocolos de seguridad más utilizados (ver 56 Capítulo 3. Arquitectura de seguridad Sección 3.3.2), se pueden ver que estos tienen dos fases principales: el proceso de saludo y la fase de comunicación posterior. Las mayores diferencias se dan en el proceso de saludo, pero todos se basan en unos principios comunes. Una vez realizado el proceso de saludo, si en un nivel se añade seguridad, los datos a enviar deberán pasar por el servicio de seguridad que modiĄcará estos si es necesario y añadirá campos adicionales de cabecera. Los campos que habitualmente se añaden son [8, 125, 81]: • IdentiĄcador de la clave o conjunto de claves temporal que se están usando para proteger los datos. A veces también se conoce como época (epoch). Las entidades suelen intercambiar una clave maestra que se utiliza para derivar otras claves temporales a partir de un índice (época) usando un algoritmo. Estas claves temporales se renuevan cada cierto tiempo. Este campo es útil sobre todo durante la transición de una clave a otra, para poder decodiĄcar y veriĄcar correctamente los datos. Hay que tener en cuenta que los mensajes pueden llegar desordenados, pueden perderse, etc. • Un número de secuencia que se incrementa en cada mensaje. El nivel donde se aplica la seguridad podría tener un campo similar, así que se podría utilizar para ambas funcionalidades. Este campo protege ante la duplicación de mensajes y garantiza la frescura de los datos. Para evitar la falsiĄcación también se puede cifrar como se hace en el protocolo QUIC [148]. • Dependiendo de los algoritmos de seguridad utilizados, por ejemplo al usar el modo encriptación autenticada con datos asociados (AEAD, Authenticated Encryption with Associated Data), pueden incluirse otros campos: – Un número aleatorio que debería ser único y no repetible, que suele llamarse nonce o vector de inicialización (IV, Initialization Vector). – Un MIC o su variante que incluye autenticación MAC. El MAC suele basarse en funciones hash cuyo resultado es cifrado posteriormente. Es frecuente colocar este campo al Ąnal de los datos, por lo que no sería propiamente un campo de cabecera. –Relleno (padding). También se suele añadir al Ąnal Así, los datos, una vez protegidos con el modo AEAD, tendrían una estructura como la mostrada en la Figura 3.5, donde el tamaño de los campos es solo orientativo. dependiente del modo de seguridad z}| { época nºsecuencia nonce datos cifrados relleno MAC Figura 3.5 Formato de datos con seguridad añadida. 3.3.1.2 Nivel físico (PHY) En esta arquitectura se supone que el nivel físico (PHY, Physical layer) es inalámbrico (usando radiofrecuencia), al menos el usado por el robot con el resto de entidades. Cualquiera de los existentes podría utilizarse en principio. El nivel físico deĄnirá la modulación 3.3 Arquitectura 57 radio, la señalización, la tasa de transferencia, los canales a utilizar, cómo se controla el consumo y la potencia de la señal, etc. 3.3.1.3 Nivel de enlace de datos (LL) La funcionalidad del LL suele dividirse en 2 subniveles: •Control de Acceso al Medio (MAC, Media Access Control). •Control de Enlace Lógico (LLC, Logical Link Control). A veces, la misma funcionalidad, especialmente el control de errores y Ćujo, puede estar localizada en distintos subniveles según el protocolo, por lo que desde el punto de esta arquitectura este nivel se verá como un único bloque. En este nivel se componen las tramas y se transmiten. Una vez recibidas se comprueba su validez, detectando y/o corrigiendo posibles errores. Esta detección debe ser lo suĄ- cientemente Ąable para evitar requerir comprobaciones adicionales en niveles superiores para datos transmitidos entre dos nodos vecinos. En cuando al control de acceso al medio, la mayoría de redes inalámbricas utiliza CSMA con CA, así que se supone este protocolo de resolución de contienda. No es necesario que en este nivel se utilicen asentimientos, aunque su uso podría suponer una ventaja en entornos muy ruidosos. En algunas redes se puede sincronizar la comunicación de los participantes utilizando balizas, estructuras de supertramas y ranuras de tiempo reservadas. En esta arquitectura se supondrá que este no es el caso. Cada dispositivo tendrá asignado una dirección MAC única. Los campos mínimos que debe contener una trama de datos serán (opcionalmente pueden existir otros): •Dirección MAC destino. •Dirección MAC origen. •Datos: unidad de datos de servicio (SDU, Service Data Unit) de este nivel. •Secuencia de comprobación de trama (FCS, Frame Check Sequence). Estos campos se muestran representados en la Figura 3.6. Otros Destino Origen SDU (variable) FCS Figura 3.6 Formato de una trama de datos mínima. La longitud de los datos podría aparecer explícitamente como un campo adicional o ser calculado implícitamente restando el tamaño de la cabecera de la trama al tamaño total, si es conocido. La longitud y codiĄcación de todos estos campos serán dependientes del protocolo en concreto. El nivel superior tratará las direcciones MAC como datos opacos y podrá obtener del LL el tamaño máximo de SDU, conocido como unidad de transmisión máxima (MTU, Maximum Transmission Unit). Se supone que existirá un único protocolo de NL, por lo que no será necesario tener un campo discriminador de protocolo superior. La comunicación entre dos vecinos va a requerir una asociación previa entre estos. Esta asociación se iniciará con un proceso de saludo que se explicará más adelante. Durante la 58 Capítulo 3. Arquitectura de seguridad asociación entre dos entidades se puede veriĄcar que el otro extremo sigue en funcionamiento obligando a transmitir al menos una trama en un intervalo determinado (trama de pulso o keepalive) si no hay datos que transmitir. Este tipo de trama se puede identiĄcar con algún campo de tipo de trama o simplemente transmitiendo unos datos que no puedan ser válidos en el nivel superior. Aquí se propone la transmisión de un único byte de datos con valor 0. En los modos de seguridad SEG_L , SEG_LTE y SEG_LT , esta asociación añadirá campos adicionales a la trama que permitan proporcionar los mecanismos de seguridad deseados. Esto hará que la MTU disminuya. Antes de generarse la trama, los datos pasarán por el servicio de seguridad que los modiĄcará. En la Figura 3.7 se puede ver el proceso realizado para una trama segura. Nivel físico Nivel de Enlace Nivel de Red Plano de Gestión y Seguridad Servicio de Seguridad Segurizar Generar trama Figura 3.7 Detalle de aplicación de seguridad a una trama. Debe existir una dirección MAC de difusión que se utilizará exclusivamente para que el robot pueda anunciarse al resto de entidades. Por seguridad, se ha optado por impedir que otro tipo de entidad pueda enviar tramas de difusión. Si una entidad tiene que enviar una misma información a todos los vecinos con los que tiene una asociación previa, desde el nivel superior se deberá solicitar el envío de una trama individualizada a cada vecino con esta misma información. Si las asociaciones están cifradas, la información se cifrará con una clave diferente para cada vecino. Esto reduce el rendimiento, pero mantiene la seguridad. En la Sección 3.3.1.4, se mostrará que este caso se produce infrecuentemente. Este nivel tendrá interfaces con otros niveles/planos para las siguientes operaciones: •Con nivel superior: ↕Recepción y envío de SDU. ↑NotiĄcaciones de creación/destrucción de asociaciones. ↓ Consulta de estadísticas, información de asociaciones, reportes de calidad de enlaces. ↓Consulta de la MTU actual. 3.3 Arquitectura 59 •Con plano de gestión y seguridad: ↑NotiĄcación de creación/destrucción de asociaciones. ↕Realización del proceso de saludo: procesos de cifrado, autenticación, etc. ↓ConĄguración de parámetros y asociaciones. ↓ Consulta de estadísticas, información de asociaciones, reportes de calidad de enlaces. ↓Consulta de la MTU actual. •Con nivel inferior: ↕Recepción y envío de PDU. En el anterior listado, el símbolo ↓ indica que la operación es un servicio ofrecido por el nivel inferior al superior, ↑ que es una notiĄcación/indicación del nivel inferior al superior y↕que son operaciones en ambos sentidos. 3.3.1.4 Nivel de red (NL) Cualquier nivel de red (NL) que permita la comunicación entre dos entidades de la red aunque no sean vecinos sería válido para esta arquitectura. No se pone ningún requisito más por lo que esta arquitectura sería adaptable a prácticamente todos los existentes. La mayoría de los protocolos de red empleados en WSN proporcionan servicios no orientados a conexión usando datagramas y las principales diferencias se dan en el protocolo de enrutamiento utilizado. En estas redes es habitual usar protocolos de encaminamiento ad hoc, que requieren un esfuerzo colaborativo en los nodos por lo que están expuestos a manipulación por alguno de ellos. Existen protocolos propuestos de encaminamiento ad hoc seguros [ 164 ], que no proporcionan seguridad completa ante todos los ataques a costa de reducir el rendimiento de la red e incrementar el procesamiento en los nodos. Aunque se podrían seguir utilizando estos protocolos, esta arquitectura permite utilizar otros protocolos más simples y menos costosos para los nodos manteniendo un nivel de seguridad alto, como: • Protocolos basados en tablas de encaminamiento almacenadas. Estas pueden ser proporcionadas por conĄguración por el robot o la BS que tienen una visión global de toda la red e incluir rutas alternativas para incrementar la robustez ante fallos de nodos. • Protocolos basados en el paradigma SDN como [ 47 ]. Los nodos solo deben conocer a priori como comunicarse con el controlador porque pueden preguntar a este qué deben hacer ante paquetes que no saben tratar. En nuestra arquitectura, las funciones de controlador de SDN podrían hacerla la BS o el robot. Es común asignar una dirección de red diferente a cada una de las entidades de la red y usar esta para hacer el enrutamiento. Esta dirección de red puede ir cambiando durante la vida de un nodo a diferencia de la dirección MAC. Cada nodo deberá guardar una tabla de correspondencia entre la dirección de red y la dirección MAC del resto de entidades conocidas (vecinos principalmente). 60 Capítulo 3. Arquitectura de seguridad La comunicación entre vecinos (con un único salto) debería poder utilizar direcciones de red locales al enlace que podrían repetirse en el resto de la red. Esto permitiría a nodos que aún no tengan asignada una dirección de red o cuya dirección de red sea incorrecta/duplicada comunicarse con vecinos. Estas direcciones no serían nunca reenviadas. De hecho, es preferible que los vecinos utilicen direcciones locales al enlace entre ellos, ya que esto puede ser una garantía de autenticidad (un nodo remoto no podría suplantar la dirección local del vecino). El protocolo de enrutamiento usado va a imponer la necesidad de incluir determinados campos en las cabeceras de los paquetes que pueden no ser necesarios en otros protocolos. Pero hay una serie de campos que se repiten en todos: • Límite de saltos, también conocido como tiempo de vida (TTL, Time To Live) en algunos protocolos. Campo que indica el límite de saltos que puede dar un paquete antes de ser descartado. Se va decrementando al pasar por cada nodo intermedio y no puede ser 0. •Un campo con opciones, dependiente del protocolo. •Dirección de red de origen. •Dirección de red de destino. Con estos campos, y suponiendo direcciones de red de 16 bits, un paquete de red básico presentaría el formato mostrado en la Figura 3.8. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Límite de saltos Opciones Dirección de origen Dirección de destino SDU (datos, variable) ··· Figura 3.8 Formato de un paquete de red básico. Difusión y multidifusión La principal imposición a este nivel es sobre la difusión de paquetes (broadcast). En las redes más comunes es habitual implementar la difusión en este nivel apoyándose en los mecanismos de difusión existentes en el LL. Pero, como se indicó en la Sección 3.3.1.3, la difusión en el LL solo se emplea para que el robot anuncie su proximidad. Por otro lado está el problema de la seguridad en los paquetes de difusión. En redes basadas en IEEE 802.15.4, por ejemplo ZigBee, se utiliza una clave de red (compartida por todas las entidades) para cifrar los paquetes de difusión. Sin embargo, en esta arquitectura no existirán claves compartidas porque el acceso no autorizado a cualquiera de las entidades afectaría a toda la red. Esta arquitectura puede funcionar sin necesidad de emplear difusión en el NL, pero como se explicará más adelante se va a permitir exclusivamente a la BS enviar mensajes de 3.3 Arquitectura 61 difusión al resto de entidades y en situaciones muy concretas e infrecuentes. Esta difusión será controlada por los niveles superiores y el plano de gestión y seguridad. Al NL solo se pedirá: • que marque los paquetes de difusión, usando un bit del campo opciones o utilizando una dirección de destino especial, • que notiĄque la llegada de estos paquetes de manera diferenciada respecto al resto de paquetes, • y que permita la transmisión de un mismo mensaje a todos los vecinos con la excepción de un conjunto de ellos. La difusión seguirá un algoritmo de inundación, donde cada entidad retransmitirá un mensaje, una vez veriĄcado, a todos sus vecinos excepto aquellos que se lo hayan enviado a ella (uno como mínimo si la retransmisión es inmediata o puede que varios si se espera un intervalo de tiempo para poder recibir de otras fuentes antes de retransmitir). El propio mensaje debe incorporar información para que pueda ser veriĄcado y autenticado. La veriĄcación incluye al menos que el mensaje no sea duplicado ni antiguo para evitar ataques de reproducción/reinyección (replay/playback) que consumirían muchos recursos. La autenticación es opcional, pero recomendable y se basará en la Ąrma digital del mensaje utilizando criptografía asimétrica. La veriĄcación de una Ąrma digital es un proceso computacionalmente costoso que es asumible para mensajes esporádicos, pero si se quieren transmitir varios mensajes de difusión consecutivos o el mensaje se quiere fragmentar en varios paquetes, se pueden utilizar técnicas más eĄcientes, como la descrita en [ 166 ], donde una misma Ąrma digital se amortiza entre varios mensajes consecutivos. En una red densamente poblada, una entidad recibirá el mismo mensaje desde diferentes vecinos lo que proporcionará Ąabilidad ante posibles pérdidas de paquetes. En otros casos se puede utilizar asentimientos o repetir la transmisión un número determinado de veces a intervalos. La multidifusión (multicast) no se usa en esta arquitectura, pero si una aplicación la necesitara estaría basada en los mismos mecanismos que la difusión. Interfaces con otros niveles o planos Este nivel tendrá interfaces con otros niveles/planos para las siguientes operaciones: •Con niveles superiores: ↕ Recepción y envío de SDU, para transmisión de difusión o unidifusión (unicast). ↓Consulta de la MTU actual. •Con plano de gestión y seguridad: ↑NotiĄcación de creación/destrucción de vecinos. ↓ConĄguración de parámetros y vecinos. ↓Consulta de estadísticas, información de vecinos y enrutamiento. ↓Consulta de la MTU actual. 62 Capítulo 3. Arquitectura de seguridad •Con nivel inferior: ↕Recepción y envío de PDU. ↓Consulta de la MTU actual. ↑Recepción de notiĄcaciones sobre asociaciones ↓ Consulta de información relevante para el enrutamiento (por ejemplo, alcanzabilidad y calidad de los vecinos). En el listado anterior, los símbolos tienen el mismo signiĄcado que en la Sección 3.3.1.3. 3.3.1.5 Nivel de transporte (TL) El nivel de transporte debe proporcionar la comunicación entre dos entidades de la red en modo con conexión y preferentemente orientado a Ćujo de mensajes. La conexión se iniciará utilizando el mismo proceso de saludo que se utiliza en el LL aunque pudiendo cambiar los valores de los temporizadores y retransmisiones. Del mismo modo que en el LL, si el modo de seguridad escogido lo indica, se cifrará la conexión. También se puede conĄgurar la veriĄcación de alcanzabilidad del otro extremo forzando la transmisión de segmentos cada cierto tiempo. Entre dos extremos solo existirá una única conexión como máximo. Suponemos que todos los usuarios del servicio de transporte comparten el mismo nivel de seguridad, confían mutuamente, no interĄeren entre sí maliciosamente y no requieren usar conexiones diferentes. Esto aumenta la eĄciencia al no tener que realizar varios procesos de saludo que suelen ser lo más costoso computacionalmente. Además, no es necesario utilizar direcciones de transporte. La conexión entre entidades se identiĄca por sus 2 direcciones de red. Este nivel multiplexará todos los mensajes del AL en el envío y hará la desmultiplexación en la recepción, si existe más de una aplicación y no se realiza esta función en el AL. Para implementar la arquitectura SNSR sería deseable que este nivel ofrezca el envío Ąable y no Ąable de mensajes a un mismo destino sobre la única conexión, para reducir el número de conexiones a utilizar. Si el tamaño de los datos es superior al que se puede transmitir en un único paquete de red, se deberá realizar la segmentación de estos datos en fragmentos antes de enviarlos. En el destino se realizará el reensamblado antes de la entrega al nivel superior. La transmisión Ąable de mensajes incluirá mecanismos para la entrega ordenada, el control de Ćujo y la recuperación ante errores. En la transmisión no Ąable de mensajes no se garantiza nada de lo anterior. No se necesita el envío simultáneo de más de un mensaje en cada dirección. Lo anterior implica que en el caso de la transmisión Ąable de varios mensajes consecutivos que deben ser segmentados, los segmentos no se enviarán intercalados. Si se utiliza una conexión segura, los segmentos son procesados por el servicio de seguridad antes de ser enviados al NL. El proceso de saludo (que se explicará en la Sección 3.3.2) y el procesamiento de la información antes de ser enviada para añadir seguridad es realizado en el servicio de seguridad. En la Figura 3.9 se representa este proceso. Nótese que se hace en orden inverso a como se hacía en el LL. Esto hace que los campos del segmento puedan ser encriptados y/o autenticados. El orden es inverso también respecto al que se utiliza en el protocolo TLS con Protocolo de Control de Transmisión (TCP, Transmission Control Protocol) [ 31 ]. Esto es posible porque solo se va a tener una 3.3 Arquitectura 63 Nivel de red Nivel de Transporte Nivel de Aplicación Plano de Gestión y Seguridad Servicio de Seguridad Crear segmentos Segurizar Figura 3.9 Detalle de aplicación de seguridad a un segmento. única conexión de transporte con unos parámetros de seguridad también únicos entre dos entidades. Aplicar seguridad a los datos antes de crear los segmentos provocaría que los campos de la cabecera de un segmento no estuvieran protegidos y esto conlleva una serie de riesgos de seguridad ante determinados ataques: • Un nodo intermedio malicioso realizando reenvío selectivo puede seleccionar descartar los segmentos que provoquen más daño. Por ejemplo, un fragmento si no se emplea transporte Ąable. • Se podría alterar los datos de un fragmento de un mensaje y el destino no podría detectar el error hasta que los datos sean reensamblados. Aunque se detecte el error no se podría saber cuál de los fragmentos es el incorrecto y habría que retransmitir todos los fragmentos de nuevo. • Un atacante podría detectar el inicio de la transmisión de un mensaje fragmentado e inyectar fragmentos erróneos pero con numeración correcta antes de que el origen lo haga (rushing attack). El destino creería que le han llegado segmentos duplicados y no sabría cuál es el correcto. Si la transmisión es Ąable, el destino enviaría asentimientos al origen de segmentos que pueden que no hayan llegado, por lo que el origen no los retransmitiría. Sin embargo, segurizar antes de crear los segmentos presenta la ventaja de una posible reducción en el número de bytes transmitidos al fragmentar un mensaje, ya que algunos campos de seguridad se transmitirían solo una vez, como por ejemplo el código de autenticación de mensaje. Esto también podría implicar un menor tiempo de cómputo, aunque en principio esto último podría ser despreciable. La función de añadir seguridad a la conexión está en el límite entre los niveles de transporte y de red. Es discutible si esta función debería realizarse en uno u otro nivel. En redes TCP/IP, un esquema de funcionamiento similar está implementado en el NL con el protocolo IPSec [ 81 ] en su modo de transporte (el nombre del modo ya indica 70 Capítulo 3. Arquitectura de seguridad ypermite garantizar que el saludo se está realizando sin intervención de ningún agente externo. 2. Cifrando los datos con la clave acordada, que a la vez permite veriĄcar que la generación de la clave ha sido correcta. Normalmente, se realiza como último mensaje del saludo. Cualquier alteración de los mensajes intercambiados dará lugar a que el resumen generado sea inválido. Dado que la Ąrma digital solo puede realizarla la entidad que posee la clave privada apropiada y que los protocolos de intercambio de claves garantizan que con la mera escucha de la conversación no se puede extraer las claves intercambiadas, se imposibilita el éxito del ataque de intermediario. No es necesario comprobar explícitamente la conectividad, ya que va implícita en cualquier intercambio de mensajes que se realice para el resto de funcionalidades. El orden en el que se transmitirán los mensajes del saludo para conseguir toda la funcionalidad descrita en este apartado será decisión de la implementación, pudiendo realizarse uno a uno o en paralelo para reducir el número de viajes de mensajes que se deben realizar. Un mensaje puede transportar varios tipos de información siempre que el tamaño total esté permitido por el nivel de la torre de protocolos usado. Para SNSR, no es necesario desarrollar un nuevo protocolo de seguridad. Se puede utilizar un protocolo de seguridad ya existente y adaptarlo. Un protocolo maduro que ha sido revisado, objeto del escrutinio de la comunidad cientíĄca, garantiza robustez y Ąabilidad. Más aún si se trata de un protocolo de seguridad que ha sido atacado y puesto a prueba en múltiples ocasiones. La adaptación no está exenta de peligros si no se comprenden todos los elementos existentes que contribuyen a hacer el sistema seguro o se añaden otros elementos que cancelan los anteriores o incrementan la predictibilidad del sistema. El formato de los mensajes del saludo estará deĄnido por la implementación elegida, aunque se exige que el primer byte, TIPO , sea diferente de cero y el valor o conjunto de valores utilizados sea fácilmente distinguible del resto de mensajes que no formen parte del saludo como se muestra en (3.3) A→B:TIPO ∥... (3.3) 3.3.2.4 Saludo avanzado de reanudación El coste computacional del saludo avanzado puede ser muy alto. Las relaciones establecidas entre las distintas entidades en esta arquitectura suelen ser permanentes por lo que este coste se amortiza con el paso del tiempo. Las entidades también deben detectar cuando se pierde la conectividad, como se discutirá en la Sección 3.3.4. La conectividad se puede perder permanentemente si la otra entidad falla fatalmente o temporalmente por interferencias o porque se mueva a otra posición como en el caso del robot. Las pérdidas de conectividad temporales pueden ser breves y/o frecuentes. En estos casos, utilizar el saludo avanzado cada vez que se restablezca la comunicación es muy costoso. El saludo avanzado de reanudación es una versión simpliĄcada del saludo avanzado donde se reutilizan los datos de una conexión anterior sin necesidad de realizar todos los procesos del saludo completo. 3.3 Arquitectura 71 Para poder utilizar el saludo avanzado de reanudación, el servidor debe haber generado un testigo (en inglés recibe el nombre de token oticket) durante la conexión anterior. Este testigo será transmitido al cliente que lo almacenará. Para el cliente el testigo es un dato opaco, pero el servidor podrá codiĄcar en él: 1. Un número de referencia interno del servidor que le permita identiĄcar los datos de una conexión. Este mecanismo está sugerido en [31]. 2. Los datos de la conexión serializados y encriptados con una clave que el servidor solo conoce. En este caso el servidor no necesitaría almacenar nada una vez terminada una conexión a costa de transmitir más información y forzar al cliente a almacenarlo él. Este mecanismo está sugerido en [38]. En esta arquitectura se utilizará la primera opción por requerir menos operaciones a realizar en el servidor y ser más equitativo en el almacenamiento. El cliente adjuntará el testigo en el mensaje Hola. El servidor validará la validez de este y retomará la comunicación en el punto en el que se dejó utilizando las mismas claves que se habían generado anteriormente. Dado que las claves deben renovarse cada cierto tiempo por seguridad, el testigo tendrá un tiempo de vida limitado. Si este vence, se obligará a realizar un saludo avanzado completo para garantizar el PFS. 3.3.3 Interacciones entre entidades Las interacciones que pueden darse entre diferentes tipos de entidades están representadas en la Figura 3.12. Se muestran en rojo aquellas en las que interviene el robot, en verde donde interviene la BS y en negro/gris las interacciones de nodos sensores. También se muestra la torre de protocolos utilizada para la comunicación. Se representa de diferente color la parte fundamentalmente distinta de cada tipo de entidad: la aplicación de gestión y el servicio de gestión. Tanto el robot como la BS pueden implementar una torre de protocolos dual, pudiendo utilizar la propia de la WSN y otra más rápida, de mayor capacidad y con mayor alcance para la comunicación entre BS y robot como redes TCP/IP sobre redes inalámbricas de la familia IEEE 802.11. Este último modo de comunicación es opcional en esta arquitectura, pero deseable sobre todo por el volumen de información que tienen que intercambiar robot y BS. Existen 4 interacciones diferentes. La Ąnalidad de cada una aparece descrita en la Tabla 3.3. Antes de que las distintas entidades puedan interactuar, se deberá establecer una conexión entre ellas, que implicará la realización de un proceso de saludo. El proceso de saludo podrá autenticar a ambos extremos de tal manera que cada entidad podrá conocer la identidad y tipo de su interlocutor. Si no se utiliza seguridad en las comunicaciones, un nodo también tendrá conocimiento del tipo del otro extremo porque para comunicarse con el robot deberá haber recibido previamente una baliza de este y la información sobre la BS a utilizar la habrá recibido por conĄguración. La BS identiĄcaría al robot por su baliza y al resto de nodos por conĄguración. El robot sabría quién es la BS por conĄguración y los nodos por descubrimiento o conĄguración. 72 Capítulo 3. Arquitectura de seguridad Figura 3.12 Relaciones entre distintas entidades de la arquitectura SNSR. La duración de una interacción no está deĄnida y las conexiones establecidas se mantendrán abiertas el mayor tiempo posible. Se podrá forzar a que los extremos intercambien datos periódicamente para probar el buen funcionamiento de la comunicación y de los mismos extremos. En las interacciones se deĄnen una serie de mensajes que utilizarán las aplicaciones de gestión. Estos mensajes se describirán en los apartados siguientes. En la Tabla 3.4 se muestra un listado con los tipos de mensajes deĄnidos, los tipos de entidad origen y destino del mensaje, una descripción breve y el apartado donde se describirán detalladamente. Los mensajes transmitidos se pueden agrupar en pares petición/respuesta (o notiĄcación/asentimiento en el caso de anomalías). Para identiĄcar correctamente la respuesta a una petición, en las peticiones y respuestas se transmitirá un identiĄcador de transacción TX_ID que deberá ser el mismo. El valor del TX_ID será un número entero sin signo y nunca podrá ser cero. El valor inicial del TX_ID podrá ser un valor aleatorio mayor que 0 e irá incrementándose con cada nueva petición (en una unidad o más de manera cíclica) y será diferente en cada sentido de la comunicación. Un mensaje con un identiĄcador menor o igual al último recibido se considerará duplicado y será descartado (si es el primer identiĄcador recibido, siempre se acepta). 3.3 Arquitectura 73 Tabla 3.3 Interacciones entre entidades de la arquitectura SNSR. Interacción Finalidad Robot ⇐⇒ BS • Intercambio de información de la topología de la red. La BS enviará al robot la información conocida inicialmente de la red y el robot enviará a la BS información recopilada tras la detección de nodos. Ambos pueden transmitir al otro la topología calculada. • El robot informará a la BS de anomalías detectadas por él o por nodos sensores. • La BS podrá informar al robot sobre cambios en la CRL y comandos administrativos. • El robot podrá preguntar sobre el estado de la BS y detectarlo como un elemento estático más de la red. BS ⇐⇒ Nodo • Como funcionamiento básico de una red de sensores, el nodo enviará a la BS las medidas recogidas. • La BS podrá enviar peticiones de estado, de cambio de conĄ- guración del nodo y actualizaciones de la CRL. •Los nodos comunicarán a la BS las anomalías que detecten. Nodo ⇐⇒ Nodo • En la arquitectura SNSR, los nodos solo se comunican entre sí para reenviar paquetes de manera colaborativa hacia su destino. Nodo ⇐⇒ Robot • El robot puede consultar el estado de los nodos y autenticarlos durante el proceso de descubrimiento y posteriormente pedirles que cambien su conĄguración o actualicen su CRL. • Los nodos comunicarán al robot las anomalías detectadas si tienen conexión directa con él. 3.3.4 Mantenimiento de la conexión Si se quiere detectar la conectividad con el otro extremo de una conexión en el LL o TL en periodos de tiempo donde no haya que intercambiar datos se recurrirá al procedimiento habitual de envío de tramas o segmentos periódicos de pulso o keepalive. Esto permite que la conexión esté preparada cuando sea necesaria e identiĄcar anomalías en la red. Es posible que este procedimiento u otro similar ya lo proporcione el LL o TL utilizados, ya que es muy habitual. El mantenimiento de la conexión será opcional en la mayoría de los casos y dependerá de las políticas y funcionamiento esperado de la red de sensores. En las conexiones de 74 Capítulo 3. Arquitectura de seguridad Tabla 3.4 Tipos de mensaje de la aplicación de gestión. Tipo de mensaje Sentido Descripción Más detalles TM_STATUS_REQ robot→BS robot→nodo BS→nodo Petición de estado Sección 3.6.2 TM_STATUS_RES BS→robot nodo→robot nodo→BS Estado de la entidad Sección 3.6.2 TM_CONFIGURE_REQ BS→robot BS→nodo robot→nodo Petición de cambio de conĄguración o CRL Sección 3.8 TM_CONFIGURE_RES robot→BS nodo→BS nodo→robot Respuesta al cambio de conĄ- guración Sección 3.8 TM_ANOMALY_STATUS robot→BS nodo→robot nodo→BS NotiĄcación de anomalías detectadas Sección 3.9.1 TM_ANOMALY_ACK BS→robot robot→nodo BS→nodo ConĄrmación de recepción de las anomalías Sección 3.9.1 TM_GET_ND_REQ robot→BS Obtención de información topológica Sección 3.5.2 TM_GET_ND_RES BS→robot Información topológica Sección 3.5.2 TM_SET_ND_REQ robot→BS Petición de modiĄcación de información topológica Sección 3.5.1 TM_SET_ND_RES BS→robot ConĄrmación de la modiĄcación de la información topológica Sección 3.5.1 TM_SET_CRL_BCAST BS→todos (por inundación) Actualización urgente de la CRL Sección 3.9.2 TM_MGMT_CMD_REQ BS→robot Ejecución de comandos administrativos Sección 3.5.3 TM_MGMT_CMD_RES robot→BS Resultado de la ejecución de comandos administrativos Sección 3.5.3 TL con entidades vecinas, será innecesario si ya se utiliza en el LL. En las conexiones de LL con el robot, se impone su obligatoriedad por las razones que se discutirán en la Sección 3.6. En el caso de tener que implementar este procedimiento, se realizaría del siguiente modo: 3.3 Arquitectura 75 • Cada extremo de la conexión almacenaría el instante de tiempo de transmisión de la última PDU, TTlast. • Si transcurre un intervalo de tiempo establecido KAI desde TTlast sin enviar nada, se enviaría una PDU de keepalive. Esta contendrá un único octeto con todos los bits a 0, como se muestra en (3.4) . KAI es un valor individual de cada conexión, aunque la entidad tendrá un valor por defecto KAI g. A→B: 0 (3.4) • Cada extremo también anotará el instante de tiempo de recepción de la última PDU, TRlast . Se deĄne un tiempo máximo que puede pasar sin recibir ninguna PDU, KATO . Este valor será un múltiplo entero de KAI como se muestra en (3.5) . El factor multiplicador será un valor predeterminado común en todas las entidades. KATO =KAIF ·KAI (3.5) • Si no se recibe ninguna PDU en un intervalo igual o mayor a KATO desde TRlast , se considerará que no hay conexión con el otro extremo. Esto se registra como una anomalía, se cierra la conexión y se informa a los niveles superiores y el plano de gestión para que estos actúen en consecuencia. El robot anunciará el valor de KAI que debe aplicar cada entidad que quiera conectarse a él en la trama de baliza. El resto de conexiones tendrán Ąjado el valor de KAI a utilizar por conĄguración o utilizarán el KAI gsi no se indica ninguno explícitamente. 3.3.5 Fases de funcionamiento de la red Con esta arquitectura la WSN pasará a lo largo del tiempo por 5 fases o etapas. Estas fases aparecen representadas en la Figura 3.13 con las transiciones entre ellas. Durante la fase inicial, se decidirán los parámetros de conĄguración estática y de seguridad que irán preconĄgurados en todas las entidades, se generarán e instalarán los certiĄcados de cada entidad y de la CA y se desplegarán los nodos sensores en las instalaciones a monitorizar. Si se conoce la lista de nodos sensores autorizados, el robot la cargará localmente o pidiéndola a la BS. Al robot también hay que darle las coordenadas de la zona donde se localizan los nodos sensores, el alcance radio máximo de estos y cualquier otra información que esté disponible y ayude en la localización de los nodos sensores posteriormente (fuentes de interferencia o aislamiento electromagnético, posiciones aproximadas, etc.). Al terminar todas estas tareas iniciales, la red pasará a la fase de descubrimiento. La creación de la red de sensores y su puesta en funcionamiento se producirá en las fases de color naranja: descubrimiento,establecimiento de la topología yconĄguración. Estas fases se pueden repetir iterativamente hasta que la red de sensores sea completamente funcional y para corregir problemas y ataques que se hayan identiĄcado en la fase de mantenimiento. En la fase de descubrimiento de nodos sensores, el robot calculará una trayectoria de tal manera que pueda establecer contacto con todos los nodos sensores desplegados en la 76 Capítulo 3. Arquitectura de seguridad Establecimiento de la topología ConĄguración Mantenimiento Descubrimiento Inicial Figura 3.13 Fases de funcionamiento de la red en la arquitectura SNSR. instalación. Esta trayectoria será más o menos eĄciente dependiendo del conocimiento previo que se tenga. Si esta fase se realiza más de una vez, la segunda vez y siguientes la trayectoria se puede optimizar dado que anteriormente ya se localizaron los nodos. El robot comenzará a moverse por la instalación detectando y autenticando todos los nodos. La velocidad debe ajustarse para que los nodos tengan tiempo de conectarse al robot y este pueda recopilar sus estados. En zonas con muchas interferencias, el robot deberá desplazarse más despacio. La principal diferencia con respecto a los esquemas de WSN tradicionales es que, en esta arquitectura, los nodos de sensores no descubren otros nodos. La primera transmisión de cada nodo sensor será para comunicarse con el robot. Esta fase terminará automáticamente cuando se detecten todos los nodos autorizados o se termine de escanear la zona establecida. Con los datos recopilados se pasará a la fase de establecimiento de la topología. El robot o la BS calculará la topología de la red en la fase de establecimiento de la topología y generará la información, como se verá en la Sección 3.4, que servirá para conĄgurar todos los nodos sensores. Dependiendo del tamaño de la red y el número de factores a optimizar este proceso puede ser más o menos costoso computacionalmente. La 3.4 Información de topología de la red 77 información recopilada en la fase anterior también permitirá calcular trayectorias mejores para visitar a todos los nodos. Una vez hechos los cálculos, la información de la topología se sincronizará entre la BS y el robot, y cuando estos estén de acuerdo se pasará a la siguiente fase. En la fase de configuración, el robot enviará la conĄguración a cada nodo. Para ello, volverá a moverse por la instalación de tal manera que tenga comunicación directa con cada nodo y así transmitir la conĄguración sin intermediarios. Los nodos, cuando apliquen la conĄguración, empezarán su modo de funcionamiento normal, donde se intentarán conectar con la BS para enviar sus medidas e informar de cualquier anomalía detectada en la red. Hasta este momento el funcionamiento del nodo había sido el de conectarse al robot y enviar su estado por lo que su consumo será muy reducido. Esta fase terminará cuando todos los nodos previamente descubiertos sean conĄgurados. Es probable que la primera topología calculada no sea totalmente correcta, sobre todo en casos en los que se asignen vecinos a nodos que realmente no sean alcanzables por distintos motivos: el alcance radio máximo puede ser optimista, interferencias no contempladas, etc. Es posible que, aunque con defectos, todos los nodos puedan comunicarse con la BS y en este caso, gracias a los informes de anomalías enviados por los nodos, se podría calcular una nueva topología corregida. Pero otras veces pueden quedarse nodos aislados que serán reconĄgurados a través del robot. Además, la comunicación con el robot es directa y no se ve afectada por problemas que puedan producirse durante el transitorio conforme se van conĄgurando los distintos nodos. Así, para tener mayores garantías, se puede volver a hacer una iteración por las tres fases de color naranja. La fase de descubrimiento serviría para validar la conĄguración enviada, comprobando el estado en el que se encuentra cada nodo (que incluye los vecinos que son alcanzables). La fase de establecimiento de la topología corregiría los errores detectados y por último se volvería a enviar la conĄguración modiĄcada. Una vez que la conĄguración se considere correcta, se pasaría a la fase de mantenimiento. La fase de mantenimiento sería la más estable y es donde la red permanecería más tiempo según los supuestos de esta Tesis Doctoral. Se analizarán las anomalías detectadas y el estado de los nodos. Si se produjera algún cambio en la topología de la red habría que volver a reconĄgurar la red. En el caso de eliminación de un nodo o actualización de la CRL se pasaría a la fase de establecimiento de la topología. Si un nodo es añadido a la red o cambia su posición, se iniciaría de nuevo la fase de descubrimiento. El funcionamiento de los nodos sensores en esta arquitectura es muy sencillo. Para un nodo solo habría dos modos de funcionamiento: con o sin conĄguración recibida. En las siguientes secciones se detallará el funcionamiento de cada entidad en las diferentes fases en las que se va a poder encontrar la red de sensores, los mensajes transmitidos y las secuencias de mensajes intercambiados. 3.4 Información de topología de la red El robot conforme explora la WSN debe ir recopilando información sobre ella. Esta información se basará en la identiĄcación de los nodos y en el estado en el que se encuentren 78 Capítulo 3. Arquitectura de seguridad estos. Aquellos nodos que no estén autorizados a formar parte de la red serán ignorados. Si se usa la autenticación con certiĄcados digitales se veriĄcarán que estos no estén en la CRL. El robot intercambiará la información obtenida de la red con la BS. Ambos mantendrán un mapa virtual de la WSN a partir de esa información. La información topológica de la red contiene todos los parámetros de conĄguración (vecinos, tablas de encaminamiento,...) que deben tener los nodos y la BS para un correcto funcionamiento. Esto se almacena en una base de datos de topología de red y simultáneamente pueden existir distintas instancias o versiones que contengan: a) restricciones iniciales, b) datos obtenidos durante la fase de descubrimiento; o c) conĄguración calculada en distintas ejecuciones de la fase de establecimiento de la topología. En a) y b) la información estará incompleta. La Figura 3.14 es un diagrama de Entidad-Relación en Lenguaje UniĄcado de Modelado (UML, UniĄed Modeling Language) [ 109 ] donde se muestran las relaciones entre los distintos tipos de información almacenada sobre la topología de la red. No se especiĄca el formato ni dónde se almacenará físicamente esta información. Aunque en el diagrama todas las relaciones son de agregación, donde un elemento contiene a los otros, también sería posible utilizar relaciones de asociación, como las relaciones entre distintas tablas de una base de datos relacional. A continuación, se describen cada una de ellas. NetworkData Es el elemento raíz que contiene al resto de elementos: una CRL, una lista de nodos y la versión de la lista. Aquí el término ńnodoż se reĄere a nodo de la red que incluye a la BS. La topología puede ir cambiando con el tiempo por distintos motivos: incorporación de nuevos nodos, eliminación de nodos, cambio de rutas o de vecinos, etc. El número de versión de la topología actual será un parámetro que se conĄgurará en todas las entidades de la red. La comparación del número de versión permite determinar si una entidad está actualizada o no, y, si no lo está, saber qué cambios necesita realizar para actualizarse. De una versión a otra debe producirse un cambio en la lista de nodos. No hay límite máximo al número total de versiones que almacenará el robot y la BS, pero si se establece un mínimo de 2 versiones: 1. Versión 0 (inicial), que debe entenderse como la lista de nodos permitidos en la red con los datos necesarios para su veriĄcación (identiĄcación de las entidades y CRL inicial), pero que normalmente no contendrá información sobre vecinos, rutas ni posiciones. Si la lista de nodos está vacía, cualquier nodo que descubra el robot con un certiĄcado válido estará autorizado a pertenecer a la red. 2. Última versión (actual) calculada. Al principio coincidirá con la versión inicial, pero posteriormente irá actualizándose. Las nuevas versiones se calculan cada vez que se entra en la fase de establecimiento de la topología. Durante el cálculo de una nueva versión, será necesario almacenar una versión temporal extra. CRLData ySerialData Es la CRL utilizada en la red propuesta. Contiene los números de serie ( SerialData ) de los certiĄcados revocados. Los números de serie son valores enteros positivos únicos asignados a los certiĄcados por la CA con un tamaño 3.4 Información de topología de la red 79 Notación de agregación NetworkData version crl CRLData version serials 1..* 1 nodes NodeData llAddress nlAddress 1..*0..* SerialData serial 1..*1..* name baseStation routes neighbors position BSData name address 1..* 0..1 RouteData ... NeighborData llAddress nlAddress name commParams 1 0..* 1 0..* Contenedor Contenido multiplicidad multiplicidad Figura 3.14 Información de la topología de la red. variable no superior a los 20 octetos [ 14 ]. Una CRL se identiĄca por su número de versión, que es independiente del número de versión del elemento NetworkData : una misma CRL puede ser utilizada por distintas versiones de la topología y la CRL puede ser actualizada sin necesidad de cambiar la versión de la topología. Las CRL son incrementales: si la versión de una CRL X es mayor que la de otra Y , contendrá todos los números de serie de la versión Yademás de otros más. NodeData Contiene información de un nodo sensor o de la BS con la conĄguración que debe tener en la topología actual. La información consiste en: •la dirección física, que no debería cambiar durante la vida de la entidad, 86 Capítulo 3. Arquitectura de seguridad Tabla 3.7 Campos de una baliza del robot en la arquitectura SNSR. Campo Descripción 0 Es un octeto con todos los bits a 0. Esto permite identiĄcar rápidamente una baliza del resto de tramas que no pueden empezar así. CN Nombre común del CertCA R. SN Es el número de serie del CertCA R . CN y SN se utilizan para veriĄcar que la baliza procede de un robot válido: el tipo debe ser el de un robot, el dominio de la red debe ser correcto y el número de serie no debe estar en la CRL. Si se usa autenticación en la conexión, la entidad comprobará que el CN del certiĄcado digital del robot es igual al transmitido en la baliza. NA (network address) Es la dirección de red del robot. CP (communication parameters) Es un campo con parámetros de comunicación a utilizar durante la conexión. Dependerá de la implementación realizada y de los parámetros que ya estén preconĄgurados en los nodos, y que por tanto no sean necesarios volver a indicar. Por ejemplo, puede incluir el valor en segundos del intervalo máximo que debe transcurrir entre mensajes transmitidos para mantener abierta la conexión, KAI . las entidades que se encuentren en el alcance radio r. Una vez que las entidades empiecen a intentar la conexión con el robot, la probabilidad de que se produzcan colisiones con la baliza aumentará. Conforme el robot se mueve por el escenario los nodos con los que podrá comunicarse irán variando. Muchas de las conexiones que el robot había establecido se cerrarán por los mecanismos de detección de fallos de comunicación al vencer los temporizadores asociados. Las entidades que pierdan la conexión con el robot volverán a ponerse a la escucha de balizas. El funcionamiento de un nodo va a ser muy sensible a la recepción de la primera baliza recibida, que le permitirá conectarse con el robot y recibir la conĄguración inicial de él. Un nodo que no reciba nunca una baliza no podrá formar parte de la red. No se comunicará con ninguna otra entidad. Si un robot malicioso se pusiera en contacto primero con el nodo, podría evitar que el nodo se conectara a robots legítimos. Para evitar los problemas descritos se disponen las siguientes medidas: 1. Las balizas deberán ser validadas antes de dar lugar a un intento de conexión con el robot emisor. 2. El robot, según el modo de seguridad elegido, será autenticado al establecer la conexión y se veriĄcará que la baliza no contenía datos falsos. 3. Un nodo deberá recibir y validar correctamente una baliza legítima en un tiempo Ąnito si el robot se encuentra dentro de su alcance radio, a pesar de que haya otros 3.6 Descubrimiento de nodos sensores 87 agentes maliciosos transmitiendo balizas falsas (siempre que las balizas falsas no saturen el canal). La BS es más inmune ante ataques con balizas falsas. La BS puede conocer cuál es el robot operativo en cada momento, por lo que puede distinguir cuál es la baliza legítima. Si en el ataque se envían duplicados de la baliza legítima sin estar próximo el robot, el efecto también sería mínimo (hacer que la BS transmita una trama Hola). Se han desarrollado dos métodos de detección de balizas: uno básico y otro avanzado. Este último ofrece mayor protección ante ataques en los que un atacante se haga pasar por un robot. A continuación se describe cada método y posteriormente se mostrará una tabla comparativa. Se podrá elegir el método más apropiado para cada red por conĄguración. En Figura 3.17 se muestra el diagrama de estados utilizado en la detección de balizas y conexión con el robot que tendría lugar en los nodos o BS para un funcionamiento básico. Inicialmente, la entidad entra en el estado de espera de nueva baliza. Cada vez que se recibe una baliza, esta es veriĄcada: pertenece a un robot de un dominio permitido, el número de serie del certiĄcado no está revocado y los parámetros de comunicación son adecuados. Mientras que no se reciba una baliza correcta, la entidad continuará esperando. Si la baliza es correcta, se esperará un tiempo de contención (back-off ) aleatorio, entre 0 y un tiempo máximo conĄgurado (TCmax), antes de comenzar el proceso de saludo. Esta espera de contención, que es opcional si TCmax ≡0, tiene dos objetivos: 1. Evitar colisiones. Es posible que muchos nodos reciban simultáneamente una misma baliza, por lo que intentarán iniciar el saludo a la vez. Los mecanismos de prevención de colisiones del nivel de enlace pueden no ser suĄcientes en casos extremos, por lo que esta espera aleatoria puede mitigar los efectos. 2. Evitar que en el robot se reciban un número excesivo de respuestas a la baliza que puedan saturar sus recursos (fenómeno conocido como implosión). Transcurrido el temporizador de espera de contención, se iniciaría el saludo. Si no tiene éxito, se volvería a esperar una nueva baliza. En caso contrario, la conexión a nivel de enlace con el robot se establecería. Cuando la conexión se pierda, se volverá al estado Espera_Baliza. LQFRUUHFWD      r   . Figura 3.17 Diagrama de estados de detección de baliza básica. Hay que notar que cualquier baliza recibida fuera del estado Espera_Baliza será descartada automáticamente. Esto reduce el consumo en los nodos porque no hay que veriĄcar las balizas, pero este funcionamiento básico presenta una serie de diĄcultades, sobre todo en el caso donde un atacante también transmita balizas: 88 Capítulo 3. Arquitectura de seguridad 1. Espera entre reintentos: es necesario recibir una nueva baliza cuando falla el saludo, aunque posiblemente se hayan recibido nuevas balizas recientemente. Esta espera estará determinada por el intervalo entre transmisión de balizas BI max. 2. Ocultación de balizas legítimas: si un atacante consigue que un nodo detecte su baliza en primer lugar, podría conseguir con una alta probabilidad que la siguiente fuera también otra suya y repetir este proceso sucesivamente sin necesidad de transmitir balizas a una tasa superior a la del robot legítimo. Aunque un robot transmita balizas con cierta aleatoriedad, debido a que el nodo ha iniciado el proceso de saludo con el atacante, el atacante conocerá el instante en el que el saludo se dé por terminado, por lo que podrá transmitir una baliza justo después, siendo esta baliza la que se detecte a continuación con mucha probabilidad. El atacante también podría controlar la duración del saludo forzando a realizar reintentos, de tal manera que el saludo termine justo después de que el robot haya transmitido una baliza que habrá sido descartada. 3. Ataque de alto consumo energético o computacional (power attacks) si se utiliza seguridad en el LL: un atacante provoca que un nodo realice el proceso de saludo constantemente. En el proceso de saludo se realiza la autenticación mutua, que implica la validación de certiĄcados digitales utilizando costosas operaciones criptográĄcas. Siguiendo el proceso de ataque descrito en el problema anterior, un atacante con certiĄcados incorrectos podría hacer que un nodo, después de detectar su baliza, entrara en el ciclo Espera_Contención →Saludo →Espera_Baliza → Espera_Contención ..., reduciendo al mínimo el tiempo que el nodo se encuentra en el estado Espera_Baliza y reduciendo el tiempo transcurrido entre saludos. Aunque en la Sección 3.1.5 se considera que los ataques de DoS son temporales, el comportamiento del sistema sería más robusto si se modiĄca el diagrama de estados de la Figura 3.17 por el que aparece en la Figura 3.18. La idea principal es no descartar balizas durante los estados Espera_Contención y Saludo ya que aún no se sabe si la conexión tendrá éxito. Estas balizas no descartadas sirven para mantener un posible candidato en caso de que el saludo falle y así no tener que esperar a la llegada de una nueva baliza. El candidato se elige aleatoriamente entre las balizas recibidas diferentes a la baliza que se está probando en ese instante, utilizando un algoritmo del tipo reservoir sampling como los descritos en [ 156 ]. Los algoritmos reservoir sampling permiten elegir aleatoriamente una muestra de n elementos de un conjunto con un número de elementos desconocidos. En este caso nos permiten elegir una baliza aleatoria entre todas las balizas recibidas hasta un instante determinado (todas con la misma probabilidad de ser elegidas). Esto resuelve los dos primeros problemas del diagrama de estados inicial: no hay espera entre reintentos si hay un candidato disponible y un atacante no puede ocultar balizas legítimas que ahora son utilizadas como posible siguiente reintento. Por último, el proceso de saludo se deberá modiĄcar para que tenga un tiempo mínimo de ejecución Űy así evitar ataques de alto consumoŰ y un tiempo máximo de ejecución menor del habitual para reducir el tiempo que puede perder un nodo intentando conectarse con un robot falso. La reducción del tiempo máximo se puede conseguir reduciendo el 3.6 Descubrimiento de nodos sensores 89  r       r  6DOXGR rr rr   (VSHUDB&RQWHQFLyQ r rr . Figura 3.18 Diagrama de estado de detección de baliza avanzada. número de reintentos permitidos (o incluso no haciendo reintentos) o reduciendo los temporizadores de espera de respuesta. Se podría pensar que recordar las balizas que han dado lugar a un proceso de saludo fallido, para descartarlas al ser recibidas posteriormente, podría ser una solución ante posibles ataques con balizas falsas (lista negra de balizas). Sin embargo, esto presenta más inconvenientes que ventajas y es una defensa fácilmente eludible: • Un atacante podría suplantar al robot legítimo antes de que estuviera presente. Más adelante, los nodos descartarían las balizas legítimas, con lo que se impediría la conexión. • Un atacante podría emitir balizas con datos distintos, de tal manera que la memoria reservada para la lista negra de balizas se llenara. A partir de ese momento, el nodo debería o borrar las entradas más antiguas Űque ahora se pueden reutilizar Ű o no añadir las siguientes balizas erróneas a la lista negra Űcon lo que se desactivaría esta defensa. Para terminar, se muestra un cuadro comparativo de ventajas e inconvenientes de cada método en la Tabla 3.8. Por conĄguración se podrá seleccionar el método elegido utilizando un parámetro llamado BEACON_DETECTION. 3.6.2 Petición de estado La petición de estado permite conocer las versiones de conĄguración y de CRL de un nodo o la BS, su dirección de red y los vecinos con los que actualmente tiene comunicación. Solo el robot o la BS están autorizados a hacer la petición. La secuencia de mensajes transmitidos aparece representada en la parte inferior de la Figura 3.16. El robot envía 90 Capítulo 3. Arquitectura de seguridad Tabla 3.8 Comparativa entre métodos de detección de baliza. Detección de baliza Ventajas Desventajas Básica •Simplicidad. •Menor memoria necesaria. • Mayor tiempo de espera para reintentar con otra baliza distinta. • Posibilidad de ataques de ocultación de balizas legítimas y ataques de alto consumo energético o computacional. Avanzada • Resistente a ataques como los descritos: garantía de conexión, menor tiempo necesario para la conexión y menor consumo energético. • Más complejo. Uso de más memoria. • Mayor número de reintentos de conexión si se pierden tramas si se limita el tiempo máximo del proceso de saludo. una petición de tipo TM_STATUS_REQ que es respondido con un mensaje del tipo TM_- STATUS_RES . El contenido del mensaje de petición de estado se muestra en (3.14) y el de la respuesta en (3.15). R→BS R→nodo BS →nodo      :TM_STATUS_REQ ∥TX_ID (3.14) BS →R nodo →R nodo →BS      :TM_STATUS_RES ∥TX_ID ∥CFGV ∥CRLV ∥NA ∥NBL (3.15) Estos mensajes serán transmitidos usando el servicio de envío Ąable del TL. Los dos primeros campos de cada mensaje son el tipo de mensaje de aplicación y el identiĄcador de transacción, como se explicó en la Sección 3.3.3. El resto de campos aparecen descritos en la Tabla 3.9. El mensaje de respuesta se podría extender con más información relevante para una instalación concreta. Por ejemplo, el nivel de batería, estadísticas de uso y de la calidad de las comunicaciones, etc. La petición de estado se enviará en los siguientes casos: 3.7 Establecimiento de la topología 91 Tabla 3.9 Campos especíĄcos del mensaje de respuesta de estado. Campo Descripción CFGV Número de versión de la conĄguración actual o 0 si la entidad no ha sido conĄgurada nunca. CRLV Número de versión de la CRL instalada o 0 si no hay ninguna. NA Dirección de red de la entidad. NBL Lista de vecinos autorizados alcanzables. Si la entidad no está conĄgurada estará vacía. Será una lista de elementos NeighborData descritos en la Sección 3.4, que a su vez será un subconjunto de la lista de vecinos autorizados que se obtuvo por conĄguración (los elementos no incluidos son vecinos no alcanzables). • En las fases de descubrimiento y de conĄguración, el robot enviará una petición de estado tras conectarse una entidad a él. Esto se hace incluso aunque la entidad se haya conectado previamente al robot, ya que el robot no puede saber con certeza si ha cambiado algo desde la última conexión. • En la fase de mantenimiento, la BS y el robot podrían hacer peticiones puntuales que permitan identiĄcar la causa de anomalías detectadas. Si la BS emite una nueva CRL por difusión, una petición de estado posterior le permite veriĄcar el estado de los nodos. También se puede enviar periódicamente para monitorizar el estado de los nodos. 3.7 Establecimiento de la topología En la fase de establecimiento de la topología, se analizarán los datos recopilados durante la fase de descubrimiento, los datos aportados administrativamente u otros medios y se veriĄcarán que son coherentes. Por ejemplo, la detección de nodos con el mismo nombre o certiĄcado indicaría que se ha clonado un nodo así que serían descartados, ya que su material de seguridad habría sido comprometido. Administrativamente también se puede limitar la pertenencia a la red a una serie de nodos aunque otros también tengan un certiĄcado válido. Una vez que se dispone de un mapa con los nodos válidos, se calcula la topología de la red. Los procedimientos para determinar los vecinos de cada entidad o para calcular las tablas de enrutamiento no están predeterminados. La topología adecuada para una red de sensores dependerá del uso que se le vaya a dar y las características de sus entidades. Por ejemplo, si se quiere optimizar la conectividad y la robustez de la red, se intentará conectar cada nodo con todos los nodos que estén a su alcance radio y la tabla de encaminamientos tendrá rutas redundantes al resto de destinos. En los casos donde la energía disponible en cada nodo sea limitada, se puede recopilar información sobre el nivel de energía de cada nodo e intentar que aquellos con menos energía no se utilicen como nodos intermedios. También se puede monitorizar el estado de los enlaces con los nodos vecinos (calidad, 92 Capítulo 3. Arquitectura de seguridad tiempo de respuesta,...) y que cada nodo solo se conecte a sus mejores vecinos. En deĄnitiva, el cálculo de la información topológica buscará maximizar unos objetivos o reducir el coste según unos parámetros dependientes de la aplicación. Después de realizar los cálculos, si hay cambios, se obtendrá una nueva versión de la información de la topología como la descrita en la Sección 3.4. Esta debe ser sincronizada entre el robot y la BS utilizando los mensajes descritos en la Sección 3.5. Si la BS no estuviera al alcance del robot, este tendría que moverse hacia ella para poder hacer la sincronización. Durante esta fase las conexiones se mantendrán activas para poder ser utilizadas inmediatamente tras el cambio a la fase de conĄguración. 3.8 Configuración de los nodos Para conĄgurar los nodos, el robot o la BS enviarán un mensaje de petición de conĄguración a los nodos. Cuando un nodo recibe el mensaje de petición de conĄguración, realiza los cambios y conĄrma el éxito del cambio de conĄguración devolviendo un mensaje de respuesta. La BS solo podrá realizar este proceso si ya tiene conexión con el nodo a conĄgurar, no hay cambios en las direcciones de red y el enrutamiento sigue siendo válido. En otro caso, el cambio podría afectar a las comunicaciones con el resto de nodos y sería preferible utilizar el robot. El robot, al comunicarse directamente con los nodos, no se ve afectado por fallos de enrutamiento y se puede usar siempre. La primera conĄguración siempre será realizada por el robot. En la fase de conĄguración el robot debe volver a moverse por la instalación para poder conĄgurar directamente cada uno de los nodos sensores. La trayectoria seguida y la velocidad debe garantizar lo anterior basándose en la posición de los nodos que se debe conocer al Ąnalizar la fase de descubrimiento. La trayectoria por tanto puede cambiar respecto a la realizada anteriormente y optimizarse en función de distintos criterios: •Distancia más corta y por tanto menor tiempo en recorrerla. • Con la información topológica se puede analizar la dependencia de unos nodos respecto a otros para la comunicación con la BS. Este análisis se puede emplear para priorizar el envío de la conĄguración a los nodos que van a soportar más tráĄco. En general los nodos más alejados de la BS dependerán de los más cercanos, por lo que la conĄguración de estos últimos es más prioritaria. Si en la fase anterior el robot se ha tenido que acercar a la BS para hacer la sincronización de la información topológica, la trayectoria ya empezará cerca de los nodos más cercanos a esta. • Otros criterios propios de las necesidades de la operativa especíĄca de la WSN pueden priorizar algunos nodos o zonas de la instalación. Conforme el robot se mueve, la interacción con los sensores será inicialmente similar a la fase de descubrimiento. Irá preguntando el estado de los nodos y determinará si necesitan ser conĄgurados o no. En caso aĄrmativo, enviará la conĄguración apropiada a cada nodo. El intercambio de mensajes se muestra en la Figura 3.19. En el caso de que la BS se encargara de la conĄguración el funcionamiento sería similar, salvo que el nodo ya se encontraría conectado a la BS. 3.8 Configuración de los nodos 93 Robot Nodo sensor Similar a la fase de descubrimiento Emparejamiento robot-nodoEmparejamiento robot-nodo Petición de conĄguración Respuesta de conĄguración Figura 3.19 Intercambio de mensajes durante la etapa de conĄguración. La conĄguración enviada al nodo se obtendrá de la información de la topología de la red explicada en la Sección 3.4 y, dependiendo del estado del nodo, podrá incluir: 1. La CRL actualizada (elemento CRLData). 2. Número de versión de la conĄguración (versión de NetworkData ) y conĄguración del nodo a partir del elemento NodeData exceptuando los campos llAddress , name y position . Los campos excluidos ya los conoce el nodo o no los necesita. Aquí se incluye la información de la BS, información de encaminamiento y lista de vecinos autorizados con sus parámetros de conexión. Opcionalmente, en vez de enviar la conĄguración completa, se podrían enviar solo los cambios que se han producido desde la versión que hay en el nodo. Esto podría reducir los datos que hay que transferir. Por consiguiente, habría 2 modos de transferencia (completa o diferencial) y 3 tipos de información enviada (solo CRL, solo conĄguración de red o ambas) que darían lugar a 6 tipos posibles de mensajes de conĄguración. Como se observa en la Figura 3.19, la conĄguración se realiza en un intercambio de mensajes: el robot/BS envía una petición de tipo TM_CONFIGURE_REQ y el nodo responde con una respuesta del tipo TM_CONFIGURE_RES . El contenido del mensaje de petición de conĄguración se muestra en (3.16) y el de la respuesta en (3.17). R→nodo BS →nodo):TM_CONFIGURE_REQ ∥TX_ID ∥T_CFG ∥ CRL_DATA ∥CFGV ∥NODE_DATA (3.16) NODE_DATA ≡NA ∥BS_DATA ∥NBL ∥NO_NBL ∥ ROUTES ∥NO_ROUTES 94 Capítulo 3. Arquitectura de seguridad nodo →R nodo →BS):TM _CONFIGURE_RES ∥TX_ID ∥CFGV ∥CRLV (3.17) Estos mensajes serán transmitidos empleando el servicio de envío Ąable del TL. Los dos primeros campos de cada mensaje son el tipo de mensaje de aplicación y el identiĄcador de transacción, como se explicó en la Sección 3.3.3. Los campos del mensaje de respuesta son equivalentes a los del mensaje de respuesta de estado, que aparecen descritos en la Tabla 3.9. El resto de campos del mensaje de petición aparecen descritos en la Tabla 3.10 y la Tabla 3.11. Tabla 3.10 Campos especíĄcos del mensaje de petición conĄguración. Campo Descripción T_CFG Tipo de la petición de conĄguración. Determina si deben aparecer el resto de campos, que son opcionales, y si el modo de transferencia es completa o diferencial. CRL_DATA CRL actualizada utilizando el mismo formato que se almacena en la información de la topología. CFGV Número de versión de la conĄguración. Equivale a la versión del elemento NetworkData de la información topológica a la que pertenece esta conĄguración. NODE_DATA Información tomada del elemento NodeData de la información topológica para este nodo con los campos descritos en la Tabla 3.11. El mensaje de petición se podría extender con más información relevante para una instalación concreta. Los nodos deben aplicar la conĄguración enviada, cerrando conexiones con vecinos que no deberían serlo y estableciendo conexiones con nuevos vecinos. Si un vecino se mantiene como tal pero sus datos o los parámetros de comunicación con él cambian, el nodo puede optar por reabrir la conexión o reutilizar la existente modiĄcándola. Si se actualiza la CRL veriĄcará que no haya establecido ninguna comunicación con entidades cuyos certiĄcados hayan sido revocados. La respuesta del nodo incluirá las nuevas versiones de conĄguración y CRL como conĄrmación que han sido aplicadas. Desde que comienza la conĄguración del primer nodo hasta que se termina de conĄgurar el último puede existir un periodo transitorio de inestabilidad. Un nodo conĄgurado puede que tenga asignados vecinos que aún no lo están, lo que implicará que tendrá que reintentar la conexión. Entre los efectos temporales que se pueden producir en la red destacan: • Congestión: los nodos empezarán a conectarse a sus vecinos y a transmitir información a la BS. Se realizarán simultáneamente muchos procesos de saludo por lo que la colisión de tramas es más probable. El robot tiene que tener en cuenta que los nodos pueden tardar más en conectarse a él. 3.8 Configuración de los nodos 95 Tabla 3.11 Subcampos del campo NODE_DATA. Subcampo Descripción NA Dirección de red. BS_DATA Información de la BS a la que debe transmitir datos con el mismo formato que se utiliza en la información de la topología. NBL Lista de los vecinos autorizados y sus parámetros de comunicación. Lista completa o lista que hay que añadir a los existentes (modo diferencial). El formato es el mismo que el utilizado en la información de la topología. NO_NBL Lista que incluye el listado de las direcciones de red de los vecinos que hay que eliminar en el caso de modo diferencial. ROUTES Información de encaminamiento a utilizar (completa) o que hay que añadir (diferencial). El formato es el mismo que el utilizado en la información de la topología. NO_ROUTES Información de encaminamiento a eliminar en el caso de modo diferencial. El formato es el mismo que el campo anterior. • Bucles: la información de enrutamiento suele estar calculada suponiendo que todos los nodos tienen la misma versión de conĄguración y en el transitorio se mezclan nodos funcionando con distintas versiones, con direccionamientos de red posiblemente incompatibles. Al Ąnal, este transitorio termina y la red se estabiliza. Si en una implementación concreta se quiere evitar y detectar estos posibles problemas temporales, se proponen las siguientes soluciones opcionales que reducen estos efectos: • Un nodo no reenviará paquetes que tengan su dirección como origen o, si es posible, lo marcará para que esto no se repita indeĄnidamente. • Se establecerá un límite de saltos en los paquetes del NL acorde a las dimensiones de la red. Este es un valor que puede calcularse a partir del diámetro de la red. • Las conexiones con los vecinos no se iniciarán inmediatamente a la recepción de la conĄguración, sino que se retardarán un tiempo aleatorio. •Los reintentos también utilizarán retardos aleatorios. • Las anomalías no se empezarán a enviar hasta haber recibido correctamente el primer mensaje de la BS a menos que el robot o la BS sean vecinos del nodo. A pesar de este transitorio el robot no debería tener diĄcultad en comunicarse directamente con los nodos situándose próximo a estos. Terminada la conĄguración de los nodos, se esperaría un tiempo prudencial para que los nodos pudieran ponerse en contacto con la BS. Si alguno de los nodos no consigue 102 Capítulo 3. Arquitectura de seguridad Tabla 3.15 Tipos de veriĄcación de la autenticidad del mensaje de difusión. Valor de BVT Verificaciones realizadas BVT_FORBIDDEN La difusión está prohibida, por lo que todos los mensajes de difusión son ignorados. Solo se permite la actualización de la CRL mediante conexión punto a punto. BVT_KNOWN_BS Se veriĄca que la dirección de red origen es la de la BS. Esta sería la veriĄcación mínima. BVT_KNOWN_BS_SIGN Además de la veriĄcación anterior, el mensaje debe incorporar el CertCA BS y una Ąrma digital. Ambos deben ser veriĄcados. El CertCA BS incluye la clave pública que permite veriĄcar la Ąrma digital aunque no se haya establecido comunicación previamente con la BS. BVT_CONNECTED_BS_SIGN Similar al caso anterior, salvo que no se transmite el CertCA BS y se reduce el tamaño del mensaje. La clave pública necesaria para veriĄcar la Ąrma digital debe haberse obtenido anteriormente durante el proceso de saludo de una conexión con la BS. ∗ → ∗ :TM_SET_CRL_BCAST ∥TX_ID ∥CRL_DATA ∥CERT ∥SIGN (3.20) Los tres primeros campos del mensaje son equivalentes a los del mensaje de petición de conĄguración descritos en la Tabla 3.10. El resto de campos aparecen descritos en la Tabla 3.16. Tabla 3.16 Campos adicionales en la petición de actualización de CRL por difusión. Campo Descripción CERT Es el CertCA BS . Contiene la clave pública que se utilizará para veriĄcar la Ąrma digital. Solo se transmite si el valor de BVT es BVT_KNOWN_BS_SIGN. SIGN Firma digital, realizada con la clave privada asociada al CertCA BS , de todo el resto del mensaje y la dirección origen. 3.9.2.3 Comparativa Si la difusión está permitida ( BVT no es BVT_FORBIDDEN ) la BS elige entre un modo u otro pudiendo utilizar como criterios: 3.10 Opciones y parámetros de la arquitectura 103 •El coste computacional. •El número de paquetes transmitidos. •Si se desea que entidades ajenas a la red puedan ver o no la información. •La autenticación deseada. •La Ąabilidad ante fallos de enrutamiento. • El tiempo necesario para conĄgurar toda la red, que puede ser dependiente de todo lo anterior. En difusión, si se quiere autenticar los mensajes, se tendría que utilizar criptografía asimétrica que es más costosa computacionalmente. Cada entidad necesita veriĄcar el mensaje tan solo una única vez ya que los mensajes duplicados se detectarían fácilmente. Sin embargo, un atacante que haya comprometido uno de los nodos podría enviar mensajes falsos forzando a otras entidades a comprobar cada uno de ellos, consumiendo sus recursos hasta que no se ponga remedio. Usando la conexión punto a punto se utilizarían las claves simétricas negociadas durante el proceso de saludo como cualquier otro mensaje. El número de mensajes transmitidos con un modo u otro dependerá de la topología de la red. Por ejemplo, si la topología es en árbol, la difusión sería muy eĄciente. En cambio, en redes con mucha densidad, la difusión generaría muchas copias aunque los nodos esperen un cierto tiempo antes de volver a difundir el mensaje. El envío por difusión no es Ąable y a veces es necesario repetir la difusión para minimizar la probabilidad de pérdida, como se hace en [ 8 ]. Con punto a punto, los nodos intermediarios más cercanos a la BS tendrían más carga pero se garantiza la entrega al utilizar envío Ąable. Con difusión, los datos estarán cifrados para entidades ajenas a la red solo si esto se hace en el LL, mientras que en punto a punto se puede elegir el nivel donde se cifra. Con punto a punto, la BS obtiene respuesta a la petición y puede gestionar el envío para que no se produzca la implosión de asentimientos, sin embargo si hubiera algún problema de enrutamiento fallaría. Usando difusión, no habría problemas de enrutamiento pero habría que veriĄcar que todas las entidades se han actualizado posteriormente. Se deja al criterio de la implementación y al del administrador de la red decidir el modo más apropiado en cada caso. 3.10 Opciones y parámetros de la arquitectura La arquitectura SNSR pretende ser lo más Ćexible posible, permitiendo que se pueda adaptar a distintos tipos de redes existentes y a las necesidades de seguridad de la instalación donde se vaya a utilizar. A lo largo de este capítulo se ha mostrado que muchos procedimientos de la arquitectura SNSR son opcionales y/o conĄgurables. Se dejan a la elección de la implementación concreta de la arquitectura SNSR y a la conĄguración del administrador de la red, de tal manera que se adapten a los requisitos de una red de sensores en particular. En esta sección se hará un resumen de todo esto. Las decisiones dependientes de la implementación y/o conĄguración son las siguientes: 104 Capítulo 3. Arquitectura de seguridad • Modo de seguridad. Si se usa seguridad, también hay que decidir: los algoritmos permitidos, el tamaño de las claves, la validez temporal máxima de las claves y el proceso de saludo a utilizar. •Contenido de la CRL de los nodos (completa o solo de certiĄcados de robots). •Método de detección de balizas. •Método de actualización urgente de CRL. •Tipo de veriĄcación de mensajes de difusión. •Tipo de enrutamiento. •Algoritmos para el cálculo de trayectorias a seguir por el robot. •Algoritmos para el cálculo de la topología de la red más eĄciente. •Tipo de entidad que realiza el cálculo de la topología. • Número de versiones de la información topológica que deben almacenar la BS y el robot. • Parámetros de comunicación por defecto para el mantenimiento de las conexiones. Reintentos, temporizadores y límites de saltos. • Parámetros estáticos (preconĄgurados) o dinámicos (conĄgurables mediante la petición de conĄguración). •Envío de conĄguración diferencial o completa. •Información de estado adicional a recopilar. • Anomalías a detectar. Límites del almacenamiento de anomalías. Políticas de eliminación y envío de anomalías. •Algoritmos para el procesamiento de anomalías. En la Tabla 3.17 se muestran los parámetros de conĄguración de todas las entidades. Algunos de ellos admiten la posibilidad de modiĄcarse posteriormente. No se incluyen aquellos parámetros que son dependientes de la implementación. Tabla 3.17 Cuadro resumen de parámetros de conĄguración. Parámetro Descripción ID Identidad de la entidad. CERT_CA CertiĄcado de la CA. CERT CertiĄcado propio. PR Clave privada propia. Continúa en la siguiente página ż 3.10 Opciones y parámetros de la arquitectura 105 Tabla 3.17 (Continúa de la página anterior) Parámetro Descripción DOMAIN Nombre de dominio de la red. BS_TYPE Campo tipo de identidades de tipo BS, (3.1). MS_TYPE Campo tipo de identidades de tipo robot, (3.1). SN_TYPE Campo tipo de identidades de tipo nodo sensor, (3.1). SEG Modo de seguridad. Tabla 3.2. CIPHER_SUITES Conjunto de algoritmos de seguridad permitidos. SIG_TYPE Tipo de Ąrmas digitales usadas en los certiĄcados. HASH_TYPE Tipo de funciones hash usadas en los certiĄcados. MIN_KEY_LEN Longitud de clave mínima permitida. TMP_KEY_DUR Duración de una clave temporal, intervalo de renovación de claves temporales en una conexión. CRL CRL inicial. BVT Tipo de veriĄcación de mensajes de difusión. B_DELAY Tiempo a esperar antes de reenviar un mensaje de difusión. LL_ADDRESS Dirección MAC. NL_ADDRESS Dirección de red. Salvo en el robot, inicialmente será 0. DEFAULT_HOP_LIMIT Número de saltos máximos al enviar nuevos paquetes. DEFAULT_KAI KAI g usado en las conexiones si no se indica otro expresamente. KAI_FACTOR KAIF para calcular el KATO de una conexión. MAX_NB Número máximo de vecinos. MAX_ANOMALIES Número máximo de anomalías a almacenar. MIN_ANOM_INTERVAL Tiempo mínimo que debe transcurrir antes de volver a enviar anomalías sin haber recibido un asentimiento. MAX_MS Número máximo de conexiones con robots y de candidatos. Ignorado por el robot. BEACON_DETECTION Detección de baliza básica o avanzada (no para el robot). Continúa en la siguiente página ż 106 Capítulo 3. Arquitectura de seguridad Tabla 3.17 (Continúa de la página anterior) Parámetro Descripción TC_MAX Tiempo de contención máximo al recibir una baliza (no para el robot). BI_MAX Intervalo máximo entre balizas (solo para el robot). MS_FAST_HS Reducción en reintentos y temporizadores para conexiones con el robot. TOP_CALC Tipo de entidad que realiza el cálculo de la topología. 3.11 Conclusiones Este Capítulo ha presentado el diseño de la arquitectura SNSR, que se corresponde con la Contribución 1 de esta Tesis Doctoral, y su adaptación para el caso de una BS y un robot, que se corresponde con la Contribución 2. Para realizar este diseño ha sido necesario un análisis minucioso del problema que se pretendía solucionar así como de las tecnologías existentes. Adaptar una red de sensores que ya se está utilizando suele ser menos costoso que sustituirla por completo. El diseño de la arquitectura propuesta ha intentado ser lo suĄcientemente genérico y Ćexible para poder reutilizar la infraestructura existente y mejorarla aprovechando las capacidades del robot. Esta nueva arquitectura, denominada arquitectura SNSR, tiene como misión principal mejorar la seguridad de las WSN permitiendo elegir el nivel deseado de seguridad, ya que la seguridad implica un coste energético. Sin embargo, gracias al uso del robot, el coste de un mismo nivel de seguridad se reduce respecto a las tecnologías de WSN existentes. Es más, incluso si no se deseara ningún nivel de seguridad, se puede mejorar la eĄciencia de las redes habituales al reducir la carga de trabajo de los nodos sensores. Esta arquitectura también es la base de un nuevo Sistema Operativo de Red (NOS, Network Operating System), dando lugar a nuevas familias de WSN. Se han detallado el software que debe ejecutarse en cada una de las entidades de la red, las comunicaciones entre ellas y el funcionamiento en conjunto. La seguridad de una cadena es la del eslabón más débil. La arquitectura SNSR reduce la dependencia de unos nodos respecto a otros. Los nodos sensores van a ser el elemento más débil y, por tanto, más fácil de atacar. Si un atacante se hace con el control de un nodo, el efecto es mucho más limitado que en otras arquitecturas de WSN. Un nodo malicioso no puede alterar el funcionamiento de la red, como mucho puede provocar una degradación del funcionamiento a nivel local. El reparto de responsabilidad en temas de seguridad se hace de acuerdo a la debilidad de la entidad, aprovechando la heterogeneidad del sistema estudiado. Aplicar soluciones de redes ad hoc donde todos los componentes tienen la misma responsabilidad en el mantenimiento de la red supondría un uso no eĄciente de recursos por un lado y un mal análisis de riesgos. Por último, la gran cantidad de opciones que permite esta arquitectura, va a permitir experimentar con ellas, sin limitar la incorporación posterior de mejoras. 4 Implementación No basta tener un buen ingenio, lo principal es aplicarlo bien. René Descartes En este capítulo se detallan la Contribución 3 de esta Tesis Doctoral ŞSistema operativo de red genéricoŤ, la Contribución 4 de esta Tesis Doctoral ŞAplicaciones de gestión de robots, estaciones base y nodos sensores para SNSRŤ, y la Contribución 5 de esta Tesis Doctoral ŞCompositor/orquestador de escenarios y sistema de gestión remota de dispositivosŤ . Se desarrolla un Sistema Operativo de Red (NOS, Network Operating System) capaz de ejecutarse en distintos equipos (robot, BS y nodos sensores) que implementa las funcionalidades descritas en la arquitectura SNSR. De esta manera se puede probar en equipos reales. La implementación tiene alta Ćexibilidad y permite probar distintas conĄguraciones, algoritmos, protocolos, entre otros. Para realizar la implementación ha sido importante tener en cuenta los escenarios donde se van a realizar las pruebas. Uno de los objetivos principales de esta Tesis Doctoral es la experimentación y validación de la arquitectura desarrollada en dispositivos físicos y condiciones reales, pero sin depender de una red de sensores concreta. En los escenarios objetivos reales el robot aéreo o terrestre estará equipado con un computador compacto, mientras que la BS será una estación de trabajo. Para los nodos sensores, se dispone de dispositivos con menor capacidad Raspberry PI 1 Model B. En esta Tesis Doctoral se utilizarán redes WiFi para la comunicación inalámbrica, en modo ad hoc, pudiendo modiĄcar la MTU para asimilarlo a las WSN. Se ha creado un portal web que permite monitorizar las versiones instaladas del software en cada equipo, así como realizar actualizaciones de este. También permite cargar distintas conĄguraciones para poder hacer pruebas en distintos escenarios. Al mismo tiempo se desean hacer pruebas masivas que involucren cientos de nodos sensores y con múltiples topologías diferentes. Dado que la realización de pruebas reales es más lenta y costosa, otro objetivo es poder realizar escenarios simulados, donde un mismo computador pueda ejecutar múltiples nodos sensores aislados lógicamente, pero utilizando el mismo software que se utilizaría realmente. Para esto, se ha desarrollado un 107 108 Capítulo 4. Implementación compositor/orquestador de escenarios especíĄco, que se ha denominado lanzador, para probar estas redes sin necesidad de hacerlo en un entorno real. Este lanzador permite simular las propiedades de los canales de comunicación y se puede emplear para probar también otras arquitecturas. En escenarios simulados, la topología se podrá deĄnir manualmente para probar casos límites, como podría ser una topología lineal o circular. También se podrán utilizar generadores automáticos de topologías que permitan generar grafos de cuadrículas (rectangulares y triangulares) y aleatorios para un número determinado de nodos sensores, permitiendo grafos fuertemente conexos o no y con un mínimo grado (número de conexiones con vecinos) para cada nodo. Las propiedades de los canales de comunicación también podrán ser modiĄcadas (retardos de propagación, probabilidad de pérdida de tramas, duplicación y envío desordenado). En la la Sección 4.1 se detallan las decisiones tomadas a la hora de implementar la arquitectura. En el resto del capítulo se explica la implementación de todo el software utilizado en esta Tesis Doctoral, comenzando en la Sección 4.2 con las aplicaciones de usuario que se ejecutarán en cada tipo de entidad. A continuación, en la Sección 4.3, se explica el NOS completo que se ejecuta en las entidades incluyendo las aplicaciones de gestión fundamentales para la arquitectura SNSR. Dado que en algunos escenarios se realizan ataques, en la Sección 4.4 se incluye una breve descripción de las herramientas utilizadas para esos ataques. Una vez descritas las entidades participantes en los escenarios, la Sección 4.5 se dedicada al lanzador, utilizado principalmente para escenarios simulados, aunque también es de ayuda en la preparación de escenarios reales. Para terminar, en la Sección 4.6, se muestra el sistema de gestión remota que permite controlar los dispositivos empleados en escenarios reales. 4.1 Decisiones de implementación En la Sección 3.10 se mostraba la alta Ćexibilidad de la arquitectura SNSR, permitiendo distintas alternativas en la implementación y conĄguración. En esta sección se describirán las decisiones tomadas para esta implementación y las opciones que son conĄgurables, ya sea en compilación, inicialización o ejecución. Se desea hacer una implementación de la arquitectura genérica, que no dependa de una tecnología de red de sensores concreta. Además, debe mantenerse suĄcientemente Ćexible para que pueda ser adaptada posteriormente a redes reales. La implementación debe correr sobre un sistema operativo existente, ya que no es el objetivo de esta Tesis Doctoral desarrollar uno. Aunque existen sistemas operativos especíĄcos para WSN, como los descritos en [ 39 ], se ha decidido utilizar el sistema operativo Linux para la ejecución de programas que actúen como las distintas entidades de la red. Linux es un sistema operativo de propósito general de código abierto y libre, que permite modiĄcarlo y adaptarlo a distintos requisitos. Al estar soportado por todos los dispositivos utilizados, va a permitir simpliĄcar las tareas de desarrollo. La implementación de una entidad como un programa de usuario del sistema operativo servirá posteriormente para simular escenarios permitiendo que un mismo ordenador ejecute distintas entidades simultáneamente. Para mantener la implementación genérica, tampoco se va a utilizar una pila de protocolos existente. En su lugar, se va a implementar una nueva que dé más libertad para hacer 4.1 Decisiones de implementación 109 pruebas. Pero sin llegar a los niveles más bajos PHY ni LL, que requieran trabajar directamente con el hardware de los dispositivos. Así que se reutilizarán los niveles inferiores existentes ya soportados por el propio sistema operativo. Sobre un LL concreto se creará un nivel de adaptación que proporcione las funcionalidades que espera la arquitectura. Se utilizan los lenguajes C/C++ para la codiĄcación. Se busca obtener una implementación eĄciente y rápida. Estos lenguajes se utilizan frecuentemente en el desarrollo de sistemas operativos [ 39 ] y pilas de protocolos (como la del propio sistema operativo Linux) y es habitual también encontrarlos en simuladores de red de eventos discretos como el ns-3 [ 128 ]. Existen compiladores para prácticamente todos los microprocesadores por lo que el código se podrá portar de manera sencilla a otros dispositivos y sistemas. A partir del código fuente puede generarse un único programa que pueda actuar como cualquier tipo de entidad por conĄguración, aunque también se puede generar un programa individual para cada tipo de entidad. Dentro del código existen constantes (macros del preprocesador) que hacen que se compilen unas partes del código y otras no (compilación condicional). Esto se ha utilizado para modiĄcar el comportamiento de las entidades, pudiendo seleccionar en tiempo de compilación distintas alternativas para implementar algunas funcionalidades. El programa generado se ha llamado Node . Además, para realizar pruebas, se ha creado otro programa partiendo del mismo código fuente, pero modiĄcando determinadas partes para simular nodos maliciosos, al que se ha llamado Badnode. La conĄguración en compilación es el modo de conĄguración más estático, ya que, una vez generado el programa, no se puede modiĄcar. Esto reduce la Ćexibilidad, pero también limita la posible modiĄcación malintencionada de un nodo y permite reducir el tamaño del ejecutable al no incluirse código que no se desea utilizar. La reducción del tamaño, la simpliĄcación del análisis de los parámetros de conĄguración y las pruebas que se han realizado son los motivos por los que estas constantes no se han conĄgurado en la inicialización. El programa Node recibe la conĄguración en la inicialización a través de los argumentos de la línea de comandos o de un Ąchero de conĄguración. Algunos de los parámetros conĄgurables pueden ser modiĄcados en ejecución, pero otros no y conservarán su valor durante la ejecución del programa. Estos últimos suelen ser parámetros cuyo valor no se desea cambiar a posteriori, y que no podrían ser modiĄcados con un mensaje de petición de conĄguración. En el listado 4.1 se muestra la ayuda que presenta el programa sobre los argumentos admitidos. Código 4.1 Argumentos de conĄguración inicial. 1Use:Node [OPTIONS] |[CONFIG_FILE] 2 3Run a node. 4 5-h, --help shows this help, 6 7Required options: 8-n, --name=name name of the node (CN certificate’s field), 9-c, --cert=file file name of the certificate in DER format, 110 Capítulo 4. Implementación 10 -k, --key=file file name of the private key in DER format, 11 -m, --ca=file file name of the CA public certificate, 12 -a, --netaddr=address network address of the node (unsigned short), 13 14 Optional options (0 or more): 15 -p, --pid=file save pid in file name 16 -x, --crl=file file name of a CRL 17 -i, --input=string listen to UDP socket. Format:IPv6#UDPport 18 listen to ETHERNET socket. Format:ifname or mac 19 -r, --route=string add route entry. Format:subnet#bits#gw#metric 20 -b, --bs=address[#name] add network address of a base station. If name 21 is given, data will be encrypted. 22 -l, --link=string add link. UDP:c|s|p#IPv6#UDP#name#addr#keepalive 23 ETHERNET:c|s|p#ETH#mac#name#addr#keepalive 24 -L, --securell=[01] secure link layer (LL) data: 25 NO=0 (default), YES=1 26 -T, --securetl=[012] secure transport layer (TL) data: 27 NONE=0, ALL=1, EXCEPT_NEIGBORS=2 28 -s, --suffixes=string suffixes to differentiate node types. Format: 29 commonCNsfx#nodeCNsfx#managerCNsfx#bsCNsfx 30 -A, --autolinks=string config autolinks. Format: 31 [CNsuffix]#maxAutolinks#[secure[0|1]][#interval] 32 if CNsuffix is omitted, managerCNsfx+commonCNsfx 33 if secure is omitted, uses securell option 34 interval between attempts in seconds (optional) 35 -B, --beacons=string send beacons. UDP IPv6#UDP#keepalive#interval 36 ETH mac#keepalive#interval 37 -u, --unknown=[0123] action for unknown packets: 38 DISCARD=0, DEFAULT_LINK=1, NEW=2, NEW_SECURE=3 39 default:0 (types ’sn’ & ’bs’), 2+securell (’ms’) 40 -K, --keepalive=int default keepalive interval for new links (0) 41 -U, --unknownpeer allow unkwnown peers data in TL. 42 default:false (types ’sn’ & ’ms’), true (’bs’) 43 -P, --allowedpeers=x-y network addresses of allowed peers in TL. 0=all 44 -t, --type=string application layer to run: 45 ’al’ (generic AL), ’sn’, ’ms’ (robot), ’bs’ 46 -C, --command=string command to execute on node at startup. 47 -v, --bvt=[0123] broadcast verify type, source must be a BS: 48 FORBIDDEN=0,KNOWN=1,KNOWN_SIGN=2,CONNECTED_SIGN=3 49 -E, --cipherlist=string cipher suite list, colon-delimited:suite:suite 50 default is ’ECDHE-ECDSA-AES128-GCM-SHA256’ 51 -F, --cipherlisttl=str cipher suite list for TL. 52 default is the same as --cipherlist 53 -d, --loglevel trace=0, debug=1, info=2, warn=3, err=4, 54 critical=5, off=6 55 -f, --logfile file name where logs are written 56 -H, --hoplimit default hop limit used in network packets [1-255] 57 58 (c) 2016-2022 - Francisco José Fernández Jiménez. DIT.US.ES 4.1 Decisiones de implementación 111 La BS y los nodos sensores permiten una conĄguración posterior cuando se establezca la topología de la red: vecinos y cómo comunicarse con ellos, enrutamiento y la CRL principalmente. El robot también puede actualizar la CRL y recibir una lista de nodos a descubrir antes de entrar en la fase de descubrimiento. Por último, cada tipo de entidad admite un conjunto de comandos administrativos, que pueden recibirse durante la ejecución por la entrada estándar (por defecto). Cada entidad proporciona una consola de comandos con la que un administrador, de manera manual o a través de otro programa, puede interactuar para obtener información del estado actual o modiĄcar la conĄguración. El listado 4.2 muestra los comandos administrativos implementados comunes y especíĄcos para cada tipo de entidad. Código 4.2 Comandos administrativos. 1=== Node commands === 2anomaly type => add anomaly. 3beacons IP#PORT#KEEPALIVE#INTERVAL => config. UDP beacons. 4beacons mac#KEEPALIVE#INTERVAL => config. ETH beacons. 5cl c|s|p#IPv6#UDP#name#addr#ka => create new UDP link. 6cl c|s|p#ETH#mac#name#addr#ka => create new ETH link. 7ct c|s|p#name#addr => create new transport connection. 8da id => delete anomaly. 9dl IP#PORT => delete link (UDP). 10 dl mac => delete link (ETHERNET). 11 dn netaddr => delete neighbor. 12 dt netaddr => delete transport connection. 13 echo string => print string. 14 help => list available commands. 15 pa => print anomalies. 16 pals => print autolink statistics. 17 pb => print base stations (AL). 18 ping netaddr => send ping. 19 pn => print neighbors (NL). 20 pp => print peers (AL). 21 pr => print routes (NL). 22 ps => print statistics. 23 restart => restart node with same arguments. 24 stop => stop and exit. 25 tr netaddr => send trace. 26 transfer netaddr,num,size,reliable => transfer test. 27 28 === Sensor commands === 29 last-ping => timestamp of last ping response received. 30 pbs => print connected base stations. 31 reset-last-ping => reset last ping. 32 sa => force to send anomalies. 33 start-pings interval => send pings to base station. 118 Capítulo 4. Implementación Para ilustrar el funcionamiento del enrutamiento se muestran en la Figura 4.1 4 casos representativos usando topologías de red sencillas (podrían ser parte de una mayor) en las se consigue que un paquete llegue a su destino a pesar de existir enlaces caídos. Las líneas negras sólidas son conexiones establecidas entre entidades y las punteadas son conexiones conĄguradas aún no establecidas. Las Ćechas rojas sólidas representan la transmisión de un paquete con enrutamiento normal y las punteadas con alternativo. El color de fondo de los nodos representa la distancia menor en saltos a la BS suponiendo que todas las conexiones conĄguradas estuvieran bien. Suponemos que todos los nodos tienen tantas rutas conĄguradas a la BS y a N3 como nodos vecinos, ordenadas de menor a mayor número de saltos teóricos. Con esos supuestos, el nodo N3 (con borde rojo) envía un paquete a la BS (con fondo rojo). Figura 4.1 Funcionamiento del enrutamiento implementado. La BS se muestra en rojo y el color de los nodos depende de la distancia a la BS. En el caso (1) solo se usa enrutamiento normal. N3 aún no ha establecido comunicación directa con la BS por lo que envía el paquete a N1 o N2 según el orden de conĄguración, sin conocer el estado de los enlaces de sus vecinos. Suponiendo que lo envía a N2 y este tampoco tiene la conexión directa con la BS, N2 elige enviarlo a N4 antes que al origen. N4 preĄere enviarlo a N1 antes que al origen o por el enlace de entrada. Por último, N1 lo envía al destino. En el caso (2), N3 podría enviar el paquete a N1 o N2 igual que en (1). Si lo envía a N1, este lo reenviará al N4. N4 preĄere enviarlo al origen antes que por el enlace de entrada. N3 detectará el bucle y activa el enrutamiento alternativo, por lo que lo enviará usando la segunda ruta más prioritaria, que es a N2. N2 lo entrega al destino Ąnal. El caso (3) es similar a (2), pero ahora no está establecida la conexión entre N3 y N4. N4 tiene ahora que reenviar el paquete por el enlace de entrada y N1 preferirá enviarlo al origen antes que al nodo anterior. N3 detecta el bucle y el resto es igual. Por último, en el caso (4), N3 lo envía a N1, pero este no tiene la conexión directa con la BS operativa. Así, que N1 lo envía a N4 y N4 a N5, porque es la ruta más corta sin usar 4.1 Decisiones de implementación 119 el enlace por el que llegó el paquete. N5 no tiene más remedio que reenviarlo al origen que activa el enrutamiento alternativo, pero se ve forzado a reenviarlo de nuevo a N1. N1 lo reenvía a N4 y ahora N4 cambia su decisión, porque preĄere enviarlo a N7 antes que a N5, que sería el mismo vecino que usaría si tuviera que enviarlo al origen (esto no se hace en enrutamiento normal). N7 lo reenvía a N8 y así sigue hasta la BS. 4.1.7 Cálculo de la topología de la red En esta implementación el objetivo principal es maximizar la robustez de la red. Para ello, se busca que la BS y los nodos tengan el número máximo posible de conexiones con vecinos (aunque su número puede limitarse en compilación) y que dispongan de rutas principales y alternativas con el resto de entidades. El orden de las rutas se decide intentando distribuir el trabajo de reenvío de paquetes entre todos los nodos. El robot va a ser el encargado de realizar el cálculo. Después comparte el resultado con la BS que lo acepta o rechaza veriĄcando los números de versiones. A la BS también se le puede pasar información topológica de manera administrativa. El proceso completo se realiza en 7 pasos: 1. Generación de un grafo representativo de la red. 2. Cálculo de las rutas. 3. Ordenación de las rutas. 4. Asignación de direcciones de red. 5. DeĄnición de los parámetros de comunicación entre vecinos. 6. Compresión de las rutas. 7. Actualización de la CRL y rellenado del resto de campos. En las siguientes secciones se describen esos pasos. 4.1.7.1 Generación de un grafo representativo de la red Lo primero que se realiza es una representación de la red usando un grafo G= (V,A) formado por un conjunto de vértices V y aristas A . Cada vértice v∈V es una entidad de la red y cada arista a∈A representa la vecindad o adyacencia entre dos entidades. En esta implementación, los grafos se representan con listas de adyacencia: cada vértice v∈V tiene una lista con los vértices adyacentes a él, que denotaremos como NG(v) . La adyacencia se puede obtener de tres modos: 1. Obtenida de la versión inicial de la información de topología, que habrá sido establecida externamente. 2. Calculada a partir del rango de alcance radio rde los nodos. De manera optimista, se considera que dos nodos pueden ser vecinos si se encuentran a una distancia menor que r. Este modo se utilizará después de la primera fase de descubrimiento si en la versión inicial de información topológica no se incluían datos de vecindad. 3. A partir de la información de estado facilitada por las propias entidades al robot en una fase de descubrimiento posterior a la primera fase de conĄguración. Cada 120 Capítulo 4. Implementación entidad intenta conectarse con los vecinos indicados e informa con cuáles se ha conectado. 4.1.7.2 Cálculo de las rutas En segundo lugar, se calculan las rutas más cortas desde cada vértice v∈V al resto de vértices v′∈V\¶v♢ para cada uno de los vértices adyacentes w∈NG(v) como siguiente salto. Por ejemplo, si un nodo x tiene n vecinos, se intentaría calcular n rutas hacia cada posible destino, siendo la ruta i la más corta que tiene al vecino i∈NG(x) como primer salto. Para lograr lo anterior se utiliza un algoritmo basado en búsqueda en profundidad (DFS, Depth First Search) [ 60 ] que también permite veriĄcar si el grafo es fuertemente conexo [ 145 ]. Una ventaja de DFS es que requiere muy poca memoria para recorrer el grafo. El grafo se recorre desde cada uno de los vértices anotando simultáneamente el número de saltos de la ruta más corta a cada destino partiendo desde cada vecino (si existe). Esta información sirve para determinar con qué prioridad se elegirá un vecino u otro para enviar un paquete a un destino. La ventaja de tener múltiples alternativas almacenadas en la tabla de rutas es que el encaminamiento de paquetes es muy robusto. Si un vecino falla, un nodo tendrá disponible otra ruta, en principio la siguiente más corta (si no se han producido más caídas de las que no es consciente), sin necesidad de comunicarse con otras entidades. Esto a su vez, reduce el número de reconĄguraciones necesarias que pueden implicar una nueva fase de descubrimiento con el robot. El inconveniente es la escalabilidad. Está demostrado que en un enrutamiento basado en rutas más cortas el tamaño de la tabla de rutas crece linealmente con el tamaño de la red en el mejor de los casos [ 85 ]. Normalmente el crecimiento es supra lineal. Un ejemplo similar muy conocido de este problema es el que se produce en las tablas del protocolo de puerta de enlace de frontera (BGP, Border Gateway Protocol) de Internet. En este caso, con rutas alternativas, el tamaño de las tablas de enrutamiento son del orden de O(♣V♣g) , siendo ♣V♣ el número de elementos de la red y g el grado medio. Según las características de las redes (como aquellas del tipo scale-free osmall-world) se pueden encontrar soluciones más escalables si no se fuerza a usar las rutas más cortas [ 85 ]. El número de rutas también se puede reducir si se tiene en cuenta las aplicaciones que se van a ejecutar sobre la red. Por ejemplo, si se conoce que los nodos se comunican exclusivamente con la BS y no entre ellos, se pueden excluir todas las rutas que usen la BS como punto intermedio. 4.1.7.3 Ordenación de las rutas A continuación, las rutas calculadas se ordenan. La métrica asociada a cada ruta es proporcional a su longitud (en número de saltos). De esta manera las rutas más cortas tendrán una métrica menor y por tanto serán más prioritarias. Puede ocurrir que existan varias rutas alternativas de longitud mínima. En estos casos las rutas se ordenan intentando que el tráĄco se distribuya lo más equitativamente posible entre los posibles nodos de tránsito en el caso más probable: ningún nodo ha fallado y siempre se utilizan las rutas más prioritarias. También se ha supuesto que todos los nodos van a generar el mismo tráĄco y que todas las entidades pueden hablar entre sí. Para realizar lo anterior se siguen los siguientes pasos: 1. Se deĄne la carga de un vértice lv∀v∈V , como el número de veces que el vértice es elegido el primer salto de la ruta más prioritaria entre otros dos vértices x∈V,y ∈V . Inicialmente es 0. 4.1 Decisiones de implementación 121 2. Sea rf x,y x∈V,y ∈V,f ∈NG(x)la primera ruta más corta encontrada entre xe y usando f como primer salto. La longitud mínima de la ruta desde x a y vendrá dada por minx,y def = m´ınrf x,y∀f∈NG(x) . No se tienen en cuenta las rutas que no existen, sería como suponer que tienen longitud inĄnita. Si minx,y =∞ el resto del proceso no se aplicaría. 3. Sea el conjunto de rutas de longitud mínima entre el vértice x y el y , Rmin x,y def = Srf x,y :x∈V,y ∈V,x =y,f ∈NG(x),rf x,y=minx,y . Sea U el conjunto formado por todos los conjuntos anteriores Udef =Rmin x,y ∀x,y ∈V,x =y. 4. Se ordenan los elementos U según el número de rutas alternativas, Rmin x,y x∈ V,y ∈V,x =y, de menor a mayor. 5. Siguiendo el orden anterior, se ordenan los elementos de cada Rmin x,y x∈V,y ∈ V,x =y según la carga del vértice usado como primer salto, lff∈NG(x),rf x,y ∈ Rmin x,y . A continuación se incrementa en una unidad el valor de carga menor: lf′= lf′+1 donde lf′= m´ınlf∀f∈NG(x),rf x,y ∈Rmin x,y . Este proceso se puede particularizar para aplicaciones concretas de la red de sensores, donde se conozca el tráĄco que va a generar cada nodo y las comunicaciones entre ellos, obteniendo resultados mejores haciendo ingeniería de tráĄco. 4.1.7.4 Asignación de direcciones de red El siguiente paso es la asignación de direcciones de red. Estas se van a representar en hexadecimal con cuatro cifras. A la BS siempre se le asigna la dirección 0x0001 . El robot debe tener una ya asignada desde el inicio, comprendida en el rango [0x0002,0x00ff] , que no cambia. Para los nodos sensores se establecen dos planes de numeración sencillos: 1. Cada nodo x tiene una dirección de red NAx con dos componentes del tipo 0xHHNN , donde HH es el número de saltos de la ruta mínima a la BS y NN es un número que se va asignando consecutivamente a los nodos situados a la misma distancia de la BS. Si existen más de 256 nodos con la misma distancia, se utilizan las direcciones con preĄjo HH+1 . Si el número de nodos con la misma distancia es superior a 512, se utiliza el segundo plan de numeración. Los nodos que no tengan conectividad con la BS toman una dirección consecutiva en el rango [0xfe00,0xffff] , dejando sin numerar aquellos que no quepan en ese rango. 2. En el caso de que no se pueda aplicar el plan de numeración anterior, se asigna una dirección a cada nodo que tenga conectividad con la BS, en orden de menor a mayor cercanía a esta, en el rango [0x0100,0xfdff] . La numeración para los nodos sin conectividad con la BS es similar al plan anterior. El primer plan de numeración permite visualizar rápidamente la topología y es el que se ha utilizado en los experimentos presentados en el Capítulo 5 de esta Tesis Doctoral. En ambos casos, se veriĄca que si xeyson dos nodos sensores, entonces: Si ∃x,y ∈V:minx,BS > miny,BS =⇒NAx>NAy(4.1) 122 Capítulo 4. Implementación es decir, la dirección de un nodo más cercano a la BS siempre será menor que uno más alejado (si la distancia es igual no se puede garantizar). En la Figura 4.2 se muestra una red aleatoria con 50 nodos con las direcciones asignadas como un ejemplo de aplicación del plan de numeración, donde los nodos con el mismo preĄjo de dirección HH aparecen con el mismo color. Figura 4.2 Ejemplo de asignación de direcciones de red. La BS se muestra en rojo y los nodos con el mismo preĄjo de dirección HH aparecen con el mismo color. 4.1 Decisiones de implementación 123 4.1.7.5 Definición de los parámetros de comunicación entre vecinos Si se usa el saludo avanzado en el LL, hay que deĄnir el papel que jugará cada extremo de la comunicación: cliente o servidor. Esta información estará contenida dentro de los parámetros adicionales para establecer la comunicación con cada vecino. Asumiendo que en el intercambio de claves se va a usar ECDHE, el coste computacional es similar para el cliente y el servidor si el proceso de saludo tiene éxito [ 107 ]. Pero el cliente transmite un mensaje más por término medio y el servidor está más expuesto a ataques de alto consumo. Se ha preferido intentar asignar el papel del servidor al extremo con más recursos o con menos carga de red (reenvío de paquetes). La BS y el robot siempre actuarán como servidores. Cuando ambos extremos sean nodos sensores, se ha tenido en cuenta que es más probable que sea mayor el tráĄco que pasa por un nodo más cercano a la BS que el que pasa por uno más alejado. Aprovechando (4.1) , la regla simple que se aplica en estos casos es que el nodo con dirección de red más alta sea el servidor. Independientemente del proceso de saludo, también se establece el parámetro de mantenimiento de la conexión KAI . El valor es común a todas las conexiones y es pasado al robot durante la inicialización. 4.1.7.6 Compresión de las rutas El número de rutas obtenidas en el segundo paso puede ser muy elevado, lo que afecta a la memoria necesaria para la tabla de rutas y al tamaño del mensaje de petición de conĄguración. El enrutamiento basado en rutas más cortas se ha demostrado que es incomprensible de manera teórica [ 52 ], en el sentido de que no hay ningún algoritmo que funcione de manera universal en todas las redes posibles. Aun así, en muchas redes se puede reducir el tamaño de la tabla de rutas con el procedimiento descrito a continuación. La información de las rutas se enriquece con las direcciones de red asignadas a cada vértice. El conjunto de rutas de un origen x a un destino y , Rx,y , se va a representar como un conjunto de pares métrica,NAf ordenado por métrica, donde el NAf es la dirección del vecino f∈NG(x) que es el siguiente salto de la ruta si existe y no se repite. Este conjunto de pares puede repetirse para otros destinos. Se va a denominar multiruta al conjunto de destinos que comparten el mismo conjunto de pares métrica,NAf , incluyendo ese conjunto de pares común. El procedimiento de compresión realiza las siguientes tareas: 1. Se forman el menor número de multirutas posibles. 2. Se agrupan las distintas direcciones destino de cada multiruta en subredes virtuales de mayor tamaño, siempre que no afecte a otros destinos. 3. La multiruta con mayor número de destinos se toma como ruta por defecto del nodo (con un solo destino, que es la subred 0/0). 4.1.7.7 Actualización de la CRL y rellenado del resto de campos A la información de la topología se añade la CRL actualizada y se rellenan los campos que falten. Por ejemplo, los datos de la BS que va a utilizar cada nodo sensor serán los mismos. Y para terminar se incrementa el número de versión. 124 Capítulo 4. Implementación 4.1.8 Almacenamiento de la información topológica La BS y el robot guardan las 2 versiones mínimas indicadas en la Sección 3.4: la versión inicial y la actual. El robot también mantiene una versión temporal durante el cálculo de la topología a la espera de ser conĄrmada por la BS. Ambas entidades admiten la importación y exportación de cualquiera de las versiones a Ącheros. Se utiliza Protocol Buffers para la serialización de los datos, ya sea para el almacenamiento en el sistema de Ącheros o para la transmisión usando mensajes del AL. El robot también permite exportar una versión de la información topológica abreviada, con solo datos obtenidos durante la fase de descubrimiento, que puede incluir información de nodos que no están autorizados, pero que se hayan conectado. Por último, se ha creado una utilidad complementaria, llamada NetworkDataExport , que permite la conversión de Ącheros codiĄcados en binario con Protocol Buffers a JSON y viceversa. Esta utilidad permite a los administradores visualizar y modiĄcar directamente la información almacenada en Ącheros binarios con cualquier editor de textos. 4.1.9 Parámetros de comunicación por defecto Aunque anteriormente se han nombrado parámetros que afectan a la comunicación, existen otros que merece la pena destacar: 1. El valor de KAI g es conĄgurable en el inicio. Este valor se aplica en las conexiones en el TL. En el LL se utiliza el valor comunicado por el robot o en la información de la topología. 2. El valor de KAIF es una constante de compilación. Por defecto se usa el valor 4. 3. El número de reintentos máximos de una conexión en el LL es: •0, para conexiones con el robot. •2, para conexiones creadas administrativamente. •Sin límite, para conexiones creadas según la información topológica. En el TL no se hacen reintentos automáticos, pero se informa al AL cuando una conexión se cierra para que pueda ser reiniciada si es necesario. 4. Una conexión en el LL puede ponerse en modo ignorar durante un tiempo cuando se detecten un número predeterminado de errores similares consecutivamente. En este modo todas las tramas recibidas son descartadas, por lo que se evita tener que realizar saludos que posiblemente terminen con el mismo error y así se reduce el consumo energético. Esto es conĄgurable en compilación y por defecto se ha establecido una duración de 100 segundos cuando ocurran 10 errores consecutivos en procesos de saludos relacionados con la validación del certiĄcado o de los datos intercambiados en el proceso. 5. La MTU del LL se puede conĄgurar en compilación para el caso más favorable. A partir de este valor y de manera dinámica se calcula la MTU de cada enlace. Este valor se propaga por los niveles superiores, restando el tamaño de las cabeceras de las PDU. Por ejemplo, en el TL se utiliza para determinar cuándo una SDU debe fragmentarse. 4.1 Decisiones de implementación 125 6. El límite de saltos máximos en el NL por defecto se puede conĄgurar en el inicio y en compilación. 4.1.10 Mensajes de aplicación Los mensajes de aplicación deĄnidos en la arquitectura SNSR presentan campos opcionales, campos dependientes de la implementación y la posibilidad de ser ampliados. En el mensaje de respuesta de estado no se va a incorporar información adicional a la ya indicada, ya que no es necesario para el cálculo de la topología. El mensaje de petición de conĄguración no soporta el modo de transferencia de conĄ- guración diferencial, tampoco ha sido extendido con más información y la información de encaminamiento puede incluir rutas individuales o multirutas. Se ha deĄnido un nuevo mensaje, PING, adicional a los deĄnidos en la arquitectura para las siguientes operaciones: 1. comprobar la conectividad entre dos entidades en el AL, 2. medir el tiempo de ida y vuelta (RTT, Round-Trip Time), 3. intercambiar identiĄcadores de entidad, 4. y hacer pruebas de transferencias Ąables o no y con fragmentación o no. El formato está representado en la Figura 4.3. 0 15 16 31 Tipo de PING Marca de Tiempo de Petición Marca de Tiempo de Recepción de Petición Marca de Tiempo de Respuesta                Solo si es una respuesta Longitud de Nombre Longitud de Datos Nombre (variable) ··· Datos (variable) ··· Opcionales con longitud 0               Figura 4.3 Formato de un mensaje PING. Las marcas de tiempo indican instantes de tiempo con una precisión de microsegundos. Son el número de segundos transcurridos desde el 1 de enero de 1970, codiĄcando la parte 126 Capítulo 4. Implementación entera en los primeros 32 bits y la parte fraccionaria en los restantes como un número de microsegundos. El tipo del mensaje PING es un número natural codiĄcado en binario. Existen 3 tipos: 1. Petición (tipo 0): utilizado para solicitar al otro extremo un mensaje de respuesta con el objetivo de comprobar la conectividad, medir el RTT e intercambiar identiĄcadores. Se envía una marca de tiempo indicando el instante en el que se envió el mensaje, TP. 2. Respuesta (tipo 1): respuesta a un mensaje de petición. Se copia la marca de tiempo de la petición y se añade una marca de tiempo del momento en que se recibió la petición, TRP y otra indicando cuando se envió la respuesta, TR. 3. Test de transferencia (tipo 2): permite hacer pruebas de transferencias de datos. El receptor tan solo registra su recepción y no debe responder. El mensaje PING incluye la identidad del emisor y opcionalmente unos datos adjuntos. Son cadenas de caracteres variables y sus longitudes se codiĄcan en sus respectivos campos auxiliares. Si la longitud de un campo es 0, no se envía. Cuando una entidad recibe un PING de respuesta puede calcular con precisión el RTT sin necesidad de que los relojes de ambos extremos estén sincronizados. Se anota el instante de tiempo de recepción de la respuesta, TRR . En la Figura 4.4 se muestra el intercambio de mensajes PING entre dos nodos con los instantes de tiempos marcados. Se supone que el reloj del nodo Xtiene una desviación desconocida ocon respecto al del nodo Y. Nodo X Nodo Y T0 T0+ o tiempo TPTRR TRP TR tt’ petición PING respuesta PING Figura 4.4 Envío y recepción de mensajes PING. Las marcas de tiempo del nodo X estarán afectadas por la desviación o que habría que restar. El cálculo de RTT sería: RTT =t+t′ t= (TRP −o)−TP t′=TRR −(TR−o) RTT =TRR −(TR−o)+(TRP −o)−TP RTT =TRR −TR+TRP −TP(4.2) 4.1 Decisiones de implementación 127 Por tanto, la desviación de los relojes no afecta al valor obtenido de RTT. 4.1.11 Anomalías detectadas y su procesamiento Todas las anomalías de la Tabla 3.13 se detectan. Además, se pueden introducir nuevas anomalías mediante comandos administrativos para hacer pruebas que validen la implementación. Se ha realizado un procesamiento básico de las anomalías para probar el funcionamiento descrito en la arquitectura SNSR. La BS va a ir almacenando las anomalías recibidas para que queden registradas sin hacer ningún otro procesamiento por el momento, aunque permite acceder a ellas desde otros procesos para su posterior análisis. No se han establecido límites en el número de anomalías a almacenar y por tanto no se van a agrupar (el campo REPEATED no se usa) y no se eliminan anomalías que no hayan sido asentidas de manera automática. Se pueden borrar anomalías mediante un comando administrativo. El tamaño de la lista de anomalías enviada en una notiĄcación de anomalías se limita para evitar que el mensaje se fragmente. El robot transmite todas las anomalías que tiene almacenada a la BS cada vez que esta se conecta con él. Continúa transmitiendo las anomalías en bloques de acuerdo al límite antes comentado mientras que la BS las siga asintiendo. Si algún nodo le envía anomalías, envía el correspondiente asentimiento e inmediatamente las retransmite a la BS. Los nodos comienzan el envío automático de anomalías cuando establecen comunicación con la BS. También se puede forzar administrativamente que el robot o los nodos intenten enviar sus anomalías inmediatamente. 4.1.12 Módulo de localización y movimiento del robot En esta Tesis Doctoral no se va a desarrollar un módulo real de localización y movimiento para el robot. El software implementado está preparado para colaborar con uno existente. Se ha desarrollado un componente que simula este módulo en los escenarios simulados. Este módulo debe tener las siguientes funcionalidades: •Obtención de la posición actual. •Localización de fuentes de emisión a su alcance. •Cálculo de la trayectoria a seguir por el robot en la fase de descubrimiento yconĄ- guración. •Movimiento del robot siguiendo trayectorias deĄnidas. La comunicación de este módulo con la implementación del robot realizada en esta Tesis Doctoral se realiza en ambas direcciones: • El módulo debe ir almacenando la dirección MAC junto con la posición de cada emisor. Esta información debe estar disponible para el robot antes de iniciar el cálculo de la información de topología. Para ello, se actualiza la versión inicial de la información de topología por vía administrativa. • La aplicación de gestión del robot permite la consulta, también por vía administrativa, del estado actual del robot y las entidades con las que está pendiente de establecer 230 Capítulo 5. Experimentación y evaluación Figura 5.23 Experimentos con robot aéreo: datos transmitidos y recibidos en LL. Figura 5.24 Experimentos con robot aéreo: tiempos requeridos para conĄguración. para el procesamiento. El robot en la cementera era un hexarotor de diseño personalizado con un 3D-LiDAR para la auto-localización y un ordenador Intel NUC y se muestra en la Figura 5.25. Los datos de la topología y la información topológica en las fases inicial, descubrimiento yestablecimiento de la topología se proporciona en [42]. 5.9 Experimentos con ataques 231 Figura 5.25 Imagen de robot aéreo sobrevolando la cementera. 5.9 Experimentos con ataques Como quedó reĆejado en la Sección 5.2, y resumido en la Tabla 5.2, algunos ataques no han sido contemplados porque no son competencia de la arquitectura de seguridad sino de la pila de red empleada. Muchos otros ataques no son posibles cuando se usan protocolos seguros como DTLS, siempre que se mantengan actualizados, la implementación sea correcta y la autenticación basada en certiĄcados sea válida por estar seguras las claves de la CA. Gran parte de la fortaleza reside en la separación clara de funcionalidades y la poca capacidad de inĆuir unos nodos sobre otros. Durante el desarrollo de la implementación se han hecho pruebas veriĄcando que esta es Ąel a la arquitectura SNSR, las entidades ignoran todos los mensajes no válidos y se han puesto límites máximos a todo aquello susceptible de ser abusado. También se ha monitorizado el tráĄco generado comprobando el funcionamiento de los distintos protocolos y que la información transmitida en claro era la esperada. Para evitar posibles sesgos en el análisis de seguridad también han sido llevado a cabo análisis alternativos por otras personas. Esto se conoce en seguridad informática como equipo rojo (red team). El red team se pone en el lugar de un atacante real y prueba la seguridad del sistema. Esto se describe en la Sección 5.9.1. De los ataques posibles, en esta Tesis Doctoral se han elegido los 2 siguientes por considerar que sus resultados son menos evidentes: • Suplantación de robot, donde uno o varios agentes maliciosos envían balizas con formato correcto, pero con información falsa, para forzar a los nodos sensores a intentar la conexión con ellos. Se quiere evaluar el comportamiento al usar distintos métodos de detección de baliza, parámetros de comunicación y comportamientos del agente malicioso. La BS es más inmune a estos ataques debido a sus recursos y a que podría conocer en un momento dado los robots reales activos con lo que 232 Capítulo 5. Experimentación y evaluación puede descartar balizas falsas. En función del comportamiento del agente malicioso, este ataque se puede asimilar a los ataques: 1. Service request power attack, cuando se obliga al nodo a realizar el proceso de saludo avanzado aunque este falle. 2. Rushing attack, si se consigue que las balizas del robot real sean descartadas. 3. Hello Ćooding, si se hace creer a los nodos que el robot es alcanzable sin serlo. 4. Byzantine attack, si varios agentes simulan distintos robots simultáneamente. Los experimentos donde se ha ejecutado este ataque se describen en la Sección 5.9.2. • Node destruction y en general cualquier fallo fatal de un nodo que provoque su desconexión de la red, ya sea por causas malintencionadas (destrucción, robo o jamming) o no (falta de energía, sustitución o desplazamiento temporal). En [ 25 ] se hacen pruebas similares para INSENS. Se cuenta el número de nodos que dejan de comunicarse con la BS según el número de nodos con fallos como medida de robustez de la red. Se tienen en cuenta los nodos que no pueden comunicarse por quedar aislados de la red (no hay alcance vía radio) y aquellos que no pueden debido a problemas de enrutamiento (se generan bucles) que se corregirían con una nueva conĄguración. Aunque el enrutamiento no está especiĄcado por la arquitectura SNSR, se quiere comprobar si el usado en la implementación es lo suĄcientemente robusto para permitir reducir la urgencia con la que el robot tiene que realizar vuelos para reconĄgurar la red. Los experimentos con este ataque se describen en la Sección 5.9.3. 5.9.1 Ataques de Red Team El Red Team debe estar formado por personas ajenas a esta Tesis Doctoral. Alejandro Rosa Neupavert, estudiante del Máster en Seguridad de la Información y las Comunicaciones de la Universidad de Sevilla en el curso 2017/2018, se encargó de hacer estos ataques. Los resultados fueron publicados en su Trabajo Fin de Máster, que tituló ŞPentesting a red de sensores securizada por robot móvilŤ y fue tutorado por el autor de esta Tesis Doctoral. Los ataques se hicieron sobre escenarios virtualizados. Para ello se proporcionó al Red Team una máquina virtual de Ubuntu 16.04 con el compositor launcher, el programa Node y 6 escenarios ya preparados. El programa Node era la versión de la implementación realizada en la fecha de ejecución de las pruebas. Solo disponía de detección básica de balizas, pero el resto de las funcionalidades estaban implementadas. Los 6 escenarios proporcionados tienen todos la misma topología que la número 1 de la Figura 5.18. La única diferencia es que cada uno tiene un modo de seguridad diferente. En estos escenarios las entidades estáticas se dividen en 3 zonas de difusión: Z1: N1, N2, N3 y BS. Z2: N4, N5, N6, N7, N8 y N9. Z3: N10, N11 y N12. 5.9 Experimentos con ataques 233 Tanto en la fase de descubrimiento como de conĄguración el robot sigue una trayectoria por las zonas (Z) en el orden Z1 → Z2 → Z3 → Z2 → Z1. Todo esto es modiĄcable y se enseñó al estudiante cómo usarlo. Además, se proporcionó documentación sobre la arquitectura y los protocolos usados. No se proporcionó el código fuente de la implementación, pero sí ejemplos básicos para generar y decodiĄcar mensajes. A continuación, se describen brevemente los ataques que se realizaron y sus resultados: • Ataque DoS a los nodos: envío de balizas falsas a la mayor tasa de transmisión posible para evitar que los nodos se conecten al robot real. Se comprobó, como se indicó en la Sección 3.6.1, que se impedía la detección de balizas del robot real. Los nodos descartaban las balizas reales mientras intentan conectarse al robot Ącticio. El robot real solo transmite entre 1 y 2 veces por segundo. Las balizas Ącticias se transmiten a una frecuencia muy superior, por lo que la probabilidad de que la primera baliza vista por un nodo sea falsa es muy elevada. Ataques parecidos aunque transmitiendo balizas falsas a la misma frecuencia que el robot real se verán en la Sección 5.9.2. El ataque realizado se puede clasiĄcar como service request power attack ohello Ćooding, se detecta fácilmente y se supone que no puede durar indeĄnidamente. Cuando se interrumpía la emisión de balizas falsas el sistema recuperaba la normalidad. Posteriormente, ya fuera del ataque de Red Team se repitió este ataque con el método de detección de baliza avanzada comprobando que ya no era efectivo. • Ataque DoS al robot: peticiones de conexión con el robot a la mayor tasa de envío posible. Este ataque provoca que se utilicen el número máximo de enlaces permitidos por el robot, impidiendo procesar otras peticiones legítimas. Este ataque puede catalogarse como del tipo LL exhaustion. El robot continúa funcionando correctamente con otras conexiones previamente establecidas e inmediatamente con el resto cuando se termina el ataque. • Ataque DoS a la BS: tras la conĄguración correcta de la red, se envían mensajes a la BS para saturarla. Todos los mensajes son ignorados, por lo que su único efecto es ocupar el canal radio, como sería en un ataque de tipo unfairness. • Intrusión con nodo con certificado duplicado: se añade un nuevo nodo al escenario usando el mismo certiĄcado de otro nodo existente, como si se hubieran robado sus datos privados. En la versión de la implementación proporcionada, durante el establecimiento de la topología, se admitía en la red al primer nodo duplicado que contactaba con el robot sin notiĄcar esta anomalía. Sin embargo, una vez detectado el posible duplicado de los datos de seguridad, no se puede conĄar en ninguno de los nodos. Esto ha sido modiĄcado en la versión actual. Ahora se crea una anomalía para advertir de esto y revocar el certiĄcado y se ignoran ambos nodos ante la imposibilidad de conĄar en ellos. • Intrusión con robot con certificado duplicado: envío de balizas desde un robot malicioso con una copia de certiĄcados válidos una vez que el robot auténtico ya se ha conectado con los nodos. Era imposible que los nodos se intentaran conectar a él, ya que los nodos ignoran cualquier baliza una vez que están conectados al robot 234 Capítulo 5. Experimentación y evaluación real. Si los nodos no hubieran estado conectados ya, este ataque hubiera funcionado al no poderse distinguir que el robot era malicioso. Por este motivo es importante revocar rápidamente los certiĄcados de los robots capturados. • Análisis de tráfico: se captura todo el tráĄco transmitido en la red para analizar su funcionamiento y la información transportada. En un escenario real este ataque requeriría la colocación de varias estaciones de escucha para cubrir todo el escenario, pero en un escenario virtualizado se realiza simplemente capturando el tráĄco local. Consigue detectar los nodos que tienen más tráĄco, aunque no el contenido de los paquetes. • Destrucción del nodo con más tránsito: se elimina el nodo que reenvía más paquetes una vez que el sistema está funcionando, pero se detecta la anomalía y los nodos siguen funcionando con normalidad porque hay rutas alternativas. • Envío de información falsa desde una estación externa a la topología: se envían mensajes aleatorios o duplicados desde otras estaciones ajenas a la red. Todos son ignorados. Todos los ataques anteriores ya habían sido contemplados a nivel interno y los resultados eran los esperados. Sin embargo, el Red Team sirvió para recapacitar sobre el tratamiento que se estaba dando a los nodos clonados como se ha comentado antes. Además, muchos ataques se realizaron con herramientas diferentes a las que se habían usado, por lo que sirvió como validación externa adicional de las capacidades de la arquitectura SNSR. 5.9.2 Ataques de suplantación de robot y comparativa de métodos de detección de baliza Se han realizado experimentos donde se han introducido robots maliciosos que transmiten balizas para que los nodos sensores se conecten a ellos. No se contemplan los modos de seguridad en el LL donde no se realiza la autenticación del robot ni tampoco se contempla que los nodos sensores puedan estar conectados simultáneamente a más de un robot. Lo primero facilitaría el ataque, lo segundo limitaría los efectos del ataque como se describe más adelante. Se supone que los atacantes no tienen en su poder las claves privadas de robots válidos. Si lo anterior ocurriera, se deben revocar sus certiĄcados y actualizar la CRL. En caso contrario, los nodos sensores no tienen ningún mecanismo de defensa para evitar la conexión con los atacantes. Para ello, SNSR dispone del procedimiento de actualización urgente de la CRL descrito en la Sección 3.9.2. A diferencia de las pruebas realizadas en el Red Team, los atacantes van a transmitir balizas con la misma cadencia que utiliza el robot real. Es decir BI_MAX será 1s, usando una componente aleatoria sin ningún control adicional sobre la emisión de balizas. Esto evita los casos límites indicados en la Sección 3.6.1 para el método básico de detección. La única ventaja permitida en este sentido será la de comenzar a emitir balizas antes de que lo haga el robot real. Un robot malicioso con las anteriores condiciones no va a poder conectarse a ninguna otra entidad, y el único comportamiento propio de un robot que va a poder suplantar es el envío de balizas y la realización del saludo de la conexión. Es sencillo emitir balizas con formato válido que no son descartadas, ya que estás no incluyen ningún mecanismo de 5.9 Experimentos con ataques 235 seguridad más allá de la comprobación de que tienen un formato correcto y los valores de sus campos son aceptables. Los objetivos principales del atacante van a ser: 1. Impedir que un nodo se conecte a un robot real mientras intenta conectarse a uno falso, teniendo en cuenta que los nodos sensores permiten solo una conexión a un robot (rushing attack) 2. Forzar a los nodos a realizar operaciones complejas (service request power attack) o transmisiones inútiles (hello Ćooding), provocando el consumo de energía. Durante los experimentos se han utilizado 1, 2 o 3 robots maliciosos con 3 comportamientos diferentes, que serán identiĄcados como IG , RK y RD respectivamente, y que se describen a continuación: IG Envío de balizas válidas e iguales para cada robot, pero ignorando peticiones de conexión. También sería equivalente enviar balizas usando direcciones de origen falsas no alcanzables, incluyendo balizas duplicadas del robot real. RK Envío de balizas válidas e iguales para cada robot, pero aceptando las peticiones. En las balizas se utiliza un número de serie falso, por lo que se fuerza al nodo a realizar el saludo avanzado. El certiĄcado real del robot malicioso está revocado por lo que al Ąnal falla el saludo. RD Envío de balizas válidas aleatorias aceptando peticiones. Es similar al caso anterior, pero para el nodo cada baliza parece provenir de un robot diferente. Los valores de los campos son aleatorios para que los nodos no puedan descartar balizas previamente vistas. El saludo falla al no coincidir la identiĄcación del certiĄcado con la que aparece en la baliza. Además, se ha realizado una primera ejecución de los experimentos sin ataques para poder hacer comparaciones posteriores. Durante el saludo avanzado, el robot actúa como servidor y, en DTLS [ 125 ], su certiĄcado será enviado en primer lugar. En la implementación utilizada ese certiĄcado es validado por el cliente usando diferentes criterios. Entre ellos están, en orden de ejecución, a) comprobar que el CN del certiĄcado es el esperado; b) veriĄcar que está Ąrmado por la CA y la Ąrma es correcta; y c) comprobar que el número de serie no ha sido revocado. Lo anterior implica que la duración del saludo durante un ataque RD será menor que en RK , que a su vez será bastante inferior que en IG . En coste computacional, los efectos de RK son los más costosos, seguidos de los de RD y en último lugar los de IG. Se quiere evaluar las distintas técnicas descritas en la Sección 3.6.1 para reducir el impacto de estos ataques. Estas técnicas eran: •Detección de baliza básica o avanzada (ambas excluyentes). •Establecer un tiempo máximo de duración del saludo con robots. •Establecer un tiempo mínimo de duración del saludo con robots. Así que los anteriores ataques se han realizado sobre 4 conĄguraciones diferentes de los nodos. El identiĄcador dado a cada una de ellas y sus detalles se muestran a continuación: 236 Capítulo 5. Experimentación y evaluación M2NF ConĄguración M2 (descrita en la Tabla 5.1) con MS_FAST_HS desactivado (sin reducción en reintentos y temporizadores para conexiones con el robot). M2 ConĄguración M2 con MS_FAST_HS activado (con reducción en reintentos y temporizadores para conexiones con el robot). M3NM ConĄguración M3 (descrita en la Tabla 5.1) con MS_FAST_HS activado. M3M1 ConĄguración M3 con MS_FAST_HS activado y un tiempo mínimo de saludo de 1s . Las otras conĄguraciones no imponen un tiempo mínimo de saludo. La activación de MS_FAST_HS inĆuye en el tiempo máximo de duración del saludo. La implementación de DTLS en la biblioteca wolfssl espera hasta 127 s en cada intento de saludo si el otro extremo no responde: hace 6 reintentos, duplicando el tiempo de espera entre cada reintento partiendo de 1s ( 1+ 2+4+8 +16+ 32+64 = 127 ). Por las características de las redes usadas y dado que el RTT visto no suele superar 1s , el valor anterior es excesivo. Por ese motivo, en la implementación se ha modiĄcado el tiempo de espera entre reintentos, a un valor aleatorio entre 1 y 2 s dado por la función random(1,2) . La componente aleatoria impide que sea predecible el siguiente intento de conexión. Con MS_FAST_HS el tiempo máximo de duración del saludo con un robot se reduce a un valor medio de 1,5s. Si no está activado, el tiempo máximo tiene un valor medio de 10,5 s. En total se han probado 40 escenarios diferentes, a los que se les ha dado un nombre simbólico en minúsculas formado por 2 caracteres iniciales que indican el número de robots, seguido por 2 caracteres que indican el tipo de ataque y el resto de los caracteres que indican la conĄguración de los nodos. Los escenarios se muestran en la Tabla 5.6. Tabla 5.6 Escenarios usados en los experimentos con ataques de suplantación de robot. Ataque M2NF M2 M3NM M3M1 Sin ataque r1nom2nf r1nom2 r1nom3nm r1nom3m1 IG, 1 atacante r2igm2nf r2igm2 r2igm3nm r2igm3m1 IG, 2 atacantes r3igm2nf r3igm2 r3igm3nm r3igm3m1 IG, 3 atacantes r4igm2nf r4igm2 r4igm3nm r4igm3m1 RK, 1 atacante r2rkm2nf r2rkm2 r2rkm3nm r2rkm3m1 RK, 2 atacantes r3rkm3nf r3rkm2 r3rkm3nm r3rkm3m1 RK, 3 atacantes r4rkm3nf r4rkm2 r4rkm3nm r4rkm3m1 RD, 1 atacante r2rdm2nf r2rdm2 r2rdm3nm r2rdm3m1 RD, 2 atacantes r3rdm2nf r3rdm2 r3rdm3nm r3rdm3m1 RD, 3 atacantes r4rdm2nf r4rdm2 r4rdm3nm r4rdm3m1 5.9 Experimentos con ataques 237 Los escenarios están formados por 100 nodos al alcance radio de los robots que tratarán de conectarse simultáneamente. Para estos experimentos no es necesario incluir una BS. Se realizan 100 repeticiones de cada escenario, por lo que en total se analizarán 10.000 conexiones para cada escenario. Se mantienen el resto de los parámetros de conĄguración usados en otros escenarios. Los robots maliciosos comienzan a transmitir balizas desde el inicio y el robot verdadero cuando ha transcurrido 1 s. Se hacen 2 mediciones en cada nodo para determinar el efecto de los ataques: 1. Tiempo necesario desde que un robot verdadero comienza a transmitir balizas hasta que el nodo se conecta a él. Esto mostrará cuánto tiempo han impedido la conexión los atacantes. 2. Número de intentos de conexión que ha hecho el nodo hasta conectarse al robot verdadero. Esto es proporcional al número de operaciones adicionales que los atacantes han forzado a realizar a los nodos. En los siguientes apartados se muestran los datos obtenidos en condiciones normales y según el ataque realizado. Hay que resaltar que el 100% de los nodos se han podido conectar al robot válido en todos los experimentos. En las Ąguras que se muestran en esta sección se utilizarán tonos amarillos para los escenarios M2NF , azules para los M2 , rojos para los M3NM y verdes para los M3M1 en ese orden de presentación de izquierda a derecha. 5.9.2.1 Conexión al robot sin ataques Los valores medios de los resultados obtenidos en las 100 repeticiones de cada escenario se muestran en la Figura 5.26. Figura 5.26 Tiempo e intentos medios necesarios para conectar al robot sin ataques. Se observa que los tiempos necesarios son superiores a los mostrados en la Tabla 5.4. Esto es debido a la congestión inicial producida al intentar conectarse los 100 nodos casi simultáneamente al robot. A pesar de la espera de contención aleatoria realizada con TC_MAX de 50ms por los nodos, el número de nodos es muy elevado. Esto implica que hay que tener en cuenta la densidad de nodos a la hora de establecer la velocidad de vuelo del robot adecuada. 238 Capítulo 5. Experimentación y evaluación Sin ataques, la conĄguración M2NF es la que presenta mejores resultados aun siendo la más sencilla. Hay que recordar que en este caso los intentos de conexión incluyen la retransmisión de mensajes, por lo que el menor número de intentos no implica la transmisión de menos tramas. La activación de MS_FAST_HS provoca un aumento en el número de intentos de conexión debido a que en situaciones de congestión se descartan algunos que hubieran funcionado con un poco más de espera. Pero hay que decir que esto no implica un aumento signiĄcativo en el número de tramas transmitidas, porque en M2NF también se harán reintentos de envío dentro del mismo intento de conexión. El tiempo también se ve incrementado debido a que cada intento va a requerir esperar la recepción de una nueva baliza y un nuevo tiempo de contención. Usar la detección de baliza básica o avanzada da resultados prácticamente similares. Pero el establecer un tiempo mínimo de saludo hace que el tiempo necesario aumente. 5.9.2.2 Comportamiento ante el ataque IG Los valores medios de los resultados obtenidos se muestran en la Figura 5.27. Figura 5.27 Tiempo e intentos medios necesarios para conectar al robot con ataque IG. En este ataque, el valor del tiempo necesario para la conexión es el más importante, ya que el objetivo del atacante es evitar en lo posible la conexión con el robot real y, por tanto, que este detecte nodos sensores. Los intentos de conexión implican solo la transmisión de tramas adicionales y en general no son elevados. En todas las conĄguraciones, el funcionamiento empeora respecto a los datos sin ataques a medida que aumenta el número de atacantes, a excepción de cuando hay un único atacante con detección avanzada. La explicación es que en estos casos la conexiones con el robot real se hace de manera más escalonada. Esto hace que el robot esté menos sobrecargado y responda más rápido por lo que los nodos realizan menos intentos. Se observa un gran aumento en el tiempo necesario en M2NF . En M2 , se reduce mucho el tiempo perdido cuando MS_FAST_HS está activo, aunque con un ligero aumento de intentos. 5.9 Experimentos con ataques 239 El ganador claro en este ataque es el uso de la detección avanzada, en las conĄguraciones M3NM y M3M1 . El próximo candidato se elige de las balizas recibidas durante el intento de conexión descartando la actual, aumentando la probabilidad de elegir la del robot real. El próximo intento se realiza sin esperar a recibir una nueva baliza. En ambas conĄguraciones el resultado es prácticamente el mismo, ya que en este caso no es necesario aplicar el tiempo mínimo de saludo al ser el tiempo de espera de respuesta mayor. 5.9.2.3 Comportamiento ante el ataque RK Los valores medios de los resultados obtenidos se muestran en la Figura 5.28. Figura 5.28 Tiempo e intentos medios necesarios para conectar al robot con ataque RK. En comparación con el ataque IG y cuando no hay ataques, los tiempos de conexión son inferiores, ya que el proceso de saludo dura menos. En cuanto a los intentos, son similares al ataque IG, a excepción de la conĄguración M3NM. La conĄguración M3NM presenta una disminución en el tiempo necesario conforme aumentan los atacantes, debido a la menor sobrecarga instantánea que sufre el robot correcto. Sin embargo, aumentan rápidamente el número de intentos. Establecer un tiempo mínimo al saludo ahora sí tiene efectos observables. En M3M1 se reducen el número de intentos comparado con M3NM . De hecho, es la conĄguración que necesita menos intentos para hacer la conexión y, por tanto, la que sufre menor coste computacional. La contrapartida está en un ligero aumento en el tiempo necesario. 5.9.2.4 Comportamiento ante el ataque RD Los valores medios de los resultados obtenidos se muestran en la Figura 5.29. Prácticamente, los resultados son similares al ataque RK . Sin embargo, aquí los intentos implican un menor coste computacional que en el caso anterior, debido al proceso de veriĄcación realizado en el saludo, que simplemente detecta que el CN del certiĄcado enviado por el atacante no coincide con el que aparece en las balizas falsas. 6 Conclusiones La verdadera ciencia enseña, sobre todo, a dudar y a ser ignorante. Miguel de Unamuno En este capítulo, primero, en la Sección 6.1, se presentan las conclusiones Ąnales de esta Tesis Doctoral y posteriormente, en la Sección 6.2, se proponen líneas futuras de trabajo que permiten extender SNSR y explorar otras alternativas. 6.1 Conclusiones Esta Tesis Doctoral propone SNSR, una arquitectura de seguridad novedosa, Ćexible y abierta que aprovecha la cooperación de robots con las WSN para lograr niveles de seguridad altos sin necesidad de usar mecanismos complejos. Su operación se estructura en fases organizadas usando un enfoque de retroalimentación, que permite repetir las fases para adaptarse a cambios en la red, ataques y corregir errores. Para realizar este diseño ha sido necesario un análisis minucioso del estado actual de la seguridad en las WSN y de las tecnologías existentes. Por una parte, en muchas aplicaciones de monitorización basadas en WSN, sobre todo las usadas en entornos industriales o grandes infraestructuras civiles, la seguridad es un problema crítico. La gran superĄcie de ataque que presentan las WSN ha motivado el desarrollo de técnicas y protocolos para prevenir, detectar y mitigar los posibles ataques. Muchas de ellas se centran en ataques especíĄcos, de tal manera que lograr una WSN segura requeriría la combinación de muchas de estas técnicas. Además, pueden ser incompatibles entre sí o suponer un consumo de recursos excesivo. Por otra parte, los robots aéreos se están usando en muchas tareas de monitorización, como inspección, detección de fallos o mantenimiento predictivo, y esta tendencia parece ir en aumento. Sin embargo, la cooperación entre WSN y robots para mejorar la seguridad de las WSN ha sido poco investigada. 247 248 Capítulo 6. Conclusiones SNSR se beneĄcia de la capacidad de actuación del robot, que localiza y autentica nodos, interactúa con ellos directamente sin intermediarios para enviarles conĄguraciones y recibir informes de estado y anomalías, y puede utilizarse para obtener observaciones directas que conĄrmen o descarten anomalías detectadas. Estos usos del robot brindan a SNSR capacidades mejoradas de detección y mitigación de ataques, y mejoran la prevención al reemplazar tareas que en las arquitecturas tradicionales son propensas a ataques o requieren información preestablecida. Los nodos sensores son el elemento más débil de la WSN y, por tanto, más fácil de atacar. La arquitectura SNSR reduce la dependencia de unos nodos respecto a otros. Si un atacante se hace con el control de un nodo, el efecto es mucho más limitado que en otras WSN. Un nodo malicioso no puede alterar el funcionamiento de la red, como mucho puede provocar una degradación del funcionamiento a nivel local. La arquitectura SNSR es lo suĄcientemente genérica y Ćexible para adaptarse a la infraestructura WSN concreta de cada caso de monitorización. La gran cantidad de opciones disponibles en SNSR permite su adaptación a las necesidades de distintas aplicaciones, por ejemplo, seleccionando el nivel de seguridad deseado. Incluso con requisitos bajos de seguridad, SNSR permite mejorar la eĄciencia de las redes habituales al reducir la carga de trabajo de los nodos sensores. Esta Tesis Doctoral se ha centrado en el caso de una WSN con una BS y un robot. Sin embargo, los protocolos y muchas de las operaciones deĄnidas se podrían utilizar en redes con múltiples BS o robots, sin modiĄcación. Para hacer realidad SNSR, se tomó la decisión de implementar un nuevo NOS, diferente a los empleados actualmente de tal manera que permita probar toda la Ćexibilidad disponible. Este NOS es independiente del uso de SNSR, pero se ha diseñado teniendo en cuenta exclusivamente sus requisitos. Es básico, pero fácilmente ampliable. Además, se basa en el funcionamiento de WSN ya existentes y usa técnicas empleadas por otros protocolos, pero la implementación es completamente nueva. Destacan la posibilidad de usarlo tanto en equipos reales como virtualizados, el uso reducido de recursos conforme a las limitaciones de los nodos sensores y la posibilidad de adaptarlo a otros sistemas operativos gracias al uso del LLAL. La adaptación de SNSR a este nuevo NOS ha requerido la toma de decisiones de implementación y resolver problemas como el cálculo de topologías, detalle y codiĄcación de los mensajes del protocolo, uso de criptografía ECC, empleo del protocolo DTLS, trayectorias a realizar por el robot, etc. de manera también Ćexible para poder hacer experimentos posteriores con diferentes conĄguraciones, incluyendo versiones maliciosas de las entidades. Se ha presentado un análisis de seguridad cualitativo que muestra cómo la reducción de la superĄcie de ataque de la WSN y los mecanismos empleados hacen que muchos ataques sean imposibles de realizarse en SNSR. Se ha hecho una comparación con la seguridad que tienen ZSE e INSENS, comprobándose que SNSR es más segura. Para experimentar con la implementación de SNSR se ha creado una plataforma de pruebas nueva tanto en escenarios reales como virtualizados. Se ha creado una PKI para generar claves y certiĄcados, un sistema de gestión remota de dispositivos reales para facilitar las pruebas con distintas conĄguraciones y dos compositores/orquestadores de escenarios simulados/virtualizados, que hemos denominado lanzadores con dos formas diferentes de simular los canales de comunicación. En uno de ellos, incluso se ha creado un módulo de movimiento simulado que es capaz de calcular las trayectorias del robot. 6.2 Líneas futuras de trabajo 249 Muchos de los componentes desarrollados en esta Tesis Doctoral pueden ser reutilizados en otras investigaciones sobre las WSN, aunque no estén relacionadas con la seguridad o con robots. Por ejemplo, el NOS es genérico y permite crear nuevas WSN, el lanzador permite probar código real en entornos simulados sin requerir usar robots, el sistema de gestión remota se puede usar en pruebas de otros trabajos que requieran usar muchos dispositivos reales, y el protocolo de transporte se puede utilizar incluso en otras redes que no sean WSN como las convencionales. Para validar la implementación y caracterizar el comportamiento de SNSR se han realizado miles de experimentos con distintos escenarios y conĄguraciones: experimentos virtualizados; experimentos de campo reales con robots terrestres y aéreos; con 5 conĄguraciones especíĄcas; con topologías diferentes y aleatorias y en redes de distinto tamaño (hasta 500 nodos); con distintas medidas de seguridad; con distintos métodos de detección de baliza; y en condiciones normales, con ataques realizados por terceras personas y con ataques propios de destrucción de nodos y de suplantación de robots. Se extraen las siguientes conclusiones de los resultados obtenidos: • La implementación de SNSR es estable, no se producen errores en condiciones normales y se ajusta a lo especiĄcado en la arquitectura. La iteración de las fases, la nueva torre de protocolos y las medidas de seguridad funcionan correctamente y dan lugar a redes de sensores totalmente operativas y robustas antes ataques y fallos. El funcionamiento una vez que la red está conĄgurada es similar al de otras WSN, pero los nodos necesitan realizar menos tareas por lo que se reduce su consumo. • El tiempo necesario para conĄgurar un nodo es reducido y el tráĄco generado es bajo. • Añadir criptografía asimétrica como medida de seguridad aumenta el coste del establecimiento de la red, pero este coste se amortiza con el tiempo durante la operativa normal de la red. • Los resultados muestran una inĆuencia destacable de la trayectoria del robot durante la conĄguración en los periodos transitorios de inestabilidad. • Los ataques de suplantación de robot son detectados con facilidad. El uso del método de detección de baliza avanzado limita signiĄcativamente sus efectos temporales. • El sistema es robusto frente ataques de destrucción de nodos, a pesar de no usar protocolos dinámicos, y puede recuperarse de los daños sin necesidad de que los nodos tengan que actuar. 6.2 Líneas futuras de trabajo El uso de robots para mejorar la seguridad es un tema poco investigado como demuestra el pequeño número de trabajos previos. Esta Tesis Doctoral presenta un trabajo innovador que puede ser la base de futuras investigaciones. La arquitectura SNSR es muy Ćexible y permite explorar otras posibilidades diferentes que no se han implementado. A continuación, se describen varias líneas futuras de trabajo. 250 Capítulo 6. Conclusiones Optimización de trayectorias del robot En los experimentos se ha mostrado que el orden en el que se conĄguran los nodos inĆuye en el tiempo de conĄguración y el periodo transitorio de inestabilidad. Si los nodos se conĄguran por orden de proximidad a la BS, según el orden BFS, se reducen los tiempos y el número de paquetes enviados. En la Tesis Doctoral se ha desarrollado una trayectoria eĄcaz pero no eĄciente en el anterior sentido. Una posible mejora sería desarrollar métodos automáticos que optimicen la trayectoria de conĄguración según el anterior criterio (u otros) y compare los resultados obtenidos. Arquitectura con N robots y M estaciones bases SNSR se puede generalizar para el caso de N robots y M estaciones bases, que implica una mayor coordinación y sincronización entre estos elementos, permitiendo considerar redes más extensas. Si existen varios robots simultáneamente, habría que encontrar la mejor manera de dividir las tareas entre ellos para su realización en paralelo, calculando sus trayectorias para que no colisionen, o de seleccionar el robot que pueda desempeñarlas en menos tiempo. La información recogida por los robots debería ser fusionada para obtener un mapa completo de la red y sincronizar la información de conĄguración entre todos los robots y las BS. Los nodos sensores podrían tener asignadas una o varias BS. La implementación actual ya permite esto, aunque solo mantiene conexión con una de ellas y solo cambia de BS si falla la conexión. Para completarlo, habría que establecer una política de asignación de BS y de envío de los datos de los sensores (solo a una BS, a varias simultáneamente, aleatoriamente...). Actualización remota de software firmado digitalmente Actualmente, la instalación de software nuevo en los dispositivos sensores se realiza con el agente del sistema de gestión remota (ver Sección 4.6), que se encuentra instalado en los dispositivos. Este agente es un programa independiente al que realiza las funciones de nodo sensor. Su uso se limita a un entorno de pruebas y no está preparado para entornos de producción. Usar actualizaciones OTA sería otra posible solución, como se hace en ZigBee [ 172 ]. En este caso, sería la aplicación de gestión de los nodos la que realizaría la actualización y reiniciaría el dispositivo si hiciera falta. Para ello habría que deĄnir un nuevo mensaje de gestión, en el que se enviaría el nuevo software. Dado que una actualización permite modiĄcar el funcionamiento del software y los parámetros de inicialización que normalmente no pueden ser modiĄcados mediante mensajes de conĄguración (su identidad, sus claves y certiĄcados, certiĄcado de la CA...), la seguridad requerida debe ser alta. Así que la opción más segura sería Ąrmar digitalmente estas actualizaciones para que no puedan alterarse. Podría utilizarse la Ąrma digital de la BS u otra entidad de mayor conĄanza. Los nodos validarían esta Ąrma antes de aplicar la actualización. Incorporar un IDS y otras contramedidas específicas para determinados ataques En el análisis cualitativo de seguridad (ver Sección 5.2) se encontraron algunos ataques que, aunque con efectos limitados, pueden seguir produciéndose. A SNSR se le podrían añadir algunas contramedidas especíĄcas para determinados ataques. Por ejemplo, integrar otros 6.2 Líneas futuras de trabajo 251 métodos para detectar selective forwarding [ 54 ], diĄcultar el análisis de tráĄco usando caminos alternativos aleatorios, etc. Las anomalías recolectadas por la BS también pueden ser analizadas por un IDS como los comentados en la Sección 2.3.2. La arquitectura SNSR ya proporciona los mecanismos para recolectar anomalías y ser procesadas de manera centralizada, y poder realizar acciones correctivas. Dada la diversidad de técnicas existentes en el campo de los IDS, su utilización requiere un extenso estudio para evaluar cuál es la más apropiada. También podría ampliarse SNSR con un sistema que facilite la notiĄcación de los ataques detectados o eventos sospechosos a operadores, mediante interfaces de usuario existentes o nuevas, y la decisión de la acción correctiva a realizar, que podría ser automática en algunos casos. Considerar el caso de robots maliciosos con certificados válidos En SNSR se ha supuesto que la captura de un robot sería detectada rápidamente y su certiĄcado sería revocado para evitar que se pueda utilizar. Todas las entidades usan una CRL que normalmente contiene números de serie de certiĄcados revocados. No es necesario almacenar en los nodos los números de secuencia revocados de la BS u otros nodos porque la comunicación con estos se puede bloquear simplemente no incluyéndolos en la conĄguración, por lo que normalmente su CRL contendrá pocas entradas y solo de certiĄcados de robots. El caso de que el robot sea capturado, modiĄcado maliciosamente y devuelto sin que sea detectado no está contemplado. También se podrían obtener sus claves y reutilizarlas en otros dispositivos que simulen ser robots. Un robot malicioso con un certiĄcado válido puede modiĄcar la conĄguración y la CRL de los nodos, que actualmente se aceptan sin comprobaciones adicionales porque confían en robots con certiĄcados válidos, y generar anomalías o información de descubrimiento falsas. Esto podría afectar al funcionamiento de la red, pero nunca permitiría introducir nuevas entidades sin certiĄcados válidos en la red. Si se detecta, la BS (si aún tiene conexión con los nodos) y cualquier otro robot podría volver a restablecer la conĄguración y revocar el certiĄcado del robot malicioso. El robot malicioso para tratar de retrasar su revocación solo puede alterar las CRL de los nodos: • Revocando antes los certiĄcados de otros robos y de la BS suponiendo que conoce los números de serie. Pero no puede evitar que se generen nuevos certiĄcados más adelante. •Llenando la memoria utilizada para almacenar la CRL. Para contemplar estos casos, se propone evaluar las siguientes medidas adicionales que habría que incluir en SNSR: • Firmar digitalmente las CRL con certiĄcados de la BS o CA. Esto implicaría un coste mayor de validación y complica la transmisión incremental de la CRL, pero sería suĄciente para resolver el problema al evitar la falsiĄcación. • Añadir comprobaciones en los nodos para que no acepten CRL con números de secuencia de las BS conocidas. 252 Capítulo 6. Conclusiones • Limitar el número de entradas de las CRL, pero permitiendo añadir siempre al menos un número de serie adicional aún a costa de borrar entradas más antiguas. • Implementar la actualización remota de software Ąrmado digitalmente antes comentada, que permitiría cambiar los certiĄcados de la CA y reiniciar las CRL. Adaptación de la implementación para usar un simulador de red de eventos discretos En esta Tesis Doctoral no se emplean simuladores de red de eventos discretos como pueden ser ns-3 [ 128 ], OMNeT++ [ 154 ] u otros [ 30 ]. El módulo DCE (Direct Code Execution) de ns-3 [ 18 ] que permite ejecutar código real sobre el simulador se ha probado, pero no es compatible con la implementación actual del NOS. Una posible línea de continuación sería la adaptación del código para hacerlo funcionar en un simulador de este tipo, que permitiría simular redes con muchos nodos. Para ello, habría que añadir al LLAL del NOS (ver Sección 4.3.2) un nuevo conector que envíe y reciba los datos a través del simulador. También habría que modiĄcar la gestión de eventos en tiempo real, para que en vez de usar interrupciones del sistema operativo use los temporizadores del simulador. Ampliación de la implementación Aunque no mejorarían la seguridad de SNSR, se propone también realizar mejoras cuya incorporación podría reducir el número de paquetes enviados, mejorar el tiempo de respuesta y aumentar la Ćexibilidad para poder ser utilizado en otras aplicaciones Son las siguientes: • Cálculo del número máximo de saltos que puede dar un paquete dinámicamente, global o por nodo. Actualmente, el número máximo de saltos se conĄgura durante la inicialización, pero se podría establecer por conĄguración. Después de calcular la topología de la red se puede estimar un número máximo de saltos a partir del diámetro del grafo de la red o según las comunicaciones que debería realizar cada nodo. • Envío de conĄguración diferencial. La conĄguración de un nodo se puede enviar de manera completa o diferencial respecto a la conĄguración anterior, lo que permite reducir su tamaño. La implementación actual del robot siempre envía la conĄguración completa, pero podría calcular la diferencia respecto a la anterior y enviar solo los cambios producidos. • Compactación y establecimiento de un número máximo de anomalías. Esto está contemplado en SNSR, pero no ha sido implementado porque durante la experimentación interesaba obtener la mayor cantidad de información de depuración posible. En una red real esta medida reduciría el tamaño de los datos transmitidos. Habría que determinar cuándo interesa hacerlo y determinar el valor máximo de anomalías a almacenar según el tipo de nodo. • Recepción simultánea de varios mensajes en TL. El protocolo de transporte implementado solo permite la transmisión simultánea de un único mensaje fragmentado en cada sentido. Si el nodo tiene suĄciente memoria esto podría mejorarse permitiendo 6.2 Líneas futuras de trabajo 253 la multiplexión de varios mensajes. Esto no era necesario en las pruebas realizadas, pero podría ser útil si hay varias aplicaciones coexistiendo en el mismo nodo. • Filtro de conexiones en el robot para evitar intentos de conexión de nodos que no están autorizados. La implementación actual del robot permite la conexión de todas las entidades que descubre que tengan un certiĄcado válido. Sin embargo, si existe una lista de entidades autorizadas, el robot podría ignorar estas peticiones de conexión y simplemente registrarlas para posteriormente analizarlas como anomalías. • Obtener datos de calidad de los enlaces y enviarlos como parte del estado del nodo. Esto podría usarse para establecer otros criterios de elección de vecinos durante el cálculo de la topología. Realizar otras implementaciones SNSR admite multitud de implementaciones distintas. SNSR es muy Ćexible y permite usarlo en diferentes escenarios o actualizarlo a las nuevas tecnologías que vayan surgiendo. En general, cualquier decisión de implementación (ver Sección 4.1) es susceptible de ser cambiada. Esto ampliaría las WSN en las que se puede aplicar SNSR y permitiría hacer posteriormente comparaciones que veriĄquen las bondades de las cambios respecto a la implementación actual. Por ejemplo, otras implementaciones podrían usar: • Otros protocolos de encaminamiento: SDN (usando una BS o un robot como controlador), encaminamiento explícito, protocolos dinámicos...El encaminamiento estático usado requiere almacenar muchas rutas en los nodos si la densidad de la red y el número de nodos son muy altos, como se explicó en Sección 4.1.7. Por tanto, en algunas redes, habría que buscar alternativas. • Otros tipos de WSN, por ejemplo, con clústeres. SNSR no ha sido probado en WSN con clústeres y sería interesante comprobar su funcionamiento en ellas. La conĄguración enviada a los nodos puede ser ampliada con información del clúster al que pertenece y datos sobre el nodo elegido como CH. • Otros sistemas operativos y en nodos con distinto hardware. No todas las WSN emplean los mismos dispositivos que se ha usado en esta Tesis Doctoral y si se quiere adaptar la arquitectura a esas redes habrá que hacer modiĄcaciones en la implementación. • Diferentes niveles inferiores, cambiando el LLAL. Existen muchos niveles físicos diferentes y, como antes, si se quiere adaptar la arquitectura a esas redes habrá que hacer modiĄcaciones en la implementación. • Otros protocolos seguros. En especial la nueva versión de DTLS 1.3 [ 127 ] que promete mensajes más compactos. Su implementación haría que el tráĄco generado disminuyera. • Otros tipos de criptografía que no sea ECC, por ejemplo, con algunas de las variantes de criptografía postcuántica que se están desarrollando. Así, si en un futuro, la computación cuántica hiciera que ECC dejara de ser seguro, SNSR estaría preparado. 254 Capítulo 6. Conclusiones También permitiría evaluar el coste de esos tipos de criptografía respecto a ECC y su viabilidad en WSN. • Diferentes tipos de certiĄcados. Los certiĄcados son muy grandes. Gran parte del coste de transmisión del saludo es debido a ellos. Los certiĄcados se podrían optimizar y deĄnir un formato compacto propietario en vez de usar el formato estándar X.509. Esto podría reducir los datos transmitidos. Otra tarea sería probar con certiĄcados que usaran otra función hash, ya que al Ąn de la escritura de esta Tesis Doctoral el algoritmo SHA-1 ya está desaconsejado. Esto está soportado en la implementación actual y simplemente habría que repetir los experimentos para ver cómo afecta. • Cambios en la forma de transmisión de certiĄcados. El robot podría recopilar todos los certiĄcados de los nodos y la BS. Los nodos en vez de veriĄcar si un certiĄcado de un vecino es válido podría compararlo con una lista que les suministre el robot, que previamente han validado. El robot podría pasar todos los certiĄcados en la conĄguración, así no haría falta pasarlos en saludos posteriores. Habría que evaluar en qué situaciones esto es más ventajoso que el procedimiento actual. La asignación de vecinos no es infalible y algunos certiĄcados se habría transmitido para nada. También se puede probar con otras alternativas de criptografía asimétrica: criptografía basada en identidad o sin certiĄcados. Esto permitiría poder prescindir de la CA, aunque habría que evaluar posibles riesgos de seguridad. Índice de Figuras 1 Ejemplo de topología lineal XXII 2.1 Arquitectura de la pila de ZigBee 33 3.1 Ejemplo de topología de red 44 3.2 Esquema con la arquitectura SNSR y las principales funcionalidades de seguridad implementadas en el robot, la BS y los nodos sensores. 48 3.3 Torre de protocolos genérica para un nodo sensor 51 3.4 Esquema del Plano de Gestión y Seguridad 53 3.5 Formato de datos con seguridad añadida 56 3.6 Formato de una trama de datos mínima 57 3.7 Detalle de aplicación de seguridad a una trama 58 3.8 Formato de un paquete de red básico 60 3.9 Detalle de aplicación de seguridad a un segmento 63 3.10 Formato de un segmento de datos no seguro básico 64 3.11 Formato de un mensaje del nivel de aplicación 65 3.12 Relaciones entre distintas entidades de la arquitectura SNSR 72 3.13 Fases de funcionamiento de la red en la arquitectura SNSR 76 3.14 Información de la topología de la red 79 3.15 Intercambio de información de topología 81 3.16 Intercambio de mensajes durante la etapa de descubrimiento 85 3.17 Diagrama de estados de detección de baliza básica 87 3.18 Diagrama de estado de detección de baliza avanzada 89 3.19 Intercambio de mensajes durante la etapa de configuración 93 3.20 Notificación de anomalías 97 3.21 Intercambio de mensajes durante la notificación de anomalías 99 4.1 Funcionamiento del enrutamiento implementado 118 4.2 Ejemplo de asignación de direcciones de red 122 4.3 Formato de un mensaje PING 125 255 Bibliografía [1] ISO/IEC/IEEE International Standard - Information technologyŰ Telecommunications and information exchange between systemsŰLocal and metropolitan area networksŰSpeciĄc requirementsŰPart 15-4: Wireless medium access control (MAC) and physical layer (PHY, ISO/IEC/IEEE 8802-15-4:2018(E) (2018), 1Ű712. [2] Muhammad Ahmed, Xu Huang, and Hongyan Cui, A novel two-stage algorithm protecting internal attack from WSNs, International Journal of Computer Networks & Communications (IJCNC) 5(2013), no. 1. [3] Ohida Rufai Ahutu and Hosam El-Ocla, Centralized routing protocol for detecting wormhole attacks in wireless sensor networks, IEEE Access 8(2020), 63270Ű63282. [4] Petteri Aimonen, Nanopb - protocol buffers with small code size, https://jpa.kapsi.Ą/nanopb/, [En línea. Consulta: 28-04-2019]. [5] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, Wireless sensor networks: a survey, Computer Networks 38 (2002), no. 4, 393Ű422. [6] Jamal N. Al-Karaki and Ahmed E. Kamal, Routing techniques in wireless sensor networks: A survey, IEEE Wireless Communications 11 (2004), no. 6, 6Ű27. [7] Martin Albrecht, Melissa Chase, Hao Chen, Jintai Ding, ShaĄ Goldwasser, Sergey Gorbunov, Shai Halevi, Jeffrey Hoffstein, Kim Laine, Kristin Lauter, Satya Lokam, Daniele Micciancio, Dustin Moody, Travis Morrison, Amit Sahai, and Vinod Vaikuntanathan, Homomorphic encryption security standard, Tech. report, HomomorphicEncryption.org, Toronto, Canada, November 2018. [8] Zigbee Alliance, Zigbee SpeciĄcation, Zigbee Alliance website (2015), 1Ű542. [9] Elaine Barker, Recommendation for key management part 1: General, Tech. report, National Institute of Standards and Technology, Gaithersburg, MD, jan 2016. 263 264 Bibliografía [10] Paolo Baronti, Prashant Pillai, Vince W.C. Chook, Stefano Chessa, Alberto Gotta, and Y. Fun Hu, Wireless sensor networks: A survey on the state of the art and the 802.15.4 and ZigBee standards, Computer Communications 30 (2007), no. 7, 1655Ű1695. [11] Deebak B.D. and Fadi Al-Turjman, A hybrid secure routing and monitoring mechanism in IoT-based wireless sensor networks, Ad Hoc Networks 97 (2020), 102022. [12] Philippe Biondi and the Scapy community, Scapy: Packet crafting for Python2 and Python3, https://scapy.net, [En línea. Consulta: 28-04-2019]. [13] Alex Biryukov and Eyal Kushilevitz, From differential cryptanalysis to ciphertextonly attacks, Advances in Cryptology Ů CRYPTO Š98 (Berlin, Heidelberg) (Hugo Krawczyk, ed.), Springer Berlin Heidelberg, 1998, pp. 72Ű88. [14] Sharon Boeyen, Stefan Santesson, Tim Polk, Russ Housley, Stephen Farrell, and Dave Cooper, Internet X.509 Public Key Infrastructure CertiĄcate and CertiĄcate Revocation List (CRL) ProĄle, RFC 5280, May 2008. [15] Djallel Eddine Boubiche, Samir Athmani, Sabrina Boubiche, and Homero Toral- Cruz, Cybersecurity issues in wireless sensor networks: Current challenges and solutions, Wireless Personal Communications (2020), 1Ű37. [16] Ismail Butun, Salvatore D. Morgera, and Ravi Sankar, A survey of intrusion detection systems in wireless sensor networks, IEEE Communications Surveys & Tutorials 16 (2014), no. 1, 266Ű282. [17] Cristiano Calcagno and Dino Distefano, Infer: An automatic program veriĄer for memory safety of C programs, Springer, Berlin, Heidelberg, 2011, pp. 459Ű465. [18] Daniel Camara, Hajime Tazaki, Emilio Mancini, Thierry Turletti, Walid Dabbous, and Mathieu Lacage, DCE: Test the real code of your protocols and applications over simulated networks, IEEE Communications Magazine 52 (2014), no. 3, 104Ű110. [19] Certicom Research, Standards for Efficient Cryptography 1 (SEC 1) : Elliptic Curve Cryptography, Standards for Efficient Cryptography 1(2009), no. Sec 1, 1Ű22. [20] Howie Choset and Philippe Pignon, Coverage path planning: The boustrophedon cellular decomposition, Field and Service Robotics, Springer London, London, 1998, pp. 203Ű209. [21] Gerald Combs and the WireShark team, Wireshark · Go Deep., https://www.wireshark.org, [En línea. Consulta: 28-04-2019]. [22] cozybit Inc., cozybit/wmediumd: mac80211_hwsim modiĄcations and related stuff, https://github.com/cozybit/wmediumd, [En línea. Consulta: 28-04-2019]. [23] Alberto De San Bernabé Clemente, José Ramiro Martínez-De Dios, Carolina Regoli, and Aníbal Ollero, Wireless sensor network connectivity and redundancy repairing with mobile robots, Studies in Computational Intelligence 554 (2014), 185Ű204. Bibliografía 265 [24] Dr. Steve E. Deering and Bob Hinden, Internet Protocol, Version 6 (IPv6) SpeciĄ- cation, RFC 8200, July 2017. [25] Jing Deng, Richard Han, and Shivakant Mishra, INSENS : Intrusion-Tolerant Routing in Wireless Sensor Networks ; CU-CS-939-02, Tech. report, 2002. [26] ,INSENS: Intrusion-tolerant routing for wireless sensor networks, Computer Communications 29 (2006), no. 2, 216Ű230. [27] Valgrind Developers, Valgrind Home, http://www.valgrind.org, [En línea. Consulta: 28-04-2019]. [28] Martin Devera, Hierachical token bucket theory, http://luxik.cdi.cz/ devik/qos/htb/- manual/theory.htm, 2002, [En línea. Consulta: 28-04-2019]. [29] R. Di Pietro, S. Guarino, N. V. Verde, and J. Domingo-Ferrer, Security in wireless ad-hoc networks - a survey, Computer Communications 51 (2014), 1Ű20. [30] Alvaro Diaz and Pablo Sanchez, Simulation of attacks for security in wireless sensor network, Sensors 16 (2016), no. 11. [31] T. Dierks and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246, RFC Editor, August 2008. [32] W. Diffie and M. Hellman, New directions in cryptography, IEEE Transactions on Information Theory 22 (1976), no. 6, 644Ű654. [33] Ramon dos Reis Fontes, GitHub - ramonfontes/manual-mininet-wiĄ, https://github.com/ramonfontes/manual-mininet-wiĄ, [En línea. Consulta: 28-04-2019]. [34] Miao Du and Kun Wang, An SDN-enabled pseudo-honeypot strategy for distributed denial of service attacks in industrial internet of things, IEEE Transactions on Industrial Informatics 16 (2020), 648Ű657. [35] A. Dunkels, B. Gronvall, and T. Voigt, Contiki - a lightweight and Ćexible operating system for tiny networked sensors, 29th Annual IEEE International Conference on Local Computer Networks, IEEE (Comput. Soc.), pp. 455Ű462. [36] Adam Dunkels and Adam, Full TCP/IP for 8-bit architectures, Proceedings of the 1st international conference on Mobile systems, applications and services - MobiSys Š03 (New York, New York, USA), ACM Press, 2003, pp. 85Ű98. [37] Khalid EL Gholami, Maleh Yassine, and Imade Fahd-Eddine Fatani, The ieee 802.15.4 standard in industrial applications: A survey, Journal of Theoretical and Applied Information Technology 99 (2021). [38] Pasi Eronen, Hannes Tschofenig, Hao Zhou, and Joseph A. Salowey, Transport Layer Security (TLS) Session Resumption without Server-Side State, RFC 5077, January 2008. 266 Bibliografía [39] Muhammad Omer Farooq and Thomas Kunz, Operating systems for wireless sensor networks: a survey, Sensors (Basel, Switzerland) 11 (2011), no. 6, 5900Ű30. [40] Francisco J Fernández-Jiménez and J Ramiro Martínez-de Dios, Design of a robotsensor network security architecture for monitoring applications, ROBOT 2017: Third Iberian Robotics Conference (Cham) (Anibal Ollero, Alberto Sanfeliu, Luis Montano, Nuno Lau, and Carlos Cardeira, eds.), Springer International Publishing, 2018, pp. 200Ű212. [41] Francisco Jose Fernandez-Jimenez and Jose Ramiro Martinez De Dios, A robotsensor network security architecture for monitoring applications, IEEE Internet of Things Journal 9(2022), no. 8, 6288Ű6304. [42] Francisco José Fernández-Jiménez and José Ramiro Martínez-de Dios, Dataset of SNSR experiments, http://dx.doi.org/10.21227/62fj-8b04, [En línea. Consulta: 17-05-2022]. [43] Jon Ferraiolo, Fujisawa Jun, and Dean Jackson, Scalable vector graphics (svg) 1.0 speciĄcation, iuniverse Bloomington, 2000. [44] Sally Floyd, Jamshid Mahdavi, Matt Mathis, and Dr. Allyn Romanow, TCP Selective Acknowledgment Options, RFC 2018, October 1996. [45] Ramon R. Fontes, Samira Afzal, Samuel H. B. Brito, Mateus A. S. Santos, and Christian Esteve Rothenberg, Mininet-WiFi: Emulating software-deĄned wireless networks, 2015 11th International Conference on Network and Service Management (CNSM), IEEE, nov 2015, pp. 384Ű389. [46] Enric Galceran and Marc Carreras, A survey on coverage path planning for robotics, Robotics and Autonomous Systems 61 (2013), no. 12, 1258Ű1276. [47] Laura Galluccio, Sebastiano Milardo, Giacomo Morabito, and Sergio Palazzo, SDN-WISE: Design, prototyping and experimentation of a stateful SDN solution for WIreless SEnsor networks, IEEE Conf. on Computer Communications (INFOCOM), apr 2015, pp. 513Ű521. [48] L Gandhimathi and G Murugaboopathi, Mobile malicious node detection using mobile agent in cluster-based wireless sensor networks, Wireless Personal Communications 117 (2021), 1209Ű1222. [49] Emden R Gansner and Stephen C North, An open graph visualization system and its applications to software engineering, Software: practice and experience 30 (2000), no. 11, 1203Ű1233. [50] Gunnar Gaubatz, Jens-Peter Kaps, and Berk Sunar, Public key cryptography in sensor networks-revisited, Springer, Berlin, Heidelberg, 2005, pp. 2Ű18. [51] Amit Kumar Gautam and Rakesh Kumar, A comprehensive study on key management, authentication and trust management techniques in wireless sensor networks, SN Applied Sciences 3(2021), 50. Bibliografía 267 [52] Cyril Gavoille and Stéphane Pérennès, Memory requirement for routing in distributed networks, Proceedings of the Ąfteenth annual ACM symposium on Principles of distributed computing - PODC Š96 (New York, New York, USA), ACM Press, 1996, pp. 125Ű133. [53] Google Inc., Protocol Buffers | Google Developers, https://developers.google.com/protocol-buffers/, [En línea. Consulta: 28-04- 2019]. [54] T. H. Hai and E. Huh, Detecting selective forwarding attacks in wireless sensor networks using two-hops neighbor knowledge, 2008 Seventh IEEE International Symposium on Network Computing and Applications, July 2008, pp. 325Ű331. [55] Nikhil Handigol, Brandon Heller, Vimalkumar Jeyakumar, Bob Lantz, and Nick Mckeown, Reproducible network experiments using container-based emulation, 2012. [56] Anne Marie Hegland, Eli Winjum, Stig F Mjolsnes, Chunming Rong, Oivind Kure, and Pal Spilling, A survey of key management in ad hoc networks, IEEE Communications Surveys & Tutorials 8(2006), no. 3, 48Ű66 (English). [57] Stephen Hemminger and Others, Network emulation with NetEm, Linux conf au, 2005, pp. 18Ű23. [58] Faouzi Hidoussi, Homero Toral-Cruz, Djallel Eddine Boubiche, Kamaljit Lakhtaria, Albena Mihovska, Miroslav Voznak, and Miroslav Voznak voznak, Centralized IDS based on misuse detection for cluster-based wireless sensors networks, Wireless Pers Commun 85 (2015), 207Ű224. [59] Chen Hongsong, Meng Caixia, Fu Zhongchuan, and Chao Hsien Lee, Novel LDoS attack detection by spark-assisted correlation analysis approach in wireless sensor network, IET Information Security 14 (2020), 452Ű458. [60] E Horowitz and S Sahni, Fundamentals of computer algorithms, computer science press, Computer Software Engineering Series (1978), 526Ű529. [61] Fei Hu, Qi Hao, and Ke Bao, A survey on software-deĄned network and OpenFlow: From concept to implementation, IEEE Communications Surveys & Tutorials 16 (2014), no. 4, 2181Ű2206. [62] René Hummen, Jan H. Ziegeldorf, Hossein Shafagh, Shahid Raza, and Klaus Wehrle, Towards viable certiĄcate-based authentication for the internet of things, HotWiSec 2013 - Proceedings of the 2013 ACM Workshop on Hot Topics on Wireless Network Security and Privacy (New York, New York, USA), ACM Press, 2013, pp. 37Ű41. [63] Safwan Mawlood Hussein, Juan Antonio López Ramos, and José Antonio Álvarez Bermejo, Distributed key management to secure IoT wireless sensor networks in smart-agro, Sensors 20 (2020), 2242. 268 Bibliografía [64] Christophe Huygens and Wouter Joosen, Federated and shared use of sensor networks through security middleware, 2009 Sixth International Conference on Information Technology: New Generations, 2009, pp. 1005Ű1011. [65] IANA, Transport Layer Security (TLS) Parameters, https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml, [En línea. Consulta: 28-04-2019]. [66] IEEE Computer Society. Portable Applications Standards Committee., IEEE Standards Board., and American National Standards Institute., IEEE standard for information technology : portable operating system interface (POSIX) : Part 1, System application program interface (API) : Amendment 1, Realtime extension [C language], Institute of Electrical and Electronics Engineers, 1994. [67] IEEE Standard SpeciĄcations for Public-Key Cryptography, IEEE Std 1363-2000 (2000), 1Ű228. [68] IEEE Standard SpeciĄcation for Public Key Cryptographic Techniques Based on Hard Problems over Lattices, IEEE Std 1363.1-2008 (2009), C1Ű69. [69] IEEE Standard SpeciĄcations for Password-Based Public-Key Cryptographic Techniques, IEEE Std 1363.2-2008 (2009), 1Ű127. [70] IEEE Standard for Identity-Based Cryptographic Techniques using Pairings, IEEE Std 1363.3-2013 (2013), 1Ű151. [71] IEEE Standard SpeciĄcations for Public-Key Cryptography - Amendment 1: Additional Techniques, IEEE Std 1363a-2004 (Amendment to IEEE Std 1363-2000) (2004), 1Ű167. [72] Jana Iyengar and Ian Swett, QUIC Loss Detection and Congestion Control, Internet- Draft draft-ietf-quic-recovery-22, Internet Engineering Task Force, July 2019, Work in Progress. [73] Jana Iyengar and Martin Thomson, QUIC: A UDP-Based Multiplexed and Secure Transport, Internet-Draft draft-ietf-quic-transport-22, Internet Engineering Task Force, July 2019, Work in Progress. [74] Steven Jacobson, Van and Leres, Craig and McCanne, Tcpdump/Libpcap public repository, https://www.tcpdump.org, [En línea. Consulta: 28-04-2019]. [75] Bo Jiang, Guosheng Huang, Tian Wang, Jinsong Gui, and Xiaoyu Zhu, Trust based energy efficient data collection with unmanned aerial vehicle in edge network, Transactions on Emerging Telecommunications Technologies (2020). [76] Shuai Jiang, Juan Zhao, and Xiaolong Xu, SLGBM: An intrusion detection mechanism for wireless sensor networks in smart environments, IEEE Access 8(2020), 169548Ű169558. Bibliografía 269 [77] Gauri Kalnoor and Jayashree Agarkhed, Pattern matching intrusion detection technique for wireless sensor networks, Proceeding of IEEE - 2nd International Conference on Advances in Electrical, Electronics, Information, Communication and Bio-Informatics, IEEE - AEEICB 2016 (2016), 724Ű728. [78] Dionisis Kandris, Christos Nakas, Dimitrios Vomvas, and Grigorios Koulouras, Applications of wireless sensor networks: An up-to-date survey, Applied System Innovation 3(2020), no. 1, 14. [79] Phil R. Karn and William A. Simpson, Photuris: Session-Key Management Protocol, RFC 2522, March 1999. [80] Charlie Kaufman, Paul E. Hoffman, Yoav Nir, Pasi Eronen, and Tero Kivinen, Internet Key Exchange Protocol Version 2 (IKEv2), RFC 7296, October 2014. [81] S. Kent and K. Seo, Security architecture for the Internet Protocol, RFC 4301, RFC Editor, December 2005. [82] D. Kim and S. An, PKC-Based DoS attacks-resistant scheme in wireless sensor networks, IEEE Sensors Journal 16 (2016), no. 8, 2217Ű2218. [83] Daehee Kim and Sunshin An, Efficient and scalable public key infrastructure for wireless sensor networks, The 2014 Intl. Symposium on Networks, Computers and Communications, IEEE, jun 2014, pp. 1Ű5. [84] Neal Koblitz, Elliptic curve cryptosystems, Mathematics of computation 48 (1987), no. 177, 203Ű209. [85] Dmitri Krioukov, k c Claffy, Kevin Fall, and Arthur Brady, On compact routing for the internet, ACM SIGCOMM Computer Communication Review 37 (2007), no. 3, 41. [86] Scott Law, Laurie and Menezes, Alfred and Qu, Minghua and Solinas, Jerry and Vanstone, An efficient protocol for authenticated key agreement, Designs, Codes and Cryptography 28 (2003), 119Ű134. [87] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, E. Brewer, and D. Culler, TinyOS: An operating system for sensor networks, Ambient Intelligence, Springer-Verlag, Berlin/Heidelberg, 2005, pp. 115Ű148. [88] Fangyu Li, Rui Xie, Zengyan Wang, Lulu Guo, Jin Ye, Ping Ma, and Wenzhan Song, Online distributed IoT security monitoring with multidimensional streaming big data, IEEE Internet of Things Journal 7(2020), no. 5, 4387Ű4394. [89] Jinhui Liu, Lianhai Wang, and Yong Yu, Improved security of a pairing-free certiĄ- cateless aggregate signature in healthcare wireless medical sensor networks, IEEE Internet of Things Journal 7(2020), 5256Ű5266. 270 Bibliografía [90] V.J. Lumelsky, S. Mukhopadhyay, and K. Sun, Dynamic path planning in sensorbased terrain acquisition, IEEE Transactions on Robotics and Automation 6(1990), no. 4, 462Ű472. [91] Ivan I. Lysogor, Leonid S. Voskov, and Sergey G. Efremov, Survey of data exchange formats for heterogeneous LPWAN-satellite IoT networks, 2018 Moscow Workshop on Electronic and Networking Technologies (MWENT), IEEE, mar 2018, pp. 1Ű5. [92] Xin Ma and Wei Luo, The analysis of 6LowPAN technology, 2008 IEEE PaciĄc-Asia Workshop on Computational Intelligence and Industrial Application, IEEE, dec 2008, pp. 963Ű966. [93] Daniel Marjamaki, Cppcheck - A tool for static C/C++ code analysis, http://cppcheck.sourceforge.net, [En línea. Consulta: 28-04-2019]. [94] J. R. Martinez-De Dios, K. Lferd, A. De San Bernabé, G. Núñez, A. Torres-González, and A. Ollero, Cooperation between UAS and wireless sensor networks for efficient data collection in large environments, Journal of Intelligent and Robotic Systems: Theory and Applications 70 (2013), no. 1-4, 491Ű508. [95] José Ramiro Martínez-de Dios, Alberto de San Bernabé, Antidio Viguria, Arturo Torres-González, and Anibal Ollero, Combining unmanned aerial systems and sensor networks for earth observation, Remote Sensing 2017, Vol. 9, Page 336 9 (2017), no. 4, 336. [96] J. R. Martínez-de Dios and et al., Aerial robot coworkers for autonomous localization of missing tools in manufacturing plants, Intl. Conf. on Unmanned Aircraft Systems, 2018, pp. 1063Ű1069. [97] John Mattsson and Francesca Palombini, Comparison of CoAP Security Protocols, Internet-Draft draft-ietf-lwig-security-protocol-comparison-03, Internet Engineering Task Force, March 2019, Work in Progress. [98] Gabi Melman, spdlog - Very fast, header only, C++ logging library, https://github.com/gabime/spdlog, [En línea. Consulta: 28-04-2019]. [99] Christian Miranda, Georges Kaddoum, Elias Bou-Harb, Sahil Garg, and Kuljeet Kaur, A collaborative security framework for software-deĄned wireless sensor networks, IEEE Transactions on Information Forensics and Security 15 (2020), 2602Ű2615. [100] P. Mockapetris, Domain names - concepts and facilities, RFC 1034, November 1987. [101] Gabriel Montenegro, Jonathan Hui, David Culler, and Nandakishore Kushalnagar, Transmission of IPv6 Packets over IEEE 802.15.4 Networks, RFC 4944, September 2007. Bibliografía 271 [102] Javier Munoz-Calle, Francisco J. Fernandez-Jimenez, Teresa Ariza, Antonio J. Sierra, and Juan M. Vozmediano, Computing labs on virtual environments: A Ćexible, portable, and multidisciplinary model, Revista Iberoamericana de Tecnologias del Aprendizaje 11 (2016), no. 4, 235Ű341. [103] Mansoor Nasir, Khan Muhammad, Paolo Bellavista, Mi Young Lee, and Muhammad Sajjad, Prioritization and alert fusion in distributed IoT sensors using kademlia based distributed hash tables, IEEE Access 8(2020), 175194Ű175204. [104] Musa Ndiaye, Gerhard P Hancke, and Adnan M Abu-Mahfouz, Software deĄned networking for improved wireless sensor network management: A survey, Sensors (Basel, Switzerland) 17 (2017), no. 5. [105] James Newsome, Elaine Shi, Dawn Song, and Adrian Perrig, The sybil attack in sensor networks: analysis & defenses, Proceedings of the 3rd international symposium on Information processing in sensor networks, ACM, 2004, pp. 259Ű268. [106] Stefan Nilsson and Gunnar Karlsson, Fast address lookup for internet routers, Broadband Communications, Springer US, Boston, MA, 1998, pp. 11Ű22. [107] Yoav Nir, Simon Josefsson, and Manuel Pégourié-Gonnard, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier, RFC 8422, August 2018. [108] Muhammad Numan, Fazli Subhan, Wazir Zada Khan, Saqib Hakak, Sajjad Haider, G. Thippa Reddy, Alireza Jolfaei, and Mamoun Alazab, A systematic review on clone node detection in static wireless sensor networks, IEEE Access 8(2020), 65450Ű65461. [109] Object Management Group Inc., OMG ® UniĄed Modeling Language ® (OMG UML ® ), 2.5.1 ed., no. December, 2017. [110] Flauzac Olivier, Gonzalez Carlos, and Nolot Florent, SDN based architecture for clustered WSN, 2015 9th Intl. Conf. on Innovative Mobile and Internet Services in Ubiquitous Computing, IEEE, jul 2015, pp. 342Ű347. [111] Anibal Ollero, Guillermo Heredia, Antonio Franchi, Gianluca Antonelli, Konstantin Kondak, Alberto Sanfeliu, Antidio Viguria, J. Ramiro Martinez-de Dios, Francesco Pierri, Juan Cortes, Angel Santamaria-Navarro, Miguel Angel Trujillo Soto, Ribin Balachandran, Juan Andrade-Cetto, and Angel Rodriguez, The AEROARMS project: Aerial robots with advanced manipulation capabilities for inspection and maintenance, IEEE Robotics and Automation Magazine 25 (2018), no. 4, 12Ű23. [112] OpenSSL Software Foundation, OpenSSL: Cryptography and SSL/TLS Toolkit, https://www.openssl.org, [En línea. Consulta: 28-04-2019]. [113] ZigBee Standards Organization, ZigBee Smart Energy Standard, (2014), 1Ű628.