Caracterización del tráfico de dispositivos de IoT usados...

UNIVERSIDAD DE COSTA RICASISTEMA DE ESTUDIOS DE POSTGRADO

Caracterización del tráfico dedispositivos de IoT usados en residencias.

Trabajo final de investigación aplicada sometido a laconsideración de la Comisión del Programa de Estudios de

Posgrado en Computación e Informática para optar al grado ytítulo de Maestría Profesional en Computación e Informática

FABIO CHAVARRÍA JIMÉNEZ

Ciudad Universitaria Rodrigo FacioSan Pedro, San José, Costa Rica

Julio de 2018

Este trabajo final de investigación aplicada fue aceptado por la Comisióndel Programa de Estudios de Posgrado en Computación e Informática dela Universidad de Costa Rica, como requisito parcial para optar al grado ytítulo de Maestría Profesional en Computación e Informática

Dr. Juan José Vargas MoralesProfesor Director

Dra. Gabriela Marín RaventósDirectora

Programa de Postgrado en Computación e Informática

Dra. Gabriela Barrantes SliesarievaRepresentante del Decano

Sistema de Estudios de Posgrado

Ing. Fabio Chavarría JiménezSustentante

iii

Dedicatoria

Dedico este esfuerzo a mi Dios, quien me llena de bendiciones cada día y me hapermitido iniciar, desarrollar y culminar este proyecto con las limitaciones que se dieron.Bendito seas Señor. A mi esposa, todo el tiempo que hemos invertido en terminar estamaestría y el apoyo prestado. Bendito el día en que te conocí, te amo. A mi preciosohijo, que también ha sufrido con este proyecto. Crece como el hombre que Dios quiere,te amo. A mis padres que desde niño me formaron para ser la persona que hoy soy.

v

Agradecimientos

Agradezco de manera especial a mi profesor Guía el Dr. Juan José Vargas Moralesy la Dra. Gabriela Barrantes Sliesarieva, quienes me brindaron su valioso tiempo ysu guía para llevar a buen término el desarrollo de este trabajo. A la directora DraGabriela Marín Raventós por sus sabios consejos y apoyo y a todos los profesores de lamaestría que indirectamente aportaron para este TFIA a lo largo de la maestría: MScMBA Marta Calderón Campos, Dr. Ricardo Villalón Fonseca, Dra. Alexandra MartínezPorras, Lidia Arévalo Bravo y Msc.Richard Delgado.

vii

Índice general

Hoja de Aprobación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiDedicatoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vAgradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiÍndice General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiÍndice de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvÍndice de Cuadros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiÍndice de Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xixResumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiPalabras Clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

1. Introducción 1

1.1. Justificación de esta investigación . . . . . . . . . . . . . . . . . . . . . 21.2. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.2. Objetivo Específico 1 . . . . . . . . . . . . . . . . . . . . . . . . 51.3.3. Objetivo Específico 2 . . . . . . . . . . . . . . . . . . . . . . . . 51.3.4. Objetivo Específico 3 . . . . . . . . . . . . . . . . . . . . . . . . 61.3.5. Alcances y Limitaciones . . . . . . . . . . . . . . . . . . . . . . 6

1.4. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5. Resumen de Capítulos . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.6. Aporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Marco Teórico 11

2.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

ix

2.1.1. En Búsqueda de Políticas de Tráfico de Red Utilizables para Dis-positivos IoT en Redes de Consumidores . . . . . . . . . . . . . 12

2.1.2. Control de Seguridad y Privacidad a Nivel de Red para Disposi-tivos IoT del Smart-Home . . . . . . . . . . . . . . . . . . . . . 12

2.1.3. Monitoreo de Red IoT . . . . . . . . . . . . . . . . . . . . . . . 132.2. Aspectos Teóricos Requeridos . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1. Dispositivo IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2. Casa Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3. Captura de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3. Modelo de Interconexión de Sistemas Abiertos . . . . . . . . . . . . . . 172.3.1. Capa Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.2. Capa de Enlace de Datos . . . . . . . . . . . . . . . . . . . . . . 182.3.3. Capa de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.4. Capa de transporte . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.5. Capa de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.6. Capa de Presentación . . . . . . . . . . . . . . . . . . . . . . . . 202.3.7. Capa de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4. Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5. Herramientas de Análisis y Captura . . . . . . . . . . . . . . . . . . . . 232.6. Especificaciones Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.6.1. Cámara de seguridad Foscam modelo FI9821P V2 . . . . . . . . 262.6.2. Monitor de Bebés MyDlink Baby Camera modelo DCS-825L . . 262.6.3. Televisor Inteligente Samsung modelo UN40EH5300 . . . . . . . 262.6.4. Caja inteligente para televisión NexBox A95X . . . . . . . . . . 272.6.5. Iluminación Hue de Philips . . . . . . . . . . . . . . . . . . . . . 27

3. Metodología 293.1. Definición del capturador . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1. Acercamiento con un proxy . . . . . . . . . . . . . . . . . . . . 303.1.2. Acercamiento por medio de redirección de tráfico . . . . . . . . 313.1.3. Acercamiento con un servidor de Internet en la red . . . . . . . 323.1.4. Modificaciones para incluir un sistema de iluminación . . . . . . 343.1.5. Captura de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . 34

x

3.2. Escenarios de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.1. Escenarios Generales . . . . . . . . . . . . . . . . . . . . . . . . 363.2.2. Escenarios específicos de la cámara Foscam . . . . . . . . . . . . 373.2.3. Escenarios específicos del monitor de bebés . . . . . . . . . . . . 383.2.4. Escenarios específicos del Smart TV . . . . . . . . . . . . . . . 383.2.5. Escenarios específicos del Smart T.V. Box . . . . . . . . . . . . 39

3.3. Caracterización del tráfico . . . . . . . . . . . . . . . . . . . . . . . . . 39

4. Análisis de Resultados 414.1. Análisis de Tamaños de Paquetes . . . . . . . . . . . . . . . . . . . . . 41

4.1.1. Cámara de Seguridad Foscam . . . . . . . . . . . . . . . . . . . 424.1.2. Monitor de Bebés Dlink . . . . . . . . . . . . . . . . . . . . . . 434.1.3. Comparación de Dispositivos de Seguridad . . . . . . . . . . . . 444.1.4. Caja Inteligente para T.V. . . . . . . . . . . . . . . . . . . . . . 464.1.5. Televisor Inteligente . . . . . . . . . . . . . . . . . . . . . . . . 474.1.6. Comparación de Dispositivos de Info-Entretenimiento . . . . . . 484.1.7. Dispositivo de Iluminación Hue . . . . . . . . . . . . . . . . . . 494.1.8. Comparación General del Tráfico Total . . . . . . . . . . . . . . 50

4.2. Análisis por su Comunicación al Exterior . . . . . . . . . . . . . . . . . 534.2.1. Comunicación de la Cámara de Seguridad con diferentes países . 534.2.2. Comunicación del Monitor de Bebés con Diferentes Países . . . 564.2.3. Comunicación del Smart Box con diferentes países . . . . . . . . 614.2.4. Comunicación del Smart TV con diferentes países . . . . . . . . 634.2.5. Comunicación del Hue con diferentes países . . . . . . . . . . . 684.2.6. Comunicación con diferentes países de toda la Red IoT del Hogar 71

4.3. Consultas DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3.1. DNS Request de la Cámara Foscam . . . . . . . . . . . . . . . . 734.3.2. DNS Request del Monitor de Bebés . . . . . . . . . . . . . . . . 744.3.3. DNS Request del SmartBox . . . . . . . . . . . . . . . . . . . . 754.3.4. DNS Request del Smart T.V. . . . . . . . . . . . . . . . . . . . 764.3.5. DNS Request del Hue . . . . . . . . . . . . . . . . . . . . . . . . 774.3.6. Hallazgos respecto a DNS . . . . . . . . . . . . . . . . . . . . . 80

4.4. Tráfico de Subida y Bajada . . . . . . . . . . . . . . . . . . . . . . . . 81

xi

4.4.1. Tráfico de Subida y Bajada de la Cámara Foscam . . . . . . . . 814.4.2. Tráfico de Subida y Bajada del Monitor de Bebés . . . . . . . . 824.4.3. Tráfico de Subida y Bajada del Smart Box . . . . . . . . . . . . 834.4.4. Tráfico de Subida y Bajada del Smart T.V. . . . . . . . . . . . 844.4.5. Tráfico de Subida y Bajada del Hue . . . . . . . . . . . . . . . . 854.4.6. Revisión de Hallazgos . . . . . . . . . . . . . . . . . . . . . . . . 85

4.5. Protocolos de Comunicación . . . . . . . . . . . . . . . . . . . . . . . . 884.6. Protocolos utilizados por la Cámara de Seguridad Foscam . . . . . . . 894.7. Protocolos utilizados por el Monitor de Bebés Dlink . . . . . . . . . . . 904.8. Protocolos utilizados por el Smart Box . . . . . . . . . . . . . . . . . . 924.9. Protocolos utilizados por el Smart T.V. . . . . . . . . . . . . . . . . . . 954.10. Protocolos utilizados por Hue . . . . . . . . . . . . . . . . . . . . . . . 974.11. Resumen comparativo: Huella del dispositivo . . . . . . . . . . . . . . . 99

5. Conclusiones 1035.1. Trabajo Futuro y Recomendaciones . . . . . . . . . . . . . . . . . . . . 105

xii

Índice de figuras

3.1. Diseño del experimento por medio de un proxy. . . . . . . . . . . . . . 303.2. Diseño del experimento con port mirroring en el router . . . . . . . . . 323.3. Diseño del experimento con port mirroring en el router inalámbrico . . 333.4. Diseño del experimento utilizando un servidor de red aislado . . . . . . 333.5. Diseño final para la captura de tráfico . . . . . . . . . . . . . . . . . . . 35

4.1. Comportamiento del tamaño de paquetes para la cámara de seguridadFoscam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2. Comportamiento del tamaño de paquetes para el monitor de bebés . . . 444.3. Comportamiento del tamaño de paquetes para dispositivos de seguridad 454.4. Comportamiento del tamaño de paquetes para la caja inteligente para

T.V. o smart box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5. Comportamiento del tamaño de paquetes para el televisor inteligente . 474.6. Comportamiento del tamaño de paquetes para dispositivos de info - en-

tretenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.7. Comportamiento del tamaño de paquetes para el dispositivo de Ilumina-

ción Hue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.8. Comparación general del comportamiento del tamaño de paquetes por

dispositivo. De los cinco dispositivos analizados, los que presentan mayo-res frecuencias de aparición de paquetes son el smart T.V. y la cámaraFoscam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.9. Comparación general del comportamiento del tamaño de paquetes pordispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.10. Normalización de los valores en el histograma de todos los dispositivos . 524.11. Comunicación de la cámara de seguridad con diferentes países . . . . . 54

xiii

4.12. Comunicación de la cámara de seguridad con el exterior . . . . . . . . . 554.13. Cantidad de IP por País para el dispositivo Foscam . . . . . . . . . . . 554.14. Comunicaciones establecidas desde los Sistemas Autónomos . . . . . . . 574.15. Mapa de comunicaciones del monitor de bebés con el exterior . . . . . . 584.16. Comunicaciones del monitor de bebés con los diferentes países . . . . . 604.17. Cantidad de IPs involucradas en las comunicaciones por ciudad para el

monitor de bebés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.18. Mapa de comunicaciones al exterior para el smart box . . . . . . . . . . 614.19. Cantidad de paquetes en comunicación al exterior para el smart box . . 624.20. Cantidad de direcciones IPs por país para el smart box . . . . . . . . . 634.21. Comunicaciones establecidas con los Sistemas Autónomos desde el smart

box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.22. Comunicaciones del Smart T.V. con el Exterior . . . . . . . . . . . . . 654.23. Comunicaciones del Smart T.V. con el Exterior . . . . . . . . . . . . . 664.24. Cantidad de IPs por País para el smart T.V. . . . . . . . . . . . . . . . 664.25. Comunicaciones establecidas desde el smart T.V. con los Sistemas Au-

tónomos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.26. Comunicación del Dispositivo de Iluminación Hue con el Exterior . . . 694.27. Cantidad de paquetes en comunicación al exterior, por país desde el Hue 694.28. Cantidad de IPs por país en comunicaciones con el Hue . . . . . . . . . 704.29. Comunicaciones establecidas desde el Hue con los Sistemas Autónomos 714.30. Comunicaciones establecidas desde toda la red de IoT del hogar hacia

los diferentes países . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.31. Solicitudes DNS de la Cámara de Seguridad Foscam . . . . . . . . . . . 734.32. Solicitudes DNS de la Cámara de Seguridad Foscam separado por Dominios 744.33. Solicitudes DNS del Monitor de Bebé . . . . . . . . . . . . . . . . . . . 754.34. Solicitudes DNS del Monitor de Bebé separado por Dominios . . . . . . 764.35. Solicitudes DNS del Smart Box . . . . . . . . . . . . . . . . . . . . . . 774.36. Solicitudes DNS del Smart Box separado por Dominios . . . . . . . . . 784.37. Solicitudes DNS del Smart T.V. . . . . . . . . . . . . . . . . . . . . . . 784.38. Solicitudes DNS del Smart T.V. separado por Dominios . . . . . . . . . 794.39. Solicitudes de DNS del Hue . . . . . . . . . . . . . . . . . . . . . . . . 794.40. Solicitudes DNS del HUE separado por Dominios . . . . . . . . . . . . 80

xiv

4.41. Tráfico de Subida y bajada para la Cámara Foscam . . . . . . . . . . . 824.42. Tráfico de Subida y bajada para el Monitor de Bebés . . . . . . . . . . 834.43. Tráfico de Subida y bajada del Smart Box . . . . . . . . . . . . . . . . 844.44. Tráfico de Subida y bajada del Smart T.V. . . . . . . . . . . . . . . . . 854.45. Tráfico de Subida y bajada para el dispositivo de Iluminación Hue. . . 864.46. Histograma de comportamiento del tráfico downlink del televisor. . . . 874.47. Distribución de protocolos para la cámara de seguridad Foscam . . . . 894.48. Distribución de protocolos transportados en UDP para la cámara de

seguridad Foscam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.49. Distribución de protocolos para el monitor de bebés . . . . . . . . . . . 914.50. Distribución de protocolos UDP para el monitor de bebés . . . . . . . . 924.51. Distribución de protocolos TCP para el monitor de bebés. . . . . . . . 934.52. Distribución de protocolos para el smart box . . . . . . . . . . . . . . . 944.53. Distribución de protocolos UDP para el monitor de bebés. . . . . . . . 944.54. Distribución de protocolos TCP para el monitor de bebés . . . . . . . . 954.55. Distribución de protocolos para el smart T.V. . . . . . . . . . . . . . . 964.56. Distribución de protocolos TCP para el smart T.V. . . . . . . . . . . . 964.57. Distribución de protocolos para el dispositivo de iluminación Hue. . . . 974.58. Distribución de protocolos UDP para el dispositivo de iluminación Hue 984.59. Distribución de protocolos TCP para el dispositivo de iluminación Hue. 99

xv

Índice de tablas

2.1. Estructura del modelo de capas OSI . . . . . . . . . . . . . . . . . . . . 172.2. Especificaciones técnicas de los dispositivos. . . . . . . . . . . . . . . . 25

3.1. Direcciones IP de los dispositivos. . . . . . . . . . . . . . . . . . . . . . 313.2. Direcciones IP de los dispositivos en la red IoT-Monitor. . . . . . . . . 34

4.1. Resumen de longitud de paquetes por dispositivo. . . . . . . . . . . . . 504.2. Hallazgos presentados con el Televisor . . . . . . . . . . . . . . . . . . . 884.3. Resumen de la huella de los dispositivos analizados . . . . . . . . . . . 1004.4. Resumen de capturas para todos los dispositivos utilizados . . . . . . . 101

xvii

Índice de Abreviaturas

En este trabajo se utilizan las siguientes abreviaturas o acrónimos. Ordénelas alfa-béticamente.

IoT: Internet of ThingsECCI: Escuela de Ciencias de la Computación e InformáticaUCR: Universidad de Costa RicaICE: Instituto Costarricense de Electricidad y TelecomunicacionesOSI: Open System InterconectionTCP: Protocolo de Control de TransmisiónUDP: Protocolo de Datagrama de UsuarioSMTP: Simple Mail Transfer ProtocolTLS: Transport Layer SecuritySSL: Secure Sockets LayerDNS: Domain Name SystemPSPP: Software para análisis estadísticosT.V. Televisión

xix

Resumen

Esta investigación se basa en un experimento en el cual se observa un hogar queutiliza al menos cinco dispositivos con las características de IoT y clasificados en lastres categorías de mayor penetración en Costa Rica. Por medio de un dispositivo deintercepción de tráfico, se capturó toda la información para su análisis con el fin decaracterizar el tráfico de cada uno de ellos. La caracterización se hizo por medio decuatro aspectos: el tamaño de los paquetes, la cantidad de países en su comunicaciónal exterior, las consultas DNS y los protocolos utilizados.

Para llevar a cabo el experimento, se utilizó un servidor de internet que proporcionóuna red diseñada solo para interconectar los dispositivos por analizar. Por medio deun capturador de tráfico instalado en el servidor, se almacenó el tráfico en archivospcap, los cuáles fueron leídos con un analizador de protocolos. A partir de los archivospcap fue posible revisar cada uno de los paquetes de los elementos en la red y se logróidentificar las particularidades en la comunicación de cada uno ellos.

Palabras clave

IoT, privacidad, caracterización de tráfico, smart home.

xxi

Capítulo 1

Introducción

El concepto de Internet de las Cosas o IoT del inglés Internet of Things surgió en1999 en una presentación de Kevin Ashton en la cual se refiere a este concepto comola interconexión de objetos cotidianos con las redes de Internet y no como tecnología[Ash09]. Un dispositivo IoT se puede definir como un objeto cotidiano, capaz de conec-tarse a Internet y de reaccionar ante estímulos humanos o ambientales 1.

Como lo menciona P. Dorri, los dispositivos IoT proporcionan mucha informaciónsobre el usuario y su comportamiento [Dor17], por ejemplo, identificadores únicos einformación personal que permite el seguimiento en línea. El uso que se le da a estosdatos es una incertidumbre. Además, existe poco conocimiento, protección y controlpor parte del usuario con respecto al funcionamiento de la información que se entregay con quién está siendo compartida.

El uso de dispositivos móviles que permanecen conectados al Internet, sumado alos avances tecnológicos, provoca un impacto en la forma de vida de las personas. Losteléfonos celulares conforman un grupo de dispositivos IoT, que por sus característicasrecopilan información de los usuarios. Por ejemplo, datos de localización geográfica, his-toriales de búsquedas y navegación, conversaciones, contactos, redes sociales y demásfacilidades, conforma una posible fuente de riesgo, cuando en algún momento se hagauso de esa información sin el consentimiento de los usuarios.

1Definición tomada en consenso con el grupo investigador del proyecto 834-B7-268 Riesgos de pri-vacidad en dispositivos residenciales de Internet de las Cosas usados en Costa Rica"

1

En los hogares costarricenses, cada vez existen más dispositivos con estas caracte-rísticas. Su funcionamiento respecto al flujo de la información, es desconocido para lamayoría de usuarios. Los dispositivos de la tendencia Smart son considerados atracti-vos por los consumidores, además de que se comercializan indicando que las tecnologíasdiseñadas facilitan la vida de las personas en sus actividades diarias. En general, lapráctica expone que son pocas las redes domésticas que cuentan con seguridad. Incluso,la mayoría de usuarios, al instalar los dispositivos, aceptan condiciones que validan laentrega de datos privados y comparten información personal revelando comportamien-tos y patrones que ponen en riesgo la privacidad individual o hasta de su propio núcleofamiliar.

1.1. Justificación de esta investigación

