Tesis Prototipo Blockchain

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 88

universidad distrital francisco josé de caldas

DESARROLLO DE UN PROTOTIPO BASADO EN


BLOCKCHAIN APLICADO A LA PLATAFORMA IOT
SOBRE UN SISTEMA EMBEBIDO

proyecto de grado
para obtener el tı́tulo de

Ingeniero Electrónico

presenta

esteban adrian restrepo e


daniel arturo olaya u
Director: Ing Msc Roberto Ferro Escobar

Bogotá D.C., Colombia 2018


2
Índice general

Índice de figuras 1

Resumen 3

Planteamiento del problema 4

Justificación 6

Objetivos 7
Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Objetivo Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Marco Teórico 8
Sistemas embebidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
El internet de las cosas (IoT). . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Tecnologı́as de identificación, detección y comunicación . . . . . . . . . 11
Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Clasificación de los problemas de seguridad . . . . . . . . . . . . . . . 15
Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Transferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Servidor de marca de tiempo . . . . . . . . . . . . . . . . . . . . . . . 20
Prueba de trabajo (Proof-of-work) . . . . . . . . . . . . . . . . . . . . 21
Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Privacidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Contratos inteligentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Estado del arte 24


Blockchain Platform for Industrial Internet of Things . . . . . . . . . . . . . 24
Autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3
4 ÍNDICE GENERAL

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Blockchain for IoT Security and Privacy: The Case Study of a Smart Homes 25
Autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Towards an Optimized Blockchain for IoT . . . . . . . . . . . . . . . . . . . 26
Autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A Blockchain Connected Gateway for BLE-based Devices in the Internet of
Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Desarrollo 30
Prototipo IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Fase no segura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Fase segura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Desarrollo Smart Contract 42


Programación del contrato . . . . . . . . . . . . . . . . . . . . . . . . . 42
El Smart Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Instalando ambiente de trabajo para la prueba del Smart Contract . . 49
Prueba del contrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Implementación Smart Contract en la Red de Nodos RITA . . . . . . . . . 51
Diseño de la página web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Resultados y análisis de resultados 55

Conclusiones 58

Anexos 60
0.1. Blink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Blink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
0.2. Conexión Wi-Fi MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Conexión Wi-Fi MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . 60
0.3. Visualizar concentración de CO2 MQTT . . . . . . . . . . . . . . . . . 62
Visualizar concentración de CO2 MQTT . . . . . . . . . . . . . . . . . 62
0.4. Conexión y búsqueda en bases de datos . . . . . . . . . . . . . . . . . 64
Conexión y búsqueda en bases de datos . . . . . . . . . . . . . . . . . 64
0.5. Código php búsqueda en base de datos . . . . . . . . . . . . . . . . . . 66
Conexión Wi-Fi MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . 66
0.6. Código para comprobar conexión con el nodo . . . . . . . . . . . . . . 67
Conexión nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ÍNDICE GENERAL 5

0.7. Código para enviar el UID y nivel de CO2 a el nodo . . . . . . . . . . 69


Envı́o de UID y nivel de CO2 . . . . . . . . . . . . . . . . . . . . . . . 69
0.8. Smart Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Smart Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
0.9. Despliegue del contrato . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Despliegue del contrato . . . . . . . . . . . . . . . . . . . . . . . . . . 77
0.10. Código página web inicio de sesión . . . . . . . . . . . . . . . . . . . . 77
Programación pagina web inicio de sesión . . . . . . . . . . . . . . . . 77
0.11. Código de la segunda página . . . . . . . . . . . . . . . . . . . . . . . 79
Código de la segunda página . . . . . . . . . . . . . . . . . . . . . . . 79

Bibliografı́a 81
6 ÍNDICE GENERAL
Índice de figuras

1. Arquitectura SOA para middleware S. Li and Zhao (2015) . . . . . . . 12


2. Principales dominios de aplicación S. Li and Zhao (2015) . . . . . . . 14
3. Modelo de red centralizada y red descentralizada(Preukschat, 2017) . 19
4. Proceso de transacción(Nakamoto, 2008) . . . . . . . . . . . . . . . . . 20
5. Marca de tiempo(Nakamoto, 2008) . . . . . . . . . . . . . . . . . . . . 21
6. Prueba de trabajo (Nakamoto, 2008) . . . . . . . . . . . . . . . . . . . 21
7. Conexión Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Parámetros conexión y definición de variables . . . . . . . . . . . . . . 32
9. Conexión al brocker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Aplicación MQTT Dashboard (configuración a la izquierda y compro-
bación a la derecha) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Tabla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
13. Archivo php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14. Conexión a el servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15. Conexión al nodo por medio de HTTP client . . . . . . . . . . . . . . 38
16. Código para crear la solicitud en formato JSON . . . . . . . . . . . . 39
17. Verificación de la solicitud y respuesta . . . . . . . . . . . . . . . . . . 39
18. Hash de las funciones del contrato . . . . . . . . . . . . . . . . . . . . 40
19. Conversión y concatenación de parámetros data . . . . . . . . . . . . 41
20. Conversión result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
21. Estados y definiciones del sistema . . . . . . . . . . . . . . . . . . . . 43
22. Funciones del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
23. Funciones para añadir o editar sensores . . . . . . . . . . . . . . . . . 45
24. Código de interacción con los datos de PPM . . . . . . . . . . . . . . 46
25. Prueba de contrato en Remix . . . . . . . . . . . . . . . . . . . . . . . 48
26. Cuentas simuladas por medio de testrpc . . . . . . . . . . . . . . . . . 50
27. Conexión de la pagina Remix con los nodos de testrpc . . . . . . . . . 50
28. Lineas de código despliegue del Smart Contract en la red de nodos de
RITA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

1
29. Inicio de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
30. Página donde se modificaran los datos que almacena el Smart Contract 53
31. Diagrama de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
32. Diagrama de uso del sistema embebido . . . . . . . . . . . . . . . . . 54
33. Máximo ppm permitido para el sistema embebido con UID 2147483647 55
34. Resultados obtenidos por el monitor serie . . . . . . . . . . . . . . . . 56
35. LED encendido (azul) al superar el valor máximo permitido . . . . . 57

2
Resumen

En este documento se describe la implementación paso a paso de un contrato in-


teligente (Smart Contract) con un dispositivo IoT para la generación de alertas en la
medición de una variable de contaminación del medio ambiente, esta alerta se genera
cuando se pasa un valor umbral definido para un sensor especifico, con el fin de tener
mas seguridad y control a través de dispositivos conectados a internet a la hora de
medir estos niveles de contaminación en una ciudad inteligente.

Se mostrará y se describirá el paso a paso para la conexión del dispositivo IoT


a la red Blockchain de RITA de la Universidad Distrital, el desarrollo de un smart
contract y sus funciones, el despliegue del contrato en una red de nodos, una página
web para agregar sensores por el UID del sistema embebido, realizar modificaciones
a el valor máximo permitido y por ultimo se mostrará los resultados de la conexión
del dispositivo IoT y los valores que retorna cuando se genera una alerta. El trabajo
se realizó para mostrar las funcionalidades de la tecnologı́a Blockchain utilizando las
herramientas que posee el grupo de investigación RITA.

3
Planteamiento del problema

La seguridad informática empezó a tener un significado importante desde los datos


personales empezaron a circular a través de redes como internet, ya que personas no
autorizadas podı́an acceder a información sensible, como cuentas bancarias o historial
médico. Aunque existen varios protocolos para elevar la seguridad en el transporte
de este tipo de datos, aun son vulnerables los servidores en los cuales se encuentra
alojada esta información.

Con el advenimiento de casas inteligentes, ciudades inteligentes, la Internet de las


cosas (IoT) se ha convertido en un área de impacto increı́ble, alto potencial y cre-
cimiento, tanto que Cisco Inc. ha hecho la predicción de tener 50 mil millones de
dispositivos conectados para el año 2020 (Evans et al., 2011), gracias al continuo
desarrollo tecnológico y la miniaturización de los dispositivos electrónicos. En el 2012
la iniciativa mundial de estándares sobre el internet de las cosas (IoT-GSI), definió
IoT como “La infraestructura de la sociedad de la información”. IoT incluye conexión
entre los objetos, por lo que se tiene sistema máquina a máquina (M2M), donde cada
equipo interactúa con otros equipos que pueden replicar lo que sucede en el mundo
real, cada objeto puede proporcionar información de un usuario.

Sin embargo, la mayorı́a de estos dispositivos IoT son limitados en capacidad de


procesamiento, almacenamiento y capacidad de red, y por lo tanto son más vulnera-
bles a los ataques que otros dispositivos, tales como teléfonos inteligentes, tabletas u
ordenadores. Teniendo en cuenta esto, se podrı́a presentar una gran cantidad de pro-
blemas legales relacionados con la privacidad y la ley de protección de datos (Fabiano,
2017).

La seguridad y la privacidad de IoT siguen siendo un gran desafı́o, principalmente


debido a la escala masiva y la naturaleza distribuida de las redes de IoT. Una forma
de abarcar y mitigar este problema, puede ser con un enfoque basado en Blockchain,
pues proporciona seguridad y privacidad descentralizadas, sin embargo, puede no ser
aplicable a dispositivos con recursos limitados.

4
Blockchain es una estructura de datos distribuida que se replica y se comparte entre
los miembros (nodos) de una red, funciona de manera descentralizada sin necesidad
de una autoridad central. El uso de la criptografı́a es una caracterı́stica clave del
Blockchain la cual brinda autenticidad en todas las interacciones (Christidis and De-
vetsikiotis, 2016).

La mayorı́a de dispositivos IoT están basados en sistemas embebidos,son de bajo


consumo energético y ligeros. Estos dispositivos deben dedicar la mayor parte de su
energı́a y computación disponibles para ejecutar la funcionalidad de la aplicación
principal, lo que hace que la tarea de respaldar de manera económica la seguridad y
la privacidad sea todo un desafı́o (Roman et al., 2013). En consecuencia, IoT exige
una protección de seguridad y privacidad ligera, escalable y distribuida. La tecnologı́a
Blockchain (BC), tiene el potencial de superar los desafı́os antes mencionados como
resultado de su naturaleza distribuida, segura y privada (Dorri et al., 2017b).

En esta investigación se planeta la integración de Blockchain a un sistema embe-


bido integrando la plataforma IoT, para garantizar a través de la red de Blockchain
de la Universidad Distrital, la confiabilidad de los datos entregados por los sensores
del dispositivo.

5
Justificación

Al investigar nuevas tecnologı́as en seguridad informática se abre una puerta de


emprendimiento, creando empresa que preste un servicio en el cual la principal tarea
serı́a proteger la información utilizando una red de nodos, aplicando el concepto de
Blockchain para tener una base de datos descentralizada y que los datos se puedan
transportar y consultar teniendo el menor riesgo en perdida y robo de datos por parte
de terceros.

La llegada de la conexión de internet a los objetos que nos rodean en nuestro dia-
rio vivir como las cámaras de seguridad, interruptores para encender o apagar una
lámpara, que podemos consultar y manipular desde cualquier lugar, nos facilita la
forma de interactuar en un espacio determinado sin la necesidad de estar presentes,
estos objetos obtienen información constante a través de sus sensores, de igual ma-
nera como nos pueden facilitar las formas que hacemos nuestras tareas diarias, hay
personas que pueden aprovechar estos dispositivos para obtener información de otros
sin su consentimiento, esta parte hace que las personas y empresas no tengan total
confianza con los dispositivos IoT por miedo a la filtración de datos, con este pro-
yecto se pretende conectar un sistema embebido a internet utilizando la tecnologı́a
Blockchain, permitiendo aprovechar sus caracterı́sticas de transparencia, seguridad y
privacidad, ası́ como el desarrollo de aplicaciones y despliegue de contratos inteligen-
tes con el fin de disminuir las fugas de información, buscando aumentar la confianza
de los consumidores en los dispositivos IoT para ampliar el uso de estos dispositivos
tanto en las casa como en las empresas y automatizar el funcionamiento de las redes
IoT reduciendo la intervención humana por medio de los contratos inteligentes.

6
Objetivos

Objetivo General
Desarrollar un prototipo basado en un sistema embebido de bajo coste aplicado a
la plataforma IoT que permita interactuar con una red Blockchain.

Objetivos Especı́ficos
Desarrollar un dispositivo prototipo IoT con base en un sistema embebido.
Poner en funcionamiento la red de nodos Blockchain de la red RITA con el fin de
establecer la conexión con el dispositivo IoT y hacer el despliegue del contrato.

Desarrollar un portal Web que permita visualizar y consultar los parámetros


provenientes del sistema embebido y realizar pruebas de seguridad en un sensor
aplicado a IoT.
Ejecutar un contrato inteligente para un sistema embebido que permita probar
la versatilidad de un esquema de seguridad bajo Blockchain.

7
Marco Teórico

