Dasdese Arerreernexreerreererre - En.es

Traducido del inglés al español - www.onlinedoctranslator.
com
Este artículo ha sido aceptado para su publicación en un número futuro de esta revista, pero no ha sido editado en su totalidad. El contenido puede cambiar antes de la publicación final. Información de citas: DOI 10.1109/JIOT.2020.3043740, IEEE Internet de
diario de cosas
Arquitectura de IoT segura habilitada para SDN

Kalol Krishna KarmakarMiembro, IEEE, Vijay VaradharajanMiembro sénior, IEEE, Surya Nepal y Uday
TupakulaMiembro, IEEE
Abstracto—El Internet de las cosas (IoT) se utiliza cada vez más en aplicaciones que van desde la agricultura de muchos dispositivos y aplicaciones IoT ya están en funcionamiento sin
precisión hasta la infraestructura nacional crítica mediante el despliegue de una gran cantidad de dispositivos con ningún mecanismo de seguridad. Un desafío importante es cómo
recursos limitados en entornos hostiles. Estos dispositivos están siendo explotados para lanzar ataques en los sistemas
proporcionar seguridad en dichas infraestructuras de IoT [4, 5].
cibernéticos. Como resultado, la seguridad se ha convertido en una preocupación importante en el diseño de
aplicaciones basadas en IoT. En este documento, presentamos una arquitectura de seguridad para redes IoT
Debido a la naturaleza de recursos limitados de los
aprovechando las funciones subyacentes compatibles con las redes definidas por software (SDN). Nuestra arquitectura dispositivos IoT, un atacante puede atacarlos fácilmente
de seguridad no solo restringe el acceso a la red a dispositivos IoT autenticados, sino que también aplica políticas enviando solicitudes falsificadas, interceptando y
granulares finas para proteger los flujos en la infraestructura de la red IoT. La autenticación se logra mediante un
manipulando ilegalmente datos de sensores valiosos en
protocolo ligero para autenticar dispositivos IoT. La autorización se logra utilizando un enfoque dinámico basado en
tránsito o capturando un dispositivo físico y
políticas. Este enfoque de seguridad integrado implica la autenticación de dispositivos IoT y permite flujos autorizados
para proteger las redes IoT de dispositivos y ataques IoT maliciosos. Implementamos y validamos nuestra arquitectura
transformándolo en un zombi para lanzar ataques en otros
usando ONOS SDN Controller y Raspbian Virtual Machines, y demostramos cómo los mecanismos de seguridad sistemas. Los ataques de denegación de servicio (DoS) y
propuestos pueden contrarrestar la inyección de paquetes de malware, los ataques DDoS usando Mirai, la agotamiento de energía son los ataques de IoT más
suplantación de identidad/enmascaramiento y los ataques Man-in-The-Middle. En el documento se presenta un análisis
comunes [6, 7]. A menudo, no es posible implementar la
de la seguridad y el rendimiento de los mecanismos de seguridad propuestos y sus aplicaciones. Implementamos y
seguridad en estos dispositivos utilizando los mecanismos
validamos nuestra arquitectura usando ONOS SDN Controller y Raspbian Virtual Machines, y demostramos cómo los
mecanismos de seguridad propuestos pueden contrarrestar la inyección de paquetes de malware, los ataques DDoS
de defensa tradicionales, ya que están ubicados en
usando Mirai, la suplantación de identidad/enmascaramiento y los ataques Man-in-The-Middle. En el documento se entornos abiertos y generarían una carga computacional
presenta un análisis de la seguridad y el rendimiento de los mecanismos de seguridad propuestos y sus aplicaciones. adicional en los dispositivos IoT pequeños. Un problema
Implementamos y validamos nuestra arquitectura usando ONOS SDN Controller y Raspbian Virtual Machines, y
principal es cómo garantizar que solo se utilicen datos
demostramos cómo los mecanismos de seguridad propuestos pueden contrarrestar la inyección de paquetes de
autenticados de dispositivos IoT legítimos en el
malware, los ataques DDoS usando Mirai, la suplantación de identidad/enmascaramiento y los ataques Man-in-The-
Middle. En el documento se presenta un análisis de la seguridad y el rendimiento de los mecanismos de seguridad

procesamiento en la nube y en la prestación de servicios.
propuestos y sus aplicaciones. En este documento, desarrollamos una solución de
arquitectura basada en red que puede ayudar a proteger la
Términos del Índice—Seguridad de Internet de las cosas (IoT), seguridad de
red definida por software (SDN), arquitectura de IoT segura basada en infraestructura de IoT.
políticas, autenticación de IoT y control de acceso. Nuestra arquitectura de seguridad utiliza redes definidas por software
(SDN) para administrar de forma segura las infraestructuras de IoT.
SDN desacopla el plano de control del plano de datos y proporciona
yo yoNTRODUCCIÓN una autoridad centralizada (controlador SDN) para administrar los
El Internet de las cosas (IoT) está siendo promocionado como la próxima recursos (como dispositivos de red e IoT) dentro del dominio bajo su
gran tendencia tecnológica tanto por investigadores académicos como por control. Dado que el controlador de SDN tiene visibilidad sobre su
actores de la industria. El IoT se refiere a la conexión de 'cosas' en el mundo dominio de red, las aplicaciones que se ejecutan en el controlador
real a través de Internet, de modo que estas 'cosas' puedan comunicarse tienen la capacidad de administrar la seguridad de la infraestructura de
entre sí y con otros servicios de Internet. Los ejemplos de dispositivos van red de IoT subyacente. El uso de SDN para administrar los dispositivos
desde bombillas inteligentes, cerraduras de puertas, sensores de tráfico, IoT no es nuevo en sí mismo; otros trabajos [8, 9] han utilizado este
monitores para bebés y dispositivos de atención médica. Estos dispositivos enfoque para detectar dispositivos maliciosos y detectar ataques. En
IoT pueden ser pequeños y con recursos limitados, así como estar [10], los autores han presentado un estudio exhaustivo de las técnicas
integrados en otros objetos del mundo real. Según una estimación de la de SDN para proteger la infraestructura de IoT. Sin embargo, en
industria, se espera que la cantidad de dispositivos IoT alcance los 50 mil nuestra arquitectura, SDN Controller actúa como una autoridad de
millones para 2020 [1]. IoT permite la conexión del mundo físico con el decisión de política de seguridad, y los conmutadores de red y las
mundo cibernético, lo que permite el monitoreo y control remoto de objetos puertas de enlace de IoT hacen cumplir las políticas de seguridad en la
físicos del mundo cibernético [2, 3]. La heterogeneidad de los dispositivos infraestructura de red de IoT. Este enfoque basado en políticas brinda
IoT, La infraestructura de comunicación subyacente y los diferentes tipos de la capacidad de lograr una gestión segura de los flujos de red en una
protocolos utilizados por estos dispositivos aumentan la complejidad de la infraestructura de IoT de manera dinámica y hacer frente a los ataques
infraestructura de IoT y la hacen vulnerable a los ataques de seguridad. de seguridad de manera proactiva.
Como ha sido el caso con Internet, la seguridad se ha convertido en una idea En este documento, describimos una arquitectura de seguridad basada en
tardía y políticas que usa SDN para una infraestructura de red IoT. La arquitectura de
seguridad utiliza políticas detalladas para controlar y administrar servicios y
Vijay Varadharajan es el director de ACSRC, la Universidad de Newcastle, Australia. dispositivos de IoT, así como para proteger los flujos correspondientes en la
Correo electrónico: vijay.varadharajan@newcastle.edu.au
Kallol Karmakar y Uday Tupakula trabajan en la Escuela de Ingeniería infraestructura de IoT. Por ejemplo, las políticas pueden imponer la creación
Eléctrica y Computación de la Universidad de Newcastle, Australia. de canales seguros para datos de dispositivos IoT autenticados particulares
Correo electrónico: kallolKrishna.Karmakar@newcastle.edu.au y a través de puertas de enlace específicas a la nube. Esto puede ayudar a
uday.tupakula@newcastle.edu.au
Surya Nepal es científica investigadora principal sénior en Data61 de CSIRO, Australia. lograr una gestión de flujo segura en la infraestructura de red de IoT.
Correo electrónico: Surya.Nepal@data61.csiro.au Nuestra arquitectura de seguridad también
2327-4662 (c) 2020 IEEE. Se permite el uso personal, pero la republicación/redistribución requiere el permiso de IEEE. Consulte http://www.ieee.org/publications_standards/publications/rights/index.html para obtener más información.
Licencia de uso autorizada limitada a: Universidad Nacional Abierta ya Distancia. Descargado el 14 de febrero de 2021 a las 16:57:38 UTC desde IEEE Xplore. Se aplican restricciones.
diario de cosas
proporciona servicios de IoT habilitados para autenticación de dispositivos e B. Modelo de amenazas de IoT:
integridad de datos, así como autorización de dispositivos para servicios de
red. Se ha desarrollado un protocolo ligero basado en criptografía de curva Las diferentes capas de arquitectura de IoT albergan una combinación
elíptica (ECC) para lograr la autenticación de dispositivos IoT y la integridad de diferentes tecnologías y, por lo tanto, son vulnerables a diferentes
de los datos IoT. La autorización para los servicios de red solicitados por amenazas y ataques. Es difícil, si no imposible, abordar las diversas
diferentes dispositivos IoT se logra mediante el protocolo de autorización amenazas en las diferentes capas utilizando una única solución. Dado
abierta (OAuth) [11]. La arquitectura propuesta se ha implementado que nuestro enfoque en este documento es proteger la infraestructura
utilizando ONOS SDN Controller. Demostramos la capacidad de nuestra de red de IoT, consideraremos principalmente las amenazas en la capa
arquitectura para asegurar la infraestructura de IoT utilizando escenarios de de red. Los componentes de cada capa de IoT, las tareas realizadas en
IoT de la vida real y mostramos cómo puede contrarrestar ataques (como la capa y las amenazas asociadas se presentan en la Tabla I.
Mirai) y detectar dispositivos de IoT maliciosos. Las capas de aplicación y middleware son vulnerables a los ataques de
software [13]. Los ataques típicos en estas capas incluyen inyección de
Las contribuciones de nuestro trabajo se pueden resumir de la siguiente manera:
código, desbordamiento de búfer y otros ataques de malware. No
abordamos los ataques en estas capas en este documento.
• Una arquitectura de seguridad basada en SDN que utiliza un enfoque basado
Las capas de red y percepción son vulnerables a ataques como el ataque de
en políticas para proteger la infraestructura de red de IoT y detectar
inyección de malware, ataques DDoS por parte de dispositivos IoT zombis
dispositivos y ataques de IoT maliciosos.
(por ejemplo, Mirai), suplantación de identidad/enmascaramiento y ataques
• Autenticación de dispositivos IoT mediante un protocolo ligero, que
Manin-the-Middle (MiTM). En este documento, nos centramos en estos
a su vez se utiliza en el aprovisionamiento de servicios de red para
ataques. Además, los ataques pueden tener varias etapas. Por ejemplo, en
dispositivos IoT autenticados.
Mirai, la primera etapa involucra la inyección de malware, seguida en la
• Acceso seguro a los servicios de red mediante dispositivos autenticados
segunda etapa por un ataque de inundación. La Sección IV proporciona un
mediante el protocolo OAuth.
análisis detallado de estos ataques utilizando nuestra arquitectura
• Demostración de la arquitectura y los protocolos de seguridad
propuesta.
propuestos utilizando un escenario de IoT realista, que muestra
cómo puede proteger la infraestructura de IoT de ataques como Amenaza 1 (inyección de malware):El firmware de los dispositivos IoT a
Malware Injection, DDoS, Spoofing/Masquerading y Man-in-The- menudo tiene características de seguridad de baja resistencia grabadas
Middle (MiTM). en su hardware por los fabricantes de dispositivos. Por lo tanto, son
• Análisis de rendimiento de la solución propuesta para asegurar la vulnerables a diferentes tipos de compromisos de red y ataques de
infraestructura IoT. inyección de paquetes. Por ejemplo, un dispositivo IoT con un puerto
Telnet abierto que permite que un adversario malicioso inyecte
El documento está estructurado de la siguiente manera. La Sección II brinda una
paquetes de malware y comprometa el dispositivo para más ataques
descripción general de la infraestructura de IoT y las posibles amenazas a la
coordinados. La ejecución de malware a menudo usa el software/API
seguridad. La Sección III describe la arquitectura de seguridad basada en SDN
en la capa de aplicación.
para la infraestructura de IoT. La Sección IV demuestra la aplicación de la
Amenaza 2 (DDoS):En la red IoT, un adversario puede usar dispositivos IoT
arquitectura de seguridad propuesta utilizando diferentes escenarios de IoT. En
para lanzar ataques DDoS para obstruir los servicios de red y servicios de
particular, analizamos los escenarios de ataques de botnets de IoT y cómo se
dispositivos IoT específicos. Debido a que muchos dispositivos IoT no tienen
contrarrestan con éxito utilizando nuestra arquitectura de seguridad. Los trabajos
ninguna funcionalidad de seguridad y debido a su naturaleza de recursos
relacionados relevantes se discuten en la Sección V. Finalmente, la Sección VI
limitados, son propensos a ataques que conducen al agotamiento de la
concluye el documento.
energía. Luego, estos dispositivos comprometidos lanzan ataques de
inundación coordinados contra los servicios de red y usuarios/dispositivos
II. IINTERNET DETBISAGRAS(IOT) TAMENAZAMETROODEL específicos. Estos ataques tienen como objetivo la capa de red y percepción.
En esta sección, brindamos una descripción general de las diferentes capas en una Mirai es un ejemplo perfecto de las amenazas 1 y 2. La primera fase de Mirai
arquitectura de IoT y describimos nuestro modelo de amenazas. utiliza un ataque de inyección de paquetes de malware para comprometer
los dispositivos IoT y crear zombies/bots. En la segunda fase, los zombis
(dispositivos comprometidos) utilizan una inundación de paquetes
A. Infraestructura IoT: coordinada para obstruir los servicios de red. Hemos proporcionado una
discusión detallada sobre Mirai en la Sección IV.
Se puede pensar que una infraestructura de IoT consta de cuatro
capas de arquitectura, a saber, Percepción, Red, Middleware y Amenaza 3 (suplantación de identidad/enmascaramiento):En la
Aplicación [12]. La capa de percepción actúa como una interfaz con infraestructura de IoT, un adversario malicioso puede intentar hacerse pasar
el mundo físico y consta de actuadores y sensores. Esta capa por otro usuario/dispositivo. Este ataque se puede usar para capturar/
transfiere los datos sin procesar a la capa de red. La capa de red modificar la información confidencial de/en los dispositivos, así como para
procesa y enruta los datos a través de la infraestructura de red. El enviar instrucciones maliciosas a los actuadores.
procesamiento posterior de los datos ocurre en la capa de Amenaza 4 (ataque MiTM):En un ataque MiTM, un adversario intercepta
middleware. Esta capa ayuda a realizar acciones precodificadas por la comunicación entre las dos partes. La infraestructura IoT también es
aplicaciones de terceros que se ejecutan en la capa de aplicación. vulnerable a este tipo de ataque. Un adversario o un dispositivo IoT
La capa de aplicación proporciona la interfaz para que terceros malintencionado puede cambiar las memorias caché ARP del usuario/
desarrollen y ejecuten sus aplicaciones para el almacenamiento y dispositivo IoT de las dos partes que se comunican para iniciar un
procesamiento posterior de los datos del dispositivo. ataque MiTM en la infraestructura IoT.
diario de cosas
TABLA I: Taxonomía de amenazas según la arquitectura IoT
Capas Componentes Tareas amenazas

