Bootstrapping seguro para IoT

Bootstrapping seguro para IoT Grado en Ingeniería Informática Convocatoria: Julio 2025 Trabajo Fin de Grado Autor: Jose Antonio López Sola Tutor: Antonio Fernando Skarmeta Gómez Cotutor: Sara Nieves Matheu García 29 de Junio de 2025 Bootstrapping seguro para IoT Autor Jose Antonio López Sola Tutor Antonio Fernando Skarmeta Gómez Ingeniería de la Información y las Comunicaciones Cotutor Sara Nieves Matheu García Ingeniería de la Información y las Comunicaciones Grado en Ingeniería Informática Murcia, 29 de Junio de 2025 Agradecimientos Este trabajo supone el punto final a mi etapa como estudiante del grado de ingeniería informática y, con ello, la obtención de un título que me acredita como ingeniero informático. Haber cumplido este objetivo no habría sido posible sin el apoyo de las personas que me rodean. Es por ello por lo que me gustaría dedicarles unas palabras: A mi familia, gracias por apoyarme y escucharme siempre que lo he necesitado. Vuestros consejos han sido aire fresco en mis peores momentos. A mi pareja, gracias por entenderme cuando ni yo mismo lo hacía, siempre has estado ahí cuando lo he necesitado. Admiro la paciencia y comprensión que has tenido conmigo. A mi abuelo, gracias por ser de los primeros en entender el esfuerzo que estaba haciendo. Tus ánimos están siempre presentes en mí. A mi amigo Fran, nunca podré agradecerte lo suficiente el apoyo que me has dado. A mi amigo Javier, no puedo estar más feliz de haber compartido contigo toda mi vida académica. A mis amigos, gracias por ofrecerme una vía de escape y diversión que me ayudase a desconectar de los estudios cuando era necesario. A los amigos que he hecho en la universidad, esta etapa ha sido más divertida gracias a vuestra compañía. El año que compartimos en Noruega jamás lo olvidaré. Por último, agradecer a todas aquellas personas que han participado en el desarrollo de este trabajo. Gracias al profesor Rafael Marín por guiarme en la elección del TFG. Gracias a Sara Nieves, Gilson, José Manuel y Pedro, por proporcionarme ayuda y material que me facilitase abordar este proyecto. Gracias al profesor Antonio Fernando Skarmeta por dirigir este trabajo, estoy muy agradecido de que entendiese mi situación personal de este año y me proporcionase un trabajo que se adaptase a estas circunstancias. Declaración firmada sobre originalidad del trabajo D./Dña. Jose Antonio López Sola, con DNI 49173017Y, estudiante de la titulación de Grado en Ingeniería Informática de la Universidad de Murcia y autor del TF titulado “Bootstrapping seguro para IoT”. De acuerdo con el Reglamento por el que se regulan los Trabajos Fin de Grado y de Fin de Máster en la Universidad de Murcia (aprobado C. de Gob. 30-04-2015, modificado 22-04-2016 y 28-09-2018), así como la normativa interna para la oferta, asignación, elaboración y defensa de los Trabajos Fin de Grado y Fin de Máster de las titulaciones impartidas en la Facultad de Informática de la Universidad de Murcia (aprobada en Junta de Facultad 27-11-2015) DECLARO: Que el Trabajo Fin de Grado presentado para su evaluación es original y de elaboración personal. Todas las fuentes utilizadas han sido debidamente citadas. Así mismo, declaro que no incumple ningún contrato de confidencialidad, ni viola ningún derecho de propiedad intelectual e industrial. Murcia, a 29 de Junio de 2025 Fdo.: Jose Antonio López Sola Autor del TF Resumen En la actualidad, la presencia de dispositivos Internet of Things (IoT) en nuestra sociedad está en aumento, pudiendo encontrarlos prácticamente en cualquier entorno. Su uso, aunque aporta grandes beneficios, también trae consigo una serie de retos a los que se debe hacer frente. Estos se deben principalmente a dos características de los dispositivos IoT: la posibilidad de manejar información sensible y su capacidad para interactuar con el entorno en el que están desplegados. Por ello, se hace necesario prestar especial interés a la securización de los dispositivos, llevando a la búsqueda de un modelo de gestión que permita asegurar su correcto funcionamiento. El objetivo del trabajo es estudiar cómo solucionar este problema. Para ello, se ha estudiado el modelo de gestión de la seguridad que está siendo planteado en la Universidad de Murcia, con el proyecto aCtive sEcurity foR connecTed devIces liFecYcles (CERTIFY). Dicho modelo busca proteger a los dispositivos durante todo su ciclo de vida, siendo una de las tareas de mayor importancia el proceso de arranque, al que se conoce como bootstrapping. Este proceso es el aspecto central de este trabajo. Su objetivo es permitir a los dispositivos obtener la información necesaria para poder trabajar de forma segura en su entorno. Para conseguir esto, el bootstrapping incluye, entre otros aspectos, realizar tareas de autenticación y autorización, que garanticen que los dispositivos desplegados en el entorno son los correctos y que las acciones que se les permite realizar están limitadas bajo ciertos criterios. Además, el bootstrapping busca dejar preparados a los dispositivos para que puedan recibir actualizaciones que mantengan el nivel de seguridad con el paso del tiempo. El cómo realizar estas actualizaciones también es estudiado en el modelo mencionado, y en este trabajo se aborda como aspecto secundario. Una vez estudiada la propuesta de la Universidad de Murcia, el trabajo propone una Proof of Concept (PoC) con el objetivo de poner a prueba ciertos aspectos del modelo. En concreto, se busca realizar el proceso de bootstrapping de un dispositivo IoT y tras este, aplicar políticas de comportamiento que limiten/controlen las acciones del dispositivo. Dichas políticas son obtenidas de ficheros que siguen el estándar Manufacturer Usage Description (MUD). Para la realización de la PoC se utiliza como dispositivo IoT una Raspberry Pi 3 Model B. vii Figura 1: Escenario IoT propuesto La figura 1muestra el escenario IoT que se plantea en este trabajo, así como los diferentes componentes necesarios para su despliegue. En particular, las entidades Bootstrapping Agent yBootstrapping-Server son las encargadas de permitir el proceso de bootstrapping del dispositivo IoT, incluyendo su autenticación. Por su parte, las entidades Enforcement and Reconfiguration Agent (ERA), Device and Domain Manager (DDM), MUD Manager y MUD Server se encargan de aplicar políticas de comportamiento, definidas en un fichero MUD, sobre el dispositivo. El resultado de la PoC ofrece un escenario que permite gestionar dispositivos IoT, securizando su configuración inicial mediante el proceso de bootstrapping, y reforzándola con la aplicación de políticas de seguridad una vez que el dispositivo ha iniciado sus operaciones. La solución planteada también proporciona beneficios al proyecto en el que se basa, CERTIFY; al haber hecho uso de componentes desarrollados en dicho proyecto, se ha podido detectar ciertos errores en las implementaciones y subsanarlos. Además, el trabajo realizado incluye una evaluación de los tiempos de ejecución de las principales actividades que se realizan en la PoC desarrollada. Se estudia tanto el tiempo empleado para completar el proceso de bootstrapping como el tiempo necesario para aplicar políticas de comportamiento. El principal resultado obtenido es que el bootstrapping es un proceso mucho más pesado, requiriendo aproximadamente seis veces el tiempo que necesita la aplicación de políticas de seguridad en el dispositivo. viii Aunque la PoC planteada no aborda la totalidad del proyecto CERTIFY, teniendo así ciertas limitaciones, supone un buen punto de partida para comprender el modelo de gestión del ciclo de vida de dispositivos IoT que propone dicho proyecto. En particular, permite tener una visión concreta de los conceptos con los que se debe trabajar y proporciona una base sobre la que poder avanzar en futuras mejoras. Extended Abstract Nowadays, the number of Internet of Things (IoT) devices is constantly increasing. In fact, we can find these devices almost everywhere. Although these artefacts are very useful, their own nature is related to some challenges that we should confront. For example, some IoT devices can interact with their environment, while others are managing sensitive information or even doing both things at the same time. This naturally highlights the importance of security in IoT systems. To address this concern, we have studied a model for managing IoT devices that is currently being developed at the University of Murcia within the European project aCtive sEcurity foR connecTed devIces liFecYcles (CERTIFY). This model proposes an approach to managing security in IoT devices; its goal is to manage their complete lifecycle, ensuring that they are working in a secure way. As part of this process, one of the main tasks is the secure boot or bootstrapping of the device, which is indeed the main focus of this work. Its purpose is to allow devices to obtain the necessary data to operate securely in their environment. To do this, bootstrapping includes, among other aspects, performing authentication and authorization tasks to ensure that the deployed devices are allowed to be in such environment, and their actions are restricted to a specific criterion. Moreover, bootstrapping prepares the devices to be able to receive updates that maintain their security level during their operational period. The procedure for carrying out these updates is also studied within the mentioned model, and in this work, it is addressed as a secondary aspect. Once the proposal from the University of Murcia and the associated technologies that it requires have been studied, the work presents a Proof of Concept (PoC) with the purpose of testing certain aspects of the model. In particular, the PoC performs the bootstrapping of an IoT device and tries to apply some behavioural policies to restrict/- control the allowed actions of the device. These policies are defined in files that follow the Manufacturer Usage Description (MUD) standard. For the testing, a Raspberry Pi 3 Model B has been used as the IoT device. To carry out this work, several components previously developed within the framework of the CERTIFY project were reused. This approach allowed us to implement the scenario more efficiently and focus on validating the key functionalities defined by the model. Developing a complete IoT environment from scratch would have been a highly complex and time-consuming task, so the reuse of existing elements was both practical Índice general 1. Introducción 1 2. Estado del arte 5 2.1. Bootstrapping de dispositivos IoT . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Modelo de bootstrapping CoAP-EAP ............... 6 2.1.1.1. Constrained Application Protocol (CoAP) . . . . . . . 8 2.1.1.2. Extensible Authentication Protocol (EAP) . . . . . . 9 2.2. Trusted Execution Environment (TEE) . . . . . . . . . . . . . . . . . . 10 2.3. Aplicación de políticas de comportamiento en dispositivos IoT . . . . . 12 2.3.1. Manufacturer Usage Description (MUD) . . . . . . . . . . . . . 13 2.3.1.1. Definición de un fichero MUD . . . . . . . . . . . . . 13 2.3.1.2. Difusión de un fichero MUD . . . . . . . . . . . . . . 13 2.3.1.3. Estructura de un fichero MUD . . . . . . . . . . . . . 14 2.3.1.4. Limitaciones de los ficheros MUD . . . . . . . . . . . 15 3. Análisis de objetivos y metodología 17 4. Diseño y resolución del trabajo realizado 19 4.1. Proceso de bootstrapping CoAP-EAP ................... 20 4.1.1. Prueba de una implementación del servidor de bootstrapping . . 20 4.1.1.1. Configuración de una Raspberry Pi 4 Model B . . . . 22 4.1.2. Actualización del servidor de bootstrapping proporcionado . . . 22 4.2. Securización de un dispositivo IoT . . . . . . . . . . . . . . . . . . . . 24 4.2.1. Prueba del proceso de bootstrapping con un cliente seguro . . . 29 4.3. Infraestructura para aplicar políticas de comportamiento . . . . . . . . 30 4.3.1. Despliegue de un ERA en un dispositivo IoT . . . . . . . . . . . 30 4.3.1.1. Prueba del ERA . . . . . . . . . . . . . . . . . . . . . 32 4.3.2. Despliegue de infraestructura para trabajar con ficheros MUD . 32 4.3.2.1. Actualización del Bootstrapping-Server ......... 33 4.3.2.2. Despliegue de un servidor que proporcione ficheros MUD 34 4.3.2.3. Despliegue de un servidor que solicite ficheros MUD . 35 4.3.2.4. Definición de un fichero MUD . . . . . . . . . . . . . 35 4.3.2.5. Coordinación de la aplicación de políticas . . . . . . . 37 4.4. Prueba de la PoC desarrollada . . . . . . . . . . . . . . . . . . . . . . . 40 5. Evaluación de la PoC desarrollada 53 xviii Índice general 6. Conclusiones y vías futuras 57 Bibliografía 60 A. Anexo I. Fichero MUD generado 64 B. Anexo II. Traducción del fichero MUD a MSPL 67 C. Anexo III. Base de datos del Device and Domain Manager 69 D. Anexo IV. Configurar SSH en una Raspberry Pi 3 Model B 71 Índice de figuras 1. Escenario IoT propuesto . . . . . . . . . . . . . . . . . . . . . . . vii 2. Proposed IoT scenario ......................... x 2.1. Interacción para el proceso de bootstrapping ............. 8 2.2. Estructura de un TEE . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Proceso de obtención de un fichero MUD . . . . . . . . . . . . . . 14 4.1. Escenario IoT a desplegar . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. PoC: Arranque de las entidades distintas al dispositivo IoT . . . . 41 4.3. PoC: Inicio del bootstrapping ..................... 42 4.4. PoC: Consecuencias del bootstrapping ................ 43 4.5. PoC: Consecuencias del bootstrapping (continuación) . . . . . . . . 44 4.6. PoC: Consecuencias del bootstrapping en el controlador central . . 46 4.7. PoC: Consecuencias del bootstrapping en el AAA server . . . . . . 47 4.8. PoC: Consecuencias del bootstrapping en el Post-Server . . . . . . 48 4.9. PoC: Consecuencias del bootstrapping en el DDM . . . . . . . . . . 49 4.10. PoC: Consecuencias del bootstrapping en el MUD Server . . . . . . 49 4.11. PoC: Consecuencias del bootstrapping en el MUD Manager . . . . 50 4.12. PoC: DDM tras aplicar el cambio de algoritmo de firma . . . . . . 51 4.13. PoC: Raspberry tras aplicar el cambio de algoritmo de firma . . . 52 5.1. Flujo del escenario IoT desplegado . . . . . . . . . . . . . . . . . . 54 5.2. Tiempos de ejecución del bootstrapping y del enforcement en la PoC 54 5.3. Desglose de los tiempos de ejecución del enforcement en la PoC . . 55 C.1. PoC: Base de datos del DDM tras completar el bootstrapping . . . 70 Índice de tablas 2.1. Limitaciones de un fichero MUD . . . . . . . . . . . . . . . . . . . . . 16 4.1. Librerías necesarias para ejecutar el servidor de bootstrapping . . . . . . 21 1. Introducción El concepto de Internet of Things (IoT) tiene cada vez más presencia en nuestra sociedad. Sin embargo, muchas veces este término es utilizado sin tener realmente claro a qué nos referimos por IoT. Por ello, dado que será el elemento central de este trabajo, es conveniente dar una introducción a este concepto y motivar por qué se ha decidido estudiarlo. Es importante tener claro que no existe una definición universal para IoT [1, 2]. Esto no quiere decir que no haya una forma de describir este concepto, simplemente cuando se trata de explicar qué es el IoT se recurre a las características que se considera que estos tipos de dispositivos poseen. En este trabajo, para dar esta definición usaremos las propiedades que remarca García Carrillo en [1]: 1. Interacción con el entorno. El IoT permite mejorar el proceso de obtención de información mediante el uso de máquinas. Estas son capaces de realizar ciertas tareas de un modo más preciso y eficiente que los seres humanos. 2. Conectividad. El IoT permite conectar a Internet dispositivos con capacidades muy diversas, desde equipos complejos hasta sensores con recursos muy limitados. Por tanto, el concepto de IoT se puede resumir en que está compuesto por dispositivos de capacidades muy variadas que son capaces de interactuar con el entorno en el que estén desplegados y de conectarse a Internet. Esto provoca que el abanico de mejoras tecnológicas a través del uso de IoT se amplíe enormemente, teniendo como consecuencia un incremento muy notorio del número de dispositivos IoT desplegados en todo el mundo. Esta tendencia queda reflejada en [3]: en 2023 se reportó la existencia de 16.6 billones de dispositivos, y en 2024 se esperaba un crecimiento hasta los 18.8 billones. Además, se pronosticó el número de dispositivos IoT desplegados entre 2024 y 2030, estimándose que, para finales del presente año, 2025, se tengan 21.5 billones. Estos datos permiten reflejar la gran relevancia del IoT en la sociedad actual. Su impacto se extiende a sectores muy diversos, como la agricultura, la industria, la medicina o el comercio, transformando el día a día de las personas mediante soluciones como las “Smart Homes”, “Smart Cities” o relojes inteligentes que permiten monitorizar la salud de las personas. 2Introducción Sin embargo, el IoT, además de sus grandes beneficios, trae consigo una serie de retos a los que se debe hacer frente. En particular, destacan los relacionados con la seguridad de los dispositivos, pues su capacidad para acceder a Internet tiene como consecuencia directa que estén expuestos a amenazas que pueden comprometer tanto su funcionamiento1como los datos2que gestionan. Esta característica junto al hecho de los dispositivos IoT están masivamente desplegados3por todo el mundo, provoca que la seguridad de los mismos sea un tema que debe ser tratado con urgencia. La protección que se debe proporcionar a los dispositivos IoT no debe abarcar únicamente los riesgos que se deban al acceso a Internet. Estos dispositivos son desplegados con la intención de que trabajen de forma autónoma, lo que puede provocar que queden expuestos físicamente y, por tanto, sean susceptibles de sufrir ataques físicos. Entre estos, destaca el conocido como tampering, pues suele tener el mismo objetivo que un ataque a través de la red: alterar el funcionamiento del dispositivo o robar información valiosa que maneje. Por tanto, encontrar una solución que garantice la seguridad en cualquier tipo de dispositivo IoT no es una tarea sencilla, pues la variedad entre los dispositivos que se pueden desplegar hace que las medidas de seguridad se vean limitadas por las capacidades de los dispositivos más restringidos. Además, los dispositivos IoT se caracterizan por tener un bajo coste, por lo que es necesario dotar de seguridad a estos dispositivos repercutiendo lo menos posible en su precio. También debe considerarse que los dispositivos IoT cuentan con ciclos de vida muy largos. Por ejemplo, un sensor agrícola diseñado para controlar la humedad del suelo puede mantenerse en funcionamiento durante años. Esto provoca que la probabilidad de que con el paso del tiempo puedan ir apareciendo nuevas amenazas que dejen expuestos a los dispositivos, se incremente. Es necesario diseñar estos dispositivos para que puedan ser actualizados de un modo seguro y eficiente, evitando que queden desprotegidos. De este modo, los dispositivos IoT deben poseer un sistema de seguridad que no solo los proteja en el inicio de su ciclo de vida, sino que pueda ser actualizado mientras el dispositivo se mantenga activo, asegurando así su protección durante toda su vida útil. 1El hecho de que un atacante pueda alterar el comportamiento de un dispositivo IoT puede tener consecuencias en todo el sistema en el que este opera. 2Proteger la información manejada por los dispositivos IoT es importante tanto por intereses personales como por la regulación actual existente, la Ley Orgánica de Protección de Datos Personales y garantía de los derechos digitales (LOPD) [4]. 3Un fallo de seguridad detectado en un dispositivo puede generar problemas en un gran número. 3 La securización de los dispositivos IoT expuesta evidencia la necesidad de establecer mecanismos de protección robustos y adaptativos desde el momento del despliegue y durante toda la vida útil de estos dispositivos. Actualmente, la Universidad de Murcia, bajo el proyecto aCtive sEcurity foR connecTed devIces liFecYcles (CERTIFY) [5], está desarrollando una propuesta que permita realizar una gestión segura de los dispositivos IoT, asegurando su correcto funcionamiento. En este trabajo se presenta una Proof of Concept (PoC) que permita poner a prueba ciertos aspectos con los que se trabaja en CERTIFY. En concreto, la PoC se centra en el proceso de bootstrapping de un dispositivo IoT. Este proceso supone la gestión de la primera fase del ciclo de vida de un dispositivo, dictaminando qué debe ocurrir cuando un dispositivo es desplegado en un determinado entorno y es arrancado por primera vez. El objetivo del bootstrapping es realizar tareas de autenticación y autorización que aseguren que el dispositivo desplegado puede operar en dicho entorno y tiene limitadas las acciones que puede realizar sobre este. Además, el bootstrapping busca preparar al dispositivo para que pueda continuar con las siguientes etapas de su ciclo de vida: operación y mantenimiento. Para ello, esta fase debe concluir con la obtención, por parte del dispositivo, de material criptográfico que le permita trabajar de forma segura. Dado que los ciclos de vida de los dispositivos IoT son muy largos, es necesario poder realizar actualizaciones sobre estos, ya sean sobre sus comportamientos o sobre la información que poseen. La PoC realizada también incluye una exploración inicial del uso de políticas de comportamiento mediante el estándar Manufacturer Usage Description (MUD) [6], como mecanismo para actualizar o adaptar la configuración de los dispositivos una vez desplegados. En concreto, estudia cómo definir y aplicar políticas de seguridad en los dispositivos IoT que han completado el proceso de bootstrapping. Para el desarrollo de la PoC se ha hecho uso de distintas tecnologías. El proceso de bootstrapping sigue el modelo CoAP-EAP propuesto en [1], consiguiendo un proceso de autenticación ligero para el dispositivo IoT. Las claves criptográficas y las operaciones críticas del mismo son protegidas mediante el uso de un Trusted Execution Environment (TEE). Además, se implementa un mecanismo para desplegar políticas en el dispositivo IoT haciendo uso del estándar MUD. En resumen, este trabajo propone un escenario de gestión básica del ciclo de vida de dispositivos IoT, basado en el proyecto CERTIFY y con foco en el proceso de bootstrapping. A pesar de sus limitaciones, representa un primer paso hacia la integración de los componentes clave del proyecto y proporciona una base sobre la cual desarrollar futuras mejoras. 4Introducción Finalmente, presentamos la organización que sigue este documento para exponer el trabajo realizado. La sección 2ofrece una visión teórica de las diferentes tecnologías, elementos y protocolos que han sido utilizados en este trabajo. Tras esto, en la sección 3se presenta de forma estructurada el objetivo de la PoC y cómo se ha trabajado para desplegarla. En la sección 4se expone con detalle cada uno de los pasos seguidos para crear el escenario IoT que se propone en este trabajo, así como los problemas encontrados durante su desarrollo y una prueba de la PoC desplegada. La sección 5presenta una evaluación de los tiempos de ejecución de las principales actividades que se realizan en el escenario desplegado. Por último, en la sección 6se discuten los resultados obtenidos con la PoC, exponiendo el trabajo futuro que se puede desarrollar a partir de este escenario IoT. 2. Estado del arte A lo largo de esta sección se expondrán los conceptos teóricos de las herramientas y tecnologías utilizadas en este trabajo. El objetivo de hacer esto es tratar de proporcionar un entendimiento general de los diferentes elementos utilizados y tratar de motivar su uso. En concreto, comenzaremos dando una introducción al proceso de bootstrapping. Una vez conocido qué es este proceso, presentaremos el modelo elegido, CoAP-EAP, definiendo así su funcionamiento y los protocolos sobre los que se basa. Tras esto, trataremos el concepto de los TEE, motivando así por qué estos son de gran utilidad para proteger dispositivos IoT. Finalmente, hablaremos del estándar MUD, concepto clave para poder controlar el comportamiento de los dispositivos IoT. 2.1. Bootstrapping de dispositivos IoT Tal y como menciona García Carrillo en [1], el ciclo de vida de un dispositivo IoT se divide en 3 fases: bootstrapping, operación y mantenimiento. La primera de estas etapas supone el arranque y configuración inicial del dispositivo para permitir que se una de forma segura a la red IoT donde el dispositivo pretende trabajar. Tras esta, comienza la fase de operación, donde el dispositivo realiza las tareas para las que ha sido diseñado. Cada cierto tiempo, el dispositivo requerirá entrar en la fase de mantenimiento para recibir actualizaciones que mantengan su correcto funcionamiento. En esta sección nos centramos en la primera de estas fases, el bootstrapping. Esta etapa tiene lugar cuando, tras su fabricación, el dispositivo es desplegado en el entorno en el que trabajará. Como ya se ha comentado, un dispositivo no debe poder empezar a trabajar conforme es desplegado, pues esto supondría una serie de riesgos tanto para el dispositivo como para el propio entorno donde está operando. Por este motivo, aparece el concepto de bootstrapping. Este proceso busca llevar a cabo dos actividades para considerar al dispositivo como seguro y permitir que comience con sus operaciones [1, 7]. Estas son: •Autenticación y autorización del dispositivo. Se debe comprobar quién es el dispositivo y qué permisos tiene para realizar acciones dentro del entorno. 12 Estado del arte donde se ejecutan las aplicaciones normales y tenemos el funcionamiento habitual del dispositivo. Cabe destacar que, para permitir la interacción entre ambos mundos, es necesario hacer uso de una API. Es importante tener claro qué propiedades se persiguen alcanzar al utilizar TEEs [20, 21]. Estas son: •Aislamiento. Se debe crear un entorno dentro del dispositivo que esté aislado de los procesos y aplicaciones no críticas. •Confidencialidad. Los datos de una TA no deben poder ser obtenidos por ninguna otra aplicación. •Integridad. Las TAs no deben poder ser modificadas. •Ejecución segura. Hay que evitar que nadie pueda descifrar qué ocurre mientras se ejecuta una TA. •Acceso controlado. Cada TA debe poder acceder únicamente a sus propios recursos. Concluimos esta sección con un ejemplo de uso de los TEEs: proteger las claves que se utilizan para cifrar las comunicaciones. En muchas ocasiones, estas claves están de forma clara en el código de nuestras aplicaciones. Esto provoca que, si alguien consigue acceder al código fuente, pueda obtenerlas. A través del uso de un TEE podemos proteger esas aplicaciones dentro del entorno seguro. Así, uno de los usos más habituales de los TEEs es cuando se necesita realizar operaciones criptográficas. 2.3. Aplicación de políticas de comportamiento en dispositivos IoT Los dispositivos IoT son capaces de conectarse a Internet, lo que les lleva de manera inevitable a estar expuestos a amenazas. Por tanto, un objetivo que debe ser fundamental cuando se trabaja con IoT es minimizar los riesgos a los que están expuestos. En este sentido, el MUD [6], un estándar definido por el IETF, permite definir en un fichero una serie de políticas que describan el comportamiento esperado en un dispositivo. Estas políticas pueden ser utilizadas para monitorizar comportamientos sospechosos (como se propone en [22]) o para reducir la superficie de ataque del dispositivo mediante su aplicación (como se plantea en este trabajo). Por tanto, el MUD permite estandarizar la definición de políticas de comportamientos de dispositivos IoT. Los ficheros que contienen dichas políticas son llamadados 2.3. Aplicación de políticas de comportamiento en dispositivos IoT 13 ficheros MUD y el propio estándar MUD establece una arquitectura para desplegar y obtener estos ficheros. Para comprender mejor el concepto de un fichero MUD recurrimos al ejemplo presentado en [6]: “Una bombilla tiene como objetivo iluminar una habitación, pero, además, podría ser diseñada para permitir que sea controlada de forma remota a través de la red. Cualquier acceso a la red por parte de la bombilla que no tenga este propósito supone una comunicación no deseada. Así, la bombilla no debe comunicarse con ningún servicio ni dispositivo que no esté relacionado con esta funcionalidad. Teniendo esto claro, podemos establecer que la bombilla solo debe poder acceder a Internet para conectarse al servicio que la controla de forma remota”. Este tipo de comportamientos son los que se busca controlar al definir un fichero MUD: se estudia el tipo de dispositivo y se restringen sus comunicaciones a través de la red para dotarlo de mayor seguridad frente a ataques. 2.3.1. Manufacturer Usage Description (MUD) Los ficheros MUD definen las conductas permitidas en un dispositivo IoT. Por ello, para poder trabajar con ellos es conveniente conocer quién se encarga de definirlos, cómo se difunden, cuál es la estructura que deben tener y qué limitaciones presentan. Las respuestas a estas cuestiones se abordan en las siguientes secciones. 2.3.1.1. Definición de un fichero MUD La entidad encargada de definir las políticas de comportamiento esperadas en un determinado dispositivo IoT se llama, según [6], manufacturer. Este término se usa con cierta ambigüedad, ya que normalmente hace referencia al fabricante del dispositivo. Sin embargo, en el contexto de los ficheros MUD, su significado puede variar en función del dispositivo IoT concreto. En el estándar citado, se expone que, aunque el término manufacturer puede resultar vago, hace referencia a una entidad dentro de la cadena de suministro del dispositivo que se encarga de definir un fichero MUD para describir su propósito de uso. 2.3.1.2. Difusión de un fichero MUD Una vez que el manufacturer genera un fichero MUD, este debe poder ser consultado. El proceso para poder obtener el contenido de un fichero MUD es el siguiente: 1. El dispositivo IoT es capaz de proporcionar la ubicación del fichero MUD a través de una Uniform Resource Locator (URL) a la que se llama MUD URL. Esta información se comparte durante el proceso de bootstrapping. 14 Estado del arte 2. Debe existir una entidad, denominada MUD Manager, que sea capaz de recibir un MUD URL y a partir de este generar una petición para obtener el fichero MUD. 3. Los ficheros MUD son almacenados en entidades llamadas MUD Server. Cuando un MUD Manager hace una petición de un fichero MUD a través de su MUD URL, el MUD Server es el encargado de responder con el fichero MUD pertinente. De este modo, una vez se tiene el fichero MUD, se puede interpretar su contenido para aplicar las políticas de comportamiento definidas en este. Figura 2.3: Proceso de obtención de un fichero MUD La figura 2.3 muestra un esquema resumen de cómo se obtiene un fichero MUD4. Es importante señalar que un fichero MUD puede ser modificado con el paso del tiempo, por lo que el MUD Manager debe estar preparado para tener esto en cuenta y actuar en consecuencia. 2.3.1.3. Estructura de un fichero MUD La estructura de un fichero MUD está ampliamente detallada en [6]. Por ello, en esta sección se destacarán solo los aspectos que se consideran más relevantes. La estructura de un fichero MUD está definida a través de un modelo Yet Another Next Generation (YANG) [23]. Además, para su transmisión por la red se usa serialización Javascript Object Notation (JSON) [24]. Su contenido se conforma a través de los siguientes elementos: •ietf-mud [6]: Contiene información relevante para comprobar la validez del propio fichero MUD, además de una referencia a las Access Control Lists (ACLs)5 [25] que se definen en el fichero, indicando su nombre y el sentido de la comunicación en el que se aplican (hacia/desde el dispositivo). 4Imagen basada en [22]. 5Una ACL constituye una política de red que puede aplicarse sobre un dispositivo. 2.3. Aplicación de políticas de comportamiento en dispositivos IoT 15 •ietf-access-control-list [25]: Permite definir las reglas que conforman las diferentes ACLs que se quieren aplicar. •ietf-acldns [6]: Permite utilizar nombres de dominio en reglas que se definan sobre una ACL. Un fichero MUD válido contiene como contenedores raíz a ietf-mud e ietf-accesscontrol-list. Es interesante destacar que es posible hacer uso de extensiones para poder añadir contenedores raíz, ampliando así la información transmitida en un fichero MUD. En el caso de querer utilizar extensiones estas deben ser declaradas dentro del contenedor ietf-mud usando el valor extensions. 2.3.1.4. Limitaciones de los ficheros MUD Respecto a los ficheros MUD no solo es importante tener un modo estandarizado para la definición de políticas de comportamiento de un dispositivo y la obtención de ficheros de este tipo; también es necesario ser capaces de aplicar dichas políticas. Además, estas políticas pueden cambiar durante el ciclo de vida del dispositivo, requiriendo por tanto actualizarlas. Estos aspectos no son incluidos en la definición del estándar MUD [26]. Existen otros problemas asociados al uso del MUD tal y como se expone en [22]: Limitación Descripción de la limitación Necesidad de un proceso de traducción Las políticas que se definen a través de un fichero MUD no pueden ser directamente aplicadas. Es necesario realizar un proceso de traducción del contenido del fichero para poder procesar y aplicar estas políticas correctamente. Falta de expresividad Los ficheros MUD tienen limitaciones para poder expresar políticas que vayan más allá de la capa de red. Existencia de conflictos Es habitual que en los entornos donde se despliegan dispositivos IoT que hacen uso de ficheros MUD, existan ya definidas ciertas políticas de seguridad. En ocasiones, las políticas definidas en el entorno del dispositivo IoT pueden entrar en conflicto con las que aparecen indicadas en el fichero MUD. Tiempo de validez de un fichero MUD Entre el contenido de un fichero MUD, aparece el tiempo de validez de este. Así, el MUD Manager no debería comprobar actualizaciones de este fichero antes de expirar dicho periodo. Sin embargo, el trabajo en Internet implica cambios casi constantes, por lo que un fichero MUD podría ser modificado antes de que se cumpla el tiempo de validez. De este modo, seguir fielmente el estándar implicaría que pudiera darse el caso de que el fichero MUD usado esté obsoleto, por lo que estaríamos aplicando políticas incorrectas en el dispostivo. 16 Estado del arte Limitación Descripción de la limitación Actualización de los ficheros MUD El estándar MUD define que el fichero MUD es obtenido cuando el dispositivo IoT envía el MUD URL al MUD Manager. Sin embargo, no especifica ningún modo de obtener el fichero MUD cuando haya actualizaciones de este. Tampoco define ningún mecanismo para que el manufacturer del dispositivo pueda avisar de cambios de este fichero. MUD Server como único punto de fallo Si el servidor que proporciona un fichero MUD se ve comprometido, el sistema se vería en problemas, pues podríamos utilizar ficheros MUD que no sean correctos. Tabla 2.1: Limitaciones de un fichero MUD Cabe mencionar que para algunos de los problemas mencionados ya se están ofreciendo soluciones. Por ejemplo, en el caso particular de la falta de expresividad del MUD, actualmente existe una propuesta para su extensión a través del uso del lenguaje Medium-level Security Policy Language (MSPL) [27, 28]. Dicha propuesta está descrita en [29] y propone ampliar el contenido del MUD mediante una extensión llamada umu-mspl-list:mspls. A través de esta se pueden incluir políticas de seguridad más complejas y que no estén enfocadas únicamente en la capa de red. Es importante tener en cuenta que la propuesta mencionada requiere introducir un paso intermedio para poder aplicar las políticas que se incluyan en el MUD, estas deben ser previamente traducidas a lenguaje MSPL para poder interpretarlas y así aplicarlas. Esta extensión es utilizada en este trabajo, en concreto, en el fichero MUD que se define en la sección 4.3.2.4 se explica cómo ha sido utilizada. 3. Análisis de objetivos y metodología El objetivo de este trabajo es desarrollar una PoC del proyecto CERTIFY que está siendo desarrollado en la Universidad de Murcia. En concreto, se busca obtener un escenario simplificado que permita realizar una gestión segura del ciclo de vida de dispositivos IoT. Para ello, se presta especial interés a la fase de bootstrapping y se trabaja de forma básica con la aplicación de políticas de comportamiento en dispositivos IoT. Por tanto, la gestión de las fases de operación y mantenimiento del dispositivo se trata como aspecto secundario. De este modo, el trabajo se divide en tres bloques: 1. Proceso de bootstrapping. Se ha buscado lograr una implementación funcional del modelo de bootstrapping propuesto en la Universidad de Murcia por García Carrillo en [1]. En concreto, la implementación utilizada es la que está actualmente aceptada por el IETF [8]. 2. Securización del dispositivo IoT. Para dotar de la mayor seguridad posible a los dispositivos, se ha estudiado el despliegue de un TEE que permita proteger las operaciones críticas del dispositivo. Por ejemplo, las operaciones criptográficas durante el proceso de bootstrapping. 3. Etapas de operación y mantenimiento. Aunque la gestión de estas etapas no es cubierta en su totalidad, se han desarrollado mecanismos que permitan actuar sobre dispositivos que hayan completado la etapa de bootstrapping. En concreto, se ha realizado un despliegue que permita aplicar políticas de comportamiento que estén definidas en ficheros MUD. Respecto a la metodología de trabajo seguida, esta no consiste en una investigación, sino en una PoC. De este modo, para la prueba del escenario desplegado se ha hecho uso de una Raspberry Pi 3 Model B y una Raspberry Pi 4 Model B como dispositivos IoT. Para la puesta en marcha de las entidades que no corresponden al dispositivo IoT, se ha utilizado un ordenador portátil de propósito general. El trabajo desarrollado para crear el escenario IoT que se presenta en este trabajo se puede resumir en las siguientes etapas: 1. Despliegue y prueba de un servidor que permita realizar el bootstrapping siguiendo el modelo CoAP-EAP. 18 Análisis de objetivos y metodología 2. Despliegue de un TEE en una Raspberry Pi 3 Model B. 3. Prueba del proceso de bootstrapping entre el servidor desplegado en la etapa 1 y el dispositivo IoT configurado en la etapa 2. 4. Despliegue y prueba de un proceso que permita aplicar políticas de comportamiento en una Raspberry Pi 3 Model B que haya completado el proceso de bootstrapping. Siguiendo la terminología del proyecto CERTIFY a dicho proceso se le llama Enforcement and Reconfiguration Agent (ERA). 5. Despliegue y prueba de un servidor capaz de proporcionar ficheros MUD a partir de un MUD URL 6. Despliegue y prueba de un servidor capaz de procesar MUD URLs, solicitar los ficheros MUD asociados, y traducir las políticas que contengan para aplicarlas en un dispositivo IoT. 7. Integración de las etapas 4, 5 y 6 para aplicar políticas de comportamiento definidas en ficheros MUD sobre dispositivos IoT. 8. Prueba del escenario completo: unión de la etapa 3 y 7. 9. Documentación del trabajo realizado. 4. Diseño y resolución del trabajo realizado En esta sección se presenta el trabajo realizado para construir la PoC basada en el proyecto CERTIFY [5]. Para ello, utilizando como base código que pertenece a dicho proyecto, se discute cómo ha sido utilizado, modificado cuando ha sido necesario, y testeado para poder integrarlo en un escenario que cumpla con los objetivos definidos en la sección 3. En concreto, se describe cómo se ha realizado el despliegue de un proceso de bootstrapping que siga el modelo CoAP-EAP. Tras esto, se define cómo realizar el despligue de un TEE que permita proteger las operaciones críticas de una Raspberry Pi 3 Model B. Finalmente, se presenta el trabajo desarrollado para definir y distribuir un fichero MUD que pueda ser utilizado para aplicar políticas de comportamiento en un dispositivo IoT que haya completado el proceso de bootstrapping. Además, para que estas políticas puedan ser aplicadas en el dispositivo, se explica cómo desplegar un ERA en una Raspberry Pi 3 Model B. Una vez presentadas todas las entidades que constituyen el escenario IoT del trabajo, se expone una prueba del correcto funcionamiento de la PoC. Figura 4.1: Escenario IoT a desplegar 20 Diseño y resolución del trabajo realizado La figura 4.1 muestra un resumen del escenario que se desarrolla en este trabajo. A lo largo de esta sección se irá describiendo el papel de cada una de las entidades que aparecen en este diagrama, así como el proceso que se siguió para incorporarlas en el escenario. 4.1. Proceso de bootstrapping CoAP-EAP En esta etapa el objetivo era desplegar un servidor capaz de realizar el proceso de bootstrapping CoAP-EAP definido en [8]. Para ello, se hizo uso de dos materiales: 1. Aunque el modelo CoAP-EAP está definido en el estándar del IETF, se proporcionó un diagrama del flujo esperado durante el proceso de bootstrapping. Este diagrama pertenece al proyecto CERTIFY, cuyo objetivo está expuesto en [26]. Dado que este proyecto aún está en desarrollo y su material no me pertenece, este diagrama no se incluye por cuestiones de privacidad. 2. Una versión de un servidor que sigue el modelo CoAP-EAP, basada en la publicada en [30]. De este modo, dado que ya se disponía de un código completamente desarrollado para el servidor de bootstrapping, el objetivo era comprobar que este era funcional, pues, aunque había sido probado en simulaciones, no se había probado con máquinas reales. Para comprobar el correcto funcionamiento de dicho servidor era necesario entender el modelo CoAP-EAP y el diagrama de flujo proporcionado. Una vez hecho esto, se debía comprobar que el código fuente del servidor seguía ambos modelos. Finalmente, se debía poner en marcha el servidor y ver que el intercambio de mensajes para completar el bootstrapping era correcto. En este punto, es importante tener en cuenta que el código proporcionado pertenece a un proyecto que aún está vivo, lo que provocó tener que trabajar con varias versiones diferentes del servidor. 4.1.1. Prueba de una implementación del servidor de bootstrapping Tras recibir la primera versión del código, lo primero que se hizo, fue tratar de ponerla en ejecución, para que, independientemente de que su implementación fuese correcta o no, se comprobase que no había ningún error de programación oculto por el uso de un entorno de simulación para su desarrollo. 4.1. Proceso de bootstrapping CoAP-EAP 21 Dado que el código estaba desarrollado en C, era necesario compilarlo. Para ello, previamente había que instalar librerías que se habían usado para desarrollar el código, pues estas son muy específicas y por lo general no suelen estar instaladas. En concreto, la prueba estaba siendo realizada sobre un Ubuntu 24.04, y con la instalación genérica, las librerías que se tuvieron que instalar fueron: Librería Descripción libcoap3-dev Permite trabajar con CoAP. libmicrohttpd-dev Permite implementar servidores HTTP de forma sencilla. libssl-dev Permite trabajar con OpenSSL [31], siendo este útil para trabajar con criptografía. uuid-dev Permite crear Universally Unique Identifiers (UUIDs) [32] de forma sencilla. libcurl4-openssl-dev Permite hacer peticiones a servidores web de forma segura para utilizarlo de manera similar a como se usa la herramienta de línea de comandos curl. libcjson-dev Permite trabajar con datos en formato JSON. Tabla 4.1: Librerías necesarias para ejecutar el servidor de bootstrapping Una vez instaladas todas las librerías necesarias y compilando con la herramienta gcc, se pudo poner en ejecución el servidor. Esta prueba detectó un problema: había un error de programación que impedía la ejecución. El motivo de este error era que se hacía una comprobación sobre el estado de un socket de la comunicación antes de inicializarlo, lo que provocaba la finalización prematura del código. Por tanto, se solucionó ese fallo y se reportó al desarrollador del código. Una vez que el servidor estaba en funcionamiento, sin comprobar su implementación, se decidió testear si este era capaz de comunicarse con otra entidad. Para hacer esto, se utilizó un código de cliente (código que se debería instalar en un dispositivo IoT) de prueba que también se había proporcionado junto al del servidor de bootstrapping. Al lanzar ambas entidades, se localizó un nuevo problema, pero ahora en el cliente. Este hacía uso de la interfaz de red del dispositivo que ejecutase ese código; sin embargo, este valor era necesario introducirlo de forma estática en el programa, lo que provocaba que fuese dependiente de la máquina en la que se ejecutase. Tras solucionar este problema y reportarlo, tanto cliente como servidor eran capaces de comunicarse y, por los mensajes de debug que se mostraban, parecían realizar un proceso de bootstrapping. Sin embargo, ahora era el turno de comprobar que el código desarrollado era correcto y seguía el modelo CoAP-EAP. Antes de comenzar con esta tarea se recibió una nueva versión del código, que había corregido los errores reportados y algunos que aún no se habían descubierto. Por este motivo, se abandonó esta versión y se pasó a trabajar con la nueva. 28 Diseño y resolución del trabajo realizado que el make fallase justo en el último comando, por lo que podemos ejecutarlo a mano tras instalarlas. Tras realizar este proceso, en /optee/out/ tenemos la imagen SD que se necesita para la Raspberry Pi 3 Model B. En concreto, en este directorio se debe buscar el archivo rpi3-sdcard.img y copiarlo en la SD que se vaya a usar para la Raspberry. El siguiente paso es explicar cómo hacer esto. Lo primero que se debe hacer es conectar la SD a nuestro PC y vaciar su contenido (si es que tiene alguno): lsblk # Vemos dónde se ha montado la SD en # nuestro sistema sudo umount </RUTA1> # Desmontamos todos los puntos dónde se ... # haya montado la SD sudo umount </RUTAN> sudo fdisk <NOMBRE_SD> # Accedemos a la SD con fdisk usando el # nombre obtenido con lsblk. El objetivo # será borrar todas las particiones que # tenga y crear una nueva desde cero. Es # importante guardar los cambios antes # de salir sudo mkfs.vfat -F 32 <PARTICIÓN_SD_CREADA> # Formateamos la partición creada en la SD Tras esto, se debe copiar la imagen creada en la SD: # Copiamos la imagen creada del contenedor a nuestro PC docker cp <CONTAINER_ID>:/optee/out/rpi3-sdcard.img . # Copiamos la imagen a la SD sudo dd if=rpi3-sdcard.img of=<NOMBRE_SD> bs=1024k conv=fsync status=progress Por último, antes de pasar a comprobar que el funcionamiento con el TEE creado para la Raspberry es correcto, se puede hacer una comprobación rápida para ver que el contenido de la SD es el adecuado, pues en ocasiones la operación de copia de la imagen puede fallar, provocando que, si se va directamente a la Raspberry, no arranque. Esta comprobación se puede hacer del siguiente modo: # Vemos las particiones que tiene la imagen creada (deberían ser 2) sudo fdisk -l rpi3-sdcard.img # Comprobamos que nuestra SD tiene las mismas particiones sudo fdisk -l <NOMBRE_SD> # Para cada partición que tenga la SD hacemos el siguiente proceso (el objetivo es # comprobar que tiene la estructura de ficheros esperada): sudo mkdir -p /mnt/<RUTA-DESEADA-PARA-LA-PRUEBA> sudo mount <PARTICIÓN-X-SD> /mnt/<RUTA-DESEADA-PARA-LA-PRUEBA> ls <PARTICIÓN-X-SD> /mnt/<RUTA-DESEADA-PARA-LA-PRUEBA> sudo umount /mnt/<RUTA-DESEADA-PARA-LA-PRUEBA> 4.2. Securización de un dispositivo IoT 29 Tras completar este último paso, se tiene una SD lista para usar en la Raspberry con el código necesario para desplegar un cliente seguro durante el proceso de bootstrapping. Por tanto, se tendría desplegada la segunda entidad del escenario IoT definido en la figura 4.1:Bootstrapping Agent. Sin embargo, antes de dar por hecho que esto es así, se debe comprobar que el bootstrapping se completa de forma exitosa. Esta es la tarea que se debe hacer antes de dar por concluida esta sección. 4.2.1. Prueba del proceso de bootstrapping con un cliente seguro La prueba de que el TEE y el bootstrapping funcionan correctamente es muy sencilla gracias a que tanto los desarrolladores de OP-TEE como el desarrollador del código del cliente para el bootstrapping han desarrollado tests. Así, ejecutando estos tests y viendo que son pasados con éxito, se puede dar por concluida la prueba. Una vez se arranca la Raspberry, disponemos de una terminal en la que se pueden ejecutar comandos. Para probar los tests de los desarrolladores de OP-TEE basta con ejecutar el comando xtest, mientras que para ejecutar los test relacionados con el bootstrapping, se debe ejecutar el comando security_api_test2. Durante la prueba, se obtuvieron los siguientes resultados: • Los tests creados por los desarrolladores de OP-TEE fueron pasados con éxito. • Los tests relacionados con el bootstrapping dieron error en su ejecución. Esto fue reportado al desarrollador del código y se consiguieron detectar dos problemas: 1. Había un error en el nombre de una de las funciones del código. Dos ficheros tenían una función llamada main. Esto hacía que el punto de comienzo del programa entrase en conflicto entre estos ficheros y se rompiese el orden de ejecución, provocando la finalización prematura del programa. 2. El código del cliente era incompatible con el del servidor. En la sección 4.1 habíamos hablado de que junto al servidor se había utilizado un cliente de prueba. Para el desarrollo del cliente securizado se pensaba que el código que se estaba instalando en la Raspberry era el mismo que el probado en aquel momento, pero modificado para hacer uso del TEE. Sin embargo, la realidad estaba muy alejada de esto. Para encontrar el origen del problema hubo que ponerse en contacto con los desarrolladores de ambos códigos. Tras hablar con ellos, se identificó el problema. El servidor había sido desarrollado siguiendo el modelo CoAP-EAP; sin embargo, no había sido posible lograr el uso de CoAP con OP-TEE, por lo que el desarrollador del cliente securizado optó por transportar los mensajes EAP directamente 2Para que este test funcione es necesario que el servidor de la sección 4.1 esté en funcionamiento y que la Raspberry esté conectada a Internet. La forma más cómoda de hacer esto último es utilizar Ethernet. 30 Diseño y resolución del trabajo realizado sobre TCP. Esto provocaba que el cliente securizado fuese totalmente distinto del probado al desplegar el servidor de bootstrapping. Además, al usar cliente y servidor protocolos de transporte distintos (servidor UDP, cliente TCP), la comunicación entre ellos no era posible. Se plantearon entonces dos posibles soluciones: a) Desarrollar un proxy que hiciese de traductor entre cliente y servidor. b) Actualizar el servidor para trabajar directamente con EAP sobre TCP. Cualquiera de las soluciones elegidas no era idónea, pues se descartaba el uso de CoAP y UDP, el cual es un aspecto clave para seguir el modelo CoAP-EAP. Sin embargo, dadas las limitaciones de tiempo para completar el trabajo y la dificultad que suponía trabajar con OP-TEE, hubo que asumir esta limitación en el escenario. Finalmente, la solución elegida fue la segunda. De este modo, tras encontrar los problemas mencionados y ponerles solución, se obtuvo una tercera versión del servidor de bootstrapping. Además, hubo que regenerar la imagen de la SD para actualizar el código del cliente (esto solo requirió actualizar el código de GitHub y volver a hacer el make). Tras esto, se repitió la prueba con las nuevas versiones de cliente y servidor y todos los tests fueron pasados exitosamente, completando así con el trabajo en el Bootstrapping Agent de la figura 4.1. 4.3. Infraestructura para aplicar políticas de comportamiento Una vez desplegado el modelo CoAP-EAP para realizar el proceso de bootstrapping en un dispositivo IoT, el paso final para completar la PoC propuesta en este trabajo, es realizar una aproximación a la gestión del dispositivo tras avanzar a la siguiente fase de su ciclo de vida: operación. En esta sección, se explica el proceso seguido para desplegar la infraestructura necesaria que permita aplicar políticas de seguridad sobre un determinado dispositivo IoT. 4.3.1. Despliegue de un ERA en un dispositivo IoT Tras desplegar un dispositivo IoT capaz de realizar el bootstrapping, la siguiente tarea es configurarlo para que sea capaz de recibir órdenes de entidades externas que permitan tanto ajustar sus políticas de comportamiento como ejecutar acciones sobre el mismo. La entidad desplegada para poder hacer esto, siguiendo la terminología del proyecto CERTIFY, es llamada Enforcement and Reconfiguration Agent (ERA). Además, se ha 4.3. Infraestructura para aplicar políticas de comportamiento 31 reutilizado la implementación desarrollada en dicho proyecto para este trabajo. Para desplegar el ERA en la Raspberry hay que tener en cuenta que se debe modificar el código del que dispone el sistema OP-TEE. Por tanto, es necesario regenerar la imagen SD que se utiliza. En concreto, se usó una nueva versión de [37]. Además, el ERA diseñado para el proyecto CERTIFY estaba desarrollado en Python, por lo que se debía instalar Python en la Raspberry. Este paso fue bastante complejo de realizar, pues no se encontró ninguna fuente que diese directrices sobre cómo añadir Python en una Raspberry Pi 3 Model B que haga uso de OP-TEE. Por este motivo, se considera conveniente proporcionar una guía sobre cómo realizar la instalación de Python. Cuando se desplegó OP-TEE en la sección 4.2 se creó en el contenedor Docker el directorio /optee. En este se dispone de una estructura de directorios que permite hacer la construcción del sistema a través de la herramienta make. Para hacer esto, dentro de los diferentes directorios se encuentran ficheros Makefile que se van llamando entre sí para acabar formando la imagen de la SD. Por tanto, para añadir Python al sistema es necesario encontrar el fichero exacto en el que se debe indicar que se haga esto. Tras estudiar el contenido de los diferentes ficheros Makefile, se llegó a la conclusión de que la clave estaba en los directorios /optee/buildroot y /optee/out-br. En /optee/out-br hay un fichero oculto, .config, en el que se debe indicar que se quiere añadir Python al sistema. Para modificar este archivo, no es conveniente hacerlo a mano, pues esto puede ser complejo y acabar con errores. En su lugar, se puede hacer uso de una interfaz gráfica accesible a través de /optee/buildroot. Así, el proceso que se debe seguir para instalar Python (asumiendo que se trabaja dentro del Docker) es el siguiente: # Accedemos a la interfaz gráfica a través de /optee/buildroot e indicamos con la opción "O" # que la configuración seleccionada y los ficheros generados se guarden en # /optee/out-br. De este modo actualizamos el fichero .config de /optee/out-br cd /optee/buildroot make O=/optee/out-br menuconfig # Dentro de la interfaz gráfica seleccionamos lo siguiente: "Target packages" >> "Interpreter languages and scripting" >> "[*] python3" # Guardamos los cambios y nos salimos de dicha interfaz # Compilamos la configuración elegida para actualizar .config de /optee/out-br make O=/optee/out-br Una vez configurado Python, para terminar con el despliegue del ERA, se debe actualizar el código con el que cuenta la Raspberry. En concreto, hay que actualizar el código procedente de [37]3y añadir los ficheros Python proporcionados para desplegar el ERA en /optee/out-br/target/root. Tras esto, se puede regenerar la imagen para la SD. 3Este código está en continuo cambio por ser parte de CERTIFY. 32 Diseño y resolución del trabajo realizado 4.3.1.1. Prueba del ERA Para probar el funcionamiento del ERA, igual que ocurrió con el Bootstrapping Agent de la sección 4.2, el autor del ERA diseñó un test que comprueba la correcta funcionalidad de este. El test incluye realizar el bootstrapping y, una vez se completa, el dispositivo pasa a ejecutar el ERA. Para poder comunicarse con este, se proporcionó otro script en Python en el que se definen dos comandos de prueba4: 1. Reiniciar el dispositivo para poder realizar un nuevo bootstrapping. 2. Cambiar el algoritmo de firma que utiliza el dispositivo. Mediante la ejecución del test junto a los comandos anteriores, se puede comprobar la correcta funcionalidad del ERA. Sin embargo, para completar el despliegue de la entidad Enforcement and Reconfiguration Agent de la figura 4.1 es necesario que los comandos lleguen de la entidad Device and Domain Manager, definida también en dicha figura. Por tanto, el despliegue del ERA se podrá dar por concluido una vez los comandos lleguen de la entidad adecuada y se apliquen correctamente en el dispositivo. Esto es lo que estudiamos en la siguiente sección del documento. 4.3.2. Despliegue de infraestructura para trabajar con ficheros MUD Una vez tenemos la Raspberry Pi preparada para completar un proceso de bootstrapping y recibir comandos que regulen su comportamiento, es momento de desarrollar las entidades necesarias para generar dichos comandos de forma adecuada. Para hacer esto, nos basamos en el uso de ficheros MUD, desplegando así la infraestructura necesaria para: proporcionar ficheros MUD; recuperar ficheros MUD a partir de un MUD URL; y convertir las políticas definidas en un fichero MUD a comandos comprensibles para el ERA desplegado. Destacar que, para las pruebas de dicha infraestructura, se utilizará un fichero MUD que es definido desde cero en este trabajo. A la entidad central que gestionará el trabajo con los MUD se le llamará Device and Domain Manager (DDM), tal y como se propone en [38]. Además, para desplegar toda la funcionalidad mencionada se toma como punto de partida código que ha sido desarrollado para el proyecto CERTIFY. Es importante tener en cuenta que este proyecto es ambicioso respecto al uso de los MUDs, cubriendo así aspectos que exceden el objetivo de este trabajo. Por este motivo, el código reutilizado cuenta con partes que no son útiles en la PoC que se propone en este documento, teniendo, por tanto, que detectarlas y eliminarlas. 4El ERA desplegado solo es capaz de ejecutar los dos comandos mencionados. 4.3. Infraestructura para aplicar políticas de comportamiento 33 Otro aspecto a destacar sobre el código del proyecto CERTIFY es que está desarrollado para interactuar con el dispositivo IoT no solo una vez que finaliza el bootstrapping, sino que también pretende intervenir a mitad de este. El motivo de hacer esto es que las políticas de comportamiento se deben aplicar en la configuración inicial del dispositivo y no esperar a que esté ya funcionando. Sin embargo, ni el servidor de bootstrapping ni el ERA desplegados están preparados para interactuar con la parte de gestión de políticas durante el bootstrapping. Estas entidades están aún en desarrollo, por lo que las diferentes partes del proyecto CERTIFY no están perfectamente integradas entre sí. El ERA desplegado se activa una vez completado el bootstrapping, mientras que el servidor de bootstrapping simula la comunicación con la parte de gestión de políticas5. Así, la falta de integración entre el ERA, el servidor de bootstrapping y el código que gestiona las políticas, provoca tener que hacer modifcaciones importantes para poder conectar todo el escenario. 4.3.2.1. Actualización del Bootstrapping-Server Como ya hemos comentado, con la versión actual del servidor de bootstrapping y del ERA es imposible que la gestión de políticas se aplique también durante el proceso de bootstrapping. Por ello, por cuestiones de tiempo, se tomó la decisión de que las políticas de comportamiento se aplicasen una vez completado el bootstrapping. Esta decisión buscaba no tener que modificar el servidor de bootstrapping. Sin embargo, hay un aspecto que debemos tener en cuenta: el envío del MUD URL del dispositivo, valor necesario para poder obtener el fichero MUD que genera el manufacturer. Este valor es enviado por el dispositivo al Bootstrapping-Server y es necesario que se reenvíe al DDM en el mismo momento en que se recibe. Esto permite que, una vez completado el bootstrapping, se sepa cómo obtener el fichero MUD del dispositivo. Este hecho genera ciertas dificultades, pues como ya hemos expuesto, el servidor de bootstrapping no está desarrollado para comunicarse con el DDM, sino que simula la comunicación enviando la información del dispositivo a un servidor “vacío”. Si nos limitamos a cambiar dicho servidor por el DDM sin preocuparnos de nada, se bloquearía el proceso de bootstrapping, pues el Bootstrapping-Server quedaría a la espera de una respuesta la cual no es capaz de procesar. Para solventar este problema, se buscó una solución intermedia que afectase lo menos posible a la estructura tanto del DDM como del servidor de bootstrapping. La solución planteada consistió en modificar el Bootstrapping-Server para que la información que mandaba al servidor “vacío” fuese reenviada automáticamente al DDM. Para evitar 5La simulación mencionada consiste en publicar en un servidor de prueba, datos del dispositivo IoT que está tratando de realizar el bootstrapping. Este servidor de prueba automáticamente responde con una respuesta sin contenido relevante, la cual es ignorada en el servidor de bootstrapping y se continúa con el proceso. 34 Diseño y resolución del trabajo realizado que este último pudiese enviar un mensaje de respuesta, se estableció un timeout muy bajo que cerrase la conexión antes de que el DDM pudiese generar una respuesta. De este modo, el servidor de bootstrapping continuaría su ejecución sin verse alterado por la funcionalidad del DDM. Este cierre de conexión puede provocar un error en el DDM si este trata de aplicar las políticas en el dispositivo, pues el ERA no está aún en funcionamiento. Por este motivo, se decidió implementar una interrupción en la ejecución del DDM para que el administrador del sistema decidiese retomarla una vez completado el bootstrapping y evitar así el error. Como es evidente esta solución supone fuertes limitaciones en el funcionamiento del escenario, pues solo podremos gestionar un dispositivo IoT en cada momento. Además, la labor del DDM debería estar automatizada para no depender de la supervisión de una persona. Sin embargo, dadas las limitaciones presentadas en el servidor de bootstrapping y en el ERA que se tenían desplegados, esta era la opción más viable para completar el escenario. 4.3.2.2. Despliegue de un servidor que proporcione ficheros MUD Suponiendo que tenemos ficheros MUD válidos, haciendo uso de Python se ha desplegado un servidor HTTP que sirva peticiones GET para proporcionar ficheros MUD. Es importante tener en cuenta que para que el servidor fuese completamente funcional, debería tener endpoints configurados que correspondiesen a MUD URLs. Sin embargo, debido a la naturaleza de este proyecto, nuestro dispositivo no tiene un MUD URL asociado. En su lugar, tiene una cadena de prueba que simboliza este valor. Es por ello, que el servidor está configurado para responder peticiones a endpoints del tipo /mud/<device_id>, donde device_id es un identificador del dispositivo IoT del que se quiere obtener el fichero MUD asociado6. Si quisiésemos hacer más realista este escenario, podríamos definir para el dispositivo IoT de prueba un MUD URL que tuviese un mayor sentido, y configurar entonces este servidor para responder únicamente a dicho endpoint. Destacar que, para esta prueba, este servidor proporcionará únicamente un fichero MUD, el definido en la sección 4.3.2.4. Así, con el despliegue de esta entidad tenemos listo el MUD Server definido en la figura 4.1. 6Este valor es intercambiado entre el dispositivo IoT, el servidor de bootstrapping y el DDM, por lo que podemos hacerlo llegar hasta este servidor. 4.3. Infraestructura para aplicar políticas de comportamiento 35 4.3.2.3. Despliegue de un servidor que solicite ficheros MUD Una vez que tenemos un servidor que es capaz de proporcionar ficheros MUD ante peticiones GET, necesitamos una entidad que sea la encargada de hacerle peticiones. Esta es la que llamamos MUD Manager en la figura 4.1. La implementación de esta entidad está altamente basada en la desarrollada para el proyecto CERTIFY, pero ha sido simplificada para tener lo estrictamente necesario para el despliegue de este escenario. Así, mediante Python se define un servidor HTTP que, mediante peticiones GET, es capaz de obtener un fichero MUD a partir de un MUD URL. Este proceso es iniciado cuando el MUD Manager recibe un mensaje POST al endpoint /mud. Dicho mensaje debe ser enviado por el DDM y tendrá en su contenido un MUD URL y el identificador del dispositivo IoT al que corresponde dicho MUD URL. Este identificador es lo que llamamos <device_id> en la sección 4.3.2.2. Un aspecto a destacar sobre esta implementación es que, aunque el código se ha dejado listo para poder utilizar MUD URLs, cuando se va a hacer la petición al MUD Server, independientemente del MUD URL que se haya recibido, siempre se utiliza el mismo endpoint: /mud/prueba. Esto se hace así en pro de la simplicidad, pues como ya hemos comentado, los MUD URLs que se utilizan son simples cadenas de texto de prueba. Además, el MUD Server tiene un único MUD disponible. Por tanto, para la prueba del correcto funcionamiento, no es importante el endpoint que usemos para el GET7. 4.3.2.4. Definición de un fichero MUD El objetivo de toda la sección 4.3.2 es poder aplicar políticas de configuración en nuestra Raspberry Pi una vez ha completado el proceso de bootstrapping. Para poder hacer esto necesitamos generar un fichero MUD que sea compatible con el ERA desplegado, es decir, el MUD debe contener políticas soportadas por el ERA. En nuestro caso, se decidió optar por crear un MUD que tuviese la política de cambio de algoritmo de firma8. Además, se completó el contenido de este fichero con políticas de red que definiesen un MUD más completo, aunque estas últimas no fuesen usadas. En esta sección se expone cómo se ha realizado la definición del fichero MUD que es utilizado para la Raspberry. Basándonos en [6] se crea la estructura básica de un fichero MUD que cumpla con el estándar. Para ello, se hace uso de los contenedores ietf-mud:mud e ietf-access-control-lists:acls. En estos se define el siguiente contenido: 7No obstante, el código se ha dejado listo para poder pasar a usar MUD URLs cuando se desee. 8Esta política es una de los soportadas por el ERA desplegado, tal y como se describe en la sección 4.3.1.1 36 Diseño y resolución del trabajo realizado •ietf-mud:mud. Los principales aspectos que se incluyen en este bloque son la definición del nombre de las ACLs que aparecen en el contenedor ietf-ccess-controllists:acls y la declaración de las extensiones que se utilizan para ampliar el estándar MUD. •ietf-access-control-lists:acls. En este bloque definimos una política de comunicación para el dispositivo. Asumiendo que todo lo que no se especifique mediante ACLs será considerado como tráfico no permitido, se establecen reglas para restringir la comunicación del dispositivo IoT únicamente a conexiones con dispositivos del entorno donde ha sido desplegado (se supondrá que dicho entorno es la red 192.168.100.0/24). En particular, el dispositivo IoT solo podrá generar tráfico hacia dispositivos de esa red si utiliza Hypertext Transfer Protocol Secure (HTTPS) [39], mientras que podrá recibir tráfico de cualquier tipo siempre que provenga de esta red. Para evitar el problema de falta de expresividad del MUD mencionado en la sección 2.3.1.4, se hace uso de la extensión propuesta en [29]: umu-mspl-list:mspls. De este modo, podemos expresar políticas más complejas que las que permiten definir las ACLs. En nuestro caso, se hace uso de esta extensión para: •Definir la política de cambio de algoritmo de firma en el dispositivo: se debe pasar a usar Hash-based Message Authentication Code (HMAC) [40]. •Ampliar la política de red definida mediante ACLs: se añade que todo el tráfico que llegue al dispositivo desde un servidor de bootstrapping de la Universidad de Murcia sea permitido. El contenido del fichero MUD resultante se puede ver en el anexo A. Destacar que la definición del MUD fue una tarea bastante compleja, pues este debía ser aceptado por un traductor diseñado para trabajar junto al DDM. La problemática estaba en que el funcionamiento exacto de este traductor era desconocido, pues la persona que lo desarrolló no estaba disponible. Por tanto, hubo que descifrar cómo funcionaba el traductor para crear un MUD con sentido y que a la vez fuese aceptado por este. El fichero MUD definido es el que proporciona el MUD Server explicado en la sección 4.3.2.2. De este modo, cuando se procese la política de cambio de algoritmo de firma, esta será enviada al ERA, mientras que el resto de las políticas podrían ser enviadas a entidades que gestionen la red donde trabaja el dispositivo IoT, por ejemplo, a una Software-Defined Networking (SDN) [41], tal y como se sugiere en [22]. Para concluir con esta sección, cabe mencionar que el significado de todos los campos utilizados en los contenedores ietf-mud:mud, ietf-access-control-list:acls y umu-mspllist:mspls puede ser consultado en [6], [25] y [29]. Por ello, para no hacer demasiado extenso el documento se evita poner las definiciones aquí. 4.3. Infraestructura para aplicar políticas de comportamiento 37 4.3.2.5. Coordinación de la aplicación de políticas Una vez tenemos toda la infraestructura relacionada con la aplicación de políticas basada en ficheros MUD es necesario conectar todo el escenario. Esto se hace a través del Device and Domain Manager presentado en la figura 4.1. El DDM desplegado para este trabajo tiene las siguientes características: 1. Se comunica con el Bootstrapping-Server para obtener información sobre los dispositivos que tratan de realizar el proceso de bootstrapping. Toda la información sobre estos dispositivos es almacenada en una base de datos gestionada por el DDM y cierta información que se utiliza en esa base de datos se obtiene a través de esta comunicación, como la dirección IP o el MUD URL. 2. Solicita al MUD Manager los ficheros MUD de los dispositivos IoT que está gestionando. Para ello hace uso de los MUD URLs que va obteniendo. 3. Interpreta el contenido de los ficheros MUD que obtiene del MUD Manager y los traduce a políticas de comportamiento que puedan ser utilizadas. Esta traducción se hace a lenguaje MSPL siguiendo el modelo sugerido en [29, 38]. 4. Interpreta las políticas obtenidas con la traducción para enviar comandos al ERA cuando sea pertinente. Para desplegar dicho DDM los pasos que se han realizado pueden ser resumidos del siguiente modo: •Paso 1. Creación de un entorno virtual para Python. El código que ha sido reutilizado del proyecto CERTIFY para desplegar el DDM hace uso de librerías de Python muy específicas. Por ello, para no instalar en nuestro sistema todas estas librerías, podemos crear un entorno virtual que tenga estrictamente lo necesario para trabajar con el DDM. Esto se puede hacer del siguiente modo: # Asumimos que estamos en el directorio donde tenemos el código fuente del DDM # Creamos un entorno virtual al que llamamos venv. Si este comando falla, previamente # habrá que ejecutar: sudo apt install python3.12-venv python3 -m venv venv # Activamos el entorno virtual creado source venv/bin/activate # Una vez que tenemos el entorno activado, comenzamos a instalar las librerías necesarias # dentro de este entorno pip3 install pyangbind pip3 install PyYAML pip3 install SQLAlchemy pip3 install Flask pip3 install requests pip3 install bitarray 44 Diseño y resolución del trabajo realizado Figura 4.5: PoC: Consecuencias del bootstrapping (continuación) 4.4. Prueba de la PoC desarrollada 45 Las figuras 4.4 y4.5 buscan mostrar que el estado de todas las entidades que aparecían en la figura 4.2 se ha visto actualizado. Sin embargo, tratar de comprender qué ha ocurrido con estas imágenes sería imposible, pues ni siquiera se puede ver toda la información que han generado. Por ello, vamos a mostrar el estado de cada una de estas entidades por separado. Comenzamos entonces con las entidades relacionadas con el Bootstrapping-Server. En concreto, la figura 4.2 mostraba que este se dividía en dos entidades: BOOTSTRAPPING yAAA SERVER. Estas corresponden a las entidades que se definieron en la figura 2.1, siendo BOOTSTRAPPING el controlador central y AAA SERVER la infraestructura AAA. La figura 4.6 muestra la información generada por la entidad BOOTSTRAPPING. En ella, podemos confirmar que actúa como el controlador central para realizar el bootstrapping, pues es la entidad que actúa como intermediario entre el dispositivo IoT y el AAA SERVER. En la figura aparece un registro sobre los principales eventos que ocurren mientras se completa el bootstrapping. Entre estos destaca la redirección de mensajes EAP entre el dispositivo IoT y el AAA SERVER, y el envío de información hacia el Device and Domain Manager una vez se ha completado la autenticación del dispositivo. Es interesante destacar que entre la información que se envía al Device and Domain Manager se incluye el MUD URL que se debería usar para la configuración de políticas de seguridad en el dispositivo. Como se mencionó en la sección 4.3.2.2, la URL que se puede observar no tiene un significado real, es una cadena de prueba que permite simular el uso de un MUD URL. 46 Diseño y resolución del trabajo realizado Figura 4.6: PoC: Consecuencias del bootstrapping en el controlador central 4.4. Prueba de la PoC desarrollada 47 Figura 4.7: PoC: Consecuencias del bootstrapping en el AAA server 48 Diseño y resolución del trabajo realizado En la figura 4.7 podemos ver las acciones que se llevan a cabo en el AAA SERVER durante el proceso de bootstrapping. La figura muestra con detalle la autenticación EAP-PSK descrita en la sección 2.1.1.2. Para indicar el momento en el que comienza cada uno de los pasos descritos en dicha sección se ha remarcado el mensaje que da comienzo a cada etapa13. Además, es interesante destacar que tal y como se expuso en dicha sección el proceso de autenticación EAP-PSK concluye con la obtención de material criptográfico. En la figura podemos apreciar esto al final de la imagen, donde podemos ver que se derivan dos claves criptográficas definidas para este protocolo: MSK y Extended Master Session Key (EMSK) El siguiente paso es mostrar cómo se ha visto actualizada la información que muestra el intermediario entre el Bootstrapping-Server y el Device and Domain Manager, el Post-Server. Esto se puede apreciar en la figura 4.8. En ella podemos ver que ha recibido la información del dispositivo que acaba de realizar el bootstrapping. Entre esta información tenemos la dirección IP del dispositivo IoT, un MUD URL y dos identificadores del mismo. Figura 4.8: PoC: Consecuencias del bootstrapping en el Post-Server El hecho de que el Post-Server haya recibido una actualización implica que esta información sea reenviada al Device and Domain Manager, provocando que se recupere el fichero MUD asociado al dispositivo que ha realizado el bootstrapping. Por tanto, las entidades MUD Manager, MUD Server y Device and Domain Manager actualizan la información que muestran, indicando cómo se recupera el fichero MUD y se realiza su traducción a lenguaje MSPL. Esto se puede observar en las figuras 4.9,4.11 y4.10. 13Destacar que el mensaje “AAA Server: EAP-Response/Success message sent to client” marcado en la imagen es un error del desarrollador del código. El mensaje que se está enviado en realidad es el mensaje EAP PSK 3. 4.4. Prueba de la PoC desarrollada 49 Figura 4.9: PoC: Consecuencias del bootstrapping en el DDM Figura 4.10: PoC: Consecuencias del bootstrapping en el MUD Server 50 Diseño y resolución del trabajo realizado Figura 4.11: PoC: Consecuencias del bootstrapping en el MUD Manager Además, el Device and Domain Manager registra en su base de datos al dispositivo que ha realizado el proceso de bootstrapping. Esto se puede apreciar en la figura C.1 del anexo C14. Una vez completado el proceso de bootstrapping, si volvemos a las figuras 4.3 y4.9, podemos ver que ambas han quedado listas para realizar un proceso de reconfiguración en el dispositivo IoT. En concreto, podemos aplicar la política de cambio de algoritmo de firma. Esto es lo que se puede observar en las figuras 4.12 y4.13. 14Esta foto ha sido añadida en el anexo Cpor falta de legibilidad en formato vertical. 4.4. Prueba de la PoC desarrollada 51 Figura 4.12: PoC: DDM tras aplicar el cambio de algoritmo de firma 52 Diseño y resolución del trabajo realizado Figura 4.13: PoC: Raspberry tras aplicar el cambio de algoritmo de firma De esta forma se pone fin a la prueba del escenario desplegado para este trabajo. 5. Evaluación de la PoC desarrollada En la sección 4hemos presentado la PoC desarrollada para este trabajo. En concreto, hemos realizado tres acciones: definir los elementos que la componen, explicar cómo se ha desplegado cada uno de esos elementos y finalmente, proporcionar un ejemplo de su correcto funcionamiento. En esta sección buscamos completar la presentación de la PoC proporcionando una evaluación del sistema desplegado. En concreto, proporcionaremos medidas del tiempo de ejecución de las principales actividades que se realizan en el escenario propuesto. De este modo, estas pueden servir como base para futuras mejoras, pues las posibles evoluciones de la PoC deberían tener entre sus objetivos reducir el tiempo de ejecución del escenario. Además, las medidas que se presentarán en esta sección pueden ser de utilidad para comparar cómo de buenas, en términos de rendimiento, son otras alternativas para la gestión de dispositivos IoT. Para realizar esta evaluación, el primer paso es tener claro el escenario que se ha desarrollado en este trabajo, pues solo así se puede valorar qué actividades merecen la pena ser evaluadas. Para ello, en la figura 5.1 se proporciona un diagrama de flujo que resume la PoC desarrollada. Como se puede observar en dicha figura, el escenario sigue un flujo secuencial, donde el primer paso es realizar el proceso de bootstrapping CoAP-EAP. Esa etapa concluye con el envío al DDM de información del dispositivo que ha completado el bootstrapping (pasos 2 y 3 del diagrama), permitiendo así que pueda comenzar la fase de reconfiguración del dispositivo. Una vez el DDM tiene la información del dispositivo que ha completado el bootstrapping, puede proceder a recuperar el fichero MUD que tiene asociado. Para ello, interactúa con el MUD Server a través del MUD Manager (paso 4 del diagrama). Así, tras recibir el MUD file (paso 5 del diagrama), puede procesarlo y mandar una solicitud de reconfiguración al dispositivo IoT si lo considera pertinente (paso 6 del diagrama). Dicha solicitud es procesada por el ERA del dispositivo y si se considera válida, es aplicada (paso 7 del diagrama). Bibliografía [1] D. García Carrillo. A CoAP-based bootstrapping service for large-scale Internetof-things networks. PhD thesis, Universidad de Murcia (UMU), Murcia, 2018. [2] Miguel Angel López Peña. DevOps Aplicado a Sistemas IoT: Definición e Implementación de Procesos Continuos de Monitorización y Retroalimentación. PhD Thesis, Universidad Politécnica de Madrid, Madrid, 2021. URL http: //oa.upm.es/68043/. [3] Satyajit Sinha. IOT ANALYTICS, 2024. URL https://iot-analytics.com/ number-connected-iot-devices/. [4] Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales., 2018. URL https://www.boe.es/eli/es/lo/ 2018/12/05/3/con. [5] CERTIFY, (s.f.). URL https://certify-project.eu/. [6] Eliot Lear, Ralph Droms, and Dan Romascanu. Manufacturer Usage Description Specification, 2019. URL https://datatracker.ietf.org/doc/html/rfc8520. [7] Sameh Khalfaoui. Security bootstrapping for Internet of Things. PhD thesis, Institut Poytechnique de Paris, Francia, 2022. [8] Dan García Carrillo. EAP-based Authentication Service for CoAP, 2024. URL https://datatracker.ietf.org/doc/html/ draft-ietf-ace-wg-coap-eap-12. [9] Russ Housley and Dr. Bernard D. Aboba. Guidance for Authentication, Authorization, and Accounting (AAA) Key Management, 2007. URL https:// datatracker.ietf.org/doc/html/rfc4962. [10] Dr. Bernard D. Aboba and Jonathan Wood. Authentication, Authorization and Accounting (AAA) Transport Profile, 2003. URL https://datatracker.ietf. org/doc/html/rfc3539. [11] John Vollbrecht, James D. Carlson, Larry Blunk, Bernard D. Aboba, and Henrik Levkowetz. Extensible Authentication Protocol (EAP), 2004. URL https:// datatracker.ietf.org/doc/html/rfc3748. Bibliografía 61 [12] Zach Shelby, Klaus Hartke, and Carsten Bormann. The Constrained Application Protocol (CoAP), 2014. URL https://datatracker.ietf.org/doc/html/ rfc7252. [13] Agustín Bassi. Introducción a CoAP, 2021. URL https://www.gotoiot.com/ pages/articles/coap_intro/index.html#:~:text=CoAP%20(Constrained% 20Application%20Protocol)%20es,que%20puedan%20comunicarse%20sobre% 20internet. [14] Henrik Nielsen, Jeffrey Mogul, Larry M Masinter, Roy T. Fielding, Jim Gettys, Paul J. Leach, and Tim Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1, 1999. URL https://datatracker.ietf.org/doc/html/rfc2616. [15] Eddy Wesley. Transmission Control Protocol (TCP), 2022. URL https:// datatracker.ietf.org/doc/html/rfc9293. [16] User Datagram Protocol, 1980. URL https://datatracker.ietf.org/doc/ html/rfc768. [17] Florent Bersani and Hannes Tschofenig. The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method, 2007. URL https:// datatracker.ietf.org/doc/html/rfc4764. [18] Itai Turbahn. Introduction to Trusted Execution Environments (TEEs), 2024. URL https://www.dynamic.xyz/blog/trusted-execution-environments. [19] What is a Trusted Execution Environment (TEE)?, 2019. URL https://www.trustonic.com/technical-articles/ what-is-a-trusted-execution-environment-tee/. [20] What is a Trusted Application?, 2024. URL https://licelus.com/insights/ what-is-a-trusted-application#:~:text=A%20Trusted%20Application% 20is%20a,%2C%20authentication%2C%20and%20secure%20storage. [21] Introduction to Trusted Execution Environments. Technical report, 2018. URL https://globalplatform.org/wp-content/uploads/2018/ 05/Introduction-to-Trusted-Execution-Environment-15May2018.pdf. [22] Jose L. Hernandez-Ramos, Sara N. Matheu, Angelo Feraudo, Gianmarco Baldini, Jorge Bernal Bernabe, Poonam Yadav, Antonio Skarmeta, and Paolo Bellavista. Defining the Behavior of IoT Devices Through the MUD Standard: Review, Challenges, and Research Directions. IEEE Access, 9:126265–126285, 2021. ISSN 2169-3536. doi: 10.1109/ACCESS.2021.3111477. URL https: //ieeexplore.ieee.org/document/9531614/. 62 Bibliografía [23] Martin Björklund. The YANG 1.1 Data Modeling Language, 2016. URL https: //datatracker.ietf.org/doc/html/rfc7950. [24] Tim Bray. The JavaScript Object Notation (JSON) Data Interchange Format, 2017. URL https://datatracker.ietf.org/doc/html/rfc8259. [25] Mahesh Jethanandani, Sonal Agarwal, Lisa Huang, and Dana Blair. YANG Data Model for Network Access Control Lists (ACLs), 2019. URL https: //datatracker.ietf.org/doc/html/rfc8519. [26] Stefano Sebastio, Sara Matheu, Antonio Skarmeta, Riccardo Orizio, Dimitris Karras, Daria Schumm, Burkhard Stiller, Rosella Omana Mancilla, Francesca Giampaolo, Simon Tuck, Thomas Bocek, Vincenzo Cuomo, Roland Atoui, Sreedevi Beena, Roberto Nardone, Alessandro Cilardo, Dinesh Sharma, Rohit Bohara, and Javier Parra-Domínguez. Cybersecurity Management Throughout the IoT Systems Lifecycle – The CERTIFY Approach. In Rashid Mehmood, Guillermo Hernández, Isabel Praça, Jaroslaw Wikarek, Roussanka Loukanova, Arsénio Monteiro Dos Reis, Antonio Skarmeta, and Eleonora Lombardi, editors, Distributed Computing and Artificial Intelligence, Special Sessions I, 21st International Conference, volume 1198, pages 281–290. Springer Nature Switzerland, Cham, 2025. ISBN 978-3-031-76458-5 978-3-031-76459-2. doi: 10.1007/978-3-031-76459-2_26. URL https://link.springer.com/10.1007/978-3-031-76459-2_26. Series Title: Lecture Notes in Networks and Systems. [27] Fulvio Valenza and Antonio Lioy. User-oriented Network Security Policy Specification. [28] Alejandro Molina Zarca, Jorge Bernal Bernabé, Jordi Ortíz, and Antonio Skarmeta. Policy-based Definition and Policy for Orchestration FInal Report. Technical report, 2018. URL https://ec.europa.eu/research/participants/ documents/downloadPublic?documentIds=080166e5c03f6297&appId=PPGMS. [29] Sara N. Matheu, Alberto Robles Enciso, Alejandro Molina Zarca, Dan GarcíaCarrillo, José Luis Hernández-Ramos, Jorge Bernal Bernabé, and Antonio F. Skarmeta. Security Architecture for Defining and Enforcing Security Profiles in DLT/SDN-Based IoT Systems. 2020. URL https://www.mdpi.com/1424-8220/ 20/7/1882. [30] Dan García Carrillo. draft-ietf-coap-eap-proof-of-concept, 2022. URL https:// github.com/dangarciacarrillo/draft-ietf-coap-eap-proof-of-concept. [31] OpenSSL Documentation, (s.f.). URL https://docs.openssl.org/master/. [32] Universally Unique IDentifiers (UUIDs), 2024. URL https://datatracker. ietf.org/doc/rfc9562/. Bibliografía 63 [33] Getting started with your Raspberry Pi, (s.f.). URL https://www.raspberrypi. com/documentation/computers/getting-started.html. [34] About OP-TEE. URL https://optee.readthedocs.io/en/latest/general/ about.html. [35] Amit Nadiger. OPTEE, 2023. URL https://www.linkedin.com/pulse/ tee-optee-amit-nadiger. [36] Build and run, (s.f.). URL https://optee.readthedocs.io/en/latest/ building/prerequisites.html. [37] Jose Manuel Merlos Espín. CERTIFY-OP-TEE, 2024. URL https:// ants-gitlab.inf.um.es/jmanuel/certify-op-tee. [38] Sara Matheu, Stefano Sebastio, Antonio Skarmeta, Riccardo Orizio, Stefanos Vasileiadis, Vasilis Kalos, Katharina Müller, Thomas Grübl, Rosella Omana Mancilla, Simon Tuck, Thomas Bocek, Vincenzo Cuomo, Roland Atoui, Sreedevi Beena, Luigi Coppolino, Roberto Nardone, Dinesh Sharma, Rohit Bohara, Javier ParraDomínguez, and Javier Prieto. Active Security for Connected Device Lifecycle: The CERTIFY Architecture. In Rashid Mehmood, Guillermo Hernández, Isabel Praça, Jaroslaw Wikarek, Roussanka Loukanova, Arsénio Monteiro dos Reis, Antonio Skarmeta, and Eleonora Lombardi, editors, Distributed Computing and Artificial Intelligence, Special Sessions I, 21st International Conference, pages 301–310, Cham, 2025. Springer Nature Switzerland. ISBN 978-3-031-76459-2. [39] Eric Rescorla. HTTP Over TLS, 2000. URL https://datatracker.ietf.org/ doc/html/rfc2818. [40] Hugo Krawczyk, Mihir Bellare, and Ran Canetti. HMAC: Keyed-Hasing for Message Authentication, 1997. URL https://datatracker.ietf.org/doc/html/ rfc2104. [41] Evangelos Haleplidis, Kostas Pentikousis, Spyros Denazis, Jamal Hadi Salim, David Meyer, and Odysseas Koufopavlou. Software-Defined Networking (SDN): Layers and Architecture Terminology, 2015. URL https://datatracker.ietf. org/doc/html/rfc7426. [42] Extensible Markup Language (XML) 1.0 (Fifth Edition), 2008. URL https: //www.w3.org/TR/xml/. [43] xml.etree.ElementTree - The ElementTree XML API. URL https://docs. python.org/3/library/xml.etree.elementtree.html. [44] Chris M. Lonvick and Tatu Ylonen. The Secure Shell (SSH) Protocol Architecture, 2006. URL https://datatracker.ietf.org/doc/html/rfc4251. A. Anexo I. Fichero MUD generado { "ietf-mud:mud": { "mud-version": 1, "mud-url": "https://www.example.com/yourmudfile.json", "last-update": "2024-12-18T21:07:00+01:00", "cache-validity": 48, "extensions": [ "umu-mspl-list:mspls" ], "is-supported": true, "modelname": "raspberry pi 3 model B", "systeminfo": "raspberyy pi 3 model B current MUD File", "from-device-policy": { "access-lists": { "access-list": [ { "name": "outbound-stricted-communication" } ] } }, "to-device-policy": { "access-lists": { "access-list": [ { "name": "inbound-stricted-communication" } ] } } }, "ietf-access-control-list:acls": { "acl": [ { "name": "outbound-stricted-communication", "type": "ipv4-acl-type", "aces": { "ace": [ { "name": "output-rule", "matches": { "ipv4": { "destination-ipv4-network": "192.168.100.0/24", "protocol": 6 }, "tcp": { "ietf-mud:direction-initiated": "from-device", "destination-port": { "operator": "eq", "port": 443 } } 65 }, "actions": { "forwarding": "accept" } } ] } }, { "name": "inbound-stricted-communication", "type": "ipv4-acl-type", "aces": { "ace": [ { "name": "input-rule", "matches": { "ipv4": { "source-ipv4-network": "192.168.100.0/24", "protocol": 6 }, "tcp": { "ietf-mud:direction-initiated": "to-device", "source-port": { "operator": "any", "port": "*" } } }, "actions": { "forwarding": "accept" } } ] } } ] }, "umu-mspl-list:mspls": { "mspl": [ { "name": "mspl_change_signature", "type": "software-mspl-type", "configuration": { "capability": "software-protection", "rule-set-configuration": { "name": "change_signature_rule_set", "configuration-rule": { "name": "change_signature_rule", "configuration-action": { "software-protection-action": { "software-protection-type": "USE-HMAC" } } } } } }, { "name": "mspl_filtering", "type": "ipv4-mspl-type", "configuration": { "capability": "Filtering_L4", "rule-set-configuration": { "name": "filtering_rule_set", 66 Anexo I. Fichero MUD generado "configuration-rule": [ { "name": "filtering_rule", "configuration-action": { "filteringAction": { "filtering-action-type": "ALLOW" } }, "configuration-condition": { "filtering-configuration-condition": { "packet-filter-condition": { "source_dnsname": "bootstrapping-server.umu", "destination_dnsname": "raspberry-pi-3-modelB-TFG.umu←- ,→", "source_port": "any", "destination_port": "any", "direction": "INBOUND", "protocol_type": "6" } } } } ] } } } ] } } B. Anexo II. Traducción del fichero MUD a MSPL <!-- MSPL 1 – Permitir tráfico con la red 192.168.100.0/24 --> <?xml version="1.0" encoding="UTF-8"?> <mspl> <name type="str">mspl_example</name> <configuration type="dict"> <capability type="str">Filtering_L4</capability> <rule-set-configuration type="dict"> <name type="str">rule_seta963b7a3-1dcb-49e2-8ed6-3fb9a1c37c64</name> <default-action type="str">deny</default-action> <configuration-rule type="dict"> <output-rule type="dict"> <external-data type="dict"> <priority type="int">1</priority> </external-data> <configuration-action type="dict"> <filtering-action type="dict"> <filtering-action-type type="str">allow</filtering-action-type> </filtering-action> </configuration-action> <configuration-condition type="dict"> <filtering-configuration-condition type="dict"> <packet-filter-condition type="dict"> <destination-address type="str">192.168.100.0/24</destination-←- ,→address> <destination-port type="str">eq 443</destination-port> <direction type="str">OUTBOUND</direction> <protocol-type type="str">6</protocol-type> </packet-filter-condition> </filtering-configuration-condition> </configuration-condition> <name type="str">output-rule</name> </output-rule> <input-rule type="dict"> <external-data type="dict"> <priority type="int">1</priority> </external-data> <configuration-action type="dict"> <filtering-action type="dict"> <filtering-action-type type="str">allow</filtering-action-type> </filtering-action> </configuration-action> <configuration-condition type="dict"> <filtering-configuration-condition type="dict"> <packet-filter-condition type="dict"> <source-address type="str">192.168.100.0/24</source-address> <source-port type="str">any *</source-port> <direction type="str">INBOUND</direction> <protocol-type type="str">6</protocol-type> </packet-filter-condition> 68 Anexo II. Traducción del fichero MUD a MSPL </filtering-configuration-condition> </configuration-condition> <name type="str">input-rule</name> </input-rule> </configuration-rule> </rule-set-configuration> </configuration> </mspl> <!-- MSPL 2 – Política de cambio de algoritmo de firma --> <?xml version="1.0" encoding="utf-8"?> <mspl> <configuration> <capability>software-protection</capability> <rule-set-configuration> <configuration-rule> <configuration-action> <software-protection-action> <software-protection-type>USE-HMAC</software-protection-type> </software-protection-action> </configuration-action> <name>change_signature_rule</name> </configuration-rule> <name>change_signature_rule_set</name> </rule-set-configuration> </configuration> <name>mspl_change_signature</name> <type>software-mspl-type</type> </mspl> <!-- MSPL 3 – Permitir tráfico entrante desde servidor de boostrapping de la UMU --> <?xml version="1.0" encoding="utf-8"?> <mspl> <configuration> <capability>Filtering_L4</capability> <rule-set-configuration> <configuration-rule> <configuration-action> <filteringAction> <filtering-action-type>ALLOW</filtering-action-type> </filteringAction> </configuration-action> <configuration-condition> <filtering-configuration-condition> <packet-filter-condition> <destination_dnsname>raspberry-pi-3-modelB-TFG.umu</←- ,→destination_dnsname> <destination_port>any</destination_port> <direction>INBOUND</direction> <protocol_type>6</protocol_type> <source_dnsname>bootstrapping-server.umu</source_dnsname> <source_port>any</source_port> </packet-filter-condition> </filtering-configuration-condition> </configuration-condition> <name>filtering_rule</name> </configuration-rule> <name>filtering_rule_set</name> </rule-set-configuration> </configuration> <name>mspl_filtering</name> <type>ipv4-mspl-type</type> </mspl> C. Anexo III. Base de datos del Device and Domain Manager En este anexo se incluye una imagen sobre el contenido de la base de datos del Device and Domain Manager una vez la Raspberry Pi 3 Model B ha completado el proceso de bootstrapping. El motivo de añadir este anexo es que en la sección 4.4 es imposible colocar la imagen de forma que esta pueda ser legible. Por ello, hacemos uso del formato apaisado en este anexo para poder visualizar el contenido de la base de datos.