Sistemas Embebidos.
El microprocesador ha tomado un papel importante en el diseño y fabricación de
sistemas embebidos, la incrustación de microprocesadores en equipos y dispositivos
de consumo comenzó antes de la aparición de la PC y consume la mayorı́a de los
microprocesadores que se fabrican actualmente. De esta forma, los microprocesadores
embebidos están más profundamente arraigados en la vida cotidiana que cualquier
otro circuito electrónico que se realice. Los sistemas embebidos se pueden utilizar en
un sin número de aplicaciones donde el objetivo es controlar un aspecto de un sistema
fı́sico, como la temperatura, el movimiento, etc. usando una variedad de entradas. Con
el reciente advenimiento de la era digital que reemplaza a muchas de las tecnologı́as
analógicas en el mundo de los consumidores, el dominio del sistema embebido es cada
vez mayor (Heath, 2002).
Un sistema embebido es un sistema basado en microprocesador que está diseñado
para controlar una función o un rango de funciones. Este se compone de procesador,
memoria, periféricos y software. El procesador es el encargado de proporcionar la
potencia de procesamiento necesaria para realizar las tareas dentro del sistema. La
memoria tiene dos funciones:
Proporcionar almacenamiento para el software que se ejecutará, esto tomará
la forma de alguna memoria no volátil que conserva su contenido cuando se
elimina la energı́a. Puede ser una memoria solo de lectura en el chip (ROM) o
una EPROM externa.
Proporciona almacenamiento para datos tales como variables de programa y
resultados intermedios, información de estado y cualquier otro dato que pueda
crearse a lo largo de la operación. El software necesita algo de memoria para
almacenar variables y para administrar estructuras de software tales como pilas.
Esta información es almacenada en la memoria de acceso aleatorio (RAM).
Un sistema embebido tiene que comunicarse con el mundo exterior y esto lo hacen

8
los periféricos. Los periféricos de entrada generalmente se asocian con sensores que
miden el entorno externo y, por lo tanto, controlan eficazmente las operaciones de
salida que realiza el sistema embebido. De esta forma, un sistema embebido se puede
modelar en tres etapas donde se ingresan datos e información en la primera etapa,
la segunda etapa la procesa antes de que la tercera etapa muestre datos (Heath, 2002).

Los principales tipos de periféricos que se utilizan incluyen:


Salidas binarias: estos son simples pines externos cuyo estado lógico puede ser
controlado por el procesador para que sea un cero lógico (apagado) o uno lógico
(encendido).
Salidas serie: estas son interfaces que envı́an o reciben datos usando uno o dos
pines en un modo en serie
Valores analógicos: mientras que los procesadores operan en el dominio digital,
el mundo natural no lo hace, y tiende a orientarse a valores analógicos. Como
resultado, las interfaces entre el sistema y el entorno externo deben convertirse
de analógico a digital y viceversa.
Display: las pantallas son cada vez más importantes y pueden variar desde LED
simples y pantallas de siete segmentos hasta pequeños paneles LCD alfanuméri-
cos.
Salidas derivadas del tiempo: los temporizadores y contadores son probablemen-
te las funciones más comúnmente utilizadas dentro de un sistema embebido.
Los componentes de software dentro de un sistema embebido a menudo abarcan
la tecnologı́a que agrega valor al sistema y define qué hace y qué tan bien lo hace. El
software puede constar de varios componentes diferentes:
Inicialización y configuración
Sistema operativo o entorno de tiempo de ejecución
El software de aplicaciones en sı́
Manejo de errores
Soporte de depuración y mantenimiento
Por medio del software también es posible ofrecer actualizaciones funcionales y
de mantenimiento, pues el sistema se puede actualizar para mejorar la funcionalidad
y permite que se agreguen nuevas funciones mediante la reprogramación, también es
beneficioso para permitir que los errores se resuelvan mediante el cambio de software
(Heath, 2002).

9
Los algoritmos son los componentes clave del software que hace que un sistema
embebido se comporte de la manera en que lo hace. Pueden ir desde el procesamiento
matemático hasta los modelos del entorno externo que se utilizan para interpretar
información de sensores externos y ası́ generar señales de control. Con la tecnologı́a
digital en uso en la actualidad, los algoritmos que codifican digitalmente los datos
analógicos están definidos por organismos de estándares. Si bien esta estandarización
podrı́a significar que la importancia de seleccionar un algoritmo es mucho menor
de lo que podrı́a pensarse, la realidad es muy diferente. El enfoque en obtener la
implementación correcta es importante ya que, por ejemplo, puede permitir que la
misma función se ejecute en hardware más económico. Como la mayorı́a de los sistemas
embebidos están diseñados para ser comercialmente exitosos, este proceso de selección
es muy importante. Definir e implementar el algoritmo correcto es una operación
crı́tica (Heath, 2002).

El internet de las cosas (IoT).


El internet de las cosas (IoT: Internet of Things) afecta en gran medida nuestra
vida diaria en diversos factores que van desde pequeños dispositivos portátiles que
usamos diariamente hasta grandes sistemas industriales; en consecuencia, se ha desa-
rrollado y desplegado una amplia variedad de aplicaciones de IoT, haciendo que los
dispositivos y el procesamiento de esta plataforma se vuelvan más inteligentes y la
comunicación más informativa. IoT se ha convertido recientemente en un tema de
investigación importante porque integra varios sensores y objetos para comunicarse
directamente entre sı́ sin intervención humana.

Con el rápido crecimiento de los dispositivos inteligentes y las redes de alta veloci-
dad, IoT ha ganado una amplia aceptación y popularidad como el principal estándar
para redes con pérdidas de baja potencia (LLNs) que tienen recursos limitados. IoT
representa una red en la que las “cosas” o dispositivos integrados que tienen sensores,
están interconectados a través de una red en donde se da el intercambio de infor-
mación entre estos dispositivos a través de protocolos especı́ficos. Estos dispositivos
pueden controlarse a distancia para llevar a cabo la funcionalidad deseada.

IoT es un sistema de dispositivos informáticos interrelacionados, máquinas mecáni-


cas y digitales, objetos, animales o personas a los que se proporcionan identificadores
únicos y la capacidad de transferir datos a través de una red sin necesidad de inter-
vención humana. Una cosa, en el Internet de las cosas, puede ser una persona con un
implante de monitor cardı́aco, un animal de granja con un biochip transpondedor, un
automóvil que tiene sensores incorporados para alertar al conductor cuando la presión
de las llantas es baja, o cualquier otro objeto hecho por el hombre que se le puede

10
asignar una dirección IP y se le proporciona la capacidad de transferir datos a través
de una red. La idea básica de este concepto es una variedad de dispositivos tales como
etiquetas, identificadores de radiofrecuencia (RFID), sensores, actuadores, teléfonos
móviles, etc. la cual, a través de esquemas de direccionamiento únicos, son capaces
de interactuar entre sı́ y cooperar con sus vecinos para alcanzar objetivos comunes
(S. Li and Zhao, 2015).

La principal fuerza de la idea de IoT es el alto impacto que tendrá sobre varios
aspectos de la vida cotidiana, la vida y el comportamiento de los usuarios potencia-
les. Desde el punto de vista de un usuario privado, los efectos más evidentes serán
visibles tanto de trabajo y campos domésticos. En este contexto, la domótica, vida
asistida, e-salud, el aumento de aprendizaje son sólo algunos ejemplos de posibles,
pero también existen aplicaciones que suplen necesidades comunitarias, aquı́ varios
dispositivos inteligentes que realizan diversas funcionalidades tales como la cirugı́a de
vigilancia en los hospitales, la detección de las condiciones meteorológicas, seguimien-
to y conectividad en automóviles, y la identificación de animales utilizando biochips
ya están sirviendo a las necesidades especı́ficas de la comunidades (Khan and Salah,
2018).

Una implementación tı́pica de la IoT contiene dispositivos heterogéneos con sensores


incorporados interconectados a través de una red, estos son singularmente identificado
y se caracterizan principalmente por su baja potencia, pequeña memoria y capacidad
de procesamiento limitada. Las gateways están desplegados para conectar dispositi-
vos IoT con el mundo exterior para la prestación remota de datos y servicios a los
usuarios IoT (S. Li and Zhao, 2015).

Tecnologı́as de identificación, detección y comunicación


Las tecnologı́as inalámbricas han jugado un papel clave y en la actualidad la rela-
ción entre radios y los seres humanos se está acercando al valor del 1 al 1. Sin embargo,
la reducción en términos de tamaño, peso, consumo de energı́a, y el coste de la radio,
esto permitirá integrar radios en casi todos los objetos, lo que conduce al concepto de
la IoT (S. Li and Zhao, 2015).

Los componentes claves son los sistemas RFID (Identificadores por radiofrecuencia),
los cuales están compuestos por un lector y varias etiquetas RFID, las cuales contie-
nen una identificación única y se puede aplicar a cualquier objeto. Desde un punto de
vista fı́sico una etiqueta RFID es un pequeño microchip conectado a una antena (que
se utiliza tanto para recibir la señal del lector y la transmisión de la etiqueta). En con-
secuencia, los sistemas RFID pueden ser utilizados para controlar objetos en tiempo
real, sin la necesidad de estar en la lı́nea de visión; esto permite el mapeo del mundo

11
real en el mundo virtual. Por lo tanto, pueden ser utilizados en una increı́blemente
amplia gama de escenarios de aplicación (S. Li and Zhao, 2015).
Las redes de sensores también jugarán un papel crucial en la IoT. De hecho,
pueden cooperar con los sistemas RFID para rastrear mejor el estado de las cosas,
es decir, su ubicación, temperatura, movimientos, etc. Como tales, pueden aumentar
el conocimiento de un determinado ambiente y, por lo tanto, actúan como un puente
entre los más mundo fı́sico y digital. Las redes de sensores consisten en un número
determinado de nodos sensores que se comunican de un modo multi-hop inalámbrico.
Por lo general, los nodos informan de los resultados de su detección a un pequeño
número de los nodos especiales llamados sumideros (S. Li and Zhao, 2015).

Middleware

Figura 1: Arquitectura SOA para middleware S. Li and Zhao (2015)

El middleware es una capa de software o un conjunto de sub-capas interpuestas


entre el los niveles de aplicación tecnológica y su caracterı́stica de ocultar los detalles
de las diferentes tecnologı́as es fundamental para eximir al programador de temas que
no están directamente relacionados con su enfoque, que es el desarrollo de la apli-

12
cación en particular permitido por las infraestructuras de IoT. El middleware está
ganando cada vez más importancia en los últimos años debido a su importante papel
en la simplificación del desarrollo de nuevos servicios y la integración de tecnologı́as
heredadas en otros nuevos. Las arquitecturas de middleware propuesto en los últimos
años para la IoT a menudo siguen el enfoque de la Arquitectura orientada a Servi-
cios (SOA). La adopción de los principios de SOA permite la descomposición de los
sistemas complejos y monolı́ticos en aplicaciones que consisten en un ecosistema de
componentes más simples y bien definidas. El uso de interfaces comunes y protocolos
estándar da una vista horizontal de un sistema de la empresa. Por lo tanto, el desa-
rrollo de procesos de negocios habilitados por el SOA es el resultado del proceso de
diseño de flujos de trabajo de servicios coordinados, lo que eventualmente se asocian
con acciones objetos (S. Li and Zhao, 2015).
Aplicaciones: Las solicitudes están en la parte superior de la arquitectura, la ex-
portación de todas las funcionalidades del sistema para el usuario final. A través
de la utilización de protocolos de servicios web estándar y tecnologı́as de com-
posición de servicios, las aplicaciones pueden realizar una perfecta integración
entre sistemas y aplicaciones distribuidas.
Composición de servicios: Esta es una capa común en la parte superior de una
arquitectura de middleware basada en SOA. proporciona las funcionalidades
para la composición de los servicios individuales ofrecidos por los objetos en red
para crear aplicaciones especı́ficas
Gestión De Servicios: Esta capa proporciona las principales funciones que se
espera que estén disponibles para cada objeto y que permitan su gestión en
el escenario de la IoT. Un conjunto básico de servicios abarca: objeto de des-
cubrimiento dinámico, monitorización del estado y servicio configuración. En
esta capa, algunas propuestas de middleware incluyen un conjunto ampliado de
funcionalidades relacionadas con la gestión de calidad de servicio y gestión de
bloqueo, ası́ como algunas funciones semánticas.
Abstracción de objetos: IoT se basa en un conjunto amplio y heterogéneo de
objetos, cada una proporcionando funciones mercantiles accesibles a través de
su propio dialecto. Por tanto, existe la necesidad de una capa de abstracción
capaz de armonizar el acceso a los diferentes dispositivos con un lenguaje y
procedimiento común. Por consiguiente, a menos que un dispositivo ofrece ser-
vicios web detectables en una red IP, existe la necesidad de introducir una capa
de envoltura, que consiste en dos principales subcapas: la interfaz y las sub-
capas de comunicaciones. La primera se proporciona una interfaz web exponer
los métodos disponibles a través de una interfaz de servicios web estándar y
es responsable de la gestión de todas las operaciones de mensajerı́a entrantes y
salientes involucrados en la comunicación con el mundo exterior.

13
Aplicaciones
Muchos son los dominios y los entornos en los que las nuevas aplicaciones pueden
mejorar la calidad de nuestras vidas. Dar a estos objetos la posibilidad de comunicarse
entre sı́ y para comunicar la información percibida del entorno implican que tienen
una amplia gama de aplicaciones que se puede desplegar. Estos se pueden agrupar
en los siguientes dominios: dominio del transporte y la logı́stica, dominio de la salud,
entorno inteligente (hogar, de oficina, planta), dominio personal y social, y dominio
futurista. Entre las posibles aplicaciones, podemos distinguir entre aquellos que ya sea
directamente aplicable o más cerca de nuestros hábitos actuales y los futuristas, que
de momento aún no se han concretado, ya que las tecnologı́as y/o nuestras sociedades
aún no están listos para su despliegue (S. Li and Zhao, 2015).

Figura 2: Principales dominios de aplicación S. Li and Zhao (2015)

El despliegue de la comunicación automática de objetos en nuestra vida representa