La era del Internet y la movilidad han facilitado el crecimiento de dispositivos IoTalrededor del mundo. La falta de conocimiento y regulación del flujo de la informa-ción que transfieren estos dispositivos es lo que motiva el desarrollo del tema. Comoejemplo, un televisor inteligente permite muchas facilidades a la hora de preparar elentretenimiento familiar y personal. Proporciona sugerencias de qué programas o pelí-culas pueden interesar al usuario, interconecta con las redes sociales, permite controlarel televisor por medio de gestos, sin necesidad de manipular un control remoto, o pormedio de comandos de voz.

Cuando los consumidores compran dispositivos IoT domésticos, tienen un conoci-miento limitado sobre el tráfico que sus dispositivos están enviando a través de Internet.Tampoco se preocupan por lo vulnerables que son sus dispositivos para ser atacados.Los dispositivos de IoT tienen acceso a información personal confidencial [DT17], quelos usuarios conscientes no desean sea compartida. Además, los usuarios a menudo estándemasiado ocupados o carecen del conocimiento de dominio necesario para analizar decerca el tráfico de la red [DT17].

El usuario promedio está satisfecho con las características que le proporciona sutelevisor, pero no está consciente de que las sugerencias de películas requieren de una

2

recopilación y análisis de datos de los gustos y preferencias. Además, para poder con-trolar el televisor con gestos se requiere una cámara que lo está monitoreando; o paracontrolar por voz el televisor hay un micrófono que está grabando su voz, desconociendosi estos datos se comparten, con quién se comparten y en qué forma.

La importancia del desarrollo e implementación de este TFIA es poder categorizarel flujo de la información personal que envían estos dispositivos. Evidenciar las entida-des que reciben la información para entender los comportamientos de los dispositivosy así generar conciencia y un precedente ante esta revolución de IoT y sus posiblesconsecuencias.

1.2. Planteamiento del Problema

El Internet de las Cosas es un concepto que se refiere a la interconexión digital deobjetos cotidianos al Internet. Estos objetos además de tener un identificador único,tienen la capacidad de transferir datos a través de una red, sin requerir ninguna acciónhumana. Estos dispositivos ponen en riesgo la privacidad de las personas, divulgandoinformación con datos que puedan revelar las identidades de los usuarios y patrones decomportamientos.

Los dispositivos IoT generan, procesan e intercambian datos personales, así comoinformación confidencial. Por lo tanto, son el blanco de varios ataques cibernéticos[Dor17]. Para proteger la privacidad del usuario, los métodos existentes, a menudo re-velan datos ruidosos o datos incompletos, lo que potencialmente puede impedir quealgunas aplicaciones IoT ofrezcan servicios personalizados. Por consiguiente, IoT exigeuna protección de seguridad y privacidad ligera, escalable y distribuida [Dor17].

Los hogares residenciales están complementándose cada vez más con elementos lla-mados inteligentes. Estos dispositivos son instalados de manera despreocupada y sinninguna seguridad en la mayoría de los hogares. Evidenciar las comunicaciones que rea-lizan estos dispositivos, la información que comparten y los destinatarios de las mismas,son las preguntas base que motivan el desarrollo de este trabajo. Las mismas interro-gantes anteriores llevan implícita la dificultad de la privacidad y la anonimización de

3

la información. Es evidente el riesgo que conlleva el mantener una cámara de vigilanciaen la casa que esté intercambiando información de vídeo, actividad y sonido a travésde Internet.

Según [DeM17], los dispositivos IoT se comunican continuamente con servidoresfuera de la red doméstica. Sin embargo, los destinos son muy limitados, es decir sonde uso muy específico y mantienen comunicación constante con un rango de servidoresbastante limitado. Dispositivos como los streammers, echo y un bombillo inteligentehacen muchas solicitudes de DNS, pero son al mismo sitio siempre o a una cantidadmuy restringida de sitios que corresponden a los servidores en la nube de los mismosproveedores.

Parte de la problemática que existe con respecto al uso de dispositivos IoT en hoga-res residenciales es que en la red local no existen políticas de seguridad que restrinjan lascomunicaciones ni firewalls que bloqueen el tráfico. La solución que propone [DeM17]es asegurar la red por medio de ACLs o listas blancas de manera que no permita co-municación con algún otro sitio más que los identificados como seguros.

Esta aproximación de seguridad propuesta por los autores [DeM17] es útil, sin em-bargo, no asegura que los datos compartidos sean tratados como privados. Tampocose conoce qué hacen los proveedores del servicio con la información, ni cómo se trans-mite. Toda esta problemática es parte esencial de analizar con respecto a la seguridady privacidad de los usuarios y sus familias. En resumen, el problema que motiva eldesarrollo de la investigación es caracterizar el tráfico de los dispositivos IoT existentesen hogares costarricenses como una forma de evidenciar las posibles vulnerabilidades yhasta violaciones a la privacidad de las personas.

1.3. Objetivos

Para el desarrollo de la investigación se pretende seleccionar un grupo pequeño dedispositivos considerados IoT para analizar y caracterizar su tráfico. Como experimento,se va a capturar el tráfico recibido y generado de estos dispositivos para determinar con

4

quién comparten información que puede ser privada y cómo la comparten. Se proponenlos siguientes objetivos:

1.3.1. Objetivo General

Caracterizar el flujo de la información personal de distintos dispositivos IoT delhogar, con base en su tráfico de red.

1.3.2. Objetivo Específico 1

Identificar al menos 3 dispositivos de IoT del hogar disponibles en Costa Rica y quepuedan ser caracterizados.

Metas

La caracterización del tráfico de cada dispositivo se obtendrá mediante capturascompletas en la red de cada uno de los dispositivos. La identificación de los protocolosde comunicación permitirá la revisión del tráfico. Esta revisión consistirá en evidenciarlos entes externos con quienes cada dispositivo mantiene comunicaciones, la manera enque se envía la información y qué es lo que reciben estos destinos, con el fin de demos-trar el envío de información confidencial.

La selección de los dispositivos será restringida por las limitaciones del investigadorde poder disponer de todos ellos en su totalidad. Se espera tener una muestra represen-tativa basada en algún criterio o aproximación para identificar las áreas de clasificaciónde dispositivos con mayor uso en hogares residenciales costarricenses.


Diseñar una interfaz de hardware y software que permita el análisis del tráfico dered generado por dichos dispositivos.

Metas

El pilar fundamental para el desarrollo de la investigación es la obtención de losdatos. Para ello se debe utilizar un elemento capturador de tráfico que permita copiar

5

los paquetes transmitidos a Internet a través de la red local. Se considera satisfecho elobjetivo cuando se logre poner en funcionamiento un elemento que capture el tráficode entrada y salida de cada uno de los dispositivos, ya sea en la red interna o hacia elexterior.

El capturador debe ser un ente transparente al flujo de los paquetes y las comuni-caciones de los dispositivos. No puede alterar ni variar el flujo de ninguno de ellos, perodebe tener la capacidad de capturar todo el tráfico de cada uno de los dispositivos aanalizar.


Analizar el flujo de información de los dispositivos en un contexto específico.

Metas

La caracterización del tráfico es la meta presente para este apartado. Estar en lacapacidad de indicar los destinos a los cuáles cada uno de los dispositivos envía datosy poder indicar cuáles representan un riesgo a la privacidad es la mayor meta. Sinembargo, el cifrado de las comunicaciones puede llegar a limitar la identificación delos datos transmitidos. Encontrar patrones de comportamiento, aun sin poder ver lainformación enviada, será valido para asumir un potencial riesgo de vulnerabilidad a laprivacidad del usuario.

1.3.5. Alcances y Limitaciones

El proyecto y la realización del experimento se basan en el análisis del tráfico de losdispositivos seleccionados en el contexto de IoT. La implementación de un capturadorde tráfico es el elemento fundamental para el avance del trabajo. El aprendizaje y usode herramientas como Tshark son necesarias para la captura de tráfico, y el uso deun analizador de protocolos como Wireshark para el análisis y procesamiento de lospaquetes.

Como alcance del trabajo se debe categorizar el flujo de la información que envíanestos dispositivos, porque cada vez son más comunes en los hogares costarricenses y

6

evidenciar las entidades que reciben la información. Con esto se pretende exponer lascarencias existentes, en temas de privacidad, con el uso de dispositivos IoT en hogarescostarricenses. Esta investigación no pretende tratar temas de hacking ni técnicas pararomper la seguridad de los dispositivos.

La cantidad de dispositivos a utilizar y la disponibilidad de ellos es definitivamenteuna limitante para el desarrollo del trabajo. El objetivo es trabajar con al menos tresdispositivos.

El proyecto y el experimento realizado es limitado a los elementos que estén al al-cance del investigador. Se considera que los dispositivos involucrados en el experimentoson lo más representativos en el territorio nacional y en particular en la gran área me-tropolitana. La selección de los dispositivos se hizo tomando en cuenta los resultados deuna encuesta [RAG18] realizada en el reporte técnico RPT01-01-1312-2018 del proyecto834-B7-268 Riesgos de privacidad en dispositivos residenciales de Internet de las Cosasusados en Costa Rica".

1.4. Hipótesis

Dentro del experimento se trabajó con dispositivos variados, en las áreas de info-entretenimiento, seguridad e iluminación. Se considera que elementos como las cámarasy monitores de bebés son los dispositivos con más comunicación al exterior y por sunaturaleza son los que representan más riesgos al usuario. Sin embargo, esa comunica-ción es bastante limitada en destinos. Desde otra perspectiva, aparatos como los smarttv o smart tv boxes son elementos que tienen una comunicación mucho más variadacon entes externos. El caso de la iluminación se supuso que tenía un comportamientosimilar a las cámaras de seguridad, con comunicaciones puntuales hacia entes externos.

Las cámaras y monitores son objetos que por su naturaleza tienen un tráfico debajada muy pequeño, pero el de subida es alto comparativamente. Caso contrario vienea ser un televisor inteligente y un smart tv box, el cuál tiene mucho consumo de datos encomparación con la subida de información. La iluminación, por otro lado, se considera

7

que se comporta como un grupo intermedio a las dos agrupaciones anteriores y tienepoco tráfico de subida y bajada. Las tres agrupaciones contribuyen con la identificacióndel comportamiento en los hogares costarricenses y constituyen una brecha de privaci-dad latente.

Adicional al comportamiento de los dispositivos en la red, en ésta investigaciónse está tomando como hipótesis que los dispositivos IoT tienen acceso a informaciónprivada del usuario que es compartida con frecuencia a entidades externas. Esto poneen riesgo la privacidad de los usuarios y permite revelar patrones de comportamiento enlos hogares que ponen en riesgo la seguridad. Este supuesto facilita la posibilidad de serespiados. El simple hecho de compartir información y que el usuario no esté conscientecon quién ni para qué, marca un precedente sobre los riegos asociados.

1.5. Resumen de Capítulos

A continuación se explica la estructura del documento. El capítulo 2 enmarca ydelimita la investigación. Define conceptos básicos involucrados, así como, los antece-dentes de la investigación. Al mismo tiempo, proporciona las especificaciones técnicasde los dispositivos utilizados en la investigación. El capítulo 3 presenta la metodologíautilizada en la implementación del laboratorio y desarrollo de la investigación. Comoreferencia se indican situaciones presentadas durante el desarrollo y la toma de deci-siones involucrada en el desarrollo de la investigación. También delimita los escenariosanalizados en la caracterización de los flujos. El capítulo 4 muestra los resultados ob-tenidos y comentarios al respecto de los mismos. El capítulo 5 resalta los hallazgos delanálisis y propone un trabajo a futuro, como propuesta para continuar o ampliar eltema de esta investigación.

1.6. Aporte

El presente TFIA aporta conocimiento nuevo sobre el uso de la tecnología de IoTen los hogares costarricenses. Primero demuestra el uso de los dispositivos catalogadoscomo IoT y segundo, evidencia los riesgos presentes en el uso de ellos. Además generaun marco de referencia y las bases fundamentales para el desarrollo del proyecto de

8

investigación 834-B7-268 Riesgos de privacidad en dispositivos residenciales de Internetde las Cosas usados en Costa Rica". Al mismo tiempo, proporciona insumos y reco-mendaciones en el área de privacidad y seguridad en general.

Debido a que el tema de IoT es una tendencia actual, demostrar vulnerabilidades ytratar de concientizar a los usuarios sobre los riesgos de uso de los dispositivos con estascaracterísticas es en definitiva uno de los mayores aportes. Por otro lado, las recomenda-ciones en seguridad para el uso de estos elementos será otro de los pilares ya que el usocotidiano de los dispositivos IoT conlleva riesgos al usuario que no han sido presentados.

De forma específica, se genera un estudio por medio de la caracterización del tráficoque generan los dispositivos IoT más comunes en Costa Rica. Se demuestra su compor-tamiento con respecto a la comunicación hacia otros países y la forma en que establecenestos enlaces. El estudio se presenta por medio del análisis de metadatos a nivel IP yevidencia los riesgos a nivel de privacidad al que están expuestos los hogares de CostaRica.

9

Capítulo 2

Marco Teórico

El presente capítulo detalla el sustento teórico utilizado como parte de la investi-gación. La misma gira en torno a tres temas específicos: trabajo previo existente enel tema, la definición de los dispositivos por utilizar y la propuesta utilizada para sucaracterización.

2.1. Antecedentes

RERUM, un proyecto de la Unión Europea1, tiene como objetivo desarrollar unmarco que permita a las aplicaciones de IoT considerar mecanismos de seguridad y pri-vacidad de forma temprana en su fase de diseño, garantizando un equilibrio configurableentre la confiabilidad, que requiere datos seguros, confiables y precisos, y la privacidadque se vale de la minimización de datos para información privada, [Kom14]. RERUMha estado investigando en los últimos años para alcanzar su visión de seguridad, priva-cidad y confianza [Kom14] orientado a dispositivos de IoT. El Internet de las Cosas, laseguridad y la privacidad siguen siendo un desafío importante, principalmente debidoa la escala masiva y la naturaleza distribuida de las redes de IoT [Dor17].

En estudios anteriores se ha identificado la facilidad con la cual los dispositivos IoTson blanco de ataques. El poco tiempo que tiene el usuario para proteger su privacidado la falta de cocimiento son los principales índices que explican este problema [DT17].

1https://ict-rerum.eu/

11

2.1.1. En Búsqueda de Políticas de Tráfico de Red Utilizables

para Dispositivos IoT en Redes de Consumidores

Nicholas DeMarinis y Rodrigo Fonseca [DeM17] demuestran los comportamientospropios de los dispositivos IoT por medio de un experimento. El artículo expone unexperimento basado en el aseguramiento de redes domésticas en el entorno IoT. Pro-ponen el uso de listas blancas o reglas de acceso para minimizar el riesgo de envío deinformación a sitios peligrosos o al menos solo validar el envío a los sitios permitidos.Se basan en una hipótesis de que los dispositivos IoT se comunican continuamente conservidores fuera de la red local, sin embargo, los destinos son muy limitados. Hacen unarevisión de tráfico por 48 horas y encuentran que los dispositivos como los streammers,echo y un bombillo inteligente hacen muchos DNS request pero a un número bastantelimitado de sitios que corresponden a los servidores en la nube de los proveedores. Losautores, basados en esta característica, proponen el aseguramiento de la red por mediode listas de acceso.

2.1.2. Control de Seguridad y Privacidad a Nivel de Red para

Dispositivos IoT del Smart-Home

Vijay Sivaraman et al [SGV+15] hacen un análisis a nivel de red para mejorar laseguridad y privacidad. Se indica que, si bien es cierto, el uso de listas de acceso pue-den ayudar a mejorar la seguridad y privacidad de la red, no es la mejor opción. Siun atacante tiene acceso al dispositivo, también tendrá acceso a la lista y podrá en-mascararse como un acceso permitido. Los autores proponen asegurar la red en vezde buscar asegurar cada dispositivo. Esta propuesta puede aplicarse también a nivelde nube y mejorarse continuamente. El enfoque tiene validez debido a la heterogenei-dad de los dispositivos IoT, ya que, si se reúnen esfuerzos en asegurar cada uno de losdispositivos, nunca existiría una solución concreta. Además, se propone un dispositivollamado Security Management Provider o SMP. Este elemento sería el encargado deproporcionar la seguridad a nivel de red. Por ejemplo, el SMP se encargaría de agregarpor sí solo las políticas de acceso de cada uno de los dispositivos. Este nivel de asegu-ramiento se puede complicar un poco más, aplicando políticas dinámicas dependiendo

12

si hay miembros de la familia en el hogar o no. Por un lado, el SMP interactúa con elproveedor de servicios de Internet y por el otro, con el usuario y los dispositivos. Enresumen, los autores proponen un mecanismo de defensa que reconfigura de forma diná-mica la red, para proporcionar privacidad y seguridad mejorada en función del contexto.

2.1.3. Monitoreo de Red IoT

En el artículo [DT17] publicado en 2017, los autores proponen el uso de un dispo-sitivo intermedio que se utilizaría para conectar los dispositivos IoT directamente. Laaproximación a la seguridad la hacen de una forma similar a la propuesta en [SGV+15].A este elemento activo le llaman IoT Network Monitor. Su software estaría monitorean-do el tráfico en busca de vulnerabilidades en las siguientes tres dimensiones: detecciónde contraseñas predeterminadas, análisis de privacidad y detección de anomalías. Eldispositivo notifica al usuario de las amenazas de seguridad, proporciona sugerenciasproactivas para una nueva contraseña y además da instrucciones para ayudar a losusuarios a comprender qué hacer en respuesta a una amenaza. Se basa en tres aspectospara operar que se describen a continuación.

Inspección de ContraseñaLa inspección de contraseña funciona analizando el tráfico de manera que cuandose detectan dispositivos con contraseñas predeterminadas en una red doméstica,la herramienta cambia la contraseña a una cadena de 12 caracteres generada alea-toriamente y notifica al usuario de la nueva contraseña en la interfaz gráfica. Lainspección se realiza primero usando nmap, un escaner de red, y escanea direc-ciones IP buscando puertos abiertos y luego realiza ataques basados en el botnetMirai. Si logra realizar una conexión con éxito, entonces cambia la contraseña ynotifica el cambio.

Análisis de PrivacidadEn el análisis de privacidad, se interceptan datos de paquetes de dispositivos IoTconectados y se detecta información, potencialmente confidencial, que se está en-viando sin cifrar y notifica al usuario. También percibe filtraciones de información

13

confidencial en los metadatos de paquetes cifrados.

Detección de AnomalíasEn la detección de anomalías en la red, se utiliza FITBOT, del inglés Find IoTBotnets, para detectar tráfico de ataques de botnets en la red de dispositivos IoT.Recopila la cantidad de destinos a los que envía información, intervalos de tiempointernos regulares entre paquetes, cargas útiles de paquetes de pequeño tamañopara ataques y por medio de análisis de comportamiento es que puede deduciruna anomalía.

El común denominador de los artículos es dejar la evidencia de que los dispositivosIoT deben dejar de considerarse dispositivos confiables y más bien tratarse como unabrecha de privacidad y seguridad. Es necesario concienciar del problema, tanto al usuariocomo al fabricante del hardware y buscar soluciones dinámicas que proporcionen esaprivacidad tan escasa.

2.2. Aspectos Teóricos Requeridos

En esta sección se definirán varios conceptos clave y se delimitará su aplicación den-tro del experimento desarrollado.

Al referirse a sistemas inteligentes y el Internet de las Cosas, se debe conocer quelos dispositivos a los cuales se hace referencia deben cumplir con ciertas características.Se indican tres aspectos que deben cumplir2 :

1. Contener sensores y actuadores.

2. Capacidad de conectarse a Internet.

3. Capacidad de interactuar con personas.

2Aspectos discutidos por el comité investigador del proyecto 834-B7-268 Riesgos de privacidad endispositivos residenciales de Internet de las Cosas usados en Costa Rica"

14

