Seguridad en MQTT para IoT: Vulnerabilidades y Soluciones

SEGURIDAD EN PROTOCOLO MQTT
UNIVERSIDAD ANTONIO NARIÑO BOGOTA
COLOMBIA
Ing. Jaime Pedraza Email: [email protected]
RESUMEN:
Este documento trata los problemas de
seguridad en el protocolo (MQTT)1 y da a
conocer
los
diferentes
tipos
de
vulnerabilidades [1] [2] y las diferentes
brechas
de
seguridad.
Además
contemplamos sus posibles soluciones. En
MQTT los datos en tránsito no se encriptan
por lo que la privacidad, autenticación e
integridad de los datos se convierten en
problemas en la implementación de este
protocolo. MQTT es uno de los más
implementados en aplicativos de internet
de las cosas. Cisco IBSG predice que el
número de dispositivos (IoT)2 alcanzará los
50 mil millones en 2020 [1]. Lo que tendrá
un impacto en casi todos los aspectos de
nuestra vida. Y por eso la importancia, de
la seguridad está en la parte superior de la
lista de desafíos de IoT. Este documento
propone el cifrado autenticado con datos
asociados (AEAD)3 [4] es una de las
soluciones más recomendadas y veremos
varios medios de mitigación de seguridad.
Estos resultados indican que protocolo de
seguridad usar con poca cantidad de
memoria para uso de microcontroladores
usados en IoT.
Palabras Clave: ChaCha20-Poly1305, nodos
restringidos, seguridad de IoT, MQTT,
seguridad sobre IoT
I.
INTRODUCCION
M
1
2
QTT es un protocolo ligero que
funciona en el modelo de
publicación y suscripción para
(MQTT) Message Queue Telemetry Transport
(IoT) Internet de las cosas
garantizar una comunicación eficiente entre
plataformas. MQTT se usa ampliamente para
IoT debido a su pequeño tamaño y al mínimo
consumo de ancho de banda [5] [2] [6] [7].
Para finales del 2020 se espera un número de
dispositivos conectados de 30 mil millones.
Para finales del mismo año se espera un
intercambio de datos superior a 40 Zettabytes.
Esto motiva a ver la importancia de todos los
datos generados, almacenados y transmitidos
des de dispositivos IoT, que es su seguridad y
como esto está relacionado con la privacidad
del usuario. Una implementación de estas solo
es exitosa si se basa en la seguridad. En un
contexto de IoT los dispositivos tienen
dirección IP para conectarse a redes de
comunicaciones y así comunicarse con otros
objetos o humanos. Hay muchos tipos de
dispositivos de bajo costo esto nos permite
utilizar dispositivos en todos los campos de
interés, por ejemplo: logística, ciudades
inteligentes, entorno inteligente, salud,
agricultura inteligente, etc. La diversidad,
eficacia, ingenio
y el transporte de
información lo convierte en un dominio
tecnológico de alta demanda, pero también lo
hacen vulnerable y riesgoso en términos de
seguridad. Este trabajo tiene como objetivo
aumentar la seguridad en los dispositivos IoT
al comprender los requisitos de seguridad para
los dispositivos, y poder analizar la superficie
del ataque en red local y red pública. La red
local es análoga al ataque interno donde el
atacante está en la misma red que los
dispositivos mientras que la red pública el
atacante puede residir en cualquier lugar de la
3
(AEAD) Cifrado Autenticado con datos asociados
red pública para atacar el sistema. Además se
propone ChaCha20-Poly1305 AEAD como
una solución para asegurar la comunicación de
IoT con recursos restringidos sobre MQTT /
MQTT-SN. ChaCha20 y Poly1305 son
respectivamente un cifrado de flujo ligero y un
autenticado de una sola vez que continúan
ganando popularidad en la comunidad de
cifrado.
B. Tipo de comando
Fuera del encabezado fijo de dos bytes, el
primer byte es el campo de control. Este
campo de control de 8 bits se divide en dos
campos de 4 bits. Los primeros 4 bits MSB son
el campo de tipo de comando.
Este documento está organizado de la
siguiente manera. En la sección II
Presentación del protocolo. En la sección III
resumimos trabajos sobre las vulnerabilidades
conocidas. En la sección IV mitigación de
vulnerabilidades, la seguridad. En la sección
V. finalmente damos algunas conclusiones.
II.
PROTOCOLO MQTT
MQTT es un protocolo binario y tiene un
formato de comando y reconocimiento de
comandos Entonces, cada vez que un cliente
envía un comando al corredor, el corredor
envía un acuse de recibo. Este protocolo de
comunicación se basa en realidad en el
protocolo TCP / IP. Primero habrá un
establecimiento de conexión TCP y luego
habrá un establecimiento de conexión MQTT
y luego ocurrirá la transferencia de datos.
Después de lo cual se terminará la conexión
TCP. Como se trata de un protocolo basado en
comandos y reconocimiento de comandos,
para cada función el cliente debe enviar
comandos al corredor. Y se envían como
paquetes. [5] [8] [7] [9] [1]
Figura 2. Tipo de comando 1
C. Control de bits de bandera
Los siguientes 4 bits son los bits de la bandera
de control y son usados por el comando de
publicación para el resto de los comandos que
están reservados y el valor será 0. Para el
comando PUBLICAR: el bit 0 denota si el
mensaje que se publica se retiene el mensaje.
Los bits 1 y 2 se utilizan para seleccionar la
calidad de servicio si es 0 o 1 o 2. Y el 3er bit
indica si es un mensaje duplicado. [10] [11] [5]
A. Formato de paquete de MQTT
El paquete MQTT consta de un encabezado
fijo de 2 bytes más un encabezado variable y
una carga útil. En este primer encabezado fijo
de 2 bytes siempre estará presente en todos los
paquetes y en los otros dos, el encabezado
variable y la carga útil no siempre estarán
presentes.
Figura 3. Control de bits de bandera 1
Figura 1. Formato MQTT
D. Conectar paquete
El primer byte del paquete de conexión será
10. Debido a que el valor del comando
CONNECT es 1, los primeros 4 MSB serán 1
y no hay banderas, por lo que los siguientes 4
bits serán 0.
Figura 4. Conectar paquete
El segundo byte debería ser la longitud
restante. Que es la longitud del encabezado
variable y la longitud de la carga útil.
Decidamos esta longitud después de completar
el encabezado de la variable y la carga útil.
Puede ver a continuación el formato del
encabezado de la variable y la carga útil del
paquete.
identificar el tráfico MQTT. Si se encuentra un
protocolo no válido, el servidor puede
rechazar la conexión. Después del nombre del
protocolo, está el nivel de protocolo. Esto
determina qué versión de MQTT admite. Para
la versión 3.1.1, el protocolo es de nivel 4. Y
si el mismo protocolo no es compatible con el
Los siguientes dos bytes se utilizan para
mencionar la duración de mantener vivo en
segundos. Durante 60 segundos, el valor será
003C en hexadecimal. Después del
encabezado de la variable, estará la carga útil
y contendrá; ID de cliente, nombre de usuario
y contraseña. En nuestro caso, no hay nombre
de usuario ni contraseña, por lo que solo estará
presente la identificación del cliente. Al igual
que hicimos para el nombre del protocolo, los
primeros 2 bytes denotarán la longitud de la
identificación del cliente. Supongamos que
nuestra identificación de cliente es PQRST.
Servidor, se desconecta enviando un acuse de
recibo con el código de retorno 01.
Figura 7. Encabezado
Figura 5. Formato de encabezado
En el encabezado de la variable, primero debe
estar el nombre del protocolo. Y para esto, los
primeros 2 bytes deben mencionar la longitud
del nombre del protocolo seguido del nombre
del protocolo. En nuestro caso, el nombre del
protocolo es MQTT, que tiene una longitud de
4. Entonces se convierte en:
Ahora es fácil determinar la 'longitud restante'
que se supone que debe estar aquí. Si cuenta el
total de bytes utilizados para el encabezado
variable y la carga útil. Es 17. Por lo tanto, la
'longitud restante' será 17.
Figura 8. Longitud 1
Figura 6. Protocolo 1
No puede dar el nombre que quiera aquí. Dado
que este nombre lo utiliza el servidor para
E. Paquete Connack
Una vez que se envía el paquete de conexión,
y si el corredor recibe la conexión, devolverá
el acuse de recibo: CONNACK. En el
encabezado de la variable de CONNACK
habrá el código de retorno de conexión. Al leer
eso, podemos entender si se establece la
conexión y, si no, el motivo del rechazo.
suscribirse al tema OPENLABPRO con QoS
0:
Figura 11. Subscribe un paquete 1
Figura 9. Tipos de Conexiones
F. Publicar paquete
Ahora publiquemos el mensaje “HOLA” al
tema OPENLABPRO. Para el comando de
publicación de paquetes, el valor es 3. Con
(QoS)4 nivel 0 y sin retener el indicador de
control de mensajes será 0. En la sección de
encabezado de variable, los primeros 2 bytes
denotarán la longitud del tema y luego
seguirán el tema. De manera similar, en la
sección de carga útil, los primeros 2 bytes
denotarán la longitud del mensaje seguido por
el mensaje.
Figura 10. Mensaje MQTT
G. Subscribe paquete
Ahora el mensaje está publicado y si hay
suscriptores para ese tema, recibirán el
mensaje. Para suscribirse a un tema, el cliente
debe enviar el paquete SUBSCRIBE. El valor
de comando del paquete de suscripción es 8 y
la bandera de control está reservada y debe ser
2. El encabezado de la variable contendrá un
ID de paquete de 16 bits distinto de cero. Y
como carga útil, estará el tema para suscribirse
seguido del nivel de QoS solicitado. Para
4
(QoS) Calidad de servicio
Ahora tiene una idea clara de los datos que se
envían en un protocolo MQTT. Y como puede
ver, todos los comandos e instrucciones se
envían y reciben como bits. Y por eso es un
protocolo de base binaria. Los campos de
texto, como nombre de usuario, contraseña,
tema, etc., están codificados como cadenas
UTF-8. Utiliza de uno a cuatro bloques de 8
bits para representar un carácter. Aquí, como
el nombre de usuario y la contraseña se envían
como datos sin procesar, la seguridad es
menor. Por lo tanto, se prefiere que la
certificación SSL sea una mejor opción.
III.
VULNERABILIDADES
El protocolo se ejecuta sobre TCP / IP (puerto
1883 y puerto 8883 para MQTT sobre TLS /
SSL). Un cliente MQTT, que puede ser un
editor o suscriptores, siempre publica o se
suscribe a un tema específico. Un servidor
central, conocido como broker, recibe
suscripciones de los clientes sobre temas,
recibe mensajes de los clientes y los reenvía,
según las suscripciones de los clientes, a los
clientes interesados. Los temas de MQTT son
jerárquicos con la forma de rutas de archivo,
por ejemplo, jardín / césped / humedad. La
conexión MQTT en sí es siempre entre un
cliente y el intermediario, ningún cliente está
conectado a otro cliente directamente. MQTT
se centra en la mensajería fiable, por lo que
incluye niveles de Calidad de servicio QoS
(nivel 0: "como máximo una vez", nivel 1: "al
menos una vez" y nivel 2: exactamente una
vez"). MQTT requiere una conexión TCP / IP,
sin embargo, esto hace que sea más difícil de
implementar en redes de sensores más simples
compuestas esencialmente por nodos de
restricción. La configuración experimental
como se muestra en la Figura. 12 incluye una
Raspberry Pi que aloja el MQTT Broker y el
editor, clientes suscriptores implementados
usando programas de Python que se ejecutan
en otra computadora. Raspberry Pi es una
computadora de placa única que se ejecuta en
un sistema operativo basado en Linux. Eclipse
Mosquitto, un MQTT Broker de código
abierto con soporte para las versiones 3.1 y
3.1.1, se implementó en Raspberry Pi. Se
utilizó el lenguaje de programación
interpretado de alto nivel Python para
implementar el Cliente (tanto el editor como el
suscriptor). Python proporciona API para la
comunicación con un agente MQTT a través
del protocolo MQTT. El analizador de
paquetes de código abierto
tema. El cliente envía un paquete CONNECT
junto con su identificación y credenciales si es
necesario. El Broker al recibirlo envía el
paquete CONNECT ACK con el acuse de
recibo. Luego, el cliente envía la SOLICITUD
DE SUSCRIPCIÓN con el nombre del tema.
El Broker al recibirlo, agrega al cliente a la
lista de suscriptores que tiene y luego envía
SUBSCRIBE ACK con el acuse de recibo.
Figura 14. Publicar datos
La figura 14. Muestra la secuencia de acciones
cuando un cliente intenta publicar datos en los
temas. CONNECT y CONNECT ACK tienen
el mismo significado que en la publicación.
Aquí, el cliente usa el nivel 0 de QoS (disparar
y olvidar) para publicar datos y, por lo tanto,
no hay respuesta del corredor una vez que el
cliente ha enviado el mensaje. El cliente envía
el mensaje PUBLICAR junto con el nombre
del tema y la carga útil. El Broker al recibir
este mensaje, lo reenvía a los suscriptores del
tema.
A. Mecanismos de autenticación
Figura 12. Servidor Broker MQTT
El archivo de registro en el extremo del Broker
se utilizó para registrar la respuesta del Broker
a varios tipos de ataques. El Broker se
implementó en Raspberry Pi y se probó para
detectar varios posibles ataques. Se
implementaron los mecanismos para prevenir
los ataques y se registraron y analizaron las
respuestas del Broker
Figura 13. Suscribirse al Broker.
La figura 13. Muestra la secuencia de acciones
cuando un cliente intenta suscribirse a un
La autenticación es un mecanismo mediante el
cual una entidad demuestra su identidad a la
otra parte, mientras que la autorización es un
mecanismo mediante el cual se utilizan las
credenciales de la entidad para permitir o
denegar el acceso a los servicios prestados. [5]
[3] [6] [9] [7] [8]
B. Sin mecanismo de autenticación
para autenticar usuarios
Cuando no existe un mecanismo de
autenticación, cualquier cliente puede publicar
o suscribirse a cualquier tema. Esto representa
una amenaza para la confidencialidad de los
datos. Los datos con los que está tratando el
Broker pueden tener información sensible y
esta información se puede obtener
simplemente proporcionando el nombre del
tema. La autenticación ayuda en la prevención
de este ataque al permitir que solo las
entidades registradas publiquen y suscriban
dato La autenticación se puede realizar
mediante diferentes métodos. El nombre de
usuario y la contraseña es la forma más común
de autenticación que se utiliza, los certificados
de cliente también se pueden utilizar para
demostrar su identidad. El desafío de usar
certificados para la autenticación es tener un
proceso
que
se
encargue
del
aprovisionamiento
de
certificados
(proporcionar certificados a los clientes) y la
revocación de certificados (para invalidar
ciertos certificados de
clientes si se
encuentran inválidos o comprometidos). Por lo
tanto, existe una necesidad de infraestructura
para hacer frente a los procesos antes
mencionados, lo que puede no ser factible en
muchos casos.
Figura 15. Muestra el CONNECT ACK diseccionado de
un cliente que intenta acceder sin credenciales válidas.
C. Credenciales de usuario enviadas
como texto sin formato en el
paquete de comandos CONNECT
El protocolo MQTT se diseñó teniendo en
cuenta la conectividad y no se prestó mucha
atención a la protección del protocolo.
Habilitar la autenticación evita que los
usuarios no autorizados no accedan a los datos,
pero las credenciales del usuario se pasan en
forma de texto sin formato y un atacante puede
utilizar este paquete para hacerse pasar por el
usuario legítimo y obtener acceso a los datos.
Un posible escenario de ataque, donde el
atacante se apodera del paquete CONNECT y
puede usarlo para obtener las credenciales para
hacerse pasar por el cliente legítimo. El pobre
cliente no se da cuenta de este ataque. Esta
vulnerabilidad en el protocolo se puede
superar mediante los siguientes mecanismos
explicados en la siguiente índice.
IV.
MITIGACION DE SEGURIDAD
Utilizando Transport Layer Security o Secure
Sockets Layer sobre el puerto 8883 (puerto
estándar utilizado para la conexión MQTT
segura), los paquetes entre el cliente y el
Broker se envían a través de un canal o túnel
de comunicación seguro como se muestra en
la Figura.17. El desafío de usar este
mecanismo es que, si el cliente realiza
reconexiones frecuentes, la sobrecarga
requerida para reanudar la sesión sería
realmente significativa. Por tanto, no se
recomienda utilizar este mecanismo en casos
de reconexiones frecuentes. La carga útil se
puede cifrar antes de enviarla a la red. Este
esquema requiere que el editor cifre el mensaje
antes de enviarlo al corredor. El descifrado se
puede realizar en el Broker o en el suscriptor.
El cifrado y el descifrado se pueden realizar
mediante algoritmos criptográficos ligeros.
Otra alternativa sería utilizar SMQTT con su
propia elección del algoritmo de cifrado.
Figura 17. Seguridad MQTT puerto 8883
La autorización se puede implementar en tres
niveles:
• Por tema: El usuario tiene acceso solo a los
temas a los que el administrador le permite
acceder. Este mecanismo permite evitar el
acceso no autorizado a los datos que se puede
realizar utilizando los comodines.
Figura 16. Muestra el paquete CONNECT COMMAND
diseccionado que revela el nombre de usuario y la
contraseña en texto sin formato
Por método: Incluso después de que el usuario
tenga acceso solo a los temas requeridos, el
usuario puede publicar y suscribirse, lo que no
es favorable en muchas situaciones. Este
mecanismo permite al usuario acceder para
publicar, suscribirse o ambos.
Por calidad de servicio (QoS): El protocolo
MQTT permite tres niveles de QoS y, por lo
tanto, se pueden imponer limitaciones en
cuanto a qué nivel de QoS tiene derecho un
usuario en particular. Los mecanismos antes
mencionados se pueden implementar usando
la Lista de Control de Acceso (ACL)5, donde
se menciona el nombre de usuario junto con
las restricciones.
A. Seguridad MQTT
El cliente MQTT puede autenticar al
intermediario utilizando certificados SSL
enviados desde el servidor. La autorización en
MQTT se utiliza para restringir el acceso a los
recursos del intermediario según la
información proporcionada por el cliente. Para
verificar la integridad de los datos, se puede
utilizar una función hash. TLS puede
proporcionar tales algoritmos. Para la
confidencialidad de los mensajes MQTT, se
puede utilizar un algoritmo de cifrado. Sin
embargo, estos algoritmos deben ser livianos y
requieren soporte del cliente. El cifrado se
puede implementar de un extremo a otro
(editor y suscriptores) o simplemente de
cliente a intermediario. El cifrado en capas
inferiores se puede utilizar cuando se ha
optado por el cifrado transparente. Se pueden
lograr en la capa de transporte con TLS o en la
capa de enlace con AES. MQTT-SN no define
ningún mecanismo de seguridad a nivel de
protocolo. Sin embargo, para MQTT-SN sobre
UDP, DTLS se puede utilizar para la seguridad
de la capa de transporte. [9] [1] [8]
B. ChaCha20-Poly1305 AEAD
ChaCha20 y Poly1305 se han diseñado para
implementaciones de software de alto
5
(ACL) Lista de control de acceso
rendimiento y para minimizar la fuga de
información a través de canales laterales.
ChaCha20, basado en Salsa20, es un cifrado de
flujo desarrollado por DJ Bernstein en 2008 y
es publicado por el RFC7539 [3]. ChaCha20
es una variante de ChaCha que tiene 20 rondas,
un aleatorio de 96 bits y una clave de 256 bits.
La función de cifrado ChaCha20 transforma
un texto de queja de longitud arbitraria en un
texto cifrado de la misma longitud. Esta
función se define de la siguiente manera en
[10]: La operación básica del algoritmo
Chacha20 es el cuarto de vuelta, que consiste
en la suma de enteros, OR exclusivo bit a bit y
rotación izquierda de n bits. La función de
bloque Chacha20 genera un bloque keystream
a XOR con un texto de conformidad. Se
pueden encontrar más detalles en [3].
C. Poly1305
Poly1305 es un autenticado de una sola vez
diseñado por DJ Bernstein en 2008 y
publicado por RFC7539 [3]. Un mensaje M de
longitud arbitraria se divide en trozos de 16
bytes y se alimenta a un polinomio basado en
el de 16 bytes clave de autenticación! ". El
valor final del polinomio se combina con un
aleatorio de 16 bytes para crear el número de
token de autenticación utilizado para
autenticar el mensaje. En [10],
D. AEAD_CHACHA20_POLY1305
AEAD_CHACHA20_POLY1305 [3] es un
cifrado autenticado con datos asociados
AEAD basado en la combinación del cifrado
de flujo ChaCha20 y el autenticado Poly1305.
AEAD_CHACHA20_POLY1305 toma como
entrada una clave de 256 bits, una aleatoria de
96 bits, un texto de demanda de longitud
arbitraria, y una longitud arbitraria Datos
autenticados adicionales (AAD)6. Esta función
devuelve un texto cifrado con el número de
autenticación que es el resultado de la función
Poly1305.
6
(AAD) Datos autenticados adicionales
AEAD_CHACHA20_POLY1305 se define de
la siguiente manera en [10]: El descifrado
funciona de manera similar con algunas
diferencias: los roles del texto cifrado y el
texto conforme se invierten. La función
Poly1305 todavía se ejecuta en el AAD y el
texto cifrado y la etiqueta generada deben
compararse bit a bit con la etiqueta recibida
para verificar la autenticidad de los datos. Sin
embargo, si el nodo está limitado por el
tamaño de la carga útil, se podría utilizar el
cifrado de la carga útil con AES-CBC. De
Santis et al. [10] presentan uno de los pocos
trabajos que discuten el uso de chacha20poly1305 AEAD para aplicaciones ligeras de
IoT.
Los
autores
proponen
una
implementación optimizada de ChaCha20
para procesadores ARMCortex-M4. La
evaluación del rendimiento muestra que los
cifrados ChaCha20-Poly1305 son candidatos
prometedores para proteger las aplicaciones
emergentes de IoT con limitaciones de espacio
y velocidad ajustadas.
V.
CONCLUSIONES
En este artículo, propusimos un esquema de
seguridad ligero para el protocolo MQTT /
MQTT-SN basado en chacha20-poly1305
AEAD. Este esquema asegura el cifrado de un
extremo a otro para los nodos.
Este documento habla sobre los diversos
protocolos utilizados en IoT, pero se centra en
el protocolo MQTT ampliamente Utilizado,
debido a sus características como tamaño de
encabezado pequeño, requisitos de ancho de
banda bajos, eficiencia y confiabilidad en
condiciones adversas, etc. A partir de los
experimentos que hemos realizado con el
protocolo MQTT, fue evidente que consistía
en su propio conjunto de vulnerabilidades que
los atacantes pueden aprovechar. Utilizando el
motor de búsqueda Shodan y las API de
Python, descubrimos que la mayoría de los
servidores que alojaban al MQTT Broker no
tenían el mecanismo de autenticación en su
lugar, que se puede explotar para robar datos
confidenciales o agregar datos redundantes
que a su vez podría afectar a todos los demás
sistemas. Que se basan en estos datos.
Una vez identificadas las vulnerabilidades, se
implementaron mecanismos de seguridad en
una Raspberry Pi que atiende a un Broker y se
modificaron sus archivos de configuración.
Además, la Lista de control de acceso ACL se
creó para garantizar que los usuarios solo
tengan acceso a los datos a los que tienen
derecho. Una vez que se impusieron estos
mecanismos de seguridad al Broker, todos los
ataques fracasaron. Por lo tanto, al
implementar un Broker, estos mecanismos de
seguridad podrían usarse en la fase inicial para
prevenir los ataques antes mencionados. Por lo
tanto, la seguridad debe tenerse en cuenta
desde el principio y no como una ocurrencia
tardía.
Bibliografía
[1] A. A. B. B. V. C. A. Q. V. P. R. Z. E. P. R. L.
3. Q. d. G. 7. P. F. G. Casteur, «Fuzzing
attacks for vulnerability discovery
within MQTT protocol,» IEEE, 2020.
[2] B. B. M. K. S. D. o. C. P. –. B. S. C. B. I.
Harsha M S, «Analysis of vulnerabilities
in MQTT security using Shodan API and
implementation of its countermeasures
via authentication and ACLs,» IEEE,
2018.
[3] R. H. S. S. A.-r. C. f. C. S. F. o. I. S. &. T.
U. K. M. 4. U. B. M. Abdulrahman
Sameer Sadeq, «A QOS APPROACH FOR
INTERNET OFTHINGS (IOT)
ENVIRONMENT USING MQTT
PROTOCOL,» IEEE, 2018.
[4] A. S. A. S. C. R. C. o. E. B. I. Prabaharan
J, «Wireless Home Automation and
Security System using MQTT Protocol,»
IEEE, 2017.
[5] G. D. B. M. B. D. E. Ü. z. T. Özlem
YERL�KAYA, «Security of Message
Queue Telemetry Transport Protocol,»
IEEE, 2017.
[6] C. B. P. K. S. o. C. a. E. U. o. M. K. C. M.
U. Anurag Thantharate, «CoAP and
MQTT based Models to deliver
Software and Security Updates to IoT
Devices Over the Air,» IEEE, 2019.
[7] J. G. B. Z. T. Z. P. R. S. o. I. S. a. E. H. U.
o. S. a. T. S. 0. C. Min Huang, «The
Design and Implementation of Security
Defense System Based on Android,»
IEEE, 2017.
[8] I. N. C. L. Ousmane Sadio, «Lightweight
Security Scheme for MQTT/MQTT-SN,»
IEEE, 2019.
[9] F. D. R. A. F. S. Giuseppe Potrino,
«Modeling and evaluation of a new IoT
security,» IEEE, 2019.
[10] «An Extensible and Transparent Thingto-Thing Security Enhancement for
MQTT Protocol in IoT Environment,»
IEEE, 2019.
[11] L. V. D. o. E. a. A. U. o. P. P. I. Yanina
Protskaya, «Broker Bridging
Mechanism for Providing Anonymity in
MQTT,» IEEE, 2019.
[12] a. B. R. b. B. H. c. 1. 2. 3. D. o. E. E. S. o.
E. E. a. I. I. T. B. B. I. Syaiful Andy1,
«Attack Scenarios and Security Analysis
of MQTT Communication Protocol in
IoT System,» IEEE, 2017.
[13] K. V. R. R. D. E. a. C. E. D. B. M. U. G. I.
Malapati Bharath, «Implementation of
IoT Architecture for Intruder Alert
System using MQTT Protocol and
MEAN Stack,» IEEE, 2018.
[14] (. M. I. ROBERT R. JAKUBEK,
«Nonequivalent Quasi-Experimental
Study of Wireless Telecommunication
Traffic During Severe Winter Storms,»
IEEE, 2015.
[15] 2. L. S. L. V. R. G. C. R. 1. o. T. a. M. P. I.
o. L. P. 2. S. a. C. R. C. (. P. I. Roberto
Leal1, «MQTT flow signatures for the
Internet of Things,» IEEE, 2019.
[16] R. R. G. D. o. I. I. S. o. B. a. R. B. I. Suja P
Mathews, «Protocol Recommendation
for Message Encryption in MQTT,»
IEEE, 2019.
[17] K. K. C.-C. C. W. H. N. N. A. R. L. 7. R. 6.
R. H. S. P. H. C. T. R. SeongHan Shin, «A
Security Framework for MQTT,» IEEE,
2016.
[18] P. D. J. P. N. K. D. o. I. T. R. A. I. o. T. N.
N. M. I. Sowmya Nagasimha Swamy,
«Security Threats in the Application
layer in IOT Applications,» IEEE, 2017.