un peligro. De hecho, sin ser visto por los usuarios, las etiquetas incrustadas en nues-
tros dispositivos personales, ropa, tiendas de comestibles, etc, pueden ser activados sin
saberlo, para responder con su ID y otra información. Esto permite potencialmente
un mecanismo de vigilancia que impregnan gran parte de nuestras vidas. Por lo tanto,
para una implementación de la IoT seguro, diversos mecanismos y parámetros tienen
que tener en cuenta como se describe a continuación:
1. Privacidad de datos, confidencialidad e integridad
Como los datos IoT viaja a través de múltiples saltos en una red, se requiere un
mecanismo de cifrado apropiado para asegurar la confidencialidad de los datos.
Debido a una diversa integración de los servicios, dispositivos y la red, los datos

14
almacenados en un dispositivo son vulnerables a la violación de privacidad por
nodos existentes comprometedores en una red de la IoT. Los dispositivos IoT
susceptibles a ataques pueden causar un atacante para impactar la integridad de
los datos mediante la modificación de los datos almacenados con fines maliciosos
(Khan and Salah, 2018).

2. Autenticación, autorización y contabilidad


Para asegurar la comunicación en la IoT, se requiere la autenticación entre dos
partes que se comunican entre sı́. Para un acceso privilegiado a los servicios,
los dispositivos deben ser autenticados. La diversidad de mecanismos de auten-
ticación para la IoT existe debido principalmente a las diversas arquitecturas
subyacentes heterogéneos y entornos que soportan dispositivos. Los mecanismos
de autorización garantizan que el acceso a los sistemas y la información que se
proporciona a los autorizados. Una aplicación adecuada de autorización y au-
tenticación resulta en un ambiente confiable que garantiza un entorno seguro
para la comunicación (Khan and Salah, 2018).

3. Disponibilidad de Servicios
Los ataques a dispositivos IoT pueden dificultar la prestación de servicios a
través de los ataques convencionales de denegación de servicio. Diversas estra-
tegias que incluyan los ataques sumidero, atascos adversarios o los ataques de
repetición explotan componentes de la IoT en diferentes capas a deteriorar la
calidad de servicio (QoS) que se proporciona a los usuarios (Khan and Salah,
2018).

4. Eficiencia energética
Los dispositivos IoT son tı́picamente limitados en recursos y se caracterizan con
baja potencia y menos almacenamiento. Los ataques a las arquitecturas de la
IoT pueden dar lugar a un aumento del consumo de energı́a inundando la red
y agotando los recursos de IoT a través de solicitudes de servicio redundantes o
falsificadas (Khan and Salah, 2018).

Clasificación de los problemas de seguridad


A medida que el paradigma de la IoT abarca una amplia variedad de dispositivos
y equipos que van desde pequeños chips de procesamiento embebidos en servidores
de gama alta y de gran tamaño, que necesita para hacer frente a los problemas de
seguridad en diferentes niveles. Las amenazas a la seguridad se pueden clasificar con
respecto a la arquitectura de implementación de la IoT como se describe a continua-
ción.

15
Los problemas de seguridad de bajo nivel El primer nivel de seguridad
se ocupa de los problemas de seguridad en las capas fı́sica y de enlace de datos de
comunicación, ası́ como a nivel de hardware. Algunos problemas relacionados con este
nivel son:

Atascos adversarios: su objetivo es deteriorar la red mediante la emisión de


señales de radio sin seguir un protocolo especı́fico, lo que provoca interferencia,
afectando el comportamiento del sistema (Khan and Salah, 2018).
Inicialización insegura: este recae en la capa fı́sica en el cual un mecanismo de
inicialización y configuración debe hacer inaccesible a receptores no autorizados
para garantizar los servicios de la red (Khan and Salah, 2018).
Interfaz fı́sica insegura: su objetivo son la seguridad fı́sica y el acceso a software
a través de interfaces fı́sicas que pueden ser explotadas para comprometer la
integridad de los nodos (Khan and Salah, 2018).
Ataques de privación de sueño: este ataque causa un agotamiento de la baterı́a
de los dispositivos conectados cuando una gran cantidad de tareas son pro-
gramadas, haciendo que los nodos se mantengan despiertos (Khan and Salah,
2018).

Los problemas de seguridad de nivel intermedio: Estos se refieren principalmente a la


comunicación, el encaminamiento y la gestión de sesiones que tienen lugar en red y
de transporte capas de la IoT. Algunos de estos problemas son:
Repetición o duplicación de los ataques debido a la fragmentación: la reconstruc-
ción de paquetes fragmentados puede resultar en el agotamiento de los recursos.
Los fragmentos duplicados enviados por nodos maliciosos afectan el reensam-
blaje del paquete, impidiendo ası́ el procesamiento de otros paquetes legı́timos
(Khan and Salah, 2018).
Descubrimiento de vecinos inseguros: la fase de descubrimiento de vecinos antes
de la transmisión de datos realiza diferentes pasos, incluido el descubrimiento del
enrutador y la resolución de la dirección. El uso de paquetes de descubrimiento
vecinos sin la verificación adecuada puede tener implicaciones graves junto con
la denegación de servicio (Khan and Salah, 2018).
Ataque de reservación de buffer: este ataque resulta en la denegación de servicios,
ya que otros fragmentos de paquetes se descartan debido al espacio ocupado por
los paquetes incompletos enviados por el atacante (Khan and Salah, 2018).
Ataques de enrutamiento RPL: el protocolo RPL es vulnerable a varios ataques
desencadenados a través de nodos comprometidos existentes en la red, lo que

16
puede resultar en el agotamiento de los recursos y las escuchas no autorizados
(Khan and Salah, 2018).

Ataques de sumidero y agujeros de gusano: con los ataques de sumidero, el nodo


atacante responde a las solicitudes de enrutamiento, haciendo que los paquetes
se encaminen a través de este, que luego puede usarse para realizar actividad
maliciosa en la red. Los ataques de agujero de gusano consisten en crear un túnel
entre dos nodos, de modo que los paquetes que llegan a un nodo llegan a otro
nodo inmediatamente. Estos ataques tienen implicaciones graves, que incluyen
espionaje, violación de privacidad y denegación de servicio (Khan and Salah,
2018).

Ataques de Sybil en capas intermedias: los nodos Sybil se pueden implementar


para degradar el rendimiento de la red e incluso violar la privacidad de los datos.
La comunicación por parte de estos nodos utilizando identidades falsas en una
red puede dar como resultado el correo no deseado, la difusión de malware o el
lanzamiento de ataques de phishing (Khan and Salah, 2018).

Autenticación y comunicación segura: los dispositivos y usuarios en IoT necesi-


tan ser autenticados a través de sistemas de administración de claves. Cualquier
brecha en la seguridad de la capa de red o una gran sobrecarga de seguridad de la
comunicación pueden exponer a la red a una gran cantidad de vulnerabilidades
(Khan and Salah, 2018).

Seguridad de nivel de transporte de extremo a extremo: su objetivo proporcio-


nar un mecanismo seguro para que los datos del nodo emisor sean recibidos
por el nodo de destino deseado de manera confiable, para esto se requiere me-
canismos integrales de autenticación que garanticen la comunicación segura de
mensajes en forma encriptada sin violar la privacidad mientras se trabaja con
una sobrecarga mı́nima (Khan and Salah, 2018).

Establecimiento de la sesión y la reanudación: el secuestro de sesión en la capa


de transporte con mensajes falsificados puede dar como resultado la denegación
de servicio. Un nodo atacante puede suplantar al nodo vı́ctima para continuar
la sesión entre dos nodos. Los nodos de comunicación incluso pueden requerir
la retransmisión de mensajes alterando los números de secuencia (Khan and
Salah, 2018).

Violación de la privacidad de la IoT a basada en la nube: se pueden lanzar


diferentes ataques que pueden violar la privacidad de identidad y ubicación en
la nube o redes IoT, también un proveedor de servicios malicioso en la nube
puede acceder a información confidencial que se transmite a un destino deseado
(Khan and Salah, 2018).

17
Los problemas de seguridad de alto nivel: Los problemas de seguridad de alto
nivel se refieren principalmente a las aplicaciones que se ejecutan en la IoT. Los más
comunes son:

Seguridad CoAP con internet: la capa de alto nivel que contiene la capa de apli-
cación también es vulnerable a los ataques. El protocolo de aplicación restringida
(CoAP) es un protocolo de transferencia web para dispositivos restringidos que
usa enlaces DTLS con varios modos de seguridad para proporcionar seguridad
de extremo a extremo. Los mensajes de CoAP siguen un formato especı́fico, que
deben cifrarse para una comunicación segura. De manera similar, el soporte de
multidifusión en CoAP requiere mecanismos adecuados de administración de
claves y autenticación (Khan and Salah, 2018).

Interfaces inseguras: las interfaces utilizadas para acceder a los servicios de IoT,
ya sea a través de la web, dispositivos móviles y la nube son vulnerables a
diferentes ataques que pueden afectar gravemente la privacidad de los datos
(Khan and Salah, 2018).

Software/Firmware inseguros: el código con lenguajes como JSON, XML, SQLi


y XSS pueden contener algún tipo de ataque, por lo que necesita ser proba-
do cuidadosamente. Del mismo modo, las actualizaciones de software/firmware
deben llevarse a cabo de manera segura (Khan and Salah, 2018).

Middleware inseguro: El middleware de IoT diseñado para proporcionar comuni-


cación entre entidades heterogéneas del paradigma de IoT debe ser lo suficiente-
mente seguro para la provisión de servicios. Diferentes interfaces y entornos que
utilizan middleware deben incorporarse para proporcionar una comunicación
segura (Khan and Salah, 2018).

Blockchain
Blockchain es una base de datos descentralizada la cual está repartida en diferentes
ordenadores, está protegida criptográficamente y organizada en bloques de transac-
ciones relacionados matemáticamente entre sı́. Este sistema permite que dos partes
que no confı́an plenamente entre ellas puedan mantener un consenso sobre la exis-
tencia, el estado y una serie de factores compartidos, esto se construye con una red
de ordenadores que gestiona la base de datos, la cual puede ser abierta (Blockchain
pública) o limitada a algunos participantes (Blockchain privada) (Preukschat, 2017).

18
Figura 3: Modelo de red centralizada y red descentralizada(Preukschat, 2017)

Los elementos que componen el sistema de Blockchain son:

Nodo: Un ordenador el cual pertenece a una red Blockchain.

Protocolo: Este protocolo define la forma de comunicación entre los nodos que
están presentes en la red Blockchain.

Sistema descentralizado: Todos los nodos conectados en la red controlan la in-


formación sin tener jerarquı́a entre nodos

En el año 2008, un individuo o grupo que escribe bajo el nombre de Satoshi Naka-
moto publicó un artı́culo titulado ”Bitcoin: un sistema de efectivo electrónico punto a
punto”. Este documento describió una versión de Peer to Peer del efectivo electrónico
que permitirı́a que los pagos en lı́nea se envı́en directamente de una parte a otra sin
pasar por una institución financiera. Bitcoin fue la primera realización de este con-
cepto (Lewis, 2015).

El Bitcoin nace de la necesidad de eliminar un tercero en este caso una entidad


bancaria para realizar transferencias bancarias, creando una red peer to peer, la cual
eliminaba la entidad bancaria reduciendo los costos y el tiempo a la hora de realizar
un envió de dinero de una persona a otra.

Para entender cómo funciona Blockchain, se mostrará el proceso de Bitcoin para


transferencias de dinero.

19
Transferencias

Cada moneda electrónica se define como una cadena de firmas digitales. Cada
propietario transfiere la moneda al siguiente al firmar digitalmente con un hash de la
transacción anterior y la clave pública del próximo propietario, se agregan todas al
final de la moneda. Un beneficiario puede verificar las firmas para verificar la cadena
de propiedad (Nakamoto, 2008).

Figura 4: Proceso de transacción(Nakamoto, 2008)

En este tipo de transacción el beneficiario no sabe si en algún punto se haya


gastado parte de la monedad en la transferencia, para solucionar ese problema cada
transacción debe anunciarse públicamente y la red de nodos debe de tener un único
historial de transferencia.

Servidor de marca de tiempo

Para publicar las transferencias se usa un servidor de marca de tiempo, funciona


tomando un hash de un bloque de elementos para marcar el tiempo y publicando
ampliamente el hash. Ese hash es una evidencia que los datos alguna vez existieron,
cada marca de tiempo, tiene una marca de tiempo anterior formando una cadena.

20
Figura 5: Marca de tiempo(Nakamoto, 2008)

Prueba de trabajo (Proof-of-work)


La prueba de trabajo, es un esfuerzo de cálculo que aplica la CPU para encontrar
un valor que aplicando un hash, este empiece con un número de bits en cero. Para
la red de marca de tiempo se añade un nonce en el bloque hasta que se encuentre
el valor que le da al hash del bloque la cantidad de bits en cero pedidos (Nakamoto,
2008).

Figura 6: Prueba de trabajo (Nakamoto, 2008)

Nonce es un campo de 32 bits el cual su valor está determinado por la cantidad


de bits en ceros sean necesarios en el hash del bloque.

Red
Los pasos que realiza la red son los siguientes:
1. Las nuevas transacciones se transmiten a todos los nodos.
2. Cada nodo recoge nuevas transacciones en un bloque.
3. Cada nodo trabaja para encontrar una prueba de trabajo para su bloque.
4. Cuando un nodo encuentra una prueba de trabajo, transmite el bloque a todos
los nodos.
5. Los nodos aceptan el bloque solo si todas las transacciones en él son válidas.