Los sensores proporcionan la información. Se registran datos de localización pormedio de sensores de GPS, cámaras y micrófonos que registran vídeo y audio, termó-metros que registran la temperatura en salas hasta datos como iluminación y cambiosen la presión. La conectividad permite que todos esos datos medidos por los sensorespuedan ser enviados por medio de redes y compartidos a través de ellas. Con respectoa personas y procesos, todos estos datos son combinados en un flujo bi-direccional demanera que se integran datos, personas, procesos y sistemas para poder obtener el me-jor rendimiento o mejores insumos para el proceso de toma de decisiones.

La interacción de esos tres grupos está creando nuevos tipos de aplicaciones inte-ligentes y servicios. Entonces, estas aplicaciones tienen un marco de uso diverso3 y seclasifican según su entorno de la siguiente manera [Pos]:

1. Hogares.

2. Transporte.

3. Salud.

4. Edificios e infraestructuras.

5. Ciudades e industria

El ámbito de este documento se desarrolla en el primer grupo, considerado uno delos más comunes, de crecimiento descontrolado y poco seguro por parte de las mismaspersonas que conviven en un hogar. Esto se determina así por las mismas facilidadestécnicas y de costo que traen los dispositivos para ser interconectados a Internet dentrode las redes locales de una casa de habitación. Según Postcapes [Pos], los dispositivosIoT en casas son el mercado más amplio en la actualidad y se proyecta mayor crecimientopara los próximos años.

2.2.1. Dispositivo IoT

Como se indicó en el primer capítulo, los dispositivos IoT son objetos cotidianos quetienen la capacidad de conectarse a Internet y de reaccionar ante estímulos humanos

3Aspectos discutidos por el comité investigador del proyecto 834-B7-268 Riesgos de privacidad endispositivos residenciales de Internet de las Cosas usados en Costa Rica"

15

o ambientales. Algunos ejemplos comunes son: cámaras WiFi, televisores inteligentes,relojes inteligentes (smartwatch ), brazaletes inteligentes (wrist band), monitores de be-bés, asistentes inteligentes como Alexa 4, Siri5, Google Home6, entre otros y así comociertos electrodomésticos, por ejemplo, refrigeradoras, lavadoras y secadoras inteligen-tes.

2.2.2. Casa Inteligente

Se considera una casa inteligente aquella que cuente con dispositivos interconectadosa Internet que disponen de sensores y en algunos casos actuadores. Los dispositivos pue-den o no interactuar entre sí para proporcionar mayor “inteligencia” al hogar [GKN+17].Esta investigación se delimita en hogares costarricenses.

2.2.3. Captura de tráfico

La supervisión del tráfico es crucial para operar todas las redes IP por muchasrazones. Si el objetivo es monitorear amenazas de seguridad, solución de problemas oanálisis, se requiere una forma confiable de ver todo el tráfico. Independientemente delanalizador o de la solución que se elija, se debe decidir sobre un método para brindaracceso físico al equipo de monitoreo al tráfico de la red. Existen tres métodos paralograrlo [JM07]:

1. La instalación de un dispositivo pasivo, puerto de acceso de prueba o TAP (TestAccess Port).

2. Redirección de tráfico en un router hacia un supervisor, método conocido comoport mirroring

3. Híbrido de las dos anteriores.

La ventaja de la solución de redirección de tráfico es su costo, ya que esta carac-terística se incluye de forma gratuita con la mayoría de los switches administrablesdisponibles en el mercado, es relativamente fácil de usar y puede configurarse remota-mente. Estas ventajas indican por qué la técnica de duplicación de puertos ha sido un

4https://developer.amazon.com/es/alexa5https://www.apple.com/siri/6https://assistant.google.com/

16

método popular para recopilar trazas de paquetes para diversos fines [JM07].

Para este proyecto, se consideraba como la mejor opción el uso de port mirroring.Sin embargo, al no disponer de hardware que permita esta técnica se tuvo que recurrir auna cuarta opción, la cual fue la instalación de un dispositivo activo llamado capturadory el cual se explicará más adelante en el capítulo 3 de metodología.

2.3. Modelo de Interconexión de Sistemas Abiertos

Tanto las redes inalámbricas como las cableadas adoptan la pila de protocolos delmodelo de interconexión de sistemas abiertos, conocido como OSI del inglés Open Sys-tem Interconection [BR17]. Debido a que el desarrollo de la investigación y el experi-mento se basa en el análisis de deferentes capas de este modelo se considera necesarioexplicar el funcionamiento de cada una de ellas.

La Organización Internacional de Estándares ISO fue la entidad que planteó el mo-delo de siete capas [LLCZ11]. Muchos de los protocolos OSI ya no se utilizan pero lareferencia es algo básico para los temas de redes [Ruf08]. La estructura se describe enla Tabla 2.1 donde se explica un poco la unidad de datos de cada una de las capas y surespectiva función básica.

Tabla 2.1: Estructura del modelo de capas OSICapa Unidad de datos Función

Aplicación Datos Servicios de red a aplicacionesPresentación Datos Representación de los datos

Sesión Datos Comunicación entre los dispositivosde la red

Transporte Segmentos Conexión extremo a extremo yfiabilidad de datos

Red Paquetes Determinación de ruta y direccionamientoIP

Enlace de datos Frames Direccionamiento FísicoFísica Bits Señalización y transmisión binaria.

17

Varios protocolos y especificaciones se implementan en todas estas capas. Por ejem-plo, la capa de aplicación usa HTTP para entregar servicios web y FTP para una grantransferencia de archivos. También es compatible con SMTP para la transmisión decorreo electrónico. La capa de transporte usa TCP, para la entrega confiable de datos yUDP, para una transmisión más rápida sin preocuparse por la entrega. La capa de redadmite IP para la entrega de datos basada en direcciones IP e ICMP para la generaciónde mensajes de error. La capa física es responsable de las características de transmisiónfísica. Es responsable de la modulación, la codificación de línea, la corrección de erroreshacia adelante, la conmutación de circuitos y el medio de transmisión [BR17].

2.3.1. Capa Física

La capa física es el nivel más bajo del modelo OSI o la primera capa. Incluye losmedios físicos de red, como un conector de cable. Su función es enviar y recibir señalesque transportan datos. Proporciona la activación, mantenimiento, comunicación cercanaentre el punto final de propiedades mecánicas, propiedades eléctricas, característicasfuncionales y características del proceso [BR17]. Cada medio dispone de una señalizaciónúnica para representar los bits en las trama, por ejemplo, el cobre utiliza patrones depulsos eléctricos, la fibra óptica patrones de pulsos de luz y el inalámbrico patronesde transmisiones de radio. El objetivo de esta capa es codificar los dígitos binariosque representan las tramas de la capa de enlace de datos en señales y el de recibiry transmitir esas señales a través del medio físico disponible que los conecta a la red[Ruf08].

2.3.2. Capa de Enlace de Datos

La capa de Enlace de Datos, es la segunda capa del modelo OSI, tiene como objetivoproporcionar una transmisión confiable. Las funciones de la capa de enlace de datosson independientes de la red y sus nodos, y del tipo utilizado en la capa física. Algunosdispositivos de capa 2 son los routers, porque decodifican el frame y usan la informaciónpara enviar frames de datos al destinatario correcto [BR17]. La capa de enlace de datosre-empaqueta los datos en tramas y controla el acceso de las mismas al medio [Ruf08].

18

2.3.3. Capa de red

La función principal de la capa de red es completar la transmisión de paquetes dered entre los hosts. Recibe segmentos de datos desde la capa de transporte y por lacapa de red se añaden los datos de enrutamiento para enviarla al siguiente router pormedio de la mejor ruta a la red de destino [Ruf08]. La capa de red realiza la traducciónde la dirección de red en la dirección física correspondiente. La capa de red tambiénpuede controlar las funciones de interconexión [BR17]. Tiene a su cargo cuatro tareas,las cuales son direccionamiento de paquetes con una dirección IP, encapsulamiento,enrutamiento y desencapsulamiento. Un ejemplo de protocolo de red es el IP versión 4que es utilizado en la mayoría de las comunicaciones [Ruf08]

2.3.4. Capa de transporte

La capa de transporte es de las más importantes del modelo OSI [BR17]. Proporcionauna transferencia transparente de los datos entre los usuarios finales y proporcionafiabilidad en la transferencia de datos fiable hacia las capas superiores. El enlace selleva por medio de un control de flujo, segmentación y des-segmentación y el control deerrores. Algunos protocolos son orientados al estado y otros a la conexión, la capa detransporte se encarga de llevar un seguimiento a los segmentos y retransmitir los quefallen [Ruf08].

2.3.5. Capa de sesión

La capa de Sesión define cómo iniciar, controlar y finalizar una sesión, incluido elnúmero de horas de control y administración de dos vías para completar solo una partede un mensaje continuo que puede informar a la aplicación para que la capa de datossea continua. Es responsable de crear, administrar, terminar la sesión entre procesos.La capa de sesión también se usa para insertar puntos de verificación en los datos paralograr la sincronización de datos [BR17]. Manipula el intercambio de información parainiciar diálogos y mantenerlos activos, así como para reiniciar sesiones interrumpidas oinactivas durante un largo período [Ruf08].

19

2.3.6. Capa de Presentación

La función principal de la capa de presentación es gestionar el descifrado y el ci-frado de datos, como el procesamiento de contraseñas del sistema. Por ejemplo, FTPle permite seleccionar el formato binario para transmisión o ASCII [BR17]. Tiene tresfunciones principales, la primera es la codificación y conversión de datos de la capa deaplicación para garantizar que los datos del dispositivo de origen puedan ser interpreta-dos por la aplicación adecuada en el destino. La segunda es la compresión de los datosde manera que el dispositivo destino los pueda descomprimir. La tercera es el cifrado delos datos para su transmisión y descifrado de los datos al recibirlos en el destino [Ruf08].

2.3.7. Capa de Aplicación

La capa de aplicación es el nivel más alto de aplicaciones de software en red orien-tadas al usuario a través del diálogo directo con los usuarios. La capa de aplicaciónproporciona la interfaz entre las aplicaciones que utilizamos para comunicarnos y lared subyacente por la que se transmiten los mensajes. En pocas palabras, se encargade intercambiar datos entre los programas que se están ejecutando [Ruf08]. La funciónprincipal del software de capa de aplicación es la de proporcionar una interfaz parapermitir que los programas usen servicios de red. La capa de aplicación proporcionaservicios que incluyen transferencia de archivos, administración de archivos y el proce-samiento de la información por correo electrónico. Los protocolos de capa de aplicaciónincluyen: Telnet, FTP, HTTP, SNMP, etc [BR17].

2.4. Protocolos

En esta sección se detallan algunos de los protocolos más importantes por describirpara contextualizar el ambiente del experimento. Las capas de transporte y de aplica-ción son las que se van a profundizar en mayor detalle. Algunos conceptos como TCP,UDP, TLS, HTTP, HTTPS y DNS se describen se describen en los apartados siguientes.

20

1. TCP y UDP

Los protocolos TCP y UDP son ambos propios de la capa de transporte. Ges-tionan la comunicación de aplicaciones. Se diferencian entre sí en funcionalidadesespecíficas que cada uno de ellos implementa. UDP (Protocolo de Datagrama deUsuario) es similar en comportamiento a TCP excepto que es un protocolo no con-fiable y sin conexión [Lan15]. Los segmentos de comunicación en UDP se llamandatagramas y utilizan el esquema del mejor esfuerzo [Ruf08], es decir, se mandanlos paquetes sin la certeza de que serán recibidos. La aplicación de resolución denombres DNS, se controla por medio de UDP. Streaming de vídeo y voz sobre IPson otros ejemplos que utilizan UDP.

TCP (Protocolo de Control de Transmisión) es un protocolo importante de lacapa de transporte [Lan15]. Es orientado a la conexión. Tiene mayor complejidadrespecto a UDP porque añade funciones especificas como el control de la entregade segmentos en el mismo orden, control de flujo y entrega fiable.

El segmento TCP contiene una cabecera o header de 20 bytes que encapsula losdatos de la capa de aplicación. El segmento UDP solo utiliza 8 bytes. UDP adoptaun modelo de transmisión simple y no diálogos de handshaking como contrastea TCP [BR17]. Algunas aplicaciones pueden utilizar tanto UDP como TCP, porejemplo UDP permite que un DNS funcione mucho más rápido al responder lassolicitudes que si lo hiciera por medio de TCP. En contraste, algunas otras apli-caciones necesitan de mayor confiabilidad dada por TCP.

2. El protocolo de seguridad de la capa de transporte TLS

El protocolo de seguridad de la capa de transporte (Transport Layer Security),conocido como TLS, está diseñado para permitir que dos partes, un cliente y unservidor se comuniquen de forma segura a través de una red insegura. SSL o, Se-cure Sockets Layer es el predecesor de TLS [BR17]. En la investigación se suponeque al menos la mayor parte del tráfico sensible será encriptado y por eso existe

21

la necesidad de revisar el tema de los protocolos criptográficos.

El protocolo TLS proporciona un canal seguro implementado en Internet. Porejemplo, las conexiones entre los navegadores web modernos y los sitios web po-pulares están protegidas con HTTP sobre TLS, a esto se le conoce como HTTPS.

Con el aumento de las preocupaciones sobre la vigilancia masiva y la actividaddelictiva en Internet en Costa Rica [dT16], el uso de TLS se está volviendo len-tamente obligatorio para muchos casos de uso, incluida la Web [BBF+17]. Cadaconexión TLS comienza con un “apretón de manos” o hand shake que negocia laversión y otros parámetros del protocolo y luego ejecuta un intercambio de clavesautenticado.

3. HTTP y HTTPS

HTTP es un protocolo que se desarrolló en un principio para publicar y recuperarpaginas HTML y ahora se utiliza en sistemas de información distribuidos y decolaboración. HTTP es un protocolo de solicitud/respuesta [Ruf08]. Cuando uncliente envía una solicitud a un servidor por medio de un navegador web, el pro-tocolo define los tipos de mensaje que el cliente utiliza para solicita la página weby los mensajes para responder por parte del servidor. Los mensajes más comunesson los GET, POST y PUT. GET es una solicitud de datos por parte del cliente.POST y PUT se utilizan para enviar mensajes que suben datos a un servidorweb. Para el caso de este documento y en complemento al apartado anterior, seconsidera importante explicar en forma breve los conceptos y diferencias de estasdos versiones de protocolos.

HTTP no es un protocolo seguro, ya que los datos transmitidos en un POSTpueden ser interceptados y leídos. Lo mismo sucede con la respuesta del servidor.Para corregir este problema se utiliza HTTP sobre TLS y se conoce como HTTPS.De esta forma, HTTPS proporciona seguridad a la comunicación cifrando los

22

datos. Puede usar autenticación y encriptación para proteger los datos mientrasviajan del origen a su destino [BBF+17].

4. Sistemas de Nombres de Dominio DNS

DNS es un protocolo de la capa de aplicación [Ruf08]. Los nombres de dominiose hicieron para evitar el acceso web a destinos por medio de direcciones IP y ensu lugar permite que utilicen nombres. Cada uno de los dispositivos, por razo-nes naturales de los protocolos de comunicación, deberá en algún momento hacerconsultas de DNS. Es humanamente más sencillo recordar un nombre que unasecuencia de números. Esos nombres se denominan dominios y son el equivalentea la dirección numérica. El uso de nombres de dominio permite cambiar las direc-ciones numéricas sin que el usuario se vea afectado por ello.

Las comunicaciones del protocolo DNS se dan por medio del concepto cliente/ser-vidor [Ruf08]. Sin embargo, se ejecuta como un servicio. Cuando una aplicaciónde un usuario solicita la conexión con un elemento remoto por medio de un nom-bre, el cliente consulta al servidor para resolver el nombre como una direcciónnumérica [Ruf08].

Para la revisión de los protocolos de comunicación se necesita de herramientas quefaciliten la captura del tráfico y la lectura para su análisis. El detalle de estas aplica-ciones se explica en la siguiente sección.

2.5. Herramientas de Análisis y Captura

Para el análisis de los protocolos y otros datos de las comunicaciones se utilizaronvarias herramientas tanto para la captura como para la revisión de lo capturado. Selistan a continuación:

1. Wireshark y Tshark

Para la revisión del tráfico y análisis de paquetes capturados, se utilizarán dosanalizadores gratuitos y confiables en sus versiones gráfica y de línea de comandos.

23

Wireshark es un analizador de protocolos o Packet Sniffer de código abierto. Esde los más populares en la actualidad [GG17]. Cuenta con una interfaz gráfica,intuitiva y poderosa para el análisis de redes. Tshark, es equivalente a Wireshark,pero en su versión de línea de comando. Tanto uno como el otro son capaces decapturar y analizar paquetes en la red mostrándolos de una forma legible al serhumano.

En general, se pueden utilizar dos modos para capturar paquetes: promiscuo ymonitor. En el modo promiscuo, todos los datos de red son capturados, sin dis-criminar que estén destinados o no a un dispositivo capturador. En modo nopromiscuo o monitor, solo los datos destinados a un controlador particular a tra-vés de direcciones MAC se envían a la CPU, los paquetes restantes se descartan[GG17]. Ambas aplicaciones cuentas con muchas características que los hacen lospreferidos. Su capacidad de filtros es bastante alta y sus herramientas de análisisson poderosas, además tienen un gran equipo de desarrollo.

2. Software PSPP

Para el análisis descriptivo de los datos, se utilizó el sistema PSPP, el cuál es unaaplicación de software libre para sustituir al SPSS 7 (Statistical Package for theSocial Sciences), de ahí se origina el nombre PSPP, que invierte las siglas hacien-do referencia a que es lo mismo que la versión de paga 8. Se consideró el uso de laherramienta por ser sencilla y por permitir analizar conjuntos de datos complejosy de gran volumen. Esto fue necesario debido a que todas las capturas de datosascendieron a más del límite manejado por otras herramientas como Open Offi-ce o Microsoft Excel. PSPP posee la capacidad para manejar 30.000 columnas y30.000.000 de filas.

PSPP provee funciones para el acceso, gestión, preparación, análisis de datos ypresentación de informes de resultados, lo cual permitió la creación de histogramaspara la descripción de horas cargadas de más tráfico. Esto facilitó la deducciónde uso de los dispositivos durante el día y revelar los patrones de comportamiento.

7https://www.ibm.com/analytics/spss-statistics-software8https://www.gnu.org/software/pspp/

24

3. AWK

AWK es un lenguaje de programación de tipo script que corre sobre plataformasLinux/Unix. Tiene la capacidad de ejecutar muchas acciones con programas deunas pocas líneas. Está especialmente diseñado para leer y procesar archivos detexto por lo que resulta muy útil su uso combinado con otras utilidades del sistemaoperativo 9. Se aprovecharon las funcionalidades de awk junto con tshark paracrear scripts que permitieron la extracción de datos de cada una de las trazas yasí dejar sólo los datos que se necesitaban analizar, por ejemplo obtener el tamañode cada uno de los paquetes.

Adicional, al finalizar los análisis, se descubrió un software de nombre Steel CentralPacket Analizer, el cual ayudó a verificar los datos obtenidos de cada uno de los elemen-tos dispositivos utilizados. En la siguiente sección se dan las especificaciones técnicasde cada uno de los dispositivos.

2.6. Especificaciones Técnicas

En esta sección se detallan las especificaciones técnicas de cada uno de los dispositi-vos involucrados en el experimento. La Tabla 2.2 resume el tipo de dispositivo utilizado,marca y modelo de cada uno de ellos. En el anexo ?? se encuentran las fichas técnicascon información detallada de cada uno de los equipos utilizados.

Tabla 2.2: Especificaciones técnicas de los dispositivos.Dispositivo Marca Modelo

Cámara de Seguridad Foscam FI9821P v2Monitor de Bebés D-link DCS-825L

Televisor Inteligente Samsung UN40EH5300Caja Inteligente para TV NexBox A95X