Tercero
Máquina
Solicitud Aplicaciones,
Aprendiendo, (f) Malware/secuencias de comandos
Capa sitios web,
diagramas de flujo, etc entre sitios
Consolas, etc
(g) Cuestiones de privacidad de datos
Procesando
software intermedio Tercero (h) Desbordamiento del búfer
y
Capa Aplicaciones
preprocesamiento
nodos, Gestión
Red
y
Capa
puertas de enlace, (a) suplantación de identidad y
Firmware enrutamiento enmascarado,

Sensores Identificar, (b) Inyección de malware.
Percepción
y Monitor, (c) DDoS,
Capa
Actuadores Adquisición, etc (d) MiTM, (e) Repetición
tercero SDN IOTSSEGURIDAD SSERVICIO AARQUITECTURA las políticas de seguridad residen y se evalúan. En esta arquitectura,
Utilizamos redes definidas por software (SDN) para desarrollar nuestra existen dos tipos de políticas de seguridad, i) Políticas de
arquitectura de seguridad para la infraestructura de red de IoT. A esto aprovisionamiento de dispositivos (que se utilizan durante el
lo llamamos SDN IoT Security (SIS) Service Architecture. Primero aprovisionamiento de un dispositivo IoT) y ii) Política de seguridad del
describimos el fundamento detrás de la elección de SDN como la servicio de red (que garantiza que solo los dispositivos IoT autorizados
tecnología subyacente para proteger la infraestructura de red de IoT. utilicen los servicios de red legítimos). ). Los dispositivos IoT pueden ser
Luego describimos la arquitectura SIS para la red IoT. de dos tipos: actuadores y sensores, que se consideran dispositivos
finales. Los dispositivos IoT utilizan nodos IoT para conectarse a la
infraestructura de red. En algunos casos, los nodos de IoT se conectan
A. ¿Por qué SDN para la seguridad de IoT?
a las puertas de enlace de IoT a través de redes cableadas o
Las características de la tecnología SDN que la convierten en una inalámbricas. El controlador SDN mantiene las puertas de enlace de IoT
plataforma adecuada para asegurar la infraestructura de IoT son las y su comportamiento de comunicación. Las puertas de enlace/nodos de
siguientes: Separación del plano de control del plano de datos:Esto es IoT, en la mayoría de los casos, admiten el protocolo OpenFlow. En esta
útil para diseñar nuestra arquitectura de seguridad basada en políticas arquitectura, consideramos y nos enfocamos solo en los conmutadores
en el controlador SDN en el plano de control y hacer cumplir las OpenFlow como puertas de enlace de IoT.
políticas de seguridad en los conmutadores de red y dispositivos IoT en Los dispositivos IoT son heterogéneos y pueden utilizar diferentes protocolos de
el plano de datos. El controlador SDN se comunica con los red y mecanismos de autenticación, y pueden tener diferentes plataformas de
conmutadores en el plano de datos mediante interfaces y protocolos operación y aplicación. Además, puede haber una gran cantidad de dispositivos
abiertos y estandarizados (OpenFlow), lo cual es útil para asegurar las IoT. Por lo tanto, se necesita una solución escalable que reconozca las capacidades
comunicaciones entre la autoridad de decisión de políticas en el individuales de los dispositivos IoT conectados. En nuestra arquitectura de
controlador y los mecanismos de cumplimiento en los dispositivos y seguridad, hemos creado un mecanismo de aprovisionamiento de dispositivos
conmutadores de IoT. para cada dispositivo/grupo de IoT utilizando un enfoque basado en políticas.
Vista de dominio de red:El Controlador SDN tiene visibilidad sobre todo Cada política de aprovisionamiento de dispositivos consta de reglas que
el dominio de la red bajo su jurisdicción. Esto puede ser utilizado por involucran varios parámetros y capacidades del dispositivo, como atributos e
nuestra arquitectura para lograr una gestión segura de dispositivos y identificadores del fabricante, protocolos y mecanismos utilizados por el
flujos de IoT en la infraestructura de red. El Controlador mantiene una dispositivo, así como otras características. Esta funcionalidad de
base de datos de información topológica que registra información aprovisionamiento de dispositivos está integrada con la aplicación central del
sobre todos los dispositivos de reenvío conectados al Controlador. Esto controlador, lo que le permite aprovisionar de forma segura los dispositivos IoT en
será útil en la especificación de políticas de seguridad basadas en rutas tiempo de ejecución.
en nuestra arquitectura.
La arquitectura de seguridad utiliza dos aplicaciones seguras para
Aplicaciones de SDN en dirección norte:La SDN proporciona una API flexible
aprovisionar, controlar y administrar los dispositivos IoT dentro de la
hacia el norte que nos permite desarrollar aplicaciones seguras o usar
red SDN. Estas aplicaciones dentro del SDN Controller. El primero es el
aplicaciones de terceros para monitorear y controlar de manera segura el
Aplicación de seguridad basada en políticas (PbSA), y el segundo se
comportamiento de los dispositivos IoT y los nodos de red en el dominio de
llamaAplicaciones de seguridad de IoT (ISA). ES UNtiene tres sub-
la red SDN. Nuestra arquitectura de seguridad tiene una aplicación segura
módulos, a saberAprovisionador de dispositivos IoT, Autoridad de
que se ejecuta sobre el controlador (desarrollada con su API de dirección
autenticación de IoTyAutoridad de autorización de IoT. Antes de
norte) que brinda servicios de seguridad en la infraestructura de IoT.
describir en detalle las funciones de cada una de estas aplicaciones y
módulos, primero brindamos una descripción general de alto nivel de
las interacciones de seguridad involucradas con los dispositivos IoT en
B. Arquitectura SIS para infraestructura de red IoT la infraestructura de red.
Nuestra arquitectura de seguridad basada en SDN propuesta utiliza políticas El funcionamiento de nuestra arquitectura de seguridad consta de dos fases. En la
para aprovisionar, controlar y administrar dispositivos, servicios y entidades primera fase, se autenticará y aprovisionará un dispositivo IoT. A medida que el
de red de IoT (conmutadores, nodos y puertas de enlace). La figura 1 dispositivo IoT se inicia y envía una solicitud de conectividad al dispositivo
muestra la arquitectura de servicio SDN IoT Security (SIS) propuesta. El OpenFlow (puerta de enlace) más cercano, las puertas de enlace IoT reenvían la
corazón de la arquitectura SIS es el SDN Controller, donde información del dispositivo IoT mediantepaquete enmes-
diario de cosas
Servicio de seguridad SDN IoT (SIS)
Evaluación
Ejecutor Repositorios Autoridad de autenticación de IoT
Motor
Autorización de IoT Dispositivo IoT
Administrador de políticas Autoridad Proveedor
PbSA Aplicación de seguridad IoT
Interfaz en dirección norte
Módulos y aplicaciones principales de SDN
Interfaz SouthBound (dispositivos de reenvío)
SW1 SW2 SW3 SW4

Interruptores OpenFlow
GWI GWII
Usuario A Usuario D.
Puertas de enlace IoT
NI NII NI NII Usuario B Usuario C Usuario E Usuario F
Nodos IoT
Sensores/Actuadores
* Puerta de enlace GW-IoT
* Nodo N‐IoT
* PbSA: aplicación de seguridad basada en políticas
Fig. 1: Arquitectura de seguridad Ctura para la infraestructura de red IoT