21
6. Los nodos expresan su aceptación del bloque al trabajar en la creación del
siguiente bloque de la cadena, usando el hash del bloque aceptado como el hash
anterior (Nakamoto, 2008).

Privacidad
Para lograr la privacidad, las claves públicas permanecerán anónimas, las personas
pueden ver que se transfiere dinero de un lugar a otro sin necesidad de saber quiénes
son las personas que están participando en estas transferencias. Además de esto, para
cada transferencia se genera un par nuevas de claves. El problema radica que al rela-
cionar a una persona con su clave pública, se puede encontrar las otras transacciones
que pertenecen a ese usuario (Nakamoto, 2008).

Contratos inteligentes.
Nick Szabo introdujo este concepto en 1994 y definió un contrato inteligente como
ün protocolo de transacción computarizado que ejecuta los términos de un contrato”.
Szabo sugirió traducir cláusulas contractuales en código e insertarlas en propiedades
(hardware o software) que puedan autoejecutarlas, para minimizar la necesidad de
intermediarios confiables entre las partes que realizan transacciones, y la ocurrencia
de excepciones maliciosas o accidentales. Dentro del contexto Blockchain, los contra-
tos inteligentes son scripts almacenados en Blockchain, como residen en la cadena,
tienen una dirección única y se activan al hacerle una transacción. A continuación, se
ejecuta de forma independiente y automática de forma predeterminada en cada nodo
de la red, de acuerdo con los datos que se incluyeron en la transacción desencadenante
(Christidis and Devetsikiotis, 2016).

Una Blockchain que admite contratos inteligentes permite que se produzcan procesos
de varios pasos (o interacciones) entre contrapartes mutuamente desconfiadas. Las
entidades que realizan transacciones llegan a:

Inspeccionar el código e identificar sus resultados antes de decidir comprome-


terse con el contrato

Tener certeza de ejecución ya que el código ya está implementado en una red


que ninguno de ellos controla completamente

Tener verificabilidad sobre el proceso ya que todas las interacciones están fir-
madas digitalmente.

Se elimina la posibilidad de una disputa (cuando se tienen en cuenta todos los


resultados posibles) ya que los participantes no pueden estar en desacuerdo con res-

22
pecto al resultado final de este proceso verificable en el que participaron (Christidis
and Devetsikiotis, 2016).

23
Estado del arte

Se realizó la búsqueda sobre la tecnologı́a de Blockchain aplicada a los dispositivos


IoT, los datos expuestos en esta parte se extrajeron de la base virtual de la IEEE, de
artı́culos publicados en la revista Journal of Software Engineering and Applications.
Las investigaciones van desde el año 2016 al 2018.

Blockchain Platform for Industrial Internet of Things(Bahga


and Madisetti, 2016)
Autores
Arshdeep Bahga, Vijay K. Madisetti del instituto de tecnologı́a de Georgia escrito
en el año 2016.

Resumen
Los autores proponen mejorar el modelo de fabricación bajo demanda basada en
la nube, ya que este utiliza un intermediario de confianza para las transacciones.
Para eliminar el intermediario desarrollaron una plataforma descentralizada llamada
BPIIoT utilizando la tecnologı́a Blockchain, la cual permite que dos objetos en una
red descentralizada sin confianza puedan interactuar entre ellos.

La plataforma BPIIOT utiliza un computador que hace la conexión con Blockchain,


controlador de conectividad de sensores y cartera Blockchain. Esta plataforma mejo-
ra la fabricación basada en la nube (CBM) proporcionando un registro distribuido,
seguro y compartido de las transacciones, activos y registros, además de facilitar la
interacción entre dos partes evitando un intermediario de confianza. Esta platafor-
ma permitirá un mercado de servicios de fabricación donde cada máquina tendrá su
propia cuenta Blockchain donde los usuarios podrán realizar transacciones con las
maquinas directamente para aprovechar los servicios de fabricación.

24
BPIIOT se implementó en un Beaglebone Black y una placa de Arduino Uno, la
cual estaba equipada con sensores de temperatura y nivel de vibración, utilizando in-
terfaces digitales, analógicas, seriales y USB para captura de los datos. Configuraron
contratos inteligentes que actúan como un acuerdo entre la máquina y los proveedores
de servicios. Fue implementado en Python el servicio controlador que se ejecuta en el
dispositivo IoT, el servicio monitoreaba constantemente la temperatura y vibración
de diferentes partes de la máquina, esto con el fin de detectar si alguna pieza de la
maquina necesitaba reemplazo. Al identificar una pieza de la maquina defectuosa se
realizaba un envió de datos al contrato inteligente entre la máquina y el proveedor de
la pieza pagando el costo de la pieza en criptomoneda (Ethers).

Las ventajas de utilizar una red Blockchain son:


Resistente: La red Blockchain es resistente a fallas ya que es una red descentra-
lizada.
Seguro y auditable: Todas las transacciones en una red Blockchain están prote-
gidas por una fuerte criptografı́a, además de ser públicas cada transacción.
Autónomo: Blockchain puede permitir que los dispositivos IoT realicen transac-
ciones de forma autónoma, asignando a cada dispositivo su cuenta Blockchain.
El desarrollo de la plataforma BIIoT permite un mercado de servicios de fabricación
donde las maquinas tiene sus propias cuentas de Blockchain y los usuarios pueden
realizar transacciones con las maquinas directamente para aprovechar esos servicios.

Blockchain for IoT Security and Privacy: The Case


Study of a Smart Home (Dorri et al., 2017b)
Autores
Ali Dorri, Salil S. Kanhere, Raja Jurdak, Praveen Gauravaram de la Universidad
de New South Wales, en Sydney, Australia, escrito en 2017

Resumen
En este documento los autores continúan con el trabajo realizado de la implemen-
tación de una Blockchain liviana en un entorno doméstico inteligente, describiendo los
diversos componentes básicos del nivel de hogar inteligente y discutiendo las diversas
transacciones y procedimientos asociados con él. Cada hogar inteligente está equipa-
do con un dispositivo siempre en lı́nea de alto recurso, conocido como ”minero”, que

25
se encarga de manejar todas las comunicaciones dentro y fuera del hogar. El minero
también conserva una Blockchain privada y segura, utilizada para controlar y auditar
las comunicaciones. También muestran que el marco propuesto de hogar inteligente
basado en Blockchain es seguro mediante el análisis exhaustivo de su seguridad con
respecto a los objetivos de seguridad fundamentales de confidencialidad, integridad y
disponibilidad.

Los autores siguen los siguientes pasos de inicialización, el manejo de transacciones y


la superposición compartida.
1. Inicialización: En esta sección, describen el proceso de agregar dispositivos y
encabezado de polı́tica a la Blockchain local. Para agregar un dispositivo a la
casa inteligente, el minero genera una transacción de generación compartiendo
una clave con el dispositivo.
2. Manejo de transacciones: Los dispositivos inteligentes pueden comunicarse di-
rectamente entre ellos o con entidades externas al hogar inteligente. Cada dis-
positivo dentro de la casa puede solicitar datos de otro dispositivo interno para
ofrecer ciertos servicios. Para lograr el control del usuario sobre las transaccio-
nes de casa inteligente, se debe asignar una clave compartida por el minero a
dispositivos que necesitan comunicarse directamente entre ellos.
3. Los dispositivos pueden exigir almacenar datos en el almacenamiento en la nube
que se conoce como transacción de almacenamiento.
4. Superposición compartida: Cuando una persona tiene más de un hogar, necesita
mineros y almacenamiento separados para cada una de las casas. Para reducir el
costo y administrar la sobrecarga en esta instancia, se define una superposición
compartida
Los resultados de simulación demuestran que los gastos generales incurridos por este
método son bajos y manejables para dispositivos IoT de bajos recursos, por lo que
cabe resaltar que los gastos generales (en términos de tráfico, tiempo de procesamiento
y consumo de energı́a) introducidos son insignificantes en relación con sus ganancias
de seguridad y privacidad.

Towards an Optimized Blockchain for IoT(Dorri et al.,


2017a)
Autores
Ali Dorri, Salil S. Kanhere, Raja Jurdak de la Universidad de New South Wales,
en Sydney, Australia, escrito en 2017

26
Resumen

Este documento los autores proponen una arquitectura liviana basada en Block-
chain para IoT que elimina virtualmente los gastos generales del Blockchain clásico,
a la vez que mantiene la mayorı́a de sus beneficios de seguridad y privacidad. Los
dispositivos IoT se benefician de un registro privado inmutable, que actúa de forma
similar a Blockchain pero que se gestiona de forma centralizada para optimizar el
consumo de energı́a. Los dispositivos de alto recurso crean una red superpuesta para
implementar un Blockchain distribuido de acceso público que garantiza seguridad y
privacidad de extremo a extremo. La arquitectura propuesta utiliza confianza distri-
buida para reducir el tiempo de procesamiento de validación de bloque. El escenario
escogido fue un entorno doméstico inteligente como un caso de estudio representativo
para aplicaciones de IoT más amplias.

La evaluación cualitativa de la arquitectura bajo modelos de amenazas comunes re-


salta su efectividad al proporcionar seguridad y privacidad para las aplicaciones de
IoT. Las simulaciones demuestran que nuestro método reduce significativamente los
gastos generales de procesamiento y paquetes en comparación con la implementación
de BC utilizada en Bitcoin.

La Blockchain propuesta está especialmente diseñada para su uso en IoT al elimi-


nar la prueba de trabajo (POW) y el concepto de monedas, por lo que no incurre en
retrasos adicionales en el procesamiento de las transacciones generadas. Emplea una
arquitectura jerárquica que utiliza un Registro Inmutable (IL) privado centralizado
en el nivel de red IoT local para reducir gastos generales, y una Blockchain pública
descentralizada en dispositivos de mayor nivel para una mayor confianza. Se emplea
un método de confianza distribuida para disminuir la nueva sobrecarga de procesa-
miento de bloques.

Se evalúa la seguridad y la privacidad del diseño que muestra la solidez de la nueva


arquitectura frente a varios ataques. Los resultados de la simulación demuestran que
el método tiene una baja sobrecarga de paquete y procesamiento. El trabajo futuro
incluye una evaluación más exhaustiva del impacto de las elecciones de diseño en la
seguridad y los gastos generales en la superposición, y un análisis exhaustivo sobre el
consenso y la seguridad.

27
A Blockchain Connected Gateway for BLE-based De-
vices in the Internet of Things (Cha et al., 2018)
Autores
Shi-Cho cha, Jyun-Fu Chen, Chunhua Su y Kuo-Hui Yeh del año 2018

Resumen
En este artı́culo se propone el diseño de Blockchain Connected Gateway (puerta
de enlace BC). En la cual busca evitar la fuga de privacidad de cada usuario a través
de la puerta de enlace la cual protege el acceso a los datos de los usuarios sin su
aprobación, proponiendo un mecanismo de firma digital para fines de autenticación y
gestión segura de las preferencias de privacidad.

En este escenario hay tres actores principales que involucra la puerta BC, los cuales
son:

1. Los propietarios o administradores de los dispositivos IoT

2. Los administradores de la puerta de enlace

3. Usuarios finales

La plataforma de Blockchain Ethereum fue la elegida por su capacidad para ejecu-


tar y hacer cumplir contratos inteligentes, en estos contratos el administrador de los
dispositivos IoT puede almacenar y administrar la información de las caracterı́sticas
principales de un dispositivo IoT (nombre del dispositivo, modelo, etc.) y las carac-
terı́sticas de privacidad. También se propone un contrato inteligente para la puerta de
enlace BC, en la cual el administrador de esta puerta de enlace vinculara el contrato
inteligente del dispositivo con el contrato inteligente de la puerta de enlace.

Cuando el tercer usuario accede desde su teléfono inteligente a la puerta de enla-


ce BC, obtiene la dirección de la puerta de enlace BC. Al acceder a la puerta de
enlace BC puede consultar la lista de dispositivos IoT conectados al contrato inte-
ligente de la puerta de enlace. El usuario puede consultar el contrato inteligente de
los dispositivos obteniendo información y las polı́ticas de privacidad a través de los
contratos de cada dispositivo.

Cuando el tercer usuario recibe las polı́ticas de privacidad del dispositivo IoT, es-
te puede aceptar o rechazar las polı́ticas, notificando esta decisión a la puerta de
enlace, evitando que los dispositivos IoT obtengan información sin antes aceptar las

28
polı́ticas de privacidad.

La puerta de enlace guarda la preferencia de cada usuario en la red Blockchain,


procesando la solicitud de cada usuario en función a las preferencias del usuario ya
almacenadas.

29
Desarrollo

El principal objetivo de este trabajo de grado es el desarrollo de un prototipo IoT


basado en un sistema embebido que permita interactuar con la tecnologı́a Blockchain
para que ası́ este dispositivo y la plataforma IoT se pueda beneficiar de las caracterı́sti-
cas que Blockchain tiene para ofrecer a nivel de seguridad, integridad, transparencia
y trazabilidad en el manejo de datos. El caso de aplicación de este trabajo de grado
consiste en fijar un valor de partes por millón (PPM) de concentración de CO2 en el
ambiente a un sensor mediante la adquisición de un nivel de concentración de CO2
permitido que es ingresado por un usuario por medio de una página web.

Para poder comprobar el esquema de seguridad que se gana al usar Blockchain, se