Iluminación Hue Philips 9290011369B

En el Apendice se encuentran las fichas técnicas completas para cada uno de losdispositivos utilizados. Se detallan tanto aspectos técnicos del equipo como detalles de

9https://www.gnu.org/software/gawk/manual/gawk.html

25

las capturas de tráfico.

2.6.1. Cámara de seguridad Foscam modelo FI9821P V2

La cámara de seguridad se basa en el protocolo HTTP con CGI (Common GatewayInterface). El programa CGI recibe datos de formularios HTTP por medio de la entra-da estándar a través de variables de entorno. Cuenta con sensores de movimiento, luzy sonido, y puede ser manipulada desde una red externa por medio de Internet paramover su ángulo de visión. Permite la comunicación por audio en forma bidireccional 10.

Cuenta con una aplicación para Android y Apple la cual le permite controlar yconfigurar cualquier parámetro de la cámara, desde el modo nocturno, el ángulo devisión y hasta la calidad del vídeo a transmitir.

2.6.2. Monitor de Bebés MyDlink Baby Camera modelo DCS-

825L

EL monitor de bebés myDlink baby es una cámara que cuenta con sensores demovimiento, sonido, luz y temperatura. Permite el intercambio de audio en forma bidi-reccional. Por medio de una aplicación instalada en dispositivos móviles como Androidy Apple es posible controlar la cámara y establecer umbrales de sensibilidad para enviaralertas. También es posible realizar todas estas funciones desde una PC por medio deuna página web 11.

2.6.3. Televisor Inteligente Samsung modelo UN40EH5300

Es un televisor inteligente de una pantalla de 40 pulgadas. A pesar de ser un smarttv es un modelo un poco obsoleto para 2018 12. Cuenta con conexión cableada e inalám-brica. Para el experimento se utilizó únicamente la red inalámbrica.

10http://foscam.us/contactus.html/11www.dlikn.com12https://www.samsung.com/latin/

26

2.6.4. Caja inteligente para televisión NexBox A95X

La smart box Nexbox es un dispositivo con sistema operativo android 6.0 y cuentacon capacidad de conexión cableada tanto como inalámbrica. En el experimento seutilizó solo la red wifi. La función que tiene es proporcionar la inteligencia que otrostelevisores convencionales no tienen y permitir la navegación por Internet y uso deaplicaciones como Youtube, Netflix, Cuevana y la visualización de canales de tipo IPTVgratuitos 13.

2.6.5. Iluminación Hue de Philips

El sistema de iluminación Hue de Philips permite al usuario controlar de formainalámbrica el sistema de iluminación en el hogar y consiste en un puente Ethernet ha-bilitado que recibe los comandos de la aplicación del usuario y los comunica de manerainalámbrica a los bombillos configurados mediante el protocolo de enlace ZigBee-Light14. El intercambio de datos entre la aplicación y el puente es a través de comandosHTTP y no está cifrado, por lo que un espía puede deducir fácilmente las operacionesque el usuario realiza en el foco [SGV+15]. Para el desarrollo de la investigación el pro-tocolo de comunicación entre los bombillos y la caja de control no se tomará en cuenta.

En el siguiente capítulo se explicará la metodología planteada para el uso de cadauna de las herramientas aplicadas a los dispositivos. Se plantea una estructura de redpara aislar cualquier ente externo de las comunicaciones de cada uno de los equipos aanalizar. Todos los dispositivos, o al menos su gran mayoría, estuvieron funcionandoparalelamente y su tráfico fue capturado por el elemento denominado capturador.

13www.tvboxforum.com14https://www2.meethue.com/en-us

27

Capítulo 3

Metodología

La primera tarea que se realizó en la investigación fue seleccionar al menos tresdispositivos IoT que estuviesen al alcance de los hogares costarricenses. Se estudió sufuncionamiento por medio del fabricante y se familiarizó con los protocolos que utili-za. La selección de los dispositivos se hizo tomando en cuenta los resultados de unaencuesta realizada en el reporte técnico RPT01-01-1312-2018 del proyecto 834-B7-268Riesgos de privacidad en dispositivos residenciales de Internet de las Cosas usados enCosta Rica".

Una vez seleccionados y estudiados, se generaron varias propuestas de diseño deuna interfaz de hadware y software la cual se denominó capturador. El capturador sedesarrolló en un equipo con un sistema operativo que agregara cierto nivel de seguridadante ataques, para que no se viesen alterados los datos recolectados. Se le proporcio-nó la capacidad para recolectar el tráfico para permitir el análisis. Posteriormente, secategorizaron los resultados obtenidos en términos de flujo de información personal yentidades que generan o reciben dicha información según los escenarios propuestos.

3.1. Definición del capturador

El capturador se diseñó para ser un elemento de red el cual, de forma transparente atoda la capa de red de dispositivos, pudo capturar tráfico bidireccional de cada uno deforma confiable. Contó con la capacidad de capturar el tráfico de subida y bajada com-pleto de cada uno de los elementos que se caracterizaron. En las siguientes subsecciones

29

se describen los diferentes acercamientos diseñados para lograr el objetivo.

3.1.1. Acercamiento con un proxy

En un principio se manejó la idea de utilizar un servidor proxy. Se implementó demanera que el proxy estuviera en la misma red local y a cada uno de los dispositivospor analizar se les modificaría el default gateway con la IP del proxy. Se configurósquid como proxy transparente para la re-dirección del tráfico de todos los elementosen estudio (ver Figura 3.1).

Figura 3.1: Diseño del experimento por medio de un proxy. En la imagen se muestraque el tráfico con las líneas verde de etiqueta 1 y 2 sí pasan por el proxy, pero el tráficocon la línea azul punteada con etiqueta 3 no iba a ser visto por el proxy

El uso del proxy no fue satisfactorio ya que todo el tráfico de salida de los dispo-sitivos fue enrutado por medio del proxy. El problema que se presentó y la razón porla cual se tuvo que descartar fue porque el tráfico de entrada no pasaba por el proxy yno podía ser capturado. En la Figura 3.1 se esquematiza el problema donde se muestracon las lineas continuas identificadas con 1 y 2, cómo el tráfico de salida viaja hacia elrouter, de ahí al proxy y después retornaba al router para salir a Internet. El tráficode entrada, identificado con la línea punteada y con la etiqueta 3, era el que invalidaba

30

la captura, ya que pasaba directamente de Internet al router y de ahí al dispositivo sinpasar por el capturador. La configuración utilizada se muestra en la Tabla 3.1).

Por la situación anterior, el capturador no cumplió con las condiciones necesariaspara capturar el tráfico completo y poder estudiar los paquetes de forma correcta. Fuenecesario replantear la configuración. Se consideró que lo ideal era realizar una copiadel tráfico que pasa por el router en la red inalámbrica y enrutarlo al capturador. Estose define en la siguiente sección.

Tabla 3.1: Direcciones IP de los dispositivos.Dispositivo IP GatewayFOSCAM 192.168.100.112 192.168.100.115

D-Link Baby 192.168.100.94 192.168.100.115Smart TV 192.168.100.6 192.168.100.115

Proxy 192.168.100.115 192.168.100.115Router 192.168.100.1 Internet

3.1.2. Acercamiento por medio de redirección de tráfico

Debido al problema presentado con el uso del proxy, se hizo un re-diseño y se con-cluyó que lo menos invasivo en la red es recurrir al uso de re-dirección de tráfico. Eltérmino en inglés utilizado para ésta técnica es port mirroring. El objetivo fue utilizarel port mirror en el switch de Internet provisto por el proveedor del servicio. De estamanera, se conectaría el servidor que iba a tener la función de capturador, en el puertode escucha (port mirror) para recibir todo el tráfico y capturar los paquetes. En laFigura 3.2 se proporciona un ejemplo de lo planteado, donde el capturador debía serconectado al port mirror del router, como se muestra en la línea 2 y el tráfico de cadauno de los dispositivos, por ejemplo la línea 1, es copiado hacia el capturador.

Nuevamente se presentó otro problema. El switch del router provisto por el pro-veedor de Internet no cuenta con la capacidad de realizar el port mirror. De nuevo setuvo que considerar un cambio en el diseño e incluir un router inalámbrico para in-tentar hacer el espejo del tráfico, como se muestra en la Figura 3.3. Sin embargo, los

31

routers con que se contaron para el diseño del experimento tampoco tuvieron la posibili-dad de realizar esta configuración por lo que se tuvo que desechar el diseño una vez más.

Figura 3.2: Diseño del experimento con port mirroring en el router. No se pudo imple-mentar de forma efectiva debido a limitaciones en el hardware

3.1.3. Acercamiento con un servidor de Internet en la red

Como consecuencia de no poder utilizar la estrategia del port mirorring se ideó eluso de un servidor de Internet dentro de la red. Se configuró un servidor en Linux paraser proveedor del servicio de Internet de una red inalámbrica segura, destinada única-mente para los dispositivos IoT seleccionados. De esta manera el servidor de Internet,en una forma muy conveniente, fue el mismo capturador de tráfico. En la Figura 3.4se muestra como todos los dispositivos a utilizar se configuran para utilizar una redsecundaria que proporciona el servidor de Internet, que es al mismo tiempo el gatewayde salida de toda la red.

El uso de este servidor permite capturar con seguridad todo el tráfico trasegadopor cada uno de los dispositivos y no consumir procesamiento extra en el mismo routercomo se hacía en los casos anteriores. La ventaja de este diseño fue que se logró aislar

32

Figura 3.3: Diseño del experimento con port mirroring en el router inalámbrico. No sepudo implementar de forma efectiva debido a limitaciones en el hardware

Figura 3.4: Diseño del experimento utilizando un servidor de red aislado. En este diseñoel capturador y el servidor de Internet son el mismo elemento y proveen de una redinalámbrica a todos los dispositivo.

33

los dispositivos de la red del hogar que en realidad es algo deseable en este tipo deelementos. Sin embargo, es bien sabido que por falta de conocimiento o presupuesto,en la mayoría de los hogares se hace la configuración bajo una única red. Para elexperimento se configuró una red privada de dispositivos, aislada de la red de usogeneral. Por consecuencia se volvió a configurar cada uno de los dispositivos para utilizarsolo esa red. La configuración que se utilizó en con este diseño se muestra en la Tabla3.2. Se puede observar como el capturador es un elemento intermedio entre la red localy la de los dispositivos IoT.

Tabla 3.2: Direcciones IP de los dispositivos en la red IoT-Monitor.Dispositivo IP GatewayFOSCAM 10.42.0.47 10.42.0.1

D-Link Baby 10.42.0.148 10.42.0.1Smart Box 10.42.0.13 10.42.0.1Smart TV 10.42.0.153 10.42.0.1

Hue 10.42.1.210 10.42.1.1Capturador 10.42.0.1 y 10.42.1.1 192.168.100.1

Router 192.168.100.1 Internet

3.1.4. Modificaciones para incluir un sistema de iluminación

El sistema de iluminación Hue de Philips fue agregado después de los primeroselementos que se empezaron a capturar y analizar. Debido a que la caja de controlrecibe los comandos por HTTP en forma inalámbrica por medio del protocolo ZigBee,y el tráfico de la caja central utiliza un cable UTP como medio físico de transporte,se tuvo que modificar una vez más la red. En este caso, se modificó la conexión comose muestra en la Figura 3.4 para conectar el puente Hue y poder capturar el tráficoenviado a la red cableada hacia el centro de mando del Hue. El diseño final se muestraen la Figura 3.5.

3.1.5. Captura de tráfico

El capturador aprovecha el sistema operativo Linux para capturar el tráfico pormedio de tshark. Debido a que las capturas de tráfico se hacen con tiempo indefini-do dentro del experimento, la generación de archivos de captura puede llegar a crear

34

Figura 3.5: Diseño final para la captura de tráfico. Se modifica la forma de conexión alInternet y se hace de forma inalámbrica para utilizar la interfaz cableada para el puentedel dispositivo de iluminación.

archivos de varios GB de tamaño que los vuelven un poco difíciles de revisar con unanalizador de protocolos, al menos los de interfaz gráfica de Wireshark. Por esta ra-zón se utiliza la opción de limitar el tamaño de las archivos con la opción -b [Fou18].De esta manera, al generar las capturas de tráfico de forma ininterrumpida por va-rios días se van creando archivos de un tamaño definido que automáticamente se lesda un consecutivo a la hora de guardarlos en disco. El comando utilizado es el siguiente:

tshark -i any -b filesize :20000 -f host "<ip del dispositivo >" -w <ar-chivo.pcap >

Se utilizó una línea del comando anterior para cada uno de los dispositivos en lared. De esta manera se generan archivos diferenciados por cada uno de los dispositivosutilizados y se incluyó en un script de bash.

tshark -i any -b filesize :20000 -f "host 10.42.0.47" -w /home/fo/IoT/-

35

Foscam.pcap &tshark -i any -b filesize :20000 -f "host 10.42.0.13" -w /home/fo/IoT/-SmartBox.pcap &tshark -i any -b filesize :20000 -f "host 10.42.0.153" -w /home/fo/IoT/-SmartTV.pcap &tshark -i any -b filesize :20000 -f "host 10.42.0.148" -w /home/fo/IoT/-BabyMonitor.pcap &

3.2. Escenarios de estudio

En esta sección del documento se presenta la estructura con la cual se llevará acabo el estudio de las capturas de datos hechas en el experimento por medio de unanalizador de protocolos. Para el análisis de paquetes se utilizará la ultima versión desoftware de Wireshark y Tshark disponible. Se plantearon escenarios del experimentosegún las siguientes subsecciones.

3.2.1. Escenarios Generales

Como parte del experimento se proponen varios escenarios de forma general de ma-nera que se aplique a todos los dispositivos estudiados.

Dispositivo Apagado (stand-by)Se propone ver si existe algún comportamiento del dispositivo mientras está stand-by y conectado a la red. El dispositivo debe estar conectado a la red eléctrica, elwifi configurado pero apagado. Algunos dispositivos pueden mantener una comu-nicación residual constante.

Dispositivo Encendido con InternetEste sería el escenario normal para cada uno de los elementos en pleno funciona-miento y con la conexión a la red necesaria. Bajo este esquema es que en seccionesposteriores se amplían mayores escenarios de revisión y análisis.

Dispositivo Encendido sin InternetSe propone también utilizar un escenario en el cual el dispositivo está funcional

36

pero tiene la singularidad de no tener acceso a la red Internet, solo a la red local.Se espera ver paquetes constantes de intento de conexión. El funcionamiento deldispositivo en la red local debería seguir sin problemas.

Análisis de TráficoPara el análisis de tráfico se espera revisar los casos de bytes de subida y bajadapara cada uno de los dispositivos. Es de esperar que el tráfico de bajada seabastante alto para los elementos como el televisor y la smart box pero, el debajada sea bastante reducido en comparación. Caso contrario para los elementosde vigilancia como la cámara y el monitor de bebes que, se espera que los bytes desubida sean los más altos respecto a los de bajada. Se pretende poder caracterizarlos sitios externos a los cuales se establece cierta comunicación cada uno de losdispositivos y los países relacionados.

Más específico, se realizarán escenarios acorde con las funcionalidades propias decada uno de los dispositivos. Esto permitirá caracterizar de una mejor forma la comu-nicación de cada uno de ellos. Los escenarios se describen a continuación.

3.2.2. Escenarios específicos de la cámara Foscam

Por las características del elemento, se plantean tres aspectos de revisión de sutráfico. El aparato cien por ciento operable con varios de sus sensores y funcionalidadesapagadas o encendidas. Se debe tomar en cuenta la comunicación hacia el exterior y losprotocolos utilizados. Se definen los siguientes casos:

Dispositivo operando sin generación de alarmasEn este caso el dispositivo funciona sin ninguna notificación hacia el cliente. Seanalizará si los sensores pueden seguir transmitiendo información, dónde y cómola envía.

Dispositivo operando con generación de alarmasPara este escenario es claro que los sensores sí están haciendo mediciones y obte-niendo datos del entorno. De la misma manera se debe analizar la transmisión dedatos, el método y los destinos.

37

Dispositivo operando con generación de alarmas y servicio en la nubeEl escenario anterior se amplía utilizando características propias del dispositivocomo lo es guardar vídeo en la nube por períodos definidos.

3.2.3. Escenarios específicos del monitor de bebés

Por las características del elemento, se plantean dos aspectos de revisión de su tráfico.El dispositivo funcionando al cien por ciento con varios de sus sensores y funcionalidadesapagadas o encendidas. Se debe tomar en cuenta la comunicación hacia el exterior, superiodicidad y los protocolos utilizados. Se definen los siguientes casos:

Dispositivo operando sin generación de alarmasEn este caso el dispositivo funciona sin ninguna notificación hacia el cliente. Seanalizará si los sensores pueden seguir transmitiendo información, dónde y cómola envía.

Dispositivo operando con generación de alarmasPara este escenario es claro que los sensores sí están haciendo mediciones y obte-niendo datos del entorno. De la misma manera, se debe analizar la transmisión dedatos, el método y los destinos al igual que se realizó con la cámara de vigilanciaFoscam.

3.2.4. Escenarios específicos del Smart TV

Por las características del televisor, se plantean dos aspectos de revisión de su com-portamiento. El dispositivo en funcionamiento normal con y sin sus aplicaciones devídeo en demanda.

Dispositivo operando en modo normalEl televisor debe estar con la interfaz inalámbrica configurada pero, no debe estarejecutando ninguna aplicación tipo Netflix. Se debe analizar si existen intentos deconexión a Internet o envío de información fuera de la red.

Dispositivo operando con aplicaciones de vídeo streaming El televisordebe estar funcionando con una aplicación de vídeo por Internet. Para este caso

38

y por las limitantes del dispositivo será utilizando Netflix. Se debe analizar elcomportamiento del tráfico en este caso y los puntos de comunicación al exterior.

3.2.5. Escenarios específicos del Smart T.V. Box

Para este dispositivo se tomará en cuenta prácticamente los mismos escenarios pro-puestos para el televisor. El dispositivo debe estar en funcionamiento normal con y sinsus sus aplicaciones de vídeo en demanda en ejecución.

Dispositivo operando en modo normalEl smart box La caja debe estar con la interfaz inalámbrica configurada pero, nodebe estar ejecutando ninguna aplicación tipo Netflix o Youtube. Se debe analizarsi existen intentos de conexión a Internet o envío de información fuera de la red.

Dispositivo operando con aplicaciones de vídeo streamingEl smart box debe estar funcionando con una aplicación de vídeo por Internet.Para este caso se utilizará sólo un escenario: con Netflix. Se debe analizar elcomportamiento del tráfico en este caso y los puntos de comunicación al exterior.

3.3. Caracterización del tráfico

Según se discutió en el grupo investigador del proyecto 834-B7-268, mencionado an-teriormente, la caracterización del tráfico se llevará a cabo por medio de cinco análisisen los escenarios anteriores. El tamaño de los paquetes utilizados por cada dispositivo,la comunicación al exterior, las consultas de DNS y el tráfico de subida y bajada forma-rán parte de la caracterización que se generará para cada dispositivo. Como resultado,la unión de los cinco estudios se denominará la “huella” de cada dispositivo. Esta huellaserá, para futuros estudios, un marco de referencia en el cuál se podrá hacer la com-paración de tráfico de cualquier dispositivo sin conocer su origen ni función y permitirconcluir si pertenece a sistemas de seguridad, info-entretenimiento o iluminación.

Tamaño de los paquetesEste análisis consiste en clasificar todo el tráfico capturado de cada uno de los

39

dispositivos y cuantificarlos según el tamaño de los paquetes. Se establecerá unaagrupación de paquetes igual para todos los dispositivos y por medio de gráficosserá posible generar una distribución de frecuencia de paquetes única para cadadispositivo de manera que sirva como un identificador de los dispositivos en cadasubgrupo de dispositivos IoT.

