(')%%*+(%%% ,)#+(-.% (()(/0&)
10(()))(%).)')#2 1((%
#$% &'
ii RESUMEN
Vivimos un momento en el que cada vez más objetos de uso común llevan aso- ciado un microcontrolador, lo que permite a dichos objetos establecer redes de co- municaciones entre ellos y con Internet. Es la llamada internet de las cosas (IoT por sus siglas en inglés). Sus aplicaciones van desde el control doméstico de temperatura hasta la automatización de procesos industriales. Tal ubicuidad plantea la cuestión del elevado impacto que podría tener un ataque realizado con éxito sobre esta clase de redes. Por otra parte, dada la limitada potencia de algunos de los microcontrola- dores, no es factible la aplicación de soluciones clásicas de la criptografía, tales como la infraestructura de clave pública (PKI).
La información de los sensores y los comandos que se envían a los actuadores generalmente no necesitan ser privados, pero es peligroso no autenticar la informa- ción y, sobre todo, los comandos. Es importante recordar que se trata de sistemas Ciberfísicos: microcontroladores que gobiernan objetos físicos, por lo que un ataque podría causar daños a objetos o incluso a personas.
El objetivo de este trabajo es diseñar e implementar un protocolo de autentica- ción que asegure que un mensaje recibido procede de un dispositivo legítimo y que fue enviado en un rango de tiempo concreto. Se pretende conseguir esto utilizando la mínima potencia de cómputo posible.
iii iv RESUMEN ABSTRACT
We live in a moment in which more and more objects of common use ara associa- ted with a microcontroller. This fact allows these objects to establish communication networks between them and with the Internet. These networks form the so-called In- ternet of Things (IoT). Its applications range from domestic temperature control to the automation of industrial processes. Such ubiquity raises the question of the high impact a succesful attack would have on this type of networks. In addition, given the limited power of some microcontrollers, the application of classical cryptography solutions, such as public key infrastructure (PKI), become infeasible.
The information from sensors and the commands sent to actuators do not need to be private. However, it is dangerous not to authenticate the information and, above all, the commands. It is important to keep in mind that these microcontrollers are attached to physical objects and, because of that, an attack coud harm objects or even people.
The target of this work is to design and implement an authentication protocol. That is, to ensure that a received message comes from a legitimate device and that it was sent in a fixed range of time. Moreover, it is intended to achive that using the lowest possible computing power.
v vi ABSTRACT Índice general
RESUMEN III
ABSTRACT V
1. Introducción 1
1.1. Notación ...... 2
2. ESTADO DEL ARTE 3
2.1. Criptografía ...... 3
2.1.1. Criptografía simétrica ...... 3
2.1.2. Funciones de derivación de claves ...... 7
2.2. Modelo OSI ...... 8
2.3. Microcontroladores y sistemas de control ...... 10
2.3.1. Arquitecturas de microcontroladores ...... 11
2.4. Internet of Things ...... 12
2.4.1. Raspberry Pi Zero W ...... 13
2.4.2. ESP32 ...... 13
2.5. Comunicación por radio ...... 14
2.5.1. Modulación digital ...... 14
2.5.2. Protocolos wireless ...... 17
vii viii ÍNDICE GENERAL
3. ESCENARIO DE TRABAJO 21
3.1. Objetivo ...... 21
3.2. Topología de la red ...... 22
3.3. Atacante ...... 24
4. SOLUCION PROPUESTA 25
4.1. Alta de un nodo ...... 26
4.2. Operación del nodo ...... 27
4.2.1. Formato del mensaje ...... 27
4.2.2. Firmado del mensaje ...... 28
4.2.3. Comprobación de la firma ...... 29
4.2.4. Resincronización del contador ...... 30
4.3. Baja de un nodo ...... 31
4.4. Elección de algoritmos criptográficos ...... 31
4.4.1. Longitud de las claves ...... 33
4.5. Limitaciones ...... 33
4.6. Pruebas ...... 34
5. CONCLUSIONES Y LÍNEAS FUTURAS 39
5.1. Conclusiones ...... 39
5.2. Líneas futuras ...... 40
Bibliografía 41 Índice de figuras
2.1. Jerarquía de derivación de claves ...... 7
2.2. Comunicación según el modelo OSI con un intermediario a nivel de red 8
2.3. Encapsulación en tres niveles ...... 9
2.4. Esquema de la arquitectura de Von Neumann ...... 11
2.5. Raspberry Pi Zero ...... 13
2.6. Módulo ESP32 ...... 13
2.7. Modulación de señales en amplitud y frecuencia ...... 15
2.8. Contaminación con ruido de una señal digital ...... 15
2.9. Típica red wifi doméstica ...... 17
3.1. Topologías de red ...... 22
3.2. Número de claves en el sistema en función del número de nodos en la red para las distintas topologías ...... 23
3.3. Número máximo de saltos que debe dar un mensaje en función del número de nodos en la red para las distintas topologías ...... 23
4.1. Intercambio de mensajes en el alta de un nuevo nodo ...... 26
4.2. Formato del mensaje ...... 27
4.3. Intercambio de mensajes en el alta de un nuevo nodo. Fuente: Google 32
4.4. Escenario para las pruebas del protocolo ...... 34
ix x ÍNDICE DE FIGURAS
4.5. Trama correcta ...... 35
4.6. Trama con el contador erróneo ...... 36
4.7. Trama de sincronización ...... 36
4.8. Paquete capturado por el atacante y que será modificado ...... 36
4.9. Paquete modificado por el atacante ...... 36
4.10. Paquete correcto ...... 37
4.11. Paquetes involucrados en el ataque por repetición ...... 37
4.12. Paquete repetido en el ataque por repetición ...... 37
4.13. Trama de sincronización ...... 37 Índice de tablas
1.1. Tabla de verdad del operador XOR ...... 2
2.1. Resumen de algoritmos de cifrado simétrico ...... 5
2.2. Tamaño del payload en LoRa según región y frecuencia ...... 18
4.1. Comparación entre ChaCha20 y AES256 ...... 32
xi xii ÍNDICE DE TABLAS Capítulo 1
Introducción
Con el auge de la Internet of Things, las redes de sensores y actuadores con- trolados por dispositivos de bajo consumo están a la orden el día. Cuando estos dispositivos utilizan un cable como medio de transmisión de sus comunicaciones y se tiene un control sobre qué dispositivos están conectados, basta un control de ac- ceso físico a dicho cable para proveer de seguridad al sistema. Tal control puede no tener una implementación trivial, pero cuando el medio de transmisión son ondas de radio es muy difícil, cuando no imposible, implementarn medidas de seguridad análogas a la protección de un cable. Por otra parte, la transmisión mediante ondas de radio es más barata y sencilla en cuanto a que no requiere extender un cable entre los dos nodos que participan en la comunicación, y a que puede llegar a cubrir largas distancias con una inversión mínima en infraestructura. Así, está claro que las ondas de radio como canal ofrecen ventajas suficientes como para utilizarlas en algunas de las redes que pueden formar esta Internet of Things.
Volviendo al problema de la seguridad, queda descartada la aplicación del mismo principio de control de acceso físico que se podría aplicar a redes cableadas, puesto que con una antena no es posible averiguar ni cuántos dispositivos captan una señal que ha emitido ni qué dispositivo ha emitido una señal que haya captado. Así, hay que encontrar un mecanismo para asegurar la autenticidad de los mensajes recibidos y que parta de la suposición de que un atacante puede leer todos los mensajes que pasen por el canal e introducir mensajes nuevos sin que estos sean, en principio, diferenciables de un mensaje legítmo.
Está claro que este mecanismo no puede pasar por la aplicación de un control sobre el canal, por lo que debe aplicar cambios en el mensaje de forma que, una vez recibido, sea posible verificar que este mensaje es legítimo. La manera de solucionar este problema pasa necesariamente por la aplicación de funciones criptográficas al mensaje, de forma que sólo aquellos que demuestren conocer un secreto, esto es, la clave, sean considerados como emisores legítimos en la comunicación.
1 2 CAPÍTULO 1. INTRODUCCIÓN
1.1. Notación
Los operadores no estándar utilizados en las fórmulas que se encuentran a lo largo de este trabajo son los siguientes:
⊕: Operador de or exclusivo o XOR, operación lógica bit a bit cuya tabla de verdad se muestra en la tabla 1.1
Tabla 1.1: Tabla de verdad del operador XOR ABA⊕ B
00 0
01 1
10 1
11 0
||: Operador de concatenación, consiste en añadir el operando derecho a la representación del izquierdo. Por ejemplo: 0011||1100 = 00111100
(x)16: Representación hexadecimal, significa que el número entre paréntesis está escrito en notación hexadecimal (base 16) en lugar de la notación usual (decimal o base 10). Capítulo 2
ESTADO DEL ARTE
2.1. Criptografía
La criptografía estudia un conjunto de técnicas matemáticas para implementar servicios de seguridad de la información y las comunicaciones. Estos servicios de seguridad son los siguientes [25]:
Confidencialidad: Se ocupa de mantener la información en secreto para todas aquellas entidades que no estén autorizadas a conocer dicha información.
Integridad: Trata de detectar la manipulación de los datos, de forma que se pueda verificar que no se han añadido, eliminado o modificado datos.
Autenticación: Identifica tanto la información como a las entidades que par- ticipan en su comunicación.
No repudio: Evita que una entidad pueda negar haber realizado determina- das acciones.
2.1.1. Criptografía simétrica
Los algoritmos englobados dentro de la criptografía simétrica tienen la propiedad de que utilizan una sola clave secreta conocida por las dos partes que participan en la comunicación. De esta forma, para establecer una comunicación cifrada entre dos entidades utilizando un cifrado simétrico, ambas entidades deben conocer la misma clave secreta, que utilizarán para cifrar y descifrar los mensajes que intercambien.[26]
3 4 CAPÍTULO 2. ESTADO DEL ARTE
Cifradores
Los algoritmos o funciones de cifrado tienen como objetivo modificar un mensaje de forma que sólo pueda ser leído y comprendido por una entidad autorizada. Esto significa que aportan confidencialidad al mensaje.
Un par de funciones C, D de cifrado y descifrado con una clave secreta k trans- forman una entrada i en una salida cifrada Ck(i) tal que Dk(Ck(i)) = i y sólo es posible descifrar el texto cifrado si se conoce la clave secreta k. De esta manera, se considera “autorizada” a cualquier entidad que conozca la clave. Por ejemplo, se podría cifrar un mensaje calculando un XOR (or exclusivo) lógico de la clave con el mensaje, tantas veces como fuera necesario. Este algoritmo evidentemente no sería seguro, ya que resultaría relativamente sencillo analzar el criptograma para averi- guar la clave, y trivial si se conociese el texto claro. Sin embargo, si la clave fuera aleatoria, se utilizara una sola vez y tuviera una longitud mayor o igual que el texto claro, sería imposible averiguar el texto claro dado el criptograma y sin conocer la clave. Son los llamados one time pad [29].
A consecuencia del método de autorización utilizado, aparece la dificultad de hacer llegar las claves a las entidades autorizadas de forma que una tercera entidad no pueda apropiarse de ellas, ya que si lo consiguiera no sería posible diferenciarla de las entidades legítimas, por lo que podría leer y comprender cualquiera de los mensajes intercambiados e incluso insertar nuevos mensajes, violando la confidencialidad del sistema.
Esta distribución de claves secretas requiere confianza en alguno de los elementos de la comunicación. Un ejemplo es la contraseña escrita en el punto de acceso de una red wifi doméstica: se considera que si alguien ha conseguido acceso físico para leerla entonces es una entidad autorizada para conectarse. En otros casos se recurre a protocolos de intercambio de claves como el de diffie-hellman [18] o al uso de canales previamente cifrados [25].
A continuación se expone una lista de algunos estos cifrados, con sus caracterís- ticas más relevantes: [27][28][11][8][36][4][3][19][12][13] 2.1. CRIPTOGRAFÍA 5
Tabla 2.1: Resumen de algoritmos de cifrado simétrico
Cifrado Longitud de la Tamaño del blo- Validez clave que
Rijndael 128, 192 o 256 128 bits Ganador del AES bits
Blowfish de 32 a 448 bits 64 bits Sometido a escrutinio público du- rante 26 años
DES 56+8 bits 64 bits Eliminado por el NIST
Triple DES 168,112 o 56 bits 64 bits Aprobado por el NIST
Serpent 128, 192 o 256 128 bits Finalista del AES bits
Serpent 128, 192 o 256 128 bits Finalista del AES bits
Twofish 128, 192 o 256 128 bits Finalista del AES bits
Camellia 128, 192 o 256 128 bits Parte del estándar TLS bits
CAST de 40 a 128 bits 64 bits Parte de GPG
GOST 256 bits 64 bits Los ataques teóricos a GOST son realizables computacionalmente
XXTEA 128 bits al menos 64 bits Vulnerable a ataques de texto en claro elegido con 259 peticiones
Salsa20 128 o 256 bits 8 bits Seleccionado por el proyecto eS- TREAM
ChaCha20 128 o 256 bits 8 bits Mejora sobre Salsa20
Funciones hash
Las funciones hash son funciones de compresión: dada una entrada de longitud arbitraria, la salida es siempre de la misma longitud. En criptografía, las funciones 6 CAPÍTULO 2. ESTADO DEL ARTE hash cumplen además que dado a es fácil calcular h(a), pero dado h(a) no es posible encontrar a. En la práctica, encontrar a a partir de h(a) no es imposible, pero sí computacionalmente muy costoso [25].
El hecho de que sean funciones de compresión tiene una consecuencia importante: si el dominio de la función es el infinito conjunto de cadenas de bits de cualquier longitud, y su codominio es el conjunto de todas las cadenas de bits de longitud n, por el principio del palomar sabemos que existen al menos dos (y posiblemente infinitos) valores de la entrada que comparten la misma salida. Este par de valores de entrada con una misma salida se denomina “colisión”, y un atacante podría intentar utilizarla para confundir a un sistema que utilice funciones hash para fines como la autenticación de mensajes. Por ello, las funciones hash sólo son aplicables a la criptografía si tienen una elevada resistencia a las colisiones. Es decir, dada una cadena de bits a, un atacante no puede encontrar una cadena a tal que h(a)= h(a) [29].
Un ejemplo básico de función hash es el módulo n. Cumple que el resultado se puede representar con log2(n) bits independientemente de la longitud de la entrada. Sin embargo, evidentemente no se podría utilizar como función hash crip- tográfica, ya que dado un número cualquiera es trivial encontrar otros números que valgan lo mismo en módulo n, es decir, el módulo no es una función resistente a colisiones.
Códigos de autenticación de mensajes
Los códigos de autenticación de mensajes (MAC por sus siglas en inglés) son algoritmos que utilizan funciones hash con clave para generar una firma digital del mensaje. El valor de esta firma depende tanto del contenido del mensaje como de la clave utilizada, por lo que sólo puede ser verificada por aquellas entidades que conocen la clave.
Cuando una entidad recibe un mensaje firmado, el proceso para verificar la firma es sencillo: primero separa el mensaje de la firma, después calcula su propia versión de la firma para ese mismo mensaje. Si la firma calculada es distinta de la firma recibida, entonces se puede afirmar que el mensaje ha sufrido alguna modificación durante la comunicación o no proviene de una fuente auténtica [25].
Habitualmente se utilizan HMAC, que son códigos de autenticación de mensajes basados en funciones hash. Funcionan de la siguiente manera[2]: HMAC(K, m)=H(K ⊕ opad||H(K ⊕ ipad||m)) (2.1) Donde:
K es la clave del HMAC 2.1. CRIPTOGRAFÍA 7
m es es el mensaje para el que el HMAC se calcula
H es una función hash
⊕ es el operador XOR (or exclusivo)
|| es el operador de concatenación
opad es un número de la misma longitud que el bloque de la función H cuyos bytes valen todos (36)16 ipad es un número de la misma longitud que el bloque de la función H cuyos bytes valen todos (5c)16
La seguridad de los HMAC depende de la seguridad de las funciones hash que utilicen.
2.1.2. Funciones de derivación de claves
Las funciones de derivación de claves (KDF) tienen como objetivo obtener una o varias claves Kfi criptográficamente seguras a partir de alguna otra clave o ma- terial[22]. Entendemos como “criptográficamente seguras” aquellas claves que no se pueden distinguir de un número escogido aleatoriamente. No deben, por lo tanto, dar información sobre el resto de claves derivadas del mismo material.
M
Kd1 Kd2 ... Kdn
Ks1,1 Ks1,2 ... Ks1,m Ks2,1 Ks2,2 ... Ks2,m Ksn,1 Ksn,2 ... Ksn,m
Figura 2.1: Jerarquía de derivación de claves
Como se muestra en la figura 2.1, se puede establecer una jerarquía de claves de forma que, conociendo una clave maestra M, se puedan derivar claves siguiendo un crecimiento exponencial de la siguiente manera: 8 CAPÍTULO 2. ESTADO DEL ARTE
1. Se aplica KDF(M) un número n de veces, obteniendo el conjunto de las claves de primer nivel {Kd1,Kd2,...,Kdn} 2. Para cada clave K del nivel más bajo del árbol (en el caso de la figura 2.1, el conjunto {Ksi,j.1 ≤ i ≤ n, 1 ≤ j ≤ m}) se puede aplicar recursivamente KDF(K) un número m de veces para derivar m claves por cada una de las claves en el nivel más bajo.
2.2. Modelo OSI
El modelo OSI (Open Sistem Interconnection) tiene como propósito “estable- cer una base común para el desarrollo de estándares para la interconexión de siste- mas” [21]. Define una serie de capas o niveles en los que se puede dividir un protocolo de comunicaciones de forma que la comunicación se realiza entre entidades pares, es decir, entre protocolos que se hayan en el mismo nivel. Esto significa que cuan- do se recibe un mensaje, cada protocolo atiende solo al contenido correspondiente a su nivel, nunca al correspondiente a niveles superiores o inferiores. Esto permite que haya intermediarios en la comunicación que utilicen solo los niveles inferiores para transmitir el mensaje entre dos entidades de forma transparente a los niveles superiores.
Aplicación Aplicación
Presentación Presentación
Sesión Sesión
Transporte Transporte
Red Red Red
Enlace Enlace Enlace
Físico Físico Físico
Medio físico Medio físico
Figura 2.2: Comunicación según el modelo OSI con un intermediario a nivel de red
En la figura 2.2 se muestra cómo dos entidades se pueden comunicar según el modelo OSI, utilizando un intermediario. Es el caso, por ejemplo, de Internet y los 2.2. MODELO OSI 9 routers. Las flechas en línea discontinua representan la comunicación virtual que se establece entre los protocolos del mismo nivel. Este tipo de separación en niveles se consigue mediante encapsulación, una técnica, representada en la figura 2.3, que consiste en añadir las cabeceras de cada nivel a las de nivel superior, tratándolo como si fueran los datos transmitidos en este nivel.
Datos ¬nivel N
Cabecera Datos nivel N-1 ¬nivel N-1
Cabecera Datos nivel N-2 nivel N-2
Figura 2.3: Encapsulación en tres niveles
El modelo OSI diferencia siete niveles [21]:
Nivel de aplicación: Es nivel más cercano al usuario. No se preocupa de la forma en la que se transmite la información, sino que genera los datos que van a transmitirse o procesa los datos que recibe.
Nivel de presentación: Ofrece al nivel de aplicación una representación de los datos que sigue una sintaxis conocida por él. De esta forma, el nivel de aplicación puede trabajar con los datos sin necesidad de más preprocesamiento.
Nivel de sesión: Permite que los niveles superiores realicen un seguimiento de la comunicación cuando están atendiendo a varias entidades. Esto significa que dos entidades que comparten los niveles inferiores pueden iniciar sesiones distintas en un mismo servicio (nivel de aplicación).
Nivel de transporte: Se ocupa de la transmisión de la información extremo a extremo, independientemente del camino que sigue para llegar. En el nivel de transporte se diferencian dos modos:
• Modo con conexión: En este modo se establece una conexión, lo que implica que se asegura que los datos enviados lleguen a su destino en el orden correcto, sin errores y, cuando es necesario, a una velocidad inferior a un límite. Esto último es especialmente útil cuando el receptor tarda mucho en procesar los datos y no dispone de memoria suficiente para recibirlos todos a la vez y procesarlos más tarde. 10 CAPÍTULO 2. ESTADO DEL ARTE
• Modo sin conexión: En este modo no se establece conexión, por lo que no hay reordenación de paquetes ni corrección de errores a nivel de transporte. Por ello, los modos sin conexión son menos fiables pero más rápidos y más sencillos de implementar que los modos con conexión.
Nivel de red: Ofrece al nivel de transporte una interfaz tal que no deba preo- cuparse por la estructura de la red ni por los niveles inferiores. De esta forma, es posible que un mensaje pase por varios nodos a nivel de red antes de llegar a su destino (como en la figura 2.2), pero los niveles superiores funcionarán independientemente de si esto ocurre.
Nivel de enlace: Permite la transmisión de mensajes de una longitud máxima fija entre nodos que están físicamente conectados entre sí o pueden estable- cer dicha conexión física. Gracias a ello, el nivel de red puede interconectar distintos nodos que no necesariamente están conectados todos entre sí.
Nivel físico: Se ocupa de la codificación y transmisión de los datos por un medio físico (cable, ondas de radio, etc.). Permite en última instancia la co- municación.
2.3. Microcontroladores y sistemas de control
Los microcontroladores son circuitos integrados que incluyen todos los compo- nentes clásicos de un computador: memoria, CPU y periféricos de entrada/salida[35]. Sin embargo, no están diseñados para propósito general, como es el caso de los or- denadores personales, sino para tareas específicas. Por ejemplo, un automovil puede incorporar más de cien microcontroladores, cada uno con un cometido. Estos come- tidos pueden ser la gestión de la apertura y cierre de las puertas, el control dela velocidad o el de estabilidad, entre otros[10].
En los sistemas de control, los microcontoladores utilizan dispositivos sensores y actuadores. Los sensores captan información del medio y la presentan al microcon- trolador de forma que este pueda procesarla y tomar una acción que influya directa o indirectamente al valor de la variable que el sensor ha medido. Esta acción se rea- liza por medio de los dispositivos actuadores, que son dispositivos con capacidad de realizar modificaciones sobre el sistema que se está controlando. Por ejemplo, en el caso del control de velociad de un vehículo, hay sensores que miden la velocidad del mismo e informan al microcontrolador, que la procesa para calcular una consigna de control que ejecuta el motor. 2.3. MICROCONTROLADORES Y SISTEMAS DE CONTROL 11
2.3.1. Arquitecturas de microcontroladores
La arquitectura hardware de los microcontroladores se basa, como en la mayoría de computadores, en la arquitectura diseñada por Von Neumann [35]: La unidad de cálculo, la unidad de control,la memoria y los periféricos se consideran componentes separados.
ALU
Bus de instrucciones Bus de direcciones Memoria Bus de datos
Unidad de control
Periféricos
Figura 2.4: Esquema de la arquitectura de Von Neumann
La unidad de cálculo se ocupa de las operaciones aritméticas (suma, resta, multiplicación, división) y lógicas (and,or,xor). Se suele abreviar ALU por las siglas en inglés de Unidad Aritmético-Lógica.
La unidad de control gestiona la ejecución del programa: Decodifica las instrucciones almacenadas en la memoria y asegura que se ejecuten en el orden preciso.
La memoria es el almacén para las instrucciones y los datos. Esto significa que la unidad de control tiene que leer de la memoria las instrucciones a ejecutar y, en algunas de estas instrucciones, escribir nuevos datos en ella.
Los periféricos forman una interfaz entre el computador y otros sistemas. En un ordenador personal, estos otros sistemas suelen ser el disco duro, el teclado, el ratón, etc. Sin embargo, los periféricos más habituales para los microcontroladores son sensores y actuadores.
Estos componentes se comunican entre sí mediante tres buses: uno para instruc- ciones, otro para direcciones y otro para datos. 12 CAPÍTULO 2. ESTADO DEL ARTE
ARM
La arquitectura ARM es un caso particular de arquitectura Von Neumann que tiene la particularidad de utilizar un conjunto reducido de instrucciones. Esto sig- nifica que puede entender pocas instrucciones distintas. A consecuencia de ello, el circuito lógico necesario para decodificarlas y ejecutarlas es más sencillo y ocupa menos superficie que en procesadores con conjuntos más complejos de instrucciones. Por tanto, necesita menos transistores y tiene un menor consumo de energía.[24]
Harvard
La arquitectura Harvard es una modificación de la arquitectura Von Neumann en la que los datos y las instrucciones se ubican en sistemas de memoria distintos. Esto permite ejecutar una operación de lectura o escritura en memoria al mismo tiempo que se obtiene la siguiente instrucción a ejecutar. Evita así el cuello de botella que suponen las operaciones sobre la memoria en la arquitectura Von Neumann.[32]
2.4. Internet of Things
Llamamos “Internet of Things” (IoT) a las redes que involucran objetos que tradicionalmente no han estado conectados entre sí. Con la miniaturización de los sensores y el hardware de comunicaciones, en los últimos años se ha vuelto cada vez más sencillo conectar todo aquello que esté asociado a un microcontrolador. Así, en el mundo de la electrónica de consumo se pueden encontrar desde microondas hasta vehículos, pasando por frigoríficos y aspiradoras automáticas, todos conectados a Internet, lo que permite monitorizarlos y controlarlos desde cualquier lugar.
La potencia de cómputo de los dispositivos, sin embargo, es variada. Esto significa que pueden contener desde procesadores de apenas 50 o 100 millones de operaciones por segundo para pequeños sensores que funcionan con batería hasta procesadores avanzados con varios núcleos y unidades auxiliares de procesamiento para procesa- miento de vídeo en tiempo real y que pueden llegar a más de 10000 millones de operaciones por segundo [34]. Esto define un escenario muy heterogéneo y, para el problema que nos ocupa, establece límites en la complejidad de los algoritmos criptográficos. A continuación se detallan algunos de los microcontroladores que se utilizan. 2.4. INTERNET OF THINGS 13
2.4.1. Raspberry Pi Zero W
La placa Raspberry Pi Zero W se trata de un pequeño ordenador con un micro- controlador BCM2835[5], que tiene una arquitectura ARM y una frecuencia de reloj de 1 GHz. Soporta comunicación wifi 802.11b/g/n, Bluetooth 4.1 y Bluetooth Low Energy sin necesidad de añadir más periféricos [20].
Figura 2.5: Raspberry Pi Zero
Tiene una capacidad de 512 MB de memoria principal y almacenamiento en tarjeta SD.
2.4.2. ESP32
Los chips ESP32 son microcontroladores con hardware de comunicaciones inte- grado. Su frecuencia de reloj oscila entre los 80 y los 240 MHz y 520 KB de memoria principal, así como 448 KB de memoria ROM y entre 2 y 4 MB de flash [6]. El micro- controlador que utiliza es un sistema con dos CPUs Xtensa LX6[33] con arquitectura Harvard.
Figura 2.6: Módulo ESP32 14 CAPÍTULO 2. ESTADO DEL ARTE
Otra característica interesante para el problema que pretendemos resolver que tienen estos microcontroladores es aceleración hardware [15] para algoritmos cripto- gráficos tales como AES, SHA-2,RSA y ECC,[6] así como un generador de números aleatorios.
2.5. Comunicación por radio
Llamamos radio a la comunicación mediante ondas electromagnéticas, es decir, variaciones en un campo electromagnético. La información se introduce en una señal portadora modificando (modulando) de forma sistemática alguno de sus parámetros de forma que, cuando se recibe una señal, se puede recuperar la información que transporta (señal moduladora) efectuando operaciones sobre la señal recibida.
Las ondas tienen tres parámetros:
Frecuencia: Es la cantidad de ciclos que realiza la onda por unidad de tiempo. Es inversamente proporcional a la longitud de onda, que es la distancia entre dos máximos o mínimos consecutivos en la función de la onda.
Amplitud: Es la variación máxima del campo electromagnético, es decir, el máximo valor que toma la función de la onda.
Fase: Es la intensidad del campo magnético en un instante dado, es decir, el valor que toma la función en dicho punto.
Como se muestra en la figura 2.7, una señal modulada en AM (Amplitud Mo- dulada) lleva la información de la moduladora en los cambios de amplitud de la portadora, mientras que una señal modulada en FM (Frecuencia modulada) lleva la información en los cambios de frecuencia.
El medio electromagnético está contaminado por ruido, que modifica la señal añadiendo pequeñas modificaciones aleatorias a la onda. Esto supone un problema puesto que, si la intensidad del ruido es suficientemente parecida a la de la señal, esta resulta imposible de extraer. Sin embargo, algunos métodos de modulación aportan una cierta tolerancia al ruido a la transmisión.
2.5.1. Modulación digital
Los métodos de modulación digital tienen la particularidad de que su señal mo- duladora toma valores discretos. Esto significa que en cada uno de sus puntos toma un valor que se puede entender como un número natural o una secuencia de bits. Por 2.5. COMUNICACIÓN POR RADIO 15
Figura 2.7: Modulación de señales en amplitud y frecuencia ello, es posible recuperar una señal digital contaminada con cierto nivel de ruido: basta con establecer umbrales entre los cuales se considera que la señal toma un valor discreto concreto.
Figura 2.8: Contaminación con ruido de una señal digital
La señal de la figura 2.8 muestra cómo puede ser una señal digital contaminada. Se puede observar que la señal digital original podría recuperarse a partir de la señal contaminada. Esto no ocurre con las señales analógicas, ya que al tomar valores continuos no se puede diferenciar si una variación es fruto de la modulación o del ruido.
Múltiplex por división de frecuencias ortogonales
El múltiplex por división de frecuencias ortogonales (OFDM por Orthogonal Frequency-Division Multiplexing) es un tipo de modulación digital en el que una señal digital se transmite en paralelo usando varias portadoras [17]. 16 CAPÍTULO 2. ESTADO DEL ARTE
El hecho de que las frecuencias sean ortogonales conlleva que las portadoras no interfieren entre ellas, permitiendo que cada una se pueda demodular y decodificar en paralelo e incrementando la resistencia al ruido.
Por otra parte, al utilizarse varias portadoras, cada uno de los valores transmi- tidos se puede mantener durante más tiempo que con una sola portadora. Esto se debe a que la información se envía en paralelo, por lo que se pueden transmitir y recibir varios valores en el mismo instante. A consecuencia de ello, se pueden trans- mitir los datos a una velocidad inversamente proporcional al número de portadoras, manteniendo la velocidad total de transmisión.
Esto proporciona otra ventaja importante: la resistencia al multitrayecto. El multitrayecto se da cuando se recibe la misma señal varias veces, con un desfase entre cada una debido a que ha tomado físicamente distintos caminos desde el emisor al receptor. Puede afectar a la transmisión si el tiempo que se desfasan las señales entre sí es parecido o superior al tiempo durante el que se transmite un mismo valor, ya que puede dar lugar a que se reciban valores distintos en el mismo instante y no sea posible diferenciar cuál es el correcto [17]. El problema se soluciona incrementando el tiempo durante el que se transmite un mismo valor, lo que no tiene por qué suponer una menor velocidad de transmisisón gracias OFDM. Además, en OFDM se añaden intervalos de guarda entre la transmisión de cada valor. En estos intervalos de guarda no se transmite nada y permiten sincronizar las señales recibidas por multitrayecto para que se lea el mismo valor de todas.
Técnicas de espectro expandido
Las técnicas de espectro expandido se aplican para que una señal dada ocupe un mayor ancho de banda, con el objetivo de hacerla más resistente a ruido o inter- ferencias, incluyendo las producidas por el multitrayecto y por otras transmisiones, tanto si utilizan estas técnicas como si no.
Existen varias técnicas de espectro expandido. Las técnicas de secuencia directa (Direct Sequence Spread Spectrum, DSSS) y de salto de frecuencia (Frequency Hop Spread SpectrumFHSS) utilizan secuencias pseudoaleatorias, ya sea para modular la portadora (como en DSSS) o para saltar de una frecuencia a otra (como en FHSS). Estas dos técnicas, originalmente desarrolladas para aportar confidencialidad a la transmisión [31][23], resultan ser efectivas para evitar interferencias [14].
Por otra parte, la técnica de espectro expandido mediante chirp (CSS) modifica la frecuencia de la portadora de forma lineal, incrementando así el rango de frecuencias que utiliza y, por tanto, su ancho de banda. 2.5. COMUNICACIÓN POR RADIO 17
2.5.2. Protocolos wireless
Wifi
Wifi es el nombre que se da al conjunto de estándares 802.11 del IEEE, diseñados para la comunicación inalámbrica en redes de área local.
Trabaja en la banda de frecuencias de los 2,4 GHz y los 5 GHz y tiene un alcance aproximado de 10 m. Las bandas de frecuencias que utiliza se dividen en canales, de forma que cada red utiliza uno solo de ellos.
En cuanto a la modulación, utiliza OFDM por sus ventajas de resistencia al ruido y al multitrayecto. Además, los nodos tratan de detectar una señal portadora antes de emitir para, en caso de encontrarla, retrasar la emisión para evitar colisiones. Este método se denomina CSMA-CA por Carrier Sense Multiple Access with Collision Avoidance.
Cada una de las redes wifi son creadas y gestionadas por un punto de acceso (AP), que hace las veces de router dentro de la propia red y de puente hacia el resto de las redes a las que esté conectado.
Conexión wireless Internet
Conexión cableada
Figura 2.9: Típica red wifi doméstica
Dado que está pensado para redes IP, podemos considerar que el tamaño máximo de su payload es el recomendado para redes IP, es decir, 576 octetos[1]. 18 CAPÍTULO 2. ESTADO DEL ARTE
LoRa
LoRa (Del inglés Long Range, Largo alcance) es un protocolo y tecnología de co- municaciones propietarios, propiedad de Semtech. El fabricante asegura que permite transmisión de datos a más de 15km.
LoRa trabaja en las bandas de frecuencias uso industrial de cada region. Así, en Europa utiliza las bandas de 433 MHz y 868 Mhz, mientras que en Estados Unidos utiliza la banda de 915 MHz.
Uiliza una versión modificada del espectro expandido mediante chirp, lo que le permite tener un mayor alcance y una mejor resistencia al ruido y a las interferencias que otros protocolos [30].
A nivel de red tiene otro protocolo propietario llamado LoraWAN, que permite crear una topología en arbol o estrella de estrellas. Está diseñado para que varios los nodos intermedios (llamados gateway) reciban datos de un mismo nodo emisor, aportando redundancia a la transmisión [7]
Tabla 2.2: Tamaño del payload en LoRa según región y frecuencia
Región Banda de frecuencias Tamaño del payload (octetos)
Europa 863-870MHz 51-230
Europa 433MHz 51-230
Estados Unidos 902-928MHz 11-230
China 779-787MHz 51-230
China 470-510MHz 51-230
Australia 915-928MHz 51-230
Corea del Sur 920-923MHz 51-230
India 865-867MHz 51-230
Rusia 864-870MHz 51-230
Como se muestra en la tabla 2.2, los mensajes enviados mediante el protocolo LoRa pueden tener por diseño un tamaño máximo de entre 51 y 230 octetos. 2.5. COMUNICACIÓN POR RADIO 19
ZigBee
ZigBee es también el nombre común de un conjunto de estándares del IEEE, en este caso, los estándares 802.15.4. Está orientado a redes de control industrial, en contraposición a wifi, que está orientado a redes de datos. Tiene un alcance de entre 10 y 100 m por diseño [9].
Trabaja en la banda de los 2.4 GHz, dividiéndola en 16 canales distintos.
En el nivel de red, Zigbee dispone del protocolo propietario Zigbee PRO, que permite crear redes con topología mesh, que admite multitud de nodos los interco- necta de forma que se obtiene una conexión fiable y con redundancia en los caminos. 20 CAPÍTULO 2. ESTADO DEL ARTE Capítulo 3
ESCENARIO DE TRABAJO
El diseño se ha realizado pensando en un escenario de monitorización de con- diciones ambientales para zonas extensas como cultivos o naves industriales. Los nodos sensores estarían alimentados por una batería, por lo que deben ser lo más energéticamente eficientes posible.
3.1. Objetivo
El objetivo es aportar tres características a la comunicación:
Integridad: Detectando modificaciones en el contenido de los paquetes.
Autenticación: Identificando a los interlocutores en la comunicación.
Frescura: Asegurando que un mensaje recibido ha sido generado en una franja de tiempo determinada.
21 22 CAPÍTULO 3. ESCENARIO DE TRABAJO
3.2. Topología de la red
Consideramos las posibles topologías que se muestran en la figura 3.1:
Estrella Anillo Completamente conexa
Sensor Actuador Concentrador
Figura 3.1: Topologías de red
Dado que vamos a utilizar criptografía asimétrica, cada pareja de nodos que estén conectados entre sí debe tener su propia clave. Por tanto, si la red es completamente conexa, el número de claves que debe haber en un sistema con n nodos es de n(n − 1) Numero de claves = 2 lo que supone un crecimiento cuadrático del número de claves con respecto a la cantidad de nodos. En las otras dos topologías, sin embargo, el número de claves tiene un crecimiento lineal respecto al número de nodos (ver figura 3.2).
Por otra parte, el camino que tiene que realizar un paquete en una red totalmente conexa siempre conlleva un solo salto, puesto que todos los nodos están conectados a todos los demás. Un caso similar se da con la topología en estrella, en la que el camino conlleva máximo dos saltos: como todos los nodos están conectados al nodo central, el primer salto sería del nodo externo emisor al nodo central y el segundo del nodo central al nodo externo receptor. Sin embargo, para la topología en anillo, en el peor de los casos el nodo receptor está en la posición opuesta al nodo emisor, n por lo que el camino que haría el paquete tendría 2 saltos (ver figura 3.3).
Además, tanto la topología en anillo como la completamente conexa conllevan una dificultad añadida en la gestión de las claves simétricas: Cuando se añade un nodo al anillo, sus nodos vecinos tienen que deshechar la clave que compartían entre 3.2. TOPOLOGÍA DE LA RED 23
Figura 3.2: Número de claves en el sistema en función del número de nodos en la red para las distintas topologías
Figura 3.3: Número máximo de saltos que debe dar un mensaje en función del número de nodos en la red para las distintas topologías si, además de negociar otra clave con el nodo nuevo. Por otra parte, cada vez que se añade un nodo a una red completamente conexa es necesario que negocie una clave con cada uno de los nodos ya presentes.
La topología en estrella permite que los nuevos nodos negocien una clave sim- plemente con el nodo central. No obstante, el nodo central estará sobrecargado y constituirá un punto único de fallo, dado que todos los mensajes pasan por él.
Consideramos que la topología que más ventajas ofrece en nuestro caso es la estrella, con el concentrador como nodo central. Normalmente este concentrador estaría conectado a otros y/o a Internet, pero para el problema que nos ocupa lo 24 CAPÍTULO 3. ESCENARIO DE TRABAJO importante es la comunicación entre los nodos externos con el concentrador. Estos nodos externos pueden ser sensores o actuadores. Los sensores toman información del entorno y la comparten, por lo que serán fundamentalmente emisores en la comunicación, en la que el concentrador sería receptor. Por otro lado, los actuadores reciben una orden desde el concentrador para ejecutar una acción, por lo que el concentrador será el emisor y los actuadores serán los receptores.
3.3. Atacante
Para diseñar y probar la seguridad del sistema, se ha hecho una serie de suposi- ciones sobre las capacidades del atacante. El atacante es capaz de:
Interceptar y leer todos los mensajes enviados por radiofrecuencia.
Almacenar los mensajes durante un tiempo indefinido.
Inyectar mensajes en la red de forma que no se puedan diferenciar de uno legítimo.
Tener conocimiento sobre la estructura del paquete en todos los niveles de la pila de protocolos de comunicaciones.
Estar lo suficientemente cerca de los nodos para modificar artificialmente al- guna de las magnitudes que miden, controlando así los datos que se enviarán en el siguiente paquete.
Producir suficiente ruido para que la comunicación por radio sea imposible.
Interceptar mensajes de forma que el atacante los lea pero no lleguen al destino.
Sin embargo, no puede:
Conocer las claves secretas a priori.
Acceder físicamente al concentrador.
De esta forma, el atacante puede efectuar ataques de repetición o replay, en los que reenvía un mensaje que fue válido anteriormente con el fin de que el sistema lo acepte de nuevo.
Otro ataque que podría realizar es la simple modificación de un mensaje con la intención de que el sistema reciba unos datos incorrectos. Capítulo 4
SOLUCION PROPUESTA
Se propone un protocolo que se situaría en el nivel de transporte dentro del modelo OSI. Esto permite trabajar sólo con los extremos de la comunicación y abstraer los niveles inferiores, abstrayendo por tanto las interconexiones físicas de los dispositivos. Además, permite aprovechar el nivel de red propio de cada tecnología de comunicación inalámbrica (ver sección 2.5.2). Por simplicidad, se ha elegido que dicho protocolo no esté orientado a conexión, dejando dos posibilidades claras para que la comunicación funcione correctamente: La primera es asegurarse de que cada paquete es independiente de los demás, mientras que la segunda es gestionar la ordenación y el control de flujo en los niveles superiores. Cabe destacar que los datos enviados en redes de sensores son de pequeño tamaño, por lo que en la mayoría de casos podría aplicarse la primera de las posibilidades.
En nuestra red, el concentrador se situaría en el nodo central, por lo que todos los demás nodos se comunicarían con él. Para que dicha comunicación pueda tener características de autenticación y frescura, ambas entidades deben negociar una clave (proceso de alta alta) que utilizarán para intercambiar mensajes (proceso de operación) hasta que caduque. Una vez haya caducado pueden ocurrir dos cosas: O bien se renueva la clave o bien el nodo se da de baja en el sistema y se deshecha.
Las soluciones que proponemos para cada uno de los objetivos (ver 3.1) son las siguientes:
Para la integridad y autenticación utilizamos firmas digitales. Para que esto funcione, es necesario que no haya nunca dos mensajes iguales firmados con la misma clave. Esto se debe a que si el sistema aceptase mensajes iguales, un atacante podría grabar un mensaje legítimo y reproducirlo para engañar al sistema. Además, para evitar que un atacante pueda realizar trabajo para construir un mensaje futuro, añadimos a nuestro mensaje una sección que varía de forma predecible para las entidades legítimas, pero impredecible para una tercera parte no autorizada. Si las entidades legítimas tienen alguna forma de predecir el contenido de esta sección
25 26 CAPÍTULO 4. SOLUCION PROPUESTA no sólo en el mensaje inmediatamente posterior, sino en todos los demás, puede implementarse la frescura, ya que se podría asegurar que un mensaje A ha sido creado después de otro B y, por tanto, que A no es más antiguo que B.
4.1. Alta de un nodo
El proceso de alta de un nodo tiene como objetivo añadir dicho nodo a la red. Para ello, el nuevo nodo debe negociar una clave simétrica con el concentrador, así como obtener una identidad o dirección única.
Como el concentrador es el único que tiene información sobre todos los demás nodos que hay en la red, es el único que puede generar identificadores asegurando que sean únicos. Por ello, se le asigna la tarea de asignar un identificador a cada nuevo nodo.
Como se ha explicado en la sección 2.1, para intercambiar una clave simétrica es necesario depositar confianza sobre alguno de los elementos de la comunicación. En nuestro caso, hemos decidido utilzar un canal seguro. Consideramos seguro cualquier canal en el que tengamos control tanto sobre los extremos como sobre el enlace entre ellos. Asi, consideraríamos segura cualquier conexión mediante un cable corto entre el nuevo nodo y el concentrador. Debido a la simplicidad de la comunicación necesaria para el alta (comunicación uno a uno en un entorno con muy poco ruido), y dado que la mayoría de microcontroladores disponen de una interfaz para ello nos basta con una conexión serie para realizar la comunicación.
Nodo Concentrador
Genera número Rn aleatorio de tamaño Asigna al nuevo nodo suficiente: Rn un número de identificación de 16 bits: IDn Genera un número aleatorio de tamaño suficiente: Rc IDn¬ || Rc Calcula Calcula Mnc=xor(Rc,Rn) Mnc=xor(Rc,Rn) y lo Guarda la tupla
Figura 4.1: Intercambio de mensajes en el alta de un nuevo nodo
Como puede observarse, los nodos generan, intercambian y mezclan mediante una operación XOR dos números aleatorios para generar el material Mnc del que se extraerán las claves criptográficas que aportarán la seguridad al sistema. Dicha 4.2. OPERACIÓN DEL NODO 27 extracción se realiza dividiendo el material en partes del tamaño necesario. Aquí, “de tamaño suficiente” quiere decir que permite extraer todas las claves necesarias sin que una se superponga con la otra. Es decir, si se necesitasen dos claves de 32 bits, el “tamaño suficiente” sería como mínimo de 32 bits × 2 claves =64bits. En este caso, la primera clave serían los 32 primeros bits de Mnc, mientras que la segunda clave estaría formada por los bits 33 a 64.
En nuestro caso, necesitamos una clave Kc para las operaciones de cifrado y un material Kh para generar la clave de firma (ver sección 4.2.2). Su tamaño dependerá de la elección de algoritmos criptográficos (ver sección 4.4.1).
Además de acordar una clave, el concentrador asigna y comunica al nuevo nodo un identificador único de 16 bits (IDn). El nodo utilizará este identificador cada vez que se comunique con el concentrador para que este sepa qué clave utilizar en el descifrado y en la comprobación de la firma.
4.2. Operación del nodo
Al principio de la sección 4 se ha explicado que se necesita una secuencia en la que no se repitan dos valores y que sea predecible para una entidad legítima pero impredecible para una tercera parte. La solución a este problema que hemos encon- trado es emplear un contador cifrado: Las partes legítimas pueden descifrarlo para compara los números de secuencia de dos mensajes, pero una entidad no autorizada no puede averiguar el siguiente valor que tomará el contador a no ser que conozca la clave.
4.2.1. Formato del mensaje
Las cabeceras del protocolo propuesto aportan información para que el destina- tario pueda verificar la autenticidad, integridad y frescura del paquete.
! "
# $
Figura 4.2: Formato del mensaje 28 CAPÍTULO 4. SOLUCION PROPUESTA
ID dispositivo: Número de 16 bits que identifica al nodo frente al concen- trador. Por tanto, debe ser único para cada dispositivo. Como se ha visto en la sección 4.1, este identificador lo asigna el concentrador. Esto es así para asegurar que no haya dos nodos con el mismo identificador.
Número de secuencia cifrado: Es el contador que se presenta al principio de esta sección. Como se ha explicado en la sección 4, se utiliza para que no haya dos mensajes iguales, y se cifra para que los cambios en el mensaje no sean predecibles.
Longitud del mensaje: Campo para representar la longitud de los datos en octetos, permitiendo así que el receptor pueda calcular el punto en el que comienza la firma digital.
Padding: Campo con valor forzado a 0 para alinear el mensaje a bytes.
Datos: Contenido del mensaje del nivel superior. Tiene tamaño variable y en la capa de transporte no se cifra, pero podría implementarse cifrado a nivel de aplicación.
Firma digital del mensaje, de tamaño fijo y generada como se muestra en la sección 4.2.2.
4.2.2. Firmado del mensaje
Para generar la firma digital del mensaje, se calcula el HMAC de todo el paquete que se puede conocer a nivel de transporte, es decir, de todo lo que se muestra en la figura 4.2.
El proceso de obtención del mensaje firmado es como se muestra a continuación:
1. Se cifra el número de secuencia n con la clave Kc dos veces seguidas, obteniendo c c c n1 de cifrar n y n2 de cifrar n1. El primero de los criptogramas se incorporará a las cabeceras del mensaje como número de secuencia cifrado, mientras que el segundo se utilizará en la clave de firma para todo el paquete.
2. Se calcula la longitud l del mensaje a enviar, representando dicho valor en un número de 12 bits.
3. Se recupera el identificador del dispositivo IDn que se configuró durante el proceso de alta.
4. Se construye el mensaje sin autenticar
c U = IDn||n1||l||DATOS 4.2. OPERACIÓN DEL NODO 29
c 5. Se construye la clave de autenticación a partir n2 obtenido en el paso 1 y el material Kh derivado del Mnc que se produjo en el proceso de alta
c Kauth = n2||Kh
6. Se calcula la firma digital AUT H del mensaje sin autenticar U utilizando Kauth como clave.
7. Se construye el mensaje firmado concatenando U||AUT H
4.2.3. Comprobación de la firma
El proceso para verificar la integridad, autenticación y frescura del mensaje sigue los siguientes pasos:
1. Se leen los primeros 16 bits del mensaje, que constituyen el identificador único del remitente. Se comprueba que se trate de un identificador conocido y, si no lo es, se descarta el mensaje, rechazándolo.
c 2. Se lee el número de secuencia cifrado n1 en los siguientes 24 bits del mensaje. Se descifra con la clave Kc para obtener n y se cifra con la misma c clave para obtener n2. 3. Si el número de secuencia n no es mayor que el último número de secuencia re- cibido por el remitente de este mensaje, se marca dicho nodo para resincronizar el número de secuencia.
4. Se leen los siguientes 12 bits del mensaje para conocer su longitud l.
5. Se extraen del mensaje todos los octetos que no pertenecen a la autenticación, es decir los N =16+24+12+(l × 8) primeros bits, obteniendo el mensaje sin autenticar U.
c 6. Se construye la clave de autenticación a partir n2 obtenido en el paso 2 y el material Kh derivado del Mnc que se produjo en el proceso de alta
c Kauth = n2||Kh
7. Se calcula la firma digital AUT H1 del mensaje sin autenticar U utilizando Kauth como clave.
8. Se extrae la firma digital AUT H2 del mensaje recibido leyendo tantos bits como dicha firma ocupe a partir de bit en la posición N calculada en el paso 5.
9. Se comparan las dos firmas AUT H1 y AUT H2. Si son distintas se rechaza el mensaje. 30 CAPÍTULO 4. SOLUCION PROPUESTA
10. Si las firmas son iguales y se había marcado el remitente para una sincroniza- ción, se lleva a cabo el proceso de resincronización descrito en la sección 4.2.4 y se rechaza el mensaje. 11. Si las firmas son iguales y no se había marcado el remitente para una sicro- nización, consideramos que el mensaje proviene realmente del remitente con identificador IDn, que no ha sufrido cambios y que es más reciente que el último de los mensajes que se recibió del mismo remitente, por lo que se pasa su contenido al protocolo de nivel superior.
4.2.4. Resincronización del contador
En algunos casos es inevitable que haya discrepancias en el número de secuencia que guardan cada uno de los interlocutores. Por ejemplo, un microcontrolador que sólo tiene disponible memoria volátil inicializará a 0 su contador cada vez que se encienda después de haber perdido energía. También puede ocurrir que se pierdan mensajes, por lo que dos valores contiguos en la secuencia que recibe el receptor no tienen por qué tener diferencia de una unidad.
Por estas razones, es necesario disponer de una manera de sincronizar los con- tadores de ambas partes. El caso de que se pierdan mensajes se resuelve de forma sencilla: Cada vez que se reciba un mensaje correcto, se toma nota de su número de secuencia y sólo se toman como correctos los mensajes posteriores con un número de secuencia estrictamente superior a él.
El caso de que el emisor tenga un número de secuencia menor que el receptor no es tan sencillo: es necesario algún mecanismo para que el receptor notifique al emisor esta discrepancia y conseguir que actualice su número de secuencia. Nosotros proponemos responder al remitente con un mensaje vacío, autenticado mediante el método explicado en la sección 4.2.2. De esta forma, el nodo emisor realizaría las siguientes acciones en el proceso completo de transmisión de un mensaje:
1. Construir el mensaje como se ha mostrado en la sección 4.2.2. 2. Envíar el mensaje 3. Esperar resupuesta durante un tiempo definido por el usuario. 4. Si dicho intervalo temporal expira, finalizar. 5. Si se recibe una respuesta dentro del intervalo temporal, comprobar que el mensaje sea correcto según los pasos descritos en la sección 4.2.3. 6. Si el mensaje recibido es correcto, comprobar si su número de secuencia n es mayor que el guardado en el estado interno. Si lo es, guardar n+1 en el estado interno y finalizar. 4.3. BAJA DE UN NODO 31
El hecho de que el nodo compruebe que el número de secuencia recibido sea mayor que el guardado evita que se fuerce el valor del contador utilizando ataques de replay: al ser una secuencia estrictamente creciente, un mensaje de actualización enviado con anterioridad siempre va a tener un número de secuencia menor al del estado interno, por lo que no forzaría la actualización del contador nodo.
4.3. Baja de un nodo
Cuando el contador de mensajes llega a su máximo, consideramos que las claves han caducado, por lo que no se pueden seguir utilizando. En ese momento se puede dar de baja el nodo y deshecharlo o renovarle la clave para que pueda iniciar una nueva secuencia.
Para dar de baja el nodo basta con marcarlo como inactivo en el concentrador. El concentrador rechazará cualquier mensaje que provenga de un nodo inactivo o desco- nocido, por lo que el proceso de baja protege contra la posibilidad de que un atacante se haga con un nodo deshechado para generar datos aparentemente legítimos en la red. Además, al ser una operación que realiza el concentrador unilateralmente, sigue siendo posible dar de baja un nodo que haya dejado de funcionar. Una vez dado de baja un nodo, su identificador podría asignarse de nuevo a otro nodo en un proceso de alta posterior. p La renovación de la clave no es más que una operación de baja seguida de una de alta. Esto quiere decir que el número identificador del nodo po- dría cambiar también, pero no supone un problema más allá de una sobrecarga en el receptor.
4.4. Elección de algoritmos criptográficos
Dada la limitada capacidad de procesamiento para la que se ha diseñado el pro- tocolo, hemos decidido utilizar unos algoritmos lo más ligeros posible. Para ello, hemos tomado como ejemplo a seguir el protocolo Adiantum de Google [16], un procolo criptográfico orientado al cifrado y firma de sistemas de ficheros para dispo- sitivos de baja potencia de cómputo que utiliza ChaCha20 como cifrador y Poly1305 como función HMAC. Este protocolo, al igual que el nuestro, se ha diseñado con la velocidad y la eficiencia en mente, por lo que consideramos merecedores de nuestro interés los algoritmos criptográficos que utiliza. Según los datos de google, mostrados en la figura 4.3, este algoritmo es aproximadamente cinco veces más rápido más. La gráfica se ha elaborado calculando la velocidad a la que se cifraban y descifraban bloques de 4096 bits en un procesador ARM Cortex-A7.
Como complemento, hemos realizado una prueba en la que se cifra 10000 veces un 32 CAPÍTULO 4. SOLUCION PROPUESTA
Figura 4.3: Intercambio de mensajes en el alta de un nuevo nodo. Fuente: Google contador de 1024 bits para comparar ChaCha20 con AES256 en un procesador AVR ATMega328P. Como resultado, el cifrado con ChaCha20 requiere aproximadamente la mitad de tiempo y, por lo tanto, menos potencia de cómputo. Los resultados se muestran en la tabla 4.1.
Tabla 4.1: Comparación entre ChaCha20 y AES256
Cifrado Tiempo invertido (Microsegundos)
AES256 92232.83
ChaCha20 47350.32
Además el uso de un cifrador de flujo como ChaCha20 permite utilizar un con- tador de cualquier tamaño, al no tener un input de gran tamaño. Por otra parte, la función HMAC Poly1305 ofrece un output de 16 bytes, limitando poco el tamaño del payload util del mensaje.
Así, resulta ventajoso utilizar ChaCha20 y Poly1305 en nuestro protocolo. 4.5. LIMITACIONES 33
4.4.1. Longitud de las claves
Como ya se ha explicado en la sección 4.1, la longitud de los números aleatorios que tomen los dos nodos al presentarse depende de la longitud de las claves que se utilicen. Estas claves dependen de los algoritmos elegidos, y en este caso necesitamos para ChaCha20 una clave de 128 o 256 bits y un vector de inicialización de 64 bits, mientras que Poly1305 utiliza una clave de 256 bits. Dado que nuestro contador ocupa 24 bits, nos basta con generar 232 bits para la firma (Kh) y 320 bits para el cifrado (a repartir 256 bits para la clave Kc y 64 bits para el vector de inicialización)
4.5. Limitaciones
El protocolo propuesto tiene las siguientes limitaciones:
Por el tamaño del identificador, las redes pueden tener un máximo de 216 = 65536 nodos, incluido el concentrador.
Por el tamaño del contador, cada nodo puede enviar 224 = 16777216 mensajes. Esto significa que podría funcionar un año enviando de media un mensaje cada 1.83 segundos.
Se rechazarán mensajes que hayan sufrido alteraciones no maliciosas, como las que se puedan dar por ruido en el canal.
Aunque el protocolo protege la autenticidad de los mensajes, no evita que se realice un ataque de denegación de servicio mediante inundación del canal o mediante la imposición de barreras físicas (como jaulas de Faraday) a los nodos emisores.
Asimismo, tampoco protege contra la alteración artificial de las condiciones que perciben los nodos sensores (por ejemplo, acercar un objeto caliente a un sensor de tempratura).
El protocolo utiliza 23 octetos de cabeceras y autenticación, lo que puede dejar un espacio reducido para el mensaje. Por ejemplo, dejaría 30 octetos en algunos supuestos de LoRa (ver tabla 2.2).
El protocolo no permite diferenciar los ataques por repetición de la desincro- nización de los contadores, por lo que siempre se va a responder a este tipo de ataques con intentos de volver a sincronizar. 34 CAPÍTULO 4. SOLUCION PROPUESTA
4.6. Pruebas
Hemos realizado una serie de pruebas para comprobar el funcionamiento correcto del protocolo. Partimos de un escenario con dos nodos ya presentados y comproba- mos cómo funciona el protocolo durante el intercambio de mensajes.
Debido a los recursos disponibles, las pruebas de comunicación se han efectuado sobre una red wifi con dos PC y un punto de acceso. Uno de los PC actuaba como concentrador, mientras que el otro hacía las veces de dispositivo emisor.
Concentrador: Dispositivo: 192.168.1.10 192.168.1.134
Figura 4.4: Escenario para las pruebas del protocolo
Para realizar las pruebas hemos desarrollado un prototipo en un lenguaje de alto nivel con una interfaz similar a la de un socket.
Funcionamiento sin ataques y con las secuencias sincronizadas
En esta prueba se ha verificado que el protocolo permite enviar y recibir mensajes sin rechazar los mensajes legítimos. Además, partimos de números de secuencia sincronizados y no perdemos ningún paquete.
Hemos utilizado la herramienta Wireshark para observar los paquetes intercam- biados.
En la figura 4.5 se muestra la captura de una trama en la interfaz de Wireshark. Se han marcado partes del paquete para facilitar su comprensión.
Recuadradas en rojo se pueden ver las cabeceras IP de dirección de origen y destino, que la herramienta ha decodificado automáticamente. A continuación, entre el recuadro rojo y el azul, podemos observar los dos oc- tetos que representan el identificador del remitente. En este caso, el remitente tiene identificador 1. 4.6. PRUEBAS 35
Figura 4.5: Trama correcta
El recuadro azul señala los tres octetos que ocupa el número de secuencia o contador cifrado. En este caso tiene un valor 2.
Los dos octetos posteriores al recuadro azul representan la longitud del conte- nido.
Los recuadros verdes señalan el contenido del mensaje. En este caso, se trata del texto “Mensaje de prueba” codificado en ASCII.
Finalmente, los octetos entre el final del recuadro verde y el final del paquete constituyen la firma digital del mismo
En adelante se utilizará el mismo código de colores explicado en esta prueba.
Sincronización de las secuencias
Para ejecutar esta prueba forzamos el número de secuencia de uno de los dispo- sitivos primero a ser inferior que el del otro y luego superior. Cuando el contador del emisor es mayor que el del receptor, este actualiza el suyo sin enviar más men- sajes, mientras que si el del remitente es menor, se intercambian más mensajes para sincronizar de nuevo.
En este caso, la trama que se muestra en la figura 4.6 tiene un valor de 7 en el contador, mientras que el receptor espera un número no menor que 40000. Ante esta situación, el receptor de la primera trama responde con un mensaje sin datos, en el que aparece el nuevo valor que debe tomar el contador. El contenido de dicha trama se puede ver en la figura 4.7 36 CAPÍTULO 4. SOLUCION PROPUESTA
Figura 4.6: Trama con el contador erróneo
Figura 4.7: Trama de sincronización
Ataque de modificación
Para esta prueba simulamos la situación en la que un atacante modifica un pa- quete enviado por el emisor legítimo para que los datos que transmita sean diferentes a los que este pretendía transmitir.
El atacante ha capturado el paquete mostrado en la figura 4.8, de forma que el que debería ser el receptor legítimo no lo ha podido recibir y, por tanto, el número de secuencia del receptor no ha sido incrementado.
Figura 4.8: Paquete capturado por el atacante y que será modificado
El mensaje lleva el texto “Este mensaje no llega al receptor” codificado en AS- CII. El atacante lo modifica sin cambiar su longitud por “Este mensaje si llega al receptor”, generando así el paquete mostrado en la figura 4.9. Tras generar dicho paquete, lo envía al receptor legítimo.
Figura 4.9: Paquete modificado por el atacante
El receptor legítimo comprueba la firma del paquete y lo rechaza. A título infor- mativo, la figura 4.10 muestra el paquete con el mismo número de secuencia y mismo 4.6. PRUEBAS 37 mensaje que el que envió el atacante, pero enviado por el remitente legítimo. Si se compara con la figura 4.9, puede observarse que las firmas digitales son diferentes.
Figura 4.10: Paquete correcto
Ataque de repetición
Para esta prueba simulamos un ataque por repetición: el atacante graba un mensaje y lo reproduce posteriormente para hacer creer al sistema que se trata de un mensaje legítimo. Según nuestro diseño, el mensaje se ignoraría y se enviaría el paquete para la resincronización.
Figura 4.11: Paquetes involucrados en el ataque por repetición
En la figura 4.11 se muestra que se han intercambiado tres paquetes. Los dos primeros (marcados en rojo) proceden aparentemente del nodo emisor y contienen el mensaje “Prueba” codificado en ASCII en la sección de datos como se muestra en la figura 4.12.
Figura 4.12: Paquete repetido en el ataque por repetición
El tercero de los paquetes, marcado en verde en la figura 4.11, es un paquete de sincronización cuyo contenido puede verse en la figura 4.13
Figura 4.13: Trama de sincronización
El hecho de que se haya respondido con un paquete de sincronización implica que el mensaje repetido ha sido rechazado. 38 CAPÍTULO 4. SOLUCION PROPUESTA Capítulo 5
CONCLUSIONES Y LÍNEAS FUTURAS
5.1. Conclusiones
Se ha presentado un protocolo para proteger la autenticidad, integridad y fres- cura de los mensajes en un entorno de dispositivos de baja potencia de cómputo conectados entre sí mediante protocolos que utilizan las ondas de radio como su medio físico.
Para proteger la autenticidad e integridad de los mensajes se utiliza una firma digital. Esta firma depende de una clave secreta conocida sólo por el emisor y el receptor, por lo que no es posible que una tercera parte suplante al emisor creando mensajes nuevos, ya que no podría firmarlos.
Por otra parte, si no se añadiera nada más, dos mensajes con el mismo contenido tendrían también la misma firma digital, por lo que un atacante podría grabar men- sajes antiguos y reproducirlos, haciendo que el sistema los aceptase como buenos. Es lo que se conoce como un ataque de replay. Para evitar esto se introduce un elemento tal que es distinto en cualquier pareja de mensajes cualesquiera. De esta forma, la firma siempre será diferente. Esto se consigue utilizando un contador o número de secuencia, lo que permite además asegurar que un mensaje recibido es posterior a los recibidos con aterioridad, puesto que debe tener un número de secuencia superior.
Lo expuesto en los dos párrafos anteriores resulta efectivo para resistir tanto ataques de repetición como de modificación del contenido del mensaje. Para los algoritmos criptográficos se ha usado ChaCha20 para los cifrados y Poly1305 para las firmas digitales.
39 40 CAPÍTULO 5. CONCLUSIONES Y LÍNEAS FUTURAS
5.2. Líneas futuras
Comunicación de un dispositvo a muchos aprovechando que, por las caracte- risticas del canal, todos podrían recibir el mensaje al mismo tiempo
Registro de un mismo dispositivo en varios concentradores, para aportar re- dundancia en la red.
Negociación de contraseñas mediante criptografía asimétrica para los dispo- sitivos que tengan suficiente potencia, manteniendo una red con dispositivos con gestión heterogénea de las claves.
Modificación del protocolo para permitir el establecimiento de conexiones. Esto implicaría asegurar que un mensaje dado llega a su destino y que si se dividen los datos en varios paquetes, estos lleguen en el orden correcto. Bibliografía
[1] Rfc 791: Internet protocol, 1981. [Online; Accedido el 1 de Abril de 2019].
[2] Rfc 2104: Hmac: Keyed-hashing for message authentication, 1997. [Online; Accedido el 1 de Abril de 2019].
[3] Rfc 2144: The cast-128 encryption algorithm, 1997. [Online; Accedido el 1 de Abril de 2019].
[4] Rfc 4132: Addition of camellia xipher suites to transport layer security, 2005. [Online; Accedido el 1 de Abril de 2019].
[5] Bcm arm peripherals, 2012. [Online; Accedido el 9 de Marzo de 2019].
[6] Esp32 series datasheet, 2019. [Online; Accedido el 9 de Marzo de 2019].
[7] LoRa Alliance. A technical overview of loraő and lorawan.
[8] Ross J. Anderson. Serpent: A candidate block cipher for the advanced encry- ption standard, 2006.
[9] Nick Baker. Zigbee and bluetooth: strengths and weaknesses for industrial applications, 2005. [Online; Accedido el 1 de Abril de 2019].
[10] Ross Bannatyne. Microcontrollers for the automobile, 2009.
[11] Nicky Barker, Elaine; Mouha. Nist special publication 800-67 revision 2: Re- commendation for the triple data encryption algorithm (tdea) block cipher, 2017.
[12] Daniel J. Bernstein. The salsa20 family of stream ciphers, 2007.
[13] Daniel J. Bernstein. The chacha20 family of stream ciphers, 2008.
[14] Steve Bible. Spread spectrum: It’s not just for breakfast anymore!, 1995.
[15] Jed Kao-Tung Chang, Chen Liu, and Jean-Luc Gaudiot. Hardware acceleration for cryptography algorithms by hotspot detection. In James J. (Jong Hyuk)
41 42 BIBLIOGRAFÍA
Park, Hamid R. Arabnia, Cheonshik Kim, Weisong Shi, and Joon-Min Gil, edi- tors, Grid and Pervasive Computing, pages 472–481, Berlin, Heidelberg, 2013. Springer Berlin Heidelberg.
[16] Paul Crowley and Eric Biggers. Adiantum: length-preserving encryption for entry-level processors. Cryptology ePrint Archive, Report 2018/720, 2018. https://eprint.iacr.org/2018/720.
[17] Mérouane Debbah. Short introduction to ofdm. White Paper, Mobile Commu- nications Group, Institut Eurecom, pages 0–1, 2004.
[18] W. Diffie and M. Hellman. New directions in cryptography. IEEE Trans. Inf. Theor., 22(6):644–654, September 2006.
[19] Shamir A. Dinur I., Dunkelman; O. Improved attacks on full gost, 2012.
[20] Raspberry Pi Foundation. Raspberry pi zero w technical specifications. [Online; Accedido el 7 de Marzo de 2019].
[21] ISO/IEC. Iso/iec 7498-1:open system interconnection - basic reference model: The basic model.
[22] Hugo Krawczyk. Cryptographic extraction and key derivation: The hkdf sche- me, 2010.
[23] George Markey, Hedy Kiesler;Antheil. Us patent us2292387a: Secret communi- cation system, 1941.
[24] Farhat Masood. RISC and CISC. CoRR, abs/1101.5364, 2011.
[25] Alfred J. et. al. Menezes. Handbook of applied cryptography. CRC Press, crc press edition, 1996.
[26] Carl Mullen, Gary; Mummert. Introduction to cryptography: principles and applications. Springer, springer edition, 2007.
[27] NIST. Announcing the advanced encryption standard (aes), 2001. [Online; Accedido el 1 de Abril de 2019].
[28] Bruce Schneier. Description of a new variable-length key, 64-bit block cipher (blowfish), 1993.
[29] Bruce Schneier. Applied Criptography Protocols,Algorithms and source code in C. 1996.
[30] Semtech. Lora modulation basics.
[31] Marvin K Simon, Jim K Omura, Robert A Scholtz, and Barry K Levitt. Spread spectrum communications handbook, volume 2. Citeseer. BIBLIOGRAFÍA 43
[32] Konstantin S. Solnushkin. Harvard computer architecture, 2007.
[33] Cadence Systems. Xtensa lx6 customizable dpu. Technical report, 2016.
[34] A. Voica. A guide to internet of things (iot) processors, 2016. [Online; Accedido el 7 de Marzo de 2019].
[35] John von Neumann. First draft of a report on the edvac. IEEE Ann. Hist. Comput., 15(4):27–75, October 1993.
[36] Bruce Schneier; Doug Whiting. A performance comparison of the five aes fina- lists, 2000. Este documento esta firmado por Firmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM, C=ES Fecha/Hora Sun Jun 02 12:00:57 CEST 2019 Emisor del [email protected], CN=CA Facultad de Certificado Informatica, O=Facultad de Informatica - UPM, C=ES Numero de Serie 630 Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe Signature)