mensajes al controlador SDN. Este paquete contiene información Aplicación de seguridad (PbSA) para asegurar la infraestructura de IoT
específicos del dispositivo, como el tipo, ID, nombre, tipos de tura utilizando SDN. ComoPbSAestá diseñado para ser modular, el
certificados admitidos, etc. El dispositivo IoT Pr Visualización de los componentes del servicio de PbSAse puede implementar en un solo host
verifica la información recibida del dispositivo contra las políticas de o se puede distribuir en múltiples hosts. Aquí proporcionamos una
aprovisionamiento. UsaAutoridad de autenticación de IoTpara autenticar el descripción detallada de los diferentes módulos dePbSA. PbSA consta
dispositivo. En nuestra implementación actual, este servicio ha pre- de cuatro módulos principales, a saber: a) Política
políticas de aprovisionamiento de dispositivos configuradas basadas en Administrador, b) Motor de evaluación, c) Repositorios y d) Ejecutor de
el uso del protocolo de autenticación basado en criptografía de curva políticas.
elíptica (ECC) y sus parámetros asociados. La finalización exitosa de • Administrador de políticas:Este es el componente central de la arquitectura de
este proceso de autenticación de IoT hará que la red seguridad, ya que gestiona todas las operaciones, como los extractos.
dominio y servicios visibles para dispositivos IoT autenticados. Atributos de flujo de dispositivos IoT, actualiza el Repositorio de
En la segunda fase, PbSA verifica la solicitud de servicio de ci
topologías e indica a Policy Enforcer quemi hacer cumplir la política
red de los dispositivos IoT autenticados contra el sp decificar mi s en las puertas
yo bajo de enlace OpenF oT. También se comunica con
políticas de seguridad. PbSA tiene políticas detalladas que controlan el elES UNaplicación para la transferencia de token OAuth después de
comportamiento de los dispositivos IoT; por ejemplo, un usuario “A” verificar la solicitud de servicio de red de los dispositivos IoT.
accediendo a través de OpenFlow Switch 3 (SW3) puede leer datos del • Motor de evaluación:El e motor evalor
es estos rvicio
Sensor 2 conectado a través dePuerta de enlace I (SW1 solicitud contra las políticas relevantes almacenadas en la Política
& Nodo NII). Describimos las políticas de seguridad y su implementación en Repositorio.
detalle en la Sección III-C. Si la solicitud de servicio es permisible de acuerdo • Repositorios:Nuestra arquitectura tiene dos repositorios: a)
con las políticas de seguridad especificadas en el PbSA, entonces nuestra Repositorio de topología yb) Repositorio de políticas. El
arquitectura de seguridad usa el protocolo OAuth repositorio de topología contiene la topología de red de IoT de-
para proporcionar un token al dispositivo IoT. El dispositivo IoT usa vicios y hosts/usuarios finales. El controlador SDN tiene su propio
este token para futuras comunicaciones en la red. Este proceso es repositorio de topología de dispositivos. Estamos utilizando el mismo
realizado conjuntamente porPbSAy elAutoridad de autorización de repositorio de topología para este propósito. El repositorio de políticas
IoT. contiene las expresiones de políticas (PE) asociadas con los diversos
dispositivos IoT y los atributos de flujo asociados. Los atributos en los PE
también incluyen parámetros de seguridad, como etiquetas de seguridad
C. Aplicación de seguridad basada en políticas asociadas con OpenFlow IoT Gateways.
• Ejecutor de políticas:Policy Enforcer obtiene la
Nuestra infraestructura de red IoT consta de conmutadores OpenFlow/
información requerida de OpenFlow IoT Gateways y
puertas de enlace IoT y hosts finales (sensores/accionadores IoT). Hemos
aplica las reglas de flujo obtenidas del Policy Manager.
utilizado un solo controlador SDN para administrar la infraestructura de la
red IoT. Los dispositivos de red (dispositivos OpenFlow) reenvían los Especificaciones de la política de seguridad
paquetes generados por los dispositivos/usuarios de IoT, que luego están Las especificaciones de la política de seguridad se expresan como
sujetos a las políticas especificadas en el SDN Controller para la Expresiones de política (PE), que especifican si los paquetes y flujos de
transferencia en la red. La figura 1 muestra la política basada los dispositivos IoT y los hosts finales siguen una ruta particular o
diario de cosas
caminos en la red, y las condiciones bajo las cuales los Un dispositivo IoT consta de dos tipos de componentes, sensores y
paquetes y flujos siguen estos caminos. La sintaxis de la actuadores. Cada sensor/actuador tiene asociado un nombre, un
especificación PE utiliza una versión mejorada de RFC1102 [14]. identificador y un tipo. También puede haber otros atributos asociados
Son detallados y especifican una gama de políticas que utilizan con un dispositivo. El fabricante del dispositivo puede especificar
varios atributos de dispositivos y flujos de IoT; por ejemplo, información como los atributos de calidad asociados con los sensores y
estos atributos incluyen diferentes tipos de dispositivos, los actuadores. Por ejemplo, un pulsioxímetro inteligente puede tener
atributos de origen y destino, atributos y restricciones de flujo, parámetros como precisión y sensibilidad. Desde la perspectiva de la
servicios solicitados, servicios de seguridad y etiquetas de seguridad, puede haber certificados asociados con un dispositivo del
seguridad. Se han especificado los siguientes atributos: fabricante, que serán útiles para la atestación del dispositivo durante el
(a) Atributos de flujo: Identificador de Flujo, Tipo de Paquetes de Flujo, tiempo de arranque.
Perfil de Seguridad que indica el conjunto de servicios de seguridad Cada dispositivo tiene un sistema operativo o firmware que controla
que se van a asociar con los paquetes en el Flujo; sus funciones. Un dispositivo estará sujeto a condiciones externas y
(b) Atributos del dispositivo: Identificadores específicos de eventos internos de IoT. Por ejemplo, un evento externo podría ser un sensor/
actuador; solicitud para leer datos de su sensor o para realizar una acción por parte del
(c) Cambiar atributos: Identificador del conmutador y etiquetas de actuador. Los eventos internos están relacionados con el funcionamiento de su
seguridad asociadas con el conmutador (así como OpenFlow IoT sistema operativo. Por ejemplo, un controlador de E/S que maneja la operación de
Gateways); entrada y salida de un dispositivo Raspberry Pi que utiliza el sistema operativo
(d) Atributos del anfitrión:Identificadores asociados con el host, como Raspbian.
ID de host de origen/destino; Como parte de su funcionamiento, un dispositivo puede comunicarse
(e) Restricciones de flujo y dominio:Restricciones como Restricciones de con redes como Internet y con otros dispositivos. Por lo tanto, puede
flujo (FlowCons) y Restricciones de dominio (DomCons) asociadas con haber software/servicios dedicados para establecer y mantener dichos
flujos de un dispositivo específico; por ejemplo, una restricción puede enlaces de comunicación. Nos referiremos a estos como adaptadores
especificar el flujo de un tipo específico de sensor, solo debe pasar por de dispositivos.
un conjunto de interruptores que pueden proporcionar un ancho de Finalmente, un usuario o aplicación puede invocar y controlar las
banda garantizado. Desde el punto de vista de la seguridad, una operaciones del sensor y actuador de un dispositivo. La Figura 3 presenta
restricción podría ser que un flujo solo deba pasar por conmutadores una representación esquemática de dicha ontología de un dispositivo. En
OpenFlow que tengan una etiqueta de seguridad particular. nuestra arquitectura, cada dispositivo IoT tiene una identificación única y se
f) Servicios:Los servicios a los que se aplica el PE (por ejemplo, acceso de conecta a las puertas de enlace IoT mediante redes inalámbricas. Las
almacenamiento FTP); puertas de enlace de IoT son básicamente conmutadores OpenFlow/puntos
(g) Validez temporal:El período de vigencia del PE; y de acceso (OF-AP) que admiten el protocolo OpenFlow. Como se mencionó
anteriormente, nuestro protocolo de seguridad tiene dos fases, a saber, la
h) Ruta:Indica una secuencia específica de conmutadores que se fase de autenticación seguida de la fase de autorización. Ahora,
permiten o deben atravesar flujos particulares de dispositivos/usuarios consideremos estas fases con más detalle.
de IoT específicos.
Los PE admiten comodines para los atributos, lo que permite que el Fase 1 - Aprovisionamiento y autenticación:
lenguaje especifique políticas para un grupo de IoT/servicios. Los dispositivos IoT se aprovisionan y autentican en la primera fase del
protocolo de seguridad. El aprovisionamiento de dispositivos forma parte de
Una plantilla de expresión de política simplificada es la siguiente: la aplicación ISA en la arquitectura SIS. Hemos adoptado un enfoque basado
en políticas para aprovisionar un dispositivo de forma segura. Nos referimos
EDUCACIÓN FÍSICAI= < FlowID, IoTDeviceID, SourceAS, a estas políticas como políticas de aprovisionamiento de dispositivos (DPP) y
DestAS, SourceHostIP, DestHostIP, SourceMAC, DestMAC, un dispositivo debe satisfacerlas antes de conectarse a las redes. Estas
Usuario, FlowCons, DomCons, Servicios, Sec Profile, Seq − − políticas especifican qué atributos y capacidades requiere un dispositivo
Path >:< Acciones > donde I es el número de expresión de
para que se aprovisione. También especifica los atributos de los usuarios
política.
que pueden aprovisionar el dispositivo. En la (Figura 4) se muestra una
representación esquemática de DPP.
• Atributos de usuario:DPP puede especificar las condiciones de los usuarios
D. Aplicación de seguridad de IoT (ISA)
que pueden aprovisionar un dispositivo. Un dispositivo solo puede ser
En esta sección, explicamos brevemente los protocolos de seguridad aprovisionado por usuarios que cumplan con estas condiciones. Esto se
utilizados en nuestra arquitectura de seguridad. Estos son implementados puede especificar explícitamente nombrando a los usuarios o en forma de
por el Aplicación de seguridad IoT (ISA). La aplicación ISA utiliza políticas de grupos o roles asociados con un usuario o, más generalmente, en forma de
aprovisionamiento de dispositivos para incorporar los dispositivos IoT. Los conjunto de atributos que los usuarios deben tener. Desde el punto de vista
servicios de aprovisionamiento de dispositivos utilizan la siguiente ontología de la seguridad, es necesario confiar en estos atributos, como el certificado
de dispositivos, que constituye la base de las políticas de aprovisionamiento de usuario (por ejemplo, el certificado X.509) y las credenciales seguras.
de dispositivos y la aplicación ISA. Esto se puede especificar mediante políticas basadas en funciones y
Ontología del dispositivo: basadas en atributos.
Una ontología de dispositivo describe los atributos, las propiedades y la • Atributos del dispositivo:DPP puede especificar condiciones sobre los
información vinculante asociada con un dispositivo IoT. Usaremos esta atributos que debe tener un dispositivo antes de que pueda ser
ontología en nuestra arquitectura de servicios SIS para el aprovisionamiento aprovisionado. Los atributos del dispositivo incluyen el tipo de dispositivo,
seguro de dispositivos IoT. el certificado del dispositivo y el certificado del fabricante del dispositivo.
diario de cosas
Autorización de IoT Autenticación IoT

Dispositivo
Puertas de enlace/DE AP APbSA
Autoridad Autoridad
S0: X= ID+Hola+NS
S1: Paquete_IN(X)
Genera un Є Zq*, S2: Iniciar el procedimiento de autenticación del dispositivo ECC

Td= aP
S3: Enviar (IDd, Td, Rd)
Kgt‐>gt=(Sargento+a)Tgt;
S4: Enviar (Tgt, M1)
M'=H1(0,kd‐>gt);
Comprobar M'==M1;
Si es un conjunto válido
K=H1(IDd||IDgt, kd‐>gt);
M2=H1(1, kd‐>gt) M''=H1(1, Kgt‐>d);
S5: Enviar (M2)
Comprueba M2==M'';
Si es válido, establezca
Política de cheques
K=H1(IDd||IDgt,kgt‐>d)
expresión para
S6: Solicitud de acceder a la red
Servicio de red (NS) Servicios (NS)
Autorización (K) Si está bien, entonces proporciona
Genera OAuth S7: Autorización Autorización

Ficha (Ko) Permiso (Kp) Permiso
S8: Autorización de envío

Ficha (Ko)
OF-AP almacena en caché el token en

Procedimiento ECC
regla de flujo para más
Procedimiento OAuth
comunicación
Fig. 2: Dia del proceso del protocolo de seguridad gramo
Ssimilar al sensor pertenece a un grupo válido (Grupo) y fabricado por un

es decir, dispositivoX se puede proporcionar por usuariotu,
fabricante válido.
Actuar. Atributos
Solenoide
si tues un usuario validoy, el dispositivo es de un válido
escribe(X) yfabricante(X)es válido. Fo
r instancia,tu puede ser valido,
si certificado(tu)es válido y/otu∈Grupoes válido. Similar,
Comunicación
Políticas MUD
Estado t fabricante(X)es válidosi ce rt(fabrica Turer(X))es

Enlace
Adaptar ejem Dispositivo

