LSB, un blockchain escalable y ligero para IoT

Hola amig@

Hoy os traigo una traducción de este artículo técnico que me ha parecido que describe muy bien lo que podría ser un entorno IoT enlazado con un Blockchain adaptado. Tiene algunas peculiaridades e ideas originales y, aunque puede que no sea una idea final, sí pone de manifiesto las opciones que se pueden presentar en entornos distribuidos formados por dispositivos con poca capacidad de proceso.

El título del artículo, «LSB, un blockchain escalable y ligero para IoT», ya nos indica que esta propuesta de arquitectura IoT ya simplifica las características que requieren mayor computación de un blockchain típico y al mismo tiempo permite una escalabilidad hacia un gran número de nodos.

Puedes encontrarlo en su versión original aquí. Como siempre, te recomiendo la aplicación Mendeley para tener tu biblioteca de artículos y PDFs, y poder leerlos en cualquier dispositivo.

Los autores son: Ali DorriSalil S. KanhereRaja JurdakPraveen Gauravaram

(Dorri, A., Kanhere, S. S., Jurdak, R., & Gauravaram, P. (2017). LSB: A Lightweight Scalable BlockChain for IoT Security and Privacy. Retrieved from http://arxiv.org/abs/1712.02969)

Primero te mostraré una traducción lo más fiel posible del abstract (resumen del artículo), luego podemos hacer juntos un repaso del contenido técnico del mismo y finalmente te pondré una traducción de las conclusiones de los autores.

(tiempo de lectura aproximado: 15 min)

Abstract (traducción literal)

Blockchain (BC) atrae una atención tremenda debido a su naturaleza inalterable a los beneficios asociados en seguridad y privacidad. BC tiene el potencial de superar los retos de seguridad y privacidad del Internet de las Cosas (IoT). Sin embargo, BC es computacionalmente caro, tiene una escalabilidad limitada e incurre en elevados de ancho de banda y restrasos que no son apropiados para el contexto de IoT. Proponemos un BC ligero, escalable y estratificado (LSB) que está optimizado para los requisitos de IoT.

Hemos probado LSB en una configuracion de casa inteligente como un ejemplo representativo de aplicaciones IoT más amplias. Los dispositivos con pocos recursos en un hogar inteligente se benefician de un gestor centralizado que establece las claves compartidas para las comunicaciones y procesa todas las peticiones entrantes y salientes. LSB consigue la descentralización formando una red donde los dispositivos con altos recursos controlan un BC público de forma conjunta, que permite la privacidad y seguridad de extremo a extremo. La red está organizada con distintos clusters para reducir los retrasos y los cabeza de cluster son los responsables de manejar el BC público.

LSB incorpora varias optimizaciones como los algoritmos para un consenso ligero, confianza distribuida y gestión del ancho de banda. Algunos datos cualitativos demuestran que LSB es resiliente a distintos ataques de seguridad. Las simulaciones exhaustivas han demostrado que LSB decrementa el tamaño de los paquetes y los retrasos e incrementa la escalabilidad de BC comparado con las principales referencias.

Introducción a LSB, un blockchain escalable y ligero

En la introducción los autores nos explican brevemente qué es Blockchain (BC) y qué beneficios trae a IoT, como la seguridad y la privacidad. También detallan por qué los BC convencionales no aplican a IoT, básicamente por los siguientes motivos:

Algoritmos de consenso complejos. Normalmente los dispositivos IoT tienen pocas capacidades de computación y no podrían abordar este tipo de trabajos. Aquí puedes leer un poco más sobre algoritmos de consenso

Escalabilidad y sobrecargas de red: Debido a que los bloques en un BC son retransmitidos a todos los nodos de la red, el sobrecoste en comunicaciones puede llegar a ser muy grande, limitando la capacidad de crecimiento de las redes en IoT, que además suelen usar redes con poca capacidad de transmisión.

Latencia. Debido a la seguridad intrínseca en un BC se puede llegar a tardar varios minutos en confirmar un bloque nuevo. En las aplicaciones IoT se suelen considerar tiempos de acceso a la información mucho menores.

Sobrecarga de seguridad. En algunos BC se usan algoritmos de seguridad para protegerse las operaciones dobles, o lo que es lo mismo, usar dos veces el mismo token. Estos algoritmos tienen mucho sentido en otros BC pero no para IoT.

Rendimiento. IoT puede necesitar muchos más bloques por segundo que un BC normal debido a la interacción entre dispositivos físicos.

En el artículo proponen una arquitectura de Blockchain ligero y escalable, LSB (Lightweight Scalable Blockchain). Usan un ejemplo de hogar inteligente para ilustrar su funcionamiento, aunque aseguran que el sistema propuesto es agnóstico al uso que se le de. Para este caso el sistema se divide en dos capas:

  • SmartHome. Es la red de dispositivos locales del hogar. Las operaciones entre entidades se llaman transacciones y se almacenan en un registro inmutable local (IL), que es similar a un BlockChain (BC) pero manejado de forma centralizada.
  • Overlay. Es la red que une los SmartHome entre sí. Está organizada en clusters que de forma organizada manejan un BC público, donde almacenan las transacciones de esta capa.

Lightweight Scalable Blockchain (LSB)

Antes de nada dos definiciones:

  • Transacción, es la comunicación básica entre dos entidades con información de control exclusivamente. El flujo de datos entre dispositivos se hace de forma independiente
  • Gestor de bloques o Block Manager (BM). Entidad responsable de manejar el BC: creación de génesis, verificación y almacenamiento de las transacciones y bloques de transacciones. Los BMs en las capas SmartHome y Overlay tienen diferentes funciones como se verá más adelante.

Capa Overlay

Al igual que ocurre en un BC típico, esta estructura comienza con un bloque génesis y el resto de transacciones hacen referencia al bloque anterior, de tal manera que se hace imposible la modificación de bloques de transacciones históricos sin romper la verificación de todo el conjunto.

Los nodos en esta capa se organizan en clusters, y solo un elemento del cluster es elegido para manejar el BC público, al que se conoce como Cluster Head (CH) o Overlay Bloc Manager (OBM). De esta forma se asegura la escalabilidad del sistema, independientemente de cuántos nodos tenga. Los OBM deben ser dispositivos con la suficiente capacidad de computación y que permanezcan encendidos la mayor parte del tiempo.

Las transacciones posibles en esta capa son:

  • Genesis, para crear el primer bloque del BC. Cada BM en esta capa genera su propio bloque génesis, desde donde registra las operaciones que se generan desde su cluster.
  • Store, para almacenar datos en un sistema en la nube
  • Access, para solicitar datos históricos perteneciente a un dispositivo
  • Monitor, para obtener el estado y los datos en tiempo real de un dispositivo

Como decía antes, las transacciones se agrupan en bloques, que son los que van finalmente al BC. El flujo de datos va aparte y es unicast, a diferencia que las transacciones que se retransmiten a todos los nodos.

Cuando un OBM recibe una transacción comprueba si el solicitante pertenece a su cluster y si está en una lista de acceso (ACL) para determinar si tiene permisos de comunicación con el dispositivo solicitado. Si el dispositivo no está en el cluster, el OBM hace un broadcast de la transacción y espera que se confirme con el mecanismo del BC público.

El algoritmo de consenso se basa en esperas aleatorias de cierta  cantidad de tiempo, llamado período de consenso. El período máximo es de 10 minutos y el mínimo es igual al doble del tiempo de retraso de paquetes entre los extremos más alejados del sistema. Esto asegura que los nodos no saturen la red con bloques y que un posible nodo falso que quiera inundar la red con bloques maliciosos no pueda prosperar, pues los nodos vecinos descartarán los bloques al no tener una separación mínima en el tiempo.

La verificación de los bloques se realiza antes de añadirlo al BC. Cada solicitante distinto tiene su propio BC, y esta es una característica muy especial de ese sistema. Los OBM generan los bloques con claves privadas (PK) que son conocidas por el resto de OBMs. Para verificar un bloque todas sus transacciones deben ser verificadas mediante la comprobación del enlace entre ellas, la veracidad de las PK contenidas y mediante un contador en la cabecera que lleva la cuenta de bloques verificados vs bloques rechazados.

Es decir que en el BC de cada solicitante se aloja la autenticidad de dicha entidad, gracias al histórico de transacciones ya verificadas anteriormente. Este mecanismo por lo tanto es un algoritmo distribuido de confianza entre nodos. De hecho, no todas las transacciones son verificadas dentro de un bloque, cuanto mayor es el nivel de confianza en el origen del bloque menos transacciones se verifican, aunque siempre se hace con un mínimo. Si a un nodo origen se le empiezan a rechazar sus transacciones, este contador de la cabecera lo reflejará y el resto de nodos empezará a incrementar el número de transacciones que le verifican.

Además, LSB implementa un sistema distribuido de rendimiento (Distributed Throughput Management o DTM), para monitorizar y ajustar el uso que se hace del BC público y no sobrepasar ciertos límites. El uso del BC se calcula como el ratio entre el número de nuevas transacciones y el número de transacciones añadidas al BC.

Si quieres conocer las fórmulas y matemática detrás del algoritmo te aconsejo que descargues el artículo original. No son complicadas, pero sería un verdadero tocho ponerlo aquí.

Tan solo indicarte que el rendimiento de la red se gestiona modificando el período de consenso y reclusterizándola en caso de que varíe el número de nodos en la red overlay.

Capa SmartHome

Los dispositivos en la red local son gestionado por un Local Block Manager (LBM) y las transacciones almacenadas en un Inmutable Ledger (IL), o registro inmutable. Este IL también almacena las transacciones que vienen o van hacia la capa Overlay, y cada IL tiene su propio bloque genesis.

Igual que ocurre en la capa Overlay, cada dispositivo tiene su propio IL, dentro de un único BC.

Como requisito se debe cumplir que cada SmartHome tenga un almacenamiento donde poder alojar estos IL para la gestión de dispositivos.

Arquitectura simplificada de LSB
LSB, un blockchain escalable y ligero para IoT

Transacciones

Transacciones locales

Como te decía más arriba, las transacciones locales son las que se producen entre dispositivos de la red SmartHome, normalmente con pocos recursos computacionales. Para simplificar la tarea la encriptación es simétrica y cada dispositivo tiene su PK (private key) que ha sido generada por el LBM (local block manager). Además cada dispositivo tiene su propio BC que almacena las transacciones originadas por él.

Las operaciones de estas transacciones son:

  • Genesis, para iniciar su BC y que le devuelve su propia PK con la que funcionará desde ese momento.
  • Store locally, envío de información a sistema de almacenamiento local, previa autorización al LBM, que autentica al dispositivo gracias a su PK.
  • Data exchange, solicitud de datos de otro dispositivo, previa autorización del LBM. Una vez autorizados, los dispositivos se comunican directamente.

Transacciones overlay

Son las transacciones en las que el solicitante y el receptor son nodos de la capa overlay.

Como decía antes, estas son las operaciones que pueden realizar estas transacciones:

  • Genesis, cada nodo crea su bloque génesis en la BC. La puede generar partiendo de las PKI (Public Key Infraestructure) en Internet, con un certificado expedido por una autoridad certificadora oficial, o bien puede “quemar” o destruir un bitcoin y usar la dirección de referencia de dicha operación como PK para el bloque inicial. Una vez verificada la transacción por el resto de nodos en la overlay, esta se almacena en el BC.
  • Store cloud, usada para almacenar información en alguno de los sistemas de almacenamiento en la nube. Se entiende que previamente ha debido haber un intercambio de claves (pública/privada) e identidades que permiten que un nodo use dicho almacenamiento. Una vez el proceso de almacenamiento ha finalizado, el sistema de almacenamiento debe firmar la operación para que esta quede almacenada en el BC.
  • Access y monitor. En ambas operaciones el OBM debe comprobar que tiene en la lista el par origen y destino y, de no ser así, hacer un broadcast de la transacción hasta que otros OBM la validen. Cuando el acceso al dato ha finalizado, recuerda que se hace por un canal distinto, el LBM del solicitado firma la operación y esta se almacena en el BC.

En el último punto del documento los autores hacen un analisis de la seguridad, la privacidad y la tolerancia a fallos del LSB. Para esto consideran adversarios que bien podrían ser nodos de la propia red, podrían interceptar tráfico, falsear datos, firmar transacciones, etc. Pero sí asumen que los protocolos estándar de encriptación no son vulnerables.

Se exponen una serie de posibles ataques y cómo quedan resueltos en LSB, si quieres conocer más sobre este aspecto, te aconsejo que consultes directamente el documento.

También realizan un interesante análisis del rendimiento de la red dependiendo del número de nodos y cantidad de transacciones. Para ello han usado dos herramientas de simulación: Cooja y NS3.

Estas simulaciones arrojan interesantes gráficos donde se aprecia el retraso introducido por usar LSB en vez de comunicación directa entre dispositvos, el consumo de energía del sistema o cómo conforme más nodos hay en la red menos sobrecarga de datos de control penalizan las transacciones.

Otras de las ventajas apreciables tras estas simulaciones es el tiempo de validación de un nodo, que gracias al algoritmos de confianza distribuido se estabiliza y deja de aumentar cuando la cantidad de nodos llega a 45.

Pero sin duda el que más te va a sorprender es el que explica que a partir de 14 nodos en la red el sistema es totalmente seguro ante ataques.

 

Conclusión (traducción literal)

En este artículo hemos argumentado que aunque BlockCain es una tecnología efectiva para dar seguridad y privacidad a IOT, su aplicación en ese contexto presenta varios retos significativos, incluyendo: complejidad, ancho de banda, latencia y escalabilidad. Para solucionar estos retos proponemos un BC ligero y escalable (LSB) para IoT. LSB tiene un algoritmo de consenso adecuado para IoT que elimina la necesidad de resolver un puzzle antes de agregar un bloque al BC.

LSB incorpora un método de confianza distribuido mediante el cual el tiempo de proceso para validar nuevos bloques decrementa gradualmente conforme se refuerza la confianza entre los OBMs. Una estrategia de rendimiento distribuida ajusta ciertos parámetros del sistema para asegurar que el uso de la red se mantiene dentro de los parámetros deseados. El análisis de seguridad demuestra que LSB es altamente segura frente a un amplio abanico de ataques. En las situaciones que falle un nodo, la operación de LSB muestra una degradación suave, haciéndola por lo tanto muy tolerante a fallos.

Los resultados de las simulaciones muestran que la arquitectura propuesta decrementa el ancho de banda y tiempo de procesamiento comparado con los BC clásicos.

Además los propietarios de SmartHomes reciben los servicios sin un retraso adicional para las transacciones locales y con un retraso imperceptible en las transacciones con la red exterior.

Generalmente LSB aporta un alto grado de seguridad y privacidad a los usuarios de IoT sin tener una gran penalización.  Como futura dirección de este trabajo, se puede considerar relajar algunos de los supuestos hechos en LSB, por ejemplo considerando casos en los que el gestor de bloques local ha sido comprometido.

En nuestro trabajo futuro queremos desarrollar un prototipo de implementación de LSB para entender su rendimiento en configuraciones del mundo real. También exploraremos la aplicación de LSB en otro dominios como las smart-grids y las redes de vehículos.

 

 

Hasta aquí la presentación de LSB, te recuerdo que si quieres ver el artículo académico completo puedes acceder su publicación en archiv.org

Si quieres ver más arquitecturas para IoT, vuelve a la sección de arquitecturas.

Por favor, síguenos y comparte:
error

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.