Comunicación al exteriorUn segundo análisis consistirá en la revisión exhaustiva de los direccionamientosIP de cada uno de los dispositivos. Separar el tráfico local del exterior y podergeoreferenciar cada una de las IPs por país y cuidad si es del caso. La cantidadde países destino será una aspecto más sumado a la caracterización de tráfico delos dispositivos. Esto podría indicar un riesgo a la seguridad y privacidad.

Consultas DNSLa cantidad y frecuencia de solicitudes de resolución de nombres formará partedel análisis completo de cada dispositivo. Por medio de la cantidad de consultasa nombres específicos se buscará encontrar patrones de comportamientos que re-presenten algún riesgo de la privacidad.

Tráfico de subida y bajadaLa cantidad de tráfico presente, tanto en subida como en bajada y con referenciael dispositivo en sí, será otro de los aspectos por analizar y comparar. Para esteestudio se tomará en cuenta la cantidad de bytes transmitidos desde y hacia eldispositivo y se cuantificará en dos gráficas por aparato.

Protocolos de comunicaciónPor último, se tomará en cuenta la revisión de los protocolos utilizados para sufuncionamiento. Se cuantificará protocolos a nivel de transporte y de aplicacióny será parte de las características del tráfico de cada uno de los dispositivos.

40

Capítulo 4

Análisis de Resultados

Esta sección contiene una explicación amplia sobre los resultados obtenidos median-te los experimentos y la caracterización que se buscó. Se hace una explicación uno a unode los dispositivos, luego se comparan entre sí según su categoría y a forma de resumense hace la comparación de todos los elementos como parte de un todo.

4.1. Análisis de Tamaños de Paquetes

En este apartado se hace una caracterización del tráfico de los dispositivos según sulongitud de paquetes por el tiempo de duración de las capturas realizadas de su tráfico.El análisis se hace en un hogar costarricense bajo operación normal como parte deldiseño del experimento. No se tiene el tráfico controlado en un laboratorio y más bienes un caso de uso real para cada uno de los dispositivos.

Como parte de la caracterización de los dispositivos por el uso de tamaños de paque-tes en sus comunicaciones, se utilizó una agrupación de tamaños mostrada en la lista acontinuación. El tamaño de cada uno de los grupos es el mismo utilizado por Wiresharky generado por medio del comando packet lenghts dentro del menú de estadísticas.

GRUPO A: paquetes entre los tamaños de 0-19 bytes

GRUPO B: paquetes entre los tamaños de 20-39 bytes

41

GRUPO C: paquetes entre los tamaños de 40-79 bytes

GRUPO D: paquetes entre los tamaños de 80-159 bytes

GRUPO E: paquetes entre los tamaños de 160-319 bytes

GRUPO F: paquetes entre los tamaños de 320-639 bytes

GRUPO G: paquetes entre los tamaños de 640-1279 bytes

GRUPO H: paquetes entre los tamaños de 1280-2559 bytes

GRUPO I: paquetes entre los tamaños de 2560-5119 bytes

GRUPO J: paquetes entre los tamaños de 5120 y más bytes

El análisis del tamaño de los paquetes es útil para la caracterización, debido a queno depende del cifrado de la información. Se utilizaron como principales medidas eltamaño de cada paquete y la frecuencia de aparición. El resultado de este análisis re-presentará una huella de cada uno de los dispositivos, de manera que será identificabley comparable con otra para su clasificación.

4.1.1. Cámara de Seguridad Foscam

La cámara de seguridad Foscam no utilizó paquetes pequeños menores de 40 bytes,pero tampoco en el orden de los 2560 bytes o mayores. La concentración más alta deconteo de paquetes fue en el rango de tamaño comprendido entre los 320 a 639 bytesinclusive correspondiente al grupo F, para un valor máximo mayor a los dos millonesen el conteo. En la Figura 4.1, que se resumen en la Tabla 4.1 de una sección posteriordel documento en la página 50, se muestra de forma gráfica y numérica el comporta-miento. Se aprecia como la cámara utiliza en su mayoría paquetes del rango indicado ylos comprendidos entre los 80 a 159 bytes, pertenecientes al grupo D.

Se infiere que la cámara de seguridad opera de forma práctica, en dos rangos delongitud de paquetes, donde su segundo pico máximo corresponde a un 38% del tráficomáximo capturado y mostrado en la Figura 4.1. De esta manera, el tráfico de la cámara

42

Figura 4.1: Comportamiento del tamaño de paquetes para la cámara de seguridad Fos-cam. Se aprecian dos elevaciones importantes en los paquetes de los grupos D y F dondela frecuencia de aparición de paquetes en esos rangos es mayor.

utilizada se categoriza en dos rangos principales y no consecutivos, los cuales seránutilizados, en subsecciones posteriores para su comparación frente a otros dispositivos.

4.1.2. Monitor de Bebés Dlink

De la misma forma que el dispositivo analizado en la subsección anterior, se espera-ba que el monitor de bebés tuviera un comportamiento similar. La relación encontradaen la distribución del uso del tamaño de paquetes para el monitor fue completamentedistinta a lo generado por la cámara de seguridad.

La cámara Dlink se comportó con menores cantidades de paquetes en su conteo perocon tres picos de tráfico evidentes para su comportamiento aislado, en la Figura 4.2 semuestra de forma gráfica el comportamiento del dispositivo según su clasificación porel tamaño de paquete utilizado. En la Tabla 4.1 se puede apreciar numéricamente losvalores cuantificados. En orden de mayor a menor primero aparece el rango de 40 a 79bytes, con un conteo de 420197 paquetes, para el orden de los 1280 a 2559 se contabilizó

43

Figura 4.2: Comportamiento del tamaño de paquetes para el monitor de bebés. Suhuella se aprecia con tres elevaciones en los grupos CEH donde los paquetes presentanmayores frecuencias de aparición.

324390 paquetes y se observa un tercer pico en el rango de 160 a 319 bytes con un totalde 185935 paquetes. En resumen las mayores cantidades de paquetes se presentaron enlos grupos C, E, H.

4.1.3. Comparación de Dispositivos de Seguridad

Los dos elementos de las subsecciones anteriores, al tratarse de cámaras o moni-tores, entran en la clasificación de dispositivos de seguridad. Se esperaba que ambostuviesen un comportamiento similar, pero no fue así. La Figura 4.3 es la comparaciónde la Figuras 4.1 y 4.2 y demuestra que no existe un patrón entre ellas.

La cámara Foscam se comportó con cantidades de paquetes más altas y en dos de lasagrupaciones cuantificadas, mientras que el monitor de bebés Dlink tuvo concentracio-nes menores en los tres picos de mayor amplitud. Una posible explicación a la diferenciadel comportamiento puede ser que cada uno de ellos estaba ubicado en distintas habi-taciones de la casa. La cámara de seguridad siempre estuvo con un ángulo de captura

44

Figura 4.3: Comportamiento del tamaño de paquetes para dispositivos de seguridad.La curva de mayor amplitud representa la cámara de seguridad Foscam, mientras quela de menor amplitud con tres elevaciones es el monitor de bebés. Se aprecia una grandiferencia en la huella de la caracterización del comportamiento de los paquetes.

de la mayoría de aposentos de la casa, de manera que sus sensores de movimiento ysonido pudieron presentar mayor actividad. La Foscam tenía posibilidad de capturaracciones de la sala de estar, el comedor, parte de la cocina, el ingreso y salida del bañoy parte del dormitorio del niño.

El monitor de bebés tenía una sección de la casa mucho más localizada. Permaneciósiempre en el dormitorio de un niño pequeño, donde censaba poco movimiento por lanoche y por el día la poca actividad que el niño realizara en su habitación. Como datoadicional, sus lugares preferidos para pasar su tiempo eran la sala de estar y el cuartode sus padres.

Estas diferencias de actividad a capturar por cada uno de los dispositivos pudo serla causante de la falta de concordancia en la cantidad de paquetes que trasegó cada unade las cámaras. Sin embargo, esta situación no explica el por qué el uso de paquetes dedatos fue tan diferente. En secciones posteriores se expresa una posibilidad asociada a

45

las diferencias de los protocolos de comunicación utilizados.

4.1.4. Caja Inteligente para T.V.

La caja inteligente para T.V. o Smart T.V. Box muestra tres elevaciones en la Fi-gura 4.4. En mayor proporción tuvo uso de paquetes en el orden de 1280 a 2559 bytes.Con una frecuencia cercana a la mitad se presentó otro pico en el rango de los paquetesde 80 a 159 bytes. Una muy pequeña curva se levanta en los paquetes de 320 a 639bytes de longitud.

Figura 4.4: Comportamiento del tamaño de paquetes para la caja inteligente para T.V.o smart box. Se aprecian dos elevaciones importantes en los grupos D y H, una tercera defrecuencia despreciable en el grupo F. La frecuencia máxima de aparición de paquetesfue hasta los trescientos mil paquetes.

Para este dispositivo, se aprecia como utiliza mayores cantidades de paquetes gran-des. Tiene una curva similar al análisis del monitor de bebés en la Figura 4.2 pero, conun uso de paquetes diferente. En lo único que concuerdan es que presentan máximossimilares en los paquetes de mayor tamaño y cantidades de paquetes máximas similares.

46

4.1.5. Televisor Inteligente

El televisor inteligente, al igual que el caso anterior de la Figura 4.4, tiene semejanzaen forma. Coincide de forma muy similar en el comportamiento del uso de paquetes,de manera que en su mayoría utiliza datos del orden de los 1280 a 2559 bytes comoagrupación mayoritaria. En segundo lugar, paquetes de menor tamaño de 40 a 79 bytesy por último un pequeño pico casi imperceptible en paquetes comprendidos en los ta-maños del 320 a 639 bytes. En la Figura 4.5 se muestra la curva resultado del análisisde paquetes para el dispositivo de televisión.

Figura 4.5: Comportamiento del tamaño de paquetes para el televisor inteligente. Seaprecian dos elevaciones que comprenden tres de las agrupaciones, los bloques C y Dbajo una curva y el H. Como dato importante, el pico máximo se dio con una frecuenciade aparición a casi los siete millones de paquetes en el grupo H.

El televisor, como era de esperarse, fue el dispositivo que utilizó mayores cantidadesde paquetes dejando casi despreciables las cantidades de los demás equipos. En la Figura4.5 se aprecian escalas de tres millones y casi siete millones de paquetes. Esto es tambiénparte de la caracterización del tráfico.

47

4.1.6. Comparación de Dispositivos de Info-Entretenimiento

Los dispositivos de info-entretenimiento, como son los televisores y dispositivos devideo, tuvieron curvas con un comportamiento casi idéntico pero con diferencias nota-bles en la cantidad de paquetes.

Figura 4.6: Comportamiento del tamaño de paquetes para dispositivos de info-entretenimiento. Se aprecia la gran similitud en comportamiento para los grupos Dy H, aunque las frecuencias de aparición son muy distantes entre ambos dispositivos.

En la Figura 4.6 se comparan ambos dispositivos de info-entretenimiento que tienenun comportamiento casi igual excepto por dos pequeños detalles. En primera instancia,el uso de paquetes pequeños fue de menores longitudes para el SmartTV mientras quepara la SmartBox fue de una categoría superior.

El segundo caso es de forma muy explícita, la cantidad de paquetes trasegados. ElSmartTV en sus picos mayores utilizó cantidades de tres millones y siete millones depaquetes contra el SmartBox que se mantuvo por debajo de los trescientos mil.

48

4.1.7. Dispositivo de Iluminación Hue

El dispositivo de Iluminación Hue de la marca Philips presentó una gráfica de as-pecto similar a la de la cámara de seguridad Foscam. Presenta dos curvas de amplitudacentuada en los paquetes del rango de 40 a 79 bytes y 120 a 639 bytes de longitud.

Figura 4.7: Comportamiento del tamaño de paquetes para el dispositivo de IluminaciónHue. Se aprecia la curva con mayor frecuencia de aparición de paquetes en los gruposC y F. Como dato importante, el Hue fue el único dispositivo que presentó paquetes enel grupo I que por su baja frecuencia de aparición en la captura, se nota casi en cero.

La iluminación Hue de Phillips presenta una particularidad a todos los otros elemen-tos analizados y es que fue el único elemento que utilizó paquetes de tamaños superiores.Se contabilizaron 266 paquetes en el rango de 2560 a 5559 bytes, mientras que todoslos otros dispositivos presentan valores de cero. Debido a la escala que presenta cadauna de las gráficas, el comportamiento se puede apreciar de mejor manera en la Tabla4.1 que en la Figura 4.7.

49

4.1.8. Comparación General del Tráfico Total

La Tabla 4.1 resume la cuantificación de paquetes según la clasificación de tamañode paquetes realizada. Es notable cómo en su mayoría presentan comportamientos si-milares con diferencias de amplitud.

Tabla 4.1: Resumen de longitud de paquetes por dispositivo.Grupo Longitud Foscam BabyMonitor SmartBox SmartTV Hue

A 0-19 0 0 0 0 0B 20-39 0 0 0 0 0C 40-79 351.900 420.197 66.909 3.001.967 100.027D 80-159 792.555 74.744 129.967 2.027.313 21.682E 160-319 18.278 185.935 7.217 17.707 695F 320-639 2.071.928 46.198 4.930 21.691 132.897G 640-1279 10.693 144.365 4.540 26.500 1.022H 1280-2559 25.290 324.390 297.315 6.831.413 1.378I 2560-5119 0 0 0 0 266J 5120 y mayor 0 0 0 0 0

La mayor parte del tráfico fue dominado por el televisor inteligente, como se mues-tra en la Figura 4.8 y para visualizar mejor el comportamiento en conjunto es mejoreliminar la curva del smartTV ya que por sus dimensiones hace parecer las demás conpoca amplitud.

En la Figura 4.9 se muestran las curvas relacionadas a todos los dispositivos exceptoel smartTV, que debido a su gran escala se decidió eliminar en esta figura para que losotros dispositivos sí se puedan apreciar mejor. En ella se muestra que el comportamien-to de todos no presentan un patrón y no puede ser posible hacer una caracterizaciónpor tipo de dispositivos. La excepción se da con los dispositivos de info-entretenimientolos cuales son los más simétricos en los tres grupos. El dispositivo de iluminación, notiene comparación en su grupo porque fue único elemento utilizado.

La caracterización del tráfico por medio del tamaño de los paquetes, si bien no pre-senta un análisis concluyente en su totalidad, permite identificar el comportamiento delos dispositivos y sus similitudes entre sí. Un dato interesante es que el Hue fue el único

50

Figura 4.8: Comparación general del comportamiento del tamaño de paquetes por dis-positivo. De los cinco dispositivos analizados, los que presentan mayores frecuencias deaparición de paquetes son el smart T.V. y la cámara Foscam.

Figura 4.9: Comparación general del comportamiento del tamaño de paquetes por dis-positivo. Se eliminan los datos del smart TV para que se aprecien mejor la huella delos demás dispositivos por cuestiones de escala.

51

elemento que presentó paquetes mayores de 1280 bytes y esto sí puede ser identificadoen la red como una característica propia de este tipo de elementos en la comunidad dedispositivos IoT.

Figura 4.10: Normalización de los valores en el histograma de todos los dispositivos. Secomparan todas las curvas de los dispositivos analizados normalizando sus frecuenciasde aparición. Se observa como los dispositivos de info-entretenimiento son muy similaresentre si. Los del grupo de seguridad no tienen ninguna relación aparente. El dispositivode iluminación es único en su grupo

Para poder ver todas las gráficas juntas y poder comparar su comportamiento fuenecesario hacer una normalización de sus valores tomando en cuenta el total del tráficode cada dispositivo. Esto permite que las escalas se ajusten visualmente a los porcenta-jes de bytes transmitidos y recibidos por cada uno de ellos. En la Figura 4.10 se puedenapreciar las gráficas para los diferentes dispositivos estudiados. Se muestran como unahuella que los identifica y sirve como base para comparar otros dispositivos.

La caracterización del tráfico por el tamaño de los paquetes en las comunicacionesde cada dispositivo permitió identificar cada uno de los dispositivos. Se logró crear unprimer acercamiento para identificar, por este tipo de análisis, qué tipos de dispositi-vos existen en un hogar y de esta manera poder identificar si existen elementos como

52

cámaras de vigilancia o dispositivos de info entretenimiento. La identificación de estosdispositivos pone en riesgo la privacidad del hogar ya que permite a un atacante saberde antemano cómo dirigir sus ataques. Si se sabe que está en presencia de una cámara,se buscaría obtener imágenes de la misma.

4.2. Análisis por su Comunicación al Exterior

Parte de la caracterización planteada en el experimento, es la revisión de la comuni-cación que mantiene el dispositivo con los diferentes países del mundo. En esta seccióndel documento se analiza uno a uno el tráfico capturado durante el experimento paradeterminar las distintas direcciones IP que fueron parte de alguna comunicación conlos dispositivos del hogar modelo de la investigación.

4.2.1. Comunicación de la Cámara de Seguridad con diferentes

países

La cámara de seguridad Foscam se mantuvo operando las 24 horas del día, 7 díasde la semana. Su funcionamiento analizado fue el más básico, sin el uso de alertas alos clientes. Bajo la premisa de que el dispositivo no fue utilizado explotando todas suscaracterísticas al máximo se encontró con una gran comunicación al exterior.

En sí los resultados fueron de importancia, ya que la cámara en su forma básica,estableció comunicaciones con tres continentes, desde América, pasando por Europa yhasta en Asia. La Figura 4.11 muestra un mapa con los distintos puntos geográfica-mente localizados por medio de la dirección IP. Se contactó al soporte técnico de lacompañía para conocer cuales son las IPs que son parte del funcionamiento correctodel dispositivo y cuáles pueden ser bloqueadas, sin embargo no se tuvo una respues-ta certera y lo que se indicó fue que el usuario puede bloquear las IPs que desee en su red.

En la Figura 4.12 se puede demostrar la cantidad de paquetes en conversaciones conlos diferentes países. En este caso Estados Unidos suma la mayor cantidad de paquetes,seguido por Alemania y China. Inclusive se muestra Costa Rica como quinto lugar,

53

Figura 4.11: Comunicación de la cámara de seguridad con diferentes países. Cada marcaen el mapa representa un punto geográfico identificado por su IP. Mapa base de Google

después de Holanda, en la cantidad de paquetes involucrados en las conversaciones. Laaparición de Costa Rica se explica debido a que al cliente en cada móvil se le permitecomunicación desde cualquier IP por medio de datos móviles o de WIFI, para el envíode comandos de control.

En la Figura 4.13 se muestran las cantidades de IP por país con la cuales la cámaraestableció algún enlace. De nuevo Estados Unidos es el país con mayor cantidad deIPs con las cuáles la cámara estableció comunicaciones. El segundo lugar correspondea Costa Rica y tiene mucho sentido ya que el cliente real estuvo siempre conectándosedentro de Costa Rica. Se considera normal que tenga varias IPs en la comunicaciónpero no tantos paquetes involucrados. Por esta razón en la Figura 4.12 Costa Rica seencuentra en una posición intermedia en la tabla.

54

Figura 4.12: Comunicación de la cámara de seguridad con el exterior. Se aprecia la grancantidad de paquetes intercambiados con Estados Unidos, Alemania y China.

Figura 4.13: Cantidad de IP por País. Se demuestra que el país con mayor cantidad deIP en comunicación con la cámara es Estados Unidos.

55

ShenZhen Foscam Intelligent Technology Co. es la empresa productora de la cámaray tiene su sede en Shenzhen, China. Por medio de una breve investigación a la empresa,en su página indica que tiene canales de distribución en más de 30 países y regiones,incluidos Alemania, Estados Unidos, Gran Bretaña, Italia, Singapur, India, Francia yCanadá1. Esto sería una posible explicación de por qué hay comunicación con tres con-tinentes y diez países extranjeros.