tu
atributos válido.
Ext.
renal mi ejemplo 2 - Devic e Estado Propiedades:Por ejemplo, un dispositivo si es
Eneterno
t Cy ser aprovisionado un dispositivo nuevo. Esto se puede verificar en el
Guiones
Sensor By examinando el registro del dispositivo. Si el dispositivo nunca ha tenido
Ubicación
Atributos de sensores tused (por ejemplo, hay un registro de dispositivo, entonces puede ser
IDENTIFICACIÓN enFerró el dispositivo es nuevo (de la variable de estadonuevode El
dvmihielo). Usando esta propiedad rty, la condición se puede expresar
Información de usuario
Nombre
Escribe
as sigue:Si(estado.nuevo ( X)es válido)el norteel dispositivo puede ser
Ubicación
r visionado
correos
La mayor preocupación de la aprovisionamiento s servicio, es cómo

Canal
a tu
continuación, identifique el dispositivo IoT legítimo. Para resolver esto, hemos
Calidad
a
utilizado un peso ligero mi
Curva Líptica C basado en criptografía
Más...
mecanismo [15] a auténtico ica los dispositivos IoT. Un dispositivo IoT
Fig. 3: Ontología de dispositivos para la arquitectura de servicios SIS stermina en “H mensaje de ello” wcon su edad X en la Figura 2) identificación (desorden
SI
solicitando poruna red Servicio (NS). Los OF-AP envían
Atributos
<Condición de aprovisionamiento>
Certificados
{¿Quién puede aprovisionar el
la identificación y ne Ser de trabajo solicitud de vicio (NS) a través depaquete en
mensajes ah t pags Provisión ning
Fichas de grupo y rol
licación El d
Usuario Cartas credenciales
Dispositivo}
miES UNap dispositivo
El servicio comprobará th miDRepositorio PP con t él attri butes

Atributos
previsto por el e IoT dev ICe. Al mismo
Dispositivo Nombre, DNI, Tipo, etc.
Rojo:Condición;
Verde:Entidad; tiempo, el dispositivo
Provisioni ng s mi
uso del servicio s elAutenticación de IoT Autoridad de notificación
Azul:Atributos Propiedades de estado
Fig. 4: Esquema de política de aprovisionamiento de dispositivos para realizar la autenticación basada en ECC del dispositivo IoT.
al final d de la fase de autenticación, el dispositivo IoT es
• Propiedades del estado del dispositivo:DPP también puede especificar aprovisionado un secreto k ey que el dispositivo IoT puede usar para s ecure
condiciones que el estado de un dispositivo debe satisfacer. También se establecen comunicaciones posteriores con el
Expresaremos esto en forma de propiedades de estado. Servicio de Red NS.
Profundizaremos en estas propiedades en la siguiente sección.
Fase 2 - Autorización: En la fase de autorización, el PbSAverifica
Aquí damos dos ejemplos de DPP utilizados en nuestra arquitectura la solicitud de Servicio de Red (NS) del dispositivo IoT utilizando
SIS. las especificaciones de política de seguridad descritas en la
Ejemplo 1 - Atributos de seguridad: El dispositivo X sólo podemos sección III-C. ElAutoridad de autenticación de IoTutiliza la clave
ser aprovisionado si y solo si el Usuario es un usuario válido (tuX I ), establecida por el protocolo ECC en la autorización
diario de cosas
solicitud dePbSA. Si los atributos de dispositivo y flujo para el Dispositivo

∗;
internet de las cosasAautenticarAutoridad de iones
Calcula:
∗;
servicio de red (NS) satisfacen las Expresiones de política, entonces ,, → Calcula:
;
el PbSA solicita elAutoridad de autorización de IoTpara generar el ;
token OAuth para el dispositivo IoT particular para los servicios de ⇒ ; ← , ⇒ , ;
, ; , ;
red específicos solicitados. El token también puede contener una cheques
⇒
;
⟹
clave secreta que el dispositivo IoT puede usar para proteger las Si es un conjunto válido,
∥ , ⇒ ;
comunicaciones posteriores con el servicio de red NS. El token , ⇒ → , ⇒ ;
puede ser almacenado en caché por el OF-AP modificado del cheques ;
Si es válido, establezca
dispositivo IoT. El dispositivo IoT autenticado y aprovisionado ∥, ⇒
utiliza el token para acceder a los servicios de red requeridos. Este

Fig. 5: Acuerdos clave entre Dispositivos yAutoridad de
proceso se ilustra en la Figura 2.
autenticación de IoT
Autenticación ligera basada en ECC para dispositivos IoT El sistema En [15], se proporciona un análisis de la seguridad del
de clave pública basado en criptografía de curva elíptica (ECC) esquema de autenticación ECC que demuestra que es seguro
utiliza la estructura algebraica de curvas elípticas como sus puntos contra atacantes activos que son capaces de espiar, modificar e
finitos. Es computacionalmente más rápido que otros inyectar mensajes en el protocolo. Los costos computacionales
criptosistemas de clave pública como RSA. Por lo tanto, es más y de comunicación asociados con el esquema propuesto se dan
adecuado para dispositivos IoT computacionalmente limitados. Se en el Apéndice A.
puede utilizar para lograr un acuerdo clave, así como el cifrado y la
Autorización para servicios de red mediante el protocolo OAuth
firma digital. En nuestra arquitectura de seguridad, los dispositivos
El servicio de autorización que utiliza el protocolo OAuth [11, 16]
IoT se autentican mediante un protocolo de autenticación ligero
funciona de la siguiente manera: Consta de cuatro actores: i)
basado en ECC propuesto en [15]. Luego usamos la clave
Cliente, ii) Propietario del recurso, iii) Servidor de recursos y iv)
establecida usando este protocolo para cifrar los datos de los
Servidor de autorización. El cliente se pone en contacto con el
dispositivos IoT autenticados. Este protocolo de seguridad ligero
Propietario del recurso. El propietario del recurso otorga acceso al
funciona junto con el protocolo OAuth.
cliente mediante el envío de un código de autorización. El cliente
El protocolo de autenticación basado en ECC utilizado en nuestra
entrega el código de autorización recibido al Servidor de
arquitectura tiene 3 etapas: configuración, instalación y acuerdo de
Autorización. El servidor de autorización verifica el código de
claves. El algoritmo 1 a continuación da un esquema de las 3 etapas. El
autorización y libera un token que contiene los detalles del
acuerdo clave (etapa 3) se ilustra en la figura 5. El rendimiento del
consentimiento proporcionado al cliente (límite de tiempo, alcance,
protocolo propuesto (en términos de costos de cómputo y
etc.). El cliente reenvía el token al servidor de recursos. El servidor
comunicación) es más alto que los protocolos propuestos
de recursos comprueba la validez del token recibido y, en caso
anteriormente. Por lo tanto, es particularmente adecuado para el IoT
afirmativo, proporciona acceso al recurso protegido.
entorno a medida que cambia la carga de procesamiento de los recursos
limitados dispositivos a los servidores más potentes del controlador. En nuestra arquitectura SDN-IoT, los servicios de red son los recursos.
La figura 2 muestra el proceso de entrega del token de OAuth
(marcado con una línea verde continua). Primero elAutoridad de
Algor ithm 1: Protocolo ECC
autenticación de IoTautentica los dispositivos IoT utilizando el
1 Paso 1 (Configuración): a) El Autoridad de autenticación de protocolo ECC mencionado anteriormente. Después de la fase de
ChoIoT oses un número primo q, calcula autenticación, solicita acceso a los servicios de red en nombre de los
Fq , E/Fq, gq, PAGS ; dispositivos IoT autenticados. El PbSA verifica el depósito de políticas y,
b) T él Autoridad de autenticación de IoTelige un maestro si la solicitud de servicio de red es válida, emite unPermiso de
llave X y calcula la clave pública PAGSpub = xP ∈E/Fq; Autorización (Kp), que se remite a la Autoridad de autorización de IoT.
c) es luego calcula dos hashesH1 yH2; ElAutoridad de autorización de IoT genera elToken OAuth (Ko). Hemos
D) Fq, E/Fq, gq, pag, pagpub, h1, h2 se hacen públicos.; 2 utilizado JSON Web Token (JWT) para este propósito. ElAutoridad de
2 Paso (Instalación): Autoridad de autenticación de IoTy los hielos
autorización de IoT reenvía el token OAuth a los dispositivos IoT. El
generan y validan por separado sus datos privados.
desarrollador
Token OAuth (Ko)contiene la identificación de usuario, la identificación
y claves públicas.; del dispositivo IoT, el tipo de dispositivo
Rgt = rgtPAGS ,donde rgt es un numero aleatorio rgt ∈Z∗ q. (por ejemplo, sensor o actuador) y tiempo de caducidad (tiempo de acceso al
ygt = H (IDENTIFICACIÓNgt, Rgt).X
1
servicio de red), así como una clave secreta. El OF-AP integra este token con
RD = rDPAGS ,donde r es un numero aleatorio rI ∈Z∗ q . la regla de flujo específica del dispositivo. Hemos modificado el OF-
yD = H (IDENTIFICACIÓN , y ).X
2 D gt
AP para almacenar en caché el token de OAuth. Para futuras comunicaciones, el
SD = rD + yD dispositivo IoT utiliza este token para acceder a la infraestructura de la red.
SD yRD son los valores privados y públicos de D. Al final
En nuestra implementación actual, hemos firmado el token OAuth
de esta etapa cada dispositivo tiene su propio
usando la clave privada de Autoridad de autenticación de IoT Sgramot,
SD, RD, yDrD yAutoridad de autenticación de IoTposee
que se utilizó en la fase de autenticación ECC. La firma es verificada por
(ygtrgt);
el servicio de red utilizando la clave pública deAutoridad de
3 Paso 3 (Acuerdo clave): Entre Autenticación IoT
autenticación de IoTRgramot antes de la prestación del servicio. (En una
Autoridad y Dispositivos IoT;
arquitectura distribuida más general dondeAutoridad de autorización
de IoTyAutoridad de autenticación de IoTson
diario de cosas
Repositorios
Administrador
Máquina virtual Raspbian Dispositivo IoT
APORTE
192.168.56.114 Proveedor
DPP
C
EDUCACIÓN FÍSICA
Administrador de políticas
Configuración
Máquina virtual Raspbian

Centro de datos
192.168.56.116
X
192.168.56.110 Motor de evaluación Autoridad de autenticación de IoT
IntentService
D
A R IoT deshonesto
Servicios principales de ONOS
Ejecutor Autoridad de autorización de IoT
B
Máquina virtual Raspbian
Dispositivo
192.168.56.101 PbSA Aplicación de seguridad IoT
192.168.56.104
Máquina virtual Kali Linux Fig. 7: Interacción del módulo de software con los servicios principales de ONOS
192.168.56.102
Amenazas 1 y 2:
Fig. 6: Configuración de red
Usaremos Mirai como un ejemplo de Amenazas 1 y 2. En Mirai, un
no coubicado, el protocolo de autenticación ECC se utilizará para atacante primero inyecta el malware en los dispositivos IoT y luego
generar valores públicos y privados paraAutoridad de autorización lanza un ataque DDoS coordinado utilizando estos dispositivos
de IoTutilizando un proceso similar al de un dispositivo IoT y esta infectados. En esta sección, primero, describimos un ataque DDoS
clave privada se utilizará para firmar el token OAuth). basado en Mirai específico para el entorno de IoT y luego mostramos
cómo nuestra arquitectura de seguridad ayuda a prevenir este ataque.
IV. IIMPLEMENTACIÓN Mirai:
Hemos desarrollado una prueba de concepto para la arquitectura de Cada bot infectado con Mirai ejecuta dos procesos paralelos. Uno es un
seguridad propuesta. La implementación de la prueba de concepto centro de Comando y Control (CnC) y el otro es un servidor
tiene módulos de red y software. Nuestra configuración de ScanListener como se muestra en la Figura 8a.
implementación utiliza Oracle VM Box, mininet-wifi [17] y ONOS (SDN Una vez que un dispositivo se ve comprometido por el código Mirai, comienza a
Controller). Estamos usando una estación de trabajo con Core i7 - escanear otros hosts vulnerables en la red. Escanea en busca de lo abierto telnet
7700K @ 4.20 GHz CPU; 64 GB de RAM en esta configuración. puertos con un activotelnetservidor. Esta fase es la fase de exploración. Una vez
Configuración de la red: La configuración de red de prueba de que encuentra un host, lleva a cabo un ataque de fuerza bruta contra eltelnet
concepto se muestra en la Figura 7. Aquí, ONOS se usa como el servidor para encontrar contraseñas y nombres de usuario correspondientes. El
controlador SDN, que se ejecuta dentro de una máquina virtual de código Mirai tiene 62 combinaciones predeterminadas de nombre de usuario y
Ubuntu Server. Para crear el tejido de conmutación inalámbrico, contraseña (que se muestran con una línea verde continua en la Figura 8a). El
hemos utilizado Mininet-WiFi. Para simular los dispositivos IoT, bot utiliza estos pares de nombres de usuario y contraseñas para iniciar
hemos utilizado Raspbian VM, que se asignan a los hosts finales en sesión en eltelnetservidor. Después de un inicio de sesión exitoso,
la red WiFi simulada. Módulos de software: Como se mencionó en bloquea los puertos 22, 23 y 80. Por lo tanto, los usuarios de este
la arquitectura de seguridad, hemos desarrollado dos aplicaciones dispositivo no podrán acceder a él. Luego, la carga útil maliciosa se
ONOS, a saber Aplicación de seguridad basada en políticas (PbSA) y carga en el dispositivo capturado para convertirlo en un bot. Si el
Aplicación de seguridad IoT (ISA). Ambos se ejecutan en la interfaz dispositivo vulnerable se convierte con éxito en un bot, se conecta al
NorthBound del controlador ONOS y están ubicados en la VM del centro CnC del bot. Entonces puede generar diferentes tipos.
servidor Ubuntu. Cada aplicación se divide en diferentes módulos de ataques DDoS. Los ataques DDoS que puede generar Mirai
de software y también existen comunicaciones entre algunos de incluye UDP, SYN, ACK, TCP Stomp, DNS, HTTP, GRE IP y
estos módulos. GRE Ethernet Flood.
Los administradores de red utilizan la Consola administrativa para Mitigación:
actualizar los repositorios de políticas (PE y DPP). Hemos utilizado la Hemos experimentado con todos los ataques de inundación anteriores y
base de datos JSON para crear estos repositorios. Los módulos de descubrió que nuestra arquitectura de seguridad es capaz de
software se crean utilizando Java. IoT Device Provisioner utiliza un contrarrestarlos con éxito. En este documento, debido a restricciones de
analizador JSON y un repositorio JSON para aprovisionar y autenticar espacio, hemos optado por incluir solo un ataque de inundación con Mirai, a
los dispositivos. Luego, el administrador de políticas verifica si los saber, el ataque de inundación SYN.
servicios de red solicitados por el dispositivo coinciden con las políticas
Considere una red simple que se muestra en la Figura 7, donde
especificadas en el repositorio de PE mediante el motor de evaluación.
192.168.56.101es una máquina virtual Raspbian y192.168.56.102es un
Luego, Policy Manager usa Policy Enforcer para enviar una solicitud de
Máquina virtual Kali Linux 2.0, y192.168.56.104es un dispositivo IoT no
intención a los módulos centrales de ONOS, que implementan las
autorizado con Raspbian VM. También tenemos otras dos máquinas
reglas de flujo en consecuencia. El Policy Manager luego lleva a cabo
virtuales Raspbian con IP192.168.56.114y192.168.56.116que se utilizan en
las actualizaciones correspondientes a los servicios de configuración
otros escenarios de ataque.
del núcleo de ONOS.
Para infectar el medio ambiente, hemos deshabilitado nuestra seguridad
aplicaciones que se ejecutan en el controlador SDN y compiló el código
A. Mitigación de amenazas fuente de Mirai en Kali Linux VM. Todas las máquinas virtuales Raspbian
En esta sección abordaremos los ataques mencionados en la sección II están configuradas con un nombre de usuario/contraseña predeterminado
y su mitigación utilizando nuestra arquitectura de seguridad. como "admin/admin". Cuando el código Mirai se ejecuta en uno de
diario de cosas
para defender los dispositivos IoT.

Carga útil
(SvC) Amenazas 3 y 4:Las amenazas 3 y 4 están interrelacionadas entre sí. Aquí, para
lanzar un ataque MiTM (Amenaza 4), hemos utilizado el envenenamiento de caché
ScanListener C CnC
ARP de usuarios/dispositivos host. El envenenamiento de caché de ARP utiliza la
A suplantación de identidad de ARP (amenaza 3).
Víctima
Dispositivo 1
B Bot R: El puerto abierto de Telnet responde de
nuevo al agente de escucha;
B: infectar el dispositivo vulnerable;

C: Conectar conCNC
Víctima
Víctima
Dispositivo 3
Dispositivo 2 Nuevo escaneo de puerto Telnet
(a)
(a)
(B)
Fig. 8: a) Diagrama de funcionamiento de Mirai Bot, b) Ataque SYN

Flood exitoso de Mirai.
la VM, el malware se inyecta en la red y se infectan. La (B)