creó una fase no segura, en la cual el sistema embebido adquiere unos datos almacena-
dos en una base de datos en MySQL que son agregados manualmente por un usuario
por medio de una página web. Esto se realizó con el fin de demostrar lo vulnerable que
puede llegar a ser un servidor web convencional y la forma en que los datos pueden
ser alterados para que el sistema embebido se pueda manipular y cambiar el nivel de
CO2 permitido en el ambiente.

Prototipo IoT
Para el desarrollo de este trabajo de grado, se escogió el sistema embebido ESP32
de la compañı́a Espressif ya que este ofrece una plataforma robusta para aplicaciones
de IoT, pues integra conexión Wi-Fi (2.4GHz), Bluetooth 4.2, un procesador dual-core
y varios periféricos. Para la programación del ESP32 se utilizó el software de Arduino
IDE por ser un entorno de desarrollo sencillo, fácil de usar y open source.

Puesto que el objetivo es implementar un dispositivo IoT con el ESP32, el primer


paso fue añadir la plataforma del ESP32 a Arduino IDE, esta plataforma contiene
las distintas placas ESP32 y las librerı́as necesarias para este dispositivo. Una vez
instalada esta plataforma, el segundo paso fue probar que la placa se comunicara co-

30
rrectamente con Arduino IDE, para esto es necesario seleccionar el modelo correcto
de la placa en el gestor de tarjetas, en este caso se seleccionó DOIT ESP32 DEV
KIT V1, pues el modelo del ESP32 adquirido fue el Kit de desarrollo de DOIT, se
verificó el puerto y se cargó un ejemplo de las librerı́as llamado LED Blink, el cual
simplemente hace parpadear el LED integrado de la placa, con esto se pudo confirmar
que no hubo problemas en la comunicación del ESP32 con el software (ANEXO LED
Blink).

Para el desarrollo del primer objetivo, el cual consiste en implementar un disposi-


tivo IoT con base en el ESP32, es necesario considerar que el dispositivo tiene que ser
capaz de conectarse a internet por Wi-Fi para adquirir y/o enviar datos, para esto
se creó un programa sencillo en cual se conectara a la red Wi-Fi con los parámetros
del nombre de la red (SSID) y la contraseña de la misma (lı́neas 6 y 7 de la figura 8)
haciendo uso de la librerı́a WiFi.h, la finalidad de este programa fue simplemente ve-
rificar la conexión con la red Wi-Fi, si se establece la conexión se confirma por medio
de un mensaje enviado vı́a Serial, como se muestra en la figura 7 a continuación.

Figura 7: Conexión Wi-Fi

31
Figura 8: Parámetros conexión y definición de variables

Una vez establecida esta conexión se decidió usar el protocolo MQTT para trans-
mitir datos, un protocolo orientado a comunicar dispositivos IoT que usa poco ancho
de banda y que permite ser ejecutado en una gran cantidad de sistemas embebidos
con pocos recursos. Para poder implementar el protocolo MQTT es necesario tener
un brocker, el cual es el encargado de gestionar la red y transmitir los mensajes publi-
cados por Topics, hay diversas maneras de desplegar un brocker, pero por simplicidad
se usó el servicio de Brocker basado en la nube de www.DIoTY.co a el cual se puede
acceder por medio de una cuenta de Google y es gratuito. Para usarlo simplemente es
necesario tener los parámetros del usuario del brocker, contraseña (enviada al correo
una vez registrado), la dirección del brocker y la librerı́a de PubSubClient.h (lı́neas 9,
10 y 11 de la figura 8) (ANEXOS Conexión MQTT), con estos parámetros se puede
verificar la conexión al brocker MQTT de forma sencilla con el código mostrado a
continuación:

32
Figura 9: Conexión al brocker

El siguiente paso para la implementación del dispositivo IoT fue enviar un dato
de manera periódica por medio de un topic y que este se pudiera visualizar en otro
dispositivo. Para realizar esto se envió el valor de CO2 medido en PPM por el sensor
MQ135 publicando un topic (ver lı́nea 12 de la figura 10), para esto se conectó el
sensor a una entrada analógica del ESP32, para definir el GPIO 2 como entrada de
datos, (ver lineas 23 y 24 de la figura 8) y esto lo hace de manera periódica, por lo
que cada dos segundos el PPM se actualiza. Luego Para comprobar que el topic es
publicado y recibido por otro dispositivo se instaló la aplicación MQTT Dashboard
a un celular Android y se configuró la conexión con los parámetros del brocker en
modo subscribe (ver imagen figura 10), esto para recibir los datos publicados por el
dispositivo MQTT implementado y comprobar que se envı́a el valor de PPM, como
se observa en la figura 10.

33
Figura 10: Aplicación MQTT Dashboard (configuración a la izquierda y comprobación
a la derecha)

Fase no segura

Como primera instancia se creó un servidor web de manera local mediante el


software Uniform Server Zero, el cual es instala un servidor WAMP (Windows Apache
MySQL, PHP), luego se inician los servicios de Apache y MySQL para crear la base
de datos en la utilidad de MySQL llamada phpMyAdmin, mediante esta herramienta
es posible administrar las bases de datos de una manera muy simple y se creó una
base de datos llamada blockchain y una tabla con los datos de id, UID, Fecha y ppm,
tal como se muestra a continuación:

34
Figura 11: Base de datos

Figura 12: Tabla

Posteriormente se desarrolló una página web sencilla en HTML en el que el admi-


nistrador puede fijar un valor de CO2 en sus unidades de ppm (partı́culas por millón)
al ingresar el UID del sistema embebido (identificador único del ESP32) y el valor
de ppm deseado, estos datos son almacenados en una base de datos por medio de un
archivo php el cual realiza el Insert en la base de datos mediante un Post. Estos datos
luego son consultados por el sistema embebido para tener este valor fijado como refe-
rencia. A continuación, se muestra el código en php con el que se realiza la búsqueda
de la variable coordenada en la base de datos.

35
Figura 13: Archivo php

El sistema embebido es capaz de capturar estos datos y almacenarlos en una


variable que sirve de referencia para hacer comparaciones, si el valor obtenido del
sensor es mayor al de referencia se activará una alarma, en este caso un LED. Para
esto primero realiza una conexión Wi-Fi, luego, se conecta a un servidor remoto por
medio de un cliente http, por lo que se requiere de la librerı́a HTTPClient.h, este
interactua con el servidor a través de un archivo php por medio de un Post en el cuál
envı́a el UID del sistema embebido y con este parámetro se realiza la búsqueda en
la base de datos para comprobar que tenga un valor de ppm definido, si este está en
la base de datos el archivo php lo retorna mediante un echo y son capturadas por
el embebido y almacenadas en la variable ppmObt para establecer una referencia. El
segmento de código que establece conexión con el servidor se muestra a continuación:

36
Figura 14: Conexión a el servidor

Esta variable obtenida será el nivel máximo de CO2 permitido y con esta el sis-
tema embebido realiza la comparación, si el valor leı́do del sensor es mayor que el
máximo permitido, este emitirá una alerta encendiendo un LED.

La principal desventaja de hacerlo por esté método (usando bases de datos) es


que el servidor puede ser atacado y obtener acceso a la base de datos, de manera que
se pueda modificar los valores establecidos para el dispositivo conectado a la red IoT.
Sin embargo, hay un método alternativo y mucho más seguro para realizar esta tarea.

Fase segura
En el desarrollo de la fase segura, en la cual los datos están protegidos en la Block-
chain, se desplegó el contrato inteligente en uno de los nodos de la red Blockchain de
la red RITA y también la página web.
Para ejecutar las funciones del contrato por medio del sistema embebido utilizado,
se hizo mediante solicitudes de JSON-RPC, este es un protocolo de llamada de pro-
cedimiento remoto (RPC) ligero y sin estado que utiliza JSON, esta especificación
define varias estructuras de datos y las reglas en torno a su procesamiento. Una lla-
mada RPC se representa enviando una solicitud o un objeto Request a un servidor.
El objeto Request tiene los siguientes miembros:

jsonrpc: Una cadena que especifica la versión del protocolo JSON-RPC. Debe
ser exactamente ”2.0”.
method: Una cadena que contiene el nombre del método que se invocará. En la
siguiente documentación se pueden ver los diferentes métodos soportados por

37
JSON-RPC

params: Un valor estructurado que contiene los valores de los parámetros que se
utilizarán durante la invocación del método. Este miembro puede ser omitido.

id: Un identificador establecido por el Cliente que debe contener un valor de


cadena, número o null, si está incluido. Si no está incluido, se supone que es una
notificación.

Para poder enviar esta solicitud al nodo se estableció una conexión al nodo de la
Blockchain de RITA mediante un cliente http usando un método Post y especificando
que el tipo de archivo a enviar está en formato JSON, como se observa a continuación:

Figura 15: Conexión al nodo por medio de HTTP client

La solicitud del JSON-RPC se hizo creando un archivo en formato JSON desde la


programación en el sistema embebido, de forma tal que desde el programa se cree el
JSON lı́nea a lı́nea con los miembros necesarios para crear la solicitud. Para esto fue
necesario instalar e implementar la librerı́a ArduinoJson.h, en la figura 16 se muestra
una de las solicitudes hechas, allı́ se observa cómo se crea el archivo JSON mediante
pares nombre- valor de acuerdo a los miembros necesarios para realizar una solicitud.
El método usado es el eth call, este método ejecuta una nueva llamada de mensaje
de manera instantánea sin crear una transacción, al usar este método es necesario
especificar los parámetros que usará, en este caso usa los parámetros “to” que indica
la dirección a la que se dirige la transacción, en este caso es la dirección del contrato
(ver lı́nea 56 de la figura 16) y “data” que debe contener el Hash de la firma del método
y parámetros codificados en hexadecimal, en este caso se está enviando 0c5fdfa5 que
es el hash de la firma del método “verEstadoSesion” (ver figura 18) y concatenado
con este se envı́a una trama de 64 bytes que contiene el ID del usuario para ver si su
sesión se encuentra activa o no, de ser ası́ en la respuesta se obtiene un 1 (True) o un
0 (False) en caso de que no se encuentre activa la sesión.

38
Figura 16: Código para crear la solicitud en formato JSON

En la figura 17 se observa la solicitud enviada por el sistema embebido y la respues-


ta obtenida, esto confirma que hay una comunicación establecida entre en nodo de la
red Blockchain, el contrato inteligente y el sistema embebido, debido a que existe una
respuesta por parte del nodo a la solicitud hecha por el sistema embebido que apunta
a una función que está en el contrato, como se observa en el resultado se obtiene un
1, el cual indica que la sesión para el usuario “1234” (almacenado previamente) está
activa.

Figura 17: Verificación de la solicitud y respuesta

39
De esta misma manera se crearon las diferentes solicitudes para interactuar con
el nodo e intercambiar la información, siempre apuntando a el hash de la función
establecida en el contrato, las cuales se muestran a continuación:

Figura 18: Hash de las funciones del contrato

Para poder enviar los parámetros del UID del sistema embebido y el valor obteni-
do por el sensor de CO2 en PPM, se apunta a el hash de la función compararP P M
(0x6dd87d55), esta función requiere de dos parámetros de entrada (UID y PPM), por
lo que es necesario concatenar el número del UID y el valor del sensor, para hacer
eso primero es necesario transformar el UID de variable entera a hexadecimal y com-
pletar una trama de 32 bytes con ceros, de igual forma para el valor del sensor, esta
tarea se realizó llenando un arreglo de 64 posiciones en donde el valor del UID y de
PPM se ubican en las últimas posiciones con sus valores en hexadecimal y el resto
de posiciones se llenan con ceros, como se observa en el código de la figura 35, luego
estos resultados son concatenados para obtener la trama de 64 bytes más el hash de
la función del contrato (ver linea 108 de la figura 35) y se envı́an en el parámetro
”data”para realizar la llamada JSON-RPC. Esta función retorna como resultado un
True cuando el valor enviado de PPM es mayor al establecido desde la página web, o
un False cuando el valor en PPM es menor.

40
Figura 19: Conversión y concatenación de parámetros data

La respuesta retornada es una trama de 32 bytes en hexadecimal con el 0x al


inicio, por lo que es necesario procesarla y obtener una variable para poder comparar.
Para realizar esta tarea fue necesario eliminar el 0x con el método remove, al hacer
esto ya queda una trama en hexadecimal, por lo que con el método strtol se puede
convertir a una variable long int, con esto ya se puede comparar y condicionar, como
se observa el la figura 20, de tal manera que si el resultado retornado es 1, se enciende
el LED indicando una alarma que supera los niveles de CO2 permitidos.

Figura 20: Conversión result

41
Desarrollo Smart Contract

Se escogió el desarrollo del SmartContract en la plataforma Ethereum, ya que


esta plataforma en su estructura de bloques cuenta con un espacio de información
la cual se utiliza para el despliegue del código de un contrato inteligente, además de
esto es fácil encontrar documentación y herramientas de trabajo para el desarrollo y la
pruebas. Además de esto, es la plataforma en la cual trabaja la red blockchain de RITA

Se utilizó Solidity, un lenguaje de programación en la cual se pueden escribir


contratos inteligentes. Remix es el IDE online en el cual se escribió el contrato que
estará encargado de proteger la información del sensor.

Programación del contrato


Para la programación del contrato, primero se planteó el objetivo que iba a cum-
plir este respecto a la información que enviará el sensor, la cual es proteger un dato
y establecer un lı́mite máximo del parámetro definido en ese dato.

Teniendo en cuenta eso, se escribieron unas funciones las cuales permiten consultar
y editar el parámetro escrito en el Smart Contract por medio de una página web.
Estas funciones son consultadas por el sistema embebido para comparar con los datos
provenientes del sensor y los datos provenientes del contrato.

