ARQUITECTURA DE REFERENCIA DE SEGURIDAD PARA BLOCKCHAIN
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
ARQUITECTURA DE REFERENCIA DE SEGURIDAD
PARA BLOCKCHAIN
María I Ortega1, Julio Moreno2, Manuel A. Serrano3 and Eduardo Fernández-Medina4
1
Telefónica, Madrid, España
2
NTT Data, Madrid, España
3
Alarcos, UCLM, Ciudad Real, España
4
GSyA, UCLM, Ciudad Real, España
mariaisabel.ortegacanalejo@telefonica.com
Resumen. La seguridad de la tecnología blockchain está más que nunca en el
punto de mira. Constantemente se identifican ataques a DLTs (Distributed Led-
ger Technology), incluyendo blockchain, que ponen de manifiesto la necesidad
de reforzar la seguridad de éstas. El uso de arquitecturas de seguridad de refe-
rencia (SRA) ha demostrado ser útil para abordar la seguridad en las primeras
fases del desarrollo facilitando la definición de requisitos de seguridad y ayu-
dando a implementar políticas de seguridad que nos permitan proteger un sistema
durante todo el ciclo de vida. En este artículo se presenta una SRA para la tecno-
logía blockchain definida mediante modelos y comprobando su aplicación me-
diante un ejemplo de uso.
Keywords: Blockchain, arquitectura de referencia, SRA, seguridad por diseño.
1 Introducción
Desde la aparición en 2008 de Bitcoin [1], la tecnología blockchain no ha dejado de
sumar adeptos. Prueba de este interés, es la creciente inversión que se está realizando
en blockchain tanto en la industria como en el mundo académico. Esta creciente inver-
sión puede verse reflejada en el estudio de MarketsandMarkets [2], en el que se estima
que el uso de blockchain pasará de 258 millones de dólares en 2020 a 2.409 millones
de dólares en 2026, con una tasa de crecimiento anual media del 45,1%. Además, los
resultados de la encuesta anual global de 2020 sobre blockchain realizada por Deloitte
[3], revelaron que el 53% de las organizaciones consideran que blockchain es una de
sus cinco prioridades estratégicas. Así mismo, la tendencia de los resultados indica que
se trata de una tendencia creciente, ya que el año anterior sólo el 43% de los encuestados
contaban con esta opinión.
A pesar de que la tecnología blockchain se presenta como una tecnología de registro
de transacciones a prueba de manipulaciones, es una realidad que las redes blockchain
no son inmunes a los ciberataques y al fraude. De hecho, se estima que durante el primer
trimestre de 2019 se produjo la pérdida de más de 356 millones de dólares en redes2 blockchain por problemas relacionados con la seguridad [4]. Algunos ejemplos concre- tos de estas acciones son la pérdida de 13 millones de dólares de EOS y 6 millones de dólares en Ripple sólo durante el mes de marzo de 2019 [5]. Además, un nuevo informe de la firma de inteligencia de amenazas de criptocurrency forensics y blockchain Cip- hertrace [6] muestra que han sido sustraídos 100 millones de dólares de redes distribui- das sólo en 2020, lo que refuerza la importancia de que la seguridad esté presente en cualquier solución blockchain. Hay muchas variables a tener en cuenta a la hora de diseñar una solución de seguri- dad. En general, las amenazas de seguridad se dividen en tres categorías principales [7]: vulnerabilidades en el endpoint, código no comprobado y riesgo en el ecosistema pro- pio o de terceros. En primer lugar, las vulnerabilidades endpoint se presentan como el método más directo y potencialmente más fácil de atacar sobre cualquier solución tecnológica [7] como pueden ser carteras digitales, dispositivos o aplicaciones. Si uno de estos puntos se ve comprometido y un actor malintencionado obtiene acceso a una cuenta, a menos que se establezcan protecciones de seguridad adicionales, es posible que se realice una acción fraudulenta sin que se produzca ninguna alarma externa o señal de comporta- miento anormal. En segundo lugar, el código no comprobado es un reflejo de cómo a medida que las nuevas tecnologías entran en el mercado, los desarrolladores se ven incentivados a ser los primeros en presentar una solución, a menudo con el riesgo de desplegar un código insuficientemente probado en blockchains activas. Un ejemplo muy conocido es el ata- que a la organización autónoma descentralizada (DAO) de la red Ethereum en 2016, dónde se desarrollaron códigos y contratos inteligentes en los que existían vulnerabili- dades en el código. Esto provocó la explotación de una vulnerabilidad que tenía la ca- pacidad de manipular los contratos inteligentes para extraer el dinero debido a un error en una llamada recursiva con la que se consiguió desviar cerca de 60 millones de dóla- res. Como última amenaza, destaca el riesgo inherente en el ecosistema de las aplicacio- nes que utilizan blockchain que puede incluir la asociación con proveedores o terceros. Una seguridad deficiente del ecosistema o un código defectuoso pueden exponer las credenciales de los usuarios y los datos de la cadena de bloques a personas no autori- zadas. Para hacer frente a las amenazas de seguridad, la seguridad debe abordarse a partir de políticas de alto nivel que puedan ser trasladadas a niveles inferiores [8]. Las Arqui- tecturas de Referencia (RA) proporcionan un modelo abstracto que soporta uno o más dominios y no tiene características de implementación [9] permitiendo así, que sean reutilizables, escalables y configurables [10]. Al incorporar un conjunto de elementos que facilitan la definición de los requisitos de seguridad y permiten una mejor com- prensión de la seguridad, las políticas, las amenazas y las vulnerabilidades, obtenemos una Arquitectura de Referencia de Seguridad (SRA), es decir, una arquitectura de alto nivel que puede utilizarse para describir un modelo conceptual de seguridad de un sis- tema. En este trabajo hemos definido una SRA para blockchain, basándonos en las dife- rentes propuestas de la comunidad científica, las diferentes propuestas de la industria y
3 la implementación habitual de múltiples sistemas blockchain abstrayendo sus compo- nentes y basándonos en los principales ataques que hacen vulnerable a un sistema blo- ckchain para identificar los elementos de la arquitectura que son más vulnerables y en los que se debe centrar la implementación de una solución de seguridad. Nuestra propuesta presenta una arquitectura que sirve de base para el desarrollo de un sistema blockchain, ya sea con fines académicos o en la industria, considerando la seguridad desde el diseño del sistema de forma integrada en la pila de la tecnología blockchain para evitar que se considere sólo en el momento del lanzamiento, o como algo que rodea a una aplicación una vez desarrollada. Organizamos el contenido del documento de la siguiente manera: en primer lugar, se presentan los trabajos relacionados existentes; en segundo lugar, se presenta nuestra propuesta de SRA para blockchain; en tercer lugar, comparamos nuestra arquitectura con un caso real de estudio mostrando cómo se pueden instanciar los diferentes com- ponentes que intervienen en su abordaje. Por último, incluimos una sección en la que se discuten las conclusiones y el trabajo futuro. 2 Trabajos relacionados La normalización de la tecnología blockchain es un paso importante hacia un concepto común, la interoperabilidad, el escalado, la auditoría y la posible regulación posterior de la tecnología. Aunque existen varias iniciativas de definición de normas y estándares para el desarrollo y mantenimiento de blockchain, se encuentran en una fase muy pre- liminar, siendo esto un obstáculo para el asentamiento de la tecnología [11]. Existen múltiples iniciativas de organizaciones que están trabajando en documentos de estandarización. La Norma UNE 71307-1 [12] define un marco de referencia gené- rico para la gestión de identidades de individuos u organizaciones, permitiendo contro- lar su propia identidad digital de forma auto-gestionada en un sistema blockchain. El NIST publicó en 2018 NISTIR 8202 - Blockchain Technology Overview [13]. Este documento aborda las funcionalidades y componentes fundamentales de un sistema blockchain, así como las preocupaciones de ciberseguridad y la aplicabilidad general de blockchain en las organizaciones. El propósito de este documento es únicamente servir de punto de entrada a la tecnología de blockchain, ya que explica la estructura y los modelos, los mecanismos de consenso y los ejemplos conocidos de la misma, así como una serie de cuestiones y consideraciones específicas de blockchain sin profun- dizar en los elementos técnicos. ANSI SCX9 publicó también en 2018 el informe de su grupo de estudio sobre DLT (Distributed Ledger Technology) y blockchain [14]. En este estudio trabajaron junto con expertos de varios campos y evaluaron qué tipos de esfuerzos de estandarización serían tanto necesarios como beneficiosos especialmente para el sector financiero, pero también para otras industrias, así como para aumentar la adopción de DLT. La mayor parte del documento se centra en las necesidades y los problemas de seguridad de blo- ckchain que aborda principalmente centrándose en el ámbito financiero. Para facilitar la comprensión de los componentes clave de los sistemas blockchain, se incluye en el
4
apéndice una arquitectura de referencia de alto nivel para ofrecer una explicación ge-
neral del funcionamiento de un sistema DLT. La norma ISO/TR 23455:2019 [15]
ofrece un extenso debate de los contratos inteligentes dentro de un sistema de blo-
ckchain/DTL y su funcionamiento.
Es posible además apreciar el interés en abordar la seguridad por diseño, la norma
DIN SPEC 4997 Privacy by Blockchain Design [16] describe un modelo estandarizado
para el tratamiento de datos personales mediante blockchain teniendo en cuenta el Re-
glamento General de Protección de Datos (GDPR) de la UE. De especial interés es el
Art. 25, Privacidad por diseño. El documento presenta una visión general de los riesgos
y mitigaciones de los principios de protección de datos con un claro enfoque en la pri-
vacidad por diseño, así como un proyecto de arquitectura de privacidad por diseño de
blockchain.
Homoliak et.al. [17] propone una arquitectura basada en versión específica para blo-
ckchain de la norma de evaluación de riesgos de amenazas ISO/IEC 15408 mediante la
adaptación de una versión personalizada del modelo apilado de cuatro capas presentado
en el trabajo de Wang et al. [18]. Esta propuesta, diferencia de este trabajo, que se
centra únicamente en el riesgo sin tener en cuenta objetivos empresariales ni la orques-
tación de políticas de seguridad.
A pesar del creciente interés en la estandarización de los sistemas blockchain, no se
han realizado estudios que hayan definido arquitecturas de seguridad en los que se
aborde la implementación de sus diferentes componentes. En este artículo se realiza
una propuesta de SRA para blockchain dónde se especifican los componentes de la
tecnología, así como, las relaciones entre los diferentes componentes y subcomponen-
tes. También se integran diferentes conceptos de seguridad para garantizar la protección
de este tipo de sistemas.
3 Arquitectura de referencia de seguridad para
Blockchain
En este trabajo se han analizado las funcionalidades y componentes fundamentales de
un sistema blockchain que han sido propuestos por el NIST [13], así como las preocu-
paciones de ciberseguridad y la aplicabilidad general de blockchain. También se han
considerado las principales implementaciones de blockchain en el mercado centrándo-
nos en Bitcoin [1], Ethereum [19], Hyperledger [20] por ser las tecnologías más conso-
lidadas a día de hoy y se han abstraído sus principales componentes para crear nuestra
arquitectura. Hemos definido nuestra SRA a través de diagramas UML ya que encon-
tramos una carencia de propuestas en las que se definan con precisión las relaciones
entre los diferentes componentes y subcomponentes. Así mismo, se trata de un lenguaje
ampliamente aceptado que facilita la comprensión de las relaciones entre los diferentes
componentes. Se ha utilizado un modelo en capas ya que nos ofrece simplicidad en la
implementación y el mantenimiento, flexibilidad y escalabilidad. La arquitectura está
dividida en seis componentes diferentes que interactúan entre sí con diferentes objeti-
vos: capa de negocio, capa de orquestación, capa de aplicación, capa de servicio, capa5
de plataforma y capa de red. La Fig.1 muestra la Arquitectura de Referencia de Segu-
ridad la arquitectura completa, así como todas las relaciones entre los diferentes com-
ponentes y sub-componentes.
Fig. 1. Arquitectura de Seguridad para Blockchain6 3.1 Capa de negocio La capa de negocio tiene como objetivo definir las reglas de negocio que recogen las funcionalidades que debe ofrecer la red blockchain. Debido a las características de esta capa, las actividades de seguridad relacionadas se centran en general en la definición de políticas de seguridad de desde la capa de orquestación, descrita en la siguiente sec- ción, y en cómo implementarlas y supervisarlas. El sistema blockchain debe satisfacer el objetivo para el que ha sido creado cum- pliendo con los objetivos a la vez que manteniéndose alineados con los diferentes ob- jetivos de negocio y las políticas de la empresa. En este sentido, el papel del adminis- trador de seguridad es crucial para garantizar el cumplimiento de los requisitos de se- guridad. Estos requisitos de seguridad deben cumplir con la normativa que afecta a cada contexto del ecosistema y serán definidos en la siguiente capa. 3.2 Capa de orquestación La capa de orquestación tiene como objetivo abordar los diferentes requisitos que debe cumplir el ecosistema blockchain. Según Biktimirov et al. [21] los requisitos de la tec- nología blockchain pueden dividirse en los siguientes grupos: ─ Requisitos estructurales sobre la disponibilidad de determinados tipos de datos en los enlaces de blockchain para garantizar el funcionamiento de la tecnología. ─ Requisitos empresariales relacionados con las políticas aplicadas, como las normas internacionales de criptografía, así como las normas nacionales o institucionales en los ámbitos de aplicación: fiscalidad, tecnologías de votación, flujo de trabajo de documentos internos, etc. Estos requisitos deben estar alineados con los objetivos del proceso de negocio para satisfacer la función para la que han sido definidos. ─ Requisitos tecnológicos sobre la fiabilidad del almacenamiento de bloques, utili- zando la tecnología propuesta por Zitsev et al. [22] para mantener los parámetros de fiabilidad y disponibilidad del almacenamiento de enlaces. ─ Requisitos de fiabilidad con una estructura clara de la cadena de bloques, tecnologías reguladas de procesamiento de enlaces y una interfaz para las operaciones de enlace. Todas las interfaces aplicadas deben estar disponibles con código fuente para garan- tizar un alto nivel de confianza. Los requisitos de seguridad pueden ser satisfechos por diferentes soluciones de se- guridad que siguen las políticas de seguridad de la empresa y tienen como objetivo principal hacer frente a las amenazas para controlar las vulnerabilidades. La definición de estas soluciones de seguridad puede ser guiada por el uso de patrones de seguridad, los cuales, se puede definir como una solución a problemas recurrentes que indican cómo defenderse de una amenaza, o de un conjunto de amenazas, de forma concisa y reutilizable [35].
7
3.3 Capa de aplicación
La capa de aplicación contiene soluciones para el usuario final y aplicaciones que se
construyen sobre la red blockchain; por lo tanto, las amenazas a la seguridad son espe-
cíficas para cada aplicación. Esta capa puede existir total o parcialmente fuera de la
red [19]. Uno de los elementos centrales de la capa de aplicación son las Aplicaciones
Descentralizadas o DApps. Se trata de aplicaciones software que se ejecutan en una red
descentralizada peer-to-peer, normalmente una red blockchain. Las DApps suelen in-
cluir una interfaz de usuario que se ejecuta en otro sistema (centralizado o descentrali-
zado). Las DApps también incluyen exploradores de blockchain, herramientas de mon-
itorización y otras herramientas de inteligencia empresarial.
Los exploradores implementados en una red blockchain son la forma más habitual
de recuperar información, estando habitualmente las partes de confianza centralizadas.
En el caso de las herramientas de monitorización facilitan la gestión de múltiples redes,
la identificación de problemas y el mantenimiento general de la salud de la red de la
cadena de bloques. Las herramientas de inteligencia empresarial proporcionan, además,
una plataforma para el seguimiento de los registros mantenidos en su base de datos
cifrada basada en el libro mayor.
Dado que se permite a los desarrolladores desarrollar sus propias DApps con con-
tratos inteligentes personalizados, son aplicaciones muy vulnerables a ataques. Un caso
común es que se produzca un ataque en la fase de transferencia de la información del
nodo. Aplicar una solución de seguridad específica según el funcionamiento de la apli-
cación permitirá disminuir el impacto de estos.
3.4 Capa de servicio
La capa de servicio permite hacer más accesible la cadena de bloques, en particular
para las empresas, reduciendo los costes y los gastos generales de adopción de la tec-
nología. La naturaleza precisa de una implementación de SaaS (Software as a Service)
dependerá del proveedor de servicios, las especificaciones de la aplicación y los ob-
jetivos del cliente [23]. Esta capa integra los gestores de activos, eventos del block-
chain.
La gestión de activos tiene como objetivo garantizar la gestión de los activos de la
capa de la plataforma, siendo los activos almacenados en la cadena de bloques la razón
principal de la existencia de la cadena. El activo digital puede ser unidades monetarias
o de otro tipo, sobre los que una organización quiere interactuar.
La gestión de los activos puede ser integrada con los sistemas de gestión empresarial
a través de interfaces externas mediante APIs, bibliotecas y técnicas comunes. Una co-
nexión directa con el núcleo de blockchain permite el correcto funcionamiento de estas
herramientas [19]. Además de las capacidades de despliegue y configuración, es im-
portante que existan posibilidades para gestionar eventos como la notificación de fallos
del software, la gestión del rendimiento, la gestión de la seguridad, la integración con
otro software empresarial y las herramientas de análisis histórico. Estos eventos pueden
ser generados través de estas APIs, bibliotecas y técnicas comunes.8 En el caso de blockchain destaca el uso de offchains y oráculos para la gestión de eventos. Las transacciones offchain, que se producen fuera de la cadena, están ganado popularidad debido a su coste cero/bajo. Las transacciones fuera de la cadena ofrecen muchas ventajas: pueden ser ejecutadas instantáneamente, no suelen tener una comisión por transacción, ya que nada ocurre dentro de la blockchain, y ofrecen más seguridad y anonimato a los participantes, ya que los detalles no se transmiten públicamente, lo que hace imposible averiguar parcialmente la identidad de un participante estudiando los patrones de las transacciones. Los oráculos ofrecen un servicio externo a la cadena que es llamado para proporcionar información de una fuente externa, por ejemplo, una tasa de cambio o el resultado de un cálculo matemático. Los oráculos son un puente seguro entre los contratos inteligentes y las fuentes de información del mundo real. La gestión de la identidad es primordial para la gestión de las claves privadas crip- tográficas, que están asociadas a la cuenta de un usuario. Los clientes de blockchain suelen optar por ofrecer una gestión local de las credenciales de los usuarios, como las claves del sistema y de la cartera. Estas facilidades también pueden aplicarse fuera del ámbito de un cliente. La solución de seguridad en esta capa adquiere relevancia al estar compuesto por elementos sensibles. Se deben implementar políticas que eviten una explotación inde- bida protegiendo que todas las transacciones sean legítimas y que la gestión de activos e identidades no se explote adulterando los activos. 3.5 Capa de plataforma Es el núcleo de la arquitectura y se encarga de la ejecución de la lógica de la red, con- tiene los elementos necesarios para la publicación de cada bloque. En función de la implementación de este componente existe la posibilidad de la creación y gestión por parte de terceros de redes basadas en la nube para empresas dedicadas a la construcción de blockchain. La solución de seguridad en la capa de la plataforma tiene como objetivo mitigar el daño que se puede causar a una red blockchain mediante la explotación de las vulnera- bilidades identificadas, protegiendo los activos digitales contenidos en la cadena. Toda la infraestructura de la plataforma blockchain puede entenderse como un Blockchain- as-a-Service (BaaS) que permite la creación y gestión por parte de terceros de redes basadas en la nube para empresas dedicadas a la construcción de aplicaciones blo- ckchain. Esta empieza a ser una tendencia creciente y es una de las principales razones para separar la capa de plataforma de la capa de servicio. La idea subyacente es con- seguir un funcionamiento similar al de un host web. Es decir, que ejecute el funciona- miento del backend de una aplicación. La tecnología blockchain funciona de forma que cada bloque almacena un número de registros o transacciones válidas, información relativa a ese bloque, su vínculo con el bloque anterior y el siguiente a través del hash de cada bloque. Cada bloque está vinculado al bloque anterior mediante un hash criptográfico [24]. Todas las transacciones deben ser cifradas con conceptos de Infraestructura de Clave Pública (PKI) para evitar que se vea comprometido con partes no deseadas. Es impor- tante que la identidad y la autorización de la creación de la transacción estén protegidas.
9 La mayoría de las veces esto se hace a través de la dirección, la clave pública y la clave privada de cada usuario en la cadena de bloques. La función de multifirma estará dis- ponible para las transacciones sensibles en la blockchain [25]. Los bloques además con- tienen información relativa a los contratos inteligentes en los que se recogen las cláu- sulas e información de cualquier contrato físico en forma de código y que deberán cum- plirse para publicar un nuevo bloque. La comunidad de SmartContractSecurity [26] ha clasificado en 25 categorías las principales amenazas que afectan a los contratos inteli- gentes y que deben ser tenidos en cuenta en el momento de la modificación o imple- mentación de nuevos contratos como son el consumo incontrolado de recursos, la veri- ficación insuficiente de la autenticidad de datos, accesos a punteros no inicializados o la verificación inadecuada de la firma criptográfica entre otros. 3.6 Capa de red La capa de red es la base sobre la que se sustenta la tecnología blockchain. Básicamente, las redes blockchain son redes que se superponen a otras redes; por lo tanto, heredan los problemas de seguridad y privacidad de las redes subyacentes. La capa de red es, por tanto, una de las bases sobre las que se asienta esta arquitectura siendo crucial contar con soluciones de seguridad que puedan cubrir los problemas de la red. Los principales servicios proporcionados por la capa de red en la tecnología blo- ckchain son la gestión y el descubrimiento peer-to-peer, que se basan en el funciona- miento de la red subyacente, como la resolución de nombres de dominio (DNS) o el enrutamiento de la red (por ejemplo, el enrutamiento LAN para IP, el enrutamiento WAN como BGP). Los problemas de seguridad de la capa de red es uno de los temas de investigación más populares en el campo de la seguridad blockchain [27]. Entre los diferentes ata- ques, los ataques de denegación de servicio distribuidos (DDoS). Así mismo, los ata- ques eclipse son también muy populares. Estos ataques deshabilitan la conexión de un nodo de la red con el resto de los nodos que son utilizados por el atacante [28]. 4 Aplicación de la SRA Se ha utilizado un caso real para analizar la aplicabilidad de la arquitectura propuesta. Nos hemos servido del caso propuesto por Sladic et al. [29] donde presentan la imple- mentación de una notaría sobre la red blockchain que soporta las transacciones realiza- das en el catastro de Serbia. El sistema almacena el vínculo legal entre las propiedades y sus propietarios [30], así como el mapa catastral que contiene los datos geométricos y los atributos topográficos del suelo [31]. La Fig 2. detalla la correlación del caso de estudio con la arquitectura propuesta. Para un mejor entendimiento del caso propuesto, se han destacado los elementos que se correlacionan con nuestra arquitectura dejando en gris aquellos de los que no se hace uso en la propuesta.
10
En la capa de negocio se propone utilizar una cadena de bloques híbrida que permita
la consulta del catastro por la población, pero que garantice que los registros de propie-
dad sean realizados siempre por un notario. En este caso, capa de negocio mapea com-
pletamente con la arquitectura propuesta en este estudio.
Fig. 2. Arquitectura del caso propuesto por Sladic et al. [29]11
A través de la capa de orquestación aseguramos el cumplimiento de uno de los prin-
cipales requisitos de seguridad del sistema que consiste en que todos los usuarios pue-
dan consultar los datos del catastro, pero únicamente puedan ser modificados por la
figura de un notario. Con este fin, se propone que los usuarios únicamente puedan ac-
ceder utilizando sus certificados digitales, documentos digitales que vinculan la clave
pública del usuario con la identidad de este y la autoridad de certificación que verificó
el contenido del certificado. El uso de certificados digitales permite controlar los ries-
gos de accesos no deseados siendo un patrón de seguridad de identificación amplia-
mente extendido. Por otro lado, los requisitos de la cadena deben cumplir con la regu-
lación existente. En este sentido, debe regirse por la Ley de documento electrónico,
identificación electrónica y servicios de confianza en el comercio electrónico [32]. A
este nivel de la arquitectura todos los componentes de la capa de orquestación coinciden
completamente con la arquitectura propuesta.
Así mismo, en la capa de aplicación la información del catastro se mantiene accesi-
ble para todos los usuarios a través de una DApp consistente en un frontal que web
permite el acceso a los datos almacenados en la cadena. El frontend de la DApp utiliza
una web estándar para el desarrollo de la interfaz, es decir, HTML, CSS y JavaScript
para renderizar una página y recuperar detalles directamente desde el backend. Por otro
lado, se presenta una segunda DApp que permite a los notarios almacenar las claves
hash de los documentos durante las actividades de transferencia de derechos. A pesar
de que no se concretan medidas de seguridad para ambas DApps, deben ser considera-
das teniendo en cuenta la tecnología utilizada.
La capa de servicio está orientada a hacer más accesible la cadena de bloques que
difiere con el objetivo de la arquitectura propuesta. La incorporación de elementos de
esta capa dependerá de si se pretende realizar una implementación orientada a obtener
servicios compartidos multiusuario que permitan ahorrar recursos sociales y lograr una
mayor escala. El componente de gestión de identidad ofrece la posibilidad de centrali-
zar la gestión de identidades dado que no se espera que cualquiera pueda generar
transacciones, sino sólo un grupo seleccionado de usuarios. El gestor de identidad con-
tiene la información relativa al usuario dado que en los controles de acceso incluyen la
verificación de que el usuario puede realizar modificaciones. La gestión de la identidad
del grupo seleccionado de usuarios que tienen permiso para generar transacciones en el
sistema se realiza mediante criptografía de clave pública. El usuario que realice un cam-
bio firmará con su certificado electrónico para demostrar su identidad.
La plataforma del sistema propuesto comprende datos alfanuméricos sobre los de-
rechos de propiedad, los titulares de los derechos y los atributos de las propiedades,
como la superficie; y datos geoespaciales (mapa catastral) como resultado de las acti-
vidades topográficas. Estos datos comprenden nuestros activos y pueden ser objeto de
una transacción en blockchain. La transacción constituye una entrada de datos que son
almacenadas en un bloque, perteneciente al libro mayor distribuido, y que contiene la
información de la transacción, es decir, userId, identificación única de una propiedad
(municipio administrativo, municipio catastral, número y subnúmero de la parcela, nú-
mero de un edificio en la parcela/número de la parte de la parcela, número de una uni-
dad de construcción), número del cambio, tipo del cambio y la descripción del cambio.
Además, la transacción se completa con los detalles de la transacción sobre el cambio12
que se ha producido (número del cambio, tipo de cambio, descripción, fecha, etc.). Se
utilizan los Smart contracts [33] para proporcionar seguridad y ejecutar el código de un
contrato inteligente mediante ordenadores en la red de Ethereum. El resultado de la
ejecución también es almacenado en el bloque al realizar una transacción. Por último,
la cadena de bloques contiene la información de los usuarios que han realizado la
transacción. Los usuarios tienen dos claves: una clave privada que sólo conoce el usua-
rio y una clave pública compartida con toda la red. El usuario que ha realizado el cam-
bio firma digitalmente la transacción con su clave privada. Una vez creada, la transac-
ción se inserta en un bloque recién creado (junto con otras transacciones válidas que se
crean al mismo tiempo) y, tras ser verificada por la red, el bloque se añade a la cadena.
La arquitectura de este caso de estudio hace uso de la red P2P para soportar el resto
de las capas de la arquitectura. En este punto no hay diferencia entre los componentes
de arquitectura y nuestra SRA.
Como se ha mencionado anteriormente una SRA pretende ofrecer una arquitectura
con un alto nivel de abstracción que permita cubrir cualquier escenario de implementa-
ción en un sistema blockchain, aplicando la implementación de unos u otros compo-
nentes en función de la necesidad de la propia cadena blockchain. Si observan los com-
ponentes propuestos por Sladic et al. [29] se puede concluir por tanto que el caso se
encuentra alineado con la SRA propuesta en el presente documento permitiéndonos
validar la aplicabilidad de la propuesta.
5 Conclusiones y trabajo futuro
En este trabajo se ha presentado una SRA que sirve de base para el desarrollo de un
sistema blockchain, integrando la seguridad desde las primeras fases del ciclo de vida
de esta tecnología.
Para ello, se han analizado las funcionalidades y componentes fundamentales de
un sistema blockchain propuestos por el NIST [13], y abstraído la estructura y los com-
ponentes de las principales implementaciones de blockchain del mercado. Hemos defi-
nido nuestra SRA a través de diagramas UML, lenguaje ampliamente aceptado que
facilita la comprensión de las relaciones entre los diferentes componentes. Además, el
uso de UML nos ha permitido definir con precisión las relaciones entre los diferentes
componentes y subcomponentes.
Por último, se ha mostrado la aplicabilidad de nuestra propuesta a través de la rea-
lización de un ejemplo real demostrando encajar de forma eficaz e incorporando todos
los elementos necesarios para la implementación del sistema. Como trabajo futuro se
pretende realizar un caso de estudio completo que nos permita validar y refinar nuestra
propuesta.
Agradecimientos
Este trabajo ha sido financiado por el proyecto ECLIPSE (RTI2018-094283-B-C31 fi-
nanciado por el Ministerio de Economía y Competitividad y el Fondo Europeo de Desa-13
rrollo Regional FEDER) y el proyecto GENESIS (SBPLY-17-180501-000202 finan-
ciado por la "Consejería de Educación, Cultura y Deportes de la Dirección General de
Universidades, Investigación e Innovación de la JCCM"), y el Programa Operativo Re-
gional FEDER 2014/2020.
Referencias
1. S. Nakamoto, «Bitcoin: A peer-to-peer electronic cash system,” http://bitcoin. org/bitcoin.
pdf», 2008.
2. «Blockchain IoT Market by Component (Hardware (IoT Sensors & Crypto-Wallets), Soft-
ware and Platform, and Services), Application (Smart Contract, Security, and Asset Track-
ing and Management), Organization Size, Vertical, and Region - Global Forecast to 2026»,
Disponible en: https://www.marketsandmarkets.com/Market-Reports/blockchain-iot-mar-
ket-168941858.html
3. Delloite, «5 Blockchain Trends for 2020». Disponible en: https://www2.deloitte.com/con-
tent/dam/Deloitte/ie/Documents/Consulting/Blockchain-Trends-2020-report.pdf
4. Ciphertrace, «Q1 2019 Cryptocurrency Anti-Money Laundering Report», 2019. https://then-
extweb.com/hardfork/2019/05/01/cryptocurrency-stolen-first-quarter-2019-hack/
5. Wolfie Zhao, «Crypto Exchange Bithumb Hacked for $13 Million in Suspected Insider Job»,
2019. https://www.coindesk.com/crypto-exchange-bithumb-hacked-for-13-million-in-sus-
pected-insider-job
6. Ciphertrace, «Half of 2020 Crypto Hacks are from DeFi Protocols and Exchanges», Cipher-
trace. https://ciphertrace.com/half-of-2020-crypto-hacks-are-from-defi-protocols-and-ex-
changes/
7. Accenture, «Blockchain’s potential starts with security».
8. E. B. Fernandez, R. Monge, y K. Hashizume, «Building a security reference architecture for
cloud systems», Requir. Eng., vol. 21, n.o 2, pp. 225-249, 2016.
9. P. Avgeriou, «Describing, instantiating and evaluating a reference architecture: A case
study», Enterp. Archit. J., vol. 342, pp. 1-24, 2003.
10. E. B. Fernandez, N. Yoshioka, H. Washizaki, y M. H. Syed, «Modeling and security in cloud
ecosystems», Future Internet, vol. 8, n.o 2, p. 13, 2016.
11. A. Deshpande, K. Stewart, L. Lepetit, y S. Gunashekar, «Distributed Ledger Technolo-
gies/Blockchain: Challenges, opportunities and the prospects for standards», Overv. Rep.
Br. Stand. Inst. BSI, vol. 40, p. 40, 2017.
12. UNE 71307-1:2020 Digital Enabling Technologies. Decentralised Identity Management
Model based on Blockchain and other Distributed Ledgers Technologies.
13. D. Yaga, P. Mell, N. Roby, y K. Scarfone, «NISTIR 8202 Blockchain Technology Over-
view». oct. 2018. [En línea]. Disponible en: https://csrc.nist.gov/publications/detail/nis-
tir/8202/final
14. Accredited Standards Committee X9, «ASC X9 Study Group Report Distributed Ledger and
Blockchain Technology Study Group». abr. 2018. [En línea]. Disponible en:
https://x9.org/wp-content/uploads/2018/04/Distributed-Ledger-and-Blockchain-Techno-
logy-Study-Group-Report-FINAL.pdf
15. «ISO/TR 23455:2019 Blockchain and distributed ledger technologies — Overview of and
interactions between smart contracts in blockchain and distributed ledger technology sys-
tems». 2019.
16. S. Schwalm, DIN SPEC 4997 Privacy by Blockchain Design: 2020.14
17. I. Homoliak, S. Venugopalan, Q. Hum, D. Reijsbergen, R. Schumi, y P. Szalachowski, «The
security reference architecture for blockchains: Towards a standardized model for studying
vulnerabilities, threats, and defenses», ArXiv Prepr. ArXiv191009775, 2019.
18. W. Wang et al., «A survey on consensus mechanisms and mining strategy management in
blockchain networks», IEEE Access, vol. 7, pp. 22328-22370, 2019.
19. «Enterprise Ethereum Alliance Client Specification v6». https://entethalliance.github.io/cli-
ent-spec/spec.html (accedido may 17, 2020).
20. «Hyperledger Facbric Architecture Reference». [En línea]. Disponible en: https://hyperled-
ger-fabric.readthedocs.io/en/release-1.3/architecture.html
21. M. Biktimirov, A. Domashev, P. Cherkashin, y A. Y. Shcherbakov, «Blockchain technol-
ogy: Universal structure and requirements», Autom. Doc. Math. Linguist., vol. 51, n.o 6, pp.
235-238, 2017.
22. A. Zaitsev, S. Gostev, P. Cherkashin, y A. Y. Shcherbakov, «Regarding the technology of
distributed storage of confidential information in centers of general-purpose data pro-
cessing», Autom. Doc. Math. Linguist., vol. 51, n.o 3, pp. 117-119, 2017.
23. J. Singh y J. D. Michels, «Blockchain as a Service (BaaS): Providers and Trust», en Pro-
ceedings - 3rd IEEE European Symposium on Security and Privacy Workshops, EURO S
and PW 2018, 2018, pp. 67-74. doi: 10.1109/EuroSPW.2018.00015.
24. W. Meng, E. W. Tischhauser, Q. Wang, Y. Wang, y J. Han, «When intrusion detection meets
blockchain technology: A review», IEEE Access, vol. 6, pp. 10179-10188, 2018, doi:
10.1109/ACCESS.2018.2799854.
25. P. S. G. A. Sri y D. L. Bhaskari, «A study on blockchain technology», Int. J. Eng. Technol.,
vol. 7, pp. 418-421, 2018.
26. «Overview · Smart Contract Weakness Classification and Test Cases». http://swcregistry.io/
(accedido may 17, 2020).
27. H. Hasanova, U. Baek, M. Shin, K. Cho, y M.-S. Kim, «A survey on blockchain cybersecu-
rity vulnerabilities and possible countermeasures», Int. J. Netw. Manag., vol. 29, n.o 2, p.
e2060, 2019.
28. X. Li, P. Jiang, T. Chen, X. Luo, y Q. Wen, «A survey on the security of blockchain sys-
tems», Future Gener. Comput. Syst., 2017.
29. G. Sladić, B. Milosavljević, S. Nikolić, D. Sladić, y A. Radulović, «A Blockchain Solution
for Securing Real Property Transactions: A Case Study for Serbia», ISPRS Int. J. Geo-Inf.,
vol. 10, n.o 1, p. 35, 2021.
30. A. Radulović, D. Sladić, y M. Govedarica, «Towards 3D cadastre in serbia: Development
of serbian cadastral domain model», ISPRS Int. J. Geo-Inf., vol. 6, n.o 10, p. 312, 2017.
31. DJordje Pržulj, N. Radaković, D. Sladić, A. Radulović, y M. Govedarica, «Domain model
for cadastral systems with land use component», Surv. Rev., vol. 51, n.o 365, pp. 135-146,
2019.
32. Official Gazette of the Republic of Serbia, «The Law on Electronic Document, Electronic
Identification and Trust Services in Electronic Business.» 2017.
33. N. Fotiou y G. C. Polyzos, «Smart Contracts for the Internet of Things: Opportunities and
Challenges», en 2018 European Conference on Networks and Communications, EuCNC
2018, 2018, pp. 256-260. doi: 10.1109/EuCNC.2018.8443212.También puede leer