Figura 8b muestra el tráfico SYN Flood a la máquina
virtual IoT con IP192.168.56.101 (procedente de 192.168.
56.102). (C)
Luego activamos nuestras aplicaciones de seguridad (PbSAy ES UN),
Fig. 9: (a) Ataque MITM exitoso, (b) Captura de administrador/-
tenemos políticas específicas parahttpServicio (EDUCACIÓN FÍSICA18) y telnet
Contraseña (c) Ataque detectado
acceso (EDUCACIÓN FÍSICAdieciséis).EDUCACIÓN FÍSICA18Establece quehttp Estos dos ataques son típicos de un ataque interno en cualquier IoT
comunicación de fuentes IoTAyBal centro de datos de destino se permitirá. infraestructura, donde un empleado recopila datos de sensores con
EDUCACIÓN FÍSICAdieciséisafirma que cualquiertelnetse eliminará la solicitud fines maliciosos [18]. Primero, presentaremos cómo funcionan los
a los dispositivos IoT desde cualquier host de origen. Por lo que la PbSA ataques y luego mostraremos cómo nuestra arquitectura de seguridad
niegatelnetacceso al atacante y previene la infección de los dispositivos IoT. ayuda a proteger la red.
Para que no puedan convertirse en zombis.
Usamos una de las VM de Raspberry como dispositivo IoT y
usamos un servidor web (IP: 192.168.56.101) para registrar los
datos IoT. El servidor web tiene un usuario/contraseña
EDUCACIÓN FÍSICAdieciséis= < *, *, *, *, *, *, *, *, *, *, *, *,23,∗, ∗
>:< Denegar > EP18= < ∗,(un, b),∗, ∗, ∗,192.168.56.110,*, *, *, *, *, dedicado para el usuario administrador y los dispositivos. En
(80,443,8080),∗, ∗ >:< Permitir > PE20= < este caso, es: “admin/contraseña”. La dirección IP de Kali Linux
*, *, *, *, *,192.168.56.110,*, *, *, *, *,21, enc,∗ > :<
Permitir > VM es 192.168.56.102. El adversario usa SDNPWN Toolkit para
envenenar los cachés ARP del dispositivo/usuario usando
parodiaataque (Amenaza 3) [19, 20]. Para envenenar la caché
Ahora considere que un nuevo dispositivo zombie IoT intenta ARP, el adversario primero envía una solicitud de flujo legítima
acceder a la red. La autenticación fallará debido a la aplicación ISA al controlador para instalar una regla de flujo, que establece
y la autoridad de autenticación de IoT. una ruta hacia el dispositivo IoT de la víctima. Luego, el
Ahora, consideremos que un dispositivo ha sido manipulado adversario falsifica una solicitud ARP gratuita para envenenar
físicamente y convertido en un zombi y pudo autenticarse con el caché APR del dispositivo IoT. El adversario también
éxito. En este caso, la aplicación PbSA entra en funcionamiento y envenena la caché ARP de otro usuario. Los paquetes del
evitará que el zombi lance ataques de inundación. Esto se logra dispositivo IoT se redirigen a través del adversario malicioso.
utilizandoEDUCACIÓN FÍSICA18y EDUCACIÓN FÍSICA20que solo Básicamente, esto permite que el adversario vea, copie y
permiten que un dispositivo zombi envíe tráfico HTTP y tráfico FTP modifique cualquier instrucción/datos hacia o desde el
cifrado al centro de datos (192.168.56.110). Sin embargo, el zombi dispositivo IoT. El adversario también puede lanzar un ataque
no puede llevar a cabo ataques de inundación (como inundación MiTM (Amenaza 4). Además, presenta la posibilidad de ataques
UDP, inundación SYN e inundación HTTP). Además, el escaneo de adicionales, como la eliminación de SSL y el secuestro de
bots no es posible debido aEDUCACIÓN FÍSICAdieciséis. Por lo tanto, sesiones. La Figura 9a muestra un ataque exitoso.
el bot no puede crear nuevos bots ni inundar la red. Con nuestra arquitectura de seguridad, cada uno de los
Cada dispositivo vulnerable responde al ScanListener en Mirai. Mirai tiene dispositivos, así como las máquinas de los usuarios, se autentican
otro detector de procesos llamado Loader que enumera las respuestas de antes de conectarse a la infraestructura de IoT mediante ECC. Un
los hosts vulnerables. En nuestro caso, la cantidad de hosts vulnerables adversario, que no sea un interno, no podrá eludir la fase de
activos fue cero. Por lo tanto, esto muestra cómo las políticas específicas de autenticación. Por otro lado, si el adversario es un interno y puede
dispositivos en nuestra arquitectura de seguridad pueden ayudar. pasar la fase de autenticación ECC, entonces el adversario será
diario de cosas
10
restringido por las políticas de seguridad en el servicio de autorización. Los flujos permanecen cifrados de un extremo a otro, y los
Además, al final de la fase de autenticación ECC, cada dispositivo IoT ha conmutadores OpenFlow intermediarios no podrán descifrar la
establecido una clave secreta, que se utiliza para cifrar sus flujos. Esto carga útil. De manera similar, los flujos también están protegidos
crea un canal seguro que el dispositivo IoT puede usar para enviar las por integridad utilizando mecanismos criptográficos. Además,
credenciales al servidor web. Por lo tanto, el adversario no puede robar nuestra arquitectura de seguridad garantiza que los dispositivos
las credenciales. La Figura 9c muestra el intento de ataque detectado estén autenticados y que su acceso a los servicios y flujos esté
por nuestra arquitectura. determinado por los privilegios de acceso otorgados a estos
dispositivos según las especificaciones de la política en PbSA.
• Mitigación de amenazas:En la sección anterior, describimos cómo
B. Análisis de seguridad
nuestra arquitectura de seguridad puede mitigar diferentes tipos
En esta sección, proporcionaremos un breve análisis de las características de de ataques. Además, la violación de las políticas de seguridad
seguridad de la arquitectura propuesta. como se especifica en la PbSA se considera una violación de la
• Autenticación del dispositivo:Un requisito importante para seguridad. En nuestra implementación actual, hemos asumido
asegurar una infraestructura de red IoT es la necesidad de un que la PbSA en sí misma está reforzada y segura contra tales
mecanismo de autenticación de dispositivos ligero y robusto. violaciones.
Nuestra arquitectura proporciona un mecanismo ligero de
autenticación de dispositivos basado en ECC. Esto garantiza que C. Desempeño
solo los dispositivos autenticados puedan acceder a los servicios En esta sección, presentamos el rendimiento de nuestra aplicación
de red. La naturaleza liviana de nuestro protocolo garantiza que de seguridad y dispositivos IoT conectados a la red SDN.
sea adecuado para dispositivos IoT con recursos limitados.
Además, la solidez del protocolo de autenticación basado en ECC Rendimiento de la aplicación
garantiza que sea computacionalmente inviable para los Primero, presentamos el rendimiento de nuestras aplicaciones que se
adversarios romper el esquema dentro de un tiempo polinomial. ejecutan en ONOS. Medimos el rendimiento, los usos de la CPU y el uso de la
Nuestro protocolo también tiene características que aseguran memoria en montón con y sin nuestra arquitectura de seguridad mediante
que no sea susceptible a ataques de repetición. Finalmente, este CBench y JConsole. Nuestra topología utiliza 16 conmutadores OpenFlow,
esquema de autenticación se combina con el servicio OAUTH para cada uno de los cuales se conecta a 500 hosts. En este documento, nos
el control de acceso a los servicios. enfocamos solo en los problemas de seguridad de una infraestructura de
• Autorización de flujo del dispositivo:Otro requisito importante es la red IoT en lugar de otras características de rendimiento.
necesidad de poder controlar y asegurar los flujos entre los La Figura 10a muestra una comparación entre el rendimiento de ONOS
dispositivos IoT en la red. Una de las principales ventajas de usar SDN que se ejecuta con y sin nuestras aplicaciones de seguridad. Variamos
es su capacidad para proporcionar administración de políticas en todo los PE y medimos el rendimiento. El gráfico de barras ilustra una
el dominio para un control seguro de los flujos dinámicos entre disminución en el rendimiento con el aumento de PE. Con 500 PE
dispositivos IoT. Nuestra arquitectura de seguridad basada en instalados, el rendimiento es de 8319,51 flujo/ms. Sin PbSA, ISA y con
políticas (PbSA) permite un flujo detallado y políticas de enrutamiento aplicaciones predeterminadas que se ejecutan en ONOS, el
seguro basadas en rutas que hacen cumplir la comunicación segura rendimiento es de 15980,9 flujos/ms.
entre los servicios y dispositivos de extremo a extremo. Por ejemplo, Las Figuras 10b y 10c muestran el uso de CPU y memoria en montón
una ruta en particular puede restringirse solo a dispositivos con una con y sin nuestras aplicaciones; hemos variado los PE de 100 a 500. Con
etiqueta de seguridad de al menos alto y un nivel específico de las aplicaciones predeterminadas, ONOS instala una cantidad de flujos
rendimiento mientras también se restringe a un conjunto de rutas en los conmutadores OpenFlow, y esto genera una carga de CPU y un
específicas (seguras). Estas políticas basadas en rutas son críticas uso de memoria en montón. Por otro lado, las aplicaciones asociadas
cuando se protegen los datos de dispositivos confidenciales, pero con nuestra arquitectura de seguridad solo instalan los flujos
también son útiles para aplicaciones con diferentes requisitos de permitidos, por lo que incurren en un menor uso de la CPU y la
calidad de servicio. Por ejemplo, el tráfico que requiere cierto ancho memoria del montón. Hemos proporcionado una comparación entre
de banda debe tomar una ruta en la que los dispositivos y canales de ambos casos cambiando el número de PE instalados. Hemos marcado
la red tengan las capacidades necesarias. Además, supongamos que tres zonas distintas en las curvas según los mensajes de registro de
debido a algún ataque (por ejemplo, un ataque DDoS), el tráfico de un cola de ONOS. Son i) la fase de arranque del controlador, ii) la fase de
dispositivo no puede atravesar la red. Nuestro PbSA proporciona una descubrimiento del dispositivo y carga del controlador, y iii) la fase de
ruta alternativa para que el tráfico del dispositivo llegue a su destino consulta de PbSA+ISA. Las fases están marcadas con una línea roja en
requerido. Esto destaca la característica novedosa de nuestro PbSA los gráficos (Fig. 10b, 10c).
para administrar dinámicamente las políticas de seguridad basadas en Durante la fase de arranque del controlador, se activan los diversos módulos
rutas y flujos para lograr comunicaciones seguras en los dominios centrales del controlador, como DHCP y la aplicación de reenvío, lo que
SDN. genera un gran consumo de recursos de CPU y memoria en montón.
• Confidencialidad, integridad y disponibilidad del flujo (CIA): Nuestra También aumenta con el descubrimiento de dispositivos. Como se mencionó
arquitectura PbSA también proporciona servicios CIA a pedido. Estos anteriormente con cbench, con el funcionamiento normal de SDN, cada host
requisitos se especifican como parte de las especificaciones de la final hace ping entre sí, lo que genera un gran uso de CPU y memoria en
política en el PbSA. En términos de confidencialidad, se pueden montón. Pero con nuestra aplicación de seguridad, algunas solicitudes de
encriptar flujos específicos a lo largo de rutas específicas entre host/dispositivo final se eliminan debido a violaciones de la política de
dispositivos específicos. Las claves de cifrado se establecen a través de seguridad, lo que efectivamente conduce a un menor uso de CPU y memoria
un proceso seguro de gestión de claves. en montón.
diario de cosas
11
durante la fase de arranque de ONOS. Aumenta hasta 280 MB durante la

Expresión de política frente a rendimiento
(Dieciséis interruptores OpenFlow)
18000
15980.9
fase de descubrimiento del dispositivo. Finalmente, en la fase de
16000
14130.2 establecimiento de la comunicación, aumenta constantemente a 370 MB.

14000
12180.61 Con 500 PE en la aplicación PbSA e ISA en ejecución, el uso de la memoria en

12000
Rendimiento medio (flujos/ms)
10000
10681.66
9540.9
montón se convierte en 140-150 MB durante la fase de arranque del
8000
8319.51
controlador. Durante la fase de detección de dispositivos, aumenta
6000
constantemente hasta 290 MB. Debido a una solicitud no permitida, el uso
4000 de la memoria en montón se mantiene entre 280 y 350 MB.
2000
Rendimiento del dispositivo:
0
100 PE 200 PE 300 PE 400 PE 500 PE Sin que
Consumo de energía del dispositivo
No de Expresión de Política
120
(a)
Con aplicaciones predeterminadas
Con aplicación PbSA
100
86.2745098
Nivel de batería (en porcentaje)

RENDIMIENTO DE CPU VS POLÍTICA (DIECISÉIS
PUNTO DE ACCESO DE FLUJO ABIERTO) 80 73.7254902
82.43143503
100PE 200PE 300PE 400PE 500PE Sin que
100 Controlador Hola 60 66.65999894

Fase Consulta PbSA +ISA
fase de arranque y fase de carga del conductor
90
40
80
20
70
60 0
00:00:00
00:01:40
00:03:20
00:05:00
00:06:40
00:08:20
00:10:00
00:11:40
00:13:20
00:15:00
00:16:40
00:18:20
00:20:00
00:21:40
00:23:20
00:25:00
00:26:40
00:28:20
00:30:00
00:31:40
00:33:20
00:35:00
00:36:40
00:38:20
00:40:00
00:41:40
00:43:20
00:45:00
00:46:40
00:48:20
00:50:00
00:51:40
00:53:20
00:55:00
00:56:40
00:58:20
01:00:00
01:01:40
50 49.1
Hora
40
30
(a)
20
TIEMPO PROMEDIO DE CONFIGURACIÓN DE RUTA ENTRE DISPOSITIVOS
10
Con PbSA e ISA Con aplicaciones ONOS predeterminadas
0
3000
2500 2589.18
TIEMPO (EN SEGUNDOS)
2487.68
TIEMPO DE CONFIGURACIÓN DE RUTA (MS)
(B) 2000 1938.33 1860.89
Usos de memoria en montón frente a variación de expresión de política

1500 1477.56 1420.65
(Dieciséis interruptores OpenFlow)
100PE 200PE 300PE 400PE 500PE Sin que 1000

Hola 720,65 690,9
500
Controlador
Fase Consulta PbSA +ISA
fase de arranque y fase de carga del conductor
349.76 330.66
0
100 DE‐AP 200 DE‐AP 300 DE‐AP 400 DE‐AP 500 DE‐AP
NÚMERO DE PUNTOS DE ACCESO DE FLUJO ABIERTO
(B)
Memoria en montón utilizada (en MB)
Fig. 11: a) Consumo de energía del dispositivo y b) Ruta promedio

