Tesis Prototipo Blockchain
Tesis Prototipo Blockchain
Tesis Prototipo Blockchain
proyecto de grado
para obtener el tı́tulo de
Ingeniero Electrónico
presenta
Índice de figuras 1
Resumen 3
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
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
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
Bibliografı́a 81
6 ÍNDICE GENERAL
Índice de figuras
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
3
Planteamiento del problema
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).
5
Justificación
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.
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).
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).
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.
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).
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
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).
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).
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).
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:
16
puede resultar en el agotamiento de los recursos y las escuchas no autorizados
(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).
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)
Protocolo: Este protocolo define la forma de comunicación entre los nodos que
están presentes en la red Blockchain.
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).
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).
20
Figura 5: Marca de tiempo(Nakamoto, 2008)
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:
Tener verificabilidad sobre el proceso ya que todas las interacciones están fir-
madas digitalmente.
22
pecto al resultado final de este proceso verificable en el que participaron (Christidis
and Devetsikiotis, 2016).
23
Estado del arte
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.
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).
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.
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.
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:
3. Usuarios finales
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.
29
Desarrollo
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.
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).
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
34
Figura 11: Base de datos
35
Figura 13: Archivo php
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.
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.
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:
38
Figura 16: Código para crear la solicitud en formato JSON
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:
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
41
Desarrollo Smart Contract
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.
La palabra mapping en Solidity se utiliza para crear tablas de valores con las
estructuras definidas previamente.
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.
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.
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.
45
Figura 24: Código de interacción con los datos 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.
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:
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
49
Figura 26: Cuentas simuladas por medio de testrpc
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)
Figura 28: Lineas de código despliegue del Smart Contract en la red de nodos de
RITA
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.
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.
53
Figura 31: Diagrama de uso
54
Resultados y análisis de
resultados
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.
56
Figura 35: LED encendido (azul) al superar el valor máximo permitido
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.
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.
59
Anexos
0.1. Blink
void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(LED_BUILTIN, OUTPUT);
}
#include <WiFi.h>
#include <PubSubClient.h>
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();
#include <WiFi.h>
#include <PubSubClient.h>
#define anInput A6
#define co2Zero 55 //CO2 inicial
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);
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....................
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);
}
}
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);
#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);
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);
<?php
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;
?>
#include <WiFi.h>
#include <WiFiClient.h>
#include <HTTPClient.h>
#include <ArduinoJson.h>
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());
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);
68
Serial.println(gethResult);
delay(8000);
}
#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());
}
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) {
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);
70
co2now[x]=analogRead(A6);
delay(200);
}
}
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
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);
if (ledOn == 1){
digitalWrite(LED_BUILTIN, HIGH);
}
else {
digitalWrite(LED_BUILTIN, LOW);
}
delay(5000);
}
72
}
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;
}
73
modifier onlyOwner{
require(msg.sender==owner);
_;
}
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
}
/*---------------------------A~
nadir Sensor------------------------------------*/
75
}
76
if(sensor[bus].PPM <= PPMS){
return true;
}
}
return false;
}
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(() => {
$(’#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
};
$(’#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
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