Los Sistemas autónomos a nivel de la red de cada país con los cuales se establecióalguna comunicación con la cámara, se muestran en la Figura 4.14 donde se puedeobservar cómo en su mayoría fueron paquetes en comunicación con Cogent Communi-cations que es uno de los proveedores de servicios de Internet más grandes del mundo,que ofrece servicios de Internet en 41 países a través de su red IP completamente óptica.

Algo que no se estaba contemplando encontrar fue la comunicación con IP externasque no poseen datos de localización geográfica. Para el caso de la cámara Foscamhubo comunicación con dos IP: 224.0.0.22 y la 239.255.255.250. Según IANA2 que es laAutoridad de Números Asignados en Internet este direccionamiento iniciado en 224 y239 se usan para multidifusión de IP. Esto es una tecnología para enviar eficientementeel mismo contenido a múltiples destinos. Se usa comúnmente para distribuir informaciónfinanciera y secuencias de vídeo y demás aplicaciones.

4.2.2. Comunicación del Monitor de Bebés con Diferentes Paí-

ses

La cámara del monitor de bebés Dlink se mantuvo operando las 24 horas del día, 7días de la semana, al igual que la cámara anterior. Su funcionamiento analizado fue dela misma forma, el más básico, sin el uso de alertas a los clientes. Bajo la premisa deque el dispositivo no fue utilizado explotando todas sus características al máximo, seencontró con resultados esperados, ya que la comunicación hacia el exterior fue bastantereducida en localidades y mucho más reducida que en el caso anterior.

1Fuente: https://foscam.com/company/about-us.html2www.iana.org

56

Figura 4.14: Comunicaciones establecidas desde los Sistemas Autónomos. Los sistemasautónomos proporcionan mayor sectorización dentro de los países

57

Figura 4.15: Comunicaciones del monitor de bebés con el exterior.En el mapa se mues-tra con marcas rojas las pocas localidades con las que el monitor de bebés estableciócomunicación. Mapa base de Google

58

Los resultados obtenidos con el análisis del monitor de bebés Dlink fueron bastantesacertados a la hipótesis sobre los dispositivos de seguridad. En este caso el dispositivosolo se comunicó con dos países en cuatro ciudades. En la Figura 4.15 se muestrangeográficamente las localidades con las cuales se estableció comunicación. Este compor-tamiento es bastante contrastante con la cámara Foscam de la subsección anterior y setienen dos posibles causas dentro del análisis y las condiciones del experimento.

Una posible causa de la diferencia de comportamiento en la cámara de seguridadrespecto al monitor de bebés, se considera que pueden ser las condiciones de operación.Mientras que la cámara Foscam tenía un rango de visión bastante amplio y de aposentosde la casa con mayor concurrencia de personas y acciones de movimiento, el monitorde bebés tenía su ángulo limitado al dormitorio del niño, limitado por las paredes.

Una segunda opción que puede explicar la diferencia entre ambos dispositivos esque la Foscam es de manufactura China, mientras que la Dlink es estadounidense. Nohace falta aclarar que los estándares de producción son diferentes para cada país y quenormalmente Estados Unidos presenta mayores calidades en seguridad y aplicación denormas.

En la Figura 4.16 se muestra el detalle de la cantidad de paquetes trasegados porcomunicación a cada país, desgranado por la ciudad. De forma muy clara, Estados Uni-dos tiene la gran mayoría del tráfico, sobre todo con San José de California. Las otraslocalidades quedaron casi nulas.

Del mismo modo, al analizar la cantidad de IPs registradas por cada ciudad, se tieneun comportamiento similar a la Figura 4.16. En la Figura 4.17 se muestra San José deCalifornia de nuevo sobresaliendo con 9 direcciones y en segundo lugar Irlanda con 2direcciones.

La empresa de manufactura del monitor de Bebés radica en California de EstadosUnidos, por lo que es bastante normal que el tráfico en su mayoría sea hacia California.El monitor de bebés parece ser mucho más seguro respecto a la cámara de seguridadFoscam de la subsección anterior. Al parecer esto puede ir de la mano de la casa matriz.

59

Figura 4.16: Comunicaciones del monitor de bebés con los diferentes países y ciudades.Se aprecia que Estados Unidos, específicamente en San José de California es a dondemayor cantidad de paquetes se enviaron.

Figura 4.17: Cantidad de IPs involucradas en las comunicaciones por ciudad para elmonitor de bebés. Estados Unidos tiene la mayor cantidad de direcciones IP involucra-das.

60

De la misma manera que se presentó en la cámara de seguridad, el monitor de bebéstambién prensentó IPs de multidifusión. En este caso las comunicaciones se dieron conlas direcciones: 224.0.0.251 y 239.255.255.250.

4.2.3. Comunicación del Smart Box con diferentes países

La caja inteligente para el televisor se mantuvo siempre conectada al T.V. y deforma operacional. Se tuvo poco uso del dispositivo y prácticamente se utilizó paramostrar youtube y netflix en el T.V. El funcionamiento del smartbox se mantenía acti-vo mientras fuera utilizado y pasaba a un estado pasivo al estar un tiempo sin uso. Seanalizó el comportamiento y las comunicaciones bajo este esquema de funcionamientoy tomando en cuenta que la mayor parte del tiempo el dispositivo estuvo en modo pasivo.

Figura 4.18: Mapa de comunicaciones al exterior para el smart box. Se aprecia grancantidad de comunicaciones hacia otros países. Mapa base de Google

Se encontraron resultados esperados, ya que la comunicación hacia el exterior fuerelativamente variada en localidades, en la Figura 4.18 se muestra geográficamente cada

61

uno de los puntos de comunicación con el dispositivo.

Figura 4.19: Cantidad de paquetes en comunicación al exterior para el smart box.Seaprecia nuevamente Estados Unidos como los países con mayores intervenciones.

En la Figura 4.19 se puede demostrar la cantidad de paquetes en conversaciones conlos diferentes países. En este caso se muestra el país de origen Costa Rica a la cabezade las localidades con mayor cantidad de paquetes. Estados Unidos se ubica como elsegundo lugar. Los demás países son casi nulos respecto los dos primeros, pero se puedenotar como mantiene una pequeña conversación con China.

En la Figura 4.20 se muestran las cantidades de IP por país con la cuáles la caja deT.V. estableció algún enlace. De nuevo Estados Unidos es el país con mayor cantidadde IPs aunque en la Figura 4.19 es el segundo lugar en cantidad de paquetes en lacomunicación. El segundo lugar corresponde a Costa Rica.

El fabricante de este dispositivo tiene su casa matriz en China. Al igual que enel caso de la cámara de seguridad de origen chino, estos dos dispositivos tuvieron unacantidad mayor de comunicaciones con IPs más variadas en diferentes partes del mundo.

De la misma forma que en los anteriores dispositivos, también fue posible determinar

62

Figura 4.20: Cantidad de direcciones IPs por país para el smart box. Estados Unidoslidera con la mayor cantidad de IPs en comunicación.

el sistema autónomo a nivel de la red de cada país con los cuales se estableció algunacomunicación con el smart box. En la Figura 4.21 se muestra como en su mayoría fueronpaquetes en comunicación con el Instituto Costarricense de Electricidad, la cuál es laempresa proveedora de servicios de Internet más grandes del país. El segundo lugarcomo sistema autónomo fue Google.

El Smart Box también presentó comunicaciones con IPs de multidifusión. Para estedispositivos se establecieron comunicaciones con las direcciones 224.0.0.251 y 239.255.255.250.

4.2.4. Comunicación del Smart TV con diferentes países

El televisor inteligente se mantuvo siempre conectado funcionando bajo operacionesnormales. Se tuvo poco uso del dispositivo para explotar las características que lo con-vierten en smart y prácticamente se utilizó para visualizar netflix.

Se encontraron resultados esperados, ya que la comunicación hacia el exterior fuerelativamente variada en localidades. En la Figura 4.22 se muestra geográficamente ca-

63

Figura 4.21: Comunicaciones establecidas con los Sistemas Autónomos desde el smartbox. El ICE representa la mayor cantidad de paquetes en los flujos de comunicación conel dispositivo.

64

da uno de los puntos de comunicación con el dispositivo.

Figura 4.22: Comunicaciones del Smart T.V. con el Exterior. Se muestra una grancantidad de destinos externos, entre ellos se resalta la aparición de Singapure. Mapabase de Google

Tomando en cuenta que lo esperado era que el televisor se comunicara con unacantidad variada de sitios, no lo fue así en cantidad de países. En la Figura 4.23 sedemuestra que solo tuvo comunicación con tres países en un continente. En este casoal igual que en la subsección anterior, Costa Rica fue el país con mayor cantidad depaquetes, seguido por Estados Unidos y en una mínima proporción, Canadá.

En la Figura 4.24 se muestran las cantidades de IP por país con la cuáles el T.V.estableció algún enlace. De nuevo Estados Unidos es el país con mayor cantidad de IPsaunque en la Figura 4.23 es el segundo lugar en cantidad de paquetes en la comunica-ción. El segundo lugar corresponde a Costa Rica según este resultado.

La casa matriz de Samsung tiene origen asiático, sur coreano. Por lo tanto es otro

65

Figura 4.23: Comunicaciones del Smart T.V. con el Exterior. La mayor cantidad depaquetes fue de tráfico interno a Costa Rica, en segundo lugar Estados Unidos.

Figura 4.24: Cantidad de IPs por País para el smart T.V. Estados Unidos se muestracomo el país con más direcciones IP de destino.

66

Figura 4.25: Comunicaciones establecidas desde el smart T.V. con los Sistemas Autó-nomos. Los S.A. proporcionan una mayor visibilidad dentro de cada país.

67

dispositivo de origen oriental, pero de una empresa mucho más sólida y de renombre.

También se determinó el sistema autónomo a nivel de la red de cada país con loscuales se estableció alguna comunicación con el smart T.V. En la Figura 4.25 se muestracómo en su mayoría los de paquetes se establecen con el sistema autónomo del Institu-to Costarricense de Electricidad y Telecomunicaciones, coincidiendo con el smart box.De forma bastante obvia, Netflix es un sistema autónomo ubicado en los primeros treslugares en comunicaciones.

El Smart T.V. fue el dispositivo con menor cantidad de IPs de multidifusión ensus comunicaciones. Para televisor se establecieron comunicaciones con sólo una IP:239.255.255.250.

4.2.5. Comunicación del Hue con diferentes países

La captura de tráfico del dispositivo Hue se realizó en mayo desde el día ocho hastael veintiuno. Durante ese tiempo se mantuvo conectado al capturador y operacional. Aligual que los demás dispositivos el Hue se mantuvo funcionando las 24 horas del díalos 7 días de la semana. Este elemento funciona como un apagador remoto, de maneraque se puede controlar también la intensidad de la luz y dependiendo de las luminariasutilizadas, se puede cambiar de color. Para el caso de este experimento se utilizó detipo luz blanca.

El Hue tuvo como resultado la comunicación con tres diferentes continentes. En laFigura 4.26 se muestran los puntos geolocalizados en el mapa con marcas en los sitioscon los que se mantuvo comunicación. En estos tres continentes también se tuvo co-municación con tres diferentes países. De forma casi estricta, Estados Unidos es el paíscon mayor cantidad de paquetes en comunicación con el dispositivo. En la Figura 4.27se muestra gráficamente la cantidad de paquetes en comunicación con el dispositivo deiluminación.

En la Figura 4.28 se muestran las cantidades de IP por país con la cuáles el Hueestableció algún enlace. De nuevo Estados Unidos es el país con mayor cantidad de IPs

68

Figura 4.26: Comunicación del Dispositivo de Iluminación Hue con el Exterior. Cadapunto marcado en el mapa representa la ubicación greográfica de direcciones IP queestablecieron comunicación con el dispositivo Hue. Mapa base de Google

Figura 4.27: Cantidad de paquetes en comunicación al exterior, por país desde el Hue.Estados Unidos representa la mayoría de las comunicaciones.

69

con las cuáles la cámara estableció comunicaciones. El segundo lugar corresponde a Sin-gapur y por último Reino Unido. Debido a que la casa matriz de Philips es en Europa,resulta bastante razonables que Reino Unido tenga comunicaciones con el dispositivo.

Figura 4.28: Cantidad de IPs por país en comunicaciones con el Hue. Estados Unidosrepresenta la mayoría de IP en comunicación con el dispositivo.

Siguiendo el mismo procedimiento que en los dispositivos anteriores, se graficó lacantidad de paquetes de comunicaciones con las redes de los sistemas autónomos regis-trados. Para el caso de Hue, en la Figura 4.29 se muestra a Google como la principalorganización que mantuvo intercambio de paquetes con la iluminación. Esto fue bas-tante predecible ya que al crear una cuenta con la aplicación cliente para controlar laluz, esta se generó con los datos de cuentas de Google.

El Hue fue el dispositivo que mayor cantidad de IPs de multidifusión presentó ensu tráfico. Para este dispositivos se establecieron comunicaciones con las direcciones:224.0.0.22, 224.0.0.251 y 239.255.255.250.

70

Figura 4.29: Comunicaciones establecidas desde el Hue con los Sistemas Autónomos.Los S.A. representan mayor visibilidad dentro de cada país.

4.2.6. Comunicación con diferentes países de toda la Red IoT

del Hogar

En general, las comunicaciones de cada uno de lo elementos analizados fue bastantelocalizada. Hay un notable patrón geográfico con los cuales los dispositivos están co-municándose como se muestra en la Figura 4.30. En general, la mayor parte del tráficoesta siendo enviado a América del Norte, entre Estados Unidos y Canadá, indistinta-mente de la casa matriz de cada uno de los dispositivos. Como segundo lugar, Asia es laregión con mayores cantidades de comunicaciones y después Europa. Estos dos últimosvan muy similar en cantidades. Además de estas agrupaciones en el mapa, quedan unpar de localizaciones que se salen de los esquemas, como lo son Sud África y Singapur,correspondientes al Smart Box y el Hue de forma respectiva. La Figura 4.30 resumetodos los puntos de comunicación geográficamente referenciados. Se aprecia como enSur África y Singapur se presentan como puntos aislados dentro de las agrupacionesformadas.

71

La identificación de la cantidad de países con los cuáles cada uno de los dispositi-vos establece comunicación es un parámetro para identificar el riesgo latente en cadauno de ellos. Entre más cantidad de países estén relacionados en comunicaciones con eldispositivo mayor riesgo de vulnerarlo y por lo tanto es una posible brecha de privacidad.

Figura 4.30: Comunicaciones establecidas desde toda la red de IoT del hogar hacia losdiferentes países. Se aprecia como hay tres agrupaciones importantes comprendidas porEstados Unidos, Europa y China. De la misma forma hay ubicaciones aisladas comoSud África y Singapur. Mapa base de Google

4.3. Consultas DNS

Otro de los aspectos por caracterizar en los dispositivos fue las consultas de DNS. Seesperaba que dispositivos de la agrupación de seguridad y de iluminación tuvieran bajotráfico de solicitudes, mientras que los de info-entretenimiento fueran bastante altos encomparación. Para este caso, igual que los anteriores, no fue necesario entrar en temasde criptografía ya que también se utilizaron los metadatos. Para el caso del protocolo

72

DNS, es fácilmente capturable los nombres de dominio y las IP de respuestas. A partirde estos datos y su relación en el tiempo es que se generó el análisis.

4.3.1. DNS Request de la Cámara Foscam

La cantidad de solicitudes de DNS en la cámara Foscam, se muestra en la Figura4.31. Los resultados obtenidos fueron bastante constantes. Aproximadamente la prime-ra mitad del mes se mantuvo muy estable en un promedio de ciento veinte solicitudes deDNS. Posterior a esta primera mitad, el tráfico se incrementó ligeramente debido a laactivación del sensor de movimiento. El pico máximo de solicitudes se dio el veinticuatrode abril a las ocho de la noche con doscientos cincuenta y nueve request realizados.

Figura 4.31: Solicitudes DNS de la Cámara de Seguridad Foscam. La variación en elcomportamiento de su tráfico coincide con la activación de alertas por detección demovimiento, permanece así en el tiempo de presencia de personas en el hogar.

La cantidad de dominios consultados por la cámara fue bastante reducido. Se regis-traron solo cinco dominios de los cuáles, la gran cantidad de solicitudes se hicieron pormotivos de sincronización de la hora como fueron time.nist.gov y time.windows.com. LaFigura 4.32, de forma simétrica a la gráfica anterior de la Figura 4.31, muestra que elincremento en la segunda mitad del mes corresponde a que con la activación del sensorde movimiento, se hacen solicitudes al dominio myfoscam.com. Se presume que esta

73

activación provoca que la cámara envíe activamente paquetes con alguna indicación alas redes de la aplicación, para emitir via Internet las alertas a los dispositivos cliente.Este comportamiento es un claro riesgo a la privacidad.

Figura 4.32: Solicitudes DNS de la Cámara de Seguridad Foscam separado por Domi-nios. Se aprecia un cambio del comportamiento a partir de la mitad del gráfico consolicitudes al dominio myfoscam.com coincidiendo con la activación del sensor de mo-vimiento.

4.3.2. DNS Request del Monitor de Bebés

El comportamiento del tráfico DNS del monitor de bebés fue similar al de la cámaraFoscam. Se presumía que el comportamiento iba a ser acorde a la cámara de seguridadpor pertenecer a la misma agrupación de seguridad.

Para el caso de este dispositivo, en su funcionamiento normal, la cantidad de consul-tas DNS fueron extremadamente reducidas. Se limitó a menos de 20 solicitudes al día.Tuvo un comportamiento atípico los días diecisiete y veinticuatro de abril cuando sepresentaron valores pico de 79 y 288 de forma respectiva por hora registrada y valoresdiarios de 124 y 2131. En la Figura 4.33 se muestra el comportamiento respecto a lasconsultas realizadas durante el tiempo de la captura de tráfico.

74

Figura 4.33: Solicitudes DNS del Monitor de Bebé, se aprecia como hubo un incrementoel día 24 de abril, cuando hubo presencia de más niños en la habitación.

En la Figura 4.34 se muestra el comportamiento por los dominios consultados. Sedemuestra que la cantidad de dominios en comunicación con el monitor de bebés fuesólo tres. Todos los dominios son relacionados con la marca del monitor Dlink. Para losdías que no tuvieron comportamiento normal se muestra que la anormalidad se presentócon el nombre mp-us-signal.auto.mydlink.com.

4.3.3. DNS Request del SmartBox

Para el smartbox se consideraba que iba a tener un incremento de consultas denombres de dominio. Si bien es cierto, fue mayor que los dos casos de los dispositivosde seguridad pero no tan elevado. En la Figura 4.35 se muestra el comportamiento a lolargo del tiempo con respecto a las solicitudes hechas por la caja para el TV. El valorpico máximo fue de cuarenta y cuatro request. Sin embargo, en promedio se mantuvoaproximadamente en unas cinco consultas por hora.

75

Figura 4.34: Solicitudes DNS del Monitor de Bebé separado por Dominios. Eldía 24 de abril presentó un incremento en las solicitudes al dominio mp-us-signal.auto.mydlink.com debido a la activación de movimiento por mayor actividadde personas en la habitación.

En la Figura 4.36 se muestra la cantidad de consultas por dominios. Algunos nom-bres fueron agrupados por facilidad a la hora de mostrar los datos. Se puede apreciarque la cantidad de nombres consultados fue de doce y que la predominancia se dió conlos dominios relacionados con Google, Youtube y Dropbox.

4.3.4. DNS Request del Smart T.V.

El caso del smart T.V. sí calzó exactamente con lo esperado para los dos dispositivosde info-entretenimiento. La cantidad de consultas de nombres y la frecuencia fueron enproporción mucho mayores que los otros dispositivos. En la Figura 4.37 se muestra co-mo en promedio se tienen consultas constantes de aproximadamente treinta peticiones.

76