800,00 MB
Tiempo de configuración entre dispositivos

600,00 megabytes
Presentamos el tiempo promedio de configuración de la ruta de extremo a extremo del dispositivo
(con OF-AP variable) y consumo de batería de un activo

400,00 megabytes
200,00 megabytes
dispositivo IoT. En la Figura 11a con aplicaciones predeterminadas ejecutándose

0,00 megabytes
en la infraestructura IoT, la batería del dispositivo IoT disminuye de manera

0:00:00
0:00:04
0:00:08
0:00:12
0:00:16
0:00:20
0:00:24
0:00:28
0:00:32
0:00:36
0:00:40
0:00:44
0:00:48
0:00:52
0:00:56
0:01:00
0:01:04
0:01:08
0:01:12
0:01:16
0:01:19
0:01:23
0:01:27
0:01:31
0:01:35
0:01:39
0:01:43
0:01:47
0:01:51
0:01:55
0:01:59
0:02:03
0:02:07
0:02:11
0:02:15
0:02:19
0:02:23
0:02:27
0:02:31
0:02:35
0:02:39
0:02:43
0:02:47
0:02:51
0:02:55
0:02:59
0:03:03
0:03:07
0:03:11
0:03:15
0:03:19
0:03:23
0:03:27
0:03:31
0:03:35
0:03:39
0:03:43
0:03:47
0:03:51
0:03:54
0:03:58
Tiempo (en segundos)
constante hasta el 73 % dentro de una hora de comunicación. Con PbSA

(C)
e ISA, el consumo de batería del dispositivo IoT disminuye
Higo. 10: a) rendimiento, b) usos de la CPU y c) memoria en montón constantemente al 67% en una hora. Los mecanismos de seguridad utilizados en
Uso los dispositivos IoT consumen su energía de la batería, lo cual es
visible en 11a.
en fa igura 10b, sin nuestra arquitectura de seguridad asociada, los El tiempo promedio de configuración de rutas entre dispositivos IoT aumenta
aplicar usos de la CPU son constantes en torno al 10 % cuando en ambos casos con el número variable de OF-AP (Figura 11b). Con las
ONOS arranca. Durante el proceso de descubrimiento de dispositivos, la CPU aplicaciones predeterminadas de ONOS ejecutándose, el promedio
uso aumenta al 84%. Finalmente, mientras se instalan los caudales el tiempo de configuración de la ruta para 100 OF-AP es330.66Sray constantemente
y C El proceso de comunicación comienza entre los dispositivos IoT, aumenta a2487.68Sracon 500 OF-AP. Por otro lado, con
UPC el uso se mantiene constante entre el 78 y el 85 %. Con 500 PE, PbSA e ISA corriendo sobre el controlador causa algunos
la p bSA e ISA que se ejecutan sobre ONOS Controller utilizan un 14 % retraso en el tiempo de configuración de la ruta. En este caso, con 100 OF-AP el
de th y CPU. Durante la fase de detección de dispositivos, el uso de la CPU el tiempo promedio de configuración de la ruta es349.76Sray va aumentando paulatinamente
aumentar ases al 80%. Debido a políticas de seguridad no permitidas, a2589.18Sracon 500 OF-AP.
comunicación El controlador descarta las solicitudes de comunicación y el uso de
la C PU disminuye constantemente. Finalmente, se vuelve constante d D. Comparación
alrededor 55-60%.
En esta sección, proporcionaremos una comparación de nuestro enfoque
Montón el uso de la memoria sigue un patrón similar al de la CPU con otros trabajos de un tipo similar. Aquí nos centraremos en dos
uso . Sin PbSA e ISA, se queda en 150-160 MB aspectos, i) funcionalidades de seguridad y ii) desempeño.
diario de cosas
12
TABLA II: Comparación de servicios de seguridad
Acercarse SDN Negro M2M SDN solo realiza autenticación tradicional basada en inicio de
MINA SDTCP
SDN
Nuestra
Servicios para Sabio
[22] [23] Acercarse sesión de usuario/dispositivo [25]. Por lo tanto, con 1000 entradas de
el dispositivo [9] [21]
Dispositivo usuario, toma alrededor de 989,34 microsegundos con nuestro
No No No No sí
Autenticación enfoque en comparación con los 867,37 microsegundos de M2M SDN.
Fluir
No No No No sí El mayor tiempo de autenticación se debe a las comprobaciones de
Autorización
Fluir seguridad adicionales proporcionadas por el servicio de
No sí No No sí
Cifrado aprovisionamiento de dispositivos en nuestra arquitectura. Finalmente,
Fluir hemos comparado los tiempos de autorización e instalación de flujo de
sí sí sí sí sí
Gestión
nuestra arquitectura con M2M SDN [25]. En ambos casos, hemos
variado el número de pólizas instaladas y medido los tiempos de
autorización de flujos e instalación de flujos. Con 1000 políticas
Funcionalidades de seguridad:Comparamos cuatro trabajos instaladas, toma aproximadamente 106,32 microsegundos y 109,56 ms
anteriores que han utilizado SDN en la provisión de para autorizar e instalar flujos respectivamente con nuestro enfoque. El
servicios para asegurar dispositivos e infraestructuras de M2M para SDN tarda alrededor de 98,75 microsegundos y 98. 26 ms
IoT. Estos servicios de seguridad han incluido la para autorizar e instalar los flujos respectivamente con la misma
autenticación de dispositivos, la autorización de flujos, el cantidad de pólizas instaladas. Nuestra arquitectura de seguridad
cifrado de flujos y la gestión de flujos. La Tabla II muestra incurre en un retraso ligeramente mayor debido a los atributos de
los diversos servicios de seguridad proporcionados por los política granulares finos y al proceso de evaluación de expresión de
trabajos anteriores y cómo se comparan con nuestro política asociado en comparación con el NAC simple de M2M SDN.
enfoque. Se puede observar que nuestra arquitectura
proporciona un conjunto más completo de servicios de
VREXALTADO WORCOS
seguridad en comparación con trabajos anteriores a la hora
de contrarrestar los ataques mencionados en el modelo de Hay varios trabajos relacionados que son relevantes para el trabajo
amenazas (Sección II). Como los trabajos anteriores solo presentado en este documento. Los hemos dividido en tres categorías
brindan un subconjunto de funcionalidades de seguridad, para compararlos con nuestro trabajo.
al comparar el rendimiento de cada una de las
funcionalidades de seguridad, solo comparamos aquellos A. Políticas y SDN
esquemas que brindan ese servicio correspondiente.
En RFC 1102, Clark introdujo el enrutamiento basado en políticas para
Además,
dominios autónomos [14], que proponía una sintaxis de políticas simple
Rendimiento: Esta sección presenta una comparación detallada de las para las comunicaciones entre dominios. Hemos perfeccionado y ampliado
características de rendimiento específicas de la comunicación y el flujo la sintaxis de la política para desarrollar especificaciones detalladas de
(como la instalación del flujo y los tiempos de autorización). Primero, políticas de seguridad dirigidas a dispositivos IoT y características de red
consideramos el tiempo de ida y vuelta promedio (RTT) y comparamos SDN. daset al. en [26] presentan un marco de política sensible al contexto
nuestro enfoque con SDN-Wise [9] y Black SDN [21] al variar la cantidad de para dispositivos IoT, para controlar y proteger el intercambio de
saltos en la figura 12a. Nuestro enfoque toma aproximadamente 145 ms en información entre ellos. Sus políticas capturan la naturaleza diversa de los
comparación con los 95 ms en BlackSDN y los 105 ms en SDN. El mayor dispositivos IoT y su interacción con los usuarios de la red mediante una
retraso en nuestra arquitectura se debe a la mayor cantidad de servicios de política de control de acceso basada en atributos. Su trabajo se centra
seguridad que se ejecutan en nuestra arquitectura de seguridad. Luego principalmente en la privacidad de los datos del usuario. En nuestro caso,
comparamos el tiempo de respuesta del flujo o el rendimiento con 6LE-SDN nos hemos centrado en asegurar la infraestructura de la red IoT mediante
[24] con una cantidad variable de conmutadores y las políticas que se políticas de acceso granular finas. Beetle [27] es un marco de políticas de
ejecutan en el controlador SDN (presentado en la figura 12b). Aquí, en control de acceso para sistemas operativos (Linux, Android) para controlar la
nuestra arquitectura, hemos utilizado 50 expresiones de política instaladas interacción de las aplicaciones con los recursos de los dispositivos
en cada uno de los conmutadores y simulamos el rendimiento. Tenemos periféricos y proporciona un acceso transparente a los dispositivos de red.
una ligera reducción en el tiempo de respuesta de flujo, que es de 19566 Más tarde, Hong utilizó el marco Beetle en las puertas de enlace de la red
flujos/ms en comparación con 22000 flujos/ms con 6LE-SDN (cinco doméstica para controlar las comunicaciones de IoT [28]. Este trabajo no
interruptores). Esta reducción se debe a nuestras expresiones de política y aborda la autenticación de dispositivos IoT o usuarios, que nuestra
las verificaciones de autorización realizadas por nuestra arquitectura de arquitectura sí considera. Se pueden encontrar otros trabajos sobre políticas
seguridad. de control de acceso para dispositivos IoT en [29, 30, 31]. Sin embargo,
Hemos comparado los tiempos de autenticación de dispositivos y usuarios ninguno de estos trabajos ha utilizado SDN para administrar y hacer cumplir
de nuestra arquitectura de seguridad con M2M SDN [25]. M2M SDN utiliza las políticas. Además, se preocupan principalmente por la seguridad del
un servicio de control de acceso a la red (NAC) para redes OpenFlow. Sin usuario en lugar de la seguridad de IoT.
embargo, los atributos NAC no son granulares finos y solo se enfocan en las Algunos trabajos relacionados relevantes en el contexto del control de
direcciones de origen y destino para autorizar las comunicaciones de flujo. políticas de red en SDN incluyen [32, 33, 34, 35, 36]. Sin embargo, estos
En este caso, hemos variado el número de usuarios y recogido los diferentes trabajos no abordaron los aspectos de seguridad y, en particular, no
tiempos de autenticación. El servicio de autenticación en nuestra proporcionaron una gestión de red basada en políticas de seguridad
arquitectura de seguridad es parte del servicio de aprovisionamiento de detallada para los servicios de IoT, que ha sido el enfoque principal de
dispositivos, que hace más que solo la autenticación basada en el inicio de nuestro documento. En 2016, propusimos una arquitectura de seguridad
sesión del usuario. Por ejemplo, puede verificar el estado de seguridad de basada en políticas para las comunicaciones SDN dentro del dominio en [37].
los dispositivos. Por otro lado, En este documento actual, hemos ampliado el lenguaje de esta política
diario de cosas
13
RTT medio
160
145 Tiempo de respuesta de caudal
140
22500 6LE‐SDN [46] Nuestro enfoque
116
120
Tiempo de respuesta de caudal (Flujos/s)

105 22000
RTT promedio (en ms) 100 95
80 21500
80
Proyectado 21000
60
36 20500
40
20 20000
0 19500
Sabio SDN Nuestro enfoque SDN negro
19000
5 saltos (ms) 10 saltos (ms) 5 SW 10 SW 15 SW
(a) (B)
Comparación de instalación y autorización de flujo

tiempo de autenticación
120
1.00E+03 M2M con SDN [42] Nuestro enfoque
100
D segundo
80
icro
60
metro
Testoy en
40
20
1.00E+02
100 entrada de usuario 1000 entrada de usuario
0
100 PE 1000 PE 100 PE 1000 PE
SDN M2M [42] Nuestro enfoque Tiempo de Autorización de Caudal (µs) Tiempo de instalación de flujo (ms)
(C) (D)
F yo G. 12: a) Comparación de RTT Promedio; b) Comparación del tiempo de respuesta de Flujo; c) Comparación de Tiempo de Autenticación mi; D)
C Comparación de tiempos de Autorización de Flujo e Instalación.
and arquitectura para la infraestructura de red IoT y se agregaron nuevas políticas de control de acceso. Han demostrado cómo se puede proteger Matiz
Fcaracterísticas para proteger los dispositivos IoT de dispositivos maliciosos y una bombilla Philips de la suplantación de identidad del usuario en virar.
aataca Este trabajo solo se enfoca en un tipo particular de dispositivos IoT. enfoque Nuestra
proporciona una arquitectura de seguridad para diferentes tipos es de