El Smart Contract
A continuación se describirá el código del contrato inteligente, las funciones que
se utilizaron y su operación.

Estados y definiciones del sistema, en esta parte se escriben las variables y las
estructuras del contrato.

42
Figura 21: Estados y definiciones del sistema

La estructura “Sensor” especifica los valores que se van almacenar en cada sensor
que se añade, en esta estructura se guardada el UID que es un valor irreempla-
zable que identifica el sistema embebido con el sensor y el tipo de valores que se
almacenaran con cada sensor, en este caso es un valor de tipo entero de PPM
máximo.

Estructura AdminioT, se ingresará en este campo los valores necesarios para


iniciar sesión, solo los usuarios que estén registrados podrán hacer cambio a los
valores del dato del sensor, o añadiendo nuevos sensores al contrato.

La palabra mapping en Solidity se utiliza para crear tablas de valores con las
estructuras definidas previamente.

La función OnlyOwner, se especifica para procesos en el contrato que solo la


cuenta que realizo el despliegue pueda modificar o consultar.
El contrato luego de que esté en la Blockchain no se puede eliminar, pero se
puede dejar sin poder interactuar con él, por esta razón se utilizo la función

43
Kill, kill es una palabra reservada que se utiliza para deshabilitar un contrato.
Funciones del sistema, estas funciones se encargaran de la seguridad en los datos
del contrato, para realizar modificaciones se debe tener en cuenta los parámetros
de inicio de sesión del usuario.

Figura 22: Funciones del sistema

El constructor lleva el mismo nombre que el contrato, en este caso CO2, esta
función solo se utiliza una vez y se utiliza en el momento que se despliega el
contrato en los nodos. Para el despliegue es necesario ingresar dos valores: el
número de identificación de un único usuario y su contraseña con la cual será
posible el inicio de sesión para modificar valores en el Sensor.

La función ingresar se llama desde la página web para verificar que la cuenta
de usuario y su contraseña sean las correctas, luego de verificar esto se le asigna
una sesión Id temporal, esto es un hash el cual se genera con la contraseña y
el tiempo del bloque, con esto se asegura que el Id temporal no será el mismo,
este Id será necesario para poder modificar valores dentro del contrato.
La función verEstadoSesion es necesaria para verificar si el usuario ingreso co-
rrectamente a la página retornando un valor booleano.

44
La función enviarSesionID, es necesaria, ya que esta nos retorna el valor de la
Id temporal asignada cuando el usuario ingresa al sistema, valor requerido para
hacer las modificaciones en los datos del sensor.
Añadir Sensor, esta parte de código tiene como tarea añadir un sensor mediante
el UID, teniendo en cuenta que el usuario tiene el Id de inicio de sesión.

Figura 23: Funciones para añadir o editar sensores

Búsqueda, función que recibe un valor de UID para hacer un recorrido en las
tablas sensor en la búsqueda de encontrar el número de identificación asignado
a ese sensor cuando fue añadido al contrato y ası́ poder realizar modificaciones
en él.

AddSensor, esta función privada agrega un nuevo sensor y le asigna un ID.

La función anadirSensor publica es la encargada de verificar si el usuario tiene


una sesión abierta teniendo en cuenta la sesión Id, si los datos están correctos
llama la función AddSensor para agregar un sensor nuevo.
EditarSensor, permite cambiar el valor de UID de un sensor.
Modificar valor PPM, las funciones que están en esta parte se encargaran de la
modificación de los datos almacenados de cada sensor en el contrato.

45
Figura 24: Código de interacción con los datos de PPM

Como en la parte de añadir sensor, la función cambiarPPM, que es publica, hace


una verificación si el usuario tiene la sesión abierta y el valor de la sesión Id que
se le asignó cuando ingresó al sistema, luego de verificar estos valores llama a
la función privada SetPPM.

SetPPM, esta función privada solo es posible llamarla desde el contrato, no se


puede llegar a ellas a través de la página web. La tarea de esta función es llamar
a la función búsqueda la cual se le entrega el identificador UID del sensor, re-
torna el SensorID asignado a ese UID y hace el cambio de los valores de PPM.

ConsultarPPM, con el UID del sensor, esta función hace una búsqueda y per-
mite visualizar los datos asignados a ese UID.

CompararPPM, es la función la cual el sistema embebido envı́a al contrato el


valor que esta registrando el sensor, la función enviará una respuesta booleana
de pendiendo si pasa el valor limite que tiene el contrato guardado para ese
sensor con su respectivo UID.

46
Luego del desarrollo del contrato se procede a realizarle las pruebas desde Remix
para verificar que el trabajo de cada función sea el correcto. Remix genera 5
cuentas con las cuales se puede interactuar con el contrato. Luego del despliegue
del contrato muestra todas sus funciones, las funciones que están de color rosado
son aquellas que no tienen un valor de retorno definido en la función, las de color
gris, son las funciones que retornan un valor, ya sea entero o booleano. Ademas
de esto, Remix indica que tipo de dato se debe de ingresar en cada función, esto
se observa en el cuadro de texto al lado del nombre de las funciones como se
observa en la figura 25.

47
Figura 25: Prueba de contrato en Remix

48
Instalando ambiente de trabajo para la prueba del Smart Con-
tract
Para esta parte de la investigación, fue necesaria la instalación de software adi-
cional para poder simular una red de nodos en un computador con el fin de probar
las funciones y la interacción de la página web con el Smart Contract. El software
instalado es libre. Los programas que se instalaron fueron los siguientes:

NodeJs es un entorno de programación para servidores utilizando JavaScript y


programación orientada a eventos.

TestRpc, es un nodo Js, cliente de ethereum para prueba y desarrollo de Smart


Contract. Al inicializar testrpc este crea 10 direcciones falsas de Ethereum si-
mulando ser una red de nodos que procesan cada solicitud que se le hace al
contrato.

Librerı́a Web3Js, es una librerı́a JavaScript que implementa JsonRpc. El proto-


colo que se usara para hablar con el nodo de Ethereum.

Prueba del contrato


Esta parte se realizó con el fin de desplegar el contrato en una red de nodos de
prueba, aprendiendo como se puede interactuar con las funciones del contrato y luego
hacer una comparación con el despliegue en la red de nodos de la universidad Distrital

1. Instalación de node modules, estos módulos son paquetes JavaScript los cuales
proporcionan una funcionalidad para cada aplicación, el paquete que se utiliza
para esta aplicación en especı́fico está en la carpeta web3, la cual se le hace
un llamado desde la página web o desde la ventana de comando de windows
para interactuar con el contrato. En la carpeta donde se encuentra el contrato,
escribimos el siguiente comando

Npm install

2. En este paso se utiliza el comando testrpc, simula 10 nodos, con su dirección de


cuenta y la clave privada de cada nodo

49
Figura 26: Cuentas simuladas por medio de testrpc

3. Utilizando la pagina de Remix, se puede hacer la conexión directamente a los


nodos del computador con su dirección IP local y el puerto 8545

Figura 27: Conexión de la pagina Remix con los nodos de testrpc

4. Luego de terminar el despliegue del contrato en la simulación de la red de


nodos, se puede editar y agregar valores en el contrato llamando sus funciones
que se declararon públicas, esto se realiza con una instancia desde la ventana
de comando de windows.

instance= CoordenadaContract.at(contractAddress)

50
Teniendo una instancia se puede llamar a las funciones, como ejemplo a la
función consultarPPM que retorna el valor del PPM asignado a un UID.