Figura 4.35: Solicitudes DNS del Smart Box. Presenta comportamientos aleatorios yconstantes solicitudes a pesar de estar en modo stand by.

También se aprecia un comportamiento anormal el día veinticuatro de abril.

La figura 4.38 muestra el comportamiento casi caótico de consultas de nombres se-parado por cada uno de los dominios. Para este caso se mostraron dieciséis dominiosdiferentes a los cuales el televisor estuvo haciendo peticiones durante el tiempo del ex-perimento. El dominio con mayor aparición es el ns11.whois.co.kr y en mucho menorintensidad a dominios relacionados con sincronización de la hora.

4.3.5. DNS Request del Hue

Para el caso del dispositivo de iluminación HUE, se presentaron valores bastantebajos con respecto a la frecuencia de consultas DNS. En la totalidad del tiempo que semantuvo la captura de datos de tráfico de este dispositivo siempre se mantuvo consul-tas con frecuencias entre 8 a 20 solicitudes por hora. En la Figura 4.39 se muestra loindicado.

En la Figura 4.39 se aprecia como existe una especie de patrón en el comportamientodel Hue. Al analizar los datos por horas se puede demostrar que siempre se dan picos

77

Figura 4.36: Solicitudes DNS del Smart Box separado por Dominios. Se observa mayorpresencia de los dominios referentes a Google y Youtube.

Figura 4.37: Solicitudes DNS del Smart T.V.. Se aprecia un incremento en el día 24 deabril por el uso del dispositivo para animados en Netflix.

en la gráfica a las horas: 6:00, 14:00 y 22:00, de manera que el momento más activosiempre es a las 22:00.

La Figura 4.40 demuestra solicitudes de resolución de nombres a únicamente 5 sitios.Este comportamiento lo convierte en el dispositivo con menos dominios consultados. Al

78

Figura 4.38: Solicitudes DNS del Smart T.V. separado por Dominios. Se elimina el día24 de abril para mejor visualización. El incremento de solicitudes del día 24 se asocia ados dominios infolink.pavv.co.kr y ns11.whois.co.kr.

Figura 4.39: Solicitudes DNS del HUE. Se aprecia que constantemente se hacen solici-tudes.

mismo tiempo se puede apreciar como los picos encontrados a las 6:00 y 14:00 corres-ponden al dominio diagnostics.meethue.com. También a las 22:00 la solicitud la haceal www,ecdinterface.philip. Este comportamiento, además de los tipos de nombres con-

79

Figura 4.40: Solicitudes DNS del HUE separado por Dominios. Se aprecia un com-portamiento repetitivo de solicitudes de DNS asociados a diagnóstico del equipo ycomunicación con la empresa Philips.

sultados, hacen que sea posible inferir que existen dispositivos de este tipo en el hogar.

4.3.6. Hallazgos respecto a DNS

Para la cámara Foscam, las solicitudes al DNS tienen una relación estrecha a la ac-tivación de alertas. Es exactamente en el 17 de abril de 2018 que se activan las alertasde movimiento y justo ese mismo día las solicitudes de DNS cambiaron, aumentandolas peticiones mientras existieran personas en movimiento dentro de la casa. Al parecerel mismo comportamiento se reflejó en la cámara del monitor de bebés ya que el 24 deabril registró mayor actividad y las solicitudes de DNS aumentaron, debido a la pre-sencia de niños en la habitación. De la misma forma que el monitor de bebés, el smartbox presentó el mismo comportamiento ya que el día veinticuatro de abril hubo mayorpresencia de niños en la casa, jugando en las habitaciones donde el monitor de bebésestá instalado y viendo videos en Youtube.

El Hue presentó un claro patrón de solicitudes entre las seis de la mañana, dos dela tarde y diez de la noche, al parecer ser que por un tema de diagnóstico y reporte al

80

sitio de la empresa.

El análisis por DNS demostró resultados importantes en el ámbito de la privacidady seguridad. La cantidad de solicitudes de resolución de nombres fue directamenteproporcional a la cantidad de personas presentes en el hogar de forma activa. Los díascon mayor presencia de personas en la casa generó cantidades anormales de solicitudes,mientras que los días con presencia normal de personas los datos eran menores y casinulos para los momentos sin actividad en la casa como las noches.

4.4. Tráfico de Subida y Bajada

Un aspecto más de la caracterización del tráfico es el flujo de subida, uplink yde bajada, downlink. Al igual que los casos anteriores de caracterización, el análisisde estos datos no depende de la encriptación de los paquetes ya que solo se analizanlos metadatos de las comunicaciones. Para este análisis se tomo en cuenta si el flujode la comunicación es hacia o desde el dispositivo en estudio y la cantidad de bytestransmitidos.

4.4.1. Tráfico de Subida y Bajada de la Cámara Foscam

Tal como se esperaba, el tráfico de subida es superior siempre con respecto al tráficode bajada. En la Figura 4.41 se grafica el comportamiento de ambos flujos de la infor-mación. En este caso la cámara siempre estuvo en su funcionamiento más simple sin laopción de almacenar vídeo en la nube. En la misma figura se eliminó el día quince deabril por considerarse un día atípico. Para ese día un miembro de la familia del hogarinvestigado celebraba su cumpleaños y por esa razón hubo más cantidad de personas enla casa. Como resultado se tuvo un pico de tráfico de subida. Esta situación se presentadebido a que la inteligencia de la cámara, por medio de los sensores de movimiento,emiten mensajes de alerta al dominio de la cámara.

81

Figura 4.41: Tráfico de Subida y bajada para la Cámara Foscam. El flujo uplink siemprefue superior al downlink. Se eliminaron días atípicos como el 15 de abril por motivos devisualización.

4.4.2. Tráfico de Subida y Bajada del Monitor de Bebés

Para el caso del monitor de bebés, el comportamiento esperado fue aún más evi-dente que el caso anterior de la cámara Foscam. En la Figura 4.42 se muestra cómo enla totalidad de la gráfica el flujo de información hacia el exterior fue superior en todomomento al de bajada.

El rango de diferencia de tráfico de subida contra el de bajada entre la cámara y elmonitor de bebés es bastante similar. En la Figura 4.42 pareciera que el flujo de subidaes mucho mayor en comparación al comportamiento de la Figura 4.41, sin embargo portemas de escala, la diferencia presentada en la cámara foscam fue mucho mayor que ladel monitor de bebés. Pero, una ves eliminados los días atípicos de tráfico, el compor-tamiento general es bastante similar entre las curvas de las dos figuras. En promedio laFoscam tiene aproximadamente 3 MB de diferencia, mientras que la BabyCam casi 2MB.

En la Figura 4.42 se eliminaron los días quince y veintiuno de abril por considerarse

82

Figura 4.42: Tráfico de Subida y bajada para el Monitor de Bebés. El flujo uplinksiempre fue superior al downlink. Se eliminaron días atípicos por motivo de apreciaciónde la curva.

días atípicos. Igual que el caso anterior estos días hubo mayor movimiento en la secciónde la casa que el monitor de bebés tenía posibilidad de capturar movimiento o sonido.Como resultado de esos días, se tuvo un par de picos de tráfico de subida que no per-miten apreciar bien el comportamiento general.

4.4.3. Tráfico de Subida y Bajada del Smart Box

Para esta etapa de análisis, el smart box se comportó tal como se esperaba. Alser un dispositivo de info-entretenimiento, su tráfico de bajada siempre fue mayor encomparación con el de subida. Efectivamente es el comportamiento opuesto a los dosejemplos anteriores de los dispositivos de seguridad. En la Figura 4.43 se resume elcomportamiento del tráfico del dispositivo, donde de forma muy clara el flujo downlinkpredomina sobre el uplink.

Para el caso de la Figura 4.43, también se eliminaron días considerados atípicos, loscuales fueron veinte, veintiuno y veinticinco de abril, que debido a su escala no permite

83

Figura 4.43: Tráfico de Subida y bajada del Smart Box. El comportamiento del tráficodownlink fue superior al uplink.

la mejor visualización de las curvas. En todo caso, el tráfico saliente del dispositivosiempre fue mayor que el entrante.

4.4.4. Tráfico de Subida y Bajada del Smart T.V.

El smart T.V. no fue la excepción. El tráfico downlink fue superior en mucho aluplink con diferencias bastante altas entre la cantidad de bytes de subida contra labajada, hasta los 5 GB máximos y en promedio 487 MB diarios. En la Figura 4.44 semuestra el comportamiento del televisor con respecto a los flujos de subida y bajada,en todos los casos registrados se comportó de forma esperada al igual que el otro dis-positivo de su categoría.

Del mismo modo que los dispositivos anteriores, al smart T.V. se le eliminaron díasatípicos. En este caso fue el día quince de abril. Los motivos son exactamente los mis-mos que se indicó en la cámara Foscam al inicio del análisis. El incremento de tráficose debe al uso que se le dio al televisor ese día al incrementarse la cantidad de personasen la casa objeto del experimento.

84

Figura 4.44: Tráfico de Subida y bajada del Smart T.V.. El comportamiento del tráficodownlink fue superior al uplink.

4.4.5. Tráfico de Subida y Bajada del Hue

Para el caso del único dispositivo de iluminación, el Hue de la marca Phillips setuvo un resultado no esperado. En un principio se consideraba a modo de hipótesis queel tráfico de los dispositivos de iluminación no iba ser alto y que ambos flujos de lacomunicación iban a ser bastante simétricos entre si. La realidad se demuestra en laFigura 4.45 donde de forma muy clara, el flujo uplink es un 93% del total, por lo tantoel downlink se queda con un 7%.

El tráfico de este dispositivo fue bastante estable en sus dos flujos. No presentóalteraciones ni fue necesario eliminar algún dato para presentar de mejor manera losresultados. Parece un poco extraña la diferencia tan grande del tráfico de subida res-pecto a la bajada. El Hue se comportó de manera similar a los dispositivos de seguridad.

4.4.6. Revisión de Hallazgos

El tráfico de subida y bajada fue un hecho relacionado directamente a la estancia depersonas en la casa. Para el caso de las cámaras, la de seguridad tanto como el monitorde bebés aumentaron su tráfico de subida con la detección de presencia de personas en

85

Figura 4.45: Tráfico de Subida y bajada para el dispositivo de Iluminación Hue. Seaprecia como el tráfico de subida es un 93% del total.

la casa, lo cuál representa un riesgo de privacidad.

Para el caso del televisor inteligente, se determinó un hallazgo revelador de informa-ción privada con el simple hecho de ver el tráfico de bajada. Se encontró un patrón enlas horas del día que había tráfico desde afuera de la casa hacia el dispositivo y coincidióde forma bastante certera con la presencia de personas en la casa.

El tiempo de mayor estancia en la casa con uso del televisor fue desde la 1 pm.hasta las 2 pm. En la Figura 4.46 se puede apreciar por medio de las barras las horascon mayor frecuencia de uso del televisor, mientras que 5, 6 y 7 A.M representan usoen menor medida.

Para el caso del hogar que estaba siendo sujeto de investigación se explica un pocola rutina para luego comparar con los datos de tráfico del televisor. En el hogar, ambospadres trabajan fuera y debían salir de la casa al rededor de las 6:30 am. Al mismotiempo, una persona externa llegaba al lugar para el cuido del niño. Durante el día yhasta las 4:20 pm. aproximadamente, empezaban a llegar los padres nuevamente. Pri-mero la madre y de último el padre aproximadamente a las 5:20 pm. El niño, algunas

86

veces se despertaba antes de que los padres se fueran, otras veces después de las 7:00am. y pocos días llegaba a casi las 8:00 am.

Figura 4.46: Histograma de comportamiento del tráfico downlink del televisor. Se apre-cia como las horas de mayor uso del dispositivo son entre la 1 y 2 pm. También sepresenta una frecuencia de uso en menor medida entre las 5 y 7 am.

La rutina del hogar fue revelada según la Tabla 4.2, donde se muestran datos detráfico de un extracto de los resultados. Se muestra que empieza a tener datos desde las6:00 am. hasta las 8:00 am. De 9:00 am. a las 11:00 am. se presenta casi siempre vacíoy es hasta las 12:00 M.D. que se muestra tráfico nuevamente. Con estos datos, se revelael hecho que el niño junto con su cuidador, salían de casa a jugar en los alrededoresy no era hasta aproximado el medio día que regresaban a tomar su almuerzo. El niñoalmorzaba entre 12:00 M.D. y 2:00 pm. Tiempo después tomaba una siesta y luegoesperaba la llegada de su madre y su padre. Posterior a eso a las 7:00 pm. se disponíana dormir el niño, tiempo del cual disfrutaba de unos momentos de televisión antes de

87

dormir, incluso algunos viernes hasta podría dormir más tarde.

De lo anterior, se demuestra como el tráfico de bajada es relacionado directamentea las actividades de la familia. Por este simple hecho es un riesgo a la privacidad dela familia. Es importante indicar que en este caso no fue necesario ningún análisisavanzado, simplemente la suma de bytes.

Tabla 4.2: Hallazgos presentados con el Televisor. Se muestra un extracto de tres díasconsecutivos, los datos en las columnas dos, tres y cuatro corresponden a presencia detráfico de bajada. La columna cinco explica la rutina del día.

H 04/18/2018 04/19/2018 04/20/2018 Rutina5:00 – – – Dormir6:00 – – 95.922 B7:00 – 95.718 B. –8:00 348.370 B. 3.556 B. –

Rango de horas en las quese despierta el niño y se letranquiliza con el T.V.

9:00 – – –10:00 – – –

Tiempo de juego fuerade casa.

11:00 – – 793.661 B.12:00 – 92.901 B. 2.792 B.13:00 95.514 B. 1.633 GB 832 GB.14:00 92.681 B. 3.018 B. 358.134 B.

Rango de horas en las quealmuerzan, primero el niñoy luego la persona con el

rol de cuidador

15:00 – – – Normalmente el niño duermeuna hora por la tarde.

16:00 – – 92.885 B.17:00 92.681 B. 3.018 B. 358.134 B.

Rango de horas en el que el niñoespera el regreso de sus padres.

18:00 92.819 B. – –19:00 2.709 B. 95.774 B. 345.444 B.20:00 – – 95.650 B.

Rango de horas de cena ytiempo de relajación antes

de dormir.21:00 – – – Dormir

4.5. Protocolos de Comunicación

Otro de los análisis hechos como parte de la caracterización, es el uso de los diversosprotocolos de comunicación por parte de los dispositivos. De la misma forma, el análisisde protocolos no implica resolver los problemas de cifrado de la captura de paquetes,sino la revisión, análisis y comparación de los distintos estándares de comunicación quesoportan cada uno de los aparatos analizados.

88

4.6. Protocolos utilizados por la Cámara de Seguridad

Foscam

La cámara Foscam utilizó en su mayoría el protocolo UDP. Este comportamientoera esperado ya que se trata de transmisión de vídeo en tiempo real, porque se necesitaacelerar la transmisión de vídeo y no la seguridad de emisión. El 99% del tráfico fuetransmitido por medio de UDP y un porcentaje despreciable por medio de TCP. LaFigura 4.47 muestra un gráfico de pastel con la representación de lo indicado.

Figura 4.47: Distribución de protocolos para la cámara de seguridad Foscam. En sugran mayoría, la cámara funciona por el protocolo UDP.

La Figura 4.48 representa la separación del tráfico de transporte UDP en los dife-rentes protocolos de la capa de aplicación que fueron detectados en la cámara Foscam.

El 88% del tráfico UDP fue exclusivamente de datos , que también es una situaciónesperada al transmitir vídeo. Se transmitió por el protocolo SCP (secure copy). Un parmás de protocolos minorías se muestran con los nombres DOF con un 9% y NTP conun 3%. El protocolo de NTP es bastante conocido y se refiere, por sus siglas en inglés

89

Figura 4.48: Distribución de protocolos transportados en UDP para la cámara de segu-ridad Foscam. Se aprecia como en su mayoría corresponde al protocolo SSDP.

a Network Time Protocol o protocolo de tiempo de red. Este permite la sincronizaciónde relojes entre sistemas con un servidor de tiempo. DOF corresponde a un proyectoconocido como OpenDOF, de sus siglas en inglés: Open Distributed Object Framework,permite el desarrollo de servicios de red escalables y confiables basados en objetos co-nectados. Se diseñó para dispositivos integrados en red, ya sean simples o complejos,para admitir funciones de red avanzadas para esos dispositivos apropiada para serviciosque amplían la funcionalidad de dispositivos en red, ya sea que esos servicios residan ensus propios servidores físicos o aproveche la nube avanzada tecnología, como es el casode ésta cámara.

4.7. Protocolos utilizados por el Monitor de Bebés

Dlink

El monitor de bebés tuvo un comportamiento opuesto a la cámara Foscam. En sumayoría utilizó el protocolo de transporte TCP y en menor medida el UDP. Lo espe-

90

rado es que tuviera un comportamiento muy similar a la cámara de seguridad Foscam.Sin embargo fue bastante desviado. Quizás el comportamiento se explica por la pocaactividad que tuvo el monitor de bebés Dlink debido a su ubicación dentro de la casamencionado en la sección 4.1.3. La Figura 4.49 muestra la distribución general del trá-fico del monitor con un 93% para TCP y un 7% para UDP.

Figura 4.49: Distribución de protocolos para el monitor de bebés. Un 93% del tráficocorresponde a TCP y un 7% a UDP, de forma opuesta a su correspondiente: la cámaraFoscam.

De la misma forma que se mostró la distribución del tráfico para el protocolo UDPcon la cámara, se muestra para el monitor de bebés. En este caso, el tráfico UDP secompuso de los protocolos SSDP, mDNS y NTP. En la Figura 4.50 se muestra la dis-tribución del los protocolos de aplicación bajo el transporte UDP. Se tiene un 7% deNTP, 8% de mDNS y un 85% del SSDP. EL protocolo mDNS significa multicast DNSy resuelve los nombres de host a las direcciones IP en redes pequeñas que no incluyenun servidor de nombres local. En resumen, hace lo mismo que el DNS pero con nuevasfuncionalidades haciendo cambios mínimos al protocolo DNS estándar actual. SSDPsignifica del inglés Simple Service Discovery Protocol que en español sería protocolosimple de descubrimiento de servicios. Sirve para la búsqueda de dispositivos UPnP en

91

una red. Está diseñado para su uso en entornos residenciales o de pequeñas oficinas.

Figura 4.50: Distribución de protocolos UDP para el monitor de bebés. En su mayoríael tráfico UDP se basa en el protocolo SSDP, luego mDNS y NTP

Para el caso del otro 7% del tráfico UDP, la distribución de los protocolos fue casien su totalidad datos TCP. HTTP y SSL fueron minoría. En la Figura 4.51 se muestrande forma gráfica los porcentajes de distribución de lo que fue el tráfico TCP del monitorde bebés. Un 96% del flujo fue HTTP, mientras que HTPPs representa un 3%, seguidopor el DLS-Monitor con un 1%.

4.8. Protocolos utilizados por el Smart Box

La caja inteligente para televisión tuvo también en su mayoría tráfico por mediodel transporte UDP y en menor medida TCP, similar al caso del monitor de bebés enla sección 4.7. La Figura 4.52 representa de la totalidad del tráfico, un 77% para elprotocolo UDP y el TCP con el 23%. Este comportamiento sí era esperado para eldispositivo, debido a que su sistema operativo es Android, se comporta más como unteléfono inteligente que como un dispositivo de vídeo en demanda, por eso se aprecia

92

Figura 4.51: Distribución de protocolos TCP para el monitor de bebés. En su mayoríase trabaja bajo el protocolo http.

un poco más de tráfico TCP aunque el UDP siempre fue superior.

El tráfico UDP del dispositivo fue casi en su totalidad del protocolo HTTPS. En laFigura 4.53 se muestra el detalle anterior donde el tráfico fue un 99% para HTTPS yun 1% de otros protocolos sin relevancia.