Dispositivos IoT. Además, los dispositivos se pueden autenticar antes
B. Seguridad y ataques de IoT
porque utilizan los servicios de red, lo que hace que la infraestructura trabajo
PAGS
único et al. en [38], Lyu et al. en [39] y Mendoza et al. en de la red IoT sea más segura.
[40] consideran varios ataques para comprometer las redes IoT.
El uso de SDN para controlar la infraestructura de IoT no es nuevo. S DN-
T Estos trabajos se centran en analizar las vulnerabilidades en IoT
WISE es el acercamiento más cercano a nuestra arquitectura [9]. El
infraestructura de red, mientras que nuestro trabajo se refiere principalmente
norte
Los investigadores han utilizado el controlador SDN para limitar la am contar
wcon el diseño de la política de autenticación y autorización
de intercambio de información entre nodos de sensores Ellos
BArquitectura de seguridad basada en infraestructura de red IoT. Pensilvania t al.
inalámbricos. introdujo una interfaz API sobre el programa ONOSer a
mien [41] proporcionan un análisis de los ataques basados en Telnet en
Controll los nodos IoT. En nuestro caso, hemos introducido uced
Idispositivos oT. Proponen un IoTPot (un honeypot) e IoTBox un
servicios de autenticación y autorización para proteger los fluye
( sandbox), que ayudan a atraer ataques basados en Telnet contra
dispositivos IoT. Heshamy otros. en [25] propone un si mple
vVarios dispositivos IoT que se ejecutan en diferentes arquitecturas de CPU.
Mecanismo de control de acceso a la red (NAC) para que la máquina
T su trabajo sobre todo y se enfoca en analizar el malware IoT
dispositivos de máquina (M2M) que utilizan SDN. Su arquitectura NAC
er,
amenazas En nuestro pap del hemos proporcionado un análisis detallado
para dispositivos M2M captura funciones de red mínimas (como
ataque de Mirai. M para Además, nuestra arquitectura de seguridad ayuda
como IP de origen y destino y tasas de bits). No es tan detallado
a detectar ataques y evita que se propaguen.
bloquear telnet ba Capellupo
como nuestras políticas y no considera el dispositivo IoT
et al. en dispositivos de [42] presentan un análisis de los hogares actuales,
parámetros específicos en el control de acceso. Qin propuso MINA
automatización como Amazon Echo y TpLink smart, cómo pueden
(Multinetwork INformation Architecture) [22], que utiliza
conectar y discutir h a representar amenazas importantes para la seguridad.
SDN para administrar la infraestructura de red de IoT. El enfoque
las redes domésticas y a la privacidad del usuario. Su trabajo se centra en
principal de este trabajo está en la gestión de los servicios de red y
principalmente en direccionesi diferentes vectores de amenazas para el IoT doméstico.
los flujos de programación. El trabajo en [23] se ocupa de la
infraestructura de red tura Nuestro enfoque ayuda a rectificar algunas
calidad de servicio y considera el uso de la infraestructura IoT para
de los problemas m mencionado en su trabajo; por ejemplo, nuestra ayuda
gestionar datos a gran escala generados por sensores IoT.
arquitectura puede h para evitar usuarios/dispositivos no autorizados
xuet al. en [44] usó SDN para prevenir ataques de flujo en la
obtener acceso a n servicios de red y tráfico de dispositivos IoT.
infraestructura de IoT. Utilizaron un mecanismo de control de acceso
dinámico y monitoreo en tiempo real de los paquetes de flujo para
C. Uso de SDN para internet de las cosas
defenderse de los ataques a la red. Black SDN [21] usó características
Una actividad de red El enfoque basado en listas negras de dispositivos IoT tiene de SDN para cifrar el encabezado y la carga útil para evitar algunos
sido propuesto en [4 3]. Los autores han utilizado funciones de SDN para ataques en la infraestructura de IoT. Miettinenet al. en [8] desarrolló un
bloquear/poner en cuarentena dinámicamente los dispositivos IoT maliciosos usando Sistema de identificación de dispositivos IoT conocido como IoT Sentinel. internet de las cosas
diario de cosas
14
Sentinel usó SDN para extraer atributos específicos del dispositivo IoT. La arquitectura de seguridad propuesta se alinea con el paradigma
En su modelo, los dispositivos IoT legítimos se identificaron mediante emergente de perímetro definido por software (SDP) que tiene como
modelos predictivos. En su trabajo, Gonzálezet al. en [45] consideró la objetivo restringir el acceso a la red y las conexiones entre elementos
gestión de una gran cantidad de dispositivos IoT y su tráfico utilizando permitidos utilizando una arquitectura controlada por software [50]. Nuestra
SDN. Sin embargo, este no es un enfoque basado en políticas de arquitectura de seguridad SDN-IoT solo permite comunicaciones para
seguridad. dispositivos IoT que han sido autenticados (IoT Authentication Authority) y
Sharma et al. en [46] usó SDN para crear una arquitectura de seguridad para cuyas solicitudes de servicios están autorizadas contra un conjunto de
hogares inteligentes. La arquitectura utiliza un orquestador y KNOT (que políticas especificadas en nuestro PbSA que determina si se han cumplido
actúa como una capa de datos) [47] para defender ataques persistentes las restricciones de seguridad. La separación entre los planos de control y de
avanzados y mitigar ataques. Por el contrario, nuestra arquitectura de datos se logró utilizando la arquitectura SDN mediante la cual la capacidad
seguridad se enfoca en desarrollar una solución de seguridad que pueda de controlar el acceso se gestiona por separado de la transmisión de datos y
autenticar e incorporar los dispositivos IoT rápidamente. las comunicaciones entre los dispositivos IoT se virtualizan mediante
El uso de IPv6 crea muchos desafíos, como alta latencia, superposiciones que representan rutas lógicas a través de una red física.
heterogeneidad y pérdida de paquetes, etc. para dispositivos 6LoWPAN
[24]. En [24], los autores han utilizado SDN para hacer frente a tales También mostramos cómo nuestra arquitectura de seguridad puede
desafíos en una infraestructura de red IoT. La arquitectura propuesta ayudar a defender la infraestructura de red de IoT de ataques
utiliza dispositivos OpenFlow como puertas de enlace de borde que específicos, como los ataques DDoS basados en Mirai, y detectar
administran los dispositivos IoT. El controlador SDN controla la red dispositivos y flujos de IoT maliciosos. Hemos presentado una discusión
central. Han propuesto aplicaciones orientadas al norte para el análisis analizando el desempeño de los mecanismos de seguridad propuestos
de datos y el modelado de soluciones comerciales. Sin embargo, su en nuestra arquitectura. Creemos que esta combinación de
solución no aborda los aspectos de seguridad. Nuestro trabajo se ha arquitectura de seguridad impulsada por políticas basada en SDN junto
centrado en estos problemas de seguridad en la infraestructura de red con un protocolo de autenticación ligero y un marco de autorización
de IoT. OAuth ofrece un enfoque novedoso para la provisión y administración
Colmillo et al. en [48] presentó el esquema de autenticación The seguras de servicios en una infraestructura de red IoT.
Hidden Pattern (THP), que previene ataques en redes IoT basadas
en SDN. El esquema de autenticación utiliza una contraseña gráfica
y un desafío-respuesta para autenticar los dispositivos, lo que RFERENCIAS
ayuda a que la infraestructura esté a salvo de los ataques
Shoulder-Surfing, Smudge y Recording Screen. Su esquema se [1] R. Bogue, “Hacia el mercado de billones de sensores,”Revisión de
centra en ataques específicos del cliente. Por otro lado, nuestro sensores, vol. 34, núm. 2, págs. 137 a 142, 2014.
trabajo se ha centrado más en cómo proteger los servicios de red [2] J. Gubbi et al., "Internet de las cosas: una visión, elementos
de dispositivos maliciosos. arquitectónicos y direcciones futuras"Sistemas informáticos de
Houda en [49] propone un marco basado en blockchain para la próxima generación., vol. 29-7, págs. 1645–1660, 2013.
mitigación colaborativa de ataques DDoS. Ha desarrollado una solución [3] SDT Kelly et al., "Hacia la implementación de iot para el monitoreo
de protección DDoS multidominio para infraestructura de red IoT. Cada de las condiciones ambientales en los hogares",Revista de
dominio utiliza un controlador SDN independiente para administrar los sensores IEEE, vol. 13, núm. 10, págs. 3846–3853, 2013.
dispositivos IoT específicos del dominio. El marco se conoce como Co- [4] RH Weber, “Internet de las cosas: nuevos desafíos de seguridad y
IoT; utiliza contratos inteligentes de Etherium para transferir la privacidad”,Revisión de seguridad y derecho informático, vol. 26,
información del ataque DDoS para proteger los dominios vecinos. núm. 1, págs. 23 a 30, 2010.
Nuestra arquitectura de seguridad apunta a la infraestructura de red [5] M. Medwed, “Retos de seguridad de IOT y caminos a
IoT intradominio y se enfoca en ataques específicos específicos seguir”, enActas del 6º Taller Internacional sobre
identificados en la sección de modelo de amenaza. Dispositivos Embebidos Confiables. ACM, 2016, pág. 55.
En nuestro enfoque, hemos desarrollado una arquitectura de [6] LAB Pacheco et al., “Evaluación de la amenaza distribuida de
seguridad que consta de autenticación ligera y políticas de denegación de servicio en el internet de las cosas”, en
seguridad detalladas, que se han aplicado mediante SDN para Network Computing and Applications (NCA), 2016 IEEE 15th
controlar la infraestructura de red de IoT. Ninguno de los enfoques International Symposium on. IEEE, 2016, págs. 89–92.
SDN-IoT anteriores proporciona autenticación ligera y autorización [7] X. Cao et al., "Fantasma en zigbee: Ataque de agotamiento de energía
basada en políticas integradas con la arquitectura SDN para redes en redes inalámbricas basadas en zigbee"Diario de Internet de las
IoT. Esto diferencia el trabajo presentado en este documento del cosas de IEEE, vol. 3, núm. 5, págs. 816–829, 2016.
trabajo previo en esta área. [8] M. Miettinen et al., "Iot centinela: identificación automatizada
del tipo de dispositivo para la aplicación de la seguridad en
VI. CONCLUSIÓN iot", en Distributed Computing Systems (ICDCS), 2017 IEEE
Las amenazas a la infraestructura de la red IoT aumentan a diario. 37th International Conference on. IEEE, 2017, págs. 2177–
Debido a las limitaciones de recursos y la diversidad de dispositivos, es 2184.
difícil implementar las medidas de seguridad heredadas existentes en [9] L. Galluccio et al., "Sdn-wise: Design, prototyping and
las redes de IoT. Nuestro enfoque principal en este documento ha sido experimentation of a stateful sdn solution for wireless
desarrollar una solución de seguridad práctica para prevenir ataques a sensor networks", enComunicaciones informáticas (INFO-
la red de dispositivos IoT maliciosos que atacan la infraestructura de la COM), Conferencia IEEE 2015 sobre. IEEE, 2015, págs.
red IoT. 513–521.
diario de cosas
15
[10] K. Kalkan y S. Zeadally, "Asegurar Internet de las cosas (iot) 2016, págs. 1 a 6.
con redes definidas por software (sdn)",Revista de [27] AA Levy et al., “Beetle: Comunicación flexible para
comunicaciones IEEE, No. 99, págs. 1 a 7, 2017. bluetooth de baja energía”, enActas de la 14.ª Conferencia
[11] D. Hardt, "El marco de autorización de Oauth 2.0", internacional anual sobre sistemas, aplicaciones y
2012. servicios móviles, ser. MobiSys'16. Nueva York, NY, EE.
[12] L. Da Xu et al., "Internet de las cosas en las industrias: una UU.: ACM, 2016, págs. 111–122.
encuesta",Transacciones IEEE sobre informática industrial, [28] J. Hong et al., "Demostración: creación de un control de acceso
vol. 10, núm. 4, págs. 2233–2243, 2014. comprensible para Internet de las cosas mediante Beetle", en
[13] AH Ngu et al., "Iot middleware: una encuesta sobre problemas y Actas de la 14.ª Conferencia internacional anual sobre
tecnologías habilitadoras",Diario de Internet de las cosas de IEEE, vol. sistemas móviles, aplicaciones y servicios complementarios,
4, núm. 1, págs. 1 a 20, 2017. ser. Compañero de MobiSys '16. ACM, 2016, págs. 102–102.
[14] D. Clark, “Enrutamiento de políticas en protocolos de Internet. solicitud [29] ALM Neto et al., "Aot: Autenticación y control de acceso
de comentario rfc-1102,”Centro de información de la red, 1989. para todo el ciclo de vida del dispositivo iot", enActas de
[15] A. Mohammadali et al., "Un nuevo método de establecimiento de clave la 14.ª Conferencia ACM sobre sistemas de sensores de
basado en la identidad para la infraestructura de medición avanzada red integrados CD-ROM. ACM, 2016, págs. 1–15.
en la red inteligente"Trans. IEEE. en red inteligente, 2016. [30] C.-JM Liang et al., “Sift: construyendo una internet de las cosas
[16] S. Sciancalepore et al., "Oauth-iot: un marco de control de seguras”, enActas de la 14ª Conferencia Internacional sobre
acceso para Internet de las cosas basado en estándares Procesamiento de Información en Redes de Sensores. ACM,
abiertos", enComputación y Comunicaciones (ISCC), 2015, págs. 298–309.
Simposio IEEE 2017 sobre. IEEE, 2017, págs. 676–681. [31] AA Yavuz, “Eta: eficiente y diminuto y autenticación para
[17] R. d. R. Fontes et al., "Mininet-wifi: una plataforma para la sistemas inalámbricos heterogéneos”, enActas de la sexta
investigación de redes inalámbricas definidas por software conferencia ACM sobre seguridad y privacidad en redes
híbridas físico-virtuales", enActas de la conferencia de 2016 inalámbricas y móviles. ACM, 2013, págs. 67–72.
sobre ACM SIGCOMM 2016 Conference. ACM, 2016, págs. [32] N. Foster et al., "Frenetic: un lenguaje de programación
607–608. en red", enAvisos ACM SIGPLAN, vol. 46, núm. 9. ACM,
[18] B. Visan et al., "Vulnerabilidades en los dispositivos IoT de la 2011, págs. 279–291.
arquitectura del concentrador", enConsumer Communications & [33] TL Hinrichs et al., "Administración práctica de red
Networking Conference (CCNC), 2017 14th IEEE Annual. IEEE, declarativa", enActas del primer taller de ACM sobre
2017, págs. 83–88. investigación en redes empresariales. ACM, 2009,
[19] Z. Yongchi et al., "Análisis del ataque de suplantación de arp", págs. 1–10.
Controlador programable y automatización de fábrica, vol. 2, [34] J. Reich et al., "Programación sdn modular con pirético",
pág. 017, 2005. Informe técnico de USENIX, 2013.
[20] D. Smyth et al., "Explotando las trampas en la implementación de [35] A. Voellmy et al., "Ortiga: Quitando el aguijón de la
redes definidas por software", enSeguridad Cibernética y programación de enrutadores de red", enAspectos prácticos
Protección de Servicios Digitales, Conferencia Internacional 2016 de los lenguajes declarativos. Springer, 2011, págs. 235–249.
sobre. IEEE, 2016, págs. 1–8. [36] ——, “Maple: simplificando la programación sdn usando políticas
[21] S. Chakrabarty et al., "Black sdn para el Internet de las algorítmicas,” enACM SIGCOMM Comunicación informática.
cosas", enMobile Ad Hoc and Sensor Systems (MASS), Revisar, vol. 43, núm. 4. ACM, 2013, págs. 87–98.
2015 IEEE 12th International Conference on. IEEE, 2015, [37] KK Karmakar et al., “Arquitectura de seguridad basada en
págs. 190–198. políticas para redes definidas por software”, enActas del
[22] Z. Qin et al., "Una arquitectura de red definida por 31.er Simposio Anual de ACM sobre Informática Aplicada.
software para el Internet de las cosas", enSimposio sobre ACM, 2016, págs. 658–663.
gestión y operaciones de red (NOMS), 2014 IEEE. IEEE, [38] P. Pongle et al., "Una encuesta: Ataques a rpl y 6lowpan en iot", en
2014, págs. 1–9. Computación generalizada (ICPC), Conferencia internacional de
[23] Y. Lu et al., "Sdtcp: Hacia el control de congestión tcp del centro de 2015 sobre. IEEE, 2015, págs. 1 a 6.
datos con sdn para aplicaciones iot"Sensores, vol. 17, núm. 1, [39] M. Lyu et al., "Cuantificación de la capacidad de ataque ddos
pág. 109, 2017. reflexiva de los dispositivos iot domésticos", enActas de la
[24] RK Das, N. Ahmed, FH Pohrmen, AK Maji y G. Saha, "6le- 10.ª Conferencia ACM sobre seguridad y privacidad en redes
sdn: una red definida por software basada en el borde inalámbricas y móviles. ACM, 2017, págs. 46–51.
para Internet de las cosas"Diario de Internet de las cosas [40] CV Mendoza et al., “Defensa para ataques selectivos en el iot
de IEEE, 2020. con un esquema de gestión de confianza distribuida”, en
[25] A. Hesham et al., "Un diseño e implementación simplificados Consumer Electronics (ISCE), Simposio internacional IEEE
de control de acceso a la red para la comunicación m2m 2016 sobre. IEEE, 2016, págs. 53–54.
usando sdn", enTalleres de conferencias sobre redes y [41] YMP Pa et al., "Iotpot: analizando el aumento de los
comunicaciones inalámbricas (WCNCW), 2017 IEEE. IEEE, compromisos de iot",EMÚ, vol. 9, pág. 1, 2015.
2017, págs. 1 a 5. [42] M. Capellupo et al., “Security and attack vector analysis of iot
[26] PK Das et al., "Seguridad basada en políticas sensibles al contexto devices”, enConferencia Internacional sobre Seguridad,
en Internet de las cosas", enComputación inteligente (SMART- Privacidad y Anonimato en Computación, Comunicación y
COMP), Conferencia internacional IEEE 2016 sobre. IEEE, Almacenamiento. Springer, 2017, págs. 593–606.
diario de cosas
dieciséis
[43] V. Sivaraman et al., "Seguridad a nivel de red y control de Hemos simulado el costo computacional del esquema propuesto
privacidad para dispositivos IoT de hogares inteligentes", en utilizando las máquinas virtuales Raspbian y Ubuntu. Los hemos
Informática móvil e inalámbrica, redes y comunicaciones presentado en la Tabla III. Aquí, también hemos presentado el tiempo
(WiMob), 2015 IEEE 11th International Conference on. IEEE, de cálculo de NIKE de [15]. Tenga en cuenta que este es un costo
2015, págs. 163–167. computacional de la implementación del protocolo NIKE en nuestra
[44] T. Xu et al., "Defensa contra ataques de flujo nuevo en Internet de infraestructura.
las cosas basado en sdn",Acceso IEEE, 2017.
TABLA III: Tiempo Computacional
[45] C. González et al., "Marco de seguridad basado en Sdn para el
IoT en la red distribuida", enInformática y Ciencias de la NIKE [15] Nuestra implementación
Entidad comunicante Hora Entidad comunicante Hora
Energía (SpliTech), Conferencia Internacional Multidisciplinar Metro 4.9s Dispositivo 5.6s
sobre. IEEE, 2016, págs. 1 a 5. AHE 5,46 ms Autoridad de autorización de IoT en 6,63 ms
[46] PK Sharma, JH Park, Y.-S. Jeong y JH Park, "Shsec: General 4,91 s general 5.61
arquitectura de red doméstica inteligente segura basada
en sdn para Internet de las cosas"Aplicaciones y redes
móviles, vol. 24, núm. 3, págs. 913–924, 2019. B. Costos de comunicación
[47] "Nudo", https://github.com/CZ-NIC/knot.
Se necesitan tres comunicaciones entre los dispositivos de IoT y la
[48] L. Fang, Y. Li, X. Yun, Z. Wen, S. Ji, W. Meng, Z. Cao y M.
autoridad de autenticación de IoT para autenticar o rechazar
Tanveer, “Thp: Un esquema de autenticación novedoso para
correctamente el dispositivo (Figura 5). Todo el proceso requiere siete
prevenir ataques múltiples en sdn- red IoT basada”,Diario de
mensajes para completar el proceso.
Internet de las cosas de IEEE, 2019.
[49] Z. Abou El Houda, A. Hafid y L. Khoukhi, "Co-iot: un esquema
colaborativo de mitigación de ddos en el entorno iot basado
en blockchain usando sdn", enConferencia de kallol karmakartrabaja como investigador en el Centro de
Investigación de Ingeniería de Seguridad Cibernética
Comunicaciones Globales IEEE 2019 (GLOBECOM). IEEE, 2019, Avanzada de la Universidad de Newcastle. Sus intereses de
págs. 1 a 6. investigación incluyen SDN, NFV, seguridad IoT e ingeniería
[50] D. Conde, "Perímetros definidos por software: una vista inversa de malware. También trabaja en estrecha
colaboración con DST y Data61, CSIRO, Australia, en
arquitectónica de sdp", https://sdn.ieee.org/newsletter/ proyectos relacionados con SDN e IoT.
march-2017/software-defined-perimeters-an-architectural-view-of-
sdp, marzo de 2017.
AAPÉNDICEA Vijay Varadharajanes Profesor de la Cátedra de