PPM= instance.consultarPPM(#UID)

Implementación Smart Contract en la Red de Nodos


RITA
Luego de terminar las pruebas en la conexión e interacción de las funciones del
contrato en una red de nodos simuladas por medio del testrpc, se procede a realizar
el despliegue en la red de nodos privada del grupo de investigación RITA.

Para realizar este despliegue en la red de nodos de RITA, se asignó un usuario y


una contraseña para poder acceder a un nodo y realizar el despliegue.

Figura 28: Lineas de código despliegue del Smart Contract en la red de nodos de
RITA

Con la dirección ritaportal.udistrital.edu.co y el puerto 10120 se puede acceder


al nodo de forma remota para realizar las pruebas de la pagina web y la conexión del
embebido con el Smart Contract. El despliegue del contrato se demoró al rededor de 5
minutos mientras los nodos procesaban la petición del despliegue, el código completo
del despliegue se encontrara en los anexos, el código se guardó como un archivo con
extensión js.

Diseño de la página web


Se desarrollaron dos paginas web. La primera página tiene como objetivo buscar
que el usuario ingrese con su cédula y contraseña, la segunda está habilitada para que
cualquiera pueda acceder a ella, pero si no se encuentra previamente con una sesión
activa, la pagina sera inservible para las personas que quieran editar algún valor. Las

51
dos paginas tienen el usuario y contraseña de un nodo de RITA desde donde se envı́an
las transacciones a la red blockchain.

La página de inicio de sesión (figura 29), cuenta con dos cuadros de texto donde
ingresara el usuario los datos que le permitirán dar credenciales para modificar valores
en el contrato. Cuenta ademas con un botón el cual enviara la información al contrato
para que sea este que decida si se le concede o no permiso a la persona que este
intentando ingresar al sistema, con el botón de estado de sesión pueden verificar si se
las ha concedido el permiso o no, en el caso de que ya tengan el permiso para ingresar
se abrirá la pagina para realizar cambios o añadir sensores al contrato.

Figura 29: Inicio de sesión

52
Figura 30: Página donde se modificaran los datos que almacena el Smart Contract

La página de la figura 32 esta dividida en cuatro partes, cada parte interactúa con
funciones especificas del Smart Contract. La parte de la información de transacción
muestra el bloque que se añade cada vez que se hace una petición a la red blockchain,
con el hash de la transacción. Con el botón de cerrar sesión se eliminan las creden-
ciales del usuario, para realizar algún cambio en el contrato debe volver a ingresar
para darle nuevas credenciales. Las otras partes de la pagina, añadir sensor, consultar
PPM y cambiar PPM, están programadas para enviar y recibir datos de las funciones
en el contrato que llevan el mismo nombre.

Las paginas se almacenan en la misma carpeta donde se encuentra el archivo no-


de modules ya que ahı́ la pagina utiliza la librerı́a web3 que le permite hacer instancias
del contrato. El código de la programación de las paginas se encuentra en anexos.

El diagrama de uso para la pagina web se muestra a continuación:

53
Figura 31: Diagrama de uso

Figura 32: Diagrama de uso del sistema embebido

54
Resultados y análisis de
resultados

Con el desarrollo de este trabajo de grado se logró la interacción de la tecnologı́a


Blockchain con la plataforma IoT de una manera sencilla y optimizando recursos de
tal forma que dispositivos de bajos recursos pueden ser capaces de beneficiarse de las
caracterı́sticas únicas que ofrece Blockchain, pues se probó que es posible ejecutar las
funciones del protocolo JSON-RPC por medio de un archivo en formato json generado
desde el sistema embebido a utilizar y capturar la respuesta con el mismo para ası́
poder ejecutar acciones en base a esta.

Por medio de un Smart Contract fue posible fijar un valor de PPM permitido de
manera segura desde una página web y compararlo con el valor que arroja el sensor
en tiempo real para ası́ por medio de una función (compararPPM) se retorna un true
o un false el cual es capturado por el sistema embebido y con base en este se enciende
un LED indicando una alerta. Previamente se registró un valor de CO2 máximo
permitido de 1000P P M por medio de la página web, a continuación se comprueba
este valor consultando el valor de PPM permitido para el UID especificado.

Figura 33: Máximo ppm permitido para el sistema embebido con UID 2147483647

55
Desde el sistema embebido se usó el método ethc all para apuntar a la función
compararP P M por su hash enviando como parámetros el UID (2147483647) y el
nivel de CO2 sensado, a continuación se muestran los resultados obtenidos.

Figura 34: Resultados obtenidos por el monitor serie

Como se observa, la respuesta de la función cambia al superar el lı́mite establecido


(1000ppm) y es capturada por el sistema embebido, ası́ mismo al cambiar de 0 a 1 el
resultado, esto enciende un LED de alerta, como se observa a continuación.

56
Figura 35: LED encendido (azul) al superar el valor máximo permitido

Con esto se demuestra el cumplimiento del objetivo general de este trabajo de


grado, pues como se vio, fue posible generar una interacción con la tecnologı́a Block-
chain a un sistema embebido bajo la plataforma IoT, de tal manera que las acciones
realizadas por el dispositivo IoT están dadas por un Smart Contract desplegado en un
nodo de la red Blockchain en donde, una vez desplegado, no es posible alterarlo y este
adquiere los valores dados por el sensor y realiza la comparación con el valor máxi-
mo permitido, el sistema embebido depende de la respuesta de este contrato, pues se
diseñó de tal forma que el contrato adquiera todos los datos y el sistema embebido
actúe de acuerdo a la respuesta del contrato brindándole seguridad a la red.

57
Conclusiones

Se desarrolló un dispositivo IoT que funciona bajo el protocolo MQTT con cone-
xión WI-Fi basado en el sistema embebido ESP32, el cuál permitió adquirir el valor
de medición de un sensor y visualizarla a través de un dispositivo android, esto gra-
cias a el manejo de los Topics de Subscribe y Publish que permiten enviar y recibir
información entre dispositivos IoT.

Se desarrolló una página web en la cual se pudo interactuar con el Smart Contract
permitiendo un control de acceso para los usuarios, gestionar sensores definidos por el
identificador único del sistema embebido (UID), esta página permitió también realizar
búsquedas a una base de datos en MySQL por medio de un archivo en formato PHP
con el cual también puede interactuar el sistema embebido.

Durante del desarrollo de este trabajo se observó una gran diferencia en el tiempo
de ejecución de las transacciones hechas en con TestRPC y la implementación con los
nodos fı́sicos de la red Blockchain de la red RITA, esto es debido a que en la vida real
estas transacciones tienen que ser minadas por los nodos y esto emplea cierto tiempo
en realizarse. Además de esto el programa de simulación TestRPC tiene conflictos con
el ingreso de valores tipo String, lo cual con la red RITA no generó ningún inconve-
niente.

Al utilizar el formato JSON permite al sistema embebido conectarse con los no-
dos e interactuar con las funciones de un Smart Contract reduciendo el espacio en
memoria utilizado por el programa, consumiendo menos recursos, pues el tamaño de
estos archivos es muy pequeño, esto hace que se pueda utilizar para dispositivos IoT
de bajos recursos permitiendo realizar acciones de forma segura y garantizando una
integridad en los datos, una trazabilidad y transparencia en el manejo de los mismos.

El despliegue del contrato en la red Blockchain de RITA se realizó de manera re-


mota utilizando el programa NodeJs, la librerı́a web3 y el archivo Desplegar.js (código
en anexos) el cual tenı́a el usuario y contraseña que permitı́a ingresar a un nodo de

58
esa red, esto con el fin de poder realizar el despliegue y pruebas a cualquier hora,
evitando desplazarse al lugar donde se encontraban los nodos.

El procesamiento de datos con Blockchain garantiza seguridad en las redes IoT y


ofrece una mejor alternativa al protocolo MQTT, pues se elimina la necesidad de un
Brocker, permitiendo a los dispositivos interactuar directamente con otros dispositivos
de manera abierta y descentralizada, con el uso de los Smart Contracts se da cierta
autonomı́a a la red, pues estos dispositivos ya actúan de manera independiente sin
interacción humana. A demás para atacar la red Blockchain o corromper los datos
en los bloques es necesario tener un poder computacional mayor al generado por el
50 % de los nodos conectados y tener acceso a más del 50 % de los nodos de la red
Blockchain, algo que es muy improbable de lograr.

59
Anexos

0.1. Blink

void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever


void loop() {
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off
delay(1000); // wait for a second
}

0.2. Conexión Wi-Fi MQTT

#include <WiFi.h>
#include <PubSubClient.h>

char ssid[] = "nombre red";


char pass[] = "contrasena";
char brockerUser[] = "[email protected]";
char brockerPass[] = "709d2a90";
char brocker[] = "mqtt.dioty.co";

60
WiFiClient espClient;
PubSubClient client(espClient);

void setupWiFI() {
delay(100);
Serial.print("\nConectando a: ");
Serial.println(ssid);

WiFi.begin(ssid, pass);
while (WiFi.status() != WL_CONNECTED) {
delay(100);
Serial.print("-");
}
Serial.print("\nConectado a: ");
Serial.println(ssid);
}

void reconnect(){
while(!client.connected()){
Serial.print("\Conectando a: ");
Serial.println(brocker);
if(client.connect("daniel", brockerUser, brockerPass)){
Serial.print("\nConectado a: ");
Serial.println(brocker);
}
else {
Serial.println("\nIntentando conectar de nuevo");
delay(2000);
}
}
}

void setup() {
Serial.begin(9600);
setupWiFI();
client.setServer(brocker, 1883);
}

void loop() {
if (!client.connected()){
reconnect();

61
}
client.loop();

0.3. Visualizar concentración de CO2 MQTT

#include <WiFi.h>
#include <PubSubClient.h>
#define anInput A6
#define co2Zero 55 //CO2 inicial

char ssid[] = "..."; // nombre de la red


char pass[] = "..."; // contrase~
na de la red
int keyIndex = 0;
char brockerUser[] = "[email protected]";
char brockerPass[] = "709d2a90";
char brocker[] = "mqtt.dioty.co";
char ppmTopic[] = "/[email protected]/CO2_PPM";

WiFiClient espClient;
PubSubClient client(espClient);

int ppm;
long currentTime, lastTime;
int cont = 0;
char mensajes[50];
char* ppmE;

void setupWiFI() {
delay(100);
Serial.print("\nConectando a: ");
Serial.println(ssid);

WiFi.begin(ssid, pass);

while (WiFi.status() != WL_CONNECTED) {


delay(100);

62
Serial.print("-");
}

Serial.print("\nConectado a: ");
Serial.println(ssid);

void reconnect(){
while(!client.connected()){
Serial.print("\nConectando a: ");
Serial.println(brocker);
if(client.connect("daniel", brockerUser, brockerPass)){
Serial.print("\nConectado a: ");
Serial.println(brocker);
}
else {
Serial.println("\nIntentando conectar de nuevo");
delay(2000);
}
}
}

void setup() {
Serial.begin(9600);
setupWiFI();
client.setServer(brocker, 1883);
pinMode(anInput,INPUT);

void loop() {
if (!client.connected()){
reconnect();
}
client.loop();
//..........................INICIA SENSOR CO2 RESULTADOS EN PPM....................

int co2now[10]; //arreglo 10 muestras


int co2raw = 0;
int co2comp = 0;

63
int co2ppm = 0;
int zzz = 0;
int grafX = 0;
for (int x = 0;x<10;x++){ //toma 10 muestras
co2now[x]=analogRead(A6);
delay(200);
}

for (int x = 0;x<10;x++){ //llena el arreglo


zzz=zzz + co2now[x];

}
co2raw = zzz/10; //promedia
co2comp = co2raw - co2Zero; //valor compensado
co2ppm = map(co2comp,0,1023,400,5000); //mapea para valores atmosféric

currentTime = millis();
if(currentTime - lastTime > 2000){
cont++;

char buffer[10];
ppmE = dtostrf(co2ppm,4,2,buffer); //convierte float a char
Serial.println(ppmE);

snprintf(mensajes, 75, "PPM: %ld", cont);


client.publish(ppmTopic, ppmE);
lastTime = millis();
Serial.print("\nla concentración de CO2 en PPM es: ");
Serial.println(co2ppm);
}

0.4. Conexión y búsqueda en bases de datos

#include <WiFi.h>
#include <WiFiClient.h>
#include <HTTPClient.h>

64
#define anInput A6
#define co2Zero 55 //CO2 inicial

uint64_t chipid;
const char* ssid = "UNE_HFC_D3EC";
const char* password = "5232496217";

void setup()
{
pinMode(anInput,INPUT);
pinMode(LED_BUILTIN, OUTPUT);
Serial.begin(115200);
WiFi.begin(ssid,password);
while (WiFi.status()!= WL_CONNECTED){
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("Conectado a Wi-Fi");
Serial.print("IP: ");
Serial.println(WiFi.localIP());
}

void loop()
{
//.........................ADQUIERE UID DEL DISPOSITIVO Y LO CONVIERTE A ENTERO..

chipid=ESP.getEfuseMac();
String result = "";
uint8_t base = 10;

do {
char c = chipid % base;
chipid /= base;

if (c < 10)
c +=’0’;
else
c += ’A’ - 10;
result = c + result;

65
} while (chipid);

//Conexión con el servidor


HTTPClient http;
http.begin("http://192.168.1.72/tesis/conexion.php");
http.addHeader("Content-Type", "application/x-www-form-urlencoded");
int httpResponseCode = http.POST("uid=" + result);

if (httpResponseCode >0){
ppmObt = http.getString();
Serial.println(httpResponseCode);
Serial.println(ppmobt);

}
else{
Serial.print("No se envió el dato");
Serial.println(httpResponseCode);
}

http.end();

delay(3000);

0.5. Código php búsqueda en base de datos

<?php

$uid = $_POST [’uid’];

// Parámetros para la conexión con la base de datos


$servername = "localhost";
$username = "user";
$password = "123456";
$dbname = "blockchain";
// Crea la conexión
$conn = new mysqli($servername, $username, $password, $dbname);

66
// Estado conexión
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}
// Realiza la búsqueda
$sql = "SELECT * FROM tabla WHERE uId=".$uid."";
if($resultado = $conn->query($sql)){
while ($fila = $resultado->fetch_assoc()) {
$respuesta = $fila["ppm"];
}
}
echo $respuesta;

?>

0.6. Código para comprobar conexión con el nodo

#include <WiFi.h>
#include <WiFiClient.h>
#include <HTTPClient.h>
#include <ArduinoJson.h>

String uId = "123";


const char* ssid = "nombre red";
const char* password = "contrase~na";

void setup()
{

sensors.begin();
Serial.begin(115200);
WiFi.begin(ssid,password);
while (WiFi.status()!= WL_CONNECTED){
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("Conectado a Wi-Fi");

67
Serial.print("IP: ");
Serial.println(WiFi.localIP());

String callGeth(String inputJSON){


HTTPClient http;
http.begin("http://ritaportal.udistrital.edu.co:10120/");
http.addHeader("Content-Type", "application/json");
//POST request.
int resultadohttp = http.POST(inputJSON);
String JSONResult = http.getString();
return JSONResult;
http.end();
}

void loop()
{
if (WiFi.status() == WL_CONNECTED) {

StaticJsonBuffer<1000> JSONbuffer;
JsonObject& gethQueryJSON = JSONbuffer.createObject();
gethQueryJSON["jsonrpc"] = "2.0";
gethQueryJSON["method"] = "eth_call";
JsonArray& gethQueryParams = gethQueryJSON.createNestedArray("params");
JsonObject& gethCallParams = JSONbuffer.createObject();
gethCallParams["to"] = "0x457aebb0691c9a157064916707b558b6eef19450";
gethCallParams["data"] = "0x0c5fdfa5000000000000000000000000000000000000000
gethQueryParams.add(gethCallParams);
gethQueryParams.add("latest");
gethQueryJSON["id"] = 1;

String gethStringJSON;
gethQueryJSON.printTo(gethStringJSON);
Serial.println("Función JSON enviada: ");
Serial.println(gethStringJSON);

String gethResult = callGeth(gethStringJSON);


JsonObject& gethJSONRPC = JSONbuffer.parseObject(gethResult);

Serial.println("Respuesta JSON-RPC: ");

68
Serial.println(gethResult);

delay(8000);
}

0.7. Código para enviar el UID y nivel de CO2 a el


nodo

#include <WiFi.h>
#include <WiFiClient.h>
#include <HTTPClient.h>
#include <ArduinoJson.h>
#define anInput A6
#define co2Zero 55 //CO2 inicial

uint64_t chipid;
const char* ssid = "nombre red";
const char* password = "contrase~na";

void setup()
{
pinMode(anInput,INPUT);
pinMode(LED_BUILTIN, OUTPUT);
Serial.begin(115200);
WiFi.begin(ssid,password);
while (WiFi.status()!= WL_CONNECTED){
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("Conectado a Wi-Fi");
Serial.print("IP: ");
Serial.println(WiFi.localIP());
}

String callGeth(String inputJSON){

69
HTTPClient http;
http.begin("http://ritaportal.udistrital.edu.co:10120/");
http.addHeader("Content-Type", "application/json");
int resultadohttp = http.POST(inputJSON);
String JSONResult = http.getString();
return JSONResult;
http.end();
}

void loop()
{
if (WiFi.status() == WL_CONNECTED) {

//.........................ADQUIERE UID DEL DISPOSITIVO Y LO CONVIERTE A ENTE

chipid=ESP.getEfuseMac();
String result = "";
uint8_t base = 10;

do {
char c = chipid % base;
chipid /= base;

if (c < 10)
c +=’0’;
else
c += ’A’ - 10;
result = c + result;
} while (chipid);

int result1 = (result.toInt());

//..........................INICIA SENSOR CO2 RESULTADOS EN PPM............

int co2now[10]; //arreglo 10 muestras


int co2raw = 0;
int co2comp = 0;
int co2ppm = 0;
int zzz = 0;
int grafX = 0;
for (int x = 0;x<10;x++){ //toma 10 muestras

70
co2now[x]=analogRead(A6);
delay(200);
}

for (int x = 0;x<10;x++){ //llena el arreglo


zzz=zzz + co2now[x];

}
co2raw = zzz/10; //promedia
co2comp = co2raw - co2Zero; //valor compensado
co2ppm = map(co2comp,0,1023,400,5000); //mapea para valores atmosféricos

//.....................................CALL JSON-RPC.............................

StaticJsonBuffer<1000> JSONbuffer;
JsonObject& gethQueryJSON = JSONbuffer.createObject();
gethQueryJSON["jsonrpc"] = "2.0";
gethQueryJSON["method"] = "eth_call";
JsonArray& gethQueryParams = gethQueryJSON.createNestedArray("params");
JsonObject& gethCallParams = JSONbuffer.createObject();
gethCallParams["from"] ="0x2c54dbf773158007d2c58a2eca64e5855d1eb640"; //dirección
gethCallParams["to"] = "0x810d4a1b0f50c48858e088a88b404e024d7aba6e"; //dirección

String hexppm = String(co2ppm, HEX);


String paddedZeroes;
for(int x = 0; x < (64 - hexppm.length()); x++)
{
paddedZeroes = String(paddedZeroes + "0");
}
hexppm = String(paddedZeroes + hexppm);

String hexuid = String(result1, HEX);


String paddedZeroes1;
for(int x = 0; x < (64 - hexuid.length()); x++)
{
paddedZeroes1 = String(paddedZeroes1 + "0");
}
hexuid = String(paddedZeroes1 + hexuid);
hexuid = String("0x6dd87d55" + hexuid + hexppm);

gethCallParams["data"] = hexuid;

71
gethQueryParams.add(gethCallParams);
gethQueryParams.add("latest");
gethQueryJSON["id"] = 1;

String gethStringJSON;
gethQueryJSON.printTo(gethStringJSON);
Serial.println("Función JSON enviada: ");
Serial.println(gethStringJSON);

String gethResult = callGeth(gethStringJSON);


JsonObject& gethJSONRPC = JSONbuffer.parseObject(gethResult);

Serial.println("Respuesta JSON-RPC: ");


Serial.println(gethResult);

//.....................CONVIERTE EL CAMPO "RESULT" A TRUE o FALSE..........

String ledString = gethJSONRPC["result"]; //captura el paráme


ledString.remove(0,2); //elimina el 0x
long int ledOn = strtol(ledString.c_str(), NULL, 16); //convierte de Stri
Serial.println("Hex result: ");
Serial.println(ledString);
Serial.println("Result: ");
Serial.println(ledOn);

if (ledOn == 1){
digitalWrite(LED_BUILTIN, HIGH);
}
else {
digitalWrite(LED_BUILTIN, LOW);
}

//.....................VISUALIZA UID Y PPM............................


Serial.print("UID: ");
Serial.println(result1);
Serial.print(co2ppm);
Serial.println(" PPM");

delay(5000);
}

72
}

0.8. Smart Contract

pragma solidity ^0.4.3;


contract CO2 {

/*--------------------------ESTADOS Y DEFINICIONES DEL SISTEMA----------------------

address owner;
uint numSensor;
uint bus;
uint SensorID;

uint ingreso;
string contras;
bytes32 SID;

struct Sensor {
uint uid;
uint PPM;
}
struct AdminioT { //Estructura del Funcionario
uint cedula;
string nombre;
bytes32 contrasena;
bytes32 sesion;//Hash del sesionID aleatorio que identifica cada sesion
bytes32 sesionIDTemporal;//almacenamiento temporal del SesionID en texto plan
bool sesionActiva;//sesion activa o inactiva
uint tiempoInicial;
}

mapping(uint => AdminioT) adminsiot;


mapping (uint => Sensor) public sensor;

uint[] cedulas;// Numeros de indentificador de usuarios

73
modifier onlyOwner{
require(msg.sender==owner);
_;
}

function kill() public onlyOwner{


selfdestruct(owner);
}

/*---------------------------Funciones del sistema-----------------------------


function CO2(uint cedula, string contrasena)public {
owner = msg.sender;
adminsiot[cedula].cedula = cedula;
adminsiot[cedula].nombre = "Usuer";
adminsiot[cedula].contrasena = keccak256(abi.encodePacked(contrasena,
adminsiot[cedula].sesion = "0";
adminsiot[cedula].sesionActiva = false;
cedulas.push(cedula);
}
function ingresar(uint cedula,string contrasena)public {
require(msg.sender == owner);
if (adminsiot[cedula].contrasena == keccak256(abi.encodePacked(contrase
adminsiot[cedula].sesionIDTemporal = keccak256(abi.encodePacked(bloc
bytes32 sesionID = adminsiot[cedula].sesionIDTemporal;
adminsiot[cedula].sesion = keccak256(abi.encodePacked(sesionID)); //
adminsiot[cedula].tiempoInicial = block.timestamp;
adminsiot[cedula].sesionActiva = true;
ingreso=cedula;
contras=contrasena;
SID=adminsiot[cedula].sesionIDTemporal;
}
}

function cerrarSesion()public {
require(msg.sender == owner);
adminsiot[ingreso].sesionActiva = false;
adminsiot[ingreso].sesion = "0";
adminsiot[ingreso].sesionIDTemporal ="0";
ingreso=0;
contras="0";
SID="0";

74
}

function verEstadoSesion(uint cedula)public constant returns(bool) {


if (adminsiot[cedula].sesionActiva) {
return (true);
}else {
return (false);
}
}
function enviarSesionID(uint cedula,string contrasena) public constant returns (b
if (adminsiot[cedula].sesionActiva && adminsiot[cedula].contrasena == keccak2
sesionID = adminsiot[cedula].sesionIDTemporal;
return sesionID;
}else {
return sesionID;
}
}

/*---------------------------A~
nadir Sensor------------------------------------*/

function busqueda(uint a) private returns (bool) {


for (uint i = 1; i <= SensorID; i++){
if(a == sensor[i].uid) {
bus=i;
return true;
}
}
return false;
} //Busqueda de sensor

function addSensor(uint uiid, uint ppm4) private {


numSensor++;
SensorID= numSensor;
sensor[SensorID]= Sensor(uiid,ppm4);
}

function anadirSensor(uint uid4, uint ppm5) public {


require(msg.sender==owner);
if ( adminsiot[ingreso].sesionActiva && adminsiot[ingreso].sesion == keccak2
addSensor(uid4,ppm5);
}

75
}

function editarSensor(uint VUid, uint NUid) public returns(bool){


bool verificar= busqueda(VUid);
if(verificar==true){
sensor[bus].uid=NUid;
return true;
}
return false;
}

/*---------------------------Modificar Valor PPM-------------------------------

function setPPM(uint uid1, uint ppm1) private returns(bool){


bool verificar= busqueda(uid1);
if(verificar==true){
sensor[bus].PPM=ppm1;
return true;
}
return false;
}

function cambiarPPM( uint uid2, uint ppm2) public {


require(msg.sender==owner);
if ( adminsiot[ingreso].sesionActiva && adminsiot[ingreso].sesion == k
setPPM(uid2,ppm2);
}
}

function consultarPPM(uint uid3) public constant returns (uint ppm3) {


bool verificar= busqueda(uid3);
if(verificar==true){
ppm3=sensor[bus].PPM;
}
return (ppm3);
}

function compararPPM(uint uid5, uint PPMS) public constant returns (bool){


bool verificar= busqueda(uid5);
if(verificar==true){

76
if(sensor[bus].PPM <= PPMS){
return true;
}
}
return false;
}

0.9. Despliegue del contrato


Web3 = require(’web3’)
web3 = new Web3(new Web3.providers.HttpProvider("http://ritaportal.udistrital.edu.co:
var account=web3.eth.coinbase;
var password="nodo1*123"
web3.personal.unlockAccount(account,password);
var cedula = 1234 ;
var contrasena = "a1b2c3" ;
var co2Contract = web3.eth.contract([{"constant":true,"inputs":[{"name":"cedula","typ
var co2 = co2Contract.new(
cedula,
contrasena,
{
from: web3.eth.accounts[0],
data: ’0x60806040523480156200001157600080fd5b50604051620015173803806200151783398
gas: ’4700000’
}, function (e, contract){
console.log(e, contract);
if (typeof contract.address !== ’undefined’) {
console.log(’Contract mined! address: ’ + contract.address + ’ transactionHa
}
})

0.10. Código página web inicio de sesión


if (typeof web3 !== ’undefined’) {
web3 = new Web3(new Web3.providers.HttpProvider("http://ritaportal.udistrital.edu
console.log(web3.eth.blockNumber);

77
}

Web3 = require(’web3’)
web3 = new Web3(new Web3.providers.HttpProvider("http://ritaportal.udistrital.e
var account=web3.eth.coinbase;
var password="nodo1*123"
web3.personal.unlockAccount(account,password);
var contract = web3.eth.contract([{"constant":true,"inputs":[{"name":"cedula"
var instance = contract.at("0x810d4a1b0f50c48858e088a88b404e024d7aba6e");
var txnObject = {
from: web3.eth.coinbase,
gas: 4700000
}

$(’#ingresar’).click(() => {

var user =$(’#usuario’).val();


var contras = $(’#contra’).val();
var estadosesion=instance.verEstadoSesion.call(1234);
console.log(estadosesion);
var txingresar=instance.ingresar(user,contras,txnObject);
console.log(txingresar);
alert("Se ha enviado los datos de sesión, verifique si esta activo en el esta
});

$(’#consulestado’).click(() => {
var user =$(’#usuario’).val();
var estadosesion=instance.verEstadoSesion.call(user);
console.log(estadosesion);
if(estadosesion==true){
window.location="./index.html";
}else{
alert("Aún no se ha realizado el ingreso");
}

});

78
0.11. Código de la segunda página
if (typeof web3 !== ’undefined’) {
web3 = new Web3(new Web3.providers.HttpProvider("http://ritaportal.udistrital.edu

Web3 = require(’web3’)
web3 = new Web3(new Web3.providers.HttpProvider("http://ritaportal.udistrital.edu
console.log(web3.eth.blockNumber);
$("#transaction-info").find("#block-number").text(web3.eth.blockNumber);
var account=web3.eth.coinbase;
var password="nodo1*123"
web3.personal.unlockAccount(account,password);
var contract = web3.eth.contract([{"constant":true,"inputs":[{"name":"cedula","
var instance = contract.at("0x810d4a1b0f50c48858e088a88b404e024d7aba6e");
var txnObject = {
from: web3.eth.coinbase,
gas: 4700000
};

$(document).on(’click’, ’.transaction’, e => updateTransactionInfoFromLink(e));

$(’#addSensor’).click(() => {
var txingresar=instance.anadirSensor($(’#adUID’).val(),$(’#adPPM’).val(),txnObj
alert("Se ha enviado la transaction");
console.log(txingresar);
$(’#adUID’).val("");
$(’#adPPM’).val("")
web3.eth.getTransaction(txingresar, function(error, transactionInfo) {
if(error) $("#errors").text(error);
else {
$("#transaction-info").find("#hash").text(transactionInfo.hash);
$("#transaction-info").find("#block-number").text(web3.eth.blockNumber);
$("#transaction-info").find("#nonce").text(transactionInfo.nonce);
}
});

$(’#consultar’).click(() => {
var txingresar=instance.consultarPPM($(’#UIDconsul’).val(),txnObject);
$(’#PPM-act’).val(txingresar);

79
console.log(txingresar);
});

$(’#actPPM’).click(() => {
var txingresar=instance.cambiarPPM($(’#UID’).val(),$(’#camPPM’).val(),txn
alert("Se ha enviado la transaction");
web3.eth.getTransaction(txingresar, function(error, transactionInfo) {
if(error) $("#errors").text(error);
else {
$("#transaction-info").find("#hash").text(transactionInfo.hash);
$("#transaction-info").find("#block-number").text(web3.eth.blockNumbe
$("#transaction-info").find("#nonce").text(transactionInfo.nonce);
}
});

$(’#UID’).val("");
$(’#camPPM’).val("")
});

$(’#cerrar’).click(() => {
var estadosesion=instance.cerrarSesion(txnObject);
alert("Se ha cerrado sesion");
console.log(estadosesion);
});

80
Bibliografı́a

Bahga, A. and Madisetti, V. K. (2016). Blockchain Platform for Industrial Internet


of Things. Journal of Software Engineering and Applications, 09(10):533–546.
Cha, S. C., Chen, J. F., Su, C., and Yeh, K. H. (2018). A Blockchain Connected
Gateway for BLE-based Devices in the Internet of Things. IEEE Access, 3536(c).
Christidis, K. and Devetsikiotis, M. (2016). Blockchains and Smart Contracts for the
Internet of Things. IEEE Access, 4:2292–2303.
Dorri, A., Kanhere, S. S., and Jurdak, R. (2017a). Towards an Optimized BlockChain
for IoT. Proceedings of the Second International Conference on Internet-of-Things
Design and Implementation - IoTDI ’17, (October):173–178.
Dorri, A., Kanhere, S. S., Jurdak, R., and Gauravaram, P. (2017b). Blockchain for IoT
security and privacy: The case study of a smart home. 2017 IEEE International
Conference on Pervasive Computing and Communications Workshops (PerCom
Workshops), pages 618–623.
Evans, D., Figuerola, N., Fundación de la Innovación Bankinter, Isenstadt, S., Se-
curity, N. C., Proves, A., Focus, R., Telefónica, F., Verdouw, C. N., Wolfert, J.,
Beulens, A. J. M., Rialland, A., Zhao, X., Fan, H., Zhu, H., Fu, Z., Fu, H., Ruiz-
Garcia, L., Barreiro, P., Robla, J. I., Lunadei, L., Barreiro, P., and Robla, I. (2011).
Internet de las cosas: Cómo la próxima evolución de Internet lo cambia todo. Jour-
nal of Food Engineering, 49(Emim):314–318.
Fabiano, N. (2017). The Internet of Things ecosystem: The blockchain and privacy
issues. the challenge for a global privacy standard. Internet of Things for the Global
Community, IoTGC 2017 - Proceedings, 2060.
Heath, S. (2002). Embedded Systems Design. Elsevier Science.
Khan, M. A. and Salah, K. (2018). IoT security: Review, blockchain solutions, and
open challenges. Future Generation Computer Systems, 82:395–411.

81
Lewis, A. (2015). Blockchain Technology Explained. Blockchain Technologies, pages
1–27.
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
Www.Bitcoin.Org, page 9.
Preukschat, A. (2017). Blockchain: la revolución industrial de internet.

Roman, R., Zhou, J., and Lopez, J. (2013). On the features and challenges of security
and privacy in distributed internet of things. Computer Networks, 57(10):2266–
2279.
S. Li, L. D. X. and Zhao, S. (2015). The internet of things: a survey. Information
Systems Frontiers, 17(2):243–259.

82

También podría gustarte