Para el caso TCP, el tráfico se conformó de básicamente dos protocolos una mayoríarepresentada por TCP puro y en segundo puesto la encriptación SSL que en realidades TLS en la versión 1.2. Una minoría extra se presentó para tráfico de datos en textoplano. En la Figura 4.54 se muestra lo indicado donde TCP se aprecia con un 77% dela totalidad, el SSL con un 22% y los datos con un 1%.

93

Figura 4.52: Distribución de protocolos para el smart box. Domina el tráfico UDP conun 77% contra un 23% del TCP.

Figura 4.53: Distribución de protocolos UDP para el monitor de bebés.

94

Figura 4.54: Distribución de protocolos TCP para el monitor de bebés.

4.9. Protocolos utilizados por el Smart T.V.

El televisor inteligente, casi de la misma forma que el monitor de bebés, tuvo comodominante el tráfico TCP sobre todos los demás. En la Figura 4.55 se aprecia comoaparece el protocolo IGMP y el UDP con valores despreciables y el TCP tiende al 100%de lo utilizado. Este comportamiento no se esperaba así, ya que se consideraba que eltráfico de vídeo streamming se regía, por temas de latencia, en el protocolo UDP.

De la misma forma que los anteriores dispositivos, se verificó cómo estaba compuestoel tráfico TCP del televisor. y se aprecian dos protocolos. Dominado en mayor cantidadpor el protocolo HTTP y en menor medida por HTTPS. En la Figura 4.56 se muestracomo el tráfico HTTP domina la comunicación con un 99%, posteriormente el HTTPScon un poco menos del 1%.

95

Figura 4.55: Distribución de protocolos para el smart T.V. Casi un 100% de su tráficoes TCP.

Figura 4.56: Distribución de protocolos TCP para el smart T.V. Un alto porcentaje desu tráfico es HTTP y en baja medida el HTTPS.

96

4.10. Protocolos utilizados por Hue

El único dispositivo de iluminación utilizado fue el Hue de la marca Philips. Paraeste equipo, el tráfico fue dominado por UDP, seguido de TCP y por último el IGMP.Para el Hue, por ser un elemento muy simple no se esperaba que el tráfico UDP do-minara. Como la función de este dispositivo es prácticamente ser un apagador remoto,se esperaba mayor tráfico en el protocolo TCP. En la Figura 4.57 se aprecia como eltráfico UDP comprende el 81% de los datos mientras que el TCP solamente un 17%.El IGMP con un 2% es prácticamente despreciable.

Figura 4.57: Distribución de protocolos para el dispositivo de iluminación Hue. Se com-pone de un 81% de tráfico UDP contra un 17% de TCP. Apenas un 2% de IGMP.

Al analizar el protocolo UDP, éste se descompone en tres bloques de protocolos,dos de presencia nula y uno con la totalidad del tráfico. El SSDP fue el protocolocon un 99% de presencia en el flujo UDP, mientras que los protocolos mDNS, NTP yBOOTP apenas suman el 1% entre los 3. En la Figura 4.58 se muestra la distribuciónde éste tráfico. BOOTP es un protocolo de arranque, significa Bootstrap Protocol. Esun protocolo de red UDP utilizado por los clientes de red para obtener su direcciónIP automáticamente. Normalmente se realiza en el proceso de arranque de las compu-

97

tadoras o del sistema operativo, por esa razón tiene un porcentaje de presencia tan bajo.

Figura 4.58: Distribución de protocolos UDP para el dispositivo de iluminación Hue.Casi el 100% de su tráfico es únicamente SSDP.

Al revisar los datos de TCP, se muestra que el tráfico fue casi divido en dos entre losprotocolos HTTPS y HTTP. En este caso, según la Figura 4.59, el protocolo HTTPSestuvo presente en un 65% del tráfico, mientras que el HTPP un 34%.

La caracterización de los dispositivos por sus diferentes tipos de protocolos utiliza-dos en sus comunicaciones permite identificar las vulnerabilidades de cada dispositivo.Equipos del tipo de info entretenimiento utiliza mucho el protocolo HTTPS mientrasque iluminación y seguridad utiliza el HTTP que es inseguro. A nivel de transportepermite caracterizar un poco más generalizado el dispositivo y en complemento conlos análisis de las secciones anteriores se genera un identificador más preciso para ladirección de ataques y posibles vulnerabilidades de los dispositivos en la revelación deinformación personal.

98

Figura 4.59: Distribución de protocolos TCP para el dispositivo de iluminación Hue.La mayor parte de su tráfico es https y en menor medida el http.

4.11. Resumen comparativo: Huella del dispositivo

A modo resumen, se genera este apartado para comparar todos los resultados obte-nidos en la caracterización de tráfico de los distintos dispositivos del experimento. Loprimero analizado en esta investigación fue la distribución de paquetes por su tamañoen la comunicación de cada uno de ellos. Para resolverlo se hizo la agrupación de pa-quetes como se muestra en la sección 4.1 en la página 41 o en la Tabla 4.1 en la página 50.

En la Tabla 4.3 se muestran la huella dejada por el análisis de tamaño de paquetesen la primera fila, el porcentaje que antecede a cada letra, corresponde a su magnituden la gráfica. Por lo tanto, si se cuenta con un análisis de paquetes para comparar y sedesconoce el dispositivo, ya se tiene un punto de comparación para empezar a suponerde qué tipo de aparatos se trata. Para esta misma tabla, en las fila siguientes, se indicantambién la cantidad de países a los cuales se contactaron y mantuvieron cierta comu-nicación. Lo mismo la cantidad de dominios consultados con frecuencia, la cantidad depeticiones de DNS por hora, el comportamiento del tráfico de subida respecto al debajada y los protocolos utilizados en su comunicación. Esta información es el corazón

99

Tabla 4.3: Resumen de la huella de los dispositivos analizadosDispositivos IoTAnálisis Foscam BabyCam SmartBox SmartTV Hue

Tamaño depaquetes

11%C24%D63%F

35%C16%E12%G27%H

13%C25%D58%H

25%C17%D57%H

39%C52%F

País demanufactura China USA China Korea Europea

Paísescontactados 11 2 10 3 3

DominiosConsultados 5 3 12 16 5

DNS por hora 127 108 7 55 prom 9 promUplink vsDownlink TS TS TB TB TS

Protocolosutilizados

TCP 9.34%:HTTP=99.92%HTTPS=0.08%

UDP 99%:SCP 88.23%DOF 8.9%NTP 2.74%

TCP 93%:HTTP=96%HTTPS=3%DLS=1%

UDP 7%:SSDP 85%mDNS 8%NTP 7%

TCP 23%:HTTP=0.5%HTTPS=99%

HPVROOM=0.5%

UDP 77%:HTTPS 99%otros 1%

TCP 99.5%:HTTP=99.5%HTTPS=0.5%

UDP 0.5%:SSDP 99%DOF 0.5%NTP 0.5%

TCP 17%:HTTP=34%HTTPS=66%

UDP 81%:SSDP 99%

mDNS 0.01%NTP 0.48%Bootp 0.23%IGMP 2%

de los resultados de la caracterización del tráfico de los dispositivos IoT en Costa Rica.

Un aspecto que no fue considerado en el estudio fue el país en el cuál radica laempresa manufacturera del aparato. En esta misma Tabla 4.3 se incluye y refleja datosinteresantes. En un principio, la tercera fila de los países de origen del dispositivo estánestrechamente relacionados con la cantidad de países a los que se contacta y por ejem-plo, los provenientes de China representan un mayor riesgo a la privacidad por tenermayores cantidades de países en sus comunicaciones.

Los dispositivos de infoentretenimiento muestran una clara tendencia a tener valo-res más altos en la cantidad de dominios consultados, los otros grupos permanecieroncon valores menores a seis dominios. Sin embargo las consultas por hora son más bajasque los elementos de seguridad. Estos otros dispositivos tuvieron consultas en un rangomayor a cien por hora, mientras que infoentreteniemiento se mantuvo en 55 o menor yel grupo de iluminación obtuvo valores mucho más bajos, menores a diez.

100

Como era de esperarse, los dispositivos de seguridad tienen un tráfico de subidadominante sobre el de bajada, contrario a los del grupo de infoentretenimiento donde eltráfico de bajada fue dominante. Para el caso del dispositivo de iluminación, se esperabaque el tráfico de subida y bajada fuera bastante simétrico, sin embargo se comportó dela misma manera que un dispositivo de seguridad.

Con respecto a los protocolos, se muestra como la cámara de seguridad hace uso delprotocolo SCP (Secure CoPy el cuál hace referencia a transferencia de archivos de unlugar a otro. Muy posiblemente se deba a la transferencia de imágenes hacia la nube, yaque representan un gran porcentaje de si transmisión. El smartbox utilizó en su mayoríatráfico HTTPS contrastando con el babycam y el televisor que usaron tráfico HTTPnormal. El dispositivo de iluminación fue muy diferente en este análisis ya que en sumayoría utilizó trafico SSDP.

Tabla 4.4: Resumen de capturas para todos los dispositivos utilizados. Se especifica eltipo de dispositivo, la fecha de inicio y fin de captura de paquetes, la cantidad de díascapturados y la totalidad de paquetes en la captura.

Dispositivo Inicio Fin Días Cantidad de PaquetesFoscam 03/04/2018 02/05/2018 29 3.270.644

BabyCam 04/04/2018 02/05/2018 27 1.195.829SmartBox 11/04/2018 28/04/2018 16 510.878SmartTV 12/04/2018 01/05/2018 19 11.741.537

Hue 08/05/2018 21/05/2018 12 345.947

Para finalizar, se generó un resumen de las capturas en la Tabla 4.4 donde se mues-tran la cantidad de días capturados en el experimento, así como la fecha de inicio y finde la misma. Cada dispositivo por su naturaleza generó una cantidad de paquetes muydistinta, siendo el televisor el dispositivo con mayor cantidad.

101

Capítulo 5

Conclusiones

Durante el experimento se trabajó con un hogar costarricense típico, representadopor un padre, una madre y un hijo. Normalmente, entre semana el niño permanecíaen casa con una tercera persona adulta que fungía el rol de cuidadora. El experimentoconsistió en la instalación de varios dispositivos IoT en el hogar representativos de losprimeros tres tipos de dispositivos resultado de una encuesta realizada en el reportetécnico RPT01-01-1312-2018. Se realizó una captura constante del tráfico para su aná-lisis y caracterización.Se revisaron los datos con diferentes escenarios para cada uno de los dispositivos ycomo resultado se obtuvo una caracterización denominada huella, la cual refleja unaidentificación de cada tipo de dispositivo.

Selección de dispositivos representativos al territorio nacionalSe trabajó con 5 dispositivos categorizados en los tres grupos de mayor penetra-ción en el país. La muestra utilizada superó las expectativas planteadas al iniciodel proyecto y representa una muestra de dispositivos bastante aceptable paraobtener resultados. Para este caso particular, la selección de dispositivos fue cum-plida con equipos representativos de la realidad nacional, lo que llevó a satisfacerel primer objetivo específico de la investigación.

Diseño satisfactorio del capturadorEl elemento capturador de tráfico fue diseñado satisfactoriamente. En un principiose utilizó sólo con dispositivos inalámbricos, pero la incorporación de elementos de

103

iluminación, en un capturador ya en funcionamiento, agregó un poco de compleji-dad al sistema. Al concluir por completo el diseño, se logró obtener un dispositivocapturador de tráfico de forma transparente al tráfico de todos los elementos. Elbinario tshark fue fundamental para lograr obtener las capturas de tráfico de for-ma segura y manejable por medio de scripts de bash en un entorno linux.

Caracterización del tráfico de los dispositivosEl análisis posterior a la caracterización del tráfico reveló la facilidad con la queestos dispositivos pueden ser utilizados para determinar datos privados del usuarioy los riesgos de seguridad asociados. El tercer objetivo de la investigación secumplió casi en su totalidad ya que por limitaciones de tiempo no fue posiblerealizar un experimento extra de bloqueo de IPs al exterior.

Los dispositivos IoT, por su naturaleza, están siempre conectados a Internet.Dispositivos como el televisor y el smart box, permanecían sin uso, apagados, perocon tráfico reducido de tipo uplink. Las cámaras no tienen el modo apagado porlo que siempre estuvieron activas, pero al no presenciar acciones en sus sensores,no generaron tráfico. Este comportamiento es un riesgo muy claro que permitedemostrar cuando hay presencia de personas o inactividad en la casa.

Los metadatos son suficientes para obtener información privadaEl cifrado aplicado por cada uno de los dispositivos complicó identificar si lainformación contenida representaba algún riesgo de privacidad, sin embargo nofue necesario incursionar en este tema ya que se utilizaron los metadatos de lascomunicaciones para obtener una huella de cada dispositivo y revelar patronesde comportamiento. Por medio de este análisis fue sencillo demostrar las brechasen la seguridad desde el punto de vista de la privacidad. Casos como aumentosde solicitudes de DNS mientras hay personas en la casa, aumento en el tráficode subida o bajada con patrones y horarios bastantes claros son parte de losresultados que deben ser atacados como parte de un trabajo a futuro, en buscade la seguridad.

El país de origen está relacionado con riesgos a la privacidadLa casa matriz manufacturera de cada uno de los dispositivos fue un aspecto que

104

reflejó resultados interesantes respecto a la cantidad de países en comunicacióncon el dispositivo. En un principio este factor no fue considerado como parte de lacaracterización, sin embargo los resultados indican que sí es importante. En estecaso, equipos fabricados en Estados Unidos o Europa tuvieron comunicaciones conmenos países destino que los de manufactura asiática, específicamente China. Ensus comunicaciones podría indicarse que los dispositivos de marcas con renombreson más seguros que otras marcas menos conocidas.

Relación entre la cantidad de personas y solicitudes de DNS en el trá-ficoSegún los resultados, el tráfico de subida y bajada y solicitudes DNS tienen unaestrecha relación con la estancia de personas en el hogar. Entre más personasexistan en la casa, mayor será la cantidad de solicitudes de resolución de nombres(DNS request). Similar ocurre con el tráfico, ya sea de bajada o de subida, de-pendiendo del dispositivo se logró demostrar que existen patrones en la estanciadel hogar que ponen en evidencia su privacidad. El único dispositivo que no pre-sentó comportamientos relacionados fue el Hue del grupo de iluminación por suscaracterísticas intrínsecas.

5.1. Trabajo Futuro y Recomendaciones

Como continuación del proyecto, se pueden plantear sistemas de seguridad y some-terlo a pruebas de manera que los dispositivos tengan IPs dinámicas o móviles que loshagan más difícil de rastrear en una captura de tráfico. Se debe pensar en hardware ysoftware que permita generar redes de dispositivos IoT más seguras.

Se debe hacer el experimento de bloquear IPs o dominios para registrar el comporta-miento de los equipos. Este experimento no se pudo realizar por limitaciones de tiemposin embargo, no representaba un alcance importante dentro de los objetivos específicosdel documento. Algunos dispositivos permiten el funcionamiento utilizando sólo la redlocal sin necesidad del Internet, pero pierden las características del IoT.

105

A modo de recomendación, se puede reproducir este experimento concentrándoseen dispositivos de la misma clasificación, por ejemplo seguridad. Utilizar escenariosespecíficos de manera controlada y de manera que cada una de las cámaras tengan lamisma posibilidad de registrar el mismo escenario. De esta forma, se pueden analizarmejor las similitudes y diferencias. Otro punto por revisar es utilizar diferentes marcaso software, por ejemplo la caja de televisión utilizada en este experimento trabaja conAndroid, puede compararse con sistemas operativos de Apple.

106

Bibliografía

[Ash09] K. Ashton. That ’internet of things’ thing in the real world, things matter more than ideas.FID Journal, June 2009.

[BBF+17] Karthikeyan Bhargavan, Ioana Boureanu, Pierre Alain Fouque, Cristina Onete, and Ben-jamin Richard. Content delivery over TLS: A cryptographic analysis of keyless SSL. Pro-ceedings - 2nd IEEE European Symposium on Security and Privacy, EuroS and P 2017,2017-April:600–615, 2017.

[BR17] Bharat Bhushan and Amit Kumar Rai. Security vulnerabilities , attacks and counter-measures in wireless sensor networks at various layers of OSI reference model : A Survey.(July):288–293, 2017.

[DeM17] Rodrigo DeMarinis, Nicholas Fonseca. Toward usable network traffic policies for iot devicesin consumer networks. Proceedings of the 2017 Workshop on Internet of Things Securityand Privacy - IoTS&P ’17, pages 43–48, 2017.

[Dor17] S. Jurdak R. Gauravaram P. Dorri, A. Kanhere. Blockchain for iot security and privacy:The case study of a smart home. IEEE International Conference on Pervasive Computingand Communications Workshops (PerCom Workshops), 2017.

[dT16] Departamento de Análisis Económico y Mercados de Telecomunicaciones. Acceso y uso delos servicios de telecomunicaciones en Costa Rica. Technical report, Ministerio de Ciencia,Tecnología y Telecomunicaciones (MICITT), San José, Costa Rica, 2016.

[DT17] Resul Das and Gurkan Tuna. Packet tracing and analysis of network cameras with Wires-hark. 2017 5th International Symposium on Digital Forensic and Security, ISDFS 2017,2017.

[Fou18] Wireshark Foundation. tshark online documentation. Wireshark Foundation, 2018.

[GG17] Piyush Goyal and Anurag Goyal. Comparative Study of two Most Popular Packet SniffingTools- Tcpdump and Wireshark. 2017 9th International Conference on ComputationalIntelligence and Communication Networks, pages 77–81, 2017.

[GKN+17] Dimitris Geneiatakis, Ioannis Kounelis, Ricardo Neisse, Igor Nai-Fovino, Gary Steri, andGianmarco Baldini. Security and privacy issues for an IoT based smart home. 2017 40thInternational Convention on Information and Communication Technology, Electronics andMicroelectronics (MIPRO), pages 1292–1297, 2017.

107

[JM07] Zhang Jian and Andrew Moore. Traffic trace artifacts due to monitoring via port mirro-ring. In Fifth IEEE/IFIP Workshop on End-to-End Monitoring Techniques and Services,E2EMON’07, 2007.

[Kom14] E. Pitsillides A. Komninos, N. Philippou. Survey in smart grid and smart home secu-rity: Issues, challenges and countermeasures. IEEE Communications Surveys & Tutorials,16(4):1933–1954, 2014.

[Lan15] Biswajit Langthasa. Classification of Network Traffic in LAN. 2015 International Confe-rence on Electronic Design, Computer Networks & Automated Verification (Edcav), pages92–99, 2015.

[LLCZ11] Yadong Li, Danlan Li, Wenqiang Cui, and Rui Zhang. Research based on OSI model. 2011IEEE 3rd International Conference on Communication Software and Networks, ICCSN2011, pages 554–557, 2011.

[Pos] Harbor Research Postscapes. Internet of things infographic.

[RAG18] Chavarría Jiménez Fabio Gómez Rodríguez Carlos Vargas Morales Juan José Ramírez Ara-na Gonzalo, Barrantes Sliesarieva Gabriela. Reporte técnico rpt01-01-1312-2018 encuestapreliminar sobre uso de dispositivos iot en cr. Technical report, Universidad de Costa Rica,2018.

[Ruf08] Mark A. Dye Rick McDonald Antoon W. Rufi. Aspectos Básicos de Networking. PearsonEducación, S.A., 2008.

[SGV+15] Vijay Sivaraman, Hassan Habibi Gharakheili, Arun Vishwanath, Roksana Boreli, and Oli-vier Mehani. Network-level security and privacy control for smart-home IoT devices. 2015IEEE 11th International Conference on Wireless and Mobile Computing, Networking andCommunications, WiMob 2015, pages 163–167, 2015.

108

Caracterización del tráfico de dispositivos de IoT usados...

Documents

Transcript of Caracterización del tráfico de dispositivos de IoT usados...