Innovación Global en la Universidad de Newcastle,
PAGSRENDIMIENTOAANÁLISIS DE LAPAGSROPUESTOECC Australia y Director del Centro de Investigación de
SQUÍMICO Seguridad Cibernética Avanzada y ha publicado más de
450 artículos en revistas y conferencias internacionales,
10 libros sobre Tecnología de la Información,
Aquí presentaremos los costos de rendimiento del esquema
Seguridad, Redes y Sistemas Distribuidos y ha realizado
basado en ECC propuesto en términos de sus cálculos y 3 patentes Vijay ha sido/está en el consejo editorial de
comunicaciones. varias revistas, incluidas ACM TISSEC, IEEE TDSC, IEEE
TIFS e IEEE TCC.
A. Costos computacionales
Surya Nepal Surya Nepal es científica investigadora
Nuestro protocolo de autenticación de dispositivos utiliza el protocolo principal sénior en Data61 de CSIRO. Actualmente
lidera el grupo de seguridad de sistemas distribuidos.
NIKE (Novel Identity-based Key Establishment) propuesto en [15]. En
Tiene más de 200 publicaciones revisadas por pares en
nuestra infraestructura, la comunicación tiene lugar entre el dispositivo su haber. Ha coeditado tres libros, incluidos seguridad,
IoT y la Autoridad de autenticación IoT. Cada dispositivo durante su privacidad y confianza en los sistemas en la nube, y es
coautor de tres patentes. Es miembro de los consejos
proceso de autenticación realiza multiplicaciones de dos puntos y tres
editoriales de IEEE TSC, TDSC y ACM Trans en
operaciones hash, mientras que la Autoridad de autenticación de IoT Tecnología de Internet y Fronteras de Big Data-
realiza multiplicaciones de tres puntos y cuatro operaciones hash. Por Seguridad Privacidad y Confianza. Ocupa un puesto
docente conjunto en la UNSW y profesor honorario.
lo tanto, la complejidad computacional del esquema para las partes
puesto en la Universidad de Macquarie.
que se comunican es la siguiente:
Uday Tupakulaes profesor titular en la Universidad de
para dispositivo:Cenfermero+ 2CMETRO+ 3Cpicadillo (1) Newcastle, Australia. En 2006 completó su doctorado
bajo la supervisión del Prof. Varadharajan. Uday tiene
Para IoTAuthenticationAuthority:Cenfermero+ 3CMETRO+ 4Cpicadillo 70 publicaciones en diferentes áreas de investigación,
(2) como seguridad de redes, ataques DDoS, seguridad
MANET y sistemas virtuales seguros.
General:2Cenfermero+ 5CMETRO+ 7Cpicadillo (3)
donde,Cenfermero=Tiempo computacional para la generación de números aleatorios;
CMETRO= Tiempo computacional para la multiplicación de puntos y Cpicadillo

= Tiempo computacional para el cálculo de la función hash.

Dasdese Arerreernexreerreererre - En.es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dasdese Arerreernexreerreererre - En.es

Cargado por

Copyright:

Formatos disponibles

Traducido del inglés al español - www.onlinedoctranslator.

Arquitectura de IoT segura habilitada para SDN

Middle. En el documento se presenta un análisis de la seguridad y el rendimiento de los mecanismos de seguridad

TABLA I: Taxonomía de amenazas según la arquitectura IoT

Capas Componentes Tareas amenazas

Firmware enrutamiento enmascarado,

Servicio de seguridad SDN IoT (SIS)

Autorización de IoT Dispositivo IoT

Administrador de políticas Autoridad Proveedor

PbSA Aplicación de seguridad IoT

Interfaz en dirección norte

Módulos y aplicaciones principales de SDN

Interfaz SouthBound (dispositivos de reenvío)

SW1 SW2 SW3 SW4

NI NII NI NII Usuario B Usuario C Usuario E Usuario F

Fig. 1: Arquitectura de seguridad Ctura para la infraestructura de red IoT

Autorización de IoT Autenticación IoT

Genera un Є Zq*, S2: Iniciar el procedimiento de autenticación del dispositivo ECC

Genera OAuth S7: Autorización Autorización

S8: Autorización de envío

OF-AP almacena en caché el token en

Fig. 2: Dia del proceso del protocolo de seguridad gramo

Ssimilar al sensor pertenece a un grupo válido (Grupo) y fabricado por un

Estado t fabricante(X)es válidosi ce rt(fabrica Turer(X))es

Adaptar ejem Dispositivo

La mayor preocupación de la aprovisionamiento s servicio, es cómo

El servicio comprobará th miDRepositorio PP con t él attri butes

solicitud dePbSA. Si los atributos de dispositivo y flujo para el Dispositivo

dispositivo IoT. El dispositivo IoT autenticado y aprovisionado ∥, ⇒

utiliza el token para acceder a los servicios de red requeridos. Este

Máquina virtual Raspbian

para defender los dispositivos IoT.

nuevo al agente de escucha;

B: infectar el dispositivo vulnerable;

Fig. 8: a) Diagrama de funcionamiento de Mirai Bot, b) Ataque SYN

la VM, el malware se inyecta en la red y se infectan. La (B)

durante la fase de arranque de ONOS. Aumenta hasta 280 MB durante la

(Dieciséis interruptores OpenFlow)

14130.2 establecimiento de la comunicación, aumenta constantemente a 370 MB.

12180.61 Con 500 PE en la aplicación PbSA e ISA en ejecución, el uso de la memoria en

Con aplicación PbSA

Nivel de batería (en porcentaje)

100PE 200PE 300PE 400PE 500PE Sin que

100 Controlador Hola 60 66.65999894

(B) 2000 1938.33 1860.89

Usos de memoria en montón frente a variación de expresión de política

100PE 200PE 300PE 400PE 500PE Sin que 1000

Fig. 11: a) Consumo de energía del dispositivo y b) Ruta promedio

Tiempo de configuración entre dispositivos

Presentamos el tiempo promedio de configuración de la ruta de extremo a extremo del dispositivo

(con OF-AP variable) y consumo de batería de un activo

dispositivo IoT. En la Figura 11a con aplicaciones predeterminadas ejecutándose

en la infraestructura IoT, la batería del dispositivo IoT disminuye de manera

Tiempo (en segundos)

constante hasta el 73 % dentro de una hora de comunicación. Con PbSA

TABLA II: Comparación de servicios de seguridad

Tiempo de respuesta de caudal (Flujos/s)

Comparación de instalación y autorización de flujo

proporciona una arquitectura de seguridad para diferentes tipos es de

AAPÉNDICEA Vijay Varadharajanes Profesor de la Cátedra de

CMETRO= Tiempo computacional para la multiplicación de puntos y Cpicadillo

También podría gustarte